[要約] 要約：RFC 4225は、Mobile IP Version 6のルート最適化セキュリティデザインに関する背景を提供しています。 目的：このRFCの目的は、Mobile IP Version 6のルート最適化セキュリティの設計に関する情報を提供し、ネットワークのセキュリティを向上させることです。
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).
Copyright（c）The Internet Society（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）ルート最適化セキュリティ設計の背後にある理論的根拠の説明です。このドキュメントの目的は、2001年から2002年にかけてのモバイル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）。これは、ヒューリスティックと賢明な実装に基づいた他の対策を必要とするRRプロトコル自体への攻撃を除いて当てはまります（セクション3.3）。
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.
このドキュメントの残りの部分は次のように整理されています。この紹介セクションの後、セクション2の攻撃の道を検討することから始めます。セキュリティの問題と対策については、セクション3で詳しく説明します。セクション4では、全体的な操作と設計の選択肢について説明します。現在のセキュリティ設計。セクション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アドレスでパケットを送信することができます。これを防ぐために、イングレスフィルタリングの最終的な導入が想定されています。イングレスフィルタリングを使用すると、スプーフィングされたアドレスを備えたトラフィックは転送されません。このフィルタリングは、インターネットサービスプロバイダー（ISP）とその顧客の間、下流と上流のISP間、またはピアISPの間など、さまざまなネットワーク境界で適用できます[5]。明らかに、Ingressフィルターの粒度は、「プレフィックスの内側のスプーフィング」できる金額を指定します。たとえば、ISP Ingressが顧客のリンクをフィルタリングしているが、顧客が何もしない場合、顧客 /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].
ただし、インターネットの大部分がそれを使用した場合にのみ、イングレスフィルタリングが役立ちます。残念ながら、まだ克服できないものではありませんが、慎重な取り扱いが必要であり、その有用性を制限または遅延させる可能性が高いいくつかの問題がまだいくつかあります（例：マルチホミングの存在）。
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）の固定プロキシとして機能できるようにすることです。モバイルノードがホームネットワークから離れているときはいつでも、ホームエージェントはノードに運命づけられたパケットを傍受し、ノードの現在のアドレスであるCare of Address（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）がパケットを直接交換できるようにする操作モードが含まれ、初期セットアップフェーズの後にホームエージェントを完全にバイパスします。この動作モードは、Route Optimization（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ルートの最適化が使用されるたびに、特派員ノードは2つの役割で効果的に機能します。第一に、それはいつものように送信するパケットのソースです。第二に、パケットの最初のルーターとして機能し、ソースルーティングを効果的に実行します。つまり、特派員ノードがパケットを送信している場合、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.
セキュリティの目標として、モバイルIPv6設計は、「（非モバイル）IPv4インターネットと同じくらい安全である」ことを目的としていました。特派員ノードとホームエージェントの間に自分自身を取り付けることができる攻撃者。理論的根拠は単純です。2001年のインターネットでは、ノードが2つの任意のノード間の通信パスにそれ自体を接続できた場合、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. Noel 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.
Eidsと恒久的なロケーターの関係は、他の提案によって悪用されています。ただし、技術的なメリットとセキュリティの問題は、このドキュメントの範囲を超えています。
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を作成し、次に慎重に選択された時間で期限切れにすることで攻撃を開始することもできます。大量のトラフィックを運ぶ多数のアクティブなBCEが同時に期限切れになった場合、結果はホームエージェントまたはホームネットワークに向かって過負荷になる可能性があります。（より詳細な説明については、セクション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つ以上のメッセージを送信する必要があるということです。したがって、メッセージのみを観察するが送信しない攻撃者を考慮することはほとんど意味がありません。実際、いくつかのアクティブな攻撃は、平均的な攻撃者にとって、受動的な攻撃よりも打ち上げられやすいです。つまり、多くのアクティブな攻撃では、攻撃者はいつでもバインディングアップデート処理を開始できますが、ほとんどのパッシブ攻撃では、攻撃者がターゲットノードによって適切なメッセージが送信されるのを待つ必要があります。
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.1）を持つことになっているノードに対する攻撃、洪水攻撃（セクション3.2）の継続、および基本的なバインディングアップデートプロトコル（セクション3.3）に対する攻撃を検討します。その後、攻撃の分類を提示します（セクション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の最も明白な危険は、攻撃者が特定のアドレスで特定のノードであると非gimit的に主張し、そのアドレスに運命づけられたトラフィックを「盗む」ことを試みた場合、アドレス「盗む」です。最初に、この攻撃の基本的なバリアントについて説明し、ターゲットが静止ノードである場合、状況がどのように影響を受けるかについて説明し、タイミング（いわゆる「将来の」攻撃）、機密性と整合性、より複雑な問題を継続します。および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ノードに送信することを検討してください。攻撃者は、バインディングアップデートのホームアドレス（HOA）をBindingアップデートを送信することにより、パケットを任意のアドレスcにリダイレクトできます。Bおよび住所の世話（COA）はCになります。このバインディングアップデートを受信した後、AはノードB用のすべてのパケットをアドレスCに送信します。図2を参照してください。
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.
攻撃者は、パケットのソースの両方のIPアドレス（上記の例のA）とパケットの宛先（B、上）を知るか推測する必要があります。これは、攻撃者が通信しているすべてのノードの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.
サーバーやStateful構成を使用しているものなど、よく知られているアドレスを持つノードが最も脆弱です。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に登録すると、より露出します。同様に、空港ワイヤレスLANSなどの公開されたネットワークにアクセスするノードは、アドレスを明らかにするリスクがあります。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はまだ効果的であり、攻撃者は成功した中間または拒否を開始することができます - サービス攻撃。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とBとの接続のふりをするか、新しいスプーフィングされた接続を確立することができます。攻撃者は、AとBの両方にスプーフィングされたバインディングアップデートを送信し、それらの間のすべての接続の中央に挿入することもできます（中間攻撃）。その結果、攻撃者はAとBの間に送信されたパケットを見て変更することができます。図3を参照してください。
Original data path, before man-in-the-middle attack
中間の攻撃の前の元のデータパス
+---+ +---+
| A | | B |
+---+ +---+
\___________________________________/
Modified data path, after the falsified binding updates
偽造されたバインディングの更新後、変更されたデータパス
+---+ +---+
| A | | B |
+---+ +---+
\ /
\ /
\ +----------+ /
\---------| Attacker |-------/
+----------+
Figure 3. Man-in-the-Middle Attack
図3.中間攻撃
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セキュリティ設計で採用されている保護は、攻撃が可能なトポロジカル位置を制限するReturn Routability（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（「リプレイ攻撃の防止」）に従って、バインディングキャッシュエントリを削除するときにケアを行使する必要があります。
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.
最も単純な攻撃では、攻撃者はノードAからBへの重いデータストリームがあることを知っており、これをターゲットアドレスCにリダイレクトします。ただし、AはBから謝辞を受け取っていないためデータの送信をすぐに停止します。
(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を参照してください。最初にデータストリーム（ビデオストリームなど）を購読し、このストリームをターゲットアドレス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 Lifetimeの数分までの制限は、追加の措置なしにここでは役立ちません。
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 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.
モバイルIPv6設計プロセス中に、この攻撃の有効性が議論されました。ターゲットノードが不要なデータストリームのソースにTCPリセットを送信し、送信を停止すると誤って想定されていました。実際には、すべての実用的なTCP/IP実装はリセットの送信に失敗します。ターゲットノードは、着信パケットのルーティングヘッダーに対応するバインディングアップデートリストエントリがないため、IPレイヤーに不要なパケットをドロップします。したがって、洪水データはターゲットノードの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).
[6]のセクション11.7.2（「特派員登録」）は、そのようなルート最適化手順をいつ開始する必要があるかを指定していません。それはいつ正当化できるかもしれないことを示しますが、これらのヒントでは十分ではありません。これは、より多くの作業が必要な領域のままです。明らかに、ルートの最適化がオプションであることを考えると、処理荷重が過剰または不当になっていることを発見するノードは、単にそれを（選択的または完全に）オフにすることができます。
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]。つまり、ターゲットに直接パケットの洪水を送信する代わりに、攻撃者は他のノードにデータを送信し、同じ数字、またはそれ以上のパケットをターゲットに送信するためにそれらをトリックします。このような反射は、イングレスフィルタリングがソースアドレスのスプーフィングを防ぐ場合でも、攻撃者のアドレスを隠すことができます。パケットを複数回反射できる場合、ループパスに送信できる場合、またはノードをだまして攻撃者から受け取るよりも多くのパケットを送信できる場合、反射は特に危険です。重要な要因によるトラフィック。プロトコルを設計するときは、反射と増幅に使用できるサービスの作成を避ける必要があります。
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つはホームアドレスに、もう1つは住所に1つ）を使用して、モバイルからの最初のメッセージに応答しました。これを使用して、2倍の洪水攻撃を増幅することが可能だったでしょう。さらに、パブリックキー認証により、特派員が送信したパケットは、それらをトリガーするパケットよりも大幅に大きかった可能性があります。
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は、任意のノードのペアで使用できるキー管理のインフラストラクチャに依存しています。このような「グローバル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です。このようなスキームは、キーRRの新しいアプリケーションを構成するため、既存の仕様によって完全にサポートされていません。それにもかかわらず、それを定義する場合、次の行に沿って進むことができます。各IPアドレスに公開キーを提供する安全な逆鍵を使用して、拘束力のある更新が実際に認定当事者によって署名されていることを確認できます。ただし、安全にするためには、そのようなシステムの各リンクは安全でなければなりません。つまり、ルートから（または少なくともモバイルノードと特派員ノードに共通するトラストアンカーから、指定された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で説明されている脅威を防止または軽減するために慎重に設計されています。パケット、遅延、処理の観点から許容可能なコスト。結果は、予想されるものではありません。それは間違いなく従来の暗号化プロトコルではありません。代わりに、結果は、腐敗していないルーティングインフラストラクチャの仮定に大きく依存しており、モバイルノードの疑いが自宅の住所とそのケアアドレスの両方を通じて実際に到達可能であることを確認するという考えに基づいています。さらに、対応したノードで作成された状態の寿命は、潜在的な脅威を時間シフトから制限するために、意図的に数分に制限されています。
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.
Return Routability（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.
基本的な返品ルー上のメカニズムは、ホームアドレスチェック（セクション4.1.1を参照）とアドレスのケアチェック（セクション4.1.2を参照）の2つのチェック（セクション4.1.1を参照）で構成されています。パケットフローを図7に示します。最初に、モバイルノードは2つのパケットを特派員ノードに送信します。ホームテストinit（hoti）パケットがホームエージェントを介して送信され、テストのケアinit（coti）が直接送信されます。特派員ノードは、ホームテストの初期化に応じてホームテスト（HOT）とテストケアのケアイニシ様に応じて送信することにより、これらの両方に独立して応答します。最後に、モバイルノードがホームテストとケアオブテストパケットの両方を受信すると、Cresserment Nodeにバインディングアップデートを送信します。
+------+ 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.
実際のデザインはやや複雑であったように見えるかもしれません。つまり、実際の返品ルー上のチェックは、メッセージペア<ホームテスト、バインディングアップデート>および<ケアオブテスト、バインディングアップデート>です。ホームテストINITとテストのケアパケットは、テストパケットをトリガーするためにのみ必要であり、バインディングアップデートは両方のテストに対するルー上の応答の組み合わせとして機能します。
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).
o 州の消耗DOS攻撃の回避（セクション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つのinitパケットを送信する理由は、増幅を避けるためです。特派員ノードはモバイルノードについて何も知らないため、任意のIPアドレスから未承諾IPパケットを受信するだけです。ある意味では、これは、以前に不明なクライアントからTCP synを受信したサーバーに似ています。セクション3.3.3で説明したように、特派員ノードが初期トリガーに応じて2つのパケットを送信する場合、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.
このスキームは、潜在的な反射攻撃の提供も回避します。特派員ノードがパケットのソースアドレス以外のアドレスに返信する場合、それは反射効果を作成します。したがって、素朴な特派員に可能な唯一の安全なメカニズムは、受信した各パケットに1つのパケットだけで返信し、受信したパケットのソースアドレスに返信することです。したがって、1つだけでなく、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）で構成されています。ホームテストinit（hoti）の到着によって引き起こされます。特派員ノードは、ホームテストINITのソースアドレスにホームテストを送信することにより、ホームテストINITに応答します。ソースアドレスはモバイルノードのホームアドレスであると想定されるため、ホームエージェントによってモバイルノードのホームテストがトンネルされると想定されます。ホームテストには、暗号化されたトークンであるホームキーゲントークンが含まれています。これは、秘密の鍵、KCNの連結、特派員ノード、ホームテストINITパケットのソースアドレス、およびnonce。
home keygen token = hash(Kcn | home address | nonce | 0)
ホームkeygenトークン=ハッシュ（kcn |ホームアドレス| nonce | 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のインデックスもホームテストパケットに含まれており、特派員ノードが適切な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.
ほとんどの場合、ホームテストパケットは、インターネットの2つの異なるセグメントに転送されます。最初に、特派員ノードからホームエージェントに移動します。この旅行では、保護されておらず、パス上の盗聴者はその内容を学ぶことができます。ホームエージェントは、パケットをモバイルノードに転送します。このパスは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.
最初は、特派員ノードとモバイルノードの間で保護されていないため、ホームエージェントとモバイルノードの間のパケットを保護する必要がないように聞こえるかもしれません。インターネット内のすべてのリンクが同様に不安定であれば、追加の保護は不要です。ただし、ほとんどの実用的な設定では、ネットワークはモバイルノードの近くよりもホームエージェントの近くで安全になる可能性があります。たとえば、ホームエージェントが仮想ホームリンクをホストし、モバイルノードが実際に自宅にいることはない場合、盗聴者は、特派員ノードの近くまたは特派員ノードとホームエージェントの間のパスにある必要があります。ホームエージェント。特派員ノードが主要なサーバーである場合、それとホームエージェントの間のパス上のすべてのリンクはかなり安全である可能性があります。一方、モバイルノードはおそらくワイヤレスアクセステクノロジーを使用しているため、アクセスリンクを盗聴するのが簡単な場合があります。したがって、モバイルノードに到達するパケットを盗聴するのはかなり簡単です。その結果、CN-HAパスが保護されていない場合でも、HA-MNパスを保護することは、実際のセキュリティ利益を提供する可能性があります。
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.
特派員のノードの観点から、アドレスのケアチェックはホームチェックに非常に似ています。唯一の違いは、現在、受信したケアオブテストINITパケットのソースアドレスがモバイルノードのケアアドレスであると想定されていることです。さらに、トークンは、ホームトークンを使用してトークンのケアを使用することを不可能にするために、またはその逆で、わずかに異なる方法で作成されます。
care-of keygen token = hash(Kcn | care-of address | nonce | 1)
Kear-of Keygenトークン=ハッシュ（kcn |ケアオブアドレス| nonce | 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.
特派員ノードは、最初のバインディングアップデートを受信するまでステートレスのままにすることができます。つまり、ホームテストINITとテストのケアイニシ様メッセージの受信と返信を記録する必要はありません。ホームテストINIT/ホームテストとケアオブテストの初期化/ケアオブテスト交換は、並行して、しかし互いに独立して行われます。したがって、特派員はすぐに各メッセージに応答することができ、それを覚えておく必要はありません。これは、潜在的なサービス拒否の状況に役立ちます。ホームテストINITとテストのケアINITメッセージを処理するためにメモリを予約する必要はありません。さらに、ホームテストINITとテストのケアイニシ式処理は、軽量になるように設計されており、必要に応じてレート制限できます。
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.
最初のバインディングアップデートを受信すると、特派員ノードはかなり複雑な手順を実行します。この手順の目的は、最近ホームテストを受けたモバイルノードと、それぞれ請求されたホームとケアオブアドレスに送信されたモバイルノードがそれぞれ存在することを確認し、特派員を確認することです。Nodeは、このチェックを実行している間、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.
ホームアドレス：バインディングアップデートで指定されているホームアドレスは、ホームテストINITメッセージで使用されるソースアドレスに等しくなければなりません。
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.
2つのNonCEインデックス：これらはホームテストとテストのケアメッセージからコピーされ、他の情報とともに、特派員ノードがホームテストとテストのケアメッセージで送信されたトークンを再作成し、使用することを許可します。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.
アドレス、NonCEインデックス（およびそれによってNonces）とキー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.
特派員ノードは、有効なバインディングアップデートを受信するまでステートレスのままである可能性があるため、モバイルノードは再送信に対して単独で責任を負うことに注意してください。つまり、モバイルノードは、ホームテスト /ケアオブテストがそれぞれ受信されるまで、ホームテストINIT /ケアオブテストINITメッセージを送信し続ける必要があります。同様に、輸送中に失われた場合、バインディングアップデートを数回送信する必要がある場合があります。
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.
セキュリティデザインと目標の他の側面には短い寿命が必要ですが、効率性と堅牢性にとって明らかに有害です。つまり、ホームテストINIT /ホームテストメッセージペアは、数分ごとにホームエージェントを介して交換する必要があります。これらのメッセージは、純粋に機能的な観点からは不要であり、それによってオーバーヘッドを表します。さらに悪いことに、彼らはホームエージェントを単一の失敗ポイントにしているということです。つまり、ホームテストINIT /ホームテストメッセージが不要な場合、モバイルノードから他のノードへの既存の接続は、ホームエージェントが故障した場合でも継続する可能性がありますが、現在の設計により、数分後にバインディングが期限切れになります。
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では、隣接するノードに対する攻撃について説明します。最後に、セクション5.4は、ルート最適化手順を互いに会話して実行する2つのモバイルノードの特別なケースを扱います。
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）を遅らせることができます。これは、IPv4とは異なり、攻撃者は2つのホスト間のパス上にある限り攻撃を続けることができます。
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.
ホームアドレスチェック：ホームアドレスチェックを暗号化資格情報に置き換える場合、これらは特定のホームアドレスに対して適切な承認を保持する必要があり、証明書の発行者がそのような承認を表明する権利があることを確認するために注意する必要があります。設計作業の時点で、ルート最適化セキュリティデザインチームは、これを行うための標準化された証明書形式を認識していませんでしたが、IETF内での最近の取り組みはこの問題に対処しています。特派員ノードとの既存の関係には、モバイルノードのホームアドレスが含まれているため（その可能性のあるアドレスのいずれかではなく）、それを行う動機がたくさんあることに注意してください。したがって、IKE Exchangeは、通信者ノードとモバイルノードのホームアドレスの間で最も自然に実行されます。これにより、モバイルノードのケアオブアドレスをチェックするという問題がまだ開かれています。
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.
住所のケアチェック：アドレスドレスのケアチェックに関しては、実際には、ノードがアドレスドレスのケアチェックを資格情報に完全に置き換える可能性は非常に低いようです。一般的に、住所の世話は短命であるため、モバイルノードが額面（任意の特派員ノードによって）で取られた資格情報を提示することは非常に困難です。前に説明したように、到達可能性チェックは、そのような攻撃を軽減するのに大いに役立ちます。通常のプロトコル交換の一環として、IKEを介してIPSECセキュリティ協会の確立には、そのような到達可能性テストが1つ含まれていることに注意してください。ただし、前のセクションによると、自然な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.
セキュリティ設計に対する攻撃の1つは、隣接するノードのふりをすることです。この攻撃を開始するために、モバイルノードは、任意の特派員ノードを使用したルート最適化を確立します。返品ルー上のテストを実行し、拘束力のある管理キー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.
私たちは感謝しています：ヘシャム・ソリマンは、セクション5.3、フランシス・デュポンで説明されている脅威について私たちに思い出させてくれて、2つのモバイルノードが互いに話し合っている（セクション5.4）、そして雑然とした他のコメントについて、ペッカ・サヴォラはセクションで彼の助けを求めています1.1.1、およびElwyn Daviesの徹底的な編集レビュー。
[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] Aura、T.、Roe、M。、およびJ. Arkko、「インターネットロケーション管理のセキュリティ」、Proc。第18回年次コンピューターセキュリティアプリケーション会議、ページ78-87、ラスベガス、ネバダ州、米国、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. Simpson、「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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[4] Bush、R。and D. Meyer、「いくつかのインターネットアーキテクチャガイドラインと哲学」、RFC 3439、2002年12月。
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[5] Baker、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] Johnson、D.、Perkins、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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Savage、S.、Cardwell、N.、Wetherall、D。、およびT. Anderson、「誤動作レシーバーによる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 Worldにおけるサービス拒否、住所所有権、および早期認証」、セキュリティプロトコル9番目の国際ワークショップ、ケンブリッジ、英国、2001年4月25〜27日、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
Authors' Addresses
著者のアドレス
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Pekka Nikander Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Jari Arkko Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Jari Arkko Ericsson Research Nomadiclab Jorvas Fin-02420フィンランド
EMail: jari.arkko@ericsson.com
Tuomas Aura Microsoft Research Ltd. Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom
Tuomas Aura Microsoft Research Ltd. Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB英国
EMail: Tuomaura@microsoft.com
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: gabriel_montenegro_2000@yahoo.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park、CA 94025 USA
EMail: erik.nordmark@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。