RFC4877 日本語訳
4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsecArchitecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT=57941 bytes) (Updates RFC3776) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Devarapalli
Request for Comments: 4877 Azaire Networks
Updates: 3776 F. Dupont
Category: Standards Track CELAR
April 2007
Devarapalliがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4877Azaireはアップデートをネットワークでつなぎます: 3776年のF.デュポンカテゴリ: 標準化過程CELAR2007年4月
Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
IKEv2とのモバイルIPv6操作と改訂されたIPsecアーキテクチャ
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2.
このドキュメントは改訂されたIPsecアーキテクチャとIKEv2とのモバイルIPv6操作について説明します。
Devarapalli & Dupont Standards Track [Page 1] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[1ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 10
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 12
6.2. Return Routability Messages . . . . . . . . . . . . . . . 13
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 14
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 15
7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 16
7.2.2. Return Routability Messages . . . . . . . . . . . . . 17
7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Security Association Negotiation Using IKEv2 . . . . . . . 18
7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
8. The Use of EAP Authentication . . . . . . . . . . . . . . . . 21
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . . . 4 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1。 一般要件. . . . . . . . . . . . . . . . . . . 5 4.2。 方針要件. . . . . . . . . . . . . . . . . . . 5 4.3。 IPsecは処理所要. . . . . . . . . . 7 4.4について議定書の中で述べます。 要件. . . . . . . . . . . . . . . 9 5を合わせる動力。 セレクタ粒状問題. . . . . . . . . . . . . 10 6。 手動の構成. . . . . . . . . . . . . . . . . . . . . 11 6.1。 アップデートと承認. . . . . . . . . . . 12 6.2を縛ります。 メッセージ. . . . . . . . . . . . . . . 13 6.3をRoutabilityに返してください。 モバイル接頭語発見メッセージ. . . . . . . . . . . . . 14 6.4。 有効搭載量パケット. . . . . . . . . . . . . . . . . . . . . 14 7。 動的設定. . . . . . . . . . . . . . . . . . . . 15 7.1。 同輩承認データベースエントリー. . . . . . . . . . . 15 7.2。 安全保障政策データベースエントリー. . . . . . . . . . . . . 15 7.2.1。 アップデートと承認. . . . . . . . . 16 7.2.2を縛ります。 Routabilityメッセージ. . . . . . . . . . . . . 17 7.2.3を返してください。 モバイル接頭語発見メッセージ. . . . . . . . . . . 17 7.2.4。 有効搭載量パケット. . . . . . . . . . . . . . . . . . . 18 7.3。 IKEv2. . . . . . . 18 7.4を使用するセキュリティ協会交渉。 運動とダイナミックな合わせ. . . . . . . . . . . . . . . 20 8ること。 EAP認証. . . . . . . . . . . . . . . . 21 9の使用。 ダイナミックなホームアドレス構成. . . . . . . . . . . . . . 22 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 24 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1。 引用規格. . . . . . . . . . . . . . . . . . . 24 12.2。 有益な参照. . . . . . . . . . . . . . . . . . 24
Devarapalli & Dupont Standards Track [Page 2] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[2ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
1. Introduction
1. 序論
RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used with Mobile IPv6 [2] to protect the signaling messages. It also illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages.
RFC3776はRFC2401[11]で説明されるIPsecがシグナリングメッセージを保護するのにモバイルIPv6[2]と共にどう使用されるかを説明します。 また、それはモバイルIPv6シグナリングメッセージを保護するのに使用できるSecurity Policy DatabaseとSecurity Association Databaseエントリーに関する例を例証します。
The IPsec architecture has been revised in RFC 4301 [5]. Among the many changes, the list of selectors has been expanded to include the Mobility Header message type. This has an impact on how security policies and security associations are configured for protecting mobility header messages. It becomes easier to differentiate between the various Mobility Header messages based on the type value instead of checking if a particular mobility header message is being sent on a tunnel interface between the mobile node and the home agent, as it was in RFC 3776. The revised IPsec architecture specification also includes ICMP message type and code as selectors. This makes it possible to protect Mobile Prefix Discovery messages without applying the same security associations to all ICMPv6 messages.
IPsecアーキテクチャはRFC4301[5]で改訂されました。 多くの変化の中では、Mobility Headerメッセージタイプを含むようにセレクタのリストを広げてあります。 これは安全保障政策とセキュリティ協会が移動性ヘッダーメッセージを保護するためにどう構成されるかに影響を与えます。 特定の移動性ヘッダーメッセージがモバイルノードとホームのエージェントとのトンネルのインタフェースで送られるかどうかチェックすることの代わりにタイプ値に基づく様々なMobility Headerメッセージを区別するのは、より簡単になります、それがRFC3776にあったとき。 また、改訂されたIPsecアーキテクチャ仕様はセレクタとしてICMPメッセージタイプとコードを含んでいます。 これで、同じセキュリティ協会をすべてのICMPv6メッセージに適用しないでモバイルPrefixディスカバリーメッセージを保護するのは可能になります。
This document discusses new requirements for the home agent and the mobile node to use the revised IPsec architecture and IKEv2. Section 4 lists the requirements. Sections 6 and 7 describe the required Security Policy Database (SPD) and Security Association Database (SAD) entries.
このドキュメントはホームのエージェントとモバイルノードが改訂されたIPsecアーキテクチャとIKEv2を使用するという新しい要件について議論します。 セクション4は要件をリストアップします。 セクション6と7は必要なSecurity Policy Database(SPD)とSecurity Association Database(SAD)エントリーについて説明します。
The Internet Key Exchange (IKE) protocol has also been substantially revised and simplified [4]. Section 7.3 of this document describes how IKEv2 can be used to set up security associations for Mobile IPv6.
また、インターネット・キー・エクスチェンジ(IKE)プロトコルは実質的に改訂されて、簡易型の[4]です。 このドキュメントのセクション7.3はモバイルIPv6のためにセキュリティ協会を設立するのにどうIKEv2を使用できるかを説明します。
The use of EAP within IKEv2 is allowed to authenticate the mobile node to the home agent. This is described in Section 8. A method for dynamically configuring a home address from the home agent using the Configuration Payload in IKEv2 is described in Section 9.
IKEv2の中のEAPの使用はホームのエージェントにモバイルノードを認証できます。 これはセクション8で説明されます。 IKEv2でConfiguration有効搭載量を使用することでダイナミックにホームのエージェントからのホームアドレスを構成するためのメソッドはセクション9で説明されます。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
Devarapalli & Dupont Standards Track [Page 3] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[3ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
3. Packet Formats
3. パケット・フォーマット
The mobile node and the home agent MUST support the packet formats as defined in Section 3 of RFC 3776.
モバイルノードとホームのエージェントはRFC3776のセクション3で定義されるようにパケット・フォーマットを支えなければなりません。
In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent. The packet format for the binding update when sent in the tunnel mode looks as follows.
モバイルノード逆がモバイルノードとホームのエージェントの間で交換されたモバイルIPv6シグナリングメッセージを含むすべてのトラフィックにトンネルを堀るといけないので、そして、ホームAddress Optionがホームのエージェントに送られたメッセージに存在させているのが必要ではありません。 トンネルモードで送ると、拘束力があるアップデートのためのパケット・フォーマットは以下の通りに見えます。
IPv6 hdr (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 hdr (source = home address,
destination = home agent)
Mobility Header
Binding Update
Alternate Care-of Address option (care-of address)
IPv6 hdr、(ソース=、注意、-、アドレス、目的地=ホームエージェント) トンネルモードIPv6 hdr(ソースはホームアドレスと等しいです、目的地=ホームエージェント)の移動性における超能力ヘッダー、Header Binding Update Alternate Care、-、Addressオプション(注意、-、アドレス)
The binding acknowledgement sent to the mobile node when it is away from the home link looks as follows.
それがホームのリンクから離れているときモバイルノードに送られた拘束力がある承認は以下の通りに見えます。
IPv6 hdr (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 hdr (source = home agent,
destination = home address)
Mobility Header
Binding Acknowledgement
IPv6 hdr、(ソースはホームのエージェントと等しいです、目的地=、注意、-、アドレス、)、トンネルモードIPv6 hdr(ソースはホームのエージェントと等しいです、目的地=ホームアドレス)移動性Header Binding Acknowledgementによる超能力ヘッダー
The packet formats for tunneled mobile prefix discovery messages are very similar to the tunneled Binding Update and Binding Acknowledgment with the with the home address as the source address in the inner IP header.
トンネルを堀られたモバイルのためのパケット・フォーマットがメッセージがトンネルを堀られたBinding Updateと非常に同様であるという発見とBinding Acknowledgmentを前に置く、内側のIPヘッダーのソースアドレスとしてのホームアドレスで。
The support for the above tunneled packet format is optional on the mobile node and the home agent.
上のトンネルを堀られたパケット・フォーマットのサポートはモバイルノードとホームのエージェントで任意です。
4. Requirements
4. 要件
This section describes mandatory rules and requirements for all Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as the key management protocol, can be used to protect traffic between the mobile node and the home agent. Many of the requirements are repeated from RFC 3776 to make this document self-contained and complete.
このセクションは、モバイルノードとホームのエージェントの間のトラフィックを保護するのにかぎ管理プロトコルとしてのIKEv2と共にIPsecを使用できるようにすべてのモバイルIPv6モバイルノードとホームのエージェントのための委任統治と要件について説明します。 要件の多くが、このドキュメントを自己充足的で完全にするようにRFC3776から繰り返されます。
Devarapalli & Dupont Standards Track [Page 4] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[4ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
4.1. General Requirements
4.1. 一般要件
o RFC 3775 states that manual configuration of IPsec security
associations MUST be supported, and automated key management MAY
be supported. This document does not make any recommendations
regarding the support of manual IPsec configuration and dynamic
IPsec configuration. This document just describes the use of
manually created IPsec security associations and the use of IKEv2
as the automated IPsec key management protocol for protecting
Mobile IPv6 signaling messages.
o RFC3775はIPsecセキュリティ協会の手動の構成をサポートしなければならなくて、自動化されたかぎ管理がサポートされるかもしれないと述べます。 このドキュメントは手動のIPsecのサポートに関する少しの推薦状も構成とダイナミックなIPsec構成にしません。 自動化されたIPsecかぎ管理がモバイルIPv6シグナリングメッセージを保護するために議定書を作るとき、このドキュメントはただ手動で作成されたIPsecセキュリティ協会の使用とIKEv2の使用について説明します。
o ESP encapsulation for Binding Updates and Binding Acknowledgements
MUST be supported and used.
o Binding UpdatesとBinding Acknowledgementsのための超能力カプセル化をサポートされて、使用しなければなりません。
o ESP encapsulation in tunnel mode for the Home Test Init (HoTi) and
Home Test (HoT) messages tunneled between the mobile node and the
home agent MUST be supported and SHOULD be used.
o 超能力カプセル化は中でモードにトンネルを堀ります。トンネルを堀られて、モバイルノードとホームのエージェントをサポートしなければならないというホームTest Init(HoTi)とホームTest(HoT)メッセージとSHOULDには、使用されてください。
o ESP encapsulation of the ICMPv6 messages related to mobile prefix
discovery MUST be supported and SHOULD be used.
o ICMPv6メッセージの超能力カプセル化は発見をサポートしなければならないモバイル接頭語とSHOULDに関連しました。使用されます。
o ESP encapsulation of the payload packets tunneled between the
mobile node and the home agent MAY be supported and used.
o モバイルノードとホームのエージェントの間でトンネルを堀られたペイロードパケットの超能力カプセル化は、サポートされて、使用されるかもしれません。
o If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data
protection MUST be supported for those protocols.
o マルチキャストグループ会員資格制御プロトコルかstatefulアドレス自動構成プロトコルがサポートされるなら、それらのプロトコルのためにペイロードデータ保護をサポートしなければなりません。
o The home agent and the mobile node MAY support authentication
using EAP in IKEv2 as described in Section 8.
o セクション8で説明されるようにIKEv2でEAPを使用して、ホームのエージェントとモバイルノードは認証を支えるかもしれません。
o The home agent and the mobile node MAY support remote
configuration of the home address as described in Section 9. When
the home agent receives a configuration payload with a CFG_REQUEST
for INTERNAL_IP6_ADDRESS, it must reply with a valid home address
for the mobile node. The home agent can pick a home address from
a local database or from a DHCPv6 server on the home link.
o ホームのエージェントとモバイルノードはセクション9で説明されるようにホームアドレスのリモート構成を支えるかもしれません。 ホームのエージェントがINTERNAL_IP6_ADDRESSのためにCFG_REQUESTと共に構成ペイロードを受け取るとき、それはモバイルノードのための有効なホームアドレスで返答しなければなりません。 ホームのエージェントはホームのリンクの上にローカルのデータベースかDHCPv6サーバからのホームアドレスを選ぶことができます。
4.2. Policy Requirements
4.2. 方針要件
The following requirements are related to the configuration of the security policy database on the home agent and the mobile node.
以下の要件はホームのエージェントとモバイルノードに関する安全保障政策データベースの構成に関連します。
o RFC 3776 required configuration of the security policies per
interface in order to be able to differentiate between mobility
header messages sent to the home agent and those tunneled through
the home agent to the correspondent node. Since the Mobility
Header message type is a selector, it is now easy to differentiate
o RFC3776はホームのエージェントに送られた移動性ヘッダーメッセージを区別できるように1インタフェースあたりの安全保障政策の構成を必要としました、そして、それらはホームのエージェントを通して通信員ノードにトンネルを堀りました。 Mobility Headerメッセージタイプがセレクタであるので、差別化するのは現在、簡単です。
Devarapalli & Dupont Standards Track [Page 5] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[5ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
between HoTi and HoT messages from other mobility header messages.
Therefore per-interface configuration of security policies is not
required for protecting mobility header messages. Note that
without per-interface security policies, payload packet protection
is limited to packets originating/terminating at the home address.
Traffic using a link local address within the Mobile IP tunnel
cannot be provided IPsec protection without per-interface security
policies.
他の移動性ヘッダーメッセージからのHoTiとHoTメッセージの間で。 安全保障政策のしたがって、インタフェースあたりの構成は、移動性ヘッダーメッセージを保護するのに必要ではありません。 1インタフェースあたりの安全保障政策がなければ、ペイロードパケット保護がホームアドレスで終わりながら/を溯源するパケットに制限されることに注意してください。 1インタフェースあたりの安全保障政策なしでモバイルIPトンネルの中でリンクローカルアドレスを使用するトラフィックにIPsec保護を提供できません。
o The home agent MUST be able to prevent a mobile node from using
its security association to send a Binding Update on behalf of
another mobile node. With manual IPsec configuration, the home
agent MUST be able to verify that a security association was
created for a particular home address. With dynamic keying, the
home agent MUST be able to verify that the identity presented in
the IKE_AUTH exchange is allowed to create security associations
for a particular home address.
o ホームのエージェントは、モバイルノードが別のモバイルノードを代表してBinding Updateを送るセキュリティ協会を使用するのを防ぐことができなければなりません。 手動のIPsec構成で、ホームのエージェントは、セキュリティ協会が特定のホームアドレスのために創設されたことを確かめることができなければなりません。 ダイナミックな合わせることで、ホームのエージェントは、イケ_AUTH交換で提示されたアイデンティティが特定のホームアドレスのためにセキュリティ協会を創設できることを確かめることができなければなりません。
o The home agent uses the Peer Authorization Database (PAD) [5] to
store per-mobile node state. More specifically the per-mobile
state stores information that is used to authenticate the mobile
node and the authorization information that ties the mobile node's
identity to the home address of the mobile node. This will allow
the home agent to prevent a mobile node from creating IPsec
security associations for another mobile node's home address. In
case of dynamic home address assignment, the home agent creates a
temporary PAD entry linking the authenticated peer identity and
the newly allocated home address.
o ホームのエージェントは、1モバイルあたりのノード状態を保存するのにPeer Authorization Database(PAD)[5]を使用します。 より明確に1モバイルあたりの州はモバイルノードを認証するのに使用される情報とモバイルノードのアイデンティティをモバイルノードに関するホームアドレスに結ぶ承認情報を保存します。 これで、ホームのエージェントは、モバイルノードが別のモバイルノードのホームアドレスのためにIPsecセキュリティ協会を創設するのを防ぐことができるでしょう。 ダイナミックなホームアドレス課題の場合には、ホームのエージェントは、認証された同輩のアイデンティティと新たに割り当てられたホームアドレスをリンクしながら、一時的なPADエントリーを作成します。
o As required in the base specification [2], 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 受信ノードに運命づけられたパケットがセキュリティ協会のIPsec安全保障政策かセレクタに取り組まされるとき、必要に応じて、基礎仕様[2]では、ホームAddress目的地オプションに現れるアドレスはパケットのソースアドレスであるとみなされます。
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ヘッダーの前に現れることに注意してください。 .2のセクション11.3基礎仕様がこれのための1つの可能な実装アプローチについて説明します: パケットがモバイルIPv6規則単位でまだ変更されていないか、またはモバイルIPv6処理の後に正規形に返されたとき、IPsec政策運営を実行できます。 すなわち、ホームAddressオプションの処理は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 同様に、受信ノードを運命づけられたType2ルート設定ヘッダーの中のホームアドレスはパケットの送付先アドレスであるとみなされます、パケットがセキュリティ協会のIPsec安全保障政策かセレクタに取り組まされるとき。
Devarapalli & Dupont Standards Track [Page 6] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[6ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
Similar implementation considerations apply to the Routing header
processing as was described above for the Home Address destination
option.
同様の実装問題はホームAddress目的地オプションのために上で説明されたルート設定ヘッダー処理に適用されます。
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, SHOULD 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,
Binding Acknowledgements and Mobile Prefix Discovery messages
SHOULD NOT be deleted as they do not depend on care-of addresses
and can be used again.
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. 安全保障政策エントリーであり、どれが保護に使用されたかがトラフィックにトンネルを堀りました。モバイルノードとホームのエージェント、SHOULDの間では、不活発に(例えばAPIを通してそれらを取り外して、後でそれらをインストールして戻すことによって)作られてください。 それらがどう作成されたかによって、対応するセキュリティ協会をそれらが維持されたように維持したか、または削除できました。 期限が切れるとき、セキュリティ協会がダイナミックにIKEを使用することで創設されたなら、それらは自動的に削除されます。 セキュリティ協会が手動の構成を通して創設されたなら、モバイルノードが後で再びホームから遠くに移行するとき、それらを保有されて、使用しなければなりません。 そして、セキュリティ協会、Binding Updates、Binding Acknowledgements、およびモバイルPrefixディスカバリーメッセージSHOULD NOTを保護して、よらないで削除されてください、オンである、注意、-、アドレス、再び使用できます。
o The mobile node MUST use the Home Address destination option in
Binding Updates and Mobile Prefix Solicitations when transport
mode IPsec protection is used, so that the home address is visible
when the IPsec policy checks are made.
o 交通機関IPsec保護が使用されているとき、モバイルノードはBinding UpdatesとモバイルPrefix SolicitationsのホームAddress目的地オプションを使用しなければなりません、IPsec方針チェックをするとき、ホームアドレスが目に見えるように。
o The home agent MUST use the Type 2 Routing header in Binding
Acknowledgements and Mobile Prefix Advertisements sent to the
mobile node when transport mode IPsec protection is used, again
due to the need to have the home address visible when the policy
checks are made.
o ホームのエージェントは交通機関IPsec保護が使用されているときモバイルノードに送られたBinding AcknowledgementsとモバイルPrefix AdvertisementsでType2ルート設定ヘッダーを使用しなければなりません、方針チェックをするとき目に見えるホームアドレスを持つ再び必要性のため。
4.3. IPsec Protocol Processing Requirements
4.3. IPsecプロトコル処理所要
The following lists requirements for IPsec processing at the Home Agent and the mobile node.
ホームのエージェントとモバイルノードでのIPsec処理のための以下のリスト要件。
o The home agent and mobile node SHOULD support Mobility Header
message type as an IPsec selector.
o ホームのエージェントとモバイルノードSHOULDは、IPsecセレクタとしてMobility Headerがメッセージタイプであるとサポートします。
o The home agent and mobile node SHOULD support ICMPv6 message type
as an IPsec selector.
o ホームのエージェントとモバイルノードSHOULDは、IPsecセレクタとしてICMPv6がメッセージタイプであるとサポートします。
o The home agent MUST be able to distinguish between HoTi messages
sent to itself (when it is acting as a Correspondent Node) and
those sent to Correspondent Nodes (when it is acting as a home
agent) based on the destination address of the packet.
o ホームのエージェントはそれ自体に送られたHoTiメッセージを見分けることができなければなりません、そして、(Correspondent Nodeとして機能しているとき)それらはパケットの送付先アドレスに基づくCorrespondent Nodes(ホームのエージェントとして務めているとき)に発信しました。
Devarapalli & Dupont Standards Track [Page 7] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[7ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
o When securing Binding Updates, Binding Acknowledgements, and
Mobile Prefix Discovery messages, both the mobile node and the
home agent MUST support the use of the Encapsulating Security
Payload (ESP) [6] 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. The use of sequence number in the ESP header to
provide anti-replay protection is optional because the sequence
numbers in the Binding Updates provide anti-replay protection.
However, the anti-replay protection fails if the home agent loses
the binding cache state, for example, due to a reboot. Since the
IPsec security association state can also be assumed to be lost,
ESP cannot provide anti-replay protection in this case. Complete
anti-replay protection can only be provided by the use of a
dynamic keying mechanism, like IKEv2.
o Binding Updates、Binding Acknowledgements、およびモバイルPrefixにディスカバリーメッセージを保証するとき、モバイルノードとホームのエージェントの両方が、交通機関におけるEncapsulating Security有効搭載量(超能力)[6]ヘッダーの使用をサポートしなければならなくて、データ発生源認証、コネクションレスな保全、および任意の反反復操作による保護を提供するのに非ヌルペイロード認証アルゴリズムを使用しなければなりません。 Binding Updatesの一連番号が反反復操作による保護を提供するので、反反復操作による保護を提供する超能力ヘッダーにおける一連番号の使用は任意です。 しかしながら、例えば、ホームのエージェントがリブートのため拘束力があるキャッシュ状態を失うなら、反反復操作による保護は失敗します。 また、IPsecセキュリティ協会状態が失われると思うことができて、超能力はこの場合反反復操作による保護を提供できません。 IKEv2のようにメカニズムを合わせる動力の使用で完全な反反復操作による保護を提供できるだけです。
Support for protecting these messages using ESP in tunnel mode is
optional.
トンネルモードで超能力を使用することでこれらのメッセージを保護するサポートは任意です。
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とSHOULDにトンネルを堀ってください。パケットの保護には、リターンroutability手順に属しながら、使用されてください。 非ヌルの暗号化変換と非ヌルの認証アルゴリズムを適用しなければなりません。
o When ESP is used to protect Binding Updates, there is no
protection for the care-of address that 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.
o いつの間、超能力がBinding Updatesを保護するのに使用されて、ノー・プロテクションがあるか、注意、-、領域の外のIPv6ヘッダーに現れるアドレスは超能力によって保護されました。 ホームのエージェントがそれについて確かめるのが、重要である、注意、-、アドレス、いじられていません。 その結果、攻撃者はモバイルノードのトラフィックを別のアドレスに向け直したでしょう。 モバイルIPv6実装がこれを防ぐのに使用されなければならない、Alternate Care、-、ホームから離れていますが、モバイルノードによって送られたBinding UpdatesのAddress移動性オプション。 これへの例外はモバイルノードが反-登録するためにホームのエージェントに家に帰って、Binding Updateを送る時です。
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.
いつにIPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されて、モバイルノードがそれが出発しているトンネルパケットに使用するソースアドレスを設定しなければならないか、電流、初期医療、-、アドレス
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
o IPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されるとき、IPsecセキュリティ協会がこの保護を提供するのが必要です。 いつ、注意、-、モバイルノードのためのアドレスは受け入れられたBinding Updateの結果、変化して、特別な処理がこれらのセキュリティ協会が使用させられた次のパケットに必要であるか。 ホームのエージェントが新しさを設定しなければならない、注意、-、これらのパケットの送付先アドレスとしてのアドレス、外側のヘッダー
Devarapalli & Dupont Standards Track [Page 8] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[8ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
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.
セキュリティ協会における送付先アドレスは変化しました。 同様に、ホームのエージェントはモバイルノードから受け取られたトンネルパケットで新しいソースアドレスを予想し始めます。
Such address changes can be implemented, for instance, through an
API from the Mobile IPv6 implementation to the IPsec
implementation. One such API is described in [12]. 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.
例えば、APIを通してモバイルIPv6実装からIPsec実装までそのようなアドレス変化を実装することができます。 そのようなAPIの1つは[12]で説明されます。 ホームのエージェントによって受け取られて、IPsecの使用で保護されたBinding Updatesに基づいてそのようなAPIの使用とアドレス変化をするだけでよいことに注意されるべきです。 他のソースに基づく通信員ノードへのBinding Updatesなどのアドレス変更が折り返し、routabilityを保護したか、またはどんなアプリケーションからのAPIへの開架もセキュリティの脆弱性をもたらすかもしれません。
4.4. Dynamic Keying Requirements
4.4. 要件を合わせる動力
The following requirements are related to the use of a dynamic key management protocol by the mobile node and the home agent. Section 7.3 describes the use of IKEv2 as the dynamic key management protocol.
以下の要件はモバイルノードとホームのエージェントによるダイナミックなかぎ管理プロトコルの使用に関連します。 セクション7.3はダイナミックなかぎ管理プロトコルとしてIKEv2の使用を記述します。
o The mobile node MUST use its care-of address as source address in
protocol exchanges, when using dynamic keying.
o モバイルノードが使用しなければならない、それ、注意、-、ソースアドレスとして、プロトコルでは、ダイナミックな合わせることを使用するときには交換を扱ってください。
o The mobile node and the home agent MUST create security
associations based on the home address, so that the security
associations survive changes in care-of address. When using IKEv2
as the key exchange protocol, the home address should be carried
as the initiator IP address in the TSi payload during the
CREATE_CHILD_SA exchange [4].
o モバイルノードとホームのエージェントはホームアドレスに基づくセキュリティ協会を創設しなければなりません、セキュリティ協会が中で変化を乗り切るように注意、-、アドレス 主要な交換プロトコルとしてIKEv2を使用するとき、ホームアドレスはCREATE_CHILD_SA交換[4]の間のTSiペイロードの創始者IPアドレスとして運ばれるべきです。
o If the mobile node has used IKEv2 to establish security
associations with its home agent, it should follow the procedures
discussed in Sections 11.7.1 and 11.7.3 of the base specification
[2] to determine whether the IKE endpoints can be moved or if the
SAs, including the IKEv2 SA, have to be re-established.
o モバイルノードがホームのエージェントとのセキュリティ仲間を証明するのにIKEv2を使用したなら、セクション11.7.1で議論した手順に従うべきです、そして、11.7に、決定する.3の基礎仕様[2]がIKE終点を動かすことができるか、IKEv2 SAを含むSAsであるなら復職しなければなりません。
o If the home agent has used IKEv2 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
[2] to determine whether the IKE endpoints can be moved or if the
SAs, including the IKEv2 SA, have to be re-established.
o ホームのエージェントがモバイルノードとのセキュリティ協会を証明するのにIKEv2を使用したなら、セクション10.3.1で議論した手順に従うべきです、そして、10.3に、決定する.2の基礎仕様[2]がIKE終点を動かすことができるか、IKEv2 SAを含むSAsであるなら復職しなければなりません。
Devarapalli & Dupont Standards Track [Page 9] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[9ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
5. Selector Granularity Considerations
5. セレクタ粒状問題
IPsec implementations are compatible with this document even if they do not support fine-grain selectors such as the Mobility Header message type and ICMPv6 message type. Note that such IPsec implementations are not compliant with RFC 4301 [5]. For various reasons, some implementations may choose to support only coarse-grain selectors (i.e., addresses and in some cases the protocol field) for forwarded traffic. As finer-grain selectors give better control, i.e., the protection is only applied when required, the examples in this document always use the finest granularity.
細粒がMobility HeaderメッセージタイプやICMPv6メッセージタイプなどのセレクタであるとサポートしないでも、IPsec実装はこのドキュメントと互換性があります。 そのようなIPsec実装がRFC4301[5]で対応でないことに注意してください。 様々な理由で、いくつかの実装が、進められたトラフィックのために唯一の粗粉がセレクタ(すなわち、アドレスといくつかの場合プロトコル分野)であるとサポートするのを選ぶかもしれません。 必要であるとセレクタが、より良いコントロール、すなわち、保護を与えるよりすばらしい粒が適用されるだけであるとき、例はいつも本書では最もすばらしい粒状を使用します。
The following describes different ways of setting up IPsec policies for protecting Mobile IPv6 messages:
以下はモバイルIPv6メッセージを保護するためのIPsec方針をセットアップする異なった方法を述べます:
1. The IPsec implementations on the mobile node and the home agent
support fine-grain selectors, including the Mobility Header
message type. This is the case assumed in the IPsec SPD and SAD
examples in this document.
1. モバイルノードとホームのエージェントの上のIPsec実装は、細粒がMobility Headerメッセージタイプを含むセレクタであるとサポートします。 これはIPsec SPDとSADの例で本書では想定されたそうです。
2. The IPsec implementations only support selectors at a protocol
level. Such an IPsec implementation can only identify mobility
header traffic and cannot identify the individual mobility header
messages. In this case, the protection of Return Routability
Messages uses a setup similar to the regular payload packets sent
to the correspondent node with the protocol selector set to
Mobility Header. All tunneled Mobility Header messages will be
protected.
2. IPsec実装はプロトコルレベルでセレクタを支えるだけです。 そのようなIPsec実装は、移動性ヘッダートラフィックを特定できるだけであって、個々の移動性ヘッダーメッセージは特定できません。 この場合、Return Routability Messagesの保護はプロトコルセレクタセットについて通信員ノードに送られたレギュラーのペイロードパケットと同様のセットアップをMobility Headerに使用します。 すべてのトンネルを堀られたMobility Headerメッセージが保護されるでしょう。
3. The third case is where the protocol selector is not available in
the IPsec implementation. In this case, all traffic sent by the
mobile node that is reverse tunneled through the home agent is
protected using ESP in tunnel mode. This case is also applicable
when the mobile node, due to privacy considerations, tunnels all
traffic to the home agent. This includes Mobile IPv6 signaling
messages exchanged between the mobile node and the home agent and
all traffic exchanged between the mobile node and the
correspondent node. This case uses IPsec tunnel mode SA with the
protocol selector set to 'any'.
3. 3番目のケースはプロトコルセレクタがIPsec実装で入手できないところです。 この場合、ホームのエージェントを通してトンネルを堀られた状態で逆のモバイルノードによって送られたすべてのトラフィックが、トンネルモードで超能力を使用することで保護されます。 また、モバイルノードがプライバシー問題のためホームのエージェントにすべてのトラフィックにトンネルを堀るとき、本件も適切です。 これはモバイルノードとホームのエージェントの間で交換されたモバイルIPv6シグナリングメッセージとモバイルノードと通信員ノードの間で交換されたすべてのトラフィックを含んでいます。 本件はプロトコルセレクタセットがあるIPsecトンネルモードSAを'いずれも'に使用します。
The third case where all tunneled traffic is protected introduces some additional considerations:
すべてのトンネルを堀られたトラフィックが保護される3番目のこの件はいくつかの追加問題を紹介します:
o If there is just one IPsec SA providing protection for all
traffic, then the SA MUST fulfill the requirements for protecting
the Return Routability messages which require confidentiality
protection. If the third case is being used for privacy
considerations, then there can also be separate tunnel mode SPD
o すべてのトラフィックのための保護を提供するちょうど1IPsec SAがあれば、SA MUSTは、秘密性保護を必要とするReturn Routabilityメッセージを保護するために要求にこたえます。 また、3番目のケースがプライバシー問題に使用されているなら、別々のトンネルモードSPDがあることができます。
Devarapalli & Dupont Standards Track [Page 10] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[10ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
entries for protecting the Return Routability messages with a
higher priority in the SPD so that the SPD entry with the higher
priority gets applied first.
より高い優先度がSPDにある状態で、より高い優先度があるSPDエントリーが最初に適用されるようにReturn Routabilityメッセージを保護するためのエントリー。
o The receipt of a Binding Update from the new care-of address
updates the tunnel endpoint of the IPsec SA as described in
Section 4.3. Since the Binding Update that updates the tunnel
endpoint is received through the same tunnel interface that needs
to be updated, special care should be taken on the home agent to
ensure that the Binding Update is not dropped. This can be
achieved either by performing the source address check on the
outer IPv6 header after the binding update is processed or by
having exception handling to check the inner packet for a Binding
Update when the source address match on the outer source address
fails. Typical IPsec processing does not check the outer source
address when the originator of the packet has already been
authenticated.
o The receipt of a Binding Update from the new care-of address updates the tunnel endpoint of the IPsec SA as described in Section 4.3. Since the Binding Update that updates the tunnel endpoint is received through the same tunnel interface that needs to be updated, special care should be taken on the home agent to ensure that the Binding Update is not dropped. This can be achieved either by performing the source address check on the outer IPv6 header after the binding update is processed or by having exception handling to check the inner packet for a Binding Update when the source address match on the outer source address fails. Typical IPsec processing does not check the outer source address when the originator of the packet has already been authenticated.
6. Manual Configuration
6. Manual Configuration
This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages. The SPD and SAD entries are only example configurations. A particular mobile node implementation and a home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages. The SPD and SAD entries are only example configurations. A particular mobile node implementation and a home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
For the examples described in this document, a mobile node with home address, "home_address_1", primary care-of address, "care_of_address_1", a home agent with address, "home_agent_1" and a user of the mobile node with identity "user_1" are assumed. If the home address of the mobile node changes, the SPD and SAD entries need to be re-created or updated for the new home address.
For the examples described in this document, a mobile node with home address, "home_address_1", primary care-of address, "care_of_address_1", a home agent with address, "home_agent_1" and a user of the mobile node with identity "user_1" are assumed. If the home address of the mobile node changes, the SPD and SAD entries need to be re-created or updated for the new home address.
The Peer Authorization Database is not used when manual IPsec configuration is used for setting up security associations for protecting Mobile IPv6 signaling messages.
The Peer Authorization Database is not used when manual IPsec configuration is used for setting up security associations for protecting Mobile IPv6 signaling messages.
Devarapalli & Dupont Standards Track [Page 11] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 11] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
6.1. Binding Updates and Acknowledgements
6.1. Binding Updates and Acknowledgements
The following are the SPD and SAD entries on the mobile node and the home agent to protect Binding Updates and Acknowledgements.
The following are the SPD and SAD entries on the mobile node and the home agent to protect Binding Updates and Acknowledgements.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = MH &
local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN)
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use SA SA1 (OUT) and SA2 (IN)
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
mobile node SAD: - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & mh_type = BU - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & mh_type = BAck
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = MH &
local_mh_type = BAck & remote_mh_type = BU
Then use SA SA2 (OUT) and SA1 (IN)
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use SA SA2 (OUT) and SA1 (IN)
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
home agent SAD: - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & mh_type = BAck - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & mh_type = BU
Devarapalli & Dupont Standards Track [Page 12] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 12] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
6.2. Return Routability Messages
6.2. Return Routability Messages
The following are the SPD and SAD entries on the mobile node and the home agent to protect Return Routability messages.
The following are the SPD and SAD entries on the mobile node and the home agent to protect Return Routability messages.
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN)
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = any & proto = MH & local_mh_type = HoTi & remote_mh_type = HoT Then use SA SA3 (OUT) and SA4 (IN)
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
mobile node SAD: - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): local_address = home_address_1 & remote_address = any & proto = MH & mh_type = HoTi - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): local_address = any & remote_address = home_address_1 & proto = MH & mh_type = HoT
home agent SPD-S:
- IF remote_address = home_address_1 & local_address = any &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA SA4 (OUT) and SA3 (IN)
home agent SPD-S: - IF remote_address = home_address_1 & local_address = any & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi Then use SA SA4 (OUT) and SA3 (IN)
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
home agent SAD: - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): local_address = any & remote_address = home_address_1 & proto = MH & mh_type = HoT - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): local_address = home_address_1 & remote_address = any & proto = MH & mh_type = HoTi
Devarapalli & Dupont Standards Track [Page 13] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 13] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
6.3. Mobile Prefix Discovery Messages
6.3. Mobile Prefix Discovery Messages
The following are the SPD and SAD entries used to protect Mobile Prefix Discovery messages.
The following are the SPD and SAD entries used to protect Mobile Prefix Discovery messages.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = ICMPv6 &
local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN)
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & local_icmp6_type = MPS & remote_icmp6_type = MPA Then use SA SA5 (OUT) and SA6 (IN)
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
mobile node SAD: - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & icmp6_type = MPA
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = ICMPv6 &
local_icmp6_type = MPA & remote_icmp6_type = MPS
Then use SA SA6 (OUT) and SA5 (IN)
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & local_icmp6_type = MPA & remote_icmp6_type = MPS Then use SA SA6 (OUT) and SA5 (IN)
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
home agent SAD: - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & icmp6_type = MPA - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS
6.4. Payload Packets
6.4. Payload Packets
Regular payload traffic between the mobile node and the correspondent node tunneled through the home agent can be protected by IPsec, if required. The mobile node and the home agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] are applicable here.
Regular payload traffic between the mobile node and the correspondent node tunneled through the home agent can be protected by IPsec, if required. The mobile node and the home agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] are applicable here.
Devarapalli & Dupont Standards Track [Page 14] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 14] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
7. Dynamic Configuration
7. Dynamic Configuration
This section describes the use of IKEv2 to set up the required security associations.
This section describes the use of IKEv2 to set up the required security associations.
7.1. Peer Authorization Database Entries
7.1. Peer Authorization Database Entries
The following describes PAD entries on the mobile node and the home agent. The PAD entries are only example configurations. Note that the PAD is a logical concept; a particular mobile node and a home agent can implement the PAD in an implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
The following describes PAD entries on the mobile node and the home agent. The PAD entries are only example configurations. Note that the PAD is a logical concept; a particular mobile node and a home agent can implement the PAD in an implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
mobile node PAD:
- IF remote_identity = home_agent_identity_1
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address home_agent_1
mobile node PAD: - IF remote_identity = home_agent_identity_1 Then authenticate (shared secret/certificate/) and authorize CHILD_SA for remote address home_agent_1
home agent PAD:
- IF remote_identity = user_1
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for remote address home_address_1
home agent PAD: - IF remote_identity = user_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address home_address_1
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
7.2. Security Policy Database Entries
7.2. Security Policy Database Entries
The following sections describe the security policy entries on the mobile node and the home agent. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
The following sections describe the security policy entries on the mobile node and the home agent. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1, the primary care-of address of the mobile node is assumed to be care_of_address_1, and the IPv6 address of the Home Agent is assumed to be home_agent_1.
In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1, the primary care-of address of the mobile node is assumed to be care_of_address_1, and the IPv6 address of the Home Agent is assumed to be home_agent_1.
Devarapalli & Dupont Standards Track [Page 15] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 15] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
7.2.1. Binding Updates and Acknowledgements
7.2.1. Binding Updates and Acknowledgements
The following are the SPD entries on the mobile node and the home agent for protecting Binding Updates and Acknowledgements.
The following are the SPD entries on the mobile node and the home agent for protecting Binding Updates and Acknowledgements.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use SA ESP transport mode Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport mode
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use SA ESP transport mode
In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address.
In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address.
The home agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The home address presented by the mobile node during the IKE negotiation is stored as the remote IP address in the resultant IPsec security associations. If the mobile node dynamically configures a home agent and the home address, the home agent may not know which mobile nodes it is supposed to be serving. Therefore, the home agent cannot have SPD entries configured per mobile node. Instead, the home agent should have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. Once a mobile node authenticates to the home agent and configures a home address, appropriate SPD entries are created for the mobile node.
The home agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The home address presented by the mobile node during the IKE negotiation is stored as the remote IP address in the resultant IPsec security associations. If the mobile node dynamically configures a home agent and the home address, the home agent may not know which mobile nodes it is supposed to be serving. Therefore, the home agent cannot have SPD entries configured per mobile node. Instead, the home agent should have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. Once a mobile node authenticates to the home agent and configures a home address, appropriate SPD entries are created for the mobile node.
The Mobility Header message type is negotiated by placing it in the most significant eight bits of the 16-bit local "port" selector during IKEv2 exchange. For more details, refer to [5]. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For the sake of brevity, we show only those values that are relevant for Mobile IPv6.
The Mobility Header message type is negotiated by placing it in the most significant eight bits of the 16-bit local "port" selector during IKEv2 exchange. For more details, refer to [5]. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For the sake of brevity, we show only those values that are relevant for Mobile IPv6.
Devarapalli & Dupont Standards Track [Page 16] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 16] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
7.2.2. Return Routability Messages
7.2.2. Return Routability Messages
The following are the SPD entries on the mobile node and the home agent for protecting the Return Routability messages.
The following are the SPD entries on the mobile node and the home agent for protecting the Return Routability messages.
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = any & proto = MH & local_mh_type = HoTi & remote_mh_type = HoT Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF local_address = any & remote_address = home_address_1 &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA ESP tunnel mode
home agent SPD-S: - IF local_address = any & remote_address = home_address_1 & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi Then use SA ESP tunnel mode
When the mobile node's care-of address changes, the SPD entries on both the mobile node and the home agent must be updated. The home agent knows about the change in care-of address of the mobile node when it receives a Binding Update from the mobile node.
When the mobile node's care-of address changes, the SPD entries on both the mobile node and the home agent must be updated. The home agent knows about the change in care-of address of the mobile node when it receives a Binding Update from the mobile node.
7.2.3. Mobile Prefix Discovery Messages
7.2.3. Mobile Prefix Discovery Messages
The following are the SPD entries on the mobile node and the home agent for protecting Mobile Prefix Discovery messages.
The following are the SPD entries on the mobile node and the home agent for protecting Mobile Prefix Discovery messages.
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & local_icmp6_type = MPS &
remote_icmp6_type = MPA
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & local_icmp6_type = MPS & remote_icmp6_type = MPA Then use SA ESP transport mode Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & local_icmp6_type = MPA &
remote_icmp6_type = MPS
Then use SA ESP transport mode
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & local_icmp6_type = MPA & remote_icmp6_type = MPS Then use SA ESP transport mode
In the examples shown above, the home address of the mobile node might not be available all the time. When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries.
In the examples shown above, the home address of the mobile node might not be available all the time. When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries.
Devarapalli & Dupont Standards Track [Page 17] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 17] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For brevity, they are not shown here.
The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For brevity, they are not shown here.
7.2.4. Payload Packets
7.2.4. Payload Packets
The following are the SPD entries on the mobile node and the home agent if payload traffic exchanged between the mobile node and its Correspondent Node needs to be protected. The SPD entries are similar to the entries for protecting Return Routability messages and have lower priority than the above SPD entries.
The following are the SPD entries on the mobile node and the home agent if payload traffic exchanged between the mobile node and its Correspondent Node needs to be protected. The SPD entries are similar to the entries for protecting Return Routability messages and have lower priority than the above SPD entries.
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X
Then use SA ESP tunnel mode
home agent SPD-S: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X Then use SA ESP tunnel mode
7.3. Security Association Negotiation Using IKEv2
7.3. Security Association Negotiation Using IKEv2
Mobile IPv6 signaling messages are typically initiated by the mobile node. The mobile node sends a Binding Update to the home agent whenever it moves and acquires a new care-of address.
Mobile IPv6 signaling messages are typically initiated by the mobile node. The mobile node sends a Binding Update to the home agent whenever it moves and acquires a new care-of address.
The mobile node initiates an IKEv2 protocol exchange if the required security associations are not present. A possible mechanism used for mutual authentication is a shared secret between the mobile node and the home agent. The home agent uses the identity of the mobile node to identify the corresponding shared secret. When a public-key-based mechanism is available, it should be the preferred mechanism for mutual authentication.
The mobile node initiates an IKEv2 protocol exchange if the required security associations are not present. A possible mechanism used for mutual authentication is a shared secret between the mobile node and the home agent. The home agent uses the identity of the mobile node to identify the corresponding shared secret. When a public-key-based mechanism is available, it should be the preferred mechanism for mutual authentication.
If a shared secret is being used, the mobile node uses the shared secret to generate the AUTH payload in the IKE_AUTH exchange. If the mobile node is using a public-key-based mechanism, then it uses its private key to generate the AUTH payload in the IKE_AUTH exchange.
If a shared secret is being used, the mobile node uses the shared secret to generate the AUTH payload in the IKE_AUTH exchange. If the mobile node is using a public-key-based mechanism, then it uses its private key to generate the AUTH payload in the IKE_AUTH exchange.
Devarapalli & Dupont Standards Track [Page 18] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 18] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
Mobile Node Home Agent ----------- ---------- HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}
-->
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
The mobile node always includes its identity in the IDi payload in the IKE_AUTH exchange. The mobile node could use the following different types of identities to identify itself to the home agent.
The mobile node always includes its identity in the IDi payload in the IKE_AUTH exchange. The mobile node could use the following different types of identities to identify itself to the home agent.
o Home Address - The mobile node could use its statically configured
home address as its identity. In this case the ID Type field is
set to ID_IPV6_ADDR.
o Home Address - The mobile node could use its statically configured home address as its identity. In this case the ID Type field is set to ID_IPV6_ADDR.
o FQDN - The mobile node can use a Fully Qualified Domain Name as
the identifier and set the ID Type field to ID_FQDN.
o FQDN - The mobile node can use a Fully Qualified Domain Name as the identifier and set the ID Type field to ID_FQDN.
o RFC 822 identifier - If the mobile node uses a RFC 822 identifier
[9], it sets the ID Type field to ID_RFC822_ADDR.
o RFC 822 identifier - If the mobile node uses a RFC 822 identifier [9], it sets the ID Type field to ID_RFC822_ADDR.
The above list of identities is not exhaustive.
The above list of identities is not exhaustive.
In the IKE_AUTH exchange, the mobile node includes the home address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. The mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement to use the same pair of IPsec security associations for both messages.
In the IKE_AUTH exchange, the mobile node includes the home address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. The mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement to use the same pair of IPsec security associations for both messages.
After the IKE_AUTH exchange completes, the mobile node initiates CREATE_CHILD_SA exchanges to negotiate additional security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages, and (optionally) payload traffic. The CREATE_CHILD_SA exchanges are protected by IKEv2 security associations created during the IKE_SA_INIT exchange. If a correspondent node, that is also a mobile node, initiates the return routability exchange, then the home agent initiates the CREATE_CHILD_SA exchange to negotiate security associations for protecting Return Routabilty messages.
After the IKE_AUTH exchange completes, the mobile node initiates CREATE_CHILD_SA exchanges to negotiate additional security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages, and (optionally) payload traffic. The CREATE_CHILD_SA exchanges are protected by IKEv2 security associations created during the IKE_SA_INIT exchange. If a correspondent node, that is also a mobile node, initiates the return routability exchange, then the home agent initiates the CREATE_CHILD_SA exchange to negotiate security associations for protecting Return Routabilty messages.
Devarapalli & Dupont Standards Track [Page 19] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 19] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
It is important that the security associations are created based on the home address of the mobile node, so that the security associations survive care-of address change. The mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange in order to create the IPsec security associations for the home address.
It is important that the security associations are created based on the home address of the mobile node, so that the security associations survive care-of address change. The mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange in order to create the IPsec security associations for the home address.
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
Mobile Node Home Agent ----------- ---------- HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
<-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]}
When PKI-based authentication is used between the mobile node and the Home Agent, the identity presented by the mobile node in the IDi payload MUST correspond to the identity in the certificate obtained by the Home Agent. The home agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the home agent MUST verify that the home address matches the address in an iPAddress field in the SubjectAltName extension [8].
When PKI-based authentication is used between the mobile node and the Home Agent, the identity presented by the mobile node in the IDi payload MUST correspond to the identity in the certificate obtained by the Home Agent. The home agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the home agent MUST verify that the home address matches the address in an iPAddress field in the SubjectAltName extension [8].
When the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. According to RFC 4306 [4], the IP header fields in the IKEv2 messages are ignored and used only in the IP headers for IKEv2 messages sent as replies.
When the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. According to RFC 4306 [4], the IP header fields in the IKEv2 messages are ignored and used only in the IP headers for IKEv2 messages sent as replies.
7.4. Movements and Dynamic Keying
7.4. Movements and Dynamic Keying
If the mobile node moves and its care-of address changes, the IKEv2 SA might not be valid. RFC 3775 defines a mechanism based on the successful exchange of Binding Update and Binding Acknowledgement messages. The mobile node establishes the IKE SA with the home agent using its primary care-of address. The IKE SA endpoints are updated on the home agent when it receives the Binding Update from the mobile node's new care-of address and on the mobile node when it sends the Binding Update to the home agent or when it receives the Binding acknowledgement sent by the home agent. This capability to change IKE endpoints is indicated through setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages. If the mobile node or the home agent does
If the mobile node moves and its care-of address changes, the IKEv2 SA might not be valid. RFC 3775 defines a mechanism based on the successful exchange of Binding Update and Binding Acknowledgement messages. The mobile node establishes the IKE SA with the home agent using its primary care-of address. The IKE SA endpoints are updated on the home agent when it receives the Binding Update from the mobile node's new care-of address and on the mobile node when it sends the Binding Update to the home agent or when it receives the Binding acknowledgement sent by the home agent. This capability to change IKE endpoints is indicated through setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages. If the mobile node or the home agent does
Devarapalli & Dupont Standards Track [Page 20] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 20] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
not support this capability, and has no other means to update the addresses, then an IKEv2 exchange MUST be initiated to re-establish a new IKE SA.
not support this capability, and has no other means to update the addresses, then an IKEv2 exchange MUST be initiated to re-establish a new IKE SA.
8. The Use of EAP Authentication
8. The Use of EAP Authentication
In addition to using public key signatures and shared secrets, EAP [10] can be used with IKEv2 for authenticating the mobile node to the home agent.
In addition to using public key signatures and shared secrets, EAP [10] can be used with IKEv2 for authenticating the mobile node to the home agent.
The mobile node indicates that it wants to use EAP by including the IDi payload but leaving out the AUTH payload in the first message during the IKE_AUTH exchange. The home agent then includes an EAP payload if it is willing to use an extensible authentication method. Security associations are not created until the subsequent IKE_AUTH exchange after successful EAP authentication. The use of EAP adds at least two round trips to the IKE negotiation. The number of round trips depends on the EAP method used.
The mobile node indicates that it wants to use EAP by including the IDi payload but leaving out the AUTH payload in the first message during the IKE_AUTH exchange. The home agent then includes an EAP payload if it is willing to use an extensible authentication method. Security associations are not created until the subsequent IKE_AUTH exchange after successful EAP authentication. The use of EAP adds at least two round trips to the IKE negotiation. The number of round trips depends on the EAP method used.
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
Mobile Node Home Agent ------------ ---------- HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr}-->
HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH,
EAP }
.
.
.
<-- HDR, SK {IDr, [CERT,] AUTH, EAP } . . .
HDR, SK {EAP} -->
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi,
TSr}
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is
When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is
Devarapalli & Dupont Standards Track [Page 21] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
Devarapalli & Dupont Standards Track [Page 21] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document.
carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document.
Some EAP methods, when used with IKEv2, generate a shared key on the mobile node and the Home Agent once the EAP authentication succeeds. This shared key is used to generate the AUTH payloads in the subsequent IKEv2 messages. The shared key, if used to generate the AUTH payloads, MUST NOT be used for any other purpose. For more details, refer to [4].
Some EAP methods, when used with IKEv2, generate a shared key on the mobile node and the Home Agent once the EAP authentication succeeds. This shared key is used to generate the AUTH payloads in the subsequent IKEv2 messages. The shared key, if used to generate the AUTH payloads, MUST NOT be used for any other purpose. For more details, refer to [4].
The use of EAP between the mobile node and the home agent might require the home agent to contact an authorization server like the AAA Home server, on the home link, to authenticate the mobile node. Please refer to [7] for more details.
The use of EAP between the mobile node and the home agent might require the home agent to contact an authorization server like the AAA Home server, on the home link, to authenticate the mobile node. Please refer to [7] for more details.
9. Dynamic Home Address Configuration
9. Dynamic Home Address Configuration
The mobile node can dynamically configure a home address by including a Configuration Payload in the IKE_AUTH exchange, with a request for an address from the home link. The mobile node should include a zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The mobile node MAY include multiple instances of the INTERNAL_IP6_ADDRESS to request multiple home address to the assigned by the home agent.
モバイルノードはイケ_AUTH交換にConfiguration有効搭載量を含んでいることによって、ダイナミックにホームアドレスを構成できます、ホームのリンクからのアドレスを求める要求で。 モバイルノードはCFG_REQUEST有効搭載量にゼロ・レングスINTERNAL_IP6_ADDRESS属性を含んでいるはずです。 モバイルノードは、ホームのエージェントによる割り当てに複数のホームアドレスを要求するためにINTERNAL_IP6_ADDRESSの複数のインスタンスを含むかもしれません。
When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The home agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The duration for which the home address is allocated to the mobile node is the same as the duration for which an IKEv2 security association exists between the mobile node and the home agent. If the IKEv2 security association is rekeyed, the home address lifetime is also extended.
ホームのエージェントがINTERNAL_IP6_ADDRESSのためにCFG_REQUESTと共に構成ペイロードを受け取るとき、それはモバイルノードのための有効なホームアドレスで返答します。 CFG_REPLYのINTERNAL_IP6_ADDRESS属性は128ビットのホームアドレスに加えたホーム接頭語の接頭語の長さを含んでいます。 ホームのエージェントは、ホームアドレスを割り当てるためにローカルのデータベースを使用するか、またはホームのリンクへDHCPv6サーバに連絡できました。 ホームアドレスがモバイルノードに割り当てられる持続時間はIKEv2セキュリティ協会がモバイルノードとホームのエージェントの間に存在する持続時間と同じです。 また、IKEv2セキュリティ協会が「再-合わせ」られるなら、ホームアドレス寿命は広げられます。
Devarapalli & Dupont Standards Track [Page 22] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[22ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
モバイルノードホームのエージェント----------- ---------- HDR、SK、IDi、[CERTREQ][IDr]AUTH、CP(CFG_要求)、SAi2、TSi、[本命]TSr--、>。
<-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2,
TSi, TSr}
<--HDR、SKIDr、[本命]AUTH、CP(CFG_回答)、SAr2、TSi、TSr
The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that was allocated for the mobile node before or an address that the mobile node auto-configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. If the home agent wants the mobile node to use a different home address, it sends a new home address in the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile Node MUST stop using its old home address and start using the newly allocated home address.
モバイルノードはそれがCFG_REQUESTで使用したがっているホームアドレスを示すかもしれません。これは、例えば、以前モバイルノードのために割り当てられたホームアドレスかモバイルノードがホームのリンクの上のIPv6接頭語から自動構成したアドレスであるかもしれません。 ホームのエージェントは、モバイルノードにCFG_REPLYペイロードでINTERNAL_IP6_ADDRESS属性を設定することによって、同じホームアドレスを同じホームアドレスに使用させることができました。 ホームのエージェントが、モバイルノードに異なったホームアドレスを使用して欲しいなら、それはCFG_REPLYペイロードのINTERNAL_IP6_ADDRESS属性における新しいホームアドレスを送ります。 モバイルNodeは、懐かしい生家アドレスを使用するのを止めて、新たに割り当てられたホームアドレスを使用し始めなければなりません。
In case the home agent is unable to allocate a home address for the mobile node during the IKE_AUTH exchange, it MUST send a Notify Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile node receives a Notify Payload with an INTERNAL_ADDRESS_FAILURE message, it SHOULD terminate the IKE_AUTH exchange. The mobile node then should initiate a new IKE_SA_INIT and IKE_AUTH exchange and try to auto-configure a home address as described in [13]. The mobile node MAY also switch to another home agent. The new home agent address can be obtained by consulting a home agent list received during a previous home agent discovery phase or, if such list is empty or not available, by attempting a new home agent discovery.
ホームのエージェントがイケ_AUTH交換の間、モバイルノードのためのホームアドレスを割り当てるといけないことができないので、それはINTERNAL_ADDRESS_FAILUREメッセージがあるNotify有効搭載量を送らなければなりません。 モバイルノードはINTERNAL_ADDRESS_FAILUREメッセージでNotify有効搭載量を受け取って、それはSHOULDです。いつ、イケ_AUTH交換を終えてくださいか。 次に、モバイルノードは、SA_INITとイケ_AUTHが交換する新しいイケ_を開始して、[13]で説明されるようにホームアドレスを自動構成しようとするはずです。 また、モバイルノードは別のホームのエージェントに切り替わるかもしれません。 前のホームエージェント発見段階かそのようなリストが空であるか、または利用可能でないときに試みるのによる新しいホームエージェント発見の間に受け取られたホームエージェントリストに相談することによって、新しいホームエージェントアドレスを得ることができます。
If the mobile node wants to configure a DNS server from the home link, it can request the DNS server information by including an INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.
ホームからDNSサーバを構成するモバイルノード必需品がリンクされるなら、それは、CFG_REQUESTペイロードにINTERNAL_IP6_DNS属性を含んでいることによって、DNSサーバ情報を要求できます。
10. Security Considerations
10. セキュリティ問題
This document describes how IPsec can be used to secure Mobile IPv6 signaling messages. Please refer to RFC 3775 [2] for security considerations related to the use of IPsec with Mobile IPv6.
このドキュメントはモバイルIPv6シグナリングがメッセージであると機密保護するのにどうIPsecを使用できるかを説明します。 モバイルIPv6とのIPsecの使用に関連するセキュリティ問題のためのRFC3775[2]を参照してください。
A misbehaving mobile node could create IPsec security associations for a home address that belongs to another mobile node. Therefore, the home agent should check if a particular mobile node is authorized
ふらちな事することのモバイルノードは別のモバイルノードに属すホームアドレスのためにIPsecセキュリティ協会を創設するかもしれません。 したがって、ホームのエージェントは、特定のモバイルノードが認可されているかどうかチェックするべきです。
Devarapalli & Dupont Standards Track [Page 23] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[23ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
to use a home address before creating IPsec security associations for the home address. If the home address is assigned as described in Section 9, the home agent MUST associate the home address with the identity used in IKE negotiation. The home agent MAY store the assigned home address in the SPD entries created for the mobile node.
ホームアドレスのためにIPsecセキュリティ協会を創設する前にホームアドレスを使用するために。 ホームアドレスがセクション9で説明されるように割り当てられるなら、ホームのエージェントはIKE交渉に使用されるアイデンティティにホームアドレスを関連づけなければなりません。 ホームのエージェントはモバイルノードのために作成されたSPDエントリーに割り当てられたホームアドレスを保存するかもしれません。
The use of EAP for authenticating the mobile node to the home agent is described in Section 8. Security considerations related to the use of EAP with IKEv2 are described in [4].
EAPのホームのエージェントにモバイルノードを認証する使用はセクション8で説明されます。 IKEv2とのEAPの使用に関連するセキュリティ問題は[4]で説明されます。
11. Acknowledgements
11. 承認
The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve Bellovin, Kilian Weniger, and Vijay Gurbani for reviewing the document.
作者は、ドキュメントを再検討して頂いて、ミカJoutsenvirta、パシEronen、ヤリArkko、ヘラルドGiaretta、Shinta杉本、Tero Kivinen、スティーブBellovin、キリアン・ウェニガー、およびビジェイGurbaniに感謝したがっています。
Many of the requirements listed in Section 4 are copied from RFC 3776. Therefore, the authors of RFC 3776 are acknowledged.
セクション4にリストアップされた要件の多くがRFC3776からコピーされます。 したがって、RFC3776の作者は承認されます。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[3]Arkko、J.、Devarapalli、V.、およびF.デュポン、「モバイルノードとホームのエージェントの間で合図するモバイルIPv6を保護するのにIPsecを使用します」、RFC3776(2004年6月)。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[4] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[5] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[6] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
12.2. Informative References
12.2. 有益な参照
[7] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress,
September 2006.
[7]Giaretta、G.、「モバイルIPv6"のAAA目標、処理中の作業、2006年9月。」
Devarapalli & Dupont Standards Track [Page 24] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[24ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
[8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/
ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
[8] B.と、「IKEv1/ ISAKMPのインターネットIPセキュリティPKIプロフィール、IKEv2、およびPKIX」というKorverは進歩、2007年2月に働いています。
[9] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[9] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[10]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[11] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile
IPv6 and IPsec/IKE", Work in Progress, September 2006.
[12] 杉本、S.、「モバイルIPv6とIPsec/IKEとのインタフェースとしてのpfの_の主要な拡張子」が進歩、2006年9月に働いています。
[13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
Work in Progress, December 2006.
[13]Giaretta、G.、「分裂シナリオを独力で進むモバイルIPv6」、Progress、2006年12月のWork。
Authors' Addresses
作者のアドレス
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireは3121ジェイ・通りカリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
EMail: vijay.devarapalli@azairenet.com
メール: vijay.devarapalli@azairenet.com
Francis Dupont CELAR
フランシスデュポンCELAR
EMail: Francis.Dupont@fdupont.fr
メール: Francis.Dupont@fdupont.fr
Devarapalli & Dupont Standards Track [Page 25] RFC 4877 Mobile IPv6 with IKEv2 and IPsec April 2007
IKEv2とDevarapalliとデュポン標準化過程[25ページ]のRFC4877のモバイルIPv6とIPsec2007年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Devarapalli & Dupont Standards Track [Page 26]
Devarapalliとデュポン標準化過程[26ページ]
一覧
スポンサーリンク
