Network Working Group A. Patel
Request for Comments: 4285 K. Leung
Category: Informational Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
January 2006
Authentication Protocol for Mobile IPv6
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. RFC 3775 and 3776 define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 used in 3GPP2 networks.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 RFC 3775および3776は、モバイルIPv6とそのセキュリティ・メカニズムを定義します。この文書では、3GPP2ネットワークで使用されるモバイルIPv6のための代替のセキュリティメカニズムを提供します。
The security properties of this mechanism have not been reviewed in the IETF. Conducting this review proved difficult because the standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol; extensions to Mobile IPv6 and the core documents make assumptions about the properties of the security model without explicitly stating what assumptions are being made. There is no documented service model. Thus it is difficult to replace the security mechanism and see if the current protocol and future extensions meet appropriate security requirements both under the original and new security mechanisms. If a service model for Mobile IPv6 security is ever formally defined and reviewed, a mechanism similar to this one could be produced and fully reviewed.
このメカニズムのセキュリティプロパティは、IETFで検討されていません。モバイルIPv6のための標準トラックセキュリティメカニズムがしっかりとプロトコルに組み込まれているので、このレビューを実施することは困難でした。モバイルIPv6およびコア文書への拡張は、明示的な仮定がなされているかを知らせることなく、セキュリティモデルの性質についての仮定を行います。何の文書化サービスモデルはありません。したがって、セキュリティ・メカニズムを交換し、現在のプロトコルや将来の拡張の両方の元と新しいセキュリティ・メカニズムの下で、適切なセキュリティ要件を満たすかどうかを確認することは困難です。モバイルIPv6のセキュリティのためのサービスモデルは、これまで正式に定義され、レビューされている場合は、この1と同様のメカニズムが生成され、十分に検討することができます。
Section 1.1 of this document provides an applicability statement for this RFC. The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement. In addition the IESG recommends those considering deploying or implementing this specification conduct a sufficient security review to meet the conditions of the environments in which this RFC will be used.
このドキュメントのセクション1.1には、このRFCのための適用性ステートメントを提供します。 IESGは、その適用性文の条件を満たした環境の外でこの仕様書の使用に対して推奨しています。また、IESGは、この仕様書このRFCが使用される環境の条件を満たすのに十分なセキュリティレビューを実施を展開または導入を検討、それらを推奨しています。
Abstract
抽象
IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.
IPsecがモバイルIPv6（MIPv6の）のためにモバイルノードとホームエージェントとの間のシグナリングメッセージを確保する手段として指定されています。固定されているMIPv6のシグナリングメッセージは、モバイルノードとそのホームエージェントの間のバインディングを管理するために使用されるバインディング更新と受信確認メッセージが含まれます。この文書では、モバイルノードとホームエージェントとの間のシグナリングメッセージをMIPv6のを確保するための別の方法を提案しています。ここで定義された別の方法は、MIPv6のシグナリングメッセージに追加することができるMIPv6の固有のモビリティメッセージ認証オプションから成ります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
2. Overview ........................................................4
3. Terminology .....................................................5
3.1. General Terms ..............................................5
4. Operational Flow ................................................6
5. Mobility Message Authentication Option ..........................7
5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations ...........................9
5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility Message Replay Protection Option ......................11
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection
option ................................................16
The base Mobile IPv6 specification [RFC3775] specifies the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile Node (MN) and Home Agent (HA) to be secured by the IPsec Security Associations (IPsec SAs) that are established between these two entities.
ベースのモバイルIPv6の仕様[RFC3775]はアップデート（BU）をバインドし、IPsecセキュリティアソシエーション（IPsecのSA）をすることにより確保されるようにモバイルノード（MN）とホームエージェント（HA）との間に確認応答（BA）を、バインディング、シグナリングメッセージを指定しますそれは、これら2つのエンティティ間で確立されています。
This document proposes a solution for securing the Binding Update and Binding Acknowledgment messages between the Mobile Node and Home Agent using a mobility message authentication option that is included in these messages. Such a mechanism enables IPv6 mobility in a host without having to establish an IPsec SA with its Home Agent. A Mobile Node can implement Mobile IPv6 without having to integrate it with the IPsec module, in which case the Binding Update and Binding Acknowledgement messages (between MN-HA) are secured with the mobility message authentication option.
この文書では、バインディングアップデートを確保し、これらのメッセージに含まれるモビリティメッセージ認証オプションを使用してモバイルノードとホームエージェントとの間で確認応答メッセージを結合するためのソリューションを提案しています。このようなメカニズムは、そのホームエージェントとのIPsec SAを確立することなく、ホストでのIPv6モビリティを可能にします。モバイルノードは、その場合には、バインディング更新及び（MN-HA間の）バインド肯定応答メッセージは、モビリティメッセージ認証オプションを使用して固定され、IPsecモジュールと統合することなく、モバイルIPv6を実装することができます。
The authentication mechanism proposed here is similar to the authentication mechanism used in Mobile IPv4 [RFC3344].
ここで提案された認証メカニズムは、モバイルIPv4 [RFC3344]で使用される認証機構に類似しています。
The mobility message authentication option specified in Section 5 is applicable in certain types of networks that have the following characteristics:
第5節で指定されたモビリティメッセージ認証オプションは、次のような特徴を持っているネットワークの特定の種類に適用可能です。
- Networks in which the authentication of the MN for network access is done by an authentication server in the home network via the home agent. The security association is established by the network operator (provisioning methods) between the MN and a backend authentication server (e.g., Authentication, Authorization, and Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776 relies on the IPsec SA between the MN and an HA. In cases where the assignment of the HA is dynamic and the only static or long-term SA is between the MN and a backend authentication server, the mobility message authentication option is desirable.
- ネットワークアクセスのためのMNの認証は、ホームエージェントを介してホームネットワーク内の認証サーバによって行われているネットワーク。セキュリティアソシエーションは、ネットワークオペレータMNとバックエンド認証サーバ（例えば、認証、許可、アカウンティング（AAA）ホームサーバ）との間の（プロビジョニング方法）によって確立されます。 RFC 3775および3776あたりとしてMIPv6のは、MNとHA間のIPsec SAに依存しています。 HAの割り当ては動的でSAがMNとバックエンド認証サーバとの間でのみ静的または長期である場合には、モビリティメッセージ認証オプションが望ましいです。
- In certain deployment environments, the mobile node needs dynamic assignment of a home agent and home address. The assignment of such can be on a per-session basis or on a per-MN power-up basis. In such scenarios, the MN relies on an identity such as a Network Access Identifier (NAI) [RFC4283], and a security association with a AAA server to obtain such bootstrapping information. The security association is created via an out-of-band mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism can be specific to the deployment environment of a network operator. In Code Division Multiple Access (CDMA) network deployments, this information can be obtained at the time of network access authentication via [3GPP2] specific extensions to PPP or DHCPv6 on the access link and by AAA extensions in the core. It should be noted that the out-of-band mechanism is not within the scope of the mobility message authentication option (Section 5) and hence is not described therein.
- 特定のデプロイメント環境では、モバイルノードは、ホームエージェントとホームアドレスの動的な割り当てを必要とします。そのようの割り当ては、セッション単位でまたはあたり-MNパワーアップ毎にすることができます。そのようなシナリオでは、MNは、ネットワークアクセス識別子（NAI）[RFC4283]として識別に依存して、及びAAAサーバとのセキュリティアソシエーションは、このようなブートストラップ情報を取得します。セキュリティアソシエーションは、アウトオブバンドメカニズムを介して、または非モバイルIPv6シグナリングによって作成されます。アウトオブバンドメカニズムは、ネットワークオペレータのデプロイメント環境に特異的であることができます。符号分割多元接続（CDMA）ネットワークの展開では、この情報はアクセスリンク上のコアにおけるAAA拡張によってPPPまたはDHCPv6のに[3GPP2]特定の拡張子を介してネットワークアクセス認証時に取得することができます。アウトオブバンドメカニズムは、モビリティメッセージ認証オプション（セクション5）の範囲内ではなく、従ってそこに記載されていないことに留意すべきです。
- Network deployments in which not all Mobile Nodes and Home Agents have IKEv2 implementations and support for the integration of IKEv2 with backend AAA infrastructures. IKEv2 as a technology has yet to reach maturity status and widespread implementations needed for commercial deployments on a large scale. At the time of this writing, [RFC4306] is yet to be published as an RFC. Hence from a practical perspective that operators face, IKEv2 is not yet capable of addressing the immediate need for MIPv6 deployment.
- いないすべてのモバイルノードとホームエージェントは、バックエンドのAAAインフラストラクチャとのIKEv2の統合のためのIKEv2の実装とサポートを持っているネットワークの展開。技術としてのIKEv2は、成熟度の状態と大規模で商用展開するために必要な広範囲の実装に到達するためには至っていません。この記事の執筆時点では、[RFC4306]はまだRFCとして公開されるべきです。従って、オペレータが直面する実用的観点から、IKEv2のまだMIPv6の配備のための即時の必要性に対処することができません。
- Networks that expressly rely on the backend AAA infrastructure as the primary means for identifying and authentication/authorizing a mobile user for MIPv6 service.
- 明確に識別および認証/ MIPv6のサービスのためにモバイルユーザを認証するための主要な手段としてのバックエンドAAAインフラストラクチャに依存しているネットワーク。
- Networks in which the establishment of the security association between the Mobile Node and the authentication server (AAA Home) is established using an out-of-band mechanism and not by any key exchange protocol. Such networks will also rely on out-of-band mechanisms to renew the security association (between MN and AAA Home) when needed.
- ネットワークここでモバイルノードと認証サーバ（AAAホーム）との間のセキュリティ・アソシエーションの確立は、アウトオブバンドメカニズムを使用して確立されていない任意のキー交換プロトコルによるものです。このようなネットワークはまた、必要なときに（MNとAAAホームの間）のセキュリティアソシエーションを更新するために、アウトオブバンドメカニズムに依存しています。
- Networks that are bandwidth constrained (such as cellular wireless networks) and for which there exists a strong desire to minimize the number of signaling messages sent over such interfaces. MIPv6 signaling that relies on Internet Key Exchange (IKE) as the primary means for setting up an SA between the MN and HA requires more signaling messages compared with the use of an mobility message authentication option carried in the BU/BA messages.
- （例えば、セルラ無線ネットワークのような）帯域幅が制約されたネットワークとれるようなインタフェースを介して送信されるシグナリングメッセージの数を最小限にする強い要望が存在します。 MNとHAの間でSAを設定するための主要な手段としてインターネットキー交換（IKE）に依存しているMIPv6のシグナリングは、BU / BAメッセージで運ばモビリティメッセージ認証オプションの使用と比較してより多くのシグナリングメッセージが必要です。
One such example of networks that have such characteristics are CDMA networks as defined in [3GPP2].
このような特性を持っているネットワークの一つ、例えば[3GPP2]で定義されるようにCDMAネットワークです。
This document presents a lightweight mechanism to authenticate the Mobile Node at the Home Agent or at the Authentication, Authorization, and Accounting (AAA) server in Home network (AAAH) based on a shared-key-based mobility security association between the Mobile Node and the respective authenticating entity. This shared-key-based mobility security association (shared-key-based mobility SA) may be statically provisioned or dynamically created. The term
この文書では、モバイルノード間の共有キー・ベースのモビリティセキュリティアソシエーションに基づいて、ホームネットワーク（AAAH）で軽量なホームエージェントで、または認証でモバイルノードを認証するためのメカニズム、認可、アカウンティング（AAA）サーバーを提示し、それぞれの認証エンティティ。この共有キー・ベースのモビリティセキュリティアソシエーション（共有キー・ベースのモビリティSA）は、静的プロビジョニングまたは動的に作成することができます。用語
"mobility security association" referred to in this document is understood to be a "shared-key-based Mobile IPv6 authentication" security association.
本書でいう「モビリティセキュリティアソシエーション」は、「共有鍵に基づくモバイルIPv6認証」セキュリティアソシエーションであると理解されます。
This document introduces new mobility options to aid in authentication of the Mobile Node to the Home Agent or AAAH server. The confidentiality protection of Return Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) is not provided when these options are used for authentication of the Mobile Node to the Home Agent. Thus, unless the network can guarantee such protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option.
この文書では、ホームエージェントまたはAAAHサーバへの移動ノードの認証を支援するための新しいモビリティオプションを紹介します。これらのオプションは、ホームエージェントにモバイルノードの認証に使用されている場合往復経路メッセージの機密性保護とモバイルプレフィックスディスカバリー（MPD）の認証/完全性保護が提供されていません。ネットワークは、（例えば、3GPP2ネットワークのように）、このような保護を保証することができない限り、モビリティメッセージ認証オプションを使用している場合このように、経路最適化とモバイルプレフィックスディスカバリーは使用すべきではありません。
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.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC 2119に記載されるように解釈されます。
First (size, input)
最初の（サイズ、入力）
Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used.
最初の「サイズ」のビットは使用されずに残っているように、この明細書におけるいくつかの式は、機能的な形態「まず（サイズ、入力）」「入力」データの切り捨てを示すために使用します。
Shared-key-based Mobility Security Association
共有キーベースのモビリティセキュリティアソシエーション
Security relation between the Mobile Node and its Home Agent, used to authenticate the Mobile Node for mobility service. The shared-key-based mobility security association between Mobile Node and Home Agent consists of a mobility Security Parameter Index (SPI), a shared key, an authentication algorithm, and the replay protection mechanism in use.
モビリティサービスのためのモバイルノードを認証するために使用されるモバイルノードとそのホームエージェントとのセキュリティ関係、。モバイルノードとホームエージェント間の共有キー・ベースのモビリティセキュリティアソシエーションは、モビリティ、セキュリティパラメータインデックス（SPI）、共有キー、認証アルゴリズム、および使用中のリプレイ保護メカニズムで構成されています。
Mobility SPI
モビリティSPI
A number in the range [0-4294967296] used to index into the shared-key-based mobility security associations.
範囲の数[0-4294967296]は共有鍵ベースのモビリティセキュリティアソシエーションへのインデックスに使用されます。
The figure below describes the sequence of messages sent and received between the MN and HA in the registration process. Binding Update (BU) and Binding Acknowledgement (BA) messages are used in the registration process.
以下の図は、登録プロセスでMNとHAの間で送受信されたメッセージのシーケンスを説明します。バインディング更新（BU）及び確認応答を結合（BA）メッセージは、登録プロセスで使用されます。
MN HA/AAAH
AAAH /誰です
| BU to HA |
(a) |----------------------------------------------------->|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| HA/AAAH authenticates MN
| |
| |
| BA to MN |
(b) |<-----------------------------------------------------|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
Figure 1: Home Registration with Authentication Protocol
図1：認証プロトコルとホーム登録
The Mobile Node MUST use the Mobile Node Identifier option, specifically the MN-NAI mobility option as defined in [RFC4283] to identify itself while authenticating with the Home Agent. The Mobile Node uses the Mobile Node Identifier option as defined in [RFC4283] to identify itself as may be required for use with some existing AAA infrastructure designs.
[RFC4283]で定義されるように、モバイルノードがホームエージェントと認証中に自分自身を識別するために、モバイルノード識別子オプション、具体的にMN-NAI移動性オプションを使用しなければなりません。 [RFC4283]で定義されるようにモバイルノードは、いくつかの既存のAAAインフラストラクチャの設計で使用するために必要とされ得るように自分自身を識別するためにモバイルノード識別子オプションを使用します。
The Mobile Node MAY use the Message Identifier option as defined in Section 6 for additional replay protection.
追加のリプレイ保護のための6節で定義されているモバイルノードは、メッセージ識別子オプションを使用するかもしれません。
The mobility message authentication option described in Section 5 may be used by the Mobile Node to transfer authentication data when the Mobile Node and the Home Agent are utilizing a mobility SPI (a number in the range [0-4294967296] used to index into the shared-key-based mobility security associations) to index between multiple mobility security associations.
セクション5に記載のモビリティメッセージ認証オプションは、モバイルノードとホームエージェントモビリティSPI（共有へのインデックスに使用される範囲[0から4294967296]に番号を利用している認証データを転送するためにモバイルノードによって使用されてもよいです-keyベースのモビリティセキュリティアソシエーション）は、複数のモビリティセキュリティアソシエーション間のインデックスへ。
This section defines a mobility message authentication option that may be used to secure Binding Update and Binding Acknowledgement messages. This option can be used along with IPsec or preferably as an alternate mechanism to authenticate Binding Update and Binding Acknowledgement messages in the absence of IPsec.
このセクションでは、バインディング更新と結合確認メッセージを保護するために使用することができるモビリティメッセージ認証オプションを定義します。このオプションは、IPsecを伴うまたは好ましくたIPsecの非存在下で結合更新と結合確認メッセージを認証するための代替メカニズムとして一緒に使用することができます。
This document also defines subtype numbers, which identify the mode of authentication and the peer entity to authenticate the message. Two subtype numbers are specified in this document. Other subtypes may be defined for use in the future.
この文書は、メッセージを認証するための認証モードとピアエンティティを識別するサブタイプ番号を定義します。二つのサブタイプ番号は、この文書で指定されています。他のサブタイプは、将来の使用のために定義することができます。
Only one instance of a mobility message authentication option of a particular subtype can be present in the message. One message may contain multiple instances of the mobility message authentication option with different subtype values. If both MN-HA and MN-AAA authentication options are present, the MN-HA authentication option must be present before the MN-AAA authentication option (else, the HA MUST discard the message).
特定のサブタイプのモビリティメッセージ認証オプションのインスタンスは1つだけのメッセージに存在することができます。一つのメッセージは、異なるサブタイプの値を持つモビリティメッセージ認証オプションの複数のインスタンスが含まれていてもよいです。 MN-HAとMN-AAA認証オプションの両方が存在する場合には、MN-HA認証オプションは、MN-AAA認証オプションの前に存在している必要があります（他に、HAはメッセージを捨てなければなりません）。
When a Binding Update or Binding Acknowledgement is received without a mobility message authentication option and the entity receiving it is configured to use the mobility message authentication option or has the shared-key-based mobility security association for the mobility message authentication option, the entity should silently discard the received message.
結合更新または結合確認は、モビリティメッセージ認証オプションなしで受信され、それを受信エンティティは、モビリティメッセージ認証オプションを使用するように構成された、またはモビリティメッセージ認証オプションの共有鍵ベースのモビリティセキュリティアソシエーションを有している、エンティティが必要があるとき静かに受信したメッセージを破棄する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mobility Message Authentication Option
図2：モビリティメッセージ認証オプション
Option Type:
オプションタイプ：
AUTH-OPTION-TYPE value 9 has been defined by IANA. An 8-bit identifier of the type mobility option.
AUTH-OPTION-TYPE値9は、IANAによって定義されています。型モビリティオプションの8ビットの識別子。
Option Length:
オプションの長さ：
8-bit unsigned integer, representing the length in octets of the Subtype, mobility Security Parameter Index (SPI) and Authentication Data fields.
サブタイプ、モビリティセキュリティパラメータインデックス（SPI）と認証データフィールドのオクテットの長さを示す8ビットの符号なし整数。
Subtype:
サブタイプ：
A number assigned to identify the entity and/or mechanism to be used to authenticate the message.
メッセージを認証するために使用されるエンティティ及び/又は機構を識別するために割り当てられた番号。
Mobility SPI:
モビリティSPI：
Mobility Security Parameter Index
モビリティセキュリティパラメータインデックス
Authentication Data:
認証データ：
This field has the information to authenticate the relevant mobility entity. This protects the message beginning at the Mobility Header up to and including the mobility SPI field.
このフィールドは、関連する移動エンティティを認証するための情報を持っています。これは、メッセージまでのモビリティヘッダで始まり、モビリティSPIフィールドを含むを保護します。
Alignment requirements :
アライメント要件：
The alignment requirement for this option is 4n + 1.
このオプションのアライメント要件は4N + 1です。
The format of the MN-HA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 1. The MN-HA mobility message authentication option is used to authenticate the Binding Update and Binding Acknowledgement messages based on the shared-key-based security association between the Mobile Node and the Home Agent.
MN-HAモビリティメッセージ認証オプションのフォーマットは、図2に定義されているように、このオプションは、MN-HAモビリティメッセージ認証オプションは、共有に基づいて、バインディング更新と結合確認メッセージを認証するために使用される1のサブタイプ値を使用しモバイルノードとホームエージェント間の-keyベースのセキュリティアソシエーション。
The shared-key-based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, a key, an authentication algorithm, and the replay protection mechanism in use. The mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 16 octets in length. The authentication algorithm is HMAC_SHA1. The replay protection mechanism may use the Sequence number as specified in [RFC3775] or the Timestamp option as defined in Section 6. If the Timestamp option is used for replay protection, the mobility security association includes a "close enough" field to account for clock drift. A default value of 7 seconds SHOULD be used. This value SHOULD be greater than 3 seconds.
この仕様書内で使用されるモバイルノードとホームエージェント間の共有キー・ベースのモビリティセキュリティアソシエーションは、モビリティSPI、キー、認証アルゴリズム、および使用中のリプレイ保護メカニズムで構成されています。モビリティSPIは、範囲[0-255]が予約されている範囲[0から4294967296]の数値です。キーは任意の値で構成され、長さは16オクテットです。認証アルゴリズムはHMAC_SHA1です。タイムスタンプオプションがリプレイ保護のために使用されている場合は第6節で定義されたリプレイ保護メカニズムは[RFC3775]で指定されたシーケンス番号またはタイムスタンプオプションを使用して、モビリティセキュリティアソシエーションは、クロックを考慮するために、フィールド「十分近い」が含まドリフト。 7秒のデフォルト値を使用する必要があります。この値は、3秒以上でなければなりません。
The MN-HA mobility message authentication option MUST be the last option in a message with a mobility header if it is the only mobility message authentication option in the message.
それはメッセージで唯一のモビリティメッセージ認証オプションである場合にMN-HAモビリティメッセージ認証オプションは、モビリティヘッダとメッセージの最後のオプションでなければなりません。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
認証データは、メッセージを、モビリティ・ヘッダ・アップから開始し、このオプションのモビリティSPI値などに基づいて計算されます。
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Data))
認証データ=最初の（96、HMAC_SHA1（MN-HA共有キー、モビリティ・データ））
Mobility Data = care-of address | home address | Mobility Header (MH) Data
モビリティデータ=気付アドレス|自宅の住所|モビリティヘッダ（MH）データ
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in the Mobility Header MUST be set to 0 to calculate the Mobility Data.
MHデータは、このオプションのモビリティSPIフィールドを含むにしてまでモビリティヘッダの内容です。モビリティヘッダのチェックサムフィールドは、モビリティデータを計算するために0に設定しなければなりません。
The first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field.
メッセージ認証コード（MAC）の結果から最初の96ビットは、認証データフィールドとして使用されます。
The assumption is that the Mobile Node has a shared-key-based security association with the Home Agent. The Mobile Node MUST include this option in a BU if it has a shared-key-based mobility security association with the Home Agent. The Home Agent MUST include this option in the BA if it received this option in the corresponding BU and Home Agent has a shared-key-based mobility security association with the Mobile Node.
仮定は、モバイルノードがホームエージェントと共有キー・ベースのセキュリティ・アソシエーションを持っていることです。それはホームエージェントと共有キー・ベースのモビリティセキュリティアソシエーションを持っている場合、モバイルノードは、BUでこのオプションを含まなければなりません。それは、対応するBUには、このオプションを受信し、ホームエージェントは、モバイルノードと共有キー・ベースのモビリティセキュリティアソシエーションを持っている場合、ホームエージェントは、BAでこのオプションを含まなければなりません。
The Mobile Node or Home Agent receiving this option MUST verify the authentication data in the option. If authentication fails, the Home Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home Agent does not have shared-key-based mobility SA, Home Agent MUST discard the BU. The Home Agent MAY log such events.
このオプションを受け取るモバイルノードまたはホームエージェントは、オプションで認証データを確かめなければなりません。認証が失敗した場合、ホームエージェントは、ステータスコードMIPV6-AUTH-FAILとBAを送らなければなりません。ホームエージェントは、共有キー・ベースのモビリティSAを持っていない場合は、ホームエージェントは、BUを捨てなければなりません。ホームエージェントは、このようなイベントを記録することがあります。
The format of the MN-AAA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared mobility security association between the Mobile Node and AAA server in Home network (AAAH). It is not used in Binding Acknowledgement messages. The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA mobility message authentication option (Section 5.1).
MN-AAAモビリティメッセージ認証オプションのフォーマットは、図2に定義されているように、このオプションは、MN-AAA認証モビリティオプションが間の共有モビリティセキュリティアソシエーションに基づいて、Binding Updateメッセージを認証するために使用される2のサブタイプ値を使用しホームネットワークにおけるモバイルノードとAAAサーバ（AAAH）。これは、受信確認メッセージをバインディングで使用されていません。対応するバインディング受信確認メッセージは、MN-HAモビリティメッセージ認証オプション（セクション5.1）を使用して認証する必要があります。
The MN-AAA mobility message authentication option must be the last option in a message with a mobility header. The corresponding response MUST include the MN-HA mobility message authentication option, and MUST NOT include the MN-AAA mobility message authentication option.
MN-AAAモビリティメッセージ認証オプションは、モビリティヘッダとメッセージの最後のオプションでなければなりません。対応する応答は、MN-HAモビリティメッセージ認証オプションを含まなければならない、とMN-AAAモビリティメッセージ認証オプションを含んではいけません。
The Mobile Node MAY use the Mobile Node Identifier option [RFC4283] to enable the Home Agent to make use of available AAA infrastructure.
モバイルノードは、利用可能なAAAインフラストラクチャを利用するためにホームエージェントを有効にするには、モバイルNode Identifierオプション[RFC4283]を使用するかもしれません。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
認証データは、メッセージを、モビリティ・ヘッダ・アップから開始し、このオプションのモビリティSPI値などに基づいて計算されます。
The authentication data shall be calculated as follows:
次のように認証データが計算されなければなりません。
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
認証データ= hash_fn（MN-AAA共有キー、MAC_Mobilityデータ）
hash_fn() is decided by the value of mobility SPI field in the MN-AAA mobility message authentication option.
hash_fnは（）MN-AAAモビリティメッセージ認証オプションの移動度SPIフィールドの値によって決定されます。
SPI = HMAC_SHA1_SPI:
MES = HMATS_SHA1_SPI：
If mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data is calculated as follows:
モビリティSPIはよく知られている値HMAC_SHA1_SPIを有する場合、hash_fn（）HMAC_SHA1あります。 HMAC_SHA1_SPIを使用する場合は、BUはHMAC_SHA1認証を使用してAAAによって認証されます。次のようにこの場合、MAC_Mobilityデータが計算されます。
MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MAC_Mobilityデータ= SHA1（気付アドレス|ホームアドレス| MHデータ）
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option.
MHデータは、このオプションのモビリティSPIフィールドを含むにしてまでモビリティヘッダの内容です。
The use of the MN-AAA mobility message authentication option assumes that AAA entities at the home site communicate with the HA via an authenticated channel. Specifically, a BU with the MN-AAA mobility message authentication option is authenticated via a home AAA server. The specific details of the interaction between the HA and the AAA server is beyond the scope of this document.
MN-AAAモビリティメッセージ認証オプションを使用すると、ホームサイトでのAAAエンティティが認証されたチャネルを介してHAと通信していることを前提としています。具体的には、MN-AAAモビリティメッセージ認証オプション付きのBUはホームAAAサーバを経由して認証されます。 HAとAAAサーバ間の相互作用の具体的な詳細は、このドキュメントの範囲を超えています。
When the Home Agent receives a Binding Update with the MN-AAA mobility message authentication option, the Binding Update is authenticated by an entity external to the Home Agent, typically a AAA server.
ホームエージェントは、MN-AAAモビリティメッセージ認証オプションを使用してバインディングアップデートを受信した場合、バインディングアップデートをホームエージェント、一般的にAAAサーバに外部のエンティティによって認証されます。
In case of authentication failure, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, if a shared-key-based mobility security association to be used between Mobile Node and Home Agent for authentication exists. If there is no shared-key-based mobility security association, HA drops the Binding Update. HA may log the message for administrative action.
認証のためにモバイルノードとホームエージェントとの間で使用される共有鍵ベースのモビリティセキュリティアソシエーションが存在する場合、認証失敗の場合には、ホーム・エージェントは、モバイルノードにステータスコードMIPV6-AUTH-FAILと結合肯定応答を送信しなければなりません。何も共有キー・ベースのモビリティセキュリティアソシエーションが存在しない場合は、HAは、バインディングアップデートを削除します。 HAは、管理アクションのメッセージを記録することがあります。
Upon receiving a Binding Acknowledgement with status code MIPV6- AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the Home Agent.
ステータスコードMIPV6- AUTH-FAILとの結合確認応答を受信すると、モバイルノードは、ホームエージェントに新しいバインディングアップデートの送信を停止する必要があります。
The Mobility message replay protection option MAY be used in Binding Update/Binding Acknowledgement messages when authenticated using the mobility message authentication option as described in Section 5.
モビリティメッセージリプレイ保護オプションは、セクション5で説明したように、モビリティメッセージ認証オプションを使用して認証する場合の更新/バインディング受信確認メッセージをバインディングで使用されるかもしれません。
The mobility message replay protection option is used to let the Home Agent verify that a Binding Update has been freshly generated by the Mobile Node and not replayed by an attacker from some previous Binding Update. This is especially useful for cases where the Home Agent does not maintain stateful information about the Mobile Node after the binding entry has been removed. The Home Agent does the replay protection check after the Binding Update has been authenticated. The mobility message replay protection option when included is used by the Mobile Node for matching BA with BU.
モビリティメッセージリプレイ保護オプションは、ホームエージェントはバインディングアップデートがたてモバイルノードによって生成され、いくつかの以前のバインディング・アップデートからの攻撃者によってリプレイではないされたことを確認してみましょうするために使用されます。これは、バインディングエントリが削除された後、ホームエージェントは、モバイルノードについてのステートフル情報を保持していない場合に特に便利です。ホームエージェントはバインディングアップデートが認証された後にリプレイ保護チェックを行います。 BUとBAを一致させるためのモバイルノードによって使用されている含まモビリティメッセージリプレイ保護オプション。
If this mode of replay protection is used, it needs to be part of the shared-key-based mobility security association.
リプレイ保護のこのモードを使用する場合は、共有キー・ベースのモビリティセキュリティアソシエーションの一部である必要があります。
If the policy at Home Agent mandates replay protection using this option (as opposed to the sequence number in the Mobility Header in Binding Update) and the Binding Update from the Mobile Node does not include this option, the Home Agent discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD.
ホーム・エージェントのポリシーは、このオプションが含まれていません。このオプション（バインディング更新にモビリティヘッダ内のシーケンス番号ではなく）とモバイルノードからバインディングアップデートを使用して再生保護を義務付けている場合、ホームエージェントは、BUを破棄し、設定しますMIPV6-MESG-ID-REQDにBAでステータスコード。
When the Home Agent receives the mobility message replay protection option in Binding Update, it MUST include the mobility message replay protection option in Binding Acknowledgement. Appendix A provides details regarding why the mobility message replay protection option MAY be used when using the authentication option.
ホームエージェントはバインディングアップデートにおけるモビリティメッセージリプレイ保護オプションを受信すると、受信確認をバインディングにおけるモビリティメッセージリプレイ保護オプションを含まなければなりません。付録Aは、認証オプションを使用するときにモビリティメッセージリプレイ保護オプションを使用することができる理由に関する詳細を提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mobility Message Replay Protection Option
図3：モビリティメッセージリプレイ保護オプション
Option Type:
オプションタイプ：
MESG-ID-OPTION-TYPE value 10 has been defined by IANA. An 8-bit identifier of the type mobility option.
MESG-ID-OPTION-TYPE値10は、IANAによって定義されています。型モビリティオプションの8ビットの識別子。
Option Length:
オプションの長さ：
8-bit unsigned integer, representing the length in octets of the Timestamp field.
タイムスタンプフィールドのオクテットの長さを示す8ビットの符号なし整数。
Timestamp:
タイムスタンプ：
This field carries the 64 bit timestamp.
このフィールドは、64ビットのタイムスタンプを運びます。
Alignment requirements :
アライメント要件：
The alignment requirement for this option is 8n + 2.
このオプションのアライメント要件は、8N + 2です。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the shared-key-based mobility security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. The two nodes must have adequately synchronized time-of-day clocks.
タイムスタンプリプレイ保護の基本的な原理は、メッセージを生成するノードは、現在の時刻を挿入し、メッセージを受信したノードがこのタイムスタンプがその日の独自の時間に十分に近いかどうかをチェックすることです。ノード間で共有キー・ベースのモビリティセキュリティアソシエーションで異なる指定がない限り、7秒のデフォルト値は、時間差を制限するために使用されるかもしれません。この値は、3秒以上でなければなりません。 2つのノードが適切に時刻クロックを同期している必要があります。
The Mobile Node MUST set the Timestamp field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC1305]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits that are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit timestamp used in a Binding Update from the Mobile Node MUST be greater than that used in any previous successful Binding Update.
モバイルノードは、ネットワークタイムプロトコル（NTP）[RFC1305]によって指定されるようにフォーマットされた64ビット値にタイムスタンプフィールドを設定しなければなりません。 NTPフォーマットの下位32ビットは小数秒を表し、時間ソースから利用できないこれらのビットは、乱数の良好な供給源から生成されるべきです。タイムスタンプを使用している場合、モバイルノードからのバインディング更新に使用される64ビットのタイムスタンプが以前の成功した結合更新に使用されるものよりも大きくなければならないこと、しかし、注意してください。
After successful authentication of Binding Update (either locally at the Home Agent or when a success indication is received from the AAA server), the Home Agent MUST check the Timestamp field for validity. In order to be valid, the timestamp contained in the Timestamp field MUST be close enough to the Home Agent's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting Mobile Node.
（ホームエージェントまたは成功指示がAAAサーバから受信したときに、ローカル）バインディング更新の認証が成功した後、ホームエージェントは、有効性のためにタイムスタンプフィールドをチェックしなければなりません。有効であるためには、タイムスタンプフィールドに含まれるタイムスタンプは、ホームエージェントの時刻クロックに十分に近くなければならないとタイムスタンプが要求モバイルノードのすべての以前に受け入れられたタイムスタンプよりも大きくなければなりません。
If the timestamp is valid, the Home Agent copies the entire Timestamp field into the Timestamp field in the BA it returns to the Mobile Node. If the timestamp is not valid, the Home Agent copies only the low-order 32 bits into the BA, and supplies the high-order 32 bits from its own time of day.
タイムスタンプが有効であれば、ホームエージェントコピーBAにおけるタイムスタンプフィールドに全体のタイムスタンプフィールドには、モバイルノードに戻ります。タイムスタンプは、BAにホームエージェントのみをコピーし、下位32ビット、有効ではありません、その日の自身の時間から上位32ビットを提供する場合。
If the Timestamp field is not valid but the authentication of the BU succeeds, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. The Home Agent does not create a binding cache entry if the timestamp check fails.
タイムスタンプフィールドが有効ではないですが、BUの認証が成功した場合、ホームエージェントは、ステータスコードMIPV6-ID-MISMATCHとの結合謝辞を送らなければなりません。タイムスタンプのチェックが失敗した場合、ホームエージェントはバインディングキャッシュエントリを作成しません。
If the Mobile Node receives a Binding Acknowledgement with the code MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by processing the MN-HA authentication mobility option.
モバイルノードは、コードMIPV6-ID-MISMATCHとの結合肯定応答を受信した場合、モバイルノードは、MN-HA認証モビリティオプションを処理することによって、BAを認証する必要があります。
If authentication succeeds, the Mobile Node MUST adjust its timestamp and send subsequent Binding Update using the updated value.
認証が成功した場合、モバイルノードは、そのタイムスタンプを調整し、更新された値を使用して、後続のバインディング更新を送らなければなりません。
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH status code, the Mobile Node MUST compare the Timestamp value in the BA to the Timestamp value it sent in the corresponding BU. If the values match, the Mobile Node proceeds to process the MN-HA authentication data in the BA. If the values do not match, the Mobile Node silently discards the BA.
MIPV6-ID不一致ステータスコードを含まないBAを受信すると、モバイルノードは、対応するBUで送信されたタイムスタンプ値にBAのタイムスタンプ値を比較しなければなりません。値が一致した場合、モバイルノードはBAでMN-HA認証データを処理するために進みます。値が一致しない場合、モバイルノードは静かにBAを破棄します。
This document proposes new mobility message authentication options to authenticate the control message between Mobile Node, Home Agent, and/or home AAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages. The MN-AAA mobility message authentication option provide for authentication with AAA infrastructure.
この文書では、モバイルノード、ホームエージェント、および/または（IPsecの代替として）ホームAAAとの間の制御メッセージを認証するために、新しいモビリティメッセージ認証オプションを提案しています。新しいオプションは、アップデートをバインドし、受信確認メッセージをバインディングの認証を提供します。 MN-AAAモビリティメッセージ認証オプションは、AAAインフラストラクチャで認証を提供します。
This specification also introduces an optional replay protection mechanism in Section 6, to prevent replay attacks. The sequence number field in the Binding Update is not used if this mechanism is used. This memo defines the timestamp option to be used for mobility message replay protection.
また、この仕様は、リプレイ攻撃を防ぐために、第6節では、オプションのリプレイ保護メカニズムを導入しています。このメカニズムが使用されている場合、結合更新のシーケンス番号フィールドは使用されません。このメモは、モビリティメッセージの再生保護のために使用されるタイムスタンプオプションを定義します。
IANA services are required for this specification. The values for new mobility options and status codes must be assigned from the Mobile IPv6 [RFC3775] numbering space.
IANAのサービスがこの仕様のために必要とされます。新しいモビリティオプションとステータスコードの値は、モバイルIPv6 [RFC3775]の番号空間から割り当てなければなりません。
The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6, have been assigned. The values are 9 for the AUTH-OPTION-TYPE and 10 for the MESG-ID-OPTION-TYPE Mobility Option.
モビリティオプションタイプAUTH-OPTION-TYPEとMESG-ID-OPTION-TYPEの値は、第5及び第6節で定義されるように、割り当てられています。値はMESG-ID-OPTION型モビリティオプションのためのAUTH-OPTION-TYPEと10 9です。
The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and MIPV6-MESG-ID-REQD, as defined in Section 6 and Section 5.3, have been assigned. The values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
ステータスコードMIPV6-ID-MISMATCH、MIPv6の-AUTH-FAIL、およびMIPV6-MESG-ID-REQDの値は、セクション6及びセクション5.3で定義されるように、割り当てられています。値はMIPV6-AUTH-FAIL用MIPV6-MESG-ID-REQDためMIPV6-ID-MISMATCH 145および146のために144です。
A new section for enumerating algorithms identified by specific mobility SPIs within the range 0-255 has to be added to
0から255の範囲内の特定のモビリティのSPIによって識別アルゴリズムを列挙するための新しいセクションが追加されなければなりません
http://www.iana.org/assignments/mobility-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／もびぃｔｙーぱらめてｒｓ
The currently defined values are as follows:
次のように現在定義されている値は次のとおりです。
The value 0 should not be assigned.
値0を割り当てるべきではありません。
The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
セクション5.2で定義された値3をHMAC_SHA1_SPIのために予約されています。
The value 5 is reserved for use by 3GPP2.
値5は、3GPP2によって使用するために予約されています。
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
この名前空間のための新しい値は、IETFコンセンサスを使用して割り当てることができます。 [RFC2434]。
In addition, IANA has created a new namespace for the Subtype field of the MN-HA and MN-AAA mobility message authentication options under
また、IANAは、MN-HAとMN-AAAモビリティメッセージ認証オプションのサブタイプフィールドの下のための新しい名前空間を作成しました
http://www.iana.org/assignments/mobility-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／もびぃｔｙーぱらめてｒｓ
The currently allocated values are as follows:
次のように現在割り当てられている値は次のとおりです。
1 MN-HA mobility message authentication option Section 5.1
1 MN-HAのモビリティメッセージ認証オプションセクション5.1
2 MN-AAA mobility message authentication option Section 5.2
2 MN-AAAモビリティメッセージ認証オプションセクション5.2
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
この名前空間のための新しい値は、IETFコンセンサスを使用して割り当てることができます。 [RFC2434]。
The authors would like to thank Basavaraj Patil, Charlie Perkins, Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior for their thorough review and suggestions on the document. The authors would like to acknowledge the fact that a similar authentication method was considered in base protocol [RFC3775] at one time.
著者は、彼らの徹底的な見直しと文書の提案のためにBasavarajパティル、チャーリー・パーキンス、ビジェイDevarapalli、ヤリArkko、およびゴパルDommety、およびアビLIORに感謝したいと思います。著者は、同様の認証方法は、一度基本プロトコル[RFC3775]に考慮されたという事実を認めるしたいと思います。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, November 2005.
[RFC4283]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のためのモバイルノード識別子オプション"、RFC 4283、2005年11月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, September 2005.
[3GPP2] "CDMA2000無線IPネットワーク標準"、3GPP2 X.S0011-D、2005年9月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
Appendix A. Rationale for Mobility Message Replay Protection Option
モビリティメッセージリプレイ保護オプション付録A.根拠
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility header to prevent replay attacks. There are two aspects that stand out in regards to using the Sequence Number to prevent replay attacks.
モバイルIPv6 [RFC3775]は、リプレイ攻撃を防ぐために、モビリティヘッダ内のシーケンス番号を規定します。リプレイ攻撃を防ぐために、シーケンス番号を使用しての点で際立って2つの側面があります。
First, the specification states that the Home Agent should accept a BU with a Sequence Number greater than the Sequence Number from the previous Binding Update. This implicitly assumes that the Home Agent has some information regarding the Sequence Number from the previous BU (even when the binding cache entry is not present). Second, the specification states that if the Home Agent has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this Mobile Node.
まず、仕様では、ホームエージェントは、以前のバインディング更新からシーケンス番号よりも大きいシーケンス番号とBUを受け入れるべきであると述べています。これは、暗黙のうちにホームエージェントは、以前のBU（バインディングキャッシュエントリが存在しない場合でも）からシーケンス番号に関するいくつかの情報を持っていることを前提としています。第二に、仕様では、ホームエージェントが示されたホームアドレスにはバインディングキャッシュエントリがない場合、それはこのモバイルノードから受信したバインディングアップデートで任意のシーケンス番号値を受け入れなければならないと述べています。
With the mechanism defined in this document, it is possible for the Mobile Node to register with a different Home Agent during each mobility session. Thus, it is unreasonable to expect each Home Agent in the network to maintain state about the Mobile Node. Also, if the Home Agent does not cache information regarding sequence number, as per the second point above, a replayed BU can cause a Home Agent to create a binding cache entry for the Mobile Node. Thus, when authentication option is used, Sequence Number does not provide protection against replay attack.
モバイルノードは、各モビリティセッション中に別のホームエージェントに登録するために、この文書で定義されたメカニズムで、それは可能です。したがって、モバイルノードについての状態を維持するために、ネットワーク内の各ホームエージェントを期待するのは無理です。ホームエージェントは、シーケンス番号に関する情報をキャッシュしない場合にも、上記第二の点ごとに、リプレイBUは、モバイルノードのバインディングキャッシュエントリを作成するために、ホームエージェントを引き起こす可能性があります。このように、認証オプションを使用する場合、シーケンス番号は、リプレイ攻撃に対する保護を提供していません。
One solution to this problem (when the Home Agent does not save state information for every Mobile Node) would be for the Home Agent to reject the first BU and assign a (randomly generated) starting sequence number for the session and force the Mobile Node to send a fresh BU with the suggested sequence number. While this would work in most cases, it would require an additional round trip, and this extra signaling and latency is not acceptable in certain deployments [3GPP2]. Also, this rejection and using sequence number as a nonce in rejection is a new behavior that is not specified in [RFC3775].
ホームエージェントは最初のBUを拒否し、セッションのために（ランダムに生成）開始シーケンス番号を割り当て、移動ノードを強制するために、この問題（ホームエージェントは、すべてのモバイルノードの状態情報を保存していない場合）に対する一つの解決策は次のようになります提案されたシーケンス番号と新鮮なBUを送信します。これは、ほとんどの場合に働くだろうが、それは追加のラウンドトリップが必要となり、この余分なシグナリングおよびレイテンシが特定の展開[3GPP2]に受け入れられません。また、この拒否、拒否でナンスとしてシーケンス番号を使用しては、[RFC3775]で指定されていない新しい動作です。
Thus, this specification uses the mobility message replay protection option to prevent replay attacks. Specifically, timestamps are used to prevent replay attacks as described in Section 6.
したがって、この仕様は、リプレイ攻撃を防ぐために、モビリティメッセージリプレイ保護オプションを使用しています。具体的には、タイムスタンプはセクション6で説明したように、リプレイ攻撃を防ぐために使用されます。
It is important to note that as per Mobile IPv6 [RFC3775] this problem with sequence number exists. Since the base specification mandates the use of IPsec (and naturally that goes with IKE in most cases), the real replay protection is provided by IPsec/IKE. In case of BU/BA between Mobile Node and Client Node (CN), the liveness proof is provided by the use of nonces that the CN generates.
モバイルIPv6 [RFC3775]に従ってシーケンス番号と、この問題が存在することに注意することが重要です。基本仕様は（そして当然それはほとんどの場合、IKEとなる）のIPsecの使用を義務付けているため、実際のリプレイ保護は、IPSec / IKEによって提供されます。モバイルノードとクライアントノード（CN）との間のBU / BAの場合には、ライブネス証拠はCNが生成するノンスを使用することによって提供されます。
Authors' Addresses
著者のアドレス
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpeshパテルシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
電話：+1 408-853-9580電子メール：alpesh@cisco.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
ケント・レオンシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408-526-5030 EMail: kleung@cisco.com
電話：+1 408-526-5030電子メール：kleung@cisco.com
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
モハメド・カリルNortel Networksの2221レイクサイドブルバードリチャードソン、TX 75082米国
Phone: +1 972-685-0574 EMail: mkhalil@nortel.com
電話：+1 972-685-0574電子メール：mkhalil@nortel.com
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
ハシーブアクタールNortel Networksの2221レイクサイドブルバードリチャードソン、TX 75082米国
Phone: +1 972-684-4732 EMail: haseebak@nortel.com
電話：+1 972-684-4732電子メール：haseebak@nortel.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntalチョードリースタレントネットワークス30・インターナショナル・プレイステュークスベリー、マサチューセッツ州01876米国
Phone: +1 214 550 1416 EMail: kchowdhury@starentnetworks.com
電話：+1 214 550 1416 Eメール：kchowdhury@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。