[要約] RFC 8046は、ホストの移動をサポートするためのホスト識別プロトコル（HIP）に関するものです。このRFCの目的は、ホストの移動を効率的かつセキュアに行うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) T. Henderson, Ed.
Request for Comments: 8046 University of Washington
Obsoletes: 5206 C. Vogt
Category: Standards Track Independent
ISSN: 2070-1721 J. Arkko
Ericsson
February 2017
Host Mobility with the Host Identity Protocol
ホストアイデンティティプロトコルを使用したホストモビリティ
Abstract
概要
This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" 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 how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC 5206.
このドキュメントでは、ホストアイデンティティプロトコル（HIP）のモビリティ拡張を定義します。具体的には、このドキュメントは、HIPホストがピアに到達する可能性のある代替アドレスについてピアに通知できるようにするHIPメッセージの「LOCATOR_SET」パラメータを定義します。このドキュメントでは、片方または両方のピアホストが使用するIPアドレスの変更全体で通信を維持するために、パラメーターを使用する方法も定義しています。同じLOCATOR_SETパラメータを使用して、エンドホストマルチホーミングをサポートすることもできます（RFC 8047で指定）。このドキュメントはRFC 5206を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8046.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8046で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Operating Environment . . . . . . . . . . . . . . . . . . 7
3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 9
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 10
3.2.2. Mobility with a Single SA Pair (Mobile-Initiated
Rekey) . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Mobility Messaging through the Rendezvous Server . . 13
3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 14
3.3. Other Considerations . . . . . . . . . . . . . . . . . . 14
3.3.1. Address Verification . . . . . . . . . . . . . . . . 14
3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 15
3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 16
4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 16
4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 18
4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 19
4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 19
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Locator Data Structure and Status . . . . . . . . . . . . 19
5.2. Sending the LOCATOR_SET . . . . . . . . . . . . . . . . . 21
5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 22
5.4. Verifying Address Reachability . . . . . . . . . . . . . 24
5.5. Changing the Preferred Locator . . . . . . . . . . . . . 26
5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 26
5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 27
5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 30
6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 31
6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 31
6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 32
6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 32
6.4. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Differences from RFC 5206 . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
The Host Identity Protocol (HIP) [RFC7401] 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 needs to 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.
Host Identity Protocol（HIP）[RFC7401]は、IPアドレスの代わりに公開/秘密鍵のペアをホストとして使用することにより、トランスポート層（TCP、UDPなど）をインターネットワーキング層（IPv4およびIPv6）から切り離すアーキテクチャをサポートしますアイデンティティ。ホストがHIPを使用する場合、上位のプロトコルサブレイヤー（トランスポートレイヤーソケットやカプセル化セキュリティペイロード（ESP）セキュリティアソシエーション（SA）など）は、これらのホストIDの表現にバインドされ、IPアドレスはパケット転送にのみ使用されます。ただし、各ホストは、そのピアが到達可能な少なくとも1つのIPアドレスも知っている必要があります。最初は、これらのIPアドレスはHIPベース交換中に使用されるものです。
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 host mobility, leaving more complicated mobility scenarios, multihoming, and other variations for further study. More specifically, the following are in scope:
このような分離の1つの結果は、ネットワーク層のモビリティとホストのマルチホーミングに対する新しいソリューションが可能になることです。可能性のあるモビリティとマルチホーミングには、潜在的に多くのバリエーションがあります。このドキュメントの範囲には、基本的なネットワークレベルのホストモビリティのメッセージングおよび手順の要素が含まれ、さらに複雑なモビリティシナリオ、マルチホーミング、およびその他のバリエーションがさらに調査されます。具体的には、以下が対象になります。
This document defines a LOCATOR_SET parameter for use in HIP messages. The LOCATOR_SET parameter allows a HIP host to notify a peer about alternate locators at which it is reachable. The locators may be merely IP addresses, or they may have additional multiplexing and demultiplexing context to aid with 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.
このドキュメントでは、HIPメッセージで使用するLOCATOR_SETパラメータを定義します。 LOCATOR_SETパラメーターを使用すると、HIPホストは、到達可能な代替ロケーターについてピアに通知できます。ロケーターは単なるIPアドレスの場合もあれば、下位層でのパケット処理を支援するための追加の多重化および逆多重化コンテキストがある場合もあります。たとえば、特定のアドレスの正しいSAでパケットが送信されるように、IPアドレスをESPセキュリティパラメータインデックス（SPI）とペアにする必要がある場合があります。
This document also specifies the messaging and elements of procedure for end-host mobility of a HIP host. In particular, message flows to enable successful host mobility, including address verification methods, are defined herein.
このドキュメントでは、HIPホストのエンドホストモビリティの手順とメッセージングについても説明しています。特に、アドレス検証方法を含む、成功したホストモビリティを可能にするメッセージフローがここで定義されます。
The HIP rendezvous server (RVS) [RFC8004] can be used to manage simultaneous mobility of both hosts, initial reachability of a mobile host, location privacy, and some modes of NAT traversal. Use of the HIP RVS to manage the simultaneous mobility of both hosts is specified herein.
HIPランデブーサーバー（RVS）[RFC8004]を使用して、両方のホストの同時モビリティ、モバイルホストの初期到達可能性、ロケーションプライバシー、およびNATトラバーサルのいくつかのモードを管理できます。ここでは、両方のホストの同時モビリティを管理するためのHIP RVSの使用について説明します。
The following topics are out of scope:
次のトピックは範囲外です。
While the same LOCATOR_SET parameter supports host multihoming (simultaneous use of a number of addresses), procedures for host multihoming are out of scope and are specified in [RFC8047].
同じLOCATOR_SETパラメータはホストマルチホーミング（多数のアドレスの同時使用）をサポートしますが、ホストマルチホーミングの手順は範囲外であり、[RFC8047]で指定されています。
While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study.
HIPはESPトランスポートフォーマット[RFC7402]以外のトランスポートで使用できる可能性がありますが、このドキュメントでは主にESPの使用を想定しており、他のトランスポートフォーマットは今後の研究に残します。
We 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.
最後に、基になるIPモビリティをトランスポート層に対して透過的にすることは、トランスポート輻輳制御、パスMTU選択、およびサービス品質（QoS）の適切な応答に影響を与えます。トランスポート層モビリティトリガー、およびHIPモビリティまたはマルチホーミングアドレス変更に対する適切なトランスポート応答は、このドキュメントの範囲外です。
The main sections of this document are organized as follows. Section 3 provides a summary overview of operations, scenarios, and other considerations. Section 4 specifies the messaging parameter syntax. Section 5 specifies the processing rules for messages. Section 6 describes security considerations for this specification.
このドキュメントの主要なセクションは、次のように構成されています。セクション3では、操作、シナリオ、およびその他の考慮事項の概要を示します。セクション4では、メッセージングパラメータの構文を指定します。セクション5では、メッセージの処理ルールを指定します。セクション6では、この仕様のセキュリティに関する考慮事項について説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
LOCATOR_SET. A HIP parameter containing zero or more Locator fields.
LOCATOR_SET。 0個以上のロケーターフィールドを含むHIPパラメーター。
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フローラベルを含めることも、単にネットワークアドレスにすることもできます。
Locator. When capitalized in the middle of a sentence, this term refers to the encoding of a locator within the LOCATOR_SET parameter (i.e., the 'Locator' field of the parameter).
ロケータ。文の途中で大文字にすると、この用語はLOCATOR_SETパラメータ内のロケータのエンコーディング（つまり、パラメータの「ロケータ」フィールド）を指します。
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. Certain locators are labeled as preferred when a host advertises its locator set to its peer. By default, the locators used in the HIP base exchange are the preferred locators. The use of preferred locators, including the scenario where multiple address scopes and families may be in use, is defined more in [RFC8047] than in this document.
優先ロケータ。ホストがデータの受信を希望するロケーター。ホストがロケーターセットをピアにアドバタイズすると、特定のロケーターが優先としてラベル付けされます。デフォルトでは、HIPベース交換で使用されるロケーターが優先ロケーターです。複数のアドレススコープとファミリが使用されているシナリオを含む、優先ロケータの使用は、このドキュメントよりも[RFC8047]で定義されています。
Credit-Based Authorization (CBA). A mechanism allowing a host to send a certain amount of data to a peer's newly announced locator before the result of mandatory address verification is known.
信用ベースの承認（CBA）。必須のアドレス検証の結果がわかる前に、ホストが特定の量のデータをピアの新しく発表されたロケータに送信できるようにするメカニズム。
This section is an overview; a more detailed specification follows this section.
このセクションは概要です。より詳細な仕様はこのセクションの後に続きます。
HIP [RFC7401] is a key establishment and parameter negotiation protocol. Its primary applications are for authenticating host messages based on host identities and establishing SAs for the ESP transport format [RFC7402] and possibly other protocols in the future.
HIP [RFC7401]は、主要な確立およびパラメータネゴシエーションプロトコルです。その主なアプリケーションは、ホストIDに基づいてホストメッセージを認証し、ESPトランスポートフォーマット[RFC7402]と将来的には他のプロトコルのSAを確立することです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP Deployment Model
図1：HIP配置モデル
The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies an extension to HIP to enable end-host mobility. 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 (HI). This document specifies the format of this new addressing (LOCATOR_SET) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism.
エンドツーエンドでの運用を想定した、HIPの一般的な展開モデルを上記に示します。このドキュメントでは、エンドホストモビリティを有効にするためのHIPの拡張について説明します。要約すると、HIPベースプロトコルへのこれらの拡張により、HIPメッセージでピアへの新しいアドレス指定情報のシグナリングが可能になります。メッセージは、ホストID（HI）に基づいた署名またはキー付きハッシュメッセージ認証コード（HMAC）によって認証されます。このドキュメントでは、この新しいアドレス指定（LOCATOR_SET）パラメーターの形式、このパラメーターを送信および処理して基本的なホストモビリティを有効にする手順、および同時アドレス検証メカニズムの手順について説明します。
---------
| 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 Host Mobility and Multihoming
図2：HIPホストモビリティとマルチホーミングのアーキテクチャ
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" corresponds to the function that manages the bindings at the ESP and HIP sublayers for mobility (specified in this document) and multihoming (specified in [RFC8047]).
図2は、ESPトランスポート形式を使用したHIP対応スタックの階層化されたアーキテクチャのビューを示しています。 HIPでは、上位層プロトコル（この図のTCPとESPを含む）はIPアドレスではなくホストアイデンティティタグ（HIT）にバインドされます。 HIPサブレイヤーは、HITとIPアドレス間のバインディングの維持を担当します。 SPIは、着信パケットを適切なHITに関連付けるために使用されます。 「MH」というラベルの付いたブロックは、モビリティ（このドキュメントで指定）とマルチホーミング（[RFC8047]で指定）のESPおよびHIPサブレイヤーでバインディングを管理する機能に対応しています。
Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC7401]. 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.
最初に、基本プロトコル仕様[RFC7401]で指定されているように、モビリティまたはマルチホーミングがない場合を検討してください。 HIPベース交換は、ホスト間で使用されるHIT、ESPに使用するSPI、およびIPアドレス（HIPシグナリングパケットとESPデータパケットの両方で使用）を確立します。特定のパケットの送信方向には、そのようなバインディングのセットが1つだけ存在することに注意してください。HIPレイヤーでのバインディングに使用されるフィールドは、ESP（SPIおよびHIT）によって公開されるフィールドのみです。インバウンド方向の場合、適切なホストコンテキストを見つけるために必要なのはSPIだけです。 ESPキー再生成イベントは、HITペアとSPI間のマッピングを変更しますが、IPアドレスは変更しません。
Consider next a mobility event, in which a host moves to another IP address. Two things need to occur in this case. First, the peer needs to be notified of the address change using a HIP UPDATE message. Second, each host needs to 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. Although internal notification of transport-layer protocols regarding the path change (e.g., to reset congestion control variables) may be desired, this specification does not address such internal notification. In addition, elements of procedure for traversing network address translators (NATs) and firewalls, including NATs and firewalls that may understand HIP, may complicate the above basic scenario and are not covered by this document.
次に、ホストが別のIPアドレスに移動するモビリティイベントについて考えます。この場合、2つのことが発生する必要があります。まず、HIP UPDATEメッセージを使用して、ピアにアドレスの変更を通知する必要があります。次に、各ホストは、HIPサブレイヤーでローカルバインディングを変更する必要があります（新しいIPアドレス）。 SPIとIPアドレスの両方が1回のUPDATEで同時に変更された可能性があります。ここで説明するプロトコルはこれをサポートしています。パスの変更に関するトランスポート層プロトコルの内部通知（輻輳制御変数をリセットするなど）が必要な場合がありますが、この仕様では、このような内部通知は扱いません。さらに、ネットワークアドレストランスレータ（NAT）およびファイアウォール（HIPを理解する可能性のあるNATおよびファイアウォールを含む）を通過する手順の要素は、上記の基本的なシナリオを複雑にする可能性があり、このドキュメントでは扱いません。
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 a 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_SET parameter is defined in Section 4.
このドキュメントは、「ロケーター」と呼ばれる住所の一般化を定義しています。ロケーターはネットワークへの接続ポイントを指定しますが、スタックの論理HIPサブレイヤーの下でのパケットの処理方法に影響を与える追加のエンドツーエンドトンネリングまたはホストごとの逆多重化コンテキストを含めることもできます。 HIPの下でパケットを処理する方法を説明するにはIPアドレスだけでは不十分な場合があるため、この一般化は有用です。たとえば、ホストマルチホーミングコンテキストでは、ESPアンチリプレイウィンドウへの違反を回避するために、特定のIPアドレスを特定のESP SPIに関連付ける必要がある場合があります。特定のトンネリングシナリオでは、アドレスがトランスポートポートに関連付けられる場合もあります。ロケーターは、単に従来のネットワークアドレスである場合があります。 LOCATOR_SETパラメータのロケータフィールドの形式は、セクション4で定義されています。
When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a single LOCATOR_SET parameter and a single ESP_INFO 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 specification [RFC7401]. The peer can authenticate the contents of the UPDATE packet based on the signature and keyed hash of the packet.
ホストが別のアドレスに移動すると、単一のLOCATOR_SETパラメータと単一のESP_INFOパラメータを含むHIP UPDATEパケットを送信することにより、ピアに新しいアドレスを通知します。このUPDATEパケットはピアによって承認されます。パケット損失がある場合の信頼性のために、UPDATEパケットはHIP仕様[RFC7401]で定義されているように再送信されます。ピアは、署名とパケットのキー付きハッシュに基づいて、UPDATEパケットの内容を認証できます。
When using the ESP transport format [RFC7402], 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 [RFC7401] and ESP extension [RFC7402].
ESPトランスポートフォーマット[RFC7402]を使用する場合、ホストは同時に、セキュリティアソシエーションのキーを再設定し、場合によっては新しいDiffie-Hellmanキーを生成することがあります。これらのアクションはすべて、基本プロトコル仕様[RFC7401]およびESP拡張[RFC7402]で定義されているように、UPDATEパケットに追加のパラメーターを含めることによってトリガーされます。
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（および将来的には他のトランスポートモード）を使用する場合、ホストは、HIPで作成されたESP SAを使用して保護されたパケットを任意のアドレスから受信できます。したがって、ホストはIPアドレスを変更し、必ずしもキーを再生成することなく、ピアにパケットを送信し続けることができます。ただし、ピアは、送信ホストに関連付けられているアドレスのセットを確実かつ安全に更新する前に、これらの新しいアドレスにパケットを送信できません。さらに、モビリティは、リオーダーが発生し、パケットがSAのESPアンチリプレイウィンドウの外に落ちるようにパス特性を変更する可能性があるため、鍵の再生成が必要になります。
In this section, we briefly introduce a number of usage scenarios for HIP host mobility. These scenarios assume that HIP is being used with the ESP transform [RFC7402], 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 specification [RFC7401] and with the use of ESP with HIP [RFC7402]. According to these specifications, the data traffic in a HIP session is protected with ESP, and the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Sections 4 and 5.
このセクションでは、HIPホストモビリティの多くの使用シナリオを簡単に紹介します。これらのシナリオは、ESP変換[RFC7402]でHIPが使用されていることを前提としていますが、将来的には他のシナリオも定義される可能性があります。これらの使用シナリオを理解するには、読者はHIP仕様[RFC7401]と、ESPとHIP [RFC7402]の使用について少なくとも最小限の知識が必要です。これらの仕様によれば、HIPセッションのデータトラフィックはESPで保護され、ESP SPIは正しいホスト間コンテキストへのインデックスとして機能します。仕様の詳細は、セクション4および5で後ほど説明します。
The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Therefore, both of the hosts 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つのHIPベース交換を完了していると想定しています。したがって、両方のホストに1つの着信SAと1つの発信SAがあります。さらに、各SAは、ベース交換で使用されるものと同じIPアドレスのペアを使用します。
The readdressing protocol is an asymmetric protocol where a mobile 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. In support of mobility, the LOCATOR_SET parameter is carried in UPDATE packets.
再アドレス指定プロトコルは非対称プロトコルであり、モバイルホストは影響を受けるSPIのIPアドレスの変更についてピアホストに通知します。再アドレス指定交換は、既存のHIP交換に便乗するように設計されています。モビリティをサポートするために、LOCATOR_SETパラメータはUPDATEパケットで伝送されます。
The scenarios below at times describe addresses as being in either an ACTIVE, UNVERIFIED, or DEPRECATED state. From the perspective of a host, newly learned addresses of the peer need to 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.
以下のシナリオでは、アドレスがACTIVE、UNVERIFIED、またはDEPRECATEDのいずれかの状態であると説明される場合があります。ホストの観点からは、ピアの新しく学習されたアドレスをアクティブサービスに入れる前に確認する必要があり、ピアによって削除されたアドレスは非推奨の状態になります。以下に説明する制限された条件（セクション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_SET parameter.
リンクローカルアドレスをHIPハンドシェイクのソースアドレスとして使用するホストは、モバイルピアから到達できない場合があります。このようなホストは、初期ハンドシェイクで、またはLOCATOR_SETパラメータを介して、グローバルにルーティング可能なアドレスを提供する必要があります（SHOULD）。
A mobile host sometimes needs to 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 needs to inform its peers about the new IP address. This first example considers the case in which the mobile host has only one interface, one IP address in use within the HIP session, a single pair of SAs (one inbound, one outbound), and no rekeying occurring on the SAs. We also assume that the new IP addresses are within the same address family (IPv4 or IPv6) as the previous address. This is the simplest scenario, depicted in Figure 3. Note that the conventions for message parameter notations in figures (use of parentheses and brackets) is defined in Section 2.2 of [RFC7401].
モバイルホストは、インターフェイスにバインドされているIPアドレスを変更する必要がある場合があります。リンクでアドバタイズされたIPv6プレフィックスの変更、再接続されたPPPリンク、新しいDHCPリース、または別のサブネットへの実際の移動により、IPアドレスの変更が必要になる場合があります。通信コンテキストを維持するために、ホストはピアに新しいIPアドレスを通知する必要があります。この最初の例では、モバイルホストのインターフェイスが1つだけで、HIPセッション内で使用されているIPアドレスが1つ、SAのペアが1つ（1つは受信、1つは送信）で、SAでキーの再生成が行われない場合を考えます。また、新しいIPアドレスは、以前のアドレスと同じアドレスファミリ（IPv4またはIPv6）内にあると想定しています。これは、図3に示す最も単純なシナリオです。図のメッセージパラメータ表記の規則（括弧と括弧の使用）は、[RFC7401]のセクション2.2で定義されています。
Mobile Host Peer Host
モバイルホストピアホスト
UPDATE(ESP_INFO, LOCATOR_SET, 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 may be disconnected from the peer host for a brief period of time while it switches from one IP address to another; this case is sometimes referred to in the literature as a "break-before-make" case. The host may also obtain its new IP address before losing the old one ("make-before-break" case). In either case, upon obtaining a new IP address, the mobile host sends a LOCATOR_SET 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, both the OLD SPI and NEW SPI parameters 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 firewalls on the path ([RFC5207] specifies some such firewall scenarios in which the HIP-aware firewall may want to associate ESP flows to host identities). The LOCATOR_SET parameter contains the new IP address (embedded in a Locator Type of "1", defined below) and a lifetime associated with the locator. The mobile host waits for this UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401].
1. モバイルホストは、あるIPアドレスから別のIPアドレスに切り替わる間、ピアホストから短時間切断されることがあります。このケースは、文献では「ブレークビフォアメイク」ケースと呼ばれることがあります。ホストは、古いIPアドレスを失う前に新しいIPアドレスを取得することもあります（「make-before-break」の場合）。どちらの場合も、新しいIPアドレスを取得すると、モバイルホストはUPDATEメッセージでLOCATOR_SETパラメータをピアホストに送信します。 UPDATEメッセージには、セキュリティアソシエーションの新旧のSPIの値を含むESP_INFOパラメータも含まれています。この場合、OLD SPIパラメーターとNEW SPIパラメーターの両方が、既存の着信SPIの値に設定されます。このESP_INFOはキー再生成イベントをトリガーしませんが、代わりに、パス上の可能なパラメーター検査ファイアウォールに含まれます（[RFC5207]は、HIP対応ファイアウォールがESPフローをホストIDに関連付けることを望む可能性があるいくつかのファイアウォールシナリオを指定します）。 LOCATOR_SETパラメーターには、新しいIPアドレス（ロケータータイプ "1"に埋め込まれ、以下で定義）とロケーターに関連付けられた有効期間が含まれます。モバイルホストは、基本仕様[RFC7401]で指定されているように、このUPDATEが確認されるまで待機し、必要に応じて再送信します。
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 both the OLD SPI and NEW SPI parameters set to the value of the preexisting incoming SPI and sends this UPDATE (with piggybacked acknowledgment) to the mobile host at its new address. This UPDATE also acknowledges the mobile host's UPDATE that triggered the exchange. The peer host waits for its UPDATE to be acknowledged, and retransmits if necessary, as specified in the base specification [RFC7401]. 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. ピアホストはUPDATEを受信してそれを検証し、HIPアソシエーションとモバイルホストの宛先アドレス間のローカルバインディングを更新します。ピアホストは、モバイルホストに返信されるUPDATEメッセージのECHO_REQUESTパラメータにナンスを配置することにより、アドレス検証を実行する必要があります。また、OLD SPIパラメータとNEW SPIパラメータの両方が既存の着信SPIの値に設定されたESP_INFOパラメータも含まれており、このUPDATE（ピギーバックされた確認応答付き）を新しいアドレスのモバイルホストに送信します。このUPDATEは、交換をトリガーしたモバイルホストのUPDATEも確認します。ピアホストは、基本仕様[RFC7401]で指定されているように、UPDATEが確認されるまで待機し、必要に応じて再送信します。ピアは新しいアドレスをすぐに使用できますが、アドレス検証が完了するまで、アドレスに送信するデータの量を制限する必要があります。
3. The mobile host completes the readdress by processing the UPDATE ACK and echoing the nonce in an ECHO_RESPONSE, containing the ACK of the peer's UPDATE. This UPDATE is not protected by a retransmission timer because it does not contain a SEQ parameter requesting acknowledgment. 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. モバイルホストは、UPDATE ACKを処理し、ピアのUPDATEのACKを含むECHO_RESPONSEにナンスをエコーすることによって、再アドレス指定を完了します。このUPDATEには確認応答を要求するSEQパラメーターが含まれていないため、このUPDATEは再送信タイマーによって保護されません。ピアホストがこの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.
ピアホストが新しいアドレスを確認している間、新しいアドレスは（暫定的に）UNVERIFIEDとしてマークされ、古いアドレスは非推奨です。ピアホストがUPDATEチャレンジに対する正しい応答を受信すると、新しいアドレスをアクティブとしてマークし、古いアドレスを削除します。
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.
モバイルホストは、ピアに新しいアドレスを通知すると同時に、SAのキーを再生成することを決定できます。この場合、図3で説明した上記の手順が少し変更されています。モバイルホストから送信されるUPDATEメッセージには、以前のSPIに設定されたOLD SPI、着信SAに必要な新しいSPI値に設定されたNEW SPI、および必要なKEYMATインデックスを含むESP_INFOが含まれます。オプションで、ホストに新しいDiffie-HellmanキーのDIFFIE_HELLMANパラメータを含めることができます。ピアは、HIPキー再生成で通常行われるように、キー再生成の要求を完了します。ただし、上記のようにUPDATE nonceチャレンジが受信されるまで、新しいアドレスはUNVERIFIEDとして保持されます。図4は、このシナリオを示しています。
Mobile Host Peer Host
モバイルホストピアホスト
UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 4: Readdress with Mobile-Initiated Rekey
図4：モバイル開始のキー再生成による再アドレス指定
Section 6.11 of [RFC7401] specifies procedures for sending HIP UPDATE packets. The UPDATE packets are protected by a timer subject to exponential backoff and resent UPDATE_RETRY_MAX times. It may be, however, that the peer is itself in the process of moving when the local host is trying to update the IP address bindings of the HIP association. This is sometimes called the "double-jump" mobility problem; each host's UPDATE packets are simultaneously sent to a stale address of the peer, and the hosts are no longer reachable from one another.
[RFC7401]のセクション6.11は、HIP UPDATEパケットの送信手順を指定しています。 UPDATEパケットは、指数バックオフの影響を受け、UPDATE_RETRY_MAX回再送信されるタイマーによって保護されます。ただし、ローカルホストがHIPアソシエーションのIPアドレスバインディングを更新しようとしているときに、ピア自体が移動中である可能性があります。これは「ダブルジャンプ」モビリティ問題と呼ばれることもあります。各ホストのUPDATEパケットは同時にピアの古いアドレスに送信され、ホストは相互に到達できなくなります。
The HIP Rendezvous Extension [RFC8004] specifies a rendezvous service that permits the I1 packet from the base exchange to be relayed from a stable or well-known public IP address location to the current IP address of the host. It is possible to support double-jump mobility with this rendezvous service if the following extensions to the specifications of [RFC8004] and [RFC7401] are followed.
HIP Rendezvous Extension [RFC8004]は、ベース交換からのI1パケットが安定した、または既知のパブリックIPアドレスの場所からホストの現在のIPアドレスに中継されるようにするランデブーサービスを指定します。 [RFC8004]と[RFC7401]の仕様に対する以下の拡張に従うと、このランデブーサービスでダブルジャンプモビリティをサポートできます。
1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, MAY resend the UPDATE to an RVS of the peer, if such a server is known. The host MAY try the RVS of the peer up to UPDATE_RETRY_MAX times as specified in [RFC7401]. The host MAY try to use the peer's RVS before it has tried UPDATE_RETRY_MAX times to the last working address (i.e., the RVS MAY be tried in parallel with retries to the last working address). The aggressiveness of a host replicating its UPDATEs to multiple destinations, to try candidates in parallel instead of serially, is a policy choice outside of this specification.
1. ピアにUPDATEを送信し、ACKを受信していないモバイルホストは、そのようなサーバーが既知である場合、ピアのRVSにUPDATEを再送信できます。ホストは、[RFC7401]で指定されているように、UPDATE_RETRY_MAX回までピアのRVSを試行できます（MAY）。ホストは、最後の作業アドレスに対してUPDATE_RETRY_MAX回試行する前に、ピアのRVSを使用しようとする可能性があります（つまり、RVSは、最後の作業アドレスへの再試行と並行して試行できます）。ホストが複数の宛先にUPDATEを複製する積極性、つまり候補を逐次ではなく並列に試行することは、この仕様の範囲外のポリシーの選択です。
2. An RVS supporting the UPDATE forwarding extensions specified herein MUST modify the UPDATE in the same manner as it modifies the I1 packet before forwarding. Specifically, it MUST rewrite the IP header source and destination addresses, recompute the IP header checksum, and include the FROM and RVS_HMAC parameters.
2. ここで指定されたUPDATE転送拡張機能をサポートするRVSは、転送前にI1パケットを変更するのと同じ方法でUPDATEを変更する必要があります。具体的には、IPヘッダーの送信元アドレスと宛先アドレスを書き換え、IPヘッダーチェックサムを再計算し、FROMパラメーターとRVS_HMACパラメーターを含める必要があります。
3. A host receiving an UPDATE packet MUST be prepared to process the FROM and RVS_HMAC parameters and MUST include a VIA_RVS parameter in the UPDATE reply that contains the ACK of the UPDATE SEQ.
3. UPDATEパケットを受信するホストは、FROMパラメータとRVS_HMACパラメータを処理する準備をしておく必要があり、UPDATE応答のACKを含むVIA_RVSパラメータをUPDATE応答に含める必要があります。
4. An Initiator receiving a VIA_RVS in the UPDATE reply should initiate address reachability tests (described later in this document) towards the end host's address and not towards the address included in the VIA_RVS.
4. UPDATE応答でVIA_RVSを受信したイニシエーターは、VIA_RVSに含まれているアドレスではなく、エンドホストのアドレスに対してアドレス到達可能性テスト（このドキュメントで後述）を開始する必要があります。
This scenario requires that hosts using RVSs also take steps to update their current address bindings with their RVS upon a mobility event. [RFC8004] does not specify how to update the RVS with a client host's new address. Section 3.2 of [RFC8003] describes how a host may send a REG_REQUEST in either an I2 packet (if there is no active association) or an UPDATE packet (if such association exists). According to procedures described in [RFC8003], if a mobile host has an active registration, it may use mobility updates specified herein, within the context of that association, to readdress the association.
このシナリオでは、RVSを使用するホストも、モビリティイベント時にRVSで現在のアドレスバインディングを更新する手順を実行する必要があります。 [RFC8004]は、クライアントホストの新しいアドレスでRVSを更新する方法を指定していません。 [RFC8003]のセクション3.2は、ホストがI2パケット（アクティブな関連付けがない場合）またはUPDATEパケット（そのような関連付けが存在する場合）でREG_REQUESTを送信する方法を説明しています。 [RFC8003]で説明されている手順に従って、モバイルホストにアクティブな登録がある場合、その関連付けのコンテキスト内で、ここに指定されているモビリティ更新を使用して、関連付けのアドレスを再設定できます。
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, and procedures described herein also apply to notify a peer of a changed address.
IPv6ネットワークは、ほとんどのIPv4ネットワークよりもはるかに頻繁に番号が付け替えられることが予想されます。エンドホストの観点からは、ネットワークの再番号付けはモビリティに似ており、ここで説明する手順は、変更されたアドレスをピアに通知する場合にも適用されます。
When a HIP host receives a set of locators from another HIP host in a LOCATOR_SET, 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]. Therefore, the HIP host needs to first check that the peer is reachable at the new address.
HIPホストがLOCATOR_SETで別のHIPホストからロケーターのセットを受信しても、要求されたアドレスで他のホストが実際に到達可能かどうかは必ずしもわかりません。実際、悪意のあるピアホストは、ターゲットアドレスに向けてパケットフラッドを引き起こすために、意図的に偽のアドレスを与えている可能性があります[RFC4225]。したがって、HIPホストは、ピアが新しいアドレスで到達可能であることを最初に確認する必要があります。
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. More details are found in Section 5.4 of this document.
チャレンジャーが推測不可能な情報を新しいアドレスに送信し、レスポンダーからの新しいアドレスでの情報の受信を示す確認を待つことにより、アドレス検証が実装されます。これには、ナンスの交換または新しいSPIの生成、および新しいSPIに到着するデータの観測が含まれる場合があります。詳細については、このドキュメントのセクション5.4を参照してください。
An additional potential benefit of performing address verification is to allow NATs and firewalls in the network along the new path to obtain the peer host's inbound SPI.
アドレス検証を実行することのさらなる潜在的な利点は、新しいパスに沿ったネットワーク内のNATおよびファイアウォールがピアホストのインバウンドSPIを取得できるようにすることです。
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, CBA 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.
これに基づいて、CBAは悪意のあるパケットのリダイレクトを排除するのではなく、増幅を防ぎます。これは、ピアが最近受信したデータによって、ホストがピアの未検証のアドレスに送信できるデータを制限することで実現されます。したがって、リダイレクトベースのフラッディング攻撃は、たとえば、攻撃者自身が被害者に偽のパケットを送信する純粋な直接フラッディングよりも魅力が少なくなります。
Figure 5 illustrates CBA: 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 5 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks.
図5は、CBAを示しています。ホストBは、ピアAから最近受信したデータの量を測定し、Aが再アドレス指定すると、パケットサイズの合計が測定された受信データ量を超えない限り、パケットをAの新しい未検証アドレスに送信します。クレジットが不足すると、BはAへのパケットの送信をAのアドレスがアクティブになるまで停止します。アドレスの変更は、モビリティ、マルチホーミング、またはその他の理由が原因である可能性があります。図5には、タイムシフト攻撃の可能性を抑えるメカニズムであるクレジットエージングの結果（セクション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 5: Readdressing Scenario
図5：シナリオの再アドレス指定
This document does not specify how to set the credit limit value, but the goal is to allow data transfers to proceed without much interruption while the new address is verified. A simple heuristic to accomplish this, if the sender knows roughly its round-trip time (RTT) and current sending rate to the host, is to allow enough credit to support maintaining the sending rate for a duration corresponding to two or three RTTs.
このドキュメントでは、クレジット制限値の設定方法を指定していませんが、目標は、新しいアドレスが確認されている間、ほとんど中断することなくデータ転送を続行できるようにすることです。これを達成するための簡単な発見的方法は、送信者がそのラウンドトリップ時間（RTT）と現在のホストへの送信レートをおおよそ知っている場合、2つまたは3つのRTTに対応する期間、送信レートの維持をサポートするのに十分なクレジットを許可することです。
When a host has multiple locators, the peer host needs to 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を参照）。
The LOCATOR_SET parameter has a type number value that is considered to be a "critical parameter" as per the definition in [RFC7401]; such parameter types MUST be recognized and processed by the recipient. The parameter 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 ("P" bit), Locator Lifetime, and a Locator encoding. A LOCATOR_SET containing zero Locator fields is permitted but has the effect of deprecating all addresses.
LOCATOR_SETパラメータには、[RFC7401]の定義に従って「重要なパラメータ」と見なされるタイプ番号値があります。このようなパラメータタイプは、受信者が認識して処理する必要があります。このパラメーターは、標準のHIPパラメーターのTypeフィールドとLengthフィールド、および0個以上のLocatorサブパラメーターで構成されています。各ロケーターサブパラメーターには、トラフィックタイプ、ロケータータイプ、ロケーター長、優先ロケータービット（「P」ビット）、ロケーターライフタイム、およびロケーターエンコーディングが含まれます。ゼロLocatorフィールドを含むLOCATOR_SETは許可されますが、すべてのアドレスを非推奨にする効果があります。
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 6: LOCATOR_SET Parameter Format
図6：LOCATOR_SETパラメータの形式
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.
トラフィックタイプ：ロケーターがHIPシグナリング、ユーザーデータ、またはその両方に関係するかどうかを定義します。
Locator Type: Defines the semantics of the Locator field.
Locator Type：Locatorフィールドのセマンティクスを定義します。
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: Lifetime of the locator, in seconds.
ロケーターのライフタイム：ロケーターのライフタイム（秒単位）。
Locator: The locator whose semantics and encoding are indicated by the Locator Type field. All sub-fields of the Locator field are integral multiples of four octets in length.
ロケーター：セマンティクスとエンコーディングがロケータータイプフィールドで示されるロケーター。 Locatorフィールドのすべてのサブフィールドは、長さが4オクテットの整数倍です。
The Locator Lifetime (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 address scope.
ロケーターの存続期間（lifetime）は、後続のロケーターが有効であると予想される期間を示します。ライフタイムは秒単位で表されます。各ロケーターはゼロ以外の存続期間を持つ必要があります。メッセージの受信から指定された秒数が経過すると、アドレスは非推奨になると予想されます。代替（非推奨）が利用可能であり、十分なアドレススコープがある場合、非推奨アドレスは宛先アドレスとして使用すべきではありません（SHOULD NOT）。
The following Traffic Type values are defined:
次のトラフィックタイプの値が定義されています。
0: Both signaling (HIP control packets) and user data.
0：シグナリング（HIP制御パケット）とユーザーデータの両方。
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 destination locator from the set of active locators.
「P」ビットが設定されている場合、対応するトラフィックタイプにスコープがあります。つまり、たとえば「P」ビットがトラフィックタイプ「2」に設定されている場合、ロケータがデータパケットに適していることを意味します。競合がある場合（たとえば、タイプ「0」のアドレスとタイプ「2」の別のアドレスに「P」ビットが設定されている場合）、より具体的なトラフィックタイプルールが適用されます（この場合、「2」 "）。デフォルトでは、ベース交換で使用されるIPアドレスは、新しい優先ロケーターが優先されない限り、シグナリングとユーザーデータの両方の優先ロケーターです。特定のトラフィックタイプで優先として指定されているロケーターがない場合、実装はアクティブなロケーターのセットから任意の宛先ロケーターを使用できます。
The following Locator Type values are defined, along with the associated semantics of the Locator field:
次のLocator Type値が、Locatorフィールドの関連するセマンティクスとともに定義されています。
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_SET and one ESP_INFO parameter are used in any HIP packet. Any UPDATE packet that includes a LOCATOR_SET parameter SHOULD include both an HMAC and a HIP_SIGNATURE parameter.
UPDATEパケット内のパラメーターの組み合わせは多数可能です（たとえば、セクション3.2を参照）。このドキュメントでは、1つのLOCATOR_SETおよび1つのESP_INFOパラメータが任意のHIPパケットで使用される場合にのみ、手順が定義されています。 LOCATOR_SETパラメータを含むUPDATEパケットには、HMACパラメータとHIP_SIGNATUREパラメータの両方を含める必要があります（SHOULD）。
The UPDATE MAY also include a HOST_ID parameter (which may be useful for HIP-aware firewalls inspecting the HIP messages for the first time). If the UPDATE includes the HOST_ID parameter, the receiving host MUST verify that the HOST_ID corresponds to the HOST_ID that was used to establish the HIP association, and the HIP_SIGNATURE MUST verify with the public key associated with this HOST_ID parameter.
UPDATEには、HOST_IDパラメータも含まれる場合があります（これは、HIP対応ファイアウォールが初めてHIPメッセージを検査するときに役立つ場合があります）。 UPDATEにHOST_IDパラメータが含まれている場合、受信ホストは、HOST_IDがHIPアソシエーションの確立に使用されたHOST_IDに対応していることを確認する必要があり、HIP_SIGNATUREは、このHOST_IDパラメータに関連付けられている公開鍵で確認する必要があります。
The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. This document does not support any elements of procedure for sending more than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE.
アナウンスされたロケータとパケットに存在するESP_INFOパラメータの関係は、セクション5.2で定義されています。このドキュメントは、単一のUPDATEで複数のLOCATOR_SETまたはESP_INFOパラメータを送信するための手順の要素をサポートしていません。
This section describes rules for sending and receiving the LOCATOR_SET parameter, testing address reachability, and using CBA on UNVERIFIED locators.
このセクションでは、LOCATOR_SETパラメーターの送受信、アドレスの到達可能性のテスト、およびUNVERIFIEDロケーターでのCBAの使用に関する規則について説明します。
Each locator announced in a LOCATOR_SET parameter is represented by a piece of state that contains the following data:
LOCATOR_SETパラメーターでアナウンスされる各ロケーターは、次のデータを含む状態の一部によって表されます。
o the actual bit pattern representing the locator, o the lifetime (seconds),
oロケーターを表す実際のビットパターン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_SET parameter:
ステータスは、LOCATOR_SETパラメータに埋め込まれたアドレスの到達可能性を追跡するために使用されます。
UNVERIFIED: indicates that the reachability of the address has not been verified yet,
UNVERIFIED：アドレスの到達可能性がまだ検証されていないことを示します。
ACTIVE: indicates that the reachability of the address has been verified and the address has not been deprecated, and
ACTIVE：アドレスの到達可能性が確認され、アドレスが廃止されていないことを示します。
DEPRECATED: indicates that the locator's lifetime has expired.
DEPRECATED：ロケーターの有効期限が切れていることを示します。
The following state changes are allowed:
次の状態変更が許可されます。
UNVERIFIED to ACTIVE: The reachability procedure completes successfully.
UNVERIFIED to ACTIVE：到達可能性の手順が正常に完了しました。
UNVERIFIED to DEPRECATED: The locator's lifetime expires while the locator is UNVERIFIED.
UNVERIFIED to DEPRECATED：ロケーターがUNVERIFIEDである間、ロケーターの存続期間は期限切れになります。
ACTIVE to DEPRECATED: The locator's 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 needs to be verified again before starting to use it again.
ACTIVEからUNVERIFIEDまで：アドレスにしばらくトラフィックがありません。ローカルポリシーにより、アドレスの到達可能性を再度使用する前に確認する必要があることがローカルポリシーで義務付けられています。
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.
廃止されたアドレスは、その到達可能性を最初に確認することなく、ACTIVEに変更してはなりません。
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.
ロケーターが優先されるかどうかの状態は、ピアから受信されるロケーターサブパラメーターの優先ビットの値と必ずしも同じではないことに注意してください。ピアは特定のロケーターを優先するように推奨する場合がありますが、実際にロケーターを優先ロケーターとして使用するかどうかの決定はローカルな決定であり、ローカルポリシーの影響を受ける可能性があります。
In addition to state maintained about status and remaining lifetime for each locator learned from the peer, an implementation would typically maintain similar state about its own locators that have been offered to the peer.
ピアから学習した各ロケーターのステータスと残りのライフタイムについて維持される状態に加えて、実装は通常、ピアに提供された自身のロケーターについて同様の状態を維持します。
A locator lifetime that is unbounded (does not expire) can be signified by setting the value of the lifetime field to the maximum (unsigned) value.
制限されていない（期限が切れていない）ロケーターの存続時間は、lifetimeフィールドの値を最大（符号なし）値に設定することで指定できます。
Finally, the locators used to establish the HIP association are by default assumed to be the initial preferred locators in ACTIVE state, with an unbounded lifetime.
最後に、HIPアソシエーションを確立するために使用されるロケーターは、デフォルトで、無制限の存続期間を持つ、ACTIVE状態の最初の優先ロケーターであると想定されます。
The decision of when to send the LOCATOR_SET is a local policy issue. However, it is RECOMMENDED that a host send a LOCATOR_SET 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 LOCATOR_SETs that force the peer to change the preferred address SHOULD be avoided.
LOCATOR_SETを送信するタイミングの決定は、ローカルポリシーの問題です。ただし、ホストがアクティブなHIPアソシエーションで使用中のIPアドレスの変更を認識し、その変更が少なくとも数秒間続くと想定する場合は常に、ホストがLOCATOR_SETを送信することをお勧めします。ピアに優先アドレスの変更を強制するLOCATOR_SETをすばやく送信することは避けてください。
The sending of a new LOCATOR_SET parameter replaces the locator information from any previously sent LOCATOR_SET parameter; therefore, if a host sends a new LOCATOR_SET parameter, it needs to continue to include all active locators. Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs.
新しいLOCATOR_SETパラメータを送信すると、以前に送信されたLOCATOR_SETパラメータのロケータ情報が置き換えられます。したがって、ホストが新しいLOCATOR_SETパラメーターを送信する場合、すべてのアクティブなロケーターを引き続き含める必要があります。ホストは、LOCATOR_SETでブロードキャストまたはマルチキャストアドレスをアナウンスしてはなりません（MUST NOT）。
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 cases are possible but are left for further study.
次に、セクション3.2で導入されたいくつかのケースについて説明します。各ロケーターのトラフィックタイプは「0」に設定されていると想定します（トラフィックタイプの他の値は、データプレーントラフィックからHIPコントロールプレーンを分離するドキュメントで指定できます）。他のモビリティケースも可能ですが、さらに調査するために残されています。
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_SET parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR_SET contains a single Locator with a Locator Type of "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 specification [RFC7401]. The UPDATE should be sent to the peer's preferred IP address with an IP source address corresponding to the address in the LOCATOR_SET parameter.
1. マルチホーミングやキー更新のないホストモビリティ。モバイルホストは、単一のLOCATOR_SETパラメータを持つ単一のESP_INFOを含む単一のUPDATEを作成します。 ESP_INFOには、OLD SPIおよびNEW SPIフィールドの両方のSPIの現在の値が含まれています。 LOCATOR_SETには、ロケータータイプが「1」の単一のロケーターが含まれます。 SPIはESP_INFOのSPIと一致する必要があります。優先ビットを設定する必要があり（SHOULD）、「Locator Lifetime」はローカルポリシーに従って設定されます。 UPDATEには、通常どおりSEQパラメータも含まれています。このパケットは、HIP仕様[RFC7401]の定義に従って再送信されます。 UPDATEは、LOCATOR_SETパラメータのアドレスに対応する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_SET parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI, 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_SET contains a single Locator with a 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. マルチホーミングはないが、鍵の再生成が可能なホストモビリティ。モバイルホストは、単一のLOCATOR_SETパラメーター（単一のアドレス）を持つ単一のESP_INFOを含む単一のUPDATEを作成します。 ESP_INFOには、OLD SPIのSPIの現在の値、NEW SPIのSPIの新しい値、およびローカルポリシーで選択されたKEYMATインデックスが含まれています。オプションで、ホストは、DIFFIE_HELLMANパラメータを含めることにより、Diffie-Hellmanキー再生成を開始することを選択できます。 LOCATOR_SETには、ロケータータイプが「1」の単一のロケーターが含まれます。 SPIは、ESP_INFOのNEW SPIのSPIと一致する必要があります。それ以外の場合、手順は、キーの再生成が開始されない場合と同じです。
A host SHOULD be prepared to receive a single LOCATOR_SET parameter in a HIP UPDATE packet. Reception of multiple LOCATOR_SET parameters in a single packet, or in HIP packets other than UPDATE, is outside of the scope of this specification.
ホストは、HIP UPDATEパケットで単一のLOCATOR_SETパラメータを受信できるように準備する必要があります。単一のパケット、またはUPDATE以外のHIPパケットでの複数のLOCATOR_SETパラメータの受信は、この仕様の範囲外です。
Because a host sending the LOCATOR_SET may send the same parameter in different UPDATE messages to different destination addresses, including possibly the RVS of the host, the host receiving the LOCATOR_SET MUST be prepared to handle the possibility of duplicate LOCATOR_SETs sent to more than one of the host's addresses. As a result, the host MUST detect and avoid reprocessing a LOCATOR_SET parameter that is redundant with a LOCATOR_SET parameter that has been recently received and processed.
LOCATOR_SETを送信するホストは、異なるUPDATEメッセージで同じパラメータを異なる宛先アドレス（ホストのRVSを含む可能性がある）に送信する可能性があるため、LOCATOR_SETを受信するホストは、LOCATOR_SETが重複して送信される可能性を処理できるように準備する必要があります。ホストのアドレス。結果として、ホストは、最近受信されて処理されたLOCATOR_SETパラメーターと重複するLOCATOR_SETパラメーターを検出して再処理する必要があります（MUST）。
This document describes sending both ESP_INFO and LOCATOR_SET 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 NATs and firewalls. The LOCATOR_SET parameter contains a complete listing of the locators that the host wishes to make or keep active for the HIP association.
このドキュメントでは、UPDATEでESP_INFOパラメータとLOCATOR_SETパラメータの両方を送信する方法について説明します。 ESP_INFOパラメータは、新しいSPIのキーを再生成またはキー入力する必要がある場合に含まれます。それ以外の場合は、HIP対応のNATおよびファイアウォールの利点のために含まれています。 LOCATOR_SETパラメータには、ホストがHIPアソシエーションのためにアクティブにするか維持したいロケータの完全なリストが含まれています。
In general, the processing of a LOCATOR_SET 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_SET 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.
一般に、LOCATOR_SETの処理は、LOCATOR_SETが含まれるパケットタイプによって異なります。ここでは、ESP_INFOが存在し、単一のLOCATOR_SETおよびESP_INFOがUPDATEメッセージで送信される場合についてのみ説明します。他のケースはさらなる研究のためです。以下の手順は、セクション5.2で説明されている各ケースをカバーしています。
The processing of ESP_INFO and LOCATOR_SET parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host SHOULD first process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Locator Type of "1" will only contain a reference to the new SPI.
ESP_INFOおよびLOCATOR_SETパラメータの処理はモジュール化され、複数のESP_INFOおよび/または複数のLOCATOR_SETパラメータを含めるための将来の一般化をサポートすることを目的としています。 ESH_INFOには既存のSPIにマップされた新しいSPI値が含まれる場合があるため、ホストは最初にLOCATOR_SETの前にESP_INFOを処理する必要があります。一方、ロケータータイプ "1"には新しいSPIへの参照のみが含まれます。
When a host receives a validated HIP UPDATE with a LOCATOR_SET 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 HIP-aware NATs and firewalls. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter:
ホストは、LOCATOR_SETおよびESP_INFOパラメーターを使用して検証済みのHIP UPDATEを受信すると、ESP_INFOを次のように処理します。 ESP_INFOパラメータは、HIP対応のNATとファイアウォールのメリットのために、SAのキーの再生成、作成、非推奨、または識別のみを行うかどうかを示します。ホストは、ESP_INFOパラメータのOLD SPIおよびNEW 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 HIP-aware NATs and firewalls) and no rekeying is necessary.
1. （キーの再生成なし）OLD SPIがNEW SPIと等しく、両方が既存のSPIに対応している場合、ESP_INFOは無償（HIP対応のNATおよびファイアウォールで提供）であり、キー再生成は不要です。
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_SET parameter will reference this new SPI instead of the old SPI.
2. （キーの再生成）OLD SPIが既存のSPIを示しており、NEW SPIがゼロ以外の異なる値である場合、既存のSAはキーが再生成され、ホストはNEWに対応するSPIで新しいアウトバウンドSAを作成することにより、HIP ESPキー再生成手順に従いますSPI。このSPIにバインドされたアドレスはありません。 LOCATOR_SETパラメータのロケータは、古い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）OLD SPI値がゼロであり、NEW SPIがゼロ以外の新しい値である場合、ピアによって新しいSAが要求されています。この場合も、キー再生成イベントのように扱われます。受信側ホストは新しいSAを作成し、UPDATE 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の非推奨）OLD SPIが既存のSPIを示し、NEW SPIがゼロの場合、SAは非推奨になり、SPIに一意にバインドされたすべてのロケーターはDEPRECATED状態になります。
If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped.
上記のいずれにも当てはまらない場合は、プロトコルエラーが発生しているため、UPDATEの処理は停止しています。
Next, the locators in the LOCATOR_SET parameter are processed. For each locator listed in the LOCATOR_SET 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.
次に、LOCATOR_SETパラメーターのロケーターが処理されます。 LOCATOR_SETパラメーターにリストされているロケーターごとに、そのアドレスが有効なユニキャストまたはエニーキャストアドレスであることを確認します。つまり、アドレスはブロードキャストまたはマルチキャストアドレスであってはなりません。ホスト自体がHIPを実行することが許可される場合があるため、一部の実装はローカルホストを示すアドレスを受け入れる場合があります。
The below assumes that all Locators are of Type "1" with a Traffic Type of "0"; other cases are for further study.
以下では、すべてのロケーターのタイプが「1」で、トラフィックタイプが「0」であると想定しています。他のケースはさらなる研究のためです。
For each Type "1" address listed in the LOCATOR_SET 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_SET parameter as DEPRECATED.
LOCATOR_SETパラメータにリストされている各タイプ「1」アドレスについて、ホストは、アドレスが指定されたSPIにすでにバインドされているかどうかを確認します。アドレスが既にバインドされている場合、その存続期間は更新されます。アドレスのステータスがDEPRECATEDの場合、ステータスはUNVERIFIEDに変更されます。アドレスがまだバインドされていない場合、アドレスが追加され、そのステータスはUNVERIFIEDに設定されます。 LOCATOR_SETパラメータにリストされていないSPIに対応するすべてのアドレスを非推奨としてマークします。
As a result, at the end of processing, the addresses listed in the LOCATOR_SET parameter have a state of either UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR_SET parameter have a state of DEPRECATED.
その結果、処理の終わりに、LOCATOR_SETパラメーターにリストされているアドレスの状態はUNVERIFIEDまたはACTIVEになり、LOCATOR_SETパラメーターにリストされていない古いSAの古いアドレスの状態はDEPRECATEDになります。
Once the host has processed the locators, if the LOCATOR_SET parameter contains a new preferred locator, the host SHOULD initiate a change of the preferred locator. This requires that the host first verify reachability of the associated address, and only then change the preferred locator; see Section 5.5.
ホストがロケーターを処理した後、LOCATOR_SETパラメーターに新しい優先ロケーターが含まれている場合、ホストは優先ロケーターの変更を開始する必要があります（SHOULD）。これには、ホストが関連付けられたアドレスの到達可能性を最初に確認してから、優先ロケーターを変更する必要があります。セクション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_SET parameter.
ホストがサポートされていないロケータータイプのロケーターを受信し、そのようなロケーターがピアの優先ロケーターであると宣言されている場合、ホストは、通知メッセージタイプがLOCATOR_TYPE_UNSUPPORTEDのNOTIFYエラーを送信し、通知データフィールドにレシーバーが処理に失敗したロケーター。それ以外の場合、サポートされていないロケータータイプの（推奨されない）ロケーターがLOCATOR_SETパラメーターで受信された場合、ホストはNOTIFYエラーを送信できます（MAY）。
A host MAY add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the LOCATOR_SET.
ホストは、ピアのLOCATOR_SETにリストされていない場合でも、受信したHIPパケットのソースIPアドレスをピアの候補ロケーターとして追加できますが、LOCATOR_SETに明示的にリストされているロケーターを優先する必要があります（SHOULD）。
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 an 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. A typical verification that is protected by retransmission timers is to include an ECHO REQUEST within an UPDATE sent to the new address.
ホストは、未確認のアドレスの到達可能性を確認する必要があります。新しく学習されたアドレスのステータスは、新しいアドレスが新しい優先ロケータとしてR1パケットでアドバタイズされない限り、最初は未確認に設定する必要があります。ホストは、しばらくしてから再度アクティブアドレスの到達可能性を確認することもできます。その場合、ホストはアドレスのステータスをUNVERIFIEDに設定し、アドレス確認を再開します。再送信タイマーによって保護される一般的な検証は、新しいアドレスに送信されるUPDATE内にECHO REQUESTを含めることです。
A host typically starts the address-verification procedure by sending a nonce to the new address. A host MAY choose from different message exchanges or different nonce values so long as it establishes that the peer has received and replied to the nonce at the new address.
ホストは通常、nonceを新しいアドレスに送信することにより、アドレス検証手順を開始します。ホストは、ピアが新しいアドレスでナンスを受信して応答したことを確認する限り、異なるメッセージ交換または異なるナンス値から選択できます。
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 random 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 for verification but with some other random value. A host MAY also use other message exchanges as confirmation of the address reachability.
たとえば、ホストがそのSPIを変更し、ESP_INFOをピアに送信している場合、NEW SPI値はランダムである必要があり（SHOULD）、ランダム値はキー更新UPDATEで送信されたECHO_REQUESTにコピーされる場合があります（MAY）。ただし、ホストがSPIを変更していない場合でも、検証にはECHO_REQUESTパラメータを使用できますが、その他のランダムな値を使用する場合があります。ホストは、アドレス到達可能性の確認として他のメッセージ交換も使用できます（MAY）。
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 7, 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.
場合によっては、HIPパケットによる確認を待つのではなく、図7に示すように、新しくアドバタイズされたSAへのデータの到着を暗黙のアドレス到達可能性検証として使用するだけで十分な場合があります。この場合、アドレス到達可能性チェックの一部として新しいSPIをアドバタイズするホストは、新しいSAでトラフィックを受信する準備ができている必要があります。
Mobile Host Peer Host
モバイルホストピアホスト
UPDATE(ESP_INFO, LOCATOR_SET, ...)
---------------------------------->
prepare incoming SA
UPDATE(ESP_INFO, ...) with new SPI
<-----------------------------------
switch to new outgoing SA
data on new SA
----------------------------------->
mark address ACTIVE
UPDATE(ACK, ECHO_RESPONSE) later arrives
----------------------------------->
Figure 7: Address Activation via Use of a New SA
図7：新しい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 CBA permits. CBA is explained in Section 5.6. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE.
新しい優先ロケーターのアドレス検証が進行中の場合、ホストは、そのロケーターが使用可能な場合、ACTIVEとしてリストされている別のロケーターを選択して、アドレス検証が完了するまで通信を継続する必要があります（SHOULD）。あるいは、ホストは、CBAが許可する範囲でUNVERIFIEDステータスにある間、新しい優先ロケーターを使用してもよい（MAY）。 CBAについては、セクション5.6で説明します。住所の検証が成功すると、新しい優先ロケーターのステータスがACTIVEに変わります。
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_SET parameter that has the "P" bit set.
ホストは、たとえば現在使用されている優先アドレスが到達不能になった可能性があることをトラフィック情報またはICMPエラーメッセージが示すためなど、さまざまな理由で優先送信ロケーターを変更する必要があります。別の理由として、「P」ビットが設定されたLOCATOR_SETパラメータを受け取ったことが考えられます。
To change the preferred locator, the host initiates the following procedure:
優先ロケーターを変更するには、ホストは次の手順を開始します。
1. If the new preferred locator has an ACTIVE status, the preferred locator is changed and the procedure succeeds.
1. 新しい優先ロケーターのステータスがACTIVEの場合、優先ロケーターが変更され、手順は成功します。
2. If the new preferred locator has an 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 CBA permits. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE, and its use is no longer governed by CBA.
2. 新しい優先ロケーターのステータスがUNVERIFIEDの場合、ホストは到達可能性の検証を開始します。ホストは、そのようなロケーターが1つでも利用できる場合にアドレス検証が完了するまで、ACTIVEとしてリストされている別のロケーターを使用する必要があります（SHOULD）。または、ホストは、CBAが許可する範囲で、未確認のステータスであっても、新しい優先ロケーターを使用する場合があります。アドレス検証が成功すると、新しい優先ロケーターのステータスがACTIVEに変わり、その使用はCBAによって管理されなくなります。
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 local 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 a 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 CBA approach MUST be used when a host sends data to an UNVERIFIED locator. The following algorithm addresses 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アプローチの使用を使用する必要があります。次のアルゴリズムは、増幅攻撃とタイムシフト攻撃を防ぐためのセキュリティの考慮事項に対処します。他の形式のクレジットエージング、特にCreditAgingFactorおよびCreditAgingIntervalパラメータのその他の値は、今後の検討課題であり、[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.
ホストは、各ピアの「クレジットカウンター」を維持します。パケットがピアから到着するたびに、ホストは受信したパケットのサイズだけそのピアのクレジットカウンターを増やす必要があります（SHOULD）。ホストにピアに送信するパケットがあり、ピアの優先ロケータがUNVERIFIEDとしてリストされていて、ステータスがACTIVEの代替ロケータが利用できない場合、ホストはパケットをUNVERIFIEDロケータに送信できるかどうかを確認します。クレジットカウンターの値が送信パケットのサイズよりも大きい場合、パケットを送信する必要があります（SHOULD）。クレジットカウンターが低すぎる場合は、アドレスの検証が成功するまで、パケットを破棄またはバッファリングする必要があります。パケットがUNVERIFIEDロケーターのピアに送信されるとき、ピアのクレジットカウンターはパケットのサイズによって減らされなければなりません（MUST）。ピアのクレジットカウンターは、ホストがそのピアのアクティブロケーターに送信するパケットの影響を受けません。
Figure 8 depicts the actions taken by the host when a packet is received. Figure 9 shows the decision chain in the event a packet is sent.
図8は、パケットを受信したときにホストが実行するアクションを示しています。図9は、パケットが送信された場合の決定チェーンを示しています。
Inbound
Packet
|
| +----------------+ +---------------+
| | Increase | | Deliver |
+-----> | credit counter |-------------> | packet to |
| by packet size | | application |
+----------------+ +---------------+
Figure 8: Receiving Packets with Credit-Based Authorization
図8：クレジットベースの認証でパケットを受信する
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
_________________
/ \ +---------------+
/ Is credit counter \ No | |
| >= |-------------> | Drop or |
\ packet size? / | buffer packet |
\_________________/ +---------------+
|
| Yes
|
v
+---------------+ +---------------+
| Reduce credit | | Send packet |
| counter by |----------------> | to preferred |
| packet size | | address |
+---------------+ +---------------+
Figure 9: Sending Packets with Credit-Based Authorization
図9：クレジットベースの承認を使用したパケットの送信
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.
クレジットエージングは、CreditAgingInterval長の固定時間間隔で、クレジットカウンターに係数CreditAgingFactor（1未満の小数値）を乗算することで実装できます。ピアがホスト自体よりも低いレートで送信する場合でも、ホストがUNVERIFIED状態のアドレスにパケットを送信できるようにするには、CreditAgingFactorおよびCreditAgingIntervalに適切な値を選択することが重要です。 CreditAgingFactorまたはCreditAgingIntervalが小さすぎる場合、ピアのクレジットカウンターが小さすぎて、アドレスの検証が完了するまでパケットの送信を続行できない可能性があります。
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 [RFC7401]). 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 UPDATEパケットを介してホストのIPアドレスを更新する安全な手段を提供します。受信すると、HIPホストはUPDATEの送信者を暗号で検証するため、HIP UPDATEパケットの偽造や再生は非常に困難です（[RFC7401]を参照）。したがって、セキュリティの問題は他の攻撃ドメインに存在します。私たちが検討する2つは、正当な接続の悪意のあるリダイレクトと、このプロトコルを使用したリダイレクトベースのフラッディング攻撃です。これは次のように分類できます。
1) Impersonation attacks
1）なりすまし攻撃
- direct conversation with the misled victim
- 騙された被害者との直接会話
- man-in-the-middle (MitM) attack
- 中間者（MitM）攻撃
2) Denial-of-service (DoS) attacks
2）サービス拒否（DoS）攻撃
- flooding attacks (== bandwidth-exhaustion attacks)
- フラッディング攻撃（==帯域幅枯渇攻撃）
* tool 1: direct flooding
* ツール1：直接洪水
* tool 2: flooding by botnets
* ツール2：ボットネットによるフラッディング
* tool 3: redirection-based flooding
* ツール3：リダイレクトベースのフラッディング
- memory-exhaustion attacks
- メモリ枯渇攻撃
- computational-exhaustion attacks
- 計算枯渇攻撃
3) Privacy concerns
3）プライバシーの懸念
We consider these in more detail in the following sections.
これらについては、次のセクションで詳しく説明します。
In Sections 6.1 and 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 hosts.
セクション6.1および6.2では、すべてのユーザーがHIPを使用していると想定しています。セクション6.3では、HIPホストと非HIPホストの両方がある場合のセキュリティの影響について検討します。
An attacker wishing to impersonate another host will try to mislead its victim into directly communicating with them or carry out a MitM attack between the victim and the victim's desired communication peer. Without mobility support, such attacks 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, both before and after establishment. If no precautionary measures are taken, an attacker could potentially misuse the redirection feature to impersonate a victim's peer from any arbitrary location. However, the authentication and authorization mechanisms of the HIP base exchange [RFC7401] 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 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).
この仕様で定義されているHIP拡張機能は、確立前と確立後の両方で接続をリダイレクトする機能を導入するという点で状況を変更します。予防策が講じられていない場合、攻撃者はリダイレクト機能を悪用して、任意の場所から被害者のピアを偽装する可能性があります。ただし、HIPベース交換の認証および承認メカニズム[RFC7401]とUPDATEメッセージの署名により、この攻撃を防ぐことができます。さらに、HIPアソシエーションの所有権はHIP HI / HITに安全にリンクされています。攻撃者が何らかの方法で実装のバグを使用してHIP接続をリダイレクトする場合、元の所有者は常に接続を取り戻すことができます（彼らは常に公開HIに関連付けられた秘密鍵の所有権を証明できます）。
MitM attacks are possible if an on-path attacker is present during the initial HIP base exchange and if the hosts do not authenticate each other's identities. However, once such an opportunistic base exchange has taken place, a MitM attacker that comes later to the path cannot steal the HIP connection 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. Also, replay attacks on the UPDATE packet are prevented as described in [RFC7401].
パス上の攻撃者が最初のHIPベース交換中に存在し、ホストがお互いのIDを認証しない場合、MitM攻撃が可能です。ただし、このような日和見ベースの交換が行われると、パスに後から来るMitM攻撃者は、次のように受け入れられるUPDATEパケット（または任意のHIPパケット）を作成することが非常に難しいため、HIP接続を盗むことができません。正当な更新。 UPDATEパケットはHMACを使用し、署名されています。攻撃者がパケットをスヌープしてSPIおよびHIT / HIを取得できる場合でも、秘密鍵を知らない限り、UPDATEパケットを偽造することはできません。また、[RFC7401]で説明されているように、UPDATEパケットに対するリプレイ攻撃は防止されます。
The purpose of a DoS attack is to exhaust some resource of the victim such that the victim ceases to operate correctly. A DoS 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 functions the same way in either case.
DoS攻撃の目的は、被害者が正常に動作しなくなるように被害者のリソースを使い果たすことです。 DoS攻撃は、被害者のネットワークアタッチメント（フラッディング攻撃）、そのメモリ、またはその処理能力を狙う可能性があります。フラッディング攻撃では、攻撃者は過剰な数の偽のパケットまたは不要なパケットを被害者に送信させ、利用可能な帯域幅をいっぱいにします。犠牲者は必ずしもノードである必要はないことに注意してください。ネットワーク全体にすることもできます。攻撃はどちらの場合でも同じように機能します。
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 (e.g., nodes in a botnet) 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 uses the HIP mobility mechanism to redirect this download to its victim. The attacker can repeat this with multiple servers. This threat is mitigated through reachability checks and CBA. When conducted using HIP, reachability checks can leverage the built-in authentication properties of HIP. They can also prevent redirection-based flooding attacks. However, the delay of such a check can have a noticeable impact on application performance. To reduce the impact of the delay, CBA can be used to send a limited number of packets to the new address while the validity of the IP address is still in question. 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 CBA 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攻撃を実現できます。ここでは、攻撃者はサーバーから大量のダウンロードを開始し、その後HIPモビリティメカニズムを使用してこのダウンロードを被害者にリダイレクトします。攻撃者はこれを複数のサーバーで繰り返すことができます。この脅威は、到達可能性チェックとCBAによって軽減されます。 HIPを使用して実施する場合、到達可能性チェックはHIPの組み込み認証プロパティを利用できます。また、リダイレクトベースのフラッディング攻撃を防ぐこともできます。ただし、このようなチェックの遅延は、アプリケーションのパフォーマンスに顕著な影響を与える可能性があります。遅延の影響を減らすために、CBAを使用して、IPアドレスの有効性がまだ問題である間に、限られた数のパケットを新しいアドレスに送信できます。どちらの戦略も、フラッディング攻撃自体を排除するものではありませんが、次のことを排除します。 （ii）リダイレクトされたパケットの数とサイズの増幅。その結果、到達可能性チェックとCBAの組み合わせにより、HIPリダイレクションベースのフラッディング攻撃は、攻撃者自身がフラッディングトラフィックを被害者に送信する直接的なフラッディング攻撃のレベルまで低下します。
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 [RFC7401]). 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, a HIP association SHOULD limit 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 [RFC7401].
ここで、HIPに提案された拡張機能が新しいDoS攻撃を追加するかどうかを検討します（基本のHIP交換と更新を使用したDoS攻撃については、[RFC7401]で説明されています）。単純な攻撃は、優先フラグが付けられていない多くのIPアドレスを含む多くのUPDATEパケットを送信することです。攻撃者は、攻撃者のHIに関連付けられたIPアドレスの数がシステムをクラッシュさせるまで、そのようなパケットを送信し続けます。したがって、HIPアソシエーションは、任意のHIに関連付けることができるIPアドレスの数を制限する必要があります（SHOULD）。 HIP UPDATEパケットを介した他の形式のメモリ/計算負荷の高い攻撃は、ベースHIPドキュメント[RFC7401]で処理されます。
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のライフタイムを長くしてUPDATEの再キーイングの速度を遅くするか、またはCookieの難易度を上げて攻撃指向の接続の速度を遅くすることを検討できます。
We now assume an environment with hosts that are both HIP and non-HIP aware. Four cases exist:
ここでは、HIPと非HIPの両方を認識するホストを含む環境を想定しています。 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ホストは、その接続を非HIPホストにリダイレクトします。非HIPホストは到達可能性パケットをドロップするため、HIPホストが到達可能性チェックに正常に応答できる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. 非HIPホストは、接続をHIPホストにリダイレクトしようとします。これは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. 非HIPホストがHIPホストのセッションを盗もうとします（次の場合、Secure Neighbor Discoveryがアクティブでないと仮定します）。非HIPホストは、HIPホストが接続しているサービスに接続し、IPアドレスを変更してHIPホストの接続を盗もうとします。この場合に何が起こるかは実装に依存しますが、そのようなリクエストは無視またはドロップされることにより失敗するはずです。攻撃が成功した場合でも、HIPホストはHIPを介して接続を取り戻すことができます。
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 solution is to prevent the local redirection of sessions that were previously using an unverified address, but outside of the existing HIP context, into the HIP SAs until the address change can be verified.
4. HIPホストは、HIP以外のホストのセッションを盗もうとします。 HIPホストは、ベース交換中に非HIPホストのIPアドレスを偽装するか、UPDATEを介して非HIPホストのIPアドレスを優先アドレスとして設定できます。他の可能性もありますが、解決策は、以前は未検証のアドレスを使用していたが、既存のHIPコンテキストの外にあるセッションが、アドレスの変更を確認できるまでHIP SAにローカルにリダイレクトされないようにすることです。
The exposure of a host's IP addresses through HIP mobility extensions may raise privacy concerns. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges. While this issue may be more relevant in a host multihoming scenario in which multiple IP addresses might be exposed [RFC8047], it is worth noting also here that mobility events might cause an implementation to try to inadvertently use a locator that the administrator would rather avoid exposing to the peer host.
HIPモビリティ拡張機能によるホストのIPアドレスの露出は、プライバシーの問題を引き起こす可能性があります。ホストの管理者は、VPNまたはその他の仮想インターフェイスを使用して、ある状況でその場所を隠そうとしている可能性があります。同様のプライバシー問題は、WebRTCなどの他のフレームワークでも発生し、HIPに固有のものではありません。実装は、ホスト管理者が選択したアドレスまたはアドレス範囲の公開をブロックできるようにするメカニズムを提供する必要があります（SHOULD）。この問題は、複数のIPアドレスが公開される可能性があるホストマルチホーミングシナリオ[RFC8047]に関連する可能性がありますが、モビリティイベントが原因で、管理者がロケーターを誤って使用しようとする可能性があることにも注意してください。ピアホストに公開します。
[RFC5206], obsoleted by this document, specified an allocation for a LOCATOR parameter in the "Parameter Types" subregistry of the "Host Identity Protocol (HIP) Parameters" registry, with a type value of 193. IANA has renamed the parameter to "LOCATOR_SET" and has updated the reference from [RFC5206] to this specification.
[RFC5206]はこのドキュメントで廃止され、「ホストIDプロトコル（HIP）パラメータ」レジストリの「パラメータタイプ」サブレジストリでタイプ値193のLOCATORパラメータの割り当てを指定しました。IANAはパラメータの名前を「 LOCATOR_SET」になり、リファレンスを[RFC5206]からこの仕様に更新しました。
[RFC5206], obsoleted by this document, specified an allocation for a LOCATOR_TYPE_UNSUPPORTED type in the "Notify Message Types" registry, with a type value of 46. IANA has updated the reference from [RFC5206] to this specification.
このドキュメントで廃止された[RFC5206]は、LOCATOR_TYPE_UNSUPPORTEDタイプの割り当てをタイプ値46で指定しました。IANAは[RFC5206]からの参照をこの仕様に更新しました。
This section summarizes the technical changes made from [RFC5206]. This section is informational, intended to help implementors of the previous protocol version. If any text in this section contradicts text in other portions of this specification, the text found outside of this section should be considered normative.
このセクションは、[RFC5206]から行われた技術的な変更を要約しています。このセクションは情報提供であり、以前のプロトコルバージョンの実装者を支援することを目的としています。このセクションのテキストがこの仕様の他の部分のテキストと矛盾する場合、このセクションの外にあるテキストは規範的であると見なされます。
This document specifies extensions to the HIP Version 2 protocol, while [RFC5206] specifies extensions to the HIP Version 1 protocol. [RFC7401] documents the differences between these two protocol versions.
このドキュメントは、HIPバージョン2プロトコルの拡張を指定していますが、[RFC5206]は、HIPバージョン1プロトコルの拡張を指定しています。 [RFC7401]には、これら2つのプロトコルバージョンの違いが記載されています。
[RFC5206] included procedures for both HIP host mobility and basic host multihoming. In this document, only host mobility procedures are included; host multihoming procedures are now specified in [RFC8047]. In particular, multihoming-related procedures related to the exposure of multiple locators in the base exchange packets; the transmission, reception, and processing of multiple locators in a single UPDATE packet; handovers across IP address families; and other multihoming-related specifications have been removed.
[RFC5206]には、HIPホストモビリティと基本的なホストマルチホーミングの両方の手順が含まれていました。このドキュメントでは、ホストモビリティ手順のみが含まれています。ホストのマルチホーミング手順は、[RFC8047]で指定されています。特に、ベース交換パケット内の複数のロケーターの公開に関連するマルチホーミング関連の手順。単一のUPDATEパケットでの複数のロケーターの送信、受信、および処理。 IPアドレスファミリ間のハンドオーバー。その他のマルチホーミング関連の仕様は削除されました。
The following additional changes have been made:
以下の追加の変更が行われました。
o The LOCATOR parameter in [RFC5206] has been renamed to LOCATOR_SET.
o [RFC5206]のLOCATORパラメータはLOCATOR_SETに名前が変更されました。
o Specification text regarding the handling of mobility when both hosts change IP addresses at nearly the same time (a "double-jump" mobility scenario) has been added.
o 両方のホストがほぼ同時にIPアドレスを変更する場合のモビリティの処理に関する仕様テキスト（「ダブルジャンプ」モビリティシナリオ）が追加されました。
o Specification text regarding the mobility event in which the host briefly has an active new locator and old locator at the same time (a "make-before-break" mobility scenario) has been added.
o ホストに一時的にアクティブな新しいロケータと古いロケータが同時に存在するモビリティイベントに関する仕様テキスト（「make-before-break」モビリティシナリオ）が追加されました。
o Specification text has been added to note that a host may add the source IP address of a received HIP packet as a candidate locator for the peer even if it is not listed in the peer's LOCATOR_SET, but that it should prefer locators explicitly listed in the LOCATOR_SET.
o ピアのLOCATOR_SETにリストされていない場合でも、ホストが受信したHIPパケットのソースIPアドレスをピアの候補ロケーターとして追加する場合があるが、LOCATOR_SETに明示的にリストされているロケーターを優先する必要があることを示すために、仕様テキストが追加されました。
o This document clarifies that the HOST_ID parameter may be included in UPDATE messages containing LOCATOR_SET parameters, for the possible benefit of HIP-aware firewalls.
o このドキュメントでは、HIP対応ファイアウォールの潜在的な利点のために、HOST_IDパラメータがLOCATOR_SETパラメータを含むUPDATEメッセージに含まれる可能性があることを明確にしています。
o The previous specification mentioned that it may be possible to include multiple LOCATOR_SET and ESP_INFO parameters in an UPDATE. This document only specifies the case of a single LOCATOR_SET and ESP_INFO parameter in an UPDATE.
o 以前の仕様では、UPDATEに複数のLOCATOR_SETおよびESP_INFOパラメータを含めることが可能な場合があると説明されていました。このドキュメントでは、UPDATEで単一のLOCATOR_SETおよびESP_INFOパラメータのケースのみを指定しています。
o The previous specification mentioned that it may be possible to send LOCATOR_SET parameters in packets other than the UPDATE. This document only specifies the use of the UPDATE packet.
o 以前の仕様では、UPDATE以外のパケットでLOCATOR_SETパラメータを送信できる可能性があると述べていました。このドキュメントでは、UPDATEパケットの使用のみを指定しています。
o This document describes a simple heuristic for setting the credit value for CBA.
o このドキュメントでは、CBAのクレジット値を設定するための簡単なヒューリスティックについて説明します。
o This specification mandates that a host must be able to receive and avoid reprocessing redundant LOCATOR_SET parameters that may have been sent in parallel to multiple addresses of the host.
o この仕様では、ホストは、ホストの複数のアドレスに並行して送信された可能性がある冗長なLOCATOR_SETパラメータを受信して再処理する必要があることを義務付けています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R。、編、Heer、T.、Jokela、P。、およびT. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<http ：//www.rfc-editor.org/info/rfc7401>。
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.
[RFC7402] Jokela、P.、Moskowitz、R。、およびJ. Melen、「Using the Encapsulating Security Payload（ESP）Transport Format with the Host Identity Protocol（HIP）」、RFC 7402、DOI 10.17487 / RFC7402、2015年4月、 <http://www.rfc-editor.org/info/rfc7402>。
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8003] Laganier、J。およびL. Eggert、「Host Identity Protocol（HIP）Registration Extension」、RFC 8003、DOI 10.17487 / RFC8003、2016年10月、<http://www.rfc-editor.org/info/rfc8003 >。
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[RFC8004] Laganier、J。およびL. Eggert、「Host Identity Protocol（HIP）Rendezvous Extension」、RFC 8004、DOI 10.17487 / RFC8004、2016年10月、<http://www.rfc-editor.org/info/rfc8004 >。
[CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Work in Progress, draft-vogt-mobopts-credit-based-authorization-00, February 2005.
[CBA-MIPv6] Vogt、C。およびJ. Arkko、「モバイルIPv6アーリーバインディングアップデートのクレジットベースの承認」、Work in Progress、draft-vogt-mobopts-credit-based-authorization-00、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, DOI 10.17487/RFC4225, December 2005, <http://www.rfc-editor.org/info/rfc4225>.
[RFC4225] Nikander、P.、Arkko、J.、Aura、T。、モンテネグロ、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティ設計の背景」、RFC 4225、DOI 10.17487 / RFC4225、2005年12月、<http://www.rfc-editor.org/info/rfc4225>。
[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008, <http://www.rfc-editor.org/info/rfc5206>.
[RFC5206] Nikander、P.、Henderson、T.、Ed。、Vogt、C。、およびJ. Arkko、「End-Host Mobility and Multihoming with the Host Identity Protocol」、RFC 5206、DOI 10.17487 / RFC5206、2008年4月、<http://www.rfc-editor.org/info/rfc5206>。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, DOI 10.17487/RFC5207, April 2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC5207] Stiemerling、M.、Quittek、J。、およびL. Eggert、「ホストアイデンティティプロトコル（HIP）通信のNATおよびファイアウォールトラバーサルの問題」、RFC 5207、DOI 10.17487 / RFC5207、2008年4月、<http：// www.rfc-editor.org/info/rfc5207>。
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", RFC 8047, DOI 10.17487/RFC8047, February 2017, <http://www.rfc-editor.org/info/rfc8047>.
[RFC8047] Henderson、T.、Ed。、Vogt、C。、およびJ. Arkko、「ホストアイデンティティプロトコルによるホストマルチホーミング」、RFC 8047、DOI 10.17487 / RFC8047、2017年2月、<http：//www.rfc -editor.org/info/rfc8047>。
[SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", Work in Progress, draft-vogt-mobopts-simple-cba-00, February 2006.
[SIMPLE-CBA] Vogt、C.およびJ. Arkko、「同時到達可能性検証のためのクレジットベースの承認」、進行中の作業、draft-vogt-mobopts-simple-cba-00、2006年2月。
Acknowledgments
謝辞
Pekka Nikander and Jari Arkko originated this document; Christian Vogt and Thomas Henderson (editor) later joined as coauthors. Greg Perkins contributed the initial text of the security section. Petri Jokela was a coauthor of the initial individual submission.
Pekka NikanderとJari Arkkoがこのドキュメントを作成しました。クリスチャンフォークトとトーマスヘンダーソン（編集者）は後に共著者として加わりました。 Greg Perkinsがセキュリティセクションの最初のテキストを寄稿しました。 Petri Jokelaは、最初の個人提出の共著者でした。
CBA was originally introduced in [SIMPLE-CBA], and portions of this document have been adopted from that earlier document.
CBAは当初[SIMPLE-CBA]で導入され、このドキュメントの一部は以前のドキュメントから採用されています。
The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to the document.
この文書の改善について、著者はJeff Ahrenholz、Baris Boyvat、Rene Hummen、Miika Komu、Mika Kousa、Jan Melen、およびSamu Varjonenに感謝します。
Authors' Addresses
著者のアドレス
Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA United States of America
トーマスR.ヘンダーソン（編集者）ワシントン大学キャンパスボックス352500シアトル、ワシントン州アメリカ合衆国
Email: tomhend@u.washington.edu
Christian Vogt Independent 3473 North First Street San Jose, CA 95134 United States of America
クリスチャンフォークト独立3473 North First Street San Jose、CA 95134アメリカ合衆国
Email: mail@christianvogt.net
Jari Arkko Ericsson Jorvas, FIN-02420 Finland
Jari Arkko Ericsson Jorvas、FIN-02420フィンランド
Phone: +358 40 5079256
Email: jari.arkko@piuha.net