[要約] RFC 4866は、Mobile IPv6における高度なルート最適化のための仕様であり、モバイルノードの通信パフォーマンスを向上させることを目的としています。このRFCでは、モバイルノードが最適な経路を選択し、通信の遅延やパケットロスを最小限に抑える方法が提案されています。
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
モバイル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）The IETF Trust（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の上のスタックレイヤーでモバイルノードを識別する際に安定した「ホームアドレス」を使用しますが、ペイロードパケットは、モバイルノードの現在のネットワーク添付ファイルにルーティングする「ケアオブアドレス」を介して送信または受信されます。モバイルIPv6は、ペイロードパケットがIPレイヤーを通過すると、ホームとケアのアドレスを交換します。モバイルノードのホームアドレスとケアオブアドレスとの関連は、モバイルノードの「バインディング」と呼ばれます。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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回の往復時間です。リターンルー上の手順のためのホームエージェントと特派員ノード、およびバインディングアップデートメッセージの伝播のために、モバイルノードから特派員ノードまでの1つの時間時間。（ここでの仮定は、返品ルーティング可能性手順の遅延がホームアドレステストによって支配されているということです。）新しいアドレスに送信された最初のペイロードパケットには、特派員ノードからモバイルへの伝播に追加の片道時間が必要です。ノード。モバイルノードは、バインディングアップデートメッセージを発送した直後に送信を再開できます。ただし、特派員ノードから拘束力のある承認メッセージを要求する場合、通常、これが受信されるまで通信が遅れます。
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レイヤーまたはリンクレイヤーの他の遅延に加えています。それらは、インタラクティブおよびリアルタイムのアプリケーションに知覚可能な品質分解を引き起こす可能性があります。長いハンドオフレイテンシが連続した再送信タイムアウトにつながり、スループットが低下する可能性があるため、TCPバルクデータ転送は同様に影響を受けます[7]。したがって、ルート最適化の強化の目的は、ハンドオフレイテンシの削減です。
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]。リダイレクトベースの洪水を引き起こす1つの方法は次のとおりです。攻撃者は、独自の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）や輸送層セキュリティ（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.
完全な特派員登録には、モバイルノードでの6つのメッセージ送信が含まれ、合計約376バイトです[9]。このシグナリングオーバーヘッドは、動きがまれである場合、許容される場合があります。たとえば、30分に1回移動するモバイルノードは、平均1.7ビット/sの信号トラフィックを生成します。ただし、モビリティが高いほど、より大きなオーバーヘッドが発生します。セルサイズ100メートルと120 km/hの速度は、3秒ごとにIP接続性の変化をもたらし、約1,000ビット/秒のシグナリングトラフィックをもたらします。これは、10,000〜30,000ビット/sの典型的なデータレートを持つ高度に圧縮された音声ストリームと比較して重要です。
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]。両方のピアがモバイルであるかどうかは倍増します。このオーバーヘッドは、ノードが通信する場合は無視できる場合がありますが、非アクティブで同じ場所に留まるモバイルノードの問題になる可能性があります。これらのノードは通常、バッテリー電源を節約するためにスタンバイモードに移動することを好みます。また、周期的な軽食は、より効率的に使用できるワイヤレス帯域幅の一部を消費します。これらの観察結果は、特にモバイルノードがしばらく移動しない場合、ベースモバイル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パラメーターを必要とします。強化されたルート最適化は、これらの欠点を軽減し、初期のCGAベースの認証を利用して、モバイルノードと特派員ノードの間の秘密の恒久的なホームキーゲントークンを安全に交換します。恒久的なホーム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接続を変更すると、到達可能性の証明を提供することなく、Crespoldent Nodeでのバインディングを新しいアドレスへのバインディングを最初に更新します。特派員ノードは、暫定的に新しい住所を登録し、それを未検証の状態に設定します。ペイロードパケットは、新しいアドレスを介して双方向に交換できますが、新しい住所でのモバイルノードの到達可能性は同時に検証されます。特派員ノードは、到達可能性の検証が完了すると、アドレスのケアを検証状態に移動します。
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.
強化されたルート最適化は、クレジットベースの承認を使用して、リダイレクトベースの洪水攻撃から保護します。クレジットベースの承認は、リダイレクトベースの洪水攻撃が直接洪水よりも効果的でないことを保証するために、特派員ノードが未検証状態の住所にペイロードパケットを送信する際に費やす努力を管理します。レイクエストされていないパケットを送信する機能は、パケット指向のネットワークの固有のプロパティであり、直接洪水はこれに起因する脅威です。モビリティサポートの有無にかかわらず、直接洪水が存在し、リダイレクトベースの洪水攻撃はこれよりも効率的ではないため、クレジットベースの承認は、非モバイルインターネットの洪水に関するルート最適化の強化によって提供されるセキュリティレベルを高めます。したがって、強化されたルートの最適化は、非モバイルインターネットのセキュリティレベルに匹敵するセキュリティレベルを提供する目的を満たします。
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.
努力の測定と制限は、「クレジット」の概念を通じて技術的に実現されます。これは、特派員ノードが、特派員ノードとの定期的な通信中にモバイルノードが消費する努力に関連して独自の努力をすることを維持しています。特派員ノードは、検証された状態のモバイルノードの世話から受け取るペイロードパケットのクレジットを増やし、モバイルノードのケアアドレスにペイロードパケットを送信するための独自の努力に比例してクレジットを減らします未検証状態。
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.
強化されたルート最適化により、モバイルノードは、それぞれの住宅登録と並行して特派員登録を追求できます。これにより、ベースのモバイル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.
o IP添付ファイルのあるポイントから別のポイントに移動しながら、特派員ノードで既存のバインディングを更新します。
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 テストのケアオプションを使用してバインディング確認メッセージを受信した後、完全なバインディングアップデートメッセージを使用して、早期のバインディング更新メッセージをフォローアップします。
o To refresh an existing binding at the correspondent node without changing the current point of IP attachment.
o IP添付ファイルの現在のポイントを変更せずに、特派員ノードで既存のバインディングを更新します。
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 特派員ノードに、モバイルノードと特派員ノードの間で共有された既存の恒久的なホームKeygenトークンを更新するように要求します（セクション4.5を参照）。
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:
これらのいずれの場合でも、モバイルノードはクレスターターンノードにバインディングアップデートメッセージを送信します。バインディングアップデートメッセージは、次の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プロパティに基づいてバインディングアップデートメッセージを認証する必要があります。住所。これには、モバイルノードが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.
o モバイルノードのホームアドレスがCGAであり、モバイルノードが特派員ノードのバインディングアップデートリストエントリに恒久的なホームキーゲントークンを持っている場合、モバイルノードは、永久ホームの知識の証明によってバインディングアップデートメッセージを認証する必要がありますkeygenトークン。
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.
o モバイルノードのホームアドレスがCGAではない場合、モバイルノードは、自宅の住所で到達可能性の証明を介してバインディングアップデートメッセージを認証する必要があります。
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.
バインディングアップデートメッセージのライフタイムフィールドでモバイルノードによって要求された寿命は、Max_cga_binding_lifetime（セクション7を参照）を超えてはなりません。恒久的な家のkeygenトークンに関するモバイルノードの知識。選択した認証方法が自宅の住所でのモバイルノードの到達可能性の証明である場合、寿命はmax_rr_binding_lifetimeを超えてはなりません[1]。すべての場合において、モバイルノードが不必要なバインディングリフレッシュを回避し、したがってシグナリングオーバーヘッドを減らすために、最大許可された寿命を要求することをお勧めします。特派員ノードでの既存のバインディングの削除を要求するバインディングアップデートメッセージの生涯フィールドは、ゼロに設定する必要があります。
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パラメーターオプション（セクション5.1を参照）を追加することにより、バインディングアップデートメッセージにCGAパラメーターと署名が含まれています。署名オプション（セクション5.2を参照）。これはセクション4.5で説明されています。恒久的なホーム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パラメーターも含まれています。これは、1つ以上の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:
バインディングアップデートメッセージの認証器は、永続的または一時的なホーム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.
o モバイルノードのホームアドレスのCGAプロパティに基づいてバインディングアップデートメッセージが認証される場合、モバイルノードは、特派員ノードの一時ホームキーゲントークンを使用する必要があります。モバイルノードには、Crespordent Nodeのバインディングアップデートリストエントリに有効な一時的なホームKeyGenトークンが既にある場合があります。または、ホームテストINITメッセージとホームテストメッセージの交換を通じて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.
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.
o バインディングアップデートメッセージが自宅の住所で到達可能性の証明を通じて認証される場合、モバイルノードは、特派員ノードからの一時的なホームKeygenトークンを使用する必要があります。前と同様に、モバイルノードには、特派員ノードのバインディングアップデートリストエントリに有効な一時的なホームキーゲントークンが既にある場合があります。または、ホームテストINITメッセージとホームテストメッセージの交換を通じて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:
バインディングアップデートメッセージの目的が、特派員ノードで既存のバインディングを削除することでない限り、認証器もキーゲントークンのケアに基づいて計算されます。モバイルノードはこれを次のように選択します。
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 モバイルノードに、登録されているアドレスの有効なケアのケアオブアドレスが、特派員ノードのバインディングアップデートリストエントリにある場合、モバイルノードは、バインディングアップデートメッセージの認証器の計算でこれを使用する必要があります。この場合、バインディングアップデートメッセージは「完全」です。
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 モバイルノードに、クレENTENTノードのバインディングアップデートリストエントリに有効なCare-of KeyGenトークンがない場合、モバイルノードはkeygenトークンのケアをゼロに定義し、バインディングアップデートの認証器の計算でこれを使用する必要がありますメッセージ。この場合、バインディングアップデートメッセージは「早期」です。
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 モバイルノードに、クレスターターンノードのバインディングアップデートリストエントリに有効なCare-of Keygenトークンがない場合、モバイルノードは、テストケアの開始メッセージの交換を通じてKeygenトークンのケアを取得することを選択できます。[1]で定義されているように、早期のバインディングアップデートメッセージを送信することなく、テストのケアメッセージ。この場合、モバイルノードはテストのケアメッセージの受信を待っており、完全なバインディングアップデートメッセージの認証器を計算する際に含まれるkeygenトークンのケアを使用します。ただし、このアプローチはハンドオフレイテンシを増加させるため、推奨されません。
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サービスを中止したい場合は、ホームおよび特派員の規制団体を並行して追求する必要があります。ただし、ローミングの期間後にホームリンクに戻った後にモバイルノードが家と特派員の退役団をコミットする場合、モバイルノードは最初にホームの解体を開始する必要があり、それが成功する前に家の解放が成功することを示す拘束力のある承認メッセージを待つ必要があります。特派員の規制団体を開始します。この動作により、ホームエージェントはモバイルノードがホームリンク上にある間にモバイルノードのホームアドレスをプロキシにしないことを保証するため、複製アドレスの検出中にモバイルノードとホームエージェント間の干渉を防ぎます。ホームの規制緩和は、モバイルノードがホームリンクからそれを追求するリンクローカルラウンドトリップ時間のみを消費するため、ハンドオフ遅延の増加に関して、特派員の規制省と並列化されないコストは通常無視できます。
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.
さらに、特派員登録のバインディングアップデートメッセージが、モバイルノードのホームアドレスのCGAプロパティに基づいて、または自宅の住所での到達可能性の証明を通じて認証される場合、モバイルノードはホームテストの開始と自宅の交換を開始する必要があります。対応者ノードから新鮮な家のkeygenトークンを積極的に引き出すために、ハンドオフの前にメッセージをテストします。これにより、ハンドオフの遅延がさらに減少します。ホームテストINITメッセージは、以前にCRORRESPENTENT NODEから取得したホームKeyGenトークンが期限切れになっている場合はいつでも定期的に送信される場合があります。トークンは3.5分間有効であるため[1]、連続したホームテストINITメッセージ間の間隔は少し少ないはずです。あるいは、リンクレイヤーが差し迫ったハンドオフを発表するトリガーを提供する場合、モバイルノードはHome Test Initメッセージを時間内に正しく送信できる場合があります。プロアクティブなホームアドレステストは、ハンドオフ全体で家の住所が変わらないため、技術的に実行可能です。
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.
モバイルノードがホームリンクからホームアドレステストを開始する場合、ホームテストの初期メッセージを特派員ノードに直接対処する必要があります。ホームテストメッセージは、特派員ノードから直接受信されます。訪問されたリンクからホームアドレステストが開始された場合、モバイルノードはホームエージェントにホームテストINITメッセージをトンネルする必要があります。ホームテストメッセージは、ホームエージェントによってモバイルノードに戻ってきます。ホームアドレステストでは、ホームテストの初期化やホームテストメッセージが失われる可能性があるため、家の登録やホーム登録と重複してはなりません。
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 keygen token contained therein in calculating the authenticator for a complete Binding Update message and send this message to the correspondent node.
バインディングアップデートメッセージが早い場合、モバイルノードはメッセージにテストのケアinitオプションを追加する必要があります（セクション5.4を参照）。バインディングアップデートメッセージに存在する場合は、テストのCare-of Test INITオプションは、CGAパラメーターと署名オプションに従う必要があります。テストのケアオプションを使用した応答バインディングの確認メッセージ（セクション5.5を参照）が受信されたら、モバイルノードは、完全なバインディングアップデートメッセージの認証器を計算して、その中に含まれるKeyGenトークンのケアを使用し、このメッセージを送信する必要があります。特派員ノード。
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.
バインディングアップデートメッセージがモバイルノードのホームアドレスのCGAプロパティに基づいて認証されている場合、モバイルノードは、CGAパラメーターリクエストオプション（セクション5.6を参照）をバインディングアップデートメッセージに追加する場合があります。拘束力のある確認メッセージ内のIPアドレス。この所有権の証明により、モバイルノードは、拘束力のある承認メッセージで返された恒久的なホーム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:
モバイルノードには、NONCEインデックスオプション[1]を使用して、バインディングアップデートメッセージの選択されたホームとキーゲントークンに関連付けられたNONCEインデックスが含まれています。それにより、Home Nonce Indexは次のように決定されます。
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.
o モバイルノードのホームアドレスのCGAプロパティに基づいてバインディングアップデートメッセージを認証する場合、モバイルノードは一時的なホームキーゲントークンを使用してバインディングアップデートメッセージの認証器を計算し、関連するホームNonCEインデックスを取得する必要があります。ホームキーゲントークンが取得されたホームテストメッセージが取得されました。
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.
o バインディングアップデートメッセージが、恒久的なホームKeygenトークンに関するモバイルノードの知識の証明によって認証される場合、Home NonCEインデックスはゼロに設定する必要があります。
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.
o バインディングアップデートメッセージが自宅のアドレスでのモバイルノードの到達可能性の証明を通じて認証される場合、モバイルノードは一時的なホームキーゲントークンを使用してバインディングアップデートメッセージの認証器を計算し、関連するホームNonCEインデックスを取得する必要があります。ホームキーゲントークンが取得されたホームテストメッセージから。
The care-of nonce index is determined according to the following rules:
Care-of NonCEインデックスは、次のルールに従って決定されます。
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.
o バインディングアップデートメッセージが完了した場合、Care-of NonCEインデックスは、テストのケアオプションまたはケアオブテストメッセージから取得されます。取得。
o If the Binding Update message is early, the care-of nonce index MUST be set to zero.
o バインディングアップデートメッセージが早い場合、Care-of NonCeインデックスをゼロに設定する必要があります。
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.
o バインディングアップデートメッセージの目的が、特派員ノードでバインディングを削除することである場合、Care-of NonCEインデックスをゼロに設定する必要があります。
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.
nonceインデックスオプションは、バインディングアップデートメッセージにも含まれている場合、CGAパラメーター、署名、ケアオブテストINIT、および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.
モバイルノードは最後に、[1]のセクション5.2およびセクション6.2.7で説明されているルールに従って、選択されたホームとケアのケアに基づいたバインディングアップデートメッセージの認証器を計算します。特派員ノードで既存のバインディングの削除を要求するバインディングアップデートメッセージの場合、認証器はホームKeygenトークンのみに基づいて計算され、Keygenトークンのケアは組み込まれていません。Authenticatorは、拘束力のある認証データオプション[1]のAuthenticatorフィールドに配置されます。これは、モバイルノードが最後のオプションとしてバインディングアップデートメッセージに追加されます。
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 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.
図1から図3の時間シーケンス図は、選択されたいくつかのメッセージ交換に基づいた強化されたルート最適化の操作を示しています。図1は、特派員の登録と交換されたメッセージを示しています。そこでは、恒久的なホームkeygenトークンに関するモバイルノードの知識の証拠によって、早期のバインディングアップデートメッセージが認証されます。初期のバインディングアップデートメッセージのテストのケアイニシ様オプションは、特派員ノードにバインディング謝辞メッセージに追加するように要求します。モバイルノードは最終的に、完全なバインディングアップデートメッセージで特派員の登録を締めくくります。図2は、バインディングアップデートメッセージが自宅の住所での到達可能性の証明で認証される特派員登録の手順を示しています。ホームアドレステストは、ハンドオフの前に積極的に実行され、モバイルノードがハンドオフの直後にバインディングアップデートメッセージを発行することを許可します。バインディングアップデートメッセージは再び早くなり、キーゲンのケアトークンがバインディングの確認メッセージとともにモバイルノードに配信されます。図3は、モバイルノードが最初に、テストのケアの交換とテストのケアメッセージを介して新たなケアのケアを取得する特派員登録を示しています。その後、ホームアドレスのCGAプロパティで認証された完全なバインディングアップデートメッセージを発行します。
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:
特派員ノードがバインディングアップデートメッセージを受信した場合、最初に送信モバイルノードがメッセージで指定されたホームアドレスの正当な所有者であるかどうかを確認する必要があります。特派員ノードは、バインディングアップデートメッセージのNONCEインデックスオプションで指定されたHome NonCEインデックス、およびバインディングアップデートメッセージのCGAパラメーターと署名オプションの存在に基づいて、認証方法を選択します。
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.
o Home NonCEインデックスが非ヌル値に設定されており、バインディングアップデートメッセージに1つ以上のCGAパラメーターオプションが署名オプションが含まれている場合、特派員ノードはモバイルノードのHomeのCGAプロパティに基づいてバインディングアップデートメッセージを認証する必要があります。住所。
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.
o Home NonCe Indexがゼロであり、バインディングアップデートメッセージに1つ以上のCGAパラメーターオプションが署名オプションが続く場合は、特派員ノードが恒久的なホームKeyGenトークンに関するモバイルノードの知識の証明により、バインディングアップデートメッセージを認証する必要があります。。
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.
o Home Nonce Indexが非NULL値に設定されており、バインディングアップデートメッセージに1つ以上のCGAパラメーターオプションが署名オプションが含まれていない場合、特派員ノードはモバイルノードのRechinababilityの証明を介してバインディングアップデートメッセージを認証する必要があります。自宅の住所で。
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.
o バインディングアップデートメッセージに1つ以上のCGAパラメーターオプションが含まれ、その後に署名オプションが含まれ、Home Nonce Indexがゼロになる場合、特派員ノードはステータスコード150（「非ヌルホームNonCe Indexが期待する」）でバインディング確認メッセージを送信する必要があります。これにより、モバイルノードのホームアドレスのCGAプロパティに基づいて認証されるバインディングアップデートメッセージも、自宅のアドレスでモバイルノードの到達可能性の証明を提供する必要があります。
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").
o バインディングアップデートメッセージが、恒久的なホームKeygenトークンに関するモバイルノードの知識の証明によって認証される場合、特派員ノードは、永続的なホームKeygenトークンを含むモバイルノードのバインディングキャッシュエントリがあることを確認する必要があります。特派員ノードにモバイルノードのバインディングキャッシュエントリがない場合、またはモバイルノードの既存のバインディングキャッシュエントリに恒久的なホームキーゲントークンが含まれていない場合、特派員ノードはバインディングを送信してバインディングアップデートメッセージを拒否する必要があります。ステータスコード147を使用した確認メッセージ（「永久ホームKeygenトークンは利用できない」）。
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.
o バインディングアップデートメッセージが自宅のアドレスでのモバイルノードの到達可能性の証明を通じて認証される場合、特派員ノードは、モバイルノードのバインディングキャッシュエントリに永続的なホームキーゲントークンがないことを確認する必要があります。特派員ノードがモバイルノードのバインディングキャッシュエントリに永久ホームKeyGenトークンを持っている場合、ステータスコード149（「永続的なホームKeygenトークンが存在する」）でバインディング確認メッセージを送信することにより、バインディングアップデートメッセージを拒否する必要があります。これにより、攻撃者は認証方法をダウングレードして、正当なモバイルノードのバインディングをハイジャックできません。
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:
バインディングアップデートメッセージの認証器は、永続的または一時的なホームKeygenトークンに基づいて計算されます。クレスコンテントノードが認証装置を検証する際に使用するホームキーゲントークン、およびホームkeygenトークンの取得または再構成のどのように、認証方法に依存するかは次のとおりです。
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.
o バインディングアップデートメッセージがモバイルノードのホームアドレスのCGAプロパティに基づいて認証される場合、特派員ノードは、バインディングのNONCEインデックスオプションの（非ヌル）ホームNONCEインデックスで定義された一時的なホームKeyGenトークンを再計算する必要がありますメッセージを更新すると、メッセージの認証者を検証する際に、この再計算されたトークンを使用する必要があります。
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.
o バインディングアップデートメッセージが、永続的なホームKeygenトークンに関するモバイルノードの知識の証明によって認証される場合、特派員ノードは、認証機の検証におけるモバイルノードのバインディングキャッシュエントリにある永久ホームKeygenトークンを使用する必要がありますバインディングアップデートメッセージの。
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.
o バインディングアップデートメッセージが自宅のアドレスでのモバイルノードの到達可能性を検証することで認証される場合、特派員ノードは、バインディングのNonCEインデックスオプションの（非ヌル）ホームNONCEインデックスで定義された一時的なホームKeyGenトークンを再計算する必要があります。メッセージを更新すると、メッセージの認証者を検証する際に、この再計算されたトークンを使用する必要があります。
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:
バインディングアップデートメッセージの目的が、特派員ノードで既存のバインディングを削除することでない限り、認証器もキーゲントークンのケアに基づいて計算されます。Care-of Keygenトークンは、Cresplentent Nodeが認証器を検証する際に使用することは、バインディングアップデートメッセージが完全か早いかによって異なります。
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.
o バインディングアップデートメッセージのNonCEインデックスオプションのCare-of NonCEインデックスが非NULL値に設定されている場合、バインディングアップデートメッセージは完了します。この場合、特派員ノードは、Care-of NonCEインデックスによって識別されるKeargenトークンを再計算する必要があり、メッセージの認証器を検証する際にこの再計算されたトークンを使用する必要があります。
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.
o バインディングアップデートメッセージのNONCEインデックスオプションのCare-of NonCEインデックスがゼロの場合、バインディングアップデートメッセージは早いです。この場合、バインディングアップデートメッセージの認証器を検証する際に、特派員ノードが使用するKeyGenトークンのケアはゼロです。
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].
特派員ノードは、[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]に記載されているように、障害を示すステータスコードを使用してバインディング確認メッセージを送信する必要がある場合があります。
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.
バインディングアップデートメッセージの認証器の検証が成功すると、特派員ノードはモバイルノードの新しいケアアドレスを登録し、既存のバインディングキャッシュエントリを存在する場合は更新するか、新しいバインディングキャッシュエントリを作成します。バインディングに対して付与される寿命は、バインディングアップデートメッセージの生涯フィールドでモバイルノードによって要求される生涯と、バインディングアップデートメッセージが認証される方法に依存します。バインディングアップデートメッセージが、モバイルノードのホームアドレスのCGAプロパティ、または恒久的なホームキーゲントークンに関するモバイルノードの知識の証明に基づいて認証されている場合、バインディングの寿命はMAX_CGA_BINDING_LIFETIMEの最大値と値に設定する必要があります。バインディングアップデートメッセージの生涯フィールドで指定されています。バインディングアップデートメッセージが自宅の住所でのモバイルノードの到達可能性の証明によって認証されている場合、バインディングの寿命はmax_rr_binding_lifetime [1]の最大値に設定し、バインディングアップデートメッセージの生涯分野で指定された値に設定する必要があります。。特派員ノードは、どちらの場合でも、さらに減少した寿命を与えますが、より高い寿命を受け入れてはなりません。
The state of the new care-of address depends on whether the Binding Update message is complete or early:
新しい住所の状態は、バインディングアップデートメッセージが完全か早いかによって異なります。
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.
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.
o バインディングアップデートメッセージが早い場合、新しいアドレスのケアは未確認の状態に設定されます。次に、特派員ノードは、検証状態に設定されるまで、この住所にパケットを送信するためにセクション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.
バインディングアップデートメッセージに1つまたは複数のCGAパラメーターオプションが含まれている場合、モバイルノードは、新しいノードに、新しいノードを確立するため、またはモバイルノードと特派員の間で共有される既存の恒久的なホームキーゲントークンを更新するために、含まれているCGAパラメーターを受け入れるように要求しています。ノード。この場合、CGAパラメーターオプションが署名オプションが直接続くかどうかを確認し、セクション4.6で説明されている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.
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.
署名オプションに含まれる署名が正しい場合、特派員ノードは、モバイルノードと共有される永続的なホームKeygenトークンを生成し、モバイルノードのバインディングキャッシュエントリに保存します。恒久的なホームkeygenトークンは、セクション4.3で説明されているように、バインディング確認メッセージ内のモバイルノードに送信されます。
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:
有効なバインディングアップデートメッセージを受信すると、特派員ノードはモバイルノードに戻り、次の場合の拘束力のある確認メッセージを返します。
o The Acknowledge flag in the Binding Update message is set.
o バインディングアップデートメッセージの確認フラグが設定されています。
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 バインディングアップデートメッセージには、1つまたは複数のCGAパラメーターオプションが直接署名オプションが続き、後者に含まれる署名が正しいと判断されました。
o The Binding Update message is early and includes a Care-of Test Init option.
o バインディングアップデートメッセージは早い段階で、テストのケアイニシ様オプションが含まれています。
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.
バインディングアップデートメッセージにCGAパラメーター要求オプションがさらに含まれ、特派員ノードのIPアドレスがCGAである場合、特派員ノードには、1つまたは複数のCGAパラメーターオプションを追加して署名が続くことにより、バインディング承認メッセージにCGAパラメーターと署名を含める必要があります。オプション。特派員ノードのCGAパラメーターと署名により、モバイルノードは、拘束力のある承認メッセージで受信した永続的なホームKeyGenトークンが右の特派員ノードによって生成されたことを確認できます。バインディングアップデートメッセージにCGAパラメーター要求オプションが含まれているが、CRORSPROSENTENT NODEのIPアドレスがCGAではない場合、特派員ノードはCGAパラメーター要求オプションを無視し、以下に説明するようにバインディングアップデートメッセージをさらに処理します。
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.
バインディングアップデートメッセージに1つまたは複数のCGAパラメーターオプションが含まれている場合、署名オプションが続く場合、後者に含まれる署名が正しいと判断された場合、特派員ノードは、恒久的なホームキーゲントークンオプション（セクション5.3を参照）を追加する必要があります。バインディング承認メッセージへの新しい恒久的なホームkeygenトークン。また、特派員ノードは、この永続的なホーム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.
バインディングアップデートメッセージにテストのケアイニシ式オプションが含まれている場合、特派員ノードは、Keygenトークンフィールドに擬似ランダム値を持つテストのケアオプションをバインディング承認メッセージに追加する必要があります。テストのケアオプションは、両方のオプションが拘束力のある確認メッセージに存在する場合に備えて、恒久的なホーム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].
[1]のセクション5.2およびセクション6.2.7で説明されているように、最後のオプションとして、拘束力のある承認データオプションを最後のオプションとして追加する必要があります。
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]で指定されたルールに従って、受信した拘束力のある確認メッセージを最初に検証します。これらのルールに基づいて拘束力のある確認メッセージが拒否されない場合、モバイルノードは次の追加手順を実行します。
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.
モバイルノードに、バインディングアップデートメッセージにCGAパラメーター要求オプションが含まれており、バインディング承認メッセージに永続的なホームKeyGenトークンオプションが含まれている場合、モバイルノードは最初のCGAパラメーターと署名オプションを次の方法で処理します。バインディング承認メッセージに、署名オプションが直接続く1つ以上のCGAパラメーターオプションが含まれている場合、モバイルノードは、セクション4.6で説明されているように含まれるCGAパラメーターと署名を確認することにより、特派員ノードのIPアドレスの所有権を確認する必要があります。CGAパラメーターと署名の検証が失敗した場合、モバイルノードは拘束力のある確認メッセージを静かに破棄する必要があります。また、モバイルノードには、メッセージに1つ以上のCGAパラメーターオプションが含まれている場合、署名オプションが直接続かない場合、または拘束力のある確認メッセージに署名オプションが存在する場合にCGAパラメーターオプションがない場合、拘束力のある確認メッセージを静かに破棄する必要があります。
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.
モバイルノードに、バインディングアップデートメッセージにCGAパラメーター要求オプションが含まれていない場合、またはバインディング承認メッセージに恒久的なホームKeyGenトークンオプションが含まれていない場合、モバイルノードは、バインディング確認メッセージに含まれるCGAパラメーターと署名オプションを無視します。Binding UpdateメッセージでCGAパラメータ要求オプションを慎重に使用すると、モバイルノードがCGAのCGAの検証に費やす処理リソースを制御するだけでなく、永続的な検証障害の場合にそのような検証を無効にすることができます。CRORRECTONTENTノード側またはモバイルノード自体で、誤解または古いCGAソフトウェア[12]を使用します。具体的には、モバイルノードが、CGAパラメーターリクエストオプションを使用してバインディングアップデートメッセージを送信することに応じて有効なCGAパラメーターと署名オプションを含む拘束力のある承認メッセージを繰り返し受け付けていない場合、モバイルノードは将来の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パラメーター要求オプションが含まれているが、バインディング承認メッセージにCGAパラメーターまたは署名オプションが含まれていない場合、モバイルノードは、通信版のノードのIPアドレスが単にCGAではないか、またはバインディングの確認メッセージが、モバイルノードから特派員ノードまでのパス上の攻撃者から発生した場合。パスオンパス攻撃者から恒久的なホームKeygenトークンを受け入れることを避けるために、モバイルノードは、そのようなオプションなしで拘束力のある承認メッセージよりも有効なCGAパラメーターと署名オプションを含む拘束力のある確認メッセージを優先する必要があります。この点で従うモバイルノードの可能なアルゴリズムの1つは、最初に受信した拘束力のある承認メッセージを常に受け入れることです。このメッセージに有効なCGAパラメーターまたは署名オプションが含まれていない場合、そのようなオプションを含む別の拘束力のある承認メッセージが後で受信されます。この後続の拘束力のある承認メッセージを支持して、最初の拘束力のある承認を受け入れることに伴う状態の変更を元に戻します。そのようなオプションなしでバインドされたCGAパラメーターとバインディング承認メッセージを介した有効なCGAパラメーターと署名オプションを使用して、拘束力のある承認メッセージに優先順位を与えることにより、モバイルノードはCGAを使用しない、同時にほとんどのパス攻撃者から保護する特派員ノードと通信できます。この戦略は、特派員ノードからバインディングの確認メッセージを傍受できる攻撃者から保護するものではありませんが、そのような攻撃者は、とにかくモバイルノードと特派員ノードの間のモビリティ管理を排除することができます。モバイルノードが有効なCGAパラメーターと署名オプションなしでバインディング承認メッセージを永続的に受け入れた場合、モバイルノードは、同じ特派員ノードの将来のバインディングアップデートメッセージに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.
バインディング承認メッセージに恒久的なホームキーゲントークンオプションが含まれている場合、モバイルノードはこのオプションに含まれている永続的なホームキーゲントークンを抽出し、特派員ノードのバインディングアップデートリストエントリに保存します。将来のバインディングアップデートメッセージは、この永続的なホーム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.
バインディング承認メッセージにテストのケアオプションが含まれている場合、モバイルノードはこのオプションに含まれるケアオブキーゲントークンを抽出し、クレスコンテントノードのバインディングアップデートリストエントリにトークンを保存し、特派員ノードに完全なバインディングを送信しますセクション4.1で定義されているメッセージを更新します。バインディングの承認メッセージには、恒久的なホームKeygenトークンオプションも含まれている場合、モバイルノードのホームアドレスのCGAプロパティに基づいて、完全なバインディングアップデートメッセージは認証されることに注意してください。これは、対応する初期のバインディングアップデートメッセージに使用された認証方法とは無関係です。
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トークンの知識を証明することにより、特定の特派員ノードのバインディングアップデートメッセージを認証しますが、この特派員ノードの登録は永続的に失敗します。自宅の住所のCGAプロパティに基づいて認証されています。このバインディングアップデートメッセージには、モバイルノードのCGAパラメーターと署名が含まれており、特派員ノードに新しい恒久的なホームkeygenトークンを生成し、これをバインディング確認メッセージ内のモバイルノードに送信します。
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および署名検証が失敗した」）を使用してバインディングの確認メッセージを受信している場合、モバイルノードは、自宅での到達可能性の証明を通じて、同じ特派員ノードの将来のバインディングアップデートメッセージを認証する必要があります。住所。これにより、モバイルノードは、通信者ノード側またはモバイルノード自体で、誤ったまたは時代遅れの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.
o モバイルノードのホームアドレスがCGAであり、モバイルノードには、特派員ノードからの恒久的なホームキーゲントークンがまだない場合、恒久的なホーム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.
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パラメーターと、CGAパラメータ要求オプションを使用してバインディングアップデートメッセージを受信したときにモバイルノードのバインディング確認メッセージに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パラメーターデータ構造の形式で送信されます。CGAパラメーターデータ構造は、セクション5.1で説明されているように、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].
ここで「|」連結を示します。「Care-of Address」はモバイルノードのCare of Addressであり、「Corresporent Node IPアドレス」は、IPの上のプロトコルレイヤーに表示される特派員ノードのIPアドレスです。特派員ノードがモバイルである場合、「特派員ノードIPアドレス」とは、特派員ノードのホームアドレスを指します。「MHデータ」は、モビリティヘッダーと最後のCGAパラメーターオプションまでのすべてのオプションを含む、バインディングアップデートまたはバインディングの確認メッセージのコンテンツです。つまり、「MHデータ」は、Mobilityヘッダー自体以外のIPv6ヘッダーとIPv6拡張ヘッダーを除外します。「モビリティデータ」は、[2]のセクション6で「メッセージ」と呼ばれるものを構成します。
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つ以上のCGAパラメーターオプションを含むバインディングアップデートまたはバインディングの確認メッセージを受信するモバイルおよび特派員ノード[1]で説明されているようにメッセージを最初に処理する署名オプションを直接処理します。これには、拘束力のある認証データオプションの認証装置フィールドにおける認証器の検証が含まれます。バインディングの更新または拘束力のある確認メッセージが、誤った認証機または他の理由により拒否された場合、メッセージはさらに処理されません。
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.
それ以外の場合、バインディングアップデートまたはバインディングの確認メッセージの検証が成功した場合、モバイルまたは特派員ノードは、セクション5.1に記載されているメッセージに含まれる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で定義されている署名検証アルゴリズムを実行します。署名検証アルゴリズムは、上記で定義されているように、検証されたCGAを入力し、再組み立てされたCGAパラメーターデータ構造、セクション4.5で定義されているMHデータ、セクション7で定義されている拡張ルート最適化のCGAメッセージタイプタグ、およびおよび署名自体。
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.
特派員ノードは、モバイルノードからCGAパラメーターと署名オプションを含むバインディングアップデートメッセージを受信した後、モバイルノードに新しい永続的なホームKeyGenトークンを割り当て、これらのオプションはセクション4.6で説明されているように正常に検証されています。恒久的なホームキーゲントークンは、特派員ノードによってランダムに生成された64ビット値です。特派員ノードは、モバイルノード用に維持されているバインディングキャッシュエントリに恒久的なホームキーゲントークンを保存します。
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 binding Home keygenトークンを拘束力のある承認メッセージで、永続的なホームKeygenトークンオプション内で暗号化された形式でモバイルノードに送信します。対応するバインディングアップデートメッセージの確認フラグが明確であったとしても、このメッセージが送信されます。特派員ノードは、RSAES-PKCS1-V1_5フォーマット[4]を使用して、モバイルノードの公開キーを使用して、永久ホームKeygenトークンをモバイルノードの公開キーで暗号化し、ciphertextを恒久的なホームKeygenトークンフィールドに配置します。
The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment message. That is, the authenticator in the 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]で説明されているようにメッセージを処理します。これは、メッセージに恒久的なHome KeyGenトークンオプションが含まれているかどうかとは無関係です。これには、拘束力のある認証データオプションの認証装置フィールドにおける認証器の検証が含まれます。誤った認証機またはその他の理由により、拘束力のある確認メッセージが拒否された場合、モバイルノードはメッセージをさらに処理しません。
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.
それ以外の場合、モバイルノードがバインディングの確認メッセージを受け入れ、メッセージに永続的なホームキーゲントークンオプションが含まれている場合、モバイルノードはこのオプションの恒久的なホームキーゲントークンフィールドから暗号文を抽出し、RSAES-PKCS1を使用してその秘密鍵でそれを抽出します-v1_5形式[4]。暗号化の結果は、特派員ノードとのさらなる登録で使用される永続的なホームKeygenトークンです。モバイルノードは、Crespordent Nodeのために維持されているバインディングアップデートリストエントリに永久ホーム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トークンを特派員ノードと共有するモバイルノードは、リプレイ攻撃から保護するために、この恒久的なホームKeygenトークンで同じシーケンス番号を2回使用してはなりません。モバイルノードは、シーケンス番号のロールオーバーが差し迫っているときに、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 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.
モバイルノード側でのハンドオフ後の早期バインディングアップデートメッセージの即時交換により、モバイルノードと特派員ノードがモバイルノードの新しいケアアドレスを介してルート最適化された通信を迅速に再確立できるようになります。モバイルノードは、初期のバインディングアップデートメッセージを発送するとすぐに、新しいケアオブアドレスからペイロードノードにペイロードパケットを送信する場合があります。特派員ノードは、早期バインディングアップデートメッセージを受信し、新しいケアオブアドレスを登録したら、新しいケアオブアドレスにモバイルノードの発信ペイロードパケットをリダイレクトします。ここで、「ペイロードパケット」は、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.
初期のバインディングアップデートメッセージに登録された新しいケアアドレスは、特派員ノードがモバイルノードから完全なバインディングアップデートメッセージを受信するまで、特派員ノードによって未検証状態で維持されます。次に、特派員ノードは、住所のケアを検証状態に設定します。住所のケアの状態は、増幅されたリダイレクトベースの洪水攻撃を防ぐために必要な、特派員ノードが住所に送信できる最大量のデータを決定します。この目的のために、特派員ノードは、バインディングキャッシュにエントリがあるモバイルノードごとに「クレジットカウンター」を維持します。検証状態にケアオブアドレスを備えたモバイルノードからペイロードパケットが到着するたびに、特派員ノードは、受信したペイロードパケットのサイズによってモバイルノードのクレジットカウンターを増やす必要があります。特派員ノードは、クレジットカウンターをより低い値で増やすか、クレジットをまったく増やさないように、ポリシーによって制限される場合があります。インバウンドペイロードパケットが未検証状態の住所から受信された場合、クレジットカウンターは変更されません。図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に示すように、モバイルノードのケアオブアドレスの状態とモバイルノードのクレジットカウンターの現在の値に依存します。対応者ノードは、検証状態にある場合、モバイルノードのケアオブアドレスにペイロードパケットを送信する必要があります。住所のケアが未確認の状態であり、クレジットカウンターの値がペイロードパケットのサイズ以上である場合、特派員ノードはペイロードパケットのサイズによってモバイルノードのクレジットカウンターを減らし、送信する必要があります。住所へのペイロードパケットも同様です。ただし、住所のケアが未確認の状態で、クレジットカウンターがペイロードパケットのサイズよりも少ない場合、ペイロードパケットをモバイルノードのケアオブアドレスに送信してはなりません。その後、特派員ノードはペイロードパケットを破棄する必要がありますが、ケアオブアドレスが確認された状態に移動するまでペイロードパケットをバッファするか、モバイルノードのホームアドレスにペイロードパケットを送信する場合があります。モバイルノードのクレジットカウンターは、特派員ノードが検証状態にある間にモバイルノードのケアオブアドレスにペイロードパケットを送信したときに変更されません。
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 Destination Options Extensionヘッダーのホームアドレスオプション。その逆の場合、特派員ノードからのすべてのペイロードパケットは、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.
特派員ノードは、すべてのクレジットカウンターが時間とともに徐々に減少することを保証します。各クレジットカウンターには、信用ングインターバルの長さの固定時間間隔で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が小さすぎる場合、クレジットカウンターは、未検証状態の住所へのペイロードパケットの送信を永続的に防ぐ可能性があります。セクション7に示されている値は、CRORSCONDENTノードがTCP接続を介してファイルをモバイルノードに転送し、エンドツーエンドの往復時間が500ミリ秒を超えない場合に適切に機能するため推奨されます。
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]で指定されているように、バインディングアップデートメッセージは、モバイル特派員ノードのホームアドレスに送信されます。これにより、2つのモバイルノードが両方とも同時にIP接続を変更しても、通信を継続できるようになります。
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バイトが含まれています。バインディングアップデートメッセージに表示されるすべての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.
署名オプションは、バインディングおよびバインディングの確認更新メッセージに使用されます。これには、モバイルまたは特派員ノードが、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トークンオプションは、拘束力のある確認メッセージで使用されます。これには、1つ以上のCGAパラメーターオプションを含むバインディングアップデートメッセージを受信した後、モバイルノードが直接モバイルノードからの署名オプションが付いた後に、特派員ノードがモバイルノードに送信する恒久的なホームキーゲントークンが含まれています。
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.
オクテットの恒久的なホームkeygenトークンフィールドの長さを表す8ビットの符号なし整数。
Permanent Home Keygen Token
恒久的なホームキーゲントークン
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で定義されているように、モバイルノードの公開キーで暗号化する必要があります。恒久的なホームKeygenトークンの長さは暗号化の前に8オクテットですが、暗号文は[4]、したがって、永続的なホームKeygenトークンフィールドが長くなる可能性があります。
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.
テストのケアイニシ様オプションは、バインディングアップデートメッセージに含まれています。それは、バインディング謝辞メッセージに新鮮なケアオブキーゲントークンを使用して、ケアオブテストオプションを返すように特派員ノードに要求します。
The format of the Care-of Test Init option is as follows:
テストCare init initオプションの形式は次のとおりです。
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.
テストのケアオプションは、拘束力のある確認メッセージで使用されます。これには、バインディングアップデートメッセージでテストのケアINITオプションを受け取った後、特派員ノードがモバイルノードに送信する新鮮なkeygenトークンが含まれています。
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に設定する必要があります。オクテットのkeygenトークンフィールドの長さを表します。
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プロパティに基づいて認証されたバインディングアップデートメッセージに含まれています。拘束力のあるノードに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プロパティを介して認証されたバインディングアップデートメッセージをモバイルノードから受信した場合、ステータスコードを使用してバインディングコードをモバイルノードに戻すバインディング確認メッセージを返しますが、特派員ノードはどちらも持っていませんモバイルノードのバインディングキャッシュエントリ、またはモバイルノードの既存のバインディングキャッシュエントリには、恒久的なホームKeygenトークンは含まれていません。ステータスコード147を使用したバインディング承認メッセージは、CGAパラメーターと署名を含むバインディングアップデートメッセージを特派員ノードに送信することにより、特派員ノードに新しい永続的なホームKeygenトークンを要求する必要があることをモバイルノードに示します。これにより、特にモバイルノードは、特派員ノードでの状態損失から迅速に回復することができます。
[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] 対応者ノードが、受信されたバインディングアップデートメッセージの認証者が正しくないことが判明した場合に障害を示すステータスコードを使用してバインディング確認メッセージを送信することを許可しません。これにより、モバイルノードは再送信タイマーの有効期限が切れた後にのみ問題を検出できるため、高い確率で追加のハンドオフレイテンシが発生します。さらに、モバイルノードは、パケットの損失を想定し、誤って認証されたバインディングアップデートメッセージを追加の時間を再送信する可能性があります。ステータスコード147を使用した拘束力のある確認メッセージは、モバイルノードがモバイルノードのホームアドレスの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.
特派員ノードは、1つ以上のCGAパラメーターオプションを含むバインディングアップデートメッセージをモバイルノードから受信した場合、[ステータスコード]をモバイルノードに[ステータスコード]でバインディング承認メッセージを返します。CGAパラメーターオプションの内容に基づいてホームアドレスを検証することはできません。または、署名オプションの署名の検証が失敗しました。
Permanent home keygen token exists (149)
恒久的なホームキーゲントークンが存在する（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が含まれていません。パラメーターオプションの後に署名オプションが続きますが、特派員ノードには、モバイルノードのバインディングキャッシュエントリに恒久的なホームKeygenトークンがあります。バインディングアップデートメッセージは、1つ以上のCGAパラメーターオプションが署名オプションが続くと直接含まれる場合、さらに処理されます。これにより、モバイルノードは、たとえば再起動のために既存のノードを失った場合に備えて、特派員ノードから新しい永続的なホームKeygenトークンを取得できます。この場合、特派員ノードがバインディングアップデートメッセージを受け入れるかどうかは、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.
特派員ノードは、モバイルノードから1つ以上のCGAパラメーターオプションを含むバインディングアップデートメッセージを署名オプションに直接含むバインディングアップデートメッセージを受信した場合、ステータスコードを含むバインディングコードをモバイルノードに戻します。NONCEインデックスオプションはゼロです。この動作により、モバイルノードのホームアドレスのCGAプロパティに基づいて認証されるバインディングアップデートメッセージも、自宅のアドレスでモバイルノードの到達可能性の証明を提供する必要があります。
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トークンは、後続の特派員登録中にモバイルノードの暗号化に使用されているため、これらの後の特派員登録は、最初のホームアドレス所有権の証明にしっかりとバインドできます。自宅の住所テストでのそれ以上の定期的な到達可能性の検証は実行されません。
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パラメーターの中には、不可逆的なハッシュエクステンション関数への入力として、公開キーとともに、一定の最小数の先行ゼロを持つ文字列になります。ホームアドレスの3つの予約ビットは、この最小数をエンコードします。
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.
最初のプロパティは、モバイルノードの公開鍵に自宅の住所を暗号化し、公開キーの暗号化により、秘密鍵に暗号化します。これにより、モバイルノードは、秘密鍵に関する知識を証明することにより、ホームアドレスの所有権を請求できます。2番目のプロパティは、最初のプロパティで十分なパブリック/プライベートキーペアのブルートフォースの方法で検索コストを増加させます。これにより、暗号化の重要性を持つ59ビットへの制限にもかかわらず、暗号化されたホームアドレスのセキュリティが向上します。それ以外の場合、最初のプロパティを実施するだけで、攻撃者はO（2^59）ステップで適切なパブリック/プライベートキーペアを見つけることができます。2番目のプロパティを追加することにより、ブルートフォース検索の複雑さをO（2^（59 n））ステップに増やすことができます。ここで、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ビットの最小キー長を規定しています。元のCGAアプリケーションであるIPv6 [13]の近隣発見を保護するために調整されたこの要件。以前に説明したように、短いキーを使用する能力は、より長いキーを使用して暗号化されたホームアドレスのセキュリティを損なうことはないため、強化されたルート最適化は最小キー長を増加させません。さらに、[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トークンは、平易なテキストで送信されることはありません。最初に割り当てられたときにモバイルノードの公開キーで暗号化され、その後の特派員登録中に不可逆的にハッシュされます。
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アドレス盗みの脅威を軽減することができますが、攻撃者はまだ正しいホームアドレスを偽りの住所に結合し、それによって特派員ノードをだましてリダイレクトパケットにします。攻撃者自体、第三者へ。したがって、攻撃者が選んだ被害者に対するリダイレクトベースの洪水攻撃に1つまたは複数の特派員ノードが無意識のうちに貢献する可能性があるため、主張されている住所でモバイルノードの到達可能性を確認することで、1つまたは複数の特派員ノードが無意識のうちに貢献する可能性があります。
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.
一般的な誤解は、ホームアドレスの所有権の強力な証拠は、リダイレクトベースの洪水の脅威を軽減し、その結果、新しい住所でモバイルノードの到達可能性を検証する必要性を排除することです。この概念は、[1]のベースモバイルIPv6ホーム登録の仕様に起因する可能性があります。これは、IPSECセキュリティ協会に基づいてモバイルノードの認証を必要としますが、モバイルノードの検証によってこれを補足する必要はありません。住所の到達可能性。ただし、ホームエージェントがモバイルノードのホームアドレスの所有権を安全に検証できるという事実ではなく、住宅登録の到達可能性検証を義務付けない理由は、ホームエージェントとモバイルノードの間の管理関係の存在です。または、住宅登録がIPSECで保護されていること。モバイルノードとの管理関係により、ホームエージェントはまず、モバイルノードのケアオブアドレスの正しさを信頼し、次に、感染のために悪意を持って動作し始めた場合、モバイルノードを迅速に識別することができます。マルウェアによる。[1]のセクション15.3および[5]のセクション1.3.2は、これらの前提条件を説明しています。
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 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.
信頼を想定すると、モバイルエージェントがモバイルユーザーが通常購読したり、彼女または自分自身を設定したり、に基づいて受信したりするモビリティサービスの不可欠な部分であるため、モバイルノードとそのホームエージェントとの間の管理関係は実行可能です。ビジネス関係。モバイルノードと特派員ノードで事前に設定された共有認証キーを活用するモバイルIPv6拡張機能[14]は、モバイルノードと特派員ノードの間の同じ関係を紹介します。この仮定はプロトコルの適用性を制限しますが（[14]、これはこれを認めています）、住宅登録の場合のように、住所の到達可能性のケアの省略を許可します。強化されたルーターの最適化は、モバイルノードと特派員ノードの関係について仮定しません。これにより、プロトコルが任意のシナリオに適用されますが、特派員ノードがすべての新しいアドレスでモバイルノードの到達可能性を検証する必要があることが必要です。
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: 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.
強化されたルートの最適化は、クレジットベースの承認を使用して到達可能性の同時検証にもかかわらず、リダイレクトベースの洪水の脅威を排除します。クレジットベースの承認は、特派員ノードが未検証状態の住所にペイロードパケットを送信する際に費やす努力を管理します。これは、次の3つの仮説に基づいて達成されます。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.
リダイレクトベースの洪水攻撃の加害者はモバイルノードの役割を引き受けるため、クレジットベースの承認を特派員ノード側で実施する必要があります。特派員ノードは、モバイルノードが特派員ノードとの通信に費やす努力を継続的に監視します。モバイルノードの努力は、モバイルノードのケアオブアドレスが未確認の状態にある場合、特派員ノードがペイロードパケットの送信に費やすことができる努力の制限と見なされます。特派員ノードが未確認状態で限られた量のペイロードパケットを住所に送信する許可により、モバイルノードがハンドオフ後に特派員ノードに新しいIPアドレスを登録した後、双方向通信の即時再開を可能にします。
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.
クレジットベースの承認のもう1つのプロパティは、モバイルノードクレジットを割り当てないことです。これは、モバイルノードのケアオブアドレスの状態とは無関係にクレジットを割り当てることが技術的に実行可能であるため、正当化に値します。ただし、未検証状態の住所から受け取ったパケットのクレジットの割り当ては、持続的な反射攻撃に対する脆弱性を導入するでしょう。具体的には、攻撃者は、特派員ノードに攻撃者のパケットを被害者の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.
強化されたルートの最適化は、ハンドオフの遅延とシグナリングオーバーヘッドを減らすために、最初のホームアドレステストもケアオブアドレステストも繰り返されません。これは、Homeアドレスに必要な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.
拡張されたルート最適化が自宅でのモバイルノードの到達可能性を検証する時間または住所のケアが輸送層接続の確立に十分に対応する可能性があることはまだ認められるべきです。これにより、攻撃者は、特派員ノードと被害者の間のパスから離れる時間を増やすため、攻撃をより実用的に変える時間を増やします。定期的な到達可能性検証の欠如が危険すぎると見なされる場合、特派員ノードは、登録の寿命を制限するか、バインディングリフレッシュリクエストメッセージをモバイルノードに送信することにより、ホームまたは住所テストの再実行を実施する場合があります。
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時間に1回は追求する必要があります。モバイルおよび特派員のノードは、シーケンス番号スペースのロールオーバーが差し迫っている場合にも再キーを再キーにします。しかし、これは頻繁に起こりそうにありませんが、利用可能なシーケンス番号が最大32768の特派員登録に十分であり、それぞれが早期および完全なバインディングアップデートメッセージで構成されることを考えると、それはほとんど起こりそうにありません。したがって、シーケンス番号スペースでは、24時間のバインディング寿命を通して再キーの必要性を公開することなく、1分あたり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プロパティに基づいて受信されたバインディング確認メッセージを認証できます。モバイルノードは、CGAパラメーターリクエストオプションをCRORSPROSENTENT NODEに送信するバインディングアップデートメッセージに含めることにより、この認証を要求し、CGAパラメーターと署名メッセージにCGAパラメーターと署名オプションに署名を追加することにより、特派員ノードが応答します。特派員ノードのIPアドレスの所有権を証明することで、モバイルノードがスプーフィングされたバインディング承認メッセージを受け入れ、将来の特派員登録中に使用するための恒久的なホーム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.
記載されているサービス拒否攻撃の脅威は、攻撃者の場所に関する要件によってある程度緩和されます。自宅の住所。この認証方法には、ホームアドレステストが含まれ、モバイルノードにバインディングアップデートメッセージの認証器を計算できるホームKeyGenトークンを提供します。モバイルノードは、戻ってくるバインディング承認メッセージの認証者が同じホームKeygenトークンで計算されると予想するため、恒久的なホームKeygenトークンを含む拘束力のある承認メッセージを喜んでスプーフィングする攻撃者であるホームアドレステストで盗聴する攻撃者です。したがって、攻撃者は、ホームアドレステストが進行している間、特派員ノードからモバイルノードのホームエージェントへのパスに存在する必要があります。さらに、恒久的なホームKeygenトークンを要求するバインディングアップデートメッセージが完了した場合、その認証者はさらにKeygenトークンのケアに基づいて計算されます。攻撃者はまた、このkeygenトークンのケアを知り、バインディング承認メッセージの認証因子を生成する必要があります。これにより、攻撃者は、特派員ノードがテストのケアメッセージまたはテストケア内でキーゲントークンをモバイルノードに送信する時点で、特派員ノードからモバイルノードの現在のIP添付ファイルへのパスにある必要があります。拘束力のある確認メッセージのオプション。
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 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.
一般的にモバイルノードは、特定の特派員ノードのIPアドレスがCGAであるかどうかを知らないため、モバイルノードは、含まれているCGAを含むバインディングアップデートメッセージの送信に応じて、CGAパラメーターと署名オプションを使用しないバインディング確認メッセージを受信する必要があります。パラメーター要求オプション。それ自体、この必須の動作は、攻撃者がCGAパラメーターと署名オプションのない拘束力のある承認メッセージを攻撃者が送信する攻撃を格下げすることを可能にする場合があります。強化されたルート最適化により、この脅威は、モバイルノードが有効なCGAパラメーターを使用したバインディング承認メッセージと、そのようなオプションなしで拘束力のある承認メッセージよりも署名オプションを優先するように要求するという点で緩和されます。これにより、攻撃者が特派員ノードからのバインディング承認メッセージを傍受できない限り、格下攻撃から保護します。攻撃者は、上記の説明とほぼ同じ時期に、攻撃者が特派員ノードからモバイルノードのホームエージェントへのパスにいる必要があるため、攻撃者は特派員ノードのバインディング承認メッセージを傍受できない場合があります。一方、特派員ノードからのバインディング承認メッセージを傍受できる攻撃者は、とにかくモバイルノードと特派員ノードに対するサービスの拒否を追求できる位置にあります。これは、非モバイルインターネットにすでに存在する脅威であり、ルートの最適化の強化に固有のものではありません。
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であるかどうかについて確実性を取得できます。その後、モバイルノードは、特派員ノードからのIPアドレスの所有権の証明を主張する場合があります。この場合、有効なCGAパラメーターと署名オプションが含まれていない受信した拘束力のある承認メッセージを破棄します。モバイルノードが標準のIPv6アドレスとCGAを区別するための考えられる1つの手段は、ドメイン名システムの拡張機能である可能性があります。
[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]:
このドキュメントでは、次の6つの新しいモビリティオプションを定義します。これは、[1]のスペースに番号付けされるモビリティオプション内でタイプ値を割り当てる必要があります。
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 「CGAと署名検証が失敗した」（148）
o "Permanent home keygen token exists" (149)
o 「恒久的なホームキーゲントークンが存在する」（149）
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.
これらのステータスコードに割り当てられる値はすべて128以上でなければなりません。これは、それぞれのバインディングアップデートメッセージが受信特派員ノードによって拒否されたことを示しています。
This document also defines a new 128-bit value under the CGA Message Type namespace [2].
このドキュメントでは、CGAメッセージタイプの名前空間[2]の下で新しい128ビット値も定義されています。
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 Aura、Gabriel Montenegro、Pekka Nikander、Mike Roe、Greg O'Shea、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 Sarikaya (in alphabetical order) for their reviews of and important comments on this document and the predecessors of this document.
著者はまた、マルセロ・バグヌロ、ローランド・ブレッシー、ゼン・カオ、サミータ・チャクラバルティ、グレッグ・デイリー、ヴィジェイ・デヴァラパリ、マーク・ドール、ラクシュミナート・ドンデティ、フランシス・デュポン、ラース・エガート、エリック・グレイ、ジェームズ・ケンプフKuefner、Lila Madour、Vidya Narayanan、Mohan Parthasarathy、Alice Qinxia、およびBehcet 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] Johnson、D.、Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Jonsson、J. and 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.、Aura、T.、Montenegro、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] Vogt、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] Vogt、C。およびM. Doll、「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 Computer Communication Review、Vol。34、No。2、ACM Press、2004年4月。
[9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", Work in Progress, May 2004.
[9] Arkko、J。およびC. Vogt、「拘束力のある生涯拡張のためのクレジットベースの承認」、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] O'Shea、G。およびM. Roe、「Mipv6（CAM）の児童耐性認証」、ACM Sigcomm Computer Communication Review、ACM Press、Vol。31、No。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月、Springer-Verlagのセキュリティプロトコルに関する国際ワークショップから論文を修正しました。
[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、「暗号化されたアドレス（CGA）の複数のハッシュアルゴリズムのサポート」、2007年4月、進行中の作業。
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[13] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[14] Perkins、C。、「静的共有キーを使用したモバイルIPv6ルート最適化の保護」、RFC 4449、2006年6月。
[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] Roe、M.、Aura、T.、O'Shea、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. Dupont、「暗号化されたアドレスを適用してMIPV6（CGA-OMIPV6）を最適化する」、2005年5月の作業進捗状況。
[17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding Updates for Mobile IPv6", Work in Progress, February 2004.
[17] Vogt、C.、Bless、R.、Doll、M。、およびT. Kuefner、「Mobile 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] Vogt、C.、Arkko、J.、Bless、R.、Doll、M。、およびT. Kuefner、「モバイルIPv6の早期拘束力のある更新に対するクレジットベースの承認」、2004年5月、進行中の作業。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
Jari Arkko Ericsson Research Nomadiclab FI-02420 Jorvas Finland
EMail: jari.arkko@ericsson.com
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
キリスト教VOGTテレマティクス大学Karlsruhe（Th）P.O。Box 6980 76128 Karlsruheドイツ
EMail: chvogt@tm.uka.de
Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada
Wassim Haddad Ericsson Research 8400、Decarie Blvd Town of Mount Royal Quebec H4p 2N2、カナダ
EMail: wassim.haddad@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。