Network Working Group C. Vogt
Request for Comments: 4651 Universitaet Karlsruhe (TH)
Category: Informational J. Arkko
Ericsson Research NomadicLab
February 2007
A Taxonomy and Analysis of Enhancements to
Mobile IPv6 Route Optimization
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
IESG Note:
IESG注：
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment.
このRFCはインターネットリサーチタスクフォースの製品であり、インターネットStandardのどんなレベルの候補ではありません。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。
Abstract
抽象
This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
この文書では説明し、この文脈でのさらなる研究の動機と導くためには、既存の提案に基づいて、モバイルIPv6経路最適化を強化するための戦略を評価します。この文書では、IPモビリティの最適化（MobOpts）研究グループの製品です。
Table of Contents
目次
1. Introduction ....................................................3
1.1. A Note on Public-Key Infrastructures .......................4
1.2. A Note on Source Address Filtering .........................5
2. Objectives for Route Optimization Enhancement ...................7
2.1. Latency Optimizations ......................................8
2.2. Security Enhancements ......................................8
2.3. Signaling Optimizations ....................................9
2.4. Robustness Enhancements ....................................9
3. Enhancements Toolbox ............................................9
3.1. IP Address Tests ..........................................10
3.2. Protected Tunnels .........................................10
3.3. Optimistic Behavior .......................................11
3.4. Proactive IP Address Tests ................................11
3.5. Concurrent Care-of Address Tests ..........................12
3.6. Diverted Routing ..........................................13
3.7. Credit-Based Authorization ................................14
3.8. Heuristic Monitoring ......................................17
3.9. Crypto-Based Identifiers ..................................18
3.10. Pre-Configuration ........................................19
3.11. Semi-Permanent Security Associations .....................20
3.12. Delegation ...............................................21
3.13. Mobile Networks ..........................................21
3.14. Location Privacy .........................................22
4. Discussion .....................................................22
4.1. Cross-Layer Interactions ..................................23
4.2. Experimentation and Measurements ..........................23
4.3. Future Research ...........................................24
5. Security Considerations ........................................24
6. Conclusions ....................................................25
7. Acknowledgments ................................................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
Mobility support for IPv6, or Mobile IPv6, enables mobile nodes to migrate active transport connections and application sessions from one IPv6 address to another. The Mobile IPv6 specification, RFC 3775 [1], introduces a "home agent", which proxies a mobile node at a permanent "home address". A roaming mobile node connects to the home agent through a bidirectional tunnel and can so communicate, from its local "care-of address", as if it was present at the home address. The mobile node keeps the home agent updated on its current care-of address via IPsec-protected signaling messages [40].
IPv6の、またはモバイルIPv6のモビリティサポートは、別の1つのIPv6アドレスから能動輸送接続とアプリケーションセッションを移行するモバイルノードを可能にします。モバイルIPv6仕様は、RFC 3775 [1]は、永久的な「ホームアドレス」にモバイルノードをプロキシ「ホーム・エージェント」を導入します。ローミングモバイルノードは、双方向トンネルを介してホームエージェントに接続し、ホームアドレスに存在していたかのように、そのローカル「気付アドレス」から、通信することができます。モバイルノードは、IPsecで保護されたシグナリングメッセージ[40]を経て、現在の気付アドレスに更新されたホームエージェントを保持します。
In case the correspondent node lacks appropriate mobility support, it communicates with the mobile node's home address, and thus all data packets are routed via the home agent. This mode, Bidirectional Tunneling, increases packet-propagation delays. RFC 3775 hence defines an additional mode for Route Optimization, which allows peers to communicate on the direct path. It requires that the correspondent node can cache a binding between the mobile node's home address and current care-of address. The challenge with Route Optimization is that an administrative relationship between the mobile node and the correspondent node can generally not be presupposed. So how can the two authenticate and authorize the signaling messages that they exchange?
コレスポンデントノードは、適切なモビリティサポートを欠いた場合には、それはモバイルノードのホームアドレスと通信し、したがって、すべてのデータパケットは、ホームエージェントを経由してルーティングされます。このモードは、双方向トンネリングは、パケット伝搬遅延が増加します。 RFC 3775は、したがってピアが直接経路上で通信することを可能にするルート最適化のための追加のモードを定義します。これは、コレスポンデントノードは、モバイルノードのホームアドレスと現在の気付アドレスの間の結合をキャッシュできることが必要です。ルート最適化と課題は、モバイルノードとコレスポンデントノード間の管理の関係は、一般的に前提とすることができないということです。それでは、どの2つの認証とは、彼らが交換するシグナリングメッセージを承認することができますか？
Mobile IPv6 solves this problem by verifying a routing property of the mobile node. Specifically, the mobile node is checked to be reachable at its home address and current care-of address in that it must prove the reception of a home and care-of keygen token, respectively. This is called the "return-routability procedure". It takes place right before a mobile node registers a new care-of address with a correspondent node and is periodically repeated in case the mobile node does not move for a while.
モバイルIPv6は、モバイルノードのルーティング性を検証することによって、この問題を解決します。それは、それぞれ、家庭の受信を証明し、気付生成トークンしなければならないという点で、具体的には、移動ノードはそのホームアドレスと現在の気付アドレスに到達可能であることを確認しています。これは、「リターン・ルータビリティ手順」と呼ばれています。これは、モバイルノードがコレスポンデントノードとの新しい気付けアドレスを登録し、定期的にモバイルノードがしばらく動かない場合に繰り返される直前に行われます。
The advantage of the return-routability procedure is that it is lightweight and does not require pre-shared authentication material. It also requires no state at the correspondent node. On the other hand, the two reachability tests can lead to a handoff delay unacceptable for many real-time or interactive applications such as Voice over IP (VoIP) and video conferencing. Also, the security that the return-routability procedure guarantees might not be sufficient for security-sensitive applications. And finally, periodically refreshing a registration at a correspondent node implies a hidden signaling overhead that may prevent mobile nodes from hibernation during times of inactivity.
リターン・ルータビリティ手順の利点は、軽量で、事前共有認証材料を必要としないことです。また、通信相手ノードで何の状態を必要としません。一方、2回の到達可能性テストでは、このようなボイスオーバーIP（VoIP）の、ビデオ会議など、多くのリアルタイムまたは対話型アプリケーションのために許容できないハンドオフ遅延につながることができます。また、リターン・ルータビリティ・プロシージャの保証はセキュリティに敏感なアプリケーションのために十分ではない可能性がありますセキュリティ。そして最後に、定期的に、通信相手ノードで登録をリフレッシュすることは、非アクティブの時間中に休止状態からの移動ノードを防ぐことが隠されたシグナリングオーバーヘッドを意味します。
Manifold enhancements for Route Optimizations have hence been suggested. This document describes and evaluates various strategies on the basis of existing proposals. It is meant to provide a conceptual framework for further work, which was found to be inevitable in the context of Route Optimization. Many scientists volunteered to review this document. Their names are duly recorded in Section 7. Section 2 analyzes the strengths and weaknesses of Route Optimization and identifies potential objectives for enhancement. Different enhancement strategies are discussed, based on existing proposals, in Section 3. Section 4 discusses the different approaches and identifies opportunities for further research. Section 5 and Section 6 conclude the document.
ルート最適化のためのマニホールド機能強化が故に提案されています。この文書では説明し、既存の提案に基づいて様々な戦略を評価します。ルート最適化の文脈で避けられないことが判明した更なる作業のための概念的枠組みを提供するものです。多くの科学者は、この文書をレビューする志願しました。彼らの名前は正式に7章2節に記録されているルート最適化の強みと弱みを分析し、改善のための潜在的な目標を識別します。異なる強化戦略は3章4は、異なるアプローチについて説明し、さらなる研究のための機会を特定のセクションでは、既存の提案に基づき、議論されています。第5節と第6節では、文書を締結します。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by the Research Group members active in the specific area of work. At the request of their chairs, this document has been comprehensively reviewed by multiple active contributors to the IETF MIP6 Working Group. At the time of this writing, some of the ideas presented in this document have been adopted by the Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) Working Group in the IETF.
この文書では、MobOpts研究グループのコンセンサスを表しています。それは仕事の特定の領域に積極的に研究グループのメンバーによって検討されています。その椅子の要請で、この文書は包括IETF MIP6ワーキンググループに複数のアクティブな貢献者によって検討されています。パフォーマンス、シグナリングおよびハンドオフの最適化（mipshop）IETFでの作業部会：この記事の執筆時点では、この文書のアイデアのいくつかは、IPのためのモビリティによって採用されています。
Mobile IPv6 Route Optimization verifies a mobile node's authenticity through a routing property. An alternative is cryptographic authentication, which requires a binding between a node's identity and some sort of secret information. Although some proposals suggest installing shared secrets into end nodes when possible (see Section 3.10), pre-configuration is not an option for general Internet use for scalability reasons. Authentication based on a Public-Key Infrastructure (PKI) does not require pair-wise pre-configuration. Here, the secret information is the private component of a public/private-key pair, and the binding between a node's identity and private key exists indirectly through the cryptographic properties of public/private-key pairs and a binding between the identity and the public key. An authority trusted by both end nodes issues a certificate that effects this latter binding.
モバイルIPv6ルート最適化は、ルーティングプロパティを介してモバイルノードの正当性を検証します。代替は、ノードのIDと秘密情報のいくつかの並べ替えの間の結合を必要とし、暗号化、認証、です。いくつかの提案が可能な場合（3.10節を参照）エンドノードに共有シークレットをインストール示唆しているが、事前設定は、スケーラビリティの理由から、一般的なインターネット利用のためのオプションではありません。公開鍵基盤（PKI）に基づく認証が対に事前設定は必要ありません。ここでは、秘密情報は、公開鍵/秘密鍵のペアの秘密の成分であり、ノードのIDと秘密鍵の間の結合は、プライベートキー/パブリック・ペアの暗号化プロパティを介して間接的に存在し、アイデンティティと公共の間の結合しますキー。両方のエンドノードによって信頼された機関は、この後者の結合に影響を与える証明書を発行します。
Large-scale use of a PKI, however, was considered unsuitable for mobility management due to the following reasons.
PKIの大規模な使用は、しかし、以下の理由により、モビリティ管理のために適さないと考えられました。
o There are differing opinions on whether a PKI could scale up to hundreds of millions of mobile nodes. Some people argue they do, as there are already examples of certification authorities responsible for millions of certificates. But more important than the expected increase in the number of certificates would be a shift in application patterns. Nowadays, public-key cryptography is used only for those applications that require strong, cryptographic authentication.
O PKIは、モバイルノードの数百万にスケールアップすることができるかどうかについて異なる意見があります。すでに証明書の何百万人の責任認定機関の例があるとして一部の人々は、彼らが主張しています。しかし、証明書の数が予想される増加よりももっと重要なのは、アプリケーション・パターンのシフトになります。今日では、公開鍵暗号方式は、強力な暗号認証を必要とするアプリケーションに使用されます。
If it was used for mobility management as well, certificate checks would become mandatory for any type of application, leading to more checks per user. Busy servers with mobility support might be unwilling to spent the processing resources required for this depending on the service they provide.
それは同様のモビリティ管理のために使用された場合は、証明書のチェックは、ユーザーあたりのチェックにつながる、アプリケーションの任意のタイプのために必須となるだろう。モビリティサポートで忙しいのサーバーは、彼らが提供するサービスに応じて、このために必要な処理リソースを費やして不本意かもしれません。
o Revoked certificates are identified on Certificate Revocation Lists (CRLs), which correspondent nodes with mobility support would have to acquire from certification authorities. CRLs must be kept up to date, requiring periodic downloads. This and the act of checking a certificate against a CRL create overhead that some correspondent nodes might be unwilling to spend.
O失効証明書は、モビリティをサポートしている通信員ノードが認証局から取得しなければならない証明書失効リスト（CRL）、上で識別されます。 CRLは、定期的なダウンロードを必要とし、最新の状態にしておく必要があります。これとCRLに対して証明書を確認する行為は、いくつか通信員ノードが費やすしたくないかもしれないというオーバーヘッドを作成します。
o Certificate verification may take some time and hence interrupt ongoing applications. This can be disturbing from the user's perspective, especially when Route Optimization starts in the middle of a session, or the session is very short-term anyway.
O証明書の検証には時間がかかるので、継続的なアプリケーションを中断することがあります。これは、ルート最適化は、セッションの途中で開始し、またはセッションがとにかく非常に短期の場合は特に、利用者の視点から邪魔することができます。
o The bigger a PKI grows, the more attractive it becomes as an attack target, endangering the Internet as a whole.
O PKIが成長する大きなは、より魅力的には、インターネット全体を危険にさらす、攻撃対象のようになります。
o There is little experience with using home addresses as identifiers in certificates. Although the home address could theoretically be placed into a certificate's Subject Alternate Name field, the entities responsible for IP-address assignment and certification are usually not the same, and it may not be easy to coordinate the two.
Oの証明書中の識別子としてホームアドレスを使用してと、ほとんど経験があります。自宅の住所は、理論的には、証明書のサブジェクト代替名フィールドに配置することができますが、IPアドレスの割り当てや認証を担当するエンティティは、通常は同じではありません、2座標することは容易ではないかもしれません。
For these reasons, this document does not consider direct authentication of mobile nodes based on a PKI. Nevertheless, it does evaluate certificate-based techniques that make the problems identified above more tractable (see Section 3.12).
これらの理由から、このドキュメントでは、PKIに基づくモバイルノードの直接認証を考慮していません。それにもかかわらず、それは（3.12節を参照）は、上記特定された問題をより扱いやすく、証明書ベースの技術を評価しません。
RFC 3775 uses care-of-address tests to probe a mobile node's presence at its claimed location. Alternatively, verification of care-of addresses may be based on infrastructure in the mobile node's local access network. For instance, the infrastructure can verify that the IP source addresses of all packets leaving the network are correct. "Ingress filtering" [38][43] provides this feature to the extent that it inspects the prefix of IP source addresses and ensures topological correctness. Network-access providers that use ingress filtering normally deploy the technique in their first-hop and site-exit routers. Similarly, ISPs may filter packets originating from a downstream network.
RFC 3775は、その特許請求の場所に移動ノードの存在を調べるために気付アドレステストを使用しています。また、気付アドレスの検証は、モバイルノードのローカル・アクセス・ネットワークのインフラに基づくことができます。たとえば、インフラストラクチャは、ネットワークを残してすべてのパケットのIP送信元アドレスが正しいことを確認することができます。 「イングレスフィルタリング」[38] [43]、それはIP送信元アドレスのプレフィックスを検査し、トポロジカル正しさを保証する程度にこの機能を提供します。イングレスフィルタリングを使用するネットワーク・アクセス・プロバイダは、通常、彼らの最初のホップとサイト出口ルータでの技術を展開します。同様に、ISPは下流のネットワークから発信パケットをフィルタリングすることができます。
Ingress filtering may eventually provide a way to replace care-of-address tests. But there are still a number of uncertainties today:
イングレスフィルタリングは、最終的に気付アドレステストを交換する方法を提供することができます。しかし、不確実性の数は今もあります。
o By definition, ingress filtering can prevent source-address spoofing only from those networks that do deploy the technique. As a consequence, ingress filtering needs to be widely, preferably universally, deployed in order to constitute Internet-wide protection. As long as an attacker can get network access without filters, all Internet nodes remain vulnerable.
O定義することで、入力フィルタリングは唯一の技術を展開行い、それらのネットワークから送信元アドレスのスプーフィングを防止することができます。その結果、イングレスフィルタリングが広く、好ましくは普遍的に、インターネット全体の保護を構成するために配備する必要があります。限り、攻撃者はフィルターなしでネットワークへのアクセスを得ることができるよう、すべてのインターネットのノードが脆弱なまま。
o There is little incentive for ISPs to deploy ingress filtering other than conscientiousness. Legal or regulatory prescription as well as financial motivation does not exist. A corrupt ISP might even have a financial incentive not to deploy the technique, if redirection-based denial-of-service (DoS) attacks using Route Optimization ever become possible and are exploited for financial gain. A similar issue was observed with, for example, email spam.
O ISPは誠実以外の入力フィルタリングを展開するためのインセンティブがあります。法律や規制の処方だけでなく、金融動機は存在しません。ルート最適化を使用したリダイレクト・ベースのサービス拒否（DoS）攻撃は、これまで可能となり、金銭上の利益のために利用されている場合は破損しているISPにも、技術を導入しないように報奨金を持っているかもしれません。同様の問題は、電子メール、スパム、例えば、で観察されました。
o Ingress filtering is most effective, and easiest to configure, at the first-hop router. However, since only prefixes are checked, the filters inevitably get less precise the further upstream they are enforced. This issue is inherent in the technique, so the best solution is checking packets as close to the originating nodes as possible, preferably in the first-hop routers themselves.
Oイングレスフィルタリングは、最初のホップルータで、設定するのが最も簡単で最も効果的である、と。プレフィクスだけがチェックされているので、フィルターは必然的にそれらが施行され、さらに上流の少ない正確な取得します。この問題は、技術に固有のものであるので、最善の解決策は、好ましくは、最初のホップルータ自体に、できるだけ発信ノードの近くにパケットをチェックしています。
o A popular implementation of ingress filtering is "Reverse Path Forwarding" (RPF). This technique relies on routes to be symmetric, which is oftentimes the case between edge networks and ISPs, but far less often between peering ISPs. Alternatives to RPF are either manually configured access lists or dynamic approaches that are more relaxed, and thereby less secure, than RPF [43].
Oイングレスフィルタリングの人気の実装は、「リバースパス転送」（RPF）です。この技術は、対称に経路に依存して、しばしばエッジネットワークとISP間の場合であるが、はるかに多くの場合、ピアリングISP間れます。 RPFの代替は、RPF [43]より、手動でアクセスリスト以上緩和される動的なアプローチを構成し、それによってより安全です。
o Another problem with ingress filtering is multi-homing. When a router attempts to forward to one ISP a packet with a source-address prefix from another ISP, filters at the second ISP would block the packet. The IETF seeks to find a way around this [39]. For instance, one could tunnel the packet to the topologically correct ISP, or one could allow source-address changes by means of a locator-identifier split [45].
O入力フィルタリングのもう一つの問題は、マルチホーミングです。ルータは、他のISPからの送信元アドレスのプレフィックスで1 ISPにパケットを転送しようとすると、第二のISPでのフィルタは、パケットをブロックします。 IETFは、この[39]の周りの道を見つけることを目指しています。例えば、一方がトポロジー的に正しいISPへのトンネルパケットか、または一方がロケータ識別子分割[45]によってソースアドレスが変更される可能性があります。
o Finally, RFC 3775 defines an Alternative Care-of Address option that mobile nodes can use to carry a care-of address within a Binding Update message outside of the IPv6 header. Such an address is not subject to inspection by ingress filtering and would have to be verified through other means [14].
O最後に、RFC 3775は、移動ノードがIPv6ヘッダーの外部Binding Updateメッセージ内の気付アドレスを運ぶために使用できる代替気付アドレスオプションを定義します。そのようなアドレスは、イングレスフィルタリングによる検査の対象ではなく、他の手段[14]を介して検証されなければなりません。
Although these problems are expected to get solved eventually, there is currently little knowledge on how applicable and deployable, as a candidate for care-of-address verification, ingress filtering will be. High investments or administrative hurdles could prevent a large, preferably universal deployment of ingress filtering, which would hinder Internet-wide protection, as mentioned in the first bullet. For these reasons, this document does not consider ingress filtering as a viable alternative to care-of-address tests, although things may be different in the future.
これらの問題が最終的に解決し得ることが予想されますが、どのように適用されると、展開にはほとんど知識が現在存在し、気付アドレス検証のための候補として、イングレスフィルタリングが可能になります。最初の箇条書きで説明したように、高い投資や管理のハードルは、インターネット全体の保護を妨げるイングレスフィルタリングの大、好ましくは普遍的展開を、防ぐことができます。物事が将来的に異なる場合がありますが、これらの理由から、このドキュメントでは、テスト・オブ・アドレスを気にする実行可能な代替としてイングレスフィルタリングを考慮していません。
Wireless environments with frequently moving nodes feature a number of salient properties that distinguish them from environments with stationary nodes or nodes that move only occasionally. One important aspect is the efficiency of mobility management. Nodes may not bother about a few round-trip times of handoff latency if they do not change their point of IP attachment often. But the negative impact that a mobility protocol can have on application performance increases with the level of mobility. Therefore, in order to maximize user satisfaction, it is important to reduce the handoff latency that the mobility protocol adds to existing delays in other places of the network stack. A related issue is the robustness of the mobility protocol, given that temporary outage of mobility support can render mobile nodes incapable of continuing to communicate.
頻繁に移動ノードと無線環境では、たまにしか移動固定ノードまたはノードと環境と区別顕著な特性の数を備えています。 1つの重要な側面は、モビリティ管理の効率化です。彼らは多くの場合、IPアタッチメントのそのポイントを変更しない場合、ノードは、ハンドオフ遅延のいくつかのラウンドトリップ時間については気にしないことがあります。しかし負の影響は、モビリティプロトコルは、モビリティのレベルのアプリケーションのパフォーマンスが増加するに与えることができます。そのため、ユーザーの満足度を最大化するためには、モビリティプロトコルは、ネットワークスタックの他の場所での既存の遅延に追加されますハンドオフ遅延を低減することが重要です。関連する問題は、モビリティサポートの一時的な停止が通信し続けることができないモバイルノードをレンダリングすることができますことを考えると、モビリティプロトコルの堅牢性です。
Furthermore, the wireless nature of data transmissions makes it potentially easier for an attacker to eavesdrop on other nodes' data or send data on behalf of other nodes. While applications can usually authenticate and encrypt their payload if need be, similar security measures may not be feasible for signaling packets of a mobility protocol, in particular if communicating end nodes have no pre-existing relationship.
さらに、データ伝送のワイヤレス性質は、他のノードのデータを盗聴や他のノードの代わりにデータを送信するために、攻撃者のために、それは潜在的に容易になります。アプリケーションは、通常、認証および必要であれば、それらのペイロードを暗号化することができるが、同様のセキュリティ対策は、通信エンドノードがない既存の関係を持たない場合、特に、モビリティプロトコルのパケットをシグナリングするための実行可能でないかもしれません。
Given the typically limited bandwidth in a wireless medium, resources ought to be spent in an economic matter. This is especially important for the amount of signaling that a mobility protocol requires.
無線媒体で一般的に限られた帯域幅を考えると、資源は経済問題に費やされるべきです。これは、モビリティプロトコルが必要とするシグナリング量のために特に重要です。
Endeavors to enhance RFC 3775 Route Optimization generally strive for reduced handoff latency, higher security, lower signaling overhead, or increased protocol robustness. These objectives are herein discussed from a requirements perspective; the technical means to reach the objectives is not considered, nor is the feasibility of achieving them.
RFC 3775ルート最適化を向上させる努力は、一般的に減少ハンドオフ遅延、より高いセキュリティ、低いシグナリングオーバーヘッド、または増加プロトコルの堅牢性のために努力します。これらの目的は、本明細書の要件の観点から議論されています。目標を達成するための技術的手段が考えられ、またそれらを達成するための可能性であるされていません。
One important objective for improving Route Optimization is to reduce handoff latencies. Assuming that the home-address test dominates the care-of-address test in terms of latency, a Mobile IPv6 handoff takes one round-trip time between the mobile node and the home agent for the home registration, a round-trip time between the mobile node and the home agent plus a round-trip time between the home agent and the correspondent node for the home-address test, and a one-way time from the mobile node to the correspondent node for the propagation of the Binding Update message. The first packet sent to the new care-of address requires an additional one-way time to propagate from the correspondent node to the mobile node. The mobile node can resume communications 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.
ルート最適化を改善するための1つの重要な目的は、ハンドオフの待ち時間を減らすことです。ホームアドレステストは、レイテンシの面で気付アドレステストを支配すると仮定すると、モバイルIPv6のハンドオフは、移動ノードとホーム登録のためのホームエージェントとの間で1往復時間を要するとの間の往復時間Binding Updateメッセージの伝播のためのコレスポンデントノードへの移動ノードから移動ノードとホームアドレステストのためのホームエージェントとコレスポンデントノードとの間にホームエージェントプラス往復時間、および片道時間。新気付けアドレスに送信された最初のパケットは、モバイルノードに対応するノードから伝播するための追加の片道時間を要します。それはBinding Updateメッセージを派遣した直後に、移動ノードが通信を再開することができます。それは相手ノードからのBinding Acknowledgementメッセージを要求した場合、これが受信されるまでしかし、通信は通常、遅れています。
These delays are additive and are not subsumed by 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.
これらの遅延は、添加剤であり、IP層やリンク層で他の遅延によって包含されていません。彼らは、インタラクティブおよびリアルタイム・アプリケーションのための知覚品質の劣化を引き起こす可能性があります。長いハンドオフ待ち時間は、連続する再送タイムアウトと劣化スループットにつながる可能性があるのでTCPバルクデータ転送も同様に影響を受けます。
The return-routability procedure was designed with the objective to provide a level of security that compares to that of today's non-mobile Internet [46]. As such, it protects against impersonation, denial of service, and redirection-based flooding attacks that would not be possible without Route Optimization. This approach is based on an assumption that a mobile Internet cannot become any safer than the non-mobile Internet.
リターン・ルータビリティ手順は、今日の非モバイル・インターネット[46]のものに比較してセキュリティのレベルを提供する目的で設計されました。このように、それはなりすまし、サービス拒否、およびルート最適化なしで可能ではないでしょうリダイレクションベースのフラッディング攻撃から保護します。このアプローチは、モバイルインターネットは非モバイルインターネットよりも任意のより安全になることができないという仮定に基づいています。
Applications that require a security level higher than what the return-routability procedure can provide are generally advised to use end-to-end protection such as IPsec or Transport Layer Security (TLS). But even then they are vulnerable to denial of service. This motivates research for stronger Route Optimization security. Security enhancements may also become necessary if future technological improvements mitigate some of the existing mobility-unrelated vulnerabilities.
リターン・ルータビリティ手順は、一般的にIPsecまたはトランスポート層セキュリティ（TLS）などのエンド・ツー・エンドの保護を使用することをお勧めし提供することができるものよりも高いセキュリティレベルを必要とするアプリケーション。それでも、彼らはサービス拒否の脆弱です。これは、より強力なルート最適化、セキュリティのための研究の動機。今後の技術の改良は、既存のモビリティ・無関係な脆弱性のいくつかを軽減する場合には、セキュリティの強化も必要になる場合があります。
One particular issue with Route Optimization is location privacy because route-optimized packets carry both home and care-of addresses in plaintext. A standard workaround is to fall back to Bidirectional Tunneling when location privacy is needed. Packets with the care-of address are then transferred only between the mobile node and the home agent, where they can be encrypted through IPsec Encapsulating Security Payload (ESP) [42]. But even Bidirectional Tunneling requires the mobile node to periodically re-establish IPsec security associations with the home agent so as to become untraceable through Security Parameter Indexes (SPIs).
経路最適化パケットは、両方の家を運ぶと気付アドレス平文でいるのでルート最適化の一つの特定の問題は、位置プライバシーです。標準の問題を回避するには、位置プライバシーが必要な場合、双方向トンネリングにフォールバックすることです。気付アドレスを持つパケットは、その後、彼らだけがIPsecのカプセル化セキュリティペイロード（ESP）[42]によって暗号化することができ、移動ノードとホームエージェントとの間で転送されます。しかし、たとえ双方向トンネリングは、セキュリティパラメータインデックス（SPIの）を通じて追跡不可能となるように、定期的にホームエージェントとのIPsecセキュリティアソシエーションを再確立するために、モバイルノードが必要です。
Route Optimization requires periodic signaling even when the mobile node does not move. The signaling overhead amounts to 7.16 bits per second if the mobile node communicates with a stationary node [6]. 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 refreshes consume a fraction of the wireless bandwidth that one could use more efficiently. Optimizations for reduced signaling overhead could mitigate these issues.
ルート最適化は、モバイルノードが移動していなくても定期的なシグナリングを必要とします。移動ノードが固定ノード[6]と通信する場合、シグナリングオーバーヘッドは、毎秒7.16ビットになります。両方のピアが携帯している場合は倍になります。ノードが通信する場合、このオーバーヘッドは無視できるが、それは不活性であり、しばらくの間同じ場所に留まるモバイルノードのための問題であることができます。これらのノードは、一般的にバッテリーを節約するためにスタンバイモードに行くことを好みます。また、定期的なリフレッシュは1つが、より効率的に使用できる無線帯域幅の一部を消費します。減少シグナリングオーバーヘッドのための最適化は、これらの問題を軽減することができます。
Route Optimization could conceptually enable continued communications during periods of temporary home-agent unavailability. The protocol defined in RFC 3775 does not achieve this independence, however, as the home agent plays an active role in the return-routability procedure. Appropriate enhancements could increase the independence from the home agent and thus enable robust Route Optimization even in the absence of the home agent.
ルート最適化は、概念的には、一時的なホームエージェントを使用できない期間の間、継続的なコミュニケーションを可能にすることができます。ホームエージェントは、リターン・ルータビリティ手順で積極的な役割を果たしているとして、RFC 3775で定義されたプロトコルは、しかし、この独立性を達成していません。適切な拡張機能は、ホームエージェントからの独立性を高めるため、でも、ホームエージェントが存在しない状態で堅牢なルート最適化を可能にすることができます。
A large body of effort has recently gone into improving Mobile IPv6 Route Optimization. Some of the proposed techniques are modifications to the return-routability procedure, while others replace the procedure by alternative mechanisms. Some of them operate end-to-end; others introduce network-side mobility support. In most cases, it is the combination of a set of techniques that is required to gain a complete -- that is, efficient and secure -- route-optimization mechanism.
努力の大きな体は、最近、モバイルIPv6ルート最適化を向上させることになりました。他の人が別の機構によって手順を交換しながら、提案された技術の一部は、リターン・ルータビリティ手順の変更です。そのうちのいくつかは、エンドツーエンドで動作します。他の人がネットワーク側のモビリティサポートをご紹介します。 、つまり効率的で安全 - - ほとんどの場合、それは完全に得るために必要とされる技術の集合の組み合わせでルート最適化メカニズム。
RFC 3775 uses IP-address tests to ensure that a mobile node is live and on the path to a specific destination address: The home-address test provides evidence that the mobile node is the legitimate owner of its home address; the care-of-address test detects spoofed care-of addresses and prevents redirection-based flooding attacks. Both tests can be performed in parallel.
RFC 3775は、モバイルノードがライブや、特定の宛先アドレスへのパス上にあることを保証するために、IPアドレスのテストを使用しています：ホームアドレステストは、モバイルノードがそのホームアドレスの正当な所有者であるという証拠を提供します。気付アドレステストは、偽装された気付アドレスを検出し、リダイレクションベースのフラッディング攻撃を防ぎます。両方の試験を並行して行うことができます。
A home-address test should be initiated by the mobile node so that the correspondent node can delay state creation until the mobile node has authenticated. The care-of-address test can conceptually be initiated by either side. It originates with the mobile node in RFC 3775, but with the correspondent node in [16] and [22]. The correspondent-node-driven approach suggests itself when authentication is done through other means than a home-address test.
モバイルノードが認証されるまで、コレスポンデントノードは、状態の作成を遅らせることができるようにホームアドレステストは、モバイルノードによって開始されなければなりません。気付アドレステストは、概念的にはどちらの側で開始することができます。これは、RFC 3775で、移動ノードと発信が、[16]及び[22]における対応ノードを有します。認証はホームアドレステスト以外の手段を介して行われたときに通信員ノード主導のアプローチは、自分自身を示唆しています。
Important advantages of IP-address tests are zero-configurability and the independence of ancillary infrastructure. As a disadvantage, IP-address tests can only guarantee that a node is on the path to the probed address, not that the node truly owns this address. This does not lead to new security threats, however, because the types of attacks that an on-path attacker can do with Route Optimization are already possible in the non-mobile Internet [46].
IPアドレスのテストの重要な利点は、ゼロ設定機能および補助インフラの独立しています。欠点として、IPアドレスのテストが唯一のノードは、ノードが本当にこのアドレスを所有していることを、プローブされたアドレスへのパス上にないことを保証することができます。上のパス攻撃者がルート最適化を行うことができます攻撃の種類は非モバイルインターネット[46]で既に可能ですので、これは、しかし、新たなセキュリティ脅威につながるものではありません。
RFC 3775 protects certain signaling messages, exchanged between a mobile node and its home agent, through an authenticated and encrypted tunnel. This prevents unauthorized nodes on that path, including eavesdroppers in the mobile node's wireless access network, from listening in on these messages.
RFC 3775は、特定のシグナリングメッセージを保護し、認証され、暗号化されたトンネルを介して、モバイルノードとそのホームエージェントの間で交換。これは、これらのメッセージに耳を傾け中から、モバイルノードの無線アクセスネットワーク内の盗聴など、そのパス上の不正のノードを、防ぐことができます。
Given that a pre-existing end-to-end security relationship between the mobile node and the correspondent node cannot generally be assumed, this protection exists only for the mobile node's side. If the correspondent node is immobile, the path between the home agent and the correspondent node remains unprotected. This is a path between two stationary nodes, so all types of attacks that a villain could wage on this path are already possible in the non-mobile Internet. In case the correspondent node is mobile, it has its own home agent, and only the path between the two (stationary) home agents remains unprotected.
モバイルノードとコレスポンデントノード間の既存のエンドツーエンドのセキュリティ関係が一般的に想定することができないことを考えると、この保護は、モバイルノードの側のために存在します。コレスポンデントノードが不動である場合は、ホームエージェントとコレスポンデントノード間のパスが保護されていないまま。これには、悪役は、このパスに賃金ができた攻撃のすべての種類は、非モバイルインターネットですでに可能であり、2つの固定ノード間のパスです。通信相手ノードがモバイルである場合には、自身のホームエージェントを有し、および2つの（固定）ホームエージェントとの間の唯一のパスが保護されていないままです。
Many Mobile IPv6 implementations [29][31] defer a correspondent registration until the associated home registration has been completed successfully. In contrast to such "conservative" behavior, a more "optimistic" approach is to begin the return-routability procedure in parallel with the home registration [52]. Conservative behavior avoids a useless return-routability procedure in case the home registration fails. This comes at the cost of additional handoff delay when the home registration is successful. Optimistic behavior saves this delay, but the return-routability procedure will be in vain should the corresponding home registration be unsuccessful.
多くのモバイルIPv6の実装[29] [31]関連するホーム登録が正常に完了するまで通信員登録を延期します。そのような「保存的」挙動とは対照的に、より多くの「楽観的」アプローチは、ホーム登録[52]と並列に戻りルータビリティ手順を開始することです。保守的な行動は、ホーム登録が失敗した場合には役に立たないリターン・ルータビリティ手順を回避することができます。ホーム登録が成功したとき、これは、追加のハンドオフ遅延のコストがかかります。楽観動作がこの遅延を保存しますが、対応するホーム登録が失敗する必要があり、リターン・ルータビリティ手順は無駄になります。
While a parallelization of the home registration and the return-routability procedure is feasible within the bounds of RFC 3775, the specification does not permit mobile nodes to continue with the correspondent registration, by sending a Binding Update message to the correspondent node, until a Binding Acknowledgment message indicating successful home registration has been received. This is usually not a problem because the return-routability procedure is likely to take longer than the home registration anyway. However, some optimizations (see Section 3.4) reduce the delay caused by the return-routability procedure. A useful improvement is then to allow Binding Update messages to be sent to correspondent nodes even before the home registration has been acknowledged.
ホーム登録とリターン・ルータビリティ手順の並列化は、RFC 3775の範囲内で実現可能であるが、仕様がバインディングまで、コレスポンデントノードにBinding Updateメッセージを送信することにより、通信員登録を続行するには、モバイルノードを許可しません成功ホーム登録を示す肯定応答メッセージが受信されています。リターン・ルータビリティ手順はとにかくホーム登録よりも長い時間がかかる可能性があるので、これは通常は問題ではありません。しかし、いくつかの最適化は、リターン・ルータビリティ手順による遅延を減らす（3.4節を参照します）。便利な改善は、その後、バインディング更新メッセージを通信員に送信できるようにするためには、自宅の登録が確認されていても前にノードれます。
The drawback of optimistic behavior is that a lost, reordered, or rejected Binding Update message can cause data packets to be discarded. Nevertheless, packet loss would have similar negative impacts on conservative approaches, so the mobile node needs to be prepared for the possible loss of these packets in any case.
楽観的行動の欠点は、並べ替え、失われた、または拒否されたBinding Updateメッセージは、データパケットが破棄される可能性がありますということです。モバイルノードがいずれの場合にも、これらのパケットの損失の可能性のために準備する必要があるので、それにもかかわらず、パケットロスは、保守的なアプローチに類似した負の影響を有するであろう。
The critical handoff phase, during which the mobile node and the correspondent node cannot fully communicate, spans the home registration and the correspondent registration, including the return-routability procedure. One technique to shorten this phase is to accomplish part of the signaling proactively before the handoff. In particular, the home-address test can be done in advance without violating the specifications of RFC 3775 [52][51].
モバイルノードとコレスポンデントノードが完全に通信することはできません、その間の重要なハンドオフ相は、リターン・ルータビリティ手順を含むホーム登録と通信員登録を、またがっています。このフェーズを短縮する一つの技術は積極的にハンドオフ前のシグナリングの一部を達成することです。具体的には、ホーム・アドレス試験は、[52] [51] RFC 3775の仕様に違反することなく、事前に行うことができます。
In order to have a fresh home keygen token ready for a future handoff, the mobile node should initiate a proactive home-address test at least once per token lifetime, that is, every 3.5 minutes. This does at most double the signaling overhead spent on home-address tests given that correspondent registrations must be refreshed every
将来のハンドオフのための準備ができてトークンの新鮮なホーム鍵を持っているために、モバイルノードが少なくとも一度トークン寿命あたりの積極的なホームアドレステストを開始する必要があり、それは、すべての3.5分です。これは、ほとんどのダブルオーバーヘッド通信員登録は、すべてをリフレッシュしなければならないことを考えるとホームアドレステストに費やしたシグナリングありません
7 minutes even when the mobile node does not move for a while. An optimization is possible where the mobile node's local link layer can anticipate handoffs and trigger the home-address test in such a case. [6] or [54] reduce the frequency of home-address tests even further. Proactive care-of-address tests are possible only if the mobile node is capable of attaching to two networks simultaneously. Dual attachment is possible if the link-layer technology enables it with a single interface [10], or if the mobile node is endowed with multiple interfaces [7].
モバイルノードがしばらく移動しなくても7分。モバイルノードのローカルリンク層は、ハンドオフを予測し、そのような場合にはホームアドレステストをトリガすることができる場所最適化が可能です。 [6]又は[54]さらに、ホーム・アドレス・テストの頻度を減らします。積極的な気付アドレス試験は、モバイルノードが、同時に2つのネットワークに結合することができる場合にのみ可能です。二重結合はリンク層技術は、単一のインタフェース[10]とそれを可能にする場合に可能である、又は移動ノードが複数のインタフェースを持たれている場合、[7]。
Without the assumption that a mobile node can simultaneously attach to multiple networks, proactive care-of-address tests, executed prior to handoff, are not an option. A correspondent node may instead authorize a mobile node to defer the care-of-address test until an early, tentative binding has been registered [52][51]. This in combination with a technique to eliminate the handoff delay of home-address tests (see Section 3.4 and Section 3.9) facilitates early resumption of bidirectional communications subsequent to handoff. The care-of address is called "unverified" during the concurrent care-of-address test, and it is said to be "verified" once the correspondent node has obtained evidence that the mobile node is present at the address. A tentative binding's lifetime can be limited to a few seconds.
モバイルノードが同時に複数のネットワークに接続できることを仮定しないと、ハンドオフの前に実行され積極的な気付アドレステストは、オプションではありません。通信相手ノードではなく早期まで気付アドレステストを延期するためにモバイルノードを認可することができる、仮結合が登録されている[52] [51]。このホーム・アドレス・テストのハンドオフ遅延を解消するための技術との組み合わせでは、（3.4節および3.9節を参照）、ハンドオフ後に双方向通信の早期再開を容易にします。気付アドレスは、同時気付アドレステスト中に「未検証」と呼ばれ、相手ノードは、モバイルノードがアドレスに存在するという証拠を入手した後、「検証」と言われています。暫定的な結合の寿命は数秒に制限することができます。
Home-address tests must not be accomplished concurrently, however, given that they serve the purpose of authentication. They guarantee that only the legitimate mobile node can create or update a binding pertaining to a particular home address.
ホームアドレステストは、彼らが認証の目的を果たすことを考えると、しかし、同時に達成することはできません。彼らは唯一の合法的なモバイルノードが特定のホームアドレスに関連するバインディングを作成または更新できることを保証します。
mobile node home agent correspondent node
| | |
| | |
|--Home Test Init------>|---------------------->|
| | |
| | |
|<----------------------|<-----------Home Test--|
| | |
| |
~~+~~ handoff |
| |
|--Early Binding Update------------------------>| -+-
|--Care-of Test Init -------------------------->| |
| | |
| | | care-of
|<----------------Early Binding Acknowledgment--| | address
|<-------------------------------Care-of Test---| | unverified
| | |
| | |
|--Binding Update------------------------------>| -+-
| |
| |
|<----------------------Binding Acknowledgment--|
| |
Figure 1: Concurrent Care-of Address Tests
図1：同時気付アドレス試験
Figure 1 illustrates how concurrent care-of-address tests are used in [52][51]: As soon as the mobile node has configured a new care-of address after a handoff, it sends to the correspondent node an Early Binding Update message. Only a home keygen token, obtained from a proactive home-address test, is required to sign this message. The correspondent node creates a tentative binding for the new, unverified care-of address when it receives the Early Binding Update message. This address can be used immediately. The mobile node finally sends a (standard) Binding Update message to the correspondent node when the concurrent care-of-address test is complete. Credit-Based Authorization (see Section 3.7) prevents misuse of care-of addresses while they are unverified.
すぐに、モバイルノードは、ハンドオフの後、新たな気付アドレスを構成しているように、それが通信相手ノードに送信アーリーバインディング更新メッセージ：図1は、気付アドレス試験は、[52] [51]に使用される方法同時示し。積極的なホームアドレステストから得た唯一のホーム鍵生成トークンは、このメッセージに署名する必要があります。コレスポンデント・ノードは、それが早期バインディング更新メッセージを受信したときに、新しい、未検証の気付アドレスのバインディング暫定的に作成されます。このアドレスは、すぐに使用することができます。同時気付アドレステストが完了すると、モバイルノードは、最終的には、通信相手ノードに（標準）Binding Updateメッセージを送信します。彼らは未検証している間、クレジットベースの認証（セクション3.7を参照）気付アドレスの不正使用を防止します。
Given that a home registration is faster than a correspondent registration in the absence of additional optimizations, the mobile node may request its traffic to be routed through the home address until a new binding has been set up at the correspondent node [52][51]. The performance of such diverted routing depends on the propagation properties of the involved routes, however.
新しいバインディングは、コレスポンデントノードに設定されているまでホーム登録は追加の最適化の不在下での通信員登録よりも高速であることを考えると、モバイルノードは、そのトラフィックがホームアドレスを経由してルーティングされるように要求することができる[52] [51] 。そのような迂回経路の性能は、しかし、関与する経路の伝播特性に依存します。
For packets to be diverted via the home address, signaling is necessary with both the home agent and the correspondent node. The home agent must be informed about the new care-of address so that it can correctly forward packets intercepted at the home address. The correspondent node continues to send packets to the old care-of address until it receives a Binding Update message indicating that the current binding is no longer valid and ought to be removed. This request requires authentication through a home-address test in order to prevent denial of service by unauthorized nodes. The test can be accomplished in a proactive way (see Section 3.4).
パケットはホームアドレスを経由して流用されるためには、シグナリングはホームエージェントとコレスポンデントノードの両方を持つ必要があります。ホームエージェントは、新しい気付けアドレスにはホームアドレスで傍受パケットを転送正しくできるように知らされなければなりません。コレスポンデント・ノードは、それが現在のバインディングがもはや有効でないと削除されるべきであることを示すBinding Updateメッセージを受信するまで、旧気付けアドレスにパケットを送信し続けます。この要求は、不正ノードによってサービス拒否を防ぐために、ホームアドレステストによる認証が必要です。テストは積極的な方法で達成することができます（3.4節を参照してください）。
The mobile node may send packets via the home address as soon as it has dispatched the Binding Update message to the home agent. It may send outgoing packets along the direct path once a Binding Update message for the new care-of address has been sent to the correspondent node.
モバイルノードは、すぐにそれがホームエージェントにバインディング更新メッセージを派遣したとして、ホームアドレスを経由してパケットを送信することができます。新しい気付アドレスのバインディング更新メッセージをコレスポンデントノードに送信された後は、ダイレクトパスに沿って発信パケットを送信することができます。
It depends on the propagation latency on the end-to-end path via the home agent relative to the latency on the direct path for how long the correspondent node should continue to send packets to the home address. If the former path is slow, it may be better to queue some of the packets until the correspondent registration is complete and packets can be sent along the direct route.
これは、コレスポンデントノードは、ホームアドレスにパケットを送信し続ける必要がありますどのくらいのための直接経路上の待ち時間に、ホームエージェントの相対的な経由でエンド・ツー・エンドのパス上の伝播遅延時間に依存します。元のパスが遅い場合、通信員登録が完了し、パケットを直接ルートに沿って送信することができるようになるまで、いくつかのパケットをキューに入れる方が良いかもしれません。
Concurrent care-of-address tests (see Section 3.5) require protection against spoofed unverified care-of addresses and redirection-based flooding attacks. Credit-Based Authorization [50] is a technique that provides such protection based on the following three hypotheses:
同時気付アドレステスト（3.5節を参照）が偽装された未検証の気付アドレスとリダイレクションベースのフラッディング攻撃に対する保護を必要としています。クレジットベースの許可[50]以下の三つの仮説に基づいて、そのような保護を提供する技術です。
1. A flooding attacker typically seeks to somehow multiply the packets it assembles for the purpose of the attack because bandwidth is an ample resource for many attractive victims.
1.フラッディング攻撃者は、通常、何らかの形で、帯域幅は、多くの魅力的な被災者のための十分なリソースであるため、それが攻撃の目的のために組み立て、パケットを乗算することを目指しています。
2. An attacker can always cause unamplified flooding by generating bogus packets itself and sending them to its victim directly.
2.攻撃者は常に偽のパケット自体を生成し、直接その犠牲者に送信することにより、増幅されていない洪水を引き起こす可能性があります。
3. Consequently, the additional effort required to set up a redirection-based flooding attack pays off for the attacker only if amplification can be obtained this way.
3.その結果、リダイレクションベースのフラッディング攻撃を設定するために必要な追加の努力は増幅がこの方法を得ることができた場合にのみ、攻撃者のためにオフに支払っています。
On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any amplification that can be reached through it. This is accomplished by limiting the data a correspondent node can send to an unverified care-of address of a mobile node by the data that the correspondent node has recently received from that mobile node. (See Section 3.5 for a definition on when a care-of address is verified and when it is unverified.) A redirection-based flooding attack is thus 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 must keep Mobile IPv6 state to coordinate the redirection.
これに基づき、むしろ最初の場所で悪意のあるパケットリダイレクションを排除するよりも、クレジットベース認証は、それを介して到達することができる任意の増幅を防ぐことができます。これは、通信相手ノードが最近、移動ノードから受信したデータによって検証されていないモバイルノードの気付アドレスに送信することができ、データに対応するノードを制限することによって達成されます。 （気付けアドレスが確認されたときに定義については、セクション3.5を参照してくださいませんし、それが検証されていないとき。）リダイレクションベースのフラッディング攻撃は何のため、攻撃者自身が被害者に偽のパケットを送信し、純粋なダイレクト氾濫、より魅力的です。これは、攻撃者がリダイレクトを調整するために、モバイルIPv6の状態を維持しなければならないことを考えると、実際にあまり魅力的です。
mobile node correspondent node
| |
| |
address |--data----------------->| credit += size(data)
verified | |
|--data----------------->| credit += size(data)
|<-----------------data--| don't change credit
| |
address + address change |
unverified |<-----------------data--| credit -= size(data)
|--data----------------->| credit += size(data)
|<-----------------data--| credit -= size(data)
| |
|<-----------------data--| credit -= size(data)
| X credit < size(data)
| | ==> Do not send!
address | |
verified |<-----------------data--| don't change credit
| |
Figure 2: Credit-Based Authorization
図2：クレジットベースの許可
Figure 2 illustrates Credit-Based Authorization for an exemplifying exchange of data packets: The correspondent node measures the bytes received from the mobile node. When the mobile node registers a new care-of address, the correspondent node labels this address "unverified" and sends packets there as long as the sum of the packet sizes does not exceed the measured, received data volume. A concurrent care-of-address test is meanwhile performed. Once the care-of address has been verified, the correspondent node relabels the address from "unverified" to "verified". Packets can then be sent to the new care-of address without restrictions. When insufficient credit is left while the care-of address is still "unverified", the correspondent node stops sending further packets to the address until the verification completes. The correspondent node may drop these packets, direct them to the mobile node's home address, or buffer them for later transmission when the care-of address is verified. Figure 2 does not show Mobile IPv6 signaling packets.
バイトは、モバイルノードから受信した通信相手ノードの測定：図2は、データパケットの一例を交換するためのクレジットベースの認可を示します。モバイルノードは、「未確認」新気付けアドレス、コレスポンデントノードのラベル、このアドレスを登録し、測定し、受信したデータ量を超えていないパケットサイズの合計限り、そこにパケットを送信するとき。同時気付アドレステストがその間に行われます。気付けアドレスが確認された後、コレスポンデント・ノードは、「検証」するために「未確認」からアドレスのラベル付けを再度行います。パケットはその後、制限なしで新しい気付けアドレスに送信することができます。気付けアドレスはまだ「未確認」である一方、不十分なクレジットが残っている場合は、コレスポンデントノードは、検証が完了するまでのアドレスにさらにパケットの送信を停止します。コレスポンデントノードは、これらのパケットをドロップするモバイルノードのホームアドレスにそれらを指示、または気付アドレスが確認されたときに、後の送信のためにそれらをバッファリングすることができます。図2は、モバイルIPv6シグナリングパケットを示していません。
The correspondent node ensures that the mobile node's acquired credit gradually decreases over time. This "aging" prevents the mobile node from building up credit over a long time. A malicious node with a slow Internet connection could otherwise provision for a burst of redirected packets that does not relate to its own upstream capacity.
コレスポンデントノードは、モバイルノードの買収信用が時間とともに徐々に減少していることを保証します。この「老化は」長い時間をかけて信用を構築するから、移動ノードを防ぐことができます。低速のインターネット接続を持つ悪意のあるノードは、自身の上流の能力に関係しないリダイレクトされたパケットのバーストのためにそうでなければ提供できました。
Allocating the mobile node's credit based on the packets that the mobile node sends and reducing the credit based on packets that the mobile node receives is defined as "Inbound Mode". (The correspondent node is in control of credit allocation, and it computes the credit based on inbound packets received from the mobile node.) A nice property of Inbound Mode is that it does not require support from the mobile node. The mobile node neither needs to understand that Credit-Based Authorization is effective at the correspondent node, nor does it have to have an idea of how much credit it has at a particular point in time.
モバイルノードが送信すると、モバイルノードは、「インバウンドモード」として定義されている受信パケットに基づいてクレジットを削減するパケットに基づいて、移動ノードのクレジットを割り当てます。 （コレスポンデントノードは、信用割り当ての制御であり、それはモバイルノードから受信した着信パケットに基づいてクレジットを計算する。）受信モードの素晴らしい特性は、モバイルノードからの支援を必要としないことです。モバイルノードは、どちらもそのクレジットベース認証は、通信相手ノードで有効であることを理解する必要がなく、またそれが特定の時点で持っているどのくらいの信用のアイデアを持っている必要がありません。
Inbound Mode works fine with applications that send comparable data volumes into both directions. On the other hand, the mode may prevent the mobile node from collecting the amount of credit it needs for a handoff when applications with asymmetric traffic patterns are in use. For instance, file transfers and media streaming are characterized by high throughput towards the client, typically the mobile node, and comparably little throughput towards the serving correspondent node.
インバウンドモードは両方向に比較可能なデータ量を送信するアプリケーションで正常に動作します。一方、モードは、非対称トラフィックパターンを持つアプリケーションを使用しているときに、ハンドオフに必要なクレジットの量を収集からモバイルノードを防止することができます。例えば、ファイル転送とメディアストリーミングは、クライアント、典型的には、モバイルノード、及びサービス提供通信相手ノードに向かって比較的少ないスループットに対して高いスループットによって特徴付けられます。
An additional "Outbound Mode" was designed to better accommodate applications with asymmetric traffic patterns. In Outbound Mode, packets that the correspondent node sends to the mobile node determine both, how much the credit increases while the current care-of address is verified, and how much the credit shrinks while the care-of address is unverified. This resolves the issue with asymmetric traffic patterns.
追加の「アウトバウンドモードは、」より良い非対称トラフィックパターンを持つアプリケーションに対応するように設計されました。送信モードでは、コレスポンデント・ノードは、現在の気付アドレスを確認し、気付アドレスが未確認であるが、どのくらい信用が収縮している間どのくらい信用増加の両方を決定するモバイルノードに送信するパケット内。これは、非対称的なトラフィックパターンで問題を解決します。
The security of Outbound Mode is based on the further hypothesis that the mobile node invests comparable effort for packet reception and transmission in terms of bandwidth, memory, and processing capacity. This justifies why credit, allocated for packets received by the mobile node, can be turned into packets that the correspondent node sends. The question is, though, how the correspondent node can determine how many of the packets sent to a mobile node are actually received and processed by that mobile node. Relying on transport-layer acknowledgments is not an option as such messages can easily be faked. Outbound Mode hence defines its own feedback mechanism, Care-of Address Spot Checks, which is robust to spoofing. The correspondent node periodically tags packets that it sends to the mobile node with a random, unguessable number, a so-called Spot Check Token. When the mobile node receives a packet with an attached Spot
送信モードのセキュリティは、モバイルノードは、帯域幅、メモリ、処理能力の点でパケットの送受信のための同等の労力を投資さらに仮説に基づいています。モバイルノードが受信したパケットに割り当てられたクレジットは、コレスポンデントノードが送信するパケットに変換することができますなぜこれが正当化。質問は、コレスポンデントノードは、実際に受信し、そのモバイルノードによって処理される方法をモバイルノードに送信されたパケットの数を決定することができますどのように、しかし、です。このようなメッセージを簡単に偽造することが可能とトランスポート層の承認に依存することはオプションではありません。アウトバウンドモードは、したがって、なりすましに強い独自のフィードバック機構、気付アドレスのスポットチェックを定義します。コレスポンデントノードは、定期的に、それはランダム、推測できない数、いわゆるスポットチェックトークンによるモバイルノードに送信するパケットをタグ付けします。モバイルノードは、添付のスポットを持つパケットを受信したとき
Check Token, it buffers the token until it sends the next packet to the correspondent node. The Spot Check Token is then included in this packet. Upon reception, the correspondent node verifies whether the returned Spot Check Token matches a token recently sent to the mobile node. New credit is allocated in proportion to the ratio between the number of successfully returned Spot Check Tokens and the total number of tokens sent. This implies that new credit is approximately proportional to the fraction of packets that have made their way at least up to the mobile node's IP stack. The preciseness of Care-of Address Spot Checks can be traded with overhead through the frequency with which packets are tagged with Spot Check Tokens.
トークンをチェックし、それが相手ノードに次のパケットを送信するまで、それはトークンをバッファリング。スポットは、トークンは、このパケットに含まれているか確認してください。受信すると、コレスポンデントノードは、返されたスポットは、トークンは最近、モバイルノードに送信されたトークンと一致して確認するかどうかを検証します。新しいクレジットが正常に返さスポットチェックトークンの数と送信されたトークンの合計数との比率に比例して配分されます。これは、新しいクレジットは、少なくとも移動ノードのIPスタックまでの自分の道を作ってきたパケットの割合にほぼ比例することを意味しています。気付アドレスの抜き打ち検査の精度は、パケットがスポットチェックトークンでタグ付けされる頻度によってオーバーヘッドと取引することができます。
An interesting question is whether Outbound Mode could be misused by an attacker with asymmetric Internet connection. Widespread digital subscriber lines (DSL), for example, typically have a much higher download rate than upload rate. The limited upload rate would render most denial-of-service attempts through direct flooding meaningless. But the attacker could leverage the strong download rate to build up credit at one or multiple correspondent nodes. It could then illegitimately spend the credit on a stronger, redirection-based flooding attack. The reason why this has so far not been considered an issue is that, in order to accumulate enough credit at the remote end, the attacker would first have to expose itself to the same packet flood that it could then redirect towards the victim.
興味深い質問は、アウトバウンドモードが非対称インターネット接続を持つ攻撃者によって悪用されることができるかどうかです。広範なデジタル加入者線（DSL）は、例えば、通常のアップロード・レートよりもはるかに高いダウンロード速度を持っています。限られたアップロードのレートは直接洪水の無意味を通じて最もサービス拒否試みをレンダリングします。しかし、攻撃者は、一つまたは複数の通信相手ノードでの信用を構築するための強力なダウンロード速度を活用することができます。その後、不正強く、リダイレクションベースのフラッディング攻撃でクレジットを過ごすことができました。これは、これまでの問題は考慮されてこなかった理由は、リモートエンドで十分な信用を蓄積するためには、攻撃者はまず、それがその後、被害者の方にリダイレクトすることができると同じパケット洪水に自分自身を公開しなければならない、ということです。
Heuristic approaches to prevent misuse of unverified care-of addresses (see Section 3.5) are conceivable as well. A heuristic, implemented at the correspondent node and possibly supplemented by a restrictive lifetime limit for tentative bindings, can prevent, or at least effectually discourage such misuse. The challenge here seems to be a feasible heuristic: On one hand, the heuristic must be sufficiently rigid to quickly respond to malicious intents at the other side. On the other hand, it should not have a negative impact on a fair-minded mobile node's communications.
ヒューリスティックは、（3.5節を参照）と同様に考えられる未検証の気付けアドレスの誤用を防ぐために近づきます。ヒューリスティック、コレスポンデント・ノードに実装され、おそらく仮バインディングの制限寿命限界によって補わは、防止、又は少なくとも実効的に、このような悪用を阻止することができます。一方では、ヒューリスティックはすぐに他の側の悪質な意図に対応するために十分な剛性を有している必要があります。ここでの課題は、実現可能なヒューリスティックのようです。一方、それは公正志向のモバイルノードの通信に悪影響を与えるべきではありません。
Another problem with heuristics is that they are usually reactive. The correspondent node can only respond to misbehavior after it appeared. If sanctions are imposed quickly, attacks may simply not be worthwhile. Yet premature measures should be avoided. One must also bear in mind that an attacker may be able to use different home addresses, and it is in general impossible for the correspondent node to see that the set of home addresses belongs to the same node. The attacker may furthermore exploit multiple correspondent nodes for its attack in an attempt to amplify the result.
ヒューリスティックのもう一つの問題は、彼らは通常、反応性であるということです。それが現れた後に、通信相手ノードは不正行為に対応することができます。制裁を迅速に課されている場合、攻撃は単に価値がないかもしれません。しかし、早期の対策は避けるべきです。一つは、また、攻撃者が異なるホームアドレスを使用することができるかもしれ心に留めなければならない、とコレスポンデントノードがホームアドレスのセットは、同じノードに属していることを確認することは、一般的には不可能です。攻撃者は、更に結果を増幅する試みにおいて、その攻撃のための複数の対応ノードを利用することができます。
A Crypto-Based Identifier (CBID) is an identifier with a strong cryptographic binding to the public component of its owner's public/private-key pair [33]. This allows the owner to prove its claim on the CBID: It signs a piece of data with its private key and sends this to the verifier along with its public key and the parameters necessary to recompute the CBID. The verifier recomputes the CBID and checks the owner's knowledge of the corresponding private key.
暗号ベースの識別子（CBID）は、強力な暗号化は、その所有者の公開/秘密鍵ペア[33]のパブリックコンポーネントへの結合を識別子です。これは、所有者がCBIDにその主張を証明することができます：それは、その秘密鍵でデータの一部に署名し、その公開鍵とCBIDを再計算するために必要なパラメータとともに、検証者にこれを送ります。検証はCBIDを再計算し、対応する秘密鍵の所有者の知識をチェックします。
CBIDs offer three main advantages: First, spoofing attacks against a CBID are much harder than attacks against a non-cryptographic identifier like a domain name or a Mobile IPv6 home address. Though an attacker can always create its own CBID, it is unlikely to find a public/private-key pair that produces someone else's. Second, a CBID does not depend on a PKI given its inherent binding to the owner's public key. Third, a CBID can be used to bind a public key to an IP address, in which case it is called a Cryptographically Generated Address (CGA) [44][34][47]. A CGA is syntactically just an ordinary IPv6 address. It has a standard routing prefix and an interface identifier generated from a hash on the CGA owner's public key and additional parameters.
CBIDsは、3つの主要な利点があります。まず、CBIDに対するスプーフィング攻撃は、ドメイン名またはモバイルIPv6ホームアドレスなどの非暗号化識別子に対する攻撃よりもはるかに困難です。攻撃者は、常に独自のCBIDを作成することができますが、他の誰かの生成、公開/秘密鍵のペアを見つけることはほとんどありません。第二に、CBIDは、所有者の公開鍵にその固有の結合特定のPKIには依存しません。第三に、CBIDは、それが暗号化生成アドレス（CGA）[44] [34] [47]と呼ばれる場合にはIPアドレス、公開鍵を結合するために使用することができます。 CGAは、構文的に普通のIPv6アドレスです。これは、標準のルーティングプレフィックスとCGAの所有者の公開鍵と追加のパラメータのハッシュから生成されたインタフェース識別子を持っています。
Many applications are conceivable where CGAs are advantageous. In Mobile IPv6, CGAs can bind a mobile node's home address to its public key [35][5] and so avoid the home-address test in most correspondent registrations. This accelerates the registration process and allows the peers to communicate independently of home-agent availability.
CGAsが有利であるところ、多くの用途が考えられます。モバイルIPv6では、CGAsは、その公開鍵[35] [5]など、ほとんどの通信員登録でホームアドレステストを避けるために、モバイルノードのホームアドレスをバインドすることができます。これは、登録プロセスを加速し、ピアが独立してホーム・エージェントの可用性を通信することができます。
Since only the interface identifier of a CGA is cryptographically protected, its network prefix can be spoofed, and flooding attacks against networks are still an issue. An initial home-address test is hence required to validate the network prefix even when the home address is a CGA. For the same reason, CGAs are rarely used as care-of addresses.
CGAの唯一のインターフェース識別子が暗号で保護されているので、そのネットワークプレフィックスを詐称することができ、ネットワークに対するフラッド攻撃はまだ問題があります。初期ホーム・アドレス試験は、したがってホームアドレスがCGAである場合でも、ネットワークプレフィックスを検証するために必要とされます。同じ理由で、CGAsはほとんど気付アドレスとして使用されていません。
One limitation of CGAs compared to other types of CBIDs is that the cryptographically protected portion is only at most 62 bits long. The rest of the address is occupied by a 64-bit network prefix as well as the universal/local and individual/group bits. (The specification in [44] further hard-codes a 3-bit security parameter into the address, reducing the cryptographically protected portion to 59 bits.) A brute-force attack might thus reveal a public/private key public/private-key pair that produces a certain CGA. This vulnerability can be contained by including the network prefix in the hash computation for the interface identifier so that an attacker, in case it did find the right public/private key public/private-key pair, could not form CGAs for multiple networks from it.
CBIDsの他のタイプと比較CGAsの1つの制限は、暗号で保護された部分は、62ビット長のみ以下であることです。アドレスの残りの部分は、64ビットのネットワークプレフィックスだけでなく、ユニバーサル/ローカルおよび個人/グループビットで占められています。 （59ビット暗号で保護された部分を減少アドレスへの[44]さらに、ハードコードで指定する3ビットのセキュリティパラメータは、。）ブルートフォース攻撃は、このように公開/秘密鍵秘密鍵/公開ペアを明らかにするかもしれませんそれは、特定のCGAを生成します。攻撃者は、それが正しい公開鍵/秘密鍵の公開/秘密鍵のペアを見つけた場合には、それから、複数のネットワークのためのCGAsを形成することができませんでしたように、この脆弱性は、インタフェース識別子のハッシュ計算におけるネットワークプレフィックスを含むによって収容することができます。
To resolve collisions in generating CGAs, a collision count is part of the input to the hash function. Changing this produces a different CGA. Unfortunately, the collision count also reduces the complexity of a brute-force attack against a CGA because it allows the same private/public-key pair to be used to generate multiple CGAs. The collision count is therefore limited to a few values only.
CGAsの生成に衝突を解決するには、衝突回数は、ハッシュ関数への入力の一部です。これは別のCGAを生成変更します。それは同じプライベート/公開鍵ペアが複数CGAsを生成するために使用することができますので、残念ながら、衝突回数もCGAに対するブルートフォース攻撃の複雑さを軽減します。衝突回数は、したがって、わずか数の値に限定されています。
Higher security can be achieved through longer CBIDs. For example, a node's primary identifier in the Host Identity Protocol [21] is a 128-bit hash on the node's public key. It is used as an IP-address replacement at stack layers above IP. This CBID is not routable, so there needs to be some external localization mechanism if a node wants to contact a peer of which it only knows the identifier.
高いセキュリティが長くCBIDsによって達成することができます。例えば、ホストアイデンティティプロトコル[21]におけるノードのプライマリ識別子はノードの公開キーで128ビットのハッシュです。これは、IP上のスタック層でのIPアドレスの代替として使用されます。このCBIDはルーティング可能ではないので、ノードは、それが唯一の識別子を知っているのピアに連絡したい場合は、いくつかの外部ローカライゼーション・メカニズムが必要です。
Where mobile and correspondent nodes can be pre-configured with a shared key, bound to the mobile node's home address, authentication through a home-address test can be replaced by a cryptographic mechanism. This has three advantages. First, cryptography allows for stronger authentication than address tests. Second, strong authentication facilitates binding lifetimes longer than the 7- minute limit that RFC 3775 defines for correspondent registrations. Third, handoff delays are usually shorter with cryptographic approaches because the round-trips of the home-address test can be spared. The disadvantage of pre-configuration is its limited applicability.
モバイルと通信員ノードは、モバイルノードのホームアドレスにバインドされた共有鍵、と事前に設定することができる場合は、ホームアドレステストによる認証は、暗号化メカニズムで置き換えることができます。これは、3つの利点があります。まず、暗号はアドレステストよりも強力な認証が可能になります。第二に、強力な認証は、RFC 3775が通信員登録のために定義されて7分の制限より長い結合寿命を容易にします。ホームアドレステストのラウンドトリップを免れることができるので、第三に、ハンドオフ遅延は通常、暗号化のアプローチと短くなっています。事前設定の欠点は、その限られた適用可能です。
Two proposals for pre-configuration are currently under discussion within the IETF. [25] endows mobile nodes with the information they need to compute home and care-of keygen tokens themselves rather than having to obtain them through the return-routability procedure. [15] uses the Internet Key Exchange protocol to establish an IPsec security association between the peers.
事前設定のための二つの提案は、IETF内の議論中です。 [25]彼らは家に計算し、気付keygenのは、リターン・ルータビリティ手順を介してそれらを取得するのではなく自分自身をトークンに必要な情報を持つモバイルノードを付与します。 [15]ピア間でIPsecセキュリティアソシエーションを確立するために、インターネット鍵交換プロトコルを使用しています。
From a technical standpoint, pre-configuration can only replace a home-address test. A test of the care-of address is still necessary to verify the mobile node's presence at that address. The problem is circumvented in [25] by postulating that the correspondent node has sufficient trust in the mobile node to believe that the care-of address is correct. This assumption discourages the use of pre-configuration in scenarios where such trust is unavailable, however. For example, a mobile-phone operator may be able to configure subscribers with secret keys for authorization to a particular service, but it may not be able to vouch that all subscribers use this service in a responsible manner. And even if users are trustworthy, their mobile nodes may become infected with malware and start behaving unreliably.
技術的な観点から、事前設定はホームアドレステストを置き換えることができます。気付アドレスのテストでは、そのアドレスに移動ノードの存在を確認することが必要です。問題は、コレスポンデントノードは、気付けアドレスが正しいことを信じるために、モバイルノードで十分な信頼を持っていることを仮定することにより、[25]に回避されます。この仮定は、しかし、そのような信頼関係が利用できないシナリオで事前設定の使用を阻止します。例えば、携帯電話事業者は、特定のサービスへの認証用の秘密鍵を加入者に設定することができるかもしれないが、すべての加入者は、責任ある方法で本サービスを利用することを保証することはできないかもしれません。ユーザーが信頼できる場合でも、そして、彼らのモバイルノードは、マルウェアに感染し、信頼できない行動を開始することができます。
Another way to avoid care-of-address verification is to rely on access networks to filter out packets with incorrect IP source addresses [38][43]. This approach is taken in [15]. The problem with local filtering is that it can only protect a network from becoming the source of an attack, not from falling victim to an attack. The technique is hence potentially unreliable unless deployed in access networks worldwide (see Section 1.2).
気付アドレス検証を回避するための別の方法間違ったIP送信元アドレスを持つパケットをフィルタリングするアクセスネットワークに依存することである[38] [43]。このアプローチは、[15]に取り込まれます。地元のフィルタリングの問題はそれだけではない、攻撃の犠牲に落ちるから、攻撃の源になってからネットワークを保護することができるということです。世界的なアクセスネットワークに配置しない限り、技術は（セクション1.2を参照）、したがって、潜在的に信頼できないです。
Care-of-address tests facilitate the use of pre-configuration in spite of lacking trust relationships or the existence of access networks without local filtering techniques. For increased performance, concurrent care-of-address tests can be used in combination with Credit-Based Authorization or heuristic monitoring.
気付アドレステストは、ローカルのフィルタリング技術なしで信頼関係やアクセスネットワークの存在を欠いているにもかかわらず、事前設定の使用を容易に。パフォーマンスの向上のために、同時気付アドレステストは、クレジットベースの許可またはヒューリスティックの監視と組み合わせて使用することができます。
A compromise between the return-routability procedure and pre-configuration are semi-permanent security associations. A semi-permanent security association is established between a mobile node and a correspondent node upon first contact, and it is used to authenticate the mobile node during subsequent correspondent registrations. Semi-permanent security associations eliminate the need for periodic home-address tests and permit correspondent registrations with lifetimes longer than the 7-minute limit specified in RFC 3775.
リターン・ルータビリティ手順及び事前設定の間の妥協が半永久的セキュリティアソシエーションです。半永久的なセキュリティ・アソシエーションは、最初の接触時に、モバイルノードとコレスポンデントノードとの間に確立され、その後の通信員登録中の移動ノードを認証するために使用されます。半永久的なセキュリティアソシエーションは、定期的なホームアドレステストの必要性を排除し、RFC 3775で指定された7分間の制限より長い寿命を持つ通信員登録を許可します。
It is important to verify a mobile node's home address before a security association is bound to it. An impersonator could otherwise create a security association for a victim's IP address and then redirect the victim's traffic at will until the security association expires. An initial home-address test mitigates this vulnerability because it requires the attacker to be on the path between the victim and the victim's peer at least while the security association is being established. Stronger security can be obtained through cryptographically generated home addresses (see Section 3.9).
セキュリティアソシエーションがそれにバインドされる前に、モバイルノードのホームアドレスを確認することが重要です。偽装は、そうでない場合は、被害者のIPアドレスのセキュリティアソシエーションを作成し、セキュリティアソシエーションの有効期限が切れるまでの意志で、被害者のトラフィックをリダイレクトすることができます。それはセキュリティアソシエーションが確立されている間に、少なくとも被害者と被害者のピア間のパス上にあるように、攻撃者が必要なので、最初のホームアドレステストは、この脆弱性を緩和します。強力なセキュリティは、暗号生成されたホームアドレス（3.9節を参照）を介して取得することができます。
Semi-permanent security associations alone provide no verification of care-of addresses and must therefore be supplemented by care-of-address tests. These may be performed concurrently for reduced handoff delays. Semi-permanent security associations were first developed in [8] where they were called "purpose-built keys".
一人で半永久的なセキュリティアソシエーションは、気付アドレスのない検証を提供しないため、気付アドレステストによって補完されなければなりません。これらは減少し、ハンドオフ遅延を同時に実行することができます。半永久的なセキュリティアソシエーションは、最初に開発された[8]彼らは「専用キー」と呼ばれた場所。
Section 1.1 lists numerous problems of PKIs with respect to authentication of mobile nodes. These problems become more tractable, however, if correspondent nodes authenticate home agents rather than mobile nodes, and the home agents vouch for the authenticity and trustworthiness of the mobile nodes [37]. Such delegation of responsibilities solves the scalability issue with PKIs given that home agents can be expected to be much less numerous than mobile nodes. Certificate revocation becomes less delicate as well because home agents are commonly administrated by a mobility provider and should as such be more accountable than mobile nodes.
セクション1.1リストの移動ノードの認証に関してのPKIの多くの問題を。コレスポンデントノードがホームエージェントではなく、モバイルノードを認証した場合、これらの問題は、しかし、より扱いやすくなり、ホームエージェントは、モバイルノード[37]の信憑性と信頼性を保証します。責任のような代表団は、ホームエージェントは、はるかに少ない多数のモバイルノードよりなることが期待できることを与えられたのPKIとスケーラビリティの問題を解決します。ホームエージェントは、一般的に、モビリティプロバイダによって管理されており、このようなモバイルノードよりも説明責任が必要があるため、証明書の失効は、同様に少ない繊細になります。
Another advantage of delegation is that it avoids public-key computations at mobile nodes. On the other hand, the processing overhead at correspondent nodes increases. This may or may not be an issue depending on resources available at the correspondent node relative to the services that the correspondent node provides. The correspondent node may also be mobile itself, in which case cryptographic operations would be problematic. Furthermore, the increased overhead implies a higher risk to resource-exhaustion attacks.
代表団のもう一つの利点は、それがモバイルノードで公開鍵の計算を避けることです。一方、対応の処理オーバーヘッドが増加ノード。これは、またはコレスポンデントノードが提供するサービスに対する対応ノードで利用可能なリソースに応じて、問題があってもなくてもよいです。コレスポンデント・ノードはまた、暗号化操作が問題となり、その場合、モバイル自体であってもよいです。さらに、増加したオーバーヘッドが攻撃-枯渇資源へのリスクが高いことを意味しています。
Mobile nodes may move as a group and attach to the Internet via a "mobile router" that stays with the group. This happens, for example, in trains or aircraft where passengers communicate via a local wireless network that is globally interconnected through a satellite link.
モバイルノードは、グループとして移動し、グループにとどまり、「モバイルルータ」を経由してインターネットに接続することがあります。これは、乗客がグローバル衛星リンクを介して相互接続されたローカル無線ネットワークを介して通信する列車や航空機に、例えば起こります。
It is straightforward to support such network mobility [41] with a single home agent and a tunnel between the mobile router and this home agent. The mobile nodes themselves then do not have to be mobility-aware. However, Route Optimization for moving networks [36][26][27][55] is more complicated. One possibility is to have the mobile router handle Route Optimization on behalf of the mobile nodes. This requires the mobile router to modify incoming and outgoing packets such that they can be routed on the direct path between the end nodes. The mobile router would also have to perform Mobile IPv6 signaling on behalf of the mobile nodes. Similarly, a network of correspondent nodes can communicate with mobile nodes, through a "correspondent router", in a route-optimized way without providing mobility support themselves.
単一のホームエージェントと、モバイルルータとそのホームエージェント間のトンネルで、このようなネットワークモビリティ[41]をサポートするために簡単です。モバイルノード自体はその後、移動性を意識する必要はありません。しかしながら、移動ネットワーク[36] [26] [27] [55]のためのルート最適化は、より複雑です。一つの可能性は、モバイルルータがモバイルノードに代わってルート最適化を処理することです。これは、彼らがエンドノード間の直接パスでルーティングすることができるように、着信と発信パケットを変更するために、モバイルルータが必要です。モバイルルータはまた、モバイルIPv6がモバイルノードに代わってシグナリングを実行する必要があります。同様に、コレスポンデントノードのネットワークは、モビリティサポート自体を設けることなく経路最適化方法では、「コレスポンデントルータ」を介して、モバイルノードと通信することができます。
RFC 3775 fails to conceal a mobile node's current position as route-optimized packets always carry both home and care-of addresses. Both the correspondent node and a third party can therefore track the mobile node's whereabouts. A workaround is to fall back to bidirectional tunneling where location privacy is needed. Packets carrying the mobile node's care-of address are thus only transferred between the mobile node and the home agent, where they can be encrypted through IPsec ESP [42]. But even then should the mobile node periodically re-establish its IPsec security associations so as to become untraceable through its SPIs. Early efforts on location privacy in Route Optimization include [17][13][24][30].
RFC 3775は、経路最適化パケットは、常に両方のホームを運ぶと気付アドレスとして、移動ノードの現在位置を隠すために失敗しました。コレスポンデントノードと第三者の両方がゆえ、モバイルノードの所在を追跡することができます。この問題を回避するには、位置プライバシーが必要な双方向トンネリングにフォールバックすることです。モバイルノードの気付アドレスを搬送するパケットは、このようにのみ、彼らはIPsecのESP [42]によって暗号化することができ、移動ノードとホームエージェントとの間で転送されます。そのSPIを通じ追跡不可能になるように。しかし、その後も、移動ノードは、定期的にそのIPSecセキュリティアソシエーションを再確立する必要があります。ルート最適化における位置プライバシー上の初期の努力は、[17] [13] [24] [30]。
Common to the proposals discussed in Section 3 is that all of them affect a trade-off between effectiveness, on one hand, and economical deployability, administrative overhead, and wide applicability, on the other. Effectiveness may be equated with low latency, strong security, reduced signaling, or increased robustness. Economy implies no, or only moderate requirements in terms of hardware upgrades and software modifications. Administrative overhead relates to the amount of manual configuration and intervention that a technique needs.
第3節で述べた提案に共通するのは、それらのすべては、他に、一方では有効、かつ経済的な展開性、管理オーバーヘッド、および幅広い適用性とのトレードオフに影響を与えるということです。有効性は、低レイテンシ、強力なセキュリティ、減少シグナリング、または増加したロバスト性と同一視することができます。経済には意味しない、またはハードウェアのアップグレードやソフトウェアの修正の観点からだけで適度な要件。管理オーバーヘッドは、手動の構成および技術が必要と介入の量に関する。
The standard return-routability procedure avoids costly pre-configuration or new network entities. This minimizes both deployment investments as well as administrative expenses. Variants with optimistic behavior and proactive or concurrent IP-address tests have these advantages as well. CBIDs allow for public-key authentication without a PKI. They constitute a more secure alternative to home-address tests and are as such most effective when combined with concurrent reachability verification. CBID-based authentication may require nodes to be programmed with a mapping between human-readable identifiers and the corresponding CBIDs. Pre-configuration is another approach to avoid home-address tests. It does without computationally expensive public-key algorithms, but requires pair-wise credentials and, therefore, administrative maintenance. Where suitable infrastructure is available, end nodes may delegate authentication and encryption tasks to trusted network entities which, in turn, vouch for the end nodes. Delegation could resurrect the use of certificates for the purpose of mobility support. But it introduces a dependency on the delegatees, adds the provisioning costs for new network entities, and is likely to be limited to communities of authorized nodes.
標準のリターン・ルータビリティ手順は、高価な事前設定したり、新しいネットワークエンティティを回避できます。これは、展開の投資だけでなく、管理費の両方を最小限に抑えます。楽観的行動と積極的または同時IPアドレスのテストを有する変異体は、これらの利点を有しています。 CBIDsは、PKIなしで公開鍵認証を可能とします。彼らはホームアドレステストへのより安全な代替を構成し、同時到達可能性の検証と組み合わせたときに、このような最も効果的なようです。 CBIDベースの認証は、人間が読み取り可能な識別子と対応CBIDsとの間のマッピングを用いてプログラムされるノードを必要とするかもしれません。事前設定は、ホームアドレステストを回避するための別のアプローチです。これは、計算コスト、公開鍵アルゴリズムなしで行いますが、ペアワイズの資格情報と、そのため、管理者のメンテナンスが必要です。適したインフラが利用可能である場合、エンド・ノードは、順番に、エンドノードを保証、信頼できるネットワークエンティティに認証と暗号化のタスクを委任することができます。委任は、モビリティサポートを目的とした証明書の使用を復活させることができます。しかし、それは、delegateesへの依存性を導入し、新たなネットワークエンティティのプロビジョニング・コストを追加し、認可ノードのコミュニティに限定される可能性があります。
The performance of Route Optimization, as evaluated in this document, should be put into perspective of handoff-related activities in other parts of the network stack. These include link-layer attachment procedures; link-layer security mechanisms such as negotiation, authentication, and key agreement; as well as IPv6 router discovery, address configuration, and movement detection. A complete network attachment in a typical IEEE 802.11 commercial deployment requires over twenty link- and IP-layer messages. Current protocol stacks also have a number of limitations in addition to long attachment delays, such as denial-of-service vulnerabilities, difficulties in trusting a set of access nodes distributed to physically insecure locations, or the inability to retrieve sufficient information for making a handoff decision [2].
ルート最適化のパフォーマンスは、この文書で評価されるように、ネットワークスタックの他の部分でのハンドオフに関連する活動の視点に入れるべきです。これらは、リンクレイヤ接続手順が含まれます。こうした交渉、認証、およびキー合意などのリンク層のセキュリティメカニズム。同様にIPv6ルータディスカバリ、アドレスの設定、および動き検出など。典型的なIEEE 802.11商用展開における完全なネットワーク接続は、20以上のリンク - およびIP-層のメッセージを必要とします。現在のプロトコルスタックは、また、そのようなサービス拒否の脆弱性限り付着遅延に加えて、物理的に安全でない場所、またはハンドオフを行うために十分な情報を取得することができないことに配布アクセスノードの集合を信頼の困難を多くの制限を有しています決定[2]。
A number of proposals have been put forth to improve handoff performance on different parts of the network stack, mostly focusing on handoff performance. These include link-layer parameter tuning [49] and network-access authentication [18][2][32], as well as IPv6 router discovery [11][12], address configuration [23], and movement detection [19][20]. It is uncertain how far this optimization can be taken by only looking at the different parts individually. An integrated approach may eventually become necessary [4][53].
提案の数は、主に、ハンドオフのパフォーマンスに焦点を当て、ネットワークスタックのさまざまな部分でのハンドオフのパフォーマンスを向上させるために出すされています。これらは、[19] [23] [49]およびネットワークアクセス認証[18] [2] [32]、ならびにIPv6ルータ探索[11] [12]、アドレス設定をリンク層パラメータチューニングを含み、動き検出[20]。この最適化は唯一、個別に異なる部分を見て、撮影することができますどの程度まで不明です。統合されたアプローチは、最終的に必要になることができる[4] [53]。
The number and diversity of mobility-related activities within a typical network stack oftentimes render theoretical analyses insufficient and call for additional, extensive experimentation or simulation. The following is a non-exhaustive list of areas where practical experience is likely to yield valuable insight.
典型的なネットワークスタック内のモビリティ関連の活動の数と多様性はしばしば不十分な理論的な分析をレンダリングし、追加、大規模な実験やシミュレーションのために呼び出します。以下は、実際の経験は貴重な洞察をもたらす可能性がある領域の非網羅的なリストです。
o Conception of a set of standard scenarios that can be used as a reference for comparable measurements and experimentation. Ideally, such standard scenarios ought to be derived from real-world environments, and they should include all features that would likely be needed in a commercial deployment. These features include link-layer access control, for instance.
O同等の測定および実験のための基準として使用することができる標準的なシナリオのセットの概念。理想的には、このような標準シナリオは実際の環境から導出されるべきである、と彼らはおそらく商用展開に必要とされるすべての機能を含める必要があります。これらの機能は、例えば、リンク層のアクセス制御が含まれます。
o Measurements of the performance impacts that existing enhancement proposals have on the different parts of the stack.
既存の強化案は、スタックの異なる部分を持っているパフォーマンスへの影響のO測定。
o Comparisons of different implementations that are based on the same specification. For instance, it would be valuable to know how much implementations differ with regards to the use of parallelism that RFC 3775 allows in home and correspondent registrations.
同じ仕様に基づいて異なる実装のOの比較。例えば、RFC 3775は、家庭や通信員登録で可能に並列処理の使用に関して異なるどのくらいの実装を知っている価値があります。
o Measurements of the impact that network conditions such as packet loss can have on existing and new optimizations.
インパクトのOの測定は、このようなパケット損失などのネットワーク条件は、既存および新規の最適化を持つことができること。
o Statistical data collection on the behavior of mobile nodes in different networks. Several Route Optimization techniques behave differently depending on the degree of mobility.
異なるネットワークにおけるモバイルノードの行動上のO統計データの収集。いくつかのルート最適化技術は、移動性の程度に応じて異なる動作をします。
o Measurements of the performance that Route Optimization schemes show under different application scenarios, such as the use of applications with symmetric vs. asymmetric traffic patterns.
ルート最適化スキームは、このような対の対称、非対称トラフィックパターンを持つアプリケーションの使用など、さまざまなアプリケーション・シナリオの下で示した性能のO測定。
Future research that goes beyond the techniques discussed in this document may consider the following items.
この文書で説明する技術を超えて今後の研究では、以下の項目を考慮することができます。
o Local mobility support or local route-repair mechanisms that do not require expensive configuration. This includes infrastructure-based Route Optimization like [48].
Oローカルモビリティサポートや高価な設定を必要としないローカルルート修復メカニズム。これは、[48]のようなインフラをベースルートの最適化を含んでいます。
o Care-of-address verification mechanisms that are based on Secure Neighbor Discovery.
セキュア近隣探索に基づいており、O気付アドレス検証メカニズム。
o The introduction of optimizations developed in the context of Mobile IPv6 to other mobility protocols, such as the Host Identity Protocol, the Stream Control Transmission Protocol, the Datagram Congestion Control Protocol, or link-layer mobility solutions.
そのようなホストアイデンティティプロトコル、ストリーム制御伝送プロトコル、データグラム輻輳制御プロトコル、またはリンク層モビリティソリューションなどの他のモビリティプロトコルにモバイルIPv6の文脈で開発された最適化の導入O。
o The extension of the developed mobility techniques to full multi-addressing, including multi-homing.
マルチホーミング含むマルチアドレッシング完全に開発されたモビリティ技術の拡張O。
o Further strategies that are based on "asymmetric cost wars" [3], such as Credit-Based Authorization.
Oなどのクレジットベースの認証として「非対称コスト戦争」[3]に基づいており、さらに戦略。
o Integrated techniques taking into account both link- and IP-layer mobility tasks.
O統合技術は、アカウントにリンク - とIP層のモビリティ・タスクの両方を取ります。
Standard Route Optimization enables mobile nodes to redirect IP packets at a remote peer from one IP address to another IP address. This ability introduces new security issues, which are explained and discussed in depth in [46]. The alternative Route Optimization techniques described in this document may introduce new security threats that go beyond those identified in [46]. Where such new threats exist, they are discussed and analyzed along with the description of the respective technique in Section 3.
標準ルート最適化は、別のIPアドレスを1つのIPアドレスからリモートピアにIPパケットをリダイレクトするためにモバイルノードを可能にします。この機能は、[46]で詳しく説明して議論されている新しいセキュリティ上の問題を、紹介します。このドキュメントで説明する代替ルート最適化技術は、[46]で同定されたものを超えた、新たなセキュリティの脅威を導入することができます。こうした新たな脅威が存在する場合、彼らが議論され、第3節では、それぞれの技術の説明とともに分析しました。
Mobile IPv6 Route Optimization reduces packet-propagation latencies so as to facilitate interactive and real-time applications in mobile environments. Unfortunately, the end-to-end protocol's high handoff latencies hinder exactly these applications. A large body of effort has therefore recently been dedicated to Route Optimization improvements. Some of the proposed techniques operate on an end-to-end basis, others require new or extended infrastructure in the network; some need pre-configuration, others are zero-configurable. This document has compared and evaluated the different strategies based on a selected set of enhancement proposals. It stands out that all proposals make a trade-off between effectiveness, on one hand -- be it in terms of reduced handoff latency, increased security, or lower signaling overhead -- and pre-configuration costs or requisite network upgrades, on the other. An optimization's investment requirements, in turn, are in relation to its suitability for widespread deployment.
モバイル環境でのインタラクティブなリアルタイムアプリケーションを容易にするために、モバイルIPv6ルート最適化は、パケットの伝搬遅延を低減します。残念ながら、エンド・ツー・エンドのプロトコルの高いハンドオフの待ち時間は、まさにこれらのアプリケーションを妨げます。努力の大きな体は、したがって、最近の経路最適化の改善に専念してきました。提案された技術のいくつかは他の人がネットワークに新規または拡張されたインフラストラクチャを必要とし、エンド・ツー・エンドに基づいて動作します。いくつかは他の人がゼロに構成され、事前設定が必要です。この文書では、機能拡張の提案の選択セットに基づいて異なる戦略を比較評価しました。他に、プリコンフィグレーションコストや必要なネットワークのアップグレード - 、シグナリングオーバーヘッドを、セキュリティを高め、以下それが減少ハンドオフ遅延の面であること - それは、一方では、すべての提案が有効とのトレードオフを行うことが目立ちます。最適化の投資要件は、今度は、広範囲の展開のためのその適合性に関連しています。
However, the real-life performance of end-to-end mobility does not only depend on enhancements of Route Optimization, but ultimately on all parts of the protocol stack [2]. Related optimization endeavors are in fact gaining momentum, and a comprehensive approach towards Route Optimization must incorporate the most suitable solutions amongst them [4]. Whichever proposals will eventually reach a maturity level sufficient for standardization, any effort should be expended to arrive at that point within the foreseeable future. Route Optimization requires support from both peers and depends on a solid basis of installed implementations in correspondent nodes. This should hence be included in emerging IPv6 stacks early on. Although IPv6 deployment is yet far away from becoming widespread, the sooner efficient Route Optimization will be available, the more likely that it will in the end be ubiquitously supported.
しかし、エンド・ツー・エンドのモビリティの実際のパフォーマンスは、ルート最適化の機能強化に依存しないだけでなく、最終的には、プロトコル・スタックのすべての部分に[2]。関連の最適化の努力は勢いを増し、実際にあり、ルート最適化に向けた包括的なアプローチは、それら[4]の中で最も適したソリューションを組み込む必要があります。どちらの提案が最終的にどんな努力が近い将来以内にそのポイントに到着するために消費する必要があり、標準化のための十分な成熟度レベルに到達します。ルート最適化は、両方のピアからの支援を必要とし、通信相手ノードでのインストール実装の固形分に依存します。これは、したがって、早期に新興国のIPv6スタックに含まれるべきです。 IPv6の展開が遠く普及してからはまだですが、早く効率的なルート最適化は、それが最終的に普遍的にサポートされる可能性が高く利用できるようになります。
This document was thoroughly reviewed, in alphabetical order, by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and Fan Zhao. The authors wish to thank these folks for their valuable comments and suggestions.
この文書は、徹底的にSamita Chakrabarti、フランシスデュポン、ティエリーエルンスト、ヘラルド・Giaretta、ジェームズ・ケンプ、ラジーブKoodli、ガブリエルモンテネグロ、Vidyaナラヤナン、およびファン趙によって、アルファベット順に、検討しました。作者は彼らの貴重なコメントや提案のためにこれらの人々に感謝したいです。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", IEEE Contribution 802.11-04/0377r1, March 2004.
[2] Alimian、A.およびB. Aboba、IEEE貢献802.11から04 / 0377r1、2004年3月 "ローミング技術の分析"。
[3] Arkko, J. and P. Nikander, "Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties", Proceedings of Security Protocols Workshop 2002, Cambridge, UK, April 2002.
[3] Arkko、J.とP. Nikander、「弱い認証：信頼当事者ずに不明なプリンシパルを認証する方法」、セキュリティプロトコルワークショップ2002年、英国ケンブリッジ、2002年4月の議事。
[4] Arkko, J., Eronen, P., Nikander, P., and V. Torvinen, "Secure and Efficient Network Access", Proceedings of the DIMACS Workshop on Mobile and Wireless Security, November 2004.
[4] Arkko、J.、Eronen、P.、Nikander、P.、およびV. Torvinen、 "安全で効率的なネットワークアクセス"、モバイルでのDIMACSワークショップやワイヤレスセキュリティ、2004年11月の議事録を。
[5] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", Work in Progress, August 2006.
[5] Arkko、J.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のためのルート最適化の強化"、進歩、2006年8月に作業を。
[6] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", Work in Progress, May 2004.
[6] Arkko、J.とC.フォークト、「長寿命化を結合するためのクレジットベース認証」、進歩、2004年5月での作業。
[7] Bahl, P., Adya, A., Padhye, J., and A. Walman, "Reconsidering Wireless Systems With Multiple Radios", ACM SIGCOMM Computer Communication Review, ACM Press, Vol. 34, No. 5, October 2004.
[7] BAHL、P.、Adya、A.、Padhye、J.、およびA. Walman、 "複数の無線機で再考ワイヤレスシステム"、ACM SIGCOMMコンピュータコミュニケーションレビュー、ACMプレス、巻。 34、第5号、2004年10月。
[8] Bradner, S., Mankin, A., and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003.
[8]ブラドナー、S.、マンキン、A.、およびJ.シラー、 "専用キー（PBK）のためのフレームワーク" が進歩、2003年6月に働いています。
[9] Castellucia, C., Montenegro, G., Laganier, J., and C. Neumann, "Hindering Eavesdropping via IPv6 Opportunistic Encryption", Proceedings of the European Symposium on Research in Computer Security, Lecture Notes in Computer Science, Springer-Verlag, September 2004.
[9] Castellucia、C.、モンテネグロ、G.、Laganier、J.、およびC.ノイマン、コンピュータセキュリティの研究に関する欧州シンポジウム、コンピュータサイエンス、スプリンガーで講義ノート「IPv6の日和見暗号化を経由して盗聴を妨害します」 -Verlag、2004年9月。
[10] Chandra, R., Bahl, P., and P. Bahl, "MultiNet: Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card", Proceedings of the IEEE INFOCOM, Vol. 2, August 2004.
[10]チャンドラ、R.、BAHL、P.、およびP. BAHL、 "のMultiNet：単一の無線カードの使用した複数のIEEE 802.11ネットワークへの接続"、IEEE INFOCOM、巻の議事録を。 2、2004年8月。
[11] Daley, G., Pentland, B., and R. Nelson, "Effects of Fast Routers Advertisement on Mobile IPv6 Handovers", Proceedings of the IEEE International Symposium on Computers and Communication, Vol. 1, June 2003.
[11]デイリー、G.、ペントランド、B.、およびR.ネルソン、コンピュータとコミュニケーション、巻上のIEEE国際シンポジウム「モバイルIPv6のハンドオーバの高速ルータアドバタイズメントの影響」。 1、2003年6月。
[12] Daley, G., Pentland, B., and R. Nelson, "Movement Detection Optimizations in Mobile IPv6", Proceedings of the IEEE International Conference on Networks, September 2003.
[12]デイリー、G.、ペントランド、B.、およびR.ネルソン、「モバイルIPv6における動き検出の最適化」、ネットワーク上のIEEE国際会議の議事録、2003年9月。
[13] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[13]デイリー、G.、 "場所のプライバシーとモバイルIPv6"、進歩、2004年1月での作業。
[14] Dupont, F., "A Note about 3rd Party Bombing in Mobile IPv6", Work in Progress, July 2006.
[14]デュポン、F.、進歩、2006年7月で、作業「サードパーティのモバイルIPv6での爆撃についてのご注意」。
[15] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", Work in Progress, August 2004.
[15]デュポン、F.及びJ. Combesの "モバイルとコレスIPv6ノードとの間のIPsecの使用"、進歩、2004年8月ワーク。
[16] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using a State Cookie", Work in Progress, July 2006.
[16]デュポン、F.およびJ. Combesの、「国家クッキーを使用してMIPv6のための気付アドレスのテスト」、進歩、2006年7月での作業。
[17] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B. Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", Work in Progress, June 2006.
[17]ハダッド、W.、Nordmarkと、E.、デュポン、F.、Bagnulo、M.、およびB.パティル、 "Mobileのプライバシーとマルチホームノード：MoMiPriv問題文"、進歩、2006年6月に作業。
[18] "IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
[18]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：ポートベースのネットワークアクセス制御」、IEEE標準802.1X、2004年12月。
[19] Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix List Based Approach", Work in Progress, January 2006.
[19]チェ、J.およびE. Nordmarkと、 "修飾されていないルータとのDNA：プレフィックスリストベースのアプローチ"、進歩、2006年1月の作業。
[20] Narayanan, S., Ed., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
[20]ナラヤナン、S.、エド。、 "IPv6のネットワークにおけるネットワーク接続検出（DNAv6）"、進歩、2006年10月に作業。
[21] Moskowitz, R., Nikander, P., Jokela, Ed., P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2006.
[21]モスコウィッツ、R.、Nikander、P.、Jokela、エド。、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、進歩、2006年6月での作業。
[22] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
進歩、2006年6月、仕事[22]ヘンダーソン、T.、エド。、「ホストアイデンティティプロトコルとエンドホストモビリティとマルチホーミング」。
[23] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[23]ムーア、N.、 "IPv6の楽観重複アドレス検出（DAD）"、RFC 4429、2006年4月。
[24] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", Work in Progress, October 2006.
[24] Koodli、R.、 "IPアドレス所在地プライバシーとモバイルIPv6：問題文"、進歩、2006年10月に作業。
[25] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[25]パーキンス、C.、RFC 4449、2006年6月 "静的共有キーを使用してセキュアなモバイルIPv6ルート最適化"。
[26] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", Work in Progress, September 2006.
[26]ン、C.、Thubert、P.、亘理、M.、およびF.趙、 "ネットワークモビリティ経路最適化問題に関する声明"、進歩、2006年9月に作業。
[27] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", Work in Progress, September 2006.
[27]ン、C.、趙、F.、亘理、M.、およびP. Thubert、 "ネットワークモビリティルート最適化ソリューションスペース解析"、進歩、2006年9月に作業。
[28] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[28] Arbaugh、W.およびB. Aboba、 "RADIUSへのハンドオフ拡張"、進歩、2003年10月に作業。
[29] "Kame-Shisa", Mobile IPv6 for FreeBSD.
[29] "亀-シーサー"、FreeBSD用モバイルIPv6。
[30] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins, "Solutions for IP Address Location Privacy in the Presence of IP Mobility", Work in Progress, February 2005.
[30] "IPモビリティの存在下でのIPアドレスの場所のプライバシーのためのソリューション" Koodli、R.、Devarapalli、V.、フリンク、H.、およびC.パーキンス、進歩、2005年2月に作業。
[31] Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for Linux (MIPL)".
[31] Nuorvala、V.、Petander、H.、およびA.トゥオミネン、 "Linux用のモバイルIPv6（MIPL）"。
[32] Mishra, A., Shin, M., Petroni Jr., N., Clancy, C., and W. Arbaugh, "Proactive Key Distribution Using Neighbor Graphs", IEEE Wireless Communications, Vol. 11, No. 1, February 2004.
[32]ミシュラ、A.、シン、M.、ペトローニジュニア、N.、クランシー、C.、およびW. Arbaugh、 "隣接グラフを使用して積極的な鍵配布"、IEEE無線通信、巻。 11、第1号、2004年2月。
[33] Montenegro, G. and Claude. Castelluccia, "Crypto-Based Identifiers (CBIDs): Concepts and Applications", ACM Transactions on Information and System Security Vol.7, No. 1, February 2004.
[33]モンテネグロ、G.およびクロード。カステルッシア、「暗号ベースの識別子（CBIDs）：概念と応用」、情報システムセキュリティ第7弾、第1号、2004年2月にACM取引。
[34] 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.
[34] Nikander、P.、「サービス拒否、アドレスの所有権、およびIPv6の世界での早期の認証」、セキュリティプロトコル、シュプリンガー・フェアラーク、2002年4月に国際ワークショップからの改訂論文。
[35] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", ACM SIGCOMM Computer Communication Review, April 2001.
[35]オシェイ、G.およびM.卵、 "MIPv6のためのチャイルドプルーフ認証"、ACM SIGCOMMコンピュータコミュニケーションレビュー、2001年4月。
[36] Perera, E., Sivaraman, V., and A. Seneviratne, "Survey on Network Mobility Support", ACM SIGCOMM Computer Communication Review, Vol. 8, No. 2, ACM Press, April 2004.
[36]ペレラ、E.、Sivaraman、V.、およびA. Seneviratne、 "ネットワークモビリティサポートに関する調査"、ACM SIGCOMMコンピュータコミュニケーションレビュー、巻。 8、第2号、ACMプレス、2004年4月。
[37] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-basedBinding Update Protocol (CBU)", Work in Progress, March 2005.
[37]バオ、F.、トウ、R.、秋、Y.、およびJ.周、 "証明書basedBinding更新プロトコル（CBU）"、進歩、2005年3月に働いています。
[38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[38]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[39] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[39] Abley、J.、ブラック、B.、およびV.ギル、 "IPv6のサイトマルチホーミングアーキテクチャの目標"、RFC 3582、2003年8月。
[40] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[40] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月。
[41] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[41] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[42] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[42]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[43] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[43]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[44] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[44]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、2005年3月。
[45] Huston, G., "Architectural Approaches to Multi-homing for IPv6", RFC 4177, September 2005.
[45]ヒューストン、G.、 "IPv6のマルチホーミングの建築アプローチ"、RFC 4177、2005年9月。
[46] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[46] Nikander、P.、Arkko、J.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、RFC 4225、2005年12月。
[47] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, February 2002.
[47]卵、M.、オーラ、T.、オシェイ、G.、およびJ. Arkko、 "更新と謝辞結合モバイルIPv6の認証"、進歩、2002年2月に働いています。
[48] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route Optimization for Mobile IP", Proceedings of the IEEE Vehicular Technology Conference, October 2001.
[48] Vadali、R.、李、J.、呉、Y.、およびG.曹操、 "モバイルIPのためのエージェントベースのルート最適化"、IEEE車両用技術会議、2001年10月の議事。
[49] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handoff Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
[49]ベラヨス、H.およびG.カールソン、 "IEEE 802.11bのMAC層ハンドオフ時間を短縮する技術"、通信ネットワーク、KTH、王立工科大学、ストックホルム、スウェーデン、TRITA-IMIT-LCN R 3時02分のための研究室では、 、2003年4月。
[50] Vogt, C., "Credit-Based Authorization for Concurrent IP-Address Tests", Proceedings of the IST Mobile and Wireless Communications Summit, June 2005.
[50]フォークト、C.、「同時IPアドレスのテストのためのクレジットベース認証」、ISTモバイルおよびワイヤレス通信サミット、2005年6月の議事。
[51] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding Updates for Mobile IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, IEEE, Vol. 3, March 2005.
[51]フォークト、C.、ブレス、R.、人形、M.、およびT. Kuefner、 "モバイルIPv6のためのアーリーバインディング更新"、IEEE無線通信とネットワーキング会議、IEEE、VOLの議事。 3、2005年3月。
[52] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", Proceedings of the IEEE Wireless Communications and Networking Conference, April 2006.
[52]フォークト、C.とM.人形、「IPv6での効率的なエンドツーエンドのモビリティサポート」、IEEE無線通信とネットワーク会議、2006年4月の議事。
[53] Vogt, C., "A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization", Institute of Telematics, Universitaet Karlsruhe (TH), Karlsruhe, Germany, TM-2006-1, January 2006.
[53]フォークト、C.、 "モバイルIPv6ルート最適化と反応し、積極的なハンドオフのための総合的遅延解析"、テレマティクスの研究所、Universitaetカールスルーエ（TH）、カールスルーエ、ドイツ、TM-2006-1、2006年1月。
[54] Zhao, F., Wu, F., and S. Jung, "Extensions to Return Routability Test in MIP6", Work in Progress, February 2005.
[54]趙、F.、呉、F.、およびS.ユング、 "MIP6でルータビリティテストを返すために、拡張機能"、進歩、2005年2月に作業。
[55] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de la Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO", IEEE Journal on Selected Areas in Communications, Vol. 24, No. 9, September 2006.
[55]カルデロン、M.、Bernardos、C.、Bagnulo、M.、ソト、I.、およびA.・デ・ラ・オリバ、 "デザインとNEMOのためのルート最適化ソリューションの実験的評価"、IEEEジャーナル選択された領域上でコミュニケーション、巻。 24、第9号、2006年9月。
Authors' Addresses
著者のアドレス
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
カールスルーエのテレマティクス大学のクリスチャン・フォークト研究所（TH）、P。ボックス6980 76128カールスルーエドイツ
EMail: chvogt@tm.uka.de
メールアドレス：chvogt@tm.uka.de
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
ヤリArkkoエリクソン研究NomadicLab FI-02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。