[要約] 要約：RFC 3776は、モバイルノードとホームエージェント間のMobile IPv6シグナリングを保護するためにIPsecを使用する方法について説明しています。目的：このRFCの目的は、Mobile IPv6ネットワークでのセキュリティを向上させるために、IPsecを使用してモバイルノードとホームエージェント間の通信を保護する方法を提案することです。
Network Working Group J. Arkko
Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
IPSECを使用して、モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護する
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6は、IPSECを使用して、ホームエージェントとモバイルノード間の信号を保護します。モバイルIPv6ベースドキュメントは、これらのノードが従わなければならない主な要件を定義します。このドキュメントでは、これらの要件についてより深く説明し、使用されているパケット形式を示し、適切な構成手順を説明し、実装が適切な順序でパケットを処理する方法を示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
This document illustrates the use of IPsec in securing Mobile IPv6 [7] traffic between mobile nodes and home agents. In Mobile IPv6, a mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link.
このドキュメントでは、モバイルIPv6 [7]モバイルノードとホームエージェント間のトラフィックを保護する際のIPSECの使用を示しています。モバイルIPv6では、モバイルノードは、現在自宅のリンクに接続されているか、自宅から離れているかにかかわらず、自宅の住所で常にアドレス指定できると予想されます。「ホームアドレス」は、ホームリンクのホームサブネットプレフィックス内のモバイルノードに割り当てられたIPアドレスです。モバイルノードが自宅にある間、自宅の住所に宛てられたパケットは、モバイルノードのホームリンクにルーティングされます。
While a mobile node is attached to some foreign link away from home, it is also addressable at a care-of address. A care-of address is an IP address associated with a mobile node that has a subnet prefix from a particular foreign link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message.
モバイルノードは自宅から離れた外国のリンクに添付されていますが、住所の世話でもアドレス指定できます。ケアオブアドレスは、特定の外国リンクからサブネットプレフィックスを備えたモバイルノードに関連付けられたIPアドレスです。モバイルノードのホームアドレスとケアオブアドレスとの関連は、モバイルノードの「バインディング」として知られています。自宅から離れている間、モバイルノードはホームリンクにルーターを使用してプライマリケアの住所を登録し、このルーターがモバイルノードの「ホームエージェント」として機能するように要求します。モバイルノードは、ホームエージェントに「バインディングアップデート」メッセージを送信することにより、このバインディング登録を実行します。ホームエージェントは、「拘束力のある承認」メッセージを返すことにより、モバイルノードに返信します。
Any other nodes communicating with a mobile node are referred to as "correspondent nodes". Mobile nodes can provide information about their current location to correspondent nodes, again using Binding Updates and Acknowledgements. Additionally, return routability test is performed between the mobile node, home agent, and the correspondent node in order to authorize the establishment of the binding. Packets between the mobile node and the correspondent node are either tunneled via the home agent, or sent directly if a binding exists in the correspondent node for the current location of the mobile node.
モバイルノードと通信する他のノードは、「特派員ノード」と呼ばれます。モバイルノードは、現在の位置に関する情報を特派員ノードに提供し、再びバインディングの更新と謝辞を使用して提供できます。さらに、バインディングの確立を承認するために、モバイルノード、ホームエージェント、および特派員ノードの間でルーティング可能性テストが実行されます。モバイルノードと特派員ノードの間のパケットは、ホームエージェントを介してトンネル化されるか、モバイルノードの現在の場所の特派員ノードにバインディングが存在する場合は直接送信されます。
Mobile IPv6 tunnels payload packets between the mobile node and the home agent in both directions. This tunneling uses IPv6 encapsulation [6]. Where these tunnels need to be secured, they are replaced by IPsec tunnels [2].
モバイルIPv6トンネルモバイルノードとホームエージェントの間のペイロードパケットの両方向。このトンネルは、IPv6カプセル化を使用します[6]。これらのトンネルを固定する必要がある場合、それらはIpsecトンネルに置き換えられます[2]。
Mobile IPv6 also provides support for the reconfiguration of the home network. Here, the home subnet prefixes may change over time. Mobile nodes can learn new information about home subnet prefixes through the "prefix discovery" mechanism.
モバイルIPv6は、ホームネットワークの再構成をサポートしています。ここでは、ホームサブネットのプレフィックスが時間とともに変化する場合があります。モバイルノードは、「プレフィックスディスカバリー」メカニズムを介してホームサブネットプレフィックスに関する新しい情報を学ぶことができます。
This document discusses security mechanisms for the control traffic between the mobile node and the home agent. If this traffic is not protected, mobile nodes and correspondent nodes are vulnerable to man-in-the-middle, hijacking, passive wiretapping, impersonation, and denial-of-service attacks. Any third parties are also vulnerable to denial-of-service attacks, for instance if an attacker could direct the traffic flowing through the home agent to a innocent third party. These attacks are discussed in more detail in Section 15.1 of the Mobile IPv6 base specification [7].
このドキュメントでは、モバイルノードとホームエージェントの間の制御トラフィックのセキュリティメカニズムについて説明します。このトラフィックが保護されていない場合、モバイルノードと特派員ノードは、中間者、ハイジャック、パッシブ盗聴、なりすまし、およびサービス拒否攻撃に対して脆弱です。また、サードパーティは、攻撃者がホームエージェントを介してトラフィックを罪のない第三者に向けることができる場合、サービス拒否攻撃に対しても脆弱です。これらの攻撃については、モバイルIPv6ベース仕様[7]のセクション15.1で詳しく説明します。
In order to avoid these attacks, the base specification uses IPsec Encapsulating Security Payload (ESP) [3] to protect control traffic between the home agent and the mobile node. This control traffic consists of various messages carried by the Mobility Header protocol in IPv6 [5]. The traffic takes the following forms:
これらの攻撃を回避するために、ベース仕様では、セキュリティペイロード（ESP）[3]をカプセル化するIPSECを使用して、ホームエージェントとモバイルノード間の制御トラフィックを保護します。このコントロールトラフィックは、IPv6のモビリティヘッダープロトコルによって運ばれるさまざまなメッセージで構成されています[5]。トラフィックは次の形式を取得します。
o Binding Update and Acknowledgement messages exchanged between the mobile node and the home agent, as described in Sections 10.3.1, 10.3.2, 11.7.1, and 11.7.3 of the base specification [7].
o ベース仕様[7]のセクション10.3.1、10.3.2、11.7.1、および11.7.3で説明されているように、モバイルノードとホームエージェントとの間で交換されるバインディングアップデートと確認メッセージ。
o Return routability messages Home Test Init and Home Test that pass through the home agent on their way to a correspondent node, as described in Section 10.4.6 of the base specification [7].
o 基本仕様のセクション10.4.6で説明されているように、ルーティング可能性メッセージのホームテストINITとホームエージェントを通信中のホームエージェントを通過するホームエージェントを通過するホームテスト[7]を返します。
o ICMPv6 messages exchanged between the mobile node and the home agent for the purposes of prefix discovery, as described in Sections 10.6 and 11.4 of the base specification [7].
o 基本仕様のセクション10.6および11.4で説明されているように、プレフィックス発見の目的でモバイルノードとホームエージェントの間で交換されたICMPV6メッセージ[7]。
The nodes may also optionally protect payload traffic passing through the home agent, as described in Section 5.5 of the base specification [7]. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection support is required.
また、ベース仕様[7]のセクション5.5で説明されているように、ホームエージェントを通過するペイロードトラフィックをオプションで保護することもできます。マルチキャストグループメンバーシップコントロールプロトコルまたはステートフルアドレスAutoconfigurationプロトコルがサポートされている場合、ペイロードデータ保護サポートが必要です。
The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and anti-replay protection. The mobile node and the home agent must have an IPsec security association to protect this traffic. IPsec does not proving correct ordering of messages. Correct ordering of the control traffic is ensured by a sequence number in the Binding Update and Binding Acknowledgement messages. The sequence number in the Binding Updates also provides protection to a certain extent. It fails in some scenarios, for example, if the Home Agent loses the Binding Cache state. Full protection against replay attacks is possible only when IKE is used.
モバイルノードとホームエージェントの間の制御トラフィックには、メッセージ認証、整合性、正しい順序付け、およびレプレイ防止防止が必要です。モバイルノードとホームエージェントには、このトラフィックを保護するためにIPSECセキュリティ協会が必要です。IPSECは、メッセージの正しい順序付けを証明していません。制御トラフィックの正しい順序付けは、バインディングアップデートおよび拘束力のある確認メッセージのシーケンス番号によって保証されます。バインディングアップデートのシーケンス番号は、ある程度保護を提供します。たとえば、ホームエージェントがバインディングキャッシュ状態を失った場合、いくつかのシナリオで失敗します。リプレイ攻撃に対する完全な保護は、IKEが使用されている場合にのみ可能です。
Great care is needed when using IKE [4] to establish security associations to Mobile IPv6 home agents. The right kind of addresses must be used for transporting IKE. This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed.
IKE [4]を使用して、モバイルIPv6ホームエージェントにセキュリティ関連を確立する場合は、細心の注意が必要です。IKEの輸送には、適切な種類のアドレスを使用する必要があります。これは、バインディングアップデートの使用が、バインディングアップデートが完了する前に完了できないIKE交換の必要性を引き起こす循環依存関係を避けるために必要です。
The mobile IPv6 base document defines the main requirements the mobile nodes and home agents must follow when securing the above traffic. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
モバイルIPv6ベースドキュメントは、上記のトラフィックを保護するときにモバイルノードとホームエージェントが従わなければならない主な要件を定義します。このドキュメントでは、これらの要件についてより深く説明し、使用されているパケット形式を示し、適切な構成手順を説明し、実装が適切な順序でパケットを処理する方法を示しています。
We begin our description by showing the required wire formats for the protected packets in Section 3. Section 4 describes rules which associated Mobile IPv6, IPsec, and IKE implementations must observe. Section 5 discusses how to configure either manually keyed IPsec security associations or how to configure IKE to establish them automatically. Section 6 shows examples of how packets are processed within the nodes.
セクション3の保護されたパケットに必要なワイヤ形式を表示することから説明を開始します。セクション4では、関連するモバイルIPv6、IPSEC、およびIKEの実装が観察する必要があるルールについて説明します。セクション5では、手動でキー付きのIPSECセキュリティアソシエーションを構成する方法、またはIKEを自動的に確立するように設定する方法について説明します。セクション6は、ノード内でパケットがどのように処理されるかの例を示しています。
All implementations of Mobile IPv6 mobile node and home agent MUST support at least the formats described in Section 3 and obey the rules in Section 4.
モバイルIPv6モバイルノードとホームエージェントのすべての実装は、少なくともセクション3で説明されている形式をサポートし、セクション4のルールに従う必要があります。
The configuration and processing sections are informative, and should only be considered as one possible way of providing the required functionality.
構成セクションと処理セクションは有益であり、必要な機能を提供する1つの可能な方法としてのみ考慮する必要があります。
Note that where this document indicates a feature MUST be supported and SHOULD be used, this implies that all implementations must be capable of using the specified feature, but there may be cases where, for instance, a configuration option disables to use of the feature in a particular situation.
このドキュメントが機能をサポートし、使用する必要があることを示す場合、これはすべての実装が指定された機能を使用できる必要があることを意味しますが、たとえば、構成オプションが機能を無効にする場合がある場合があります。特定の状況。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、RFC 2119 [1]に記載されているように解釈されます。
When the mobile node is away from its home, the BUs sent by it to the home agent MUST support at least the following headers in the following order:
モバイルノードが自宅から離れている場合、それによってホームエージェントに送られたバスは、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode Mobility header Binding Update Alternate Care-of Address option (care-of address)
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）Destination Options Header Home Addressオプション（ホームアドレス）ESPヘッダーIN TRANSTRAINCE MODE MODILITYヘッダーバインドアップデート代替ケアオブアドレスオプション（ケアオブアドレス）
Note that the Alternate Care-of Address option is used to ensure that the care-of address is protected by ESP. The home agent considers the address within this option as the current care-of address for the mobile node. The home address is not protected by ESP directly, but the use of a specific home address with a specific security association is required by policy.
代替ケアオブアドレスオプションは、ESPによってケアオブアドレスが保護されることを確認するために使用されることに注意してください。ホームエージェントは、このオプション内のアドレスをモバイルノードの現在のアドレスと見なします。ホームアドレスはESPによって直接保護されていませんが、特定のセキュリティ協会を使用した特定のホームアドレスの使用はポリシーで必要です。
The Binding Acknowledgements sent back to the mobile node when it is away from home MUST support at least the following headers in the following order:
自宅から離れているときにモバイルノードに送り返されるバインディングの謝辞は、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ルーティングヘッダー（タイプ2）ホームアドレス輸送モードモビリティヘッダーバインディング承認のESPヘッダー
When the mobile node is at home, the above rules are different as the mobile node can use its home address as a source address. This typically happens for the de-registration Binding Update when the mobile is returning home. In this situation, the Binding Updates MUST support at least the following headers in the following order:
モバイルノードが自宅にある場合、モバイルノードはホームアドレスをソースアドレスとして使用できるため、上記のルールは異なります。これは通常、モバイルが帰宅しているときに登録解除バインディングアップデートで発生します。この状況では、バインディングの更新は、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = home address, destination = home agent) ESP header in transport mode Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）ESPヘッダーイントラントモードモービリティヘッダーバインディングアップデート
The Binding Acknowledgement messages sent to the home address MUST support at least the following headers in the following order:
自宅の住所に送信された拘束力のある承認メッセージは、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = home agent, destination = home address) ESP header in transport mode Mobility header Binding Acknowledgement
IPv6ヘッダー（Source = Home Agent、Destination = Home Address）ESP Header in Transport Mode Mobilityヘッダーバインディング承認
When the Home Test Init messages tunneled to the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
ホームエージェントにトンネリングされたホームテストINITメッセージがIPSECによって保護されている場合、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header In Tunnel Mode IPv6 Header（Source = Home Address、Destination = crespordent Node）Mobility Header Home Test Init
This format assumes that the mobile node's current care-of address is used as the outer header destination address in the security association. As discussed in Section 4.3, this requires the home agent to update the destination address when the mobile node moves. Policy entries and security association selectors stay the same, however, as the inner packets do not change upon movements.
この形式では、モバイルノードの現在のケアアドレスが、セキュリティ協会の外側のヘッダー宛先アドレスとして使用されることを前提としています。セクション4.3で説明したように、これには、モバイルノードが移動するときにホームエージェントが宛先アドレスを更新する必要があります。ただし、ポリシーエントリとセキュリティアソシエーションセレクターは、内側のパケットが動きで変化しないため、同じままです。
Note that there are trade-offs in using care-of addresses as the destination addresses versus using the home address and attaching an additional Home Address destination option and/or Routing header to the packets. The basis for requiring support for at least the care-of address case has been discussed in Section 7.
宛先アドレスとしてケアオブアドレスを使用することと、ホームアドレスを使用すること、追加のホームアドレス宛先オプションおよび/またはルーティングヘッダーをパケットに添付することにはトレードオフがあることに注意してください。少なくとも住所のケアケースのサポートを要求するための根拠は、セクション7で説明されています。
Similarly, when the Home Test messages tunneled from the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
同様に、ホームエージェントからトンネリングされたホームテストメッセージがIPSECによって保護されている場合、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）トンネルモードのESPヘッダーIPv6ヘッダー（Source = crespordent Node、destination = homeアドレス）モビリティヘッダーホームテスト
The format used to protect return routability packets relies on the destination of the tunnel packets to change for the mobile node as it moves. The home agent's address stays the same, but the mobile node's address changes upon movements, as if the security association's outer header destination address had changed. When the mobile node adopts a new care-of address, it adopts also a new source address for outgoing tunnel packets. The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked according to the rules in RFC 2401. (We note, however, that some implementations are known to make source address checks.) For a discussion of the role of source addresses in outer tunnel headers, see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent requires the packets to be authenticated regardless of the source address change, hence the "new" sender must possess the same keys for the security association as it had in the previous location. This proves that the sender is the same entity, regardless of the changes in the addresses.
リターンルー上のパケットを保護するために使用される形式は、トンネルパケットの宛先に依存して、移動する際にモバイルノードの変更を行います。ホームエージェントのアドレスは同じままですが、セキュリティ協会の外側のヘッダー宛先アドレスが変更されたかのように、モバイルノードのアドレスは動きで変化します。モバイルノードが新しいケアオブアドレスを採用すると、発信トンネルパケットの新しいソースアドレスも採用します。ホームエージェントは、トンネルパケットの外側のソースアドレスがRFC 2401のルールに従ってチェックされていないため、このように送信されたパケットを受け入れます。外側のトンネルヘッダーにおけるソースアドレスの役割。RFC2401[2]のセクション5.1.2.1を参照してください。また、ホームエージェントは、ソースアドレスの変更に関係なくパケットを認証する必要があるため、「新しい」送信者は、前の場所と同じセキュリティ協会のために同じキーを所有している必要があります。これは、アドレスの変更に関係なく、送信者が同じエンティティであることを証明します。
The process is more complicated in the home agent side, as the home agent has stored the previous care-of address in its Security Association Database as the outer header destination address. When IKE is being used, the mobile node runs it on top of its current care-of address, and the resulting tunnel-mode security associations will use the same addresses as IKE run over. In order for the home agent to be able to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had modified the outer header destination address in the security association used for this protection. This implies that the same security association can be used in multiple locations, and no new configuration or re-establishment of IKE phases is needed per movement. Section 5.2.2 discusses the security policy and security association database entries that are needed to accomplish this.
ホームエージェントは、セキュリティ協会のデータベースに以前のケアオブアドレスを外側のヘッダー宛先アドレスとして保存しているため、ホームエージェント側ではこのプロセスがより複雑です。IKEが使用されると、モバイルノードは現在のアドレスのケアの上にそれを実行し、結果のトンネルモードセキュリティ協会はIKEと同じアドレスを使用します。ホームエージェントがホームテストメッセージをモバイルノードにトンネルにできるようにするために、ホームエージェントがトンネルパケットの宛先として現在のケアのケアを使用します。この保護に使用されるセキュリティ協会。これは、同じセキュリティ協会が複数の場所で使用できることを意味し、移動ごとに新しい構成またはIKEフェーズの再確立が必要ではないことを意味します。セクション5.2.2では、これを達成するために必要なセキュリティポリシーおよびセキュリティ協会のデータベースエントリについて説明します。
If IPsec is used to protect prefix discovery, requests for prefixes from the mobile node to the home agent MUST support at least the following headers in the following order.
IPSecがプレフィックスの発見を保護するために使用される場合、モバイルノードからホームエージェントへのプレフィックスのリクエストは、少なくとも次の順序で次のヘッダーをサポートする必要があります。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode ICMPv6 Mobile Prefix Solicitation
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）宛先オプションヘッダーホームアドレスオプション（ホームアドレス）ESPヘッダー輸送モードICMPv6モバイルプレフィックス勧誘
Again if IPsec is used, solicited and unsolicited prefix information advertisements from the home agent to the mobile node MUST support at least the following headers in the following order.
繰り返しますが、IPSECを使用すると、ホームエージェントからモバイルノードへの勧誘および未承諾のプレフィックス情報広告は、少なくとも次の順序で次のヘッダーをサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode ICMPv6 Mobile Prefix Advertisement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ルーティングヘッダー（タイプ2）ホームアドレス輸送モードのESPヘッダーICMPv6モバイルプレフィックス広告
If IPsec is used to protect payload packets tunneled to the home agent from the mobile node, we use a format similar to the one in Section 3.2. However, instead of the MobilityHeader, these packets may contain any legal IPv6 protocol(s):
IPSecがモバイルノードからホームエージェントにトンネルされたペイロードパケットを保護するために使用される場合、セクション3.2の形式と同様の形式を使用します。ただし、MobilityHeaderの代わりに、これらのパケットには法的IPv6プロトコルが含まれている場合があります。
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Any protocol
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header In Tunnel Mode IPv6 Header（Source = Home Address、Destination = cresporsent Node）任意のプロトコル
Similarly, when the payload packets are tunneled from the home agent to the mobile node with ESP encapsulation, they MUST support at least the following headers in the following order:
同様に、PayloadパケットがESPカプセル化によりホームエージェントからモバイルノードにトンネリングされる場合、少なくとも次のヘッダーを次の順序でサポートする必要があります。
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Any protocol
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）トンネルモードのESPヘッダーIPv6ヘッダー（Source = crespordentノード、宛先=ホームアドレス）任意のプロトコル
This section describes mandatory rules for all Mobile IPv6 mobile nodes and home agents. These rules are necessary in order for it to be possible to enable IPsec communications despite movements, guarantee sufficient security, and to ensure correct processing order of packets.
このセクションでは、すべてのモバイルIPv6モバイルノードとホームエージェントの必須ルールについて説明します。これらのルールは、動きにもかかわらずIPSEC通信を有効にし、十分なセキュリティを保証し、パケットの正しい処理順序を確保するために可能であるために必要です。
The rules in the following sections apply only to the communications between home agents and mobile nodes. They should not be taken as requirements on how IPsec in general is used by mobile nodes.
次のセクションのルールは、ホームエージェントとモバイルノード間の通信にのみ適用されます。それらは、一般的にIPSECがモバイルノードによってどのように使用されるかについての要件としてとられるべきではありません。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o Manual configuration of IPsec security associations MUST be supported. The configuration of the keys is expected to take place out-of-band, for instance at the time the mobile node is configured to use its home agent.
o IPSECセキュリティ協会の手動構成をサポートする必要があります。たとえば、モバイルノードがホームエージェントを使用するように構成されている時点で、キーの構成は帯域外に行われると予想されます。
o Automatic key management with IKE [4] MAY be supported. Only IKEv1 is discussed in this document. Other automatic key management mechanisms exist and will appear beyond IKEv1, but this document does not address the issues related to them.
o IKE [4]を使用した自動キー管理がサポートされる場合があります。このドキュメントではIKEV1のみが説明されています。他の自動キー管理メカニズムが存在し、IKEV1を超えて表示されますが、このドキュメントはそれらに関連する問題に対処していません。
o ESP encapsulation of Binding Updates and Acknowledgements between the mobile node and home agent MUST be supported and MUST be used.
o モバイルノードとホームエージェントの間のバインディングの更新と謝辞のESPカプセル化をサポートする必要があり、使用する必要があります。
o ESP encapsulation of the Home Test Init and Home Test messages tunneled between the mobile node and home agent MUST be supported and SHOULD be used.
o モバイルノードとホームエージェントの間でトンネルを絞ったホームテストINITとホームテストメッセージのESPカプセル化をサポートする必要があり、使用する必要があります。
o ESP encapsulation of the ICMPv6 messages related to prefix discovery MUST be supported and SHOULD be used.
o プレフィックス発見に関連するICMPV6メッセージのESPカプセル化をサポートする必要があり、使用する必要があります。
o ESP encapsulation of the payload packets tunneled between the mobile node and home agent MAY be supported and used.
o モバイルノードとホームエージェントの間にトンネルされたペイロードパケットのESPカプセル化がサポートされ、使用される場合があります。
o If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported for those protocols.
o マルチキャストグループメンバーシップコントロールプロトコルまたはステートフルアドレスAutoconfigurationプロトコルがサポートされている場合、これらのプロトコルに対してペイロードデータ保護をサポートする必要があります。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o As required in the base specification [7], when a packet destined to the receiving node is matched against IPsec security policy or selectors of a security association, an address appearing in a Home Address destination option is considered as the source address of the packet.
o ベース仕様[7]で必要に応じて、受信ノードに任命されたパケットがIPSECセキュリティポリシーまたはセキュリティアソシエーションのセレクターと一致する場合、ホームアドレスの宛先オプションに表示されるアドレスがパケットのソースアドレスと見なされます。
Note that the home address option appears before IPsec headers. Section 11.3.2 of the base specification describes one possible implementation approach for this: The IPsec policy operations can be performed at the time when the packet has not yet been modified per Mobile IPv6 rules, or has been brought back to its normal form after Mobile IPv6 processing. That is, the processing of the Home Address option is seen as a fixed transformation of the packets that does not affect IPsec processing.
ホームアドレスオプションは、iPSECヘッダーの前に表示されることに注意してください。ベース仕様のセクション11.3.2では、これに対する1つの可能な実装アプローチについて説明します。IPSECポリシー操作は、モバイルIPv6ルールごとにパケットがまだ変更されていないか、モバイル後に通常のフォームに戻されたときに実行できます。IPv6処理。つまり、ホームアドレスオプションの処理は、IPSEC処理に影響を与えないパケットの固定変換と見なされます。
o Similarly, a home address within a Type 2 Routing header destined to the receiving node is considered as the destination address of the packet, when a packet is matched against IPsec security policy or selectors of a security association.
o 同様に、受信ノードに向けたタイプ2ルーティングヘッダー内のホームアドレスは、パケットがIPSECセキュリティポリシーまたはセキュリティ協会のセレクターと一致する場合、パケットの宛先アドレスと見なされます。
Similar implementation considers apply to the Routing header processing as was described above for the Home Address destination option.
同様の実装は、ホームアドレスの宛先オプションについて上記で説明したように、ルーティングヘッダー処理に適用されると考えています。
o When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters this tunnel.
o IPSECを使用して、Returability SignalingまたはPayload Packetsを保護するために、この保護は、モバイルノードとホームエージェントの間にIPv6カプセル化されたトンネルインターフェイスを入力するリターンルー上のパケットにのみ適用する必要があります。これは、たとえば、トンネルインターフェイス専用のセキュリティポリシーデータベースエントリを定義することで実現できます。つまり、ポリシーエントリは一般に、ノードの物理インターフェイス上のすべてのトラフィックに適用されるのではなく、このトンネルに入るトラフィックのみに適用されます。
o The authentication of mobile nodes MAY be based either on machine or user credentials. Note that multi-user operating systems typically allow all users of a node to use any of the IP addresses assigned to the node. This limits the capability of the home agent to restrict the use of a home address to a particular user in such environment. Where user credentials are applied in a multi-user environment, the configuration should authorize all users of the node to control all home addresses assigned to the node.
o モバイルノードの認証は、マシンまたはユーザーの資格情報のいずれかに基づいている場合があります。マルチユーザーオペレーティングシステムにより、ノードのすべてのユーザーがノードに割り当てられたIPアドレスのいずれかを使用できるようにすることに注意してください。これにより、ホームエージェントの能力が制限され、そのような環境の特定のユーザーへのホームアドレスの使用を制限します。ユーザー資格情報がマルチユーザー環境で適用される場合、構成はノードに割り当てられたすべてのホームアドレスを制御するようにノードのすべてのユーザーを承認する必要があります。
o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent MUST be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again.
o モバイルノードがホームエージェントとホームと解雇を返すと、ホームエージェントとモバイルノードのケアアドレスの間のトンネルが取り壊されます。モバイルノードとホームエージェント間のトンネルトラフィックを保護するために使用されたセキュリティポリシーエントリは、非アクティブにする必要があります（たとえば、それらを削除してAPIを介して後でインストールすることにより）。対応するセキュリティ協会は、作成方法に応じて、そのまま保持するか、削除できます。IKEを使用してセキュリティ協会が動的に作成された場合、有効期限が切れると自動的に削除されます。セキュリティアソシエーションが手動構成を通じて作成された場合、モバイルノードが再び自宅から離れて移動したときに保持され、後で使用する必要があります。拘束力のある更新と謝辞を保護するセキュリティ協会、およびプレフィックスの発見は、アドレスのケアに依存せず、再び使用できるため削除すべきではありません。
The following rules apply to mobile nodes:
次のルールがモバイルノードに適用されます。
o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations, sent to the home agent from a care-of address.
o モバイルノードは、拘束力のある更新とモバイルプレフィックスの勧誘でホームアドレスの宛先オプションを使用して、住所からホームエージェントに送信する必要があります。
o When the mobile node receives a changed set of prefixes from the home agent during prefix discovery, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this.
o モバイルノードがプレフィックスディスカバリー中にホームエージェントから変更されたプレフィックスのセットを受信すると、新しいセキュリティポリシーエントリを構成する必要があり、新しいセキュリティ協会を構成する必要があるかもしれません。この仕様の範囲外で、このための自動メソッドについて説明します。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node, again due to the need to have the home address visible when the policy checks are made.
o ホームエージェントは、ポリシーチェックが行われたときにホームアドレスを表示する必要があるため、再びモバイルノードに送信されるバインディング謝辞とモバイルプレフィックス広告でタイプ2ルーティングヘッダーを使用する必要があります。
o It is necessary to avoid the possibility that a mobile node could use its security association to send a Binding Update on behalf of another mobile node using the same home agent. In order to do this, the security policy database entries MUST unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent when manually keyed IPsec security associations are used. When dynamic keying is used, the security policy database entries MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used.
o モバイルノードがセキュリティアソシエーションを使用して、同じホームエージェントを使用して別のモバイルノードに代わってバインディングアップデートを送信できる可能性を回避する必要があります。これを行うために、セキュリティポリシーデータベースエントリは、手動でキー付きIPSECセキュリティ関連付けを使用した場合、特定のホームアドレスとホームエージェント間の拘束力のある更新を保護するための単一のセキュリティ協会を明確に識別する必要があります。動的キーリングを使用する場合、セキュリティポリシーデータベースエントリは、特定のホームアドレスのバインディングアップデートを保護するためのセキュリティ協会の作成を許可するために使用できるIKEフェーズ1資格情報を明確に識別する必要があります。これらのマッピングがどのように維持されるかは、この仕様の範囲外ですが、たとえば、ホームエージェントでローカルに管理されたテーブルとして維持される場合があります。フェーズ1のアイデンティティが完全に適格なドメイン名（FQDN）である場合、DNSの安全なフォームも使用できます。
o When the set of prefixes advertised by the home agent changes, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this, if new home addresses are required.
o ホームエージェントによって宣伝されているプレフィックスのセットが変更された場合、新しいセキュリティポリシーエントリを構成する必要があり、新しいセキュリティ協会を構成する必要があるかもしれません。新しいホームアドレスが必要な場合、この仕様の自動メソッドを議論するのは、この仕様の範囲外です。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection.
o バインディングの更新、バインディングの謝辞、およびプレフィックスの発見を確保する場合、モバイルノードとホームエージェントの両方がサポートする必要があり、輸送モードのカプセル化セキュリティペイロード（ESP）[3]ヘッダーを使用し、非ヌルペイロード認証アルゴリズムを使用する必要があります。データオリジン認証、コネクションレスの完全性、およびオプションのアンチレプレイ保護を提供します。
Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care is needed when selecting suitable encryption algorithms for ESP, however. Currently available integrity protection algorithms are in general considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, however. This is particularly problematic when IPsec security associations are configured manually, as the same key is used for a long time.
暗号化および整合性保護アルゴリズムの必須サポートは、RFC 2401 [2]、RFC 2402 [8]、およびRFC 2406 [3]で定義されています。ただし、ESPに適した暗号化アルゴリズムを選択する場合は、注意が必要です。現在利用可能な整合性保護アルゴリズムは、一般的に安全であると考えられています。ただし、現在のIPSEC標準によって義務付けられている暗号化アルゴリズムDES DESはそうではありません。これは、同じキーが長い間使用されているため、IPSECセキュリティ関連が手動で構成されている場合に特に問題があります。
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied.
o トンネルモードIPSEC ESPをサポートする必要があり、返品ルー上の手順に属するパケットの保護に使用する必要があります。非ヌル暗号化変換と非ヌル認証アルゴリズムを適用する必要があります。
Note that the return routability procedure involves two message exchanges from the mobile node to the correspondent node. The purpose of these exchanges is to assure that the mobile node is live at the claimed home and care-of addresses. One of the exchanges is sent directly to and from the correspondent node, while another one is tunneled through the home agent. If an attacker is on the mobile node's link and the mobile node's current link is an unprotected wireless link, the attacker would able to see both sets of messages, and launch attacks based on it (these attacks are discussed further in Section 15.4 of the base specification [7].) One can prevent the attack by making sure that the packets tunneled through the home agent are encrypted.
返品ルー上の手順には、モバイルノードから特派員ノードへの2つのメッセージ交換が含まれることに注意してください。これらの交換の目的は、モバイルノードが主張されたホームとケアオブアドレスでライブであることを保証することです。交換の1つは特派員ノードとの間で直接送信され、別の交換はホームエージェントを通してトンネリングされます。攻撃者がモバイルノードのリンクにあり、モバイルノードの現在のリンクが保護されていないワイヤレスリンクである場合、攻撃者は両方のメッセージセットを表示し、それに基づいて攻撃を起動することができます（これらの攻撃については、ベースのセクション15.4でさらに説明します。仕様[7]。）ホームエージェントを介してトンネリングされたパケットが暗号化されていることを確認することにより、攻撃を防ぐことができます。
Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementations mechanisms. In the case of IPsec tunnel mode, the use of IP-in-IP encapsulation followed by IPsec transport mode encapsulation may also be possible.
この仕様は、ワイヤー内の形式のみに関係しており、特定の実装メカニズムを決定しないことに注意してください。IPSECトンネルモードの場合、IP-in-IPカプセル化とそれに続くIPSEC輸送モードのカプセル化の使用も可能です。
The following rules apply to mobile nodes:
次のルールがモバイルノードに適用されます。
o When ESP is used to protect Binding Updates, there is no protection for the care-of address which appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered with. As a result, the attacker would have redirected the mobile node's traffic to another address. In order to prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register. In this case no Alternate Care-of Address option is needed, as described in Section 3.1.
o ESPを使用してバインディングアップデートを保護する場合、ESPによって保護されているエリアの外側のIPv6ヘッダーに表示される住所のケアの保護はありません。ホームエージェントにとって、住所のケアが改ざんされていないことを確認することが重要です。その結果、攻撃者はモバイルノードのトラフィックを別のアドレスにリダイレクトしました。これを防ぐために、モバイルIPv6の実装は、自宅から離れている間にモバイルノードによって送信されたバインディングアップデートで、代替ケアオブアドレスモビリティオプションを使用する必要があります。これの例外は、モバイルノードが家に帰り、登録を解除するためにホームエージェントにバインディングアップデートを送信する場合です。この場合、セクション3.1で説明されているように、代替のアドレスケアオプションオプションは必要ありません。
When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address. The mobile node starts to use a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address. Similarly, it starts to use the new address as the required destination address of tunneled packets received from the home agent.
IPSECを使用してルーティング可能性の信号またはペイロードパケットを保護する場合、モバイルノードは、発信トンネルパケットに使用するソースアドレスを現在のプライマリケアオブアドレスに設定する必要があります。モバイルノードは、この新しいアドレスを登録するためにホームエージェントにバインディングアップデートを送信した直後に、新しいプライマリケアオブアドレスを使用し始めます。同様に、新しいアドレスをホームエージェントから受け取ったトンネルパケットの必要な宛先アドレスとして使用し始めます。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
o When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node.
o IPSECを使用して、Returability SignalingまたはPayload Packetsを保護する場合、この保護を提供するためにIPSECセキュリティアソシエーションが必要です。受け入れられたバインディングアップデートの結果としてモバイルノードのケアのケアが変更される場合、これらのセキュリティ協会を使用して送信される次のパケットには特別な処理が必要です。ホームエージェントは、セキュリティ協会の外側のヘッダー宛先アドレスが変更されたかのように、これらのパケットの宛先アドレスとして新しいアドレスを設定する必要があります。同様に、ホームエージェントは、モバイルノードから受信したトンネルパケットの新しいソースアドレスを期待し始めます。
Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. It should be noted that the use of such an API and the address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec. Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application may result in security vulnerabilities.
このようなアドレスの変更は、たとえば、モバイルIPv6の実装からIPSEC実装までのAPIを介して実装できます。このようなAPIの使用とアドレスの変更は、ホームエージェントが受け取ったバインディングアップデートに基づいてのみ行われ、IPSECの使用によって保護される必要があることに注意する必要があります。他のソースに基づいたアドレスの変更は、返品ルーティング可能性によって保護されている特派員ノードへのバインディングアップデートや、あらゆるアプリケーションからAPIへのオープンアクセスなど、セキュリティの脆弱性をもたらす可能性があります。
The following requirements apply to both home agents and mobile nodes:
次の要件は、ホームエージェントとモバイルノードの両方に適用されます。
o If anti-replay protection is required, dynamic keying MUST be used. IPsec can provide anti-replay protection only if dynamic keying is used (which may not always be the case). IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, sequence numbers within the Mobile IPv6 messages are used to ensure correct ordering. However, if the 16 bit Mobile IPv6 sequence number space is cycled through, or the home agent reboots and loses its state regarding the sequence numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can together prevent such attacks.
o アンチレプレイ保護が必要な場合は、動的キーリングを使用する必要があります。IPSECは、動的キーインが使用される場合にのみ、アンチレプレイ保護を提供できます（常にそうではない場合があります）。IPSECは、パケットの正しい順序付けも保証するものではなく、再生されていないことだけです。このため、モバイルIPv6メッセージ内のシーケンス番号は、正しい順序付けを確実にするために使用されます。ただし、16ビットのモバイルIPv6シーケンス番号スペースが循環される場合、またはホームエージェントがシーケンス番号に関して再起動して状態を失った場合、攻撃を再生および並べ替えることが可能になります。動的キーイング、IPSECアンチレプレイ保護、およびモバイルIPv6シーケンス番号の使用は、このような攻撃を妨げる可能性があります。
o If IKE version 1 is used with preshared secrets in main mode, it determines the shared secret to use from the IP address of the peer. With Mobile IPv6, however, this may be a care-of address and does not indicate which mobile node attempts to contact the home agent. Therefore, if preshared secret authentication is used in IKEv1 between the mobile node and the home agent then aggressive mode MUST be used. Note also that care needs to be taken with phase 1 identity selection. Where the ID_IPV6_ADDR Identity Payloads is used, unambiguous mapping of identities to keys is not possible. (The next version of IKE may not have these limitations.)
o IKEバージョン1がメインモードのPreshared Secretで使用されている場合、ピアのIPアドレスから使用する共有秘密を決定します。ただし、モバイルIPv6を使用すると、これは住所の世話である可能性があり、どのモバイルノードがホームエージェントに連絡しようとするかを示していません。したがって、Mobileノードとホームエージェントの間でIKEV1でPreshared Secret認証が使用される場合、積極的なモードを使用する必要があります。また、フェーズ1のアイデンティティ選択を使用すると、注意が必要であることに注意してください。ID_IPV6_ADDRアイデンティティペイロードが使用される場合、キーへのアイデンティティの明確なマッピングは不可能です。（IKEの次のバージョンには、これらの制限がない場合があります。）
Note that the difficulties with main mode and preshared secrets in IKE version 1 are well known for dynamic addresses. With static addresses, there has not been a problem. With Mobile IPv6, however, the use of the care-of addresses to run IKE to the home agent presents a problem even when the home address stays stable. Further discussion about the use of care-of addresses in this way appears in Section 7.
IKEバージョン1のメインモードとプレシャの秘密の困難は、動的アドレスでよく知られていることに注意してください。静的アドレスでは、問題はありませんでした。ただし、モバイルIPv6を使用すると、ホームエージェントにIKEを実行するためのケアのケアを使用すると、ホームアドレスが安定したままであっても問題が発生します。この方法でのアドレスのケアの使用に関するさらなる議論は、セクション7に表示されます。
The following rules apply to mobile nodes:
次のルールがモバイルノードに適用されます。
o In addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent.
o 上記のルールに加えて、動的キーイングを使用する場合、主要な管理プロトコルは、モバイルノードのホームエージェントとのプロトコル交換のソースアドレスとしてケアオブアドレスを使用する必要があります。
o However, the IPsec security associations with the mobile node's home agent use home addresses. That is, the IPsec security associations MUST be requested from the key management protocol using the home address of the mobile node as the client identity.
o ただし、モバイルノードのホームエージェントとのIPSECセキュリティ関連は、ホームアドレスを使用しています。つまり、IPSECセキュリティ協会は、モバイルノードのホームアドレスをクライアントIDとして使用して、主要な管理プロトコルから要求する必要があります。
The security associations for protecting Binding Updates and Acknowledgements are requested for the Mobility header protocol in transport mode and for specific IP addresses as endpoints. No other selectors are used. Similarly, the security associations for protecting prefix discovery are requested for the ICMPv6 protocol and the specific IP addresses, again without other selectors. Security associations for payload and return routability protection are requested for a specific tunnel interface and either the payload protocol or the Mobility header protocol, in tunnel mode. In this case one requested endpoint is an IP address and the other one is a wildcard, and there are no other selectors.
拘束力のある更新と謝辞を保護するためのセキュリティ協会は、輸送モードのモビリティヘッダープロトコル、および特定のIPアドレスがエンドポイントとして要求されます。他のセレクターは使用されていません。同様に、プレフィックス発見を保護するためのセキュリティ協会は、他のセレクターなしで、ICMPV6プロトコルと特定のIPアドレスに対して要求されます。ペイロードおよびリターンルー上の保護のセキュリティ関連は、特定のトンネルインターフェイスと、トンネルモードのペイロードプロトコルまたはモビリティヘッダープロトコルのいずれかに対して要求されます。この場合、要求されたエンドポイントはIPアドレスであり、もう1つはワイルドカードであり、他のセレクターはありません。
o If the mobile node has used IKE version 1 to establish security associations with its home agent, it should follow the procedures discussed in Section 11.7.1 and 11.7.3 of the base specification [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
o モバイルノードがIKEバージョン1を使用してホームエージェントとセキュリティ関連を確立した場合、ベース仕様[7]のセクション11.7.1および11.7.3で説明した手順に従って、IKEエンドポイントを移動できるかどうかを判断する必要があります。IKEフェーズ1を再確立する必要がある場合。
The following rules apply to home agents:
次のルールは、ホームエージェントに適用されます。
o If the home agent has used IKE version 1 to establish security associations with the mobile node, it should follow the procedures discussed in Section 10.3.1 and 10.3.2 of the base specification [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
o ホームエージェントがIKEバージョン1を使用してモバイルノードとのセキュリティ関連を確立した場合、ベース仕様のセクション10.3.1および10.3.2で説明した手順[7]に従って、IKEエンドポイントを移動できるかどうかを判断する必要があります。IKEフェーズ1を再確立する必要がある場合。
In the following we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home agent.
以下では、モバイルノードとホームエージェントの間で交換されるバインディングの更新と拘束力のある謝辞を保護するために必要なセキュリティポリシーデータベース（SPD）およびセキュリティ協会データベース（SAD）エントリについて説明します。
Section 5.1 introduces the format we use in the description of the SPD and the SAD. Section 5.2 describes how to configure manually keyed IPsec security associations without dynamic keying, and Section 5.3 describes how to use dynamic keying.
セクション5.1では、SPDおよびSADの説明で使用する形式を紹介します。セクション5.2では、動的キーリングなしで手動でキー付きIPSECセキュリティアソシエーションを構成する方法について説明し、セクション5.3では、動的キーリングの使用方法について説明します。
The format used in the examples is as follows. The SPD description has the format
例で使用される形式は次のとおりです。SPDの説明には形式があります
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has the following format:
<node>はノードの名前を表し、<spdentry>には次の形式があります。
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |
Where <condition> is a boolean expression about the fields of the
IPv6 packet, <sa> is the name of a specific security association, and
<pattern> is a specification for a security association to be
negotiated via IKE [4]. The SAD description has the format
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has the following format:
<node>はノードの名前を表し、<sadentry>には次の形式があります。
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association, <destination> is its destination, <ipsec-proto> is in our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule> is an expression which describes the IPsec selectors, i.e., which fields of the IPv6 packet must have which values.
ここで、<dir>は「in」または「out」です。<spi>はセキュリティ協会のSPIです。トンネル「または「輸送」、および<rule>は、IPSECセレクター、つまりIPv6パケットのどのフィールドが必要な値を持たなければならない式を記述する式です。
We will be using an example mobile node in this section with the home address "home_address_1". The user's identity in this mobile node is "user_1". The home agent's address is "home_agent_1".
このセクションのモバイルノードの例を使用して、Homeアドレス「Home_Address_1」を備えています。このモバイルノードのユーザーのIDは「user_1」です。ホームエージェントの住所は「HOME_AGENT_1」です。
Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements:
SPDの内容と、拘束力のある更新と謝辞を保護するための悲しいものがあります。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
モバイルノードSPDアウト： - source = home_address_1＆destination = home_agent_1＆proto = mhの場合、sa sa1を使用します
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
モバイルノードSPD In：-fource = home_agent_1＆destination = home_address_1＆proto = mhの場合、SASA2を使用します
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
ホームエージェントSPD出力：-Source = HOME_AGENT_1＆DENTVESTION = HOME_ADDRESS_1＆PROTO = MHの場合、SASA2を使用します
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
ホームエージェントSPD In：-fource = home_address_1＆destination = home_agent_1＆proto = mhの場合、sa sa1を使用します
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
In the above, "MH" refers to the protocol number for the Mobility Header [7].
上記では、「MH」とは、モビリティヘッダーのプロトコル番号を指します[7]。
In the following we describe the necessary SPD and SAD entries to protect return routability signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. In other words, the higher precedence entries must occur first in the RFC 2401 [2] ordered list of SPD entries.
以下では、モバイルノードとホームエージェント間の返品性の信号を保護するために必要なSPDとSADエントリについて説明します。SPDのルールが注文されており、前のセクションのルールがこれらよりも優先される必要があることに注意してください。言い換えれば、より高い優先順位エントリは、最初にRFC 2401 [2] SPDエントリの順序リストで発生する必要があります。
mobile node SPD OUT: - IF interface = IPv6 IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
モバイルノードSPDアウト：-INTERFACE = IPv6 IPv6トンネルからHOME_AGENT_1＆SOURCE = HOME_ADDRESS_1＆DENTVENTION = ANY＆ProTO = MHを使用してからSA SA3を使用します
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
モバイルノードSPD IN：-INTERFACE = IPv6トンネルHOME_AGENT_1＆source = any＆destination = home_address_1＆proto = mhからSA SA4を使用します
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
ホームエージェントSPDアウト：-Interface = IPv6トンネルからHome_Address_1＆Source = any＆Destination = home_address_1＆proto = mhの場合、SA SA4を使用します
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
ホームエージェントSPD IN：-INTERFACE = IPv6 Tunnel from Home_Address_1＆source = home_address_1＆destination = any＆proto = mhその後、SASA3を使用します
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. It can be initialized to the home address before the mobile node has registered.
ホームエージェントからモバイルノードまでのセキュリティ協会は、現在の住所を宛先として使用します。前述のように、このアドレスはモバイルノードが移動するにつれてSADで更新されます。モバイルノードが登録される前に、自宅の住所に初期化できます。
In the following we describe some additional SPD and SAD entries to protect prefix discovery. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent, as IPsec may not have the ability to distinguish between different ICMPv6 types.
以下では、プレフィックスの発見を保護するための追加のSPDおよびSADエントリについて説明します。上記のSPDは、IPSECが異なるICMPV6タイプを区別する機能を持たない可能性があるため、モバイルノードとホームエージェント間のすべてのICMPV6トラフィックを保護することに注意してください。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5.
モバイルノードSPD OUT：-SOURCE = HOME_ADDRESS_1＆DENTIVENT = HOME_AGENT_1＆Proto = ICMPV6の場合、SA SA5を使用します。
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
モバイルノードSPD IN：-FOURSE = HOME_AGENT_1＆DENTINTION = HOME_ADDRESS_1＆PROTO = ICMPV6を使用してからSA SA6を使用します
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
ホームエージェントSPD出力： - source = home_agent_1＆destination = home_address_1＆proto = icmpv6の場合、sa sa6を使用します
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5
ホームエージェントSPD IN：-FOURSE = HOME_ADDRESS_1＆DENTINTION = HOME_AGENT_1＆PROTO = ICMPV6を使用してからSA SA5を使用します
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
It is also possible to perform some additional, optional, protection of tunneled payload packets. This protection takes place in a similar manner to the return routability protection above, but requires a different value for the protocol field. The necessary SPD and SAD entries are shown below. It is assumed that the entries for protecting Binding Updates and Acknowledgements, and the entries to protect Home Test Init and Home Test messages take precedence over these entries.
トンネル付きペイロードパケットの追加のオプションの保護を実行することもできます。この保護は、上記の返品可能性保護と同様の方法で行われますが、プロトコルフィールドには異なる値が必要です。必要なSPDと悲しいエントリを以下に示します。拘束力のある更新と謝辞を保護するためのエントリ、およびホームテストINITとホームテストメッセージを保護するためのエントリがこれらのエントリよりも優先されると想定されています。
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
モバイルノードSPDアウト：-Interface = IPv6トンネルからHome_Agent_1＆source = home_address_1＆destination = any＆proto = xを使用してからsa sa7を使用します
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
モバイルノードSPD IN：-INTERFACE = IPv6 Tunnel from Home_Agent_1＆source = any＆destination = home_address_1＆proto = xを使用してからSA SA8を使用します
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
ホームエージェントSPD出力：-Interface = IPv6トンネルからHome_Address_1＆source = any＆destination = home_address_1＆proto = xを使用してからSA SA8を使用します
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
ホームエージェントSPD IN：-INTERFACE = IPv6 Tunnel from Home_Address_1＆source = home_address_1＆destination = any＆proto = xを使用してからsa sa7を使用します
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
If multicast group membership control protocols such as MLDv1 [9] or MLDv2 [11] need to be protected, these packets may use a link-local address rather than the home address of the mobile node. In this case the source and destination can be left as a wildcard and the SPD entries will work solely based on the used interface and the protocol, which is ICMPv6 for both MLDv1 and MLDv2.
MLDV1 [9]やMLDV2 [11]などのマルチキャストグループメンバーシップ制御プロトコルを保護する必要がある場合、これらのパケットはモバイルノードのホームアドレスではなく、リンクローカルアドレスを使用する場合があります。この場合、ソースと宛先はワイルドカードとして残すことができ、SPDエントリは使用されているインターフェイスとプロトコル（MLDV1とMLDV2の両方のICMPv6）に基づいてのみ動作します。
Similar problems are encountered when stateful address autoconfiguration protocols such as DHCPv6 [10] are used. The same approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP protocol.
DHCPV6 [10]などのAutoconfigurationプロトコルをStatefulアドレスが使用する場合、同様の問題が発生します。同じアプローチもDHCPV6にも適用できます。DHCPV6はUDPプロトコルを使用します。
Support for multiple layers of encapsulation (such as ESP encapsulated in ESP) is not required by RFC 2401 [2] and is also otherwise often problematic. It is therefore useful to avoid setting the protocol X in the above entries to either AH or ESP.
カプセル化の複数の層（ESPにカプセル化されたESPなど）のサポートは、RFC 2401 [2]では必要ではなく、しばしば問題があります。したがって、上記のエントリにプロトコルXをAHまたはESPに設定することを避けることは便利です。
In this section we show an example configuration that uses IKE to negotiate security associations.
このセクションでは、IKEを使用してセキュリティ協会をネゴシエートする例を示します。
Here are the contents of the SPD for protecting Binding Updates and Acknowledgements:
バインディングの更新と謝辞を保護するためのSPDの内容は次のとおりです。
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the above, and all details related to the particular authentication method such as certificates beyond listing a specific identity that must be used.
上記で提案された変換の詳細と、使用する必要がある特定のIDをリストする以外の証明書などの特定の認証方法に関連するすべての詳細を省略しました。
We require IKE version 1 to be run using the care-of addresses but still negotiate IPsec SAs that use home addresses. The extra conditions set by the home agent SPD for the peer phase 1 identity to be "user_1" must be verified by the home agent. The purpose of the condition is to ensure that the IKE phase 2 negotiation for a given user's home address can not be requested by another user. In the mobile node, we simply set our local identity to be "user_1".
IKEバージョン1を使用して実行する必要がありますが、ホームアドレスを使用するIPSEC SASと交渉してください。ピアフェーズ1のアイデンティティが「user_1」になるために、ホームエージェントSPDによって設定された追加の条件は、ホームエージェントによって検証する必要があります。この条件の目的は、特定のユーザーのホームアドレスのIKEフェーズ2の交渉が他のユーザーから要求できないことを確認することです。モバイルノードでは、ローカルIDを「user_1」に設定するだけです。
These checks also imply that the configuration of the home agent is user-specific: every user or home address requires a specific configuration entry. It would be possible to alleviate the configuration tasks by using certificates that have home addresses in the Subject AltName field. However, it is not clear if all IKE implementations allow one address to be used for carrying the IKE negotiations when another address is mentioned in the used certificates. In any case, even this approach would have required user-specific tasks in the certification authority.
これらのチェックは、ホームエージェントの構成がユーザー固有であることも意味します。すべてのユーザーまたはホームアドレスには特定の構成エントリが必要です。件名AltNameフィールドにホームアドレスがある証明書を使用して、構成タスクを軽減することができます。ただし、すべてのIKE実装により、使用済みの証明書に別のアドレスが記載されている場合、IKEの交渉を実施するために1つのアドレスを使用できるかどうかは明らかではありません。いずれにせよ、このアプローチでさえ、認証機関のユーザー固有のタスクが必要になるでしょう。
Protection for the return routability signaling can be configured in a similar manner as above.
返品ルー上のシグナル伝達の保護は、上記と同様の方法で構成できます。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. The SPD entries can be written using the home address (as above), if the care-of address update in the SAD is also done upon the creation of security associations.
ホームエージェントからモバイルノードまでのセキュリティ協会は、現在の住所を宛先として使用します。前述のように、このアドレスはモバイルノードが移動するにつれてSADで更新されます。SPDエントリは、セキュリティ協会の作成時にSADのCare of Addressの更新も行われる場合、自宅の住所（上記のように）を使用して記述できます。
In the following we describe some additional SPD entries to protect prefix discovery with IKE. (Note that when actual new prefixes are discovered, there may be a need to enter new manually configured SPD entries to specify the authorization policy for the resulting new home addresses.)
以下では、IKEを使用したプレフィックス発見を保護するための追加のSPDエントリについて説明します。（実際の新しいプレフィックスが発見された場合、結果の新しいホームアドレスの承認ポリシーを指定するために、新しい手動で構成されたSPDエントリを入力する必要があるかもしれないことに注意してください。）
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
Protection for the payload packets happens similarly to the protection of return routability signaling. As in the manually keyed case, these SPD entries have lower priority than the above ones.
ペイロードパケットの保護は、リターンルー上のシグナル伝達の保護と同様に発生します。手動でキーのあるケースのように、これらのSPDエントリは上記のエントリよりも優先度が低くなっています。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
Step 1. At the mobile node, Mobile IPv6 module first produces the following packet:
ステップ1.モバイルノードでは、モバイルIPv6モジュールが最初に次のパケットを生成します。
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）モビリティヘッダーバインディングアップデート
Step 2. This packet is matched against the IPsec SPD on the mobile node and we make a note that IPsec must be applied.
ステップ2.このパケットは、モバイルノードのIPSEC SPDと一致し、IPSECを適用する必要があることに注意します。
Step 3. Then, we add the necessary Mobile IPv6 options but do not change the addresses yet, as described in Section 11.3.2 of the base specification [7]. This results in:
ステップ3.次に、ベース仕様のセクション11.3.2で説明されているように、必要なモバイルIPv6オプションを追加しますが、まだアドレスを変更しません。これは次のとおりです。
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションヘッダーホームアドレスオプション（ケアオブアドレス）モビリティヘッダーバインディングアップデート
Step 4. Finally, IPsec headers are added and the necessary authenticator values are calculated:
ステップ4.最後に、IPSECヘッダーが追加され、必要な認証因子値が計算されます。
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションヘッダーホームアドレスオプション（ケアオブアドレス）ESPヘッダー（SPI = SPI_A）モビリティヘッダーバインディングアップデート
Here spi_a is the SPI value that was either configured manually, or agreed upon in an earlier IKE negotiation.
ここで、SPI_Aは、手動で構成されているか、以前のIKE交渉で合意されたSPI値です。
Step 5. Before sending the packet, the addresses in the IPv6 header and the Destination Options header are changed:
ステップ5.パケットを送信する前に、IPv6ヘッダーと宛先オプションヘッダーのアドレスが変更されます。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）Destination Optionsヘッダーホームアドレスオプション（ホームアドレス）ESPヘッダー（SPI = SPI_A）モビリティヘッダーバインディングアップデート
Step 1. The following packet is received at the home agent:
ステップ1.次のパケットがホームエージェントで受信されます。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）Destination Optionsヘッダーホームアドレスオプション（ホームアドレス）ESPヘッダー（SPI = SPI_A）モビリティヘッダーバインディングアップデート
Step 2. The home address option is processed first, which results in
ステップ2.ホームアドレスオプションは最初に処理され、その結果
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションヘッダーホームアドレスオプション（ケアオブアドレス）ESPヘッダー（SPI = SPI_A）モビリティヘッダーバインディングアップデート
Step 3. ESP header is processed next, resulting in
ステップ3. ESPヘッダーが次に処理され、その結果
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）宛先オプションヘッダーホームアドレスオプション（ケアオブアドレス）モビリティヘッダーバインディングアップデート
Step 4. This packet matches the policy required for this security association (source = home address, destination = home agent, proto = MH).
ステップ4.このパケットは、このセキュリティ協会に必要なポリシーと一致します（ソース=ホームアドレス、宛先=ホームエージェント、プロト= MH）。
Step 5. Mobile IPv6 processes the Binding Update. The Binding Update is delivered to the Mobile IPv6 module.
ステップ5.モバイルIPv6は、バインディングアップデートを処理します。バインディングアップデートは、モバイルIPv6モジュールに配信されます。
Step 6. If there are any security associations in the security association database for the protection of return routability or payload packets for this mobile node, those security associations are updated with the new care-of address.
ステップ6.このモバイルノードの返品ルーチャビリティまたはペイロードパケットの保護のために、セキュリティ協会データベースにセキュリティ協会がある場合、これらのセキュリティ協会は新しいケアオブアドレスに更新されます。
Step 1. Mobile IPv6 produces the following packet:
ステップ1.モバイルIPv6は、次のパケットを生成します。
IPv6 header (source = home agent, destination = home address) Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ホームアドレス）モビリティヘッダーバインディング謝辞
Step 2. This packet matches the IPsec policy entries, and we remember that IPsec has to be applied.
ステップ2.このパケットは、IPSECポリシーエントリと一致し、IPSECを適用する必要があることを覚えています。
Step 3. Then, we add the necessary Route Headers but do not change the addresses yet, as described in Section 9.5.4 of the base specification [7]. This results in:
ステップ3.次に、必要なルートヘッダーを追加しますが、基本仕様[7]のセクション9.5.4で説明されているように、アドレスをまだ変更しません。これは次のとおりです。
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ホームアドレス）ルーティングヘッダー（タイプ2）アドレスモビリティヘッダーバインディング承認
Step 4. We apply IPsec:
ステップ4. IPSECを適用します。
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ホームアドレス）ルーティングヘッダー（タイプ2）アドレスESPヘッダー（SPI = SPI_B）モビリティヘッダーバインディング確認
Step 5. Finally, before sending the packet out we change the addresses in the IPv6 header and the Route header:
ステップ5.最後に、パケットを送信する前に、IPv6ヘッダーとルートヘッダーのアドレスを変更します。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ルーティングヘッダー（タイプ2）ホームアドレスESPヘッダー（SPI = SPI_B）モビリティヘッダーバインディング承認
Step 1. The following packet is received at the mobile node
ステップ1.モバイルノードで次のパケットが受信されます
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ルーティングヘッダー（タイプ2）ホームアドレスESPヘッダー（SPI = SPI_B）モビリティヘッダーバインディング承認
Step 2. After the routing header is processed the packet becomes
ステップ2.ルーティングヘッダーが処理された後、パケットは
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ホームアドレス）ルーティングヘッダー（タイプ2）アドレスESPヘッダー（SPI = SPI_B）モビリティヘッダーバインディング確認
Step 3. ESP header is processed next, resulting in:
ステップ3. ESPヘッダーが次に処理され、次のようになります。
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6ヘッダー（ソース=ホームエージェント、宛先=ホームアドレス）ルーティングヘッダー（タイプ2）アドレスモビリティヘッダーバインディング承認
Step 4. This packet matches the policy required for this security association (source = home agent, destination = home address, proto = MH).
ステップ4.このパケットは、このセキュリティ協会に必要なポリシーと一致します（Source = Home Agent、Destination = Home Address、Proto = MH）。
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 module.
ステップ5.拘束力のある確認は、モバイルIPv6モジュールに配信されます。
Step 1. The mobile node constructs a Home Test Init message:
ステップ1.モバイルノードは、ホームテストINITメッセージを作成します。
IPv6 header (source = home address, destination = correspondent node) Mobility header Home Test Init
IPv6ヘッダー（ソース=ホームアドレス、宛先=特派員ノード）モビリティヘッダーホームテストinit
Step 2. Mobile IPv6 determines that this packet should go to the tunnel to the home agent.
ステップ2.モバイルIPv6は、このパケットがホームエージェントにトンネルに移動する必要があると判断します。
Step 3. The packet is matched against IPsec policy entries for the interface, and we find that IPsec needs to be applied.
ステップ3.パケットは、インターフェイスのIPSECポリシーエントリと一致しており、IPSECを適用する必要があることがわかります。
Step 4. IPsec tunnel mode headers are added. Note that we use a care-of address as a source address for the tunnel packet.
ステップ4. IPSECトンネルモードヘッダーが追加されます。トンネルパケットのソースアドレスとしてケアオブアドレスを使用していることに注意してください。
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address,
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESPヘッダー（SPI = SPI_C）IPv6ヘッダー（Source = Home Address、
destination = correspondent node) Mobility header Home Test Init
宛先=特派員ノード）モビリティヘッダーホームテストinit
Step 5. The packet is sent directly to the home agent using IPsec encapsulation.
ステップ5.パケットは、IPSECカプセル化を使用してホームエージェントに直接送信されます。
Step 1. The home agent receives the following packet:
ステップ1.ホームエージェントは次のパケットを受け取ります。
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header（SPI = SPI_C）IPv6ヘッダー（Source = Home Address、Destination = crespordent Node）Mobility Header Home Test Init
Step 2. IPsec processing is performed, resulting in:
ステップ2. IPSEC処理が実行され、次のようになります。
IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6ヘッダー（ソース=ホームアドレス、宛先=特派員ノード）モビリティヘッダーホームテストinit
Step 3. The resulting packet matches the policy required for this security association and the packet can be processed further.
ステップ3.結果のパケットは、このセキュリティ協会に必要なポリシーと一致し、パケットをさらに処理できます。
Step 4. The packet is then forwarded to the correspondent node.
ステップ4.次に、パケットが特派員ノードに転送されます。
Step 1. The home agent receives a Home Test packet from the correspondent node:
ステップ1.ホームエージェントは、特派員ノードからホームテストパケットを受け取ります。
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダー（Source = crespordentノード、宛先=ホームアドレス）モビリティヘッダーホームテストinit
Step 2. The home agent determines that this packet is destined to a mobile node that is away from home, and decides to tunnel it.
ステップ2.ホームエージェントは、このパケットが自宅から離れているモバイルノードに運命づけられていると判断し、それをトンネルすることにしました。
Step 3. The packet matches the IPsec policy entries for the tunnel interface, and we note that IPsec needs to be applied.
ステップ3.パケットは、トンネルインターフェイスのIPSECポリシーエントリと一致し、IPSECを適用する必要があることに注意してください。
Step 4. IPsec is applied, resulting in a new packet. Note that the home agent must keep track of the location of the mobile node, and update the tunnel endpoint address in the security association(s) accordingly.
ステップ4. IPSECが適用され、新しいパケットが表示されます。ホームエージェントは、モバイルノードの場所を追跡し、それに応じてセキュリティ協会のトンネルエンドポイントアドレスを更新する必要があることに注意してください。
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ESPヘッダー（SPI = SPI_D）IPv6ヘッダー（Source = crespoldent Node、Destination = Homeアドレス）モビリティヘッダーホームテストInit
Step 5. The packet is sent directly to the care-of address using IPsec encapsulation.
ステップ5.パケットは、IPSECカプセル化を使用して、ケアオブアドレスに直接送信されます。
Step 1. The mobile node receives the following packet:
ステップ1.モバイルノードは、次のパケットを受信します。
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ESPヘッダー（SPI = SPI_D）IPv6ヘッダー（Source = crespoldent Node、Destination = Homeアドレス）モビリティヘッダーホームテストInit
Step 2. IPsec is processed, resulting in:
ステップ2. IPSECが処理され、結果として以下が行われます。
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6ヘッダー（Source = crespordentノード、宛先=ホームアドレス）モビリティヘッダーホームテストinit
Step 3. This matches the policy required for this security association (source = any, destination = home address).
ステップ3.これは、このセキュリティ協会に必要なポリシーと一致します（Source = any、destination = homeアドレス）。
Step 4. The packet is given to Mobile IPv6 processing.
ステップ4.パケットは、モバイルIPv6処理に与えられます。
This procedure is similar to the one presented in Section 6.1.
この手順は、セクション6.1で提示されている手順に似ています。
This procedure is similar to the one presented in Section 6.2.
この手順は、セクション6.2に示されている手順と類似しています。
This procedure is similar to the one presented in Section 6.3.
この手順は、セクション6.3で提示されている手順に似ています。
This procedure is similar to the one presented in Section 6.4.
この手順は、セクション6.4で提示されている手順に似ています。
This procedure is similar to the one presented in Section 6.5.
この手順は、セクション6.5で提示されている手順に似ています。
This procedure is similar to the one presented in Section 6.6.
この手順は、セクション6.6で提示されている手順に似ています。
This procedure is similar to the one presented in Section 6.7.
この手順は、セクション6.7に示されている手順と類似しています。
This procedure is similar to the one presented in Section 6.8.
この手順は、セクション6.8で提示されている手順に似ています。
Step 1. The mobile node wishes to send a Binding Update to the home agent.
ステップ1.モバイルノードは、ホームエージェントにバインディングアップデートを送信したいと考えています。
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6ヘッダー（ソース=ホームアドレス、宛先=ホームエージェント）モビリティヘッダーバインディングアップデート
Step 2. There is no existing security association to protect the Binding Update, so the mobile node initiates IKE. The IKE packets are sent as shown in the following examples. The first packet is an example of an IKE packet sent from the mobile node, and the second one is from the home agent. The examples shows also that the phase 1 identity used for the mobile node is a FQDN.
ステップ2.バインディングアップデートを保護するための既存のセキュリティ協会はないため、モバイルノードはIKEを開始します。IKEパケットは、次の例に示すように送信されます。最初のパケットは、モバイルノードから送信されたIKEパケットの例であり、2番目のパケットはホームエージェントからです。例は、モバイルノードに使用されるフェーズ1の同一性がFQDNであることも示しています。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDii = ID_FQDN mn123.ha.net ...
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）UDP IKE ... IDII = ID_FQDN MN123.HA.NET ...
IPv6 header (source = home agent destination = care-of address) UDP IKE ... IDir = ID_FQDN ha.net ...
IPv6ヘッダー（Source = Home Agent Destination = Care-of Address）UDP IKE ... IDIR = ID_FQDN HA.NET ...
Step 3. IKE phase 1 completes, and phase 2 is initiated to request security associations for protecting traffic between the mobile node's home address and the home agent. These addresses will be used as selectors. This involves sending and receiving additional IKE packets. The below example shows again one packet sent by the mobile node and another sent by the home agent. The example shows also that the phase 2 identity used for the mobile node is the mobile node's home address.
ステップ3. IKEフェーズ1が完了し、フェーズ2が開始され、モバイルノードのホームアドレスとホームエージェントの間のトラフィックを保護するためのセキュリティ協会が要求されます。これらのアドレスは、セレクターとして使用されます。これには、追加のIKEパケットの送信と受信が含まれます。以下の例は、モバイルノードから送信されたパケットとホームエージェントから送信された別のパケットを再び示しています。この例は、モバイルノードに使用されるフェーズ2アイデンティティがモバイルノードのホームアドレスであることも示しています。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDci = ID_IPV6_ADDR home address ...
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）UDP IKE ... IDCI = ID_IPV6_ADDRホームアドレス...
IPv6 header (source = home agent, destination = care-of address) UDP IKE ... IDcr = ID_IPV6_ADDR home agent ...
IPv6ヘッダー（Source = Home Agent、Destination = Care-of Address）UDP IKE ... IDCR = ID_IPV6_ADDRホームエージェント...
Step 4. The remaining steps are as shown in Section 6.1.
ステップ4.残りの手順は、セクション6.1に示すとおりです。
Step 1. The mobile node and the home agent have existing security associations. Either side may decide at any time that the security associations need to be rekeyed, for instance, because the specified lifetime is approaching.
ステップ1.モバイルノードとホームエージェントには、既存のセキュリティ協会があります。たとえば、指定された寿命が近づいているため、セキュリティ協会を再キーにする必要があることをどちらの側も決定する場合があります。
Step 2. Mobility header packets sent during rekey may be protected by the existing security associations.
ステップ2. Rekey中に送信されるモビリティヘッダーパケットは、既存のセキュリティ協会によって保護される場合があります。
Step 3. When the rekeying is finished, new security associations are established. In practice there is a time interval during which an old, about-to-expire security association and newly established security association will both exist. The new ones should be used as soon as they become available.
ステップ3.再キーイングが終了すると、新しいセキュリティ協会が確立されます。実際には、古くから露出していないセキュリティ協会と新たに確立されたセキュリティ協会の両方が存在する時間間隔があります。新しいものは、利用可能になるとすぐに使用する必要があります。
Step 4. A notification of the deletion of the old security associations is received. After this, only the new security associations can be used.
ステップ4.古いセキュリティ協会の削除の通知が受信されます。この後、新しいセキュリティ協会のみを使用できます。
Note that there is no requirement that the existence of the IPsec and IKE security associations is tied to the existence of bindings. It is not necessary to delete a security association if a binding is removed, as a new binding may soon be established after this.
IPSECおよびIKEセキュリティ協会の存在がバインディングの存在に結びついているという要件はないことに注意してください。この後に新しいバインディングがすぐに確立される可能性があるため、バインディングが削除された場合、セキュリティ協会を削除する必要はありません。
Since cryptographic acceleration hardware may only be able to handle a limited number of active security associations, security associations may be deleted via IKE in order to keep the number of active cryptographic contexts to a minimum. Such deletions should not be interpreted as a sign of losing a contact to the peer or as a reason to remove a binding. Rather, if additional traffic needs to be sent, it is preferable to bring up another security association to protect it.
暗号化アクセラレーションハードウェアは限られた数のアクティブセキュリティ関連を処理できる場合があるため、アクティブな暗号化コンテキストの数を最小限に抑えるために、IKEを介してセキュリティ関連を削除することができます。このような削除は、ピアへの接触を失う兆候として、またはバインディングを削除する理由として解釈されるべきではありません。むしろ、追加のトラフィックを送信する必要がある場合は、それを保護するために別のセキュリティ協会を育てることが望ましいです。
In this section we describe the sequence of events that relate to movement with IKE-based security associations. In the initial state, the mobile node is not registered in any location and has no security associations with the home agent. Depending on whether the peers will be able to move IKE endpoints to new care-of addresses, the actions taken in Step 9 and 10 are different.
このセクションでは、IKEベースのセキュリティ協会との動きに関連する一連のイベントについて説明します。初期状態では、モバイルノードはどの場所でも登録されておらず、ホームエージェントとのセキュリティ関連はありません。ピアがIKEエンドポイントを新しいアドレスに移動できるかどうかに応じて、ステップ9と10で行われたアクションは異なります。
Step 1. Mobile node with the home address A moves to care-of address B.
ステップ1.ホームアドレス付きのモバイルノードAはアドレスのケアに移動しますB B
Step 2. Mobile node runs IKE from care-of address B to the home agent, establishing a phase 1. The home agent can only act as the responder before it knows the current location of the mobile node.
ステップ2.モバイルノードは、Care-of Address BからホームエージェントにIKEを実行し、フェーズ1を確立します。ホームエージェントは、モバイルノードの現在の場所を知る前に、レスポンダーとしてのみ機能します。
Step 3. Protected by this phase 1, mobile node establishes a pair of security associations for protecting Mobility Header traffic to and from the home address A.
ステップ3.このフェーズ1で保護されているモバイルノードは、自宅の住所との間のモビリティヘッダートラフィックを保護するためのセキュリティ協会のペアを確立します。
Step 4. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3.
ステップ4.モバイルノードは、バインディングアップデートを送信し、ステップ3で作成されたセキュリティアソシエーションを使用して拘束力のある承認を受信します。
Step 5. Mobile node establishes a pair of security associations for protecting return routability packets. These security associations are in tunnel mode and their endpoint in the mobile node side is care-of address B. For the purposes of our example, this step uses the phase 1 connection established in Step 2. Multiple phase 1 connections are also possible.
ステップ5.モバイルノードは、返品ルー上のパケットを保護するためのセキュリティ協会のペアを確立します。これらのセキュリティ関連はトンネルモードで、モバイルノード側のエンドポイントはケアオブアドレスBです。この例の目的のために、このステップではステップ2で確立されたフェーズ1接続を使用します。複数のフェーズ1接続も可能です。
Step 6. The mobile node uses the security associations created in Step 5 to run return routability.
ステップ6.モバイルノードは、ステップ5で作成されたセキュリティアソシエーションを使用して、返品ルーティング可能性を実行します。
Step 7. The mobile node moves to a new location and adopts a new care-of address C.
ステップ7.モバイルノードは新しい場所に移動し、新しい住所Cを採用します。
Step 8. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3. The home agent ensures that the next packets sent using the security associations created in Step 5 will have the new care-of address as their destination address, as if the outer header destination address in the security association had changed.
ステップ8.モバイルノードは、バインディングアップデートを送信し、ステップ3で作成されたセキュリティアソシエーションを使用して拘束力のある承認を受信します。ホームエージェントは、ステップ5で作成されたセキュリティアソシエーションを使用して送信された次のパケットが、新しいケアアドレスを彼らのものとして保証することを保証します。セキュリティ協会の外側のヘッダー宛先アドレスが変更されたかのように、宛先アドレス。
Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they do not have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and will establish a new IKE phase 1 on top of the care-of address C. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [7] in the Binding Update and Binding Acknowledgement messages.
ステップ9.モバイルノードとHAにIKEエンドポイントを変更する機能がある場合、アドレスをCに変更します。機能がない場合、両方のノードはアドレスのケアの上に作成されたフェーズ1接続を削除します。bおよびWILは、Care of Address Cの上に新しいIKEフェーズ1を確立します。IKEフェーズ1エンドポイントを変更するこの機能は、バインディングアップデートで主要な管理モビリティ機能（k）フラグ[7]を設定することで示されています。拘束力のある確認メッセージ。
Step 10. If a new IKE phase 1 connection was setup after movement, the MN will not be able to receive any notifications delivered on top of the old IKE phase 1 security association. Notifications delivered on top of the new security association are received and processed normally. If the mobile node and HA were able to update the IKE endpoints, they can continue using the same IKE phase 1 connection.
ステップ10.移動後に新しいIKEフェーズ1接続がセットアップされた場合、MNは古いIKEフェーズセキュリティ協会の上に配信される通知を受信できません。新しいセキュリティ協会の上に配信される通知は、正常に受信および処理されます。モバイルノードとHAがIKEエンドポイントを更新できた場合、同じIKEフェーズ1接続を使用し続けることができます。
Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. In general, the use of formats not required here may lead to incorrect processing of the packets by the peer (such as silently discarding them), unless support for these formats has been verified off-line. Such verification can take place at the same time the parameters of the security associations are agreed upon. In some cases, however, basic IPv6 specifications call for support of options not discussed here. In these cases, such a verification step might be unnecessary as long as the peer fully supports the relevant IPv6 specifications. However, no claims are made in this document about the validity of these other formats in the context of Mobile IPv6. It is also likely that systems that support Mobile IPv6 have been tested more extensively with the required formats.
セクション3で説明したパケット形式とヘッダーの順序付けはサポートする必要がありますが、実装も他の形式をサポートする場合があります。一般に、ここで必要とされていないフォーマットの使用は、これらの形式のサポートがオフラインで検証されていない限り、ピアによるパケットの処理が誤っていない場合（静かに廃棄するなど）。このような検証は、セキュリティ協会のパラメーターが合意されると同時に行うことができます。ただし、場合によっては、基本的なIPv6仕様では、ここでは説明していないオプションのサポートが必要です。これらの場合、ピアが関連するIPv6仕様を完全にサポートしている限り、このような検証ステップは不要になる可能性があります。ただし、このドキュメントでは、モバイルIPv6のコンテキストにおけるこれらの他の形式の有効性に関する主張はありません。また、モバイルIPv6をサポートするシステムは、必要な形式でより広範囲にテストされている可能性があります。
We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to require support for the shorter packet formats both for payload and return routability packets.
リターンルーチャ性とペイロードパケット保護のためにカプセル化形式を要求することを選択しました。これは、モバイルノードが移動するときにホームエージェントから送信されたIPSECパケットの宛先を変更できる場合にのみ実現できます。このようなフォーマットを選択する主な理由の1つは、ホームアドレスオプションまたはルーティングヘッダーがトンネルパケットに追加されたときに24バイトのオーバーヘッドを削除することです。このようなオーバーヘッドは、返品ルー上のパケットの保護には重要ではありませんが、Payloadパケットのトンネルをホームエージェントに保護するためにIPSecを使用すると、追加のオーバーヘッドが作成されます。このオーバーヘッドは、リアルタイムトラフィックにとって重要な場合があります。トラフィックに短いパケット形式を使用するには、適切なAPIの存在が必要であることを考えると、ペイロードと返品のルー上のパケットの両方でより短いパケット形式のサポートが必要になることを選択しました。
In order to support the care-of address as the destination address on the mobile node side, the home agent must act as if the outer header destination address in the security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address.
モバイルノード側の宛先アドレスとしてのアドレスのケアをサポートするために、ホームエージェントは、モバイルノードのセキュリティ協会の外側のヘッダー宛先アドレスが動きで変更されたかのように行動する必要があります。実装は、APIをIPSEC実装に使用してセキュリティ協会のパラメーターを変更し、セキュリティ協会を削除し、新しいものをインストールしたり、パケットを変更した後の変更を変更したなど、この変更を行うための特定の方法を自由に選択できます。IPSEC処理を介して。唯一の要件は、ホームエージェントに新しいバインディングを登録した後、このセキュリティ協会に送信された次のIPSECパケットが新しい住所に宛てられることです。
We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. A further complication of the IPsec processing on a tunnel interface is that this requires access to the BITS implementation before the packet actually goes out.
トンネルインターフェイスに固有のポリシーエントリを要求することを選択しました。これは、実装がホームエージェント - モバイルノードトンネルを、IPSEC SPDのベースにできる別のインターフェイスと見なす必要があることを意味します。トンネルインターフェイスでのIPSEC処理のさらに複雑さは、これにはパケットが実際に消える前にビットの実装にアクセスする必要があることです。
We have chosen to require that a dynamic key management protocol must be able to make an authorization decision for IPsec security association creation with different addresses than with what the key management protocol is run. We expect this to be done typically by configuring the allowed combinations of phase 1 user identities and home addresses.
動的なキー管理プロトコルが、主要な管理プロトコルが実行されるものよりも異なるアドレスを使用して、IPSECセキュリティ協会の作成に対して承認決定を下すことができなければならないことを要求することを選択しました。これは通常、フェーズ1ユーザーのアイデンティティとホームアドレスの許可された組み合わせを構成することで行われると予想しています。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even with single certificates if they are large. Many firewalls do not handle fragments properly, and may drop them. Routers in the path may also discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an access list. Where fragmentation occurs, the endpoints will not always be able to establish a security association.
証明書認証が使用されると、IKEの断片化に遭遇する可能性があります。これは、証明書チェーンが使用されている場合、またはそれらが大きい場合は単一の証明書を使用しても発生する可能性があります。多くのファイアウォールはフラグメントを適切に処理せず、ドロップする場合があります。パス内のルーターは、通常、アクセスリストと比較できる完全なIPヘッダーが含まれていないため、最初のルーターの後に断片を破棄する場合があります。断片化が発生する場合、エンドポイントは常にセキュリティ協会を確立できるとは限りません。
Fortunately, typical Mobile IPv6 deployment uses short certificate chains, as the mobile node is communicating directly with its home network. Where the problem appears, it may be difficult (at least away from home) to replace the firewalls or routers with equipment that can properly support fragments. It may help to store the peer certificates locally, or to obtain them through other means.
幸いなことに、モバイルノードはホームネットワークと直接通信しているため、典型的なモバイルIPv6展開では短い証明書チェーンが使用されます。問題が現れる場合は、（少なくとも自宅から離れて）、ファイアウォールまたはルーターをフラグメントを適切にサポートできる機器に置き換えることが難しい場合があります。ピア証明書をローカルに保存したり、他の手段でそれらを取得するのに役立ちます。
Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As Mobile IPv6 specific modifications of the packets are required before or after IPsec processing, the BITS implementation has to perform also some tasks related to mobility. This may increase the complexity of the implementation, even if it already performs some tasks of the IP layer (such as fragmentation).
モバイルIPv6は、IPSECのいわゆるバンプイン（ビット）実装モデルの高い要件を設定します。IPSEC処理の前後にパケットのモバイルIPv6固有の変更が必要であるため、BITS実装はモビリティに関連するいくつかのタスクも実行する必要があります。これにより、IPレイヤーのいくつかのタスク（断片化など）を既に実行していても、実装の複雑さが増加する可能性があります。
Specifically, Bump-in-the-Stack implementations may have to deal with the following issues:
具体的には、バンプインザスタックの実装は、次の問題に対処する必要がある場合があります。
o Processing the Home Address destination option and Routing header type 2 to a form suitable for IPsec processing to take place. This is needed, among other things, for the security association and policy lookups. While relatively straightforward, the required processing may have a hardware effect in BITS implementations, if they use hardware support beyond the cryptographic operations.
o ホームアドレスの宛先オプションとルーティングヘッダータイプ2の処理IPSEC処理が行われるのに適したフォームにルーティングされます。これは、とりわけ、セキュリティ協会とポリシーの検索に必要です。比較的簡単ですが、必要な処理は、暗号化操作を超えてハードウェアサポートを使用する場合、ビットの実装でハードウェア効果を持つ場合があります。
o Detecting packets sent between the mobile node and its home agent using IPv6 encapsulation.
o IPv6カプセル化を使用して、モバイルノードとそのホームエージェント間で送信されるパケットの検出。
o Offering the necessary APIs for updating the IPsec and IKE security association endpoints.
o IPSECおよびIKE Security Associationのエンドポイントを更新するために必要なAPIを提供します。
No IANA actions are necessary based on this document. IANA actions for the Mobile IPv6 protocol itself have been covered in [7].
このドキュメントに基づいてIANAアクションは必要ありません。モバイルIPv6プロトコル自体のIANAアクションは[7]でカバーされています。
The Mobile IPv6 base specification [7] requires strong security between the mobile node and the home agent. This memo discusses how that security can be arranged in practice, using IPsec. The security considerations related to this are documented in the base specification, including a discussion of the implications of using either manual or dynamic keying.
モバイルIPv6ベース仕様[7]には、モバイルノードとホームエージェントの間の強力なセキュリティが必要です。このメモでは、IPSECを使用して、そのセキュリティを実際にどのように配置できるかについて説明します。これに関連するセキュリティの考慮事項は、手動または動的キーイングを使用することの意味についての議論を含む、基本仕様に文書化されています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[3] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[4] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[6] Conta、A。and S. Deering、「IPv6仕様における一般的なパケットトンネル」、RFC 2473、1998年12月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[7] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[8] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Deering、S.、Fenner、W。and B. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[10] Droms、R.、Ed。、Bound。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[11] Vida、R。and L. Costa、eds。、「Multicast Riesder Discoveryバージョン2（MLDV2）のIPv6」、RFC 3810、2004年6月。
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel Montenegro, Steven Kent, and Santeri Paavolainen for interesting discussions in this problem space.
著者は、グレッグ・オシェア、マイケル・トーマス、ケビン・マイルズ、シェリル・マドソン、バーナード・アボバ、エリック・ノードマーク、ガブリエル・モンテネグロ、スティーブン・ケント、サンテリ・パボラネンに、この問題の分野での興味深い議論に感謝します。
Jari Arkko Ericsson 02420 Jorvas Finland
Jari Arkko Ericsson 02420 Jorvas Finland
EMail: jari.arkko@ericsson.com
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
EMail: vijayd@iprg.nokia.com
Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
フランシス・デュポン・エンスト・ブルターニュ・キャンパス・デ・レンヌ2、rue de de la Chataigneraie CS 17607 35576 CESSON-SEVIGNE CEDEX FRANCE
EMail: Francis.Dupont@enst-bretagne.fr
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。