この文書はRFC3756の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Nikander, Ed.
Request for Comments: 3756 Ericsson Research Nomadic Lab
Category: Informational J. Kempf
DoCoMo USA Labs
E. Nordmark
Sun Microsystems Laboratories
May 2004
IPv6 Neighbor Discovery (ND) Trust Models and Threats
ＩＰｖ６近隣探索（ＮＤ）信頼モデルと脅威
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
既存のＩＥＴＦ標準はＩＰｖ６近隣探索（ＮＤ）とアドレス自動設定メカニ
ズムがＩＰｓｅｃ認証ヘッダ（ＡＨ）で守られるかもしれないことを明示し
ます。しかしながら、現在の仕様書は自動鍵管理の直面している実際的な問
題のためにセキュリティ解決策を手動の暗号鍵入力に制限します。この書類
は３つの異なった信頼モデルを指定し、そしてＩＰｖ６近隣探索と関係があ
る脅威を論じます。この論議の目的はＩＰｖ６近隣探索を安全に保つための
必要条件を定義することです。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Remarks
1.1. 注目
2. Previous Work
2. 以前の仕事
3. Trust Models
3. 信頼モデル
3.1. Corporate Intranet Model
3.1. 企業のイントラネットモデル
3.2. Public Wireless Network with an Operator
3.2. オペレータの公共無線ネットワーク
3.3. Ad Hoc Network
3.3. アドホックネットワーク
4. Threats on a (Public) Multi-Access Link
4. （公共）多重アクセスリンク上の脅威
4.1. Non router/routing related threats
4.1. 非ルータ／ルーティング関連の脅威
4.1.1. Neighbor Solicitation/Advertisement Spoofing
4.1.1. 近隣要請／広告のなりすまし
4.1.2. Neighbor Unreachability Detection (NUD) failure
4.1.2. 近隣非接続発見（ＮＵＤ）失敗
4.1.3. Duplicate Address Detection DoS Attack
4.1.3. 重複アドレス発見のサービス妨害攻撃
4.2. Router/routing involving threats
4.2. ルーター／ルーティングを伴う脅威
4.2.1. Malicious Last Hop Router
4.2.1. 悪意がある最終ホップルータ
4.2.2. Default router is 'killed'
4.2.2. デフォルトルータが「消去」
4.2.3. Good Router Goes Bad
4.2.3. 良いルータが悪くなる
4.2.4. Spoofed Redirect Message
4.2.4. 偽リダイレクトメッセージ
4.2.5. Bogus On-Link Prefix
4.2.5. 偽オンラインプレフィックス
4.2.6. Bogus Address Configuration Prefix
4.2.6. 偽アドレス設定プレフィックス
4.2.7. Parameter Spoofing
4.2.7. パラメータなりすまし
4.3. Replay attacks and remotely exploitable attacks
4.3. 再生攻撃と遠隔利用攻撃
4.3.1. Replay attacks
4.3.1. 再生攻撃
4.3.2. Neighbor Discovery DoS Attack
4.3.2. 近隣探索サービス妨害攻撃
4.4. Summary of the attacks
4.4. 攻撃の要約
5. Security Considerations
5. セキュリティの考察
6. Acknowledgements
6. 謝辞
7. Informative References
7. 有益な参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
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].
ＩＰｖ６近隣探索（ＮＤ）ＲＦＣ２４６１[2]とアドレス自動設定ＲＦＣ２４
６２[3]の機構は、ローカルノードのＩＰからＭＡＣアドレス対応と、ローカ
ルネットワークにあるルータのＩＰとＭＡＣアドレスと、ローカルルータの
供給するルーティングプレフィックスを含めて、ローカルトポロジーを学習
するためにＩＰｖ６ネットワークのノードが使います。現在の仕様書はＩＰ
ｓｅｃ ＡＨ ＲＦＣ２４０２[1]がセキュリティメカニズムに使われるかも
しれないと示唆しますが、明示しません。現在のＡＨメカニズムを使うこと
は鍵管理問題[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.
問題を解くために、安全な近隣探索（ＳＥＮＤ）作業班が２００２年秋に作
られました。作業班のゴールは極端な手動の暗号鍵入力を必要としないで、
ＩＰｖ６近隣探索を安全に保つためのプロトコルサポートを定義することで
す。
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.
この文書の目的は安全なＩＰｖ６近隣探索メカニズムが働くことが期待され
るネットワークの種類とセキュリティプロトコルが扱わなくてはならない脅
威を定義することです。この目的を満たすために、この文書は最初に、ほぼ
安全に保たれた企業のイントラネットと、公共の無線アクセスネットワーク
と、純粋なアドホックネットワークに対応して、３つの異なる信頼モデルを
定義します。その後に、多くの脅威がこれらの信頼モデルを考慮に入れて論
じられます。脅威の一覧は徹底的であるようにしていますが、何らかの脅威
に気付いていないのはことはありそうです。それで、新しい脅威を考慮する
のが要請されます。
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.
ＳＥＮＤ ＷＧの憲章は作業班の範囲をセキュアな近隣探索機能に制限するこ
とに注意してください。さらに、憲章は近隣探索の本来の基本的な目的はゼ
ロ設定だと言います。ネットワークアクセス認証とアクセス管理がこの仕事
の範囲外です。
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.
重要。この文書は時折、暗号的に生成されたアドレス（ＣＧＡ）[7]とアドレ
スベース鍵（ＡＢＫ）[6]のような、解決提案を論じます。しかしながら、こ
のような論議はもっぱら説明的な目的のためです。その目的は読者に＊ある＊
可能解決策のより具体的な考えを与えることです。このような論議は著者や
作業班の解決作の好みを示してはいません(NOT)。
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.
用語「信頼」はどちらかと言うと専門的でない方法でこの文書で使われてる
ことを指摘します。最も適切な解釈は、これを組織や共同の信念の表現と考
える事です、すなわち、他の関係者の未来の行動についての一般に共有され
た確信の表現です。逆に、期間「信頼関係」は、グループが他のグループが
将来に渡って正確に振る舞うと信じる、関係組織やグループ間の相互の理論
的な関係を示します。信頼関係がグループ間の認証と認可情報の配置を可能
にし、他方このような関係の欠如はこのような情報を事前設定することを不
可能にします。
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.
ＩＰｖ６近隣探索とアドレス自動設定プロトコル[2][3]を指定するＲＦＣは
セキュリティの考察の章でセキュリティの必要とされる論議を含んでいます。
この文書で識別された脅威のいくつかは元のＲＦＣでも書かれています。推
薦された対応はＩＰｓｅｃ ＡＨヘッダ[1]でパケットを安全に保つ事でした。
しかしながら、その推薦はＡＨ鍵管理問題を未来の仕事として単純化し過ぎ
ています。例えば、公共アクセスネットワークにアクセスを得ようと試みて
いるホストが、必要とされるＩＰｓｅｃセキュリティアソシエーションをネッ
トワークと設立してるかもしれないし、していないかもしれません。ユーザ
が現在ホームプロバイダと異なるサービスプロバイダを通してネットワーク
にアクセスしているローミング状態で（必ずしもモバイルではない）、ホス
トが自分自身を認証させることを許している現在の接続プロバイダネットワー
クと適切な相互信頼関係を事前設定していることはなさそうです。
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.
今日の時点で、近隣探索とアドレス自動設定プロトコルがある程度どのよう
にホストがリンクの最初のアクセスを得るかを扱うから、ホストと最終ホッ
プルータかリンク上の他のホストとの間のＩＰｓｅｃセキュリティアソシエー
ションが完全に手作業で事前設定される必要があるでしょう。それで、もし
セキュリティアソシエーションが最初のアクセスのために必要で、ホストが
そのアソシエーションを持っていないなら、現時点で、ホストがたとえ必要
最小限の鍵材料を持っているとしても、そのアソシエーションで動的に自分
自身を設定できる標準的な方法がありません。この状態は、鍵変更のような
イベントが起こる時、管理の困難を誘発します。
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.
加えて、近隣探索とアドレス自動設定は少数の固定マルチキャストアドレス
と、１千６百万の広範囲の「要請ノード」マルチキャストアドレスを使いま
す。事前設定されたＳＡの単純なアプリケーションは、与えられたある要請
ノードマルチキャストアドレスが使われる場合に備えて、それぞれのホスト
とルータの上に無数のＳＡを事前設定することを必要とするでしょう。事前
設定されたＡＳはこのような多くの可能性があるアドレス範囲を安全に保つ
ことに対して実際的ではありません。
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.
ＩＰｖ６近隣探索（ＮＤ）[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.
以下で、ＲＦＣ２４６１／ＲＦＣ２４６２メカニズムは大ざっぱに２つの種
類に分けられます：近隣探索（ＮＤ）とルータ探索（ＲＤ）。前者は主にルー
タに関係しないオペレーションで、後者は関係するオペレーションです。
Three different trust models are specified:
３つの異なった信頼モデルが指定されます：
1. A model where all authenticated nodes trust each other to behave
correctly at the IP layer and not to send any ND or RD messages
that contain false information. This model is thought to
represent a situation where the nodes are under a single
administration and form a closed or semi-closed group. A
corporate intranet is a good example.
1. すべての認証されたノードが、ＩＰレイヤで正しく振舞い、偽情報を含
むＮＤやＲＤメッセージを送らないと、お互いを信頼するモデル。この
モデルはノードがひとつの管理者の下にある状態を表し、そして閉じた、
あるいはほぼ閉じたグループを構成すると思われます。企業のイントラ
ネットは良い例です。
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. ネットワークの他のノードが信頼するルータからなり、正当なルータが
ローカルネットワークと他の外部ネットワーク間で誠実にパケットを転
送するモデル。さらに、ルータはＩＰ層で正しく振舞い偽のＮＤやＲＤ
メッセージを送らないと信頼されます。
This model is thought to represent a public network run by an
operator. The clients pay to the operator, have its credentials,
and trust it to provide the IP forwarding service. The clients
do not trust each other to behave correctly; any other client
node must be considered able to send falsified ND and RD
messages.
このモデルはオペレータの運営する公共ネットワークを示すと思われま
す。クライアントはオペレータに代金を払い、その証明書を持ち、そし
てＩＰ転送サービスを供給されると信頼します。クライアントはお互い
に正確に振る舞とは信頼しません；他のクライアントノードが偽のＮＤ
とＲＤメッセージを送ることが可能と思わなくてはなりません。
3. A model where the nodes do not directly trust each other at the
IP layer. This model is considered suitable for e.g., ad hoc
networks.
3. ノードがＩＰ層でお互いに直接信頼し合わないモデル。このモデルは例
えばアドホックネットワークに適していると思われます。
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.
最初のモデルでノードがお互いに信頼できるとしても（企業のイントラネッ
ト）、最悪を考えて、ノードがローカルネットワークに与えることが可能な
損害の広さを制限することが望ましい事に注意してください。
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.
すべてのノードが１つの管理ドメイン下にある、企業のイントラネットある
いは他のネットワークで、ノードはＩＰレイヤにおいて信頼性が高いと考え
られるかもしれません。それで、ノードがネットワークのメンバと受け入れ
られた途端に、それは信頼できる振る舞いをする考えられます。
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.
このモデル下で、もしネットワークが物理的に安全に保たれるなら、あるい
はもしリンクレイヤが必要とされる程度に暗号的に安全に保たれるなら、ノー
ドが危険にならない限り、他のどのような保護もＩＰｖ６のＮＤに必要とさ
れません。例えば、８０２．１ｘアクセスコントロールを持つ無線ＬＡＮや、
ＡＥＳ暗号を使う８０２．１１ｉ強固セキュリティネットワークのＷＬＡＮ
は、十分安全と思われ、この信頼モデル下でこれ以上の保護を必要としない
かもしれません。他方、このモデル下でもＮＤセキュリティは保護を強化す
るでしょう（下記参照）。さらに、Ｌ２メカニズムが供給が可能なセキュリ
ティレベルを過大評価すべきではありません。
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.
もしネットワークが物理的に安全に保たれてなくてリンクレイヤが暗号保護
を持たないなら、あるいはもし暗号保護のセキュリティが十分高くないなら
（例えば、ＷＬＡＮで８０２．１１ｉでなく８０２．１ｘの場合）、ネット
ワークのノードは４章で示す脅威に弱いかもしれません。このような場合、
ある保護がセキュアなＮＤに望ましいです。このような保護を供給すること
はＳＥＮＤ作業班の最初の主な焦点です。
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.
２章で述べたように、セキュアＮＤの１つの可能性は信頼できる全てのノー
ドが共有し他者が知らない対称鍵でＩＰｓｅｃのＡＨを使うことであるでしょ
う。しかしながら、現在標準化された自動鍵配布機構のどれも動きません。
詳細は[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].
より特化すると、現在使われている鍵合意プロトコル、ＩＫＥ、鶏と卵の問
題で苦しみます[8]：ＩＫＥを動かすにはＩＰアドレスがいります、ＩＰｓｅ
ｃのＳＡ確立にはＩＫＥが必要で、ＩＰアドレス設定にはＩＰｓｅｃのＳＡ
が必要です。さらに、対称鍵暗号のＮＤを安全に保つ容易で効率的な方法で
あるように思われません。必要とされるセキュリティアソシエーションの数
は非常に大きいでしょう[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.
例えば、この限界を克服する１つの可能な方法が、公開鍵暗号を使うことで、
公開鍵署名で直接ＮＤパケットを安全に保つことです。
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
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.
オペレータが実施する公共無線（あるいは無線回線）ネットワーク、例えば
ホテルや空港やカフェでのＷＬＡＮ、のシナリオは異なる信頼モデルを持っ
ています。ここでノードはオペレータがＩＰ転送サービスを信頼できる方法
で供給し、クライアントのトラフィックを混乱させるか誤った転送をしない
と、信じるでしょう。しかしながら、クライアントは通常お互いに信頼し合
いません。一般に、ルータは１つの管理者のドメイン配下にあり、クライア
ントノードはクライアント自身で管理するドメインの下にあります。
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.
このシナリオ下でオペレータがすべてのクライアントノードを認証するか、
あるいは少なくとも支払いの形で認可を必要とすると想定されます。同時に、
クライアントはルータを認証し、それが信頼できるオペレータに属すること
を確かにできなければなりません。リンクレイヤ認証プロトコルとその配置
に依存して、リンクレイヤは相互認証の面倒を見るかもしれません。リンク
レイヤ認証プロトコルはクライアントノードとアクセスルータ間でセキュリ
ティアソシエーションを作ることを許すかもしれません。認証プロトコルが
存在することに注意してください、例えば、特定のＥＡＰ手段は安全な鍵材
料を作らずクライアントがネットワークを認証することを可能にしません。
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.
このシナリオで、暗号的にリンク層をセキュアにすることは４章で概説され
るすべての脅威を阻止するわけではありません；個別の脅威の記述を見て下
さい。特に、ＡＥＳ暗号を使う８０２．１１ｉ ＲＳＮでさえ、ブロードキャ
ストとマルチキャストの鍵はすべてのノードで共通です。たとえ基礎リンク
レイヤがすべてのノードのリンクレイヤアドレスに気付いて、そしてソース
アドレスが偽造されていないことを調べることが可能であったとしても、脆
弱性がまだあるでしょう。
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.
リンク層セキュリティとＩＰトポロジーが必ずしも合致しないことも指摘さ
れています。例えば、無線アクセスポイントはＩＰ層でまったく見えないか
もしれません。このような場合リンク層での暗号セキュリティがＩＰ近隣探
索に関してセキュリティを供給しません。
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.
このシナリオでセキュリティをもたらす少なくとも２つの方法があるように
思われます。１つの可能性はクライアントとアクセスルータの間に強いセキュ
リティを実施し、ＩＰとリンクレイヤプロトコルの細部を認識するアクセス
ルータを作る事と思われます。すなわち、ルータはＩＣＭＰｖ６パケット中
身を検査し、ネットワークトポロジに合わない情報を含むパケットをフィル
タするでしょう。他の多分適切な方法はＮＤメッセージを運んでいるＩＣＭ
Ｐｖ６パケットに暗号保護を加えることです。
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.
アドホックネットワーク、あるいは信頼できるオペレーターがないネットワー
クで、ノードがお互いに信頼し合いません。一般的な場合、ノードは初めて
お互いに会い、そして他のノードがＩＰレイヤで正確に振る舞うという保証
がありません。偽のＮＤとＲＤメッセージを送る事を怪しまなければなりま
せん。
Since there are no a priori trust relationships, the nodes cannot
rely on traditional authentication. That is, the traditional
authentication protocols rely on some existing relationship between
the parties. The relationship may be direct or indirect. The
indirect case relies on one or more trusted third parties, thereby
creating a chain of trust relationships between the parties.
仮の信頼関係がないので、ノードは伝統的な認証に頼ることができません。
すなわち、伝統的な認証プロトコルは当事者間の既存の関係に依存します。
関係は直接か間接的です。間接的な場合は、１つ以上の信頼できる第三者に
依存し、当事者間に信頼関係の鎖を作ります。
In the generic ad hoc network case, there are no trusted third
parties, nor do the parties trust each other directly. Thus, the
traditional means of first authenticating and then authorizing the
users (to use their addresses) do not work.
一般的なアドホックネットワークの場合に、信頼できる第三者がいません、
同様に当事者は直接お互いに信頼し合いません。それで、最初に認証して、
次にユーザ（がアドレスを使うの）を認可する伝統的な手段はうまくいきま
せん。
It is still possible to use self-identifying mechanisms, such as
Cryptographically Generated Addresses (CGA) [7]. These allow the
nodes to ensure that they are talking to the same nodes (as before)
at all times, and that each of the nodes indeed have generated their
IP address themselves and not "stolen" someone else's address. It
may also be possible to learn the identities of any routers using
various kinds of heuristics, such as testing the node's ability to
convey cryptographically protected traffic towards a known and
trusted node somewhere in the Internet. Methods like these seem to
mitigate (but not completely block) some of the attacks outlined in
the next section.
暗号的に生成されたアドレス（ＣＧＡ）[7]のような、自己識別メカニズムを
使うことはまだ可能です。これらはノードがいつも（前と同じように）同じ
ノードと話をしている事を保障し、ノードのそれぞれが本当に自身のＩＰア
ドレスを生成して、ほかの誰かのアドレスを「盗まなかった」ことを保証す
ることを許します。インターネットのどこかの既知の信頼できるノードに向
かって暗号的に保護されたトラフィックを伝達するノードの能力をテストす
るような、様々な種類の発見的手法を使いルータの識別子を学ぶ事は可能か
もしれません。これらのような方法が次の章で概説され、攻撃のいくらかを
和らげる（しかし完全に防げない）ように思われます。
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.
この章で我々は、多重アクセスリンクで使われる時の、現在のＩＰｖ６近隣
探索メカニズムに対する脅威を論じます。脅威は前の章で定義した信頼モデ
ルを考慮して論じられます。
There are three general types of threats:
脅威の３つの一般的なタイプがあります：
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. 悪意があるノードが、攻撃対象と他のすべてノード間の通信、あるいは
特定の宛先アドレスの通信を妨害する、サービス妨害（ＤｏＳ）攻撃。
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. 悪意があるノードが、他のホストのトラヒックを犠牲者ノードに送り、
それで犠牲者ノードを偽トラヒックで溢れさす、氾濫サービス妨害（Ｄ
ｏＳ）攻撃。
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.
転送攻撃は、完全にあるいは選択的にパケットを攻撃相手に転送し、パケッ
トが転送されたノードを停止させることで、ＤｏＳの目的で使えます。
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.
下記の章はＩＰｖ６ネットワークアクセスのための特定の脅威を示します。
脅威の記述は３つの章でまとめられます。我々は最初にルータやルーティン
グ情報に関係しない脅威を考えます。我々は次にルータやルーティング情報
に関係する脅威を考えます。最後に、遠隔から利用できる再生攻撃と脅威を
考えます。すべての脅威は信頼モデルを考慮に入れて論じられます。
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.
この章で我々は「純粋」近隣探索機能、すなわち近隣探索（ＮＤ）と近隣非
接続発見（ＮＵＤ）とアドレス自動設定でのアドレス重複発見（ＤＡＤ）に
対する攻撃を論じます。
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:
リンク上のノードがＩＰアドレスとＭＡＣアドレスの間に結合を作るため近
隣要請と広告メッセージを使います。もっと具体的に言うと、ノードが要請
を受けとって近隣キャッシュ項目を作る２つの場合があります：
1. A node receives a Neighbor Solicitation that contains a node's
address. The node can use that to populate its neighbor cache.
This is basically a performance optimization, and a SHOULD in the
base documents.
1. ノードがノードのアドレスを含む近隣要請を受信します。ノードはこれ
を近隣キャッシュに入れることができます。これは基本的に性能の最適
化で基本文書ですべき(SHOULD)とされています。
2. During Duplicate Address Detection (DAD), if a node receives a
Neighbor Solicitation for the same address it is soliciting for,
the situation is considered a collision, and the node must cease
to solicit for the said address.
2. 重複アドレス発見（ＤＡＤ）の間に、もしノードが要請しているのと同
じアドレスの近隣要請を受信した場合、要請は衝突したと考えられ、ノー
ドは当該アドレスの要請をやめなくてはなりません。
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.
新しいリンクレイヤアドレスを持つ近隣キャッシュ項目が古いので上書きさ
れるから、攻撃は成功します。もし偽リンクレイヤアドレスが正当であるな
ら、攻撃者が近隣非接続発見の一部として送られたユニキャスト近隣要請メッ
セージに返答する限り、パケットがリダイレクトされ続けるでしょう。これ
はリダイレクト／サービス妨害攻撃です。
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.
このメカニズムは使われていないリンクレイヤアドレスを指定することによっ
てサービス妨害攻撃に使うことができます；しかしながら、このサービス妨
害攻撃は、３０-５０秒後（デフォルトタイマー値）に近隣非接続発見メカニ
ズムがリンクレイヤアドレスを発見するために悪いリンクレイヤアドレスと
マルチキャストを捨てるだろうから、限定された持続時間です。結果として、
攻撃者は、もしタイムアウト以降も攻撃を持続することを望むなら、偽リン
クレイヤアドレスで返答し続ける必要があるでしょう。
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.
この攻撃は、もしリンクへのアクセスが信頼できるノードに制限されるなら、
懸念点ではありません；もし信頼できるノードが汚染されるなら、他のノー
ドはこの脅威にさらされます。オペレータが信頼される場合に、ノートは他
のローカルノードのアドレス結合を証明するオペレータに依存するかもしれ
ません。セキュリティの見地から、ルータは他のノードのための信頼でき代
理人の役を務めるかもしれません。これはルータがリンク上で正確に他のノー
ドの存在を示す都信頼できると想定します。特別なネットワークの場合、他
の２の場合のオプションで、ノードはアドレス結合を認証する自己認証テク
ニック（例えば、ＣＧＡ）を示すかもしれません。
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. 近隣非接続発見（ＮＵＤ）失敗
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]でローカルな宛先とルータの可
到達性をモニターします。通常ノードはピアノードが到達可能かどうか決定
するのを上位レイヤ情報に依存します。しかしながら、もし上位レイヤトラ
フィックにかなり長い遅延があるなら、あるいはもしノードがピアノードか
ら応答を受け取るのをやめるなら、ＮＵＤ手順が呼び出されます。ノードは
ピアノードに目標を定めたＮＳを送ります。もしピアがまだ到達可能である
なら、ピアはＮＡで返事するでしょう。しかしながら、もし要求しているノー
ドが答えを受け取らないなら、もう何回か試して、結局は近隣キャッシュ項
目を削除します。もし必要なら、これは新しいＭＡＣアドレスを学習するた
めの標準アドレス解決プロトコルを引き起こします。もし（多分間違って）
ピアが到達可能でないと決定した後でこの手順で近隣キャッシュ項目を消し
たら、上位トラフィックは伝達できません。
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.
悪意があるノードがＮＵＤ ＮＳメッセージに応えて偽造ＮＡを送り続けるか
もしれません。ＮＡメッセージが保護されていないなら、攻撃者はこのテク
ニックを使って長期間攻撃を継続可能であるかもしれません。実際の結果は、
ノードが最初の場所で到達不可能になった理由と、目標ノードが、もしノー
ドが到達不可能になったことを知っていたら、どう振る舞うかによります。
これはサービス妨害攻撃です。
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.
この攻撃は、もしリンクへのアクセスが信頼できるノードに制限されるなら、
脅威ではありません；もし信頼できるノードが汚染される、他のノードはこ
のサービス妨害の脅威にさらされます。２つの他の信頼モデル下で、解決策
はＮＵＤを実行しているノードが本物と偽造ＮＡ応答の間の区別をすること
が可能であることを要求します。
4.1.3. Duplicate Address Detection DoS Attack
4.1.3. 重複アドレス発見のサービス妨害攻撃
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]を使っているアドレスを得るネッ
トワークで、攻撃ノードがすべての起動ホストの行う重複アドレス検出の試
みに返答することでサービス妨害攻撃をできます。もし攻撃者がアドレスを
主張するなら、ホストは決してアドレスを得ることが可能ではないでしょう。
攻撃者は２つの方法でアドレスを主張することができます：ＤＡＤの実行を
装ってＮＡを返すか、アドレスが既に使用中と装ってＮＡを返すかです。こ
の脅威はＲＦＣ２４６２[3]で示されました。この問題は、他の種類のアドレ
ス設定が使用中でも、つまり実際に提案されたアドレスを設定する前にＤＡ
Ｄが行われるなら、同じく存在しているかもしれません。
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.
この攻撃は、もしリンクへのアクセスが信頼できるノードに制限されるなら、
脅威ではありません；もし信頼できるノードが汚染されるなら、他のノード
はこのサービス妨害の脅威に露出します。他の２つの信頼モデル下で、解決
策はＤＡＤを行っているノードがＮＡ応答の送り主がそのＩＰアドレスを使
う権限を与えられるかどうか確かめることが可能であることを要求します。
信頼できるオペレータの場合、オペレータは権威者の役割をし、割り当てら
れたアドレスを記録・追跡し、ノードに数（百）アドレスを超える割り当て
をしていないことを確実にするかもしれません。他方、ＴＣＰ接続毎に異な
るアドレスを作ったり、ＮＤプロキシを実行するなど、１つのノードが多数
のアドレスを持つ望ましい状態があるかもしれないから、このような規則を
採用することは有害であるかもしれません。それで、ＩＳＰがホストが持て
る異正当なアドレスを制御するのを提案することは不適当であるかもしれま
せん；上記の議論は、この文書の初めに述べられるように、例としてだけ考
えなければなりません。
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]で示されましたが、一般的なＩＰｖ６の脅威で、モバイルＩＰ
ｖ６に固有ではありません。これはＲＦＣ２４６１[2]でも示されます。この
脅威はリダイレクト／サービス妨害攻撃です。
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.
正しい最終ホップルータを発見しようと試みているホストと同じサブネット
上の攻撃ノードが、マルチキャストルータ広告要請に応えて、ホストから正
しく見えるＩＰｖ６ルータ広告をマルチキャストするかルータ広告をユニキャ
ストすることによってＩＰｖ６の最終ホップルータのふりをすることができ
ます。もしホストが攻撃者をデフォルトルータに選ぶなら、攻撃者はホスト
からトラフィックを吸収するか、中間者攻撃を開始する機会を持ちます。攻
撃者がゼロの寿命の本当の最終ホップルータの周期的なルータ広告をマルチ
キャストすることで、ホストが攻撃者をデフォルトルータに選ぶことを保証
できます。これは本当のアクセスルータがトラフィックを扱わないとホスト
が信じる詐欺になるかもしれません。正当なルータと受け入れられれば、攻
撃者はホストにリダイレクトメッセージを送る事で、姿を消し、追跡を逃れ
ます。
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.
この脅威はＲＦＣ２４６２で部分的に和らぎます；ＲＦＣ２４６２の５.５.３
章は、もし広告されたプレフィックスの寿命が２時間以下で、保存された寿
命より小さいなら、パケットが認証されない限り、保存された寿命を減少さ
せないことを要求します。しかしながら、デフォルトルータ選択手順は、Ｒ
ＦＣ２４６１の６.３.６章で定義されるように、このような規則を含んでい
ません。
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.
信頼できるオペレータの場合、ノードがオペレータの動かす信頼可能なルー
タと他のノードを区別をする手段があるに違いありません。アドホックネッ
トワークの場合、現在広く受け入れられた解決策がありません、そして問題
は研究課題として残されています。
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.
この攻撃で、攻撃者がデフォルトルータを「消去」し、リンク上のノードに
すべてのノードがローカルと想定させます。ＲＦＣ２４６１[2]の５.２章で
「［もし］デフォルトルータリストが空なら、送り主は宛先がリンク上にあ
ると想定します。」と述べられています。それで、もし攻撃者がノードにリ
ンクにデフォルトルータがないと信じさせることが可能なら、ノードは近隣
探索を使いパケットを直接届けようとするでしょう。その後、攻撃者はリン
ク外の宛先に対しもＮＳ／ＮＡなりすましを使うことができます。
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.
攻撃者がデフォルトルータを「消去」するいくつかの方法が知られています。
１つはルータに対して古典的なサービス妨害攻撃を仕掛けて、他から見えな
いようにする事です。他はゼロのルータ寿命の偽ルータ広告の送信です（Ｒ
ＦＣ２４６１[2]の６.３.４章参照）。４.２.１章の上記のく論議を見てくだ
さい。
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.
この攻撃は主にサービス妨害攻撃で、トラヒックを次に良いルータに向け直
すのに使うことができ、そしてこれは攻撃者かもしれません。
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.
この章で論じられた脅威はルータ広告メッセージを伴います。この脅威の１
つの変形はルータに過負荷をかけることで、ＮＤ／ＲＤメッセージを使ずに、
可能かもしれません。
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にこの脅威の指摘に感謝します。
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.
この攻撃で、前に信頼されたルータを汚染します。利用可能な攻撃は４.２.１
章で論じたのと同じです。これはリダイレクト／サービス妨害攻撃です。
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.
３つの信頼モデルのどれにも現在周知の解決策がありません。他方、マルチ
ルータのリンク上で、ルータの権限剥奪を含む解決策があるとの想像があり
ます。状態は研究課題として残されています。
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.
リダイレクトメッセージは、特定の宛先パケットを、リンク上の任意のリン
クレイヤアドレスに送るために使うことができます。攻撃者は正当なホスト
にリダイレクトメッセージを送るため、現在の最終ホップルータのリンクロー
カルアドレスを使います。メッセージがその最初のホップのルータから来て
いることを、リンクローカルアドレスが示すので、ホストがリダイレクトを
受け入れます。攻撃者がリンクレイヤアドレスの近隣非接続発見調査に返答
する限り、リダイレクトは実際に残るでしょう。これはリダイレクト／サー
ビス妨害攻撃です。
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.
この攻撃は、もしリンクへのアクセスが信頼できるノードに制限されるなら、
脅威ではありません；もし信頼できるノードが汚染されるなら、他のノード
はこの脅威にさらされます。信頼できるオペレータの場合、オペレータの動
かす信頼可能なルータと他のノードを、ノードが区別をする手段があるに違
いありません。アドホックネットワークケース場合に、現在広く受け入れら
れた解決策がありません、そして問題は研究課題として残されています。
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.
攻撃ノードがルータ広告メッセージで任意のプレフィックスがリンク上にで
あると明示できます。もし送信ホストがプレフィックスがリンク上にあると
思うなら、決してそのプレフィックスに対するパケットをルータに送らない
でしょう。その代わりに、ホストは近隣要請を送ることによってアドレス解
決を行おうとするでしょう、しかし近隣要請は回答をもたらさず、攻撃され
たホストのサービスを妨害するでしょう。これはサービス妨害攻撃です。
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.
攻撃者は偽プレフィックス広告で任意の寿命を使うことができます。もし寿
命が無限なら、送信ホストがプレフィックスリストから状態を失うまで、例
えば再起動や後で同じプレフィックスがゼロ寿命で広告されるまで、サービ
スを妨害されるでしょう。攻撃は１２８のビットプレフィックス、すなわち
完全アドレスを使うことによって特定プレフィックス宛のパケットに対して
選択的に行うことができます。
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.
この脅威はルータ広告メッセージを伴います。拡張された攻撃は４.１.１章
とこの章で定義された攻撃を結合し、そして近隣要請と近隣広告とルータ広
告メッセージを伴います。
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).
例えば、この攻撃の損害を制限する１つの可能な方法は、広告されたオンリ
ンクプレフィックスが/46であることを要求することです（さもなければ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.
攻撃ノードがルータ広告メッセージを使い無効なサブネットプレフィックス
をホストがアドレス自動設定で使うように指定できます。アドレス自動設定
アルゴリズムを実行しているホストが、そのアドレスがサブネットで正当で
なくても、アドレス[3]を組み立てるために広告されたプレフィックスを使
います。結果として、応答パケットは、ホストのソースアドレスが無効であ
るから、決してホストに達しません。これはサービス妨害攻撃です。
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動的更新を行うなら、攻撃されたホストを越えて影響を与える可能性
を持っています。ＤＮＳ更新[4]は偽アドレスを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>.
分散攻撃者が標的が作るダイナミックＤＮＳ項目と整合する偽逆ＤＮＳ項目
を作ることで、よりひどい攻撃をすることができます。プレフィックス
<ATTACK_PRFX>に正当なアクセス権を持つ攻撃者と、インタフェースＩＤ
<TARGET_IID>を持つ標的を考えてください。攻撃者は標的の真のドメイン名
を指し示す<ATTACK_PRFX>:<TARGET_IID>の逆のＤＮＳ項目、例えば
「secure.target.com」、を作ります。次に攻撃者は標的のリンクで
<ATTACK_PRFX>プレフィックスを広告します。標的はアドレス
<ATTACK_PRFX>:<TARGET_IID>を作り、そして「 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.
この章で論じられた基本的な脅威はルータ広告メッセージを伴います。同じ
く、拡張された攻撃シナリオはＤＮＳを伴います。
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
Router Advertisement from the legitimate default router, except the
included parameters are designed to disrupt legitimate traffic. This
is a DoS attack.
ＩＰｖ６ルータ広告はパケットを送る時にホストが使うのと、ホストにがス
テートフルアドレス設定[2]を行うべきであるかどうかを示す、小数のパラメー
タを含んでいます。攻撃しているノードが正当なデフォルトルータからのルー
タ広告をコピーして、含まれるパラメータがトラフィックを混乱させるよう
意図される以外、正当に思われるルータ広告を送ることができます。これは
サービス妨害攻撃です。
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. 攻撃に、攻撃者が正当なパケットが宛先に着くまでに廃棄されると知っ
ている、１か他の小さい数の現在のホップ限界を含みます。
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. 攻撃者は偽ＤＨＣＰｖ６サーバあるいはリレーサーバを実装し、「Ｍ」
や「Ｏ」フラグを設定し、ステートフルアドレス設定や他のパラメータ
のステートフル設定がされるべきであることを示します。
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.)
ＤＨＣＰだけを安全に保つことがこの問題を解決しないことに注意してくだ
さい。これの２つの理由があります。第一に、攻撃者はノードが最初にＤＨ
ＣＰを使うのを阻止してもよいです。第二に、ノードのローカル設定に依存
して、攻撃者は信頼できるないＤＨＣＰサーバを使わせるためにノードに偽
アドレスで送れます。（後者はいわゆる「入札妨害」あるいは「等級劣化」
攻撃の一種です。）
As an example, one possible approach to mitigate this threat is to
ignore very small hop limits. The nodes could implement a
configurable minimum hop limit, and ignore attempts to set it below
said limit.
例えば、この脅威を和らげる１つの可能な方法は、非常に小さいホップ限界
を無視する事です。ノードは構成可能な最小ホップ限界を実装し、そして限
界以下に設定する試みを無視することができます。
This attack is not a concern if access to the link is restricted to
trusted nodes; if a trusted node is compromised the other nodes are
exposed to this treat. In the case of a trusted operator, there must
be a means for the nodes to make a distinction between trustworthy
routers, run by the operator, and other nodes. There are currently
no known solutions for the ad hoc network case, and the issue remains
a research question.
この攻撃は、もしリンクへのアクセスが信頼できるノードに制限されるなら、
懸念ではありません；もし信頼できるノードが汚染されるなら、他のノード
はこの脅威にさらされます。信頼できるオペレータの場合、ノードがオペレー
タの動かす信頼可能なルータと他のノードの間の区別をする手段があるに違
いありません。アドホックネットワークケースのために現在周知の解決策が
ありません、そして問題は研究課題のままです。
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
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.
幸いにたいていの再生攻撃からの保護はかなり容易です。要請広告のような、
要求応答交換で、要請は応答に現われなくてはならない符合を含んでいるか
もしれません。それで、古い答は正しい符合を含んでいないので、正当では
ありません。これに対し、要請されていない広告やリダイレクトメッセージ
のような独立型のメッセージは、タイムスタンプやカウンタで守られるかも
しれません。受信者が他のノードの時計の差を調べて、新しいメッセージが
最後に受取ったメッセージより新しいことを確信できるので、実質的に、だ
いたお一致した時計とタイムスタンプはうま働くように思われます。
4.3.2. Neighbor Discovery DoS Attack
4.3.2. 近隣探索サービス妨害攻撃
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.
この攻撃で、攻撃ノードはサブネットプレフィックスでアドレスを造り、連
続的にそれでパケットを送り始めます。最後のホップルータは近隣要請パケッ
トを送ることによってこれらのアドレスを変換するよう義務づけられます。
ネットワークに入ろうと試みている正しいホストは、すでに他の要請を送る
ことで忙しいであろうから、最後のホップルータから近隣探索サービスを得
ることが可能ではないかもしれません。このサービス妨害攻撃は、攻撃者が
リンク外かもしれないという点で、他のと異なっています。この場合攻撃さ
れている資源は概念的な近隣キャッシュで、そしてこれは有効なプレフィッ
クスで無効サフィックスのＩＰｖ６アドレスを変換する試みで満たされるで
しょう。これはサービス妨害攻撃です。
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.
ある意味で、この問題はかなりＴＣＰのＳＹＮ洪水の問題に類似しています。
例えば、近隣要請を制限や、未解決の要請のために確保された状態の量の限
定や、賢いキャッシュ管理は適用できるかもしれません。
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.
ホストとルータの両方がこの問題で心配する必要があることを指摘します。
ルータの場合は上で論じられました。ホストは、近隣探索手順がが潜在的に
任意のリンク上の宛先にパケットを送るアプリケーションに悪用できるので、
同じく攻撃されやすいです。
4.4. Summary of the attacks
4.4. 攻撃の要約
Columns:
列：
N/R Neighbor Discovery (ND) or Router Discovery (RD) attack
近隣探索（ＮＤ）か、ルータ探索（ＲＤ）攻撃か
R/D Redirect/DoS (Redir) or just DoS attack
リダイレクト／ＤｏＳ（Redir）か、サービス妨害攻撃か
Msgs Messages involved in the attack: NA, NS, RA, RS, Redir
攻撃に関係しているメッセージ：ＮＡ、ＮＳ、ＲＡ、ＲＳ、Redir
1 Present in trust model 1 (corporate intranet)
信頼モデル１（企業のイントラネット）で存在
2 Present in trust model 2 (public operator run network)
信頼モデル２（公共のオペレータによって運営されたネットワーク）で存在
3 Present in trust model 3 (ad hoc network)
信頼モデル３（アドホックネットワーク）で存在
Symbols in trust model columns:
信頼モデル列の中の記号：
- The threat is not present or not a concern.
脅威は存在せず、心配ありません。
+ The threat is present and at least one solution is known.
脅威はあり、少なくとも１つの解決があります。
R The threat is present but solving it is a research problem.
脅威は存在しているが、解決は研究課題です。
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. It is possible to protect the Router Advertisements, thereby
closing one variant of this attack. However, closing the other
variant (overloading the router) does not seem to be plausible
within the scope of this working group.
1. この攻撃の１種を止める事で、ルータ広告を守ることは可能です。しか
しながら、他（ルータに過負荷をかける）を止めることはこの作業班内
で、可能と思われていません。
2. Note that the extended attack defined in Section 4.2.5 combines
sending a bogus on-link prefix and performing NS/NA spoofing as
per Section 4.1.1. Thus, if the NA/NS exchange is secured, the
ability to use Section 4.2.5 for redirect is most probably
blocked, too.
2. ４.２.５章で定義した拡張攻撃は、偽のオンラインプレフィックスの送
信と、４.１.１章のＮＳ／ＮＡ詐欺を結合します。それで、もしＮＡ／
ＮＳ交換が保証されるなら、転送に４.２.５章を使う能力も恐らく阻止
されます。
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. ＤＮＳ更新[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]の７章を見てください。特に[9]の７.７章の表は
非常に良いです。
5. Security Considerations
5. セキュリティの考察
This document discusses security threats to network access in IPv6.
As such, it is concerned entirely with security.
この文書はＩＰｖ６でネットワークアクセスに対するセキュリティの考察を
論じます。それで、これは完全にセキュリティに関係しています。
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.
近隣探索サービス妨害攻撃を識別はドコモ通信研究所ＵＳＡのAlper Yeginの
おかげです。我々は同じく脅威のいくつかを我々と論じることに対して、マ
イクロソフト研究ケンブリッジのTuomas AuraとMichael Roe と、エリクソン
研究ノルディックラボの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.
多数の非常に良いコメントと、特に偽オンリンクプレフィックスの脅威と再
生攻撃で無効なＮＤを受け入れることを拒否する実装の資料について、対し
てCraig Metzに感謝します。
7. Informative References
7. 有益な参考文献
[1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[4] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[5] Mankin, A., "Threat Models introduced by Mobile IPv6 and
Requirements for Security in Mobile IPv6", Work in Progress.
[6] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6
Neighbor Discovery Using Address Based Keys (ABKs)", Work in
Progress, June 2002.
[7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and
Acknowledgments", Work in Progress, March 2002.
[8] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March
2003.
[9] Arkko, J., "Manual Configuration of Security Associations for
IPv6 Neighbor Discovery", Work in Progress, March 2003.
Authors' Addresses
著者のアドレス
Pekka Nikander (editor)
Ericsson Research Nomadic Lab
JORVAS FIN-02420
FINLAND
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
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
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.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。