RFC4225 日本語訳
4225 Mobile IP Version 6 Route Optimization Security DesignBackground. P. Nikander, J. Arkko, T. Aura, G. Montenegro, E.Nordmark. December 2005. (Format: TXT=98584 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Nikanderがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4225年のJ.Arkkoカテゴリ: 情報のエリクソンのG.モンテネグロマイクロソフト社E.Nordmarkサン・マイクロシステムズ研究NomadicLab T.香気マイクロソフト研究2005年12月
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)インターネット協会(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)ルートOptimizationセキュリティデザインの後ろの原理の記述です。 このドキュメントの目的は、考えを示して、2002年に2001--モバイルIPv6セキュリティデザインの後ろに推理を保存することです。
The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs.
ドキュメントには、2人の対象者がいます: (1) MIPv6作成者は、よりよくMIPv6セキュリティ手順でデザイン選択を理解していて、それらのデザインで移動性かマルチホーミングに対処する人々が多くの潜在的セキュリティ落とし穴を避けることができる(2)を理解しているのを助けます。
Nikander, et al. Informational [Page 1] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[1ページ]のRFC4225
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
1. 序論…3 1.1. 既存のIPインフラストラクチャに関する仮定…4 1.2. 移動性問題とモバイルIPv6ソリューション…6 1.3. 原則と目標を設計してください…8 1.3.1. 終わりから終わりへの原則…8 1.3.2. 仮定を信じてください…8 1.3.3. 保護レベル…8 1.4. モバイルIPv6 MobilityとそのVariationsに関して…9 2. 攻撃のアベニュー…9 2.1. 狙います。10 2.2. タイミング…10 2.3. 位置…11 3. 脅威と制限…11 3.1. アドレス'所有者'(「アドレス横取り」)に対する攻撃。 ...12 3.1.1. 基本的なアドレス横取り…12 3.1.2. 静止したノードの横取りのアドレス…13 3.1.3. 将来のアドレス封…14 3.1.4. 秘密保持と保全に対する攻撃…15 3.1.5. 基本的なサービス不能攻撃…16 3.1.6. 拘束力があるアップデートを再演して、妨げます…16 3.2. 他のノードとネットワーク(氾濫)に対する攻撃…16 3.2.1. 基本的な氾濫…17 3.2.2. リターンからホームへの氾濫…18 3.3. 結合に対する攻撃はプロトコルをアップデートします…18 3.3.1. 不要な拘束力があるアップデートを引き起こします…19 3.3.2. 非最適化されたルート設定を強制します…20 3.3.3. 反射と増幅…21 3.4. 攻撃の分類…22 3.5. インフラストラクチャベースの承認に関する問題…23 4. モバイルIPv6のために選択されたソリューション…24 4.1. Routabilityを返してください…24 4.1.1. ホームアドレスチェック…26 4.1.2. アドレス検査の注意…27 4.1.3. 最初の拘束力があるアップデートを形成します…27 4.2. 安全に状態を創設します…28 4.2.1. Retransmissionsと州のマシン…29 4.3. Binding Cache Entriesの迅速な満了…29 5. セキュリティ問題…30 5.1. IPv4と比較される残りの脅威…31 5.2. IPsecとの相互作用…31 5.3. 人の隣人であるふりをします…32 5.4. 互いに話す2つのモバイルノード…33 6. 結論…33 7. 承認…34 8. 有益な参照…34
Nikander, et al. Informational [Page 2] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[2ページ]のRFC4225
1. Introduction
1. 序論
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
セクション1.1の序論は既にモバイルIPv6に詳しい読者にとって余分に見えるかもしれませんが、とにかくそれを読むのは貴重であるかもしれません。 本書では取られたアプローチはまさしくそのです。
Nikander, et al. Informational [Page 3] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[3ページ]のRFC4225
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.
それと、モバイル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).
特に、このドキュメントは「リターンRoutability」(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はこのドキュメントを結論づけます。
1.1. Assumptions about the Existing IP Infrastructure
1.1. 既存のIPインフラストラクチャに関する仮定
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
これらの仮定は些細であるように見えるかもしれませんが、それらをもう少し探りましょう。 まず最初に、現在のIPv6操作上の習慣では、IPアドレス接頭語は階層的な方法で分配されます。 これはそれぞれの個々のルータが扱う必要がある経路指定テーブルエントリーの数を制限します。 重要な含意はそれです。
Nikander, et al. Informational [Page 4] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[4ページ]のRFC4225
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).
トポロジーは、どんなグローバルに発送可能なIPアドレスが与えられた位置で利用可能であるかを決定します。 すなわち、ノードは、どんなグローバルに発送可能なIPアドレスを使用したらよいかを自由に決めることができません。 彼らはRouter Advertisementsを通したローカルルータか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.
2番目に、現在のインターネット構造では、ルータは、ネットワーク形態とフォワードの分散データベースが各パケットであることをパケットで運ばれた送付先アドレスで断固とした位置に向かってまとめて支持します。 トポロジー情報を保守するために、ルータは互いを少なくともある程度まで信じなければなりません。 ルータは他のルータからトポロジー情報を学びます、そして、それらには、遠方のトポロジーに関してそれらの隣人ルータを信じる以外のオプションが全くありません。 管理ドメインの境界では、政策ルールは、恐らく同輩ドメインから受け取られた不完全な経路指定テーブル情報の量を制限するのに使用されます。 これは管理誤りを取り外すのにほとんど使用されますが、また、それはセキュリティで助かります。 目的はだれかが不完全な情報をルーティングシステムに提供していてもネットワーク形態の合理的に正確な考えを維持することです。
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セキュリティ問題による例えばどんな取り組みも)を保証するいかなる他の取り組みも絶望的にするでしょう。
1.1.1. A Note on Source Addresses and Ingress Filtering
1.1.1. ソースアドレスとイングレスフィルタリングに関する注
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
本書では議論した脅威と攻撃のいくつかがソースアドレススプーフィングの容易さを利用します。 すなわち、現在のインターネットでは、誤ったソースIPアドレスがあるパケットを送るのは可能です。 イングレスフィルタリングの最後の導入がこれを防ぐと思われます。 イングレスフィルタリングが使用されているとき、偽造しているアドレスがあるトラフィックは進められません。 異なったネットワーク境界でこのフィルタリングを適用できます、インターネット接続サービス業者(ISP)とその顧客か、川下の、そして、上流のISPか、同輩ISP[5]の間のそれらなどのように。 明らかに、イングレスフィルタの粒状は、あなたがどれほど「接頭語では、だますことができるか」を指定します。 例えば、ISPイングレスが顧客のリンクをフィルターにかけますが、顧客が何もしないなら、顧客のもの/48接頭語における何でも偽造されるかもしれません。 顧客がそうするなら
Nikander, et al. Informational [Page 5] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[5ページ]のRFC4225
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].
LANサブネットでフィルターにかけて、/64接頭語における何でも偽造することができました。 そのような「接頭語におけるスプーフィング」で課された制限にもかかわらず、一般に、イングレスフィルタリングは、トラフィックが本当のソースネットワーク[5]に起因しているのを可能にします。
However, ingress filtering helps if and only if a large part of the Internet uses it. Unfortunately, there are still some issues (e.g., in the presence of site multi-homing) that, although not insurmountable, do require careful handling, and that are likely to limit or delay its usefulness [5].
そして、しかしながら、イングレスフィルタリングが助ける、インターネットのかなりの部分がそれを使用する場合にだけ。 残念ながら、まだ、いくつかの有用性[5]を打ち勝ちがたくはありませんが、取り扱いに注意を要している、制限しそうであるか、または遅らせそうな問題(例えば、サイトマルチホーミングがあるとき)は、あります。
1.2. The Mobility Problem and the Mobile IPv6 Solution
1.2. 移動性問題とモバイルIPv6ソリューション
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つの問題を解決することを目指します。 まず最初に、それで、基本的なホストがそれらのIPアドレスを動かし、変えても、トランスポート層セッション(TCP接続、UDPはトランザクションを基礎づけた)は続きます。 2番目に、それは、ノードに静的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)がモバイルノード(ミネソタ)のための静止したプロキシとして働いているのを許容することです。 モバイルノードがホームネットワークから離れているときはいつも、ホームのエージェントがノードに運命づけられたパケットを妨害して、ノードの現在のアドレスにそれらにトンネルを堀ることによってパケットを進める、注意、-、(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.
基本解決法はホームのエージェントを通してトンネルを堀って、その結果、より長い経路と降格している性能に通じるのを必要とします。 計画されていて、モバイルノードから同輩までのパケットが直接横断を静めるかもしれないのが、元々呼ばれて以来、このトンネリングは時々三角形のルーティングと呼ばれます、ホームのエージェントを迂回させて。
Nikander, et al. Informational [Page 6] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[6ページ]のRFC4225
+----+ +----+
| MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA |
+----+ ____________ +-#--+
| CoA ___/ \_____ # Home Link
-+-------/ Internet * * *-*-*-*-#-#-#-#-----
| * * | * Home Address
\___ * * _____/ + * -+
\_____*______/ | MN |
* + - -+
+----+
| CN | Data path as * * * *
+----+ it appears to correspondent node
+----+ +----+ | ミネソタ|=#=#=#=#=#=#=#=#=トンネル=#=#=#=#=#=#は#=#と等しいです。|#ハ| +----+ ____________ +-#--+ | CoA___/ \_____ # ホームリンク-+-------/インターネット******####----- | * * | * ホームアドレス、\___ * * _____/ + * -+ \_____*______/ | ミネソタ| * + - -+ +----+ | CN| ****+としてのデータ経路----+ それは通信員ノードに現れます。
Real data path # # # #
本当のデータ経路####
Figure 1. Basic Mode of Operation in Mobile IPv6
図1。 モバイルIPv6の基本的な運転モード
To alleviate the performance penalty, Mobile IPv6 includes a mode of operation that allows the mobile node and its peer, a correspondent node (CN), to exchange packets directly, bypassing the home agent completely after the initial setup phase. This mode of operation is called route optimization (RO). When route optimization is used, the mobile node sends its current care-of address to the correspondent node, using binding update (BU) messages. The correspondent node stores the binding between the home address and care-of address into its Binding Cache.
パフォーマンスに不利な条件を軽減するために、モバイルIPv6はモバイルノードとその同輩(初期のセットアップフェーズの完全に後に直接パケットを交換するためにホームのエージェントを迂回させる通信員ノード(CN))を許容する運転モードを含んでいます。 この運転モードは経路最適化(RO)と呼ばれます。 経路最適化が使用されているとき、モバイルノードが電流を送る、注意、-、拘束力があるアップデート(BU)メッセージを使用して、通信員ノードに扱います。 そして、対応であっているノードがホームアドレスの間の結合を保存する、注意、-、Binding Cacheへのアドレス。
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経路最適化データ構造に相談して、必要なら、パケットを別ルートで送ります。 そして、Binding Cache Entry(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.
通信員ノードを残すパケットが掘られたソースである、注意、-、アドレス。 各パケットはモバイルノードに関するホームアドレスを含むルーティングヘッダーを含んでいます。 そして、このようにして、そして、論理的に、パケットが最初に発送される、注意、-、アドレス、そして実際には、注意、-、ホームアドレスへのアドレス。 もちろん、実際には、パケットがモバイルノードによって消費される、注意、-、アドレス。 ヘッダーがモバイルノードに1の代わりにホームアドレスに関連しているソケットをただ選択させる、注意、-、アドレス しかしながら、メカニズムはソースルーティングに類似しています、通信員ノードでかかわるルーティング状態があって、ルーティングヘッダーが使用されているとき。
Nikander, et al. Informational [Page 7] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[7ページ]のRFC4225
Nevertheless, this routing header is special (type 2) to avoid the risks associated with using the more general (type 0) variant.
それにもかかわらず、このルーティングヘッダーは、より一般的な(0をタイプする)異形を使用すると関連している危険を避けるために特別です(2をタイプします)。
1.3. Design Principles and Goals
1.3. 設計原理と目標
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デザインとセキュリティデザインが終わりから終わりへの原則に従って、ノードの間の信頼関係で違いに気付いて、実用的にaを提供することに関して明白であることを目指した、(過剰野心満々である、)、保護のレベル。
1.3.1. End-to-End Principle
1.3.1. 終わりから終わりへの原則
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の場合では、終わりから終わりへの原則は、移動性関連の状態を主としてホームのエージェントに制限することによって、適用されます。 また、経路最適化が使用されているなら、さらに、通信員ノードがモバイルノードのものに関連する軟性国家を現在に維持する、注意、-、アドレス(Binding Cache) 基本的なルーティングシステムの中で独特のホストルートを使用するアプローチに対してこれを対照できます。 そのようなアプローチはネットワークの周りの巨大な数のルータに状態を創設するでしょう。 モバイルIPv6では、ホームのエージェントと交信ノードだけが、状態を創設する必要があります。
1.3.2. Trust Assumptions
1.3.2. 信頼仮定
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がスケーラブルな方法で機能するのを許容します、通信員ノードにおける構成を必要としないで。
1.3.3. Protection Level
1.3.3. 保護レベル
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
セキュリティ目標、デザインが目的としたモバイルIPv6として、デザイン時点で、同じくらい「(非モバイル)のIPv4インターネットと同じくらい安全であること」がありました、2002年の2001--時代に。 特に、それは、通信員ノードとホームのエージェントの間で自分たちを付けることができる攻撃者に対する保護がほとんどないことを意味します。 原理は簡単です: 2001年のインターネットでは、ノードはaであるならそれ自体を付けることができました。
Nikander, et al. Informational [Page 8] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[8ページ]のRFC4225
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.
2つの任意のノードの間の通信路、2つのノードの間のすべてのトラフィックを混乱させて、変更して、盗み聞くことができました、IPsec保護が使用されなかったなら。 IPsecが使用さえされたとき、攻撃者は、単にパケットを下げることによって、まだ選択的にコミュニケーションを妨げることができるでしょう。 また、2つのノードの間のルータのコントロールにおける攻撃者は、2つのノード(より実際ににせのデータの同等な流れる)の間のデータフローを第三者に向け直すことによって、フラッディング攻撃を仕掛けることができるでしょう。
1.4. About Mobile IPv6 Mobility and its Variations
1.4. モバイルIPv6 MobilityとそのVariationsに関して
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.
より抽象的な角度を取って、1つのアドレス(ホームアドレス)に送られるパケットを別のアドレスに向けるためにルーティング情報への地方の例外を管理するためのメカニズムとIPv6の移動性を定義できる、(注意、-、アドレス) 地方のルーティング例外(送信元経路)がダイナミックに作成されて、削除されるのは意味で管理されています、モバイルノードによって送られた指示によると。 それはルーティング例外がホームのエージェントだけで有効であるという意味で地方です、そして、通信員ノードでは、最適化はルートであるなら使用されています。 状態の作成された断片はルータによってまとめて運ばれた正常な位相的なルーティング情報に優越するという意味で例外です。
Using the terminology introduced by J. Noel Chiappa [14], we can say that the home address functions in the dual role of being an end- point identifier (EID) and a permanent locator. The care-of address is a pure, temporary locator, which identifies the current location of the mobile node. The correspondent nodes effectively perform source routing, redirecting traffic destined to the home address to the care-of address. This is even reflected in the packet structure: the packets carry an explicit routing header.
J.クリスマスChiappa[14]によって紹介された用語を使用して、私たちは、終わりであるニ重の役割におけるホームアドレス機能が識別子(EID)と永久的なロケータを向けると言うことができます。 注意、-、アドレス、純粋で、一時的なロケータはそうです。(それは、モバイルノードの現在の位置を特定します)。 事実上、対応であっているノードがホームアドレスに運命づけられたトラフィックを向け直すソースルーティングを実行する、注意、-、アドレス これはパケット構造に反映さえされます: パケットは明白なルーティングヘッダーを運びます。
The relationship between EIDs and permanent locators has been exploited by other proposals. Their technical merits and security problems, however, are beyond the scope of this document.
EIDsと永久的なロケータとの関係は他の提案で利用されました。 しかしながら、それらの技術的な長所と警備上の問題はこのドキュメントの範囲を超えています。
2. Avenues of Attack
2. 攻撃のアベニュー
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諸条件には、危険がBinding Cache Entries(BCE)の権限のない作成の可能性にあります。 攻撃の目標、攻撃のタイミング、および攻撃者の位置によって、攻撃の効果は異なります。
Nikander, et al. Informational [Page 9] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[9ページ]のRFC4225
2.1. Target
2.1. 目標
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自体は全くかかわる必要はありません。 その上、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を見てください)。
2.2. Timing
2.2. タイミング
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
モバイルIPv6関連の危険を理解することにおける重要な一面はタイミングです。 静止したIPv4ネットワークには、ノードと同時のノードが伝えるコミュニケーションの間には、攻撃者がいるに違いありません。 拘束力があるキャッシュエントリーを作成するモバイルIPv6能力によると、状況は変化します。 新たな脅威は作成されます。 適切な保護がなければ、攻撃者はしばらく、ホームのエージェントと対応であっているノードの間でそれ自体を付けることができて、BCEを作成してください。
Nikander, et al. Informational [Page 10] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[10ページ]のRFC4225
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.)
通信員ノード、位置を出てください、そして、絶え間なくモバイルノードの居場所に関する通信員ノードをアップデートしてください。 これで、BCEが有効なままで残っていた限り、通信員ノードはモバイルノードに運命づけられたパケットを不正確なアドレスに送るでしょう、すなわち、通常、通信員ノードがリブートされるまで。 また、逆も可能でしょう: また、攻撃者は、BCEを作成して、次に、慎重に選択された時に期限が切れながら、最初にで攻撃を開始できました。 多量のトラフィックを運ぶ多くのアクティブなBCEsが同時に期限が切れるなら、結果はホームのエージェントかホームネットワークに向かったオーバーロードでしょうに。 (より詳細な説明に関してセクション3.2.2を見てください。)
2.3. Location
2.3. 位置
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が保護のないBinding Updatesを送らせるなら、攻撃者はインターネットでどこからでもどんな通信員ノードにもBCEを作成できるでしょうに、単に詐欺的なBinding Updateを通信員ノードに送ることによって。 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インターネットでは、攻撃ノードは攻撃時点で存在していなければなりません、そして、適当な方法でそれらを置かなければならない、さもなければ、攻撃は第一に、可能でないでしょう。
3. Threats and Limitations
3. 脅威と制限
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 Route Optimizationに対する攻撃とモバイルIPv6がそれらに対してどんな保護メカニズムを適用するかを説明します。 攻撃者の目標は、通信員ノードの拘束力があるキャッシュを崩壊させて、パケットが間違ったアドレスに提供されることを引き起こすことである場合があります。 これは交信パーティーにおいて求められていないパケットを受けるアドレスでコミュニケーションの秘密保持と保全とサービスの原因否定(DoS)に感染することができます。 また、攻撃者はモバイルノード、ホームのエージェント、または通信員ノードのリソースがBinding Update(BU)メカニズムでくたくたになる特徴を利用するかもしれません。 このセクションの目的は様々なプロトコルメカニズムと彼らの制限の概要を提供することです。 メカニズムの細部はセクション4でカバーされています。
Nikander, et al. Informational [Page 11] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[11ページ]のRFC4225
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は、パケット(例えば、Binding Updates、ルーティングヘッダーまたはホームアドレスオプション)に潜在的により機密の情報を加えることによって、問題を悪化させます。 このドキュメントはこれらの攻撃を扱いません。
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)を持つべきであるノードに対して攻撃を考えます、基本的なBinding Updateプロトコル(セクション3.3)に対してフラッディング攻撃(セクション3.2)と攻撃を続行して。 その後に、私たちは攻撃(セクション3.4)の分類を提示します。 最終的に、私たちはグローバルなセキュリティインフラストラクチャ(セクション3.5)についてある種を当てにするソリューションの適用性を考えます。
3.1. Attacks Against Address 'Owners' ("Address Stealing")
3.1. アドレス'所有者'に対する攻撃(「アドレス横取り」)
The most obvious danger in Mobile IPv6 is address "stealing", when an attacker illegitimately claims to be a given node at a given address and tries to "steal" traffic destined to that address. We first describe the basic variant of this attack, follow with a description of how the situation is affected if the target is a stationary node, and continue with more complicated issues related to timing (so called "future" attacks), confidentiality and integrity, and DoS aspects.
モバイルIPv6で最も明白な危険はアドレス「横取り」です、攻撃者が与えられたアドレスの与えられたノードであると不合理に主張して、そのアドレスに運命づけられたトラフィックを「横取りしようとする」とき。 私たちは、最初にこの攻撃の基本的な異形について説明して、状況が目標が静止したノードであるならどう影響を受けるかに関する記述と共に続いて、タイミング(したがって、「将来」の攻撃と呼ばれる)に関連するより複雑な問題、秘密性、保全、およびDoS局面を続行します。
3.1.1. Basic Address Stealing
3.1.1. 基本的なアドレス横取り
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
Binding Updatesが全く認証されないなら、攻撃者は、インターネットでどこからでも偽造している拘束力があるアップデートを作って、送ることができるでしょうに。 通信員ノードが機能性であることを支えるすべてのノードがこの攻撃への知らず知らずの共犯になるでしょう。 as
Nikander, et al. Informational [Page 12] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[12ページ]のRFC4225
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 |
+----------+
+---+ オリジナル+---+ 新しいパケット+---+ | B| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| A|- - - - - - ->| C| +---+ パケット流動+---+ 流れ+---+ ^ | | 偽のBU: B->C| +----------+ | 攻撃者| +----------+
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ノード、拘束力があるアップデートにおけるホームアドレス(HoA)がそうするA.にBinding Updateを送ることによって別のIPノード、B.への攻撃者が向け直すことができたIPパケットに任意のアドレス、Cへのパケットを送るAがBであると考えてください、注意、-、アドレス(CoA)がこの拘束力があるアップデートを受けるC.Afterであるだろう、AはノードBのためにアドレスC.See図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アドレスにもなるように、扱います。 攻撃者がローカルを選んだ、注意、-、それが受信されるのを許容するのが、パケットであると扱ってください、そして、それは対応であっているノードに回答を送ることができるでしょう。 攻撃者のローカル+ネットワークのイングレスフィルタリングがBinding Updatesのスプーフィングを防ぎませんが、選ぶために攻撃者を強制する、注意、-、アドレス、ネットワークか使用へのそれ自身が内部からの、Alternateである、注意、-、サブオプションを扱ってください。
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セキュリティデザインに使用される拘束力があるアップデート承認メカニズムは、この脅威を緩和して、攻撃者の位置を通信員ノードとホームのエージェントの間の経路に制限することを主として意図します。
3.1.2. Stealing Addresses of Stationary Nodes
3.1.2. 静止したノードの横取りのアドレス
The attacker needs to know or guess the IP addresses of both the source of the packets to be diverted (A in the example above) and the destination of the packets (B, above). This means that it is difficult to redirect all packets to or from a specific node because the attacker would need to know the IP addresses of all the nodes with which it is communicating.
攻撃者は、紛らされるべきパケットの源(上記の例のA)とパケットの目的地(上のB)の両方のIPアドレスを知っているか、または推測する必要があります。 攻撃者は、それが交信する予定であるすべてのノードのIPアドレスを知る必要があるでしょう、したがって、これがノード、または、特定のノードからすべてのパケットを向け直すのが難しいことを意味します。
Nikander, et al. Informational [Page 13] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[13ページ]のRFC4225
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.
頻繁に住所を変更して、無作為のアドレスを使用するノードは比較的安全です。 しかしながら、自分達のアドレスをDynamic DNSに登録するなら、彼らはさらに暴露されるようになります。 同様に、空港無線LANなどの公的にアクセスしやすいネットワークを訪問するノードは、それらのアドレスを明らかにする危険を冒します。 プライバシーが特徴[3]であると扱うIPv6は、これらの危険を程度まで緩和しますが、それらのアドレスを使用する公開審議がまだある間完全にアドレスを再生できるというわけではないことに注意します。
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.
したがって、横取りの攻撃を扱うのは、最も被害を受け易いモバイルノードではありません。 それはよく知られる静的なサーバです。 その上、サーバは、しばしば古いか大いに最適化されたオペレーティングシステムを動かして、少しの移動性関連するコードも全く持っていないかもしれません。 したがって、セキュリティデザインはモバイルノードがだれかがそれらのアドレスを盗んだかどうか検出して、通信員ノードにどうにか状態をリセットできるかもしれないという考えに基づくことができません。 代わりに、セキュリティデザインは第一に詐欺的な拘束力があるキャッシュエントリーの作成を防ぐ妥当な測定をしなければなりません。
3.1.3. Future Address Sealing
3.1.3. 将来のアドレス封
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.
攻撃者がノードが将来選択しそうであるアドレスを知っているなら、それは、攻撃を横取りしながら、「将来」のアドレスを始めることができます。 攻撃者はそれが、目標ノードが使用すると予期するホームアドレスでBinding Cache Entryを作成します。 ホームのエージェントがダイナミックなホームアドレスを許すなら、攻撃者は合法的にこれができるかもしれません。 すなわち、攻撃者がホームのエージェントのクライアントであり、一時ホームアドレスを取得できるなら、そうして、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セキュリティデザインで適用されたメカニズムは数分までBinding Cache Entriesの生涯を制限することです。
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.
この攻撃がかなり特定の状態だけに適用されることに注意してください。 また、この攻撃のいくつかのある他の状態の下で理論的に可能な変化があります。 しかしながら、これらの攻撃のすべてがBinding Cache Entry生涯までに制限されます、そして、したがって、それらは現在のデザインがある本当の関心ではありません。
Nikander, et al. Informational [Page 14] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[14ページ]のRFC4225
3.1.4. Attacks against Secrecy and Integrity
3.1.4. 秘密保持と保全に対する攻撃
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.
スプーフィングBinding Updatesで、攻撃者は2つのIPノードの間のすべてのパケットをそれ自体に向け直すことができました。 偽造している拘束力があるアップデートをAに送ることによって、それはB.に意図するデータを得るかもしれません。ThatはそうですBとのBと乗っ取りAの接続であるふりをするかもしれませんか、またはそれは新しい偽造している接続を確立するかもしれません。 攻撃者は、また、偽造している拘束力があるアップデートをAとBの両方に送って、彼ら(介入者攻撃)の間のすべての接続の途中にそれ自体を挿入できました。 その結果、攻撃者は、AとBとの間に送られたパケットを、見て、変更できるでしょう。図3を見てください。
Original data path, before man-in-the-middle attack
介入者攻撃の前の元のデータ経路
+---+ +---+
| A | | B |
+---+ +---+
\___________________________________/
+---+ +---+ | A| | B| +---+ +---+ \___________________________________/
Modified data path, after the falsified binding updates
改竄された拘束力があるアップデートの後の変更されたデータ経路
+---+ +---+
| A | | B |
+---+ +---+
\ /
\ /
\ +----------+ /
\---------| Attacker |-------/
+----------+
+---+ +---+ | A| | B| +---+ +---+ \ / \ / \ +----------+ / \---------| 攻撃者|-------/ +----------+
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 Security Designに採用された保護はリターンroutability(RR)によるアドレスを認証する(弱いのですが)(セクション4.1を見てください)ことです。(routabilityは攻撃が可能である位相的な位置を制限します)。
Nikander, et al. Informational [Page 15] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[15ページ]のRFC4225
3.1.5. Basic Denial-of-Service Attacks
3.1.5. 基本的なサービス不能攻撃
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サーバ)に属すまた、被害を受け易い固定ノードを含んでいて。 一方、選択された保護メカニズムはリターンroutability(RR)です。
3.1.6. Replaying and Blocking Binding Updates
3.1.6. 拘束力があるアップデートを再演して、妨げます。
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.
関連する攻撃では、攻撃者は、新しい位置のモバイル、例えば、ラジオリンクを詰め込むか、またはフラッディング攻撃を仕掛けることによって、拘束力があるアップデートを妨げます。 そして、攻撃者は古い位置でモバイルの接続を持って行きます。 攻撃者は、モバイルに送られたパケットをキャプチャして、通信員のBinding Cacheエントリーが期限が切れるまで、モバイルをまねることができるでしょう。
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].
上の攻撃の両方が、攻撃者がモバイルがある同じ企業内情報通信網の一員であることを必要とします。(そこでは、モバイルが新しい位置に移行しないでも、それは、比較的容易にパケットを観察して、それらを妨げることができます)。 したがって、私たちは、これらの攻撃が離れた場所から取り付けることができるものほど重大でないと信じています。 Binding Cacheエントリーと関連一回だけの限られた寿命は反射攻撃が可能である時間枠を制限します。 反復操作による保護は一連番号とMACによってBinding Updateに提供されます。 拘束力があるキャッシュエントリーを削除するときこの保護を弱体化させないように、通信員ノードは注意しなければなりません、[6]のセクション5.2.8(「反射攻撃を防ぐ」)に従って。
3.2. Attacks Against Other Nodes and Networks (Flooding)
3.2. 他のノードとネットワークに対する攻撃(氾濫)
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
偽造している拘束力があるアップデートを送ることによって、攻撃者は任意のIPアドレスにトラフィックを向け直すことができるでしょう。 パケット('爆撃攻撃'として、知られている)の過度のボリュームで任意のインターネット・アドレスを積みすぎるのにこれを使用できました。 また、攻撃者はaを狙うことができました。
Nikander, et al. Informational [Page 16] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[16ページ]のRFC4225
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.
ネットワークの中の1つ以上のIPアドレスにデータを向け直すことによって、ネットワークでつなぎます。 氾濫の2回の主な変化があります: 基本的な氾濫とリターンからホームへの氾濫。 私たちは別々にそれらを考えます。
3.2.1. Basic Flooding
3.2.1. 基本的な氾濫
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.Howeverにこれを向け直して、Aは、すぐ、それがBから承認を受けていないのでデータを送るのを止めるでしょう。
(B is attacker)
(Bは攻撃者です)
+---+ original +---+ flooding packet +---+
| B |<================| A |==================>| C |
+---+ packet flow +---+ flow +---+
| ^
\ /
\__________________/
False binding update + false acknowledgements
+---+ オリジナル+---+ 氾濫パケット+---+ | B|<========| A|==================>| C| +---+ パケット流動+---+ 流れ+---+ | ^ \ / \__________________/誤った拘束力があるアップデート+誤った承認
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承認を作成できました。 いずれにせよ、多くの仕事自体をしないで、攻撃者は求められていないデータの増加するストリームをあて先アドレスに向け直すことができるでしょう。 より多くの初めのストリームとBinding Cacheエントリーをリフレッシュするとき、それは、あらゆる数分の新しい拘束力があるアップデートを送ることによって、運ばれることができるでしょう。 したがって、BCE生涯から数分の制限はここで追加措置なしで助けません。
During the Mobile IPv6 design process, the effectiveness of this attack was debated. It was mistakenly assumed that the target node would send a TCP Reset to the source of the unwanted data stream, which would then stop sending. In reality, all practical TCP/IP implementations fail to send the Reset. The target node drops the unwanted packets at the IP layer because it does not have a Binding
モバイルIPv6デザイン過程の間、この攻撃の有効性は討論されました。 目標ノードが次に発信するのを止めるだろう求められていないデータ・ストリームの源にTCP Resetを送ると誤って思われました。 ほんとうは、すべての実用的なTCP/IPインプリメンテーションはResetを送りません。 Bindingを持っていないので、目標ノードはIP層で求められていないパケットを下げます。
Nikander, et al. Informational [Page 17] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[17ページ]のRFC4225
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.
入って来るパケットの上のルート設定Headerに対応するListエントリーをアップデートしてください。 したがって、目標ノードのTCP層に氾濫データを決して処理しません、そして、Resetを全く送りません。 これは、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.
目標がモバイルものだけではなく、どんなノードやネットワークであるかもしれないのでも、この攻撃は重大です。 それを特に重大にする他の攻撃にたとえられたことは目標自体が攻撃を防ぐようなことを何もできないということです。 例えば、目標ネットワークが、Route Optimizationを使用するのを止めるなら、それは助かりません。 これらのテクニックが他の分配されたサービスの否定(DDoS)攻撃の効果を増幅するのに使用されるなら、損害は悪化します。 攻撃者の企業内情報通信網におけるイングレスフィルタリングがソースアドレスのスプーフィングを防ぎますが、攻撃がAlternateを設定することによってまだ可能であるだろう、注意、-、サブオプションをあて先アドレスに扱ってください。
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のために採用された保護メカニズムはリターンroutabilityです。 今回本当に、ノードが新しさにあるのをチェックするのが必要である、注意、-、アドレス、そして、ノードはまさしくそのアドレスに向け直すパケットを要求したもの(セクション4.1.2を見る)です。
3.2.2. Return-to-Home Flooding
3.2.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.
の代わりにする、爆撃攻撃の変化がホームアドレスかホームネットワークを狙うだろう、注意、-、アドレス、または、訪問されたネットワーク。 攻撃者は、あて先アドレスと等しいホームアドレスがあるモバイルであると主張するでしょう。 ホームから離れていると主張している間、攻撃者は、データ・ストリームをダウンロードし始めるでしょう。 攻撃者は、次に、拘束力があるアップデートキャンセル(すなわち、Binding Cacheから結合を削除するという要求)を送るか、またはキャッシュエントリーが期限が切れるのをただ許すでしょう。 どちらかがホームネットワークにデータ・ストリームを向け直すでしょう。 爆撃する、注意、-、アドレス、攻撃者は、ストリームを生かして、スプーフィング承認でデータ信号速度を増強さえできます。 うまくいって、ホームネットワークに対する爆撃攻撃がいつにそれとちょうど同じくらい重大であるか、注意、-、アドレス
The basic protection mechanism adopted is return routability. However, it is hard to fully protect against this attack; see Section 4.1.1.
採用された基本的な保護メカニズムはリターンroutabilityです。 しかしながら、この攻撃から完全に守りにくいです。 セクション4.1.1を見てください。
3.3. Attacks against Binding Update Protocols
3.3. 拘束力があるアップデートプロトコルに対する攻撃
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
首尾よく秘密保持とデータの完全性を保護するセキュリティプロトコルで、関係者は時々サービス不能攻撃により被害を受け易くなる場合があります。 事実上、認証、より簡単であるのは攻撃者が使用するようにそれがあるかもしれないより強いです。
Nikander, et al. Informational [Page 18] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[18ページ]のRFC4225
protocol features to exhaust the mobile's or the correspondent's resources.
モバイルのものを消耗させる特徴か通信員のリソースについて議定書の中で述べてください。
3.3.1. Inducing Unnecessary Binding Updates
3.3.1. 不要な拘束力があるアップデートを引き起こします。
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パケット(例えば、ピングか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ノードの本当のアドレスであるなら、拘束力があるアップデートプロトコルのほとんどのインスタンスが首尾よく完成さえするかもしれないその時です。 Binding Cacheで作成されたエントリーは、正しいのですが、無駄です。 このように、攻撃者は、モバイルが不必要に拘束力があるアップデートプロトコルを実行するのを引き起こすことができます(モバイルのリソースを消耗させることができます)。
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
それが処理に使用するリソース(すなわち、処理時間、メモリ、およびコミュニケーション帯域幅)の量における限界が付くように設定することによって、ノードは攻撃から我が身をかばうはずです。
Nikander, et al. Informational [Page 19] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[19ページ]のRFC4225
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層に、より高いプロトコル層でプロトコル状態に関して知るのが不可能であるかもしれないので、たぶんアドレスあたり過去のコミュニケーションの重要良い測定はパケットカウントです。 あるいはまた、Neighborディスカバリー[2](セクション5.1、Conceptual Data Structures)は最近トラフィックを送る目的地に関して1セットのエントリーとDestination Cacheを定義します。 したがって、作成者はDestination Cacheの情報を使用したがっているかもしれません。
Section 11.7.2 ("Correspondent Registration") in [6] does not specify
when such a route optimization procedure should be initiated. It
does indicate when it may justifiable to do so, but these hints are
not enough. This remains an area where more work is needed.
Obviously, given that route optimization is optional, any node that
finds the processing load excessive or unjustified may simply turn it
off (either selectively or completely).
セクション11.7 .2 [6]の(「通信員登録」)は、そのような経路最適化手順がいつ着手されるべきであるかを指定しません。 それはそうするかもしれません。いつかを示す、そうするのにおいて正当であることで、これらの唯一のヒントは十分ではありません。 これは、より多くの仕事が必要である領域のままで残っています。 明らかに、経路最適化が任意であるなら、処理負荷が過度である、または不正であることがわかるどんなノードも単にそれをオフにするかもしれません(選択的か完全に)。
3.3.2. Forcing Non-Optimized Routing
3.3.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.
前の攻撃の異形として、攻撃者が、通信員ノードが不要なエントリーでBinding Cacheを満たすことによって経路最適化を使用するのを防ぐことができるので、本当のモバイルのためのほとんどのエントリーが下げられます。
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
目標ノードはBinding Cacheのために、より多くのスペースを予約することによって、攻撃の効果を緩和できます、そうでなければ、DoS攻撃を切り抜けることができないときだけ非最適化されたルーティングに戻ることによって
Nikander, et al. Informational [Page 20] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[20ページ]のRFC4225
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.
積極的に、最適化されたルーティング、またはそれが確立した関係を持っているモバイルを支持することによって、戻ろうとします。 この攻撃は、より早く説明されたものほど重大ではありませんが、Route Optimizationを当てにするアプリケーションはまだ影響を受けることができました。 例えば、会話のマルチメディアセッションは三角形ルーティングで引き起こされた追加遅れに抜本的に苦しむことができます。
3.3.3. Reflection and Amplification
3.3.3. 反射と増幅
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)を受けて、ホームAddress Option(HAO)でモバイルノードによって与えられたホームアドレスに答えます。 モバイルは本当にモバイルでないかもしれません、そして、ホームアドレスは実際にあて先アドレスであるかもしれません。 目標は、パケットが通信員によって送られるのを見るだけであるだろう、攻撃者のアドレスは見ることができませんでした(攻撃者がイングレスフィルタリングによってソースアドレスを偽造することができないでも)。
+----------+ TCP SYN with HAO +-----------+
| Attacker |-------------------->| Reflector |
+----------+ +-----------+
|
| TCP SYN-ACK to HoA
V
+-----------+
| Flooding |
| target |
+-----------+
+----------+ HAO+とTCP SYN-----------+ | 攻撃者|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 反射鏡| +----------+ +-----------+ | | HoA V+へのTCP SYN-ACK-----------+ | 氾濫| | 目標| +-----------+
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
また、反射にひどく設計された拘束力があるアップデートプロトコルは使用できました: 通信員が拘束力があるアップデート認証プロトコルを開始することによってデータ・パケットに応じるだろう、どれ、通常
Nikander, et al. Informational [Page 21] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[21ページ]のRFC4225
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.
パケットをホームアドレスに送ることを伴います。 その場合、反射攻撃は、モバイルによって通信員に送られたメッセージにモバイルのアドレスをコピーすることによって、お勧めできないことができます。 通常、(のモバイルソースアドレスが同じである、注意、-、アドレス、Alternative Care、-、缶が指定するAddressサブオプションa異なる、注意、-、アドレス)。 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、注意、-、アドレス) 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セキュリティデザインに適用されました。
3.4. Classification of Attacks
3.4. 攻撃の分類
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
セクト。 名前Target Sevを攻撃してください。 緩和--------------------------------------------------------------------- 3.1.1 基本的なアドレス横取りのミネソタMed。 ミネソタLow RRと秘密保持に対する生涯3.1.4Attacksと保全ミネソタLow RR(IPsec3.1.5Basicサービス不能攻撃Any Med)を横取りするAny High RR3.1.3Futureが扱う静止したノードのRR3.1.2のStealingアドレス。 RR3.1.6Replayingとブロッキング結合はミネソタLow生涯アップデートします、seq番号、MAC3.2.1Basicが1Medあたり発見的教授法3.3.2Forcing非最適化されたルーティングミネソタLow発見的教授法3.3.3Reflectionと増幅N/のAny High RR3.2.2Returnからホームへの氾濫Any High RR3.3.1のInducingの不要な結合アップデートミネソタ(CN Med)をあふれさせて。 BUデザイン
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は議論した攻撃の概要をします。 これを書いている時点で立つように、ホームへのリターン氾濫と不要な拘束力があるアップデートの誘導は私たちが保護の最小量を持っている脅威に似ています、それらの厳しさと比べて。
Nikander, et al. Informational [Page 22] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[22ページ]のRFC4225
3.5. Problems with Infrastructure-Based Authorization
3.5. インフラストラクチャベースの承認に関する問題
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が任意の通信員ノードでBinding Updatesを固定するデフォルト方法であるかもしれないと思われました。 しかしながら、これは不可能であると判明しました。 明瞭な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) 当時、(2)がセキュリティ協会を証明するのにかかったIPsec(CPUと周遊旅行時間に関する)、および拘束力があるアップデート[13]のために、適切な承認(まさしく認証と対照的に)を言い表す(3)の状態に、不十分なフィルタリング粒状。 これらの問題は解決できます、そして、モバイルノードとホームのエージェント[7]の間には、拘束力があるアップデートがある状態で、特に、(1)と(3)はIPsec用法のために扱われました。
However, the lack of a global PKI remains unsolved.
しかしながら、グローバルなPKIの不足は未解決のままで残っています。
One way to provide a global key infrastructure for mobile IP could be DNSSEC. Such a scheme is not completely supported by the existing specifications, as it constitutes a new application of the KEY RR, something explicitly limited to DNSSEC [8] [9] [10]. Nevertheless, if one were to define it, one could proceed along the following lines: A secure reverse DNS that provided a public key for each IP address could be used to verify that a binding update is indeed signed by an authorized party. However, in order to be secure, each link in such a system must be secure. That is, there must be a chain of keys and signatures all the way down from the root (or at least starting from a trust anchor common to the mobile node and the correspondent node) to the given IP address. Furthermore, it is not enough that each key be signed by the key above it in the chain. It is also necessary that each signature explicitly authorize the lower key to manage the corresponding address block below.
グローバルな主要なインフラストラクチャをモバイルIPに提供する1つの方法がDNSSECであるかもしれません。 そのような体系は既存の仕様で完全にサポートされるというわけではありません、KEY RRの新しいアプリケーションを構成するとき、明らかにDNSSEC[8][9][10]に何か限られたもの。 それにもかかわらず、1つがそれを定義するなら、1つは以下のやり方で続くことができるでしょうに: 本当に、拘束力があるアップデートが認可されたパーティーによって署名されることを確かめるのにそれぞれのIPアドレスに公開鍵を提供した安全な逆のDNSは使用できました。 しかしながら、安全になるように、そのようなシステムのそれぞれのリンクは安全でなければなりません。 すなわち、キーと署名のチェーンが根(モバイルノードと通信員ノードに共通の信頼アンカーから少なくとも始めて)から与えられた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
上に示された系列に沿って安全な逆のDNSインフラストラクチャを築き上げるのが理論的に可能でしょうが、実用的な問題は威圧でしょう。 委譲と主要な署名は木の根の近くで働くかもしれませんが、それはたぶん経路に沿ったどこかで個々のノードに故障するでしょう。 同様の委譲木が現在Secure Neighborディスカバリー[15]のために提案されていることに注意してください、この場合唯一のルータ(必ずあらゆる潜在的モバイルノードでない)が、そのような証明書を固定する必要がありますが。 その上、木の上ですべての署名をチェックすると、かなりの負担が通信員ノードにかけられるでしょう、経路最適化を禁止、またはまさしくそのだけ少なくとも正当にして
Nikander, et al. Informational [Page 23] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[23ページ]のRFC4225
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.
特定の事情。 最終的に、モバイルノードが与えられたホームアドレスを含む拘束力があるアップデートを送るのが認可されるかどうか単にチェックするのは十分ではありません、氾濫から守るのが攻撃されるので注意、-、アドレス、また、確かめなければなりません。
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インフラストラクチャを当てにする、注意、-、アドレスはホームアドレスについて確かめるよりさらに困難でしょう。 代わりに、異なったメソッドが必要であるだろう、例えば、リターンはroutability手順です。 そして、そうだとすれば、明白な疑問が単にリターンを使用すると比べて、それが提供する追加保護をインフラストラクチャは価値があるグローバルな安全なDNSに配布する巨大な費用が両方のためにホームアドレスをroutabilityするかどうかということである、注意、-、検証を扱ってください。
4. Solution Selected for Mobile IPv6
4. モバイルIPv6のために選択されたソリューション
The current Mobile IPv6 route optimization security has been carefully designed to prevent or mitigate the threats that were discussed in Section 3. The goal has been to produce a design with a level of security close to that of a static IPv4-based Internet, and with an acceptable cost in terms of packets, delay, and processing. The result is not what one would expect: it is definitely not a traditional cryptographic protocol. Instead, the result relies heavily on the assumption of an uncorrupted routing infrastructure and builds upon the idea of checking that an alleged mobile node is indeed reachable through both its home address and its care-of address. Furthermore, the lifetime of the state created at the corresponded nodes is deliberately restricted to a few minutes, in order to limit the potential threat from time shifting.
現在のモバイルIPv6経路最適化セキュリティは、セクション3で議論した脅威を防ぐか、または緩和するように入念に設計されています。 目標は静的なIPv4ベースのインターネットのものの近くのセキュリティのレベル、およびパケット、遅れ、および処理による許容できる費用でデザインを生産することです。 結果はものが予想することではありません: それは確実に伝統的な暗号のプロトコルではありません。 そして、結果が代わりに、大いに腐敗していないルーティングインフラストラクチャの仮定に依存して、本当に、申し立てられたモバイルノードが両方のホームアドレスを通して届いているのをチェックするという考えを当てにする、それ、注意、-、アドレス その上、対応するノードに創設された状態の寿命は故意に数分に制限されます、タイム・シフトから潜在的な脅威を制限するために。
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).
このセクションは詳細に妥当なソリューションについて説明します(さらに詳しい明細については仕様を見てください)、Return Routability(セクション4.1)から始めて、通信員ノード(セクション4.2)で州の作成についての議論を続行して、Binding Cache Entries(セクション4.3)の生涯頃に議論で記述を終了して。
4.1. Return Routability
4.1. リターンRoutability
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
リターンRoutability(RR)はモバイルIPv6経路最適化セキュリティデザインによって配布された基本的機構の名前です。 RRはノードが、すなわち、ノードがあることを確かめるはずであることができるという考えに与えられたアドレスに送られたパケットに応じることができる状態で基づいています。 ルーティングインフラストラクチャが感染されるか、または確かめられるために検証とアドレスの間には、攻撃者がいれば、チェックは無病誤診をもたらします。 これらの例外で、うまくいっている回答が、本当に、ノードが付与にあるのを示すと思われます。
Nikander, et al. Informational [Page 24] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[24ページ]のRFC4225
address, and that the node is willing to reply to the probes sent to it.
アドレス、そして、ノードは、それに送られた探測装置に答えても構わないと思っています。
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.
基本的なリターンroutabilityメカニズムは2つのチェック、ホームAddressチェック(セクション4.1.1を見る)、およびアドレス検査の注意から成ります(セクション4.1.2を見てください)。 パケット流動は図7に表現されます。 まず最初に、モバイルノードは2つのパケットを通信員ノードに送ります: ホームのエージェント、およびaを通してホームTest Init(HoTI)パケットを送る、Care、-、Test Init、(CoTI) 直接。 に対応して通信員ノードがホームTest Initとaに対応してホームTest(HoT)を送ることによって独自にこれらの両方に答える、Care、-、Test(CoT)、Care、-、Test Init。 そして、一度、最終的に、モバイルノードが両方のホームTestを受けたことがある、Care、-、Testパケット、それは通信員ノードにBinding Updateを送ります。
+------+ 1a) HoTI +------+
| |---------------------->| |
| MN | 2a) HoT | HA |
| |<----------------------| |
+------+ +------+
1b) CoTI | ^ | / ^
| |2b| CoT / /
| | | / /
| | | 3) BU / /
V | V / /
+------+ 1a) HoTI / /
| |<----------------/ /
| CN | 2a) HoT /
| |------------------/
+------+
+------+ 1a) HoTI+------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| ミネソタ| 2a) 熱い| ハ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +------+ +------+1b) CoTI| ^ | / ^ | |2b| 簡易寝台//| | | / / | | | 3) BU//V| V//+------+ 1a) HoTI//| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--/ / | CN| 2a) 熱い/| |------------------/ +------+
Figure 7. Return Routability Packet Flow
図7。 リターンRoutabilityパケット流動
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.
実際のデザインがいくらか複雑であったように見えるかもしれません。 そして、すなわち、実質収益routabilityチェックがメッセージ組の<ホームTestと、Binding Update>と<である、Care、-、Test(Binding Update>)ホームTest Init、Care、-、Test Initパケットがテストパケットの引き金となるのが必要であるだけであり、Binding Updateはテストの両方への結合したroutability応答として機能します。
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
1の代わりに2つのInitパケットを送る理由は増幅を避けることです。 ノードが何も知らない通信員
Nikander, et al. Informational [Page 25] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[25ページ]のRFC4225
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.
モバイルノード、したがって、それは何らかの任意のIPアドレスから求められていないIPパケットをただ受けます。 ある意味で、これは以前に未知のクライアントからTCP SYNを受けるサーバと同様です。 それは通信員ノードが初期の引き金に対応して2つのパケットを送ることであるなら、DoS増幅作用の可能性を提供します、セクション3.3.3で議論するように。
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つのパケットでそれぞれの容認されたパケットに答えて、容認されたパケットのソースアドレスに回答を送ることです。 したがって、2個の初期の引き金がちょうど1の代わりに必要です。
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つのリターンroutabilityテストを考えましょう。 以下のセクションでは、それぞれのこれらからの暗号の材料の派生は簡易型の方法で示されます。 本当の定石とその他の詳細について、[6]を参照してください。
4.1.1. Home Address Check
4.1.1. ホームアドレスチェック
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.
ホームAddressチェックはホームTest(HoT)パケットとその後のBinding Update(BU)から成ります。 それはホームTest Init(HoTI)の到着で引き起こされます。 通信員ノードは、ホームTest InitのソースアドレスにホームTestを送ることによって、ホームTest Initに答えます。 ソースアドレスはモバイルノードに関するホームアドレスであると思われます、そして、したがって、ホームTestはホームのエージェントによってモバイルノードにトンネルを堀られると思われます。 ホームTestはトークンであると暗号で生成されたa、ホームkeygenトークンを含んでいます。(それは、秘密鍵、単に通信員ノード、ホームTest Initパケットのソースアドレス、および一回だけによって知られていたKcnの連結に関してハッシュ関数について計算することによって、形成されます)。
home keygen token = hash(Kcn | home address | nonce | 0)
ホームkeygenトークン=ハッシュ(Kcn| ホームアドレス|一回だけ|0)
An index to the nonce is also included in the Home Test packet, allowing the correspondent node to find the appropriate nonce more easily.
また、一回だけへのインデックスはホームTestパケットに含まれています、通信員ノードが、より容易に適切な一回だけを見つけるのを許容して。
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.
トークンで、通信員ノードは、次に受けられたどんな拘束力があるアップデートもホームTestパケットを見たノードによって作成されたのを確実にすることができます。 セクション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
多くの場合、インターネットの2つ以上の異なったセグメントをホームTestパケットに送ります。 それは最初に、通信員ノードからホームまでエージェントを横断します。 この旅行では、それは保護されません、そして、経路のどんな立ち聞きする者もコンテンツを学ぶことができます。 そしてホームのエージェント
Nikander, et al. Informational [Page 26] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander、他 IPv6 ROセキュリティデザイン2005年12月のモバイルの情報[26ページ]のRFC4225
forwards the packet to the mobile node. This path is taken inside an IPsec ESP protected tunnel, making it impossible for the outsiders to learn the contents of the packet.
モバイルノードにパケットを送ります。 この経路はIPsecの中で取って、超能力がトンネルを保護しました、部外者がパケットのコンテンツを学ぶのを不可能にしてことです。
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.
初めに、ホームのエージェントとモバイルノードの間のパケットを保護するのは不要に聞こえるかもしれません、通信員ノードとモバイルノードの間で保護がない状態で移動したので。 インターネットのすべてのリンクが等しく不安定であるなら、追加保護は不要でしょうに。 しかしながら、ほとんどの実用的な設定では、ネットワークはホームのエージェントの近くでは、モバイルノードより安全である傾向があります。 例えば、ホームのエージェントが仮想のホームのリンクを接待して、モバイルノードが実際にホームに決してないなら、立ち聞きする者は通信員ノードの近くか通信員ノードとホームのエージェントの間の経路の上にいるべきです、ホームのエージェントで盗み聞くことができなかったので。 通信員ノードが主要なサーバであるなら、それとホームのエージェントの間の経路のすべてのリンクがかなり安全である傾向があります。 他方では、モバイルNodeはたぶんワイヤレス・アクセス技術を使用しています、アクセスリンクを立ち聞きするのを時々些細にして。 したがって、モバイルノードに到着するパケットを立ち聞きするのはかなり簡単です。 CN-HA経路が保護がないままで残るときさえ、その結果、HA-ミネソタ経路を保護するのは物上担保利益を提供しそうです。
4.1.2. Care-of-Address Check
4.1.2. アドレス検査の注意
From the correspondent node's point of view, the Care-of-Address check is very similar to the home check. The only difference is that now the source address of the received Care-of Test Init packet is assumed to be the care-of address of the mobile node. Furthermore, the token is created in a slightly different manner in order to make it impossible to use home tokens for care-of tokens or vice versa.
通信員ノードの観点から、アドレス検査のCareはホームチェックと非常に同様です。 唯一の違いがソースが扱う受け取られていることのその現在である、Care、-、Test Initパケットによる思われる、注意、-、モバイルノードのアドレス。 または、その上、トークンがそれをホームトークンを使用するのが不可能にするようにわずかに異なった方法で作成される、注意、-、トークン、逆もまた同様です。
care-of keygen token = hash(Kcn | care-of address | nonce | 1)
注意、-、keygenトークン=ハッシュ(Kcn|、注意、-、アドレス|一回だけ|1)
The Care-of Test traverses only one leg, directly from the correspondent node to the mobile node. It remains unprotected all along the way, making it vulnerable to eavesdroppers near the correspondent node, on the path from the correspondent node to the mobile node, or near the mobile node.
Care、-、Testは直接通信員ノードからモバイルノードまで1本の脚だけを横断します。 それは道に沿って保護がないままで残っています、通信員ノードの近くでそれを立ち聞きする者にとって被害を受け易くして、通信員ノードからモバイルノードまでモバイルノードにおける経路で。
4.1.3. Forming the First Binding Update
4.1.3. 最初の拘束力があるアップデートを形成します。
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.
そして、モバイルノードが両方のホームTestを受けた、Care、-、Testメッセージ、拘束力があるキーを作成します、Kbm、トークンの連結の上のハッシュ関数が受けたコンピューティングで。
This key is used to protect the first and the subsequent binding updates, as long as the key remains valid.
有効なままで残っている限り、このキーは、1番目とその後の拘束力があるアップデートを保護するのに使用されます。
Nikander, et al. Informational [Page 27] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 27] RFC 4225 Mobile IPv6 RO Security Design December 2005
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).
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).
4.2. Creating State Safely
4.2. Creating State Safely
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.
The correspondent node may remain stateless until it receives the first Binding Update. That is, it does not need to record receiving and replying to the Home Test Init and Care-of Test Init messages. The Home Test Init/Home Test and Care-of Test Init/Care-of Test exchanges take place in parallel but independently of each other. Thus, the correspondent can respond to each message immediately, and it does not need to remember doing that. This helps in potential denial-of-service situations: no memory needs to be reserved for processing Home Test Init and Care-of Test Init messages. Furthermore, Home Test Init and Care-of Test Init processing is designed to be lightweight, and it can be rate limited if necessary.
When receiving a first binding update, the correspondent node goes through a rather complicated procedure. The purpose of this procedure is to ensure that there is indeed a mobile node that has recently received a Home Test and a Care-of Test that were sent to the claimed home and care-of addresses, respectively, and to make sure that the correspondent node does not unnecessarily spend CPU or other resources while performing this check.
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.
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:
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.
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.
Home address: The home address specified in the Binding Update must
be equal to the source address used in the Home Test Init message.
Home address: The home address specified in the Binding Update must be equal to the source address used in the Home Test Init message.
Two nonce indices: These are copied over from the Home Test and
Care-of Test messages, and together with the other information
they allow the correspondent node to re-create the tokens sent in
the Home Test and Care-of Test messages and used for creating Kbm.
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.
Nikander, et al. Informational [Page 28] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 28] RFC 4225 Mobile IPv6 RO Security Design December 2005
Without them, the correspondent node might need to try the 2-3
latest nonces, leading to unnecessary resource consumption.
Without them, the correspondent node might need to try the 2-3 latest nonces, leading to unnecessary resource consumption.
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.
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.
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.
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.
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.
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.
4.2.1. Retransmissions and State Machine
4.2.1. Retransmissions and State Machine
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.
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.
4.3. Quick expiration of the Binding Cache Entries
4.3. Quick expiration of the Binding Cache Entries
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.
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.
Nikander, et al. Informational [Page 29] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 29] RFC 4225 Mobile IPv6 RO Security Design December 2005
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.
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.
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.
Although short lifetimes are required by other aspects of the security design and the goals, they are clearly detrimental for efficiency and robustness. That is, a Home Test Init / Home Test message pair must be exchanged through the home agent every few minutes. These messages are unnecessary from a purely functional point of view, thereby representing overhead. What is worse, though, is that they make the home agent a single point of failure. That is, if the Home Test Init / Home Test messages were not needed, the existing connections from a mobile node to other nodes could continue even when the home agent fails, but the current design forces the bindings to expire after a few minutes.
This concludes our walk-through of the selected security design. The cornerstones of the design were the employment of the return routability idea in the Home Test, Care-of Test, and binding update messages, the ability to remain stateless until a valid binding update is received, and the limiting of the binding lifetimes to a few minutes. Next we briefly discuss some of the remaining threats and other problems inherent to the design.
This 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.
5. Security Considerations
5. Security Considerations
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.
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.
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.
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.
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.
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.
Nikander, et al. Informational [Page 30] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 30] RFC 4225 Mobile IPv6 RO Security Design December 2005
5.1. Residual Threats as Compared to IPv4
5.1. Residual Threats as Compared to IPv4
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.
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.
Since the binding lifetimes are severely restricted in the current design, the ability to do a time shifting attack is equivalently restricted.
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.
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.
5.2. Interaction with IPsec
5.2. Interaction with IPsec
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.
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.
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.
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
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
Nikander, et al. Informational [Page 31] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 31] RFC 4225 Mobile IPv6 RO Security Design December 2005
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.
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.
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.
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.
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.
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.
5.3. Pretending to Be One's Neighbor
5.3. Pretending to Be One's Neighbor
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
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
Nikander, et al. Informational [Page 32] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 32] RFC 4225 Mobile IPv6 RO Security Design December 2005
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.
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.
This attack would allow the mobile node to divert unwanted traffic towards the neighboring node, resulting in an flooding attack.
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.
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.
5.4. Two Mobile Nodes Talking to Each Other
5.4. Two Mobile Nodes Talking to Each Other
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.
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.
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.
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.
6. Conclusions
6. Conclusions
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.
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.
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.
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.
Nikander, et al. Informational [Page 33] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 33] RFC 4225 Mobile IPv6 RO Security Design December 2005
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.
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.
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 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.
7. Acknowledgements
7. Acknowledgements
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.
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.
8. Informative References
8. Informative References
[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., 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.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines
and Philosophy", RFC 3439, December 2002.
[4] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[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., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[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., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
Nikander, et al. Informational [Page 34] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 34] RFC 4225 Mobile IPv6 RO Security Design December 2005
[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., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[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., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[11] Chiappa, J., "Will The Real 'End-End Principle' Please Stand
Up?", Private Communication, April 2002.
[11] Chiappa, J., "Will The Real 'End-End Principle' Please Stand Up?", Private Communication, April 2002.
[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., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29:5, October 1999.
[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., "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.
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", Private
Communication, 1999.
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", Private Communication, 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., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
Nikander, et al. Informational [Page 35] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 35] RFC 4225 Mobile IPv6 RO Security Design December 2005
Authors' Addresses
Authors' Addresses
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
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 FINLAND
EMail: jari.arkko@ericsson.com
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 United Kingdom
EMail: Tuomaura@microsoft.com
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
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
EMail: erik.nordmark@sun.com
Nikander, et al. Informational [Page 36] RFC 4225 Mobile IPv6 RO Security Design December 2005
Nikander, et al. Informational [Page 36] RFC 4225 Mobile IPv6 RO Security Design December 2005
Full Copyright Statement
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Nikander, et al. Informational [Page 37]
Nikander, et al. Informational [Page 37]
一覧
スポンサーリンク
