Network Working Group J. Arkko
Request for Comments: 4866 Ericsson Research NomadicLab
Category: Standards Track C. Vogt
Universitaet Karlsruhe (TH)
W. Haddad
Ericsson Research
May 2007
Enhanced Route Optimization for Mobile IPv6
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead.
この文書は、下のハンドオフ遅延を提供する、モバイルIPv6経路最適化の強化バージョンを指定し、セキュリティを増加し、シグナリングオーバーヘッドを削減しました。
Table of Contents
目次
1. Introduction ....................................................3
2. Objectives ......................................................4
2.1. Handoff Latency ............................................5
2.2. Security ...................................................5
2.3. Signaling Overhead .........................................7
3. Protocol Design .................................................7
3.1. Cryptographically Generated Home Addresses .................7
3.2. Non-Cryptographic Care-of Addresses ........................8
3.3. Semi-Permanent Security Associations .......................8
3.4. Initial Home Address Tests .................................8
3.5. Concurrent Care-of Address Tests ...........................9
3.6. Credit-Based Authorization .................................9
3.7. Parallel Home and Correspondent Registrations .............10
4. Protocol Operation .............................................10
4.1. Sending Binding Update Messages ...........................10
4.2. Receiving Binding Update Messages .........................18
4.3. Sending Binding Acknowledgment Messages ...................22
4.4. Receiving Binding Acknowledgment Messages .................23
4.5. Sending CGA Parameters ....................................25
4.6. Receiving CGA Parameters ..................................26
4.7. Sending Permanent Home Keygen Tokens ......................27
4.8. Receiving Permanent Home Keygen Tokens ....................28
4.9. Renewing Permanent Home Keygen Tokens .....................28
4.10. Handling Payload Packets .................................28
4.11. Credit Aging .............................................31
4.12. Simultaneous Movements ...................................32
5. Option Formats and Status Codes ................................32
5.1. CGA Parameters Option .....................................32
5.2. Signature Option ..........................................33
5.3. Permanent Home Keygen Token Option ........................34
5.4. Care-of Test Init Option ..................................35
5.5. Care-of Test Option .......................................35
5.6. CGA Parameters Request Option .............................36
5.7. Status Codes ..............................................36
6. Security Considerations ........................................38
6.1. Home Address Ownership ....................................39
6.2. Care-of Address Ownership .................................41
6.3. Credit-Based Authorization ................................43
6.4. Time Shifting Attacks .....................................46
6.5. Replay Attacks ............................................47
6.6. Resource Exhaustion .......................................47
6.7. IP Address Ownership of Correspondent Node ................47
7. Protocol Constants and Configuration Variables .................49
8. IANA Considerations ............................................50
9. Acknowledgments ................................................50
10. References ....................................................51
10.1. Normative References .....................................51
10.2. Informative References ...................................51
Mobile IPv6 route optimization [1] enables mobile and correspondent nodes to communicate via a direct routing path despite changes in IP connectivity on the mobile node side. Both end nodes use a stable "home address" in identifying the mobile node at stack layers above IP, while payload packets are sent or received via a "care-of address" that routes to the mobile node's current network attachment. Mobile IPv6 swaps the home and care-of addresses when a payload packet traverses the IP layer. The association between a mobile node's home address and care-of address is called a "binding" for the mobile node. It is the responsibility of the mobile node to update its binding at the correspondent node through a "correspondent registration" when it changes IP connectivity. A correspondent registration further involves the mobile node's home agent, which proxies the mobile node at the home address and mainly serves as a relay for payload packets exchanged with correspondent nodes that do not support route optimization. The mobile node keeps the home agent up to date about its current care-of address by means of "home registrations".
モバイルIPv6ルート最適化は、[1]モバイルノード側のIP接続性が変化しても直接ルーティングパスを介して通信するモバイルと対応ノードを可能にします。ペイロードパケットはモバイルノードの現在のネットワーク接続にルーティングすることを、「気付アドレス」を介して送信または受信している間、両方のエンド・ノードは、IP上のスタック層にモバイルノードを識別する際に安定した「ホームアドレス」を使用します。ペイロードパケットは、IP層を横断するとき、モバイルIPv6は、家庭と気付アドレスを交換します。モバイルノードのホームアドレスと気付アドレスとの関連付けは、モバイルノードのための「結合」と呼ばれています。 IP接続を変更したときにその「は通信員登録」を通じて相手ノードでの結合を更新するために、モバイルノードの責任です。通信員登録は、さらに、ホームアドレスにモバイルノードをプロキシと主に経路最適化をサポートしていない相手ノードと交換ペイロードパケットの中継として機能するモバイルノードのホームエージェントを含みます。モバイルノードは、現在の「ホーム登録」を用いて気付アドレスに関する最新のホームエージェントを保持します。
From a security perspective, the establishment of a binding during a correspondent registration requires the correspondent node to verify the mobile node's ownership of both the home address and the care-of address. Unprecedented impersonation and flooding threats [5] would arise if correspondent nodes took liberties with respect to these obligations. A correspondent registration hence incorporates a "home address test" and a "care-of address test", collectively called the "return routability procedure". These tests allow the correspondent node to probe the mobile node's reachability at the home and care-of addresses in an ad hoc, non-cryptographic manner. Successful reachability verification at both IP addresses indicates (though it does not guarantee) the mobile node's ownership of the IP addresses, and hence that a binding between the home address and the care-of address is legitimate.
セキュリティの観点から、通信員登録時の結合の確立はホームアドレスと気付アドレスの両方のモバイルノードの所有権を確認するために、通信相手ノードが必要です。前例のない偽装や洪水の脅威通信員ノードがこれらの義務に関して自由を取った場合、[5]生じるであろう。通信員登録は、したがって、「ホームアドレステスト」と「気付アドレステスト」を取り入れ、総称して「リターン・ルータビリティ手順」と呼ばれます。これらのテストは、通信相手ノードは、自宅でモバイルノードの到達可能性を探ると気付アドレスアドホック、非暗号的にすることができます。ホームアドレスと気付アドレスとの間の結合が正当であること、したがって、IPアドレスのモバイルノードの所有権を（それが保証するものではありませんが）、および両方のIPアドレスで成功した到達可能性の検証が示しています。
The advantage of the return routability procedure is that it is lightweight and does not depend on a public-key infrastructure or on a preexisting relationship between the mobile node and the correspondent node. This facilitates a broad deployment. On the other hand, the procedure has an adverse impact on handoff delays since both the home address test and the care-of address test consist of an end-to-end message exchange between the mobile node and the correspondent node. The latency of the home address test may be particularly high because it routes through the home agent. The return routability procedure is also vulnerable to attackers that are in a position where they can interpose in the home or care-of address test. The value of interposing is limited in that the return routability procedure must be repeated in intervals of at most 7 minutes, even in the absence of changes in IP connectivity on the mobile node side. But this comes at the cost of an increased signaling overhead. Much effort has therefore gone into improvements for Mobile IPv6 route optimization [6] that mitigate these disadvantages.
リターン・ルータビリティ手順の利点は、軽量で、公開鍵インフラストラクチャ上またはモバイルノードとコレスポンデントノード間の既存の関係に依存しないことです。これは、幅広い展開を容易にします。一方、手続きは、ホーム・アドレス・テスト及び気付けアドレス・テストの両方ので、ハンドオフ遅延に悪影響は、モバイルノードとコレスポンデントノードとの間のエンドツーエンドのメッセージ交換から構成されています。ホームアドレステストの待ち時間は、ホームエージェントを介して、それをルーティングするので、特に高いかもしれません。リターン・ルータビリティ手順はまた、彼らは自宅で挟むか、気付けアドレステストできる位置にある攻撃に対して脆弱です。介在の値は、リターン・ルータビリティ手順もモバイルノード側のIP接続性の変化が存在しない場合に、最大で7分の間隔で繰り返さなければならないという点で制限されています。しかし、これは増加したシグナリングオーバーヘッドのコストがかかります。多くの努力は、したがって、これらの欠点を緩和するモバイルIPv6経路最適化のための改良[6]に行ってきました。
This document specifies Enhanced Route Optimization, an amendment to route optimization in base Mobile IPv6. Enhanced Route Optimization secures a mobile node's home address against impersonation through an interface identifier that is cryptographically and verifiably bound [2] to the public component of the mobile node's public/private-key pair. The mobile node proves ownership of the home address by providing evidence that it knows the corresponding private key. An initial home address test validates the home address prefix; subsequent home address tests are unnecessary. Enhanced Route Optimization further allows mobile and correspondent nodes to resume bidirectional communications in parallel with pursuing a care-of address test. The latency of the home and care-of address tests are therefore eliminated in most cases. The use of cryptographically generated home addresses also mitigates the threat of impersonators that can interpose on the home address test and thereby facilitate longer binding lifetimes. This leads to increased security and a reduction in signaling overhead. Cryptographically generated home addresses and concurrent care-of address tests are preferably applied together, but a mobile node may choose to use only one of these enhancements.
この文書では、強化されたルート最適化、ベースのモバイルIPv6における経路最適化の改正を指定します。強化されたルート最適化は、モバイルノードの公開/秘密鍵ペアの公開コンポーネントへ[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 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[3]で説明されるように解釈されます。
The design of route optimization in base Mobile IPv6 is in many ways conservative, leaving room to optimize handoff delay, security, and signaling overhead. Enhanced Route Optimization tackles these issues and thus constitutes a more progressive variant of Mobile IPv6.
ベースモバイルIPv6の経路最適化の設計は、ハンドオフ遅延、セキュリティ、およびシグナリングオーバーヘッドを最適化する余地を残して、多くの方法で保守的です。強化されたルート最適化は、これらの問題に取り組むため、モバイルIPv6のより進歩的バリアントを構成しています。
Despite any Mobile IPv6 optimizations, it is important to take into account that mobility-related activities elsewhere in the protocol stack may have their own impact. For example, attachment procedures, access control, and authentication at the link layer contribute their own handoff delays. So do IP layer tasks such as router discovery, neighbor discovery, movement detection, and IP address configuration. The handoff delays and signaling overhead of Mobile IPv6 are typically small compared to the total delay and overhead. The improvements of Enhanced Route Optimization hence ought to be seen in view of the entire protocol stack.
任意のモバイルIPv6の最適化にもかかわらず、他の場所で、プロトコルスタックにおけるモビリティ関連の活動は、自分の影響力を持っていることを考慮することが重要です。例えば、添付ファイルの手順、アクセス制御、およびリンク層での認証は、独自のハンドオフ遅延を貢献しています。だから、そのようなルータディスカバリ、近隣探索、動き検出、およびIPアドレスの設定としてIPレイヤの作業を行います。ハンドオフ遅延とモバイルIPv6のシグナリングオーバーヘッドは、総遅延及びオーバーヘッドに比べて一般的に小さいです。拡張ルート最適化の改良は、したがって全体のプロトコルスタックの図に見られるべきです。
The typical handoff delay in base Mobile IPv6 route optimization is one round-trip time between the mobile node and the home agent for the home registration, one round-trip time between the mobile node and the home agent plus one round-trip time between the home agent and the correspondent node for the return routability procedure, and one one-way time from the mobile node to the correspondent node for the propagation of the Binding Update message. (The assumption here is that the latency of the return routability procedure is dominated by the home address test.) The first payload packet sent to the new care-of address requires one additional one-way time to propagate from the correspondent node to the mobile node. The mobile node can resume transmissions right after it has dispatched the Binding Update message. But if it requests a Binding Acknowledgment message from the correspondent node, communications are usually delayed until this is received.
ベースモバイルIPv6経路最適化における典型的なハンドオフ遅延は、モバイルノードとホーム登録、モバイルノードとホームエージェントプラスとの間の1往復時間との間の1往復時間のホームエージェントとの間の1往復時間でありますBinding Updateメッセージの伝播のためのモバイルノードからコレスポンデントノードにホームエージェントとコレスポンデントノードリターン・ルータビリティ手順のために、1片道時間。 （ここでの仮定はリターン・ルータビリティ手順のレイテンシはホームアドレステストによって支配されていることである。）新気付けアドレスに送信された最初のペイロードパケットは、モバイルに対応するノードから伝播する一つの追加の片道時間を必要とノード。モバイルノードは、それがBinding Updateメッセージを派遣した直後に送信を再開することができます。それは相手ノードからのBinding Acknowledgementメッセージを要求した場合、これが受信されるまでしかし、通信は通常、遅れています。
Handoff delays in base Mobile IPv6 route optimization are additive to other delays at the IP layer or link layer. They can cause perceptible quality degradations for interactive and real-time applications. TCP bulk-data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput [7]. An objective of Enhanced Route Optimization is hence a reduction of the handoff latency.
ベースモバイルIPv6経路最適化におけるハンドオフ遅延は、IP層またはリンク層における他の遅延に加算されます。彼らは、インタラクティブおよびリアルタイム・アプリケーションのための知覚品質の劣化を引き起こす可能性があります。長いハンドオフ待ち時間は、連続する再送タイムアウトや劣化スループット[7]につながる可能性があるのでTCPバルクデータ転送も同様に影響を受けます。強化されたルート最適化の目的は、したがって、ハンドオフの待ち時間の短縮です。
The return routability procedure was designed with the objective to provide a level of security that compares to that of today's non-mobile Internet [5]. As such, it protects against impersonation, denial-of-service, and flooding threats that do not exist in the non-mobile Internet, but that the introduction of mobility would introduce in the absence of appropriate countermeasures. In particular, the return routability procedure satisfies the following requirements:
リターン・ルータビリティ手順は、今日の非モバイル・インターネット[5]のものに比較してセキュリティのレベルを提供する目的で設計されました。このように、それは非モバイルインターネットには存在しませんが、モビリティの導入が適切な対策がない状態で導入することになりすまし、サービス拒否、および洪水の脅威から保護します。具体的には、リターン・ルータビリティ手順は、次の要件を満たします：
o An attacker off the path from a correspondent node to a victim should not be able to trick a correspondent node into redirecting packets, which should normally be delivered to a victim, to itself, or to a third IP address. The attacker could otherwise impersonate the victim to the correspondent node or cause denial of service against the victim. The attacker may launch these attacks from an arbitrary position, which would not necessarily have to be on the path between the victim and the correspondent node.
O被害者への通信相手ノードから経路外攻撃者は、通常、それ自体に、又は第3のIPアドレスに、被害者に送達しなければならないリダイレクトパケットにコレスポンデントノードをだますことができないはずです。攻撃者は、そうでない場合は、通信相手ノードに被害者になりすましたり、被害者に対するサービス拒否を引き起こす可能性があります。攻撃者は必ずしも被害者とコレスポンデントノード間のパス上にある必要はありません任意の位置から、これらの攻撃を起動することができます。
o An attacker off the path from a correspondent node to a victim should not be able to trick the correspondent node into redirecting packets, which should normally be delivered to the attacker itself, to the victim. The attacker could otherwise flood the victim with unrequested packets. Such "redirection-based flooding" may be appealing to the attacker because the burden of generating the flooding packets and sending them to the victim would be on the correspondent node rather than on the attacker. The attacker could spoof multiple correspondent nodes into flooding the same victim. This would enable the attacker to impact the victim much stronger than with a direct flooding attack, where the attacker itself would generate and send the flooding packets. Comparable amplification is today only possible through an army of compromised nodes [8]. One way to cause redirection-based flooding is this: The attacker could accomplish the initial TCP handshake for a voluminous file download through its own IP address, and subsequently bind the victim's IP address (as a care-of address) to the attacker's own IP address (or home address). The correspondent node thereby redirects the download to the victim. The attacker could spoof acknowledgments on behalf of the victim based on the sequence numbers it learned during the initial handshake in order to maintain or accelerate the download. The acknowledgments would be smaller and typically less than the full-sized segments that the correspondent node generates, hence facilitating the amplification.
O被害者への通信相手ノードから経路外攻撃者は、通常、被害者に、攻撃者自体に送達されなければならないリダイレクトパケットにコレスポンデントノードをだますことができないはずです。攻撃者は、そうでない場合は非要求パケットで被害者をあふれさせることができました。フラッディングパケットを生成し、被害者に送信する負担がコレスポンデントノード上ではなく、攻撃者になるため、このような「リダイレクションベースの氾濫は、」攻撃者にアピールすることができます。攻撃者は、同じ被害者を氾濫に複数の通信相手ノードになりすますことができます。これにより、攻撃者自身が生成し、フラッディングパケットを送信し、ダイレクトフラッディング攻撃、と比べてはるかに強い被害者に影響を与える攻撃を可能にします。同等の増幅が損なわノード[8]の軍隊を介してのみ可能である今日。リダイレクションベースの氾濫を起こすための一つの方法はこれです：攻撃者は、独自のIPアドレスを通じて大量のファイルのダウンロードのための最初のTCPハンドシェイクを達成し、続いて攻撃者自身のIPに（気付アドレスなど）被害者のIPアドレスをバインドすることができアドレス（またはホームアドレス）。コレスポンデント・ノードは、それによって被害者へのダウンロードをリダイレクトします。攻撃者は、それがダウンロードを維持または促進するために、最初のハンドシェイク中に学習シーケンス番号に基づいて被害者を代表して謝辞をだますことができます。肯定応答が小さく、したがって、増幅を容易にコレスポンデントノードが生成する、フルサイズのセグメント、より一般的に少なくなるであろう。
o Attackers should not be able to cause denial of service against mobile or correspondent nodes through exploiting expensive computations involved in the mobility protocol.
O攻撃者は、モビリティプロトコルに関与高価な計算を利用して携帯電話やコレスポンデントノードに対してサービス拒否を引き起こすことはできないはずです。
The return routability procedure precludes impersonation, denial of service, and redirection-based flooding by attackers that are not on the path from a correspondent node to a victim, and it is sufficiently lightweight not to expose expensive operations. But the return routability procedure fails to protect against attackers that are located on the path from the correspondent node to the victim. Applications that require a higher security level are generally advised to use end-to-end protection such as IP security (IPsec) or Transport Layer Security (TLS). But even then are they vulnerable to denial of service or flooding. Furthermore, end-to-end security mechanisms generally require mobile and correspondent nodes to be preconfigured with authentication credentials, or they depend on a public-key infrastructure. Both would hinder a wide deployment of Mobile IPv6 route optimization if it was a prerequisite for the protocol. An objective of Enhanced Route Optimization is hence to securely authenticate mobile nodes without preconfigured credentials or a public-key infrastructure, even in the presence of attackers on the path from the correspondent node to the victim.
リターン・ルータビリティ手順は、被害者への対応ノードからのパス上にない攻撃者によって偽装、サービス拒否、およびリダイレクションベースの氾濫を排除し、高価な操作を公開しないように十分に軽量です。しかし、リターン・ルータビリティ手順は、被害者への対応ノードからのパスに配置されて攻撃者から保護するために失敗しました。より高いセキュリティレベルを必要とするアプリケーションは、一般的なIPセキュリティ（IPsec）またはTransport Layer Security（TLS）などのエンドツーエンドの保護を使用することをお勧めします。それでも、彼らは、サービスや洪水の拒否に対して脆弱です。さらに、エンドツーエンドのセキュリティメカニズムは、一般的に認証資格情報を事前に設定することが、モバイルと通信員ノードを必要とし、またはそれらは、公開鍵インフラストラクチャに依存しています。それは、プロトコルのための前提条件だった場合の両方がモバイルIPv6経路最適化の幅広い展開を妨げます。強化されたルート最適化の目的は、安全であっても、被害者への対応ノードからパス上の攻撃者の存在下で、事前に設定資格情報または公開鍵インフラストラクチャなしでモバイルノードを認証するために、したがってあります。
A complete correspondent registration involves six message transmissions at the mobile node, totaling about 376 bytes [9]. This signaling overhead may be acceptable if movements are infrequent. For example, a mobile node that moves once every 30 minutes generates an average of 1.7 bits/s of signaling traffic. Higher mobility causes more substantial overhead, however. A cell size of 100 meters and a speed of 120 km/h yields a change in IP connectivity every 3 s and about 1,000 bits/s of signaling traffic. This is significant compared to a highly compressed voice stream with a typical data rate of 10,000 to 30,000 bits/s.
完全通信員登録は約376バイトを合計モバイルノードで6つのメッセージ送信を含む[9]。動きがまれである場合、このシグナリングオーバーヘッドは許容可能であり得ます。例えば、30分ごとに移動する移動ノードは、トラフィックシグナリングの1.7ビット/秒の平均を生成します。高い移動度は、しかし、より実質的なオーバーヘッドが発生します。 100メートルのセルサイズ及び毎時120キロの速度は、IP接続性の変化毎に3秒およびシグナリングトラフィックの約1,000ビット/秒が得られます。これは10,000〜30,000ビット/秒の典型的なデータレートと高圧縮音声ストリームに比べて重要です。
Furthermore, base Mobile IPv6 requires mobile nodes to renew a correspondent registration at least every 7 minutes. The signaling overhead amounts to 7.16 bits/s if the mobile node communicates with a stationary node [9]. It doubles if both peers are mobile. This overhead may be negligible when the nodes communicate, but it can be an issue for mobile nodes that are inactive and stay at the same location for a while. These nodes typically prefer to go to standby mode to conserve battery power. Also, the periodic refreshments consume a fraction of the wireless bandwidth that one could use more efficiently. These observations lead to the objective of Enhanced Route Optimization to reduce the signaling overhead of a base Mobile IPv6 correspondent registrations as much as possible, in particular when the mobile node does not move for a while.
また、ベースモバイルIPv6は、少なくとも毎分7対応の登録を更新するためにモバイルノードを必要とします。 7.16ビット/ sのシグナリングオーバーヘッド量モバイルノードは、固定ノード[9]と通信する場合。両方のピアが携帯している場合は倍になります。ノードが通信する場合、このオーバーヘッドは無視できるが、それは不活性であり、しばらくの間同じ場所に留まるモバイルノードのための問題であることができます。これらのノードは、一般的にバッテリーを節約するためにスタンバイモードに行くことを好みます。また、定期的な軽食は1つが、より効率的に使用できる無線帯域幅の一部を消費します。これらの観察は、モバイルノードがしばらく動かないとき、可能な限り、特にベースのモバイルIPv6の特派登録のシグナリングオーバーヘッドを減らすために強化されたルート最適化の目標につながります。
Enhanced Route Optimization consists of a set of optimizations that collectively afford the achievement of the objectives discussed in Section 2. These optimizations are summarized in the following.
強化されたルート最適化を一括してこれらの最適化は、以下に要約されている第2節で述べた目標の達成を買う余裕の最適化のセットで構成されます。
A Mobile IPv6 binding is conceptually a packet redirection from a home address to a care-of address. The home address is the source of the redirection and the care-of address is the destination. The packets to be redirected can hence be identified based on the home address. This motivates a cryptographic ownership proof for the home address. Enhanced Route Optimization applies cryptographically generated home addresses for this purpose [10][11]. In general, a Cryptographically Generated Address (CGA) provides a strong, cryptographic binding between its interface identifier and the CGA owner's public key. This facilitates a cryptographic home address ownership proof without a public-key infrastructure, enabling other nodes to securely and autonomously authenticate the CGA owner as such, modulo the correctness of the CGA's subnet prefix. Cryptographically generated home addresses can supersede home address tests with the exception of an initial test for validating the home address prefix. This facilitates lower handoff delays and longer binding lifetimes, as well as reduced signaling overhead for mobile nodes that temporarily do not move. Enhanced Route Optimization also optionally enables the correspondent node to prove ownership of its IP address.
モバイルIPv6は、結合概念的に気付アドレスへのホームアドレスからのパケットリダイレクションです。ホームアドレスは、リダイレクトの源であり、気付アドレスが宛先です。リダイレクトされるパケットは、したがって、ホームアドレスに基づいて特定することができます。これは、ホームアドレスのための暗号所有権の証明を動機付けます。強化されたルート最適化は、[10] [11]、この目的のために、暗号生成されたホームアドレスを適用します。一般的に、暗号化生成アドレス（CGA）は、そのインタフェース識別子とCGA所有者の公開鍵の間の結合の強い、暗号化を提供します。これはしっかりと自律などのCGAの所有者を認証するために、他のノードを有効にする、公開鍵インフラストラクチャなしで暗号ホームアドレス所有権の証明を容易に、CGAのサブネットプレフィックスの正しさを法。暗号で生成されたホームアドレスはホームアドレスのプレフィックスを検証するための最初のテストを除いてホームアドレステストに取って代わることができます。これは、下のハンドオフ遅延と長い結合寿命を促進するだけでなく、一時的に移動しないモバイルノードのためのシグナリングオーバーヘッド削減します。強化されたルート最適化はまた、必要に応じてそのIPアドレスの所有権を証明するために、通信相手ノードを可能にします。
In contrast to a home address, a care-of address does not have identifying functionality. There is hence little benefit in a cryptographic ownership proof of a care-of address. Given that the care-of address is the destination of a packet redirection, it is rather the mobile node's reachability at the care-of address that matters. Enhanced Route Optimization uses care-of address tests for this purpose, but allows correspondent nodes to send packets to a new care-of address before the mobile node has been found to be reachable there.
自宅の住所とは対照的に、気付アドレスは、機能性を特定する必要はありません。気付アドレスの暗号所有権の証明にはほとんど利点が故にあります。気付けアドレスは、パケットのリダイレクトの宛先であることを考えると、それは重要なこと気付アドレスにモバイルノードの到達可能性はむしろです。強化されたルート最適化は、この目的のために気付アドレステストを使用しますが、モバイルノードが到達可能であることが判明している前に、通信員ノードが新しい気付アドレスにパケットを送信することができます。
CGA-based authentication involves public-key cryptography and is hence computationally much less efficient than authentication through a shared secret key. The technique further requires a substantial amount of supplementary CGA parameters to be piggybacked onto protected messages. Enhanced Route Optimization mitigates these disadvantages in that it utilizes an initial CGA-based authentication to securely exchange a secret permanent home keygen token between a mobile node and a correspondent node. The permanent home keygen token is used to authenticate the mobile node more efficiently in subsequent correspondent registrations. Mobile and correspondent nodes renew the permanent home keygen token on an infrequent basis. The token is therefore neither constant nor short-lived, which is why the security association between the mobile node and the correspondent node is called "semi-permanent".
CGAベースの認証は、公開鍵暗号方式を含み、共有秘密鍵を通じて、したがって、計算はるかに少ない効率的な認証よりもです。技術は、さらに、保護されたメッセージにピギーバックされる補助CGAパラメータのかなりの量を必要とします。強化されたルート最適化は、それがしっかりとモバイルノードとコレスポンデントノードとの間で秘密の永久的な家のkeygenトークンを交換するための初期CGAベースの認証を利用していること、これらの欠点を軽減するで。永久的な家のkeygenトークンは、その後の通信員登録で、より効率的にモバイルノードを認証するために使用されます。モバイルと通信員ノードはまれ基づいて永久的な家のkeygenトークンを更新します。トークンは、モバイルノードとコレスポンデントノード間のセキュリティアソシエーションは、「半永久的」と呼ばれている理由である、したがって、定数も短命でもありません。
An initial home address test is necessary despite a cryptographic proof of home address ownership to protect against spoofed subnet prefixes in home addresses. In the complete absence of home address tests, a malicious node could cryptographically generate a home address with the subnet prefix of a victim network, and request a correspondent node to register a binding between this spoofed home address and the attacker's own care-of address. The attacker then tricks the correspondent node into sending a stream of packets to the care-of address and subsequently deregisters the binding or lets it expire. The consequence is that the correspondent node redirects the packet stream "back" to the home address, causing the victim network to be flooded with unrequested packets. To preclude such misuse, an initial home address test is required for the mobile node and the correspondent node to establish a semi-permanent security association. The home address test is, if possible, executed in proactive manner so as to save a potentially costly message exchange via the home agent during the critical handoff period. The home address test does not need to be repeated upon subsequent movements.
最初のホームアドレステストはホームアドレスで偽装されたサブネットプレフィックスから保護するために、ホームアドレスの所有権の暗号証明にもかかわらず、必要があります。ホームアドレステストの完全な欠如では、悪意のあるノードは、暗号被害者ネットワークのサブネットプレフィックスを持つホームアドレスを生成し、この偽装されたホームアドレスと攻撃者自身の気付アドレス間の結合を登録するには、通信相手ノードを要求することができます。気付アドレスにパケットのストリームを送信し、その後結合の登録を解除するか、それが期限切れにすることができますへのトリックその後、攻撃者は、通信相手ノード。その結果は、コレスポンデントノードは、被害者のネットワークが要求されていないパケットが殺到するように引き起こして、ホームアドレスにパケットストリーム「バック」をリダイレクトするということです。そのような誤用を排除するには、最初のホームアドレステストは、半永久的なセキュリティアソシエーションを確立するために、モバイルノードとコレスポンデントノードに必要です。可能な場合はホームアドレステストは重要なハンドオフ期間中にホームエージェントを介して潜在的に高価なメッセージ交換を保存するように積極的に実行し、です。ホームアドレステストは、その後の動きに応じ繰り返す必要はありません。
Enhanced Route Optimization allows a correspondent node to send payload packets to a mobile node's new care-of address before the mobile node has been found to be reachable at the care-of address. When the mobile node changes IP connectivity, it first updates its binding at the correspondent node to the new care-of address without providing a proof of reachability. The correspondent node registers the new care-of address on a tentative basis and sets it to UNVERIFIED state. Payload packets can then be exchanged bidirectionally via the new care-of address, while the mobile node's reachability at the new care-of address is verified concurrently. The correspondent node moves the care-of address to VERIFIED state once reachability verification completes.
強化されたルートの最適化は、モバイルノードが気付アドレスに到達可能であることが判明している前に、コレスポンデントノードは、モバイルノードの新しい気付けアドレスにペイロードパケットを送信することができます。モバイルノードは、IP接続を変更すると、それは最初には、到達可能性の証拠を提供することなく、新たな気付アドレスに対応するノードでの結合更新します。コレスポンデントノードは、暫定的に新気付けアドレスを登録してUNVERIFIED状態に設定します。新しい気付アドレスにモバイルノードの到達可能性を同時に検証している間に、ペイロードパケットは、その後、新しい気付アドレス経由で双方向にやり取りすることができます。到達可能性の検証が完了すると、通信相手ノードが検証状態に気付アドレスを移動します。
Concurrent care-of address tests without additional protection would enable an attacker to trick a correspondent node into temporarily redirecting payload packets, which would otherwise be addressed to the attacker itself, to the IP address of a victim. Such "redirection-based flooding" [5] may be appealing to the attacker because the correspondent node (not the attacker) generates the flooding packets and sends them to the victim. This enables the attacker to amplify the strength of the attack to a significant degree compared to a direct flooding attack where the attacker itself would generate the flooding packets.
同時気付アドレステスト追加の保護なしでは、一時的にそうでない場合は、被害者のIPアドレスに、攻撃者自身に宛てられるペイロードパケットを、リダイレクトに対応するノードをだますために、攻撃者を可能にします。そのような「リダイレクションベースのフラッディング」コレスポンデントノード（ない攻撃者）がフラッディングパケットを生成し、被害者に送信しているため[5]攻撃者にアピールすることができます。これにより、攻撃者自身が氾濫パケットを生成するダイレクトフラッディング攻撃と比較して有意な程度に攻撃の強さを増幅させるために、攻撃者を可能にします。
Enhanced Route Optimization protects against redirection-based flooding attacks through the use of Credit-Based Authorization. Credit-Based Authorization manages the effort that a correspondent node expends in sending payload packets to a care-of address in UNVERIFIED state so as to ensure that a redirection-based flooding attack cannot be more effective than direct flooding. The ability to send unrequested packets is an inherent property of packet-oriented networks, and direct flooding is a threat that results from this. Since direct flooding exists with and without mobility support, and redirection-based flooding attacks cannot be any more efficient than this, Credit-Based Authorization increases the security level provided by Enhanced Route Optimization with respect to flooding to that of the non-mobile Internet. Enhanced Route Optimization therefore satisfies the objective to provide a security level comparable to that of the non-mobile Internet.
強化されたルートの最適化は、クレジットベースの許可を使用してリダイレクトベースのフラッディング攻撃から保護します。クレジットベース認証は、コレスポンデントノードは、リダイレクションベースのフラッディング攻撃が直接洪水よりも効果的でないことを保証するために、気付アドレスUNVERIFIED状態でのペイロードパケットを送信することに費やす労力を管理します。非要求パケットを送信する機能は、パケット指向のネットワークの固有の財産となり、直接洪水が、この結果から脅威です。ダイレクトフラッディングがでとモビリティのサポートなしで存在し、リダイレクションベースのフラッディング攻撃は、これよりもより効率的にすることはできませんので、クレジットベース認証は、非モバイルインターネットのものと氾濫に対する強化されたルートの最適化によって提供されるセキュリティレベルを向上させます。強化されたルート最適化は、したがって、非モバイルインターネットのそれに匹敵するセキュリティレベルを提供することを目的とする満たします。
The measuring and limiting of effort are technically realized through the concept of "credit", which a correspondent node maintains to put its own effort in relation to the effort that a mobile node expends during regular communications with the correspondent node. The correspondent node increases the credit for payload packets it receives from a care-of address of the mobile node in VERIFIED state, and it reduces the credit in proportion to its own effort for sending payload packets to a care-of address of the mobile node in UNVERIFIED state.
努力の測定および制限は、技術的には、通信相手ノードは、モバイルノードは、コレスポンデントノードとの定期的な通信中に費やすことの努力に関連して、独自の努力を入れて維持し、「クレジット」の概念を通じて実現されます。コレスポンデント・ノードは、それが検証状態におけるモバイルノードの気付アドレスから受信ペイロードパケットのクレジットを増加させ、それが気付にモバイルノードのアドレスをペイロードパケットを送信するための独自の努力に比例してクレジットを減少させUNVERIFIED状態インチ
Enhanced Route Optimization enables mobile nodes to pursue a correspondent registration in parallel with the respective home registration. This reduces handoff delays compared to base Mobile IPv6, which requires mobile nodes to wait for a Binding Acknowledgment message indicating a successful home registration before they initiate a correspondent registration.
強化されたルートの最適化は、各家庭の登録と並行して通信員登録を追求するために、モバイルノードを可能にします。これは、彼らが通信員登録を開始する前に、成功したホーム登録を示すBinding Acknowledgementメッセージを待つために、モバイルノードを必要とベースのモバイルIPv6のに比べて、ハンドオフ遅延を低減します。
Enhanced Route Optimization allows a mobile node to securely authenticate to a correspondent node based on the CGA property of its home address, and to request a concurrent care-of address test for increased handoff efficiency. Depending on whether the mobile node wishes to take advantage of either or both of these enhancements, the messages exchanged during a correspondent registration are different. This is described in the following.
強化されたルート最適化は、モバイルノードがしっかりとそのホームアドレスのCGAの特性に基づいて、通信相手ノードに認証するために、そして増加したハンドオフ効率の同時気付アドレスのテストを要求することができます。モバイルノードは、これらの拡張機能のいずれかまたは両方の利点を活用することを希望するかどうかに応じて、通信員登録時に交換されるメッセージが異なります。これは、以下に記載されています。
A mobile node may initiate a correspondent registration for any of the following reasons:
モバイルノードは、次のいずれかの理由で対応登録を開始することができます。
o To establish a new binding at a correspondent node while away from its home link so that subsequent packets will be route-optimized and no longer be routed through the mobile node's home agent.
後続のパケットは、ルート最適化し、もはやモバイルノードのホームエージェントを経由してルーティングしないことになるように、oはしばらく離れてそのホームリンクから相手ノードでバインディング新を確立します。
o To update an existing binding at the correspondent node while moving from one point of IP attachment to another.
別のIPアタッチメントの一点から移動しながらoは既存のコレスポンデント・ノードにおけるバインディングを更新します。
o To follow up an early Binding Update message with a complete Binding Update message after receiving a Binding Acknowledgment message with a Care-of Test option.
oは気付テストのオプションでBinding Acknowledgementメッセージを受信した後、完全なBinding Updateメッセージと早期Binding Updateメッセージをフォローアップします。
o To refresh an existing binding at the correspondent node without changing the current point of IP attachment.
IPアタッチメントの現在位置を変更することなく、既存の通信相手ノードでバインディングを更新するには、O。
o To request the correspondent node to renew an existing permanent home keygen token shared between the mobile node and the correspondent node (see Section 4.5).
oは、モバイルノードとコレスポンデントノード（4.5節を参照）との間で共有既存の永久的な家のkeygenトークンを更新するために、通信相手ノードを要求します。
o To request the correspondent node to deregister an existing binding.
oは既存のバインディングの登録を解除するために、通信相手ノードを要求します。
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 1: Correspondent registration with authentication by a proof of the mobile node's knowledge of a permanent home keygen token; concurrent care-of address test
図1：永久的な家のkeygen象徴のモバイルノードの知識の証明による認証との特派登録。同時気付けアドレステスト
In any of these cases, the mobile node sends a Binding Update message to the correspondent node. The Binding Update message is authenticated by one of the following three authentication methods:
これらの場合のいずれにおいても、モバイルノードは、コレスポンデント・ノードへのバインディング更新メッセージを送信します。 Binding Updateメッセージは、次の3つの認証方法のいずれかによって認証されています。
o If the mobile node's home address is a CGA, but the mobile node does not have a permanent home keygen token in its Binding Update List entry for the correspondent node, the mobile node SHOULD authenticate the Binding Update message based on the CGA property of its home address. This requires the mobile node to send its CGA parameters and signature to the correspondent node and to pass a check of reachability at the home address.
OモバイルノードのホームアドレスがCGAですが、モバイルノードは、コレスポンデントノードのためにその結合更新リスト項目に永久的な家のkeygenトークンを持っていない、モバイルノードは、そののCGAの特性に基づくBinding Updateメッセージを認証する必要がある場合自宅の住所。これは、コレスポンデントノードにそのCGAパラメタと署名を送信するために、ホームアドレスに到達可能性のチェックを通過するために、モバイルノードが必要です。
o If the mobile node's home address is a CGA, and the mobile node has a permanent home keygen token in its Binding Update List entry for the correspondent node, the mobile node MUST authenticate the Binding Update message by a proof of its knowledge of the permanent home keygen token.
モバイルノードのホームアドレスがCGAで、モバイルノードがコレスポンデントノードのためにその結合更新リスト項目内の永久的な家のkeygenトークンを持っている場合は、O、モバイルノードは永久の知識の証拠でBinding Updateメッセージを認証しなければなりません。ホーム鍵生成トークン。
o If the mobile node's home address is not a CGA, the mobile node MUST authenticate the Binding Update message through a proof of reachability at its home address.
モバイルノードのホームアドレスがCGAでない場合は、O、モバイルノードは、そのホームアドレスで到達可能性の証明を通じてBinding Updateメッセージを認証しなければなりません。
The lifetime requested by the mobile node in the Lifetime field of the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME (see Section 7) if the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address or by a proof of the mobile node's knowledge of a permanent home keygen token. If the selected authentication method is a proof of the mobile node's reachability at the home address, the lifetime MUST NOT exceed MAX_RR_BINDING_LIFETIME [1]. It is RECOMMENDED in all cases that the mobile node requests the maximum permitted lifetime in order to avoid unnecessary binding refreshes and thus reduce signaling overhead. The Lifetime field of a Binding Update message that requests the deletion of an existing binding at the correspondent node MUST be set to zero.
Binding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性上またはの証拠によって基づいて認証する場合はBinding UpdateメッセージのLifetimeフィールドに、モバイルノードによって要求された寿命は（セクション7を参照）MAX_CGA_BINDING_LIFETIMEを超えてはなりません永久的な家のkeygen象徴のモバイルノードの知識。選択した認証方法は、ホームアドレスに移動ノードの到達性の証拠である場合には、寿命がMAX_RR_BINDING_LIFETIMEを超えてはならない[1]。移動ノードが不要結合リフレッシュを回避し、したがって、シグナリングオーバーヘッドを低減するために、最大許容寿命を要求することが全てのケースで推奨されています。既存の通信相手ノードでのバインディングの削除を要求するBinding Updateメッセージの寿命フィールドはゼロに設定しなければなりません。
If the selected authentication method is by way of the CGA property of the mobile node's home address, the mobile node includes its CGA parameters and signature in the Binding Update message by adding one or more CGA Parameters options (see Section 5.1) directly followed by a Signature option (see Section 5.2). This is described in Section 4.5. Once a permanent home keygen token has been obtained from the correspondent node, the mobile node MUST authenticate all subsequent Binding Update messages by a proof of its knowledge of this permanent home keygen token until either the binding lifetime expires, the permanent home keygen token is renewed, or the mobile node explicitly deregisters the binding at the correspondent node. This ensures that an attacker on the path from the correspondent node to the mobile node's home address cannot downgrade the mobile node's chosen authentication method to a proof of reachability at the home address. The mobile node MAY choose to ignore the CGA property of its home address and authenticate Binding Update messages through a proof of reachability at the home address. However, this behavior increases the vulnerability to on-path attackers and is therefore NOT RECOMMENDED.
選択された認証方法は、移動ノードのホームアドレスのCGAの性質によるものである場合、モバイルノードは、1つ以上のCGAパラメータオプションを追加することにより、Binding UpdateメッセージにそのCGAパラメータと署名を含む直接続く（セクション5.1を参照）署名オプション（5.2節を参照してください）。これは、4.5節に記載されています。永久的な家のkeygenトークンが相手ノードから取得された後結合ライフタイムの有効期限が切れた、永久的な家のkeygenトークンが更新されるかまでは、モバイルノードは、この永久的な家のkeygen象徴に関する知識の証明によって、後続のすべてのバインディング更新メッセージを認証しなければなりません。 、またはモバイルノードは、明示的に、通信相手ノードでバインディングの登録を解除します。これは、モバイルノードのホームアドレスに対応するノードからパス上の攻撃者がホームアドレスで到達可能性の証明にモバイルノードの選択された認証方式をダウングレードすることはできませんことを保証します。モバイルノードは、そのホームアドレスのCGAの特性を無視して、ホームアドレスで到達可能性の証明を通じてバインディング更新メッセージを認証する方法もあります。しかし、この動作は、上のパス攻撃に対する脆弱性を増大させ、したがって、推奨されません。
Mobile node Home agent Correspondent node
| | |
| | |
|-Home Test Init--------->|------------------------>|
| | |
|<------------------------|<--------------Home Test-|
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-early Binding Update + Care-of Test Init option-->|
| | |
| | |
|<------------Binding Ack-| |
|<----------early Binding Ack + Care-of Test option-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 2: Correspondent registration with authentication based on reachability verification at the home address; concurrent care-of address test
図2：ホームアドレスで到達可能性の検証に基づく認証と特派登録。同時気付けアドレステスト
The mobile node also includes its CGA parameters in the Binding Update message when it intends to renew an existing permanent home keygen token shared with the correspondent node. This is accomplished, as before, by adding to the message one or more CGA Parameters options and a Signature option.
それはコレスポンデントノードと共有既存の永久的な家のkeygenトークンを更新しようとするとき、モバイルノードは、バインディング更新メッセージにそのCGAパラメータを含んでいます。これは、メッセージの一つ以上のCGAパラメータオプションと署名のオプションを追加することで、以前のように、達成されます。
The authenticator for the Binding Update message is calculated based on a permanent or temporary home keygen token. Which type of home keygen token the mobile node uses in calculating the authenticator depends on the authentication method:
Binding Updateメッセージのためのオーセンティケータは、永続的または一時的な家庭鍵生成トークンに基づいて計算されます。どのタイプの家のkeygenのモバイルノードがオーセンティケータを計算する際に使用するトークンは、認証方式によって異なります。
o If the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address, the mobile node MUST use a temporary home keygen token from the correspondent node. The mobile node may already have a valid temporary home keygen token in its Binding Update List entry for the correspondent node, or it may retrieve one through the exchange of a Home Test Init message and a Home Test message.
Binding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性に基づいて認証する場合は、O、モバイルノードは、コレスポンデントノードからの一時的なホーム鍵生成トークンを使用しなければなりません。モバイルノードは、すでに相手ノードのためにその結合更新リスト項目に有効な一時的なホーム鍵生成トークンを有していてもよく、またはそれはホーム試験開始メッセージとホームテストメッセージの交換を通じて1を検索することができます。
o If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the mobile node MUST use the permanent home keygen token that is has in its Binding Update List entry for the correspondent node.
Binding Updateメッセージが永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証される場合は、O、モバイルノードは、コレスポンデントノードのためにその結合更新リスト項目に持っている永久的な家のkeygenトークンを使用しなければなりません。
o If the Binding Update message is to be authenticated through a proof of reachability at the home address, the mobile node MUST use a temporary home keygen token from the correspondent node. As before, the mobile node may already have a valid temporary home keygen token in its Binding Update List entry for the correspondent node, or it may retrieve one through the exchange of a Home Test Init message and a Home Test message.
Binding Updateメッセージがホームアドレスで到達可能性の証拠によって認証される場合は、O、モバイルノードは、コレスポンデントノードからの一時的なホーム鍵生成トークンを使用しなければなりません。前と同じように、モバイルノードは、すでに相手ノードのためにその結合更新リスト項目に有効な一時的なホーム鍵生成トークンを有していてもよく、またはそれはホーム試験開始メッセージとホームテストメッセージの交換を通じて1を検索することができます。
Unless the purpose of the Binding Update message is to delete an existing binding at the correspondent node, the authenticator is also calculated based on a care-of keygen token. The mobile node selects this as follows:
Binding Updateメッセージの目的は、既存のコレスポンデント・ノードでの結合を削除することである場合を除き、オーセンティケータは、気付生成トークンに基づいて計算されます。次のようにモバイルノードは、これを選択します。
o If the mobile node has a valid care-of keygen token for the to-be-registered care-of address in its Binding Update List entry for the correspondent node, the mobile node MUST use this in calculating the authenticator for the Binding Update message. The Binding Update message is in this case "complete".
モバイルノードがために有効な気付鍵生成トークンを持っている場合はOに被登録コレスポンデント・ノードのためにその結合更新リスト項目内の気付アドレス、モバイルノードは、バインディング更新メッセージのためのオーセンティケータを計算することでこれを使用しなければなりません。 Binding Updateメッセージは、「完了」このケースです。
o If the mobile node does not have a valid care-of keygen token in its Binding Update List entry for the correspondent node, the mobile node SHOULD define the care-of keygen token to be zero and use this in calculating the authenticator for the Binding Update message. The Binding Update message is in this case "early".
モバイルノードは、コレスポンデントノードのためにその結合更新リスト項目に有効な気付鍵生成トークンを持っていない場合は、O、モバイルノードがゼロになるように生成トークンのケア定義し、結合のためのオーセンティケータを計算することでこれを使用すべきですメッセージを更新します。 Binding Updateメッセージは、「早期」このケースです。
o If the mobile node does not have a valid care-of keygen token in its Binding Update List entry for the correspondent node, the mobile node MAY choose to retrieve a care-of keygen token through the exchange of a Care-of Test Init message and a Care-of Test message, as defined in [1], without sending an early Binding Update message. In this case, the mobile node waits for receipt of the Care-of Test message and uses the care-of keygen token contained therein in calculating the authenticator for a complete Binding Update message. This approach increases the handoff latency, however, and is therefore NOT RECOMMENDED.
モバイルノードは、コレスポンデントノードのためにその結合更新リスト項目に有効な気付鍵生成トークンを持っていない場合は、O、モバイルノードは、気付テスト開始メッセージの交換を通じて気付生成トークンを取得することを選択するかもしれませんそしてテスト気付メッセージ、事前バインディング更新メッセージを送信せずに、[1]で定義されます。この場合、移動ノードは、気付テストメッセージの受信を待ち、気付キー生成トークン完全Binding Updateメッセージのためのオーセンティケータを計算する際に、その中に含まれるを使用します。しかし、このアプローチは、ハンドオフ遅延を増大させ、したがって、推奨されません。
For reduced handoff delays, the mobile node SHOULD simultaneously initiate home and correspondent registrations for a particular care-of address. The mobile node SHOULD also pursue home and correspondent deregistrations in parallel if it wishes to discontinue Mobile IPv6 service while away from its home link. However, when the mobile node commits home and correspondent deregistrations after returning back to the home link after a period of roaming, the mobile node MUST initiate the home deregistration first, and it MUST wait for a Binding Acknowledgment message indicating a successful home deregistration before it initiates the correspondent deregistration. This behavior ensures that the home agent does not proxy the mobile node's home address while the mobile node is on the home link, hence preventing interference between the mobile node and the home agent during Duplicate Address Detection. Since a home deregistration consumes only a link-local round-trip time when the mobile node pursues it from the home link, the cost of not parallelizing it with a correspondent deregistration, in terms of increased handoff delay, is typically negligible.
減少し、ハンドオフの遅延のために、モバイルノードは、特定の気付アドレスのホームと通信員登録を同時に開始すべき。それはしばらく離れてそのホームリンクからモバイルIPv6サービスを中止することを希望する場合、モバイルノードは、並行して、家庭や特派登録解除を追求すべきです。モバイルノードがローミングの期間後にバックホームリンクに戻った後、家庭や通信員登録解除をコミットするときしかし、モバイルノードは、最初のホーム登録解除を開始しなければなりません、そして、それは、それまでに成功した家庭の登録解除を示すBinding Acknowledgementメッセージを待たなければなりません特派登録解除を開始します。この動作は、モバイルノードが故に重複アドレス検出時の移動ノードとホームエージェントとの間の干渉を防止し、ホームリンク上にある間にホームエージェントは、モバイルノードのホームアドレスプロキシないことを保証します。ホーム登録抹消は、モバイルノードがホームリンクからそれを追求するだけでリンクローカル往復時間を消費するため、特派登録解除して、それを並列化ではないのコストは、増加したハンドオフ遅延の観点から、一般的に無視することができます。
Moreover, when the Binding Update message for the correspondent registration is to be authenticated based on the CGA property of the mobile node's home address or through a proof of reachability at the home address, the mobile node SHOULD initiate the exchange of Home Test Init and Home Test messages prior to handoff in order to proactively elicit a fresh home keygen token from the correspondent node. This reduces handoff delays further. A Home Test Init message may be sent periodically whenever the home keygen token previously acquired from the correspondent node is about to expire. Tokens are valid for 3.5 minutes [1], so the interval between successive Home Test Init messages should be a little less. Alternatively, the mobile node may be able to send the Home Test Init message right in time if its link layer provides a trigger announcing imminent handoff. Proactive home address tests are technically feasible because a home address does not change across handoffs.
通信員登録Binding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性にまたはホームアドレスの到達可能性の証拠を通して基づいて認証する場合また、モバイルノードは、ホーム試験開始ホームの交換を開始すべきテストメッセージ積極的に対応するノードからの新鮮なホーム鍵生成トークンを引き出すためにハンドオフする前に。これはさらに、ハンドオフ遅延を低減します。以前にコレスポンデントノードから取得したホーム鍵生成トークンの有効期限が近づいている時はいつでもホーム試験開始メッセージが定期的に送信することができます。トークンは3.5分[1]のために有効であるので、連続したホーム試験開始メッセージの間隔は少し少なめにする必要があります。代替的に、モバイルノードは、そのリンクレイヤが差し迫っハンドオフを発表トリガーを提供する場合、適切なタイミングでホーム試験開始メッセージを送信することができるかもしれません。自宅の住所は、ハンドオフ間で変化していないため、積極的なホームアドレステストは、技術的に実現可能です。
If the mobile node initiates the home address test from the home link, it MUST address the Home Test Init message directly to the correspondent node. The Home Test message will then be received directly from the correspondent node. If the home address test is initiated from a visited link, the mobile node MUST tunnel the Home Test Init message to the home agent. The Home Test message will then be tunneled back to the mobile node by the home agent. A home address test SHOULD NOT overlap with a home registration or home deregistration since this could result in the loss of the Home Test Init or Home Test message.
モバイルノードがホームリンクからホームアドレステストを開始する場合、それは、コレスポンデントノードに直接ホーム試験開始メッセージに対処しなければなりません。ホームテストメッセージは、コレスポンデントノードから直接受信されます。ホームアドレステストは、ホームエージェントに訪問したリンク、モバイルノードMUSTトンネルホーム試験開始メッセージから開始された場合。ホームテストメッセージは、ホームエージェントによって、モバイルノードに戻ってトンネルされます。これはホーム試験開始またはHomeテストメッセージの損失をもたらす可能性があるので、ホームアドレステストはホーム登録や自宅の登録解除と重複しないようにしてください。
If the Binding Update message is early, the mobile node MUST add a Care-of Test Init option (see Section 5.4) to the message, requesting the correspondent node to return a new care-of keygen token. The Care-of Test Init option MUST follow the CGA Parameters and Signature options, if those exist in the Binding Update message. Once a responding Binding Acknowledgment message with a Care-of Test option (see Section 5.5) is received, the mobile node MUST use the care-of
Binding Updateメッセージが早い場合には、モバイルノードは、気付テスト開始オプションを追加する必要があります新しい気付け生成トークンを返すために、通信相手ノードを要求し、メッセージに（5.4節を参照してください）。これらは、Binding Updateメッセージに存在する場合気付テスト開始オプションは、CGAパラメータと署名オプションに従わなければなりません。気付テストオプション（セクション5.5を参照）で応答Binding Acknowledgementメッセージを受信すると、モバイルノードは、気付を使用しなければなりません
keygen token contained therein in calculating the authenticator for a complete Binding Update message and send this message to the correspondent node.
キー生成トークンは、完全なBinding Updateメッセージのためのオーセンティケータを計算する際に、その中に含まれるとコレスポンデントノードにこのメッセージを送信します。
If the Binding Update message is authenticated based on the CGA property of the mobile node's home address, the mobile node MAY add a CGA Parameters Request option (see Section 5.6) to the Binding Update message so as to request the correspondent node to prove ownership of its IP address within the Binding Acknowledgment message. This ownership proof enables the mobile node to verify that the permanent home keygen token returned in the Binding Acknowledgment message was generated by the right correspondent node.
Binding UpdateメッセージをモバイルノードのホームアドレスのCGAの特性に基づいて認証された場合の所有権を証明するために、通信相手ノードを要求するように、モバイルノードは、バインディング更新メッセージに（5.6節を参照）CGAパラメータ要求オプションを加えるかもしれBinding Acknowledgementメッセージ内のIPアドレス。この所有権の証明はBinding Acknowledgementメッセージで返さ永久的な家のkeygenトークンは右コレスポンデントノードによって生成されたことを確認するために、移動ノードを可能にします。
The mobile node includes the nonce indices associated with the selected home and care-of keygen tokens in the Binding Update message using a Nonce Indices option [1]. The home nonce index is thereby determined as follows:
モバイルノードは、ホーム選択及び気付keygenのトークンBinding Updateメッセージでノンス指数オプションを使用して、[1]に関連付けられたノンス・インデックスを含みます。次のようにホームナンス指数は、それによって決定されます。
o If the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address, the mobile node uses a temporary home keygen token to calculate the authenticator for the Binding Update message, and the associated home nonce index MUST be taken from the Home Test message with which the home keygen token was obtained.
Binding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性に基づいて認証する場合は、O、モバイルノードは、バインディング更新メッセージのためのオーセンティケータを計算するために、一時的なホーム鍵生成トークンを使用し、関連するホームナンス指数が取られなければなりませんホーム鍵生成トークンを取得したとのホームテストメッセージから。
o If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the home nonce index MUST be set to zero.
Binding Updateメッセージが永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証される場合は、O、ホームナンス指数はゼロに設定しなければなりません。
o If the Binding Update message is to be authenticated through a proof of the mobile node's reachability at the home address, the mobile node uses a temporary home keygen token to calculate the authenticator for the Binding Update message, and the associated home nonce index MUST be taken from the Home Test message with which the home keygen token was obtained.
Binding Updateメッセージがホームアドレスに移動ノードの到達性の証拠によって認証される場合は、O、モバイルノードは、バインディング更新メッセージの認証子を計算するために、一時的なホーム鍵生成トークンを使用し、関連するホームナンス指数でなければなりませんホーム鍵生成トークンを取得したとのホームテストメッセージから取られました。
The care-of nonce index is determined according to the following rules:
気付けナンス指数は、次の規則に従って決定されます。
o If the Binding Update message is complete, the care-of nonce index is taken from the Care-of Test option or Care-of Test message with which the care-of keygen token (used to calculate the authenticator for the Binding Update message) was obtained.
Binding Updateメッセージが完了した場合、O、気付けナンス指数は、気付テストオプションまたは気付気付キー生成トークンは、（Binding Updateメッセージのためのオーセンティケータを計算するために使用される）を有するテストメッセージから取得されが得られた。
o If the Binding Update message is early, the care-of nonce index MUST be set to zero.
Binding Updateメッセージが早い場合は、O、気付けナンス指数はゼロに設定しなければなりません。
o If the purpose of the Binding Update message is to delete a binding at the correspondent node, the care-of nonce index MUST be set to zero.
Binding Updateメッセージの目的は、通信相手ノードでバインディングを削除する場合は、O、気付けナンス指数はゼロに設定しなければなりません。
The Nonce Indices option follows the CGA Parameters, Signature, Care-of Test Init, and CGA Parameters Request options if those are included in the Binding Update message as well.
それらは同様にBinding Updateメッセージに含まれている場合ナンス指数オプションはCGAパラメータ、署名、気付テスト開始、及びCGAパラメータ要求オプションに従います。
The mobile node finally calculates an authenticator for the Binding Update message based on the selected home and care-of keygen tokens, following the rules described in Section 5.2 and Section 6.2.7 of [1]. For a Binding Update message that requests the deletion of an existing binding at the correspondent node, the authenticator is calculated based on only a home keygen token, and it does not incorporate a care-of keygen token. The authenticator is placed into the Authenticator field of a Binding Authorization Data option [1], which the mobile node adds to the Binding Update message as the last option.
モバイルノードが最終的に基づいて、Binding Updateメッセージのためのオーセンティケータを計算家庭選択及び気付keygenのトークン、セクション5.2およびセクション6.2.7に記載のルールを以下の[1]。既存のコレスポンデント・ノードでの結合の削除を要求するBinding Updateメッセージの場合は、オーセンティケータは、唯一のホーム鍵生成トークンに基づいて計算され、それが気付keygenのトークンを組み込んでいません。オーセンティケータは、モバイルノードは、最後のオプションとして、Binding Updateメッセージに追加する結合認証データオプション[1]の認証フィールドに置かれます。
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-Care-of Test Init-------------------------------->|
| | |
| | |
|<------------Binding Ack-| |
|<-------------------------------------Care-of Test-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
Figure 3: Correspondent registration with authentication by a proof of the mobile node's knowledge of a permanent home keygen token; explicit care-of address test
図3：永久的な家のkeygen象徴のモバイルノードの知識の証明による認証との特派登録。明示的な気付アドレステスト
The time-sequence diagrams in Figure 1 through Figure 3 illustrate the operation of Enhanced Route Optimization based on a few selected message exchanges. Figure 1 shows the messages exchanged for a correspondent registration where an early Binding Update message is authenticated by a proof of the mobile node's knowledge of a permanent home keygen token. A Care-of Test Init option in the early
図1の時系列図図3を介していくつかの選択されたメッセージ交換に基づいて、拡張ルート最適化の動作を示します。図1は、初期のBinding Updateメッセージが永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証された通信員登録のために交換されるメッセージを示しています。気付テスト開始オプションの早期で
Binding Update message requests the correspondent node to add to the Binding Acknowledgment message a fresh care-of keygen token in a Care-of Test option. The mobile node finally concludes the correspondent registration with a complete Binding Update message. Figure 2 shows the procedure of a correspondent registration where the Binding Update message is authenticated with a proof of reachability at the home address. The home address test is proactively performed prior to handoff, permitting the mobile node to issue a Binding Update message directly after the handoff. The Binding Update message is again early, and a care-of keygen token is delivered to the mobile node along with the Binding Acknowledgment message. Figure 3 depicts a correspondent registration where the mobile node initially obtains a fresh care-of keygen token through the dedicated exchange of Care-of Test Init and Care-of Test messages. It subsequently issues a complete Binding Update message that is authenticated with the CGA property of the home address.
Binding UpdateメッセージはBinding Acknowledgementメッセージ新鮮気付け生成トークン気付テストのオプションでに追加するコレスポンデントノードを要求します。モバイルノードは、最終的には完全なBinding Updateメッセージを通信員登録を終了します。図2は、Binding Updateメッセージがホームアドレスの到達可能性の証明と認証された相手の登録の手順を示しています。ホームアドレステストは積極的に直接ハンドオフ後にBinding Updateメッセージを発行するために、モバイルノードを許可、ハンドオフに先立って行われます。 Binding Updateメッセージは、初期再びあり、気付キー生成トークンは、Binding Acknowledgementメッセージと共にモバイルノードに配信されます。図3は、モバイルノードが最初に気付試験開始と気付試験メッセージの専用の交換を通じて新鮮気付キー生成トークンを取得通信員登録を示します。これは、その後、ホームアドレスのCGAプロパティで認証され、完全なBinding Updateメッセージを発行します。
When the correspondent node receives a Binding Update message, it must first verify whether the sending mobile node is the legitimate owner of the home address specified in the message. The correspondent node selects the authentication method based on the home nonce index given in the Nonce Indices option of the Binding Update message, and on the existence of CGA Parameters and Signature options in the Binding Update message:
コレスポンデント・ノードは、バインディング更新メッセージを受信すると、まず、送信モバイルノードがメッセージで指定されたホームアドレスの正当な所有者であるかどうかを確認する必要があります。コレスポンデント・ノードは、Binding UpdateメッセージのNonceのインデックスオプションで指定したホームナンス指数に基づく認証方式を選択し、CGAパラメータとBinding Updateメッセージでの署名オプションの存在に：
o If the home nonce index is set to a non-null value and the Binding Update message includes one or more CGA Parameters options followed by a Signature option, the correspondent node MUST authenticate the Binding Update message based on the CGA property of the mobile node's home address.
ホームナンス指数がnull以外の値に設定し、Binding Updateメッセージが署名オプションに続いて一つ以上のCGAパラメータオプションが含まれている場合は、O、コレスポンデントノードは、モバイルノードののCGAの特性に基づくBinding Updateメッセージを認証しなければなりません。自宅の住所。
o If the home nonce index is zero and the Binding Update message does not include one or more CGA Parameters options followed by a Signature option, the correspondent node MUST authenticate the Binding Update message by a proof of the mobile node's knowledge of a permanent home keygen token.
ホームナンス指数がゼロでBinding Updateメッセージが署名オプションに続いて一つ以上のCGAパラメータオプションが含まれていない場合は、O、コレスポンデント・ノードは、永久的なホーム鍵のモバイルノードの知識の証拠でBinding Updateメッセージを認証しなければなりません。トークン。
o If the home nonce index is set to a non-null value and the Binding Update message does not include one or more CGA Parameters options followed by a Signature option, the correspondent node MUST authenticate the Binding Update message through a proof of the mobile node's reachability at the home address.
ホームナンス指数がnull以外の値に設定され、Binding Updateメッセージが署名オプションに続いて一つ以上のCGAパラメータオプションが含まれていない場合は、O、コレスポンデントノードは、モバイルノードの証明を通じてBinding Updateメッセージを認証しなければなりません。ホームアドレスで到達可能。
In addition to the validation procedure for Binding Update messages specified in [1], the correspondent node must take the following additional steps to reject Binding Update messages that are inappropriately authenticated:
[1]で指定された更新メッセージをバインディングするための検証手順に加えて、通信相手ノードが不適切に認証されたバインディング更新メッセージを拒否するために、次の追加のステップを取る必要があります。
o If the Binding Update message includes one or more CGA Parameters options followed by a Signature option and the home nonce index is zero, the correspondent node MUST send a Binding Acknowledgment message with status code 150 ("Non-null home nonce index expected"). This ensures that a Binding Update message that is authenticated based on the CGA property of the mobile node's home address must also provide a proof of the mobile node's reachability at the home address.
Binding Updateメッセージは、署名オプションとホーム・ナンス指数続いて一つ以上のCGAパラメータオプションが含まれている場合、Oはゼロであり、ステータスコード150（「期待非ヌルホームナンス指数」）とBinding Acknowledgementメッセージを送信しなければならない相手ノード。これは、モバイルノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージは、ホームアドレスに移動ノードの到達可能性の証明を提供しなければならないことを保証します。
o If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the correspondent node MUST verify that it has a Binding Cache entry for the mobile node that includes a permanent home keygen token. In case the correspondent node does not have a Binding Cache entry for the mobile node, or if the existing Binding Cache entry for the mobile node does not include a permanent home keygen token, the correspondent node MUST reject the Binding Update message by sending a Binding Acknowledgment message with status code 147 ("Permanent home keygen token unavailable").
Binding Updateメッセージが永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証される場合は、O、コレスポンデント・ノードは、それが永久的な家のkeygenトークンを含む移動ノードの結合キャッシュ項目を持っていることを確かめなければなりません。場合には、通信相手ノードは、モバイルノードのためのBinding Cacheエントリーを持っていない、またはモバイルノードのための既存の結合キャッシュ項目が永久的な家のkeygenトークンが含まれていない場合は、コレスポンデント・ノードは、バインディングを送信することにより、Binding Updateメッセージを拒絶しなければなりませんステータスコード147（「パーマネントホーム鍵生成トークンが利用できない」）と確認応答メッセージ。
o If the Binding Update message is to be authenticated through a proof of the mobile node's reachability at the home address, the correspondent node MUST verify that it does not have a permanent home keygen token in its Binding Cache entry for the mobile node. If the correspondent node has a permanent home keygen token in its Binding Cache entry for the mobile node, it MUST reject the Binding Update message by sending a Binding Acknowledgment message with status code 149 ("Permanent home keygen token exists"). This ensures that an attacker cannot downgrade the authentication method to hijack the binding of a legitimate mobile node.
Binding Updateメッセージがホームアドレスに移動ノードの到達性の証拠によって認証される場合は、O、コレスポンデントノードは、モバイルノードのためのBinding Cacheエントリーにおける永久的な家のkeygenトークンを持っていないことを確かめなければなりません。コレスポンデントノードは、モバイルノードのためのBinding Cacheエントリーにおける永久的な家のkeygenトークンを持っている場合、それはステータスコード149（「永久的な家のkeygenトークンが存在する」）とBinding Acknowledgementメッセージを送信することにより、Binding Updateメッセージを拒絶しなければなりません。これにより、攻撃者は正当なモバイルノードのバインディングをハイジャックするための認証方法をダウングレードすることができないことを保証します。
The authenticator for the Binding Update message is calculated based on a permanent or temporary home keygen token. Which type of home keygen token the correspondent node uses in validating the authenticator, and how it retrieves or recomputes the home keygen token, depends on the authentication method:
Binding Updateメッセージのためのオーセンティケータは、永続的または一時的な家庭鍵生成トークンに基づいて計算されます。家のどのタイプの生成トークンコレスポンデントノードは、認証を有効に使用し、それが取得や自宅の鍵生成トークンを再計算し、認証方法に応じて異なります：
o If the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address, the correspondent node MUST recompute the temporary home keygen token defined by the (non-null) home nonce index in the Nonce Indices option of the Binding Update message, and it MUST use this recomputed token in validating the authenticator of the message.
Binding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性に基づいて認証する場合は、O、コレスポンデントノードは、のナンスインデックスオプションで（null以外の）ホームナンス指数によって定義された一時的なホーム鍵生成トークンを再計算しなければなりませんBinding Updateメッセージ、そしてそれは、メッセージのオーセンティケータを有効にこの再計算トークンを使用しなければなりません。
o If the Binding Update message is to be authenticated by a proof of the mobile node's knowledge of a permanent home keygen token, the correspondent node MUST use the permanent home keygen token that it has in its Binding Cache entry for the mobile node in validating the authenticator of the Binding Update message.
Binding Updateメッセージが永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証される場合、それは持っているO、コレスポンデントノードは、検証にモバイルノードのためのBinding Cacheエントリーに永久的な家のkeygenトークンを使用しなければなりませんBinding Updateメッセージのオーセンティケータ。
o If the Binding Update message is to be authenticated through verification of the mobile node's reachability at the home address, the correspondent node MUST recompute the temporary home keygen token defined by the (non-null) home nonce index in the Nonce Indices option of the Binding Update message, and it MUST use this recomputed token in validating the authenticator of the message.
Binding Updateメッセージがホームアドレスに移動ノードの到達性の検証によって認証される場合は、O、コレスポンデントノードは、のナンスインデックスオプションで（null以外の）ホームナンス指数によって定義された一時的なホーム鍵生成トークンを再計算しなければなりませんBinding Updateメッセージ、そしてそれは、メッセージのオーセンティケータを有効にこの再計算トークンを使用しなければなりません。
Unless the purpose of the Binding Update message is to delete an existing binding at the correspondent node, the authenticator is also calculated based on a care-of keygen token. Which care-of keygen token the correspondent node uses in validating the authenticator depends on whether the Binding Update message is complete or early:
Binding Updateメッセージの目的は、既存のコレスポンデント・ノードでの結合を削除することである場合を除き、オーセンティケータは、気付生成トークンに基づいて計算されます。どの気付生成トークンコレスポンデント・ノードは、Binding Updateメッセージが完全または早期であるかどうかに依存して、認証を有効に使用しています。
o If the care-of nonce index in the Nonce Indices option of the Binding Update message is set to a non-null value, the Binding Update message is complete. In this case, the correspondent node MUST recompute the care-of keygen token that is identified by the care-of nonce index, and it MUST use this recomputed token in validating the authenticator of the message.
気付けナンス指数Binding UpdateメッセージのNonceのインデックスオプションでは、null以外の値に設定されている場合は、O、Binding Updateメッセージは完了です。この場合には、通信相手ノードは、気付けナンス指数気付によって識別されるキー生成トークンを再計算しなければならない、そして、それは、メッセージの認証子を検証し、この再計算されたトークンを使用しなければなりません。
o If the care-of nonce index in the Nonce Indices option of the Binding Update message is zero, the Binding Update message is early. The care-of keygen token to be used by the correspondent node in validating the authenticator of the Binding Update message is zero in this case.
気付けナンス指数Binding UpdateメッセージのNonceのインデックスオプションでは、ゼロの場合、O、Binding Updateメッセージは早いです。気付キー生成トークンBinding Updateメッセージの認証子を検証で通信相手ノードによって使用されるが、この場合にはゼロです。
The correspondent node finally validates the authenticator in the Binding Update message based on the selected home and care-of keygen tokens, following the algorithm described in Section 9.5.1 of [1].
コレスポンデント・ノードは、最終的に家を選択し、気付keygenのトークン、[1]のセクション9.5.1に記載したアルゴリズム以下に基づいてバインディング更新メッセージに認証子を検証します。
If the validation fails, the correspondent node MUST discard the Binding Update message. The correspondent node may have to send a Binding Acknowledgment message with a status code indicating the failure, as described in [1].
検証が失敗した場合、コレスポンデント・ノードは、バインディング更新メッセージを捨てなければなりません。コレスポンデントノード[1]に記載のように、失敗したことを示すステータスコードでBinding Acknowledgementメッセージを送信することを有してもよいです。
Provided that the validation of the authenticator in the Binding Update message succeeds, the correspondent node registers the mobile node's new care-of address, either updating an existing Binding Cache entry, if one exists, or creating a new Binding Cache entry. The lifetime granted for the binding depends on the lifetime requested by the mobile node in the Lifetime field of the Binding Update message and the method by which the Binding Update message is authenticated. If the Binding Update message is authenticated based on the CGA property of the mobile node's home address or by a proof of the mobile node's knowledge of a permanent home keygen token, the lifetime for the binding SHOULD be set to the maximum of MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime field of the Binding Update message. If the Binding Update message is authenticated through a proof of the mobile node's reachability at the home address, then the lifetime for the binding SHOULD be set to the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in the Lifetime field of the Binding Update message. The correspondent node may in either case grant a further reduced lifetime, but it MUST NOT accept a higher lifetime.
Binding Updateメッセージでオーセンティケータの検証が成功したと仮定すると、コレスポンデントノードは、モバイルノードの新しい気付アドレスを登録し、いずれかの既存のBinding Cacheエントリーを更新し、1が存在する場合、または新しいバインディングキャッシュエントリを作成します。結合のために付与された寿命はBinding UpdateメッセージとBinding Updateメッセージが認証される方法の寿命フィールドに移動ノードによって要求された寿命に依存します。 Binding UpdateメッセージをモバイルノードのホームアドレスのCGAの特性上または永久的な家のkeygen象徴のモバイルノードの知識の証拠によって基づいて認証されている場合は、結合のための寿命はMAX_CGA_BINDING_LIFETIMEの最大値と値に設定する必要がありますBinding UpdateメッセージのLifetimeフィールドで指定されました。 Binding Updateメッセージは、ホームアドレスにモバイルノードの到達可能性の証拠を介して認証された場合、その後の結合のため寿命はMAX_RR_BINDING_LIFETIMEの最大値[1]とBinding Updateメッセージの寿命フィールドで指定された値に設定されてください。コレスポンデントノードは、いずれの場合にはさらに減少した寿命を与えることができるが、それは高い寿命を受け入れてはいけません。
The state of the new care-of address depends on whether the Binding Update message is complete or early:
新気付けアドレスの状態がBinding Updateメッセージが完全または早期であるかどうかによって異なります。
o If the Binding Update message is complete, the new care-of address is set to VERIFIED state. The correspondent node may then immediately send packets to the new care-of address without restrictions.
Binding Updateメッセージが完了している場合は、O、新気付けアドレスは状態が確認するように設定されています。コレスポンデントノードは、その後すぐに制限されることなく、新たな気付アドレスにパケットを送信することができます。
o If the Binding Update message is early, the new care-of address is set to UNVERIFIED state. The correspondent node MUST then follow the rules defined in Section 4.10 for sending packets to this care-of address until the care-of address is set in VERIFIED state.
Binding Updateメッセージが早い場合は、O、新気付けアドレスがUNVERIFIED状態に設定されています。コレスポンデント・ノードは、次に、気付アドレスが確認状態に設定されるまで、この気付アドレスにパケットを送信するために、セクション4.10で定義された規則に従わなければなりません。
If the Binding Update message contains one or multiple CGA Parameters options, the mobile node is requesting the correspondent node to accept the included CGA parameters either for establishing a new, or for renewing an existing permanent home keygen token shared between the mobile node and the correspondent node. The correspondent node MUST in this case check if the CGA Parameters options are directly followed by a Signature option and, if so, validate the CGA parameters and signature as described in Section 4.6.
Binding Updateメッセージは、1つまたは複数のCGAパラメータオプションが含まれている場合、モバイルノードは、新たに確立するための、またはモバイルノードと通信員との間で共有既存の永久的な家のkeygenトークンを更新するためのいずれかに含まCGAパラメータを受け入れるように対応するノードを要求していますノード。セクション4.6で説明したようにので、CGAパラメータと署名を検証する場合、通信相手ノードは、この場合チェックでCGAパラメータオプションは、直接、署名オプションが続くとされなければならない場合。
If the CGA Parameters option is not directly followed by a Signature option, or the validation of the included CGA parameters and signature fails, the correspondent node MUST discard the Binding Update message and send a Binding Acknowledgment message with status code 148 ("CGA and signature verification failed") to the mobile node.
CGAパラメータオプションを直接署名オプション、または含まCGAパラメータの検証が続き、署名が失敗していない場合は、コレスポンデント・ノードはBinding Updateメッセージを破棄し、ステータスコード148（「CGAと署名付きBinding Acknowledgementメッセージを送らなければなりません検証は、モバイルノードに）」に失敗しました。
Provided that the signature included in the Signature option is correct, the correspondent node generates a permanent home keygen token to be shared with the mobile node and stores it in its Binding Cache entry for the mobile node. The permanent home keygen token is sent to the mobile node within a Binding Acknowledgment message as described in Section 4.3.
署名オプションに含まれる署名が正しいことを、コレスポンデントノードは、モバイルノードとモバイルノードのためのその結合キャッシュエントリに格納すると共有するパーマネントホーム鍵生成トークンを生成することを条件とします。セクション4.3で説明したように、永久ホーム鍵生成トークンは、Binding Acknowledgementメッセージ内の移動ノードへ送信されます。
Upon receipt of a valid Binding Update message, the correspondent node returns to the mobile node a Binding Acknowledgment message in any of the following cases:
有効なバインディング更新メッセージを受信すると、モバイルノード以下のいずれかの場合にBinding Acknowledgementメッセージにコレスポンデントノードの戻り値：
o The Acknowledge flag in the Binding Update message is set.
O Binding Updateメッセージで確認応答フラグが設定されています。
o The Binding Update message contains one or multiple CGA Parameters options directly followed by a Signature option, and the signature included in the latter was determined to be correct.
O Binding Updateメッセージは、直接署名オプションに続く一つまたは複数のCGAパラメータオプションが含まれ、後者に含まれる署名が正しいことを決定しました。
o The Binding Update message is early and includes a Care-of Test Init option.
O Binding Updateメッセージは早いですし、試験開始ケア-のオプションが含まれています。
If the Binding Update message further contains a CGA Parameters Request option and the correspondent node's IP address is a CGA, the correspondent node MUST include its CGA parameters and signature in the Binding Acknowledgment message by adding one or more CGA Parameters options directly followed by a Signature option. The correspondent node's CGA parameters and signature enable the mobile node to verify that the permanent home keygen token received in the Binding Acknowledgment message was generated by the right correspondent node. If the Binding Update message contains a CGA Parameters Request option, but the correspondent node's IP address is not a CGA, the correspondent node ignores the CGA Parameters Request option and processes the Binding Update message further as described below.
Binding UpdateメッセージはさらにCGAパラメータ要求オプションが含まれており、対応するノードのIPアドレスが直接署名に続く一つ以上のCGAパラメータオプションを追加することにより、CGA、コレスポンデントノードは、Binding AcknowledgementメッセージにおけるそのCGAパラメタと署名を含まなければならないのであればオプション。通信相手ノードのCGAパラメータと署名Binding Acknowledgementメッセージで受信された永久ホーム鍵生成トークンが右コレスポンデント・ノードによって生成されたことを確認するためにモバイルノードを有効にします。 Binding UpdateメッセージがCGAパラメータ要求のオプションが含まれていますが、コレスポンデントノードのIPアドレスがCGAでない場合は、コレスポンデントノードは、CGAパラメータ要求オプションを無視し、以下に説明するように、さらにBinding Updateメッセージを処理します。
If the Binding Update message contains one or multiple CGA Parameters options directly followed by a Signature option, and the signature included in the latter was determined to be correct, the correspondent node MUST add a Permanent Home Keygen Token option (see Section 5.3) with a new permanent home keygen token to the Binding Acknowledgment message. The correspondent node also stores this permanent home keygen token in its Binding Cache entry for the mobile node.
Binding Updateメッセージに含まれる場合は、1つまたは複数のCGAパラメータオプションが直接署名オプション続いて、署名は、後者に含まれる正解であると決定された、通信相手ノードは、永続的なホームキー生成トークンのオプションを追加しなければならない（セクション5.3を参照） Binding Acknowledgementメッセージに新しい永久的な家のkeygen象徴。コレスポンデントノードは、モバイルノードのためのBinding Cacheエントリーでこの永久的な家のkeygenトークンを格納します。
If the Binding Update message includes a Care-of Test Init option, the correspondent node MUST append to the Binding Acknowledgment message a Care-of Test option with a pseudo-random value in the Care-of Keygen Token field. The Care-of Test option MUST appear after the Permanent Home Keygen Token option in case both options are present in the Binding Acknowledgment message.
Binding Updateメッセージは、気付テスト開始オプションが含まれている場合、通信相手ノードはBinding Acknowledgementメッセージ気付テストオプション気付キー生成トークン分野における擬似ランダム値とに追加しなければなりません。気付テストのオプションは、両方のオプションがBinding Acknowledgementメッセージに存在している場合には永久的な家のkeygenトークンオプションの後に現れなければなりません。
A Binding Authorization Data option must be added to the Binding Acknowledgment message as a last option, as described in Section 5.2 and Section 6.2.7 of [1].
セクション5.2で説明したように結合認証データオプションは、最後のオプションとして、Binding Acknowledgementメッセージに追加する必要があり、セクション6.2.7 [1]の。
A mobile node first verifies a received Binding Acknowledgment message according to the rules specified in [1]. Provided that the Binding Acknowledgment message is not rejected based on these rules, the mobile node takes the following additional steps.
モバイルノードは、最初の[1]で指定された規則に従って、受信Binding Acknowledgementメッセージを検証します。 Binding Acknowledgementメッセージは、これらのルールに基づいて拒絶されないことを条件とする、モバイルノードは、以下の追加の工程を要します。
If the mobile node included a CGA Parameters Request option in the Binding Update message and the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node first processes any CGA Parameters and Signature options in the Binding Acknowledgment message in the following manner. If the Binding Acknowledgment message contains one or more CGA Parameters options that are directly followed by a Signature option, the mobile node MUST check the ownership of the correspondent node's IP address by verifying the included CGA parameters and signature as described in Section 4.6. If the validation of the CGA parameters and signature fails, the mobile node MUST silently discard the Binding Acknowledgment message. The mobile node MUST also silently discard the Binding Acknowledgment message if the message includes one or more CGA Parameters options that are not directly followed by a Signature option, or if the Binding Acknowledgment message lacks any CGA Parameters options in the presence of a Signature option.
モバイルノードは、バインディング更新メッセージとBinding AcknowledgementメッセージにおけるCGAパラメータ要求のオプションが含まれている場合は永久的な家のkeygenトークンオプションが含まれている、モバイルノードは、最初に次のようにBinding Acknowledgementメッセージで任意のCGAパラメータおよび署名オプションを処理します。 Binding Acknowledgementメッセージを直接署名オプションが続くされる1つ以上のCGAパラメータオプションが含まれている場合、モバイルノードは、セクション4.6に記載されるように含まCGAパラメータと署名を検証することにより通信相手ノードのIPアドレスの所有権を確認しなければなりません。 CGAパラメータと署名の検証が失敗した場合、モバイルノードは静かBinding Acknowledgementメッセージを破棄しなければなりません。メッセージはBinding Acknowledgementメッセージは、署名オプションの存在下で任意のCGAパラメータオプションを欠いている場合、直接署名オプション続いて、またはされていない1つの以上のCGAパラメータオプションが含まれている場合、モバイルノードは、サイレントBinding Acknowledgementメッセージを破棄しなければなりません。
If the mobile node did not include a CGA Parameters Request option in the Binding Update message or the Binding Acknowledgment message does not contain a Permanent Home Keygen Token option, the mobile node ignores any CGA Parameters and Signature options that the Binding Acknowledgment message may contain. Careful use of the CGA Parameters Request option in Binding Update messages enables the mobile node to control the processing resources it spends on the verification of a correspondent node's CGA as well as to disable such verification in the case of persistent verification failures, which may be due to misconfigured or outdated CGA software [12] on the correspondent node side or at the mobile node itself. Specifically, if the mobile node repeatedly fails to receive a Binding Acknowledgment message including valid CGA Parameters and Signature options in response to sending a Binding Update message with a CGA Parameters Request option, the mobile node SHOULD refrain from including a CGA Parameters Request option in future Binding Update messages for the same correspondent node.
モバイルノードがBinding UpdateメッセージにおけるCGAパラメータ要求オプションまたは永久的な家のkeygenトークンオプションが含まれていないBinding Acknowledgementメッセージが含まれていなかった場合は、モバイルノードは、Binding Acknowledgementメッセージが含まれていてもよい任意のCGAパラメータと署名のオプションを無視します。 Binding UpdateメッセージにおけるCGAパラメータ要求オプションを慎重に使用することは、それが通信員ノードのCGAの検証に費やす処理リソースを制御するだけでなく、永続的な検証が失敗した場合には、このような検証を無効にするには、モバイルノード、原因である可能性があり可能通信相手ノード側又はモバイルノード自体に誤って設定または古いCGAソフトウェア[12]。モバイルノードが繰り返しCGAパラメータ要求オプション付きBinding Updateメッセージを送信することに応答して、有効なCGAパラメータおよび署名オプションを含むBinding Acknowledgementメッセージの受信に失敗した場合具体的には、移動ノードは、将来的にCGAパラメータ要求オプションを含めたお控えください同じ相手ノードの更新メッセージをバインディング。
If the mobile node included a CGA Parameters Request option in the Binding Update message, but the Binding Acknowledgment message does not contain any CGA Parameters or Signature options, the mobile node cannot be sure if the correspondent node's IP address is simply not a CGA, or if the Binding Acknowledgment message originates from an attacker on the path from the mobile node to the correspondent node. To avoid accepting a permanent home keygen token from an on-path attacker, the mobile node MUST give precedence to Binding Acknowledgment messages that include valid CGA Parameters and Signature options over Binding Acknowledgment messages without such options. One possible algorithm for the mobile node to follow in this regard is to always accept the Binding Acknowledgment message received first, and if this message does not contain valid CGA Parameters or Signature options and another Binding Acknowledgment message including such options is received later on, to revert any state changes involved in accepting the first Binding Acknowledgment in favor of this subsequent Binding Acknowledgment message. Giving precedence to Binding Acknowledgment messages with valid CGA Parameters and Signature options over Binding Acknowledgment messages without such options enables the mobile node to communicate with correspondent nodes that do not use a CGA, and at the same time protects against most on-path attackers. The strategy does not protect against an attacker that can intercept Binding Acknowledgment messages from the correspondent node, but such an attacker could preclude mobility management between the mobile node and the correspondent node anyway. When the mobile node has permanently accepted a Binding Acknowledgment message without valid CGA Parameters and Signature options, the mobile node SHOULD refrain from including a CGA Parameters Request option in future Binding Update messages for the same correspondent node.
モバイルノードは、バインディング更新メッセージにCGAパラメータ要求のオプションが含まれますが、Binding Acknowledgementメッセージは、任意のCGAパラメータまたは署名オプションが含まれていない、モバイルノードは、コレスポンデントノードのIPアドレスは、単にCGAでない場合は確認することができない場合、またはBinding Acknowledgementメッセージは、コレスポンデント・ノードにモバイルノードからの経路上の攻撃者からの発信場合。パス上の攻撃者からの永久的な家のkeygenトークンを受け入れないようにするには、モバイルノードは、そのようなオプションを指定せずに受信確認メッセージをバインディング上で有効なCGAパラメータと署名オプションを含む受信確認メッセージをバインディングに優先権を与える必要があります。この点で追従するモバイルノードのための一つの可能なアルゴリズムは、常にBinding Acknowledgementメッセージが最初に受信受け入れることであり、このメッセージが有効CGAパラメータまたは署名オプションとそのようなオプションを含む別のBinding Acknowledgementメッセージが含まれていない場合に、後に受信されますこの後続のバインディング確認メッセージを支持する第一の結合確認を受け付けるに関与する任意の状態の変更を元に戻します。そのようなオプションなしで確認応答メッセージをバインディング上で有効なCGAパラメータと署名オプションを使用して確認応答メッセージをバインディングに優先権を与えることはCGAを使用していない通信相手ノードと通信するために、モバイルノードを可能にし、同時に、ほとんどのパス攻撃から保護します。戦略は、コレスポンデントノードからのバインディング受信確認メッセージを傍受することができ、攻撃者から保護しませんが、そのような攻撃はとにかく移動ノードとコレスポンデントノード間のモビリティ管理を排除することができます。モバイルノードは永久に有効なCGAパラメータと署名のオプションなしでBinding Acknowledgementメッセージを受け入れた場合には、モバイルノードは、同じ通信員ノードのためのBinding Updateメッセージ将来のCGAパラメータ要求オプションを含むお控えください。
If the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node extracts the permanent home keygen token included in this option and stores it in its Binding Update List entry for the correspondent node. Future Binding Update messages will then be authenticated by a proof of the mobile node's knowledge of this permanent home keygen token.
Binding Acknowledgementメッセージは永久的な家のkeygenトークンオプションが含まれている場合、モバイルノードは、コレスポンデントノードのためにその結合更新リストエントリでこのオプションを格納それに含ま永久的な家のkeygenトークンを抽出します。将来のバインディング更新メッセージは、この永久的な家のkeygen象徴のモバイルノードの知識の証拠によって認証されます。
If the Binding Acknowledgment message contains a Care-of Test option, the mobile node extracts the care-of keygen token included in this option, stores the token in its Binding Update List entry for the correspondent node, and sends the correspondent node a complete Binding Update message as defined in Section 4.1. Note that the complete Binding Update message will be authenticated based on the CGA property of the mobile node's home address if the Binding Acknowledgment message also includes a Permanent Home Keygen Token option. This is independent of the authentication method that was used for the corresponding early Binding Update message.
Binding Acknowledgementメッセージは、気付テストオプションが含まれている場合は、モバイルノードが気付生成トークン、このオプションに含まを抽出し、対応ノードのためにその結合更新リスト項目にトークンを格納し、完全な結合相手ノードを送信セクション4.1で定義されたメッセージを更新します。 Binding Acknowledgementメッセージも永久的な家のkeygenトークンオプションが含まれている場合、完全なBinding Updateメッセージは、モバイルノードのホームアドレスのCGAの特性に基づいて認証されることに注意してください。これは、対応する初期のBinding Updateメッセージのために使用された認証方式とは無関係です。
A mobile node MUST ensure that, while it has a binding for a certain home address at a correspondent node, it also has a valid binding at its home agent for the same home address. This may at times require the mobile node to extend the binding lifetime at the home agent, request a correspondent node to use a binding lifetime less than the permitted maximum, or explicitly deregister an existing binding at a correspondent node.
それは、通信相手ノードで特定のホームアドレスの結合がある一方で、モバイルノードは、次のことを確認しなければならない、それはまた、同じホームアドレスのためにそのホームエージェントで有効なバインディングを持っています。これは時々、ホームエージェントに結合寿命を延ばす許可された最大値よりも少ない結合寿命を使用するために、通信相手ノードを要求する、または明示的に既存のコレスポンデント・ノードでの結合の登録を解除するために、モバイルノードが必要な場合があります。
If the mobile node authenticates Binding Update messages for a particular correspondent node by proving its knowledge of a permanent home keygen token, but registrations at this correspondent node persistently fail, the mobile node SHOULD renew the permanent home keygen token by sending a Binding Update message that is authenticated based on the CGA property of its home address. This Binding Update message includes the mobile node's CGA parameters and signature, and it requests the correspondent node to generate a new permanent home keygen token and send this to the mobile node within a Binding Acknowledgment message.
モバイルノードは永久的な家のkeygen象徴の知識を証明することにより、特定の相手ノードのためのBinding Updateメッセージ認証しますが、このコレスポンデントノードの登録は持続的に失敗した場合、モバイルノードは、バインディング更新メッセージを送信することによって、永久的な家のkeygenトークンを更新する必要があることそのホームアドレスのCGAの特性に基づいて認証されます。このBinding Updateメッセージは、モバイルノードのCGAパラメータと署名を含み、そしてそれは新しい永久的な家のkeygenトークンを生成し、Binding Acknowledgementメッセージ内の移動ノードにこれを送信するために、通信相手ノードを要求します。
If the mobile node persistently receives Binding Acknowledgment messages with status code 148 ("CGA and signature verification failed") from a correspondent node, the mobile node SHOULD authenticate future Binding Update messages for the same correspondent nodes through a proof of its reachability at the home address. This enables the mobile node to recover from misconfigured or outdated CGA software [12] on the correspondent node side or at the mobile node itself.
モバイルノードは、永続的にコレスポンデントノードからステータスコード148と結合応答メッセージ（「CGAと署名検証に失敗しました」）を受信した場合、モバイルノードは、自宅で、その到達可能性の証拠を介して同一のコレスポンデントノードに対して更新メッセージをバインディング将来の認証SHOULD住所。これは、通信相手ノード側又はモバイルノード自体に誤って設定または古いCGAソフトウェア[12]から回復するためにモバイルノードを可能にします。
A mobile node includes its CGA parameters and signature in a Binding Update message for a correspondent node in any of the following situations:
モバイルノードは、次のいずれかの状況において、通信相手ノードのバインディング更新メッセージにそのCGAパラメータおよび署名を含みます。
o To acquire a permanent home keygen token if the mobile node's home address is a CGA, and the mobile node does not yet have a permanent home keygen token from the correspondent node.
モバイルノードのホームアドレスがCGAであればoは永久的な家のkeygenトークンを取得するには、モバイルノードは、まだ相手ノードからの永久的な家のkeygenトークンを持っていません。
o To extend the lifetime of an existing binding if the mobile node already has a permanent home keygen token from the correspondent node, and the lifetime of the binding at the correspondent node is about to expire.
モバイルノードがすでに相手ノードから永久的な家のkeygenトークンを持ち、相手ノードでの結合の寿命が期限切れになる場合には、既存の結合の寿命を延ばすために、O。
o To renew an existing permanent home keygen token to prevent replay attacks in the imminent event of a sequence number rollover, or for improved protection against cryptanalysis.
oは、または解読法に対して改善された保護のためのシーケンス番号のロールオーバーの切迫したイベントにリプレイ攻撃を防ぐために、既存の永久的な家のkeygenトークンを更新します。
A correspondent node whose IP address is a CGA includes its CGA parameters and signature in a Binding Acknowledgment message for the mobile node when it receives a Binding Update message with a CGA Parameters Request option.
IPアドレスが通信相手ノードは、CGAは、それがCGAパラメータ要求オプションでBinding Updateメッセージを受信するモバイルノードのバインディング確認メッセージにそのCGAパラメータと署名を含んでいます。
CGA parameters are transmitted in the format of the CGA Parameters data structure defined in [2]. The CGA Parameters data structure is split over one or more CGA Parameters options as described in Section 5.1. The last CGA Parameters option MUST be directly followed by a Signature option.
CGAパラメータは、[2]で定義されたCGAパラメータデータ構造の形式で送信されます。 5.1節で説明したようにCGAパラメータのデータ構造は、1つ以上のCGAパラメータオプションに分割されます。最後のCGAパラメータオプションは、直接署名オプションが続かなければなりません。
The value for the Signature field in the Signature option is calculated according to the signature generation algorithm defined in Section 6 of [2]. The value is calculated with the mobile or correspondent node's private key over the following sequence of octets:
署名オプションで署名フィールドの値は[2]のセクション6で定義された署名生成アルゴリズムに従って計算されます。値はオクテットの次のシーケンスを超えるモバイルや通信員ノードの秘密鍵を用いて計算されます。
mobility data = care-of address | correspondent node IP address | MH data
モビリティデータ=気付アドレス|コレスポンデントノードのIPアドレス| MHデータ
where "|" denotes concatenation. "Care-of address" is the mobile node's care-of address, and "correspondent node IP address" is the IP address of the correspondent node that is visible to protocol layers above IP. In case the correspondent node is mobile, "correspondent node IP address" refers to the correspondent node's home address. "MH data" is the content of the Binding Update or Binding Acknowledgment message including the mobility header and all options up to the last CGA Parameters option. That is, "MH data" excludes the IPv6 header and any IPv6 extension headers other than the mobility header itself. The "mobility data" constitutes what is referred to as the "message" in Section 6 of [2].
ここで、「|」連結を示しています。 「気付アドレス」が移動ノードの気付アドレスであり、「相手ノードのIPアドレスが」IP上のプロトコル層に表示される通信相手ノードのIPアドレスです。コレスポンデントノードがモバイルの場合は、「相手ノードのIPアドレス」相手ノードのホームアドレスを指します。 「MHデータは、」結合Updateまたはモビリティヘッダと最後のCGAパラメータオプションまで、すべてのオプションを含むBinding Acknowledgementメッセージの内容です。すなわち、「MHデータが」IPv6ヘッダとモビリティヘッダ自体以外のIPv6拡張ヘッダを除外しています。 「移動性データ」の第6章の「メッセージ」と呼ばれるものを構成している[2]。
The value for the Signature field is calculated as if the Checksum field in the mobility header was zero. The Checksum field in the transmitted packet is still calculated in the usual manner, with the calculated value in the Signature field being a part of the packet protected by the checksum.
署名フィールドの値は、モビリティヘッダ内のチェックサムフィールドがゼロであったかのように計算されます。送信されたパケット内のチェックサムフィールドは依然として署名フィールドの計算値がチェックサムによって保護されたパケットの一部であると、通常の方法で計算されます。
Mobile and correspondent nodes that receive a Binding Update or Binding Acknowledgment message including one or more CGA Parameters options directly followed by a Signature option first process the message as described in [1]. This includes a verification of the authenticator in the Authenticator field of the Binding Authorization Data option. If the Binding Update or Binding Acknowledgment message is rejected due to an incorrect authenticator or for any other reason, the message is not processed further.
[1]において説明したようにバインディング更新または1つ以上のCGAパラメータオプションを含むBinding Acknowledgementメッセージを受信するモバイルと対応ノードが直接メッセージ署名オプション最初のプロセスが続きます。これは、結合認証データオプションの認証分野でのオーセンティケータの検証を含んでいます。バインディングUpdateまたはBinding Acknowledgementメッセージが誤った認証システムやその他の理由で拒否された場合、メッセージはさらに処理されていません。
Otherwise, if the validation of the Binding Update or Binding Acknowledgment message succeeds, the mobile or correspondent node reassembles the CGA Parameters data structure from the CGA Parameters options included in the message as described in Section 5.1, and executes the CGA verification algorithm defined in Section 5 of [2]. The CGA verification algorithm takes the to-be-verified CGA and the reassembled CGA Parameters data structure as input. The to-be-verified CGA is the mobile node's home address when the CGA verification algorithm is executed by the correspondent node. When the mobile node executes the CGA verification algorithm, the to-be-verified CGA is the correspondent node's IP address that is visible to protocol layers above IP. This is the correspondent node's home address in case the correspondent node is mobile. The following steps are skipped if the CGA verification fails.
バインディング更新の検証やBinding Acknowledgementメッセージが成功した場合そうでない場合、モバイル又はコレスノードは、セクション5.1で説明したように、メッセージに含まCGAパラメータオプションからCGAパラメータデータ構造を再構成し、そしてセクションで定義されたCGA検証アルゴリズムを実行します[2] 5。 CGA検証アルゴリズムは、検証する-CGA入力として再組立てCGAパラメータデータ構造をとります。 -であることを検証CGA CGA検証アルゴリズムは、コレスポンデントノードによって実行されたときに、モバイルノードのホームアドレスです。モバイルノードは、CGA検証アルゴリズムを実行する際に、検証されるべき-CGAは、IP上のプロトコル層に表示される通信相手ノードのIPアドレスです。これは、コレスポンデントノードがモバイルの場合には、通信相手ノードのホームアドレスです。 CGAの検証が失敗した場合、次のステップはスキップされます。
If the CGA verification succeeds, the mobile or correspondent node performs a more time-consuming check of the signature. It extracts the signature from the Signature field in the Signature option and executes the signature verification algorithm defined in Section 6 of [2]. The signature verification algorithm takes as input the to-be-verified CGA as defined above, the reassembled CGA Parameters data structure, the MH data as defined in Section 4.5, the CGA Message Type tag of Enhanced Route Optimization as defined in Section 7, and the signature itself.
CGA検証が成功した場合、モバイル又はコレスノード署名のより時間のかかるチェックを行います。これは、署名オプションで署名フィールドから署名を抽出し、[2]のセクション6で定義された署名検証アルゴリズムを実行します。署名検証アルゴリズムは、TO-検証することが上記で定義され、再び組み立てCGAパラメータデータ構造をCGAを、4.5節で定義されるようMHデータは、拡張ルート最適化のCGAメッセージタイプタグは、セクション7で定義されるように入力として受け取り、および署名そのもの。
A correspondent node assigns a mobile node a new permanent home keygen token after it has received from the mobile node a Binding Update message with included CGA Parameters and Signature options, and these options have been successfully validated as described in Section 4.6. The permanent home keygen token is a 64-bit value randomly generated by the correspondent node. The correspondent node stores the permanent home keygen token in the binding cache entry that it maintains for the mobile node.
コレスポンデント・ノードは、それが4.6節で説明したように含まCGAパラメータおよび署名オプション、およびこれらのオプションでBinding Updateメッセージが正常に検証されているモバイルノードから受信した新しい永久的な家のkeygenトークンの後、移動ノードが割り当てられます。パーマネントホーム鍵生成トークンは、ランダムに、コレスポンデント・ノードによって生成された64ビット値です。コレスポンデントノードは、モバイルノードのために維持していることをバインディングキャッシュエントリに永久的な家のkeygenトークンを格納します。
The correspondent node sends the permanent home keygen token to the mobile node in encrypted form within a Permanent Home Keygen Token option in a Binding Acknowledgment message. It sends this message even if the Acknowledge flag in the corresponding Binding Update message was clear. The correspondent node encrypts the permanent home keygen token with the mobile node's public key using the RSAES-PKCS1-v1_5 format [4], and places the ciphertext into the Permanent Home Keygen Token field of the Permanent Home Keygen Token option.
コレスポンデントノードは、Binding Acknowledgementメッセージに永久的な家のkeygenトークンオプションの中に暗号化された形式で、移動ノードに永久的な家のkeygenトークンを送信します。それは、対応するBinding Updateメッセージで確認応答フラグが明らかになった場合でも、このメッセージを送信します。対応ノードは、[4] RSAES-PKCS1-v1_5の形式を使用して、モバイルノードの公開鍵で永久的な家のkeygenトークンを暗号化し、かつ永久的な家生成トークンオプションの永久的な家のkeygenトークンフィールドに暗号文を配置します。
The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment message. That is, the authenticator in the
結合認証データオプションは、Binding Acknowledgementメッセージの最後のオプションでなければなりません。これは、オーセンティケータであります
Binding Authorization Data option covers the Permanent Home Keygen Token option.
結合認証データオプションは、永久的な家のkeygenトークンオプションをカバーしています。
A mobile node that receives a Binding Acknowledgment message first processes the message as described in [1], independent of whether the message includes a Permanent Home Keygen Token option. This includes a verification of the authenticator in the Authenticator field of the Binding Authorization Data option. If the Binding Acknowledgment message is rejected due to an incorrect authenticator or for any other reason, the mobile node does not process the message further.
[1]に記載のようにBinding Acknowledgementメッセージが最初のメッセージは、パーマネントホームキー生成トークンオプションを含むかどうかとは無関係に、メッセージを処理して受信するモバイルノード。これは、結合認証データオプションの認証分野でのオーセンティケータの検証を含んでいます。 Binding Acknowledgementメッセージが誤った認証システムやその他の理由で拒否された場合、モバイルノードは、さらにメッセージを処理しません。
Otherwise, if the mobile node accepts the Binding Acknowledgment message and the message includes a Permanent Home Keygen Token option, the mobile node extracts the ciphertext from the Permanent Home Keygen Token field in this option and decrypts it with its private key using the RSAES-PKCS1-v1_5 format [4]. The result of the encryption is the permanent home keygen token to be used in further registrations with the correspondent node. The mobile node stores the permanent home keygen token in the Binding Update List entry that it maintains for the correspondent node.
モバイルノードが受け入れる場合Binding Acknowledgementメッセージとメッセージが永久的な家のkeygenトークンオプションが含まれてそれ以外の場合は、モバイルノードは、このオプションでは永久的な家のkeygenトークンフィールドから暗号文を抽出し、RSAES-PKCS1を使用して、その秘密鍵で復号化し-v1_5形式[4]。暗号化の結果は、コレスポンデントノードとの更なる登録に使用する永久的な家のkeygenトークンです。モバイルノードは、それが相手ノードのために維持して結合更新リスト項目内の永久的な家のkeygenトークンを格納します。
A mobile node that shares a permanent home keygen token with a correspondent node MUST NOT use the same sequence number twice with this permanent home keygen token in order to protect against replay attacks. The mobile node MUST renew the permanent home keygen token by including its CGA parameters and signature in a Binding Update message for the correspondent node when a sequence number rollover is imminent. In addition, the mobile node MAY renew its permanent home keygen token at any time. Periodic renewal of the permanent home keygen token provides increased protection against cryptanalysis. Finally, the mobile node may in most cases want to renew the permanent home keygen token when the lifetime of its binding at the correspondent node expires.
コレスポンデントノードとの永久的な家のkeygenトークンを共有するモバイルノードは、リプレイ攻撃から保護するために、このパーマネントホーム鍵生成トークンで二度同じシーケンス番号を使用してはなりません。モバイルノードは、シーケンス番号のロールオーバーが差し迫っている場合、コレスポンデント・ノードのバインディング更新メッセージにそのCGAパラメータと署名を含めることにより、永久ホーム鍵生成トークンを更新しなければなりません。また、モバイルノードは、いつでもその永久的な家のkeygenトークンを更新することができます。永久的な家のkeygen象徴の定期的な更新が解読法に対して増加保護を提供します。最後に、モバイルノードは、ほとんどの場合、そのは、コレスポンデントノードでの結合の寿命が満了したときに永久的な家のkeygenトークンを更新することをお勧めします。
The immediate exchange of an early Binding Update message after a handoff on the mobile node side enables mobile and correspondent nodes to quickly reestablish route-optimized communications via the mobile node's new care-of address. The mobile node may send payload packets to the correspondent node from the new care-of address as soon as it has dispatched the early Binding Update message. The correspondent node redirects outgoing payload packets for the mobile node to the new care-of address once it has received the early
モバイルノード側のハンドオフ後の初期のBinding Updateメッセージの即時交換が素早く移動ノードの新しい気付けアドレスを経由して経路最適化通信を再確立するために、モバイルと通信員ノードを可能にします。モバイルノードは、それが初期のBinding Updateメッセージを派遣しているとすぐに新しい気付アドレスから相手ノードへのペイロードパケットを送信することができます。それが早期に受信した後、コレスポンデント・ノードは、新たな気付アドレスにモバイルノードの発信ペイロードパケットをリダイレクト
Binding Update message and registered the new care-of address. Here, a "payload packet" is defined as a packet that originates at a protocol layer above IP.
Updateメッセージを結合し、新しい気付けアドレスを登録。ここで、「ペイロードパケットは、」IP上のプロトコル層に発信パケットとして定義されます。
Inbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Increase credit |
| in |---------------------> | counter by |
\ VERIFIED state? / | payload packet size |
\_________________/ |_____________________|
| |
| |
| No |
| V
| _____________________
| | |
| | Deliver payload |
+--------------------------------> | packet to upper- |
| layer protocol |
|_____________________|
Figure 4: Handling outbound payload packets
図4：アウトバウンドペイロードパケットの処理
A new care-of address that was registered with an early Binding Update message is maintained in UNVERIFIED state by the correspondent node until the correspondent node receives a complete Binding Update message from the mobile node. The correspondent node then sets the care-of address to VERIFIED state. The state of the care-of address determines the maximum amount of data that the correspondent node is allowed to send to the care-of address, as is necessary to prevent amplified, redirection-based flooding attacks. For this purpose, the correspondent node maintains a "credit counter" for each mobile node with an entry in its Binding Cache. Whenever a payload packet arrives from a mobile node with a care-of address in VERIFIED state, the correspondent node SHOULD increase the mobile node's credit counter by the size of the received payload packet. The correspondent node MAY be restricted by policy to increase the credit counter by a lower value or not to increase the credit at all. The credit counter does not change when an inbound payload packet is received from a care-of address in UNVERIFIED state. Figure 4 shows a flow chart of this procedure.
コレスポンデントノードは、モバイルノードからの完全なBinding Updateメッセージを受信するまで、新しい気付アドレス早期Binding Updateメッセージに登録された通信相手ノードによってUNVERIFIED状態に維持されます。コレスポンデントノードは、VERIFIED状態に気付アドレスを設定します。気付アドレスの状態は、増幅、リダイレクションベースのフラッディング攻撃を防止する必要があるように、通信相手ノードは、気付けアドレスに送信することを許可されているデータの最大量を決定します。このためには、コレスポンデント・ノードは、そのバインディングキャッシュにエントリを持つ各モバイルノードのための「クレジット・カウンタ」を維持しています。ペイロードパケットが検証状態の気付アドレスを持つモバイルノードから到着するたびに、相手ノードは、受信したペイロードパケットのサイズによって、モバイルノードのクレジットカウンタを増やす必要があります。コレスポンデント・ノードは、まったく信用を高めるために低い値でクレジットカウンタを増加させたりしないようにポリシーによって制限される場合があります。インバウンドペイロードパケットが気付アドレスUNVERIFIED状態にあるから受信したときにクレジットカウンタは変化しません。図4は、この手順のフローチャートを示します。
Outbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Send payload |
| in |---------------------> | packet to |
\ VERIFIED state? / | care-of address |
\_________________/ |_____________________|
|
| _____________________
| No | |
| | Discard payload |
| +---------> | packet |
| | | immediately |
V | |_____________________|
_________________ | _____________________
/ \ | | |
/ Credit counter \ Yes / \ | Send payload |
| less than payload |-------> | |-------> | packet to |
\ packet size? / \ / | home address |
\_________________/ | |_____________________|
| | _____________________
| | | |
| No | | Buffer payload |
| +---------> | packet for |
| | later transmission |
| |_____________________|
V
_____________________ _____________________
| | | |
| Reduce credit | | Send payload |
| counter by |---------------------> | packet to |
| payload packet size | | care-of address |
|_____________________| |_____________________|
Figure 5: Handling outbound payload packets
図5：アウトバウンドペイロードパケットの処理
When the correspondent node has a payload packet to send to the mobile node, further treatment of the payload packet depends on the state of the mobile node's care-of address and the current value of the mobile node's credit counter, as illustrated in Figure 5: The correspondent node MUST send the payload packet to the mobile node's care-of address if the care-of address is in VERIFIED state. If the care-of address is in UNVERIFIED state and the value of the credit counter is higher than or equal to the size of the payload packet, the correspondent node MUST reduce the mobile node's credit counter by the size of the payload packet and send the payload packet to the care-of address as well. However, if the care-of address is in UNVERIFIED state and the credit counter is less than the size of the payload packet, the payload packet MUST NOT be sent to the mobile node's care-of address. The correspondent node SHOULD then discard the payload packet, although it MAY alternatively buffer the payload packet until the care-of address moves to VERIFIED state, or send the payload packet to the mobile node's home address. The credit counter of the mobile node does not change when the correspondent node sends a payload packet to the mobile node's care-of address while the care-of address is in VERIFIED state.
コレスポンデント・ノードは、モバイルノードに送信するペイロードパケットを有する場合、図5に示すように、ペイロードパケットのさらなる処理は、モバイルノードの気付アドレスの状態とモバイルノードのクレジットカウンタの現在の値に依存します。気付けアドレスが検証状態にある場合には、通信相手ノードは、モバイルノードの気付アドレスにペイロードパケットを送らなければなりません。気付けアドレスはUNVERIFIED状態にあり、クレジットカウンタの値がより高いか、ペイロードパケットのサイズに等しい場合、コレスポンデントノードは、ペイロードパケットのサイズによって、モバイルノードのクレジットカウンタを削減し、送らなければなりません気付けアドレスのほかにペイロードパケット。気付けアドレスはUNVERIFIED状態にあり、クレジットカウンタは、ペイロードパケットのサイズよりも小さい場合には、ペイロードパケットは、モバイルノードの気付アドレスに送ってはいけません。それは代わりに気付アドレスが状態を検証し、またはモバイルノードのホームアドレスにペイロードパケットを送信するために移動するまでペイロードパケットをバッファリングすることができるが、コレスポンデントノードは、その後、ペイロードパケットを破棄すべきです。気付けアドレスが検証状態にあるときに、通信相手ノードは、モバイルノードの気付アドレスにペイロードパケットを送信するときに、モバイルノードのクレジットカウンタは変化しません。
The amount of data that the mobile node may send to the correspondent node is never restricted due to the state of the mobile node's care-of address. The care-of address state also does not change the addressing and routing of payload packets in either traffic direction: All payload packets that originate from the mobile node have the care-of address in the Source Address field of the IPv6 header and the home address in the Home Address option of the IPv6 Destination Options extension header. Vice versa, all payload packets from the correspondent node have the care-of address in the Destination Address field of the IPv6 header and the home address in the IPv6 Routing extension header.
モバイルノードは、コレスポンデントノードに送信することができ、データの量が原因モバイルノードの気付アドレスの状態に制限されることはありません。気付アドレスの状態も対処するといずれかのトラフィック方向のペイロードパケットのルーティングを変更しない：モバイルノードから発信すべてのペイロードパケットは、IPv6ヘッダのソースアドレスフィールドとホームアドレスに気付アドレスを持っていますIPv6の宛先オプション拡張ヘッダのホームアドレスオプションインチ逆もまた同様、コレスポンデントノードからのすべてのペイロードパケットは、IPv6ヘッダとIPv6ルーティング拡張ヘッダ内のホームアドレスの宛先アドレスフィールドに気付アドレスを持っています。
A correspondent node ensures that all credit counters that it maintains gradually decrease over time. Each credit counter is multiplied with a factor, CreditAgingFactor, of less than one in fixed time intervals of CreditAgingInterval length. Such "credit aging" limits the total credit that a mobile node can earn, provided that the replenishing rate for the credit is constant or nearly constant. It thereby enforces an upper bound on the rate at which the correspondent node can durably sent to the mobile node's care-of address while the care-of address is in UNVERIFIED state. In the absence of credit aging, a malicious node with poor up-link capacity could adopt the role of a mobile node, build up credit at a very slow speed and over a long period, and spend this credit during a much shorter period on redirecting a burst of payload packets to the IP address of a victim.
コレスポンデント・ノードは、それが時間の経過とともに徐々に減少維持し、すべてのクレジットカウンターことを保証します。各クレジットカウンタはCreditAgingInterval長の一定の時間間隔で1未満の係数、CreditAgingFactorと乗算されます。そのような「信用の老化」は信用のために補充速度が一定またはほぼ一定であることを条件とする、モバイルノードが得ることができ、総クレジットを制限します。それによって気付アドレスは未確認の状態にある間に、通信相手ノードは、永続的移動ノードの気付アドレスに送信できる速度の上限を強制します。クレジット老化がない場合には、貧しい人々のアップリンク容量を持つ悪意のあるノードは、モバイルノードの役割を採用する可能性が非常に遅い速度でかつ長期にわたって信用を構築し、リダイレクトにはるかに短い期間の間に、このクレジットを過ごします被害者のIPアドレスへのペイロード・パケットのバースト。
Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to facilitate applications where the correspondent node sends at a higher rate than the mobile node. If CreditAgingFactor or CreditAgingInterval is too small, the credit counter might persistently prevent the transmission of payload packets to a care-of address in UNVERIFIED state. The values given in Section 7 are RECOMMENDED as they work well when the correspondent node transfers a file to the mobile node via a TCP connection and the end-to-end round-trip time does not exceed 500 milliseconds.
CreditAgingFactorとCreditAgingIntervalのための適切な値を選択すると、コレスポンデントノードは、モバイルノードよりも高いレートで送信したアプリケーションを容易にするために重要です。 CreditAgingFactorまたはCreditAgingIntervalが小さすぎると、クレジットカウンタは、永続的に気付アドレスUNVERIFIED状態でのペイロードパケットの送信を防ぐかもしれません。コレスポンデントノードは、TCP接続とエンドツーエンドの往復時間を介して移動ノードへのファイルが500ミリ秒を超えていない転送したときに、彼らはうまく機能として、第7節で与えられた値が推奨されています。
As specified in [1], Binding Update messages are sent to a mobile correspondent node's home address. This makes it possible for two mobile nodes to continue communications even if both of them change IP connectivity at the same time.
[1]で指定されているように、バインディング更新メッセージは、モバイル、通信相手ノードのホームアドレスに送信されます。これにより、それらの両方が同時にIP接続を変更した場合でも、2つのモバイルノードが通信を継続できるようになります。
Enhanced Route Optimization uses a set of new mobility options and status codes in addition to the mobility options and status codes defined in [1]. These are described below.
強化されたルート最適化は、[1]で定義されたモビリティオプションとステータスコードに加えて、新しいモビリティオプションとステータスコードのセットを使用しています。これらは、以下に記載されています。
The CGA Parameters option is used in Binding Update and Binding Acknowledgment messages. It contains part of the mobile or correspondent node's CGA parameters. [1] limits mobility header options to a maximum length of 255 bytes, excluding the Option Type and Option Length fields. Since the CGA parameters are likely to exceed this limit, multiple CGA Parameters options may have to be concatenated to carry all CGA parameters.
CGAパラメータオプションは、アップデートをバインドし、受信確認メッセージをバインディングで使用されています。これは、携帯電話や通信員ノードのCGAパラメータの一部が含まれています。 [1]オプションタイプとオプション長フィールドを除く、255バイトの最大長にモビリティヘッダオプションを制限します。 CGAパラメータがこの制限を超える可能性があるので、複数のCGAパラメータオプションは、すべてのCGAパラメータを運ぶために連結されなければなりません。
The format of the CGA Parameters option is as follows:
次のようにCGAパラメータオプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: CGA Parameters :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 12.
このモビリティオプションのタイプの8ビットの識別子。その値は12です。
Option Length
オプション長
8-bit unsigned integer representing the length of the CGA Parameters field in octets.
オクテットでCGAパラメータフィールドの長さを示す8ビットの符号なし整数。
CGA Parameters
CGAパラメータ
This field contains up to 255 bytes of the CGA Parameters data structure defined in [2]. The concatenation of all CGA Parameters options in the order they appear in the Binding Update message MUST result in the original CGA Parameters data structure. All CGA Parameters options in the Binding Update message except the last one MUST contain exactly 255 bytes in the CGA Parameters field, and the Option Length field MUST be set to 255 accordingly. All CGA Parameters options MUST appear directly one after another, that is, a mobility option of a different type MUST NOT be placed in between two CGA Parameters options.
このフィールドは、[2]で定義されたCGAパラメータデータ構造の255のバイトまでを含みます。彼らはBinding Updateメッセージに表示される順序ですべてのCGAパラメータオプションの連結は、元CGAパラメータのデータ構造をもたらさなければなりません。最後のものを除いてバインディング更新メッセージのすべてのCGAパラメータオプションは、CGAパラメータ]フィールドに正確に255バイトを含まなければならない、とオプション長フィールドはそれに応じて255に設定しなければなりません。すべてのCGAパラメータオプションは、異なるタイプのモビリティオプションが2つのCGAパラメータオプションの間に置かれてはならない、つまり、直接次々と現れなければなりません。
The Signature option is used in Binding and Binding Acknowledgment Update messages. It contains a signature that the mobile or correspondent node generates with its private key over one or more preceding CGA Parameters options.
署名オプションは、バインディングと謝辞Binding Updateメッセージで使用されています。これは、携帯電話や通信員ノードが1つの以上前のCGAパラメータオプションの上にその秘密鍵で生成した署名が含まれています。
The format of the Signature option is as follows:
次のように署名オプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Signature :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 13.
このモビリティオプションのタイプの8ビットの識別子。その値は13です。
Option Length
オプション長
8-bit unsigned integer representing the length of the Signature field in octets.
オクテット内の署名フィールドの長さを示す8ビットの符号なし整数。
Signature
署名
This field contains the mobile or correspondent node's signature, generated with the mobile or correspondent node's private key as specified in Section 4.5.
このフィールドは、セクション4.5に指定されているモバイルや通信員ノードの秘密鍵で生成され、携帯電話や通信員ノードの署名が含まれています。
The Permanent Home Keygen Token option is used in Binding Acknowledgment messages. It contains a permanent home keygen token, which the correspondent node sends to the mobile node after it has received a Binding Update message containing one or more CGA Parameters options directly followed by a Signature option from the mobile node.
恒久的なホームkeygenのトークンのオプションは、確認応答メッセージをバインディングで使用されています。それは直接、モバイルノードからの署名オプションに続いて一つ以上のCGAパラメータオプションを含むBinding Updateメッセージを受信した後にコレスポンデントノードは、モバイルノードに送信され、永久的な家のkeygenトークンが含まれています。
The format of the Permanent Home Keygen Token option is as follows:
次のように永久的な家のkeygenトークンオプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Permanent Home Keygen Token :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 14.
このモビリティオプションのタイプの8ビットの識別子。その値は14です。
Option Length
オプション長
8-bit unsigned integer representing the length of the Permanent Home Keygen Token field in octets.
オクテット永久ホームキー生成トークンフィールドの長さを示す8ビットの符号なし整数。
Permanent Home Keygen Token
恒久的なホームkeygenのトークン
This field contains the permanent home keygen token generated by the correspondent node. The content of this field MUST be encrypted with the mobile node's public key as defined in Section 4.7. The length of the permanent home keygen token is 8 octets before encryption, though the ciphertext [4] and, hence, the Permanent Home Keygen Token field may be longer.
このフィールドは、コレスポンデントノードによって生成された永久的な家のkeygenトークンが含まれています。このフィールドの内容は、4.7節で定義されているモバイルノードの公開鍵で暗号化されなければなりません。暗号文は、[4]と、それゆえ、永久的な家のkeygenトークンフィールドは長くなるかもしれないが永久的な家のkeygenトークンの長さは、暗号化前の8つのオクテットです。
The Care-of Test Init option is included in Binding Update messages. It requests a correspondent node to return a Care-of Test option with a fresh care-of keygen token in the Binding Acknowledgment message.
気付テスト開始オプションがBinding Updateメッセージに含まれています。それは、Binding Acknowledgementメッセージで新鮮気付け生成トークンと気付テストのオプションを返すために、通信相手ノードを要求します。
The format of the Care-of Test Init option is as follows:
次のように気付試験開始オプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 15.
このモビリティオプションのタイプの8ビットの識別子。その値は15です。
Option Length
オプション長
This field MUST be set to zero.
このフィールドはゼロに設定しなければなりません。
The Care-of Test option is used in Binding Acknowledgment messages. It contains a fresh care-of keygen token, which the correspondent node sends to the mobile node after it has received a Care-of Test Init option in a Binding Update message.
気付テストのオプションは、確認応答メッセージをバインディングで使用されています。それは新鮮な気付keygenのトークン、それはBinding Updateメッセージで試験開始気付けオプションを受け取った後にコレスポンデントノードは、モバイルノードに送信する含まれています。
The format of the Care-of Test option is as follows:
次のように気付テストオプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 16.
このモビリティオプションのタイプの8ビットの識別子。その値は16です。
Option Length
オプション長
This field MUST be set to 8. It represents the length of the Care-of Keygen Token field in octets.
このフィールドは、それはオクテットで気付鍵生成トークンのフィールドの長さを表し8に設定しなければなりません。
Care-of Keygen Token
気付生成トークン
This field contains the care-of keygen token generated by the correspondent node, as specified in Section 4.3.
このフィールドは、セクション4.3で指定されるように、コレスポンデントノードによって生成さkeygenのケア - のトークンが含まれています。
The CGA Parameters Request option is included in Binding Update messages that are authenticated based on the CGA property of the mobile node's home address. It requests a correspondent node to return its CGA parameters and signature in the Binding Acknowledgment message, enabling the mobile node to verify that the permanent home keygen token returned in the Binding Acknowledgment message was generated by the right correspondent node.
CGAパラメータ要求オプションは、モバイルノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージに含まれています。それは、Binding Acknowledgementメッセージで返さ永久的な家のkeygenトークンは右コレスポンデントノードによって生成されたことを確認するために、モバイルノードを有効にする、Binding AcknowledgementメッセージにそのCGAパラメタと署名を返すために、通信相手ノードを要求します。
The format of the CGA Parameters Request option is as follows:
次のようにCGAパラメータ要求オプションの形式は次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value is 11.
このモビリティオプションのタイプの8ビットの識別子。その値は11です。
Option Length
オプション長
This field MUST be set to zero.
このフィールドはゼロに設定しなければなりません。
Enhanced Route Optimization uses the following four new status codes for Binding Acknowledgment messages in addition to the status codes defined in [1]:
強化されたルート最適化は、[1]で定義されたステータスコードに加えて、受信確認メッセージを結合するために、次の4つの新しいステータスコードを使用しています。
Permanent home keygen token unavailable (147)
使用できない永久的な家のkeygenトークン（147）
A correspondent node returns a Binding Acknowledgment message with status code 147 to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through the CGA property of the mobile node's home address, but the correspondent node either does not have a Binding Cache entry for the mobile node, or the existing Binding Cache entry for the mobile node does not contain a permanent home keygen token. A Binding Acknowledgment message with status code 147 indicates to the mobile node that it should request a new permanent home keygen token from the correspondent node by sending the correspondent node a Binding Update message including its CGA parameters and signature. This in particular enables the mobile node to quickly recover from state loss at the correspondent node.
それは、モバイルノードからモバイルノードのホームアドレスのCGAプロパティを介して認証されたBinding Updateメッセージが、コレスポンデントノードが受信したか、持っていない場合、対応するノードは、移動ノードに、ステータスコード147とBinding Acknowledgementメッセージを返します。モバイルノードのためのBinding Cacheエントリー、またはモバイルノードのための既存のBinding Cacheエントリーは永久的な家のkeygenトークンが含まれていません。ステータスコード147とBinding Acknowledgementメッセージは、コレスポンデント・ノードにそのCGAパラメータおよび署名を含むBinding Updateメッセージを送信することにより通信相手ノードから新しい永久ホーム鍵生成トークンを要求すべきであるモバイルノードに指示します。これは特に、モバイルノードが迅速対応ノードの状態の損失から回復することができます。
[1] does not allow a correspondent node to send a Binding Acknowledgment message with a status code indicating failure when the authenticator of a received Binding Update message turns out to be incorrect. This causes additional handoff latency with high probability because the mobile node can detect the problem only after the expiration of a retransmission timer. The mobile node is furthermore likely to assume packet loss and resend the incorrectly authenticated Binding Update message additional times. A Binding Acknowledgment message with status code 147 helps the mobile node to identify the underlying problem more efficiently when the correspondent node could not verify the CGA property of the mobile node's home address.
[1]コレスポンデント・ノードは、受信したBinding Updateメッセージのオーセンティケータが不正確であることが判明した場合に失敗したことを示すステータスコードとBinding Acknowledgementメッセージを送信することはできません。モバイルノードが唯一の再送タイマの満了後に問題を検出することができますので、これは高い確率で追加のハンドオフ遅延の原因となります。モバイルノードは、パケット損失を仮定し、誤って認証されたBinding Updateメッセージの追加の時間を再送することがさらに可能性があります。ステータスコード147とBinding Acknowledgementメッセージは、コレスポンデントノードは、モバイルノードのホームアドレスのCGAのプロパティを確認できませんでしたときに、より効率的に根本的な問題を識別するために、モバイルノードに役立ちます。
CGA and signature verification failed (148)
CGAと署名検証に失敗した（148）
A correspondent node returns a Binding Acknowledgment message with status code 148 to a mobile node if it has received from the mobile node a Binding Update message that includes one or more CGA Parameters options directly followed by a Signature option, but either the CGA property of the home address cannot be verified based on the contents of the CGA Parameters options, or the verification of the signature in the Signature option has failed.
通信相手ノードは、モバイルノードから直接署名オプション続いて一つ以上のCGAパラメータオプションを含むバインディングアップデートメッセージを受信した場合に、モバイルノードにステータスコード148とBinding Acknowledgementメッセージを返し、しかしのCGA性のいずれかホームアドレスがCGAパラメータオプションの内容に基づいて検証することができない、または署名オプションで署名の検証に失敗しました。
Permanent home keygen token exists (149)
永久的な家のkeygenトークンが存在する（149）
A correspondent node returns a Binding Acknowledgment message with status code 149 to a mobile node if it has received from the mobile node a Binding Update message that was authenticated through verification of the mobile node's reachability at the home address and does not include one or more CGA Parameters options directly followed by a Signature option, but the correspondent node has a permanent home keygen token in its Binding Cache entry for the mobile node. The Binding Update message is processed further if it includes one or more CGA Parameters options directly followed by a Signature option. This enables a mobile node to obtain a new permanent home keygen token from the correspondent node in case it has lost the existing one, for instance, due to a reboot. Whether the correspondent node accepts the Binding Update message in this case depends on the verification of the CGA parameters and the signature provided in the Binding Update message.
コレスポンデントノードは、移動ノードからホームアドレスで、移動ノードの到達性の検証を通じて認証された1つ以上のCGAが含まれていないバインディング更新メッセージを受信した場合、移動ノードに、ステータスコード149とBinding Acknowledgementメッセージを返します。パラメータのオプションは直接署名オプションが続くが、コレスポンデントノードは、モバイルノードのためのBinding Cacheエントリーにおける永久的な家のkeygenトークンを持っています。それが直接署名オプション続いて一つ以上のCGAパラメータオプションを含む場合Binding Updateメッセージはさらに処理されます。これは、それが原因の再起動に、例えば、既存のものを失った場合には、通信相手ノードから新しい永久的な家のkeygenトークンを取得するために、モバイルノードを可能にします。コレスポンデント・ノードは、この場合、Binding Updateメッセージを受け入れるかどうかはBinding Updateメッセージにおいて提供CGAパラメータと署名の検証に依存します。
Non-null home nonce index expected (150)
予想される非ヌルホームナンス指数（150）
A correspondent node returns a Binding Acknowledgment message with status code 150 to a mobile node if it has received from the mobile node a Binding Update message that includes one or more CGA Parameters options directly followed by a Signature option, but the home nonce index specified in the Nonce Indices option is zero. This behavior ensures that a Binding Update message that is authenticated based on the CGA property of the mobile node's home address must also provide a proof of the mobile node's reachability at the home address.
通信相手ノードは、モバイルノードから直接署名オプション続いて一つ以上のCGAパラメータオプションを含むバインディングアップデートメッセージを受信した場合に、モバイルノードにステータスコード150とBinding Acknowledgementメッセージを返すが、ホーム・ナンス指数はで指定されましたナンスインデックスのオプションはゼロです。この動作は、モバイルノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージは、ホームアドレスに移動ノードの到達可能性の証明を提供しなければならないことを保証します。
Enhanced Route Optimization differs from base Mobile IPv6 in that it applies a set of optimizations for increased handoff performance, stronger security, and reduced signaling overhead. These optimizations entail the following conceptual changes to the security model [5] of base Mobile IPv6:
強化されたルート最適化は、それが増加し、ハンドオフのパフォーマンスの最適化のセットを適用することで、ベースモバイルIPv6とは異なり、より強力なセキュリティ、およびシグナリングオーバーヘッドを削減しました。これらの最適化は、塩基モバイルIPv6のセキュリティモデル[5]に以下の概念の変更を伴います。
o Base Mobile IPv6 conducts periodic tests of a mobile node's reachability at the home address as a proof of home address ownership. Enhanced Route Optimization applies an initial cryptographic home address ownership proof in combination with a verification of the mobile node's reachability at the home address in order to securely exchange a secret permanent home keygen token. The permanent home keygen token is used for cryptographic authentication of the mobile node during subsequent correspondent registrations, so that these later correspondent registrations can be securely bound to the initial home address ownership proof. No further periodic reachability verification at the home address tests is performed.
OベースのモバイルIPv6は、ホームアドレスの所有権の証拠としてホームアドレスでの移動ノードの到達可能性を定期的に検査を行っています。強化されたルート最適化が確実に秘密の永久的な家のkeygenトークンを交換するために自宅の住所での移動ノードの到達性の検証と組み合わせて、初期暗号ホームアドレス所有権の証明を適用します。これらの後の通信員登録が確実に最初のホームアドレス所有権証拠に結合することができるように、永久的な家のkeygenトークンは、その後の通信員登録中の移動ノードの暗号化認証に使用されます。ホームアドレステストでこれ以上の定期的な到達可能性の検証は行われません。
o Base Mobile IPv6 requires a mobile node to prove its reachability at a new care-of address during a correspondent registration. This implies that the mobile node and the correspondent node must exchange Care-of Test Init and Care-of Test messages before the mobile node can initiate the binding update proper. Enhanced Route Optimization allows the mobile node to initiate the binding update first and follow up with a proof of reachability at the care-of address. Mobile and correspondent nodes can so resume communications early on after a handoff, while reachability verification proceeds concurrently. The amount of data that the correspondent node is permitted to send to the care-of address until reachability verification completes is governed by Credit-Based Authorization.
OベースのモバイルIPv6は、新しい気付アドレス通信員登録時に、その到達可能性を証明するために、モバイルノードが必要です。これは、モバイルノードは、バインディング更新は、適切な開始する前に、モバイルノードとコレスポンデントノードは、気付試験開始と気付テストメッセージを交換しなければならないことを意味します。強化されたルート最適化は、モバイルノードが最初のバインディングアップデートを開始し、気付アドレスに到達可能性の証拠をフォローアップすることができます。到達可能性の検証が同時に進行しながら、モバイルと対応ノードがので、ハンドオフ後の早い段階での通信を再開することができます。コレスポンデントノードが到達性の検証が完了するまで気付けアドレスに送信することが許可されていることをデータの量は、クレジットベース認証によって支配されています。
o The maximum binding lifetime for correspondent registrations is 7 minutes in base Mobile IPv6. A mobile node must hence periodically refresh a correspondent registration in cases where it does not change IP connectivity for a while. This protocol increases the maximum binding lifetime to 24 hours, reducing the need for periodic refreshes to a negligible degree.
O通信員登録のための最大結合寿命は、ベースモバイルIPv6で7分です。モバイルノードは、したがって、定期的に、それはしばらくの間、IP接続を変更しない場合は通信員登録を更新する必要があります。このプロトコルは、無視できる程度の定期的な更新の必要性を減らす、24時間に最大結合寿命を増大させます。
The ensuing discussion addresses the implications that these conceptual changes of the Mobile IPv6 security model have. The discussion ought to be seen in context with the security considerations of [1], [2], and [5].
その後の議論は、モバイルIPv6のセキュリティモデルのこれらの概念の変化が持つ意味合いに対応しています。議論は、セキュリティ問題に関連して見られるべきである[1]、[2]、[5]。
Enhanced Route Optimization requires a mobile node to deliver a strong cryptographic proof [2] that it is the legitimate owner of the home address it wishes to use. The proof is based on the true home address owner's knowledge of the private component in a public/ private-key pair with the following two properties:
強化されたルート最適化は、それが使用することを希望するホームアドレスの正当な所有者である[2]という強力な暗号化証明を提供するために、モバイルノードが必要です。証明は次の2つのプロパティを持つ公開/秘密鍵ペアのプライベートコンポーネントの真のホームアドレスの所有者の知識に基づいています。
o As an input to an irreversible CGA generation function along with a set of auxiliary CGA parameters, the public key results in the mobile node's home address.
O補助CGAパラメータのセットと共に不可逆CGA生成関数への入力として、モバイルノードのホームアドレスに公開鍵結果。
o Among the CGA parameters that are fed into the CGA generation function is a modifier that, as an input to an irreversible hash extension function along with the public key, results in a string with a certain minimum number of leading zeroes. Three reserved bits in the home address encode this minimum number.
O CGA生成機能に供給されるCGAパラメータのうち改質剤である、公開鍵と一緒に不可逆ハッシュ拡張関数への入力として、先行ゼロのある最小数のストリングが得られます。ホームアドレスエンコードにおける三つの予約ビットこの最小数。
The first property cryptographically binds the home address to the mobile node's public key and, by virtue of public-key cryptography, to the private key. It allows the mobile node to claim ownership of the home address by proving its knowledge of the private key. The second property increases the cost of searching in brute-force manner for a public/private-key pair that suffices the first property. This increases the security of a cryptographically generated home address despite its limitation to 59 bits with cryptographic significance. Solely enforcing the first property would otherwise allow an attacker to find a suitable public/private-key pair in O(2^59) steps. By addition of the second property, the complexity of a brute-force search can be increased to O(2^(59+N)) steps, where N is the minimum number of leading zeroes that the result of the hash extension function is required to have.
最初のプロパティは、暗号秘密鍵に、公開鍵暗号方式のおかげで、モバイルノードの公開鍵にホームアドレスをバインドします。これは、モバイルノードは、秘密鍵の知識を証明することによって、ホームアドレスの所有権を主張することができます。第二の特性は、第一の特性を十分で公開/秘密鍵ペアのための強引な方法で検索のコストを増大させます。これは暗号的意義を有する59ビットへの制限にもかかわらず、暗号化生成ホームアドレスのセキュリティを増大させます。単に最初のプロパティを強制することはそうでない場合は、攻撃者がO（2 ^ 59）の手順で、適切な公開/秘密鍵のペアを見つけることができるようになります。第二の特性を加えることにより、力まかせ探索の複雑さは、Nは、ハッシュ拡張関数の結果が必要とされる先行ゼロの最小数であり、O（2 ^（59 + N））の手順に増加させることができます持つ。
In practice, for a legitimate mobile node to cryptographically generate a home address, the mobile node must first accomplish a brute-force search for a suitable modifier, and then use this modifier to execute the CGA generation function. An attacker who is willing to spoof the mobile node's home address, so-called "IP address stealing" [5], then has two options: It could either generate its own public/private-key pair and perform a brute-force search for a modifier which, in combination with the generated public key, suffices the initially described two properties; or it could integer-factor the mobile node's public key, deduce the corresponding private key, and copy the mobile node's modifier without a brute-force search. The cost of the attack can be determined by the mobile node in either case: Integer-factoring a public key becomes increasingly complex as the length of the public key grows, and the key length is at the discretion of the mobile node. The cost of a brute-force search for a suitable modifier increases with the number of leading zeroes that the result of the hash extension function is required to have. This number, too, is a parameter that the mobile node can choose. Downgrading attacks, where the attacker reduces the cost of spoofing a cryptographically generated home address by choosing a set of CGA parameters that are less secure than the CGA parameters the mobile node has used to generate the home address, are hence impossible.
実際には、暗号的にホームアドレスを生成するための合法的なモバイルノードのために、モバイルノードは、最初に、適切な修飾のための力まかせ探索を達成した後、CGA生成機能を実行するために、この修飾子を使用する必要があります。モバイルノードのホームアドレスを偽装するために喜んで攻撃、「IPアドレスを盗む」いわゆる[5]、2つのオプションがあります。それは、自身の公開鍵/秘密鍵のペアを生成し、用力まかせ探索を行うことができどちらか生成された公開鍵と組み合わせて、最初に説明した2つの特性が十分で、改質剤;またはそれは、モバイルノードの公開鍵を-係数を整数に対応する秘密鍵を推測し、力まかせ探索することなく、モバイルノードの修正をコピーすることもできます。攻撃のコストは、いずれの場合にも、移動ノードによって決定することができる公開鍵の長さが成長し、キーの長さは、移動ノードの裁量であるとして整数、ファクタリング公開鍵は、ますます複雑になります。ハッシュ拡張機能の結果を有することが要求される先行ゼロの数の適切な修飾増大用力まかせ探索のコスト。この数は、あまりにも、モバイルノードが選択できるパラメータです。攻撃者はCGAは、モバイルノードがホームアドレスを生成するために使用しているパラメータよりもより安全であるCGAパラメータのセットを選択することにより、暗号生成されたホームアドレスをスプーフィングのコストを削減攻撃を、ダウングレード、それゆえに不可能です。
The CGA specification [2] requires the use of RSA public and private keys, and it stipulates a minimum key length of 384 bits. This requirement that was tailored to Secure Neighbor Discovery for IPv6 [13], the original CGA application. Enhanced Route Optimization does not increase the minimum key length because, in the absence of downgrading attacks as explained before, the ability to use short keys does not compromise the security of home addresses that were cryptographically generated using longer keys. Moreover, extensions to [2] may eventually permit the use of public/private-key classes other than RSA. Such extensions are compatible with the CGA application of Enhanced Route Optimization. Care must be taken in selecting an appropriate key class and length, however. Home addresses are typically rather stable in nature, so the chosen parameters must be secure for a potentially long home address lifetime. Where RSA keys are used, a minimum key length of 1024 bits is therefore RECOMMENDED.
CGA仕様[2] RSA公開鍵と秘密鍵の使用を必要とし、それは384ビットの最小の鍵長を規定します。 IPv6の近隣探索[13]、オリジナルCGAアプリケーションを保護するように調整した。この要件。前述したように強化されたルート最適化は、ダウングレード攻撃が存在しない場合に、暗号的に長いキーを使用して生成されたホームアドレスのセキュリティを損なわない短いキーを使用する能力を理由最小キー長を増加させません。また、[2]最終的にRSA以外の公開/秘密鍵のクラスの使用を許可することができるの拡張機能。このような拡張は、強化されたルート最適化のCGAアプリケーションと互換性があります。ケアは、しかし、適切なキークラスと長さの選択に注意する必要があります。ホームアドレスは、一般的に自然の中でかなり安定しているので、選択されたパラメータは、潜在的に長いホームアドレス寿命のために安全でなければなりません。 RSAキーが使用される場合、1024ビットの最小の鍵長は、したがって、推奨されます。
While the CGA generation function cryptographically ties the interface identifier of a home address to the subnet prefix of the home address, the function accepts any subnet prefix and hence does not prevent a node from cryptographically generating a home address with a spoofed subnet prefix. As a consequence, the CGA property of a home address does not guarantee the owner's reachability at the home address. This could be misused for a "return-to-home flooding attack" [5], where the attacker uses its own public key to cryptographically generate a home address with a subnet prefix from a victim network, requests a correspondent node to bind this to the attacker's current care-of address, initiates the download of a large file via the care-of address, and finally deregisters the binding or lets it expire. The correspondent node would then redirect the packets being downloaded to the victim network identified by the subnet prefix of the attacker's spoofed home address. The protocol defined in this document performs a reachability test for the home address at the time the home address is first registered with the correspondent node. This precludes return-to-home flooding.
CGA生成機能は、暗号ホームアドレスのサブネット・プレフィックスへのホームアドレスのインタフェース識別子を結び付けながら、機能は、任意のサブネットプレフィックスを受け取り、したがって暗号スプーフィングされたサブネットプレフィックスとホームアドレスを生成するからノードを妨げません。その結果、ホームアドレスのCGAの特性は、自宅の住所で所有者の到達可能性を保証するものではありません。これは、[5]、攻撃者は、暗号被害者のネットワークからサブネットプレフィックスを持つホームアドレスを生成するために、独自の公開鍵を使用する場合、これをバインドするために、通信相手ノードを要求し、「リターンツーホームフラッディング攻撃」のために悪用される可能性が攻撃者の現在の気付アドレスは、気付アドレス経由で大きなファイルのダウンロードを開始し、最終的には結合の登録を解除するか、それが期限切れにすることができます。コレスポンデントノードは、攻撃者の偽装されたホームアドレスのサブネットプレフィックスで識別される被害者のネットワークにダウンロードされたパケットをリダイレクトします。この文書で定義されたプロトコルは、ホームアドレスが最初のコレスポンデント・ノードに登録された時点で、ホームアドレスの到達可能性テストを実行します。これはリターンツーホームフラッディングを排除します。
The verification of the CGA property of a mobile node's home address involves asymmetric public-key cryptography, which is relatively complex compared to symmetric cryptography. Enhanced Route Optimization mitigates this disadvantage through the use of symmetric cryptography after an initial public-key-based verification of the mobile node's home address has been performed. Specifically, the correspondent node assigns the mobile node a permanent home keygen token during the initial correspondent registration based on which the mobile node can authenticate to the correspondent node during subsequent correspondent registrations. Such authentication enables the correspondent node to bind a subsequent correspondent registration back to the initial public-key-based verification of the mobile node's home address. The permanent home keygen token is never sent in plain text; it is encrypted with the mobile node's public key when initially assigned, and irreversibly hashed during subsequent correspondent registrations.
モバイルノードのホームアドレスのCGAの特性の検証は、対称暗号化に比べて比較的複雑で非対称公開鍵暗号方式を伴います。モバイルノードのホームアドレスの最初の公開鍵ベースの検証が行われた後に強化されたルートの最適化は、対称暗号化を使用してこの欠点を軽減します。具体的には、コレスポンデントノードは、モバイルノードにモバイルノードが、その後の通信員登録の際に、通信相手ノードに認証できるかに基づいて、最初の通信員登録時に永久的な家のkeygenトークンを割り当てます。このような認証は、バックモバイルノードのホームアドレスの最初の公開鍵ベースの検証後に通信員登録をバインドするために、通信相手ノードを可能にします。永久的な家のkeygenトークンは、プレーンテキストで送信されることはありません。最初に割り当てられたとき、移動ノードの公開鍵で暗号化し、不可逆的にその後の通信員登録の際にハッシュされます。
A secure proof of home address ownership can mitigate the threat of IP address stealing, but an attacker may still bind a correct home address to a false care-of address and thereby trick a correspondent node into redirecting packets, which would otherwise be delivered to the attacker itself, to a third party. Neglecting to verify a mobile node's reachability at its claimed care-of address could therefore cause one or multiple correspondent nodes to unknowingly contribute to a redirection-based flooding attack against a victim chosen by the attacker.
ホームアドレスの所有権の安全な証拠は、IPアドレスの盗難の脅威を軽減することができますが、攻撃者は、そうでない場合に配信されるであろう、まだ偽気付アドレスに正しいホームアドレスを結合し、それにより、パケットをリダイレクトに対応するノードをだますこと第三者に、自分自身を攻撃者。その主張気付アドレスにモバイルノードの到達可能性を検証するために無視することはしたがって、一つまたは複数の通信相手ノードは、無意識のうちに、攻撃者によって選ばれた被害者に対するリダイレクションベースのフラッディング攻撃に貢献する可能性があります。
Redirection-based flooding attacks may target a single node, a link, or a router or other critical network device upstream of an entire network. Accordingly, the attacker's spoofed care-of address may be the IP address of a node, a random IP address from a subnet prefix of a particular link, or the IP address of a router or other network device. An attack against a network potentially impacts a larger number of nodes than an attack against a specific node, although neighbors of a victim node on a broadcast link typically suffer the same damage as the victim itself.
リダイレクションベースのフラッディング攻撃は、単一のノード、リンク、またはネットワーク全体のアップストリームルータまたは他の重要なネットワークデバイスをターゲットにすることができます。したがって、攻撃者の偽装された気付アドレスはノードのIPアドレス、特定のリンクのサブネットプレフィックス、またはルータなどのネットワーク機器のIPアドレスからのランダムなIPアドレスであってもよいです。ネットワークに対する攻撃の潜在的に影響を与える特定のノードに対する攻撃よりもノードの大きい数、放送リンク上の犠牲者ノードの近隣は、典型的には、犠牲者自体と同じダメージを受けません。
Requiring mobile nodes to cryptographically generate care-of addresses in the same way as they generate home addresses would mitigate the threat of redirection-based flooding only marginally. While it would prevent an attacker from registering as its care-of address the IP address of a specific victim node, the attacker could still generate a different CGA-based care-of address with the same subnet prefix as that of the victim's IP address. Flooding packets redirected towards this care-of address would then not have to be received and processed by any specific node, but they would impact an entire link or network and thus cause comparable damage. CGA-based care-of addresses therefore have little effectiveness with respect to flooding protection. On the other hand, they would require a computationally expensive, public-key-based ownership proof whenever the care-of address changes. For these reasons, Enhanced Route Optimization uses regular IPv6 care-of addresses.
暗号的にモバイルノードを必要とする彼らはホームアドレスを生成するのと同じ方法で、気付アドレスを生成することはわずかにリダイレクトベースの洪水の脅威を緩和するでしょう。それはその気付アドレスのような特定の犠牲者ノードのIPアドレスを登録から攻撃を防ぐためだろうが、攻撃者はまだ被害者のIPアドレスと同じサブネットのプレフィックスと異なるCGAベースの気付アドレスを生成することができます。この気付アドレスに向けてリダイレクトフラッディングパケットは、任意の特定のノードが受信して処理する必要がないだろうが、彼らは全体のリンクやネットワークに影響を与えるため、同程度の損傷を引き起こします。 CGAベースの気付アドレスは、したがって、洪水の保護に関してはほとんど効果があります。一方、彼らは計算コスト、公開鍵ベースの所有権を証明するたびに気付アドレスの変更が必要となります。これらの理由から、拡張ルート最適化は、通常のIPv6気付アドレスを使用しています。
A common misconception is that a strong proof of home address ownership would mitigate the threat of redirection-based flooding and consequently eliminate the need to verify a mobile node's reachability at a new care-of address. This notion may originate from the specification of a base Mobile IPv6 home registration in [1], which calls for the authentication of a mobile node based on an IPsec security association, but does not require this to be supplemented by a verification of the mobile node's reachability at the care-of address. However, the reason not to mandate reachability verification for a home registration is in this case the existence of an administrative relationship between the home agent and the mobile node, rather than the fact that the home agent can securely verify the mobile node's home address ownership, or that the home registration is IPsec-protected. The administrative relationship with the mobile node allows the home agent, first, to trust in the correctness of a mobile node's care-of address and, second, to quickly identify the mobile node should it still start behaving maliciously, for example, due to infection by malware. Section 15.3 in [1] and Section 1.3.2 in [5] explain these prerequisites.
よくある誤解は、ホームアドレス所有権の強力な証拠がリダイレクトベースの洪水の脅威を軽減し、その結果、新たな気付アドレスにモバイルノードの到達可能性を検証する必要性を排除するだろうということです。この概念は、IPsecセキュリティアソシエーションに基づいて、移動ノードの認証のために呼び出しますが、モバイルノードの検証によって補完されるように、これを必要としない、[1]にベースモバイルIPv6ホーム登録の仕様に由来し得ます気付けアドレスに到達可能。しかし、ホーム登録のための到達性の検証を強制しない理由は、この場合には、ホームエージェントとモバイルノード間の管理の関係ではなく、ホームエージェントがしっかりとモバイルノードのホームアドレスの所有権を確認することができるという事実の存在です、または自宅の登録がIPsecで保護されていること。それはまだ感染による、例えば、悪意を持って行動を開始すべきであるモバイルノードと行政の関係は急速にモバイルノードを識別するために、第2のモバイルノードのアドレスのケア - と、の正確で信頼するように、まず、ホームエージェントを可能にマルウェアによって。 [5]これらの前提条件を説明する[1]およびセクション1.3.2でセクション15.3。
Assuming trust, an administrative relationship between the mobile node and its home agent is viable, given that the home agent is an integral part of the mobility services that a mobile user typically subscribes to, sets up her- or himself, or receives based on a business relationship. A Mobile IPv6 extension [14] that leverages a shared authentication key, preconfigured on the mobile node and the correspondent node, preassumes the same relationship between the mobile node and a correspondent node. While this assumption limits the applicability of the protocol (Section 2 of [14] acknowledges
信頼を仮定すると、モバイルノードとそのホームエージェント間の管理関係は、HER-または自分自身を設定し、ホームエージェントは、モバイルユーザーが一般的に加入するモビリティサービスの不可欠な部分であることを考えると、実行可能である、またはに基づいて受信しますビジネス関係。モバイルノードとコレスポンデントノードに事前設定共有認証キーを利用モバイルIPv6拡張[14]は、モバイルノードとコレスポンデントノードとの間の同じ関係をpreassumes。この仮定は、プロトコル（の第2の適用性を制限しながら、[14]認めます
this), it permits omission of care-of address reachability verification as in the case of the home registration. Enhanced Router Optimization does not make assumptions on the relationship between mobile and correspondent nodes. This renders the protocol applicable to arbitrary scenarios, but necessitates that correspondent nodes must verify a mobile node's reachability at every new care-of address.
これは）、それはホーム登録の場合と同様に、気付けアドレスの到達可能性検証の省略が可能となります。強化されたルータの最適化は、モバイルと通信員ノード間の関係についての仮定をしていません。これは、任意のシナリオに適用されるプロトコルをレンダリングしますが、コレスポンデントノードは、すべての新しい気付アドレスにモバイルノードの到達可能性を検証しなければならないことを必要とします。
Enhanced Route Optimization enables mobile and correspondent nodes to resume bidirectional communications after a handoff on the mobile-node side before the mobile node's reachability at the new care-of address has been verified by the correspondent node. Such concurrency would in the absence of appropriate protection reintroduce the threat of redirection-based flooding, which reachability verification was originally designed to eliminate: Given that the correspondent node is in general unaware of the round-trip time to the mobile node, and since reachability verification may fail due to packet loss, the correspondent node must accept a sufficiently long concurrency period for reachability verification to complete. An attacker could misuse this to temporarily trick the correspondent node into redirecting packets to the IP address of a victim. The attacker may also successively postpone reachability verification in that it registers with the correspondent node anew, possibly with a different spoofed care-of address, shortly before the correspondent node's maximum permitted concurrency period elapses and the correspondent node switches to waiting for the completion of reachability verification without sending further packets. This behavior cannot necessarily be considered malicious on the correspondent node side since even a legitimate mobile node's reachability may fail to become verified before the mobile node's care-of address changes again. This may be due to high mobility on the mobile node side, or to persistent packet loss on the path between the mobile node and the correspondent node. It is generally non-trivial to decide on the correspondent node side whether the party at the other end behaves legitimately under adverse conditions or maliciously.
強化されたルート最適化は、通信相手ノードによって検証された新しい気付アドレスにモバイルノードの到達可能性の前にモバイル・ノード側のハンドオフ後に双方向通信を再開するために、モバイルと通信員ノードを可能にします。コレスポンデントノードは、モバイルノードへのラウンドトリップ時間の一般的気づかないでいることを考えると、到達可能になったのは：このような並行処理は、適切な保護のない状態で到達可能性検証が元々排除するように設計されたリダイレクトベースの洪水の脅威を再導入う検証がパケット損失に失敗する可能性があり、コレスポンデントノードは、完了するまでに到達可能性検証のための十分に長い同時実行期間を受け入れる必要があります。攻撃者は、一時的に被害者のIPアドレスにパケットをリダイレクトに対応するノードをだますために、これを誤用ことができます。それはおそらく到達可能性の完了を待つまで経過異なるスプーフィングされた気付アドレス、通信相手ノードの最大許容直前に同時実行期間とコレスポンデントノードのスイッチと、新たに通信相手ノードに登録することで、攻撃者はまた、順次到達可能性の検証を延期することができますさらに、パケットを送信せずに検証。でも、正当なモバイルノードの到達可能性が再びモバイルノードの気付アドレスの変更前に検証になるために失敗することがあるので、この動作は、必ずしも相手ノード側の悪質なと考えることはできません。これは、移動ノード側で高い移動度、又はモバイルノードとコレスポンデント・ノードの間の経路上の永続的なパケット損失に起因し得ます。もう一方の端の当事者が悪意を持って不利な条件や下合法的に動作するかどうかを相手ノード側で決定することが一般的に非自明です。
Enhanced Route Optimization eliminates the threat of redirection-based flooding despite concurrent reachability verification through the use of Credit-Based Authorization. Credit-Based Authorization manages the effort that a correspondent node expends in sending payload packets to a care-of address in UNVERIFIED state. This is accomplished based on the following three hypotheses:
強化されたルートの最適化は、クレジットベースの許可を使用して同時到達可能性の検証にもかかわらず、リダイレクトベースの洪水の脅威を排除します。クレジットベース認証は、コレスポンデントノードがUNVERIFIED状態に気付アドレスにペイロードパケットを送信するに費やす労力を管理します。これは、次の3つの仮説に基づいて行われます。
1. A flooding attacker typically seeks to shift the burden of assembling and sending flooding packets to a third party. Bandwidth is an ample resource for many attractive victims, so the effort for sending the high rate of flooding packets required to impair the victim's ability to communicate may exceed the attacker's own capacities.
1.フラッディング攻撃者は、通常、第三者にフラッディングパケットを組み立て、送信の負担をシフトしようとしています。帯域幅は、多くの魅力的な被災者のための十分なリソースなので、攻撃者自身の能力を超える可能性が通信するために、被害者の能力を損なうために必要なフラッディングパケットの高レートを送信するための努力です。
2. The attacker can always flood a victim directly by generating bogus packets itself and sending those to the victim. Such an attack is not amplified, so the attacker must be provisioned enough to generate a packet flood sufficient to bring the victim down.
2.攻撃者は常に偽のパケット自体を生成し、被害者にそれらを送信することにより、直接被害者をあふれさせることができます。攻撃者は被害者をダウンさせるために十分なパケットの洪水を生成するのに十分なプロビジョニングされなければならないので、このような攻撃は、増幅されません。
3. Consequently, the additional effort required to set up and coordinate a redirection-based flooding attack pays off for the attacker only if the correspondent node can be tricked into contributing to and amplifying the attack.
3.これにより、セットアップ及びリダイレクションベースのフラッディング攻撃を調整するために必要な追加の努力は、コレスポンデント・ノードは、に貢献し、攻撃を増幅だまさすることができる場合にのみ、攻撃者報わ。
Non-amplified redirection-based flooding is hence, from an attacker's perspective, no more attractive than pure direct flooding, where the attacker itself sends bogus packets to the victim. It is actually less attractive given that the attacker needs to maintain a context for mobility management in order to coordinate the redirection. On this basis, Credit-Based Authorization extinguishes the motivation for redirection-based flooding by preventing the amplification that could be reached through it, rather than eliminating malicious packet redirection in the first place. The ability to send unrequested packets is an inherent property of packet-oriented networks, and direct flooding is a threat that results from this. Since direct flooding exists with and without mobility support, it constitutes a reasonable measure in comparing the security provided by Enhanced Route Optimization to the security of the non-mobile Internet. Through the use of Credit-Based Authorization, Enhanced Route Optimization satisfies the objective to provide a security level comparable to that of the non-mobile Internet.
非増幅リダイレクションベースの氾濫は、攻撃者の視点から、したがって、攻撃者自身が被害者に偽のパケットを送信し、純粋なダイレクト氾濫、以下より魅力的ではありません。これは、攻撃者がリダイレクトを調整するために、移動性管理のためのコンテキストを維持する必要があることを考えると、実際にあまり魅力的です。これに基づき、クレジットベースの認証ではなく、最初の場所で悪意のあるパケットリダイレクションを排除するよりも、それを介して到達できる増幅を防止することにより、リダイレクションベースの氾濫のためのモチベーションを消灯します。非要求パケットを送信する機能は、パケット指向のネットワークの固有の財産となり、直接洪水が、この結果から脅威です。ダイレクトフラッディングがでとモビリティのサポートなしで存在するので、それは非モバイルインターネットのセキュリティに強化されたルートの最適化によって提供されるセキュリティを比較して、合理的な措置を構成しています。クレジットベースの認証を使用することにより、強化されたルート最適化は、非モバイルインターネットのそれに匹敵するセキュリティレベルを提供することを目的とする満たします。
Since the perpetrator of a redirection-based flooding attack would take on the role of a mobile node, Credit-Based Authorization must be enforced on the correspondent node side. The correspondent node continuously monitors the effort that the mobile node spends in communicating with the correspondent node. The mobile node's effort is then taken as a limit on the effort that the correspondent node may spend in sending payload packets when the mobile node's care-of address is in UNVERIFIED state. The permission for the correspondent node to send a limited amount of payload packets to a care-of address in UNVERIFIED state enables immediate resumption of bidirectional communications once the mobile node has registered a new IP address with the correspondent node after a handoff.
リダイレクションベースのフラッディング攻撃の加害者は、モバイルノードの役割を担うであろうから、クレジットベース認証は、通信相手ノード側に施行されなければなりません。コレスポンデント・ノードは、連続的に、モバイルノードは、コレスポンデントノードとの通信に費やす労力を監視します。モバイルノードの努力は、コレスポンデントノードは、モバイルノードの気付アドレスがUNVERIFIED状態にあるとき、ペイロードパケットを送信して過ごすことが努力の上限としました。モバイルノードがハンドオフ後に対応するノードとの新しいIPアドレスを登録した後に気付アドレスUNVERIFIED状態でのペイロードパケットの限られた量を送信するために、通信相手ノードの許可は、双方向通信の即時再開を可能にします。
If what appears to be a mobile node is in fact an attacker who tricks the correspondent node into redirecting payload packets to the IP address of a victim, Credit-Based Authorization ensures that the stream of flooding packets ceases before the effort that the correspondent node spends on generating the stream exceeds the effort that the attacker has recently spent itself. The flooding attack is therefore at most as effective as a direct flooding attack, and consequently fails to produce any amplification.
何が誰被害者のIPアドレスにペイロードパケットをリダイレクトするにトリックコレスポンデントノードを攻撃者が実際には、移動ノードであるように思われる場合は、クレジット・ベースの許可は、フラッディングパケットのストリームは、通信相手ノードが費やす労力の前に止まることを保証しますストリームを生成するには、攻撃者が最近、自分自身を費やしてきた努力を超えています。フラッディング攻撃は、したがって、ダイレクトフラッディング攻撃などで最もとして有効であり、その結果、任意の増幅を生成するために失敗しました。
Another property of Credit-Based Authorization is that it does not assign a mobile node credit while its care-of addresses is in UNVERIFIED state. This deserves justification since it would technically be feasible to assign credit independent of the state of the mobile node's care-of address. However, the assignment of credit for packets received from a care-of address in UNVERIFIED state would introduce a vulnerability to sustained reflection attacks. Specifically, an attacker could cause a correspondent node to redirect packets for the attacker to the IP address of a victim, and sustain the packet flow towards the victim in that it continuously replenishes its credit by sending packets to the correspondent node. Although such a redirection-based reflection attack would fail to produce any amplification, it may still be appealing to an attacker who wishes to pursue an initial transport protocol handshake with the correspondent node -- which typically requires the attacker to receive some unguessable data -- and redirect the download to the victim's IP address afterwards. Credit-Based Authorization ensures that the attacker in this case cannot acquire additional credit once the download has been redirected, and thereby forces the attack to end quickly.
クレジットベースの認証のもう一つの特性は、その気付アドレスがUNVERIFIED状態にある間、それはモバイルノードのクレジットを割り当てていないということです。技術的には、移動ノードの気付アドレスの状態の信用の独立を割り当てることが可能になるので、これは正当に値します。しかし、気付アドレスUNVERIFIED状態にあるから受信したパケットのための信用の割り当ては、持続的な反射攻撃に対する脆弱性を導入します。具体的には、攻撃者は被害者のIPアドレスへの攻撃のパケットをリダイレクトし、それが継続的に対応するノードにパケットを送信することによって、そのクレジットを補充することで、被害者へのパケットの流れを維持するために、通信相手ノードを引き起こす可能性があります。典型的には、いくつかの推測できないデータを受信するために、攻撃者を必要とする - そのようなリダイレクションベース反射攻撃は、任意の増幅を生じることができないだろうが、それでも、コレスポンデントノードとの初期トランスポートプロトコルハンドシェイクを追求することを望む攻撃者にアピールすることができます - そしてその後、被害者のIPアドレスへのダウンロードをリダイレクトします。クレジットベースの認証は、この場合、攻撃者は、ダウンロードがリダイレクトされた後、追加のクレジットを取得し、速やかに終了し、攻撃を強制することはできませんことを保証します。
Base Mobile IPv6 limits the lifetime of a correspondent registration to 7 minutes and so arranges that a mobile node's reachability at its home and care-of addresses is reverified periodically. This ensures that the return routability procedure's vulnerability to eavesdropping cannot be exploited by an attacker that is only temporarily on the path between the correspondent node and the spoofed home or care-of address. Such "time shifting attacks" [5] could otherwise be misused for off-path IP address stealing, return-to-home flooding, or flooding against care-of addresses.
ベースのモバイルIPv6は7分に通信員登録の有効期間を制限し、とてもそのホームと気付アドレスでモバイルノードの到達可能性を定期的に再検証されていることを並べます。これは盗聴へのリターンルータビリティ処理の脆弱性は、通信相手ノードと、偽装された家の間のパスにのみ、一時的であるか、気付けアドレス、攻撃者によって悪用されないことを保証します。 [5]それ以外の場合は、オフパスIPアドレス盗むために悪用される可能性があり、このような「タイムシフト攻撃」、気付アドレスに対するリターンツーホーム洪水、または洪水。
Enhanced Route Optimization repeats neither the initial home address test nor any care-of address test in order to decrease handoff delays and signaling overhead. This does not limit the protocol's robustness to IP address stealing attacks because the required CGA-based ownership proof for home addresses already eliminates such attacks. Reachability verification does not add further protection in this regard. On the other hand, the restriction to an initial reachability verification facilitates time-shifted, off-path flooding attacks -- either against home addresses with incorrect prefixes or against spoofed care-of addresses -- if the perpetrator can interpose in the exchange before it moves to a different location.
強化されたルートの最適化は、初期のホームアドレステストやハンドオフ遅延およびシグナリングオーバーヘッドを減少させるために、任意の気付アドレスのテストでもないが繰り返されます。ホームアドレスのために必要なCGAベースの所有権の証明が、すでにこのような攻撃を排除ので、これは攻撃を盗むIPアドレスにプロトコルの堅牢性を制限するものではありません。到達可能性の検証は、この点で、さらに保護を追加しません。加害者は、その前に交換で挟み込むことができるかどうか - 間違った接頭辞を持つホームアドレスに対して、または偽装された気付アドレスに対して、どちらか - 一方、最初の到達可能性検証の制限は、タイムシフト、オフパスフラッディング攻撃を容易に別の場所に移動します。
The design choice against repeated home and care-of address tests was made based on the observation that time shifting attacks are already an existing threat in the non-mobile Internet of today. Specifically, an attacker can temporarily move onto the path between a victim and a correspondent node, request a stream of packets from the correspondent node on behalf of the victim, and then move to a different location. Most transport protocols do not verify an initiator's reachability at the claimed IP address after an initial verification during connection establishment. It enables an attacker to participate only in connection establishment and then move to an off-path position, from where it can spoof acknowledgments to feign continued presence at the victim's IP address. The threat of time shifting hence already applies to the non-mobile Internet.
自宅繰り返し、気付アドレスのテストに対する設計上の選択は、その時のシフト攻撃はすでに今日の非モバイルインターネットの既存の脅威であるという観察に基づいてなされたものです。具体的には、攻撃者が一時的に、被害者と通信相手ノードとの間の経路上に移動する被害者に代わって相手ノードからのパケットのストリームを要求し、その後、別の場所に移動することができます。ほとんどのトランスポートプロトコルは、接続の確立中に初期検証後に主張IPアドレスでイニシエータの到達可能性を検証しません。それだけで、接続の確立に参加し、それが被害者のIPアドレスでの継続的な存在を装うために確認応答を偽装することができ、そこから、オフパスの位置に移動する攻撃を可能にします。したがって、タイムシフトの脅威は、すでに非モバイルインターネットに適用されます。
It should still be acknowledged that the time at which Enhanced Route Optimization verifies a mobile node's reachability at a home or care-of address may well antecede the establishment of any transport layer connection. This gives an attacker more time to move away from the path between the correspondent node and the victim and so makes a time shifting attack more practicable. If the lack of periodic reachability verification is considered too risky, a correspondent node may enforce reruns of home or care-of address tests by limiting the registration lifetime, or by sending Binding Refresh Request messages to a mobile node.
まだよく任意のトランスポート層接続の確立をantecedeてルート最適化を強化した時刻が自宅でモバイルノードの到達可能性を検証したことを認めまたは気付アドレスされなければなりません。これは、攻撃者に対応するノードと被害者との間のパスから離れて移動するより多くの時間を与え、その時間より実用的な攻撃をシフトします。定期的な到達可能性検証の欠如は危険すぎると考えている場合は、コレスポンデント・ノードは、登録の有効期間を、制限することにより、またはモバイルノードに結合更新要求メッセージを送信することにより、家庭や気付アドレステストの再放送を強制することがあります。
The protocol specified in this document relies on 16-bit base Mobile IPv6 sequence numbers and periodic rekeying to avoid replay attacks. Rekeying allows mobile and correspondent nodes to reuse sequence numbers without exposing themselves to replay attacks. It must be pursued at least once every 24 hours due to the maximum permitted binding lifetime for correspondent registrations. Mobile and correspondent nodes also rekey whenever a rollover in sequence number space becomes imminent. This is unlikely to happen frequently, however, given that available sequence numbers are sufficient for up to 32768 correspondent registrations, each consisting of an early and a complete Binding Update message. The sequence number space thus permits an average rate of 22 correspondent registrations per minute without exposing a need to rekey throughout the 24-hour binding lifetime.
この文書で指定されたプロトコルは、リプレイ攻撃を避けるために、16ビットベースのモバイルIPv6のシーケンス番号と定期的な再入力に依存しています。鍵の再生成は、モバイルと通信員ノードが攻撃を再生するために自分自身をさらすことなく、シーケンス番号を再利用することができます。これは、通信員登録のために生涯を結合許さによる最大限に少なくとも一度は24時間毎に追求しなければなりません。シーケンス番号空間のロールオーバーが切迫になるたびモバイルと通信員ノードもリキー。これが頻繁に起こることはほとんどありません、しかし、それぞれが早期かつ完全なBinding Updateメッセージからなる、可能なシーケンス番号が最大で32768件の通信員登録のために十分であることを与えられました。シーケンス番号空間は、このように24時間結合寿命を通してリキーする必要性をさらすことなく、毎分22件の通信員登録の平均速度を可能にします。
While a CGA-based home address ownership proof provides protection against unauthenticated Binding Update messages, it can expose a correspondent node to denial-of-service attacks since it requires computationally expensive public-key cryptography. Enhanced Route Optimization limits the use of public-key cryptography to only the first correspondent registration and if/when rekeying is needed. It is RECOMMENDED that correspondent nodes in addition track the amount of processing resources they spend on CGA-based home address ownership verification, and that they reject new correspondent registrations that involve public-key cryptography when these resources exceed a predefined limit. [2] discusses the feasibility of CGA-based resource exhaustion attacks in depth.
CGAベースのホームアドレス所有権の証明が認証されていないバインディング更新メッセージに対する保護を提供しますが、それは計算コストが高く、公開鍵暗号方式を必要とするので、それは、サービス拒否攻撃に対応するノードを公開することができます。強化されたルート最適化は最初の通信員登録すると、再入力が必要な場合/場合は、公開鍵暗号の使用を制限します。ほかに通信員ノードは、彼らがCGAベースのホームアドレスの所有権の確認に費やす処理リソースの量を追跡することが推奨され、そして、彼らは、これらのリソースは、事前に定義された制限を超えたときに、公開鍵暗号を伴う新しい通信員登録を拒否すること。 [2]深さにおけるCGAベースのリソース消耗攻撃の可能性を論じています。
Enhanced Route Optimization enables mobile nodes to authenticate a received Binding Acknowledgment message based on a CGA property of the correspondent node's IP address, provided that the correspondent node has a CGA. The mobile node requests this authentication by including a CGA Parameters Request option in the Binding Update message that it sends to the correspondent node, and the correspondent node responds by adding its CGA parameters and signature to the Binding Acknowledgment message within CGA Parameters and Signature options. Proving ownership of the correspondent node's IP address protects the mobile node from accepting a spoofed Binding Acknowledgment message and from storing the included permanent home keygen token for use during future correspondent registrations. Such an attack would result in denial of service against the mobile node because it would prevent the mobile node from transacting any binding updates with the obtained permanent home keygen token. Enhanced Route Optimization recommends renewal of a permanent home keygen token in case of persistent correspondent registration failures, allowing mobile nodes to recover from denial-of-service attacks that involve spoofed permanent home keygen tokens.
強化されたルート最適化は、コレスポンデントノードがCGAを有していれば、相手ノードのIPアドレスのCGAの特性に基づいて、受信したBinding Acknowledgementメッセージを認証するために、モバイルノードを可能にします。モバイルノードの要求、それは相手ノードに送信するBinding UpdateメッセージにおけるCGAパラメータ要求のオプション、およびコレスポンデントノードを含むことにより、この認証は、CGAパラメータと署名のオプション内のBinding AcknowledgementメッセージにそのCGAパラメタと署名を追加することによって応答します。相手ノードのIPアドレスの所有権を証明することは偽装されたバインディング受信確認メッセージを受け入れることからして、将来の通信員登録の際に使用するために含まれる永久的な家のkeygenトークンを保存するから、移動ノードを保護します。それが得られ永久的な家のkeygenトークンを使用して任意のバインディングアップデートを取引からモバイルノードを妨げるため、このような攻撃は、モバイルノードに対するサービス拒否につながります。強化されたルート最適化は、モバイルノードは永久的な家のkeygenトークンを偽装されたことを伴うサービス拒否攻撃から回復することができ、持続的な通信員登録障害が発生した場合には永久的な家のkeygenトークンの更新を推奨します。
The threat of the described denial-of-service attack is to some extent mitigated by requirements on the attacker's location: A Binding Update message that requests a correspondent node to provide a permanent home keygen token is authenticated based on the CGA property of the mobile node's home address. This authentication method involves a home address test, providing the mobile node with a home keygen token based on which it can calculate the authenticator of the Binding Update message. Since the mobile node expects the authenticator of the returning Binding Acknowledgment message to be calculated with the same home keygen token, an attacker that is willing to spoof a Binding Acknowledgment message that includes a permanent home keygen token must eavesdrop on the home address test. The attacker must hence be present on the path from the correspondent node to the mobile node's home agent while the home address test proceeds. Moreover, if the Binding Update message requesting the permanent home keygen token is complete, its authenticator is further calculated based on a care-of keygen token. The attacker must then also know this care-of keygen token to generate the authenticator of the Binding Acknowledgment message. This requires the attacker to be on the path from the correspondent node to the mobile node's current IP attachment at the time the correspondent node sends the care-of keygen token to the mobile node within a Care-of Test message or the Care-of Test option of a Binding Acknowledgment message.
説明DoS攻撃の脅威は、攻撃者の場所に要件によって軽減ある程度です：永久的な家のkeygenトークンを提供するために、コレスポンデントノードを要求したバインディング更新メッセージは、移動ノードののCGAの特性に基づいて認証されます自宅の住所。この認証方法は、Binding Updateメッセージのオーセンティケータを計算することができるかに基づいて、ホーム鍵生成トークンとモバイルノードを提供し、ホーム・アドレス・テストを含みます。モバイルノードが同じホーム鍵生成トークンと計算さに戻る結合確認メッセージの認証子を期待しているので、永久ホーム鍵生成トークンを含むバインディング確認メッセージを偽装する意思がある攻撃者は、ホーム・アドレス試験を盗聴しなければなりません。攻撃者は、したがって、ホームアドレステストが進行中、移動ノードのホームエージェントに対応するノードからパス上に存在する必要があります。永久的な家のkeygenトークンを要求するBinding Updateメッセージが完了した場合また、そのオーセンティケータは、さらに気付生成トークンに基づいて計算されます。その後、攻撃者はまた、Binding Acknowledgementメッセージの認証子を生成するには、この気付鍵生成トークンを知っている必要があります。これは、コレスポンデントノードは、内の移動ノードに気付け生成トークンを送信気付テストメッセージまたは気付テスト時に、移動ノードの現在のIP接続に対応するノードからのパス上にあるように、攻撃者が必要ですBinding Acknowledgementメッセージのオプション。
Since a mobile node in general does not know whether a particular correspondent node's IP address is a CGA, the mobile node must be prepared to receive a Binding Acknowledgment message without CGA Parameters and Signature options in response to sending a Binding Update message with an included CGA Parameters Request option. Per se, this mandatory behavior may enable downgrading attacks where the attacker would send, on the correspondent node's behalf, a Binding Acknowledgment message without CGA Parameters and Signature options, claiming that the correspondent node's IP address is not a CGA. Enhanced Route Optimization mitigates this threat in that it calls for mobile nodes to prioritize Binding Acknowledgment messages with valid CGA Parameters and Signature options over Binding Acknowledgment messages without such options. This protects against downgrading attacks unless the attacker can intercept Binding Acknowledgment messages from the correspondent node. Given that the attacker must be on the path from the correspondent node to the mobile node's home agent at roughly the same time as explained above, the attacker may not be able to intercept the correspondent node's
一般的に、モバイルノードは、特定の対応ノードのIPアドレスがCGAであるかどうか知らないので、モバイルノードが含まCGAでBinding Updateメッセージを送信することに応答してCGAパラメータと署名のオプションなしでBinding Acknowledgementメッセージを受け取ることを準備する必要がありますパラメータはオプションを要求します。それ自体は、この必須の行動は、攻撃者が相手ノードのIPアドレスがCGAではないことを主張し、CGAパラメータと署名のオプションを指定せずに、コレスポンデントノードに代わって、Binding Acknowledgementメッセージを送信した攻撃をダウングレード可能にしてもよいです。強化されたルート最適化は、モバイルノードは、そのようなオプションを指定せずに受信確認メッセージをバインディング上で有効なCGAパラメータと署名オプションとバインディング受信確認メッセージの優先順位を決定することが呼び出すことで、この脅威を緩和します。攻撃者は、通信相手ノードからのバインディング受信確認メッセージを傍受することができない限り、これはダウングレード攻撃から保護します。上述したように、攻撃者は、ほぼ同時に、モバイルノードのホーム・エージェントへの対応ノードからのパス上になければならないことを考えると、攻撃者は、通信相手ノードのを傍受することができないかもしれません
Binding Acknowledgment messages. On the other hand, an attacker that can intercept Binding Acknowledgment messages from the correspondent node is anyway in a position where it can pursue denial of service against the mobile node and the correspondent node. This is a threat that already exists in the non-mobile Internet, and it is not specific to Enhanced Route Optimization.
確認メッセージをバインディング。一方、通信相手ノードからバインディング確認メッセージを傍受することができ、攻撃者は、モバイルノードとコレスポンデントノードに対してサービスの拒否を追求することができる位置にとにかくあります。これは、すでに非モバイルインターネットに存在する脅威であり、それは強化されたルート最適化に固有ではありません。
External mechanisms may enable the mobile node to obtain certainty about whether a particular correspondent node's IP address is a CGA. The mobile node may then insist on an IP address ownership proof from the correspondent node, in which case it would discard any received Binding Acknowledgment messages that do not contain valid CGA Parameters and Signature options. One conceivable means for mobile nodes to distinguish between standard IPv6 addresses and CGAs might be an extension to the Domain Name System.
外部メカニズムは、特定の対応ノードのIPアドレスがCGAであるかどうかについて確信を得るために、モバイルノードを可能にすることができます。モバイルノードは、それがいずれかの有効なCGAパラメータと署名のオプションが含まれていない受信確認メッセージを受信したバインディング捨てることになる場合には、通信相手ノードからIPアドレスの所有権の証拠、を主張することがあります。モバイルノードがドメインネームシステムへの拡張であるかもしれない標準のIPv6アドレスとCGAsを区別するために一つの考えを意味します。
[2] defines a CGA Message Type namespace from which CGA applications draw CGA Message Type tags to be used in signature calculations. Enhanced Route Optimization uses the following constant, randomly generated CGA Message Type tag:
[2] CGAアプリケーションが署名の計算に使用されるCGAメッセージタイプのタグを描くそこからCGAメッセージタイプの名前空間を定義します。強化されたルートの最適化は、以下の定数、ランダムに生成されたCGAメッセージタイプのタグを使用しています。
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13
[1] bounds the lifetime for bindings that were established with correspondent nodes by way of the return routability procedure to MAX_RR_BINDING_LIFETIME. Enhanced Route Optimization adopts this limit for bindings that are authenticated through a proof of the mobile node's reachability at the home address. However, the binding lifetime is limited to the more generous constant value of MAX_CGA_BINDING_LIFETIME when the binding is authenticated through the CGA property of the mobile node's home address:
[1] MAX_RR_BINDING_LIFETIMEへリターン・ルータビリティ手順を介してコレスポンデントノードと確立されたバインディングの存続期間の境界。強化されたルートの最適化は、ホームアドレスに移動ノードの到達性の証拠によって認証されているバインディングのこの制限を採用しています。しかし、結合寿命は結合がモバイルノードのホームアドレスのCGAプロパティを介して認証されMAX_CGA_BINDING_LIFETIMEのより寛大な一定の値に制限されています。
MAX_CGA_BINDING_LIFETIME 86400 seconds
MAX_CGA_BINDING_LIFETIME 86400秒
Credit aging incorporates two configuration variables to gradually decrease a mobile node's credit counter over time. It is RECOMMENDED that a correspondent node uses the following values:
クレジット老化は徐々に時間をかけて、移動ノードのクレジットカウンタを減少させるために2つの構成変数が組み込まれています。コレスポンデントノードは、次の値を使用することをお勧めします。
CreditAgingFactor 7/8 CreditAgingInterval 5 seconds
CreditAgingFactor 7/8 CreditAgingInterval 5秒
This document defines the following six new mobility options, which must be assigned type values within the mobility option numbering space of [1]:
この文書では、[1]のスペースをナンバリングモビリティオプション内タイプの値を割り当てる必要があります以下の6つの新しいモビリティオプションを定義します。
o CGA Parameters Request mobility option (11)
O CGAパラメータ要求モビリティオプション（11）
o CGA Parameters mobility option (12)
O CGAパラメータモビリティオプション（12）
o Signature mobility option (13)
O署名モビリティオプション（13）
o Permanent Home Keygen Token mobility option (14)
O永久的な家のkeygenトークンモビリティオプション（14）
o Care-of Test Init mobility option (15)
O気付テスト開始モビリティオプション（15）
o Care-of Test mobility option (16)
O気付テストモビリティオプション（16）
This document allocates the following four new status codes for Binding Acknowledgment messages:
この文書では、受信確認メッセージを結合するために、次の4つの新しいステータスコードを割り当てます。
o "Permanent home keygen token unavailable" (147)
O「永久ホーム鍵生成トークン利用できません」（147）
o "CGA and signature verification failed" (148)
O（148）、 "CGAと署名検証に失敗しました"
o "Permanent home keygen token exists" (149)
O（149） "を永久的な家のkeygenトークンが存在しています"
o "Non-null home nonce index expected" (150)
O「非ヌルホームナンス指数予想」（150）
The values to be assigned for these status codes must all be greater than or equal to 128, indicating that the respective Binding Update message was rejected by the receiving correspondent node.
これらのステータスコードのために割り当てられる値は、すべてそれぞれのBinding Updateメッセージを受信相手ノードによって拒否されたことを示し、128以上でなければなりません。
This document also defines a new 128-bit value under the CGA Message Type namespace [2].
この文書はまた、CGAメッセージタイプ名前空間の下に新しい128ビットの値を定義する[2]。
The authors would like to thank Tuomas Aura, Gabriel Montenegro, Pekka Nikander, Mike Roe, Greg O'Shea, Vesa Torvinen (in alphabetical order) for valuable and interesting discussions around cryptographically generated addresses.
著者は、暗号生成されたアドレスの周りに貴重で興味深い議論をのTuomasオーラ、ガブリエルモンテネグロ、ペッカNikander、マイク・卵、グレッグ・オシェイ、（アルファベット順）のVesa Torvinenに感謝したいと思います。
The authors would also like to thank Marcelo Bagnulo, Roland Bless, Zhen Cao, Samita Chakrabarti, Greg Daley, Vijay Devarapalli, Mark Doll, Lakshminath Dondeti, Francis Dupont, Lars Eggert, Eric Gray, Manhee Jo, James Kempf, Suresh Krishnan, Tobias Kuefner, Lila Madour, Vidya Narayanan, Mohan Parthasarathy, Alice Qinxia, and Behcet
著者らはまた、ローランドは祝福、ジェン曹操、Samita Chakrabarti、グレッグ・デイリー、ビジェイDevarapalli、マーク・人形、Lakshminath Dondeti、フランシスデュポン、ラースEggertの、エリックグレー、Manheeジョー、ジェームズ・ケンプ、スレシュクリシュナン、トビアスをマルセロBagnuloに感謝したいと思いますKuefner、リラMadour、Vidyaナラヤナン、モハンパルタサラティ、アリスQinxia、およびベーチェット
Sarikaya (in alphabetical order) for their reviews of and important comments on this document and the predecessors of this document.
（アルファベット順）Sarikayaこのドキュメントに関するコメントや、このドキュメントの前任者の重要な彼らのレビューのために。
Finally, the authors would also like to emphasize that [15] pioneered the use of cryptographically generated addresses in the context of Mobile IPv6 route optimization, and that this document consists largely of material from [16], [17], and [18] and the contributions of their authors.
最後に、著者らはまた、[15]モバイルIPv6経路最適化の文脈における暗号化生成アドレスの使用を開拓することを強調したい、この文書は、[16]、[17]から大きく材料からなり、その[18]そして、その作者の貢献。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、2005年3月。
[3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", IETF BCP 14, RFC 2119, March 1997.
[3]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、IETF BCP 14、RFC 2119、1997年3月を。
[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[4]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[5] Nikander、P.、Arkko、J.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、RFC 4225、2005年12月。
[6] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[6]フォークト、C.およびJ. Arkko、 "分類及び分析の拡張のモバイルIPv6ルート最適化を"、RFC 4651、2007年2月。
[7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, IEEE, April 2006.
[7]フォークト、C.とM.人形、「効率的なエンドツーエンドのIPv6におけるモビリティサポート」、IEEE無線通信とネットワーク会議の議事録、IEEE、2006年4月。
[8] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS Defense Mechanisms", ACM SIGCOMM Computer Communication Review, Vol. 34, No. 2, ACM Press, April 2004.
[8] Mirkovic、J.とP. Reiher、 "DDoS攻撃の攻撃やDDoS攻撃防衛の分類学"、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 34、第2号、ACMプレス、2004年4月。
[9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", Work in Progress, May 2004.
[9] Arkko、J.とC.フォークト、「長寿命化を結合するためのクレジットベース認証」、進歩、2004年5月での作業。
[10] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6 (CAM)", ACM SIGCOMM Computer Communication Review, ACM Press, Vol. 31, No. 2, April 2001.
[10]オシェイ、G.およびM.卵、 "MIPv6の（CAM）のためのチャイルドプルーフ認証"、ACM SIGCOMMコンピュータコミュニケーションレビュー、ACMプレス、巻。 31、第2号、2001年4月。
[11] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Revised papers from the International Workshop on Security Protocols, Springer-Verlag, April 2002.
[11] Nikander、P.、「サービス拒否、アドレスの所有権、およびIPv6の世界での早期の認証」、セキュリティプロトコル、シュプリンガー・フェアラーク、2002年4月に国際ワークショップからの改訂論文。
[12] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", Work in Progress, April 2007.
[12] Bagnulo、M.及びJ. Arkko、 "暗号化生成アドレス（CGAs）の複数のハッシュアルゴリズムのサポート"、進歩、2007年4月に働いています。
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[13] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[14]パーキンス、C.、RFC 4449、2006年6月 "静的共有キーを使用してセキュアなモバイルIPv6ルート最適化"。
[15] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[15]卵、M.、オーラ、T.、オシェイ、G.、およびJ. Arkko、 "更新と謝辞結合モバイルIPv6の認証"、進歩、2002年3月に働いています。
[16] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6)", Work Progress, May 2005.
[16] Haddadの、W.、Madour、L.、Arkko、J.、およびF.デュポン、作業の進捗状況、2005年5月 "暗号での適用は、MIPv6の（CGA-OMIPv6）を最適化するためにアドレスを生成しました"。
[17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding Updates for Mobile IPv6", Work in Progress, February 2004.
[17]フォークト、C.、祝福、R.、人形、M.、およびT. Kuefner、 "モバイルIPv6のための事前バインディングアップデート"、進歩、2004年2月に作業。
[18] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Work in Progress, May 2004.
[18]フォークト、C.、Arkko、J.、ブレス、R.、人形、M.、およびT. Kuefner、 "更新をバインディングモバイルIPv6初期ためのクレジット・ベースの許可"、進歩、2004年5月ワーク。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
ヤリArkkoエリクソン研究NomadicLab FI-02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
カールスルーエのテレマティクス大学のクリスチャン・フォークト研究所（TH）、P。ボックス6980 76128カールスルーエドイツ
EMail: chvogt@tm.uka.de
メールアドレス：chvogt@tm.uka.de
Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada
ワッシムハダッドエリクソン研究8400、マウントロイヤルケベックH4P 2N2、カナダのDecarieブルバードタウン
EMail: wassim.haddad@ericsson.com
メールアドレス：wassim.haddad@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。