Network Working Group P. Nikander, Ed.
Request for Comments: 3756 Ericsson Research Nomadic Lab
Category: Informational J. Kempf
DoCoMo USA Labs
E. Nordmark
Sun Microsystems Laboratories
May 2004
IPv6 Neighbor Discovery (ND) Trust Models and Threats
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 (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.
既存のIETF標準は、IPv6近隣探索（ND）とアドレス自動設定機構はIPsecの認証ヘッダ（AH）で保護することができることを指定します。しかし、現在の仕様では、自動鍵管理に直面した現実的な問題のため手動キー入力にセキュリティソリューションを制限します。この文書では、3つの異なる信頼モデルを指定したIPv6近隣探索に関連する脅威について説明します。この議論の目的は、確保のIPv6近隣探索のための要件を定義することです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Previous Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Corporate Intranet Model. . . . . . . . . . . . . . . . . 5
3.2. Public Wireless Network with an Operator. . . . . . . . . 6
3.3. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . . 7
4. Threats on a (Public) Multi-Access Link. . . . . . . . . . . . 8
4.1. Non router/routing related threats. . . . . . . . . . . . 9
4.1.1. Neighbor Solicitation/Advertisement Spoofing . . . 9
4.1.2. Neighbor Unreachability Detection (NUD) failure. . 10
4.1.3. Duplicate Address Detection DoS Attack . . . . . . 11
4.2. Router/routing involving threats. . . . . . . . . . . . . 12
4.2.1. Malicious Last Hop Router. . . . . . . . . . . . . 12
4.2.2. Default router is 'killed' . . . . . . . . . . . . 13
4.2.3. Good Router Goes Bad . . . . . . . . . . . . . . . 14
4.2.4. Spoofed Redirect Message . . . . . . . . . . . . . 14
4.2.5. Bogus On-Link Prefix . . . . . . . . . . . . . . . 14
4.2.6. Bogus Address Configuration Prefix . . . . . . . . 15
4.2.7. Parameter Spoofing . . . . . . . . . . . . . . . . 16
4.3. Replay attacks and remotely exploitable attacks . . . . . 17
4.3.1. Replay attacks . . . . . . . . . . . . . . . . . . 17
4.3.2. Neighbor Discovery DoS Attack. . . . . . . . . . . 18
4.4. Summary of the attacks. . . . . . . . . . . . . . . . . . 19
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
The IPv6 Neighbor Discovery (ND) RFC 2461 [2] and Address Autoconfiguration RFC 2462 [3] mechanisms are used by nodes in an IPv6 network to learn the local topology, including the IP to MAC address mappings for the local nodes, the IP and MAC addresses of the routers present in the local network, and the routing prefixes served by the local routers. The current specifications suggest that IPsec AH RFC 2402 [1] may be used to secure the mechanisms, but does not specify how. It appears that using current AH mechanisms is problematic due to key management problems [8].
IPv6近隣探索（ND）RFC 2461 [2]とアドレス自動設定RFC 2462 [3]ローカルノードのIP MACのアドレスマッピング、IPなど、ローカルトポロジーを学習するIPv6ネットワーク内のノードによって使用されるメカニズムとMACのローカルネットワークに存在するルータのアドレス、およびローカルルータによって提供されるルーティングプレフィックス。現在の仕様は、IPsec AHのRFC 2402 [1]のメカニズムを保護するために使用することができるが、どのように指定されていないことを示唆しています。現在のAHメカニズムを使用することにより、鍵管理の問題[8]に問題があると思われます。
To solve the problem, the Secure Neighbor Discovery (SEND) working group was chartered in Fall 2002. The goal of the working group is to define protocol support for securing IPv6 Neighbor Discovery without requiring excessive manual keying.
この問題を解決するために、セキュア近隣探索（SEND）ワーキンググループは秋2002年に結成されたワーキンググループの目標は、過剰な手動キーを必要とすることなく、IPv6の近隣探索を固定するためのプロトコルのサポートを定義することです。
The purpose of this document is to define the types of networks in which the Secure IPv6 Neighbor Discovery mechanisms are expected to work, and the threats that the security protocol(s) must address. To fulfill this purpose, this document first defines three different trust models, roughly corresponding to secured corporate intranets, public wireless access networks, and pure ad hoc networks. After that, a number of threats are discussed in the light of these trust models. The threat catalog is aimed to be exhaustive, but it is likely that some threats are still missing. Thus, ideas for new threats to consider are solicited.
この文書の目的は、セキュリティプロトコル（複数可）に対処しなければならないことセキュアIPv6近隣探索機構が動作することが期待されているネットワークのタイプ、および脅威を定義することです。この目的を果たすために、このドキュメントは、最初に大まかにセキュアな企業イントラネット、公衆無線アクセスネットワーク、および純粋なアドホックネットワークに対応した3つの異なる信頼モデルを定義します。その後、脅威の数は、これらの信頼モデルの光の中で議論されています。脅威のカタログは、網羅的であることを目指したが、いくつかの脅威がまだ不足している可能性が高いです。このように、考慮すべき新たな脅威のためのアイデアを募集しています。
Note that the SEND WG charter limits the scope of the working group to secure Neighbor Discovery functions. Furthermore, the charter explicitly mentions zero configuration as a fundamental goal behind Neighbor Discovery. Network access authentication and access control are outside the scope of this work.
SENDのWGチャーターは、近隣探索機能を確保するワーキンググループの範囲を制限することに留意されたいです。さらに、憲章は、明示的に近隣探索の背後にある基本的な目標として、ゼロコンフィギュレーションに言及しています。ネットワークアクセスの認証とアクセス制御は、この作業の範囲外です。
During the discussions while preparing this document, the following aspects that may help to evaluate the eventual solutions were mentioned.
この文書を準備している間議論の中で、最終的な解決策を評価するのを助けることができる次のような特徴が挙げられました。
Zero configuration
ゼロコンフィグレーション
Interaction with access control solutions
アクセス・コントロール・ソリューションとの相互作用
Scalability
スケーラビリティ
Efficiency
効率
However, the main evaluation criteria are formed by the trust models and threat lists. In other words, the solutions are primarily evaluated by seeing how well they secure the networks against the identified threats, and only secondarily from the configuration, access control, scalability, and efficiently point of view.
しかし、主要評価基準は、信頼モデルと脅威リストによって形成されています。言い換えれば、解決策は主に、彼らが識別された脅威からネットワークを保護し、唯一の二次的な構成、アクセス制御、スケーラビリティ、およびビューの効率の点から、どれだけ見て評価されます。
IMPORTANT. This document occasionally discusses solution proposals, such as Cryptographically Generated Addresses (CGA) [7] and Address Based Keys (ABK) [6]. However, such discussion is solely for illustrative purposes. Its purpose is to give the readers a more concrete idea of *some* possible solutions. Such discussion does NOT indicate any preference on solutions on the behalf of the authors or the working group.
重要。この文書では、時折、このような暗号化生成アドレス（CGA）のようなソリューション提案を説明[7]とアドレスベースの鍵（ABK）[6]。しかし、そのような議論は、例示の目的のためだけです。その目的は、読者に*いくつかの*可能な解決策のより具体的なアイデアを与えることです。このような議論は執筆者の代理やワーキンググループのソリューションのいずれかの優先度を示すものではありません。
It should be noted that the term "trust" is used in this document in a rather non-technical manner. The most appropriate interpretation is to consider it as an expression of an organizational or collective belief, i.e., an expression of commonly shared beliefs about the future behavior of the other involved parties. Conversely, the term "trust relationship" denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future. A trust relationship makes it possible to configure authentication and authorization information between the parties, while the lack of such a relationship makes it impossible to pre-configure such information.
用語「信頼」は、むしろ非技術的な方法で、このドキュメントで使用されていることに留意すべきです。最も適切な解釈は、組織や集団的信念、すなわち、他の関係者の将来の行動についての一般的共有信念の表現の表現としてそれを考えることです。逆に、用語「信頼関係は、」当事者が他の当事者も、将来的に正しく動作することを信じて、関係機関や当事者間の相互の先験的の関係を示しています。そのような関係の欠如は、それが不可能事前に設定し、そのような情報になりながら、信頼関係は、当事者間の認証と認可の情報を設定することが可能となります。
The RFCs that specify the IPv6 Neighbor Discovery and Address Autoconfiguration protocols [2] [3] contain the required discussion of security in a Security Considerations section. Some of the threats identified in this document were raised in the original RFCs. The recommended remedy was to secure the involved packets with an IPsec AH [1] header. However, that recommendation oversimplifies the problem by leaving the AH key management for future work. For example, a host attempting to gain access to a Public Access network may or may not have the required IPsec security associations set up with the network. In a roaming (but not necessarily mobile) situation, where a user is currently accessing the network through a service provider different from the home provider, it is not likely that the host will have been preconfigured with the proper mutual trust relationship for the foreign provider's network, allowing it to directly authenticate the network and get itself authenticated.
IPv6の近隣探索とアドレス自動設定プロトコルを指定するRFCは、[2] [3] Security Considerations部でのセキュリティの必要な議論を含んでいます。このドキュメントで識別された脅威のいくつかは、元のRFCで提起されました。推奨される治療薬は、IPsec AH [1]のヘッダに関わるパケットを確保することでした。しかし、その勧告は、将来の仕事のためにAH鍵管理を残すことによって、問題を単純化しすぎています。たとえば、パブリックアクセスネットワークにアクセスしようとするホストは、ネットワークをセットアップし、必要なのIPsecセキュリティアソシエーションがあってもなくてもよいです。ユーザーは、現在自宅プロバイダは異なるサービスプロバイダを介してネットワークにアクセスしているローミング（必ずしもモバイルではない）状況では、ホストが外国プロバイダーのための適切な相互の信頼関係で事前に設定されている可能性が高いではありませんネットワーク、それが直接ネットワークを認証するために、それ自体が認証を取得可能。
As of today, any IPsec security association between the host and the last hop routers or other hosts on the link would need to be completely manually preconfigured, since the Neighbor Discovery and Address Autoconfiguration protocols deal to some extent with how a host obtains initial access to a link. Thus, if a security association is required for initial access and the host does not have that association, there is currently no standard way that the host can dynamically configure itself with that association, even if it has the necessary minimum prerequisite keying material. This situation could induce administration hardships when events such as re-keying occur.
今日のように、ホストと最後のホップルータまたはリンク上の他のホストの間の任意のIPsecセキュリティアソシエーションは、ホストがへの初期アクセスを取得する方法である程度の近隣探索とアドレス自動設定プロトコルの契約以来、完全に手動で事前に設定する必要がありますリンク。セキュリティアソシエーションは、初期アクセスのために必要で、ホストがその関連を有しない場合、ホストは動的にそれは必要最低限の前提鍵材料を持っている場合でも、その関連で自身を設定できることを標準的な方法は現在のところありません。このような再キーイングなどのイベントが発生したときに、このような状況は、管理苦難を誘導することができました。
In addition, Neighbor Discovery and Address Autoconfiguration use a few fixed multicast addresses plus a range of 16 million "solicited node" multicast addresses. A naive application of pre-configured SAs would require pre-configuring an unmanageable number of SAs on each host and router just in case a given solicited node multicast address is used. Preconfigured SAs are impractical for securing such a large potential address range.
また、近隣探索とアドレス自動設定は、マルチキャストアドレスを「ノードを求め、」少数の固定マルチキャストアドレス+16万ドルの範囲を使用します。 SAが所定の要請ノードマルチキャストアドレスが使用されているだけの場合、各ホストおよびルータ上のSAの事前設定管理不能数を必要とする事前構成のナイーブアプリケーション。事前設定されたSAは、このような大きな電位アドレス範囲を確保するための実用的でありません。
When considering various security solutions for the IPv6 Neighbor Discovery (ND) [2], it is important to keep in mind the underlying trust models. The trust models defined in this section are used later in this document, when discussing specific threats.
IPv6の近隣探索（ND）[2]のためのさまざまなセキュリティソリューションを検討する場合、心の中で基本的な信頼モデルを維持することが重要です。特定の脅威を議論する際に、このセクションで定義された信頼モデルは、このドキュメントの後半で使用されています。
In the following, the RFC 2461/RFC 2462 mechanisms are loosely divided into two categories: Neighbor Discovery (ND) and Router Discovery (RD). The former denotes operations that do not primarily involve routers while the operations in the latter category do.
以下では、RFC 2461 / RFC 2462のメカニズムが緩く二つのカテゴリーに分けられる：近隣探索（ND）とルータ探索（RD）。前者は後者のカテゴリに操作を行う一方で、主にルータを伴わない操作を示しています。
Three different trust models are specified:
三つの異なる信頼モデルが指定されています。
1. A model where all authenticated nodes trust each other to behave correctly at the IP layer and not to send any ND or RD messages that contain false information. This model is thought to represent a situation where the nodes are under a single administration and form a closed or semi-closed group. A corporate intranet is a good example.
1.すべての認証済みのノードが虚偽の情報を含むすべてのNDやRDメッセージを送信するためにIP層で正しく動作していないためにお互いを信頼したモデル。このモデルは、ノードが単回投与を受けている状況を表し、閉鎖または半閉鎖基を形成すると考えられています。企業イントラネットが良い例です。
2. A model where there is a router trusted by the other nodes in the network to be a legitimate router that faithfully routes packets between the local network and any connected external networks. Furthermore, the router is trusted to behave correctly at the IP layer and not to send any ND or RD messages that contain false information.
2.ネットワーク内の他のノードから信頼ルータが正当なルータであることがあるモデル、ローカルネットワークと接続された任意の外部ネットワークとの間の忠実ルートパケット。さらに、ルータはIP層で正しく動作するようにし、虚偽の情報を含むすべてのNDやRDメッセージを送信しないように信頼されています。
This model is thought to represent a public network run by an
operator. The clients pay to the operator, have its credentials,
and trust it to provide the IP forwarding service. The clients
do not trust each other to behave correctly; any other client
node must be considered able to send falsified ND and RD
messages.
3. A model where the nodes do not directly trust each other at the IP layer. This model is considered suitable for e.g., ad hoc networks.
3.ノードが直接IP層において互いを信用していないモデル。このモデルは、例えば、アドホックネットワークに適していると考えられます。
Note that even though the nodes are assumed to trust each other in the first trust model (corporate intranet), it is still desirable to limit the extent of damage a node is able to inflict to the local network if it becomes compromised.
ノードが最初信頼モデル（企業イントラネット）で互いに信頼するように想定されていても、ノードは、それが危険にさらされるようになる場合、ローカルネットワークに与えることができる損傷の程度を制限することが望ましいことに留意されたいです。
In a corporate intranet or other network where all nodes are under one administrative domain, the nodes may be considered to be reliable at the IP layer. Thus, once a node has been accepted to be a member of the network, it is assumed to behave in a trustworthy manner.
すべてのノードが1つの管理ドメインの下にある企業のイントラネットまたは他のネットワークでは、ノードは、IP層での信頼できると考えてよいです。ノードがネットワークのメンバーであることが受け入れられた後したがって、信頼できる方法で動作すると仮定されます。
Under this model, if the network is physically secured or if the link layer is cryptographically secured to the extent needed, no other protection is needed for IPv6 ND, as long as none of the nodes become compromised. For example, a wired LAN with 802.1x access control or a WLAN with 802.11i Robust Security Network (RSN) with AES encryption may be considered secure enough, requiring no further protection under this trust model. On the other hand, ND security would add protection depth even under this model (see below). Furthermore, one should not overestimate the level of security any L2 mechanism is able to provide.
このモデルでは、ネットワークを物理的に確保されている場合は、リンク層は、暗号必要な範囲に固定されている場合、他の保護がある限り、ノードのどれもが危険にさらさなっていないとして、IPv6のNDのために必要ありません。たとえば、802.1Xアクセス制御またはAES暗号化を使用した802.11iの堅牢なセキュリティネットワーク（RSN）とWLANと有線LANは、この信頼モデルの下では、さらに保護を必要としない、十分に安全であると考えることができます。一方、NDのセキュリティは、（下記参照）も、このモデルの下で保護深さを追加します。また、一つは、任意のL2メカニズムが提供することができるセキュリティのレベルを過大評価してはなりません。
If the network is not physically secured and the link layer does not have cryptographic protection, or if the cryptographic protection is not secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the nodes in the network may be vulnerable to some or all of the threats outlined in Section 4. In such a case some protection is desirable to secure ND. Providing such protection falls within the main initial focus of the SEND working group.
ネットワークは、物理的に確保されていないと、リンク層は、暗号保護を持っていない、または暗号保護（例えば、単に802.1xとないWLANでの802.11i）十分に確保されていない場合は、ネットワーク内のノードはに対して脆弱である可能性がある場合一部の保護はNDを確保することが望ましいような場合には第4節で概説した脅威の一部または全部。このような保護を提供することはSENDワーキンググループの主な初期フォーカス内にあります。
Furthermore, it is desirable to limit the amount of potential damage in the case a node becomes compromised. For example, it might still be acceptable that a compromised node is able to launch a denial-of-service attack, but it is undesirable if it is able to hijack existing connections or establish man-in-the-middle attacks on new connections.
また、ノードが損なわなった場合の潜在的な損傷の量を制限することが望ましいです。例えば、まだ危険にさらさノードは、サービス拒否攻撃を仕掛けることが可能であることを受け入れられるかもしれませんが、既存の接続をハイジャックしたり、新しい接続のman-in-the-middle攻撃を確立することができるならば、それは望ましくありません。
As mentioned in Section 2, one possibility to secure ND would be to use IPsec AH with symmetric shared keys, known by all trusted nodes and by no outsiders. However, none of the currently standardized automatic key distribution mechanisms work right out-of-the-box. For further details, see [8]. Furthermore, using a shared key would not protect against a compromised node.
第2節で述べたように、NDを確保するための一つの可能性は、すべての信頼できるノードによって、ノー部外者に知られている対称共有鍵とのIPsec AHを使用することであろう。しかし、現在標準化自動キー配布メカニズムはいずれも右すぐに動作しません。詳細については、[8]を参照。さらに、共有キーを使用して、妥協のノードから保護しません。
More specifically, the currently used key agreement protocol, IKE, suffers from a chicken-and-egg problem [8]: one needs an IP address to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are required to configure an IP address. Furthermore, there does not seem to be any easy and efficient ways of securing ND with symmetric key cryptography. The required number of security associations would be very large [9].
具体的には、現在使用されるキー合意プロトコル、IKEは、鶏と卵の問題[8]に苦しんでいる：1は、IKEを実行するために、IPアドレスを必要とし、IKEはIPsecのSAの、およびIPsec SAを確立するために必要とされる設定する必要がありますIPアドレス。さらに、対称鍵暗号方式とNDの確保のいずれかの簡単かつ効率的な方法があるようには思えません。セキュリティアソシエーションの必要数は非常に大きくなります[9]。
As an example, one possible approach to overcome this limitation is to use public key cryptography, and to secure ND packets directly with public key signatures.
一例として、この制限を克服するための一つの可能なアプローチは、公開鍵暗号を使用すること、および公開鍵署名と直接NDパケットを確保するためです。
A scenario where an operator runs a public wireless (or wireline) network, e.g., a WLAN in a hotel, airport, or cafe, has a different trust model. Here the nodes may be assumed to trust the operator to provide the IP forwarding service in a trustworthy manner, and not to disrupt or misdirect the clients' traffic. However, the clients do not usually trust each other. Typically the router (or routers) fall under one administrative domain, and the client nodes each fall under their own administrative domain.
オペレータは、公衆無線（または有線）ネットワークを運営シナリオは、例えば、ホテル、空港、またはカフェでWLAN、異なる信頼モデルを持っています。ここでは、ノードは、信頼できる方法でIP転送サービスを提供する事業者を信頼して、クライアントのトラフィックを中断させるか、misdirectしないと仮定することができます。ただし、クライアントは通常、お互いを信頼していません。通常のルータ（またはルータ）は、1つの管理ドメインに該当し、クライアントは、独自の管理ドメインの下にそれぞれの秋ノード。
It is assumed that under this scenario the operator authenticates all the client nodes, or at least requires authorization in the form of a payment. At the same time, the clients must be able to authenticate the router and make sure that it belongs to the trusted operator. Depending on the link-layer authentication protocol and its deployment, the link layer may take care of the mutual authentication. The link-layer authentication protocol may allow the client nodes and the access router to create a security association. Note that there exist authentication protocols, e.g., particular EAP methods, that do not create secure keying material and/or do not allow the client to authenticate the network.
このシナリオの下で、オペレータは、すべてのクライアント・ノードを認証し、あるいは少なくとも支払いの形で認証を必要とするものとします。同時に、クライアントがルータを認証し、それが信頼できる事業者に属していることを確認することができなければなりません。リンク層認証プロトコルとその展開によっては、リンク層は、相互認証の世話をすることがあります。リンク層の認証プロトコルは、クライアント・ノードとアクセスルータはセキュリティアソシエーションを作成することを可能にします。認証プロトコル、安全な鍵素材を作成しないおよび/またはクライアントがネットワークを認証することはできません。例えば、特定のEAPメソッドは、そこに存在することに注意してください。
In this scenario, cryptographically securing the link layer does not necessarily block all the threats outlined in Section 4; see the individual threat descriptions. Specifically, even in 802.11i RSN with AES encryption the broadcast and multicast keys are shared between all nodes. Even if the underlying link layer was aware of all the nodes' link-layer addresses, and were able to check that no source addresses were falsified, there would still be vulnerabilities.
このシナリオでは、暗号リンク層の確保が必ずしもセクション4に概説すべての脅威をブロックしません。個々の脅威の説明を参照してください。具体的には、偶数のAES暗号化802.11iのRSNにブロードキャストおよびマルチキャストキーは、すべてのノード間で共有されます。基本的なリンク層は、すべてのノードのリンク層アドレスを知っていた、と何のソースアドレスが偽造されなかったことを確認することができたとしても、まだ脆弱性が存在することになります。
One should also note that link-layer security and IP topology do not necessarily match. For example, the wireless access point may not be visible at the IP layer at all. In such a case cryptographic security at the link layer does not provide any security with regard to IP Neighbor Discovery.
一つは、リンク層のセキュリティとIPトポロジが必ずしも一致しないことに注意すべきです。例えば、無線アクセスポイントは、すべてのIP層での見えないかもしれません。そのような場合には、リンク層での暗号化セキュリティがIP近隣探索に関して、どのようなセキュリティを提供しません。
There seems to be at least two ways to bring in security into this scenario. One possibility seems to be to enforce strong security between the clients and the access router, and make the access router aware of the IP and link-layer protocol details. That is, the router would check ICMPv6 packet contents, and filter packets that contain information which does not match the network topology. The other possibly acceptable way is to add cryptographic protection to the ICMPv6 packets carrying ND messages.
このシナリオにセキュリティにもたらすために少なくとも2つの方法があるようです。一つの可能性は、クライアントとアクセスルータとの間の強力なセキュリティを強化し、IPおよびリンク層プロトコルの詳細のアクセスルータに認識させるためにあるように思われます。つまり、ルータはのICMPv6パケットの内容、およびネットワークトポロジに一致しない情報が含まれているフィルタパケットをチェックします。他の可能性が許容可能な方法は、NDメッセージを運ぶのICMPv6パケットに暗号保護を追加することです。
In an ad hoc network, or any network without a trusted operator, none of the nodes trust each other. In a generic case, the nodes meet each other for the first time, and there are no guarantees that the other nodes would behave correctly at the IP layer. They must be considered suspicious to send falsified ND and RD messages.
信頼オペレータなしに、アドホックネットワーク、又は任意のネットワークでは、ノードのどれもが互いに信頼していません。一般的なケースでは、ノードは初めてお互いを満たし、かつ他のノードはIP層で正しく動作することを保証はありません。彼らは偽造NDとRDメッセージを送信するために、疑わしい考慮されなければなりません。
Since there are no a priori trust relationships, the nodes cannot rely on traditional authentication. That is, the traditional authentication protocols rely on some existing relationship between the parties. The relationship may be direct or indirect. The indirect case relies on one or more trusted third parties, thereby creating a chain of trust relationships between the parties.
先験的信頼関係が存在しないため、ノードは、従来の認証に頼ることはできません。つまり、従来の認証プロトコルは、当事者間のいくつかの既存の関係に依存しています。関係が直接的または間接的であってもよいです。間接的な場合は、これにより、当事者間の信頼関係のチェーンを作成し、一つ以上の信頼できる第三者機関に依存しています。
In the generic ad hoc network case, there are no trusted third parties, nor do the parties trust each other directly. Thus, the traditional means of first authenticating and then authorizing the users (to use their addresses) do not work.
一般的なアドホックネットワークの場合、そこには信頼できる第三者はなく、また当事者が直接互いに信頼ありません。このように、最初に認証し、ユーザーを認証するの伝統的な手段は、（自分のアドレスを使用する）は動作しません。
It is still possible to use self-identifying mechanisms, such as Cryptographically Generated Addresses (CGA) [7]. These allow the nodes to ensure that they are talking to the same nodes (as before) at all times, and that each of the nodes indeed have generated their IP address themselves and not "stolen" someone else's address. It may also be possible to learn the identities of any routers using various kinds of heuristics, such as testing the node's ability to convey cryptographically protected traffic towards a known and trusted node somewhere in the Internet. Methods like these seem to mitigate (but not completely block) some of the attacks outlined in the next section.
このような暗号化生成アドレス（CGA）として自己識別メカニズムを使用することが可能である[7]。これらは、ノードは、彼らはすべての回で（以前と）同じノードに話していることを保証することができ、かつ各ノードが実際に自分のIPが自分自身に対処し、生成していないことを他人のアドレス「盗まれた」と。また、インターネットのどこかに既知の信頼できるノードに向けて暗号で保護されたトラフィックを伝えるために、ノードの能力を試験するようヒューリスティックの様々な種類を使用して、任意のルータのアイデンティティを学習することも可能です。このような方法は、（ただし、完全にブロック）次のセクションで概説した攻撃のいくつかを軽減するように見えます。
In this section we discuss threats against the current IPv6 Neighbor Discovery mechanisms, when used in multi-access links. The threats are discussed in the light of the trust models defined in the previous section.
マルチアクセスリンクで使用する場合、このセクションでは、現在のIPv6近隣探索メカニズムに対する脅威を議論します。脅威は前のセクションで定義された信頼モデルの観点で議論されています。
There are three general types of threats:
脅威の3つの一般的なタイプがあります。
1. Redirect attacks in which a malicious node redirects packets away from the last hop router or other legitimate receiver to another node on the link.
1.悪意のあるノードがリンク上の別のノードに離れて最後のホップルータまたはその他の合法的な受信機からのパケットをリダイレクトする攻撃をリダイレクトします。
2. Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and all other nodes, or a specific destination address.
悪意のあるノードが攻撃を受けたノードと他のすべてのノード、または特定の宛先アドレスとの間の通信を防止する2.サービス拒否（DoS）攻撃、。
3. Flooding Denial-of-Service (DoS) attacks, in which a malicious node redirects other hosts' traffic to a victim node, and thereby creates a flood of bogus traffic at the victim host.
3.悪意のあるノードが犠牲者ノードに他のホストのトラフィックをリダイレクトし、それによって犠牲ホストの偽のトラフィックの洪水を作成するサービス拒否（DoS）攻撃をフラッディング。
A redirect attack can be used for DoS purposes by having the node to which the packets were redirected drop the packets, either completely or by selectively forwarding some of them and not others.
リダイレクト攻撃は、パケットが完全にまたは選択的にそれらのうちのいくつかではなく他人を転送することによって、ドロップパケットリダイレクトされた先のノードを有することにより、DoS攻撃の目的のために使用することができます。
The subsections below identify specific threats for IPv6 network access. The threat descriptions are organized in three subsections. We first consider threats that do not involve routers or routing information. We next consider threats that do involve routers or routing information. Finally, we consider replay attacks and threats that are remotely exploitable. All threats are discussed in the light of the trust models.
以下のサブセクションでは、IPv6ネットワークにアクセスするための具体的な脅威を識別します。脅威の記述は3つのサブセクションで構成されています。私たちは、最初のルーターやルーティング情報を含まない脅威を検討してください。私たちは、次のルータまたはルーティング情報を伴わない脅威を考えます。最後に、我々はリモートから悪用されるリプレイ攻撃や脅威を考えます。全ての脅威は、信頼モデルの光の中で議論されています。
In this section we discuss attacks against "pure" Neighbor Discovery functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability Detection (NUD), and Duplicate Address Detection (DAD) in Address Autoconfiguration.
このセクションでは、「純粋な」近隣探索機能に対する攻撃を議論、すなわち、近隣探索（ND）、近隣到達不能検出（NUD）、およびアドレス自動でアドレス検出（DAD）を複製します。
Nodes on the link use Neighbor Solicitation and Advertisement messages to create bindings between IP addresses and MAC addresses. More specifically, there are two cases when a node creates neighbor cache entries upon receiving Solicitations:
リンク上のノードはIPアドレスとMACアドレス間のバインディングを作成するために、近隣要請と広告メッセージを使用しています。具体的には、ノードは要請を受けて近隣キャッシュエントリを作成する2つのケースがあります。
1. A node receives a Neighbor Solicitation that contains a node's address. The node can use that to populate its neighbor cache. This is basically a performance optimization, and a SHOULD in the base documents.
1.ノードは、ノードのアドレスが含まれている近隣要請を受けます。ノードは、その近隣キャッシュを移入するためにそれを使用することができます。これは、基本的には、ベースの文書でのパフォーマンスの最適化、およびSHOULDです。
2. During Duplicate Address Detection (DAD), if a node receives a Neighbor Solicitation for the same address it is soliciting for, the situation is considered a collision, and the node must cease to solicit for the said address.
ノードは、それがために募集されているのと同じアドレスのために近隣要請を受信した場合、重複期間中2.状況は衝突とみなされ、検出（DAD）のアドレス、およびノードが言ったアドレスに勧誘をやめなければなりません。
In contrast to solicitation messages that create or modify state only in these specific occasions, state is usually modified whenever a node receives a solicited-for advertisement message.
ノードは、要請のための広告メッセージを受信するたびに作成するか、またはこれらのみ特定の場面で状態を変更要請メッセージとは対照的に、状態は、通常、変更されます。
An attacking node can cause packets for legitimate nodes, both hosts and routers, to be sent to some other link-layer address. This can be done by either sending a Neighbor Solicitation with a different source link-layer address option, or sending a Neighbor Advertisement with a different target link-layer address option.
攻撃ノードは、他のいくつかのリンク層アドレスに送信する正当なノード、ホストとルータの両方のためのパケットを引き起こす可能性があります。これは、異なるソースリンク層アドレスオプションを指定して近隣要請を送信し、または異なるターゲットリンク層アドレスオプションを指定して近隣広告を送ることのいずれかによって行うことができます。
The attacks succeed because the Neighbor Cache entry with the new link-layer address overwrites the old. If the spoofed link-layer address is a valid one, as long as the attacker responds to the unicast Neighbor Solicitation messages sent as part of the Neighbor Unreachability Detection, packets will continue to be redirected. This is a redirect/DoS attack.
新しいリンク層アドレスを持つ近隣キャッシュエントリは古いが上書きされるため、攻撃が成功します。偽装されたリンク層アドレスが有効なものである場合に限り、攻撃者は近隣到達不能検出の一部として送信されたユニキャスト近隣要請メッセージに応答して、パケットがリダイレクトされていきます。これは、リダイレクト/ DoS攻撃です。
This mechanism can be used for a DoS attack by specifying an unused link-layer address; however, this DoS attack is of limited duration since after 30-50 seconds (with default timer values) the Neighbor Unreachability Detection mechanism will discard the bad link-layer address and multicast anew to discover the link-layer address. As a consequence, the attacker will need to keep responding with fabricated link-layer addresses if it wants to maintain the attack beyond the timeout.
このメカニズムは、未使用のリンク層アドレスを指定することにより、DoS攻撃のために使用することができます。しかし、このDoS攻撃は、近隣到達不能検出メカニズムは、リンク層アドレスを発見するために新たに悪いリンク層アドレスおよびマルチキャストを破棄します（デフォルトタイマー値を持つ）30〜50秒後以降限られた期間です。その結果、攻撃者は、それがタイムアウトを超えた攻撃を維持したい場合、作製リンク層アドレスで応答しておく必要があります。
The threat discussed in this subsection involves Neighbor Solicitation and Neighbor Advertisement messages.
この章で論じられた脅威は近隣要請と近隣広告メッセージを含んでいます。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case where just the operator is trusted, the nodes may rely on the operator to certify the address bindings for other local nodes. From the security point of view, the router may act as a trusted proxy for the other nodes. This assumes that the router can be trusted to represent correctly the other nodes on the link. In the ad hoc network case, and optionally in the other two cases, the nodes may use self certifying techniques (e.g., CGA) to authorize address bindings.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードは、この脅威にさらされています。単にオペレータが信頼されている場合には、ノードは、他のローカルノードのアドレスバインディングを認証するためにオペレータに依存してもよいです。セキュリティの観点から、ルータが他のノードのための信頼できるプロキシとして動作することができます。これは、ルータが正しくリンク上の他のノードを表すのに信頼できることを前提としています。アドホックネットワークの場合には、必要に応じて他の2つの場合に、ノードはアドレスバインディングを許可する（例えば、CGA）自己認証技術を使用することができます。
Additionally, some implementations log an error and refuse to accept ND overwrites, instead requiring the old entry to time out first.
さらに、いくつかの実装はエラーをログに記録し、代わりに最初のタイムアウトに古いエントリを必要とする、NDは上書き受け入れることを拒否します。
Nodes on the link monitor the reachability of local destinations and routers with the Neighbor Unreachability Detection procedure [2]. Normally the nodes rely on upper-layer information to determine whether peer nodes are still reachable. However, if there is a sufficiently long delay on upper-layer traffic, or if the node stops receiving replies from a peer node, the NUD procedure is invoked. The node sends a targeted NS to the peer node. If the peer is still reachable, it will reply with a NA. However, if the soliciting node receives no reply, it tries a few more times, eventually deleting the neighbor cache entry. If needed, this triggers the standard address resolution protocol to learn the new MAC address. No higher level traffic can proceed if this procedure flushes out neighbor cache entries after determining (perhaps incorrectly) that the peer is not reachable.
リンク上のノード[2]近隣到達不能検出手順と、ローカルの宛先とルータの到達可能性を監視します。通常、ノードは、ピア・ノードが依然として到達可能であるかどうかを決定するために上位レイヤ情報に依存しています。しかし、上層トラフィックに十分に長い遅延がある場合、またはノードがピア・ノードからの応答を受信し停止した場合、NUD手順が呼び出されます。ノードは、ピア・ノードを対象とNSを送信します。ピアがまだ到達可能であるならば、それはNAで返信されます。勧誘ノードが応答なししかし、もし、それが最終的に近隣キャッシュエントリを削除する、より多くの数回を試みます。必要であれば、これは新しいMACアドレスを学習するための標準的なアドレス解決プロトコルをトリガします。この手順では、ピアが到達不能であることを（おそらく間違って）決定した後に、近隣キャッシュエントリをフラッシュすると、どんなより高いレベルのトラフィックを進めることはできません。
A malicious node may keep sending fabricated NAs in response to NUD NS messages. Unless the NA messages are somehow protected, the attacker may be able to extend the attack for a long time using this technique. The actual consequences depend on why the node become unreachable for the first place, and how the target node would behave if it knew that the node has become unreachable. This is a DoS attack.
悪意のあるノードは、NUD NSメッセージに応じて製造されたNASに送り続けることがあります。 NAメッセージが何らかの形で保護されていない限り、攻撃者がこの技術を使用して長い時間のために攻撃を延長することができるかもしれません。実際の結果は、ノードが最初の場所のための到達不能になった理由に依存し、そしてそれは、ノードが到達不能になったことを知っていた場合、ターゲットノードが振る舞うだろうか。これは、DoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
この章で論じられた脅威は近隣要請/広告メッセージを含んでいます。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this DoS threat. Under the two other trust models, a solution requires that the node performing NUD is able to make a distinction between genuine and fabricated NA responses.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードはこのDoS攻撃の脅威にさらされています。他の二つの信頼モデルの下では、解決策は、NUDを実行するノードが本物と製作NA応答の区別を行うことが可能であることが必要です。
In networks where the entering hosts obtain their addresses using stateless address autoconfiguration [3], an attacking node could launch a DoS attack by responding to every duplicate address detection attempt made by an entering host. If the attacker claims the address, then the host will never be able to obtain an address. The attacker can claim the address in two ways: it can either reply with an NS, simulating that it is performing DAD, too, or it can reply with an NA, simulating that it has already taken the address into use. This threat was identified in RFC 2462 [3]. The issue may also be present when other types of address configuration is used, i.e., whenever DAD is invoked prior to actually configuring the suggested address. This is a DoS attack.
入力ホストはステートレスアドレス自動設定[3]を使用して、そのアドレスを取得したネットワークでは、攻撃ノードが入ってくるホストによって行われたすべての重複アドレス検出試行に応答することにより、DoS攻撃を起動することができます。攻撃者がアドレスを主張する場合、ホストは、アドレスを取得することはできません。攻撃者は、2つの方法でアドレスを主張することができます：それはあまりにも、それはDADを実行していることをシミュレートし、NSに応答することができるか、それが既に使用されるようにアドレスを取ったことをシミュレートし、NAを使用して返信することができます。この脅威は、RFC 2462で確認された[3]。 DADは、従来は、実際に提案アドレスを設定するために呼び出されるたびにアドレス設定の他のタイプ、すなわち、使用される場合に問題が存在してもよいです。これは、DoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
この章で論じられた脅威は近隣要請/広告メッセージを含んでいます。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes become exposed to this DoS threat. Under the two other trust models, a solution requires that the node performing DAD is able to verify whether the sender of the NA response is authorized to use the given IP address or not. In the trusted operator case, the operator may act as an authorizer, keeping track of allocated addresses and making sure that no node has allocated more than a few (hundreds of) addresses. On the other hand, it may be detrimental to adopt such a practice, since there may be situations where it is desirable for one node to have a large number of addresses, e.g., creating a separate address per TCP connection, or when running an ND proxy. Thus, it may be inappropriate to suggest that ISPs could control how many addresses a legitimate host can have; the discussion above must be considered only as examples, as stated in the beginning of this document.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードはこのDoS攻撃の脅威にさらされるようになります。他の二つの信頼モデルの下では、解決策は、DADを実行するノードはNA応答の送信者が指定したIPアドレスの使用を許可されているかどうかを確認することができることが必要です。信頼されたオペレータの場合には、オペレータは、割り当てられたアドレスを追跡し、どのノードがアドレスより少ない（数百）に割り当てられていないことを確認し、承認者として作用することができます。一方、TCP接続ごとに別々のアドレスを作成する、またはNDを実行するとき、一方のノードは、例えばアドレスの数が多いすることが望ましい状況があり得るので、そのような慣行を採用すること有害であり得ますプロキシ。したがって、正当なホストを持つことができますどのように多くのアドレスのISPが制御できることを示唆することは不適切であってもよく、本書の冒頭で述べたように上記の議論は、例としてのみ考慮されなければなりません。
In the ad hoc network case one may want to structure the addresses in such a way that self authorization is possible.
アドホックネットワークの場合、1は、自己の認証が可能であるようにアドレスを構築することもできます。
In this section we consider threats pertinent to router discovery or other router assisted/related mechanisms.
このセクションでは、ルータディスカバリや他のルータ支援/関連メカニズムに関連する脅威を考えます。
This threat was identified in [5] but was classified as a general IPv6 threat and not specific to Mobile IPv6. It is also identified in RFC 2461 [2]. This threat is a redirect/DoS attack.
この脅威は、[5]において同定されたが、モバイルIPv6に特有の一般的なIPv6の脅威として分類されませんでした。また、RFC 2461 [2]で識別されます。この脅威はリダイレクト/ DoS攻撃です。
An attacking node on the same subnet as a host attempting to discover a legitimate last hop router could masquerade as an IPv6 last hop router by multicasting legitimate-looking IPv6 Router Advertisements or unicasting Router Advertisements in response to multicast Router Advertisement Solicitations from the entering host. If the entering host selects the attacker as its default router, the attacker has the opportunity to siphon off traffic from the host, or mount a man-in-the-middle attack. The attacker could ensure that the entering host selected itself as the default router by multicasting periodic Router Advertisements for the real last hop router having a lifetime of zero. This may spoof the entering host into believing that the real access router is not willing to take any traffic. Once accepted as a legitimate router, the attacker could send Redirect messages to hosts, then disappear, thus covering its tracks.
入ってくるホストからルータ広告要請をマルチキャストに対応して合法的に見えるのIPv6ルータ広告またはユニキャストルータ広告をマルチキャストすることにより、IPv6のラストホップルータになりすます可能性があり、正当なラストホップルータを発見しようとするホストと同じサブネット上の攻撃ノード。入力するホストがデフォルトルータとして攻撃者を選択した場合、攻撃者は、man-in-the-middle攻撃をホストからのトラフィックをオフにサイフォン、またはマウントする機会を持っています。攻撃者が入ってくるホストはゼロの寿命を持つ本当のラストホップルータのための定期的なルータ広告をマルチキャストすることにより、デフォルトルータとしての地位を選択していることを確認できました。これは、実際のアクセスルータがトラフィックを取ることを望んでいないことを信じるように入力するホストを偽装することがあります。一度正当なルータとして受け入れ、攻撃者がその曲をカバーするため、消えた後、ホストにリダイレクトメッセージを送信することができます。
This threat is partially mitigated in RFC 2462; in Section 5.5.3 of RFC 2462 it is required that if the advertised prefix lifetime is less than 2 hours and less than the stored lifetime, the stored lifetime is not reduced unless the packet was authenticated. However, the default router selection procedure, as defined in Section 6.3.6. of RFC 2461, does not contain such a rule.
この脅威は、部分的にRFC 2462に軽減されます。 RFC 2462のセクション5.5.3に広告を出して、プレフィックス寿命が2時間以下と保存寿命よりも小さい場合、パケットが認証されていない限り、保存された寿命を低下させないことが必要です。ただし、デフォルトルータの選択手順、6.3.6項で定義されています。 RFC 2461で、そのような規則が含まれていません。
The threat discussed in this subsection involves Router Advertisement and Router Advertisement Solicitation messages.
この章で論じられた脅威はルータアドバタイズメントおよびルータ広告要請メッセージを含んでいます。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. However, the threat can be partially mitigated through a number of means, for example, by configuring the nodes to prefer existing routers over new ones. Note that this approach does not necessarily prevent one from introducing new routers into the network, depending on the details of implementation. At minimum, it just makes the existing nodes to prefer the existing routers over the new ones.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードは、この脅威にさらされています。しかし、脅威は部分的に例えば、新しいものの上に既存のルータを好むようにノードを構成することで、多くの手段によって軽減することができます。このアプローチは、必ずしも実装の詳細に応じて、ネットワークに新しいルータを導入から1を妨げるものではないことに注意してください。最低でも、それだけで、既存のノードが新しいものの上に既存のルータを好むようになります。
In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。そこアドホックネットワークの場合には広く受け入れられた解決策は現在ありません、そして問題は研究課題として残っています。
In this attack, an attacker 'kills' the default router(s), thereby making the nodes on the link to assume that all nodes are local. In Section 5.2 of RFC 2461 [2] it is stated that "[if] the Default Router List is empty, the sender assumes that the destination is on-link." Thus, if the attacker is able to make a node to believe that there are no default routers on the link, the node will try to send the packets directly, using Neighbor Discovery. After that the attacker can use NS/NA spoofing even against off-link destinations.
この攻撃では、攻撃者はこれにより、すべてのノードがローカルであると仮定して、リンク上のノードを作り、デフォルトルータ（複数可）を「殺します」。 RFC 2461の5.2節では、[2]「デフォルトルータリストが空である[場合]、送信者が宛先がオンリンクであることを前提としています。」と記載されています攻撃者は、リンク上のデフォルトルータが存在しないことを信じるようにノードを作ることができればこのように、ノードは近隣探索を使用して、直接パケットを送信しようとします。その後、攻撃者は、オフリンク先に対しても、NS / NAスプーフィングを使用することができます。
There are a few identified ways how an attacker can 'kill' the default router(s). One is to launch a classic DoS attack against the router so that it does not appear responsive any more. The other is to send a spoofed Router Advertisement with a zero Router Lifetime (see Section 6.3.4 of RFC 2461 [2]). However, see also the discussion in Section 4.2.1, above.
どのように攻撃者がデフォルトルータ（複数可）を「殺す」ことができますいくつかの識別方法があります。一つは、これ以上応答が表示されないように、ルータに対する古典的なDoS攻撃を起動することです。他のゼロルータ寿命と偽装ルータ広告を送信することである（RFC 2461のセクション6.3.4を参照[2]）。しかし、上記の、また、セクション4.2.1での議論を参照してください。
This attack is mainly a DoS attack, but it could also be used to redirect traffic to the next better router, which may be the attacker.
この攻撃は、主にDoS攻撃であるが、また、攻撃者かもしれ次回より良いルータにトラフィックをリダイレクトするために使用することができます。
The threat discussed in this subsection involves Router Advertisement messages. One variant of this threat may be possible by overloading the router, without using any ND/RD messages.
この章で論じられた脅威はルータ広告メッセージを伴います。この脅威の一つの変異体は、任意のND / RDメッセージを使用せずに、ルータに過負荷をかけることでも可能です。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. That protects against spoofed Router Advertisements, but it does not protect against router overloading. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードは、この脅威にさらされています。信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。これは、偽装されたルータ広告から保護し、それがルータのオーバーロードを防ぐことはできません。そこアドホックネットワークの場合には広く受け入れられた解決策は現在ありません、そして問題は研究課題として残っています。
Thanks to Alain Durand for identifying this threat.
この脅威を識別するためのアラン・デュランのおかげ。
In this attack, a router that previously was trusted is compromised. The attacks available are the same as those discussed in Section 4.2.1. This is a redirect/DoS attack.
この攻撃では、以前に信頼されたルータが危険にさらされています。利用可能な攻撃は、4.2.1項で説明したものと同じです。これは、リダイレクト/ DoS攻撃です。
There are currently no known solutions for any of the presented three trust models. On the other hand, on a multi-router link one could imagine a solution involving revocation of router rights. The situation remains as a research question.
提示3つの信頼モデルのいずれかに対する既知の解決策はありません。一方、マルチルータのリンクに1は、ルータ権の失効を含むソリューションを想像することができます。状況は、研究課題として残っています。
The Redirect message can be used to send packets for a given destination to any link-layer address on the link. The attacker uses the link-local address of the current first-hop router in order to send a Redirect message to a legitimate host. Since the host identifies the message by the link-local address as coming from its first hop router, it accepts the Redirect. As long as the attacker responds to Neighbor Unreachability Detection probes to the link-layer address, the Redirect will remain in effect. This is a redirect/DoS attack.
リダイレクトメッセージは、リンク上の任意のリンク層アドレスに指定された宛先にパケットを送信するために使用することができます。攻撃者は、正当なホストにリダイレクトメッセージを送信するために、現在の第1ホップルータのリンクローカルアドレスを使用しています。ホストが最初のホップルータから来るようにリンクローカルアドレスによってメッセージを識別するので、リダイレクトを受け付けます。限り、攻撃者はリンク層アドレスへ近隣非検出プローブに応答するように、リダイレクトが有効のままになります。これは、リダイレクト/ DoS攻撃です。
The threat discussed in this subsection involves Redirect messages.
この章で論じられた脅威はリダイレクトメッセージを含んでいます。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードは、この脅威にさらされています。信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。そこアドホックネットワークの場合には広く受け入れられた解決策は現在ありません、そして問題は研究課題として残っています。
An attacking node can send a Router Advertisement message specifying that some prefix of arbitrary length is on-link. If a sending host thinks the prefix is on-link, it will never send a packet for that prefix to the router. Instead, the host will try to perform address resolution by sending Neighbor Solicitations, but the Neighbor Solicitations will not result in a response, denying service to the attacked host. This is a DoS attack.
攻撃ノードは、任意の長さのいくつかのプレフィックスがオンリンクであることを指定するRouter Advertisementメッセージを送ることができます。送信ホストがプレフィックスがオンリンクであると考えるならば、それはルータへのプレフィックスのためのパケットを送信することはありません。代わりに、ホストは、近隣要請を送信することにより、アドレス解決を実行しようとしますが、近隣要請が攻撃されたホストへのサービスを拒否、応答にはなりません。これは、DoS攻撃です。
The attacker can use an arbitrary lifetime on the bogus prefix advertisement. If the lifetime is infinity, the sending host will be denied service until it loses the state in its prefix list e.g., by rebooting, or after the same prefix is advertised with a zero lifetime. The attack could also be perpetrated selectively for packets destined to a particular prefix by using 128 bit prefixes, i.e., full addresses.
攻撃者は、偽のプレフィックス広告上の任意の寿命を使用することができます。寿命が無限大である場合は、再起動することによって、例えばそのプレフィックスリストの状態を失い、または同じ接頭辞の後にゼロ寿命でアドバタイズされるまで、送信側ホストは、サービスを拒否されます。攻撃も128ビットのプレフィックス、すなわち、完全なアドレスを使用して、特定のプレフィックス宛てのパケットに対して選択犯さことができます。
Additionally, the attack may cause a denial-of-service by flooding the routing table of the node. The node would not be able to differentiate between legitimate on-link prefixes and bogus ones when making decisions as to which ones are kept and which are dropped. Inherently, any finite system must have some point at which new received prefixes must be dropped rather than accepted.
さらに、攻撃はノードのルーティングテーブルをあふれさせることにより、サービス拒否が発生することがあります。意思決定を行う際のものが保持され、これがドロップされると、ノードは、正当なオンリンクプレフィックスと偽のものを区別することができないであろう。本質的に、任意の有限システムは、新たな受信プレフィックスが廃棄ではなく、受け入れなければならない時に、いくつかのポイントを持っている必要があります。
This attack can be extended into a redirect attack if the attacker replies to the Neighbor Solicitations with spoofed Neighbor Advertisements, thereby luring the nodes on the link to send the traffic to it or to some other node.
攻撃者はそれにより、またはいくつかの他のノードにトラフィックを送信するためのリンク上のノードを誘惑、偽装された近隣広告と近隣要請に応答する場合、この攻撃は、リダイレクト攻撃に拡張することができます。
This threat involves Router Advertisement message. The extended attack combines the attack defined in Section 4.1.1 and in this section, and involves Neighbor Solicitation, Neighbor Advertisement, and Router Advertisement messages.
この脅威はRouter Advertisementメッセージを含んでいます。拡張された攻撃は、セクション4.1.1で、このセクションで定義された攻撃を組み合わせて、近隣要請、近隣広告、およびルータ広告メッセージを伴います。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains as a research question.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼できるノードが危険にさらされている場合、他のノードは、この脅威にさらされています。信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。そこアドホックネットワークの場合には、既知の解決策は現在ありません、そして問題は研究課題として残っています。
As an example, one possible approach to limiting the damage of this attack is to require advertised on-link prefixes be /64s (otherwise it's easy to advertise something short like 0/0 and this attack is very easy).
例として、この攻撃のダメージを制限する一つの可能なアプローチは宣伝オンリンクプレフィックスこと/ 64S（それ以外の場合は0/0のような短いものを宣伝するのは簡単だし、この攻撃は非常に簡単である）を必要とすることです。
An attacking node can send a Router Advertisement message specifying an invalid subnet prefix to be used by a host for address autoconfiguration. A host executing the address autoconfiguration algorithm uses the advertised prefix to construct an address [3], even though that address is not valid for the subnet. As a result, return packets never reach the host because the host's source address is invalid. This is a DoS attack.
攻撃ノードは、アドレス自動設定のためにホストによって使用されるように、無効なサブネットプレフィックスを指定するRouter Advertisementメッセージを送ることができます。アドレス自動アルゴリズムを実行するホストは、そのアドレスがサブネットに対して有効でない場合でも、[3]のアドレスを構築するために広告を出して接頭辞を使用しています。ホストの送信元アドレスが無効であるため、結果として、戻りパケットがホストに到達することはありません。これは、DoS攻撃です。
This attack has the potential to propagate beyond the immediate attacked host if the attacked host performs a dynamic update to the DNS based on the bogus constructed address. DNS update [4] causes the bogus address to be added to the host's address record in the
この攻撃は、攻撃されたホストは、偽の構築アドレスに基づいて、DNSへの動的更新を実行した場合にすぐに攻撃されたホストを超えて伝播する可能性を秘めています。 DNSの更新は、[4]偽のアドレスは、ホストのアドレスレコードに追加されます
DNS. Should this occur, applications performing name resolution through the DNS obtain the bogus address and an attempt to contact the host fails. However, well-written applications will fall back and try the other addresses registered in DNS, which may be correct.
DNS。この発生した場合、DNSによる名前解決を実行するアプリケーションは、偽のアドレスとホストに障害が発生した連絡しようとする試みを得ます。しかし、よく書かれたアプリケーションは、フォールバックし、正しいかもしれDNSに登録されている他のアドレスを、しようとします。
A distributed attacker can make the attack more severe by creating a falsified reverse DNS entry that matches with the dynamic DNS entry created by the target. Consider an attacker who has legitimate access to a prefix <ATTACK_PRFX>, and a target who has an interface ID <TARGET_IID>. The attacker creates a reverse DNS entry for <ATTACK_PRFX>:<TARGET_IID>, pointing to the real domain name of the target, e.g., "secure.target.com". Next the attacker advertises the <ATTACK_PRFX> prefix at the target's link. The target will create an address <ATTACK_PRFX>:<TARGET_IID>, and update its DNS entry so that "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>.
分散型攻撃者がターゲットで作成されたダイナミックDNSエントリと一致した偽造逆DNSエントリを作成することにより、攻撃がより深刻なことができます。接頭辞<ATTACK_PRFX>への正当なアクセス権を持つ攻撃者は、インタフェースID <TARGET_IID>を持つターゲットを考えてみましょう。 <TARGET_IID>、ターゲットの実際のドメイン名を指し、例えば、「secure.target.com」：攻撃者が<ATTACK_PRFX>のための逆引きDNSエントリを作成します。次の攻撃者は、対象者のリンクから<ATTACK_PRFX>プレフィックスをアドバタイズします。ターゲットは、アドレス<ATTACK_PRFX>が作成されます：<TARGET_IID>を、そして<ATTACK_PRFX>に "secure.target.com" のポイントように、そのDNSエントリを更新：<TARGET_IID>。
At this point "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>, and <ATTACK_PRFX>:<TARGET_IID> points to "secure.target.com". This threat is mitigated by the fact that the attacker can be traced since the owner of the <ATTACK_PRFX> is available at the registries.
この時点で、<ATTACK_PRFX>に "secure.target.com" のポイント： "secure.target.com" へ<TARGET_IID>ポイント：<TARGET_IID>、および<ATTACK_PRFX>。この脅威は、<ATTACK_PRFX>の所有者がレジストリで利用可能であるため、攻撃者がたどることができるという事実によって軽減されます。
There is also a related possibility of advertising a target prefix as an autoconfiguration prefix on a busy link, and then have all nodes on this link try to communicate to the external world with this address. If the local router doesn't have ingress filtering on, then the target link may get a large number of replies for those initial communication attempts.
そこ忙しいリンクの自動設定のプレフィックスとしてターゲットプレフィックスを広告するのに関連する可能性もあり、その後、このリンク上のすべてのノードは、このアドレスを外部の世界と通信しようとしています。ローカルルータは、上のフィルタリング進入を持っていない場合は、ターゲットリンクは、それらの初期通信の試みのための回答が多数を得ることができます。
The basic threat discussed in this subsection involves Router Advertisement messages. The extended attack scenarios involve the DNS, too.
この項で説明する基本的な脅威はルータ広告メッセージを伴います。拡張攻撃シナリオでは、あまりにも、DNSを伴います。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains as a research question.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼されたノードが侵害された場合、他のノードはこの脅威にさらされています。信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。そこアドホックネットワークの場合には、既知の解決策は現在ありません、そして問題は研究課題として残っています。
IPv6 Router Advertisements contain a few parameters used by hosts when they send packets and to tell hosts whether or not they should perform stateful address configuration [2]. An attacking node could send out a valid-seeming Router Advertisement that duplicates the
IPv6ルーター広告は、彼らがパケットを送信する場合、ホストによって使用されるいくつかのパラメータが含まれており[2]、彼らは、ステートフルアドレス設定を行う必要があるかどうかをホストに伝えます。攻撃ノードは、複製し、有効な-見せかけルータ通知を送ることができ
Router Advertisement from the legitimate default router, except the included parameters are designed to disrupt legitimate traffic. This is a DoS attack.
含まれるパラメータを除き、正当なデフォルトルータからルータ広告は、正当なトラフィックが中断するように設計されています。これは、DoS攻撃です。
Specific attacks include:
特定の攻撃は、次のとおりです。
1. The attacker includes a Current Hop Limit of one or another small number which the attacker knows will cause legitimate packets to be dropped before they reach their destination.
1.攻撃者は、1の現在のホップ制限や攻撃者が彼らの目的地に到達する前に、正当なパケットがドロップされることになります知っている別の小さな数を含んでいます。
2. The attacker implements a bogus DHCPv6 server or relay and the 'M' and/or 'O' flag is set, indicating that stateful address configuration and/or stateful configuration of other parameters should be done. The attacker is then in a position to answer the stateful configuration queries of a legitimate host with its own bogus replies.
2.攻撃者は、偽のDHCPv6サーバを実装またはリレーと「M」及び/または「O」フラグは、ステートフルアドレス構成および/または他のパラメータのステートフル設定が行われるべきことを示し、設定されています。攻撃者は、独自の偽の応答で正当なホストのステートフル設定の問い合わせに回答する立場に続いています。
The threat discussed in this subsection involves Router Advertisement messages.
この章で論じられた脅威はルータ広告メッセージを伴います。
Note that securing DHCP alone does not resolve this problem. There are two reasons for this. First, the attacker may prevent the node from using DHCP in the first place. Second, depending on the node's local configuration, the attacker may spoof the node to use a less trusted DHCP server. (The latter is a variant of the so called "bidding down" or "down grading" attacks.)
一人でDHCPを確保することは、この問題を解決しないことに注意してください。これには2つの理由があります。まず、攻撃者は、最初の場所でDHCPを使用してからノードを防ぐことができます。第二に、ノードのローカル構成に応じて、攻撃者は、信頼性の低いDHCPサーバーを使用するようにノードを偽装することがあります。 （後者は、いわゆる「入札ダウン」または「ダウングレーディング」攻撃の変異体です。）
As an example, one possible approach to mitigate this threat is to ignore very small hop limits. The nodes could implement a configurable minimum hop limit, and ignore attempts to set it below said limit.
一例として、この脅威を緩和するための一つの可能なアプローチは、非常に小さいホップ制限を無視することです。ノードは、設定最小ホップ制限を実装し、それを設定する試みを無視することができ、以下に制限は述べています。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised the other nodes are exposed to this treat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains a research question.
リンクへのアクセスが信頼できるノードに制限されている場合、この攻撃は問題ではありません。信頼されたノードが侵害された場合、他のノードは、この御馳走にさらされています。信頼されたオペレータの場合には、ノードがオペレータによって実行される信頼できるルータ、および他のノードとの間の区別をするために手段がなければなりません。そこアドホックネットワークの場合には、既知の解決策は現在ありません、そして問題は研究課題のまま。
All Neighbor Discovery and Router Discovery messages are prone to replay attacks. That is, even if they were cryptographically protected so that their contents cannot be forged, an attacker would be able to capture valid messages and replay them later. Thus, independent on what mechanism is selected to secure the messages, that mechanism must be protected against replay attacks.
すべての近隣探索およびルータ検出メッセージは、リプレイ攻撃する傾向があります。それは、その内容を偽造することができない、攻撃者は有効なメッセージをキャプチャし、後でそれを再生することが可能であろうように、それらが暗号で保護されたとしても、です。このように、メッセージを保護するために選択されているもののメカニズムに依存しない、そのメカニズムは、リプレイ攻撃から保護されなければなりません。
Fortunately it is fairly easy to defeat most replay attacks. In request-reply exchanges, such as Solicitation-Advertisement, the request may contain a nonce that must appear also in the reply. Thus, old replies are not valid since they do not contain the right nonce. Correspondingly, stand-alone messages, such as unsolicited Advertisements or Redirect messages, may be protected with timestamps or counters. In practise, roughly synchronized clocks and timestamps seem to work well, since the recipients may keep track of the difference between the clocks of different nodes, and make sure that all new messages are newer than the last seen message.
幸いなことに、ほとんどのリプレイ攻撃を倒すために非常に簡単です。このような要請、広告などの要求 - 応答のやり取りにおいて、要求は、応答にも現れなければならないnonceを含んでいてもよいです。このように、古い返信は彼らが正しいnonceを含んでいないため、有効ではありません。これに対応し、そのような未承諾広告やリダイレクトメッセージとしてスタンドアローンのメッセージは、タイムスタンプまたはカウンタで保護することができます。実際には、大まかに同期したクロックとタイムスタンプは、受信者が異なるノードのクロック間の違いを追跡し、すべての新しいメッセージが最後に見られたメッセージよりも新しいことを確認してください可能性があるので、うまく動作するように見えます。
In this attack, the attacking node begins fabricating addresses with the subnet prefix and continuously sending packets to them. The last hop router is obligated to resolve these addresses by sending neighbor solicitation packets. A legitimate host attempting to enter the network may not be able to obtain Neighbor Discovery service from the last hop router as it will be already busy with sending other solicitations. This DoS attack is different from the others in that the attacker may be off-link. The resource being attacked in this case is the conceptual neighbor cache, which will be filled with attempts to resolve IPv6 addresses having a valid prefix but invalid suffix. This is a DoS attack.
この攻撃では、攻撃ノードは、サブネットプレフィックスでアドレスを作製し、継続的にそれらにパケットの送信を開始します。ラストホップルータは、近隣要請パケットを送信することにより、これらのアドレスを解決するために義務付けられています。それが他の勧誘を送信すると、すでに忙しくなるように、ネットワークを入力しようとする合法的なホストは、最後のホップルータから近隣探索サービスを取得することができない場合があります。このDoS攻撃は、攻撃者がオフリンクかもしれで他と異なっています。この場合には攻撃されているリソースが有効な接頭辞が、無効な接尾辞を持つIPv6アドレスを解決しようとする試みで満たされる概念近隣キャッシュ、です。これは、DoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation messages.
この章で論じられた脅威は近隣要請メッセージを含んでいます。
This attack does not directly involve the trust models presented. However, if access to the link is restricted to registered nodes, and the access router keeps track of nodes that have registered for access on the link, the attack may be trivially plugged. However, no such mechanisms are currently standardized.
この攻撃は、直接提示信頼モデルを必要としません。リンクへのアクセスが登録されたノードに制限され、アクセスルータがリンク上でのアクセスのために登録したノードを追跡している場合は、攻撃は自明差し込むことができます。しかし、そのようなメカニズムは現在、標準化されていません。
In a way, this problem is fairly similar to the TCP SYN flooding problem. For example, rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management may be applied.
ように、この問題は、TCP SYNフラッディング問題にかなり似ています。例えば、未解決の要請のために予約状態の量を制限する近隣要請、および巧妙なキャッシュ管理レート制限が適用されてもよいです。
It should be noted that both hosts and routers need to worry about this problem. The router case was discussed above. Hosts are also vulnerable since the neighbor discovery process can potentially be abused by an application that is tricked into sending packets to arbitrary on-link destinations.
両方のホストとルータは、この問題を心配する必要があることに注意すべきです。ルータの場合は、上述しました。近隣探索プロセスは、潜在的に任意のオンリンクの宛先にパケットを送信するようにだまされているアプリケーションによって悪用される可能性があるためホストも脆弱です。
Columns:
コラム：
N/R Neighbor Discovery (ND) or Router Discovery (RD) attack
N / R近隣探索（ND）またはルータ発見（RD）攻撃
R/D Redirect/DoS (Redir) or just DoS attack
R / Dリダイレクト/ DOS（REDIR）または単にDoS攻撃
Msgs Messages involved in the attack: NA, NS, RA, RS, Redir
攻撃に関与したSMSメッセージ：NANA、RA、RS、Redditに
1 Present in trust model 1 (corporate intranet)
信頼モデル1（企業のイントラネット）で1つの現状
2 Present in trust model 2 (public operator run network)
信頼モデルで2現在2（公共事業者の実行ネットワーク）
3 Present in trust model 3 (ad hoc network)
信頼モデル3（アドホックネットワーク）で3現状
Symbols in trust model columns:
信頼モデルの列の記号：
- The threat is not present or not a concern.
- 脅威が懸念存在かどうかではありません。
+ The threat is present and at least one solution is known.
+脅威が存在し、少なくとも一つの解決策が知られています。
R The threat is present but solving it is a research problem.
R脅威は存在するが、それを解決することは、研究の問題です。
Note that the plus sign '+' in the table does not mean that there is a ready-to-be-applied, standardized solution. If solutions existed, this document would be unnecessary. Instead, it denotes that in the authors' opinion the problem has been solved in principle, and there exists a publication that describes some approach to solve the problem, or a solution may be produced by straightforward application of known research and/or engineering results.
表中のプラス記号「+」は、すぐに適用され、標準化されたソリューションがあることを意味しないことに注意してください。ソリューションは存在していた場合は、この文書が不要になります。代わりに、それは著者の意見では問題は、原理的には解決されていることを示し、問題を解決するためにいくつかのアプローチを説明し、または溶液は、既知の研究および/またはエンジニアリング結果の単純なアプリケーションによって生成することができる出版物が存在します。
In the other hand, and 'R' indicates that the authors' are not aware of any publication describing a solution to the problem, and cannot at the time of writing think about any simple and easy extension of known research and/or engineering results to solve the problem.
一方では、と「R」は作者が問題の解決策を説明あらゆる出版物を認識していないことを示し、執筆の時点で知られている研究および/またはエンジニアリング結果のいずれかのシンプルで簡単な拡張を考えることはできません問題を解く。
+-------+----------------------+-----+-------+-------+---+---+---+
| Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + |
| 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + |
| 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R |
| 4.2.2 | Default router killed| RD | Redir | RA |+/R|+/R| R | 1)
| 4.2.3 | Good router goes bad | RD | Redir | RA RS | R | R | R |
| 4.2.4 | Spoofed redirect | RD | Redir | Redir | + | + | R |
| 4.2.5 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 2)
| 4.2.6 | Bogus address config | RD | DoS | RA | - | + | R | 3)
| 4.2.7 | Parameter spoofing | RD | DoS | RA | - | + | R |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.3.1 | Replay attacks | All | Redir | All | + | + | + |
| 4.3.2 | Remote ND DoS | ND | DoS | NS | + | + | + |
+------------------------------+-----+-------+-------+---+---+---+
Figure 1
図1
1. It is possible to protect the Router Advertisements, thereby closing one variant of this attack. However, closing the other variant (overloading the router) does not seem to be plausible within the scope of this working group.
1.それによって、この攻撃の一つの変形を閉じ、ルータ広告を保護することが可能です。しかし、他のバリアント（ルータに過負荷をかける）を閉鎖することは、このワーキンググループの範囲内でもっともらしいではないようです。
2. Note that the extended attack defined in Section 4.2.5 combines sending a bogus on-link prefix and performing NS/NA spoofing as per Section 4.1.1. Thus, if the NA/NS exchange is secured, the ability to use Section 4.2.5 for redirect is most probably blocked, too.
拡張された攻撃は、4.2.5項で定義されていること2.注意が偽のオンリンクプレフィックスを送信し、4.1.1項に従ってNS / NAスプーフィングを行っ兼ね備えています。 NA / NS交換が確保されていればこのように、リダイレクトについては、セクション4.2.5を使用する機能は、おそらくあまりにも、ブロックされています。
3. The bogus DNS registration resulting from blindly registering the new address via DNS update [4] is not considered an ND security issue here. However, it should be noted as a possible vulnerability in implementations.
3.盲目的DNSアップデート経由で新しいアドレスを登録起因する偽のDNS登録は、[4]ここでNDのセキュリティ上の問題を考慮されていません。しかし、それは実装で可能な脆弱性として注目されるべきです。
For a slightly different approach, see also Section 7 in [9]. Especially the table in Section 7.7 of [9] is very good.
わずかに異なるアプローチのために、[9]にも、セクション7を参照してください。特に[9]のセクション7.7のテーブルは非常に良好です。
This document discusses security threats to network access in IPv6. As such, it is concerned entirely with security.
この文書は、IPv6でのアクセスをネットワークにセキュリティ上の脅威について説明します。このように、それは完全にセキュリティを懸念しています。
Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for identifying the Neighbor Discovery DoS attack. We would also like to thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge as well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research Nomadiclab for discussing some of the threats with us.
近隣探索DoS攻撃を識別するためのドコモコミュニケーション研究所USAのアルパースYeginに感謝します。我々はまた、私たちと脅威のいくつかを議論するためのTuomasオーラとマイクロソフトリサーチケンブリッジのマイケル・ローだけでなく、ヤリArkkoとエリクソン研究Nomadiclabの、VESAマッティ・マンティラに感謝したいと思います。
Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay Devaparalli, Dave Thaler, and Alain Durand for their constructive comments.
彼らの建設的なコメントについてアルパースYegin、ペッカSavola、ビルゾンマーフェルト、ビジェイDevaparalli、デーブターラー、そしてアランデュランのおかげ。
Thanks to Craig Metz for his numerous very good comments, and especially for more material of implementations that refuse to accept ND overrides, for the bogus on-link prefix threat, and for reminding us about replay attacks.
彼の数多くの非常に良いコメント、および特にNDオーバーライドを受け入れることを拒否実装の多くの材料のために、偽のオンリンクプレフィックスの脅威のため、およびリプレイ攻撃についての私達に思い出させるためのクレイグ・メッツに感謝します。
[1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[1]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[3]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[4] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[4]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[5] Mankin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", Work in Progress.
[5]が進行中で働いてマンキン、A.、「モバイルIPv6およびモバイルIPv6のセキュリティ要件によって導入された脅威モデルを」。
[6] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", Work in Progress, June 2002.
[6]ケンプ、J.、紳士、C.及びA. Silverberg、 "セキュリティのIPv6近隣探索アドレスに基づく鍵（ABKs）の使用"、進歩、2002年6月の作業を。
[7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[7]卵、M.、進歩、2002年3月に仕事「更新と謝辞をバインドモバイルIPv6の認証」。
[8] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003.
[8] Arkko、J.、 "IKE上のICMPv6の影響"、進歩、2003年3月に仕事を。
[9] Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", Work in Progress, March 2003.
[9] Arkko、J.、「IPv6の近隣探索のためのセキュリティアソシエーションの手動設定」、進歩、2003年3月での作業。
Authors' Addresses
著者のアドレス
Pekka Nikander (editor) Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND
ペッカNikander（エディタ）エリクソン研究遊牧ラボJORVAS FIN-02420フィンランド
Phone: +358 9 299 1 EMail: pekka.nikander@nomadiclab.com
電話：+358 9 299 1 Eメール：pekka.nikander@nomadiclab.com
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
ジェームズ・ケンプドコモUSA Labsの181メトロドライブ、スイート300サンノゼ、CA 95110 USA
Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
電話：+1 408 451 4711 Eメール：kempf@docomolabs-usa.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94043 USA
エリックNordmarkとSun Microsystemsの17ネットワークサークルメンロパーク、CA 94043 USA
Phone: +1 650 786 2921 EMail: erik.nordmark@sun.com
電話：+1 650 786 2921 Eメール：erik.nordmark@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。