[要約] RFC 5204は、Host Identity Protocol (HIP) Rendezvous Extensionに関する仕様です。この拡張の目的は、HIPネットワーク内のホストが通信を確立するための中継役を果たすランデブーサーバの機能を提供することです。
Network Working Group J. Laganier
Request for Comments: 5204 DoCoMo Euro-Labs
Category: Experimental L. Eggert
Nokia
April 2008
Host Identity Protocol (HIP) Rendezvous Extension
ホストIDプロトコル（HIP）ランデブー拡張
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Abstract
概要
This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
The Host Identity Protocol (HIP) Architecture [RFC4423] introduces the rendezvous mechanism to help a HIP node to contact a frequently moving HIP node. The rendezvous mechanism involves a third party, the rendezvous server (RVS), which serves as an initial contact point ("rendezvous point") for its clients. The clients of an RVS are HIP nodes that use the HIP Registration Extension [RFC5203] to register their HIT->IP address mappings with the RVS. After this registration, other HIP nodes can initiate a base exchange using the IP address of the RVS instead of the current IP address of the node they attempt to contact. Essentially, the clients of an RVS become reachable at the RVS's IP address. Peers can initiate a HIP base exchange with the IP address of the RVS, which will relay this initial communication such that the base exchange may successfully complete.
ホストIDプロトコル（HIP）アーキテクチャ[RFC4423]は、股関節ノードが頻繁に移動する股関節ノードに接触するのに役立つランデブーメカニズムを導入します。Rendezvousメカニズムには、クライアントの初期接触点（「Rendezvous Point」）として機能する第三者であるRendezvous Server（RVS）が含まれます。RVSのクライアントは、HIP登録拡張機能[RFC5203]を使用してRVSにヒット> IPアドレスマッピングを登録する股関節ノードです。この登録後、他の股関節ノードは、連絡を試みるノードの現在のIPアドレスの代わりに、RVSのIPアドレスを使用してベース交換を開始できます。基本的に、RVSのクライアントはRVSのIPアドレスで到達可能になります。ピアは、RVSのIPアドレスとの股関節ベース交換を開始できます。これにより、ベース交換が正常に完了するようにこの最初の通信を中継します。
This section defines terms used throughout the remainder of this specification.
このセクションでは、この仕様の残りの部分で使用される用語を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In addition to the terminology defined in the HIP specification [RFC5201] and the HIP Registration Extension [RFC5203], this document defines and uses the following terms:
HIP仕様[RFC5201]および股関節登録拡張[RFC5203]で定義されている用語に加えて、このドキュメントは次の用語を定義および使用します。
Rendezvous Service A HIP service provided by a rendezvous server to its rendezvous clients. The rendezvous server offers to relay some of the arriving base exchange packets between the initiator and responder.
RendezvousサービスRendezvousサーバーがランデブークライアントに提供するヒップサービス。Rendezvousサーバーは、イニシエーターとレスポンダーの間に到着するベース交換パケットの一部を中継することを提供します。
Rendezvous Server (RVS) A HIP registrar providing rendezvous service.
Rendezvous Server（RVS）Rendezvousサービスを提供するHIPレジストラ。
Rendezvous Client A HIP requester that has registered for rendezvous service at a rendezvous server.
RendezvousクライアントRendezvousサーバーでRendezvousサービスに登録したヒップリクエスター。
Rendezvous Registration A HIP registration for rendezvous service, established between a rendezvous server and a rendezvous client.
rendezvous登録RendezvousサーバーとRendezvousクライアントの間に確立されたRendezvousサービスのヒップ登録。
Figure 1 shows a simple HIP base exchange without a rendezvous server, in which the initiator initiates the exchange directly with the responder by sending an I1 packet to the responder's IP address, as per the HIP specification [RFC5201].
図1は、HIP仕様[RFC5201]に従って、I1パケットをResponderのIPアドレスに送信することにより、イニシエーターがResponderと直接交換を開始するランデブーサーバーのない単純な股関節ベース交換を示しています。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP base exchange without rendezvous server.
図1：RendezvousサーバーのないHIPベース交換。
The End-Host Mobility and Multihoming with the Host Identity Protocol specification [RFC5206] allows a HIP node to notify its peers about changes in its set of IP addresses. This specification presumes initial reachability of the two nodes with respect to each other.
ホストIDプロトコル仕様[RFC5206]を使用したエンドホストモビリティとマルチホームにより、HIPノードは、IPアドレスのセットの変更について同僚に通知できます。この仕様は、互いに2つのノードの初期到達可能性を推定します。
However, such a HIP node MAY also want to be reachable to other future correspondent peers that are unaware of its location change. The HIP Architecture [RFC4423] introduces rendezvous servers with whom a HIP node MAY register its host identity tags (HITs) and current IP addresses. An RVS relays HIP packets arriving for these HITs to the node's registered IP addresses. When a HIP node has registered with an RVS, it SHOULD record the IP address of its RVS in its DNS record, using the HIP DNS resource record type defined in the HIP DNS Extension [RFC5205].
ただし、このような股関節ノードは、場所の変更に気付いていない他の将来の特派員のピアに到達可能にすることも望んでいる場合があります。HIPアーキテクチャ[RFC4423]は、HIPノードがホストIDタグ（ヒット）と現在のIPアドレスを登録する可能性のあるRendezvousサーバーを導入します。RVSは、これらのヒットに到着したノードの登録IPアドレスに到着する股関節パケットをリレーします。股関節ノードがRVSに登録されている場合、HIP DNS拡張[RFC5205]で定義された股関節DNSリソースレコードタイプを使用して、DNSレコードにRVSのIPアドレスを記録する必要があります。
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server.
図2：ランデブーサーバーとのヒップベース交換。
Figure 2 shows a HIP base exchange involving a rendezvous server. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC5203]. When the initiator I tries to establish contact with the responder R, it must send the I1 of the base exchange either to one of R's IP addresses (if known via DNS or other means) or to one of R's rendezvous servers. Here, I obtains the IP address of R's rendezvous server from R's DNS record and then sends the I1 packet of the HIP base exchange to RVS. RVS, noticing that the HIT contained in the arriving I1 packet is not one of its own, MUST check its current registrations to determine if it needs to relay the packets. Here, it determines that the HIT belongs to R and then relays the I1 packet to the registered IP address. R then completes the base exchange without further assistance from RVS by sending an R1 directly to the I's IP address, as obtained from the I1 packet. In this specification, the client of the RVS is always the responder. However, there might be reasons to allow a client to initiate a base exchange through its own RVS, like NAT and firewall traversal. This specification does not address such scenarios, which should be specified in other documents.
図2は、ランデブーサーバーを含む股関節ベース交換を示しています。HIPノードRは、HIP登録延長[RFC5203]を使用して、以前にRVSにヒットと現在のIPアドレスを登録したと想定されています。イニシエーターIがレスポンダーRとの接触を確立しようとする場合、ベース交換のi1をRのIPアドレスのいずれか（DNSまたはその他の手段で既知の場合）またはRのランデブーサーバーのいずれかに送信する必要があります。ここでは、RのDNSレコードからRのRendezvousサーバーのIPアドレスを取得し、HIPベース交換のi1パケットをRVSに送信します。RVSは、到着するI1パケットに含まれるヒットが独自の1つではないことに気付くことで、現在の登録をチェックして、パケットを中継する必要があるかどうかを判断する必要があります。ここでは、ヒットがRに属し、I1パケットを登録されたIPアドレスにリレーすることを決定します。その後、I1パケットから取得したように、R1をIのIPアドレスに直接送信することにより、RVSからのさらなる支援なしでベース交換を完了します。この仕様では、RVSのクライアントは常に対応者です。ただし、NATやファイアウォールトラバーサルなど、クライアントが独自のRVを介して基本交換を開始できるようにする理由があるかもしれません。この仕様では、そのようなシナリオには対処されておらず、他のドキュメントで指定する必要があります。
Notation Significance
-------- ------------
I, R I and R are the respective source and destination IP addresses in the IP header.
I、R I、Rは、IPヘッダーのそれぞれのソースおよび宛先IPアドレスです。
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the responder's HITs in the packet, respectively.
HIT-I、HIT-R HIT-I、HIT-Rは、それぞれパケットでのイニシエーターとレスポンダーのヒットです。
REG_REQ A REG_REQUEST parameter is present in the HIP header.
reg_req reg_requestパラメーターは股関節ヘッダーに存在します。
REG_RES A REG_RESPONSE parameter is present in the HIP header.
reg_res reg_responseパラメーターは、股関節ヘッダーに存在します。
FROM:I A FROM parameter containing the IP address I is present in the HIP header.
From：I Aは、IPアドレスを含むパラメーターから、股関節ヘッダーに存在します。
RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the appropriate registration key is present in the HIP header.
RVS_HMAC適切な登録キーを備えたHMACを含むRVS_HMACパラメーターは、股関節ヘッダーに存在します。
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a rendezvous server is present in the HIP header.
Via：RVS A via_rvsパラメーターランデブーサーバーのIPアドレスRVがHIPヘッダーに存在します。
Before a rendezvous server starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with it to receive rendezvous service by using the HIP Registration Extension [RFC5203] as illustrated in the following schema:
ランデブーサーバーがヒップパケットをランデブークライアントにリレーし始める前に、ランデブークライアントは、次のスキーマに示されているように、股関節登録拡張[RFC5203]を使用してランデブーサービスを受信するために登録する必要があります。
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
Rendezvous client registering with a rendezvous server.
Rendezvousクライアントは、Rendezvousサーバーに登録します。
If a HIP node and one of its rendezvous servers have a rendezvous registration, the rendezvous servers relay inbound I1 packets (that contain one of the client's HITs) by rewriting the IP header. They replace the destination IP address of the I1 packet with one of the IP addresses of the owner of the HIT, i.e., the rendezvous client. They MUST also recompute the IP checksum accordingly.
股関節ノードとそのランデブーサーバーの1つがランデブー登録を持っている場合、ランデブーサーバーはIPヘッダーを書き換えることによりインバウンドI1パケット（クライアントのヒットの1つを含む）をリレーします。I1パケットの宛先IPアドレスを、ヒットの所有者のIPアドレスの1つ、つまりRendezvousクライアントに置き換えます。また、それに応じてIPチェックサムを再計算する必要があります。
Because of egress filtering on the path from the RVS to the client [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source IP address, i.e., the IP address of I, with one of its own IP addresses. The replacement IP address SHOULD be chosen according to relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because this replacement conceals the initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet. This FROM parameter MUST be integrity protected by an RVS_HMAC keyed with the corresponding rendezvous registration integrity key [RFC5203].
RVSからクライアント[RFC2827] [RFC3013]へのパスでの出口フィルタリングのため、股関節ランデブーサーバーはソースIPアドレス、つまりIのIPアドレスを独自のIPアドレスの1つに置き換える必要があります。交換IPアドレスは、関連するIPv4およびIPv6仕様[RFC1122] [RFC3484]に従って選択する必要があります。この交換はイニシエーターのIPアドレスを隠すため、RVSはパケットの元のソースIPアドレスを含むパラメーターからAを追加する必要があります。これは、パラメーターから、対応するランデブー登録整合性キー[RFC5203]を備えたRVS_HMACによって保護されている必要があります。
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous server rewriting IP addresses.
Rendezvousサーバーの書き換えIPアドレス。
This modification of HIP packets at a rendezvous server can be problematic because the HIP protocol uses integrity checks. Because the I1 does not include HMAC or SIGNATURE parameters, these two end-to-end integrity checks are unaffected by the operation of rendezvous servers.
ランデブーサーバーでのこの股関節パケットの変更は、股関節プロトコルが整合性チェックを使用するため、問題が発生する可能性があります。I1にはHMACまたは署名パラメーターが含まれていないため、これら2つのエンドツーエンドの整合性チェックは、Rendezvousサーバーの動作により影響を受けません。
The RVS SHOULD verify the checksum field of an I1 packet before doing any modifications. After modification, it MUST recompute the checksum field using the updated HIP header, which possibly included new FROM and RVS_HMAC parameters, and a pseudo-header containing the updated source and destination IP addresses. This enables the responder to validate the checksum of the I1 packet "as is", without having to parse any FROM parameters.
RVSは、変更を行う前に、I1パケットのチェックサムフィールドを検証する必要があります。変更後、更新された股関節ヘッダーを使用してチェックサムフィールドを再計算する必要があります。これにより、パラメーターから解析することなく、Responderがi1パケットの「現状のまま」のチェックサムを検証することができます。
This section describes extensions to the HIP Registration Extension [RFC5203], allowing a HIP node to register with a rendezvous server for rendezvous service and notify the RVS aware of changes to its current location. It also describes an extension to the HIP specification [RFC5201] itself, allowing establishment of HIP associations via one or more HIP rendezvous server(s).
このセクションでは、股関節登録拡張機能[RFC5203]への拡張機能について説明します。これにより、HIPノードはRendezvousサービス用のRendezvousサーバーに登録し、RVSに現在の場所への変更を認識します。また、股関節仕様[RFC5201]自体への拡張を説明し、1つ以上の股関節ランデブーサーバーを介して股関節関連を確立できるようにします。
This specification defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
この仕様では、Rendezvousサービス用のRendezvousサーバーへの登録を可能にする、股関節登録拡張拡張拡張機能[RFC5203]の追加登録を定義します。
Number Registration Type
------ -----------------
1 RENDEZVOUS
The RVS_HMAC is a non-critical parameter whose only difference with the HMAC parameter defined in the HIP specification [RFC5201] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC):
RVS_HMACは、股関節仕様[RFC5201]で定義されているHMACパラメーターとの唯一の違いがその「タイプ」コードです。この変更により、From Parameterの後に（HMACとは対照的に）配置されます。
Type 65500 Length Variable. Length in octets, excluding Type, Length, and Padding. HMAC HMAC computed over the HIP packet, excluding the RVS_HMAC parameter and any following parameters. The HMAC is keyed with the appropriate HIP integrity key (HIP-lg or HIP-gl) established when rendezvous registration happened. The HIP "checksum" field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameter when the HMAC is calculated. The size of the HMAC is the natural size of the hash computation output depending on the used hash function.
タイプ65500長さ変数。オクテットの長さ、タイプ、長さ、およびパディングを除く。HMAC HMACは、RVS_HMACパラメーターと次のパラメーターを除く、股関節パケットを介して計算されました。HMACは、Rendezvous登録が発生したときに確立された適切なHip Integrityキー（HIP-LGまたはHIP-GL）が確立されています。股関節「チェックサム」フィールドはゼロに設定する必要があり、HMACが計算されたときに除外されたパラメーターをカバーしないように、股関節のヘッダー長の股関節ヘッダーの長さを計算する必要があります。HMACのサイズは、使用されたハッシュ関数に応じて、ハッシュ計算出力の自然なサイズです。
To allow a rendezvous client and its RVS to verify the integrity of packets flowing between them, both SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity key established while registration occurred. A valid RVS_HMAC SHOULD be present on every packet flowing between a client and a server and MUST be present when a FROM parameter is processed.
RendezvousクライアントとそのRVがそれらの間で流れるパケットの整合性を検証できるようにするために、両方とも登録が発生している間に確立されたHIP-LGまたはHIP-GLの完全性キーをキーにした追加のRVS_HMACパラメーターでパケットを保護する必要があります。クライアントとサーバーの間に流れるすべてのパケットに有効なRVS_HMACが存在する必要があり、FROM PARAMETERが処理されたときに存在する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498 Length 16 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
タイプ65498長さ16アドレスIPv6アドレスまたはIPv4-in-IPV6形式IPv4アドレス。
A rendezvous server MUST add a FROM parameter containing the original source IP address of a HIP packet whenever the source IP address in the IP header is rewritten. If one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones.
Rendezvousサーバーは、IPヘッダーのソースIPアドレスが書き直されるたびに、股関節パケットの元のソースIPアドレスを含むパラメーターからAを追加する必要があります。パラメーターから1つ以上が既に存在する場合、既存のパラメーターから新しいパラメーターを追加する必要があります。
Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC protecting the packet integrity, especially the IP address included in the FROM parameter.
RVSがパラメーターからaを挿入するときはいつでも、パケットの整合性、特にPramerに含まれるIPアドレスを保護するRVS_HMACを挿入する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65502 Length Variable Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
タイプ65502長さ変数アドレスIPv6アドレスまたはIPv4-in-IPV6形式IPv4アドレス。
After the responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the initiator's IP address, without further assistance from an RVS. For debugging purposes, it MAY include a subset of the IP addresses of its RVSs in some of these packets. When a responder does so, it MUST append a newly created VIA_RVS parameter at the end of the HIP packet. The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues encountered while establishing a HIP association via an RVS.
RESPONDERがリレーしたI1パケットを受け取った後、RVSの支援なしに、イニシエーターのIPアドレスにアドレス指定された股関節パケットを送信し始めることができます。デバッグのために、これらのパケットの一部にRVSSのIPアドレスのサブセットが含まれる場合があります。レスポンダーがそうする場合、股関節パケットの最後に新しく作成されたvia_rvsパラメーターを追加する必要があります。VIA_RVSパラメーターを使用する主な目標は、RVSを介して股関節関連を確立しながら遭遇する可能性のある問題をオペレーターが診断できるようにすることです。
The following subsections describe the differences of processing of I1 and R1 while a rendezvous server is involved in the base exchange.
以下のサブセクションでは、I1とR1の処理の違いについて説明しますが、ランデブーサーバーがベース交換に関与しています。
An initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address that is known to be a rendezvous server address, unless it wants to establish a HIP association with the rendezvous server itself and does not know its HIT.
When an RVS rewrites the source IP address of an I1 packet due to egress filtering, it MUST add a FROM parameter to the I1 that contains the initiator's source IP address. This FROM parameter MUST be protected by an RVS_HMAC keyed with the integrity key established at rendezvous registration.
RVSが出口フィルタリングのためにi1パケットのソースIPアドレスを書き換える場合、イニシエーターのソースIPアドレスを含むi1にパラメーターからAを追加する必要があります。パラメーターからこれは、Rendezvous登録時に確立されたIntegrity Keyを備えたRVS_HMACによって保護する必要があります。
When a rendezvous server receives an I1 whose destination HIT is not its own, it consults its registration database to find a registration for the rendezvous service established by the HIT owner. If it finds an appropriate registration, it relays the packet to the registered IP address. If it does not find an appropriate registration, it drops the packet.
rendezvousサーバーが宛先ヒットが独自のものではないi1を受信すると、登録データベースを参照して、ヒット所有者によって確立されたランデブーサービスの登録を見つけます。適切な登録が見つかった場合、登録されたIPアドレスにパケットを中継します。適切な登録が見つからない場合、パケットをドロップします。
A rendezvous server SHOULD interpret any incoming opportunistic I1 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself and SHOULD NOT attempt to relay it to one of its clients.
Rendezvousサーバーは、着信する日和見I1（つまり、ヌルの宛先ヒットを持つI1）をI1と解釈する必要があります。
When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM parameter is present, the packet MUST be dropped.
RendezvousクライアントがI1を受信した場合、現在のRVS_HMACパラメーターを検証する必要があります。RVS_HMACを検証できない場合、パケットをドロップする必要があります。RVS_HMACを検証できず、PARAMETER FROM PARAMETERが存在する場合、パケットをドロップする必要があります。
A rendezvous client acting as responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed.
Responderとして作用するランデブークライアントは、i1が中継されていることを示すため、ParameterからのAを含む日和見的なi1をドロップする必要があります。
When a responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVSs.
RVSを介してリレーされたI1に応答者が応答する場合、トラバースRVSSのIPアドレスを含む通常のR1ヘッダーA VIA_RVSパラメーターに追加する必要があります。
The HIP specification [RFC5201] mandates that a system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., the system is in state I1-SENT). When the R1 is replying to a relayed I1, this check SHOULD be based on HITs only. In case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter.
HIP仕様[RFC5201]は、R1を受信するシステムが最初にR1の発信者にI1を送信したかどうかを確認する必要があることを義務付けています（つまり、システムは状態I1-SENTにあります）。R1がリレーされたI1に応答している場合、このチェックはヒットのみに基づいている必要があります。IPアドレスもチェックされている場合は、VIO_RVSパラメーターに含まれるIPアドレスに対してソースIPアドレスをチェックする必要があります。
This section discusses the known threats introduced by these HIP extensions and the implications on the overall security of HIP. In particular, it argues that the extensions described in this document do not introduce additional threats to the Host Identity Protocol.
このセクションでは、これらの股関節拡張によって導入された既知の脅威と、股関節の全体的なセキュリティに対する影響について説明します。特に、このドキュメントで説明されている拡張機能は、ホストIDプロトコルに追加の脅威を導入していないと主張しています。
It is difficult to encompass the whole scope of threats introduced by rendezvous servers because their presence has implications both at the IP and HIP layers. In particular, these extensions might allow for redirection, amplification, and reflection attacks at the IP layer, as well as attacks on the HIP layer itself, for example, man-in-the-middle attacks against the HIP base exchange.
Rendezvousサーバーによって導入された脅威の範囲全体を含めることは困難です。なぜなら、その存在はIP層と股関節層の両方に影響を与えるからです。特に、これらの拡張は、IP層でのリダイレクト、増幅、および反射攻撃、および股関節層自体の攻撃、たとえば股関節ベース交換に対する中間の攻撃を可能にする可能性があります。
If an initiator has a priori knowledge of the responder's host identity when it first contacts the responder via an RVS, it has a means to verify the signatures in the HIP base exchange, which protects against man-in-the-middle attacks.
イニシエーターがRVSを介して最初にレスポンダーに接触したときにレスポンダーのホストIDの先験的な知識を持っている場合、それは、中間の攻撃から保護するヒップベース交換の署名を検証する手段を持っています。
If an initiator does not have a priori knowledge of the responder's host identity (so-called "opportunistic initiators"), it is almost impossible to defend the HIP exchange against these attacks, because the public keys exchanged cannot be authenticated. The only approach would be to mitigate hijacking threats on HIP state by requiring an R1 answering an opportunistic I1 to come from the same IP address that originally sent the I1. This procedure retains a level of security that is equivalent to what exists in the Internet today.
イニシエーターがレスポンダーのホストアイデンティティ（いわゆる「日和見イニシエーター」）の先験的な知識を持っていない場合、交換されたパブリックキーを認証できないため、これらの攻撃に対する股関節交換を守ることはほとんど不可能です。唯一のアプローチは、R1が日和見I1に応答することを要求することにより、I1を元々送信した同じIPアドレスから来ることを要求することにより、ヒップ状態のハイジャックの脅威を軽減することです。この手順は、今日のインターネットに存在するものと同等のセキュリティのレベルを保持しています。
However, for reasons of simplicity, this specification does not allow the establishment of a HIP association via a rendezvous server in an opportunistic manner.
ただし、簡単にするため、この仕様では、日和見的な方法でランデブーサーバーを介して股関節関連を確立することはできません。
This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
このセクションは、RFCS [RFC2434]にIANA考慮事項セクションを作成するためのガイドラインに従って解釈されます。
This document updates the IANA Registry for HIP Parameters Types by assigning new HIP Parameter Types values for the new HIP Parameters defined in Section 4.2:
このドキュメントは、セクション4.2で定義されている新しい股関節パラメーターの新しい股関節パラメータータイプの値を割り当てることにより、股関節パラメータータイプのIANAレジストリを更新します。
o RVS_HMAC (defined in Section 4.2.1)
o RVS_HMAC（セクション4.2.1で定義）
o FROM (defined in Section 4.2.2)
o から（セクション4.2.2で定義）
o VIA_RVS (defined in Section 4.2.3) This document defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
o VIA_RVS（セクション4.2.3で定義）このドキュメントでは、RendezvousサービスのためにRendezvousサーバーに登録できる股関節登録拡張拡張機能[RFC5203]の追加登録を定義しています。
Number Registration Type
------ -----------------
1 RENDEZVOUS
The following people have provided thoughtful and helpful discussions and/or suggestions that have improved this document: Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen Quittek.
以下の人々は、この文書を改善した思慮深く有益な議論や提案を提供してきました：マーカス・ブルナー、トム・ヘンダーソン、ミカ・コム、ミカ・クーサ、ペッカ・ニカンダー、ジャスティノ・サントス、サイモン・シューッツ、ティム・シェパード、クリスチャン・スラボフ、マーティン・スティミーリング、Juergen Quittek。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203] Laganier、J.、Koponen、T。、およびL. Eggert、「Host Identity Protocol（HIP）登録拡張」、RFC 5203、2008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205] Nikander、P。およびJ. Laganier、「ホストIDプロトコル（HIP）ドメイン名システム（DNS）拡張機能」、RFC 5205、2008年4月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013] Killalea、T。、「推奨されるインターネットサービスプロバイダーセキュリティサービスと手順」、BCP 46、RFC 3013、2000年11月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Henderson、T.、ed。、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
Julien Laganier Docomo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687ドイツ
Phone: +49 89 56824 231
EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.Box 407 Nokia Group 00045フィンランド
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。