RFC4866 日本語訳
4866 Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt,W. Haddad. May 2007. (Format: TXT=145757 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4866年のエリクソン研究NomadicLabカテゴリ: 標準化過程C.フォークトUniversitaetカールスルーエ(TH)W.ハダドエリクソン研究2007年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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
1. 序論…3 2. 目的…4 2.1. 移管潜在…5 2.2. セキュリティ…5 2.3. シグナリングオーバーヘッド…7 3. デザインについて議定書の中で述べてください…7 3.1. ホームアドレスであると暗号で生成されます…7 3.2. 非暗号、注意、-、アドレス…8 3.3. 半永久的なセキュリティ協会…8 3.4. ホームアドレステストに頭文字をつけてください…8 3.5. 同時発生、注意、-、テストを扱ってください…9 3.6. クレジットベースの承認…9 3.7. ホームと通信員登録証明書に沿ってください…10 4. 操作について議定書の中で述べてください…10 4.1. 結合を送って、メッセージをアップデートしてください…10 4.2. 結合を受けて、メッセージをアップデートしてください…18 4.3. 拘束力がある承認メッセージを送ります…22
Arkko, et al. Standards Track [Page 1] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[1ページ]RFC4866
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
4.4. 拘束力がある承認メッセージを受け取ります…23 4.5. パラメタをCGAに送ります…25 4.6. CGAパラメタを受け取ります…26 4.7. 永久的なホームKeygenトークンを送ります…27 4.8. 永久的なホームKeygenトークンを受けます…28 4.9. 永久的なホームKeygenトークンを更新します…28 4.10. 取り扱い有効搭載量パケット…28 4.11. 年をとることを掛けてください…31 4.12. 同時の運動…32 5. オプション形式と状態コード…32 5.1. CGAパラメタオプション…32 5.2. 署名オプション…33 5.3. 永久的なホームKeygenトークンオプション…34 5.4. 注意、-、イニットオプションをテストしてください…35 5.5. 注意、-、オプションをテストしてください…35 5.6. CGAパラメタはオプションを要求します…36 5.7. 状態コード…36 6. セキュリティ問題…38 6.1. ホームアドレス所有権…39 6.2. 注意、-、所有権を扱ってください…41 6.3. クレジットベースの承認…43 6.4. タイム・シフトは攻撃されます…46 6.5. 反射攻撃…47 6.6. リソース疲労困憊…47 6.7. 通信員ノードのIPアドレス所有権…47 7. 定数と構成変数について議定書の中で述べてください…49 8. IANA問題…50 9. 承認…50 10. 参照…51 10.1. 標準の参照…51 10.2. 有益な参照…51
Arkko, et al. Standards Track [Page 2] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[2ページ]RFC4866
1. Introduction
1. 序論
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の上のスタック層のモバイルノードを特定する際に安定した「ホームアドレス」を使用します、aを通してペイロードパケットを送るか、または受け取りますが「注意、-、」 それがモバイルノードの現在のネットワーク付属に発送するアドレス。 そして、モバイル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]は起こるでしょうに。 テストを扱ってください。したがって、通信員登録が「ホームアドレステスト」とaを取り入れる、「注意、-、」 まとめて「リターンroutability手順」と呼ばれます。 そして、通信員ノードがホームでこれらのテストでモバイルノードの可到達性を調べることができる、注意、-、臨時の、そして、非暗号の方法で、扱います。 そして、モバイルノードのIPアドレスの所有権を示して(どんな保証もしませんが)、したがって、両方のIPアドレスでのうまくいっている可到達性検証はホームアドレスの間で付くそのaを示す、注意、-、アドレス、正統です。
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手順の利点は軽量であり、公開鍵インフラストラクチャ、または、モバイルノードと通信員ノードとの先在の関係によらないということです。 これは広い展開を容易にします。 そして、他方では、手順が両方のホームアドレステスト以来の移管遅れに悪影響を持っている、注意、-、アドレステストはモバイルノードと対応であっているノードの間の終わりから終わりへの交換処理から成ります。 ホームを通ってエージェントを発送するので、ホームアドレステストの潜在は特に高いかもしれません。 または、また、彼らがホームの口をはさむことができる位置にいる攻撃者にとって、リターンroutability手順も被害を受け易い、注意、-、テストを扱ってください。 挿入の値がそれで制限される、リターン
Arkko, et al. Standards Track [Page 3] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[3ページ]RFC4866
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.
高々7分の間隔でroutability手順を繰り返さなければなりません、モバイルノード側のIPの接続性における変化がないときでさえ。 しかし、これは増強されたシグナリングオーバーヘッドの費用で来ます。 したがって、多くの取り組みがモバイル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で最適化を発送するためにEnhanced Route Optimization、修正を指定します。 高められたRoute Optimizationはモバイルノードの公衆/秘密鍵組の公共のコンポーネントへの暗号でと証明可能に制限された[2]であるインタフェース識別子を通してものまねに対してモバイルノードのホームアドレスを保証します。 モバイルノードは、対応する秘密鍵を知っているという証拠を提供することによって、ホームアドレスの所有権を立証します。 初期のホームアドレステストはホームアドレス接頭語を有効にします。 その後のホームアドレステストは不要です。 aを追求することと平行して高められたRoute Optimizationがモバイルの、そして、対応であっているノードに双方向のコミュニケーションをさらに再開させる、注意、-、テストを扱ってください。 そして、潜在する、ホームについて注意、-、多くの場合、したがって、アドレステストは排除されます。 使用、また、暗号で、発生しているホームアドレスはホームアドレステストのときに挿入して、その結果より長い拘束力がある生涯を容易にすることができるものまね役者の脅威を緩和します。 これはオーバーヘッドに合図する際に増強されたセキュリティと減少に通じます。 暗号でホームアドレスで同時発生で生成される、注意、-、アドレステストは望ましくは一緒に適用されますが、モバイルノードは、これらの増進の1つだけを使用するのを選ぶかもしれません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[3]で説明されるように本書では解釈されることであるべきですか?
2. Objectives
2. 目的
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の経路最適化のデザインが保守的な人、退出が移管遅れ、セキュリティ、およびシグナリングオーバーヘッドを最適化するために同居する多くの方法であります。 高められたRoute Optimizationはこれらの問題に取り組んで、その結果、モバイル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
どんなモバイルIPv6最適化にもかかわらずも、プロトコル・スタックのほかの場所での移動性関連の活動にはそれら自身の影響力があるかもしれないのを考慮に入れるのは重要です。 例えば、リンクレイヤでの付属手順、アクセスコントロール、および認証はそれら自身の移管遅れを寄付します。 ルータ発見や、隣人発見や、動き検出や、IPアドレス構成などのIP層のタスクもそうします。 モバイルIPv6の移管遅れとシグナリングオーバーヘッドはそうです。
Arkko, et al. Standards Track [Page 4] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[4ページ]RFC4866
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.
通常小さい、総遅れとオーバーヘッドと比較されます。 Enhanced Route Optimizationの改良はしたがって、全体のプロトコル・スタックから見て見られるべきです。
2.1. Handoff Latency
2.1. 移管潜在
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経路最適化の典型的な移管遅れは本国登録(Binding Updateメッセージの伝播のためのモバイルノードとホームのエージェントとリターンroutability手順のためのホームのエージェントと通信員ノード、および1一方通行の時間の往復の1回の間の往復のモバイルノードから通信員ノードまでの1回)のためのモバイルノードとホームのエージェントの間の往復の1回です。 (リターンroutability手順の潜在がホームアドレステストで支配されるという仮定がここにあります。) 最初のペイロードパケットが新しさに発信した、注意、-、アドレスは通信員ノードからモバイルノードまで伝播する1追加一方通行の時間を必要とします。 Binding Updateメッセージを派遣したまさしく後にモバイルノードはトランスミッションを再開できます。 しかし、通信員ノードからBinding Acknowledgmentメッセージを要求するなら、これが受け取られているまで、通常、コミュニケーションは遅れます。
Handoff delays in base Mobile IPv6 route optimization are additive to other delays at the IP layer or link layer. They can cause perceptible quality degradations for interactive and real-time applications. TCP bulk-data transfers are likewise affected since long handoff latencies may lead to successive retransmission timeouts and degraded throughput [7]. An objective of Enhanced Route Optimization is hence a reduction of the handoff latency.
ベースのモバイルIPv6経路最適化の移管遅れはIP層かリンクレイヤの他の遅れに付加的です。 彼らは対話的でリアルタイムのアプリケーションのための知覚可能な品質劣化を引き起こす場合があります。 長い移管潜在が連続した再送タイムアウトと降格しているスループット[7]につながるかもしれないので、TCPバルク・データ転送は同様に影響を受けます。 したがって、Enhanced Route Optimizationの目的は移管潜在の減少です。
2.2. Security
2.2. セキュリティ
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:
リターンroutability手順は目的で設計されていて、今日の非モバイルインターネットの[5]のものと比較されるセキュリティのレベルを提供しました。 そういうものとして、それはものまね、サービスの否定、および非モバイルインターネットでは存在しませんが、移動性の導入が適切な対策がないとき導入する氾濫の脅威から守ります。 特に、リターンroutability手順は以下の要件を満たします:
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
o 通信員ノードから犠牲者までの経路の攻撃者は、通信員ノードがパケットを向け直すようにだますことができないべきです。(通常、パケットは犠牲者、または、それ自体、または、3番目のIPアドレスに提供されるはずです)。 そうでなければ、攻撃者は犠牲者に対してサービスの通信員ノードか原因否定に犠牲者をまねることができました。 攻撃者はこれらを始めるかもしれません。
Arkko, et al. Standards Track [Page 5] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[5ページ]RFC4866
attacks from an arbitrary position, which would not necessarily
have to be on the path between the victim and the correspondent
node.
任意の位置からの攻撃。(必ず、それは、犠牲者と通信員ノードの間の経路にある必要はないでしょう)。
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
リターンroutability手順は通信員ノードから犠牲者まで経路にいない攻撃者でものまね、サービスの否定、およびリダイレクションベースの氾濫を排除します、そして、高価な操作を暴露しないのは十分軽量です。 しかし、リターンroutability手順は通信員ノードから犠牲者まで経路に位置している攻撃者から守りません。 一般に、より高いセキュリティー・レベルを必要とするアプリケーションがIPセキュリティ(IPsec)かTransport Layer Security(TLS)などの終わりから終わりへの保護を使用するように教えられます。 しかし、その時でさえ、彼らはサービスか氾濫の否定に被害を受け易い状態でいます。 その上、一般に、終わりから終わりへのセキュリティー対策が、モバイルと通信員ノードが認証資格証明書であらかじめ設定されるのを必要とするか、またはそれらは公開鍵インフラストラクチャによります。 両方がそれが前提条件であるならモバイルIPv6経路最適化の広い展開を妨げるでしょうに。
Arkko, et al. Standards Track [Page 6] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[6ページ]RFC4866
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.
議定書を作ってください。 したがって、Enhanced Route Optimizationの目的はそうです。経路の攻撃者の面前でさえあらかじめ設定された資格証明書も公開鍵インフラストラクチャなしでモバイルノードをしっかりと通信員ノードから犠牲者まで認証するために。
2.3. Signaling Overhead
2.3. シグナリングオーバーヘッド
A complete correspondent registration involves six message transmissions at the mobile node, totaling about 376 bytes [9]. This signaling overhead may be acceptable if movements are infrequent. For example, a mobile node that moves once every 30 minutes generates an average of 1.7 bits/s of signaling traffic. Higher mobility causes more substantial overhead, however. A cell size of 100 meters and a speed of 120 km/h yields a change in IP connectivity every 3 s and about 1,000 bits/s of signaling traffic. This is significant compared to a highly compressed voice stream with a typical data rate of 10,000 to 30,000 bits/s.
およそ376バイト[9]を合計して、完全な通信員登録はモバイルノードでの6つのメッセージ送信にかかわります。 運動が珍しいなら、このシグナリングオーバーヘッドは許容できるかもしれません。 例えば、30分に一度移行するモバイルノードは平均1.7ビット/sのシグナリングトラフィックを生成します。 より高い移動性が. しかしながら、より実質的なオーバーヘッド、120km/hの利回りの100メーターと速度のセルサイズにIPの接続性における変化を引き起こす、あらゆる、3秒間とおよそ1,000ビット/sのシグナリングトラフィック。 1万〜3万ビット/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分単位で通信員登録を更新するためにモバイルノードを必要とします。 モバイルノードが静止したノード[9]とコミュニケートするなら、シグナリングオーバーヘッドは7.16ビット/sに達します。 両方の同輩モバイルであるなら、それは倍増します。 ノードが交信するとき、このオーバーヘッドが取るにたらないかもしれませんが、それは、不活発なモバイルノードのための問題であり、しばらく、同じ位置にいることができます。 これらのノードは、電池残量を保存しに待ち受け状態に行くのを通常好みます。 また、周期的な軽い飲食物は1つが、より効率的に使用できたワイヤレスの帯域幅の部分を消費します。 これらの観測はベースのモバイルIPv6通信員登録証明書のシグナリングオーバーヘッドをできるだけ下げるためにEnhanced Route Optimizationの目的につながります、特定でモバイルノードがしばらく移行しないと。
3. Protocol Design
3. プロトコルデザイン
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.
高められたRoute Optimizationはセクション2で議論した目的の達成をまとめて提供する1セットの最適化から成ります。 これらの最適化は以下にまとめられます。
3.1. Cryptographically Generated Home Addresses
3.1. ホームアドレスであると暗号で生成されます。
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,
モバイルIPv6結合が概念的にそうである、ホームアドレスからのパケットリダイレクション、注意、-、アドレス そして、ホームアドレスがリダイレクションの源である、注意、-、アドレスは目的地です。 したがって、ホームアドレスに基づいて向け直されるべきパケットは特定できます。 これはホームアドレスのための暗号の所有権証拠を動機づけます。 高められたRoute Optimizationは暗号でこの目的[10][11]のための発生しているホームアドレスを適用します。 一般に、Cryptographically Generated Address(CGA)は強い状態でaを提供します。
Arkko, et al. Standards Track [Page 7] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[7ページ]RFC4866
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.
インタフェース識別子とCGA所有者の公開鍵の間の暗号の結合。 これは公開鍵インフラストラクチャなしで暗号のホームアドレス所有権証拠を容易にします、他のノードがしっかりと、自主的にそういうもののCGA所有者を認証するのを可能にして、法。CGAのサブネット接頭語の正当性。 暗号で、ホームアドレス接頭語を有効にするための初期のテストを除いて、発生しているホームアドレスはホームアドレステストに取って代わることができます。 これは、下側の移管遅滞と一時移行しないモバイルノードのためにオーバーヘッドに減少するより長い拘束力がある同じくらい生涯、同じくらいよく合図するのを容易にします。 また、高められたRoute Optimizationは、通信員ノードがIPアドレスの所有権を立証するのを任意に可能にします。
3.2. Non-Cryptographic Care-of Addresses
3.2. 非暗号、注意、-、アドレス
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.
ホームアドレス、aと対照して注意、-、アドレスには、特定の機能性がありません。 したがって、aの暗号の所有権証拠には利益がほとんどない、注意、-、アドレス。 それを与える、注意、-、アドレス、パケットリダイレクションの目的地、それがむしろモバイルノードの可到達性であるということである、注意、-、重要なアドレス。 Route Optimization用途を機能アップする、注意、-、アドレスでこのためにテストしますが、通信員ノードがパケットをaに新しい状態で送る、注意、-、モバイルノードの前のアドレスはそこで届くのがわかりました。
3.3. Semi-Permanent Security Associations
3.3. 半永久的なセキュリティ協会
CGA-based authentication involves public-key cryptography and is hence computationally much less efficient than authentication through a shared secret key. The technique further requires a substantial amount of supplementary CGA parameters to be piggybacked onto protected messages. Enhanced Route Optimization mitigates these disadvantages in that it utilizes an initial CGA-based authentication to securely exchange a secret permanent home keygen token between a mobile node and a correspondent node. The permanent home keygen token is used to authenticate the mobile node more efficiently in subsequent correspondent registrations. Mobile and correspondent nodes renew the permanent home keygen token on an infrequent basis. The token is therefore neither constant nor short-lived, which is why the security association between the mobile node and the correspondent node is called "semi-permanent".
CGAベースの認証は、公開鍵暗号にかかわって、したがって、認証より共有された秘密鍵を通して計算上あまり効率的ではありません。 テクニックは、かなりの量の補っているCGAパラメタが保護されたメッセージに背負われるのをさらに必要とします。 モバイルノードと通信員ノードの間でしっかりと秘密の永久的なホームkeygenトークンを交換するのに初期のCGAベースの認証を利用するので、高められたRoute Optimizationはこれらの損失を緩和します。 永久的なホームkeygenトークンは、その後の通信員登録証明書で、より効率的にモバイルノードを認証するのに使用されます。 モバイルと通信員ノードは珍しいベースで永久的なホームkeygenトークンを更新します。 トークンはそうです、したがって、一定でなくて、また短命でないことで、モバイルノードと通信員ノードとのセキュリティ協会が「半永久的である」と呼ばれる理由はどれですか?
3.4. Initial Home Address Tests
3.4. 初期のホームアドレステスト
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
ホームアドレスの偽造しているサブネット接頭語に対して保護するホームアドレス所有権の暗号の証拠にもかかわらず、初期のホームアドレステストが必要です。 ホームアドレステストの完全欠損では、悪意があるノードは暗号でホームを生成するかもしれません。
Arkko, et al. Standards Track [Page 8] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[8ページ]RFC4866
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.
そして、犠牲者ネットワーク、および要求のサブネット接頭語でこれがホームアドレスを偽造した結合を登録する通信員ノードを扱ってください、攻撃者のものが所有している、注意、-、アドレス 次に、攻撃者がパケットの流れを送ることへの通信員ノードをだます、注意、-、アドレスと次に「反-レジスタ」、付くか、またはそれは期限が切れます。 結果は通信員ノードがホームアドレスにパケットストリームを向け直すということです、犠牲者ネットワークが非要求されたパケットで水につかっていることを引き起こして。 そのような誤用を排除するために、モバイルノードと通信員ノードが半永久的なセキュリティ協会を設立するのに初期のホームアドレステストが必要です。 できれば、ホームアドレステストは、重要な移管の期間のホームのエージェントを通して潜在的に高価な交換処理を保存するために先を見越す方法で実行されます。 その後の運動のときにホームアドレステストは繰り返される必要はありません。
3.5. Concurrent Care-of Address Tests
3.5. 同時発生、注意、-、テストを扱ってください。
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.
高められたRoute Optimizationが通信員ノードにモバイルノードのものにペイロードパケットを新しい状態で送らせる、注意、-、モバイルノードが届いているのがわかる前に扱う、注意、-、アドレス モバイルノードがIPの接続性を変えると、最初に通信員ノードで新しさに付くのをアップデートする、注意、-、可到達性の証拠を提供することのないアドレス。 通信員ノードが新しさを登録する、注意、-、一時的な基礎とセットでUNVERIFIED状態にそれを扱ってください。 次に、新しさであることを通して双方向に有効搭載量パケットを交換できる、注意、-、新しさのモバイルノードの可到達性である間、扱う、注意、-、アドレスは同時に確かめられます。 通信員ノードが移行する、注意、-、かつて状態が検証が完成する可到達性であるとVERIFIEDに扱ってください。
3.6. Credit-Based Authorization
3.6. クレジットベースの承認
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
高められたRoute OptimizationはベースのCredit Authorizationの使用でリダイレクションベースのフラッディング攻撃から守ります。 ベースのクレジットAuthorizationが通信員ノードが中に発信しているペイロードパケットを費やす努力を管理する、注意、-、アドレス、UNVERIFIEDが浸水しながらリダイレクションベースでそのaを確実にするために述べるコネ
Arkko, et al. Standards Track [Page 9] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[9ページ]RFC4866
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.
攻撃はダイレクト氾濫より効果的であるはずがありません。 非要求されたパケットを送る能力はパケット指向のネットワークの固有の特性です、そして、ダイレクト氾濫はこれから生じる脅威です。 ダイレクト氾濫が移動性サポートのあるなしにかかわらず存在していて、リダイレクションベースのフラッディング攻撃がもうこれより効率的であるはずがないので、ベースのCredit Authorizationは氾濫に関してEnhanced Route Optimizationによって非モバイルインターネットのものに提供されたセキュリティー・レベルを増加させます。 したがって、高められたRoute Optimizationは、非モバイルインターネットのものに匹敵するセキュリティー・レベルを提供するために目的を満たします。
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.
努力の測定と制限は「クレジット」の概念を通して技術的に実感されます。通信員ノードは、可動のノードが通信員ノードとの通常のコミュニケーションの間に費やす努力と関連してそれ自身の努力を置くために概念を維持します。 通信員ノードがそれが受信するペイロードパケットのためにクレジットを増加させる、注意、-、アドレス、VERIFIEDの可動のノードが述べて、ペイロードパケットを送りながらそれ自身の努力に比例したクレジットを減少させる、注意、-、アドレス、UNVERIFIED状態の可動のノードについて。
3.7. Parallel Home and Correspondent Registrations
3.7. 平行なホームと通信員登録証明書
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.
高められたRoute Optimizationは、可動のノードがそれぞれの本国登録と平行して通信員登録につきまとうのを可能にします。 彼らが通信員登録を開始する前にうまくいっている本国登録を示すBinding Acknowledgmentメッセージを待つために可動のノードを必要とするモバイルIPv6を基礎づけるために比べて、これは移管遅れを減少させます。
4. Protocol Operation
4. プロトコル操作
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.
高められたRoute Optimizationが可動のノードにホームアドレスのCGAの特性に基づく通信員ノードと、そして、要求に同時発生でaをしっかりと認証させる、注意、-、増加する移管効率のためのテストを記述してください。 可動のノードがこれらの増進のどちらかか両方を利用したがっているかどうかによって、通信員登録の間に交換されたメッセージは異なっています。 これは以下で説明されます。
4.1. Sending Binding Update Messages
4.1. 送付の拘束力があるアップデートメッセージ
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 その後のパケットは、家から離れている間、通信員ノードで新しい結合を証明するために、リンクして、ルートによって最適化されてい、もう可動のノードの家のエージェントを通して発送されないでしょう。
Arkko, et al. Standards Track [Page 10] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[10ページ]RFC4866
o To update an existing binding at the correspondent node while
moving from one point of IP attachment to another.
o 別のものへの1ポイントの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 完全なBinding Updateメッセージがある早めのBinding UpdateメッセージをBinding Acknowledgmentメッセージを受け取ることのあとについて行く、Care、-、Testオプション
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-|
| | |
モバイルノードホームエージェントCorrespondentノード| | | | | | ~ 移管| | | | | |-拘束力があるアップデート--------->|、| |-前のBinding Update+、注意、-、Test Initオプション-->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、--Ackを縛ります。| | | <、-、-、-、-、-、-、-、-、--前のBinding Ack+、注意、-、Testオプション| | | | | | | |-拘束力があるアップデート----------------------------------->|、|、|、|、|、|、| |<--------------------------------------Ackを縛ります。| | | |
Figure 1: Correspondent registration with authentication by a proof
of the mobile node's knowledge of a permanent home keygen token;
concurrent care-of address test
図1: 永久的な家のkeygen象徴に関する可動のノードの知識の証拠による認証による通信員登録。 同時発生、注意、-、テストを記述してください。
In any of these cases, the mobile node sends a Binding Update message to the correspondent node. The Binding Update message is authenticated by one of the following three authentication methods:
これらの場合のいずれではも、可動のノードはBinding Updateメッセージを通信員ノードに送ります。 Binding Updateメッセージは以下の3つの認証方法の1つで認証されます:
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
o 可動のノードのホームアドレスであるなら、aはCGAですが、可動のノードは通信員ノードのためのBinding Update Listエントリーに永久的な家のkeygen象徴を持っていません、可動のノードSHOULD
Arkko, et al. Standards Track [Page 11] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[11ページ]RFC4866
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.
ホームアドレスのCGAの特性に基づくBinding Updateメッセージを認証してください。 これは、そのCGAパラメタと署名を通信員ノードに送って、ホームアドレスで可到達性のチェックを通過するために可動のノードを必要とします。
o If the mobile node's home address is a CGA, and the mobile node
has a permanent home keygen token in its Binding Update List entry
for the correspondent node, the mobile node MUST authenticate the
Binding Update message by a proof of its knowledge of the
permanent home keygen token.
o 可動のノードのホームアドレスがCGAであり、可動のノードが通信員ノードのためのBinding Update Listエントリーに永久的な家のkeygen象徴を持っているなら、可動のノードは永久的な家のkeygen象徴に関する知識の証拠でBinding Updateメッセージを認証しなければなりません。
o If the mobile node's home address is not a CGA, the mobile node
MUST authenticate the Binding Update message through a proof of
reachability at its home address.
o 可動のノードのホームアドレスがCGAでないなら、可動のノードは可到達性の証拠を通してホームアドレスでBinding Updateメッセージを認証しなければなりません。
The lifetime requested by the mobile node in the Lifetime field of the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME (see Section 7) if the Binding Update message is to be authenticated based on the CGA property of the mobile node's home address or by a proof of the mobile node's knowledge of a permanent home keygen token. If the selected authentication method is a proof of the mobile node's reachability at the home address, the lifetime MUST NOT exceed MAX_RR_BINDING_LIFETIME [1]. It is RECOMMENDED in all cases that the mobile node requests the maximum permitted lifetime in order to avoid unnecessary binding refreshes and thus reduce signaling overhead. The Lifetime field of a Binding Update message that requests the deletion of an existing binding at the correspondent node MUST be set to zero.
Binding UpdateメッセージのLifetime分野で可動のノードによって要求された寿命はBinding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいた永久的な家のkeygen象徴に関する可動のノードの知識の証拠によって認証されることであるならマックス_CGA_BINDING_LIFETIME(セクション7を見る)を超えてはいけません。 選択された認証方法がホームアドレスにおける可動のノードの可到達性の証拠であるなら、寿命はマックス_RR_BINDING_LIFETIME[1]を超えてはいけません。 最大が不要な結合を避けるために可能にした可動のノードが生涯を要求するすべての場合におけるRECOMMENDEDがシグナリングオーバーヘッドをリフレッシュして、その結果、下げるということです。 通信員ノードで既存の結合の削除を要求するBinding UpdateメッセージのLifetime分野をゼロに設定しなければなりません。
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の特性を通してあるなら、Signatureオプションで1つ以上のCGA Parametersオプション(セクション5.1を見る)が直接続いた(セクション5.2を見る)と言い足すことによって、可動のノードはBinding UpdateメッセージにそのCGAパラメタと署名を含んでいます。 これはセクション4.5で説明されます。 通信員ノードから永久的な家のkeygen象徴をいったん入手すると、可動のノードがこの永久的な家のkeygen象徴に関する知識の証拠で永久的な家のkeygen象徴が明らかに拘束力がある寿命が期限が切れるか、更新されていて可動のノードになるまですべてのその後のBinding Updateメッセージを認証しなければならない、「反-レジスタ」、通信員ノードでの結合。 これは、通信員ノードから可動のノードのホームアドレスまでの経路の攻撃者がホームアドレスで可動のノードの選ばれた認証方法を可到達性の証拠に格下げできないのを確実にします。 可動のノードは、ホームアドレスのCGAの特性を無視して、可到達性の証拠を通してホームアドレスでBinding Updateメッセージを認証するのを選ぶかもしれません。 しかしながら、この振舞いは、経路の攻撃者に脆弱性を増加させて、したがって、NOT RECOMMENDEDです。
Arkko, et al. Standards Track [Page 12] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[12ページ]RFC4866
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-|
| | |
モバイルノードホームエージェントCorrespondentノード| | | | | | |-ホームテストイニット--------->|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |<------------------------|<--------------家、試しに。| | | | | | | ~ 移管| | | | | |-拘束力があるアップデート--------->|、| |-前のBinding Update+、注意、-、Test Initオプション-->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、--Ackを縛ります。| | | <、-、-、-、-、-、-、-、-、--前のBinding Ack+、注意、-、Testオプション| | | | | | | |-拘束力があるアップデート----------------------------------->|、|、|、|、|、|、| |<--------------------------------------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象徴を取り替えるつもりであるとき、可動のノードはBinding UpdateメッセージにCGAパラメタを含んでいます。 これは、従来と同様1つ以上のCGA ParametersオプションとSignatureオプションをメッセージに追加することによって、達成されます。
The authenticator for the Binding Update message is calculated based on a permanent or temporary home keygen token. Which type of home keygen token the mobile node uses in calculating the authenticator depends on the authentication method:
Binding Updateメッセージのための固有識別文字は永久的であるか一時的な家のkeygen象徴に基づいて計算されます。 可動のノードが固有識別文字について計算する際にどのタイプの家の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 Binding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいて認証されることであるなら、可動のノードは通信員ノードから仮設住宅keygen象徴を使用しなければなりません。 可動のノードが通信員ノードのためのBinding Update Listエントリーに既に仮設住宅の有効なkeygen象徴を持っているかもしれませんか、またはそれはホームTest InitメッセージとホームTestメッセージの交換を通して1つを検索するかもしれません。
Arkko, et al. Standards Track [Page 13] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[13ページ]RFC4866
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 Binding Updateメッセージが認証されることであるなら、永久的な家のkeygen象徴に、可動のノードが永久的な家を使用しなければならないという可動のノードの知識の証拠で、keygen象徴は通信員ノードのためのBinding Update Listエントリーでそうしました。
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 Binding Updateメッセージが可到達性の証拠を通してホームアドレスで認証されることであるなら、可動のノードは通信員ノードから仮設住宅keygen象徴を使用しなければなりません。 従来と同様、可動のノードが通信員ノードのためのBinding Update Listエントリーに既に仮設住宅の有効なkeygen象徴を持っているかもしれませんか、またはそれはホームTest InitメッセージとホームTestメッセージの交換を通して1つを検索するかもしれません。
Unless the purpose of the Binding Update message is to delete an existing binding at the correspondent node, the authenticator is also calculated based on a care-of keygen token. The mobile node selects this as follows:
また、固有識別文字がBinding Updateメッセージの目的が通信員ノードで既存の結合を削除しないことであるなら、ベースで計算される、オンである、注意、-、keygen象徴 可動のノードは以下の通りこれを選択します:
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 aが可動のノードで有効になる、注意、-、象徴をkeygenする、-いてください、-、登録、注意、-、通信員ノードのためのBinding Update Listエントリーにおけるアドレス、可動のノードはBinding Updateメッセージのために固有識別文字について計算する際にこれを使用しなければなりません。 この場合、Binding Updateメッセージは「完全」です。
o If the mobile node does not have a valid care-of keygen token in
its Binding Update List entry for the correspondent node, the
mobile node SHOULD define the care-of keygen token to be zero and
use this in calculating the authenticator for the Binding Update
message. The Binding Update message is in this case "early".
o aが可動のノードで有効にならない、注意、-、通信員ノード、SHOULDが定義する可動のノードのためのBinding Update Listエントリーにおけるkeygen象徴、注意、-、ゼロであり、Binding Updateメッセージのために固有識別文字について計算する際にこれを使用するkeygen象徴。 Binding Updateメッセージはこの場合、「早くに」ということです。
o If the mobile node does not have a valid care-of keygen token in
its Binding Update List entry for the correspondent node, the
mobile node MAY choose to retrieve a care-of keygen token through
the exchange of a Care-of Test Init message and a Care-of Test
message, as defined in [1], without sending an early Binding
Update message. In this case, the mobile node waits for receipt
of the Care-of Test message and uses the care-of
keygen token contained therein in calculating the authenticator
for a complete Binding Update message. This approach increases
the handoff latency, however, and is therefore NOT RECOMMENDED.
o 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. この場合可動のノードが領収書を待つ、Care、-、Testメッセージと用途、注意、-、そこに完全なBinding Updateメッセージのために固有識別文字について計算する際に含まれたkeygen象徴。 このアプローチは、しかしながら、移管潜在を高めて、したがって、NOT RECOMMENDEDです。
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
減少している移管遅れ、SHOULDが同時に家と通信員登録証明書を開始する可動のノード、事項、注意、-、アドレス また、家のリンクから離れている間、モバイルIPv6サービスを中止したいなら、可動のノードSHOULDは平行な家と通信員「反-登録証明書」を追求します。 しかしながら、可動のノードがいつ家を遂行するか、そして、家に帰って戻った後の通信員「反-登録証明書」はローミングの期間の後にリンクします、可動
Arkko, et al. Standards Track [Page 14] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[14ページ]RFC4866
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.
ノードは最初に家の反登録を開始しなければなりません、そして、それは通信員反登録を開始する前にうまくいっている家の反登録を示すBinding Acknowledgmentメッセージを待たなければなりません。 この振舞いは、家のリンクの上に可動のノードがありますが、家のエージェントが可動のノードのホームアドレスをどんなプロキシにもしないのを確実にします、したがって、Duplicate Address Detectionの間、可動のノードと家のエージェントの間の干渉を防いで。 家の反登録が可動のノードが家のリンクからそれにつきまとうリンク地方の往復の時だけを費やすので、通信員反登録と共に増加する移管遅れに関してそれをparallelizingしない費用は通常取るにたらないです。
Moreover, when the Binding Update message for the correspondent registration is to be authenticated based on the CGA property of the mobile node's home address or through a proof of reachability at the home address, the mobile node SHOULD initiate the exchange of Home Test Init and Home Test messages prior to handoff in order to proactively elicit a fresh home keygen token from the correspondent node. This reduces handoff delays further. A Home Test Init message may be sent periodically whenever the home keygen token previously acquired from the correspondent node is about to expire. Tokens are valid for 3.5 minutes [1], so the interval between successive Home Test Init messages should be a little less. Alternatively, the mobile node may be able to send the Home Test Init message right in time if its link layer provides a trigger announcing imminent handoff. Proactive home address tests are technically feasible because a home address does not change across handoffs.
そのうえ、通信員登録へのBinding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいたホームアドレスにおける可到達性の証拠を通して認証されることであるときに、可動のノードSHOULDは、移管の前に通信員ノードから新鮮な家のkeygen象徴を予測して引き出すためにホームTest InitとホームTestメッセージの交換を起こします。 これは移管遅れをさらに減少させます。 以前に通信員ノードから入手された家のkeygen象徴が期限が切れようとしているときはいつも、定期的にホームTest Initメッセージを送るかもしれません。 3.5分[1]に、象徴が有効であるので、連続したホームTest Initメッセージの間隔はもう少しであるべきではありません。 あるいはまた、リンクレイヤが差し迫っている移管を発表する引き金を提供するなら、可動のノードは時間内に正しいホームTest Initメッセージを送ることができるかもしれません。 ホームアドレスがhandoffsの向こう側に変化しないので、先を見越すホームアドレステストは技術的に可能です。
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.
可動のノードが家のリンクからホームアドレステストを開始するなら、それは直接通信員ノードにホームTest Initメッセージを記述しなければなりません。 そして、直接通信員ノードからホームTestメッセージを受け取るでしょう。 ホームアドレステストが訪問されたリンクから開始されるなら、可動のノードはホームTest Initメッセージに家のエージェントにトンネルを堀らなければなりません。 そして、ホームTestメッセージは家のエージェントによる可動のノードにトンネルを堀って戻されるでしょう。 これ以来SHOULD NOTが本国登録か家の反登録に重ね合わせるホームアドレステストはホームTest InitかホームTestメッセージの損失をもたらすかもしれません。
If the Binding Update message is early, the mobile node MUST add a Care-of Test Init option (see Section 5.4) to the message, requesting the correspondent node to return a new care-of keygen token. The Care-of Test Init option MUST follow the CGA Parameters and Signature options, if those exist in the Binding Update message. Once a responding Binding Acknowledgment message with a Care-of Test option (see Section 5.5) is received, the mobile node MUST use the care-of
Binding Updateメッセージが初期であるなら、可動のノードがaを加えなければならない、Care、-、Test Initはメッセージにゆだねます(セクション5.4を見ます)、新しい状態でaを返すよう通信員ノードに要求して注意、-、keygen象徴。 Care、-、Test InitオプションはCGA ParametersとSignatureオプションに続かなければなりません、ものがBinding Updateメッセージに存在しているなら。 かつてのaがある応じているBinding Acknowledgmentメッセージ、Care、-、Testオプション(セクション5.5を見る)が受け取られている、可動のノードが使用しなければならない、注意、-
Arkko, et al. Standards Track [Page 15] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[15ページ]RFC4866
keygen token contained therein in calculating the authenticator for a complete Binding Update message and send this message to the correspondent node.
keygen象徴は、そこに完全なBinding Updateのための固有識別文字について計算する際にメッセージを含んでいて、このメッセージを通信員ノードに送ります。
If the Binding Update message is authenticated based on the CGA property of the mobile node's home address, the mobile node MAY add a CGA Parameters Request option (see Section 5.6) to the Binding Update message so as to request the correspondent node to prove ownership of its IP address within the Binding Acknowledgment message. This ownership proof enables the mobile node to verify that the permanent home keygen token returned in the Binding Acknowledgment message was generated by the right correspondent node.
Binding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいて認証されるなら、可動のノードは、Binding Acknowledgmentメッセージの中でIPアドレスの所有権を立証するよう通信員ノードに要求するために、CGA Parameters Requestオプション(セクション5.6を見る)をBinding Updateメッセージに追加するかもしれません。 この所有権証拠は、可動のノードが、Binding Acknowledgmentメッセージで返された永久的な家の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 Indicesオプション[1]を使用するBinding Updateメッセージでのkeygen象徴。 その結果、家の一回だけインデックスは以下の通り決定しています:
o If the Binding Update message is to be authenticated based on the
CGA property of the mobile node's home address, the mobile node
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 Binding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいて認証されることであるなら、可動のノードは、Binding Updateメッセージ、および一回だけのインデックスがそうしなければならない関連家への固有識別文字が家のkeygen象徴が入手されたホームTestメッセージから抜粋されると見込むのに仮設住宅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
home nonce index MUST be set to zero.
o Binding Updateメッセージが永久的な家の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
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 Binding Updateメッセージが可動のノードの可到達性の証拠を通してホームアドレスで認証されることであるなら、可動のノードは、Binding Updateメッセージ、および一回だけのインデックスがそうしなければならない関連家への固有識別文字が家のkeygen象徴が入手されたホームTestメッセージから抜粋されると見込むのに仮設住宅keygen象徴を使用します。
The care-of nonce index is determined according to the following rules:
注意、-、以下の規則に従って、一回だけのインデックスは決定しています:
o If the Binding Update message is complete, the care-of nonce index
is taken from the Care-of Test option or Care-of Test message with
which the care-of keygen token (used to calculate the
authenticator for the Binding Update message) was obtained.
o または、Binding Updateメッセージが完全であるなら注意、-、一回だけのインデックスを取る、Care、-、Testオプション、Care、-、Testが通信する、どれ、注意、-、keygen象徴(Binding Updateメッセージのために以前はよく固有識別文字について計算していた)を入手したか。
o If the Binding Update message is early, the care-of nonce index
MUST be set to zero.
o Binding Updateメッセージが初期であるなら注意、-、一回だけのインデックスをゼロに設定しなければなりません。
Arkko, et al. Standards Track [Page 16] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[16ページ]RFC4866
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 Binding Updateメッセージの目的が通信員ノードで結合を削除することであるなら注意、-、一回だけのインデックスをゼロに設定しなければなりません。
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 IndicesオプションはCGA Parametersに続きます、Signature、Care、-、Test Init、CGA Parameters Requestオプションがそれらであるならまた、Binding Updateメッセージに含まれています。
The mobile node finally calculates an authenticator for the Binding Update message based on the selected home and care-of keygen tokens, following the rules described in Section 5.2 and Section 6.2.7 of [1]. For a Binding Update message that requests the deletion of an existing binding at the correspondent node, the authenticator is calculated based on only a home keygen token, and it does not incorporate a care-of keygen token. The authenticator is placed into the Authenticator field of a Binding Authorization Data option [1], which the mobile node adds to the Binding Update message as the last option.
そして、可動のノードが選択された家に基づくBinding Updateメッセージのために最終的に固有識別文字について計算する、注意、-、keygen象徴、約束を守るのは[1]のコネセクション5.2とセクション6.2.7について説明しました。 通信員ノードで既存の結合の削除を要求するBinding Updateメッセージに関しては固有識別文字が家のkeygen象徴だけに基づいて計算されて、盛込まない、注意、-、keygen象徴 固有識別文字はBinding Authorization Dataオプション[1]のAuthenticator分野に置かれます。(可動のノードは最後のオプションとしてBinding Updateメッセージにオプションを追加します)。
Mobile node Home agent Correspondent node
| | |
| | |
~ Handoff | |
| | |
|-Binding Update--------->| |
|-Care-of Test Init-------------------------------->|
| | |
| | |
|<------------Binding Ack-| |
|<-------------------------------------Care-of Test-|
| | |
| | |
|-Binding Update----------------------------------->|
| | |
| | |
|<--------------------------------------Binding Ack-|
| | |
モバイルノードホームエージェントCorrespondentノード| | | | | | ~ 移管| | | | | |-拘束力があるアップデート--------->|、| |-注意、-、イニットをテストしてください。-------------------------------->|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、--Ackを縛ります。| | |<-------------------------------------注意、-、試しに。| | | | | | | |-拘束力があるアップデート----------------------------------->|、|、|、|、|、|、| |<--------------------------------------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
図3を通した図1の時間シーケンス線図はいくつかの選択された交換処理に基づくEnhanced Route Optimizationの操作を例証します。 早めのBinding Updateメッセージが永久的な家のkeygen象徴に関する可動のノードの知識の証拠によって認証されるところに図1は通信員登録と交換されたメッセージを示しています。 Care、-、早さのTest Initオプション
Arkko, et al. Standards Track [Page 17] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[17ページ]RFC4866
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.
拘束力があるUpdateメッセージが、aを新たに通信させるようにBinding Acknowledgmentに言い足すよう通信員ノードに要求する、注意、-、象徴をkeygenする、Care、-、Testオプション 可動のノードは完全なBinding Updateメッセージで最終的に通信員登録を結論づけます。 図2は、Binding Updateメッセージがどこで可到達性の証拠でホームアドレスで認証されるかを通信員登録の手順に示します。 ホームアドレステストは移管の前に予測して実行されます、可動のノードが移管直後Binding Updateメッセージを発行することを許可して。 そして、Binding Updateメッセージが再び初期である、注意、-、keygen象徴、Binding Acknowledgmentメッセージに伴う可動のノードに渡します。 そして、可動のノードが初めは新たにaを得るところに図3が通信員登録について表現する、注意、-、ひたむきな交換による象徴をkeygenする、Care、-、Test Init、Care、-、Testメッセージ。 それは次に、ホームアドレスのCGAの特性で認証される完全なBinding Updateメッセージを発行します。
4.2. Receiving Binding Update Messages
4.2. 拘束力があるアップデートメッセージを受け取ります。
When the correspondent node receives a Binding Update message, it must first verify whether the sending mobile node is the legitimate owner of the home address specified in the message. The correspondent node selects the authentication method based on the home nonce index given in the Nonce Indices option of the Binding Update message, and on the existence of CGA Parameters and Signature options in the Binding Update message:
通信員ノードがBinding Updateメッセージを受け取るとき、それは、最初に、送付の可動のノードがメッセージで指定されたホームアドレスの正統の所有者であるかどうか確かめなければなりません。 通信員ノードはBinding UpdateメッセージのNonce Indicesオプションと、Binding UpdateメッセージにおけるCGA ParametersとSignatureオプションの存在の上で与えられた家の一回だけインデックスに基づく認証方法を選択します:
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 家の一回だけであるなら、インデックスは非ヌル値に設定されます、そして、Binding UpdateメッセージはSignatureオプションがあとに続いた1つ以上のCGA Parametersオプションを含んでいます、そして、通信員ノードは可動のノードのホームアドレスのCGAの特性に基づくBinding Updateメッセージを認証しなければなりません。
o If the home nonce index is zero and the Binding Update message
does not include one or more CGA Parameters options followed by a
Signature option, the correspondent node MUST authenticate the
Binding Update message by a proof of the mobile node's knowledge
of a permanent home keygen token.
o 家の一回だけであるなら、インデックスはゼロです、そして、Binding UpdateメッセージはSignatureオプションがあとに続いた1つ以上のCGA Parametersオプションを含んでいません、そして、通信員ノードは永久的な家のkeygen象徴に関する可動のノードの知識の証拠でBinding Updateメッセージを認証しなければなりません。
o If the home nonce index is set to a non-null value and the Binding
Update message does not include one or more CGA Parameters options
followed by a Signature option, the correspondent node MUST
authenticate the Binding Update message through a proof of the
mobile node's reachability at the home address.
o 家の一回だけであるなら、インデックスは非ヌル値に設定されます、そして、Binding UpdateメッセージはSignatureオプションがあとに続いた1つ以上のCGA Parametersオプションを含んでいません、そして、通信員ノードは可動のノードの可到達性の証拠を通してホームアドレスでBinding Updateメッセージを認証しなければなりません。
Arkko, et al. Standards Track [Page 18] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[18ページ]RFC4866
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]で指定されたBinding Updateメッセージのための合法化手順に加えて、通信員ノードは不適当に認証されるBinding Updateメッセージを拒絶するために追加方法を以下まで採らなければなりません:
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 Binding Updateメッセージが1つを含んでいるか、Signatureオプションがあとに続いたオプションと家の一回だけが索引をつけるより多くのCGA Parametersがゼロであるなら、通信員ノードはステータスコード150(「一回だけのインデックスが予想した非ヌルの家」)があるBinding Acknowledgmentメッセージを送らなければなりません。 これは、また、可動のノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージがホームアドレスで可動のノードの可到達性の証拠を提供しなければならないのを確実にします。
o If the Binding Update message is to be authenticated by a proof of
the mobile node's knowledge of a permanent home keygen token, the
correspondent node MUST verify that it has a Binding Cache entry
for the mobile node that includes a permanent home keygen token.
In case the correspondent node does not have a Binding Cache entry
for the mobile node, or if the existing Binding Cache entry for
the mobile node does not include a permanent home keygen token,
the correspondent node MUST reject the Binding Update message by
sending a Binding Acknowledgment message with status code 147
("Permanent home keygen token unavailable").
o Binding Updateメッセージが永久的な家のkeygen象徴に関する可動のノードの知識の証拠によって認証されることであるなら、通信員ノードは、それには永久的な家のkeygen象徴を含んでいる可動のノードのためのBinding Cacheエントリーがあることを確かめなければなりません。 可動のノードのための既存のBinding Cacheエントリーが永久的な家のkeygen象徴を含んでいないなら通信員ノードには可動のノードのためのBinding Cacheエントリーがないといけないので、通信員ノードはステータスコード147(「入手できない永久的な家のkeygen象徴」)でBinding Acknowledgmentメッセージを送ることによって、Binding Updateメッセージを拒絶しなければなりません。
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 Binding Updateメッセージが可動のノードの可到達性の証拠を通してホームアドレスで認証されることであるなら、通信員ノードは、可動のノードのためのBinding Cacheエントリーに永久的な家のkeygen象徴を持っていないことを確かめなければなりません。 通信員ノードが可動のノードのためのBinding Cacheエントリーに永久的な家のkeygen象徴を持っているなら、それは、ステータスコード149でBinding Acknowledgmentメッセージを送ることによって、Binding Updateメッセージを拒絶しなければなりません(「永久的な家の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:
Binding Updateメッセージのための固有識別文字は永久的であるか一時的な家のkeygen象徴に基づいて計算されます。 それがどのタイプについて家の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 Binding Updateメッセージが可動のノードのホームアドレスの特性、通信員ノードがそうしなければならないCGAに基づいて認証されることであるなら、仮設住宅keygen象徴が(非ヌルの)家の一回だけインデックスでBinding Updateメッセージ、およびそれのNonce Indicesオプションで定義したrecomputeはメッセージの固有識別文字を有効にする際にこの再計算された象徴を使用しなければなりません。
Arkko, et al. Standards Track [Page 19] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[19ページ]RFC4866
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 Binding Updateメッセージが永久的な家のkeygen象徴に関する可動のノードの知識の証拠によって認証されることであるなら、通信員ノードは可動のノードに、Binding Updateメッセージの固有識別文字を有効にする際にそれがBinding Cacheエントリーに持っている永久的な家の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 通信員ノードはBinding Updateメッセージがホームアドレスで可動のノードの可到達性の検証で認証されることであるなら、仮設住宅keygen象徴が(非ヌルの)家の一回だけインデックスでBinding UpdateメッセージのNonce Indicesオプションで定義して、メッセージの固有識別文字を有効にして、それがこの再計算された象徴を使用しなければならないrecomputeを認証されなければなりません。
Unless the purpose of the Binding Update message is to delete an existing binding at the correspondent node, the authenticator is also calculated based on a care-of keygen token. Which care-of keygen token the correspondent node uses in validating the authenticator depends on whether the Binding Update message is complete or early:
また、固有識別文字がBinding Updateメッセージの目的が通信員ノードで既存の結合を削除しないことであるなら、ベースで計算される、オンである、注意、-、keygen象徴 どれ、注意、-、通信員ノードが固有識別文字を有効にする際に使用するkeygen象徴はBinding Updateメッセージが完全であるか初期であるかよります:
o If the care-of nonce index in the Nonce Indices option of the
Binding Update message is set to a non-null value, the Binding
Update message is complete. In this case, the correspondent node
MUST recompute the care-of keygen token that is identified by the
care-of nonce index, and it MUST use this recomputed token in
validating the authenticator of the message.
o 注意、-、Binding UpdateメッセージのNonce Indicesオプションにおける一回だけのインデックスは非ヌル値に設定されて、Binding Updateメッセージは完全です。 この場合通信員ノードが再計算しなければならない、注意、-、それが特定されるkeygen象徴、注意、-、一回だけは索引をつけて、中でメッセージの固有識別文字を有効にして、それはこの再計算された象徴を使用しなければなりません。
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 注意、-、Binding UpdateメッセージのNonce Indicesオプションにおける一回だけのインデックスがゼロである、Binding Updateメッセージは初期です。 注意、-、この場合通信員ノードによってBinding Updateメッセージの固有識別文字を有効にする際に使用されるべき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].
そして、通信員ノードが最終的に選択された家に基づくBinding Updateメッセージの固有識別文字を有効にする、注意、-、keygen象徴、アルゴリズムに従うと、[1]のコネセクション9.5.1は説明されました。
If the validation fails, the correspondent node MUST discard the Binding Update message. The correspondent node may have to send a Binding Acknowledgment message with a status code indicating the failure, as described in [1].
合法化が失敗するなら、通信員ノードはBinding Updateメッセージを捨てなければなりません。 通信員ノードはステータスコードが失敗を示しているBinding Acknowledgmentメッセージを送らなければならないかもしれません、[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
Binding Updateメッセージにおける、固有識別文字の合法化が成功すれば、通信員ノードが登録する、可動のノードが新しい、注意、-、アドレス、既存のBinding Cacheエントリーをアップデートして、1つが存在しているか、そして、または新しいBinding Cacheエントリーを作成すること。 結合のために与えられた寿命はBinding UpdateメッセージのLifetime分野で可動のノードによって要求された生涯によります。
Arkko, et al. Standards Track [Page 20] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[20ページ]RFC4866
and the method by which the Binding Update message is authenticated. If the Binding Update message is authenticated based on the CGA property of the mobile node's home address or by a proof of the mobile node's knowledge of a permanent home keygen token, the lifetime for the binding SHOULD be set to the maximum of MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime field of the Binding Update message. If the Binding Update message is authenticated through a proof of the mobile node's reachability at the home address, then the lifetime for the binding SHOULD be set to the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in the Lifetime field of the Binding Update message. The correspondent node may in either case grant a further reduced lifetime, but it MUST NOT accept a higher lifetime.
そして、Binding Updateメッセージが認証される方法。 _Binding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいて認証されるか、永久的な家のkeygen象徴、拘束力があるSHOULDのための生涯に関する可動のノードの知識の証拠によるマックス_CGAの最大へのセットであるなら、BINDING_LIFETIMEと値はBinding UpdateメッセージのLifetime分野で指定しました。 拘束力があるSHOULDのために、マックス_RR_BINDING_LIFETIME[1]の最大に設定されて、Binding Updateメッセージは次に、ホームアドレス、生涯、可動のノードの可到達性の証拠を通して認証されます。値はBinding UpdateメッセージのLifetime分野で指定しました。 通信員ノードはどちらの場合でもさらなる減少している生涯を与えるかもしれませんが、それは、より高い生涯を受け入れてはいけません。
The state of the new care-of address depends on whether the Binding Update message is complete or early:
新しさの状態、注意、-、アドレスはBinding Updateメッセージが完全であるか初期であるかよります:
o If the Binding Update message is complete, the new care-of address
is set to VERIFIED state. The correspondent node may then
immediately send packets to the new care-of address without
restrictions.
o Binding Updateメッセージが完全であるなら新しさ、注意、-、アドレスはVERIFIED状態に設定されます。 次に、通信員ノードがすぐにパケットを新しさに送るかもしれない、注意、-、制限のないアドレス。
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 Binding Updateメッセージが初期であるなら新しさ、注意、-、アドレスはUNVERIFIED状態に設定されます。 次に、通信員ノードが送付パケットのためにセクション4.10でこれと定義されていた状態で規則に従わなければならない、注意、-、アドレス、注意、-、アドレス、VERIFIED状態では、設定されます。
If the Binding Update message contains one or multiple CGA Parameters options, the mobile node is requesting the correspondent node to accept the included CGA parameters either for establishing a new, or for renewing an existing permanent home keygen token shared between the mobile node and the correspondent node. The correspondent node MUST in this case check if the CGA Parameters options are directly followed by a Signature option and, if so, validate the CGA parameters and signature as described in Section 4.6.
Binding Updateメッセージが1か複数のCGA Parametersオプションを含んでいるなら、可動のノードは、新しい状態でaを設立するか、または可動のノードと通信員ノードの間で共有された既存の永久的な家のkeygen象徴を取り替えるための含まれているCGAパラメタを受け入れるよう通信員ノードに要求しています。 通信員ノードは、この場合Signatureオプションが直接CGA Parametersオプションのあとに続くかどうかチェックしなければなりません、そして、そうだとすれば、セクション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.
Signatureオプションが直接CGA Parametersオプションのあとに続いていないか、または含まれているCGAパラメタと署名の合法化が失敗するなら、通信員ノードは、ステータスコード148(「CGAと署名照合は失敗した」)と共に可動のノードにBinding Updateメッセージを捨てて、Binding Acknowledgmentメッセージを送らなければなりません。
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
Signatureオプションに署名を含んでいるのが正しければ、通信員ノードは、可動のノードと共有されるために永久的な家のkeygen象徴を発生させて、可動のノードのためにBinding Cacheエントリーにそれを格納します。 永久的な家のkeygen象徴はそうです。
Arkko, et al. Standards Track [Page 21] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[21ページ]RFC4866
sent to the mobile node within a Binding Acknowledgment message as described in Section 4.3.
セクション4.3で説明されるようにBinding Acknowledgmentメッセージの中の可動のノードに発信しました。
4.3. Sending Binding Acknowledgment Messages
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:
有効なBinding Updateメッセージを受け取り次第、通信員ノードは以下のケースのどれかのBinding Acknowledgmentメッセージを可動のノードに返します:
o The Acknowledge flag in the Binding Update message is set.
o Binding UpdateメッセージのAcknowledge旗は設定されます。
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 Signatureオプションで複数のCGA Parametersオプションが直接続きました、そして、Binding Updateメッセージが1つを含んでいるか、または後者に署名を含んでいるのは正しいことを決定していました。
o The Binding Update message is early and includes a Care-of Test
Init option.
o Binding Updateメッセージが早く、aを含んでいる、Care、-、Test Initオプション。
If the Binding Update message further contains a CGA Parameters Request option and the correspondent node's IP address is a CGA, the correspondent node MUST include its CGA parameters and signature in the Binding Acknowledgment message by adding one or more CGA Parameters options directly followed by a Signature option. The correspondent node's CGA parameters and signature enable the mobile node to verify that the permanent home keygen token received in the Binding Acknowledgment message was generated by the right correspondent node. If the Binding Update message contains a CGA Parameters Request option, but the correspondent node's IP address is not a CGA, the correspondent node ignores the CGA Parameters Request option and processes the Binding Update message further as described below.
Binding UpdateメッセージがさらにCGA Parameters Requestオプションを含んでいて、通信員ノードのIPアドレスがCGAであるなら、Signatureオプションで1つ以上のCGA Parametersオプションが直接続いたと言い足すことによって、通信員ノードはBinding AcknowledgmentメッセージにそのCGAパラメタと署名を含まなければなりません。 通信員ノードのCGAパラメタと署名は、可動のノードが、Binding Acknowledgmentメッセージに受け取られた永久的な家のkeygen象徴が正しい通信員ノードで発生したことを確かめるのを可能にします。 Binding UpdateメッセージがCGA Parameters Requestオプションを含んでいますが、通信員ノードのIPアドレスがCGAでないなら、通信員ノードは、CGA Parameters Requestオプションを無視して、さらに以下で説明されるようにBinding Updateメッセージを処理します。
If the Binding Update message contains one or multiple CGA Parameters options directly followed by a Signature option, and the signature included in the latter was determined to be correct, the correspondent node MUST add a Permanent Home Keygen Token option (see Section 5.3) with a new permanent home keygen token to the Binding Acknowledgment message. The correspondent node also stores this permanent home keygen token in its Binding Cache entry for the mobile node.
Binding Updateメッセージが1か複数のCGA Parametersを含んでいるなら、Signatureオプションでオプションは直接続きました、そして、後者に署名を含んでいるのが正しいことを決定していた、通信員ノードは新しい永久的な家のkeygen象徴でPermanentホームKeygen TokenオプションをBinding Acknowledgmentメッセージに追加しなければなりません(セクション5.3を見ます)。 また、通信員ノードは可動のノードのためのBinding Cacheエントリーにこの永久的な家のkeygen象徴を格納します。
If the Binding Update message includes a Care-of Test Init option, the correspondent node MUST append to the Binding Acknowledgment message a Care-of Test option with a pseudo-random value in the Care-of Keygen Token field. The Care-of Test option MUST appear after the Permanent Home Keygen Token option in case both options are present in the Binding Acknowledgment message.
Binding Updateメッセージが含んでいる、Care、-、Test Initオプション、対応であっているノードがメッセージをBinding Acknowledgmentに追加しなければならない、Care、-、Testオプション、中の擬似ランダム値、Care、-、Keygen Token分野。 Care、-、両方のオプションがBinding Acknowledgmentメッセージに存在しているといけないので、TestオプションはPermanentホームKeygen Tokenオプションの後に現れなければなりません。
Arkko, et al. Standards Track [Page 22] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[22ページ]RFC4866
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].
最後のオプションとしてBinding Authorization DataオプションをBinding Acknowledgmentメッセージに追加しなければなりません、[1]についてセクション5.2とセクション6.2.7で説明されるように。
4.4. Receiving Binding Acknowledgment Messages
4.4. 拘束力がある承認メッセージを受け取ります。
A mobile node first verifies a received Binding Acknowledgment message according to the rules specified in [1]. Provided that the Binding Acknowledgment message is not rejected based on these rules, the mobile node takes the following additional steps.
[1]で指定された規則に従って、可動のノードは最初に、受信されたBinding Acknowledgmentメッセージについて確かめます。 Binding Acknowledgmentメッセージがこれらの規則に基づいて拒絶されなければ、可動のノードは追加方法を以下まで採ります。
If the mobile node included a CGA Parameters Request option in the Binding Update message and the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node first processes any CGA Parameters and Signature options in the Binding Acknowledgment message in the following manner. If the Binding Acknowledgment message contains one or more CGA Parameters options that are directly followed by a Signature option, the mobile node MUST check the ownership of the correspondent node's IP address by verifying the included CGA parameters and signature as described in Section 4.6. If the validation of the CGA parameters and signature fails, the mobile node MUST silently discard the Binding Acknowledgment message. The mobile node MUST also silently discard the Binding Acknowledgment message if the message includes one or more CGA Parameters options that are not directly followed by a Signature option, or if the Binding Acknowledgment message lacks any CGA Parameters options in the presence of a Signature option.
可動のノードがBinding UpdateメッセージにCGA Parameters Requestオプションを含んで、Binding AcknowledgmentメッセージがPermanentホームKeygen Tokenオプションを含んでいて、可動のノードが最初に以下の方法でBinding AcknowledgmentメッセージにおけるどんなCGA ParametersとSignatureオプションも処理するなら。 Binding AcknowledgmentメッセージがSignatureオプションが直接あとに続く1つ以上のCGA Parametersオプションを含んでいるなら、可動のノードは、セクション4.6で説明されるように含まれているCGAパラメタと署名について確かめることによって、通信員ノードのIPアドレスの所有権をチェックしなければなりません。 CGAパラメタと署名の合法化が失敗するなら、可動のノードは静かにBinding Acknowledgmentメッセージを捨てなければなりません。 また、メッセージがSignatureオプションが直接あとに続かない1つ以上のCGA Parametersオプションを含んでいるか、またはBinding AcknowledgmentメッセージがSignatureオプションがあるとき何かCGA Parametersオプションを欠いているなら、可動のノードは静かにBinding Acknowledgmentメッセージを捨てなければなりません。
If the mobile node did not include a CGA Parameters Request option in the Binding Update message or the Binding Acknowledgment message does not contain a Permanent Home Keygen Token option, the mobile node ignores any CGA Parameters and Signature options that the Binding Acknowledgment message may contain. Careful use of the CGA Parameters Request option in Binding Update messages enables the mobile node to control the processing resources it spends on the verification of a correspondent node's CGA as well as to disable such verification in the case of persistent verification failures, which may be due to misconfigured or outdated CGA software [12] on the correspondent node side or at the mobile node itself. Specifically, if the mobile node repeatedly fails to receive a Binding Acknowledgment message including valid CGA Parameters and Signature options in response to sending a Binding Update message with a CGA Parameters Request option, the mobile node SHOULD refrain from including a CGA Parameters Request option in future Binding Update messages for the same correspondent node.
可動のノードがBinding UpdateメッセージにCGA Parameters Requestオプションを含んでいなかったか、そして、Binding AcknowledgmentメッセージがPermanentホームKeygen Tokenオプションを含んでいなくて、可動のノードはBinding Acknowledgmentメッセージが含むかもしれないどんなCGA ParametersとSignatureオプションも無視します。 Binding UpdateメッセージにおけるCGA Parameters Requestオプションの慎重な使用は、可動のノードがそれが通信員ノードのCGAの検証に費やす処理リソースを制御して、通信員ノード側の上、または、可動のノード自体のmisconfiguredされたか時代遅れのCGAソフトウェア[12]のためであるかもしれないしつこい検証失敗の場合でそのような検証を無効にするのを可能にします。 明確に、可動のノードが繰り返してCGA Parameters Requestオプションと共にBinding Updateメッセージを送ることに対応して有効なCGA ParametersとSignatureオプションを含むBinding Acknowledgmentメッセージを受け取らないなら、可動のノードSHOULDは、同じ通信員ノードへの将来のBinding UpdateメッセージにCGA Parameters Requestオプションを含んでいるのを控えます。
Arkko, et al. Standards Track [Page 23] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[23ページ]RFC4866
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.
可動のノードがBinding UpdateメッセージにCGA Parameters Requestオプションを含んでいましたが、Binding Acknowledgmentメッセージが少しのCGA ParametersやSignatureオプションも含んでいなくて、可動のノードが通信員ノードのIPアドレスが単にCGAでないかどうかかそれともBinding Acknowledgmentメッセージが経路に攻撃者から可動のノードから通信員ノードまで発するかどうかを確信しているはずがないなら。 経路の攻撃者から永久的な家のkeygen象徴を受け入れるのを避けるために、可動のノードはBinding Acknowledgmentメッセージの上でそのようなオプションなしで有効なCGA Parametersを含んでいるBinding AcknowledgmentメッセージとSignatureオプションに優先権を与えなければなりません。 可動のノードがこの点で従う1つの可能なアルゴリズムがいつもこのメッセージが有効なCGA ParametersかSignatureオプションを含んでいないなら最初に受け取られたBinding Acknowledgmentメッセージを受け入れることであり、このその後のBinding Acknowledgmentメッセージを支持して最初のBinding Acknowledgmentを受け入れるのにかかわるどんな州の変化も振り向けるために後でそのようなオプションを含む別のBinding Acknowledgmentメッセージを受け取ります。 有効なCGA ParametersとSignatureオプションと共にBinding Acknowledgmentメッセージの上でそのようなオプションなしでBinding Acknowledgmentメッセージに優先権を与えるのは、可動のノードがCGAを使用しない通信員ノードとコミュニケートするのを可能にして、同時に、経路のほとんどの攻撃者から守ります。 戦略は通信員ノードからのBinding Acknowledgmentメッセージを傍受できる攻撃者から守りませんが、そのような攻撃者はとにかく可動のノードと通信員ノードの間の移動性管理を排除できました。 可動のノードが永久に有効なCGA ParametersとSignatureオプションなしでBinding Acknowledgmentメッセージを受け入れたとき、可動のノードSHOULDは、同じ通信員ノードへの将来のBinding UpdateメッセージにCGA Parameters Requestオプションを含んでいるのを控えます。
If the Binding Acknowledgment message contains a Permanent Home Keygen Token option, the mobile node extracts the permanent home keygen token included in this option and stores it in its Binding Update List entry for the correspondent node. Future Binding Update messages will then be authenticated by a proof of the mobile node's knowledge of this permanent home keygen token.
Binding AcknowledgmentメッセージがPermanentホームKeygen Tokenオプションを含んでいるなら、可動のノードは、このオプションに含まれていた永久的な家のkeygen象徴を抽出して、通信員ノードのためのBinding Update Listエントリーにそれを格納します。 そして、将来のBinding Updateメッセージはこの永久的な家のkeygen象徴に関する可動のノードの知識の証拠によって認証されるでしょう。
If the Binding Acknowledgment message contains a Care-of Test option, the mobile node extracts the care-of keygen token included in this option, stores the token in its Binding Update List entry for the correspondent node, and sends the correspondent node a complete Binding Update message as defined in Section 4.1. Note that the complete Binding Update message will be authenticated based on the CGA property of the mobile node's home address if the Binding Acknowledgment message also includes a Permanent Home Keygen Token option. This is independent of the authentication method that was used for the corresponding early Binding Update message.
Binding Acknowledgmentメッセージが含んでいる、Care、-、Testオプション、可動のノード抽出、注意、-、keygen象徴は、通信員ノードのためのBinding Update Listエントリーでこのオプション、店で象徴を含めて、セクション4.1で定義されるように完全なBinding Updateメッセージを通信員ノードに送ります。 また、Binding AcknowledgmentメッセージがPermanentホームKeygen Tokenオプションを含んでいると完全なBinding Updateメッセージが可動のノードのホームアドレスのCGAの特性に基づいて認証されることに注意してください。 これは対応する早めのBinding Updateメッセージに使用された認証方法から独立しています。
Arkko, et al. Standards Track [Page 24] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[24ページ]RFC4866
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.
可動のノードは、通信員ノードに、あるホームアドレスのための結合を持っていますが、また、同じホームアドレスのための家のエージェントに有効な結合を持っているのを確実にしなければなりません。 これは、時には可動のノードが家のエージェントで拘束力がある生涯を広げるのを必要とするかもしれません、受入れられた最大より少ないか、または明らかにderegisterで拘束力がある生涯を費やす要求a通信員ノード。通信員ノードで拘束力がある存在。
If the mobile node authenticates Binding Update messages for a particular correspondent node by proving its knowledge of a permanent home keygen token, but registrations at this correspondent node persistently fail, the mobile node SHOULD renew the permanent home keygen token by sending a Binding Update message that is authenticated based on the CGA property of its home address. This Binding Update message includes the mobile node's CGA parameters and signature, and it requests the correspondent node to generate a new permanent home keygen token and send this to the mobile node within a Binding Acknowledgment message.
可動のノードが永久的な家のkeygen象徴に関する知識を立証することによって特定の通信員ノードへのBinding Updateメッセージを認証しますが、この通信員ノードの登録証明書が持続して失敗するなら、可動のノードSHOULDは、ホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージを送ることによって、永久的な家のkeygen象徴を取り替えます。 このBinding Updateメッセージは可動のノードのCGAパラメタと署名を含んでいます、そして、それは新しい永久的な家のkeygen象徴を発生させて、Binding Acknowledgmentメッセージの中の可動のノードにこれを送るよう通信員ノードに要求します。
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と署名照合は失敗した」)で通信員ノードからBinding Acknowledgmentメッセージを持続して受け取るなら、可動のノードSHOULDは可到達性の証拠を通してホームアドレスで同じ通信員ノードへの将来のBinding Updateメッセージを認証します。 これは、可動のノードが通信員ノード側の上、または、可動のノード自体のmisconfiguredされたか時代遅れのCGAソフトウェア[12]から回復するのを可能にします。
4.5. Sending CGA Parameters
4.5. 送付CGAパラメタ
A mobile node includes its CGA parameters and signature in a Binding Update message for a correspondent node in any of the following situations:
可動のノードは通信員ノードへのBinding Updateメッセージに以下の状況のどれかでその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 可動のノードのホームアドレスであるなら、keygen象徴は永久的な家を帯びるためには、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 広がるように、通信員ノードでの結合の可動のノードでは通信員ノードからの永久的な家のkeygen象徴が既にあるか、そして、生涯の間の既存の結合の寿命は期限が切れようとしています。
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します。
Arkko, et al. Standards Track [Page 25] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[25ページ]RFC4866
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.
CGA Parameters RequestオプションでBinding Updateメッセージを受け取るとき、IPアドレスがCGAである通信員ノードは可動のノードへのBinding Acknowledgmentメッセージにその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 Parametersデータ構造の形式で伝えられます。 CGA Parametersデータ構造はセクション5.1で説明されるように1つ以上のCGA Parametersオプションの上で分けられます。 Signatureオプションは直接最後のCGA Parametersオプションのあとに続かなければなりません。
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で定義された署名世代アルゴリズムによると、SignatureオプションにおけるSignature分野への値は計算されます。 値は可動であるか通信員ノードの秘密鍵で八重奏の以下の系列に関して計算されます:
mobility data =
care-of address | correspondent node IP address | MH data
移動性データが等しい、注意、-、アドレス| 通信員ノードIPアドレス| MHデータ
where "|" denotes concatenation. "Care-of address" is the mobile node's care-of address, and "correspondent node IP address" is the IP address of the correspondent node that is visible to protocol layers above IP. In case the correspondent node is mobile, "correspondent node IP address" refers to the correspondent node's home address. "MH data" is the content of the Binding Update or Binding Acknowledgment message including the mobility header and all options up to the last CGA Parameters option. That is, "MH data" excludes the IPv6 header and any IPv6 extension headers other than the mobility header itself. The "mobility data" constitutes what is referred to as the "message" in Section 6 of [2].
「どこ」|「連結を指示します。」 「注意、-、アドレス、」、可動のノードのもの、注意、-、アドレス、「通信員ノードIPアドレス」はIPの上の層について議定書の中で述べるのにおいて目に見える通信員ノードのIPアドレスです。 通信員ノードが可動であるといけないので、「通信員ノードIPアドレス」は通信員ノードのホームアドレスを示します。 「MHデータ」は移動性ヘッダーとすべてのオプションを最後のCGA Parametersオプションまで含むBinding UpdateかBinding Acknowledgmentメッセージの内容です。 すなわち、「MHデータ」は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.
Signature分野への値はまるで移動性ヘッダーのChecksum分野がゼロであるかのように計算されます。 伝えられたパケットのChecksum分野はまだ常法で計算されています、チェックサムによって保護されたパケットの一部である計算された値がSignature分野にある状態で。
4.6. Receiving CGA Parameters
4.6. CGAパラメタを受け取ります。
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.
Signatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含むBinding UpdateかBinding Acknowledgmentメッセージを受け取るモバイルと通信員ノードが最初に、[1]で説明されるようにメッセージを処理します。 これはBinding Authorization DataオプションのAuthenticator分野での固有識別文字の検証を含んでいます。 Binding UpdateかBinding Acknowledgmentメッセージが不正確な固有識別文字のためかいかなる他の理由のでも拒絶されるなら、メッセージはさらに処理されません。
Arkko, et al. Standards Track [Page 26] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[26ページ]RFC4866
Otherwise, if the validation of the Binding Update or Binding Acknowledgment message succeeds, the mobile or correspondent node reassembles the CGA Parameters data structure from the CGA Parameters options included in the message as described in Section 5.1, and executes the CGA verification algorithm defined in Section 5 of [2]. The CGA verification algorithm takes the to-be-verified CGA and the reassembled CGA Parameters data structure as input. The to-be- verified CGA is the mobile node's home address when the CGA verification algorithm is executed by the correspondent node. When the mobile node executes the CGA verification algorithm, the to-be- verified CGA is the correspondent node's IP address that is visible to protocol layers above IP. This is the correspondent node's home address in case the correspondent node is mobile. The following steps are skipped if the CGA verification fails.
さもなければ、Binding UpdateかBinding Acknowledgmentメッセージの合法化が成功するなら、可動であるか通信員ノードは、メッセージにオプションを含んでいて、セクション5.1で説明されるようにCGA ParametersからCGA Parametersデータ構造を組み立て直して、[2]のセクション5で定義されたCGA検証アルゴリズムを実行します。 CGA検証アルゴリズムは入力されるように確かめられたCGAと組み立て直されたCGA Parametersデータ構造を取ります。 --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検証が成功するなら、可動であるか通信員ノードは署名の、より手間がかかったチェックを実行します。 それは、SignatureオプションにおけるSignature分野から署名を抽出して、[2]のセクション6で定義された署名照合アルゴリズムを実行します。 署名照合アルゴリズムが入力されるように取る、-いてください、-、上で定義されるCGA、組み立て直されたCGA Parametersデータ構造(セクション4.5、セクション7における定義されるとしてのEnhanced Route OptimizationのCGA Message Typeタグ、および署名自体で定義されるMHデータ)について確かめます。
4.7. Sending Permanent Home Keygen Tokens
4.7. 送付の永久的なホームKeygen象徴
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 ParametersとSignatureオプションで可動のノードからBinding Updateメッセージを受け取った後に通信員ノードは新しい永久的な家のkeygen象徴を可動のノードに割り当てます、そして、これらのオプションはセクション4.6で説明されるように首尾よく有効にされました。 永久的な家のkeygen象徴は通信員ノードで手当たりしだいに発生する64ビットの値です。 通信員ノードはそれが可動のノードのために維持する拘束力があるキャッシュエントリーに永久的な家のkeygen象徴を格納します。
The correspondent node sends the permanent home keygen token to the mobile node in encrypted form within a Permanent Home Keygen Token option in a Binding Acknowledgment message. It sends this message even if the Acknowledge flag in the corresponding Binding Update message was clear. The correspondent node encrypts the permanent home keygen token with the mobile node's public key using the RSAES-PKCS1-v1_5 format [4], and places the ciphertext into the Permanent Home Keygen Token field of the Permanent Home Keygen Token option.
通信員ノードはBinding AcknowledgmentメッセージのPermanentホームKeygen Tokenオプションの中のコード化されたフォームでの可動のノードに永久的な家のkeygen象徴を送ります。 対応するBinding UpdateメッセージのAcknowledge旗が明確であったとしても、それはこのメッセージを送ります。 通信員ノードは、可動のノードの公開鍵がRSAES-PKCS1-v1_5形式[4]を使用している状態で永久的な家のkeygen象徴をコード化して、PermanentホームKeygen TokenオプションのPermanentホームKeygen Token分野に暗号文を置きます。
The Binding Authorization Data option MUST be the last option in the Binding Acknowledgment message. That is, the authenticator in the
Binding Authorization DataオプションはBinding Acknowledgmentメッセージで最後のオプションであるに違いありません。 すなわち、中の固有識別文字
Arkko, et al. Standards Track [Page 27] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[27ページ]RFC4866
Binding Authorization Data option covers the Permanent Home Keygen Token option.
拘束力があるAuthorization DataオプションはPermanentホームKeygen Tokenオプションをカバーしています。
4.8. Receiving Permanent Home Keygen Tokens
4.8. 永久的なホーム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.
Binding Acknowledgmentメッセージを受け取る可動のノードは最初に[1]で説明されるようにメッセージを処理します、メッセージがPermanentホームKeygen Tokenオプションを含んでいるかどうかの如何にかかわらず。 これはBinding Authorization DataオプションのAuthenticator分野での固有識別文字の検証を含んでいます。 Binding Acknowledgmentメッセージが不正確な固有識別文字のためかいかなる他の理由のでも拒絶されるなら、可動のノードはさらにメッセージを処理しません。
Otherwise, if the mobile node accepts the Binding Acknowledgment message and the message includes a Permanent Home Keygen Token option, the mobile node extracts the ciphertext from the Permanent Home Keygen Token field in this option and decrypts it with its private key using the RSAES-PKCS1-v1_5 format [4]. The result of the encryption is the permanent home keygen token to be used in further registrations with the correspondent node. The mobile node stores the permanent home keygen token in the Binding Update List entry that it maintains for the correspondent node.
さもなければ、可動のノードがBinding Acknowledgmentメッセージを受け入れて、メッセージがPermanentホームKeygen Tokenオプションを含んでいるなら、可動のノードは、このオプションにおけるPermanentホームKeygen Token分野から暗号文を抽出して、秘密鍵がRSAES-PKCS1-v1_5形式[4]を使用している状態で、それを解読します。 暗号化の結果は通信員ノードでさらなる登録証明書に使用されるべき永久的な家のkeygen象徴です。 可動のノードはそれが通信員ノードのために維持するBinding Update Listエントリーに永久的な家のkeygen象徴を格納します。
4.9. Renewing Permanent Home Keygen Tokens
4.9. 永久的なホーム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象徴と共に同じ一連番号を二度使用してはいけません。 可動のノードは、一連番号ロールオーバーが差し迫っているとき通信員ノードへのBinding UpdateメッセージにそのCGAパラメタと署名を含んでいることによって、永久的な家のkeygen象徴を取り替えなければなりません。 さらに、可動のノードはいつでも、永久的な家のkeygen象徴を取り替えるかもしれません。 永久的な家のkeygen象徴の周期的な更新は暗号文解読術に対する増加する保護を提供します。 最終的に、通信員ノードで付く寿命が期限が切れると、多くの場合、可動のノードは永久的な家のkeygen象徴を取り替えたがっているかもしれません。
4.10. Handling Payload Packets
4.10. 取り扱い有効搭載量パケット
The immediate exchange of an early Binding Update message after a handoff on the mobile node side enables mobile and correspondent nodes to quickly reestablish route-optimized communications via the mobile node's new care-of address. The mobile node may send payload packets to the correspondent node from the new care-of address as soon as it has dispatched the early Binding Update message. The correspondent node redirects outgoing payload packets for the mobile node to the new care-of address once it has received the early
を通して可動ノード側における移管が、可動、そして、通信員ノードがルートで最適化されたコミュニケーションをすばやく回復させるのを可能にした後に早めのBinding Updateメッセージの即座の交換、可動のノードが新しい、注意、-、アドレス 可動のノードがペイロードパケットを新しさから通信員ノードに送るかもしれない、注意、-、それの次第アドレスは早めのBinding Updateメッセージを派遣しました。 通信員ノードが可動のノードのために出発しているペイロードパケットを新しさに向け直す、注意、-、いったん早さを受けると、記述します。
Arkko, et al. Standards Track [Page 28] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[28ページ]RFC4866
Binding Update message and registered the new care-of address. Here, a "payload packet" is defined as a packet that originates at a protocol layer above IP.
拘束力があるUpdateが新しさを通信して、登録した、注意、-、アドレス。 ここで、「ペイロードパケット」はIPの上のプロトコル層で由来するパケットと定義されます。
Inbound
payload packet
|
|
V
_________________ _____________________
/ \ | |
/ Care-of address \ Yes | Increase credit |
| in |---------------------> | counter by |
\ VERIFIED state? / | payload packet size |
\_________________/ |_____________________|
| |
| |
| No |
| V
| _____________________
| | |
| | Deliver payload |
+--------------------------------> | packet to upper- |
| layer protocol |
|_____________________|
本国行きのペイロードパケット| | V_________________ _____________________ / \ | | /、注意、-、\を記述してください、はい。| クレジットを増加させてください。| | コネ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 反対してください。| VERIFIEDが述べる\? / | ペイロードパケットサイズ| \_________________/ |_____________________| | | | | | いいえ| | V| _____________________ | | | | | ペイロードを届けてください。| +-------------------------------->| 上側へのパケット| | 層のプロトコル| |_____________________|
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.
A新しい、注意、-、通信員ノードが可動のノードから完全なBinding Updateメッセージを受け取るまで、早めのBinding Updateメッセージに登録されたアドレスはUNVERIFIED状態で通信員ノードによって維持されます。 次に、通信員ノードがセットする、注意、-、VERIFIED状態へのアドレス。 状態、注意、-、アドレスが通信員ノードが発信できる最大のデータ量を測定する、注意、-、アドレス、増幅されて、防ぐのに必要であることで、そのままで、リダイレクションベースの氾濫は攻撃されます。 このために、通信員ノードはそれぞれの可動のノードのためにBinding Cacheでエントリーで「クレジットカウンタ」を維持します。 いつ、ペイロードパケットが可動のノードから到着するか、注意、-、アドレス、VERIFIED状態では、容認されたペイロードパケットのサイズに従って、通信員ノードSHOULDは可動のノードのクレジットカウンタを増加させます。 通信員ノードは、下側の値でクレジットカウンタを増加させるか、または全くクレジットを増加させないように方針によって制限されるかもしれません。 クレジットカウンタが、本国行きのペイロードパケットがいつから受け取られているかを変えない、注意、-、アドレス、UNVERIFIED状態で。 図4はこの手順のフローチャートを示しています。
Arkko, et al. Standards Track [Page 29] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[29ページ]RFC4866
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 |
|_____________________| |_____________________|
外国行きのペイロードパケット| | V_________________ _____________________ / \ | | /、注意、-、\を記述してください、はい。| ペイロードを送ってください。| | コネ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| パケット| VERIFIEDが述べる\? / | 注意、-、アドレス| \_________________/ |_____________________| | | _____________________ | いいえ| | | | ペイロードを捨ててください。| | +--------->| パケット| | | | すぐに| V| |_____________________| _________________ | _____________________ / \ | | | /クレジットカウンタ\、はい、/、\| ペイロードを送ってください。| | ペイロード以下|、-、-、-、-、-、--、>| |、-、-、-、-、-、--、>| パケット| \パケットサイズ? / \ / | ホームアドレス| \_________________/ | |_____________________| | | _____________________ | | | | | いいえ| | バッファペイロード| | +--------->| パケット| | | 後のトランスミッション| | |_____________________| V_____________________ _____________________ | | | | | クレジットを減少させてください。| | ペイロードを送ってください。| | 反対してください。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| パケット| | ペイロードパケットサイズ| | 注意、-、アドレス| |_____________________| |_____________________|
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,
通信員ノードが可動のノードに送るペイロードパケットを持っているとき、ペイロードパケットのさらなる処理を可動のノードのものの事情に依存する、注意、-、アドレスと可動のノードのクレジットの現行価値は反対します、図5で例証されるように: 通信員ノードが可動のノードのものにペイロードパケットを送らなければならない、注意、-、アドレス、注意、-、アドレス、VERIFIED状態に、あります。 注意、-、アドレス、クレジットカウンタの値は、ペイロードパケットのサイズとコネがUNVERIFIED状態であり、より高いか、または等しいです。
Arkko, et al. Standards Track [Page 30] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[30ページ]RFC4866
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.
通信員ノードがペイロードパケットのサイズに従って可動のノードのクレジットカウンタを減少させて、ペイロードパケットを送らなければならない、注意、-、また、アドレス。 しかしながら、注意、-、アドレス、ペイロードパケットのサイズ以下がUNVERIFIED状態とクレジットカウンタに、あって、ペイロードパケットに発信してはいけないということである、可動のノードのもの、注意、-、アドレス 次に、通信員ノードSHOULDはペイロードパケットを捨てます、あるいはまた、ペイロードパケットをバッファリングするかもしれませんが注意、-、VERIFIED状態に移動を記述するか、または可動のノードのホームアドレスにペイロードパケットを送ってください。 可動のノードのクレジットカウンタが、通信員ノードがいつ可動のノードのものにペイロードパケットを送るかを変えない、注意、-、アドレスがゆったり過ごす、注意、-、アドレス、VERIFIED状態に、あります。
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ヘッダーとホームアドレスのSource Address分野のIPv6 Destination Options拡張ヘッダーのホームAddressオプションにおけるアドレス。 逆もまた同様ですと、通信員ノードからのパケットが持っているすべてのペイロード、注意、-、IPv6ルート設定拡張ヘッダーのIPv6ヘッダーとホームアドレスのDestination Address分野のアドレス。
4.11. Credit Aging
4.11. クレジットの年をとること
A correspondent node ensures that all credit counters that it maintains gradually decrease over time. Each credit counter is multiplied with a factor, CreditAgingFactor, of less than one in fixed time intervals of CreditAgingInterval length. Such "credit aging" limits the total credit that a mobile node can earn, provided that the replenishing rate for the credit is constant or nearly constant. It thereby enforces an upper bound on the rate at which the correspondent node can durably sent to the mobile node's care-of address while the care-of address is in UNVERIFIED state. In the absence of credit aging, a malicious node with poor up-link capacity could adopt the role of a mobile node, build up credit at a very slow speed and over a long period, and spend this credit during a much shorter period on redirecting a burst of payload packets to the IP address of a victim.
通信員ノードは、それが徐々に維持するすべてのクレジットカウンタが時間がたつにつれて減少するのを確実にします。 それぞれのクレジットカウンタは要素、CreditAgingIntervalの長さの一定時間間隔の1未満のCreditAgingFactorと共に掛けられます。 そのような「クレジットの年をとること」は可動のノードが得ることができる総クレジットを制限します、クレジットの補給レートが一定であるか、またはほとんど一定であれば。 その結果、上限に通信員ノードが永久的にそうすることができるレートに可動のノードのものに送った状態で押しつける、注意、-、アドレスがゆったり過ごす、注意、-、アドレス、UNVERIFIED状態に、あります。 クレジットの年をとることが不在のとき、貧しいアップリンク容量がある悪意があるノードは、可動のノードの役割を採用して、非常に遅い速度において長期の上間、クレジットを確立して、はるかに短い期間、犠牲者の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
CreditAgingFactorとCreditAgingIntervalのための適切な値を選ぶのは、通信員ノードが可動のノードより高いレートで発信するアプリケーションを容易にするために重要です。 CreditAgingFactorかCreditAgingIntervalが小さ過ぎます、力がペイロードパケットのトランスミッションを持続して防ぐクレジットカウンタ、注意、-、アドレス、UNVERIFIED状態で。 与えられた値
Arkko, et al. Standards Track [Page 31] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[31ページ]RFC4866
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.
セクションでは、通信員ノードがTCP接続で可動のノードにファイルを移すとき、彼らがうまくいくとき、7はRECOMMENDEDです、そして、終わりから終わりへの往復の時間は500人のミリセカンドを超えていません。
4.12. Simultaneous Movements
4.12. 同時の運動
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]で指定されるように、可動の通信員ノードのホームアドレスにBinding Updateメッセージを送ります。 これで、それらの両方が同時にIPの接続性を変えても、2つの可動のノードがコミュニケーションを続けているのが可能になります。
5. Option Formats and Status Codes
5. オプション形式とステータスコード
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.
高められたRoute Optimizationは[1]で定義された移動性オプションとステータスコードに加えて1セットの新しい移動性オプションとステータスコードを使用します。 これらは以下で説明されます。
5.1. CGA Parameters Option
5.1. CGAパラメタオプション
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 ParametersオプションはBinding UpdateとBinding Acknowledgmentメッセージで使用されます。 それは可動であるか通信員ノードのCGAパラメタの一部を含んでいます。 Option TypeとOption Length分野を除いて、[1]は移動性ヘッダーオプションを最大255バイトの長さに制限します。 CGAパラメタがこの限界を超えていそうであるので、複数のCGA ParametersオプションがすべてのCGAパラメタを運ぶために連結されなければならないかもしれません。
The format of the CGA Parameters option is as follows:
CGA Parametersオプションの形式は以下の通りです:
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 :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : CGAパラメタ: : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value
is 12.
この移動性オプションのタイプの8ビットの識別子。 値は12です。
Arkko, et al. Standards Track [Page 32] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[32ページ]RFC4866
Option Length
オプションの長さ
8-bit unsigned integer representing the length of the CGA
Parameters field in octets.
八重奏における、CGA Parameters分野の長さを表す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 Parametersデータ構造の最大255バイトを含んでいます。 それらがBinding Updateメッセージで見えるオーダーにおける、すべてのCGA Parametersオプションの連結はオリジナルのCGA Parametersデータ構造をもたらさなければなりません。 最後のもの以外のBinding UpdateメッセージにおけるすべてのCGA ParametersオプションがCGA Parameters分野にちょうど255バイトを保管しなければなりません、そして、Option Length分野はそれに従って、255に位置しなければなりません。 すべてのCGA Parametersオプションが直接相次いで現れなければなりません、すなわち、異なったタイプの移動性オプションは2つのCGA Parametersオプションの間に置かれてはいけません。
5.2. Signature Option
5.2. 署名オプション
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.
SignatureオプションはBindingとBinding Acknowledgment Updateメッセージで使用されます。 それは1かCGA Parametersオプションにさらに先行する上で可動であるか通信員ノードが秘密鍵で発生させる署名を含んでいます。
The format of the Signature option is as follows:
Signatureオプションの形式は以下の通りです:
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 :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
オプションタイプ
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.
八重奏における、Signature分野の長さを表す8ビットの符号のない整数。
Arkko, et al. Standards Track [Page 33] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[33ページ]RFC4866
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における指定されるとしての可動であるか通信員ノードの秘密鍵で、発生しています。
5.3. Permanent Home Keygen Token Option
5.3. 永久的なホームKeygen象徴オプション
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.
PermanentホームKeygen TokenオプションはBinding Acknowledgmentメッセージで使用されます。 それは永久的な家のkeygen象徴を含んでいます。(可動のノードからのSignatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含むBinding Updateメッセージを受け取った後に通信員ノードは可動のノードにそれを送ります)。
The format of the Permanent Home Keygen Token option is as follows:
PermanentホームKeygen Tokenオプションの形式は以下の通りです:
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 :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : 永久的なホームKeygen象徴: : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
八重奏における、PermanentホームKeygen Token分野の長さを表す8ビットの符号のない整数。
Permanent Home Keygen Token
永久的なホームKeygen象徴
This field contains the permanent home keygen token generated by
the correspondent node. The content of this field MUST be
encrypted with the mobile node's public key as defined in
Section 4.7. The length of the permanent home keygen token is 8
octets before encryption, though the ciphertext [4] and, hence,
the Permanent Home Keygen Token field may be longer.
この分野は通信員ノードで発生する永久的な家のkeygen象徴を含んでいます。 セクション4.7で定義される可動のノードの公開鍵でこの分野の内容をコード化しなければなりません。 永久的な家のkeygen象徴の長さは暗号化の前の8つの八重奏です、暗号文[4]としたがって、PermanentホームKeygen Token分野は、より長いかもしれませんが。
Arkko, et al. Standards Track [Page 34] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[34ページ]RFC4866
5.4. Care-of Test Init Option
5.4. 注意、-、イニットオプションをテストしてください。
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.
Care、-、Test InitオプションはBinding Updateメッセージに含まれています。 戻るよう通信員ノードに要求する、Care、-、Testオプション、新鮮なa、注意、-、Binding Acknowledgmentメッセージでのkeygen象徴。
The format of the Care-of Test Init option is as follows:
形式、Care、-、Test 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
オプションタイプ
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.
この分野をゼロに設定しなければなりません。
5.5. Care-of Test Option
5.5. 注意、-、オプションをテストしてください。
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.
Care、-、TestオプションはBinding Acknowledgmentメッセージで使用されます。 新たにaを含んでいる、注意、-、keygen象徴、Care、-、Test Initオプション、Binding Updateメッセージで。受信した後に通信員ノードは可動のノードに象徴を送ります。
The format of the Care-of Test option is as follows:
形式、Care、-、Testオプションは以下の通りです:
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +、注意、-、Keygen象徴+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
8-bit identifier of the type of this mobility option. Its value
is 16.
この移動性オプションのタイプの8ビットの識別子。 値は16です。
Arkko, et al. Standards Track [Page 35] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[35ページ]RFC4866
Option Length
オプションの長さ
This field MUST be set to 8. It represents the length of the
Care-of Keygen Token field in octets.
この分野を8に設定しなければなりません。 長さを表す、Care、-、八重奏におけるKeygen Token分野。
Care-of Keygen Token
注意、-、Keygen象徴
This field contains the care-of keygen token generated by the
correspondent node, as specified in Section 4.3.
この分野が含んでいる、注意、-、keygen象徴を通信員ノードはセクション4.3で指定されるように発生させました。
5.6. CGA Parameters Request Option
5.6. CGAパラメタはオプションを要求します。
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 Parameters RequestオプションはモバイルノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージに含まれています。 それは、Binding AcknowledgmentメッセージにおけるそのCGAパラメタと署名を返すよう通信員ノードに要求します、モバイルノードが、Binding Acknowledgmentメッセージで返された永久的なホームkeygenトークンが正しい通信員ノードによって生成されたことを確かめるのを可能にして。
The format of the CGA Parameters Request option is as follows:
CGA Parameters Requestオプションの形式は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
オプションタイプ
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.
この分野をゼロに設定しなければなりません。
5.7. Status Codes
5.7. ステータスコード
Enhanced Route Optimization uses the following four new status codes for Binding Acknowledgment messages in addition to the status codes defined in [1]:
高められたRoute OptimizationはBinding Acknowledgmentメッセージに[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
モバイルノードから認証されたBinding Updateメッセージを受け取ったなら、通信員ノードはステータスコード147があるBinding Acknowledgmentメッセージをモバイルノードに返します。
Arkko, et al. Standards Track [Page 36] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[36ページ]RFC4866
through the CGA property of the mobile node's home address, but
the correspondent node either does not have a Binding Cache entry
for the mobile node, or the existing Binding Cache entry for the
mobile node does not contain a permanent home keygen token. A
Binding Acknowledgment message with status code 147 indicates to
the mobile node that it should request a new permanent home keygen
token from the correspondent node by sending the correspondent
node a Binding Update message including its CGA parameters and
signature. This in particular enables the mobile node to quickly
recover from state loss at the correspondent node.
モバイルノードのホームアドレスのCGA所有地を通して、通信員ノードだけがモバイルノードのためのBinding Cacheエントリーを持っていないか、またはモバイルノードのための既存のBinding Cacheエントリーは永久的なホームkeygenトークンを含んでいません。 ステータスコード147があるBinding Acknowledgmentメッセージは、通信員ノードからそのCGAパラメタと署名を含むBinding Updateメッセージを通信員ノードに送ることによって新しい永久的なホーム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]で、受信されたBinding Updateメッセージの固有識別文字が不正確であると判明するとステータスコードが失敗を示していて、通信員ノードはBinding Acknowledgmentメッセージを送ることができません。 モバイルノードが再送信タイマーの満了の後にだけ問題を検出できるので、これは高い確率で追加移管潜在を引き起こします。 モバイルノードはそうであり、その上、おそらく、パケット損失を仮定して、不当に認証されたBinding Updateを再送するために、追加回を通信させてください。 通信員ノードがモバイルノードのホームアドレスのCGAの特性について確かめることができなかったとき、ステータスコード147があるBinding Acknowledgmentメッセージは、モバイルノードが、より効率的に根本的な問題を特定するのを助けます。
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.
モバイルノードからSignatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含んでいるBinding Updateメッセージを受け取りましたが、CGA Parametersオプションのコンテンツに基づいてホームアドレスのCGAの特性について確かめることができないか、またはSignatureオプションにおける、署名の検証が失敗したなら、通信員ノードはステータスコード148があるBinding Acknowledgmentメッセージをモバイルノードに返します。
Permanent home keygen token exists (149)
永久的なホームkeygenトークンは存在しています。(149)
A correspondent node returns a Binding Acknowledgment message with
status code 149 to a mobile node if it has received from the
mobile node a Binding Update message that was authenticated
through verification of the mobile node's reachability at the home
address and does not include one or more CGA Parameters options
directly followed by a Signature option, but the correspondent
node has a permanent home keygen token in its Binding Cache entry
for the mobile node. The Binding Update message is processed
further if it includes one or more CGA Parameters options directly
followed by a Signature option. This enables a mobile node to
obtain a new permanent home keygen token from the correspondent
node in case it has lost the existing one, for instance, due to a
モバイルノードからホームアドレスでモバイルノードの可到達性の検証で認証されたBinding Updateメッセージを受け取って、Signatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含んでいないなら、通信員ノードはステータスコード149があるBinding Acknowledgmentメッセージをモバイルノードに返しますが、通信員ノードはモバイルノードのためのBinding Cacheエントリーに永久的なホームkeygenトークンを持っています。 Signatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含んでいるなら、Binding Updateメッセージはさらに処理されます。 例えば、aのため既存のものを失ったといけないので、これは、モバイルノードが通信員ノードから新しい永久的なホームkeygenトークンを得るのを可能にします。
Arkko, et al. Standards Track [Page 37] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[37ページ]RFC4866
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.
リブートしてください。 通信員ノードがBinding Updateメッセージを受け入れるかどうかがこの場合CGAパラメタの検証とBinding Updateメッセージに提供された署名によります。
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.
モバイルノードからSignatureオプションが直接あとに続いた1つ以上のCGA Parametersオプションを含んでいるBinding Updateメッセージを受け取ったなら、通信員ノードはステータスコード150があるBinding Acknowledgmentメッセージをモバイルノードに返しますが、一回だけのインデックスがNonce Indicesオプションで指定したホームはゼロです。 この振舞いは、また、モバイルノードのホームアドレスのCGAの特性に基づいて認証されるBinding Updateメッセージがホームアドレスでモバイルノードの可到達性の証拠を提供しなければならないのを確実にします。
6. Security Considerations
6. セキュリティ問題
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:
高められたRoute Optimizationは増強された移管性能、より強いセキュリティ、および減少しているシグナリングオーバーヘッドのための1セットの最適化を適用するという点においてベースのモバイル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はホームアドレス所有権の証拠としてホームアドレスでモバイルノードの可到達性の周期的なテストを行います。 モバイルノードの可到達性の検証と組み合わせて高められたRoute Optimizationは、しっかりと秘密の永久的なホームkeygenトークンを交換するためにホームアドレスで初期の暗号のホームアドレス所有権証拠を適用します。 永久的なホームkeygenトークンはモバイルノードの暗号の認証にその後の通信員登録証明書の間、使用されます、しっかりと初期のホームアドレス所有権証拠にこれらの後の通信員登録証明書を縛ることができるように。 ホームアドレステストにおけるさらなるどんな周期的な可到達性検証も実行されません。
o Base Mobile IPv6 requires a mobile node to prove its reachability
at a new care-of address during a correspondent registration.
This implies that the mobile node and the correspondent node must
exchange Care-of Test Init and Care-of Test messages before the
mobile node can initiate the binding update proper. Enhanced
Route Optimization allows the mobile node to initiate the binding
update first and follow up with a proof of reachability at the
care-of address. Mobile and correspondent nodes can so resume
communications early on after a handoff, while reachability
verification proceeds concurrently. The amount of data that the
o 基地のモバイルIPv6がaの可到達性が新しいと立証するためにモバイルノードを必要とする、注意、-、通信員登録の間のアドレス。 そして、これが、モバイルノードと対応であっているノードが交換しなければならないのを含意する、Care、-、Test Init、Care、-、モバイルノードの前のTestメッセージはアップデートの拘束力がある自体を開始できます。 高められたRoute Optimizationがモバイルノードに1番目と尾行が可到達性の証拠で上昇する拘束力があるアップデートを開始させる、注意、-、アドレス したがって、モバイルと通信員ノードは移管の後に早くからコミュニケーションを再開できますが、可到達性検証は同時に続きます。 データ量、それ
Arkko, et al. Standards Track [Page 38] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[38ページ]RFC4866
correspondent node is permitted to send to the care-of address
until reachability verification completes is governed by Credit-
Based Authorization.
通信員ノードが発信することが許可されている、注意、-、可到達性検証までのアドレスが完成する、CreditのベースのAuthorizationによって治められます。
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]のセキュリティ問題で見られるべきです。
6.1. Home Address Ownership
6.1. ホームアドレス所有権
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:
高められたRoute Optimizationは、[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 1セットの補助の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番目の特性は最初の特性を満足させる公衆/秘密鍵組がブルートフォース方法で探される費用を増強します。 制限にもかかわらず、これは暗号の意味でホームアドレスであると暗号で生成されたaのセキュリティを59ビットまで増強します。 唯一最初の特性を実施するのに、攻撃者は別の方法でO(2^59)ステップで適当な公衆/秘密鍵組を見つけることができるでしょう。 2番目の特性の追加で、O(2^(59+N))ステップにブルートフォース検索の複雑さを増強できます。そこでは、Nがハッシュ拡大機能の結果が持つのに必要である主なゼロの最小の数です。
Arkko, et al. Standards Track [Page 39] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[39ページ]RFC4866
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つの初めは説明された特性を満足させる修飾語のために、それ自身の公衆/秘密鍵組を生成して、ブルートフォース検索を実行するかもしれません。 または、それはコピーできました。整数モバイルノードの公開鍵を因数分解してください、そして、対応する秘密鍵を推論してください、そして、ブルートフォース検索なしでモバイルノードの修飾語をコピーしてください。 攻撃の費用はどちらかのケースの中のモバイルノードで決定できます: 公開鍵の長さが成長するのに応じて、公開鍵を整数で因数分解するのはますます複雑になります、そして、モバイルノードの裁量にはキー長があります。 ハッシュ拡大機能の結果が持つのに必要である主なゼロの数に応じて、適当な修飾語のブルートフォース検索の費用は上がります。 また、この数はモバイルノードが選ぶことができるパラメタです。 攻撃者が1セットのモバイルノードにはあるCGAパラメタが以前はよくホームアドレスを生成していたほど安全でない、そして、したがって不可能なCGAパラメタを選ぶことによってホームアドレスであると暗号で生成されたaを偽造するコストを削減するところで攻撃を格下げします。
The CGA specification [2] requires the use of RSA public and private keys, and it stipulates a minimum key length of 384 bits. This requirement that was tailored to Secure Neighbor Discovery for IPv6 [13], the original CGA application. Enhanced Route Optimization does not increase the minimum key length because, in the absence of downgrading attacks as explained before, the ability to use short keys does not compromise the security of home addresses that were cryptographically generated using longer keys. Moreover, extensions to [2] may eventually permit the use of public/private-key classes other than RSA. Such extensions are compatible with the CGA application of Enhanced Route Optimization. Care must be taken in selecting an appropriate key class and length, however. Home addresses are typically rather stable in nature, so the chosen parameters must be secure for a potentially long home address lifetime. Where RSA keys are used, a minimum key length of 1024 bits is therefore RECOMMENDED.
CGA仕様[2]はRSA公衆と秘密鍵の使用を必要とします、そして、それは最低384ビットのキー長を規定します。 IPv6[13]、オリジナルのCGAアプリケーションのためにSecure Neighborディスカバリーに合わせたこの要件。 以前説明されるように攻撃を格下げすることが不在のとき短いキーを使用する能力が、より長いキーを使用することで暗号で生成されたホームアドレスのセキュリティに感染しないので、高められたRoute Optimizationは最小のキー長を増強しません。 そのうえ、[2]への拡大は結局、RSA以外の公衆/秘密鍵のクラスの使用を可能にするかもしれません。 そのような拡大はEnhanced Route OptimizationのCGAアプリケーションと互換性があります。 しかしながら、適切なキークラスと長さを選択しながら、注意を中に入れなければなりません。通常、ホームアドレスが現実にかなり安定している、したがって、選ばれたパラメタは潜在的に長いホームアドレス生涯安全であるに違いありません。 RSAキーが使用されているところでは、したがって、最低1024ビットのキー長はRECOMMENDEDです。
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
CGA世代機能が暗号でホームアドレスに関するインタフェース識別子をホームアドレスのサブネット接頭語に結んでいる間、機能は、どんなサブネット接頭語も受け入れて、したがって、ノードが偽造しているサブネット接頭語で暗号でホームアドレスを生成するのを防ぎません。 結果として、ホームアドレスのCGAの特性はホームアドレスで所有者の可到達性を保証しません。 「リターンからホームへの氾濫」ゆえこれを誤用できました。
Arkko, et al. Standards Track [Page 40] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[40ページ]RFC4866
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.
または、を通してこれを縛る通信員ノードが、攻撃者がサブネット接頭語で犠牲者ネットワークからホームアドレスを暗号で生成するのにそれ自身の公開鍵を使用する「攻撃」[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の特性の検証は非対称の公開鍵暗号にかかわります。(左右対称の暗号と比べて、それは、比較的複雑です)。 モバイルノードのホームアドレスの初期の公開鍵ベースの検証が実行された後に高められたRoute Optimizationは左右対称の暗号の使用によるこの不都合を緩和します。 明確に、通信員ノードはモバイルノードがその後の通信員登録証明書の間、通信員ノードにどれを認証できるかに基づく初期の通信員登録の間、永久的なホームkeygenトークンをモバイルノードに割り当てます。 そのような認証は、通信員ノードがモバイルノードのホームアドレスの初期の公開鍵ベースの検証にその後の通信員登録を縛って戻すのを可能にします。 プレーンテキストで永久的なホームkeygenトークンを決して送りません。 それは、初めは割り当てられるとモバイルノードの公開鍵で暗号化されて、その後の通信員登録証明書の間、逆転できないように論じ尽くされます。
6.2. Care-of Address Ownership
6.2. 注意、-、所有権を扱ってください。
A secure proof of home address ownership can mitigate the threat of IP address stealing, but an attacker may still bind a correct home address to a false care-of address and thereby trick a correspondent node into redirecting packets, which would otherwise be delivered to the attacker itself, to a third party. Neglecting to verify a mobile node's reachability at its claimed care-of address could therefore cause one or multiple correspondent nodes to unknowingly contribute to a redirection-based flooding attack against a victim chosen by the attacker.
ホームアドレス所有権の安全な証拠がIPアドレス横取りの脅威を緩和できますが、攻撃者がまだ正しいホームアドレスを偽に縛っているかもしれない、注意、-、向け直すパケットへの通信員ノードを扱って、その結果、だましてください。(そうでなければ、それは、攻撃者自身、第三者に提供されるでしょう)。 モバイルノードの可到達性について確かめるのを忘れる、注意、-、アドレス、したがって、ものか複数の通信員ノードが攻撃者によって選ばれた犠牲者に対するリダイレクションベースのフラッディング攻撃に知らずに貢献することを引き起こす場合がありました。
Redirection-based flooding attacks may target a single node, a link, or a router or other critical network device upstream of an entire network. Accordingly, the attacker's spoofed care-of address may be the IP address of a node, a random IP address from a subnet prefix of a particular link, or the IP address of a router or other network device. An attack against a network potentially impacts a larger number of nodes than an attack against a specific node, although
リダイレクションベースのフラッディング攻撃は全体のネットワークのただ一つのノード、リンク、ルータまたは他の重要なネットワークデバイス上流を狙うかもしれません。 それに従って、攻撃者がだました、注意、-、アドレスは、ノードのIPアドレス、特定のリンクのサブネット接頭語からの無作為のIPアドレス、またはルータか他のネットワークデバイスのIPアドレスであるかもしれません。 ネットワークに対する攻撃は潜在的に特定のノードに対して攻撃より多くのノードに影響を与えます。
Arkko, et al. Standards Track [Page 41] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[41ページ]RFC4866
neighbors of a victim node on a broadcast link typically suffer the same damage as the victim itself.
放送リンクの上の犠牲者ノードの隣人は犠牲者自身と同じ損害を通常受けます。
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が扱う特定の犠牲者ノードのアドレス、攻撃者がまだaを生成することができた、相違、CGAベース、注意、-、犠牲者のIPアドレスのものと同じサブネット接頭語があるアドレス。 氾濫パケットがこれに向かって向け直した、注意、-、次に、アドレスがどんな特定のノードによっても受け取られて、処理される必要はないでしょうが、それらは、全体のリンクかネットワークに影響を与えて、その結果、匹敵する損害をもたらすでしょう。 CGAベース、注意、-、したがって、アドレスには、氾濫保護に関して有効性がほとんどありません。 他方では、彼らが計算上高価で、公開鍵ベースの所有権証拠を必要とするだろう、いつ、注意、-、変化を扱ってくださいか。 これらの理由に、Enhanced Route Optimizationが通常の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.
ありがちな誤解がホームアドレス所有権の確かな証拠がリダイレクションベースの氾濫の脅威を緩和して、その結果、aで新しい状態でモバイルノードの可到達性について確かめる必要性を排除するだろうということである、注意、-、アドレス。 ノードが、[1]のIPv6本国登録、認証のためのどの呼び出しのときにモバイルでは、IPsecセキュリティ協会を基礎づけますが、これがモバイルノードの可到達性の検証で補われるのを必要としないかというこの概念がベースモバイルの仕様から起因するかもしれない、注意、-、アドレス しかしながら、この場合、本国登録のための可到達性検証を強制しない理由はホームのエージェントがしっかりとモバイルノードのホームアドレス所有権について確かめることができるか、または本国登録がIPsecによって保護されているという事実よりむしろホームのエージェントとモバイルノードとの管理関係の存在です。 モバイルノードとの管理関係が最初にモバイルノードのものの正当性を信じるためにホームのエージェントを許容する、注意、-、アドレス、2番目に、すぐにモバイルノードを特定するために、静まるなら、例えば陰湿に振る舞う開始はマルウェアによる感染がそうします。 [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
ホームのエージェントがモバイルユーザが通常加入する移動性サービスの不可欠の部分であるなら信頼であり、モバイルノードとそのホームのエージェントとの管理関係が実行可能であると仮定するのをセットアップされる、彼女、-、自分、取引関係に基づいて、受信します。 モバイルノードと通信員ノードの上で主要で、あらかじめ設定された共有された認証、preassumesがモバイルノードと通信員ノードとの同じ関係であると利用するモバイルIPv6拡張子[14]。 この仮定がプロトコルの適用性を制限する、([14]のセクション2は承認します。
Arkko, et al. Standards Track [Page 42] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[42ページ]RFC4866
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.
これ)、省略を可能にする、注意、-、本国登録に関するケースのように可到達性検証を扱ってください。 高められたRouter Optimizationはモバイルと通信員ノードとの関係で仮定をしません。 これが任意のシナリオに適切にプロトコルを表しますが、ノードがモバイルノードの可到達性について確かめなければならないその通信員を必要とする、あらゆる、新しさ、注意、-、アドレス。
6.3. Credit-Based Authorization
6.3. クレジットベースの承認
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.
高められたRoute Optimizationが、モバイルと通信員ノードがモバイルノードの可到達性の前に移管の後に新しさでモバイルノード側で双方向のコミュニケーションを再開するのを可能にする、注意、-、アドレスは通信員ノードによって確かめられました。 そのような並行性は適切な保護がないとき可到達性検証が元々排除するように設計されたリダイレクションベースの氾濫の脅威に再紹介するでしょう: それを考えて、一般に、通信員ノードはそうです。モバイルノード、可到達性検証がパケット損失のため失敗するかもしれなくて以来の往復の現代に気づきません、通信員ノードは可到達性検証が完成する十分長い並行性の期間を受け入れなければなりません。 攻撃者は、通信員ノードが犠牲者のIPアドレスにパケットを向け直すように一時だますためにこれを誤用できました。 また、攻撃者が相次ぐときに中のそれが新たに、ことによると通信員ノードに登録する可到達性検証を延期するかもしれない、a異なる、パロディー、注意、-、アドレス、通信員ノードの最大が可能にするすぐ前に、並行性の期間は経過して、通信員ノードは一層のパケットを送らないで可到達性検証の完成を待つのに切り替わります。 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. モバイルノード側の上の高い移動性か、モバイルノードと通信員ノードの間の経路における永続的なパケット損失にこれはあるかもしれません。 一般に、もう一方の端のパーティーが合法的に逆の条件か陰湿に振る舞うか否かに関係なく、通信員ノード側を決めるのは重要です。
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:
高められたRoute Optimizationは同時発生の可到達性検証にもかかわらず、ベースのCredit Authorizationの使用で浸水しながら基づくリダイレクションの脅威を排除します。 ベースのクレジットAuthorizationが通信員ノードが中に発信しているペイロードパケットを費やす取り組みを管理する、注意、-、アドレス、UNVERIFIED状態で。 これは以下の3つの仮説に基づいて達成されます:
Arkko, et al. Standards Track [Page 43] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[43ページ]RFC4866
1. A flooding attacker typically seeks to shift the burden of
assembling and sending flooding packets to a third party.
Bandwidth is an ample resource for many attractive victims, so
the effort for sending the high rate of flooding packets required
to impair the victim's ability to communicate may exceed the
attacker's own capacities.
1. 氾濫攻撃者は氾濫パケットを第三者に組み立てて、送ることの重荷を通常取り除こうとします。 帯域幅が多くの魅力的な犠牲者への十分なリソースであるので、パケットが交信する犠牲者の能力を損なうのを必要とした氾濫の高い率を送るための取り組みは攻撃者の自己の能力を超えるかもしれません。
2. The attacker can always flood a victim directly by generating
bogus packets itself and sending those to the victim. Such an
attack is not amplified, so the attacker must be provisioned
enough to generate a packet flood sufficient to bring the victim
down.
2. 攻撃者は、直接、それ自体でにせのパケットを生成して、それらを犠牲者に送ることによって、犠牲者をいつもあふれさせることができます。 そのような攻撃が増幅されないので、攻撃者に犠牲者を落ち込ませることができるくらいのパケット洪水を生成することができるくらい食糧を供給しなければなりません。
3. Consequently, the additional effort required to set up and
coordinate a redirection-based flooding attack pays off for the
attacker only if the correspondent node can be tricked into
contributing to and amplifying the attack.
3. その結果、攻撃を貢献して、増幅するように通信員ノードをだますことができる場合にだけ、リダイレクションベースのフラッディング攻撃をセットアップして、調整するのに必要である追加取り組みは攻撃者にうまく行きます。
Non-amplified redirection-based flooding is hence, from an attacker's perspective, no more attractive than pure direct flooding, where the attacker itself sends bogus packets to the victim. It is actually less attractive given that the attacker needs to maintain a context for mobility management in order to coordinate the redirection. On this basis, Credit-Based Authorization extinguishes the motivation for redirection-based flooding by preventing the amplification that could be reached through it, rather than eliminating malicious packet redirection in the first place. The ability to send unrequested packets is an inherent property of packet-oriented networks, and direct flooding is a threat that results from this. Since direct flooding exists with and without mobility support, it constitutes a reasonable measure in comparing the security provided by Enhanced Route Optimization to the security of the non-mobile Internet. Through the use of Credit-Based Authorization, Enhanced Route Optimization satisfies the objective to provide a security level comparable to that of the non-mobile Internet.
攻撃者の見解から、したがって、非増幅されたリダイレクションベースの氾濫は、攻撃者自身がにせのパケットを犠牲者に送るところで浸水しながら、魅力的であるというよりもダイレクトに純粋です。 攻撃者が、リダイレクションを調整するために移動性管理のための文脈を維持する必要があるなら、実際にそれほど魅力的ではありません。 このベースでは、ベースのCredit Authorizationは、第一に悪意があるパケットリダイレクションを排除するよりそれを通してむしろ達することができた増幅を防ぐことによって、リダイレクションベースの氾濫に関する動機を失います。 非要求されたパケットを送る能力はパケット指向のネットワークの固有の特性です、そして、ダイレクト氾濫はこれから生じる脅威です。 ダイレクト氾濫が移動性サポートのあるなしにかかわらず存在しているので、それはEnhanced Route Optimizationによって非モバイルインターネットのセキュリティに提供されたセキュリティを比較する際に妥当な測定を構成します。 ベースのCredit Authorizationの使用で、Enhanced Route Optimizationは、非モバイルインターネットのものに匹敵するセキュリティー・レベルを提供するために目的を満たします。
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.
リダイレクションベースのフラッディング攻撃の加害者は可動のノードの役割を引き受けるでしょう、したがって、通信員ノード側でベースのCredit Authorizationを実施しなければなりません。 通信員ノードは絶え間なく、可動のノードが通信員ノードとコミュニケートするのに費やす努力をモニターします。 次に、可動のノードの努力が可動のノードのものであるときに通信員ノードが送付ペイロードパケットに費やすかもしれない努力における限界としてみなされる、注意、-、アドレスがUNVERIFIED状態にあります。 対応であっているノードがペイロードパケットの数量限定を送る許可、注意、-、アドレス、UNVERIFIEDでは、可動のノードが移管の後にいったん新しいIPアドレスを通信員ノードに登録すると、州は双方向のコミュニケーションの即座の再開を可能にします。
Arkko, et al. Standards Track [Page 44] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[44ページ]RFC4866
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アドレスにペイロードパケットを向け直すようにだます攻撃者であるなら、ベースのCredit Authorizationは、通信員ノードが流れを発生させるのに費やす努力自体が攻撃者が最近費やした努力を超える前に氾濫パケットの流れがやむのを確実にします。 フラッディング攻撃は、したがって、ダイレクトフラッディング攻撃と高々同じくらい有効であり、その結果、少しの増幅も起こしません。
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.
ベースのCredit Authorizationの別の特性がクレジットがゆったり過ごす可動のノードを割り当てないということである、それ、注意、-、アドレスがUNVERIFIED状態にあります。 それは状態の如何にかかわらずクレジットを割り当てるのにおいて技術的に可能でしょう、したがって、これが正当化に値する、可動のノードのもの、注意、-、アドレス しかしながら、パケットのためのクレジットの課題が受信した、注意、-、アドレス、UNVERIFIEDでは、州は持続している反射攻撃に脆弱性を紹介するでしょう。 明確に、通信員ノードにパケットを送ることによって絶え間なくクレジットを補給するので、攻撃者は、通信員ノードが攻撃者のために犠牲者のIPアドレスにパケットを向け直すことを引き起こして、犠牲者に向かってパケット流動を支えることができました。 そのようなリダイレクションベースの反射攻撃は少しの増幅も起こさないでしょうが、攻撃者がいくつかの「蹄-可能」データを受け取るのを通常必要とする通信員ノードで初期のトランスポート・プロトコル握手を追求して、その後犠牲者のIPアドレスにダウンロードを向け直したがっている攻撃者に、それはまだ好みに合っているかもしれません。 ベースのクレジットAuthorizationは攻撃者がダウンロードがいったん向け直されるとこの場合追加クレジットを取得できないで、その結果、攻撃を強制的に急速に終わらせるのを確実にします。
Arkko, et al. Standards Track [Page 45] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[45ページ]RFC4866
6.4. Time Shifting Attacks
6.4. タイム・シフト攻撃
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分まで通信員登録の生涯を制限するのでそれをアレンジする、家の可動のノードの可到達性、注意、-、アドレスは定期的に再検証されます。 または、これが、通信員ノードとだまされた家の間の経路に一時だけいる攻撃者が雨垂れへのリターンroutabilityプロシージャの脆弱性を利用できないのを確実にする、注意、-、アドレス。 [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.
高められたRoute Optimizationが初期のホームアドレステストもいずれも繰り返さない、注意、-、移管遅れとシグナリングオーバーヘッドを下げるためにテストを記述してください。 ホームアドレスのための必要な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.
または、時間が家でどのEnhanced Route Optimizationで可動のノードの可到達性について確かめるかとまだ認められているべきである、注意、-、アドレスはたぶんどんなトランスポート層接続の設立もantecedeするでしょう。 これで、通信員ノードと犠牲者の間の経路から遠くで動くより多くの時間を攻撃者に与えるので、タイム・シフト攻撃は、より実用的になります。 または、周期的な可到達性検証の不足が危険過ぎると考えられるなら、通信員ノードが家の再放送を実施するかもしれない、注意、-、登録生涯を制限するか、または可動のノードへのメッセージをBinding Refresh Requestに送ることによって、テストを記述してください。
Arkko, et al. Standards Track [Page 46] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[46ページ]RFC4866
6.5. Replay Attacks
6.5. 反射攻撃
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.
本書では指定されたプロトコルは、反射攻撃を避けるために「再-合わせ」ながら、モバイルIPv6一連番号で周期的に16ビットのベースを当てにします。 Rekeyingで、反射攻撃に親しまないで、可動、そして、通信員ノードは一連番号を再利用できます。 最大の受入れられた拘束力がある生涯のため通信員登録証明書のために少なくとも24時間に一度それを追求しなければなりません。 また、一連番号スペースのロールオーバーが差し迫るようになるときはいつも、モバイルの、そして、対応であっているノードはrekeyします。 しかしながら、有効な一連番号が32768の通信員登録証明書まで十分であるなら、これは頻繁に起こりそうにはありません、早いメッセージと完全なBinding Updateメッセージからそれぞれ成って。 その結果、一連番号スペースは24時間の拘束力がある生涯の間中必要性を露出することのない分あたり22の通信員登録証明書対rekeyの平均相場を可能にします。
6.6. Resource Exhaustion
6.6. リソース疲労困憊
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ベースのホームアドレス所有権証拠がunauthenticated Binding Updateメッセージに対する保護を提供している間、それは、計算上高価な公開カギ暗号を必要とするので、通信員ノードをサービス不能攻撃に露出できます。 高められたRoute Optimizationは公開カギ暗号の使用を「再-合わせ」るときだけ、最初の通信員登録と/が必要であるかどうか制限します。 通信員ノードがさらに、それらがCGAベースのホームアドレス所有権検証に費やす処理リソースの量を追跡して、これらのリソースが事前に定義された限界を超えていると公開カギ暗号にかかわる新しい通信員登録証明書を拒絶するのは、RECOMMENDEDです。 [2]はCGAベースのリソース疲労困憊攻撃に関する実現の可能性について徹底的に議論します。
6.7. IP Address Ownership of Correspondent Node
6.7. 通信員ノードのIPアドレス所有権
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
高められたRoute Optimizationは、可動のノードが通信員ノードのIPアドレスのCGAの特性に基づく受信されたBinding Acknowledgmentメッセージを認証するのを可能にします、通信員ノードにCGAがあれば。 可動のノードは、通信員ノードに発信して、通信員ノードがCGA ParametersとSignatureオプションの中でそのCGAパラメタと署名をBinding Acknowledgmentメッセージに追加することによって応じるというBinding UpdateメッセージにCGA Parameters Requestオプションを含んでいることによって、この認証を要求します。 通信員ノードのIPアドレスの所有権を立証すると、可動のノードは将来の通信員登録証明書の間、だまされたBinding Acknowledgmentメッセージを受け入れて、使用のために含まれている永久的な家のkeygen象徴を格納することから保護されます。 可動のノードがどんな結合も商取引するのを防ぐでしょう、したがって、そのような攻撃は可動のノードに対してサービスの否定をもたらすでしょう。
Arkko, et al. Standards Track [Page 47] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[47ページ]RFC4866
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.
得られた永久的な家によるアップデートは象徴をkeygenします。 高められたRoute Optimizationはしつこい通信員登録失敗の場合に永久的な家の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象徴を提供するために通信員ノードを要求するBinding Updateメッセージは可動のノードのホームアドレスのCGAの特性に基づいて認証されます。 この認証方法はホームアドレステストを伴います、家のkeygen象徴に基づいてそれがBinding Updateメッセージの固有識別文字について計算できる可動のノードに提供して。 可動のノードが同じ家のkeygen象徴で計算されるべき戻っているBinding Acknowledgmentメッセージの固有識別文字を予想するので、永久的な家のkeygen象徴を含んでいるBinding Acknowledgmentメッセージをだましても構わないと思っている攻撃者はホームアドレステストを立ち聞きしなければなりません。 したがって、ホームアドレステストが続く間、攻撃者は経路に通信員ノードから可動のノードの家のエージェントまで出席しているに違いありません。 そのうえ、永久的な家のkeygen象徴を要求するBinding Updateメッセージが完全であるなら、固有識別文字がさらにベースで計算される、オンである、注意、-、keygen象徴 次に、また、攻撃者がこれを知らなければならない、注意、-、Binding Acknowledgmentメッセージの固有識別文字を発生させるkeygen象徴。 または、通信員ノードが発信するときこれが、通信員ノードから現在の可動のノードのIP付属まで攻撃者が経路にいるのを必要とする、注意、-、中で可動のノードに象徴をkeygenする、Care、-、Testメッセージ、Care、-、Binding AcknowledgmentメッセージのTestオプション。
Since a mobile node in general does not know whether a particular correspondent node's IP address is a CGA, the mobile node must be prepared to receive a Binding Acknowledgment message without CGA Parameters and Signature options in response to sending a Binding Update message with an included CGA Parameters Request option. Per se, this mandatory behavior may enable downgrading attacks where the attacker would send, on the correspondent node's behalf, a Binding Acknowledgment message without CGA Parameters and Signature options, claiming that the correspondent node's IP address is not a CGA. Enhanced Route Optimization mitigates this threat in that it calls for mobile nodes to prioritize Binding Acknowledgment messages with valid CGA Parameters and Signature options over Binding Acknowledgment messages without such options. This protects against downgrading attacks unless the attacker can intercept Binding Acknowledgment messages from the correspondent node. Given that the attacker must be on the path from the correspondent node to the mobile node's home agent at roughly the same time as explained above, the attacker may not be able to intercept the correspondent node's
一般に、可動のノードが、特定の通信員ノードのIPアドレスがCGAであるかどうかを知らないので、含まれているCGA Parameters Requestオプションと共にBinding Updateメッセージを送ることに対応してCGA ParametersとSignatureオプションなしでBinding Acknowledgmentメッセージを受け取るように可動のノードを準備しなければなりません。 そういうものとして、この義務的な振舞いは攻撃者が通信員ノードに代わってCGA ParametersなしでBinding Acknowledgmentメッセージを送るだろうところで攻撃を格下げして、Signatureオプションを可能にするかもしれません、通信員ノードのIPアドレスがCGAでないと主張して。 Binding Acknowledgmentメッセージの上に有効なCGA ParametersとSignatureオプションがある状態で可動のノードがそのようなオプションなしでBinding Acknowledgmentメッセージを最優先させるように求めるので、高められたRoute Optimizationはこの脅威を緩和します。 これは、攻撃者がBinding Acknowledgmentメッセージを傍受できないなら攻撃を格下げしないように通信員ノードから保護されます。 通信員ノードから可動のノードの家のエージェントまで攻撃者がおよそ上で説明されるのと同時に経路にいるに違いないなら、攻撃者は通信員ノードのものを傍受できないかもしれません。
Arkko, et al. Standards Track [Page 48] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[48ページ]RFC4866
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.
Acknowledgmentメッセージを縛ります。 他方では、通信員ノードからのBinding Acknowledgmentメッセージを傍受できる攻撃者はaにとにかくそれがどこで可動のノードに対してサービスの否定を追求できるか、そして、通信員ノードを置くことです。 これは非モバイルインターネットで既に存在する脅威です、そして、それはEnhanced Route Optimizationに特定ではありません。
External mechanisms may enable the mobile node to obtain certainty about whether a particular correspondent node's IP address is a CGA. The mobile node may then insist on an IP address ownership proof from the correspondent node, in which case it would discard any received Binding Acknowledgment messages that do not contain valid CGA Parameters and Signature options. One conceivable means for mobile nodes to distinguish between standard IPv6 addresses and CGAs might be an extension to the Domain Name System.
外部のメカニズムは、可動のノードが特定の通信員ノードのIPアドレスがCGAであるかどうかの周りで確実性を得るのを可能にするかもしれません。 次に、可動のノードは通信員ノードからIPアドレス所有権証拠を主張するかもしれません、その場合、それが有効なCGA ParametersとSignatureオプションを含まないどんな受信されたBinding Acknowledgmentメッセージも捨てるでしょう。 可動のノードが標準のIPv6アドレスを見分ける想像できる1つの手段とCGAsはドメインネームシステムへの拡大であるかもしれません。
7. Protocol Constants and Configuration Variables
7. プロトコル定数と構成変数
[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 Message Typeタグを引き出すCGA Message Type名前空間を定義します。 高められたRoute Optimizationは以下の一定の、そして、手当たりしだいに発生しているCGA Message Typeタグを使用します:
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13
0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A2E13
[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]はバウンドしています。マックス_RR_BINDING_LIFETIMEへのリターンroutability手順を通して通信員ノードで確立された結合のための生涯。 高められたRoute Optimizationは可動のノードの可到達性の証拠を通してホームアドレスで認証される結合のためのこの限界を採用します。 しかしながら、結合が可動のノードのホームアドレスのCGA所有地を通して認証されるとき、拘束力がある寿命はマックス_CGA_BINDING_LIFETIMEの、より寛大な恒常価値に制限されます:
MAX_CGA_BINDING_LIFETIME 86400 seconds
86400秒のマックス_CGA_BINDING_LIFETIME
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つの構成変数を取り入れます。 通信員ノードが以下の値を使用するのは、RECOMMENDEDです:
CreditAgingFactor 7/8
CreditAgingInterval 5 seconds
5秒のCreditAgingFactor7/8CreditAgingInterval
Arkko, et al. Standards Track [Page 49] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[49ページ]RFC4866
8. IANA Considerations
8. IANA問題
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 Parameters Request移動性オプション(11)
o CGA Parameters mobility option (12)
o CGA Parameters移動性オプション(12)
o Signature mobility option (13)
o 署名移動性オプション(13)
o Permanent Home Keygen Token mobility option (14)
o 永久的なホームKeygen Token移動性オプション(14)
o Care-of Test Init mobility option (15)
o 注意、-、Test Init移動性オプション(15)
o Care-of Test mobility option (16)
o 注意、-、Test移動性オプション(16)
This document allocates the following four new status codes for Binding Acknowledgment messages:
このドキュメントはBinding Acknowledgmentメッセージのために以下の4つの新しいステータスコードを割り当てます:
o "Permanent home keygen token unavailable" (147)
o 「入手できない永久的な家のkeygen象徴」(147)
o "CGA and signature verification failed" (148)
o 「CGAと署名照合は失敗しました」(148)
o "Permanent home keygen token exists" (149)
o 「永久的な家のkeygen象徴は存在しています」(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以上でなければなりません、それぞれのBinding Updateメッセージが受信通信員ノードによって拒絶されたのを示して。
This document also defines a new 128-bit value under the CGA Message Type namespace [2].
また、このドキュメントはCGA Message Type名前空間[2]の下で新しい128ビットの値を定義します。
9. Acknowledgments
9. 承認
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.
作者は、貴重で興味深いおよそ議論のためのVesa Torvinen(アルファベット順に)が暗号でアドレスを作ったのをTuomas Aura、ガブリエル・モンテネグロペッカNikander、マイクRoe、グレッグ・オシアに感謝したがっています。
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
また、作者はマルセロBagnulo、ローランドBless、曹臻、Samita Chakrabarti、グレッグ・デイリー、ビジェイDevarapalli、マークDoll、Lakshminath Dondeti、フランシス・デュポン、ラース・エッゲルト、エリック・グレー、Manheeジョウ、ジェームス・ケンフ、Sureshクリシュナン、トビアスKuefner、ライラMadour、Vidyaナラヤナン、モハンパルタサラティ、アリスQinxia、およびBehcetに感謝したがっています。
Arkko, et al. Standards Track [Page 50] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[50ページ]RFC4866
Sarikaya (in alphabetical order) for their reviews of and important comments on this document and the predecessors of this document.
(アルファベット順に)彼らのレビューのためにSarikayaする、そして、このドキュメントのこのドキュメントと前任者の重要なコメント。
Finally, the authors would also like to emphasize that [15] pioneered the use of cryptographically generated addresses in the context of Mobile IPv6 route optimization, and that this document consists largely of material from [16], [17], and [18] and the contributions of their authors.
最終的に、作者は作ったでしょう、また、強調する[15]が使用を開拓した同類が暗号で彼らの作者の[16]、[17]、[18]、および投稿によって物質的にこのドキュメントが主に成るモバイルIPv6経路最適化と、その文脈のアドレスを作りました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[2] 香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
[3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", IETF BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、IETF BCP14、RFC2119、1997年3月。
[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447, February 2003.
[4] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
10.2. Informative References
10.2. 有益な参照
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[5]Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4225、2005年12月。
[6] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[6] フォークト、C.、およびJ.Arkko、「モバイルIPv6への増進の分類学と分析は最適化を発送します」、RFC4651、2007年2月。
[7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
IPv6", Proceedings of the IEEE Wireless Communications and
Networking Conference, IEEE, April 2006.
[7] フォークト、C.、およびM.は、「IPv6"での終わりから終わりへの移動性効率的なサポート、IEEE無線通信とネットワークコンファレンスの議事、IEEE、2006年4月」をめかします。
[8] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS
Defense Mechanisms", ACM SIGCOMM Computer Communication Review,
Vol. 34, No. 2, ACM Press, April 2004.
[8] MirkovicとJ.とP.Reiher、「DDoS攻撃とDDoS防衛機構の分類学」、ACM SIGCOMMコンピュータコミュニケーションは再検討されます、Vol.34、No.2、ACMプレス、2004年4月。
[9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
Lifetime Extension", Work in Progress, May 2004.
[9] 「拘束力がある生涯拡大のためのクレジットベースの認可」というArkko、J.、およびC.フォークトは進歩、2004年5月に働いています。
Arkko, et al. Standards Track [Page 51] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[51ページ]RFC4866
[10] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6
(CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,
Vol. 31, No. 2, April 2001.
[10] オシアとG.とM.魚卵、「MIPv6(CAM)のための子供にとって安全な認証」、ACM SIGCOMMコンピュータコミュニケーションレビュー、ACMは押します、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] Revisedは、Securityプロトコルの国際WorkshopからNikanderと、P.と、「IPv6世界でのサービスの否定、アドレス所有権、および早めの認証」に紙を張ります、Springer-Verlag、2002年4月。
[12] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms
in Cryptographically Generated Addresses (CGAs)", Work
in Progress, April 2007.
[12] 「複数の細切れ肉料理アルゴリズムのサポートは中で暗号で、アドレス(CGAs)を作った」というBagnulo、M.、およびJ.Arkkoは進行中(2007年4月)で働いています。
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[13]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
Static Shared Key", RFC 4449, June 2006.
[14] パーキンス、C.、「静的な共有されたキーを使用することでモバイルIPv6経路最適化を保証します」、RFC4449、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.
「モバイルIPv6拘束力があるアップデートと承認の認証」という[15]魚卵、M.、香気、T.、オシア、G.、およびJ.Arkkoは進行中(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] 「暗号で、MIPv6(CGA- OMIPv6)を最適化するために生成アドレスを適用し」て、ハダド、W.、Madour、L.、Arkko、J.、およびF.デュポンは進歩(2005年5月)を扱います。
[17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
Updates for Mobile IPv6", Work in Progress, February 2004.
フォークト、C.が祝福する[17]、R.、人形、M.とT.Kuefner、「モバイルIPv6"のための事前バインディングアップデート、処理中の作業、2004年2月。」
[18] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
"Credit-Based Authorization for Mobile IPv6 Early Binding
Updates", Work in Progress, May 2004.
[18] フォークト、Arkko(J.)が祝福するC.、R.、人形、M.、およびT.Kuefner、「モバイルIPv6事前バインディングアップデートのためのクレジットベースの認可」が進行中(2004年5月)で働いています。
Arkko, et al. Standards Track [Page 52] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[52ページ]RFC4866
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
ヤリ・Arkkoエリクソン研究NomadicLab FI-02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
クリスチャンのフォークトテレマティックスUniversitaetカールスルーエ研究所(TH)P.O. Box6980 76128カールスルーエドイツ
EMail: chvogt@tm.uka.de
メール: chvogt@tm.uka.de
Wassim Haddad Ericsson Research 8400, Decarie Blvd Town of Mount Royal Quebec H4P 2N2, Canada
WassimハダドエリクソンResearch8400、山のロイヤルケベックH4P 2N2、カナダのDecarie Blvd町
EMail: wassim.haddad@ericsson.com
メール: wassim.haddad@ericsson.com
Arkko, et al. Standards Track [Page 53] RFC 4866 Enhanced Route Optimization May 2007
Arkko、他 経路最適化2007年5月に高められた標準化過程[53ページ]RFC4866
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Arkko, et al. Standards Track [Page 54]
Arkko、他 標準化過程[54ページ]
一覧
スポンサーリンク
