Network Working Group P. Nikander
Request for Comments: 4225 J. Arkko
Category: Informational Ericsson Research NomadicLab
T. Aura
Microsoft Research
G. Montenegro
Microsoft Corporation
E. Nordmark
Sun Microsystems
December 2005
Mobile IP Version 6 Route Optimization Security Design Background
モバイルIPバージョン6経路最適化セキュリティデザインの背景
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 Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.
この文書では、モバイルIPv6（MIPv6の）ルート最適化のセキュリティ設計の論理的根拠のアカウントです。 2002 - 本書の目的は、考え方を提示すると、2001年のモバイルIPv6のセキュリティ設計の背後にある理由を保存することです。
The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs.
文書には、2人のターゲットオーディエンスを持っている：（1）より良いのMIPv6セキュリティ手順で設計の選択肢を理解するのMIPv6の実装を支援し、そして（2）モビリティやマルチホーミングを扱う人々が自分たちのデザインにおける潜在的なセキュリティ上の落とし穴の数を回避することを可能にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Assumptions about the Existing IP Infrastructure ...........4
1.2. The Mobility Problem and the Mobile IPv6 Solution ..........6
1.3. Design Principles and Goals ................................8
1.3.1. End-to-End Principle ..................................8
1.3.2. Trust Assumptions .....................................8
1.3.3. Protection Level ......................................8
1.4. About Mobile IPv6 Mobility and its Variations ..............9
2. Avenues of Attack ...............................................9
2.1. Target ....................................................10
2.2. Timing ....................................................10
2.3. Location ..................................................11
3. Threats and Limitations ........................................11
3.1. Attacks Against Address 'Owners' ("Address Stealing").. ...12
3.1.1. Basic Address Stealing ...............................12
3.1.2. Stealing Addresses of Stationary Nodes ...............13
3.1.3. Future Address Sealing ...............................14
3.1.4. Attacks against Secrecy and Integrity ................15
3.1.5. Basic Denial-of-Service Attacks ......................16
3.1.6. Replaying and Blocking Binding Updates ...............16
3.2. Attacks Against Other Nodes and Networks (Flooding) .......16
3.2.1. Basic Flooding .......................................17
3.2.2. Return-to-Home Flooding ..............................18
3.3. Attacks against Binding Update Protocols ..................18
3.3.1. Inducing Unnecessary Binding Updates .................19
3.3.2. Forcing Non-Optimized Routing ........................20
3.3.3. Reflection and Amplification .........................21
3.4. Classification of Attacks .................................22
3.5. Problems with Infrastructure-Based Authorization ..........23
4. Solution Selected for Mobile IPv6 ..............................24
4.1. Return Routability ........................................24
4.1.1. Home Address Check ...................................26
4.1.2. Care-of-Address Check ................................27
4.1.3. Forming the First Binding Update .....................27
4.2. Creating State Safely .....................................28
4.2.1. Retransmissions and State Machine ....................29
4.3. Quick expiration of the Binding Cache Entries .............29
5. Security Considerations ........................................30
5.1. Residual Threats as Compared to IPv4 ......................31
5.2. Interaction with IPsec ....................................31
5.3. Pretending to Be One's Neighbor ...........................32
5.4. Two Mobile Nodes Talking to Each Other ....................33
6. Conclusions ....................................................33
7. Acknowledgements ...............................................34
8. Informative References .........................................34
Mobile IPv4 is based on the idea of supporting mobility on top of existing IP infrastructure, without requiring any modifications to the routers, the applications, or the stationary end hosts. However, in Mobile IPv6 [6] (as opposed to Mobile IPv4), the stationary end hosts may provide support for mobility, i.e., route optimization. In route optimization, a correspondent node (CN) (i.e., a peer for a mobile node) learns a binding between the mobile node's stationary home address and its current temporary care-of address. This binding is then used to modify the handling of outgoing (as well as the processing of incoming) packets, leading to security risks. The purpose of this document is to provide a relatively compact source for the background assumptions, design choices, and other information needed to understand the route optimization security design. This document does not seek to compare the relative security of Mobile IPv6 and other mobility protocols, or to list all the alternative security mechanisms that were discussed during the Mobile IPv6 design process. For a summary of the latter, we refer the reader to [1]. Even though incidental implementation suggestions are included for illustrative purposes, the goal of this document is not to provide a guide to implementors. Instead, it is to explain the design choices and rationale behind the current route optimization design. The authors participated in the design team that produced the design and hope, via this note, to capture some of the lessons and reasoning behind that effort.
モバイルIPv4は、ルータ、アプリケーション、または固定エンドホストに変更を必要とせず、既存のIPインフラストラクチャの上に移動性をサポートするという考えに基づいています。しかしながら、モバイルIPv6の[6]（モバイルIPv4とは対照的に）、固定エンドホストは、移動性のサポート、すなわち、ルート最適化を提供することができます。ルート最適化では、コレスポンデントノード（CN）（モバイルノードのために、すなわち、ピア）は、モバイルノードの固定ホームアドレスとその現在の仮の気付アドレスとのバインディングを学習します。この結合は、セキュリティリスクにつながる、発信の取り扱い（ならびに着信の処理）パケットを変更するために使用されます。このドキュメントの目的は、背景の仮定、設計上の選択、およびルート最適化のセキュリティ設計を理解するために必要なその他の情報については、比較的コンパクトなソースを提供することです。この文書では、モバイルIPv6や他のモビリティプロトコルの相対的な安全性を比較しようとしない、またはモバイルIPv6の設計プロセスの間に議論されたすべての代替セキュリティメカニズムを一覧表示します。後者の概要については、我々は、[1]〜リーダーを指します。偶発的な実装の提案は、例示目的のために含まれているにもかかわらず、このドキュメントの目標は、実装者へのガイドを提供することではありません。代わりに、それは現在のルートの最適化設計の背後にある設計の選択と根拠を説明することです。著者は、その努力の後ろのレッスンと推論の一部をキャプチャするために、このノートを経て、デザインと希望を生み出しデザインチームに参加しました。
The authors' intent is to document the thinking behind that design effort as it was. Even though this note may incorporate more recent developments in order to illustrate the issues, it is not our intent to present a new design. Rather, along with the lessons learned, there is some effort to clarify differing opinions, questionable assumptions, or newly discovered vulnerabilities, should such new information be available today. This is also very important, because it may benefit the working group's hindsight as it revises or improves the Mobile IPv6 specification.
著者の意図は、それがあったとして、その設計努力の背後にある考え方を文書化することです。このノートは、問題を説明するために、より多くの最近の動向を組み込むことができるにもかかわらず、新しいデザインを提示するために我々の意図するところではありません。むしろ、教訓とともに、新たな情報が今日利用可能であるべき異なった意見、疑問仮定、または新たに発見された脆弱性を、明確にするいくつかの努力があります。それはモバイルIPv6の仕様を修正または改善として、それはワーキンググループの後知恵を利益を得ることができるので、これは、また非常に重要です。
To fully understand the security implications of the relevant design constraints, it is necessary to explore briefly the nature of the existing IP infrastructure, the problems Mobile IP aims to solve, and the design principles applied. In the light of this background, we can then explore IP-based mobility in more detail and have a brief look at the security problems. The background is given in the rest of this section, starting from Section 1.1.
完全に関連する設計上の制約のセキュリティへの影響を理解するために、それは簡単に既存のIPインフラストラクチャの本質を探求する必要がある、モバイルIPを解決することを目的問題、および設計原理が適用されます。このような背景を踏まえて、我々は、より詳細にIPベースのモビリティを探索し、セキュリティ上の問題を簡単に見を持つことができます。背景は、セクション1.1から始めて、このセクションの残りの部分に記載されています。
Although the introduction in Section 1.1 may appear redundant to readers who are already familiar with Mobile IPv6, it may be valuable to read it anyway. The approach taken in this document is very different from that in the Mobile IPv6 specification. That is, we have explicitly aimed to expose the implicit assumptions and design choices made in the base Mobile IPv6 design, while the Mobile IPv6 specification aims to state the result of the design. By understanding the background, it is much easier to understand the source of some of the related security problems, and to understand the limitations intrinsic to the provided solutions.
セクション1.1で導入が既にモバイルIPv6に精通している読者への冗長見えるかもしれないが、とにかくそれを読んで価値があります。本書で取られたアプローチは、モバイルIPv6仕様のものとは非常に異なっています。つまり、我々は、明示的にモバイルIPv6の仕様は、設計の結果を述べることを目指しながら、ベースのモバイルIPv6のデザインで作られた暗黙の仮定と設計上の選択を公開することを目的としています。背景を理解することで、セキュリティ関連の問題のいくつかの原因を理解するために、と提供ソリューションに固有の制限を理解する方がはるかに簡単です。
In particular, this document explains how the adopted design for "Return Routability" (RR) protects against the identified threats (Section 3). This is true except for attacks on the RR protocol itself, which require other countermeasures based on heuristics and judicious implementation (Section 3.3).
特に、この文書は、「リターンルータビリティ」（RR）のために採用され、デザインが識別された脅威（第3節）から保護する方法について説明します。これは、ヒューリスティック及び賢明な実装（セクション3.3）に基づいて、他の対策を必要とするRRプロトコル自体への攻撃を除いて同様です。
The rest of this document is organized as follows: after this introductory section, we start by considering the avenues of attack in Section 2. The security problems and countermeasures are studied in detail in Section 3. Section 4 explains the overall operation and design choices behind the current security design. Section 5 analyzes the design and discuss the remaining threats. Finally, Section 6 concludes this document.
このドキュメントの残りは以下のように構成されています。この入門セクションの後、我々はセキュリティ上の問題と対策が第3節第4節で詳細に検討されている第2節では、攻撃の手段を検討することから始め全体的な動作を説明し、後ろのデザインの選択現在のセキュリティ設計。第5節では、設計を分析し、残りの脅威を議論します。最後に、第6節は、この文書を終わります。
One of the design goals in the Mobile IP design was to make mobility possible without changing too much. This was especially important for IPv4, with its large installed base, but the same design goals were inherited by Mobile IPv6. Some alternative proposals take a different approach and propose larger modifications to the Internet architecture (see Section 1.4).
モバイルIPの設計における設計目標の1つは、あまりにも多くを変更することなく、可能なモビリティを作ることでした。これは、大規模なインストール・ベースで、IPv4のために特に重要だったが、同じ設計目標は、モバイルIPv6に継承されました。いくつかの代替案は異なるアプローチをとり、インターネットアーキテクチャに大きな変更を提案している（1.4節参照）。
To understand Mobile IPv6, it is important to understand the MIPv6 design view of the base IPv6 protocol and infrastructure. The most important base assumptions can be expressed as follows:
モバイルIPv6を理解するには、基本IPv6プロトコルとインフラのMIPv6のデザインビューを理解することが重要です。次のように最も重要な基本仮定は表すことができます。
1. The routing prefixes available to a node are determined by its current location, and therefore the node must change its IP address as it moves.
1.ノードが利用可能なルーティングプレフィックスは、その現在の位置によって決定され、それが移動するように、したがってノードは、そのIPアドレスを変更しなければなりません。
2. The routing infrastructure is assumed to be secure and well functioning, delivering packets to their intended destinations as identified by destination address.
2.ルーティングインフラストラクチャは、宛先アドレスによって特定されるように、その目的の宛先にパケットを送達する、安全で十分に機能していると仮定されます。
Although these assumptions may appear to be trivial, let us explore them a little further. First, in current IPv6 operational practice the IP address prefixes are distributed in a hierarchical manner. This limits the number of routing table entries each individual router needs to handle. An important implication is that the topology determines what globally routable IP addresses are available at a given location. That is, the nodes cannot freely decide what globally routable IP address to use; they must rely on the routing prefixes served by the local routers via Router Advertisements or by a DHCP server. In other words, IP addresses are just what the name says, addresses (i.e., locators).
これらの仮定は些細なことに見えるかもしれないが、私たちは少しさらにそれらを探検してみましょう。まず、現在のIPv6運用実際にはIPアドレスプレフィックスは、階層的に分散されています。これは、個々のルータが処理する必要があるテーブルのエントリをルーティングの数を制限します。重要な含意は、トポロジがグローバルにルーティング可能なIPアドレスが与えられた場所で利用可能であるかを決定することです。これは、ノードが自由にグローバルにルーティング可能なIPアドレスを使用するかを決定することはできません。彼らは、ルータ広告を介して、またはDHCPサーバによってローカルルータによって提供ルーティングプレフィックスに依存しなければなりません。言い換えれば、IPアドレスは、名前を言うだけで何のアドレス（すなわち、ロケータ）です。
Second, in the current Internet structure, the routers collectively maintain a distributed database of the network topology and forward each packet towards the location determined by the destination address carried in the packet. To maintain the topology information, the routers must trust each other, at least to a certain extent. The routers learn the topology information from the other routers, and they have no option but to trust their neighbor routers about distant topology. At the borders of administrative domains, policy rules are used to limit the amount of perhaps faulty routing table information received from the peer domains. While this is mostly used to weed out administrative mistakes, it also helps with security. The aim is to maintain a reasonably accurate idea of the network topology even if someone is feeding faulty information to the routing system.
第二に、現在のインターネット構造では、ルータは、集合的にネットワークトポロジの分散データベースを維持し、パケットで運ばれた宛先アドレスによって決定された位置に向かって、各パケットを転送します。トポロジー情報を維持するために、ルータは、少なくともある程度まで、互いを信頼しなければなりません。ルータは他のルータからのトポロジ情報を学び、そして、彼らは遠くのトポロジーについての彼らの隣人ルータを信頼するしか選択肢がありません。管理ドメインの境界で、ポリシールールは、ピア・ドメインから受信した、おそらく不良ルーティングテーブル情報の量を制限するために使用されます。これは主に、管理ミスを取り除くために使用されるが、それはまた、セキュリティに役立ちます。その目的は、誰かがルーティングシステムに障害のある情報を供給されている場合でも、ネットワークトポロジの合理的に正確なアイデアを維持することです。
In the current Mobile IPv6 design, it is explicitly assumed that the routers and the policy rules are configured in a reasonable way, and that the resulting routing infrastructure is trustworthy enough. That is, it is assumed that the routing system maintains accurate information of the network topology, and that it is therefore able to route packets to their destination locations. If this assumption is broken, the Internet itself is broken in the sense that packets go to wrong locations. Such a fundamental malfunction of the Internet would render hopeless any other effort to assure correct packet delivery (e.g., any efforts due to Mobile IP security considerations).
現在のモバイルIPv6の設計では、明示的ルータとポリシールールが妥当な方法で構成されているものと、得られたルーティングインフラストラクチャは、十分に信頼できること。つまり、ルーティングシステムは、ネットワークトポロジーの正確な情報を保持しているものと、それが目的地の場所までパケットをルーティングすることができることである、です。この仮定が壊れている場合は、インターネット自体は、パケットが間違った場所に行くという意味で壊れています。インターネットのような基本的な機能不全は、正しいパケット配信を保証するために絶望的な他の努力をレンダリングします（例えば、モバイルIPのセキュリティに関する考慮事項に起因するいかなる努力）。
Some of the threats and attacks discussed in this document take advantage of the ease of source address spoofing. That is, in the current Internet it is possible to send packets with a false source IP address. The eventual introduction of ingress filtering is assumed to prevent this. When ingress filtering is used, traffic with spoofed addresses is not forwarded. This filtering can be applied at different network borders, such as those between an Internet service provider (ISP) and its customers, between downstream and upstream ISPs, or between peer ISPs [5]. Obviously, the granularity of ingress filters specifies how much you can "spoof inside a prefix". For example, if an ISP ingress filters a customer's link but the customer does nothing, anything inside the customer's /48 prefix could be spoofed. If the customer does filtering at LAN subnets, anything inside the /64 prefixes could be spoofed. Despite the limitations imposed by such "in-prefix spoofing", in general, ingress filtering enables traffic to be traceable to its real source network [5].
この文書で説明した脅威や攻撃の中には、送信元アドレススプーフィングの容易性を活用します。これは、現在のインターネットでは、偽の送信元のIPアドレスを持つパケットを送信することが可能となります。イングレスフィルタリングの最終的な導入は、これを防止するために想定されます。イングレスフィルタリングを使用する場合は、偽装されたアドレスを持つトラフィックが転送されません。このフィルタリングは、[5]の下流と上流のISP間、またはピアのISPとの間で、このようなインターネットサービスプロバイダ（ISP）とその顧客との間のもののような異なるネットワーク境界、で適用することができます。もちろん、侵入フィルタの粒度は指定どのくらいのことができます「接頭内部なりすまし」。たとえば、ISPの侵入は、顧客のリンクをフィルタリングしますが、お客様は何もしない、顧客の/ 48プレフィックス内のものは、スプーフィングされる可能性があります。顧客がLANサブネットでのフィルタリングない場合は、/ 64プレフィックス内のものは詐称することができます。一般的に、そのような「イン接頭なりすまし」による制限にもかかわらず、イングレスフィルタリングは、実際のソースネットワークにトレーサブルであることトラフィックを可能にする[5]。
However, ingress filtering helps if and only if a large part of the Internet uses it. Unfortunately, there are still some issues (e.g., in the presence of site multi-homing) that, although not insurmountable, do require careful handling, and that are likely to limit or delay its usefulness [5].
しかし、イングレスフィルタリングは、インターネットの大部分は、それを使用する場合にのみ役立ちます。残念ながら、いくつかの問題が残っている（例えば、サイトマルチホーミングの存在下で）克服できないではないが、慎重な取り扱いを必要としますし、制限したり、その有用性を遅らせる可能性があること、という[5]。
The Mobile IP design aims to solve two problems at the same time. First, it allows transport layer sessions (TCP connections, UDP-based transactions) to continue even if the underlying host(s) move and change their IP addresses. Second, it allows a node to be reached through a static IP address, a home address (HoA).
モバイルIPの設計は、同時に2つの問題を解決することを目的とします。まず、それはトランスポート層セッション（TCP接続、UDPベースのトランザクションが）も、基礎となるホスト（複数可）に移動した場合継続し、そのIPアドレスを変更することができます。第二に、それは、ノードは、静的IPアドレス、ホームアドレス（HoAで）を介して到達することができます。
The latter design choice can also be stated in other words: Mobile IPv6 aims to preserve the identifier nature of IP addresses. That is, Mobile IPv6 takes the view that IP addresses can be used as natural identifiers of nodes, as they have been used since the beginning of the Internet. This must be contrasted to proposed and existing alternative designs where the identifier and locator natures of the IP addresses have been separated (see Section 1.4).
後者の設計上の選択は、他の言葉で述べることができる：モバイルIPv6は、IPアドレスの識別性を維持することを目指しています。それは、彼らがインターネットの初めから使用されているとして、モバイルIPv6は、IPアドレスは、ノードの自然の識別子として使用することが可能という見解をとり、あります。これは、IPアドレスの識別子とロケータ性質が分離されている提案し、既存の代替設計（第1.4節を参照）と対比されなければなりません。
The basic idea in Mobile IP is to allow a home agent (HA) to work as a stationary proxy for a mobile node (MN). Whenever the mobile node is away from its home network, the home agent intercepts packets destined to the node and forwards the packets by tunneling them to the node's current address, the care-of address (CoA). The transport layer (e.g., TCP, UDP) uses the home address as a stationary identifier for the mobile node. Figure 1 illustrates this basic arrangement.
モバイルIPの基本的な考え方は、ホームエージェント（HA）は、モバイルノード（MN）のための静止プロキシとして動作できるようにすることです。モバイルノードがそのホームネットワークから離れているときはいつでも、ホームエージェントは、ノード宛のパケットを傍受し、ノードの現在のアドレス、気付アドレス（CoA）にそれらをトンネリングすることによってパケットを転送します。トランスポート層（例えば、TCP、UDP）は、移動ノードのための固定識別子としてホームアドレスを使用します。図1は、この基本的な構成を示す図です。
The basic solution requires tunneling through the home agent, thereby leading to longer paths and degraded performance. This tunneling is sometimes called triangular routing since it was originally planned that the packets from the mobile node to its peer could still traverse directly, bypassing the home agent.
基本的な解決策は、それによって長いパスと性能低下につながる、ホームエージェントを介してトンネリングが必要です。それは、もともとそのピアに、モバイルノードからのパケットはまだホームエージェントを介さず、直接行き来できることが計画されていたので、このトンネルは時々三角ルーティングと呼ばれています。
+----+ +----+
| MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA |
+----+ ____________ +-#--+
| CoA ___/ \_____ # Home Link
-+-------/ Internet * * *-*-*-*-#-#-#-#-----
| * * | * Home Address
\___ * * _____/ + * -+
\_____*______/ | MN |
* + - -+
+----+
| CN | Data path as * * * *
+----+ it appears to correspondent node
Real data path # # # #
実際のデータパス####
Figure 1. Basic Mode of Operation in Mobile IPv6
図1.モバイルIPv6の動作の基本モード
To alleviate the performance penalty, Mobile IPv6 includes a mode of operation that allows the mobile node and its peer, a correspondent node (CN), to exchange packets directly, bypassing the home agent completely after the initial setup phase. This mode of operation is called route optimization (RO). When route optimization is used, the mobile node sends its current care-of address to the correspondent node, using binding update (BU) messages. The correspondent node stores the binding between the home address and care-of address into its Binding Cache.
パフォーマンスの低下を軽減するために、モバイルIPv6は、初期セットアップ段階の後、完全にホームエージェントをバイパスし、直接パケットを交換するために、コレスポンデントノード（CN）は、モバイルノードとそのピアを可能にする動作モードを含みます。この動作モードは、経路最適化（RO）と呼ばれています。ルート最適化を使用すると、モバイルノードは、バインディングアップデート（BU）メッセージを使用して、コレスポンデントノードへの現在の気付アドレスを送信します。コレスポンデント・ノードは、その結合キャッシュにホームアドレスと気付アドレスとの間のバインディングを格納します。
Whenever MIPv6 route optimization is used, the correspondent node effectively functions in two roles. Firstly, it is the source of the packets it sends, as usual. Secondly, it acts as the first router for the packets, effectively performing source routing. That is, when the correspondent node is sending out packets, it consults its MIPv6 route optimization data structures and reroutes the packets, if necessary. A Binding Cache Entry (BCE) contains the home address and the care-of address of the mobile node, and records the fact that packets destined to the home address should now be sent to the destination address. Thus, it represents a local routing exception.
MIPv6のルート最適化が使用されるたびに、コレスポンデント・ノードは、効果的に二つの役割で機能します。第一に、それはいつものように、送信パケットの送信元です。第二に、それが効果的にソースルーティングを行う、パケットの最初のルータとして働きます。これは、コレスポンデントノードがパケットを送信しているとき、必要であれば、それは、そのMIPv6のルート最適化データ構造を参照し、パケットを再ルーティングし、です。バインディングキャッシュエントリ（BCE）ホームアドレスと気付けモバイルノードのアドレスが含まれており、ホームアドレス宛のパケットが、今の宛先アドレスに送信されなければならないという事実を記録します。これにより、ローカルルーティング例外を表します。
The packets leaving the correspondent node are source routed to the care-of address. Each packet includes a routing header that contains the home address of the mobile node. Thus, logically, the packet is first routed to the care-of address and then, virtually, from the care-of address to the home address. In practice, of course, the packet is consumed by the mobile node at the care-of address; the header just allows the mobile node to select a socket associated with the home address instead of one with the care-of address. However, the mechanism resembles source routing, as there is routing state involved at the correspondent node, and a routing header is used.
通信員ノードを残すパケットがソース気付けアドレスにルーティングされています。各パケットは、モバイルノードのホームアドレスを含むルーティングヘッダを含みます。このように、論理的に、パケットは最初の気付アドレスにルーティングされ、その後、事実上、からホームアドレスに気付アドレス。実際には、当然のことながら、パケットが気付アドレスにモバイルノードによって消費されます。ヘッダだけ気付アドレスとホームアドレスの代わりに一つと関連ソケットを選択するために、モバイルノードを可能にします。そこコレスポンデント・ノードに関係するルーティング状態は、ルーティング・ヘッダが使用されるが、機構は、ソースルーティングに似ています。
Nevertheless, this routing header is special (type 2) to avoid the risks associated with using the more general (type 0) variant.
それにもかかわらず、このルーティングヘッダは、より一般的な（タイプ0）変異体を使用することに関連するリスクを回避するための特別な（タイプ2）です。
The MIPv6 design and security design aimed to follow the end-to-end principle, to notice the differences in trust relationships between the nodes, and to be explicit about delivering a practical (instead of an over-ambitious) level of protection.
ノード間の信頼関係の違いに気づき、および保護のレベル（代わりに過野心的なの）実用を提供について明示的であるためには、エンド・ツー・エンド原理に従うことを目的としたMIPv6のデザインとセキュリティ設計。
Perhaps the leading design principle for Internet protocols is the so-called end-to-end principle [4][11]. According to this principle, it is beneficial to avoid polluting the network with state, and to limit new state creation to the involved end nodes.
おそらく、インターネットプロトコルのための主要な設計原理は、いわゆるエンド・ツー・エンド原理である[4] [11]。この原則によれば、国家とのネットワークを汚染を避けるために、そして関与エンドノードに新しい状態の作成を制限することが有益です。
In the case of Mobile IPv6, the end-to-end principle is applied by restricting mobility-related state primarily to the home agent. Additionally, if route optimization is used, the correspondent nodes also maintain a soft state relating to the mobile nodes' current care-of addresses, the Binding Cache. This can be contrasted to an approach that would use individual host routes within the basic routing system. Such an approach would create state on a huge number of routers around the network. In Mobile IPv6, only the home agent and the communicating nodes need to create state.
モバイルIPv6の場合は、エンド・ツー・エンド原理は、主にホームエージェントにモビリティ関連状態を制限することによって適用されます。ルート最適化が使用されている場合はさらに、コレスポンデント・ノードはまた、モバイルノードの現在の気付アドレス、バインディングキャッシュに関連するソフト状態を維持します。これは、基本的なルーティングシステム内の個々のホストルートを使用するアプローチと対比させることができます。このようなアプローチは、ネットワーク周りのルータの膨大な数に状態を作成します。モバイルIPv6では、ホームエージェントと通信ノードのみが状態を作成する必要があります。
In the Mobile IPv6 security design, different approaches were chosen for securing the communication between the mobile node and its home agent and between the mobile node and its correspondent nodes. In the home agent case, it was assumed that the mobile node and the home agent know each other through a prior arrangement, e.g., due to a business relationship. In contrast, it was strictly assumed that the mobile node and the correspondent node do not need to have any prior arrangement, thereby allowing Mobile IPv6 to function in a scalable manner, without requiring any configuration at the correspondent nodes.
モバイルIPv6のセキュリティ設計では、異なるアプローチは、モバイルノードとホームエージェントとの間で、モバイルノードとコレスポンデントノードとの間の通信を確保するために選択しました。ホームエージェントの場合には、モバイルノードとホームエージェントが原因ビジネス関係を、例えば、事前の取り決めを介してお互いを知っていると仮定しました。対照的に、それが厳密にモバイルノードとコレスポンデントノードは、コレスポンデント・ノードにおける任意の構成を必要とせず、それによって、モバイルIPv6は、スケーラブルな方法で機能することを可能にする、任意の事前構成を有する必要はないと仮定しました。
As a security goal, Mobile IPv6 design aimed to be "as secure as the (non-mobile) IPv4 Internet" was at the time of the design, in the period 2001 - 2002. In particular, that means that there is little protection against attackers that are able to attach themselves between a correspondent node and a home agent. The rationale is simple: in the 2001 Internet, if a node was able to attach itself to the communication path between two arbitrary nodes, it was able to disrupt, modify, and eavesdrop all the traffic between the two nodes, unless IPsec protection was used. Even when IPsec was used, the attacker was still able to block communication selectively by simply dropping the packets. The attacker in control of a router between the two nodes could also mount a flooding attack by redirecting the data flows between the two nodes (or, more practically, an equivalent flow of bogus data) to a third party.
セキュリティの目標としては、期間2001年には、設計時にあった「（非モバイル）IPv4インターネットがほど安全」であることを目的としたモバイルIPv6の設計 - 特に2002年は、それはに対して少し保護があることを意味しますコレスポンデントノードとホームエージェントとの間で自分自身を添付することができます攻撃。理論的根拠は単純である：ノードは、任意の二つのノード間の通信経路に自分自身を添付することができた場合に2001インターネットでは、IPsec保護を使用した場合を除き、破壊、変更、および2つのノード間のすべてのトラフィックを盗聴することができました。 IPsecを使用した場合でも、攻撃者は、依然として、単にパケットをドロップすることによって選択的に通信をブロックすることができました。また、データをリダイレクトすることによって、フラッディング攻撃を仕掛けることができ、2つのノード間のルータの制御に攻撃者は、第三者への2つのノード（または、より具体的には、偽のデータの同等の流れ）との間を流れます。
Taking a more abstract angle, IPv6 mobility can be defined as a mechanism for managing local exceptions to routing information in order to direct packets that are sent to one address (the home address) to another address (the care-of address). It is managing in the sense that the local routing exceptions (source routes) are created and deleted dynamically, according to instructions sent by the mobile node. It is local in the sense that the routing exceptions are valid only at the home agent, and in the correspondent nodes if route optimization is used. The created pieces of state are exceptions in the sense that they override the normal topological routing information carried collectively by the routers.
より抽象的な角度を取って、IPv6のモビリティは、別のアドレス（気付アドレス）に一つのアドレス（ホームアドレス）に送信されたパケットを送信するために、ルーティング情報にローカルの例外を管理するためのメカニズムとして定義することができます。これは、モバイルノードによって送信された指示に従って、ローカルルーティング例外（ソースルート）が作成され、動的に削除されるという意味で管理されています。これは、経路最適化が使用されている場合、ルーティング例外は唯一のホームエージェントであり、通信相手ノードに有効であることを意味してローカルです。状態の作成された作品は、それらがルータによってまとめ実施通常トポロジーのルーティング情報を上書きするという意味で例外です。
Using the terminology introduced by J. Noel Chiappa [14], we can say that the home address functions in the dual role of being an end-point identifier (EID) and a permanent locator. The care-of address is a pure, temporary locator, which identifies the current location of the mobile node. The correspondent nodes effectively perform source routing, redirecting traffic destined to the home address to the care-of address. This is even reflected in the packet structure: the packets carry an explicit routing header.
J.クリスマスChiappa [14]によって導入された用語を使用して、我々は、エンドポイント識別子（EID）と永久ロケータであることの二重の役割におけるホームアドレス関数と言うことができます。気付アドレスは、移動ノードの現在位置を特定し、純粋な、一時的なロケータです。コレスポンデント・ノードは、効果的に気付アドレスにホームアドレス宛てのトラフィックをリダイレクトし、ソースルーティングを行います。これはさえパケット構造に反映される：パケットが明示的ルーティングヘッダを運びます。
The relationship between EIDs and permanent locators has been exploited by other proposals. Their technical merits and security problems, however, are beyond the scope of this document.
EIDと永久ロケータとの間の関係は、他の提案により利用されてきました。彼らの技術的なメリットとセキュリティの問題は、しかし、このドキュメントの範囲を超えています。
From the discussion above, it should now be clear that the dangers that Mobile IPv6 must protect from lie in creation (or deletion) of the local routing exceptions. In Mobile IPv6 terms, the danger is in the possibility of unauthorized creation of Binding Cache Entries (BCE). The effects of an attack differ depending on the target of the attack, the timing of the attack, and the location of the attacker.
上記の議論から、それは今ローカルルーティング例外のモバイルIPv6が作成（または削除）に嘘から保護しなければならないことの危険ことは明らかです。モバイルIPv6の用語では、危険がキャッシュエントリ（BCE）バインディングの不正創造の可能性です。攻撃の影響は、攻撃、攻撃のタイミング、および攻撃者の位置の目標に応じて異なります。
Basically, the target of an attack can be any node or network in the Internet (stationary or mobile). The basic differences lie in the goals of the attack: does the attacker aim to divert (steal) the traffic destined to and/or sourced at the target node, or does it aim to cause denial-of-service to the target node or network? The target does not typically play much of an active role attack. As an example, an attacker may launch a denial-of-service attack on a given node, A, by contacting a large number of nodes, claiming to be A, and subsequently diverting the traffic at these other nodes so that A is no longer able to receive packets from those nodes. A itself need not be involved at all before its communications start to break. Furthermore, A is not necessarily a mobile node; it may well be stationary.
基本的に、攻撃のターゲットは、インターネット内の任意のノードまたはネットワーク（固定又は移動）とすることができます。攻撃者は、トラフィックが宛ておよび/またはターゲット・ノードで調達（盗む）流用することを目指しない、またはそれは、ターゲット・ノードまたはネットワークへのサービス拒否を引き起こすことを目指しん：基本的な違いは、攻撃の目標にあります？ターゲットは、一般的に積極的な役割攻撃の多くを再生できません。一例として、攻撃者は、多数のノードと接触Aであると主張し、続いてAがもはやなるように、これらの他のノードでトラフィックを迂回しないことにより、特定のノード、A上のサービス拒否攻撃を仕掛けることができますこれらのノードからのパケットを受信できます。自体は、その通信が中断を開始する前に、すべての関与する必要はありません。また、Aは、モバイルノードは必ずしもありません。それも静止していてもよいです。
Mobile IPv6 uses the same class of IP addresses for both mobile nodes (i.e., home and care-of addresses) and stationary nodes. That is, mobile and stationary addresses are indistinguishable from each other. Attackers can take advantage of this by taking any IP address and using it in a context where, normally, only mobile (home or care-of) addresses appear. This means that attacks that otherwise would only concern mobile nodes are, in fact, a threat to all IPv6 nodes.
モバイルIPv6は、IPの同じクラスは、モバイルノード（すなわち、家庭及び気付アドレス）と固定ノードの両方のアドレスが使用されます。すなわち、モバイル及び固定アドレスは互いに区別できません。攻撃者は、通常、唯一のモバイル（自宅や気付）アドレスが表示されるコンテキストで任意のIPアドレスを取得し、それを使って、この利点を取ることができます。これは、そうでない場合のみ、モバイルノードに関係するであろうと攻撃は、実際には、すべてのIPv6ノードへの脅威であることを意味します。
In fact, a mobile node appears to be best protected, since a mobile node does not need to maintain state about the whereabouts of some remote nodes. Conversely, the role of being a correspondent node appears to be the weakest, since there are very few assumptions upon which it can base its state formation. That is, an attacker has a much easier task in fooling a correspondent node to believe that a presumably mobile node is somewhere it is not, than in fooling a mobile node itself into believing something similar. On the other hand, since it is possible to attack a node indirectly by first targeting its peers, all nodes are equally vulnerable in some sense. Furthermore, a (usually) mobile node often also plays the role of being a correspondent node, since it can exchange packets with other mobile nodes (see also Section 5.4).
モバイルノードは、いくつかのリモート・ノードの所在についての状態を維持する必要はありませんので、実際には、モバイルノードは、最高の保護されて表示されます。それは、その状態の形成を基礎とすることができ、その上に非常にいくつかの仮定があるので逆に、コレスポンデントノードであることの役割は、最も弱いように見えます。これは、攻撃者は、おそらく、モバイルノードは、同様の何かを信じるように、モバイルノード自身をだましよりも、それはないどこかにあると信じて、コレスポンデントノードをだますにははるかに簡単にタスクを持っている、です。それは最初にそのピアを標的とすることによって、間接的にノードを攻撃することが可能であるので一方、全てのノードは、ある意味で同等に脆弱です。それは他のモバイルノード（セクション5.4を参照）でパケットを交換することができますので、（通常は）モバイルノードは、多くの場合も、コレスポンデントノードであることの役割を果たしています。
An important aspect in understanding Mobile IPv6-related dangers is timing. In a stationary IPv4 network, an attacker must be between the communication nodes at the same time as the nodes communicate. With the Mobile IPv6 ability of creating binding cache entries, the situation changes. A new danger is created. Without proper protection, an attacker could attach itself between the home agent and a correspondent node for a while, create a BCE at the correspondent node, leave the position, and continuously update the correspondent node about the mobile node's whereabouts. This would make the correspondent node send packets destined to the mobile node to an incorrect address as long as the BCE remained valid, i.e., typically until the correspondent node is rebooted. The converse would also be possible: an attacker could also launch an attack by first creating a BCE and then letting it expire at a carefully selected time. If a large number of active BCEs carrying large amounts of traffic expired at the same time, the result might be an overload towards the home agent or the home network. (See Section 3.2.2 for a more detailed explanation.)
理解モバイルIPv6関連の危険性における重要な側面はタイミングです。固定IPv4ネットワークでは、攻撃者は、ノードが通信と同時に通信ノードとの間でなければなりません。バインディングキャッシュエントリを作成するのモバイルIPv6機能により、状況が変化します。新しい危険が作成されます。適切な保護がなければ、攻撃者は、しばらくの間、ホームエージェントとコレスポンデントノードとの間で自分自身を添付することができ、通信相手ノードでBCEを作成し、位置を離れ、そして継続的にモバイルノードの所在についての対応ノードを更新します。これは、BCEが有効に残ってコレスポンデントノードは、コレスポンデントノードが再起動される一般的になるまで、すなわち、限り誤ったアドレスにモバイルノード宛のパケットを送信するだろう。逆も可能である：攻撃者はまた、最初のBCEを作成し、それを慎重に選択した時間に失効させることで攻撃を仕掛けることができます。大量のトラフィックを運ぶアクティブBCEsの多数が同時に満了した場合、その結果は、ホームエージェントへの過負荷やホームネットワークであるかもしれません。 （より詳細な説明については、3.2.2項を参照してください。）
In a static IPv4 Internet, an attacker can only receive packets destined to a given address if it is able to attach itself to, or to control, a node on the topological path between the sender and the recipient. On the other hand, an attacker can easily send spoofed packets from almost anywhere. If Mobile IPv6 allowed sending unprotected Binding Updates, an attacker could create a BCE on any correspondent node from anywhere in the Internet, simply by sending a fraudulent Binding Update to the correspondent node. Instead of being required to be between the two target nodes, the attacker could act from anywhere in the Internet.
送信者と受信者との間のトポロジー経路上、ノードに自分自身を添付したり、制御することが可能である場合は、静的IPv4インターネットでは、攻撃者は、指定されたアドレス宛てのパケットを受信することができます。一方、攻撃者が簡単にほとんどどこから偽装されたパケットを送信することができます。モバイルIPv6は、保護されていないバインディングアップデートを送信する許可された場合、攻撃者は、単に相手ノードに不正バインディングアップデートを送信することにより、どこでもインターネットからでも相手ノードのBCEを作成することができます。代わりに、2つのターゲットノードの間であることが要求されているのは、攻撃者がどこでもインターネットでから行動することができます。
In summary, by introducing the new routing exception (binding cache) at the correspondent nodes, Mobile IPv6 introduces the dangers of time and space shifting. Without proper protection, Mobile IPv6 would allow an attacker to act from anywhere in the Internet and well before the time of the actual attack. In contrast, in the static IPv4 Internet, the attacking nodes must be present at the time of the attack and they must be positioned in a suitable way, or the attack would not be possible in the first place.
要約すると、コレスポンデントノードに新しいルーティング例外（バインディングキャッシュ）を導入することにより、モバイルIPv6は、時間と空間シフトの危険性を導入します。適切な保護がなければ、モバイルIPv6は、攻撃者が実際の攻撃の時間の前にどこかインターネットでよくから行動することが可能になります。これとは対照的に、静的IPv4インターネットで、攻撃ノードが攻撃の時点で存在している必要があり、彼らは適切な方法で配置されなければならない、または攻撃が最初の場所では不可能であろう。
This section describes attacks against Mobile IPv6 Route Optimization and what protection mechanisms Mobile IPv6 applies against them. The goal of the attacker can be to corrupt the correspondent node's binding cache and to cause packets to be delivered to a wrong address. This can compromise secrecy and integrity of communication and cause denial-of-service (DoS) both at the communicating parties and at the address that receives the unwanted packets. The attacker may also exploit features of the Binding Update (BU) mechanism to exhaust the resources of the mobile node, the home agent, or the correspondent nodes. The aim of this section is to provide an overview of the various protocol mechanisms and their limitations. The details of the mechanisms are covered in Section 4.
このセクションでは、モバイルIPv6ルート最適化に対する攻撃を説明し、モバイルIPv6はそれらに対して適用されるものを保護メカニズム。攻撃者の目的は、破損している相手ノードのバインディングキャッシュにすることができ、パケットが間違ったアドレスに配信させるように。これは、通信の秘匿性と完全性を危うくし、通信相手で、不要なパケットを受信したアドレスの両方のサービス拒否（DoS）を引き起こす可能性があります。また、攻撃者は、モバイル・ノード、ホーム・エージェント、又はコレスポンデントノードからリソースを排出するバインディング更新（BU）機構の機能を利用することができます。このセクションの目的は、様々なプロトコルメカニズムとその限界の概要を提供することです。メカニズムの詳細については、セクション4で覆われています。
It is essential to understand that some of the threats are more serious than others, that some can be mitigated but not removed, that some threats may represent acceptable risk, and that some threats may be considered too expensive to the attacker to be worth preventing.
いくつかが緩和さが、除去されていない、いくつかの脅威が許容できるリスクを表すことができること、およびいくつかの脅威が阻止価値があると、攻撃者に高価すぎると考えることができることをすることができ、脅威のいくつかは他よりも深刻であることを理解することが不可欠です。
We consider only active attackers. The rationale behind this is that in order to corrupt the binding cache, the attacker must sooner or later send one or more messages. Thus, it makes little sense to consider attackers that only observe messages but do not send any. In fact, some active attacks are easier, for the average attacker, to launch than a passive one would be. That is, in many active attacks the attacker can initiate binding update processing at any time, while most passive attacks require the attacker to wait for suitable messages to be sent by the target nodes.
私たちは、アクティブな攻撃を検討してください。この背後にある論理的根拠が壊れバインディングキャッシュするためには、攻撃者は遅かれ早かれ、1つまたは複数のメッセージを送信しなければならないということです。したがって、それはメッセージのみを観察するが、いずれも送信しない攻撃を考慮することはほとんど意味があります。実際には、いくつかのアクティブな攻撃は次のようになり、パッシブ1よりも起動するように、平均的な攻撃のために、簡単です。ほとんどの受動的攻撃がターゲットノードによって送信される適切なメッセージを待つために、攻撃者を必要としながら、すなわち、多くの活発な攻撃では、攻撃者は、いつでもバインディング更新処理を開始することができるされています。
Nevertheless, an important class of passive attacks remains: attacks on privacy. It is well known that simply by examining packets, eavesdroppers can track the movements of individual nodes (and potentially, users) [3]. Mobile IPv6 exacerbates the problem by adding more potentially sensitive information into the packets (e.g., Binding Updates, routing headers or home address options). This document does not address these attacks.
それにも関わらず、受動的攻撃の重要なクラスは残る：プライバシーへの攻撃を。ウェルの[3]、単にパケットを調べることによって、盗聴者は、個々のノード（及び潜在的に、ユーザ）の動きを追跡することができることが知られています。モバイルIPv6は、パケット（例えば、結合更新、ルーティングヘッダ又はホームアドレスオプション）に、より潜在的な機密情報を追加することによって問題を悪化させます。この文書では、これらの攻撃には対処できません。
We first consider attacks against nodes that are supposed to have a specified address (Section 3.1), continuing with flooding attacks (Section 3.2) and attacks against the basic Binding Update protocol (Section 3.3). After that, we present a classification of the attacks (Section 3.4). Finally, we consider the applicability of solutions relying on some kind of a global security infrastructure (Section 3.5).
我々は最初のフラッド攻撃（3.2節）と基本的なバインディングアップデートプロトコル（3.3節）に対する攻撃を続け、指定されたアドレス（3.1節）を持っていることになっているノードに対する攻撃を検討してください。その後、我々は攻撃（3.4節）の分類を提示します。最後に、私たちは、グローバルなセキュリティインフラストラクチャ（3.5節）のいくつかの種類に依存するソリューションの適用可能性を検討してください。
The most obvious danger in Mobile IPv6 is address "stealing", when an attacker illegitimately claims to be a given node at a given address and tries to "steal" traffic destined to that address. We first describe the basic variant of this attack, follow with a description of how the situation is affected if the target is a stationary node, and continue with more complicated issues related to timing (so called "future" attacks), confidentiality and integrity, and DoS aspects.
モバイルIPv6における最も明白な危険性は、攻撃者が不正に指定されたアドレスの指定されたノードであることを主張し、そのアドレス宛てのトラフィックを「盗む」しようとすると、「盗む」のアドレスです。私たちはまず、この攻撃の基本的な変種を記述する状況は、ターゲットが静止ノードであればどのように影響されるかの説明を、以下、より複雑なタイミングに関連する問題（いわゆる「未来」の攻撃）、機密性と完全性を継続しますそして、のDoS側面。
If Binding Updates were not authenticated at all, an attacker could fabricate and send spoofed binding updates from anywhere in the Internet. All nodes that support the correspondent node functionality would become unwitting accomplices to this attack. As explained in Section 2.1, there is no way of telling which addresses belong to mobile nodes that really could send binding updates and which addresses belong to stationary nodes (see below), so potentially any node (including "static" nodes) is vulnerable.
バインディングアップデートが全く認証されなかった場合、攻撃者が製造し、どこでもインターネットでからスプーフィングされたバインディングアップデートを送信することができます。コレスポンデントノード機能をサポートするすべてのノードは、この攻撃に知らず知らずの共犯になります。セクション2.1で説明したように、そう潜在的に（「静的」ノードを含む）任意のノードが脆弱である（下記参照）、実際にバインディング更新を送ることができ、固定ノードに属するアドレスどの移動ノードに属するアドレスを伝える方法はありません。
+---+ original +---+ new packet +---+
| B |<----------------| A |- - - - - - ->| C |
+---+ packet flow +---+ flow +---+
^
|
| False BU: B -> C
|
+----------+
| Attacker |
+----------+
Figure 2. Basic Address Stealing
図2.基本アドレス窃盗
Consider an IP node, A, sending IP packets to another IP node, B. The attacker could redirect the packets to an arbitrary address, C, by sending a Binding Update to A. The home address (HoA) in the binding update would be B and the care-of address (CoA) would be C. After receiving this binding update, A would send all packets intended for the node B to the address C. See Figure 2.
IPノードを考慮し、Aは、別のIPノードにIPパケットを送信し、B.、攻撃者が任意のアドレスにパケットをリダイレクトすることができ、Cは、バインディングアップデートでAにホームアドレス（HoA）を結合更新を送信することによってであろうBと気付アドレス（CoA）は、このバインディングアップデートを受信した後C.なり、AはアドレスC.参照。図2に、ノードBのために意図されるすべてのパケットを送信することになります。
The attacker might select the care-of address to be either its own current address, another address in its local network, or any other IP address. If the attacker selected a local care-of address allowing it to receive the packets, it would be able to send replies to the correspondent node. Ingress filtering at the attacker's local+ network does not prevent the spoofing of Binding Updates but forces the attacker either to choose a care-of address from inside its own network or to use the Alternate care-of address sub-option.
攻撃者は、自身の現在のアドレス、そのローカルネットワーク内の別のアドレス、または任意の他のIPアドレスのいずれかであることを気付アドレスを選択できます。攻撃者がローカル気付けそれがパケットを受信できるようにアドレスを選択した場合は、コレスポンデントノードへの応答を送信することができるだろう。攻撃者のローカル+ネットワークのイングレスフィルタリングは、独自のネットワーク内部からの気付アドレスを選択するか、代替気付アドレスのサブオプションを使用するかバインディングアップデートのなりすましを防ぐことが、攻撃者が強制的にしません。
The binding update authorization mechanism used in the MIPv6 security design is primarily intended to mitigate this threat, and to limit the location of attackers to the path between a correspondent node and the home agent.
MIPv6のセキュリティ設計で使用されるバインディング更新の認証メカニズムは、主にこの脅威を軽減するために、およびコレスポンデントノードとホームエージェントとの間のパスに攻撃者の位置を限定することを意図しています。
The attacker needs to know or guess the IP addresses of both the source of the packets to be diverted (A in the example above) and the destination of the packets (B, above). This means that it is difficult to redirect all packets to or from a specific node because the attacker would need to know the IP addresses of all the nodes with which it is communicating.
攻撃者が流用されるパケットのソース（上記の例ではA）と（上記B）のパケットの宛先の両方のIPアドレスを知っているか、または推測する必要があります。攻撃者は、それが通信している全てのノードのIPアドレスを知っている必要があるために、または特定のノードからのすべてのパケットをリダイレクトすることが困難であることを意味します。
Nodes with well-known addresses, such as servers and those using stateful configuration, are most vulnerable. Nodes that are a part of the network infrastructure, such as DNS servers, are particularly interesting targets for attackers and particularly easy to identify.
サーバなどのよく知られたアドレス、およびそれらの使用ステートフル設定を持つノードは、最も脆弱です。そのようなDNSサーバなどのネットワークインフラストラクチャの一部であるノードは、攻撃者にとって特に興味深いターゲットと識別することが特に容易です。
Nodes that frequently change their address and use random addresses are relatively safe. However, if they register their address into Dynamic DNS, they become more exposed. Similarly, nodes that visit publicly accessible networks such as airport wireless LANs risk revealing their addresses. IPv6 addressing privacy features [3] mitigate these risks to an extent, but note that addresses cannot be completely recycled while there are still open sessions that use those addresses.
頻繁に彼らのアドレスを変更し、ランダムなアドレスを使用するノードは比較的安全です。彼らは、ダイナミックDNSに自分のアドレスを登録する場合は、彼らがより多くの露出になります。同様に、それらのアドレスを明らかにAirMacワイヤレスLANのリスクとして公にアクセス可能なネットワークを訪問したノード。 IPv6は、プライバシー機能に対処[3]程度のこれらのリスクを軽減するが、これらのアドレスを使用して開いているセッションが残っている間、アドレスは完全にリサイクルすることができないことに注意してください。
Thus, it is not the mobile nodes that are most vulnerable to address stealing attacks; it is the well-known static servers. Furthermore, the servers often run old or heavily optimized operating systems and may not have any mobility related code at all. Thus, the security design cannot be based on the idea that mobile nodes might somehow be able to detect whether someone has stolen their address, and reset the state at the correspondent node. Instead, the security design must make reasonable measures to prevent the creation of fraudulent binding cache entries in the first place.
したがって、アドレス盗む攻撃に最も脆弱であるモバイルノードではありません。それは、よく知られた静的なサーバです。さらに、サーバは、多くの場合、古いまたは重く最適化されたオペレーティングシステムを実行し、まったくのモビリティ関連のコードを持っていないかもしれません。このように、セキュリティ設計は、モバイルノードが何らかの形で誰かが自分のアドレスを盗まれた、とコレスポンデントノードの状態をリセットしているかどうかを検出することができるかもしれないという考えに基づいてすることはできません。代わりに、セキュリティ設計は、最初の場所で不正バインディングキャッシュエントリの作成を防止するための合理的な措置をしなければなりません。
If an attacker knows an address that a node is likely to select in the future, it can launch a "future" address stealing attack. The attacker creates a Binding Cache Entry with the home address that it anticipates the target node will use. If the Home Agent allows dynamic home addresses, the attacker may be able to do this legitimately. That is, if the attacker is a client of the Home Agent and is able to acquire the home address temporarily, it may be able to do so and then to return the home address to the Home Agent once the BCE is in place.
攻撃者は、ノードが、将来的に選択する可能性があるアドレスを知っている場合、それは攻撃を盗む「未来」のアドレスを起動することができます。攻撃者は、ターゲット・ノードが使用する予想していたホームアドレスとバインディングキャッシュエントリが作成されます。ホームエージェントは、動的ホームアドレスを許可している場合、攻撃者が合法的にこれを行うことができるかもしれません。これは、攻撃者がホームエージェントのクライアントであり、一時的にホームアドレスを取得することができるならば、BCEが配置されたら、ホームエージェントにホームアドレスを返すためにそうしてから行うことができるかもしれません、です。
Now, if the BCE state had a long expiration time, the target node would acquire the same home address while the BCE is still effective, and the attacker would be able to launch a successful man-in-the-middle or denial-of-service attack. The mechanism applied in the MIPv6 security design is to limit the lifetime of Binding Cache Entries to a few minutes.
BCE状態が長い有効期限を持っている場合今、BCEは依然として有効であるが、ターゲットノードが同じホームアドレスを買収する、と攻撃者が成功のman-in-the-middleまたは拒否オブを起動することができるだろうサービス攻撃。 MIPv6のセキュリティ設計に適用されるメカニズムは、数分にキャッシュエントリをバインドの寿命を制限することです。
Note that this attack applies only to fairly specific conditions. There are also some variations of this attack that are theoretically possible under some other conditions. However, all of these attacks are limited by the Binding Cache Entry lifetime, and therefore they are not a real concern with the current design.
この攻撃は唯一のかなり特定の条件に適用されることに注意してください。他のいくつかの条件の下で理論的には可能であり、この攻撃のいくつかのバリエーションがあります。しかし、これらの攻撃のすべてのバインディングキャッシュエントリの有効期間によって制限されているので、彼らは、現在のデザインと現実的な懸念ではありません。
By spoofing Binding Updates, an attacker could redirect all packets between two IP nodes to itself. By sending a spoofed binding update to A, it could capture the data intended to B. That is, it could pretend to be B and highjack A's connections with B, or it could establish new spoofed connections. The attacker could also send spoofed binding updates to both A and B and insert itself in the middle of all connections between them (man-in-the-middle attack). Consequently, the attacker would be able to see and modify the packets sent between A and B. See Figure 3.
結合更新をスプーフィングすることにより、攻撃者は自身に2つのIPノード間のすべてのパケットをリダイレクトすることができました。 Aに偽装されたバインディングアップデートを送信することにより、それは、それはBのふりをし、BとAの接続をハイジャックできているBに意図されたデータを取り込むことができ、またはそれは、新たな偽装された接続を確立することができます。攻撃者はまた、AとBの両方に偽装されたバインディング更新を送信し、それらの間のすべての接続の真ん中に自分自身を挿入することができ（man-in-the-middle攻撃）。これにより、攻撃者はAとB図3を参照の間に送信されたパケットを参照し、変更することができるであろう。
Original data path, before man-in-the-middle attack
man-in-the-middle攻撃の前に、元のデータ・パス、
+---+ +---+
| A | | B |
+---+ +---+
\___________________________________/
Modified data path, after the falsified binding updates
偽造バインディングアップデート後に、データ・パスを修正
+---+ +---+
| A | | B |
+---+ +---+
\ /
\ /
\ +----------+ /
\---------| Attacker |-------/
+----------+
Figure 3. Man-in-the-Middle Attack
図3. man-in-the-middle攻撃
Strong end-to-end encryption and integrity protection, such as authenticated IPsec, can prevent all the attacks against data secrecy and integrity. When the data is cryptographically protected, spoofed binding updates could result in denial of service (see below) but not in disclosure or corruption of sensitive data beyond revealing the existence of the traffic flows. Two fixed nodes could also protect communication between themselves by refusing to accept binding updates from each other. Ingress filtering, on the other hand, does not help, as the attacker is using its own address as the care-of address and is not spoofing source IP addresses.
な認証されたIPSecなど、強力なエンドツーエンドの暗号化と整合性の保護、データの機密性と完全性に対するすべての攻撃を防ぐことができます。データが暗号で保護されている場合、バインディング更新はトラフィックフローの存在を明らかに超えた機密データの開示や破損にサービス拒否が発生する（下記参照）が、できなかった、スプーフィングされました。 2つの固定ノードは互いに結合更新を受け入れることを拒否することによって自分自身との間の通信を保護することができます。イングレスフィルタリングは、他の一方で、攻撃者が気付けアドレスとして自身のアドレスを使用しており、送信元IPアドレスを偽装されていないとして、役に立ちません。
The protection adopted in MIPv6 Security Design is to authenticate (albeit weakly) the addresses by return routability (RR), which limits the topological locations from which the attack is possible (see Section 4.1).
MIPv6のセキュリティ設計で採用されている保護は（弱いながらも）攻撃が可能であるから、トポロジカルな場所を制限し、リターン・ルータビリティ（RR）によるアドレスを認証することである（4.1節を参照してください）。
By sending spoofed binding updates, the attacker could redirect all packets sent between two IP nodes to a random or nonexistent address (or addresses). As a result, it might be able to stop or disrupt communication between the nodes. This attack is serious because any Internet node could be targeted, including fixed nodes belonging to the infrastructure (e.g., DNS servers) that are also vulnerable. Again, the selected protection mechanism is return routability (RR).
スプーフィングされたバインディング更新を送信することによって、攻撃者は、ランダムまたは存在しないアドレス（またはアドレス）に2つのIPノード間で送信されるすべてのパケットをリダイレクトすることができました。その結果、ノード間の通信を停止または破壊することができるかもしれません。任意のインターネットノードは、インフラストラクチャに属する固定ノードを含む、標的にされる可能性があるため、この攻撃は深刻である（例えば、DNSサーバ）も脆弱です。再び、選択された保護メカニズムは、リターンルータビリティ（RR）です。
Any protocol for authenticating binding updates has to consider replay attacks. That is, an attacker may be able to replay recently authenticated binding updates to the correspondent and, consequently, to direct packets to the mobile node's previous location. As with spoofed binding updates, this could be used both for capturing packets and for DoS. The attacker could capture the packets and impersonate the mobile node if it reserved the mobile's previous address after the mobile node has moved away and then replayed the previous binding update to redirect packets back to the previous location.
バインディング更新を認証するための任意のプロトコルは、リプレイ攻撃を考慮しなければなりません。つまり、攻撃者がモバイルノードの以前の場所にパケットを向けるために、結果として、対応する最近認証されたバインディング更新を再生とすることができる場合があります。スプーフィングされたバインディング更新と同様に、これは、パケットをキャプチャするためとDOSの両方に使用することができます。攻撃者は、パケットをキャプチャし、モバイルノードが離れて移動した後、バック前位置にパケットをリダイレクトするために、以前のバインディング更新を再生した後、それは移動局の前のアドレスを予約している場合、モバイルノードになりすます可能性があります。
In a related attack, the attacker blocks binding updates from the mobile at its new location, e.g., by jamming the radio link or by mounting a flooding attack. The attacker then takes over the mobile's connections at the old location. The attacker will be able to capture the packets sent to the mobile and to impersonate the mobile until the correspondent's Binding Cache entry expires.
関連する攻撃では、攻撃者ブロックがその新しい位置で、例えば、無線リンクを妨害することによって、またはフラッディング攻撃を搭載することにより、モバイルからの更新を結合。その後、攻撃者は、古い場所でのモバイルの接続を引き継ぎます。攻撃者がモバイルに送信されたパケットをキャプチャし、特派の結合キャッシュ項目の有効期限が切れるまで、モバイルを偽装することができるようになります。
Both of the above attacks require that the attacker be on the same local network with the mobile, where it can relatively easily observe packets and block them even if the mobile does not move to a new location. Therefore, we believe that these attacks are not as serious as ones that can be mounted from remote locations. The limited lifetime of the Binding Cache entry and the associated nonces limit the time frame within which the replay attacks are possible. Replay protection is provided by the sequence number and MAC in the Binding Update. To not undermine this protection, correspondent nodes must exercise care upon deleting a binding cache entry, as per section 5.2.8 ("Preventing Replay Attacks") in [6].
上記の攻撃の両方が攻撃者は、それが比較的容易にパケットを観察し、モバイルが新しい場所に移動していない場合でも、それらをブロックすることができ、モバイル、同じローカルネットワーク上にあることが必要です。したがって、我々はこれらの攻撃は、遠隔地からマウントすることが可能なものほど深刻ではないと考えています。バインディングキャッシュエントリと関連付けられた一回だけの限られた寿命は、リプレイ攻撃が可能な範囲内の時間枠を制限します。リプレイ保護は、結合更新のシーケンス番号とMACによって提供されます。この保護を弱体化しないように、通信員ノードは、セクション5.2.8、[6]に（「リプレイ攻撃の防止」）ごとに、バインディングキャッシュエントリを削除するときに注意しなければなりません。
By sending spoofed binding updates, an attacker could redirect traffic to an arbitrary IP address. This could be used to overload an arbitrary Internet address with an excessive volume of packets (known as a 'bombing attack'). The attacker could also target a network by redirecting data to one or more IP addresses within the network. There are two main variations of flooding: basic flooding and return-to-home flooding. We consider them separately.
偽装されたバインディングアップデートを送信することにより、攻撃者は任意のIPアドレスへのトラフィックをリダイレクトすることができます。これは（「爆撃攻撃」として知られている）パケットの過剰量で任意のインターネットアドレスをオーバーロードするために使用することができます。攻撃者は、ネットワーク内の1つまたは複数のIPアドレスにデータをリダイレクトすることでネットワークをターゲットにすることができます。基本的な洪水やリターンツーホーム洪水：洪水には主に2つのバリエーションがあります。私たちは、それらを別々に検討します。
In the simplest attack, the attacker knows that there is a heavy data stream from node A to B and redirects this to the target address C. However, A would soon stop sending the data because it is not receiving acknowledgements from B.
最も単純な攻撃では、攻撃者がBにノードAから大量のデータ・ストリームがあることを知っていて、AはすぐにそれがBからの確認応答を受信していないので、データの送信を停止する。しかし、ターゲットアドレスCにこれをリダイレクト
(B is attacker)
（Bは、攻撃者です）
+---+ original +---+ flooding packet +---+
| B |<================| A |==================>| C |
+---+ packet flow +---+ flow +---+
| ^
\ /
\__________________/
False binding update + false acknowledgements
Figure 4. Basic Flooding Attack
図4.基本的なフラッディング攻撃
A more sophisticated attacker would act itself as B; see Figure 4. It would first subscribe to a data stream (e.g., a video stream) and redirect this stream to the target address C. The attacker would even be able to spoof the acknowledgements. For example, consider a TCP stream. The attacker would perform the TCP handshake itself and thus know the initial sequence numbers. After redirecting the data to C, the attacker would continue to send spoofed acknowledgements. It would even be able to accelerate the data rate by simulating a fatter pipe [12].
より洗練された攻撃者はBとしての地位を作用するであろう。図4を参照してこれは第1のデータストリーム（例えば、ビデオストリーム）をサブスクライブすると、攻撃者も肯定応答を偽装することができるであろう目標アドレスC.このストリームをリダイレクトすることになります。たとえば、TCPストリームを検討してください。攻撃者は、TCPハンドシェイク自体を行うので、初期シーケンス番号を知っているだろう。 Cにデータをリダイレクトした後、攻撃者が偽装された確認応答を送信し続けます。それも太っ管[12]をシミュレートすることによって、データレートを加速することができるであろう。
This attack might be even easier with UDP/RTP. The attacker could create spoofed RTCP acknowledgements. Either way, the attacker would be able to redirect an increasing stream of unwanted data to the target address without doing much work itself. It could carry on opening more streams and refreshing the Binding Cache entries by sending a new binding update every few minutes. Thus, the limitation of BCE lifetime to a few minutes does not help here without additional measures.
この攻撃は、UDP / RTPでも簡単かもしれません。攻撃者が偽装されたRTCPの確認応答を作成することができます。どちらにしても、攻撃者は多くの作業自体を行わず、ターゲットアドレスに不要なデータの増加ストリームをリダイレクトすることができるだろう。これは、より多くのストリームを開き、新しいバインディング更新に数分おきに送信することにより、結合キャッシュエントリをリフレッシュするに運ぶことができます。このように、数分にBCE寿命の制限は、追加措置なしに、ここでは役立ちません。
During the Mobile IPv6 design process, the effectiveness of this attack was debated. It was mistakenly assumed that the target node would send a TCP Reset to the source of the unwanted data stream, which would then stop sending. In reality, all practical TCP/IP implementations fail to send the Reset. The target node drops the unwanted packets at the IP layer because it does not have a Binding
モバイルIPv6の設計プロセスの間に、この攻撃の有効性が議論されました。これは、誤ってターゲットノードが次に送信停止する不要なデータストリームのソースにTCPリセットを送信するであろうと仮定しました。実際には、すべての実用的なTCP / IPの実装は、リセットを送信するために失敗します。それはバインディングを持っていないため、ターゲットノードはIPレイヤで不要なパケットを廃棄します
Update List entry corresponding to the Routing Header on the incoming packet. Thus, the flooding data is never processed at the TCP layer of the target node, and no Reset is sent. This means that the attack using TCP streams is more effective than was originally believed.
着信パケットのルーティングヘッダに対応するリストのエントリを更新します。したがって、洪水データは、ターゲット・ノードのTCP層で処理されることはありませんし、何のリセットが送信されません。これは、TCPストリームを使った攻撃が最初に信じられていたよりも効果的であることを意味しています。
This attack is serious because the target can be any node or network, not only a mobile one. What makes it particularly serious compared to the other attacks is that the target itself cannot do anything to prevent the attack. For example, it does not help if the target network stops using Route Optimization. The damage is compounded if these techniques are used to amplify the effect of other distributed denial-of-service (DDoS) attacks. Ingress filtering in the attacker's local network prevents the spoofing of source addresses but the attack would still be possible by setting the Alternate care-of address sub-option to the target address.
ターゲットは、任意のノードまたはネットワークだけでなく、モバイルいずれかになりますので、この攻撃は深刻です。他にどのような攻撃に比べて、それは特に深刻になり、ターゲット自体が攻撃を防ぐために何もできないということです。ターゲットネットワークがルート最適化を使用して停止した場合たとえば、それは助けにはなりません。これらの技術は、他の分散型サービス拒否（DDoS）攻撃の効果を増幅するために使用されている場合はダメージが配合されます。攻撃者のローカルネットワーク内のイングレスフィルタリングは、送信元アドレスのスプーフィングを防止するが、攻撃はまだターゲットアドレスへの代替気付アドレスのサブオプションを設定することで可能になります。
Again, the protection mechanism adopted for MIPv6 is return routability. This time it is necessary to check that there is indeed a node at the new care-of address, and that the node is the one that requested redirecting packets to that very address (see Section 4.1.2).
ここでも、MIPv6のために採用した保護メカニズムは、ルータビリティを返すことです。今回はあったノードが新しい気付けアドレスに実際にあり、ノードはその非常にアドレス（4.1.2項を参照）にパケットをリダイレクト要求したものであるとことを確認する必要があります。
A variation of the bombing attack would target the home address or the home network instead of the care-of address or a visited network. The attacker would claim to be a mobile with the home address equal to the target address. While claiming to be away from home, the attacker would start downloading a data stream. The attacker would then send a binding update cancellation (i.e., a request to delete the binding from the Binding Cache) or just allow the cache entry to expire. Either would redirect the data stream to the home network. As when bombing a care-of address, the attacker can keep the stream alive and even increase the data rate by spoofing acknowledgements. When successful, the bombing attack against the home network is just as serious as that against a care-of address.
爆撃攻撃のバリエーションは、自宅の住所またはその代わりに気付アドレスまたは訪問先ネットワークのホームネットワークを標的とします。攻撃者がターゲットアドレスに等しいホームアドレスとモバイルであると主張するでしょう。家から離れてであると主張する一方で、攻撃者は、データ・ストリームのダウンロードを開始します。その後、攻撃者はバインディング更新中止（バインディングキャッシュからバインディングを削除する、すなわち、要求）を送信したり、単にキャッシュエントリが期限切れにできるようになります。どちらかがホームネットワークにデータ・ストリームをリダイレクトします。気付アドレスを爆撃したときのように、攻撃者は生きている流れを維持しても、確認応答を偽装することによって、データレートを上げることができます。成功した場合、ホームネットワークに対する爆撃攻撃は気付アドレスに対するものと同じくらい深刻です。
The basic protection mechanism adopted is return routability. However, it is hard to fully protect against this attack; see Section 4.1.1.
採用した基本的な保護メカニズムはリターンルータビリティです。しかし、完全にこの攻撃を防御するのは難しいです。 4.1.1項を参照してください。
Security protocols that successfully protect the secrecy and integrity of data can sometimes make the participants more vulnerable to denial-of-service attacks. In fact, the stronger the authentication, the easier it may be for an attacker to use the protocol features to exhaust the mobile's or the correspondent's resources.
成功したデータの機密性と完全性を保護するセキュリティプロトコルは、時々、サービス拒否攻撃への参加者はより脆弱にすることができます。実際には、認証が強く、容易にそれはモバイルのか通信員のリソースを排出するために、プロトコルの機能を使用するには、攻撃者のためであってもよいです。
When a mobile node receives an IP packet from a new correspondent via the home agent, it may initiate the binding update protocol. An attacker can exploit this by sending the mobile node a spoofed IP packet (e.g., ping or TCP SYN packet) that appears to come from a new correspondent node. Since the packet arrives via the home agent, the mobile node may start the binding update protocol with the correspondent node. The decision as to whether to initiate the binding update procedure may depend on several factors (including heuristics, cross layer information, and configuration options) and is not specified by Mobile IPv6. Not initiating the binding update procedure automatically may alleviate these attacks, but it will not, in general, prevent them completely.
モバイルノードがホームエージェントを介して新しい通信員からのIPパケットを受信すると、バインディング更新プロトコルを開始することができます。攻撃者は、新しい相手ノードから来るように見えるモバイルノード偽装されたIPパケット（例えば、pingやTCP SYNパケット）を送信することにより、これを利用することができます。パケットは、ホームエージェントを経由して到着したので、モバイルノードは、コレスポンデントノードとのバインディング更新プロトコルを起動することがあります。 （ヒューリスティック、クロスレイヤ情報、およびコンフィギュレーションオプションを含む）いくつかの要因に依存し得るバインディングアップデート手順を開始し、モバイルIPv6によって指定されていないかどうかの決定。ないこれらの攻撃を軽減することが自動的にバインディング更新手順を開始するが、それは、一般的には、それらを完全に防ぐことはできません。
In a real attack the attacker would induce the mobile node to initiate binding update protocols with a large number of correspondent nodes at the same time. If the correspondent addresses are real addresses of existing IP nodes, then most instances of the binding update protocol might even complete successfully. The entries created in the Binding Cache are correct but useless. In this way, the attacker can induce the mobile to execute the binding update protocol unnecessarily, which can drain the mobile's resources.
実際の攻撃では、攻撃者は、同時に対応ノードの数が多いバインディング更新プロトコルを開始するためにモバイルノードを誘導します。特派アドレスは、既存のIPノードの実アドレスである場合、バインディング更新プロトコルのほとんどの場合であっても正常に完了することがあります。バインディングキャッシュに作成されたエントリは正しいが、役に立ちません。この方法では、攻撃者が携帯電話のリソースを排出することができた、不必要にバインディング更新プロトコルを実行するために、モバイルを誘導することができます。
A correspondent node (i.e., any IP node) can also be attacked in a similar way. The attacker sends spoofed IP packets to a large number of mobiles, with the target node's address as the source address. These mobiles will initiate the binding update protocol with the target node. Again, most of the binding update protocol executions will complete successfully. By inducing a large number of unnecessary binding updates, the attacker is able to consume the target node's resources.
コレスポンデントノード（すなわち、任意のIPノード）も同様の方法で攻撃することができます。攻撃者は、送信元アドレスとして、ターゲットノードのアドレスと、移動体の多数に偽装されたIPパケットを送信します。これらの携帯電話は、ターゲット・ノードとのバインディング更新プロトコルを開始します。ここでも、バインディング更新プロトコルの実行のほとんどが正常に完了します。不要なバインディングアップデートの多数を誘導することにより、攻撃者がターゲットノードのリソースを消費することができます。
This attack is possible against any binding update authentication protocol. The more resources the binding update protocol consumes, the more serious the attack. Therefore, strong cryptographic authentication protocol is more vulnerable to the attack than a weak one or unauthenticated binding updates. Ingress filtering helps a little, since it makes it harder to forge the source address of the spoofed packets, but it does not completely eliminate this threat.
この攻撃は、任意のバインディング更新の認証プロトコルに対して可能です。バインディング更新プロトコルが消費するより多くの資源、より深刻な攻撃。したがって、強力な暗号化認証プロトコルは弱い一つまたは認証されていないバインディング更新より攻撃に対してより脆弱です。それはそれは難しい偽装されたパケットの送信元アドレスを偽造することができますので、イングレスフィルタリングは、少しのに役立ちますが、それは完全にこの脅威を排除するものではありません。
A node should protect itself from the attack by setting a limit on the amount of resources (i.e., processing time, memory, and communications bandwidth) that it uses for processing binding updates. When the limit is exceeded, the node can simply stop attempting route optimization. Sometimes it is possible to process some binding updates even when a node is under the attack. A mobile node may have a local security policy listing a limited number of addresses to which binding updates will be sent even when the mobile node is under DoS attack. A correspondent node (i.e., any IP node) may similarly have a local security policy listing a limited set of addresses from which binding updates will be accepted even when the correspondent is under a binding update DoS attack.
ノードは、バインディング更新を処理するために使用するリソースの量（すなわち、処理時間、メモリ、および通信帯域幅）に制限を設定することによって、攻撃から自身を守るべきです。制限を超えると、ノードは、単純にルート最適化を試みて停止することができます。時にはノードが攻撃を受けている場合でも、一部のバインディング更新を処理することが可能です。モバイルノードは、モバイルノードがDoS攻撃を受けているときバインディングアップデートにも送られる先のアドレスの数に制限をリストローカルセキュリティポリシーを有することができます。コレスポンデントノード（すなわち、任意のIPノード）は、同様に対応バインディング更新DoS攻撃下にある場合でも、結合更新は受け入れられるそこからアドレスの限定されたセットをリストローカルセキュリティポリシーを有することができます。
The node may also recognize addresses with it had meaningful communication in the past and only send binding updates to, or accept them from, those addresses. Since it may be impossible for the IP layer to know about the protocol state in higher protocol layers, a good measure of the meaningfulness of the past communication is probably per-address packet counts. Alternatively, Neighbor Discovery [2] (Section 5.1, Conceptual Data Structures) defines the Destination Cache as a set of entries about destinations to which traffic has been sent recently. Thus, implementors may wish to use the information in the Destination Cache.
ノードはまた、過去に有意義なコミュニケーションを持っていただけにバインディング更新を送信することでアドレスを認識し、またはこれらのアドレスから、それらを受け入れることができます。 IP層は上位プロトコル層におけるプロトコルの状態について知ることができないことがありますので、過去の通信の有意味の良い指標は、おそらくアドレス毎のパケット数です。また、近隣探索[2]（セクション5.1、概念データ構造）は、トラフィック最近送られてきたために目的地についてのエントリの集合として宛先キャッシュを定義します。したがって、実装者は、宛先キャッシュ内の情報を使用することを望むかもしれません。
Section 11.7.2 ("Correspondent Registration") in [6] does not specify when such a route optimization procedure should be initiated. It does indicate when it may justifiable to do so, but these hints are not enough. This remains an area where more work is needed. Obviously, given that route optimization is optional, any node that finds the processing load excessive or unjustified may simply turn it off (either selectively or completely).
11.7.2項（「特派登録」）で、このようなルート最適化手順を開始すべきとき[6]指定されていません。それはそうすることを正当化する際には示してないが、これらのヒントは十分ではありません。これは、より多くの作業が必要とされているエリアのまま。明らかに、ルート最適化がオプションであることを考慮すると、過剰な又は不当な処理負荷を検出したノードは、単に、（いずれかの選択的にまたは完全に）それをオフにしてもよいです。
As a variant of the previous attack, the attacker can prevent a correspondent node from using route optimization by filling its Binding Cache with unnecessary entries so that most entries for real mobiles are dropped.
以前の攻撃の変種として、攻撃者は、実際の携帯電話のための最もエントリが廃棄されるように不要なエントリとその結合キャッシュを充填することにより、経路最適化を使用してからの対応ノードを防ぐことができます。
Any successful DoS attack against a mobile or correspondent node can also prevent the processing of binding updates. We have previously suggested that the target of a DoS attack may respond by stopping route optimization for all or some communication. Obviously, an attacker can exploit this fallback mechanism and force the target to use the less efficient home agent-based routing. The attacker only needs to mount a noticeable DoS attack against the mobile or correspondent, and the target will default to non-optimized routing.
モバイルや通信員ノードに対してどれ成功したDoS攻撃は、結合更新の処理を防ぐことができます。我々は以前にDoS攻撃のターゲットはすべて、または一部の通信のための経路最適化を停止することによって応答することができることを示唆しています。明らかに、攻撃者はこのフォールバックメカニズムを活用し、効率の低いホームエージェントベースのルーティングを使用するようにターゲットを強制することができます。攻撃者は、モバイルや特派員に対する顕著なDoS攻撃をマウントする必要があり、ターゲットは、非最適化ルーティングにデフォルト設定されます。
The target node can mitigate the effects of the attack by reserving more space for the Binding Cache, by reverting to non-optimized routing only when it cannot otherwise cope with the DoS attack, by trying aggressively to return to optimized routing, or by favoring mobiles with which it has an established relationship. This attack is not as serious as the ones described earlier, but applications that rely on Route Optimization could still be affected. For instance, conversational multimedia sessions can suffer drastically from the additional delays caused by triangle routing.
ターゲット・ノードは、それがそうでない場合は、最適化ルーティングに戻るには、積極的にしようとすることによって、または有利モバイルによって、DoS攻撃に対応できない場合にのみ、非最適化ルーティングに戻すことで、バインディングキャッシュのためのより多くのスペースを確保することによって、攻撃の影響を軽減することができますそれは、確立された関係を有します。この攻撃は、前述のものほど深刻ではありませんが、ルート最適化に依存するアプリケーションは、依然として影響を受ける可能性があります。例えば、会話のマルチメディアセッションは、三角ルーティングによって引き起こされる追加の遅延から大幅に苦しむことができます。
Attackers sometimes try to hide the source of a packet-flooding attack by reflecting the traffic from other nodes [1]. That is, instead of sending the flood of packets directly to the target, the attacker sends data to other nodes, tricking them to send the same number, or more, packets to the target. Such reflection can hide the attacker's address even when ingress filtering prevents source address spoofing. Reflection is particularly dangerous if the packets can be reflected multiple times, if they can be sent into a looping path, or if the nodes can be tricked into sending many more packets than they receive from the attacker, because such features can be used to amplify the traffic by a significant factor. When designing protocols, one should avoid creating services that can be used for reflection and amplification.
攻撃者は、時々、他のノード[1]からのトラフィックを反射して、パケットフラッディング攻撃のソースを隠そう。それは代わりに、ターゲットに直接パケットの洪水を送信すると、攻撃者がターゲットに同じ番号、またはそれ以上、パケットを送信するためにそれらをだまし、他のノードにデータを送信し、です。このような反射は、イングレスフィルタリングは、送信元アドレスのスプーフィングを防止しても、攻撃者のアドレスを非表示にすることができます。パケットが複数回反射することができれば、それらはループ経路に送信することができれば反射は、特に危険である、またはノードが、より多くのパケットを送信するようにだまさすることができれば、このような特徴を増幅するために使用することができるので、彼らは、攻撃者から受け取るより重要な要因によってトラフィック。プロトコルを設計するとき、1は反射と増幅のために使用することができるサービスを作成することは避けてください。
Triangle routing would easily create opportunities for reflection: a correspondent node receives packets (e.g., TCP SYN) from the mobile node and replies to the home address given by the mobile node in the Home Address Option (HAO). The mobile might not really be a mobile and the home address could actually be the target address. The target would only see the packets sent by the correspondent and could not see the attacker's address (even if ingress filtering prevents the attacker from spoofing its source address).
トライアングルルーティングが簡単に反射の機会を作成します。コレスポンデントノードは、モバイルノードからのパケット（例えば、TCP SYN）を受信し、ホームアドレスオプション（HAO）内のモバイルノードによって与えられたホームアドレスに応答します。モバイルは本当にモバイルではないかもしれませんし、ホームアドレスが実際にターゲットアドレスである可能性があります。ターゲットは通信員によって送信されたパケットを見ることになると（イングレスフィルタリングは、その送信元アドレスを偽装から攻撃を防止しても）、攻撃者のアドレスを見ることができませんでした。
+----------+ TCP SYN with HAO +-----------+
| Attacker |-------------------->| Reflector |
+----------+ +-----------+
|
| TCP SYN-ACK to HoA
V
+-----------+
| Flooding |
| target |
+-----------+
Figure 5. Reflection Attack
図5.リフレクション攻撃
A badly designed binding update protocol could also be used for reflection: the correspondent would respond to a data packet by initiating the binding update authentication protocol, which usually involves sending a packet to the home address. In that case, the reflection attack can be discouraged by copying the mobile's address into the messages sent by the mobile to the correspondent. (The mobile's source address is usually the same as the care-of address, but an Alternative Care-of Address sub-option can specify a different care-of address.) Some of the early proposals for MIPv6 security used this approach and were prone to reflection attacks.
ひどく設計されたバインディング更新プロトコルは、反射のために使用することができます通信員は、通常、ホームアドレスにパケットを送信する必要バインディング更新の認証プロトコルを、開始することによってデータパケットに応答することになります。その場合には、反射攻撃は、特派員に携帯から送信されたメッセージの中に携帯のアドレスをコピーして落胆することができます。 （モバイルの送信元アドレスは、通常、気付アドレスと同じであるが、代替気付アドレスサブオプションは、異なる気付アドレスを指定することができます。）のMIPv6セキュリティのための初期の提案のいくつかは、このアプローチを使用し、がちでした反射攻撃に。
In some of the proposals for binding update authentication protocols, the correspondent node responded to an initial message from the mobile with two packets (one to the home address, one to the care-of address). It would have been possible to use this to amplify a flooding attack by a factor of two. Furthermore, with public-key authentication, the packets sent by the correspondent might have been significantly larger than the one that triggers them.
更新認証プロトコルを結合するための提案のいくつかでは、コレスポンデントノードは、二つのパケット（ホームアドレス、気付アドレスに一から一）で、モバイルからの最初のメッセージに反応しました。 2つの要因によってフラッディング攻撃を増幅するためにこれを使用することも可能だったでしょう。さらに、公開鍵認証で、通信員によって送信されたパケットは、それらをトリガー1よりもかなり大きくなっている可能性があります。
These types of reflection and amplification can be avoided by ensuring that the correspondent only responds to the same address from which it received a packet, and only with a single packet of the same size. These principles have been applied to MIPv6 security design.
反射および増幅のこれらのタイプは、対応のみがパケットを受信し、そして、同じサイズの単一のパケットと、そこから同じアドレスに応答することを保証することによって回避することができます。これらの原則は、MIPv6のセキュリティ設計に適用されています。
Sect. Attack name Target Sev. Mitigation
---------------------------------------------------------------------
3.1.1 Basic address stealing MN Med. RR
3.1.2 Stealing addresses of stationary nodes Any High RR
3.1.3 Future address stealing MN Low RR, lifetime
3.1.4 Attacks against secrecy and integrity MN Low RR, IPsec
3.1.5 Basic denial-of-service attacks Any Med. RR
3.1.6 Replaying and blocking binding updates MN Low lifetime,
seq number,
MAC
3.2.1 Basic flooding Any High RR
3.2.2 Return-to-home flooding Any High RR
3.3.1 Inducing unnecessary binding updates MN, CN Med. heuristics
3.3.2 Forcing non-optimized routing MN Low heuristics
3.3.3 Reflection and amplification N/A Med. BU design
Figure 6. Summary of Discussed Attacks
話題攻撃の図6.まとめ
Figure 6 gives a summary of the attacks discussed. As it stands at the time of writing, the return-to-the-home flooding and the induction of unnecessary binding updates look like the threats against which we have the least amount of protection, compared to their severity.
図6は、議論の攻撃の概要を示します。それは執筆時点で現状では、リターン・ツー・家庭洪水や不要なバインディングアップデートの誘導は、その重大度に比べて、私たちは保護の最低額を持って、それに対して脅威のように見えます。
Early in the MIPv6 design process, it was assumed that plain IPsec could be the default way to secure Binding Updates with arbitrary correspondent nodes. However, this turned out to be impossible. Plain IPsec relies on an infrastructure for key management, which, to be usable with any arbitrary pair of nodes, would need to be global in scope. Such a "global PKI" does not exist, nor is it expected to come into existence any time soon.
初期のMIPv6の設計プロセスで、それはプレーンIPsecは、任意の通信相手ノードでバインディングアップデートを確保するためのデフォルトの方法かもしれないと仮定しました。しかし、これは不可能であることが判明しました。無地IPsecは、ノードの任意のペアで使用可能の範囲にグローバルであることが必要であろう、鍵管理のためのインフラストラクチャに依存しています。このような「グローバルPKIは、」存在しません。また、存在にいつでもすぐに来ることが予想されます。
More minor issues that also surfaced at the time were: (1) insufficient filtering granularity for the state of IPsec at the time, (2) cost to establish a security association (in terms of CPU and round trip times), and (3) expressing the proper authorization (as opposed to just authentication) for binding updates [13]. These issues are solvable, and, in particular, (1) and (3) have been addressed for IPsec usage with binding updates between the mobile node and the home agent [7].
また、一度に浮上もっとマイナーな問題であった：（1）不十分なフィルタリング時のIPsecの状態のための粒度、（2）コスト（CPUと往復時間の点で）セキュリティアソシエーションを確立するため、および（3）バインディングアップデートのための適切な権限（単に認証とは対照的に）[13]を発現します。これらの問題は、特に、（1）及び（3）モバイルノードとホームエージェント[7]との間のバインディング更新とのIPsecの使用のためにアドレス指定されている、解決可能であり、。
However, the lack of a global PKI remains unsolved.
しかし、世界的なPKIの欠如は未解決のまま。
One way to provide a global key infrastructure for mobile IP could be DNSSEC. Such a scheme is not completely supported by the existing specifications, as it constitutes a new application of the KEY RR, something explicitly limited to DNSSEC [8] [9] [10]. Nevertheless, if one were to define it, one could proceed along the following lines: A secure reverse DNS that provided a public key for each IP address could be used to verify that a binding update is indeed signed by an authorized party. However, in order to be secure, each link in such a system must be secure. That is, there must be a chain of keys and signatures all the way down from the root (or at least starting from a trust anchor common to the mobile node and the correspondent node) to the given IP address. Furthermore, it is not enough that each key be signed by the key above it in the chain. It is also necessary that each signature explicitly authorize the lower key to manage the corresponding address block below.
モバイルIPのためのグローバル鍵インフラストラクチャを提供する1つの方法は、DNSSECである可能性があります。それがKEY RRの新たなアプリケーションを構成するように完全に、既存の仕様によってサポートされていないような方式、DNSSECに明示的に限定されもの[8] [9] [10]。バインディング更新が実際に許可された当事者によって署名されていることを確認するために使用することができ、各IPアドレスの公開鍵を提供し、安全なリバースDNS：1はそれを定義した場合にもかかわらず、1は次の行に沿って進めることができました。しかし、安全であるために、このようなシステム内の各リンクは安全でなければなりません。すなわち、与えられたIPアドレスに（または少なくとも、モバイルノードとコレスポンデントノードに共通のトラストアンカーから始まる）のすべての方法ダウンルートから鍵及び署名の連鎖が存在しなければならない、です。また、各キーはチェーンで上記鍵によって署名されていることが十分ではありません。各署名が明示以下対応するアドレスブロックを管理するために、下キーを許可することも必要です。
Even though it would be theoretically possible to build a secure reverse DNS infrastructure along the lines shown above, the practical problems would be daunting. Whereas the delegation and key signing might work close to the root of the tree, it would probably break down somewhere along the path to the individual nodes. Note that a similar delegation tree is currently being proposed for Secure Neighbor Discovery [15], although in this case only routers (not necessarily every single potential mobile node) need to secure such a certificate. Furthermore, checking all the signatures on the tree would place a considerable burden on the correspondent nodes, making route optimization prohibitive, or at least justifiable only in very particular circumstances. Finally, it is not enough simply to check whether the mobile node is authorized to send binding updates containing a given home address, because to protect against flooding attacks, the care-of address must also be verified.
それは上に示した線に沿って安全なリバースDNSインフラストラクチャを構築することは理論的には可能だろうにもかかわらず、実用上の問題は困難なことでしょう。委任と鍵の署名は、ツリーのルートに近い動作する可能性があるのに対し、それはおそらく、個々のノードへのパスに沿ってどこかに分解します。この場合、唯一のルータ（必ずしもすべての単一電位モバイルノード）は、そのような証明書を確保する必要があるものの、同様の委任ツリーは現在、セキュア近隣探索[15]のために提案されていることに留意されたいです。さらに、木の上のすべての署名をチェックするルート最適化が法外、または非常に特定の状況では少なくとも正当作り、コレスポンデントノードにかなりの負担をかけるでしょう。フラッディング攻撃から保護するためにので最後に、それは、モバイルノードが与えられたホームアドレスを含むバインディング更新を送信することが許可されているかどうかをチェックするだけでは十分ではありません、気付アドレスも確認する必要があります。
Relying on this same secure DNS infrastructure to verify care-of addresses would be even harder than verifying home addresses. Instead, a different method would be required, e.g., a return routability procedure. If so, the obvious question is whether the gargantuan cost of deploying the global secure DNS infrastructure is worth the additional protection it affords, as compared to simply using return routability for both home address and care-of address verification.
気付アドレスを確認するために、この同じセキュアなDNSインフラストラクチャに依存することはホームアドレスを検証するよりもさらに困難になります。代わりに、別の方法は、例えば、リターン・ルータビリティ手順を必要とされるであろう。もしそうなら、明白な疑問は、グローバルセキュアなDNSインフラストラクチャを展開する巨大なコストは、単にホームアドレスと気付けアドレス検証の両方のリターンルータビリティを使用する場合と比較して、それがもたらす追加の保護価値があるかどうかです。
The current Mobile IPv6 route optimization security has been carefully designed to prevent or mitigate the threats that were discussed in Section 3. The goal has been to produce a design with a level of security close to that of a static IPv4-based Internet, and with an acceptable cost in terms of packets, delay, and processing. The result is not what one would expect: it is definitely not a traditional cryptographic protocol. Instead, the result relies heavily on the assumption of an uncorrupted routing infrastructure and builds upon the idea of checking that an alleged mobile node is indeed reachable through both its home address and its care-of address. Furthermore, the lifetime of the state created at the corresponded nodes is deliberately restricted to a few minutes, in order to limit the potential threat from time shifting.
現在のモバイルIPv6経路最適化セキュリティは慎重に第3節で目標を議論した脅威を防止または軽減するために設計されている静的IPv4ベースのインターネットのそれに近いセキュリティのレベルで設計を生成することであって、としていますパケット遅延、及び処理の観点から許容されるコスト。結果は1つが期待するものではありません：それは間違いなく、伝統的な暗号プロトコルではありません。その代わり、その結果は、破損していないルーティングインフラストラクチャの仮定に大きく依存していると主張されたモバイルノードがそのホームアドレスとその気付アドレスの両方を通じて実際に到達可能であることを確認するというアイデアに基づいて構築します。また、対応付けられたノードで作成された状態の寿命は、意図的に時間シフトから潜在的な脅威を制限するために、数分に制限されています。
This section describes the solution in reasonable detail (for further details see the specification), starting from Return Routability (Section 4.1), continuing with a discussion about state creation at the correspondent node (Section 4.2), and completing the description with a discussion about the lifetime of Binding Cache Entries (Section 4.3).
このセクションでは、（詳細は仕様を参照）妥当詳細溶液を記載し、リターンルータビリティ（セクション4.1）から出発して、コレスポンデントノード（セクション4.2）の状態の作成についての議論を続けると、約議論で説明を完成キャッシュエントリをバインドの寿命（4.3節）。
Return Routability (RR) is the name of the basic mechanism deployed by Mobile IPv6 route optimization security design. RR is based on the idea that a node should be able to verify that there is a node that is able to respond to packets sent to a given address. The check yields false positives if the routing infrastructure is compromised or if there is an attacker between the verifier and the address to be verified. With these exceptions, it is assumed that a successful reply indicates that there is indeed a node at the given address, and that the node is willing to reply to the probes sent to it.
リターンルータビリティ（RR）は、モバイルIPv6経路最適化セキュリティデザインによって展開の基本的なメカニズムの名前です。 RRは、ノードが指定されたアドレスに送信されたパケットに応答することができるノードが存在することを確認することができるはずという考えに基づいています。ルーティングインフラストラクチャが損なわれている場合、チェックは、偽陽性を生じるか、存在する場合、検証者とアドレスとの間の攻撃者が検証します。これらの例外を除いて、成功した応答は、ノードがそれに送信されたプローブに応答する意思があることが実際に指定されたアドレスのノードである、ことを示しているものとします。
The basic return routability mechanism consists of two checks, a Home Address check (see Section 4.1.1) and a care-of-address check (see Section 4.1.2). The packet flow is depicted in Figure 7. First, the mobile node sends two packets to the correspondent node: a Home Test Init (HoTI) packet is sent through the home agent, and a Care-of Test Init (CoTI) directly. The correspondent node replies to both of these independently by sending a Home Test (HoT) in response to the Home Test Init and a Care-of Test (CoT) in response to the Care-of Test Init. Finally, once the mobile node has received both the Home Test and Care-of Test packets, it sends a Binding Update to the correspondent node.
基本的なリターン・ルータビリティメカニズムは、2つのチェック、ホームアドレスのチェック（4.1.1項を参照）と気付アドレスのチェック（4.1.2項を参照）で構成されています。ホーム試験開始（HoTIに）パケットは、ホームエージェントを介して送信され、そしてテストケア-の初期化（のCoTI）が直接：パケットフローは、まず、図7に描かれている、モバイルノードは、コレスポンデントノードへの2つのパケットを送信します。コレスポンデント・ノードは、ホーム試験開始と気付テスト（COT）気付テスト開始に応答に応答して、ホーム試験（HOT）を送信することにより、独立して、これらの両方に応答します。モバイルノードがホームテストと気付テストパケットの両方を受信した後、最後に、それはコレスポンデントノードへの結合更新を送信します。
+------+ 1a) HoTI +------+
| |---------------------->| |
| MN | 2a) HoT | HA |
| |<----------------------| |
+------+ +------+
1b) CoTI | ^ | / ^
| |2b| CoT / /
| | | / /
| | | 3) BU / /
V | V / /
+------+ 1a) HoTI / /
| |<----------------/ /
| CN | 2a) HoT /
| |------------------/
+------+
Figure 7. Return Routability Packet Flow
図7.リターンルータビリティパケットフロー
It might appear that the actual design was somewhat convoluted. That is, the real return routability checks are the message pairs < Home Test, Binding Update > and < Care-of Test, Binding Update >. The Home Test Init and Care-of Test Init packets are only needed to trigger the test packets, and the Binding Update acts as a combined routability response to both of the tests.
実際の設計はやや複雑だったように見えるかもしれません。それは本当のリターン・ルータビリティ・チェックは、メッセージのペア<ホームテスト、バインディング更新>と<気付テスト、バインディングアップデート>は、あります。ホーム試験開始や試験開始気付のパケットのみテストパケットをトリガするために必要であり、結合更新は、テストの両方に合わせたルータビリティ応答として機能しています。
There are two main reasons behind this design:
この設計の背後にある2つの主な理由があります：
o avoidance of reflection and amplification (see Section 3.3.3), and
反射および増幅のO回避（セクション3.3.3を参照）、および
o avoidance of state exhaustion DoS attacks (see Section 4.2).
状態枯渇DoS攻撃のO回避（4.2節を参照してください）。
The reason for sending two Init packets instead of one is to avoid amplification. The correspondent node does not know anything about the mobile node, and therefore it just receives an unsolicited IP packet from some arbitrary IP address. In a way, this is similar to a server receiving a TCP SYN from a previously unknown client. If the correspondent node were to send two packets in response to an initial trigger, that would provide the potential for a DoS amplification effect, as discussed in Section 3.3.3.
1つではなく、2つの初期化パケットを送信するための理由は、増幅を避けるためです。コレスポンデントノードは、モバイルノードについて何も知らないので、それだけでいくつかの任意のIPアドレスから迷惑IPパケットを受信します。ように、これは以前に未知のクライアントからのTCP SYNを受信するサーバと同様です。コレスポンデント・ノードは、最初のトリガに応答して2つのパケットを送信した場合、セクション3.3.3で説明したように、それは、DoS攻撃の増幅効果の可能性を提供するであろう。
This scheme also avoids providing for a potential reflection attack. If the correspondent node were to reply to an address other than the source address of the packet, that would create a reflection effect. Thus, the only safe mechanism possible for a naive correspondent is to reply to each received packet with just one packet, and to send the reply to the source address of the received packet. Hence, two initial triggers are needed instead of just one.
この方式は、潜在的な反射攻撃のために提供する避けることができます。通信相手ノードは、パケットの送信元アドレス以外のアドレスに返信した場合、その反射効果を作成することになります。このように、ナイーブ対応のための可能な唯一の安全なメカニズムは、ただ一つのパケットを受信した各パケットに返信すると、受信したパケットの送信元アドレスに返信を送信することです。したがって、2つの初期のトリガーではなく、単に一つで必要とされています。
Let us now consider the two return routability tests separately. In the following sections, the derivation of cryptographic material from each of these is shown in a simplified manner. For the real formulas and more detail, please refer to [6].
私たちは今、別に2つのリターン・ルータビリティ・テストを考えてみましょう。以下のセクションでは、これらのそれぞれからの暗号化材料の導出は簡略化して示されています。実際の式と詳細については、[6]を参照してください。
The Home Address check consists of a Home Test (HoT) packet and a subsequent Binding Update (BU). It is triggered by the arrival of a Home Test Init (HoTI). A correspondent node replies to a Home Test Init by sending a Home Test to the source address of the Home Test Init. The source address is assumed to be the home address of a mobile node, and therefore the Home Test is assumed to be tunneled by the Home Agent to the mobile node. The Home Test contains a cryptographically generated token, home keygen token, which is formed by calculating a hash function over the concatenation of a secret key, Kcn, known only by the correspondent node, the source address of the Home Test Init packet, and a nonce.
ホームアドレスチェックがホームテスト（HOT）パケットとその後のバインディングアップデート（BU）から構成されています。それは、ホーム試験開始（HoTIメッセージ）の到着によってトリガーされます。コレスポンデント・ノードは、ホーム試験開始の送信元アドレスにホームテストを送信することにより、ホーム試験開始に応答します。送信元アドレスは、モバイルノードのホームアドレスであると仮定され、したがって、ホームテストは、モバイルノードにホームエージェントによってトンネルされるものとします。ホームテストは、コレスポンデントノード、ホーム試験開始パケットの送信元アドレスのみが知っている秘密鍵、Kcnを、の連結上のハッシュ関数を計算することによって形成され、暗号生成されたトークン、ホーム鍵生成トークンを、含まれており、ナンス。
home keygen token = hash(Kcn | home address | nonce | 0)
ホーム鍵生成トークン=ハッシュ（Kcnを|ホームアドレス|ナンス| 0）
An index to the nonce is also included in the Home Test packet, allowing the correspondent node to find the appropriate nonce more easily.
ナンスへのインデックスは、コレスポンデントノードは、より簡単に適切なnonceを見つけることができるように、ホームテストパケットに含まれています。
The token allows the correspondent node to make sure that any binding update received subsequently has been created by a node that has seen the Home Test packet; see Section 4.2.
トークンは、コレスポンデントノードは、必ずいずれかのバインディングアップデートを受信した後、ホームテストパケットを見ているノードによって作成されたことを確認することができます。 4.2節を参照してください。
In most cases, the Home Test packet is forwarded over two different segments of the Internet. It first traverses from the correspondent node to the Home Agent. On this trip, it is not protected and any eavesdropper on the path can learn its contents. The Home Agent then forwards the packet to the mobile node. This path is taken inside an IPsec ESP protected tunnel, making it impossible for the outsiders to learn the contents of the packet.
ほとんどの場合、ホームテストパケットは、インターネットの二つの異なるセグメントを介して転送されます。これは、最初のホームエージェントに対応するノードからトラバース。この旅行では、それが保護されていないと、パス上の任意の盗聴者がその内容を知ることができます。ホームエージェントは、モバイルノードにパケットを転送します。このパスは、それが不可能な部外者がパケットの内容を学習するために作る、IPsecのESP保護されたトンネル内で取られます。
At first, it may sound unnecessary to protect the packet between the home agent and the mobile node, since it travelled unprotected between the correspondent node and the mobile node. If all links in the Internet were equally insecure, the additional protection would be unnecessary. However, in most practical settings the network is likely to be more secure near the home agent than near the mobile node. For example, if the home agent hosts a virtual home link and the mobile nodes are never actually at home, an eavesdropper should be close to the correspondent node or on the path between the correspondent node and the home agent, since it could not eavesdrop at the home agent. If the correspondent node is a major server, all the links on the path between it and the home agent are likely to be fairly secure. On the other hand, the Mobile Node is probably using wireless access technology, making it sometimes trivial to eavesdrop on its access link. Thus, it is fairly easy to eavesdrop on packets that arrive at the mobile node. Consequently, protecting the HA-MN path is likely to provide real security benefits even when the CN-HA path remains unprotected.
それは相手ノードとモバイルノードとの間に保護されていない旅以来初めてで、それは、ホームエージェントとモバイルノードとの間でパケットを保護する必要が聞こえることがあります。インターネットのすべてのリンクが等しく安全でないならば、追加の保護が不要になります。しかし、最も現実的な設定で、ネットワークは、移動ノードに近いよりもホームエージェントの近くに、より安全である可能性が高いです。ホームエージェントは、仮想ホームリンクをホストし、モバイルノードは自宅で実際にされることはありませんならば、それはで盗聴ができませんでしたので、例えば、盗聴者は、コレスポンデントノードまたはコレスポンデントノードとホームエージェントとの間のパスに近いはずホームエージェント。コレスポンデントノードは、主要なサーバーである場合は、それとホームエージェントとの間のパス上のすべてのリンクはかなり安全である可能性が高いです。一方、モバイルノードは、おそらくそのアクセスリンク上で盗聴することは時々些細な作り、無線アクセス技術を使用しています。これにより、モバイルノードに到着するパケットを盗聴することはかなり容易です。その結果、HA-MNパスを保護することはCN-HAパスが保護されていない残っている場合でも、実際のセキュリティ上の利点を提供する可能性があります。
From the correspondent node's point of view, the Care-of-Address check is very similar to the home check. The only difference is that now the source address of the received Care-of Test Init packet is assumed to be the care-of address of the mobile node. Furthermore, the token is created in a slightly different manner in order to make it impossible to use home tokens for care-of tokens or vice versa.
ビューの相手ノードの観点から、気付アドレスチェックは、ホームチェックと非常によく似ています。唯一の違いは、今受信した気付テスト開始パケットの送信元アドレスは、気付モバイルノードのアドレスであると仮定されていることです。さらに、トークンは、それが不可能に気付けトークンまたはその逆のホームトークンを使用できるようにするために、わずかに異なる方法で作成されます。
care-of keygen token = hash(Kcn | care-of address | nonce | 1)
気付生成トークン=ハッシュ（Kcnを|気付アドレス|ナンス| 1）
The Care-of Test traverses only one leg, directly from the correspondent node to the mobile node. It remains unprotected all along the way, making it vulnerable to eavesdroppers near the correspondent node, on the path from the correspondent node to the mobile node, or near the mobile node.
テスト-のケアは、直接モバイルノードに対応するノードから、一つだけの脚を通過します。これは、コレスポンデントノードの近くに、モバイルノードに対応するノードからパス上、またはモバイルノードの近くに盗聴者にそれが脆弱になって、すべての道に沿って保護されていないまま。
When the mobile node has received both the Home Test and Care-of Test messages, it creates a binding key, Kbm, by computing a hash function over the concatenation of the tokens received.
モバイルノードは、ホーム試験および気付試験メッセージの両方を受信した場合には、トークンは、受信の連結上のハッシュ関数を計算することによって、結合キーKbmをを作成します。
This key is used to protect the first and the subsequent binding updates, as long as the key remains valid.
このキーは限りキーが有効のままとして、第一およびその後の結合の更新を保護するために使用されます。
Note that the key Kbm is available to anyone who is able to receive both the Care-of Test and Home Test messages. However, they are normally routed by different routes through the network, and the Home Test is transmitted over an encrypted tunnel from the home agent to the mobile node (see also Section 5.4).
キーKbmを両方のテストとホーム気付テストメッセージを受信することができます誰にでも利用可能であることに注意してください。しかし、これらは通常、ネットワークを介して異なる経路でルーティングされ、ホームテストは、移動ノードのホーム・エージェントからの暗号化トンネルを介して送信される（セクション5.4参照）。
The correspondent node may remain stateless until it receives the first Binding Update. That is, it does not need to record receiving and replying to the Home Test Init and Care-of Test Init messages. The Home Test Init/Home Test and Care-of Test Init/Care-of Test exchanges take place in parallel but independently of each other. Thus, the correspondent can respond to each message immediately, and it does not need to remember doing that. This helps in potential denial-of-service situations: no memory needs to be reserved for processing Home Test Init and Care-of Test Init messages. Furthermore, Home Test Init and Care-of Test Init processing is designed to be lightweight, and it can be rate limited if necessary.
それが最初のバインディングアップデートを受信するまで、通信相手ノードは、ステートレス残ることがあります。つまり、受信してホーム試験開始と気付テスト開始メッセージに返信を記録する必要はありません、です。ホーム試験開始/ホームテストおよび気付試験開始/ケア-のテスト交換が並行して行われたが、互いに独立して。このように、通信員は、直ちに各メッセージに応答することができ、それはそれをやって覚えておく必要はありません。これは、潜在的なサービス拒否の状況で役立ちます：なしメモリはホーム試験開始と試験開始ケア-のメッセージを処理するために予約する必要はありません。さらに、ホーム試験開始と気付テスト開始処理が軽量に設計され、必要に応じてレート制限することができます。
When receiving a first binding update, the correspondent node goes through a rather complicated procedure. The purpose of this procedure is to ensure that there is indeed a mobile node that has recently received a Home Test and a Care-of Test that were sent to the claimed home and care-of addresses, respectively, and to make sure that the correspondent node does not unnecessarily spend CPU or other resources while performing this check.
最初のバインディングアップデートを受信した場合、相手ノードは、かなり複雑な手順を経ます。この手順の目的は、それぞれ、最近、ホームテストと気付テスト主張自宅に送られて、気付アドレスされた受信した移動ノードが実際に存在していることを保証するために、かつ確実な対応ということにすることですこのチェックを実行中にノードが不必要にCPUなどのリソースを費やすことはありません。
Since the correspondent node does not have any state when the binding update arrives, the binding update itself must contain enough information so that relevant state can be created. To that end, the binding update contains the following pieces of information:
コレスポンデントノードがどのような状態を持っていないので、結合更新が到着したときに、関連する状態を作成することができるように、バインディングアップデート自体は十分な情報が含まれている必要があります。そのために、バインディングアップデートは、以下の情報が含まれています。
Source address: The care-of address specified in the Binding Update must be equal to the source address used in the Care-of Test Init message. Notice that this applies to the effective Care-of Address of the Binding Update. In particular, if the Binding Update includes an Alternate Care-of Address (AltCoA) [6], the effective CoA is, of course, this AltCoA. Thus, the Care-of Test Init must have originated from the AltCoA.
ソースアドレス：気付バインディング更新で指定されたアドレスは、気付テスト開始メッセージで使用される送信元アドレスと同じでなければなりません。これは効果的なケアのバインディングアップデートのアドレスに適用されることに注意してください。結合更新は、代替気付アドレス（AltCoA）を含む場合、特に、[6]、有効なCoAが、当然のことながら、このAltCoAあります。このように、試験開始気付AltCoAに由来している必要があります。
Home address: The home address specified in the Binding Update must be equal to the source address used in the Home Test Init message.
ホームアドレス：バインディングアップデートに指定されたホームアドレスはホーム試験開始メッセージで使用される送信元アドレスと同じでなければなりません。
Two nonce indices: These are copied over from the Home Test and Care-of Test messages, and together with the other information they allow the correspondent node to re-create the tokens sent in the Home Test and Care-of Test messages and used for creating Kbm.
二ナンス指数：これらは、ホームテストと気付テストメッセージ、一緒に彼らは、通信相手ノードがホームテストとテスト気付メッセージで送信などに使用するトークンを再作成することができ、他の情報とからコピーされていますたKbmを作成します。
Without them, the correspondent node might need to try the 2-3 latest nonces, leading to unnecessary resource consumption.
それらがなければ、コレスポンデントノードは、不必要なリソース消費につながる、2-3最新のナンスを試してみる必要があるかもしれません。
Message Authentication Code (MAC): The binding update is authenticated by computing a MAC function over the care-of address, the correspondent node's address and the binding update message itself. The MAC is keyed with the key Kbm.
メッセージ認証コード（MAC）：バインディング更新は、気付アドレス、通信相手ノードのアドレスとバインディング更新メッセージ自体の上MAC関数を計算することによって認証されます。 MACは、キーKbmをしてキーイングされます。
Given the addresses, the nonce indices (and thereby the nonces) and the key Kcn, the correspondent node can re-create the home and care-of tokens at the cost of a few memory lookups and computation of one MAC and one hash function.
アドレス、ナンス指数（およびそれによってナンス）と鍵Kcnを考えると、コレスポンデントノードは、家庭を再作成することができ、気付けトークン数のメモリ検索と1 MACの計算と1つのハッシュ関数のコストで。
Once the correspondent node has re-created the tokens, it hashes the tokens together, giving the key Kbm. If the Binding Update is authentic, Kbm is cached together with the binding. This key is then used to verify the MAC that protects integrity and origin of the actual Binding Update. Note that the same Kbm may be used for a while, until the mobile node moves (and needs to get a new care-of-address token), the care-of token expires, or the home token expires.
コレスポンデントノードがトークンを再作成したら、それはキーKbmをを与え、一緒にトークンをハッシュ。バインディングアップデートが本物であれば、Kbmをバインディングと一緒にキャッシュされます。このキーは、実際のバインディングアップデートの完全性と起源を保護MACを検証するために使用されます。同じたKbmは、モバイルノードが移動するまで、しばらくの間使用することができることに注意してください（と新しい気付アドレストークンを取得する必要があります）、気付けトークンの有効期限が切れる、または家庭用トークンの有効期限が切れます。
Note that since the correspondent node may remain stateless until it receives a valid binding update, the mobile node is solely responsible for retransmissions. That is, the mobile node should keep sending the Home Test Init / Care-of Test Init messages until it receives a Home Test / Care-of Test, respectively. Similarly, it may need to send the binding update a few times in the case it is lost while in transit.
それは有効なバインディングアップデートを受信するまで、通信相手ノードはステートレス残っている場合がありますので、モバイルノードが再送信する責任であることに注意してください。つまり、モバイルノードは、それがホームテスト/ケア-のテストを受信するまで、それぞれ、ホーム試験開始/気付テスト開始メッセージを送信しておく必要があります。同様に、転送中に、それが失われた場合にはバインディングアップデートを数回送信する必要があるかもしれません。
A Binding Cache Entry, along with the key Kbm, represents the return routability state of the network at the time when the Home Test and Care-of Test messages were sent out. It is possible that a specific attacker is able to eavesdrop a Home Test message at some point of time, but not later. If the Home Test had an infinite or a long lifetime, that would allow the attacker to perform a time shifting attack (see Section 2.2). That is, in the current IPv4 architecture an attacker on the path between the correspondent node and the home agent is able to perform attacks only as long as the attacker is able to eavesdrop (and possibly disrupt) communications on that particular path. A long living Home Test, and consequently the ability to send valid binding updates for a long time, would allow the attacker to continue its attack even after the attacker is no longer able to eavesdrop on the path.
キーKbmを一緒にバインディングキャッシュエントリ、ホームテストと気付テストメッセージが送信された時点でのネットワークのリターンルータビリティ状態を表しています。特定の攻撃者は、時間のある時点で、ホームテストメッセージを盗聴することができますが、遅くともことも可能です。ホームテストは、無限または攻撃者が攻撃をタイムシフトを実行できるようになる長い寿命を持っていた場合（2.2節を参照してください）。すなわち、現在のIPv4アーキテクチャで通信相手ノードとホームエージェントとの間の経路上の攻撃者のみ限り、攻撃者は、その特定のパス上の通信を盗聴（そしておそらく破壊）することができるように攻撃を行うことが可能です。長い生活ホームテスト、そして長い時間のために有効なバインディング更新を送信するために、結果としての能力は、攻撃者は、攻撃者は、もはやパスを盗聴することができた後も、その攻撃を続けることができるようになります。
To limit the seriousness of this and other similar time shifting threats, the validity of the tokens is limited to a few minutes. This effectively limits the validity of the key Kbm and the lifetime of the resulting binding updates and binding cache entries.
これと他の同様の時間シフトの脅威の深刻さを制限するには、トークンの有効性は、数分に制限されています。これは、効果的にキーKbmをの有効性及び得られた結合更新と結合キャッシュエントリの有効期間を制限します。
Although short lifetimes are required by other aspects of the security design and the goals, they are clearly detrimental for efficiency and robustness. That is, a Home Test Init / Home Test message pair must be exchanged through the home agent every few minutes. These messages are unnecessary from a purely functional point of view, thereby representing overhead. What is worse, though, is that they make the home agent a single point of failure. That is, if the Home Test Init / Home Test messages were not needed, the existing connections from a mobile node to other nodes could continue even when the home agent fails, but the current design forces the bindings to expire after a few minutes.
短い寿命は、セキュリティ設計や目標の他の側面によって必要とされているが、それらは明らかに効率性と堅牢性のために有害です。それはホーム試験開始/ホームテストメッセージペアは、ホームエージェントを介して数分毎に交換しなければならない、です。これらのメッセージは、それによってオーバーヘッドを表し、ビューの純粋に機能的な観点から不要です。さらに悪いことに、しかし、彼らはホームエージェントが単一障害点にするということです。それはホーム試験開始/ホームテストメッセージを必要とされていない場合は、ホームエージェントが失敗した場合でも、他のノードへの移動ノードから既存の接続が継続する可能性があり、ですが、現在の設計は、数分後に期限切れにバインディングを強制します。
This concludes our walk-through of the selected security design. The cornerstones of the design were the employment of the return routability idea in the Home Test, Care-of Test, and binding update messages, the ability to remain stateless until a valid binding update is received, and the limiting of the binding lifetimes to a few minutes. Next we briefly discuss some of the remaining threats and other problems inherent to the design.
これは、選択されたセキュリティ設計の私達のウォークスルーを終了します。デザインの基礎はホームテスト、気付試験におけるリターンルータビリティのアイデアの雇用たし、更新メッセージ、有効なバインディング更新が受信されるまでステートレス維持する能力、およびに結合寿命の制限を結合します数分。次は、簡単な設計に固有の残りの脅威やその他の問題のいくつかを議論します。
This section gives a brief analysis of the security design, mostly in the light of what was known when the design was completed in Fall 2002. It should be noted that this section does not present a proper security analysis of the protocol; it merely discusses a few issues that were known at the time the design was completed.
このセクションでは、ほとんどのデザインは、このセクションはプロトコルの適切なセキュリティ分析を提示していないことに留意すべきである秋2002年に完成した時に知られていたものに照らして、セキュリティ設計の簡単な分析を提供します。それは単に設計が完了した時点で知られていたいくつかの問題について説明します。
It should be kept in mind that the MIPv6 RO security design was never intended to be fully secure. Instead, as we stated earlier, the goal was to be roughly as secure as non-mobile IPv4 was known to be at the time of the design. As it turns out, the result is slightly less secure than IPv4, but the difference is small and most likely insignificant in real life.
MIPv6のROのセキュリティ設計が完全に安全であることを意図していなかったことを心に留めておくべきです。我々は先に述べたように代わりに、目標は非モバイルIPv4のは、設計の時点であることが知られていたとして、およそとして安全であることでした。結局のところ、その結果は、IPv4よりもわずかに小さい安全ですが、違いは小さく、実際の生活の中で最も可能性の高い軽微であります。
The known residual threats as compared with IPv4 are discussed in Section 5.1. Considerations related to the application of IPsec to authorize route optimization are discussed in Section 5.2. Section 5.3 discusses an attack against neighboring nodes. Finally, Section 5.4 deals with the special case of two mobile nodes conversing and performing the route optimization procedure with each other.
IPv4のと比較して既知の残留脅威はセクション5.1に記載されています。ルート最適化を許可するためのIPsecのアプリケーションに関連する考察は、セクション5.2に記載されています。 5.3節では、隣接ノードに対する攻撃について説明します。最後に、2つのモバイルノードの特別な場合と5.4の取引は会話と相互に経路最適化処理を行います。
As we mentioned in Section 4.2, the lifetime of a binding represents a potential time shift in an attack. That is, an attacker that is able to create a false binding is able to reap the benefits of the binding as long as the binding lasts. Alternatively, the attacker is able to delay a return-to-home flooding attack (Section 3.2.2) until the binding expires. This is different from IPv4, where an attacker may continue an attack only as long as it is on the path between the two hosts.
我々は4.2節で述べたように、結合の寿命は攻撃の潜在的な時間シフトを表しています。それは偽のバインディングを作成することができ、攻撃者がいる限り結合が続くよう結合のメリットを享受することができ、あります。また、攻撃者は、バインディングの有効期限が切れるまでリターンツーホームフラッディング攻撃（セクション3.2.2）を遅らせることが可能です。これにより、攻撃者だけであれば、2つのホスト間のパス上にあるように攻撃を続けることができるIPv4の、異なっています。
Since the binding lifetimes are severely restricted in the current design, the ability to do a time shifting attack is equivalently restricted.
結合寿命が厳しく現在の設計に制限されているので、時間シフト攻撃を行う能力が同等に制限されています。
Threats possible because of the introduction of route optimization are, of course, not present in a baseline IPv4 internet (Section 3.3). In particular, inducing unnecessary binding updates could potentially be a severe attack, but this would be most likely due to faulty implementations. As an extreme measure, a correspondent node can protect against these attacks by turning off route optimization. If so, it becomes obvious that the only residual attack against which there is no clear-cut prevention (other than its severe limitation as currently specified) is the time shifting attack mentioned above.
なぜなら、経路最適化の導入の可能性のある脅威が、当然のことながら、ベースラインIPv4インターネット（3.3節）には存在しません。具体的には、不要なバインディングアップデートを誘導することは、潜在的に深刻な攻撃かもしれないが、これは不良による実装に最も可能性が高いだろう。極端な措置として、コレスポンデントノードは、ルート最適化をオフにすることで、これらの攻撃から守ることができます。もしそうなら、それだけ残留攻撃がそれに対して（現在指定されているように、その厳しい制限以外）は、明確な防止がないことが明らかになり、上述したタイムシフト攻撃です。
A major motivation behind the current binding update design was scalability, which implied the ability to run the protocol without any existing security infrastructure. An alternative would have been to rely on existing trust relationships, perhaps in the form of a special-purpose Public Key Infrastructure in conjunction with IPsec. That would have limited scalability, making route optimization available only in environments where it is possible to create appropriate IPsec security associations between the mobile nodes and the corresponding nodes.
現在のバインディングアップデートのデザインの背後にある主な動機は、既存のセキュリティインフラストラクチャなしでプロトコルを実行する能力を暗示スケーラビリティ、でした。代替は、おそらくのIPsecと一緒に特別な目的の公開鍵インフラストラクチャの形で、既存の信頼関係に依存してきただろう。つまり、モバイルノードと対応するノードとの間に適切なのIPsecセキュリティアソシエーションを作成することが可能であるのみの環境で利用可能な経路最適化を行うこと、限られた拡張性を持っているでしょう。
There clearly are situations where there exists an appropriate relationship between a mobile node and the correspondent node. For example, if the correspondent node is a server that has pre-established keys with the mobile node, that would be the case. However, entity authentication or an authenticated session key is not necessarily sufficient for accepting Binding Updates.
明らかに、モバイルノードとコレスポンデントノードとの間に適切な関係が存在する状況があります。例えば、コレスポンデントノードは、モバイルノードとキーを事前に確立しているサーバである場合、それは場合です。しかし、エンティティ認証または認証されたセッションキーは、バインディングアップデートを受け入れるためには必ずしも十分ではありません。
Home Address Check: If one wants to replace the home address check with cryptographic credentials, these must carry proper authorization for the specific home address, and care must be taken to make sure that the issuer of the certificate is entitled to express such authorization. At the time of the design work, the route optimization security design team was not aware of standardized certificate formats to do this, although more recent efforts within the IETF are addressing this issue. Note that there is plenty of motivation to do so, as any pre-existing relationship with a correspondent node would involve the mobile node's home address (instead of any of its possible care-of addresses). Accordingly, the IKE exchange would most naturally run between the correspondent node and the mobile node's home address. This still leaves open the issue of checking the mobile node's care-of address.
ホームアドレスチェック：1の暗号資格情報を使用してホームアドレスチェックを交換したい場合、これらは特定のホームアドレスのための適切な権限を運ばなければならない、とケアは、証明書の発行者は、このような許可を表現する権利があることを確認するために注意する必要があります。 IETF内のより最近の努力は、この問題に対処しているが、設計作業の時には、経路最適化セキュリティ設計チームは、これを行うための標準化された証明書フォーマットを認識していませんでした。 （代わりに、その可能気付アドレスのいずれかの）モバイルノードのホームアドレスを伴うだろうコレスポンデントノードとの任意の既存の関係として、そうする動機が十分にあることに注意してください。したがって、IKE交換が最も自然に相手ノードとモバイルノードのホームアドレスとの間で実行します。これはまだ、モバイルノードの気付アドレスを確認する問題を開いたまま。
Care-of Address Check: As for the care-of-address check, in practice, it seems highly unlikely that nodes could completely replace the care-of-address check with credentials. Since the care-of addresses are ephemeral, in general it is very difficult for a mobile node to present credentials that taken at face value (by an arbitrary correspondent node) guarantee no misuse for, say, flooding attacks (Section 3.2). As discussed before, a reachability check goes a long way to alleviate such attacks. Notice that, as part of the normal protocol exchange, establishing IPsec security associations via IKE includes one such reachability test. However, as per the previous section, the natural IKE protocol exchange runs between the correspondent node and the mobile node's home address. Hence, another reachability check is needed to check the care-of address at which the node is currently reachable. If this address changes, such a reachability test is likewise necessary, and it is included in ongoing work aimed at securely updating the node's current address.
気付アドレスのチェック：気付アドレスチェックについては、実際には、ノードが完全に資格情報を持つ気付アドレスチェックを置き換えることができることを非常に考えにくいです。気付アドレスは短命なので、移動ノードは、（任意のコレスポンデントノードによって）額面で撮影された資格情報を提示するために、一般的には非常に困難であるフラッディング攻撃、たとえば、のための誤用（3.2節）を保証しません。前に述べたように、到達可能性チェックは、このような攻撃を軽減するための長い道のりを行きます。通常のプロトコル交換の一部として、IKEを介してIPsecセキュリティアソシエーションを確立すると、そのような到達可能性テストを含むことに注意してください。しかし、前のセクションごとに、自然のIKEプロトコル交換は、通信相手ノードとモバイルノードのホームアドレスの間で実行されます。したがって、別の到達性チェックは気付のノードが現在到達されたアドレスを確認するために必要とされます。このアドレスが変更された場合、そのような到達可能性テストも同様に必要であり、それがしっかりとノードの現在のアドレスを更新を目的とした進行中の作業に含まれています。
Nevertheless, the Mobile IPv6 base specification [6] does not specify how to use IPsec together with the mobility procedures between the mobile node and correspondent node. On the other hand, the specification is carefully written to allow the creation of the binding management key Kbm through some different means. Accordingly, where an appropriate relationship exists between a mobile node and a correspondent node, the use of IPsec is possible, and is, in fact, being pursued in more recent work.
それにもかかわらず、モバイルIPv6の基本仕様[6]モバイルノードとコレスポンデントノードとの間のモビリティ手順と共にIPsecを使用する方法を指定しません。一方、仕様は慎重に、いくつかの異なる手段によって結合管理鍵Kbmをを作成できるように書かれています。したがって、適切な関係が、モバイルノードとコレスポンデントノードとの間に存在する場合、のIPsecの使用が可能であり、そして、実際には、より最近の研究で進められています。
One possible attack against the security design is to pretend to be a neighboring node. To launch this attack, the mobile node establishes route optimization with some arbitrary correspondent node. While performing the return routability tests and creating the binding management key Kbm, the attacker uses its real home address but a faked care-of address. Indeed, the care-of address would be the address of the neighboring node on the local link. The attacker is able to create the binding since it receives a valid Home Test normally, and it is able to eavesdrop on the Care-of Test, as it appears on the local link.
セキュリティ設計に対する一つの可能な攻撃は隣接ノードであることをふりをすることです。この攻撃を起動するには、モバイルノードは、いくつかの任意のコレスポンデントノードとの経路最適化を確立します。リターン・ルータビリティ・テストを実行し、結合管理鍵Kbmを作成中、攻撃者はその本当のホームアドレスが、偽造さ気付アドレスを使用しています。確かに、気付アドレスは、ローカルリンク上の隣接ノードのアドレスになります。攻撃者は、それが正常に有効なホームテストを受けるため、バインディングを作成することができ、そしてローカルリンクに表示される、気付テストを盗聴することができます。
This attack would allow the mobile node to divert unwanted traffic towards the neighboring node, resulting in an flooding attack.
この攻撃は、モバイルノードがフラッディング攻撃で、その結果、隣接ノードへの不要なトラフィックを迂回させることが可能になります。
However, this attack is not very serious in practice. First, it is limited in the terms of location, since it is only possible against neighbors. Second, the attack works also against the attacker, since it shares the local link with the target. Third, a similar attack is possible with Neighbor Discovery spoofing.
しかし、この攻撃は、実際には非常に深刻ではありません。それは隣人に対してのみ可能であるので、まず、それは、場所の面で制限されています。それがターゲットとローカルリンクを共有するため、第二に、攻撃は、攻撃者に対しても動作します。第三に、同様の攻撃は、近隣探索なりすましで可能です。
When two mobile nodes want to establish route optimization with each other, some care must be exercised in order not to reveal the reverse tokens to an attacker. In this situation, both mobile nodes act simultaneously in the mobile node and the correspondent node roles. In the correspondent node role, the nodes are vulnerable to attackers that are co-located at the same link. Such an attacker is able to learn both the Home Test and Care-of Test sent by the mobile node, and therefore it is able to spoof the location of the other mobile host to the neighboring one. What is worse is that the attacker can obtain a valid Care-of Test itself, combine it with the Home Test, and then claim to the neighboring node that the other node has just arrived at the same link.
2つのモバイルノードが互いに経路最適化を確立したい場合は、いくつかの注意が攻撃者に逆のトークンを明らかにしないようにするために行使しなければなりません。この状況では、両方のモバイルノードは、モバイルノードとコレスポンデントノードの役割に同時に作用します。コレスポンデントノードの役割では、ノードが同じリンクで同じ場所に配置されている攻撃に対して脆弱です。そのような攻撃者は、モバイル・ノードによって送信されたホーム試験および気付試験の両方を学習することができ、したがって、隣接一つに他の移動ホストの位置を偽装することが可能です。さらに悪いのは、攻撃者は、有効な気付テスト自体を得るホームテストとそれを組み合わせるし、その後他のノードがちょうど同じリンクに到着した隣接ノードに主張することができるということです。
There is an easy way to avoid this attack. In the correspondent node role, the mobile node should tunnel the Home Test messages that it sends through its home agent. This prevents the co-located attacker from learning any valid Home Test messages.
この攻撃を回避するための簡単な方法があります。コレスポンデントノードの役割には、モバイルノードにトンネルそれはそのホームエージェントを介して送信ホームテストメッセージをする必要があります。これは、任意の有効なホームテストメッセージを学習から同じ場所に配置攻撃を防ぐことができます。
This document discussed the security design rationale for the Mobile IPv6 Route Optimization. We have tried to describe the dangers created by Mobile IP Route Optimization, the security goals and background of the design, and the actual mechanisms employed.
この文書では、モバイルIPv6ルート最適化のためのセキュリティ設計根拠を議論しました。私たちは、モバイルIPルート最適化、セキュリティ目標とデザインの背景、そして使用される実際のメカニズムによって作成された危険性を説明することを試みました。
We started the discussion with a background tour to the IP routing architecture the definition of the mobility problem. After that, we covered the avenues of attack: the targets, the time shifting abilities, and the possible locations of an attacker. We outlined a number of identified threat scenarios, and discussed how they are mitigated in the current design. Finally, in Section 4 we gave an overview of the actual mechanisms employed, and the rational behind them.
私たちは、IPルーティングアーキテクチャの背景ツアーモビリティ問題の定義と議論を始めました。ターゲット、時間シフト能力、および攻撃者の可能性のある場所：その後、我々は攻撃の道をカバーしました。私たちは、特定された脅威シナリオの数を概説し、それらは現在の設計で軽減する方法を議論しました。最後に、第4節では、我々は、使用される実際のメカニズムの概要を与え、そしてその背後にある合理的。
As far as we know today, the only significant difference between the security of an IPv4 Internet and that of an Internet with Mobile IPv6 (and route optimization) concerns time shifting attacks. Nevertheless, these are severely restricted in the current design.
限り、我々が今日知っているように、IPv4インターネットのセキュリティとモバイルIPv6（及び経路最適化）とインターネットの間の唯一の大きな違いは、時間シフトの攻撃に関するものです。それにもかかわらず、これらは厳しく、現在のデザインに制限されています。
We have also briefly covered some of the known subtleties and shortcomings, but that discussion cannot be exhaustive. It is quite probable that new subtle problems will be discovered with the design. As a consequence, it is most likely that the design needs to be revised in the light of experience and insight.
また、簡単に知られている機微や欠点のいくつかをカバーしているが、その議論は網羅することはできません。新たな微妙な問題は、デザインで発見されることは非常に可能性があります。その結果、デザインが経験と見識に照らして改訂する必要があることを最も可能性が高いです。
We are grateful for: Hesham Soliman for reminding us about the threat explained in Section 5.3, Francis Dupont for first discussing the case of two mobile nodes talking to each other (Section 5.4) and for sundry other comments, Pekka Savola for his help in Section 1.1.1, and Elwyn Davies for his thorough editorial review.
私たちは、のために感謝している：脅威についての私達に思い出させるためのHeshamソリマンは、最初にお互いに話を2つのモバイルノード（セクション5.4）の場合を議論するために雑貨他のコメントについては、セクション5.3、フランシスデュポンで説明した、節で彼の助けのためのペッカSavola 1.1.1、および彼の徹底的な編集レビューのためのエルウィン・デイヴィス。
[1] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV, USA, IEEE Press, December 2002.
[1]オーラ、T.、卵、M.、およびJ. Arkko、 "インターネットロケーション管理のセキュリティ"、PROC。第18回コンピュータセキュリティアプリケーションの会議、ページ78-87、ラスベガス、NV、USA、IEEEプレス、2002年12月。
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[3] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[4]ブッシュ、R.およびD.マイヤー、 "一部のインターネットの建築ガイドラインと哲学"、RFC 3439、2002年12月。
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[5]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[7] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月を。
[8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[8]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[9]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、2005年3月。
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[10]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[11] Chiappa, J., "Will The Real 'End-End Principle' Please Stand Up?", Private Communication, April 2002.
[11] Chiappa、J.は、「実際の 『エンドツーエンド原理は、』スタンド・アップしてくださいますか？」、プライベートコミュニケーション、2002年4月。
[12] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29:5, October 1999.
[12]サベージ、S.、カードウェル、N.、Wetherall、D.、およびT.アンダーソン、 "ふらちなレシーバーとのTCP輻輳制御"、ACMコンピュータコミュニケーションレビュー、29：5、1999年10月。
[13] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Security Protocols 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pages 12-26, Springer, 2002.
[13] Nikander、P.、「サービス拒否、アドレスの所有権、およびIPv6の世界での早期の認証」、セキュリティプロトコル第9回国際ワークショップ、ケンブリッジ、英国、4月25-27 2001、LNCS 2467、ページ12-26 、スプリンガー、2002。
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", Private Communication, 1999.
[14] Chiappa、J.、「エンドポイントとエンドポイント名：インターネットアーキテクチャへの提案強化」、プライベートコミュニケーション、1999。
[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[15] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ペッカNikanderエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
電話：+358 9 299 1 Eメール：pekka.nikander@nomadiclab.com
Jari Arkko Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
ヤリArkkoエリクソン研究NomadicLab JORVAS FIN-02420フィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Tuomas Aura Microsoft Research Ltd. Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom
Tuomasオーラマイクロソフトリサーチ株式会社ロジャーニーダムビル7 JJトムソンアベニューケンブリッジCB3 0FBイギリス
EMail: Tuomaura@microsoft.com
メールアドレス：Tuomaura@microsoft.com
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
がｂりえｌ もんてねｇろ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: gabriel_montenegro_2000@yahoo.com
メールアドレス：gabriel_montenegro_2000@yahoo.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmarkとSun Microsystemsの17ネットワークサークルメンロパーク、CA 94025 USA
EMail: erik.nordmark@sun.com
メールアドレス：erik.nordmark@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。