RFC3756 日本語訳
3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats. P.Nikander, Ed., J. Kempf, E. Nordmark. May 2004. (Format: TXT=56674 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループP.Nikander、エドをネットワークでつないでください。コメントのために以下を要求してください。 3756年のエリクソンの研究の遊牧民的な研究室カテゴリ: 情報のJ.の米国研究室E.Nordmarkサン・マイクロシステムズ研究所ケンフDoCoMo2004年5月
IPv6 Neighbor Discovery (ND) Trust Models and Threats
IPv6隣人発見(ノースダコタ)信頼モデルと脅威
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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ディスカバリー(ノースダコタ)とAddress AutoconfigurationメカニズムがIPsec Authentication Header(AH)と共に保護されるかもしれないと指定します。 しかしながら、現在の仕様はセキュリティソリューションを実用的な自動かぎ管理に直面していた問題のため手動の合わせるのに制限します。 このドキュメントは、3つの異なった信頼モデルを指定して、IPv6 Neighborディスカバリーに適切な脅威について議論します。 この議論の目的はSecuring IPv6 Neighborディスカバリーのための要件を定義することです。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 所見. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 前の仕事。 . . . . . . . . . . . . . . . . . . . . . . . . 4 3. モデル. . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1を信じてください。 企業イントラネットモデル。 . . . . . . . . . . . . . . . . 5 3.2. オペレータとの公立のワイヤレス・ネットワーク。 . . . . . . . . 6 3.3. 臨時のネットワーク。 . . . . . . . . . . . . . . . . . . . . . 7 4. (公共)のマルチアクセスの脅威はリンクされます。 . . . . . . . . . . . 8 4.1. 非ルータ/ルーティングは脅威を関係づけました。 . . . . . . . . . . . 9 4.1.1. 隣人懇願/広告スプーフィング. . . 9 4.1.2。 隣人Unreachability Detection(NUD)の故障。 . 10 4.1.3. アドレス検出DoS攻撃. . . . . . 11 4.2をコピーしてください。 脅威を伴うルータ/ルーティング。 . . . . . . . . . . . . 12 4.2.1. 最後の悪意があるホップルータ。 . . . . . . . . . . . . 12
Nikander, et al. Informational [Page 1] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[1ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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
4.2.2. デフォルトルータは.134.2に'殺されて'.3です。 良いルータは.144.2に.4に腐ります。 再直接のメッセージ. . . . . . . . . . . . . 14 4.2.5であると偽造されます。 リンクの上のにせの接頭語. . . . . . . . . . . . . . . 14 4.2.6。 にせのアドレス構成接頭語. . . . . . . . 15 4.2.7。 パラメタスプーフィング. . . . . . . . . . . . . . . . 16 4.3。 反射攻撃と離れて利用可能な攻撃. . . . . 17 4.3.1。 反射攻撃. . . . . . . . . . . . . . . . . . 17 4.3.2。 隣人発見DoSは攻撃します。 . . . . . . . . . . 18 4.4. 攻撃の概要。 . . . . . . . . . . . . . . . . . 19 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 20 6. 承認. . . . . . . . . . . . . . . . . . . . . . . 21 7。 有益な参照. . . . . . . . . . . . . . . . . . . . 21作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 22の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
1. 序論
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ディスカバリーRFC2461[2]とAddress Autoconfiguration RFC2462[3](ノースダコタ)メカニズムはノードによってIPv6ネットワークに使用されて、地方のトポロジーを学びます、ローカルのノード、IP、企業内情報通信網における現在のルータのMACアドレス、およびローカルルータによって役立たれるルーティング接頭語のためのMACアドレス・マッピングにIPを含めて。 現在の仕様は、IPsec AH RFC2402[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ディスカバリー(SEND)ワーキンググループはFall2002でチャーターされました。 ワーキンググループの目標は過度の手動の合わせることを必要としないでIPv6 Neighborがディスカバリーであると機密保護するプロトコルサポートを定義することです。
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.
このドキュメントの目的はSecure IPv6 Neighborディスカバリーメカニズムが働くと予想されるネットワークのタイプ、およびセキュリティプロトコルが演説しなければならない脅威を定義することです。 この目的を実現させるために、このドキュメントは最初に3つの異なった信頼モデルを定義します、およそ機密保護している企業イントラネット、公立のワイヤレス・アクセスネットワーク、および純粋な臨時のネットワークに対応しています。 その後に、これらの信頼モデルの見地から多くの脅威について議論します。 脅威カタログは徹底的になるように目的とされますが、いくつかの脅威がまだなくなっているのは、ありそうです。 したがって、考える新しい脅威のための考えは請求されます。
Nikander, et al. Informational [Page 2] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[2ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
1.1. Remarks
1.1. 注意
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特許がワーキンググループの範囲を安全なNeighborディスカバリー機能に制限することに注意してください。 その上、特許は基本的な目標としてNeighborディスカバリーの後ろで明らかに構成について全く言及しません。 この仕事の範囲の外にネットワークアクセス認証とアクセスコントロールがあります。
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.
重要。 このドキュメントは時折Cryptographically Generated Addresses(CGA)[7]やAddress Basedキーズ(ABK)[6]などのソリューション提案について議論します。 しかしながら、そのような議論は唯一説明に役立った目的のためのものです。 目的は以上が考えが*いくつか具体的である読者aに*可能なソリューションを与えることです。 そのような議論は作者かワーキンググループに代わってソリューションにおける少しの好みも示しません。
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.
「信じる」という用語が本書ではかなり非技術系の方法で使用されることに注意されるべきです。 最も適切な解釈はそれが組織的であるか集合的な信念(すなわち、他の関係者の今後の振舞いに関する一般的に共有された信念の式)の式であるとみなすことです。 逆に、「信頼関係」という用語はパーティーが、相手が将来さえ正しく振る舞うと信じているかかわった組織かパーティーの間の先験的な互いの関係を指示します。 信頼関係で認証と承認情報を構成するのはパーティーの間で可能になります、そのような情報をあらかじめ設定するのがそのような関係の不足で不可能になりますが。
Nikander, et al. Informational [Page 3] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[3ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
2. Previous Work
2. 前の仕事
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ディスカバリーとAddress Autoconfigurationプロトコル[2][3]を指定するRFCsはSecurity Considerations部でのセキュリティの必要な議論を含んでいます。 本書では特定された脅威のいくつかがオリジナルのRFCsで上げられました。 お勧めの療法はIPsec AH[1]ヘッダーと共にかかわったパケットを機密保護することでした。 しかしながら、その推薦は、今後の活動のためのかぎ管理にAHを残すことによって、問題を単純化しすぎます。 例えば、Public Accessネットワークへのアクセスを得るのを試みるホストはネットワークと共に必要な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セキュリティ仲間も、手動で完全にあらかじめ設定される必要があるでしょう、NeighborディスカバリーとAddress Autoconfigurationプロトコルがホストがどうリンクへの初期のアクセスを得るかにある程度対処するので。 したがって、セキュリティ協会が初期のアクセスに必要であり、ホストにその協会がないなら、現在、ホストがその関係でダイナミックにそれ自体を構成できるどんな標準の方法もありません、それに材料を合わせる必要な最小の前提条件があっても。 再の合わせなどなどのイベントが起こるとき、この状況は管理苦労を引き起こすかもしれません。
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.
さらに、NeighborディスカバリーとAddress Autoconfigurationは1600万の「請求されたノード」マルチキャストアドレスのいくつかの固定マルチキャストアドレスと範囲を使用します。 まさしく与えられた請求されたノードマルチキャストアドレスが使用されているといけないので、あらかじめ設定されたSAsのナイーブなアプリケーションは、各ホストとルータで「非-処理しやす」番号をあらかじめ設定するのをSAsを要求するでしょう。 そのような大きい潜在的アドレスの範囲を保証するのに、あらかじめ設定されたSAsは非実用的です。
3. Trust Models
3. 信頼モデル
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ディスカバリー(ノースダコタ)[2]のために様々なセキュリティソリューションを考えるとき、念頭に基本的な信頼がモデルであることを保つのは重要です。 後で特定の脅威について議論するとき、このセクションで定義された信頼モデルは本書では使用されます。
Nikander, et al. Informational [Page 4] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[4ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
以下では、RFC2461/RFC2462メカニズムは緩く2つのカテゴリに分割されます: 隣人発見(ノースダコタ)とルータ発見(RD)。 後者のカテゴリにおける操作は指示しますが、前者は主としてルータにかかわらない操作を指示します。
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層で正しく振る舞って、偽情報を含むメッセージをどんなノースダコタや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層で正しく振る舞って、ルータが偽情報を含むメッセージをどんなノースダコタや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を提供するためにオペレータに支払って、資格証明書を持って、それを信じます。 クライアントは、互いが正しく振る舞うと信じません。 改竄されたノースダコタと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.
ノードが第1代信頼モデル(企業イントラネット)で互いを信じると思われますが、感染されるようになるならノードが企業内情報通信網に課すことができる損害の程度を制限するのがまだ望ましいことに注意してください。
3.1. Corporate Intranet Model
3.1. 企業イントラネットモデル
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
このモデルの下では、物理的にネットワークを保証するか、または暗号で必要である範囲にリンクレイヤを固定するなら、他の保護を全くIPv6ノースダコタに必要としません、ノードのいずれも感染されるようにならない限り。 または例えば、802.1xアクセスコントロールがあるワイヤードなLAN。
Nikander, et al. Informational [Page 5] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[5ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
AES暗号化がある802.11i Robust Security Network(RSN)とWLANは十分安全であると考えられるかもしれません、これ以上この信頼モデルの下で保護を必要としないで。 他方では、ノースダコタセキュリティはこのモデルの下でさえ保護の深さを加えるでしょう(以下を見てください)。 その上、どんな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.11iではなく、まさしく802.1x)、ネットワークにおけるノードはセクション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.
その上、場合における、可能性のあるダメージの量を制限するために、ノードが感染されるようになるのは、望ましいです。 例えば、感染しているノードが-既存の接続をハイジャックできるならサービス攻撃において、だけ望ましくないという否定に着手するか、または新しい接続のときに介入者攻撃を確立できるのが、まだ許容できているかもしれません。
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、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がIPsec SAsを設立するのが必要であり、IPsec SAsはIPアドレスを構成しなければなりません人がIKEを実行するのにIPアドレスが必要があります、そして、。 その上、対称鍵暗号でノースダコタを確保する少しの簡単で効率的な方法もあるように思えません。 セキュリティ協会の必要数は非常に大きい[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つの可能なアプローチは、公開鍵暗号を使用して、直接公開鍵署名でノースダコタがパケットであることを保証することです。
3.2. Public Wireless Network with an Operator
3.2. オペレータとの公立のワイヤレス・ネットワーク
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
オペレータが公立のワイヤレス(または、ワイヤーライン)のネットワークを経営しているシナリオ(例えば、ホテル、空港、またはカフェのWLAN)には、異なった信頼モデルがあります。 ここで、ノードが、オペレータがクライアントのトラフィックを信頼できる方法でサービスを進めながらIPを提供して、混乱させるか、または誤った指導しないと信じると思われるかもしれません。 しかしながら、クライアントはそうします。
Nikander, et al. Informational [Page 6] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[6ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
通常、互いを信じてください。 通常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ディスカバリーに関して少しのセキュリティも提供しません。
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パケットコンテンツ、およびフィルタパケットをチェックするでしょう。 もう片方のことによると許容できる道はノースダコタメッセージを伝えながらICMPv6パケットに暗号の保護を加えることです。
3.3. Ad Hoc Network
3.3. 臨時のネットワーク
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層で正しく振る舞うだろうという保証が全くありません。 改竄されたノースダコタとRDにメッセージを送るために疑わしげであるとそれらを考えなければなりません。
Nikander, et al. Informational [Page 7] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[7ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
Cryptographically Generated Addresses(CGA)[7]などの自己を特定するメカニズムを使用するのはまだ可能です。 これらで、ノードは、本当に、それぞれのノードが彼らが(従来と同様)いつも同じノードと話していて、自分たちでそれらのIPアドレスを作って、他の誰かのアドレスを「盗んでいないこと」を保証できます。 また、様々な種類の発見的教授法を使用するどんなルータのアイデンティティも学ぶのも可能であるかもしれません、インターネットのどこかで知られていて信じられたノードに向かって暗号で保護されたトラフィックを伝えるノードの性能をテストするのなどように。 これらのようなメソッドは次のセクションで概説された攻撃の(しかし、完全にブロックであるというわけではない)いくつかを緩和するように思えます。
4. Threats on a (Public) Multi-Access Link
4. (公共)のマルチアクセスリンクにおける脅威
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 Neighborディスカバリーメカニズムに対して脅威について議論します。 前項で定義された信頼モデルの見地から脅威について議論します。
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目的に再直接の攻撃を使用できます。
Nikander, et al. Informational [Page 8] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[8ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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つの小区分で組織化されます。 私たちは最初に、ルータかルーティング情報にかかわらない脅威を考えます。 私たち、次はルータかルーティング情報にかかわる脅威を考えます。 最終的に、私たちは離れて利用可能な反射攻撃と脅威を考えます。 信頼モデルの見地からすべての脅威について議論します。
4.1. Non router/routing related threats
4.1. 非ルータ/ルーティングは脅威を関係づけました。
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.
このセクションで、私たちはAddress Autoconfigurationで「純粋な」Neighborディスカバリー機能、すなわち、Neighborディスカバリー(ノースダコタ)、Neighbor Unreachability Detection(NUD)、およびDuplicate Address Detection(DAD)に対して攻撃について議論します。
4.1.1. Neighbor Solicitation/Advertisement Spoofing
4.1.1. 隣人懇願/広告スプーフィング
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:
リンクの上のノードはNeighbor SolicitationとIPアドレスとMACアドレスの間で結合を作成するAdvertisementメッセージを使用します。 Solicitationsを受けるときノードが隣人キャッシュエントリーを作成するとき、より明確に、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. ノードはノードのアドレスを含むNeighbor Solicitationを受けます。 ノードは、隣人キャッシュに居住するのにそれを使用できます。 これは、基本的にパフォーマンスの最適化と、元にした文書の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. Duplicate Address Detection(DAD)の間、ノードがそれが請っている同じアドレスのためにNeighbor Solicitationを受けるなら、状況は衝突であると考えられます、そして、ノードは前述のアドレスを請うのをやめなければなりません。
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.
攻撃ノードで、正統のノードのためのパケット、ホストとルータの両方をある他のリンクレイヤアドレスに送ることができます。 異なったソースリンクレイヤアドレスオプションと共にNeighbor Solicitationを送るか、または異なった目標リンクレイヤアドレスオプションと共にNeighbor Advertisementを送ることによって、これができます。
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.
新しいリンクレイヤアドレスによるNeighbor Cacheエントリーが老人を上書きするので、攻撃は成功します。 偽造しているリンクレイヤアドレスが有効なものであるなら、攻撃者がNeighbor Unreachability Detectionの一部として送られたユニキャストNeighbor Solicitationメッセージに応じる限り、パケットは、向け直され続けるでしょう。 これは再直接の/DoS攻撃です。
Nikander, et al. Informational [Page 9] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[9ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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攻撃に未使用のリンクレイヤアドレスを指定することによって、このメカニズムを使用できます。 しかしながら、Neighbor Unreachability Detectionメカニズムが30-50秒(デフォルトタイマ値がある)以降リンクレイヤアドレスを発見するために新たに悪いリンクレイヤアドレスとマルチキャストを捨てるので、このDoS攻撃は限られた持続時間のものです。 結果として、攻撃者は、タイムアウトを超えて攻撃を維持したいなら作られたリンクレイヤアドレスで応じ続ける必要があるでしょう。
The threat discussed in this subsection involves Neighbor Solicitation and Neighbor Advertisement messages.
この小区分で議論した脅威はNeighbor SolicitationとNeighbor Advertisementメッセージにかかわります。
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.
さらに、いくつかの実装が、誤りを登録して、ノースダコタ重ね書きを受け入れるのを拒否します、最初に代わりに古いエントリーをタイムアウトに必要として。
4.1.2. Neighbor Unreachability Detection (NUD) failure
4.1.2. 隣人Unreachability Detection(NUD)の故障
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.
リンクの上のノードはNeighbor Unreachability Detection手順[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
悪意があるノードはNUD NSメッセージに対応して作られたNAsを送り続けるかもしれません。 長い間、NAメッセージがどうにか保護されない場合、攻撃者はこのテクニックを使用するのにおいて攻撃を広げることができるかもしれません。 実際の結果はノードがなる理由に依存します。
Nikander, et al. Informational [Page 10] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[10ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
1位と、ノードが手が届かなくなったのを知っているなら目標ノードがどう振る舞うかに、手が届きません。 これはDoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
この小区分で議論した脅威はNeighbor Solicitation/広告メッセージにかかわります。
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つの信頼モデルの下では、ソリューションは、NUDを実行するノードが本物の、そして、作られたNA応答の間で区別をすることができるのを必要とします。
4.1.3. Duplicate Address Detection DoS Attack
4.1.3. アドレス検出DoS攻撃をコピーしてください。
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つの方法でアドレスを要求できます: それは、NS、シミュレートでまた、DADを実行しているか、またはNA、シミュレートで既にアドレスを使用に連れていったと返答できると返答できます。 この脅威はRFC2462[3]で特定されました。 また、実際に提案されたアドレスを構成する前にDADが呼び出されるときはいつも、他のタイプのアドレス構成がすなわち、使用されるとき、問題も存在しているかもしれません。 これはDoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
この小区分で議論した脅威はNeighbor Solicitation/広告メッセージにかかわります。
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つの信頼モデルの下では、ソリューションは、DADを実行するノードが、NA応答の送付者が与えられたIPアドレスを使用するのに権限を与えられるかどうか確かめることができるのを必要とします。 信じられたオペレータ事件では、authorizer、アドレスが動向をおさえるのが割り当てられて、確実にそれをどんなノードにもしないと(何百)アドレスがかなり多くに割り当てられたとき、オペレータは行動するかもしれません。 他方では、そのような習慣を採用するのは有害であるかもしれません、1つのノードには多くのアドレスがあるのが、例えば望ましくて、TCP接続あたり1つの別々のアドレスを作成するか、またはノースダコタプロキシを車で送るとき、状況があるかもしれないので。 したがって、ISPが、正統のホストがいくつのアドレスを持つことができるかを制御するかもしれないのを示すのは不適当であるかもしれません。 単に初めに例述べられるようにこのドキュメントについて上の議論を考えなければなりません。
Nikander, et al. Informational [Page 11] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[11ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
In the ad hoc network case one may want to structure the addresses in such a way that self authorization is possible.
臨時のネットワーク場合では、自己承認が可能であるような方法でアドレスを構造化したがっているかもしれません。
4.2. Router/routing involving threats
4.2. 脅威を伴うルータ/ルーティング
In this section we consider threats pertinent to router discovery or other router assisted/related mechanisms.
このセクションでは、私たちは、ルータ発見か他のルータに適切な脅威がメカニズムを補助したか、または関係づけたと考えます。
4.2.1. Malicious Last Hop Router
4.2.1. 最後の悪意があるホップルータ
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に特定ではありませんでした。 また、それはRFC2461[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 Router Advertisementsかunicasting Router Advertisementsで入っているホストからのマルチキャストRouter Advertisement Solicitationsに対応してルータを飛び越します。 入っているホストがデフォルトルータとして攻撃者を選定するなら、攻撃者にはホストからトラフィックを吸収するか、または中の男性を取り付ける機会がある、-、-、中央、攻撃してください。 攻撃者は、入っているホストがゼロの生涯を持っている最後の本当のホップルータのためにデフォルトルータとしてマルチキャスティングの周期的なRouter Advertisementsでそれ自体を選定したのを保証できました。 本当のアクセスルータがどんなトラフィックも取ることを望んでいないと信じているのにこれは入っているホストを偽造するかもしれません。 正統のルータとしていったん認められると、攻撃者はホストへのメッセージをRedirectに送って、次に、姿を消して、その結果、証拠を隠すかもしれません。
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.
この脅威はRFC2462で部分的に緩和されます。 .3セクション5.5RFC2462年に、寿命が広告を出している接頭語であるなら2時間未満であることが必要であり、パケットが認証されなかったなら、保存された寿命は保存された生涯ほど短縮されません。 しかしながら、RFC2461についてセクション6.3で.6に定義されるデフォルトルータ選択手順はそのような規則を含んでいません。
The threat discussed in this subsection involves Router Advertisement and Router Advertisement Solicitation messages.
この小区分で議論した脅威はRouter AdvertisementとRouter Advertisement Solicitationメッセージにかかわります。
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.
リンクへのアクセスが信じられたノードに制限されるなら、この攻撃は関心ではありません。 信じられたノードが感染されるなら、他のノードはこの脅威に暴露されます。 しかしながら、例えば、新しいものより既存のルータを好むためにノードを構成することによって、多くの手段で脅威を部分的に緩和できます。 人がこのアプローチによって必ず新しいルータをネットワークに取り入れることができないというわけではないことに注意してください、実装の詳細によって。 最小限では、それは、新しい方より既存のルータを好むためにただ既存のノードを作ります。
Nikander, et al. Informational [Page 12] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[12ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
信じられたオペレータの場合には、ノードがオペレータによって実行された信頼できるルータの間で区別をする手段と他のノードがあるに違いありません。 現在、臨時のネットワークケースのための広く受け入れられたソリューションが全くありません、そして、問題は研究質問として残っています。
4.2.2. Default router is 'killed'
4.2.2. デフォルトルータは'殺されます'。
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.
この攻撃では、攻撃者はデフォルトルータを'殺します'、その結果、すべてのノードがローカルであると仮定するためにリンクの上にノードを作ります。 RFC2461[2]のセクション5.2では、それが述べられている、それ、「[if]、Default Router Listが空である、送付者が目的地がオンであると仮定する、リンク、」 したがって、攻撃者がリンクの上にデフォルトルータが全くないと信じるためにノードを作ることができると、ノードは直接パケットを送ろうとするでしょう、Neighborディスカバリーを使用して。 その後に、攻撃者はオフリンクの目的地に対してさえだます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攻撃に着手することになっているので、それはもう敏感に見えません。 もう片方はゼロがある偽造しているRouter AdvertisementにRouter Lifetimeを送ることです。(.4セクション6.3RFC2461[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.
この小区分で議論した脅威はRouter Advertisementメッセージにかかわります。 この脅威の1つの異形がどんなノースダコタ/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.
リンクへのアクセスが信じられたノードに制限されるなら、この攻撃は関心ではありません。 信じられたノードが感染されるなら、他のノードはこの脅威に暴露されます。 信じられたオペレータの場合には、ノードがオペレータによって実行された信頼できるルータの間で区別をする手段と他のノードがあるに違いありません。 それは偽造しているRouter Advertisementsから守りますが、それはルータ積みすぎから守りません。 現在、臨時のネットワークケースのための広く受け入れられたソリューションが全くありません、そして、問題は研究質問として残っています。
Thanks to Alain Durand for identifying this threat.
アラン・ジュランドにこの脅威を特定してくださってありがとうございます。
Nikander, et al. Informational [Page 13] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[13ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
4.2.3. Good Router Goes Bad
4.2.3. 良いルータは腐ります。
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は、ソリューションがルータ権利の取消しにかかわると想像するかもしれません。 状況は研究質問として残っています。
4.2.4. Spoofed Redirect Message
4.2.4. 再直接のメッセージであると偽造されます。
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.
リンクでどんなリンクレイヤアドレスへの与えられた目的地にもパケットを送るのにRedirectメッセージを使用できます。 攻撃者は、Redirectメッセージを正統のホストに送るのに現在の最初に、ホップルータのリンクローカルアドレスを使用します。 ホストが最初のホップルータから来るとしてリンクローカルアドレスでメッセージを特定するので、それはRedirectを受け入れます。 攻撃者がリンク層のアドレスへのNeighbor Unreachability Detection徹底的調査に応じる限り、Redirectは有効なままで残るでしょう。 これは再直接の/DoS攻撃です。
The threat discussed in this subsection involves Redirect messages.
この小区分で議論した脅威はRedirectメッセージにかかわります。
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.
リンクへのアクセスが信じられたノードに制限されるなら、この攻撃は関心ではありません。 信じられたノードが感染されるなら、他のノードはこの脅威に暴露されます。 信じられたオペレータの場合には、ノードがオペレータによって実行された信頼できるルータの間で区別をする手段と他のノードがあるに違いありません。 現在、臨時のネットワークケースのための広く受け入れられたソリューションが全くありません、そして、問題は研究質問として残っています。
4.2.5. Bogus On-Link Prefix
4.2.5. リンクの上のにせの接頭語
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メッセージは、任意の長さの何らかの接頭語がリンクであると指定できます。 送付ホストが、接頭語がリンクであると考えると、それはその接頭語のためにパケットをルータに決して送らないでしょう。 代わりに、ホストはNeighbor Solicitationsを送ることによって、アドレス解決を実行しようとするでしょうが、Neighbor Solicitationsは応答をもたらさないでしょう、攻撃されたホストに対するサービスを否定して。 これは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
攻撃者はにせの接頭語広告のときに任意の生涯を費やすことができます。 寿命が無限であるなら、接頭語リストで例えば、リブートすることによって状態を失うか、または同じ接頭語がゼロで広告に掲載された後にサービスは送付ホストに対して否定されるでしょう。
Nikander, et al. Informational [Page 14] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[14ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
攻撃者がそれ、または、ある他のノードにトラフィックを送るためにリンクの上にNeighbor Advertisementsであると偽造されて、その結果、ノードを誘い出すのにNeighbor Solicitationsに答えるなら、この攻撃を再直接の攻撃に広げることができます。
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とこのセクションで定義された攻撃を結合して、Neighbor Solicitation、Neighbor Advertisement、およびRouter Advertisementメッセージにかかわります。
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つの可能なアプローチがそうであることのように/64年代になってください(さもなければ、0/0とこの攻撃が非常に簡単であるように何か短いものの広告を出すのは簡単です)。
4.2.6. Bogus Address Configuration Prefix
4.2.6. にせのアドレス構成接頭語
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]で、中でホストのアドレス記録ににせのアドレスを追加します。
Nikander, et al. Informational [Page 15] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[15ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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>を持っている目標を考えてください。 攻撃者は<ATTACK_PRFX>のために逆のDNSエントリーを作成します: <TARGET_IID>、目標の本当のドメイン名を示す例えば、"secure.target.com"。 次に、攻撃者は目標のリンクに<ATTACK_PRFX>接頭語の広告を出します。 目標がアドレス<ATTACK_PRFX>: <TARGET_IID>を作成して、DNSエントリーをアップデートするので、"secure.target.com"は<ATTACK_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"は<ATTACK_PRFX>: <TARGET_IID>、および<ATTACK_PRFX>を示します: <TARGET_IID>は"secure.target.com"を示します。 <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.
この小区分で議論した基本的な脅威はRouter Advertisementメッセージにかかわります。 拡張攻撃シナリオは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.
リンクへのアクセスが信じられたノードに制限されるなら、この攻撃は関心ではありません。 もう片方が信じられたノードに感染されるなら、ノードはこの脅威に暴露されます。 信じられたオペレータの場合には、ノードがオペレータによって実行された信頼できるルータの間で区別をする手段と他のノードがあるに違いありません。 臨時のネットワークケースのための現在知られていないソリューションがあります、そして、問題は研究質問として残っています。
4.2.7. Parameter Spoofing
4.2.7. パラメタスプーフィング
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 Router Advertisementsは彼らがパケットを送るときホストによって使用されたいくつかのパラメタを含んでいます、そして、彼らが働くべきであるかどうかホストに言うのがアドレス構成[2]をstatefulします。 攻撃ノードは出ているa有効な見えているRouter Advertisementにその写しを送るかもしれません。
Nikander, et al. Informational [Page 16] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[16ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
Router Advertisement from the legitimate default router, except the included parameters are designed to disrupt legitimate traffic. This is a DoS attack.
含まれているパラメタ以外の正統のデフォルトルータからのルータAdvertisementはそうです。正統のトラフィックを混乱させるために、設計されています。 これは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のCurrent Hop Limitを入れるか、または目的地に到着する前に攻撃者が知っているもう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'旗は設定されます、他のパラメタのそのstatefulアドレス構成、そして/または、stateful構成が完了しているべきであるのを示して。 攻撃者はそして、それ自身のにせの回答による正統のホストのstateful構成質問に答える立場にいます。
The threat discussed in this subsection involves Router Advertisement messages.
この小区分で議論した脅威はRouter Advertisementメッセージにかかわります。
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を使用するのを防ぐかもしれません。 2番目に、ノードの地方の構成によって、攻撃者は、それほど信じられなかった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.
リンクへのアクセスが信じられたノードに制限されるなら、この攻撃は関心ではありません。 もう片方が信じられたノードに感染されるなら、ノードはこの御馳走に暴露されます。 信じられたオペレータの場合には、ノードがオペレータによって実行された信頼できるルータの間で区別をする手段と他のノードがあるに違いありません。 臨時のネットワークケースのための現在知られていないソリューションがあります、そして、問題は研究質問のままで残っています。
4.3. Replay attacks and remotely exploitable attacks
4.3. 反射攻撃とほんの少し利用可能攻撃
4.3.1. Replay attacks
4.3.1. 反射攻撃
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
すべてのNeighborディスカバリーとRouterディスカバリーメッセージは反射攻撃の傾向があります。 すなわち、それらがそれらのコンテンツを鍛造できないように暗号で保護されたとしても、攻撃者は保護されるでしょうに。
Nikander, et al. Informational [Page 17] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[17ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
幸い、ほとんどの反射攻撃を破るのはかなり簡単です。 Solicitation-広告などの要求回答交換では、要求はまた回答に現れなければならない一回だけを含むかもしれません。 したがって、正しい一回だけを含んでいないので、古い回答は有効ではありません。 求められていないAdvertisementsかRedirectメッセージなどのスタンドアロンのメッセージはタイムスタンプかカウンタで対応する、保護されるかもしれません。 練習している、およそ連動している時計とタイムスタンプでは、すべての新しいメッセージが最後に見られたメッセージより新しいように受取人がよく異なったノードの時計の違いの動向をおさえて、確実にするかもしれなくて以来の仕事に思えてください。
4.3.2. Neighbor Discovery DoS Attack
4.3.2. 隣人発見DoS攻撃
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.
この攻撃では、攻撃ノードは、サブネット接頭語でアドレスを作って、絶え間なくパケットをそれらに送り始めます。 最後のホップルータが隣人懇願にパケットを送ることによってこれらのアドレスを決議するのが義務付けられます。 ネットワークに入るのを試みる正統のホストは、他の懇願を送るのに既に忙しくなるので、最後のホップルータからNeighborディスカバリーサービスを得ることができないかもしれません。 このDoS攻撃は他のものと攻撃者がリンクであるかもしれないという点において異なっています。 この場合攻撃されるリソースは概念的な隣人キャッシュです。(そのキャッシュは有効な接頭語にもかかわらず、無効の接尾語を持っているIPv6アドレスを決議する試みで満たされるでしょう)。 これはDoS攻撃です。
The threat discussed in this subsection involves Neighbor Solicitation messages.
この小区分で議論した脅威はNeighbor Solicitationメッセージにかかわります。
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氾濫問題とかなり同様です。 例えば、未定の懇願のために予約された状態の量を制限して、Neighbor Solicitationsを制限しながら、評価してください。そうすれば、賢明なキャッシュ管理は適用されてもよいです。
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.
ホストとルータの両方が、この問題を心配する必要に注意されるべきです。 上でルータケースについて議論しました。 また、ホストも、リンクの上の任意の目的地にパケットを送るようにだまされるアプリケーションで潜在的に隣人発見プロセスを乱用できるので、被害を受け易いです。
Nikander, et al. Informational [Page 18] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[18ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
4.4. Summary of the attacks
4.4. 攻撃の概要
Columns:
コラム:
N/R Neighbor Discovery (ND) or Router Discovery (RD) attack
N/R隣人ディスカバリー(ノースダコタ)かRouterディスカバリー(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
攻撃にかかわったMsgs Messages: Na、ナノ秒、RA、RS、Redir
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.
テーブルの'+'というプラスサインが、aがあることを意味しないことに注意してください、準備ができている、未来、適用、標準液。 ソリューションが存在しているなら、このドキュメントは不要でしょうに。 代わりに、それは問題が原則として解決されて、問題を解決するために何らかのアプローチについて説明する刊行物が存在しているか、またはソリューションが知られている研究、そして/または、工学結果の簡単な適用で生産されるかもしれないという作者の意見でそれを指示します。
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'は、作者がどんな公表もソリューションについて問題に説明するのを意識していないのを示して、問題を解決するためにこれを書いている時点で知られている研究、そして/または、工学結果の少しの簡単で簡単な拡大についても考えることができません。
Nikander, et al. Informational [Page 19] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[19ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
+-------+----------------------+-----+-------+-------+---+---+---+ | 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 | + | + | + | +------------------------------+-----+-------+-------+---+---+---+
+-------+----------------------+-----+-------+-------+---+---+---+ | 秒| 攻撃名| N/R| R/D| Msgs| 1 | 2 | 3 | +-------+----------------------+-----+-------+-------+---+---+---+ | 4.1.1 | NS/NAスプーフィング| ノースダコタ| Redir| Naナノ秒| + | + | + | | 4.1.2 | NUDの故障| ノースダコタ| DoS| Naナノ秒| - | + | + | | 4.1.3 | おとうさんのDoS| ノースダコタ| DoS| Naナノ秒| - | + | + | +-------+----------------------+-----+-------+-------+---+---+---+ | 4.2.1 | 悪意があるルータ| rd| Redir| RA RS| + | + | R| | 4.2.2 | デフォルトルータは殺されました。| rd| Redir| RA|+/R|+/R| R| 1) | 4.2.3 | 良いルータは腐ります。| rd| Redir| RA RS| R| R| R| | 4.2.4 | 再直接で、だまします。| rd| Redir| Redir| + | + | R| | 4.2.5 | リンクの上のにせの接頭語| rd| DoS| RA| - | + | R| 2) | 4.2.6 | にせのアドレスコンフィグ| rd| DoS| RA| - | + | R| 3) | 4.2.7 | パラメタスプーフィング| rd| DoS| RA| - | + | R| +-------+----------------------+-----+-------+-------+---+---+---+ | 4.3.1 | 反射攻撃| すべて| Redir| すべて| + | + | + | | 4.3.2 | リモート第DoS| ノースダコタ| DoS| ナノ秒| + | + | + | +------------------------------+-----+-------+-------+---+---+---+
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. Router Advertisementsを保護するのは可能であって、その結果、この攻撃の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登録の結果になることは、DNSアップデート[4]で盲目的に新しいアドレスを登録するので、ここのノースダコタ安全保障問題であると考えられません。 しかしながら、それは実装における可能な脆弱性として注意されるべきです。
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におけるテーブルは非常に良いです。
5. Security Considerations
5. セキュリティ問題
This document discusses security threats to network access in IPv6. As such, it is concerned entirely with security.
このドキュメントはIPv6でアクセスをネットワークでつなぐ軍事的脅威について議論します。 そういうものとして、それは完全にセキュリティに関係があります。
Nikander, et al. Informational [Page 20] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[20ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
6. Acknowledgements
6. 承認
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.
おかげに、NeighborディスカバリーDoSを特定するためのDoCoMo Communications研究所米国のAlper Yeginは攻撃します。 また、脅威のいくつかについて私たちと議論して頂いて、ヤリArkkoと同様にマイクロソフトResearchケンブリッジのTuomas AuraとマイケルRoeとエリクソンResearch NomadiclabのVesa-マッティMantylaに感謝申し上げます。
Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay Devaparalli, Dave Thaler, and Alain Durand for their constructive comments.
彼らの建設的なコメントをAlper Yegin、ペッカSavola、ビル・ゾンマーフェルト、ビジェイDevaparalli、デーヴThaler、およびアラン・ジュランドをありがとうございます。
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.
特に、彼の頻繁な非常に良いコメントと、ノースダコタオーバーライドを受け入れるのを拒否する実装の、より多くの材料と、リンクにおけるにせの接頭語の脅威と、反射攻撃に関して私たちに思い出させるためのクレイグ・メスをありがとうございます。
7. Informative References
7. 有益な参照
[1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[1] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、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)のための隣人発見」、RFC2461、1998年12月。
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[3] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[4] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[4] ウェリントン、2000年11月、B.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[5] Mankin, A., "Threat Models introduced by Mobile IPv6 and
Requirements for Security in Mobile IPv6", Work in Progress.
[5] マンキン、「脅威ModelsはSecurityのためにモバイルIPv6"、ProgressのWorkでモバイルIPv6とRequirementsで導入した」A.。
[6] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6
Neighbor Discovery Using Address Based Keys (ABKs)", Work in
Progress, June 2002.
[6] 「IPv6がアドレスを使用するとキー(ABKs)が基づいたという隣人発見であると機密保護し」て、ケンフ、J.、紳士階級、C.、およびA.シルバーバーグは進行中(2002年6月)で働いています。
[7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and
Acknowledgments", Work in Progress, March 2002.
[7] 魚卵、M.、「モバイルIPv6拘束力があるアップデートと承認の認証」が進歩、2002年3月に働いています。
[8] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March
2003.
[8] J.、「IKEへのICMPv6の効果」というArkkoは進歩、2003年3月に働いています。
[9] Arkko, J., "Manual Configuration of Security Associations for
IPv6 Neighbor Discovery", Work in Progress, March 2003.
[9] J.、「IPv6隣人発見のためのセキュリティ協会の手動の構成」というArkkoは進歩、2003年3月に働いています。
Nikander, et al. Informational [Page 21] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[21ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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 メール: pekka.nikander@nomadiclab.com
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
ジェームスケンフDoCoMo米国研究室181地下鉄ドライブ、Suite300サンノゼ、カリフォルニア95110米国
Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
以下に電話をしてください。 +1 4711年の408 451メール: kempf@docomolabs-usa.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94043 USA
エリックNordmarkサン・マイクロシステムズ17ネットワーク円のカリフォルニア94043メンローパーク(米国)
Phone: +1 650 786 2921 EMail: erik.nordmark@sun.com
以下に電話をしてください。 +1 2921年の650 786メール: erik.nordmark@sun.com
Nikander, et al. Informational [Page 22] RFC 3756 IPv6 ND Trust Models and Threats May 2004
Nikander、他 情報[22ページ]のRFC3756IPv6信頼第モデルと脅威2004年5月
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Nikander, et al. Informational [Page 23]
Nikander、他 情報[23ページ]
一覧
スポンサーリンク
