[要約] RFC 8004は、Host Identity Protocol (HIP) Rendezvous Extensionに関するものであり、HIPの機能を拡張し、ネットワーク上のホスト同士の通信を容易にすることを目的としています。
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 8004 Luminate Wireless, Inc.
Obsoletes: 5204 L. Eggert
Category: Standards Track NetApp
ISSN: 2070-1721 October 2016
Host Identity Protocol (HIP) Rendezvous Extension
Host Identity Protocol（HIP）ランデブー拡張
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 multihomed or mobile. This document obsoletes RFC 5204.
このドキュメントでは、ホストアイデンティティプロトコル（HIP）のランデブー拡張を定義します。ランデブー拡張は、HIPおよびHIP登録拡張を拡張して、HIPランデブーサーバーを介してHIPノード間の通信を開始します。ランデブーサーバーは、HIPノードがマルチホームまたはモバイルである場合の到達可能性と操作を改善します。このドキュメントはRFC 5204を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8004.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8004で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
"The Host Identity Protocol (HIP) Architecture" [HIP-ARCH] 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 [RFC8003] 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）アーキテクチャ」[HIP-ARCH]は、ランデブーメカニズムを導入して、HIPノードが頻繁に移動するHIPノードに接続できるようにします。ランデブーメカニズムには、サードパーティのランデブーサーバー（RVS）が関与します。RVSは、クライアントの初期の接点（「ランデブーポイント」）として機能します。 RVSのクライアントは、HIP Registration Extension [RFC8003]を使用してHIT-> IPアドレスマッピングをRVSに登録するHIPノードです。この登録後、他のHIPノードは、接続しようとするノードの現在のIPアドレスの代わりに、RVSの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 [RFC7401] and the HIP Registration Extension [RFC8003], this document defines and uses the following terms:
HIP仕様[RFC7401]およびHIP Registration Extension [RFC8003]で定義されている用語に加えて、このドキュメントでは次の用語を定義して使用します。
Rendezvous Service A HIP service provided by an RVS to its rendezvous clients. The RVS offers to relay some of the arriving base exchange packets between the Initiator and Responder.
ランデブーサービスRVSがランデブークライアントに提供するHIPサービス。 RVSは、イニシエーターとレスポンダーの間で到着するベース交換パケットの一部を中継することを提供します。
Rendezvous Server (RVS) A HIP registrar providing rendezvous service.
ランデブーサーバー（RVS）ランデブーサービスを提供するHIPレジストラ。
Rendezvous Client A HIP requester that has registered for rendezvous service at an RVS.
ランデブークライアントRVSでランデブーサービスに登録したHIPリクエスター。
Rendezvous Registration A HIP registration for rendezvous service, established between an RVS and a rendezvous client.
ランデブー登録RVSとランデブークライアントの間に確立されたランデブーサービスのHIP登録。
Figure 1 shows a simple HIP base exchange without an RVS, 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 [RFC7401].
図1は、RVSのない単純なHIPベース交換を示しています。イニシエーターは、HIP仕様[RFC7401]に従って、I1パケットをレスポンダーのIPアドレスに送信することにより、レスポンダーと直接交換を開始します。
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP Base Exchange without a Rendezvous Server
図1：RendezvousサーバーのないHIP Base Exchange
The End-Host Mobility and Multihoming with the HIP specification [HIP-HOST-MOB] 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.
エンドホストモビリティとHIP仕様のマルチホーミング[HIP-HOST-MOB]を使用すると、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 [HIP-ARCH] introduces RVSs 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 [RFC8005].
ただし、そのようなHIPノードは、その場所の変更を認識していない他の将来の通信相手にも到達可能にする必要があります。 HIPアーキテクチャ[HIP-ARCH]は、HIPノードがホストIDタグ（HIT）と現在のIPアドレスを登録できるRVSを導入します。 RVSは、これらのHITに到着するHIPパケットをノードの登録済みIPアドレスに中継します。 HIPノードがRVSに登録されると、HIP DNS拡張[RFC8005]で定義されたHIP DNSリソースレコードタイプを使用して、RVSのIPアドレスをDNSレコードに記録する必要があります（SHOULD）。
+-----+
+--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 an RVS. It is assumed that HIP node R previously registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC8003]. 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 RVSs. Here, I obtains the IP address of R's RVS 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 (such as NAT and firewall traversal) to allow a client to initiate a base exchange through its own RVS. This specification does not address such scenarios, which should be specified in other documents.
図2は、RVSを含むHIPベース交換を示しています。 HIPノードRは、HIP Registration Extension [RFC8003]を使用して、以前にHITと現在のIPアドレスをRVSに登録したと想定しています。イニシエーターIがレスポンダーRとの接続を確立しようとするとき、ベース交換のI1をRのIPアドレスの1つ（DNSまたはその他の手段で既知の場合）またはRのRVSのいずれかに送信する必要があります。ここでは、RのDNSレコードからRのRVSのIPアドレスを取得し、HIPベースエクスチェンジのI1パケットをRVSに送信します。 RVSは、到着したI1パケットに含まれているHITがそれ自体のものではないことに注意して、現在の登録をチェックして、パケットをリレーする必要があるかどうかを判断する必要があります。ここでは、HITがRに属していると判断し、I1パケットを登録されたIPアドレスに中継します。次に、Rは、I1パケットから取得したR1を直接IのIPアドレスに送信することにより、RVSからの支援なしに基本交換を完了します。この仕様では、RVSのクライアントは常にレスポンダです。ただし、クライアントが独自のRVSを介してベース交換を開始できるようにする理由（NATやファイアウォールトラバーサルなど）がある場合があります。この仕様は、他のドキュメントで指定する必要があるそのようなシナリオには対応していません。
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はそれぞれ、パケット内のイニシエーターおよびレスポンダーのHITです。
REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_REQ REG_REQUESTパラメータがHIPヘッダーにあります。
REG_RES A REG_RESPONSE parameter is present in the HIP header.
REG_RES REG_RESPONSEパラメータがHIPヘッダーにあります。
FROM:I A FROM parameter containing the IP address I is present in the HIP header.
FROM：I IPアドレスを含むFROMパラメータは、HIPヘッダーに存在します。
RVS_HMAC An RVS_HMAC parameter containing an Hashed Message Authentication Code (HMAC) keyed with the appropriate registration key is present in the HIP header.
RVS_HMAC適切な登録キーでキー付けされたハッシュメッセージ認証コード（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：RVSランデブーサーバーのIPアドレスRVSを含むVIA_RVSパラメータがHIPヘッダーにあります。
Before an RVS starts to relay HIP packets to a rendezvous client, the rendezvous client needs to register with the RVS to receive rendezvous service by using the HIP Registration Extension [RFC8003] as illustrated in the following schema:
RVSがランデブークライアントへのHIPパケットのリレーを開始する前に、次のスキーマに示すように、ランデブークライアントはRVSに登録してHIP登録拡張[RFC8003]を使用してランデブーサービスを受信する必要があります。
+-----+ +-----+
| | 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 RVSs have a rendezvous registration, the RVSs 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ノードとそのRVSの1つにランデブー登録がある場合、RVSはIPヘッダーを書き換えることにより、（クライアントのHITの1つを含む）着信I1パケットを中継します。これらは、I1パケットの宛先IPアドレスを、HITの所有者、つまりランデブークライアントのIPアドレスの1つに置き換えます。また、それに応じてIPチェックサムを再計算する必要があります。
Because of ingress filtering on the path from the RVS to the client [RFC2827] [RFC3013], a HIP RVS 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] [RFC6724]. 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 [RFC8003].
RVSからクライアント[RFC2827] [RFC3013]へのパスでの入力フィルタリングのため、HIP RVSは、送信元IPアドレス、つまりIのIPアドレスを独自のIPアドレスの1つに置き換える必要があります（SHOULD）。置換IPアドレスは、関連するIPv4およびIPv6仕様[RFC1122] [RFC6724]に従って選択する必要があります（SHOULD）。この置換はイニシエーターのIPアドレスを隠すため、RVSはパケットの元のソースIPアドレスを含むFROMパラメーターを追加する必要があります。このFROMパラメータは、対応するランデブー登録整合性キー[RFC8003]でキー付けされた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 an RVS can be problematic because HIP 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 RVSs.
HIPは整合性チェックを使用するため、RVSでのHIPパケットのこの変更は問題になる可能性があります。 I1にはHMACまたはSIGNATUREパラメータが含まれていないため、これら2つのエンドツーエンドの整合性チェックは、RVSの操作による影響を受けません。
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パケットのチェックサムフィールドを検証する必要があります（SHOULD）。変更後、更新されたHIPヘッダーを使用してチェックサムフィールドを再計算する必要があります。これには、新しいFROMおよびRVS_HMACパラメーターと、更新された送信元および宛先IPアドレスを含む疑似ヘッダーが含まれる可能性があります。これにより、レスポンダは、FROMパラメータを解析せずに、I1パケットのチェックサムを「そのまま」検証できます。
This section describes extensions to the HIP Registration Extension [RFC8003], allowing a HIP node to register with an RVS for rendezvous service and to notify the RVS aware of changes to its current location. It also describes an extension to the HIP specification [RFC7401] itself, allowing establishment of HIP associations via one or more HIP RVSs.
このセクションでは、HIP登録拡張[RFC8003]の拡張について説明します。これにより、HIPノードはRVSにランデブーサービスを登録し、現在の場所の変更をRVSに通知できます。また、HIP仕様[RFC7401]自体への拡張についても説明し、1つ以上のHIP RVSを介してHIPアソシエーションを確立できるようにします。
This specification defines an additional registration for the HIP Registration Extension [RFC8003] that allows registering with an RVS for rendezvous service.
この仕様は、ランデブーサービス用のRVSへの登録を可能にするHIP Registration Extension [RFC8003]の追加登録を定義しています。
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 [RFC7401] is its "type" code. This change causes it to be located after the FROM parameter (as opposed to the HMAC):
RVS_HMACは重要ではないパラメーターであり、HIP仕様[RFC7401]で定義されているHMACパラメーターとの唯一の違いは、その「タイプ」コードです。この変更により、（HMACではなく）FROMパラメータの後に配置されます。
Type 65500 Length Variable. Length in octets, excluding Type, Length, and Padding.
タイプ65500長さ変数。タイプ、長さ、パディングを除くオクテット単位の長さ。
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.
HMACパケットを介して計算されたHMACHMAC。RVS_HMACパラメーターと後続のパラメーターは除きます。 HMACは、ランデブー登録が行われたときに確立された適切なHIP整合性キー（HIP-lgまたはHIP-gl）で鍵が設定されています。 HIPの「チェックサム」フィールドはゼロに設定する必要があり、HMACの計算時に除外パラメーターをカバーしないように、HIP共通ヘッダーのHIPヘッダー長を計算する必要があります。 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パラメータでパケットを保護する必要があります（SHOULD）。有効なRVS_HMACは、クライアントとサーバーの間を流れるすべてのパケットに存在する必要があり（SHOULD）、FROMパラメータが処理されるときに存在する必要があります。
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アドレス。
An RVS 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アドレスが書き換えられるときは常に、RVSはHIPパケットの元のソースIPアドレスを含むFROMパラメータを追加する必要があります。 1つ以上のFROMパラメータがすでに存在する場合は、既存のパラメータの後に新しいFROMパラメータを追加する必要があります。
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がFROMパラメータを挿入するときは常に、パケットの整合性、特にFROMパラメータに含まれる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 MUST append a newly created VIA_RVS parameter at the end of the R1 packet that contains the IP address of the RVS that relayed the I1 packet. Including more than one IP address in the VIA_RVS parameter is outside the scope of this specification. 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パケットの送信を開始できます。デバッグ目的で、I1パケットをリレーしたRVSのIPアドレスを含むR1パケットの最後に、新しく作成されたVIA_RVSパラメータを追加する必要があります。 VIA_RVSパラメータに複数のIPアドレスを含めることは、この仕様の範囲外です。 VIA_RVSパラメーターを使用する主な目的は、オペレーターがRVSを介してHIPアソシエーションを確立しているときに発生する可能性のある問題を診断できるようにすることです。
The following subsections describe the differences of the processing of I1 and R1 while an RVS is involved in the base exchange.
以下のサブセクションでは、RVSが基本交換に関与しているときの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 RVS itself and does not know its HIT.
イニシエーターは、RVS自体との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アドレスを書き換えるとき、イニシエーターのソースIPアドレスを含むFROMパラメーターをI1に追加する必要があります。このFROMパラメータは、ランデブー登録時に確立された整合性キーでキー付けされたRVS_HMACによって保護されている必要があります。
When an RVS 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.
RVSは、宛先HITが自分のものではないI1を受信すると、その登録データベースを調べて、HIT所有者によって確立されたランデブーサービスの登録を見つけます。適切な登録が見つかると、パケットを登録されたIPアドレスに中継します。適切な登録が見つからない場合は、パケットをドロップします。
An RVS 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.
RVSは、着信する日和見的I1（つまり、宛先HITがNULLのI1）をそれ自体にアドレス指定されたI1として解釈する必要があり（SHOULD）、クライアントの1つにリレーしようとすべきではありません（SHOULD NOT）。
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を検証できない場合、パケットをドロップする必要があります（SHOULD）。 RVS_HMACを検証できず、FROMパラメータが存在する場合は、パケットをドロップする必要があります。
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パラメーターを含む日和見I1をドロップする必要があります（SHOULD）。
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に応答する場合、通過したRVSのIPアドレスを含むVIA_RVSパラメータを通常のR1ヘッダーに追加する必要があります。
The HIP specification [RFC7401] 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仕様[RFC7401]は、R1を受信するシステムがまず、R1の発信者にI1を送信したかどうかを確認する必要があることを義務付けています（つまり、システムは状態I1-SENTにあります）。 R1がリレーされたI1に応答する場合、このチェックはHITのみに基づいている必要があります（SHOULD）。 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 HIP.
このセクションでは、これらのHIP拡張機能によってもたらされる既知の脅威と、HIPの全体的なセキュリティへの影響について説明します。特に、このドキュメントで説明されている拡張機能は、HIPに新たな脅威をもたらすものではないと主張しています。
It is difficult to encompass the whole scope of threats introduced by RVSs 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.
RVSによってもたらされる脅威の全体を網羅することは困難です。RVSの存在は、IP層とHIP層の両方に影響を与えるためです。特に、これらの拡張機能により、IP層でのリダイレクト、増幅、および反射攻撃だけでなく、HIP層自体への攻撃（HIPベース交換に対する中間者攻撃など）が可能になる場合があります。
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を事前に知っている場合は、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.
イニシエーターがレスポンダーのホストID（いわゆる「日和見イニシエーター」）を事前に認識していない場合、交換された公開鍵を認証できないため、これらの攻撃に対してHIP交換を防御することはほとんど不可能です。唯一のアプローチは、日和見I1に応答するR1に、最初にI1を送信したのと同じIPアドレスから来るよう要求することにより、HIP状態でのハイジャックの脅威を軽減することです。この手順は、今日のインターネットに存在するものと同等のセキュリティレベルを保持します。
However, for reasons of simplicity, this specification does not allow the establishment of a HIP association via an RVS in an opportunistic manner.
ただし、簡単にするために、この仕様では、RVSを介した便宜的な方法でのHIPアソシエーションの確立を許可していません。
[RFC5204], obsoleted by this document, made the following definitions and reservations in the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters":
[RFC5204]は、このドキュメントで廃止され、「ホストIDプロトコル（HIP）パラメータ」の「パラメータタイプ」サブレジストリで次の定義と予約を行いました。
Value Parameter Type Length
----- -------------- --------
65498 FROM 16
65500 RVS_HMAC variable
65502 VIA_RVS variable
In the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to [RFC5204] have been replaced by references to this document.
「Host Identity Protocol（HIP）Parameters」の「Parameter Types」サブレジストリで、[RFC5204]への参照はこのドキュメントへの参照に置き換えられました。
[RFC5204], obsoleted by this document, made the following definition and reservation in the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters":
[RFC5204]は、このドキュメントで廃止され、「ホストIDプロトコル（HIP）パラメータ」の「登録タイプ」サブレジストリで次の定義と予約を行いました。
Value Registration Type
----- -----------------
1 RENDEZVOUS
In the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters", references to [RFC5204] have been replaced by references to this document.
「Host Identity Protocol（HIP）Parameters」の「Registration Types」サブレジストリで、[RFC5204]への参照は、このドキュメントへの参照に置き換えられました。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<http ：//www.rfc-editor.org/info/rfc7401>。
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8003] Laganier、J。およびL. Eggert、「Host Identity Protocol（HIP）Registration Extension」、RFC 8003、DOI 10.17487 / RFC8003、2016年10月、<http://www.rfc-editor.org/info/rfc8003 >。
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, <http://www.rfc-editor.org/info/rfc8005>.
[RFC8005] Laganier、J。、「Host Identity Protocol（HIP）Domain Name System（DNS）Extension」、RFC 8005、DOI 10.17487 / RFC8005、2016年10月、<http://www.rfc-editor.org/info/ rfc8005>。
[HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423- bis-14, June 2016.
[HIP-ARCH] Moskowitz、R。およびM. Komu、「Host Identity Protocol Architecture」、Work in Progress、draft-ietf-hip-rfc4423- bis-14、2016年6月。
[HIP-HOST-MOB] Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", Work in Progress, draft-ietf-hip-rfc5206-bis-14, October 2016.
[HIP-HOST-MOB] Henderson、T.、Vogt、C.、J。Arkko、「Host Identity Protocol with Host Identity Protocol」、Work in Progress、draft-ietf-hip-rfc5206-bis-14、2016年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, DOI 10.17487/RFC3013, November 2000, <http://www.rfc-editor.org/info/rfc3013>.
[RFC3013] Killalea、T。、「Recommended Internet Service Provider Security Services and Procedures」、BCP 46、RFC 3013、DOI 10.17487 / RFC3013、2000年11月、<http://www.rfc-editor.org/info/rfc3013> 。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204, April 2008, <http://www.rfc-editor.org/info/rfc5204>.
[RFC5204] Laganier、J。およびL. Eggert、「Host Identity Protocol（HIP）Rendezvous Extension」、RFC 5204、DOI 10.17487 / RFC5204、2008年4月、<http://www.rfc-editor.org/info/rfc5204 >。
o Updated HIP references to revised HIP specifications.
o 修正されたHIP仕様へのHIPリファレンスを更新しました。
Acknowledgments
謝辞
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, Juergen Quittek, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, and Martin Stiemerling.
次の人々は、このドキュメントを改善するために、思慮深く有益なディスカッションや提案を提供しています。マーティン・スティーマーリング。
Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866. This document reflects only the authors' views, and the European Commission is not responsible for any use that may be made of the information it contains.
Lars Eggertは、EUのHorizon 2020研究およびイノベーションプログラム2014-2018から助成金契約番号644866の下で資金を受け取りました。このドキュメントは著者の見解のみを反映しており、欧州委員会は、含まれる情報。
Thanks to Joel M. Halpern for performing the Gen-ART review of this document as part of the publication process.
出版プロセスの一環としてこのドキュメントのGen-ARTレビューを行ってくれたJoel M. Halpernに感謝します。
Authors' Addresses
著者のアドレス
Julien Laganier Luminate Wireless, Inc. Cupertino, CA United States of America
ジュリアンラガニアLuminate Wireless、Inc.クパチーノ、カリフォルニア州アメリカ合衆国
Email: julien.ietf@gmail.com
Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany
Lars Eggert NetApp Sonnenallee 1キルヒハイム85551ドイツ
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org