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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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.
この文書では、ホスト識別プロトコル（HIP）のためのランデブー拡張子を定義します。ランデブー拡張はHIP及びHIPランデブーサーバを介してHIPノード間の通信を開始するためのHIP登録拡張を拡張します。 HIPノードがマルチホームや携帯しているとき、ランデブーサーバは、到達可能性と操作性を向上します。
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.
ホスト識別プロトコル（HIP）アーキテクチャ[RFC4423]は、頻繁に移動するHIPノードを連絡するHIPノードを支援するためのランデブーメカニズムを導入しています。ランデブーメカニズムは、そのクライアントのために初期接触点（「ランデブーポイント」）として機能し、第三者、ランデブーサーバ（RVS）を含みます。 RVSのクライアントは、RVSで自分のHIT-> IPアドレスのマッピングを登録するにはHIP登録拡張[RFC5203]を使用HIPノードです。この登録後、他のHIPノードはRVSの代わりに、彼らが連絡しようとするノードの現在のIPアドレスのIPアドレスを使用して、塩基交換を開始することができます。基本的に、RVSのクライアントは、RVSのIPアドレスに到達可能になります。ピアは、塩基交換が正常に完了することができるように、この最初の通信を中継するRVSのIPアドレスを持つHIP基本交換を開始することができます。
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]とHIP登録拡張[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.
ランデブーサービスのランデブークライアントへランデブーサーバが提供するHIPサービス。ランデブーサーバは、イニシエータとレスポンダとの間に到着した塩基交換パケットの一部を中継するために提供しています。
Rendezvous Server (RVS) A HIP registrar providing rendezvous service.
ランデブーサーバ（RVS）ランデブーサービスを提供するHIPレジストラ。
Rendezvous Client A HIP requester that has registered for rendezvous service at a rendezvous server.
ランデブークライアントランデブーサーバでランデブーサービスに登録されたHIPリクエスタ。
Rendezvous Registration A HIP registration for rendezvous service, established between a rendezvous server and a rendezvous client.
ランデブーサーバとランデブークライアント間で確立ランデブー登録ランデブーサービスのHIP登録、。
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]に従って、応答者のIPアドレスにI1パケットを送信することによって応答と直接交換を開始したランデブーサーバない単純なHIP基本交換を示しています。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP base exchange without rendezvous server.
図1：ランデブーサーバなしで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.
ホストアイデンティティプロトコル仕様[RFC5206]とエンドホストモビリティとマルチホーミングはHIPノードは、IPアドレスのセットの変更についてのピアに通知することができます。この仕様は、互いに対して二つのノードの最初の到達可能性を推定します。
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ノードも、その位置の変化に気づいていない他の将来の特派ピアに到達可能にすることができます。 HIPアーキテクチャ[RFC4423]はHIPノードは、そのホストIDタグ（ヒット）と、現在のIPアドレスを登録することができ、誰とランデブーサーバを導入しています。 RVSは、ノードの登録済みIPアドレスにこれらのヒットのために到着HIPパケットを中継します。 HIPノードはRVSに登録された場合には、HIP DNS拡張[RFC5205]で定義されたHIPのDNSリソースレコードタイプを使用して、そのDNSレコードにそのRVSのIPアドレスを記録する必要があります。
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server.
図2：ランデブーサーバとHIP基本交換。
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
図2は、ランデブーサーバを伴うHIP基本交換を示しています。 HIPノードRは、先にHIP登録拡張[RFC5203]を使用して、そのヒットとRVSとの現在のIPアドレスを登録しているものとします。イニシエータは、私はとの接続を確立しようとすると
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.
応答Rは、それはRのIPアドレスの1つに（DNSまたは他の手段を介して既知の場合）またはRのランデブーサーバの1つにいずれかの塩基交換のI1を送信する必要があります。ここで、私はRのDNSレコードからRのランデブーサーバのIPアドレスを取得し、RVSにHIPベース交換のI1パケットを送信します。到着I1パケットに含まHITは、独自のものではないことに気付いRVSは、それがパケットを中継する必要があるかどうかを決定するために、現在の登録をチェックしなければなりません。ここでは、それはHITがRに属していると判断して、登録されたIPアドレスへのI1パケットを中継します。 Rは、I1パケットから取得したとして、私のIPアドレスに直接R1を送信することにより、RVSからの更なる支援なし塩基交換を完了します。本明細書では、RVSのクライアントは常に応答者です。しかし、その理由は、クライアントがNATやファイアウォール越えのように、独自のRVSを介してベース交換を開始できるようにすることがあるかもしれません。この仕様は、他の文書で指定されなければならないようなシナリオに対処しません。
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を-Iを押すとHIT-Rをそれぞれ、パケットにイニシエータのと応答のヒット曲です。
REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_REQ A REG_REQUESTパラメータは、HIPヘッダ内に存在します。
REG_RES A REG_RESPONSE parameter is present in the HIP header.
REG_RES A REG_RESPONSEパラメータは、HIPヘッダ内に存在します。
FROM:I A FROM parameter containing the IP address I is present in the HIP header.
FROM：I IはHIPヘッダ内に存在するIPアドレスを含むパラメータFROM。
RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the appropriate registration key is present in the HIP header.
適切な登録キーとキー止めHMACを含むRVS_HMACアンRVS_HMACパラメータは、HIPヘッダ内に存在します。
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a rendezvous server is present in the HIP header.
VIAは：ランデブーサーバのIPアドレスRVSを含むVIA_RVSパラメータはHIPヘッダに存在するRVS。
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:
ランデブーサーバがランデブークライアントにHIPパケットを中継するために開始する前に、ランデブークライアントは、次のスキーマに示すように、HIP登録拡張[RFC5203]を使用してランデブーサービスを受けるためにそれに登録する必要があります。
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
Rendezvous client registering with a rendezvous server.
ランデブーサーバに登録ランデブークライアント。
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.
HIPノードとそのランデブーサーバーのいずれかがランデブー登録をお持ちの場合は、ランデブーサーバは、IPヘッダを書き換えることにより、（クライアントのヒットの一つを含んで）インバウンドI1パケットを中継します。彼らは、HIT、すなわち、ランデブークライアントの所有者のIPアドレスのいずれかでI1パケットの宛先IPアドレスを交換してください。彼らはまた、それに応じて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].
そのため、クライアント[RFC2827] [RFC3013]へのRVSからのパスに出力フィルタリングの、HIPランデブーサーバは、独自のIPアドレスの1つに、送信元IPアドレス、Iのすなわち、IPアドレスを交換する必要があります。置換IPアドレスは、関連するIPv4とIPv6の仕様[RFC1122]、[RFC3484]に従って選択されるべきです。この交換は、イニシエータのIPアドレスを隠しているため、RVSは、パケットの元のソースIPアドレスを含むパラメータFROM追加する必要があります。このからのパラメータは、対応するランデブー登録インテグリティキー[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.
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.
HIPプロトコルが整合性チェックを使用するため、ランデブーサーバでHIPパケットのこの変形は問題となり得ます。 I1は、HMACや署名のパラメータが含まれていないため、これらの二つのエンドツーエンドの整合性チェックは、ランデブーサーバの動作に影響されません。
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パケットのチェックサムフィールドを確認する必要があります。修正後、更新された可能性から新しい含まHIPヘッダ、及びRVS_HMACパラメータ、および更新された送信元および宛先IPアドレスを含む疑似ヘッダを使用してチェックサムフィールドを再計算しなければなりません。これは、パラメータから任意のものを解析することなく、「そのまま」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).
このセクションでは、HIPノードはランデブーサービスのランデブーサーバに登録し、その現在の場所への変更を認識RVSを通知することができ、HIP登録拡張[RFC5203]の拡張を記述しています。それはまた、1つ以上のHIPランデブーサーバ（複数可）を介してHIPアソシエーションの確立を可能にする、HIP仕様[RFC5201]自体の拡張を記述しています。
This specification defines an additional registration for the HIP Registration Extension [RFC5203] that allows registering with a rendezvous server for rendezvous service.
この仕様は、ランデブーサービスのためのランデブーサーバに登録することができますHIP登録拡張[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は、その唯一の違いHIP仕様[RFC5201]で定義されたHMACパラメータを使用してその「タイプ」コードである非重要なパラメータです。この変更は、それがFROMパラメータ（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パラメータと任意の次のパラメータを除く、HIPパケットにわたって計算しました。 HMACは、適切なHIP完全性キーで鍵がかけられ（HIP-LGやHIP-GL）ランデブー登録が起こったときに設立します。 HIP「チェックサム」フィールドはゼロに設定しなければなりません、そしてHIP共通ヘッダにおけるHIPヘッダ長は、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.
ランデブークライアントとそのRVSは、それらの間を流れるパケットの整合性を検証できるようにするには、両方の登録が発生している間に確立HIP-LGやHIP-GL完全性キーでキーを追加RVS_HMACパラメータを指定してパケットを保護すべきです。有効な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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498 Length 16 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
65498長さ16のアドレスアンIPv6アドレスまたはIPv4インの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.
ランデブーサーバは、IPヘッダの送信元IPアドレスが書き換えられるたびにHIPパケットの元の送信元IPアドレスを含むパラメーターから、追加しなければなりません。パラメータから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は、パラメータからの挿入するたびに、それは特に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インの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.
応答者が中継I1パケットを受信した後、それはRVSからのさらなる支援を受けず、イニシエータのIPアドレスに宛てHIPパケットを送信し始めることができます。デバッグのために、それはこれらのパケットの一部ではそのRVSSのIPアドレスのサブセットを含むかもしれません。レスポンダがそうするとき、それはHIPパケットの最後に新しく作成されたVIA_RVSパラメータを追加しなければなりません。 VIA_RVSパラメータを使用しての主な目標は、事業者がRVSを経由してのHIPアソシエーションを確立中に発生した可能性のある問題を診断することができるようにすることです。
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.
イニシエータは、それがランデブーサーバ自体とのHIPアソシエーションを確立したいとHITを知らない場合を除き、ランデブーサーバのアドレスであることが知られているIPアドレスにNULL先HITと日和見I1を送るべきではありません。
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アドレスを書き換えた場合は、パラメータFROMイニシエータの送信元IPアドレスが含まれているI1に追加する必要があります。パラメータFROMこれは、ランデブー登録時に確立インテグリティキーとキー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.
ランデブーサーバが宛先HIT独自のではないI1を受信すると、HITの所有者によって確立されたランデブーサービスの登録を見つけるために、その登録データベースを調べます。それは適切な登録を見つけた場合、それが登録された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.
ランデブーサーバが着信日和見I1を解釈すべきである（すなわち、NULL先HITと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.
ランデブークライアントがI1を受信すると、それはどんな存在RVS_HMACパラメータを検証する必要があります。 RVS_HMACが確認できない場合、パケットは廃棄されるべきです。 RVS_HMACを検証することができず、FROMパラメータaが存在する場合、パケットは廃棄されなければなりません。
A rendezvous client acting as responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed.
これはI1が中継されたことを示しているので、レスポンダとして動作するランデブークライアントは、パラメータFROM含ま日和見I1sを削除する必要があります。
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.
I1に応答応答がRVSを介して中継されるとき、それは、通常R1ヘッダに横断RVSSのIPアドレスを含む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-SENTである）にI1を送信したかどうかをチェックしなければならない義務。 R1がリレーI1に返信されると、このチェックはヒットのみに基づくべきです。場合にはIPアドレスも、ソースのIPアドレスがVIA_RVSパラメータに含まれる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.
このセクションでは、これらのHIP拡張機能やHIPの全体的なセキュリティ上の影響により導入された既知の脅威について説明します。特に、この文書で説明する機能拡張は、ホストアイデンティティプロトコルへの追加の脅威を導入していないと主張します。
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.
彼らの存在は、IPおよびHIP層の両方の意味を持っているので、ランデブーサーバが導入された脅威の全体の範囲を網羅することは困難です。具体的には、これらの拡張は、IP層、並びに例えばHIP層自体への攻撃、HIP基本交換に対するman-in-the-middle攻撃でリダイレクション、増幅、および反射攻撃を可能にするかもしれません。
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を経由して、それが最初に接触応答者の事前知識を持っている場合、それはman-in-the-middle攻撃から保護HIP基本交換に署名を検証する手段を有しています。
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.
イニシエータは、レスポンダのホストアイデンティティ（いわゆる「日和見イニシエータ」）の先験的な知識を持っていない場合は、公開鍵を認証することはできません交換するので、これらの攻撃に対するHIP交換を守ることはほとんど不可能です。唯一の方法は、もともとI1を送信し、同じIPアドレスから来るように日和見I1に答えるR1を要求することにより、HIP状態でハイジャックの脅威を軽減することです。この手順は、今日インターネットに存在するものと同等であるセキュリティのレベルを保持します。
However, for reasons of simplicity, this specification does not allow the establishment of a HIP association via a rendezvous server in an opportunistic manner.
しかしながら、単純化の理由のために、この仕様は、日和見方法でランデブーサーバを介してHIPアソシエーションの確立を許可しません。
This section is to be interpreted according to the Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434].
このセクションでは、RFCに[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で定義された新しいHIPパラメータのための新しいHIPパラメータタイプ値を割り当てることによって、HIPパラメータタイプのためのIANAレジストリを更新します。
o RVS_HMAC (defined in Section 4.2.1)
RVS_HMAC O（セクション4.2.1で定義されました）
o FROM (defined in Section 4.2.2)
（セクション4.2.2で定義されている）から、O
o VIA_RVS (defined in Section 4.2.3)
VIA_RVS O（セクション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.
この文書では、ランデブーサービスのためのランデブーサーバに登録することができますHIP登録拡張[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.
マーカスブルンナー、トム・ヘンダーソン、Miikaこむ、ミカKousa、ペッカNikander、Justinoサントス、サイモンSchuetz、ティム・シェパード、クリスチャンSlavov、マーティンStiemerling、そして次の人は、このドキュメントを改善している思慮深く、有用な議論、および/または提案を提供していますユルゲンQuittek。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、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.エッゲルト、 "ホストアイデンティティプロトコル（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、 "ホストアイデンティティプロトコル（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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]ヘンダーソン、T.、エド。、「エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで」、RFC 5206、2008年4月。
Authors' Addresses
著者のアドレス
Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany
ジュリアンLAGANIERドコモコミュニケーション研究所ヨーロッパ社ランデスシュトラーセ312 80687ミュンヘンドイツ
Phone: +49 89 56824 231 EMail: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/
電話：+49 89 56824 231 Eメール：julien.ietf@laposte.net URI：http://www.docomolab-euro.com/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/
電話番号：+358 50 48 24461電子メール：lars.eggert@nokia.com URI：http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。