[要約] RFC 5206は、ホスト識別プロトコル（HIP）を使用したエンドホストの移動とマルチホーミングに関する仕様です。このRFCの目的は、ネットワークの移動性と冗長性を向上させるために、ホストの識別情報を使用する方法を提供することです。
Network Working Group P. Nikander
Request for Comments: 5206 Ericsson Research NomadicLab
Category: Experimental T. Henderson, Ed.
The Boeing Company
C. Vogt
J. Arkko
Ericsson Research NomadicLab
April 2008
End-Host Mobility and Multihoming with the Host Identity Protocol
ホストIDプロトコルを使用したエンドホストモビリティとマルチホーム
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 mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.
このドキュメントでは、ホストIDプロトコル（HIP）へのモビリティとマルチホーム拡張機能を定義しています。具体的には、このドキュメントでは、股関節ホストが到達する可能性のある代替アドレスについてピアに通知できる股関節メッセージの一般的な「ロケーター」パラメーターを定義します。このドキュメントでは、ヒップホストの移動性の手順の要素も定義します。これは、ホストがパケットを受信するために使用する主要なロケーターを動的に変更するプロセスです。同じロケーターパラメーターを使用して、エンドホストのマルチホミングをサポートすることもできますが、詳細な手順はさらなる研究のために残されています。
Table of Contents
目次
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8
3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 8
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 11
3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 13
3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14
3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 14
3.2.7. Using LOCATORs across Addressing Realms . . . . . . . 14
3.2.8. Network Renumbering . . . . . . . . . . . . . . . . . 15
3.2.9. Initiating the Protocol in R1 or I2 . . . . . . . . . 15
3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 16
3.3.1. Address Verification . . . . . . . . . . . . . . . . . 16
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 17
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 18
3.3.4. Interaction with Security Associations . . . . . . . . 18
4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 21
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 23
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 23
4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 24
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Locator Data Structure and Status . . . . . . . . . . . . 24
5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 25
5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 28
5.4. Verifying Address Reachability . . . . . . . . . . . . . . 30
5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 31
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 32
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 35
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 36
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 36
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 36
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative references . . . . . . . . . . . . . . . . . . . 38
9.2. Informative references . . . . . . . . . . . . . . . . . . 38
The Host Identity Protocol [RFC4423] (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange [RFC5201].
ホストIDプロトコル[RFC4423]（HIP）は、IPアドレスの代わりにパブリック/秘密キーペアを使用して、インターネットワーキングレイヤー（IPv4およびIPv6）から輸送層（TCP、UDPなど）を切り離すアーキテクチャをサポートします。アイデンティティ。ホストが股関節を使用する場合、上にあるプロトコルサブレイヤー（たとえば、輸送層ソケットやカプセル化セキュリティペイロード（ESP）セキュリティ協会（SAS））は、これらのホストIDの表現に結合され、IPアドレスはパケット転送にのみ使用されます。ただし、各ホストは、ピアが到達可能な少なくとも1つのIPアドレスを知っている必要があります。当初、これらのIPアドレスは、股関節ベース交換中に使用されるIPアドレスです[RFC5201]。
One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level mobility and simple multihoming, leaving more complicated scenarios and other variations for further study. More specifically:
このようなデカップリングの結果の1つは、ネットワーク層のモビリティとホストマルチホームの新しいソリューションが可能であることです。可能な限り多くのバリエーションとマルチホームがあります。このドキュメントの範囲には、基本的なネットワークレベルのモビリティとシンプルなマルチホミングのメッセージングと手順の要素が含まれており、さらなる研究のために、より複雑なシナリオやその他のバリエーションが残ります。すなわち：
This document defines a generalized LOCATOR parameter for use in HIP messages. The LOCATOR parameter allows a HIP host to notify a peer about alternate addresses at which it is reachable. The LOCATORs may be merely IP addresses, or they may have additional multiplexing and demultiplexing context to aid the packet handling in the lower layers. For instance, an IP address may need to be paired with an ESP Security Parameter Index (SPI) so that packets are sent on the correct SA for a given address.
このドキュメントでは、股関節メッセージで使用するための一般化されたロケーターパラメーターを定義します。ロケーターパラメーターを使用すると、股関節ホストが到達可能な代替アドレスについてピアに通知することができます。ロケーターは単なるIPアドレスである場合があります。または、下位層でのパケット処理を支援するために、追加の多重化と非複数のコンテキストがある場合があります。たとえば、IPアドレスをESPセキュリティパラメーターインデックス（SPI）と組み合わせる必要があるため、特定のアドレスに対してパケットが正しいSAに送信されるようにする必要があります。
This document also specifies the messaging and elements of procedure for end-host mobility of a HIP host -- the sequential change in the preferred IP address used to reach a host. In particular, message flows to enable successful host mobility, including address verification methods, are defined herein.
このドキュメントは、股関節ホストのエンドホストモビリティのメッセージングと手順の要素も指定します。特に、アドレス検証方法を含む成功したホストモビリティを有効にするメッセージの流れは、本明細書で定義されています。
However, while the same LOCATOR parameter is intended to support host multihoming (parallel support of a number of addresses), and experimentation is encouraged, detailed elements of procedure for host multihoming are left for further study.
ただし、同じロケーターパラメーターはホストのマルチホミング（多くのアドレスの並行サポート）をサポートすることを目的としており、実験が推奨されますが、ホストマルチホミングの手順の詳細な要素はさらなる研究のために残されています。
While HIP can potentially be used with transports other than the ESP transport format [RFC5202], this document largely assumes the use of ESP and leaves other transport formats for further study.
HIPはESP輸送形式[RFC5202]以外の輸送で使用できますが、この文書はESPの使用を主に想定しており、さらなる研究のために他の輸送形式を残します。
There are a number of situations where the simple end-to-end readdressing functionality is not sufficient. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the network, such as a HIP rendezvous server [RFC5204]. Such functionality is out of the scope of this document. We also do not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document.
単純なエンドツーエンドの再送信機能で十分ではない状況がいくつかあります。これらには、モバイルホストの初期到達可能性、ロケーションプライバシー、両方のホストの同時モビリティ、およびNATトラバーサルのいくつかのモードが含まれます。これらの状況では、股関節ランデブーサーバー[RFC5204]など、ネットワーク内のヘルパー機能が必要です。このような機能は、このドキュメントの範囲外です。また、ローカライズされたモビリティ管理拡張機能（つまり、特派員ノードを直接通知することを伴わないモビリティ管理手法）も考慮しません。このドキュメントは、エンドツーエンドのモビリティに関係しています。最後に、輸送層に対して基礎となるIPモビリティを透明にすることは、輸送渋滞制御、パスMTU選択、およびサービス品質（QOS）の適切な応答に影響を与えます。輸送層のモビリティトリガー、および股関節の移動性またはマルチホミングアドレスの変更に対する適切な輸送応答は、このドキュメントの範囲外です。
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]で説明されているように解釈されます。
LOCATOR. The name of a HIP parameter containing zero or more Locator fields. This parameter's name is distinguished from the Locator fields embedded within it by the use of all capital letters.
ロケータ。ゼロ以上のロケーターフィールドを含む股関節パラメーターの名前。このパラメーターの名前は、すべての大文字を使用することにより、その中に埋め込まれたロケーターフィールドと区別されます。
Locator. A name that controls how the packet is routed through the network and demultiplexed by the end host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address.
ロケータ。パケットがネットワークを介してどのようにルーティングされ、エンドホストによって逆流したかを制御する名前。IPv6アドレスなどの従来のネットワークアドレスとESP SPIなどのエンドツーエンドの識別子の連結が含まれる場合があります。また、トランスポートポート番号またはIPv6フローラベルが非gultiplexingコンテキストとして含まれる場合もあれば、単にネットワークアドレスである場合もあります。
Address. A name that denotes a point-of-attachment to the network. The two most common examples are an IPv4 address and an IPv6 address. The set of possible addresses is a subset of the set of possible locators.
住所。ネットワークへのパイントメントを示す名前。最も一般的な2つの例は、IPv4アドレスとIPv6アドレスです。可能なアドレスのセットは、可能なロケーターのセットのサブセットです。
Preferred locator. A locator on which a host prefers to receive data. With respect to a given peer, a host always has one active Preferred locator, unless there are no active locators. By default, the locators used in the HIP base exchange are the Preferred locators.
優先ロケーター。ホストがデータを受信することを好むロケーター。特定のピアに関しては、アクティブなロケーターがいない限り、ホストには常に1つのアクティブな優先ロケーターがあります。デフォルトでは、股関節ベース交換で使用されるロケーターが優先ロケーターです。
Credit Based Authorization. A host must verify a mobile or multihomed peer's reachability at a new locator. Credit-Based Authorization authorizes the peer to receive a certain amount of data at the new locator before the result of such verification is known.
クレジットベースの承認。ホストは、新しいロケーターでモバイルまたはマルチホームのピアの到達可能性を確認する必要があります。クレジットベースの承認は、そのような検証の結果が知られている前に、ピアが新しいロケーターで一定のデータを受け取ることを許可します。
This section is an overview; more detailed specification follows this section.
このセクションは概要です。より詳細な仕様については、このセクションに従います。
The Host Identity Protocol (HIP) [RFC5201] is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities, and establishing security associations (SAs) for the ESP transport format [RFC5202] and possibly other protocols in the future.
ホストIDプロトコル（HIP）[RFC5201]は、重要な確立およびパラメーターネゴシエーションプロトコルです。その主なアプリケーションは、ホストのアイデンティティに基づいてホストメッセージを認証し、ESP輸送形式[RFC5202]および将来の他のプロトコルのセキュリティ協会（SAS）を確立することです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1：股関節展開モデル
The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies extensions to the HIP protocol to enable end-host mobility and basic multihoming. In summary, these extensions to the HIP base protocol enable the signaling of new addressing information to the peer in HIP messages. The messages are authenticated via a signature or keyed hash message authentication code (HMAC) based on its Host Identity. This document specifies the format of this new addressing (LOCATOR) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism.
股関節の一般的な展開モデルは、エンドツーエンドの方法で動作を想定して、上に示されています。このドキュメントは、股関節プロトコルへの拡張機能を指定して、エンドホストモビリティと基本的なマルチホームを可能にします。要約すると、これらの股関節ベースプロトコルへの拡張は、股関節のピアへの新しいアドレス指定情報のシグナル伝達を可能にします。メッセージは、ホストIDに基づいて署名またはキー付きハッシュメッセージ認証コード（HMAC）を介して認証されます。このドキュメントは、この新しいアドレス指定（ロケーター）パラメーターの形式、このパラメーターを送信および処理して基本的なホストモビリティを有効にする手順、および同時アドレス検証メカニズムの手順を指定します。
---------
| TCP | (sockets bound to HITs)
---------
|
---------
----> | ESP | {HIT_s, HIT_d} <-> SPI
| ---------
| |
---- ---------
| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
---- ---------
|
---------
| IP |
---------
Figure 2: Architecture for HIP Mobility and Multihoming (MH)
図2：股関節の機動性とマルチホミングのアーキテクチャ（MH）
Figure 2 depicts a layered architectural view of a HIP-enabled stack using the ESP transport format. In HIP, upper-layer protocols (including TCP and ESP in this figure) are bound to Host Identity Tags (HITs) and not IP addresses. The HIP sublayer is responsible for maintaining the binding between HITs and IP addresses. The SPI is used to associate an incoming packet with the right HITs. The block labeled "MH" is introduced below.
図2は、ESP輸送形式を使用して、股関節対応スタックの階層化されたアーキテクチャビューを示しています。股関節では、上層層プロトコル（この図のTCPおよびESPを含む）は、IPアドレスではなくIDタグ（ヒット）をホストすることになります。股関節崇高は、ヒットとIPアドレスの間のバインディングを維持する責任があります。SPIは、着信パケットを適切なヒットに関連付けるために使用されます。「MH」というラベルの付いたブロックを以下に紹介します。
Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC5201]. The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but do not change the IP addresses.
基本プロトコル仕様[RFC5201]で指定されているように、最初に移動性またはマルチホームがない場合を考えてみましょう。HIPベース交換は、ホスト、ESPに使用するスピス、およびIPアドレス（HIPシグナリングパケットとESPデータパケットの両方で使用）間で使用されているヒットを確立します。特定のパケットのアウトバウンド方向にそのようなバインディングのセットは1つだけであり、股関節層でのバインディングに使用される唯一のフィールドはESP（SPIとヒット）によって露出したフィールドであることに注意してください。インバウンド方向の場合、SPIは正しいホストコンテキストを見つけるために必要なすべてです。特にイベントの再キーイングイベントは、ヒットペアとSPI間のマッピングを変更しますが、IPアドレスを変更しないでください。
Consider next a mobility event, in which a host is still single-homed but moves to another IP address. Two things must occur in this case. First, the peer must be notified of the address change using a HIP UPDATE message. Second, each host must change its local bindings at the HIP sublayer (new IP addresses). It may be that both the SPIs and IP addresses are changed simultaneously in a single UPDATE; the protocol described herein supports this. However, simultaneous movement of both hosts, notification of transport layer protocols of the path change, and procedures for possibly traversing middleboxes are not covered by this document.
次に、ホストがまだ独身であるが、別のIPアドレスに移動するモビリティイベントを考えてみましょう。この場合、2つのことが発生する必要があります。最初に、ピアには、ヒップ更新メッセージを使用してアドレス変更を通知する必要があります。第二に、各ホストは、股関節溝（新しいIPアドレス）でローカルバインディングを変更する必要があります。SPISアドレスとIPアドレスの両方が、単一の更新で同時に変更される可能性があります。ここで説明するプロトコルはこれをサポートしています。ただし、両方のホストの同時移動、パス変更の輸送層プロトコルの通知、およびおそらく移動するミドルボックスの手順は、このドキュメントではカバーされていません。
Finally, consider the case when a host is multihomed (has more than one globally routable address) and has multiple addresses available at the HIP layer as alternative locators for fault tolerance. Examples include the use of (possibly multiple) IPv4 and IPv6 addresses on the same interface, or the use of multiple interfaces attached to different service providers. Such host multihoming generally necessitates that a separate ESP SA is maintained for each interface in order to prevent packets that arrive over different paths from falling outside of the ESP anti-replay window [RFC4303]. Multihoming thus makes it possible that the bindings shown on the right side of Figure 2 are one to many (in the outbound direction, one HIT pair to multiple SPIs, and possibly then to multiple IP addresses). However, only one SPI and address pair can be used for any given packet, so the job of the "MH" block depicted above is to dynamically manipulate these bindings. Beyond locally managing such multiple bindings, the peer-to-peer HIP signaling protocol needs to be flexible enough to define the desired mappings between HITs, SPIs, and addresses, and needs to ensure that UPDATE messages are sent along the right network paths so that any HIP-aware middleboxes can observe the SPIs. This document does not specify the "MH" block, nor does it specify detailed elements of procedure for how to handle various multihoming (perhaps combined with mobility) scenarios. The "MH" block may apply to more general problems outside of HIP. However, this document does describe a basic multihoming case (one host adds one address to its initial address and notifies the peer) and leave more complicated scenarios for experimentation and future documents.
最後に、ホストがマルチホーム（グローバルにルーティング可能なアドレスを複数持っています）があり、障害耐性のための代替ロケーターとして股関節層で複数のアドレスを利用できる場合を検討してください。例には、同じインターフェイスで（おそらく複数の）IPv4およびIPv6アドレスの使用、または異なるサービスプロバイダーに接続された複数のインターフェイスの使用が含まれます。このようなホストのマルチホームは、一般に、異なるパスに到達するパケットがESPアンチレプレイウィンドウの外側に到達するのを防ぐために、各インターフェイスに対して個別のESP SAが維持されることを必要とします[RFC4303]。したがって、Multihomingは、図2の右側に示されているバインディングが多くのものであることを可能にします（アウトバウンド方向では、1つのヒットペアが複数のスピスに、そしておそらく複数のIPアドレスに）。ただし、特定のパケットに使用できるSPIとアドレスペアは1つだけであるため、上記の「MH」ブロックのジョブは、これらのバインディングを動的に操作することです。このような複数のバインディングをローカルに管理するだけでなく、ピアツーピアの股関節シグナル伝達プロトコルは、ヒット、スピス、アドレスの間の望ましいマッピングを定義するのに十分な柔軟性が必要であり、適切なネットワークパスに沿って更新メッセージが送信されるようにする必要があります。股関節を認識しているミドルボックスは、スピスを観察できます。このドキュメントでは、「MH」ブロックを指定しておらず、さまざまなマルチホミング（おそらくモビリティと組み合わせた）シナリオを処理する方法の手順の詳細な要素も指定していません。「MH」ブロックは、股関節以外のより一般的な問題に適用される場合があります。ただし、このドキュメントでは、基本的なマルチホームケースについて説明します（1人のホストは、最初のアドレスに1つのアドレスを追加し、ピアに通知します）、実験と将来のドキュメントのためにより複雑なシナリオを残します。
This document defines a generalization of an address called a "locator". A locator specifies a point-of-attachment to the network but may also include additional end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be sufficient to describe how packets should be handled below HIP. For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs to avoid violating the ESP anti-replay window. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4.
このドキュメントは、「ロケーター」と呼ばれるアドレスの一般化を定義します。ロケーターは、ネットワークへのアタッチメントを指定しますが、パケットがスタックの論理股関節サブレイヤーの下で処理される方法に影響を与える追加のエンドツーエンドトンネリングまたはホストあたりの反転抑制コンテキストを含めることもできます。IPアドレスだけでは、パケットを股関節の下で処理する方法を説明するのに十分ではない場合があるため、この一般化は有用です。たとえば、ホストのマルチホームコンテキストでは、ESPアンチレプレイウィンドウに違反しないように、特定のIPアドレスを特定のESP SPIに関連付ける必要がある場合があります。アドレスは、特定のトンネリングシナリオの輸送ポートと提携することもできます。ロケーターは、単に従来のネットワークアドレスである可能性があります。ロケーターパラメーターのロケーターフィールドの形式は、セクション4で定義されています。
When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a LOCATOR parameter. This UPDATE packet is acknowledged by the peer. For reliability in the presence of packet loss, the UPDATE packet is retransmitted as defined in the HIP protocol specification [RFC5201]. The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet.
ホストが別のアドレスに移動すると、ロケーターパラメーターを含むヒップ更新パケットを送信することにより、新しいアドレスのピアに通知します。この更新パケットは、ピアによって認められています。パケット損失の存在下での信頼性のために、更新パケットは、股関節プロトコル仕様[RFC5201]で定義されているように再送信されます。ピアは、パケットの署名とキー付きハッシュに基づいて、更新パケットのコンテンツを認証できます。
When using ESP Transport Format [RFC5202], the host may at the same time decide to rekey its security association and possibly generate a new Diffie-Hellman key; all of these actions are triggered by including additional parameters in the UPDATE packet, as defined in the base protocol specification [RFC5201] and ESP extension [RFC5202].
ESP輸送形式[RFC5202]を使用する場合、ホストは同時にセキュリティ協会の再キーを再キーすることを決定し、新しいDiffie-Hellmanキーを生成する可能性があります。これらのアクションはすべて、ベースプロトコル仕様[RFC5201]およびESP拡張[RFC5202]で定義されているように、更新パケットに追加のパラメーターを含めることによってトリガーされます。
When using ESP (and possibly other transport modes in the future), the host is able to receive packets that are protected using a HIP created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers without necessarily rekeying. However, the peers are not able to send packets to these new addresses before they can reliably and securely update the set of addresses that they associate with the sending host. Furthermore, mobility may change the path characteristics in such a manner that reordering occurs and packets fall outside the ESP anti-replay window for the SA, thereby requiring rekeying.
ESP（および将来的には他のトランスポートモード）を使用する場合、ホストは、任意のアドレスから作成されたESP SAを使用して保護されたパケットを受信できます。したがって、ホストはIPアドレスを変更し、必ずしも再キーをかけずにピアにパケットを送信し続けることができます。ただし、ピアは、送信ホストに関連付けられているアドレスのセットを確実かつ安全に更新できる前に、これらの新しいアドレスにパケットを送信することができません。さらに、モビリティは、並べ替えが発生し、パケットがSAのESPアンチレプレイウィンドウの外側にあるため、再発作が必要になるような方法でパス特性を変える可能性があります。
A related operational configuration is host multihoming, in which a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR parameter defined herein, a host can inform its peers of additional (multiple) locators at which it can be reached, and can declare a particular locator as a "preferred" locator. Although this document defines a basic mechanism for multihoming, it does not define detailed policies and procedures, such as which locators to choose when more than one pair is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming on transport protocols and ESP anti-replay windows. Additional definitions of HIP-based multihoming are expected to be part of future documents.
関連する運用構成は、モビリティの場合のように、ホストが順次ではなく複数のロケーターを同時に持っているホストマルチホミングです。本明細書で定義されているロケーターパラメーターを使用することにより、ホストは、到達できる追加の（複数の）ロケーターを仲間に通知し、特定のロケーターを「優先」ロケーターとして宣言できます。このドキュメントはマルチホームの基本的なメカニズムを定義していますが、複数のペアが利用可能な場合に選択するロケーター、同時モビリティとマルチホームの操作、ソースアドレス選択ポリシー（で指定されているものを超えて、どのロケーターが選択するかなどの詳細なポリシーと手順を定義するものではありません。[RFC3484]）、および輸送プロトコルとESPアンチレプレイウィンドウに対するマルチホミングの意味。股関節ベースのマルチホミングの追加の定義は、将来の文書の一部になると予想されます。
In this section, we briefly introduce a number of usage scenarios for HIP mobility and multihoming. These scenarios assume that HIP is being used with the ESP transform [RFC5202], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC5201]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP the actual payload traffic is protected with ESP, and that the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Section 4 and Section 5.
このセクションでは、股関節のモビリティとマルチホミングに関する多くの使用シナリオを簡単に紹介します。これらのシナリオは、ESP変換[RFC5202]で股関節が使用されていることを想定していますが、他のシナリオは将来定義される可能性があります。これらの使用シナリオを理解するには、読者は少なくともHIPプロトコル仕様[RFC5201]に最小限に精通している必要があります。ただし、（比較的）初心者の読者にとっては、ヒップでは実際のペイロードトラフィックがESPで保護されており、ESP SPIが適切なホスト対宿主コンテキストのインデックスとして機能することを念頭に置いておくことが最も重要です。より多くの仕様の詳細は、セクション4およびセクション5の後半で見つかります。
The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts therefore have one incoming and one outgoing SA. Further, each SA uses the same pair of IP addresses, which are the ones used in the base exchange.
以下のシナリオでは、2人のホストが互いに単一の股関節ベース交換を完了したことを前提としています。したがって、両方のホストには、1つの入っているSAと1つの発信SAがあります。さらに、各SAは同じペアのIPアドレスを使用します。これは、ベース交換で使用されているIPアドレスです。
The readdressing protocol is an asymmetric protocol where a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets on which the LOCATOR parameters are expected to be carried are UPDATE packets. However, some implementations may want to experiment with sending LOCATOR parameters also on other packets, such as R1, I2, and NOTIFY.
再生プロトコルは、モバイルまたはマルチホームのホストが、影響を受けるSPIのIPアドレスの変更についてピアホストに通知する非対称プロトコルです。再生交換は、既存の股関節交換でピギーバックされるように設計されています。ロケーターパラメーターが運ばれると予想されるパケットの大部分は、更新パケットです。ただし、一部の実装では、R1、I2、通知など、他のパケットでもロケーターパラメーターを送信することを実験したい場合があります。
The scenarios below at times describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a host, newly-learned addresses of the peer must be verified before put into active service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described below (Section 5.6), an UNVERIFIED address may be used. The addressing states are defined more formally in Section 5.1.
以下のシナリオは、アドレスがアクティブ、検証、または非推奨状態のいずれかにあると説明することがあります。ホストの観点から見ると、ピアの新たに学習したアドレスをアクティブなサービスに入れる前に検証する必要があり、ピアによって削除されたアドレスは非推奨状態に入れられます。以下に説明する限られた条件（セクション5.6）では、未検証のアドレスを使用できます。アドレス指定状態は、セクション5.1でより正式に定義されています。
Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR parameter.
Link-Localアドレスを股関節の握手でソースアドレスとして使用するホストは、モバイルピアが到達できない場合があります。このようなホストは、最初の握手またはロケーターパラメーターを介して、グローバルにルーティング可能なアドレスを提供する必要があります。
A mobile host must sometimes change an IP address bound to an interface. The change of an IP address might be needed due to a change in the advertised IPv6 prefixes on the link, a reconnected PPP link, a new DHCP lease, or an actual movement to another subnet. In order to maintain its communication context, the host must inform its peers about the new IP address. This first example considers the case in which the mobile host has only one interface, IP address, a single pair of SAs (one inbound, one outbound), and no rekeying occurs on the SAs. We also assume that the new IP addresses are within the same address family (IPv4 or IPv6) as the first address. This is the simplest scenario, depicted in Figure 3.
モバイルホストは、インターフェイスにバインドされたIPアドレスを変更する必要があります。リンク上の広告されたIPv6プレフィックスの変更、再接続されたPPPリンク、新しいDHCPリース、または別のサブネットへの実際の動きにより、IPアドレスの変更が必要になる場合があります。通信コンテキストを維持するために、ホストは新しいIPアドレスについて同僚に通知する必要があります。この最初の例では、モバイルホストに1つのインターフェイス、IPアドレス、単一のSAS（1つのインバウンド、1つのアウトバウンド）のみがあり、SASで再キーイングが発生しない場合を検討します。また、新しいIPアドレスは、最初のアドレスと同じアドレスファミリ（IPv4またはIPv6）内にあると仮定します。これは、図3に示す最も単純なシナリオです。
Mobile Host Peer Host
モバイルホストピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ)
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 3: Readdress without Rekeying, but with Address Check
図3：再キーリングせずに再生されますが、アドレスチェック付き
The steps of the packet processing are as follows:
パケット処理の手順は次のとおりです。
1. The mobile host is disconnected from the peer host for a brief period of time while it switches from one IP address to another. Upon obtaining a new IP address, the mobile host sends a LOCATOR parameter to the peer host in an UPDATE message. The UPDATE message also contains an ESP_INFO parameter containing the values of the old and new SPIs for a security association. In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. The LOCATOR parameter contains the new IP address (Locator Type of "1", defined below) and a locator lifetime. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC5201].
1. モバイルホストは、1つのIPアドレスから別のIPアドレスに切り替える間、ピアホストから短時間切断されます。新しいIPアドレスを取得すると、モバイルホストは更新メッセージでロケーターパラメーターをピアホストに送信します。更新メッセージには、セキュリティ協会の古いSPIと新しいSPIの値を含むESP_INFOパラメーターも含まれています。この場合、古いSPIと新しいSPIパラメーターは両方とも既存の入っているSPIの値に設定されます。このESP_INFOは、再キーイングイベントをトリガーするものではありませんが、代わりにパス上の可能なパラメーター検査ミドルボックスに含まれています。ロケーターパラメーターには、新しいIPアドレス（以下に定義されている「1」のロケータータイプ）とロケーターの寿命が含まれています。モバイルホストは、ベース仕様[RFC5201]で指定されているように、この更新が確認されるのを待ち、必要に応じて再送信されます。
2. The peer host receives the UPDATE, validates it, and updates any local bindings between the HIP association and the mobile host's destination address. The peer host MUST perform an address verification by placing a nonce in the ECHO_REQUEST parameter of the UPDATE message sent back to the mobile host. It also includes an ESP_INFO parameter with the OLD SPI and NEW SPI parameters both set to the value of the preexisting incoming SPI, and sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address. The peer MAY use the new address immediately, but it MUST limit the amount of data it sends to the address until address verification completes.
2. ピアホストは、アップデートを受信し、検証し、HIP関連とモバイルホストの宛先アドレスの間のローカルバインディングを更新します。ピアホストは、モバイルホストに送信された更新メッセージのECHO_REQUESTパラメーターにNONCEを配置することにより、アドレス検証を実行する必要があります。また、古いSPIと新しいSPIパラメーターを備えたESP_INFOパラメーターも含まれており、どちらも既存の着信SPIの値に設定されており、新しいアドレスのモバイルホストにこのアップデート（PiggyBackedの承認を伴う）を送信します。ピアはすぐに新しいアドレスを使用できますが、アドレスの確認が完了するまで、アドレスに送信するデータの量を制限する必要があります。
3. The mobile host completes the readdress by processing the UPDATE ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer host receives this ECHO_RESPONSE, it considers the new address to be verified and can put the address into full use.
3. モバイルホストは、更新ACKを処理し、ECHO_RESPONSEで非CEをエコーすることにより、ReawDressを完了します。ピアホストがこのECHO_RESPONSEを受信すると、新しいアドレスを検証することを検討し、アドレスを完全に使用することができます。
While the peer host is verifying the new address, the new address is marked as UNVERIFIED in the interim, and the old address is DEPRECATED. Once the peer host has received a correct reply to its UPDATE challenge, it marks the new address as ACTIVE and removes the old address.
ピアホストは新しいアドレスを検証していますが、新しいアドレスは暫定的に未検証としてマークされ、古いアドレスは非推奨です。ピアホストが更新チャレンジに対する正しい返信を受け取ると、新しいアドレスをアクティブとしてマークし、古いアドレスを削除します。
The mobile host may decide to rekey the SAs at the same time that it notifies the peer of the new address. In this case, the above procedure described in Figure 3 is slightly modified. The UPDATE message sent from the mobile host includes an ESP_INFO with the OLD SPI set to the previous SPI, the NEW SPI set to the desired new SPI value for the incoming SA, and the KEYMAT Index desired. Optionally, the host may include a DIFFIE_HELLMAN parameter for a new Diffie-Hellman key. The peer completes the request for a rekey as is normally done for HIP rekeying, except that the new address is kept as UNVERIFIED until the UPDATE nonce challenge is received as described above. Figure 4 illustrates this scenario.
モバイルホストは、新しいアドレスのピアに通知されると同時にSASを再キーすることを決定する場合があります。この場合、図3で説明する上記の手順はわずかに変更されています。モバイルホストから送信された更新メッセージには、以前のSPIに設定された古いSPIを備えたESP_INFO、着信SAの目的の新しいSPI値に設定された新しいSPIセット、およびキーマットインデックスが必要です。オプションで、ホストには、新しいdiffie-hellmanキーのdiffie_hellmanパラメーターを含めることができます。ピアは、上記のように更新されたNonCeチャレンジが受信されるまで新しいアドレスが未確認のように保持されることを除いて、通常、股関節の再キーイングのために行われるRekeyのリクエストを完了します。図4は、このシナリオを示しています。
Mobile Host Peer Host
モバイルホストピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 4: Readdress with Mobile-Initiated Rekey
図4：モバイル開始の再キーを使用した再生
A (mobile or stationary) host may sometimes have more than one interface or global address. The host may notify the peer host of the additional interface or address by using the LOCATOR parameter. To avoid problems with the ESP anti-replay window, a host SHOULD use a different SA for each interface or address used to receive packets from the peer host when multiple locator pairs are being used simultaneously rather than sequentially.
（モバイルまたは固定）ホストには、複数のインターフェイスまたはグローバルアドレスがある場合があります。ホストは、ロケーターパラメーターを使用して、追加のインターフェイスまたはアドレスのピアホストに通知することができます。ESPアンチレプレイウィンドウの問題を回避するために、ホストは、複数のロケーターペアが順次ではなく同時に使用されている場合、ピアホストからパケットを受信するために使用される各インターフェイスまたはアドレスに対して異なるSAを使用する必要があります。
When more than one locator is provided to the peer host, the host SHOULD indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the addresses used in the base exchange are preferred until indicated otherwise.
ピアホストに複数のロケーターが提供される場合、ホストはどのロケーターが優先されるかを示す必要があります（ホストがトラフィックを受信することを好むロケーター）。デフォルトでは、基本交換で使用されるアドレスは、そうでないことが示されるまで推奨されます。
In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator, although rules for source address selection should ultimately govern the selection of the source locator based on the destination locator.
マルチホミングの場合、送信者は、トラフィックを調達するために複数の有効なロケーターを持っている場合があります。実際には、マルチホーム構成の股関節関連は、優先ピアロケーターと優先ローカルロケーターの両方を備えている可能性がありますが、ソースアドレスの選択のルールは、宛先ロケーターに基づくソースロケーターの選択を最終的に管理する必要があります。
Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is RECOMMENDED that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should be also rekeyed at that time. Although asymmetric SA configurations might be experimented with, their usage may constrain interoperability at this time. However, it is recommended that implementations attempt to support peers that prefer to use non-paired SAs. It is expected that this section and behavior will be modified in future revisions of this protocol, once the issue and its implications are better understood.
プロトコルは、ホスト間に非対称数のSAがある構成を可能にする場合があります（たとえば、1つのホストには2つのインターフェイスと2つのインバウンドSAがありますが、ピアには1つのインターフェイスと1つのインバウンドSAがあります）。アウトバウンドSAは、ホスト間でペアワイズを作成します。ESP_INFOが特定のアウトバウンドSAを再キーするために到着すると、その時点で対応するインバウンドSAも再び届く必要があります。非対称SA構成は実験される可能性がありますが、その使用は現時点で相互運用性を制約する可能性があります。ただし、実装は、ペアでないSASを使用することを好む仲間をサポートしようとすることをお勧めします。このセクションと動作は、問題とその意味がよりよく理解されると、このプロトコルの将来の改訂で変更されることが予想されます。
Consider the case between two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single-homed host about its other address. It is RECOMMENDED that the multihomed host set up a new SA pair for use on this new address. To do this, the multihomed host sends a LOCATOR with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero, and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR parameter also contains a second Type "1" locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for an ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address. Figure 5 illustrates this scenario.
2つのホスト、1つのシングルホームと1つのマルチホームの間のケースを考慮してください。マルチホームのホストは、シングルホームのホストに他の住所について通知することを決定する場合があります。Multihomedホストは、この新しいアドレスで使用するために新しいSAペアをセットアップすることをお勧めします。これを行うために、MultiHomedホストはESP_INFOを備えたロケーターを送信し、古いSPI値をゼロに設定し、新しく作成された受信SPIに新しいSPI値を設定することにより、新しいSAのリクエストを示します。「1」のロケータータイプが使用され、新しいアドレスを新しいSPIに関連付けます。ロケーターパラメーターには、元のアドレスとSPIの2番目のタイプ「1」ロケーターも含まれています。パラメーター処理を簡素化し、明示的なプロトコル拡張機能を回避してロケーターを削除するには、各ロケーターパラメーターが接続で使用されているすべてのロケーターをリストする必要があります（インバウンドロケーターとホストのSPIの完全なリスト）。マルチホームのホストは、ピアからESP_INFO（新しいアウトバウンドSA）と独自のアップデートのACKを待ちます。モビリティの場合と同様に、ピアホストは、新しいアドレスを積極的に使用する前にアドレス検証を実行する必要があります。図5は、このシナリオを示しています。
Multi-homed Host Peer Host
マルチホームのホストピアホスト
UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 5: Basic Multihoming Scenario
図5：基本的なマルチホームシナリオ
In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATORs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR as the local address to which the LOCATOR plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses.
マルチホームのシナリオでは、更新を受信するホストがアップデートを運ぶパケットで使用される宛先アドレスに正しく関連付けることが重要です。複数のアドレスを持つインターフェイスに新しいセキュリティ関連を確立するインバウンドロケーターを処理する場合、ホストは、ロケーターとESP_INFOがターゲットにされるローカルアドレスとしてロケーターを含む更新の宛先アドレスを使用します。これは、ホストが異なるピアアドレスに同じ（ロケーター）IPアドレスを持つ更新プログラムを送信する可能性があるためです。これは、異なるピアソースアドレスに暗黙的に提携した複数のインバウンドSAを作成する効果があるためです。
A host may have an interface that has multiple globally routable IP addresses. Such a situation may be a result of the site having multiple upper Internet Service Providers, or just because the site provides all hosts with both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available global routable addresses, independent of how they are provided.
ホストには、グローバルにルーティング可能な複数のIPアドレスを持つインターフェイスがある場合があります。このような状況は、サイトが複数のアッパーインターネットサービスプロバイダーを持っている結果である可能性があります。または、サイトがすべてのホストにIPv4とIPv6アドレスの両方を提供しているためです。ホストは、提供方法とは無関係に、現在利用可能なグローバルルーティブアドレスのサブセットでまったく到達可能である必要があります。
This case is handled the same as if there were different IP addresses, described above in Section 3.2.3. Note that a single interface may experience site multihoming while the host itself may have multiple interfaces.
このケースは、上記のセクション3.2.3で説明した異なるIPアドレスがある場合と同じように処理されます。単一のインターフェイスでは、ホスト自体に複数のインターフェイスがある可能性があり、単一のインターフェイスがマルチホミングを経験する可能性があることに注意してください。
Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others.
ホストはマルチホームとモバイルの同時に同時に行われる可能性があり、マルチホームのホストは、他のいくつかの実際のIPアドレスを明らかにしながら、いくつかのインターフェイスの場所を保護したい場合があることに注意してください。
This document does not presently specify additional site multihoming extensions to HIP; further alignment with the IETF shim6 working group may be considered in the future.
このドキュメントでは、現在、股関節への追加のサイトマルチホーム拡張機能を指定していません。IETF SHIM6ワーキンググループとのさらなる整合性は、将来考慮される可能性があります。
Consider the case in which both hosts would like to add an additional address after the base exchange completes. In Figure 6, consider that host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It would send an UPDATE with LOCATOR (containing the address addr1b) to host2, using destination address addr2a, and a new set of SPIs would be added between hosts 1 and 2 (call them SPI1b and SPI2b -- not shown in the figure). Next, consider host2 deciding to add addr2b to the relationship. Host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send to both, then a full mesh (four SA pairs) of SAs would exist between the two hosts. This is the most general case; it often may be the case that hosts primarily establish new SAs only with the peer's Preferred locator. The readdressing protocol is flexible enough to accommodate this choice.
両方のホストが、基本交換が完了した後に追加のアドレスを追加したい場合を考えてみましょう。図6では、SPI1AとSPI2Aをセットアップするためにベース交換でアドレスADDR1Aを使用したHOST1が、アドレスADDR1Bを追加することを検討してください。宛先アドレスADDR2Aを使用して、ロケーター（アドレスADDR1Bを含むアドレスADDR1Bを含む）を使用して更新を送信し、ホスト1と2の間に新しいSPIのセットが追加されます（SPI1BとSPI2Bと呼びます - 図には示されていません）。次に、HOST2が関係にADDR2Bを追加することを決定することを検討します。Host2は、更新を開始するためにHost1のアドレスのいずれかを選択する必要があります。ADDR1A、ADDR1B、またはその両方のアップデートを開始することを選択できます。両方に送信することを選択した場合、2つのホストの間に完全なメッシュ（4つのSAペア）のSASが存在します。これは最も一般的なケースです。多くの場合、ホストは主にピアの優先ロケーターでのみ新しいSASを確立する場合があります。再生プロトコルは、この選択に対応するのに十分な柔軟性があります。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
Figure 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to Add a Second Address
図6：各ホストがロケーターを使用して2番目のアドレスを追加するデュアルマルチホームケース
It looks likely that in the future, many mobile hosts will be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some other(s) may experience mobility (undergo IP address change).
将来的には、多くのモバイルホストが同時にモバイルとマルチホームになっている可能性があります。つまり、複数のモバイルインターフェイスを持っています。さらに、インターフェイスが異なるアクセステクノロジーを使用している場合、1つのインターフェイスが安定しているように見える可能性があります（現在のIPアドレスを保持します）。
The use of LOCATOR plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far.
Locator Plus ESP_INFOの使用は、このようなシナリオのほとんどを処理するのに十分な柔軟性が必要ですが、これまでのところ、より複雑なシナリオは研究されていません。
It is possible for HIP associations to migrate to a state in which both parties are only using locators in different addressing realms. For example, the two hosts may initiate the HIP association when both are using IPv6 locators, then one host may loose its IPv6 connectivity and obtain an IPv4 address. In such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text. The basic problem in this example is that the host readdressing to IPv4 does not know a corresponding IPv4 address of the peer. This may be handled (experimentally) by possibly configuring this address information manually or in the DNS, or the hosts exchange both IPv4 and IPv6 addresses in the locator.
股関節の関連が、両当事者が異なるアドレス指定領域のロケーターのみを使用している状態に移行する可能性があります。たとえば、2人のホストは、両方がIPv6ロケーターを使用しているときに股関節関連を開始する場合があり、1人のホストがIPv6接続を失い、IPv4アドレスを取得できます。そのような場合、異なる領域間のインターワーキングのためのある種のメカニズムを採用する必要があります。このような手法は、現在のテキストの範囲外です。この例の基本的な問題は、IPv4を再処理するホストがピアの対応するIPv4アドレスを知らないことです。これは、このアドレス情報を手動またはDNSで構成する可能性がある場合、またはホストがロケーターのIPv4アドレスとIPv6アドレスの両方を交換する可能性がある場合に（実験的に）処理できます。
It is expected that IPv6 networks will be renumbered much more often than most IPv4 networks. From an end-host point of view, network renumbering is similar to mobility.
IPv6ネットワークは、ほとんどのIPv4ネットワークよりもはるかに頻繁に変更されることが予想されます。終わりの視点から、ネットワークの変更はモビリティに似ています。
A Responder host MAY include a LOCATOR parameter in the R1 packet that it sends to the Initiator. This parameter MUST be protected by the R1 signature. If the R1 packet contains LOCATOR parameters with a new Preferred locator, the Initiator SHOULD directly set the new Preferred locator to status ACTIVE without performing address verification first, and MUST send the I2 packet to the new Preferred locator. The I1 destination address and the new Preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes.
レスポンダーホストには、R1パケットにロケーターパラメーターがイニシエーターに送信されることがあります。このパラメーターは、R1署名によって保護する必要があります。R1パケットに新しい優先ロケーターを備えたロケーターパラメーターが含まれている場合、イニシエーターは最初にアドレス検証を実行せずに新しい優先ロケーターをアクティブに直接設定し、I2パケットを新しい優先ロケーターに送信する必要があります。I1宛先アドレスと新しい優先ロケーターは同一である可能性があります。すべての新しい非優先ロケーターは、基本交換が完了すると、住所検証を受けなければなりません。
Initiator Responder
イニシエーターレスポンダー
R1 with LOCATOR
<-----------------------------------
record additional addresses
change responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)
Figure 7: LOCATOR Inclusion in R1
図7：R1へのロケーターインクルージョン
An Initiator MAY include one or more LOCATOR parameters in the I2 packet, independent of whether or not there was a LOCATOR parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new Preferred locator SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the Preferred locator.
イニシエーターには、R1にロケーターパラメーターがあったかどうかに関係なく、i2パケットに1つ以上のロケーターパラメーターを含めることができます。これらのパラメーターは、i2署名によって保護する必要があります。I2パケットにロケーターパラメーターが含まれている場合でも、ResponderはI2のソースアドレスにR2パケットを送信する必要があります。新しい優先ロケーターは、i2ソースアドレスと同一である必要があります。I2パケットにロケーターパラメーターが含まれている場合、すべての新しいロケーターが通常どおりアドレス検証を受ける必要があり、その後続くESPトラフィックは優先ロケーターを使用する必要があります。
Initiator Responder
イニシエーターレスポンダー
I2 with LOCATOR
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
Figure 8: LOCATOR Inclusion in I2
図8：i2にロケーターを含める
The I1 and I2 may be arriving from different source addresses if the LOCATOR parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for instance, the example in Appendix A of [RFC5201]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR parameter.
I1とI2は、ロケーターパラメーターがR1に存在する場合、異なるソースアドレスから到着する可能性があります。この場合、イニシエーターIPアドレスによってインデックス付けされた複数の事前に作成されたR1Sを使用して同時に実装は、認識されたパズルの不一致により、I2パケットのパズルソリューションに不注意に失敗する可能性があります。たとえば、[RFC5201]の付録Aの例を参照してください。解決策として、R1がロケーターパラメーターを含める場合、Responderのパズルインデックスメカニズムは、状況に対応するのに十分な柔軟性が必要です。
When a HIP host receives a set of locators from another HIP host in a LOCATOR, it does not necessarily know whether the other host is actually reachable at the claimed addresses. In fact, a malicious peer host may be intentionally giving bogus addresses in order to cause a packet flood towards the target addresses [RFC4225]. Likewise, viral software may have compromised the peer host, programming it to redirect packets to the target addresses. Thus, the HIP host must first check that the peer is reachable at the new address.
ヒップホストがロケーターの別の股関節ホストからロケーターのセットを受信する場合、他のホストが請求されたアドレスで実際に到達可能かどうかは必ずしもわかりません。実際、悪意のあるピアホストは、ターゲットアドレスにパケットフラッドを引き起こすために、意図的に偽のアドレスを与えている可能性があります[RFC4225]。同様に、ウイルスソフトウェアがピアホストを侵害し、ターゲットアドレスにパケットをリダイレクトするようにプログラミングする可能性があります。したがって、HIPホストは、最初にピアが新しいアドレスで到達可能であることを確認する必要があります。
An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI.
アドレス検証を実行することの追加の潜在的な利点は、新しいパスに沿ってネットワーク内のミドルボックスを許可して、ピアホストのインバウンドSPIを取得できるようにすることです。
Address verification is implemented by the challenger sending some piece of unguessable information to the new address, and waiting for some acknowledgment from the Responder that indicates reception of the information at the new address. This may include the exchange of a nonce, or the generation of a new SPI and observation of data arriving on the new SPI.
アドレスの検証は、チャレンジャーによって実装され、新しいアドレスに施されていない情報の一部を送信し、新しいアドレスでの情報の受信を示すレスポンダーからの承認を待っています。これには、非CEの交換、または新しいSPIの生成、および新しいSPIに到着するデータの観察が含まれる場合があります。
Credit-Based Authorization (CBA) allows a host to securely use a new locator even though the peer's reachability at the address embedded in the locator has not yet been verified. This is accomplished based on the following three hypotheses:
クレジットベースの承認（CBA）により、ロケーターに埋め込まれたアドレスでのピアの到達可能性がまだ検証されていない場合でも、ホストは新しいロケーターを安全に使用できます。これは、次の3つの仮説に基づいて達成されます。
1. A flooding attacker typically seeks to somehow multiply the packets it generates for the purpose of its attack because bandwidth is an ample resource for many victims.
1. 洪水攻撃者は通常、帯域幅が多くの被害者にとって十分なリソースであるため、攻撃の目的で生成するパケットを何らかの形で掛けることを求めています。
2. An attacker can often cause unamplified flooding by sending packets to its victim, either by directly addressing the victim in the packets, or by guiding the packets along a specific path by means of an IPv6 Routing header, if Routing headers are not filtered by firewalls.
2. 攻撃者は、パケット内の被害者に直接対処するか、ラーティングヘッダーがファイアウォールでフィルタリングされていない場合、IPv6ルーティングヘッダーによって特定のパスに沿ってパケットを導くことにより、被害者にパケットを送信することにより、増幅されていない洪水を引き起こすことがよくあります。
3. Consequently, the additional effort required to set up a redirection-based flooding attack (without CBA and return routability checks) would pay off for the attacker only if amplification could be obtained this way.
3. その結果、リダイレクトベースの洪水攻撃を設定するために必要な追加の努力（CBAおよび返品ルー上のチェックなし）は、この方法で増幅を取得できる場合にのみ攻撃者の報われます。
On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents amplifications. This is accomplished by limiting the data a host can send to an unverified address of a peer by the data recently received from that peer. Redirection-based flooding attacks thus become less attractive than, for example, pure direct flooding, where the attacker itself sends bogus packets to the victim.
これに基づいて、そもそも悪意のあるパケットリダイレクトを排除するのではなく、クレジットベースの承認は増幅を防ぎます。これは、ホストがそのピアから最近受け取ったデータによって、ホストがピアの未検証のアドレスに送信できるデータを制限することによって達成されます。したがって、リダイレクトベースの洪水攻撃は、たとえば、攻撃者自体が偽のパケットを被害者に送信する純粋な直接洪水よりも魅力的ではありません。
Figure 9 illustrates Credit-Based Authorization: Host B measures the amount of data recently received from peer A and, when A readdresses, sends packets to A's new, unverified address as long as the sum of the packet sizes does not exceed the measured, received data volume. When insufficient credit is left, B stops sending further packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 9 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks.
図9はクレジットベースの承認を示しています：ホストBは、ピアAから最近受け取ったデータの量を測定し、パケットサイズの合計が測定された、受信された、受信した、パケットサイズの合計が測定されていない限り、パケットをAの新しい未確認のアドレスに送信する場合、データボリューム。クレジットが不十分な場合、BはAのアドレスがアクティブになるまでAにさらにパケットを送信するのを停止します。住所の変更は、機動性、マルチホーム、またはその他の理由が原因である可能性があります。図9には示されていないのは、クレジット老化の結果（セクション5.6.2）であり、可能性のあるタイムシフト攻撃を減衰させるために使用されるメカニズムです。
+-------+ +-------+
| A | | B |
+-------+ +-------+
| |
address |------------------------------->| credit += size(packet)
ACTIVE | |
|------------------------------->| credit += size(packet)
|<-------------------------------| do not change credit
| |
+ address change |
+ address verification starts |
address |<-------------------------------| credit -= size(packet)
UNVERIFIED |------------------------------->| credit += size(packet)
|<-------------------------------| credit -= size(packet)
| |
|<-------------------------------| credit -= size(packet)
| X credit < size(packet)
| | => do not send packet!
+ address verification concludes |
address | |
ACTIVE |<-------------------------------| do not change credit
| |
Figure 9: Readdressing Scenario
図9：再生シナリオ
When a host has multiple locators, the peer host must decide which to use for outbound packets. It may be that a host would prefer to receive data on a particular inbound interface. HIP allows a particular locator to be designated as a Preferred locator and communicated to the peer (see Section 4).
ホストに複数のロケーターがある場合、ピアホストはアウトバウンドパケットに使用するものを決定する必要があります。ホストは、特定のインバウンドインターフェイスに関するデータを受信することを好む可能性があります。HIPを使用すると、特定のロケーターを優先ロケーターとして指定し、ピアと通信できます（セクション4を参照）。
In general, when multiple locators are used for a session, there is the question of using multiple locators for failover only or for load-balancing. Due to the implications of load-balancing on the transport layer that still need to be worked out, this document assumes that multiple locators are used primarily for failover. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
一般に、セッションに複数のロケーターを使用する場合、フェールオーバーのみまたはロードバランスに複数のロケーターを使用するという問題があります。まだ解決する必要がある輸送層での負荷分散の意味により、このドキュメントは、複数のロケーターが主にフェールオーバーに使用されることを前提としています。実装では、ICMPの相互作用、到達可能性チェック、またはロケーターの障害を検出するその他の手段を使用する場合があります。
This document specifies a new HIP protocol parameter, the LOCATOR parameter (see Section 4), that allows the hosts to exchange information about their locator(s) and any changes in their locator(s). The logical structure created with LOCATOR parameters has three levels: hosts, Security Associations (SAs) indexed by Security Parameter Indices (SPIs), and addresses.
このドキュメントは、ホストがロケーターに関する情報とロケーターの変更を交換できるようにする新しい股関節プロトコルパラメーターであるロケーターパラメーター（セクション4を参照）を指定します。ロケーターパラメーターで作成された論理構造には、ホスト、セキュリティアソシエーション（SA）がセキュリティパラメーターインデックス（SPI）によってインデックス付けされた3つのレベル、およびアドレスの3つのレベルがあります。
The relation between these levels for an association constructed as defined in the base specification [RFC5201] and ESP transform [RFC5202] is illustrated in Figure 10.
基本仕様[RFC5201]で定義されていると構築された関連付けのこれらのレベル間の関係は、図10に示されています。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
Figure 10: Relation between Hosts, SPIs, and Addresses (Base Specification)
図10：ホスト、スピス、アドレス間の関係（ベース仕様）
In Figure 10, host1 and host2 negotiate two unidirectional SAs, and each host selects the SPI value for its inbound SA. The addresses addr1a and addr2a are the source addresses that the hosts use in the base HIP exchange. These are the "preferred" (and only) addresses conveyed to the peer for use on each SA. That is, although packets sent to any of the hosts' interfaces may be accepted on the inbound SA, the peer host in general knows of only the single destination address learned in the base exchange (e.g., for host1, it sends a packet on SPI2a to addr2a to reach host2), unless other mechanisms exist to learn of new addresses.
図10では、HOST1とHOST2は2つの単方向SASをネゴシエートし、各ホストがインバウンドSAのSPI値を選択します。アドレスADDR1AとADDR2Aは、ホストがベース股関節交換で使用するソースアドレスです。これらは、各SAで使用するためにピアに伝えられる「優先」（およびのみ）アドレスです。つまり、ホストのいずれかのインターフェイスに送信されたパケットはインバウンドSAで受け入れられる場合がありますが、一般的にピアホストは基本交換で学習した単一の宛先アドレスのみを知っています（例：HOST1の場合、SPI2Aのパケットを送信しますaddr2aに、Host2に到達するために）、新しいアドレスを学習するために他のメカニズムが存在しない限り。
In general, the bindings that exist in an implementation corresponding to this document can be depicted as shown in Figure 11. In this figure, a host can have multiple inbound SPIs (and, not shown, multiple outbound SPIs) associated with another host. Furthermore, each SPI may have multiple addresses associated with it. These addresses that are bound to an SPI are not used to lookup the incoming SA. Rather, the addresses are those that are provided to the peer host, as hints for which addresses to use to reach the host on that SPI. The LOCATOR parameter is used to change the set of addresses that a peer associates with a particular SPI.
一般に、このドキュメントに対応する実装に存在するバインディングは、図11に示すように示すことができます。この図では、ホストは別のホストに関連付けられた複数のインバウンドSPI（そして示されていない、複数のアウトバウンドSPI）を持つことができます。さらに、各SPIには複数のアドレスが関連付けられている場合があります。SPIに拘束されているこれらのアドレスは、着信SAの検索には使用されません。むしろ、アドレスは、そのSPIのホストに到達するために使用するアドレスをヒントとして、ピアホストに提供されるアドレスです。ロケーターパラメーターは、ピアが特定のSPIに関連付けるアドレスのセットを変更するために使用されます。
address11
/
SPI1 - address12
/
/ address21
host -- SPI2 <
\ address22
\
SPI3 - address31
\
address32
Figure 11: Relation between Hosts, SPIs, and Addresses (General Case)
図11：ホスト、スピス、アドレス間の関係（一般的なケース）
A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing. For example, if the host needs to change its addresses on SPI2, it is likely that both address21 and address22 will simultaneously become obsolete. In a typical case, such SPIs may correspond with physical interfaces; see below. Note, however, that especially in the case of site multihoming, one of the addresses may become unreachable while the other one still works. In the typical case, however, this does not require the host to inform its peers about the situation, since even the non-working address still logically exists.
ホストは、ピアと任意の数のセキュリティ協会（またはSPI）を確立することができます。ピアで複数のスピスを持つことの主な目的は、アドレスを運命共有を経験する可能性のあるコレクションにグループ化することです。たとえば、ホストがSPI2のアドレスを変更する必要がある場合、address21とaddress22の両方が同時に時代遅れになる可能性があります。典型的なケースでは、そのようなスピスは物理インターフェイスに対応する場合があります。下記参照。ただし、特にマルチホミングの場合には、1つのアドレスが到達できなくなる場合があり、もう1つはまだ機能している可能性があることに注意してください。ただし、典型的なケースでは、これはホストがこの状況について同僚に通知する必要はありません。これは、非労働住所でさえも論理的に存在するためです。
A basic property of HIP SAs is that the inbound IP address is not used to lookup the incoming SA. Therefore, in Figure 11, it may seem unnecessary for address31, for example, to be associated only with SPI3 -- in practice, a packet may arrive to SPI1 via destination address address31 as well. However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there is a concern that anti-replay windows might be violated. In this sense, we can say that a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is loose.
股関節SASの基本的な特性は、インバウンドIPアドレスが着信SAを検索するために使用されないことです。したがって、図11では、たとえば、address31がSPI3にのみ関連付けられる必要がないように思われる場合があります。実際には、宛先アドレスアドレス31を介してパケットがSPI1に到着する可能性があります。ただし、異なるソースアドレスと宛先アドレスの使用は通常、ネットワーク内の異なるレイテンシを持つ異なるパスにつながり、特定のSPIの任意の宛先IPアドレス（またはパス）を介してパケットが到着する場合、異なるレイテンシーによる並べ替えは並べ替えます。一部のパケットがESPアンチレプレイウィンドウの外側に落ちる可能性があります。このため、HIPは、アンチレプレイウィンドウに違反される可能性があるという懸念がある場合、インバウンドSPIを使用して宛先アドレスをアフィリエートするメカニズムを提供します。この意味で、特定のインバウンドSPIには特定のインバウンドIPアドレスに対して「親和性」があり、この親和性はピアホストに伝えられていると言えます。ESPアンチレプレイウィンドウが緩んでいない限り、各物理インターフェイスには別のSAが必要です。
Moreover, even when the destination addresses used for a particular SPI are held constant, the use of different source interfaces may also cause packets to fall outside of the ESP anti-replay window, since the path traversed is often affected by the source address or interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI or at least reset its ESP anti-replay window when the peer host readdresses.
さらに、特定のSPIに使用される宛先アドレスが一定に保持されている場合でも、異なるソースインターフェイスを使用すると、パスが通過するパスがソースアドレスまたはインターフェイスによって影響を受けることが多いため、パケットがESPアンチレプレイウィンドウの外側に落ちる可能性があります。使用済み。ホストには、ピアが特定のSPIにパケットを送信するソースインターフェイスに影響を与える方法はありません。ホストは、特定の宛先IPアドレスとSPIに送信する際に、同じソースインターフェイスとアドレスを一貫して使用する必要があります。このため、ホストは、SPIを変更するか、ピアホストが再生されたときにESPアンチレプレイウィンドウを少なくともリセットすることが役立つ場合があります。
An address may appear on more than one SPI. This creates no ambiguity since the receiver will ignore the IP addresses during SA lookup anyway. However, this document does not specify such cases.
アドレスが複数のSPIに表示される場合があります。とにかく、受信者はSAルックアップ中にIPアドレスを無視するため、これは曖昧さを生み出しません。ただし、このドキュメントではそのようなケースは指定されていません。
When the LOCATOR parameter is sent in an UPDATE packet, then the receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an R1 or I2 packet, the base exchange retransmission mechanism will confirm its successful delivery. LOCATORs may experimentally be used in NOTIFY packets; in this case, the recipient MUST consider the LOCATOR as informational and not immediately change the current preferred address, but can test the additional locators when the need arises. The use of the LOCATOR in a NOTIFY message may not be compatible with middleboxes.
ロケーターパラメーターが更新パケットで送信されると、レシーバーは更新承認で応答します。ロケーターパラメーターがR1またはI2パケットで送信されると、ベース交換再送信メカニズムはその成功した配信を確認します。ロケーターは、通知パケットで実験的に使用できます。この場合、受信者はロケーターを情報提供と見なし、現在の優先アドレスをすぐに変更しないでください。ただし、必要に応じて追加のロケーターをテストできます。Notifyメッセージでのロケーターの使用は、ミドルボックスと互換性がない場合があります。
The LOCATOR parameter is a critical parameter as defined by [RFC5201]. It consists of the standard HIP parameter Type and Length fields, plus zero or more Locator sub-parameters. Each Locator sub-parameter contains a Traffic Type, Locator Type, Locator Length, Preferred locator bit, Locator Lifetime, and a Locator encoding. A LOCATOR containing zero Locator fields is permitted but has the effect of deprecating all addresses.
ロケーターパラメーターは、[RFC5201]で定義されている重要なパラメーターです。標準の股関節パラメータータイプと長さフィールドと、ゼロ以上のロケーターサブパラメーターで構成されています。各ロケーターサブパラメーターには、トラフィックタイプ、ロケータータイプ、ロケーターの長さ、優先ロケータービット、ロケーターライフタイム、ロケーターエンコードが含まれています。ゼロロケーターフィールドを含むロケーターは許可されていますが、すべてのアドレスを非難する効果があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: LOCATOR Parameter Format
図12：ロケーターパラメーター形式
Type: 193
タイプ：193
Length: Length in octets, excluding Type and Length fields, and excluding padding.
長さ：オクテットの長さ、タイプと長さのフィールドを除く、パディングを除く。
Traffic Type: Defines whether the locator pertains to HIP signaling, user data, or both.
トラフィックタイプ：ロケーターが股関節の信号、ユーザーデータ、またはその両方に関係するかどうかを定義します。
Locator Type: Defines the semantics of the Locator field.
ロケータータイプ：ロケーターフィールドのセマンティクスを定義します。
Locator Length: Defines the length of the Locator field, in units of 4-byte words (Locators up to a maximum of 4*255 octets are supported).
ロケーターの長さ：4バイトの単語の単位で、ロケーターフィールドの長さを定義します（最大4*255オクテットのロケーターがサポートされています）。
Reserved: Zero when sent, ignored when received.
予約済み：送信時にゼロ、受け取ったときに無視されます。
P: Preferred locator. Set to one if the locator is preferred for that Traffic Type; otherwise, set to zero.
P：優先ロケーター。そのトラフィックタイプにロケーターが優先される場合は、1に設定します。それ以外の場合は、ゼロに設定します。
Locator Lifetime: Locator lifetime, in seconds.
ロケーターのライフタイム：ロケーターライフタイム、秒単位。
Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All Locator sub-fields are integral multiples of four octets in length.
ロケーター：セマンティクスとエンコードがロケータータイプフィールドで示されるロケーター。すべてのロケーターサブフィールドは、長さの4オクテットの積分倍です。
The Locator Lifetime indicates how long the following locator is expected to be valid. The lifetime is expressed in seconds. Each locator MUST have a non-zero lifetime. The address is expected to become deprecated when the specified number of seconds has passed since the reception of the message. A deprecated address SHOULD NOT be used as a destination address if an alternate (non-deprecated) is available and has sufficient scope.
ロケーターの寿命は、次のロケーターが有効になると予想される期間を示します。寿命は数秒で表現されます。各ロケーターにはゼロ以外の寿命が必要です。指定された秒数がメッセージの受信以来通過した場合、住所は非推奨になると予想されます。代替（非廃止）が利用可能であり、十分な範囲がある場合、非推奨アドレスを宛先アドレスとして使用しないでください。
The following Traffic Type values are defined:
次のトラフィックタイプの値が定義されています。
0: Both signaling (HIP control packets) and user data.
0：シグナリング（ヒップ制御パケット）とユーザーデータの両方。
1: Signaling packets only.
1：シグナリングパケットのみ。
2: Data packets only.
2：データパケットのみ。
The "P" bit, when set, has scope over the corresponding Traffic Type. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. If there is a conflict (for example, if the "P" bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case, "2"). By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. If no locators are indicated as preferred for a given Traffic Type, the implementation may use an arbitrary locator from the set of active locators.
「P」ビットは、設定されたときに、対応するトラフィックタイプを範囲に及ぼします。つまり、「P」ビットがトラフィックタイプ「2」に設定されている場合、たとえば、ロケーターがデータパケットに好まれることを意味します。競合がある場合（たとえば、「p」ビットがタイプ「0」のアドレスと「タイプ2」の別のアドレスに設定されている場合）、より具体的なトラフィックタイプのルールが適用されます（この場合、2」"）。デフォルトでは、ベース交換で使用されるIPアドレスは、新しい優先ロケーターがそれらに取って代わらない限り、信号データとユーザーデータの両方に対して優先ロケーターです。特定のトラフィックタイプに対して好まれていると示されているロケーターがない場合、実装はアクティブロケーターのセットから任意のロケーターを使用する場合があります。
The following Locator Type values are defined, along with the associated semantics of the Locator field: 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] (128 bits long). This locator type is defined primarily for non-ESP-based usage.
次のロケータータイプの値は、ロケーターフィールドの関連するセマンティクスとともに定義されています：0：IPv6アドレスまたはIPv4-in-IPV6形式IPv4アドレス[RFC4291]（長さ128ビット）。このロケータータイプは、主に非ESPベースの使用法に対して定義されます。
1: The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 128 bits). This IP address is defined primarily for ESP-based usage.
1：ESP SPI（最初の32ビット）の連結と、IPv6アドレスまたはIPv4-in-IPV6形式のIPv4アドレス（追加の128ビット）が続きます。このIPアドレスは、主にESPベースの使用法に対して定義されています。
A number of combinations of parameters in an UPDATE packet are possible (e.g., see Section 3.2). In this document, procedures are defined only for the case in which one LOCATOR and one ESP_INFO parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD list all of the locators that are active on the HIP association (including those on SAs not covered by the ESP_INFO parameter). Any UPDATE packet that includes a LOCATOR parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. The sending of multiple LOCATOR and/or ESP_INFO parameters is for further study; receivers may wish to experiment with supporting such a possibility.
更新パケット内のパラメーターの多くの組み合わせが可能です（たとえば、セクション3.2を参照）。このドキュメントでは、手順は、1つのロケーターと1つのESP_INFOパラメーターが任意の股関節パケットで使用される場合にのみ定義されます。さらに、ロケーターは、股関節関連（ESP_INFOパラメーターでカバーされていないSASを含む）でアクティブなすべてのロケーターをリストする必要があります。ロケーターパラメーターを含む更新パケットは、HMACとHIP_Signatureパラメーターの両方を含める必要があります。発表されたロケーターとパケットに存在するESP_INFOパラメーターとの関係は、セクション5.2で定義されています。複数のロケーターおよび/またはESP_INFOパラメーターの送信は、さらなる研究のためのものです。受信者は、そのような可能性をサポートすることを実験したい場合があります。
This section describes rules for sending and receiving the LOCATOR parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators.
このセクションでは、ロケーターパラメーターの送信と受信、アドレスの到達可能性のテスト、および未検証のロケーターでのクレジットベースの認証（CBA）の使用に関するルールについて説明します。
In a typical implementation, each outgoing locator is represented by a piece of state that contains the following data:
典型的な実装では、各発信ロケーターは、次のデータを含む状態の一部で表されます。
o the actual bit pattern representing the locator,
o ロケーターを表す実際のビットパターン、
o the lifetime (seconds),
o 生涯（秒）、
o the status (UNVERIFIED, ACTIVE, DEPRECATED),
o ステータス（未検証、アクティブ、非推奨）、
o the Traffic Type scope of the locator, and
o ロケーターのトラフィックタイプスコープ、および
o whether the locator is preferred for any particular scope.
o 特定の範囲にロケーターが好まれるかどうか。
The status is used to track the reachability of the address embedded within the LOCATOR parameter:
ステータスは、ロケーターパラメーターに埋め込まれたアドレスの範囲の範囲を追跡するために使用されます。
UNVERIFIED indicates that the reachability of the address has not been verified yet,
未検証は、アドレスの到達可能性がまだ検証されていないことを示しています、
ACTIVE indicates that the reachability of the address has been verified and the address has not been deprecated,
アクティブは、アドレスの到達可能性が検証されており、アドレスが非推奨されていないことを示しています。
DEPRECATED indicates that the locator lifetime has expired.
非推奨は、ロケーターの寿命が切れたことを示しています。
The following state changes are allowed:
次の状態の変更が許可されています。
UNVERIFIED to ACTIVE The reachability procedure completes successfully.
到達可能性の手順をアクティブにするために正常に完了します。
UNVERIFIED to DEPRECATED The locator lifetime expires while the locator is UNVERIFIED.
ロケーターが未確認の間、ロケーターの寿命が失効することを控除するために未確認。
ACTIVE to DEPRECATED The locator lifetime expires while the locator is ACTIVE.
ロケーターがアクティブになっている間、ロケーターの寿命が切れるようにアクティブになります。
ACTIVE to UNVERIFIED There has been no traffic on the address for some time, and the local policy mandates that the address reachability must be verified again before starting to use it again.
アクティブから未検証のために、しばらくの間住所にトラフィックがありませんでした。また、ローカルポリシーは、住所の到達可能性を再度使用し始める前に再度検証する必要があることを義務付けています。
DEPRECATED to UNVERIFIED The host receives a new lifetime for the locator.
ホストが検証されないように非推奨は、ロケーターに新しい生涯を受け取ります。
A DEPRECATED address MUST NOT be changed to ACTIVE without first verifying its reachability.
非推奨住所は、最初にその到達可能性を確認せずにアクティブに変更してはなりません。
Note that the state of whether or not a locator is preferred is not necessarily the same as the value of the Preferred bit in the Locator sub-parameter received from the peer. Peers may recommend certain locators to be preferred, but the decision on whether to actually use a locator as a preferred locator is a local decision, possibly influenced by local policy.
ロケーターが優先されるかどうかの状態は、ピアから受け取ったロケーターサブパラメーターの優先ビットの値と必ずしも同じではないことに注意してください。ピアは特定のロケーターを推奨することを推奨する場合がありますが、実際にロケーターを優先ロケーターとして使用するかどうかについての決定はローカルの決定であり、おそらくローカルポリシーの影響を受けます。
The decision of when to send LOCATORs is basically a local policy issue. However, it is RECOMMENDED that a host send a LOCATOR whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. Rapidly sending LOCATORs that force the peer to change the preferred address SHOULD be avoided.
ロケーターをいつ送信するかという決定は、基本的にローカルポリシーの問題です。ただし、ホストは、アクティブな股関節関連で使用されているIPアドレスの変更を認識するたびにロケーターを送信することをお勧めし、変更が少なくとも数秒間続くと想定しています。ピアを強制するロケーターを迅速に送信して、優先アドレスを変更するように強制することは避ける必要があります。
When a host decides to inform its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs. The grouping should consider also whether middlebox interaction requires sending the same LOCATOR in separate UPDATEs on different paths. Since each SPI is associated with a different Security Association, the grouping policy may also be based on ESP anti-replay protection considerations. In the typical case, simply basing the grouping on actual kernel level physical and logical interfaces may be the best policy. Grouping policy is outside of the scope of this document.
ホストがIPアドレスの変更について同僚に通知することを決定した場合、さまざまなアドレスをSPIでグループ化する方法を決定する必要があります。グループ化は、Middleboxの相互作用に異なるパスの個別の更新で同じロケーターを送信する必要があるかどうかを検討する必要があります。各SPIは異なるセキュリティ協会に関連付けられているため、グループ化ポリシーはESPアンチレプレイ保護の考慮事項にも基づいている可能性があります。典型的なケースでは、実際のカーネルレベルの物理的および論理的インターフェイスにグループ化するだけで最良のポリシーになる可能性があります。グループ化ポリシーは、このドキュメントの範囲外です。
Note that the purpose of announcing IP addresses in a LOCATOR is to provide connectivity between the communicating hosts. In most cases, tunnels or virtual interfaces such as IPsec tunnel interfaces or Mobile IP home addresses provide sub-optimal connectivity. Furthermore, it should be possible to replace most tunnels with HIP based "non-tunneling", therefore making most virtual interfaces fairly unnecessary in the future. Therefore, virtual interfaces SHOULD NOT be announced in general. On the other hand, there are clearly situations where tunnels are used for diagnostic and/or testing purposes. In such and other similar cases announcing the IP addresses of virtual interfaces may be appropriate.
ロケーターでIPアドレスを発表する目的は、通信ホスト間の接続を提供することであることに注意してください。ほとんどの場合、IPSECトンネルインターフェイスやモバイルIPホームアドレスなどのトンネルまたは仮想インターフェイスは、最適な接続性を提供します。さらに、ほとんどのトンネルを股関節ベースの「非タンネル」に置き換えることができるはずであるため、ほとんどの仮想インターフェイスは将来的にはかなり不必要になります。したがって、仮想インターフェイスを一般的に発表するべきではありません。一方、診断および/またはテストの目的でトンネルが使用される状況は明らかにあります。このようなおよび他の同様のケースでは、仮想インターフェイスのIPアドレスを発表するのが適切かもしれません。
Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link-local. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as Preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link.
ホストは、ロケーターの放送またはマルチキャストアドレスを発表してはなりません。リンクローカルアドレスは、ピアのIP宛先アドレスがリンクローカルである場合など、同じリンク上の隣人であることが知られているピアに発表される場合があります。この場合のLink-Localアドレスの発表は政策決定です。優先ロケーターとして使用されるLink-Localアドレスは、ホストが別のリンクに移動すると、到達可能性の問題が発生します。いずれにせよ、そのピアが同じリンクにあることが知られていない限り、Link-Localアドレスをピアに発表してはなりません。
Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR parameter that serves as a complete representation of the addresses and affiliated SPIs intended for active use. We now describe a few cases introduced in Section 3.2. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation.
ホストがSPISへのアドレスのグループと割り当てを決定すると、アクティブな使用を目的としたアドレスと関連するSPIの完全な表現として機能するロケーターパラメーターを作成します。現在、セクション3.2で導入されたいくつかのケースについて説明します。各ロケーターのトラフィックタイプは「0」に設定されていると仮定します（トラフィックタイプのその他の値は、股関節制御プレーンをデータプレーントラフィックから分離するドキュメントで指定できます）。他のモビリティやマルチホームのケースは可能ですが、さらなる実験のために残されています。
1. Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR contains a single Locator with a "Locator Type" of "1";
1. マルチホームがなく、再キーキングのないホストモビリティ。モバイルホストは、単一のロケーターパラメーターを備えた単一のESP_INFOを含む単一の更新を作成します。ESP_INFOには、古いSPIフィールドと新しいSPIフィールドの両方にSPIの現在の値が含まれています。ロケーターには、「1」の「ロケータータイプ」を持つ単一のロケーターが含まれています。
the SPI must match that of the ESP_INFO. The Preferred bit SHOULD be set and the "Locator Lifetime" is set according to local policy. The UPDATE also contains a SEQ parameter as usual. This packet is retransmitted as defined in the HIP protocol specification [RFC5201]. The UPDATE should be sent to the peer's preferred IP address with an IP source address corresponding to the address in the LOCATOR parameter.
SPIはESP_INFOのSPIと一致する必要があります。優先ビットを設定し、「ロケーターライフタイム」はローカルポリシーに従って設定されます。更新には、通常どおりSEQパラメーターも含まれています。このパケットは、股関節プロトコル仕様[RFC5201]で定義されているように再送信されます。更新は、ロケーターパラメーターのアドレスに対応するIPソースアドレスを使用して、ピアの優先IPアドレスに送信する必要があります。
2. Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI and the new value of the SPI in the NEW SPI, and a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. The LOCATOR contains a single Locator with "Locator Type" of "1"; the SPI must match that of the NEW SPI in the ESP_INFO. Otherwise, the steps are identical to the case in which no rekeying is initiated.
2. マルチホミングのないが、再キーリングしてホストのモビリティ。モバイルホストは、単一のロケーターパラメーターを備えた単一のESP_INFO（単一のアドレスを含む）を含む単一の更新を作成します。ESP_INFOには、古いSPIのSPIの現在の値と、新しいSPIのSPIの新しい値、およびローカルポリシーで選択されたキーマットインデックスが含まれています。オプションで、ホストはdiffie_hellmanパラメーターを含めることにより、Diffie Hellman Rekeを開始することを選択できます。ロケーターには、「1」の「ロケータータイプ」を持つ単一のロケーターが含まれています。SPIは、ESP_INFOの新しいSPIのSPIと一致する必要があります。それ以外の場合、手順は、再キーイングが開始されない場合と同じです。
3. Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host SHOULD set up a new SA pair between this new address and the preferred address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW SPI field corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR with two Type "1" Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI contained in the ESP_INFO). The Preferred bit SHOULD be set depending on the policy to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and optionally a DIFFIE_HELLMAN parameter, and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's Preferred address with a source address corresponding to the new locator.
3. ホストマルチホミング（アドレスの追加）。（以前の）シングルホームの非モバイルホストに追加のアドレスを追加する簡単なケースのみを説明します。ホストは、この新しいアドレスとピアホストの優先アドレスの間に新しいSAペアをセットアップする必要があります。これを行うために、マルチホームのホストは新しいインバウンドSAを作成し、新しいSPIを作成します。発信更新メッセージの場合、「0」の古いSPIフィールド、新しいSPIに対応する新しいSPIフィールド、およびローカルポリシーで選択されたキーマットインデックスを持つESP_INFOパラメーターを挿入します。ホストは、2つのタイプの「1」ロケーターを持つロケーターを更新メッセージに追加します。これは、関連性のある元のアドレスとSPI、および新しいアドレスと新しいSPIが追加されます（SPIがESP_INFOに含まれる新しいSPIと一致します）。優先ビットは、ピアホストに2つのロケーターのうちどれが推奨されているかを伝えるためのポリシーに応じて設定する必要があります。この更新には、SEQパラメーターとオプションでdiffie_hellmanパラメーターも含まれており、この新しいアドレスに関する再キーイング手順に従います。更新メッセージは、新しいロケーターに対応するソースアドレスを使用して、ピアの優先アドレスに送信する必要があります。
The sending of multiple LOCATORs, locators with Locator Type "0", and multiple ESP_INFO parameters is for further study. Note that the inclusion of LOCATOR in an R1 packet requires the use of Type "0" locators since no SAs are set up at that point.
複数のロケーター、ロケータータイプ「0」のロケーター、および複数のESP_INFOパラメーターの送信は、さらなる研究用です。R1パケットにロケーターを含めるには、その時点でSASがセットアップされないため、タイプ「0」ロケーターを使用する必要があることに注意してください。
A host SHOULD be prepared to receive a LOCATOR parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY.
ホストは、次の股関節パケットでロケーターパラメーターを受信する準備をする必要があります：R1、I2、更新、および通知。
This document describes sending both ESP_INFO and LOCATOR parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI, and is otherwise included for the possible benefit of HIP-aware middleboxes. The LOCATOR parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association.
このドキュメントでは、アップデートでESP_INFOとロケーターの両方のパラメーターを送信することについて説明します。ESP_INFOパラメーターは、新しいSPIを再キーまたはキーする必要がある場合に含まれており、股関節が認識されるミドルボックスの可能性のために含まれています。ロケーターパラメーターには、ホストが股関節関連のためにアクティブにしたい、または維持したいロケーターの完全なマップが含まれています。
In general, the processing of a LOCATOR depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.2.
一般に、ロケーターの処理は、それが含まれているパケットタイプに依存します。ここでは、ESP_INFOが存在し、単一のロケーターとESP_INFOが更新メッセージに送信される場合のみを説明します。他のケースはさらなる研究のためです。以下の手順は、セクション5.2で説明した各ケースをカバーしています。
The processing of ESP_INFO and LOCATOR parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD first process the ESP_INFO before the LOCATOR, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" locator will only contain a reference to the new SPI.
ESP_INFOおよびロケーターパラメーターの処理は、モジュール式であり、複数のESP_INFOおよび/または複数のロケーターパラメーターを含めるための将来の一般化をサポートすることを目的としています。ESP_INFOには既存のSPIにマッピングされた新しいSPI値が含まれているため、ホストは最初にロケーターの前にESP_INFOを処理する必要がありますが、タイプ「1」ロケーターには新しいSPIへの参照のみが含まれます。
When a host receives a validated HIP UPDATE with a LOCATOR and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter:
ホストがロケーターとESP_INFOパラメーターを使用して検証済みのHIPアップデートを受信すると、次のようにESP_INFOを処理します。ESP_INFOパラメーターは、SAがミドルボックスの利益のために再キー化、作成、非推奨、または単に識別されているかどうかを示します。ホストは、ESP_INFOパラメーターで古いSPIと新しいSPI値を調べます。
1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes) and no rekeying is necessary.
1. （再キーイングなし）古いSPIが新しいSPIに等しく、どちらが既存のSPIに対応している場合、ESP_INFOは無償（ミドルボックスに提供）であり、再キーイングは必要ありません。
2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the NEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR parameter will reference this new SPI instead of the old SPI.
2. （再キーイング）古いSPIが既存のSPIを示し、新しいSPIが異なる非ゼロ値である場合、既存のSAは再キーがかかり、ホストは新しいアウトバウンドSAを新しいアウトバウンドSAを作成することにより手順を再キーにしています。SPI、このSPIに拘束されていないアドレスはありません。ロケーターパラメーターのロケーターは、古いSPIの代わりにこの新しいSPIを参照することに注意してください。
3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host must create a new SA and respond with an UPDATE ACK.
3. （新しいSA）古いSPI値がゼロで、新しいSPIが新しい非ゼロ値である場合、ピアから新しいSAが要求されます。このケースは、再キーイングイベントのようにも扱われます。受信ホストは、新しいSAを作成し、更新ACKで応答する必要があります。
4. (deprecating the SA) If the OLD SPI indicates an existing SPI and the NEW SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into the DEPRECATED state.
4. （SAを非難する）古いSPIが既存のSPIを示し、新しいSPIがゼロである場合、SAは非推奨であり、すべてのロケーターがSPIに一意に縛られていることが非推奨状態に入れられます。
If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped.
上記のケースのいずれも適用されない場合、プロトコルエラーが発生し、更新の処理が停止します。
Next, the locators in the LOCATOR parameter are processed. For each locator listed in the LOCATOR parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself.
次に、ロケーターパラメーターのロケーターが処理されます。ロケーターパラメーターにリストされている各ロケーターについて、そのアドレスが法的ユニキャストまたはAnycastアドレスであることを確認します。つまり、アドレスは放送またはマルチキャストアドレスであってはなりません。一部の実装は、ホストがそれ自体で股関節を実行することを許可される可能性があるため、ローカルホストを示すアドレスを受け入れる場合があることに注意してください。
The below assumes that all locators are of Type "1" with a Traffic Type of "0"; other cases are for further study.
以下は、すべてのロケーターがトラフィックタイプの「0」を持つタイプ「1」であることを前提としています。他のケースはさらなる研究のためです。
For each Type "1" address listed in the LOCATOR parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED.
ロケーターパラメーターにリストされている各タイプ「1」アドレスについて、ホストはアドレスがすでに示されているSPIに拘束されているかどうかをチェックします。アドレスがすでにバインドされている場合、その寿命は更新されます。アドレスのステータスが非推奨される場合、ステータスは未確認に変更されます。アドレスがまだバインドされていない場合、アドレスが追加され、そのステータスは未確認に設定されています。廃止されたロケーターパラメーターにリストされていないSPIに対応するすべてのアドレスをマークします。
As a result, at the end of processing, the addresses listed in the LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR parameter have a state of DEPRECATED.
その結果、処理の終了時に、ロケーターパラメーターにリストされているアドレスには未検証またはアクティブの状態があり、ロケーターパラメーターにリストされていない古いSAの古いアドレスは、非推奨の状態を持っています。
Once the host has processed the locators, if the LOCATOR parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes the Preferred locator; see Section 5.5.
ホストがロケーターを処理したら、ロケーターパラメーターに新しい優先ロケーターが含まれている場合、ホストは優先ロケーターの変更を開始する必要があります。これには、ホストが最初に関連するアドレスの到達可能性を検証する必要があり、次に優先ロケーターを変更するだけです。セクション5.5を参照してください。
If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the Preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR parameter.
ホストがサポートされていないロケータータイプを持つロケーターを受信し、そのようなロケーターがピアの優先ロケーターであると宣言された場合、ホストは通知メッセージタイプのlocator_type_unsupportedで通知メッセージタイプで通知エラーを送信する必要があります。受信者が処理に失敗したロケーター。それ以外の場合、ホストは、サポートされていないロケータータイプを備えた（非優先）ロケーターがロケーターパラメーターで受信された場合、Notifyエラーを送信する場合があります。
A host MUST verify the reachability of an UNVERIFIED address. The status of a newly learned address MUST initially be set to UNVERIFIED unless the new address is advertised in a R1 packet as a new Preferred locator. A host MAY also want to verify the reachability of an ACTIVE address again after some time, in which case it would set the status of the address to UNVERIFIED and reinitiate address verification.
ホストは、未検証のアドレスの到達可能性を確認する必要があります。新しく学習したアドレスのステータスは、新しいアドレスが新しい優先ロケーターとしてR1パケットで宣伝されない限り、最初に未確認に設定する必要があります。ホストは、しばらくしてから再びアクティブアドレスの到達可能性を再度検証することもできます。その場合、アドレスのステータスを未検証に設定し、住所の検証を再現します。
A host typically starts the address-verification procedure by sending a nonce to the new address. For example, when the host is changing its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD be random and the value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. However, if the host is not changing its SPI, it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent to the new address. A host MAY also use other message exchanges as confirmation of the address reachability.
通常、ホストは、新しいアドレスに非CEを送信することにより、アドレス検証手順を開始します。たとえば、ホストがSPIを変更し、ESP_INFOをピアに送信している場合、新しいSPI値はランダムであり、値をRekeyingアップデートで送信したECHO_REQUESTにコピーすることができます。ただし、ホストがSPIを変更していない場合でも、新しいアドレスに送信された更新メッセージでECHO_REQUESTパラメーターを使用する場合があります。ホストは、アドレスの到達可能性の確認として、他のメッセージ交換を使用することもあります。
Note that in the case of receiving a LOCATOR in an R1 and replying with an I2 to the new address in the LOCATOR, receiving the corresponding R2 is sufficient proof of reachability for the Responder's preferred address. Since further address verification of such an address can impede the HIP-base exchange, a host MUST NOT separately verify reachability of a new Preferred locator that was received on an R1.
R1でロケーターを受信し、I2でロケーターの新しいアドレスに返信する場合、対応するR2を受信することは、Responderの優先アドレスのリーチ性の十分な証明であることに注意してください。このような住所のさらなるアドレスの検証は、股関節ベース交換を妨げる可能性があるため、ホストはR1で受信された新しい優先ロケーターの到達可能性を個別に確認してはなりません。
In some cases, it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification as depicted in Figure 13, instead of waiting for the confirmation via a HIP packet. In this case, a host advertising a new SPI as part of its address reachability check SHOULD be prepared to receive traffic on the new SA.
場合によっては、股関節パケットを介して確認を待つ代わりに、図13に示すように、新しく宣伝されたSA上のデータの到着を、図13に示すように、暗黙のアドレスの到達可能性検証として使用するだけで十分かもしれません。この場合、アドレスの到達可能性チェックの一部として新しいSPIを宣伝するホストは、新しいSAのトラフィックを受信するために準備する必要があります。
Mobile host Peer host
モバイルホストピアホスト
prepare incoming SA
NEW SPI in ESP_INFO (UPDATE)
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
Figure 13: Address Activation Via Use of a New SA
図13：新しいSAの使用によるアドレスアクティベーション
When address verification is in progress for a new Preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new Preferred locator while in UNVERIFIED status to the extent Credit-Based Authorization permits. Credit-Based Authorization is explained in Section 5.6. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE.
新しい優先ロケーターのアドレス検証が進行中の場合、ホストは、住所検証が完了するまで通信を継続するために、そのようなロケーターが利用可能な場合、アクティブとしてリストされている別のロケーターを選択する必要があります。あるいは、ホストは、クレジットベースの承認許可の範囲で未検証のステータスで、新しい優先ロケーターを使用する場合があります。クレジットベースの承認は、セクション5.6で説明されています。住所の確認が成功すると、新しい優先ロケーターのステータスがアクティブに変更されます。
A host MAY want to change the Preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have become unreachable. Another reason may be due to receiving a LOCATOR parameter that has the "P" bit set.
ホストは、トラフィック情報またはICMPエラーメッセージが現在使用されている優先アドレスが到達不能になった可能性があることを示しているため、さまざまな理由で、優先される発信ロケーターを変更したい場合があります。もう1つの理由は、「P」ビットが設定されているロケーターパラメーターを受信したことです。
To change the Preferred locator, the host initiates the following procedure:
好みのロケーターを変更するために、ホストは次の手順を開始します。
1. If the new Preferred locator has ACTIVE status, the Preferred locator is changed and the procedure succeeds.
1. 新しい優先ロケーターがアクティブなステータスを持っている場合、優先ロケーターが変更され、手順が成功します。
2. If the new Preferred locator has UNVERIFIED status, the host starts to verify its reachability. The host SHOULD use a different locator listed as ACTIVE until address verification completes if one such locator is available. Alternatively, the host MAY use the new Preferred locator, even though in UNVERIFIED status, to the extent Credit-Based Authorization permits. Once address verification succeeds, the status of the new Preferred locator changes to ACTIVE and its use is no longer governed by Credit-Based Authorization.
2. 新しい優先ロケーターが未確認のステータスを持っている場合、ホストはそのリーチ性の確認を開始します。ホストは、そのようなロケーターが1つ利用可能な場合、アドレス検証が完了するまでアクティブとしてリストされている別のロケーターを使用する必要があります。あるいは、ホストは、未検証のステータスであっても、クレジットベースの承認許可の範囲で、新しい優先ロケーターを使用する場合があります。住所の検証が成功すると、新しい優先ロケーターのステータスがアクティブに変更され、その使用はクレジットベースの承認によって支配されなくなります。
3. If the peer host has not indicated a preference for any address, then the host picks one of the peer's ACTIVE addresses randomly or according to policy. This case may arise if, for example, ICMP error messages that deprecate the Preferred locator arrive, but the peer has not yet indicated a new Preferred locator.
3. ピアホストがいかなるアドレスの好みを示していない場合、ホストはピアのアクティブアドレスの1つをランダムにまたはポリシーに従って選択します。このケースは、たとえば、優先されたロケーターを非難するICMPエラーメッセージが到着した場合に発生する可能性がありますが、ピアはまだ新しい優先ロケーターを示していません。
4. If the new Preferred locator has DEPRECATED status and there is at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new Preferred locator and continues. If the selected address is UNVERIFIED, the address verification procedure described above will apply.
4. 新しい優先ロケーターのステータスが非推奨されており、少なくとも1つの非抑制アドレスがある場合、ホストは新しい優先ロケーターとして非削除されたアドレスの1つを選択し、継続します。選択したアドレスが未確認の場合、上記のアドレス検証手順が適用されます。
To prevent redirection-based flooding attacks, the use of a Credit-Based Authorization (CBA) approach is mandatory when a host sends data to an UNVERIFIED locator. The following algorithm meets the security considerations for prevention of amplification and time-shifting attacks. Other forms of credit aging, and other values for the CreditAgingFactor and CreditAgingInterval parameters in particular, are for further study, and so are the advanced CBA techniques specified in [CBA-MIPv6].
リダイレクトベースの洪水攻撃を防ぐために、ホストが未検証のロケーターにデータを送信する場合、クレジットベースの認可（CBA）アプローチの使用が必須です。次のアルゴリズムは、増幅およびタイムシフト攻撃の防止に関するセキュリティ上の考慮事項を満たしています。クレジットエイジングの他の形態、および特に信用ングファクターおよびクレジットングインターバルパラメーターのその他の価値は、さらなる研究のためであり、[CBA-MIPV6]で指定された高度なCBA技術も同様です。
A host maintains a "credit counter" for each of its peers. Whenever a packet arrives from a peer, the host SHOULD increase that peer's credit counter by the size of the received packet. When the host has a packet to be sent to the peer, and when the peer's Preferred locator is listed as UNVERIFIED and no alternative locator with status ACTIVE is available, the host checks whether it can send the packet to the UNVERIFIED locator. The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. If the credit counter is too low, the packet MUST be discarded or buffered until address verification succeeds. When a packet is sent to a peer at an UNVERIFIED locator, the peer's credit counter MUST be reduced by the size of the packet. The peer's credit counter is not affected by packets that the host sends to an ACTIVE locator of that peer.
ホストは、各ピアの「クレジットカウンター」を維持します。パケットがピアから到着するたびに、ホストは受信したパケットのサイズによってピアのクレジットカウンターを増やす必要があります。ホストがピアに送信するパケットを持っている場合、およびピアの優先ロケーターが未検証のものとしてリストされ、ステータスがアクティブな代替ロケーターが利用できない場合、ホストは未検証のロケーターにパケットを送信できるかどうかを確認します。クレジットカウンターの値がアウトバウンドパケットのサイズよりも高い場合は、パケットを送信する必要があります。クレジットカウンターが低すぎる場合、住所の確認が成功するまで、パケットを破棄またはバッファリングする必要があります。パケットが未確認のロケーターでピアに送信される場合、ピアのクレジットカウンターはパケットのサイズによって縮小する必要があります。ピアのクレジットカウンターは、ホストがそのピアのアクティブなロケーターに送信するパケットの影響を受けません。
Figure 14 depicts the actions taken by the host when a packet is received. Figure 15 shows the decision chain in the event a packet is sent.
図14は、パケットが受信されたときにホストが取ったアクションを示しています。図15は、パケットが送信された場合の決定チェーンを示しています。
Inbound
packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
Figure 14: Receiving Packets with Credit-Based Authorization
図14：クレジットベースの承認を伴うパケットの受信
Outbound
packet
| _________________
| / \ +---------------+
| / Is the preferred \ No | Send packet |
+-----> | destination address |-------------> | to preferred |
\ UNVERIFIED? / | address |
\_________________/ +---------------+
|
| Yes
|
v
_________________
/ \ +---------------+
/ Does an ACTIVE \ Yes | Send packet |
| destination address |-------------> | to ACTIVE |
\ exist? / | address |
\_________________/ +---------------+
|
| No
|
v
_________________
/ \ +---------------+
/ Credit counter \ No | |
| >= |-------------> | Drop packet |
\ packet size? / | |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
Figure 15: Sending Packets with Credit-Based Authorization
図15：クレジットベースの承認を伴うパケットの送信
A host ensures that the credit counters it maintains for its peers gradually decrease over time. Such "credit aging" prevents a malicious peer from building up credit at a very slow speed and using this, all at once, for a severe burst of redirected packets.
ホストは、同僚が時間とともに徐々に減少するために維持するクレジットカウンターを保証します。このような「クレジットエイジング」は、悪意のあるピアが非常に遅い速度でクレジットを構築することを防ぎ、これを一度に使用して、リダイレクトされたパケットの重度のバーストを使用します。
Credit aging may be implemented by multiplying credit counters with a factor, CreditAgingFactor (a fractional value less than one), in fixed time intervals of CreditAgingInterval length. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to ensure that a host can send packets to an address in state UNVERIFIED even when the peer sends at a lower rate than the host itself. When CreditAgingFactor or CreditAgingInterval are too small, the peer's credit counter might be too low to continue sending packets until address verification concludes.
クレジットエイジングは、クレジットカウンターを係数、CreditagingFactor（1未満の分数値）に、信用ングインターバル長の固定時間間隔で乗算することにより実装できます。CreditagingFactorおよびCreditagingIntervalの適切な値を選択することは、ホストがホスト自体よりも低いレートで送信した場合でも、ホストが未検証の住所にパケットを送信できるようにするために重要です。CreditagingFactorまたはCreditagingIntervalが小さすぎる場合、Peerのクレジットカウンターが低すぎて、住所の確認が終わるまでパケットを送信し続けることができない場合があります。
The parameter values proposed in this document are as follows:
このドキュメントで提案されているパラメーター値は次のとおりです。
CreditAgingFactor 7/8 CreditAgingInterval 5 seconds
CreditagingFactor 7/8 CreditagingInterval 5秒
These parameter values work well when the host transfers a file to the peer via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds. Alternative credit-aging algorithms may use other parameter values or different parameters, which may even be dynamically established.
これらのパラメーター値は、ホストがTCP接続を介してファイルをピアに転送し、エンドツーエンドの往復時間が500ミリ秒を超えない場合にうまく機能します。代替クレジット老化アルゴリズムは、他のパラメーター値または異なるパラメーターを使用する場合がありますが、これは動的に確立される場合があります。
The HIP mobility mechanism provides a secure means of updating a host's IP address via HIP UPDATE packets. Upon receipt, a HIP host cryptographically verifies the sender of an UPDATE, so forging or replaying a HIP UPDATE packet is very difficult (see [RFC5201]). Therefore, security issues reside in other attack domains. The two we consider are malicious redirection of legitimate connections as well as redirection-based flooding attacks using this protocol. This can be broken down into the following:
HIPモビリティメカニズムは、HIPアップデートパケットを介してホストのIPアドレスを更新する安全な手段を提供します。受領時に、股関節ホストは更新の送信者を暗号化するため、股関節更新パケットを鍛造または再生することは非常に困難です（[RFC5201]を参照）。したがって、セキュリティの問題は他の攻撃ドメインにあります。私たちが考慮する2つは、このプロトコルを使用して、合法的な接続の悪意のあるリダイレクトとリダイレクトベースの洪水攻撃です。これは、次のように分類できます。
Impersonation attacks
なりすまし攻撃
- direct conversation with the misled victim
- 誤った犠牲者との直接の会話
- man-in-the-middle attack
- 中間攻撃
DoS attacks
DOS攻撃
- flooding attacks (== bandwidth-exhaustion attacks)
- 洪水攻撃（==帯域幅排除攻撃）
* tool 1: direct flooding
* ツール1：直接洪水
* tool 2: flooding by zombies
* ツール2：ゾンビによる洪水
* tool 3: redirection-based flooding
* ツール3：リダイレクトベースの洪水
- memory-exhaustion attacks
- メモリ排除攻撃
- computational-exhaustion attacks
- 計算排除攻撃
We consider these in more detail in the following sections.
これらについては、次のセクションでより詳細に検討します。
In Section 6.1 and Section 6.2, we assume that all users are using HIP. In Section 6.3 we consider the security ramifications when we have both HIP and non-HIP users. Security considerations for Credit-Based Authorization are discussed in [SIMPLE-CBA].
セクション6.1およびセクション6.2では、すべてのユーザーが股関節を使用していると想定しています。セクション6.3では、股関節ユーザーと非ヒップユーザーの両方がいる場合、セキュリティの影響を検討します。クレジットベースの承認に関するセキュリティ上の考慮事項は、[Simple-CBA]で議論されています。
An attacker wishing to impersonate another host will try to mislead its victim into directly communicating with them, or carry out a man-in-the-middle (MitM) attack between the victim and the victim's desired communication peer. Without mobility support, both attack types are possible only if the attacker resides on the routing path between its victim and the victim's desired communication peer, or if the attacker tricks its victim into initiating the connection over an incorrect routing path (e.g., by acting as a router or using spoofed DNS entries).
別のホストになりすましたい攻撃者は、被害者と直接コミュニケーションをとることを誤解させようとするか、被害者と被害者の希望するコミュニケーションピアの間で中間（MITM）攻撃を実行しようとします。モビリティサポートがなければ、両方の攻撃タイプは、攻撃者が被害者と被害者の希望するコミュニケーションピアの間のルーティングパスにある場合にのみ可能です。攻撃者が被害者をだまして、誤ったルーティングパスでの接続を開始するようにします（例えば、ルーターまたはスプーフィングされたDNSエントリを使用）。
The HIP extensions defined in this specification change the situation in that they introduce an ability to redirect a connection (like IPv6), both before and after establishment. If no precautionary measures are taken, an attacker could misuse the redirection feature to impersonate a victim's peer from any arbitrary location. The authentication and authorization mechanisms of the HIP base exchange [RFC5201] and the signatures in the UPDATE message prevent this attack. Furthermore, ownership of a HIP association is securely linked to a HIP HI/HIT. If an attacker somehow uses a bug in the implementation or weakness in some protocol to redirect a HIP connection, the original owner can always reclaim their connection (they can always prove ownership of the private key associated with their public HI).
この仕様で定義されている股関節拡張機能は、施設の前後で接続（IPv6など）をリダイレクトする能力を導入するという点で状況を変更します。予防措置が講じられていない場合、攻撃者はリダイレクト機能を誤用して、任意の場所から被害者の仲間になりすましている可能性があります。股関節ベース交換[RFC5201]の認証と承認メカニズムと更新メッセージの署名は、この攻撃を防ぎます。さらに、股関節関連の所有権は、股関節HI/ヒットに安全にリンクされています。攻撃者が何らかの形でいくつかのプロトコルの実装または弱点を使用して股関節接続をリダイレクトする場合、元の所有者はいつでも接続を取り戻すことができます（彼らは常に公共のHIに関連する秘密鍵の所有権を証明できます）。
MitM attacks are always possible if the attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once the opportunistic base exchange has taken place, even a MitM cannot steal the HIP connection anymore because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a legitimate update. UPDATE packets use HMAC and are signed. Even when an attacker can snoop packets to obtain the SPI and HIT/HI, they still cannot forge an UPDATE packet without knowledge of the secret keys.
最初の股関節ベース交換中に攻撃者が存在し、ホストが互いのアイデンティティを認証しない場合、MITM攻撃は常に可能です。ただし、日和見的な基本交換が行われると、攻撃者が正当な更新として受け入れられる更新パケット（または股関節パケット）を作成することは非常に困難であるため、MITMでさえ股関節接続を盗むことができなくなりました。更新パケットはHMACを使用し、署名されています。攻撃者がSPIを取得してヒット/HIを取得してパケットをスヌープできる場合でも、秘密のキーの知識なしに更新パケットを偽造することはできません。
The purpose of a denial-of-service attack is to exhaust some resource of the victim such that the victim ceases to operate correctly. A denial-of-service attack can aim at the victim's network attachment (flooding attack), its memory, or its processing capacity. In a flooding attack, the attacker causes an excessive number of bogus or unwanted packets to be sent to the victim, which fills their available bandwidth. Note that the victim does not necessarily need to be a node; it can also be an entire network. The attack basically functions the same way in either case.
サービス拒否攻撃の目的は、被害者が正しく動作しなくなるように、被害者のリソースを使い果たすことです。サービス拒否攻撃は、被害者のネットワークアタッチメント（洪水攻撃）、その記憶、またはその処理能力を目指します。洪水攻撃では、攻撃者は過度の数の偽または不要なパケットを被害者に送信し、利用可能な帯域幅を埋めます。被害者は必ずしもノードである必要はないことに注意してください。また、ネットワーク全体にすることもできます。攻撃は基本的にどちらの場合でも同じように機能します。
An effective DoS strategy is distributed denial of service (DDoS). Here, the attacker conventionally distributes some viral software to as many nodes as possible. Under the control of the attacker, the infected nodes, or "zombies", jointly send packets to the victim. With such an 'army', an attacker can take down even very high bandwidth networks/victims.
効果的なDOS戦略は、サービス拒否（DDOS）の分散です。ここでは、攻撃者は通常、いくつかのウイルスソフトウェアをできるだけ多くのノードに配布しています。攻撃者の制御下で、感染したノード、または「ゾンビ」は、パケットを被害者に共同で送信します。このような「軍隊」では、攻撃者は非常に高い帯域幅ネットワーク/被害者でさえも倒すことができます。
With the ability to redirect connections, an attacker could realize a DDoS attack without having to distribute viral code. Here, the attacker initiates a large download from a server, and subsequently redirects this download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and credit-based authorization. Both strategies do not eliminate flooding attacks per se, but they preclude: (i) their use from a location off the path towards the flooded victim; and (ii) any amplification in the number and size of the redirected packets. As a result, the combination of a reachability check and credit-based authorization lowers a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim.
接続をリダイレクトする機能により、攻撃者はウイルスコードを配布することなくDDOS攻撃を実現できます。ここで、攻撃者はサーバーからの大規模なダウンロードを開始し、その後、このダウンロードを被害者にリダイレクトします。攻撃者は、複数のサーバーでこれを繰り返すことができます。この脅威は、到達可能性チェックとクレジットベースの承認を通じて緩和されます。どちらの戦略もそれ自体が洪水攻撃を排除しませんが、次のことを排除します。（ii）リダイレクトされたパケットの数とサイズの増幅。その結果、到達可能性チェックとクレジットベースの承認の組み合わせにより、股関節リダイレクトベースの洪水攻撃は、攻撃者自体が洪水トラフィックを被害者に送信する直接的な洪水攻撃のレベルに低下します。
We now consider whether or not the proposed extensions to HIP add any new DoS attacks (consideration of DoS attacks using the base HIP exchange and updates is discussed in [RFC5201]). A simple attack is to send many UPDATE packets containing many IP addresses that are not flagged as preferred. The attacker continues to send such packets until the number of IP addresses associated with the attacker's HI crashes the system. Therefore, there SHOULD be a limit to the number of IP addresses that can be associated with any HI. Other forms of memory/computationally exhausting attacks via the HIP UPDATE packet are handled in the base HIP document [RFC5201].
ここで、ヒップの提案された拡張が新しいDOS攻撃を追加するかどうかを検討します（[RFC5201]で基本股関節交換と更新を使用したDOS攻撃の考慮事項について説明します）。簡単な攻撃は、好まれているとフラグが付けられていない多くのIPアドレスを含む多くの更新パケットを送信することです。攻撃者は、攻撃者のHIに関連するIPアドレスの数がシステムをクラッシュさせるまで、そのようなパケットを送信し続けます。したがって、HIに関連付けることができるIPアドレスの数には制限があるはずです。HIPアップデートパケットを介した他の形式のメモリ/計算的に消耗する攻撃は、ベースヒップドキュメント[RFC5201]で処理されます。
A central server that has to deal with a large number of mobile clients may consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections.
多数のモバイルクライアントに対処しなければならない中央サーバーは、SA寿命を増やして更新を再キーニングする速度を遅くしたり、Cookieの難しさを増やして攻撃指向の接続率を遅くしたりすることを検討する場合があります。
We now assume an environment with both HIP and non-HIP aware hosts. Four cases exist.
現在、股関節と非人権の両方のホストを持つ環境を想定しています。4つのケースが存在します。
1. A HIP host redirects its connection onto a non-HIP host. The non-HIP host will drop the reachability packet, so this is not a threat unless the HIP host is a MitM that could somehow respond successfully to the reachability check.
1. HIPホストは、接続を非Hostにリダイレクトします。非ヒップホストは到達可能性パケットをドロップするため、股関節ホストが到達可能性チェックに何らかの形で正常に対応できるMITMでない限り、これは脅威ではありません。
2. A non-HIP host attempts to redirect their connection onto a HIP host. This falls into IPv4 and IPv6 security concerns, which are outside the scope of this document.
2. 非ヒップホストは、接続を股関節ホストにリダイレクトしようとします。これは、このドキュメントの範囲外であるIPv4およびIPv6セキュリティの懸念に該当します。
3. A non-HIP host attempts to steal a HIP host's session (assume that Secure Neighbor Discovery is not active for the following). The non-HIP host contacts the service that a HIP host has a connection with and then attempts to change its IP address to steal the HIP host's connection. What will happen in this case is implementation dependent but such a request should fail by being ignored or dropped. Even if the attack were successful, the HIP host could reclaim its connection via HIP.
3. 非ヒップホストは、股関節ホストのセッションを盗もうとします（以下については、安全な近隣発見がアクティブではないと仮定します）。非ヒップホストは、股関節ホストが接続しているサービスに連絡し、その後、IPアドレスを変更して股関節ホストの接続を盗もうとします。この場合に起こることは実装依存ですが、そのような要求は無視または削除されて失敗するはずです。攻撃が成功したとしても、股関節ホストは股関節を介して接続を取り戻すことができました。
4. A HIP host attempts to steal a non-HIP host's session. A HIP host could spoof the non-HIP host's IP address during the base exchange or set the non-HIP host's IP address as its preferred address via an UPDATE. Other possibilities exist, but a simple solution is to prevent the use of HIP address check information to influence non-HIP sessions.
4. ヒップホストは、非人権ホストのセッションを盗もうとします。股関節ホストは、ベースエクスチェンジ中にヒップホストのIPアドレスをスプーフィングしたり、更新を介して希望のアドレスとして非ヒップホストのIPアドレスを設定することができます。他の可能性は存在しますが、簡単な解決策は、ヒップアドレスチェック情報を使用して非ヒップセッションに影響を与えることです。
This document defines a LOCATOR parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 4 with a Type of 193.
このドキュメントは、ホストIDプロトコル[RFC5201]のロケーターパラメーターを定義します。このパラメーターは、セクション4で193のタイプで定義されています。
This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type as defined in the Host Identity Protocol specification [RFC5201]. This parameter is defined in Section 5.3 with a value of 46.
このドキュメントは、ホストIDプロトコル仕様[RFC5201]で定義されているLocator_type_unsupported Notifyメッセージタイプも定義します。このパラメーターは、値46のセクション5.3で定義されています。
Pekka Nikander and Jari Arkko originated this document, and Christian Vogt and Thomas Henderson (editor) later joined as co-authors. Greg Perkins contributed the initial draft of the security section. Petri Jokela was a co-author of the initial individual submission.
Pekka NikanderとJari Arkkoがこの文書を生み出し、Christian VogtとThomas Henderson（編集者）が後に共著者として加わりました。グレッグパーキンスは、セキュリティセクションの最初のドラフトに貢献しました。Petri Jokelaは、最初の個人提出の共著者でした。
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document.
著者は、Miika Komu、Mika Kousa、Jeff Ahrenholz、およびJan Melenに、文書の多くの改善に感謝します。
[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月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[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月。
[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月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the ESP Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202] Jokela、P.、Moskowitz、R。、およびP. Nikander、「Host Identity Protocol（HIP）でESP輸送形式を使用」、RFC 5202、2008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204] Laganier、J。およびL. Eggert、「ホストIDプロトコル（HIP）Rendezvous Extension」、RFC 5204、2008年4月。
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Work in Progress, February 2005.
[CBA-MIPV6] Vogt、C。およびJ. Arkko、「モバイルIPv6の早期バインディングアップデートのクレジットベースの承認」、2005年2月、進行中の作業。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", Work in Progress, February 2006.
[Simple-CBA] Vogt、C。およびJ. Arkko、「同時到達可能性検証のためのクレジットベースの承認」、2006年2月の作業。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Pekka Nikander Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Thomas R. Henderson (editor) The Boeing Company P.O. Box 3707 Seattle, WA USA
トーマスR.ヘンダーソン（編集者）ボーイングカンパニーP.O.ボックス3707シアトル、ワシントンアメリカ
EMail: thomas.r.henderson@boeing.com
Christian Vogt Ericsson Research NomadicLab Hirsalantie 11 JORVAS FIN-02420 FINLAND
クリスチャンフォッグエリクソン研究nomadiclab hirsalantie 11 jorvas fin-02420フィンランド
Phone: EMail: christian.vogt@ericsson.com
電話：電子メール：Christian.vogt@ericsson.com
Jari Arkko Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Jari Arkko Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
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への情報をお問い合わせください。