[要約] 要約：RFC 3756は、IPv6 Neighbor Discovery（ND）の信頼モデルと脅威に関する情報を提供しています。 目的：このRFCの目的は、IPv6 NDプロトコルのセキュリティ上の問題と脅威を理解し、適切な対策を講じるためのガイダンスを提供することです。
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
IPv6ネイバーディスカバリー（ND）信頼モデルと脅威
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）The Internet Society（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 Neighbor Discovery（ND）およびAddress AutoconfigurationメカニズムがIPSEC認証ヘッダー（AH）で保護される可能性があることを指定しています。ただし、現在の仕様により、自動キー管理に直面している実際の問題により、セキュリティソリューションが手動キーイングのセキュリティソリューションを制限しています。このドキュメントは、3つの異なる信頼モデルを指定し、IPv6 Neighbor Discoveryに関連する脅威について説明します。この議論の目的は、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 Neighbor Discovery（ND）RFC 2461 [2]およびArdats autoconfiguration RFC 2462 [3]メカニズムは、IPv6ネットワークのノードによって使用され、ローカルトポロジー、ローカルノード、IP、IP、およびIPのMACアドレスマッピングを含むローカルトポロジーを学習します。ローカルネットワークに存在するルーターの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.
問題を解決するために、Secure Neighbor Discovery（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.
送信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 Neighbor Discoveryを指定し、Autoconfigurationプロトコルに対処するRFC [2] [3]には、セキュリティに関する考慮事項セクションにセキュリティの必要な議論が含まれています。このドキュメントで特定された脅威のいくつかは、元の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.
近隣の発見とAutoconfiguration Protocolsがホストが初期アクセスを取得する方法にある程度取引するため、今日の現在の現在の現在の現在のところ、リンク上の最後のホップルーターまたはリンク上の他のホストとの間の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.
さらに、近隣の発見とアドレスAutoconfigurationは、いくつかの固定マルチキャストアドレスに加えて、1600万の「Solicated Node」マルチキャストアドレスを使用します。事前に構成されたSASの素朴なアプリケーションでは、特定の勧誘されたノードマルチキャストアドレスが使用された場合に備えて、各ホストとルーターに不可能な数のSASを事前に構成する必要があります。事前に設定されたSASは、このような大きな潜在的なアドレス範囲を確保するために非現実的です。
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 Neighbor Discovery（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）の2つのカテゴリに大まかに分割されています。前者は、主にルーターを関与させない操作を示しますが、後者のカテゴリの操作は行われます。
Three different trust models are specified:
3つの異なる信頼モデルが指定されています。
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. すべての認証されたノードが互いに信頼してIPレイヤーで正しく動作し、誤った情報を含むNDまたはRDメッセージを送信しないモデル。このモデルは、ノードが単一の投与の下にあり、閉じたまたは半閉鎖グループを形成する状況を表すと考えられています。コーポレートイントラネットは良い例です。
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.
このモデルは、オペレーターが実行するパブリックネットワークを表すと考えられています。クライアントはオペレーターに支払い、資格情報を持ち、IP転送サービスを提供するためにそれを信頼します。クライアントは、お互いを信頼して正しく行動することを信頼していません。他のクライアントノードは、偽造されたNDおよびRDメッセージを送信できると見なされる必要があります。
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アクセス制御を備えた有線LANまたはAES暗号化を備えた802.11iの堅牢なセキュリティネットワーク（RSN）を備えたWLANは、この信頼モデルの下でさらなる保護を必要としません。一方、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.
ネットワークが物理的に固定されておらず、リンクレイヤーに暗号化保護がない場合、または暗号化保護が十分に安全でない場合（たとえば、WLANで802.1xではなく802.1xではありません）、ネットワーク内のノードは脆弱である可能性がありますセクション4で概説されている脅威の一部またはすべては、そのような場合、NDを確保するためにある程度の保護が望ましい。このような保護を提供することは、送信ワーキンググループの主要な初期焦点に分類されます。
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.
さらに、ノードが侵害される場合の潜在的な損傷の量を制限することが望ましいです。たとえば、侵害されたノードがサービス拒否攻撃を開始できることはまだ受け入れられるかもしれませんが、既存の接続をハイジャックしたり、新しい接続に対する中間の攻撃を確立することができれば望ましくありません。
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を保護する可能性の1つは、すべての信頼できるノードと部外者が知らない対称共有キーで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]：IKEを実行するにはIPアドレスが必要です。IKESを確立するにはIKEが必要です。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.
例として、この制限を克服するための1つの可能なアプローチは、公開キーの暗号を使用し、公開キーの署名で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転送サービスを提供することをオペレーターに信頼すると想定される場合があります。ただし、クライアントは通常お互いを信頼しません。通常、ルーター（またはルーター）は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 Neighbor Discoveryに関するセキュリティを提供しません。
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つの方法があるようです。1つの可能性は、クライアントとアクセスルーター間の強力なセキュリティを実施し、アクセスルーターにIPおよびリンク層プロトコルの詳細を認識させることです。つまり、ルーターはICMPV6パケットの内容を確認し、ネットワークトポロジと一致しない情報を含むフィルターパケットを確認します。もう1つの認められる方法は、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.
アプリオリの信頼関係はないため、ノードは従来の認証に依存することはできません。つまり、従来の認証プロトコルは、当事者間の既存の関係に依存しています。関係は直接的または間接的かもしれません。間接的なケースは、1つ以上の信頼できる第三者に依存しており、それにより、当事者間の信頼関係の連鎖を生み出します。
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. ノードは、ノードのアドレスを含む近隣の勧誘を受信します。ノードはそれを使用して近隣キャッシュを入力できます。これは基本的にパフォーマンスの最適化であり、ベースドキュメントにあるはずです。
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で返信します。ただし、勧誘ノードに返信がない場合、さらに数回試行され、最終的にNeighbor Cacheエントリを削除します。必要に応じて、これにより、標準のアドレス解像度プロトコルをトリガーして、新しい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の脅威にさらされます。他の2つの信頼モデルでは、ソリューションでは、NODを実行するノードが本物と製造された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.
入力ホストがStateless Address Autoconfiguration [3]を使用してアドレスを取得するネットワークでは、攻撃ノードは、入力ホストによって行われたすべての複製アドレス検出試行に応答することにより、DOS攻撃を開始できます。攻撃者が住所を請求する場合、ホストは住所を取得することができません。攻撃者は2つの方法で住所を請求することができます。NSで返信して、パパを実行していることをシミュレートするか、NAで返信して、すでに住所を使用していることをシミュレートできます。この脅威は、RFC 2462 [3]で特定されました。この問題は、他のタイプのアドレス構成が使用されている場合、つまり、提案されたアドレスを実際に構成する前にパパが呼び出されるときはいつでも存在する場合があります。これは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の脅威にさらされます。他の2つの信頼モデルでは、ソリューションでは、NODEを実行するノードがNA応答の送信者が指定されたIPアドレスを使用することを許可されているかどうかを確認できることが必要です。信頼できるオペレーターのケースでは、オペレーターは承認者として機能し、割り当てられたアドレスを追跡し、ノードがいくつか（数百）のアドレスを割り当てられていないことを確認することができます。一方、1つのノードが多数のアドレスを持つことが望ましい場合、たとえば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.
アドホックネットワークケースでは、自己許可が可能であるようにアドレスを構成したい場合があります。
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の最後のホップルーターを装って、ホストに入ることからのマルチキャストルーター広告の勧誘に応えて装っています。入力ホストが攻撃者をデフォルトのルーターとして選択した場合、攻撃者はホストからトラフィックを吸い上げるか、中間の攻撃をマウントする機会があります。攻撃者は、エントリホストが、寿命がゼロのリアルラストホップルーターのマルチリキャスト周期ルーター広告によってデフォルトのルーターとして選択されることを保証できます。これは、実際のアクセスルーターがトラフィックを取ることをいとわないと信じるように入力するホストを吹き込みます。正当なルーターとして受け入れられると、攻撃者はリダイレクトメッセージをホストに送信してから消えて、そのトラックを覆うことができます。
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.
この攻撃は、リンクへのアクセスが信頼できるノードに制限されている場合、懸念事項ではありません。信頼できるノードが侵害された場合、他のノードはこの脅威にさらされます。ただし、たとえば、新しいルーターよりも既存のノードを優先するように構成することにより、多くの手段を通じて脅威を部分的に軽減できます。このアプローチは、実装の詳細に応じて、必ずしもネットワークに新しいルーターを導入することを防ぐとは限らないことに注意してください。少なくとも、既存のノードが新しいノードよりも既存のノードを好むようにするだけです。
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 [2]のセクション5.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.
攻撃者がデフォルトのルーターを「殺す」ことができる方法はいくつかあります。1つは、ルーターに対する古典的なDOS攻撃を開始して、応答性の高いものにならないようにすることです。もう1つは、ゼロルーターの寿命でスプーフィングされたルーター広告を送信することです（RFC 2461 [2]のセクション6.3.4を参照）。ただし、上記のセクション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.
このサブセクションで説明されている脅威には、ルーター広告メッセージが含まれます。この脅威の1つのバリアントは、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.
この脅威を特定してくれたAlain Durandに感謝します。
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つの信頼モデルのいずれにも既知のソリューションはありません。一方、マルチルーターリンクでは、ルーターの権利の取り消しを含む解決策を想像できます。状況は研究の質問として残っています。
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.
リダイレクトメッセージを使用して、特定の宛先のパケットをリンク上のリンク層アドレスに送信できます。攻撃者は、正当なホストにリダイレクトメッセージを送信するために、現在の最初のホップルーターのリンクローカルアドレスを使用します。ホストは、Link-Localアドレスによるメッセージを最初のホップルーターから識別するため、リダイレクトを受け入れます。攻撃者が近隣の到達不能検出プローブにリンク層アドレスに応答する限り、リダイレクトは引き続き有効になります。これはリダイレクト/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.
攻撃ノードは、任意の長さの何らかのプレフィックスがリンクであることを指定するルーター広告メッセージを送信できます。送信ホストがプレフィックスがリンクであると考えている場合、そのプレフィックスのパケットをルーターに送信することはありません。代わりに、ホストは隣人の勧誘を送信することでアドレス解決を実行しようとしますが、隣人の勧誘は攻撃されたホストへのサービスを拒否し、応答をもたらさないでしょう。これは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.
この脅威には、ルーター広告メッセージが含まれます。拡張攻撃は、セクション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).
例として、この攻撃の損傷を制限する可能性のあるアプローチの1つは、宣伝されているオンリンクプレフィックスBE /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.
攻撃ノードは、アドレスAutoconfigurationのためにホストが使用する無効なサブネットプレフィックスを指定するルーター広告メッセージを送信できます。アドレスを実行するホストAutoconfigurationアルゴリズムは、広告されたプレフィックスを使用してアドレス[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. 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アップデート[4]により、偽のアドレスが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エントリを作成することにより、攻撃をより深刻にすることができます。接頭辞<Atthip_prfx>に正当なアクセスを持つ攻撃者と、インターフェイスID <Target_iid>を持っているターゲットを検討してください。攻撃者は、<astita_prfx>：<target_iid>の逆DNSエントリを作成し、ターゲットの実際のドメイン名を指します。たとえば、「Secure.target.com」。次に、攻撃者は、ターゲットのリンクで<Atthip_prfx>プレフィックスを宣伝します。ターゲットは、アドレス<Atthip_prfx>：<Target_iid>を作成し、DNSエントリを更新して、「secure.target.com」が<astita_prfx>：<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.
この時点で、「secure.target.com」は<astitad_prfx>：<Target_iid>、および<Attack_prfx>：<target_iid>を指します。「secure.target.com」この脅威は、<Atthip_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 Router Advertisement from the legitimate default router, except the included parameters are designed to disrupt legitimate traffic. This is a DoS attack.
IPv6ルーター広告には、ホストがパケットを送信するときに使用されるいくつかのパラメーターが含まれており、ホストにステートフルなアドレス構成を実行するかどうかを伝えるために[2]。攻撃ノードは、正当なデフォルトルーターからルーター広告を複製する有効なルーター広告を送信できます。これは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.
例として、この脅威を軽減するための可能なアプローチの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 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が含まれる場合があります。したがって、古い応答は正しいノンセを含んでいないため、有効ではありません。それに対応して、未承諾の広告やリダイレクトメッセージなどのスタンドアロンメッセージは、タイムスタンプまたはカウンターで保護される場合があります。実際には、受信者は異なるノードのクロック間の違いを追跡し、すべての新しいメッセージが最後の見られたメッセージよりも新しいことを確認する可能性があるため、大まかに同期した時計とタイムスタンプがうまく機能しているようです。
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攻撃は、攻撃者がオフリンクである可能性があるという点で、他の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 Redirect/DOS（Redir）またはDOS攻撃のみ
Msgs Messages involved in the attack: NA, NS, RA, RS, Redir
攻撃に関与するSMSメッセージ：Na、Na、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.
+ 脅威が存在し、少なくとも1つのソリューションが既知です。
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. ルーターの広告を保護し、それにより、この攻撃の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.
2. セクション4.2.5で定義されている拡張攻撃は、セクション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アップデート[4]を介して盲目的に新しいアドレスを登録したことに起因する偽のDNS登録は、ここではセキュリティの問題とは見なされません。ただし、実装の脆弱性の可能性として注意する必要があります。
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.
Docomo Communications Laboratories USAのAlper Yeginに感謝します。また、Microsoft Research CambridgeのTuomas AuraとMichael Roe、Ericsson Research NomadiclabのJari ArkkoとVesa-Matti Mantylaの脅威について議論してくれたことにも感謝します。
Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay Devaparalli, Dave Thaler, and Alain Durand for their constructive comments.
Alper Yegin、Pekka Savola、Bill Sommerfeld、Vijay Devaparalli、Dave Thaler、およびAlain Durandの建設的なコメントに感謝します。
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] Kent、S。およびR. Atkinson、「IP Authentication Header」、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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[3] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[4] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[4] ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[5] Mankin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", Work in Progress.
[5] Mankin、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] Kempf、J.、Gentry、C。and A. Silverberg、「アドレスベースのキー（ABKS）を使用したIPv6ネイバーディスカバリーの保護」、2002年6月、進行中の作業。
[7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[7] Roe、M。、「モバイルIPv6のバインディングの更新と謝辞の認証」、2002年3月、進行中の作業。
[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 Neighbor Discoveryのセキュリティ協会の手動構成」、2003年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Pekka Nikander (editor) Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND
Pekka Nikander（編集者）エリクソン研究遊牧民ラボJorvas Fin-02420フィンランド
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
James Kempf Docomo USA Labs 181 Metro Drive、Suite 300 San Jose、CA 95110 USA
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94043 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park、CA 94043 USA
Phone: +1 650 786 2921
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。