[要約] RFC 4651は、モバイルIPv6ルート最適化の改善に関する分類と分析を提供する。その目的は、モバイルネットワークにおけるルーティングの効率性とパフォーマンスの向上を促進することである。
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
モバイルIPv6ルートの最適化の強化の分類と分析
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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は、インターネット研究タスクフォースの製品であり、インターネット標準のレベルの候補者ではありません。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のモビリティサポートにより、モバイルノードはアクティブな輸送接続とアプリケーションセッションをある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は、モバイルノードのルーティングプロパティを確認することにより、この問題を解決します。具体的には、モバイルノードは、それぞれ自宅の住所と現在の住所で到達できるようにチェックされます。これは、それぞれ家庭とkeygenトークンの受信を証明する必要があります。これは、「返品済み性能手順」と呼ばれます。モバイルノードが特派員ノードを使用して新しいケアオブアドレスを登録する直前に行われ、モバイルノードがしばらく移動しない場合に定期的に繰り返されます。
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つの到達可能性テストは、Voice over 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 Research Groupのコンセンサスを表しています。これは、特定の作業分野で活動している研究グループメンバーによってレビューされています。彼らの椅子の要求に応じて、この文書は、IETF MIP6ワーキンググループへの複数のアクティブな貢献者によって包括的にレビューされています。この執筆時点で、このドキュメントで提示されているアイデアのいくつかは、IETFのパフォーマンス、シグナル、ハンドオフ最適化（MIPSHOP）ワーキンググループのモビリティによって採用されています。
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）に基づく認証は、ペアワイズの事前構成を必要としません。ここで、秘密情報はパブリック/プライベートキーペアのプライベートコンポーネントであり、ノードのアイデンティティとプライベートキーの間のバインディングは、パブリック/プライベートキーペアの暗号化特性とアイデンティティと公開のバインディングを通じて間接的に存在します鍵。両方のENDノードによって信頼される当局は、この後者のバインディングに影響を与える証明書を発行します。
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 A 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ソースアドレスが正しいことを確認できます。「Ingress Filtering」[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が良心以外のイングレスフィルタリングを展開するインセンティブはほとんどありません。法的または規制の処方箋、および経済的動機付けは存在しません。腐敗したISPは、リダイレクトベースのサービス拒否（DOS）攻撃がルート最適化を使用してこれまでに可能になり、経済的利益のために活用されている場合、テクニックを展開しないという財政的インセンティブさえ持っている可能性があります。たとえば、電子メールスパムで同様の問題が観察されました。
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 イングレスフィルタリングのもう1つの問題は、マルチホミングです。ルーターが1つのISPに別のISPからのソースアドレスプレフィックスを備えたパケットを転送しようとすると、2番目の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ヘッダーの外側のバインディングアップデートメッセージ内でモバイルノードが使用できる代替のケアオプションオプションを定義します。このような住所は、イングレスフィルタリングによる検査の対象ではなく、他の手段を通じて検証する必要があります[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回の往復時間を取っています。モバイルノードとホームエージェントに加えて、ホームエージェントとホームアドレステストのための特派員ノード間の往復時間、およびバインディングアップデートメッセージの伝播のためのモバイルノードから特派員ノードまでの一方向。新しいアドレスに送信された最初のパケットには、特派員ノードからモバイルノードへの伝播に追加の一方向の時間が必要です。モバイルノードは、バインディングアップデートメッセージを発送した直後に通信を再開できます。ただし、特派員ノードから拘束力のある承認メッセージを要求する場合、通常、これが受信されるまで通信が遅れます。
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).
ルート最適化の特定の問題の1つは、ルート最適化されたパケットが自宅とケアの両方の住所の両方をプレーンテキストで運ぶため、ロケーションプライバシーです。標準的な回避策は、ロケーションのプライバシーが必要な場合、双方向トンネルに戻ることです。次に、アドレスのケアを備えたパケットは、モバイルノードとホームエージェントの間でのみ転送され、セキュリティペイロード（ESP）[42]をカプセル化するIPSECを介して暗号化できます。しかし、双方向のトンネルでさえ、セキュリティパラメーターインデックス（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.
ルートの最適化には、モバイルノードが移動しない場合でも、定期的なシグナル伝達が必要です。モバイルノードが静止ノードと通信する場合、シグナリングオーバーヘッドは1秒あたり7.16ビットになります[6]。両方のピアがモバイルであるかどうかは倍増します。このオーバーヘッドは、ノードが通信する場合は無視できる場合がありますが、非アクティブで同じ場所に留まるモバイルノードの問題になる可能性があります。これらのノードは通常、バッテリー電源を節約するためにスタンバイモードに移動することを好みます。また、周期的なリフレッシュは、より効率的に使用できるワイヤレス帯域幅の一部を消費します。シグナリングオーバーヘッドを減らすための最適化は、これらの問題を軽減する可能性があります。
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-Addressテストを使用して、モバイルノードがライブであることを確認し、特定の宛先アドレスへのパス上にあります。ホームアドレステストは、モバイルノードが自宅の住所の正当な所有者であるという証拠を提供します。アドレスのケアテストは、スプーフィングされた住所を検出し、リダイレクトベースの洪水攻撃を防ぎます。両方のテストは並行して実行できます。
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の境界内では、帰還性の高い手順が実行可能ですが、仕様では、拘束力のあるノードに拘束力のある更新メッセージを送信して、バインディングまで拘束力のある更新メッセージを送信することにより、モバイルノードが特派員登録を続けることを許可しません。住宅登録が成功したことを示す謝辞メッセージが受信されました。とにかく、帰還性の高い手順には自宅の登録よりも時間がかかる可能性が高いため、これは通常問題ではありません。ただし、いくつかの最適化（セクション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.
楽観的な行動の欠点は、紛失、並べ替え、または拒否されたバインディングアップデートメッセージがデータパケットを破棄する可能性があることです。それにもかかわらず、パケットの損失は保守的なアプローチに同様のマイナスの影響を与えるでしょう。したがって、モバイルノードは、いずれにせよ、これらのパケットの損失の可能性に備える必要があります。
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].
モバイルノードと特派員ノードが完全に通信できないクリティカルハンドオフフェーズは、帰還性の高い手順を含め、住宅登録と特派員登録に及びます。このフェーズを短縮する1つの手法は、ハンドオフの前にシグナリングの一部を積極的に達成することです。特に、RFC 3775 [52] [51]の仕様に違反することなく、ホームアドレステストを事前に実行できます。
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 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].
将来のハンドオフの準備が整った新鮮なホームKeygenトークンを用意するために、モバイルノードは、トークン寿命ごと、つまり3.5分ごとに積極的なホームアドレステストを少なくとも1回開始する必要があります。これは、モバイルノードがしばらく動かなくても7分ごとに、特派員の登録を7分ごとに更新する必要があることを考えると、ホームアドレステストに費やされた信号のオーバーヘッドを最大2倍にします。モバイルノードのローカルリンクレイヤーがハンドオフを予測し、そのような場合のホームアドレステストをトリガーできる最適化が可能です。[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]で並行したアドレスのケアテストがどのように使用されるかを示しています。モバイルノードがハンドオフ後に新しいケアのケアを構成するとすぐに、特派員ノードに早期バインディングアップデートメッセージを送信します。このメッセージに署名するには、プロアクティブなホームアドレステストから取得されたホームキーゲントークンのみが必要です。特派員ノードは、初期のバインディングアップデートメッセージを受信したときに、新しい未確認の住所のための暫定的なバインディングを作成します。このアドレスはすぐに使用できます。モバイルノードは最終的に、ADDRESSテストの同時ケアテストが完了すると、（標準の）バインディングアップデートメッセージを特派員ノードに送信します。クレジットベースの承認（セクション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).
ホームアドレスを介してパケットを転用するには、ホームエージェントと特派員ノードの両方で信号が必要です。ホームエージェントは、新しい住所で傍受されるパケットを正しく転送できるように、新しい住所について通知する必要があります。特派員ノードは、現在のバインディングがもはや有効ではなく、削除されるべきであることを示すバインディングアップデートメッセージを受信するまで、古い住所にパケットを送信し続けます。このリクエストには、不正なノードによるサービスの拒否を防ぐために、ホームアドレステストによる認証が必要です。テストは積極的に実現できます（セクション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]は、次の3つの仮説に基づいてそのような保護を提供する手法です。
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.
Inboundモードは、同等のデータボリュームを両方向に送信するアプリケーションで正常に動作します。一方、このモードは、非対称トラフィックパターンを備えたアプリケーションが使用されている場合、ハンドオフに必要なクレジットの量をモバイルノードに収集することを防ぐ場合があります。たとえば、ファイルの転送とメディアストリーミングは、クライアント、通常はモバイルノードに向けた高スループットが特徴であり、サービスサービスの特派員ノードに向かってスループットはほとんどありません。
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）は、通常、アップロードレートよりもはるかに高いダウンロードレートを持っています。アップロードレートが限られているため、直接の洪水を意味のない、ほとんどのサービス拒否の試みを提供します。しかし、攻撃者は、強力なダウンロード率を活用して、1つまたは複数の特派員ノードでクレジットを構築できます。その後、より強力でリダイレクトベースの洪水攻撃にクレジットを違法に費やす可能性があります。これがこれまで問題と見なされていない理由は、リモートエンドで十分なクレジットを蓄積するために、攻撃者が最初に同じパケット洪水にさらされなければならないため、被害者に向かってリダイレクトする必要があるからです。
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.
ヒューリスティックのもう1つの問題は、それらが通常反応的であることです。特派員ノードは、表示された後にMishaviorにのみ応答できます。制裁が迅速に課される場合、攻撃は単に価値がないかもしれません。しかし、時期尚早の措置は避けるべきです。また、攻撃者は異なるホームアドレスを使用できる可能性があり、一般的に、特派員ノードがホームアドレスのセットが同じノードに属していることを確認することは不可能であることに留意する必要があります。攻撃者はさらに、結果を増幅しようとして、攻撃のために複数の特派員ノードを悪用する場合があります。
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を使用して、公開キーをIPアドレスに結合することができます。この場合、暗号化されたアドレス（CGA）[44] [34] [47]と呼ばれます。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.
多くのアプリケーションは、CGAが有利な場合に考えられます。モバイルIPv6では、CGAはモバイルノードのホームアドレスを公開キー[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である場合でも、ネットワークプレフィックスを検証するには、最初のホームアドレステストが必要です。同じ理由で、CGAがアドレスのケアとして使用されることはめったにありません。
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.
他のタイプのCBIDと比較したCGAの制限の1つは、暗号化された部分が長さで最大62ビットのみであることです。アドレスの残りの部分は、64ビットネットワークのプレフィックスと、ユニバーサル/ローカルおよび個人/グループビットによって占有されています。（[44]の仕様は、3ビットセキュリティパラメーターをアドレスにさらにハードコードし、暗号化された保護された部分を59ビットに削減します。）ブルートフォース攻撃は、パブリック/プライベートキーパブリック/プライベートキーペアを明らかにする可能性があります。特定のCGAが生成されます。この脆弱性は、攻撃者が適切なパブリック/プライベートキーパブリック/プライベートキーペアを見つけた場合に備えて、攻撃者が複数のネットワークのCGAを形成できないように、インターフェイス識別子のハッシュ計算にネットワークプレフィックスを含めることで抑制できます。。
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.
CGAを生成する際の衝突を解決するために、衝突カウントはハッシュ関数への入力の一部です。これを変更すると、異なるCGAが生成されます。残念ながら、衝突カウントは、同じプライベート/パブリックキーのペアを使用して複数のCGAを生成できるため、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.
より長いCBIDを通じて、より高いセキュリティを達成できます。たとえば、ホストIDプロトコル[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.
事前構成に関する2つの提案は現在、IETF内で議論されています。[25]は、return Rotability手順を通じてそれらを取得する必要があるのではなく、自宅とケアのケア自体を計算するために必要な情報をモバイルノードに与えます。[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.
委任のもう1つの利点は、モバイルノードでのパブリックキー計算を回避することです。一方、特派員ノードでのオーバーヘッドが増加します。これは、特派員ノードが提供するサービスに比べて、特派員ノードで利用可能なリソースに応じて問題になる場合とそうでない場合があります。特派員ノードはモバイル自体である可能性があります。その場合、暗号化操作には問題があります。さらに、オーバーヘッドの増加は、資源排除攻撃に対するリスクが高いことを意味します。
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]はより複雑です。1つの可能性は、モバイルノードに代わってモバイルルーターハンドルルートの最適化を持つことです。これには、モバイルルーターが着信パケットと発信パケットを変更して、エンドノード間の直接パスにルーティングできるようにする必要があります。モバイルルーターは、モバイルノードに代わってモバイル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]を介して暗号化できます。しかし、それでもモバイルノードが定期的に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アドレステストを備えたバリエーションには、これらの利点もあります。CBIDは、PKIなしで公開キー認証を可能にします。それらは、ホームアドレステストのより安全な代替品を構成しており、同時に到達可能性の検証と組み合わせると最も効果的です。CBIDベースの認証では、人間が可読できる識別子と対応するCBIDの間のマッピングでノードをプログラムする必要がある場合があります。事前構成は、ホームアドレステストを避けるためのもう1つのアプローチです。計算上の高価なパブリックキーアルゴリズムなしでは行われますが、ペアごとの資格情報、したがって管理上のメンテナンスが必要です。適切なインフラストラクチャが利用可能な場合、エンドノードは、認証と暗号化タスクを信頼できるネットワークエンティティに委任する場合があります。委任は、モビリティサポートを目的とした証明書の使用を復活させる可能性があります。しかし、それは代表者への依存を導入し、新しいネットワークエンティティのプロビジョニングコストを追加し、認可されたノードのコミュニティに限定される可能性があります。
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].
ネットワークスタックのさまざまな部分でのハンドオフパフォーマンスを改善するために、主にハンドオフパフォーマンスに焦点を当てた多くの提案が提示されています。これらには、リンク層パラメーターチューニング[49]およびネットワークアクセス認証[18] [2] [32]、およびIPv6ルーター発見[11] [12]、アドレス構成[23]、および移動検出[19]が含まれます。[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.
o モバイルIPv6のコンテキストで、ホストIDプロトコル、ストリーム制御伝送プロトコル、Datagram輻輳制御プロトコル、またはリンクレイヤーモビリティソリューションなど、他のモビリティプロトコルへのコンテキストで開発された最適化の導入。
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アドレスから別の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.
この文書は、アルファベット順に、サミタ・チャクラバルティ、フランシス・デュポン、ティエリー・エルンスト、ジェレルド・ジャレッタ、ジェームズ・ケンプフ、ラジーフ・クードリ、ガブリエル・モンテネグロ、ヴィディヤ・ナラヤナン、ファン・ザオによって徹底的にレビューされました。著者は、これらの人々の貴重なコメントと提案に感謝したいと考えています。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[2] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", IEEE Contribution 802.11-04/0377r1, March 2004.
[2] Alimian、A。and 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年4月、英国ケンブリッジ、セキュリティプロトコルワークショップ2002の議事録。
[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、「安全で効率的なネットワークアクセス」、2004年11月、モバイルおよびワイヤレスセキュリティに関するDIMACSワークショップの議事録。
[5] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", Work in Progress, August 2006.
[5] Arkko、J.、Vogt、C。、およびW. Haddad、「モバイル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. Vogt、「拘束力のある生涯拡張のためのクレジットベースの承認」、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 Computer Communication Review、ACM Press、Vol。34、No。5、2004年10月。
[8] Bradner, S., Mankin, A., and J. Schiller, "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003.
[8] Bradner、S.、Mankin、A。、およびJ. Schiller、「専用キー（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.、Montenegro、G.、Laganier、J。、およびC. Neumann、「IPv6の日和見暗号化による盗聴を妨げる」、コンピューターセキュリティの研究に関する欧州シンポジウムの議事録、コンピューターサイエンスの講義ノート、Springer-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] Chandra、R.、Bahl、P。、およびP. Bahl、「Multinet：単一のワイヤレスカードを使用した複数のIEEE 802.11ネットワークへの接続」、IEEE Infocomの議事録、Vol。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] Daley、G.、Pentland、B。、およびR. Nelson、「モバイルIPv6ハンドオーバーに対する高速ルーター広告の影響」、コンピューターと通信に関するIEEE国際シンポジウムの議事録、Vol。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] Daley、G.、Pentland、B。、およびR. Nelson、「Mobile IPv6の動き検出最適化」、2003年9月、IEEE国際会議の議事録。
[13] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[13] Daley、G。、「ロケーションプライバシーとモバイルIPv6」、2004年1月、進行中の作業。
[14] Dupont, F., "A Note about 3rd Party Bombing in Mobile IPv6", Work in Progress, July 2006.
[14] Dupont、F。、「モバイルIPv6でのサードパーティの爆撃に関するメモ」、2006年7月、進行中の作業。
[15] Dupont, F. and J. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", Work in Progress, August 2004.
[15] Dupont、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] Dupont、F。、およびJ. Combes、「State Cookieを使用した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] Haddad、W.、Nordmark、E.、Dupont、F.、Bagnulo、M。、およびB. Patil、「モバイルおよびマルチホームのノードのプライバシー：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 Standard 802.1x、2004年12月。
[19] Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix List Based Approach", Work in Progress, January 2006.
[19] Choi、J。およびE. Nordmark、「変更されていないルーターを備えたDNA：プレフィックスリストベースのアプローチ」、2006年1月、進行中の作業。
[20] Narayanan, S., Ed., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
[20] Narayanan、S.、ed。、「IPv6ネットワーク（DNAV6）のネットワーク添付ファイルの検出」、2006年10月の作業。
[21] Moskowitz, R., Nikander, P., Jokela, Ed., P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2006.
[21] Moskowitz、R.、Nikander、P.、Jokela、ed。、P.、およびT. Henderson、「Host Identity Protocol」、2006年6月、進行中の作業。
[22] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
[22] Henderson、T.、ed。、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、2006年6月、Work in Progress。
[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] Perkins、C。、「静的共有キーを使用したモバイルIPv6ルート最適化の保護」、RFC 4449、2006年6月。
[26] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", Work in Progress, September 2006.
[26] Ng、C.、Thubert、P.、Watari、M。、およびF. Zhao、「ネットワークモビリティルート最適化問題ステートメント」、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] Ng、C.、Zhao、F.、Watari、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] 「Kame-Shisa」、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] Koodli、R.、Devarapalli、V.、Flinck、H。、およびC. Perkins、「IPモビリティの存在下でのIPアドレスの場所プライバシーのソリューション」、2005年2月の進行中。
[31] Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for Linux (MIPL)".
[31] Nuorvala、V.、Petander、H。、およびA. Tuominen、「Linux for Linux（Mipl）のモバイルIPv6」。
[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] Mishra、A.、Shin、M.、Petroni Jr.、N.、Clancy、C。、およびW. Arbaugh、「近隣グラフを使用したプロアクティブキー分布」、IEEE Wireless Communications、Vol。11、No。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。およびクロード。Castelluccia、「暗号ベースの識別子（CBIDS）：概念とアプリケーション」、情報に関するACMトランザクションおよびシステムセキュリティVol.7、No。1、2004年2月。
[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月、Springer-Verlagのセキュリティプロトコルに関する国際ワークショップから論文を修正しました。
[35] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", ACM SIGCOMM Computer Communication Review, April 2001.
[35] O'Shea、G。およびM. Roe、「Mipv6の児童耐性認証」、ACM Sigcomm Computer Communication Review、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] Perera、E.、Sivaraman、V。、およびA. Seneviratne、「ネットワークモビリティサポートに関する調査」、ACM Sigcomm Computer Communication Review、Vol。8、No。2、ACM Press、2004年4月。
[37] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-basedBinding Update Protocol (CBU)", Work in Progress, March 2005.
[37] Bao、F.、Deng、R.、Qiu、Y。、およびJ. Zhou、「証明書ベースのバインディングアップデートプロトコル（CBU）」、2005年3月、Work in Progress。
[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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Black、B。、およびV. Gill、「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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[42] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[42] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[43] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[43] Baker、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] Huston、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.、Aura、T.、Montenegro、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] Roe、M.、Aura、T.、O'Shea、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.、Li、J.、Wu、Y。、およびG. Cao、「モバイルIPのエージェントベースのルート最適化」、IEEE Vehicular Technology Conferenceの議事録、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] Velayos、H。and G. Karlsson、「IEEE 802.11b MACレイヤーハンドオフ時間を減らすための技術」、通信ネットワークの研究所、KTH、ロイヤルインスティテュート、ストックホルム、スウェーデン、TRITA-IMIT-LCN R 03：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] Vogt、C。、「同時のIPアドレステストに対するクレジットベースの承認」、2005年6月、ISTモバイルおよびワイヤレス通信サミットの議事録。
[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] Vogt、C.、Bless、R.、Doll、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] Vogt、C。およびM. Doll、「IPv6の効率的なエンドツーエンドモビリティサポート」、2006年4月、IEEEワイヤレス通信およびネットワーキング会議の議事録。
[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] Vogt、C。、「モバイルIPv6ルート最適化による反応性および積極的なハンドオフの包括的な遅延分析」、テレマティクス研究所、カールスルーエ大学（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] Zhao、F.、Wu、F。、およびS. Jung、「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] Calderon、M.、Bernardos、C.、Bagnulo、M.、Soto、I。、およびA. de La Oliva、「Nemoのルート最適化ソリューションの設計と実験的評価」、IEEEジャーナルコミュニケーションのIEEEジャーナル、vol。24、No。9、2006年9月。
Authors' Addresses
著者のアドレス
Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany
キリスト教VOGTテレマティクス大学Karlsruhe（Th）P.O。Box 6980 76128 Karlsruheドイツ
EMail: chvogt@tm.uka.de
Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland
Jari Arkko Ericsson Research Nomadiclab FI-02420 Jorvas Finland
EMail: jari.arkko@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。