[要約] RFC 6583は、オペレーショナルな隣接ディスカバリの問題に関する要約です。その目的は、IPv6ネットワークでの隣接ディスカバリの問題を特定し、解決策を提供することです。
Internet Engineering Task Force (IETF) I. Gashinsky
Request for Comments: 6583 Yahoo!
Category: Informational J. Jaeggli
ISSN: 2070-1721 Zynga
W. Kumari
Google, Inc.
March 2012
Operational Neighbor Discovery Problems
オペレーショナルネイバー探索の問題
Abstract
概要
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
IPv4では、サブネットは一般的に小さく、サブネット上の実際のマシン数をカバーするのに十分な大きさになります。対照的に、デフォルトのIPv6サブネットサイズは/ 64であり、数兆のアドレスをカバーする非常に大きな数であり、その圧倒的な数は割り当てられません。その結果、近隣探索（ND）の単純な実装は、意図的または偶発的なサービス拒否（DoS）に対して脆弱になる可能性があり、割り当てられていない多数のアドレスに対してアドレス解決を実行しようとします。このようなサービス拒否攻撃は、意図的に（攻撃者によって）起動される可能性があり、正当な操作ツールや事故状態から発生する可能性があります。これらの脆弱性の結果、新しいデバイスがネットワークに「参加」できなくなり、新しいIPv6フローを確立できなくなり、既存のIPv6トランスポートフローが中断される可能性があります。
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks.
このドキュメントでは、DoSの可能性を詳細に説明し、可能な実装の改善と、場合によってはそのような攻撃からの保護または少なくともその影響を緩和するために使用できる運用上の軽減手法を提案します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6583.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6583で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability ..............................................3
2. The Problem .....................................................3
3. Terminology .....................................................4
4. Background ......................................................5
5. Neighbor Discovery Overview .....................................6
6. Operational Mitigation Options ..................................7
6.1. Filtering of Unused Address Space ..........................7
6.2. Minimal Subnet Sizing ......................................7
6.3. Routing Mitigation .........................................8
6.4. Tuning of the NDP Queue Rate Limit .........................8
7. Recommendations for Implementors ................................8
7.1. Prioritize NDP Activities ..................................9
7.2. Queue Tuning ..............................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
This document describes implementation issues with IPv6's Neighbor Discovery protocol that can result in vulnerabilities when a network is scanned, either by an intruder or through the use of scanning tools that perform network inventory, security audits, etc. (e.g., "nmap").
このドキュメントでは、侵入者によって、またはネットワークインベントリやセキュリティ監査などを実行するスキャンツール（「nmap」など）を使用してネットワークをスキャンしたときに脆弱性が発生する可能性があるIPv6のネイバー探索プロトコルの実装の問題について説明します。
This document describes the problem in detail, suggests possible implementation improvements, as well as operational mitigation techniques, that can, in some cases, protect against such attacks.
このドキュメントでは、問題を詳細に説明し、考えられる実装の改善と、場合によってはそのような攻撃から保護できる運用上の緩和手法を提案します。
The RFCs generally describe the behavior of protocols, that is, "what" is to be done by a protocol, but not exactly "how" it is to be implemented. The exact details of how best to implement a protocol will depend on the overall hardware and software architecture of a particular device. The actual "how" decisions are (correctly) left in the hands of implementors, so long as implementation differences will generally produce proper on-the-wire behavior.
RFCは、一般にプロトコルの動作、つまり、プロトコルによって「何が」実行されるかを記述しますが、それがどのように実装されるかを正確に記述しているわけではありません。プロトコルの最適な実装方法の詳細は、特定のデバイスのハードウェアとソフトウェアの全体的なアーキテクチャによって異なります。実際の「方法」の決定は、（正しく）実装の違いが一般的に適切な通信中の動作を生成する限り、実装者に委ねられます。
While reading this document, it is important to keep in mind that discussions of how things have been implemented beyond basic compliance with the specification is not within the scope of the Neighbor Discovery RFCs.
このドキュメントを読む際、仕様への基本的な準拠を超えて物事がどのように実装されたかについての議論は、近隣探索RFCの範囲外であることを覚えておくことが重要です。
This document is primarily intended for operators of IPV6 networks and implementors of [RFC4861]. The document provides some operational considerations as well as recommendations to increase the resilience of the Neighbor Discovery protocol.
このドキュメントは、主にIPV6ネットワークのオペレーターと[RFC4861]の実装者を対象としています。このドキュメントには、運用上の考慮事項と、近隣探索プロトコルの回復力を高めるための推奨事項が記載されています。
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. For example, an IPv4 /20 contains only 4096 address. In contrast, the default IPv6 subnet size is a /64, a number so large it covers literally billions of billions of addresses, the overwhelming majority of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery may fail to perform as desired when they perform address resolution of large numbers of unassigned addresses. Such failures can be triggered either intentionally by an attacker launching a denial-of-service attack (DoS) [RFC4732] to exploit this vulnerability or unintentionally due to the use of legitimate operational tools that scan networks for inventory and other purposes. As a result of these failures, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transport flows may be interrupted.
IPv4では、サブネットは一般的に小さく、サブネット上の実際のマシン数をカバーするのに十分な大きさになります。たとえば、IPv4 / 20には4096のアドレスしか含まれていません。対照的に、デフォルトのIPv6サブネットサイズは/ 64であり、文字通り数十億億のアドレスをカバーする非常に大きな数であり、その圧倒的大部分は割り当てられません。その結果、近隣探索の単純化した実装は、割り当てられていない多数のアドレスのアドレス解決を実行するときに、必要に応じて実行に失敗する可能性があります。このような障害は、攻撃者がサービス拒否攻撃（DoS）[RFC4732]を開始してこの脆弱性を悪用することによって意図的に、またはインベントリやその他の目的でネットワークをスキャンする正当な運用ツールを使用することによって、意図せずに引き起こされる可能性があります。これらの障害の結果、新しいデバイスがネットワークに「参加」できなくなり、新しいIPv6フローを確立できなくなり、既存のIPv6トランスポートフローが中断される可能性があります。
Network scans attempt to find and probe devices on a network. Typically, scans are performed on a range of target addresses, or all the addresses on a particular subnet. When such probes are directed via a router, and the target addresses are on a directly attached network, the router will attempt to perform address resolution on a large number of destinations (i.e., some fraction of the 2^64 addresses on the subnet). The router's process of testing for the (non)existence of neighbors can induce a denial-of-service condition, where the number of necessary Neighbor Discovery requests overwhelms the implementation's capacity to process them, exhausts available memory and replaces existing in-use mappings with incomplete entries that will never be completed. A directed DoS attack may seek to intentionally create similar conditions to those created unintentionally by a network scan. The resulting network disruption may impact existing traffic, and devices that join the network may find that address resolution attempts fail. The DoS as a consequence of network scanning was previously described in [RFC5157].
ネットワークスキャンは、ネットワーク上のデバイスを見つけて調査しようとします。通常、スキャンは、ある範囲のターゲットアドレス、または特定のサブネット上のすべてのアドレスに対して実行されます。このようなプローブがルーターを介して送信され、ターゲットアドレスが直接接続されたネットワーク上にある場合、ルーターは多数の宛先（つまり、サブネット上の2 ^ 64アドレスの一部）でアドレス解決を実行しようとします。ネイバーの（非）存在をテストするルーターのプロセスは、サービス拒否状態を引き起こす可能性があります。この場合、必要なネイバー探索要求の数が実装の処理能力を圧倒し、利用可能なメモリを使い果たし、既存の使用中のマッピングを次のものに置き換えます。決して完了しない不完全なエントリ。直接的なDoS攻撃は、ネットワークスキャンによって意図せずに作成されたものと同様の条件を意図的に作成しようとする場合があります。結果として生じるネットワークの混乱は、既存のトラフィックに影響を与える可能性があり、ネットワークに参加するデバイスは、アドレス解決の試行が失敗することに気付く場合があります。ネットワークスキャンの結果としてのDoSは、以前に[RFC5157]で説明されていました。
In order to mitigate risk associated with this DoS threat, some router implementations have taken steps to rate-limit the processing rate of Neighbor Solicitations (NS). While these mitigations do help, they do not fully address the issue and may introduce their own set of issues to the Neighbor Discovery process.
このDoS脅威に関連するリスクを軽減するために、一部のルーター実装では、近傍要請（NS）の処理速度をレート制限するための措置を講じています。これらの緩和策は役立ちますが、問題を完全には解決せず、近隣探索プロセスに独自の問題のセットをもたらす可能性があります。
Address Resolution: Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. In IPv6, address resolution is performed as part of Neighbor Discovery [RFC4861], Section 7.2.
アドレス解決：アドレス解決は、ノードがIPアドレスのみを指定されたネイバーのリンク層アドレスを決定するプロセスです。 IPv6では、アドレス解決は近隣探索[RFC4861]、セクション7.2の一部として実行されます。
Forwarding Plane: The part of a router responsible for forwarding packets. In higher-end routers, the forwarding plane is typically implemented in specialized hardware optimized for performance. Steps in the forwarding process include determining the correct outgoing interface for a packet, decrementing its Time To Live (TTL), verifying and updating the checksum, placing the correct link-layer header on the packet, and forwarding it.
フォワーディングプレーン：パケットの転送を担当するルーターの部分。ハイエンドルータでは、フォワーディングプレーンは通常、パフォーマンスが最適化された専用ハードウェアに実装されています。転送プロセスの手順には、パケットの正しい発信インターフェイスの決定、Time To Live（TTL）のデクリメント、チェックサムの確認と更新、正しいリンク層ヘッダーのパケットへの配置、および転送が含まれます。
Control Plane: The part of the router implementation that maintains the data structures that determine where packets should be forwarded. The control plane is typically implemented as a "slower" software process running on a general purpose processor and is responsible for such functions as communicating network status changes via routing protocols, maintaining the forwarding table, performing management, and resolving the correct link-layer address for adjacent neighbors. The control plane "controls" the forwarding plane by programming it with the information needed for packet forwarding.
コントロールプレーン：パケットの転送先を決定するデータ構造を維持するルーター実装の一部。コントロールプレーンは通常、汎用プロセッサで実行される「低速」ソフトウェアプロセスとして実装され、ルーティングプロトコルを介したネットワークステータスの変更の通信、転送テーブルの維持、管理の実行、正しいリンク層アドレスの解決などの機能を担当します。隣接する隣人。コントロールプレーンは、パケット転送に必要な情報を使用してプログラミングすることにより、転送プレーンを「制御」します。
Neighbor Cache: As described in [RFC4861], the data structure that holds the cache of (amongst other things) IP address to link-layer address mappings for connected nodes. As the information in the Neighbor Cache is needed by the forwarding plane every time it forwards a packet, it is usually implemented in an Application-specific Integrated Circuit (ASIC).
ネイバーキャッシュ：[RFC4861]で説明されているように、接続されたノードのリンク層アドレスマッピングへのIPアドレス（とりわけ）のキャッシュを保持するデータ構造。ネイバーキャッシュ内の情報は、パケットを転送するたびにフォワーディングプレーンによって必要とされるため、通常、アプリケーション固有の集積回路（ASIC）に実装されます。
Neighbor Discovery Process: The Neighbor Discovery Process (NDP) is that part of the control plane that implements the Neighbor Discovery protocol. NDP is responsible for performing address resolution and maintaining the Neighbor Cache. When forwarding packets, the forwarding plane accesses entries within the Neighbor Cache. When the forwarding plane processes a packet for which the corresponding Neighbor Cache Entry (NCE) is missing or incomplete, it notifies NDP to take appropriate action (typically via a shared queue). NDP picks up requests from the shared queue and performs any necessary discovery action. In many implementations, the NDP is also responsible for responding to router solicitation messages, Neighbor Unreachability Detection (NUD), etc.
近隣探索プロセス：近隣探索プロセス（NDP）は、近隣探索プロトコルを実装するコントロールプレーンの一部です。 NDPは、アドレス解決の実行とネイバーキャッシュの維持を担当します。パケットを転送するとき、転送プレーンはネイバーキャッシュ内のエントリにアクセスします。フォワーディングプレーンは、対応するネイバーキャッシュエントリ（NCE）が欠落しているか不完全なパケットを処理するときに、適切なアクションを実行するように（通常は共有キュー経由で）NDPに通知します。 NDPは共有キューから要求を取得し、必要な検出アクションを実行します。多くの実装では、NDPはルーター要請メッセージ、Neighbor Unreachability Detection（NUD）などへの応答も行います。
Modern router architectures separate the forwarding of packets (forwarding plane) from the decisions needed to decide where the packets should go (control plane). In order to deal with the high number of packets per second, the forwarding plane is generally implemented in hardware and is highly optimized for the task of forwarding packets. In contrast, the NDP control plane is mostly implemented in software processes running on a general purpose processor.
最新のルーターアーキテクチャでは、パケットの転送（転送プレーン）と、パケットの宛先（コントロールプレーン）を決定するために必要な決定を分けています。 1秒あたりの大量のパケットを処理するために、フォワーディングプレーンは一般にハードウェアに実装され、パケットを転送するタスクに対して高度に最適化されています。対照的に、NDPコントロールプレーンは、ほとんどが汎用プロセッサで実行されるソフトウェアプロセスに実装されています。
When a router needs to forward an IP packet, the forwarding plane logic performs the longest match lookup to determine where to send the packet and what outgoing interface to use. To deliver the packet to an adjacent node, the forwarding plane encapsulates the packet in a link-layer frame (which contains a header with the link-layer destination address). The forwarding plane logic checks the Neighbor Cache to see if it already has a suitable link-layer destination, and if not, places the request for the required information into a queue, and signals the control plane (i.e., NDP) that it needs the link-layer address resolved.
ルータがIPパケットを転送する必要がある場合、フォワーディングプレーンロジックは最長一致検索を実行して、パケットの送信先と使用する発信インターフェイスを決定します。パケットを隣接ノードに配信するために、フォワーディングプレーンはパケットをリンク層フレーム（リンク層宛先アドレスを持つヘッダーを含む）にカプセル化します。フォワーディングプレーンロジックは、近隣キャッシュをチェックして、適切なリンク層宛先がすでにあるかどうかを確認し、ない場合は、必要な情報の要求をキューに入れ、コントロールプレーン（つまり、NDP）に必要なことを通知します。リンク層アドレスが解決されました。
In order to protect NDP specifically and the control plane generally from being overwhelmed with these requests, appropriate steps must be taken. For example, the size and fill rate of the queue might be limited. NDP running in the control plane of the router dequeues requests and performs the address resolution function (by performing a neighbor solicitation and listening for a neighbor advertisement). This process is usually also responsible for other activities needed to maintain link-layer information, such as Neighbor Unreachability Detection (NUD).
NDPを保護し、コントロールプレーンがこれらの要求に圧倒されないようにするために、適切な手順を実行する必要があります。たとえば、キューのサイズとフィルレートが制限される場合があります。ルータのコントロールプレーンで実行されているNDPは、要求をデキューし、アドレス解決機能を実行します（ネイバー送信要求を実行し、ネイバーアドバタイズメントをリッスンすることにより）。このプロセスは、通常、Neighbor Unreachability Detection（NUD）など、リンク層情報を維持するために必要な他のアクティビティも担当します。
By sending appropriate packets to addresses on a given subnet, an attacker can cause the router to queue attempts to resolve so many addresses that it crowds out attempts to resolve "legitimate" addresses (and in many cases becomes unable to perform maintenance of existing entries in the Neighbor Cache, and unable to answer Neighbor Solicitation). This condition can result in the inability to resolve new neighbors and loss of reachability to neighbors with existing NCEs. During testing, it was concluded that four simultaneous nmap sessions from a low-end computer were sufficient to make a router's Neighbor Discovery process unusable; therefore, forwarding became unavailable to the destination subnets.
攻撃者は、特定のサブネット上のアドレスに適切なパケットを送信することにより、ルーターに非常に多くのアドレスを解決する試みをキューイングさせ、「正当な」アドレスを解決する試みを混雑させます（多くの場合、既存のエントリのメンテナンスを実行できなくなります）近隣キャッシュ、および近隣要請に応答できません）。この状態により、新しいネイバーを解決できなくなり、既存のNCEを持つネイバーへの到達可能性が失われる可能性があります。テスト中、ローエンドコンピューターからの4つの同時nmapセッションは、ルーターの近隣探索プロセスを使用不能にするのに十分であると結論付けられました。そのため、宛先サブネットへの転送は利用できなくなりました。
The failure to maintain proper NDP behavior whilst under attack has been observed across multiple platforms and implementations, including the largest modern router platforms available (at the inception of work on this document).
攻撃を受けている間に適切なNDP動作を維持できないことは、利用可能な最大の最新のルータープラットフォームを含む複数のプラットフォームと実装にわたって観察されています（このドキュメントの作業開始時）。
When a packet arrives at (or is generated by) a router for a destination on an attached link, the router needs to determine the correct link-layer address to use in the destination field of the Layer 2 encapsulation. The router checks the Neighbor Cache for an existing Neighbor Cache Entry for the neighbor, and if none exists, invokes the address resolution portions of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the link-layer address of the neighbor.
接続されたリンク上の宛先のルーターにパケットが到着した（またはルーターによって生成された）場合、ルーターは、レイヤー2カプセル化の宛先フィールドで使用する正しいリンク層アドレスを決定する必要があります。ルータは、ネイバーキャッシュをチェックして、ネイバーの既存のネイバーキャッシュエントリを確認し、存在しない場合は、IPv6ネイバーディスカバリ[RFC4861]プロトコルのアドレス解決部分を呼び出して、ネイバーのリンク層アドレスを決定します。
[RFC4861], Section 5.2, outlines how this process works. A very high-level summary is that the device creates a new Neighbor Cache Entry for the neighbor, sets the state to INCOMPLETE, queues the packet, and initiates the actual address resolution process. The device then sends out one or more Neighbor Solicitations, and when it receives a corresponding Neighbor Advertisement, completes the Neighbor Cache Entry and sends the queued packet.
[RFC4861]、セクション5.2、このプロセスの仕組みの概要。非常に高レベルの要約では、デバイスはネイバーの新しいネイバーキャッシュエントリを作成し、状態をINCOMPLETEに設定し、パケットをキューに入れ、実際のアドレス解決プロセスを開始します。次に、デバイスは1つ以上の近隣要請を送信し、対応する近隣アドバタイズを受信すると、近隣キャッシュエントリを完了して、キューに入れられたパケットを送信します。
This section provides some feasible mitigation options that can be employed today by network operators in order to protect network availability while vendors implement more effective protection measures. It can be stated that some of these options are "kludges", and can be operationally difficult to manage. They are presented, as they represent options we currently have. It is each operator's responsibility to evaluate and understand the impact of changes to their network due to these measures.
このセクションでは、ベンダーがより効果的な保護対策を実装しながらネットワークの可用性を保護するために、ネットワークオペレーターが現在採用できるいくつかの実行可能な軽減オプションを提供します。これらのオプションの一部は「クラッジ」であり、運用上管理が難しい場合があると言えます。それらは、私たちが現在持っているオプションを表すため、提示されています。これらの対策によるネットワークへの変更の影響を評価および理解することは、各オペレーターの責任です。
The DoS condition is induced by making a router try to resolve addresses on the subnet at a high rate. By carefully addressing machines into a small portion of a subnet (such as the lowest numbered addresses), it is possible to filter access to addresses not in that assigned portion of address space using Access Control Lists (ACLs), or by null routing, features which are available on most existing platforms. This will prevent the attacker from making the router attempt to resolve unused addresses. For example, if there are only 50 hosts connected to an interface, you may be able to filter any address above the first 64 addresses of that subnet by null-routing the subnet carrying a more specific /122 route or by applying ACLs on the WAN link to prevent the attack traffic reaching the vulnerable device.
DoS状態は、ルーターがサブネット上のアドレスを高速で解決しようとすることによって引き起こされます。サブネットの小さな部分（最も小さい番号のアドレスなど）にマシンを注意深くアドレス指定することにより、アクセス制御リスト（ACL）を使用して、またはnullルーティング機能を使用して、アドレス空間の割り当てられた部分にないアドレスへのアクセスをフィルタリングできます。ほとんどの既存のプラットフォームで利用できます。これにより、攻撃者がルーターで未使用のアドレスを解決しようとするのを防ぐことができます。たとえば、インターフェイスに接続されているホストが50台しかない場合、より具体的な/ 122ルートを運ぶサブネットをヌルルーティングするか、WANにACLを適用することにより、そのサブネットの最初の64アドレスを超えるアドレスをフィルタリングできます。攻撃トラフィックが脆弱なデバイスに到達するのを防ぐためのリンク。
As mentioned at the beginning of this section, it is fully understood that this is ugly (and difficult to manage); but failing other options, it may be a useful technique especially when responding to an attack.
このセクションの冒頭で述べたように、これは醜い（そして管理が難しい）ことは十分に理解されています。しかし、他のオプションに失敗すると、特に攻撃に応答するときに、それは有用なテクニックになる可能性があります。
This solution requires that the hosts be statically or statefully addressed (as is often done in a datacenter), and they may not interact well with networks using [RFC4862].
このソリューションでは、ホストが静的またはステートフルにアドレス指定される必要があり（データセンターでよく行われるように）、[RFC4862]を使用してネットワークとうまく相互作用しない可能性があります。
By sizing subnets to reflect the number of addresses actually in use, the problem can be avoided. For example, [RFC6164] recommends sizing the subnets for inter-router links so they only have two addresses (a /127). It is worth noting that this practice is common in IPv4 networks, in part to protect against the harmful effects of Address Resolution Protocol (ARP) request flooding.
実際に使用されているアドレスの数を反映するようにサブネットのサイジングを行うことにより、問題を回避できます。たとえば、[RFC6164]は、ルーター間リンクのサブネットを2つのアドレス（a / 127）のみを持つようにサイジングすることを推奨しています。この手法はIPv4ネットワークでは一般的であり、アドレス解決プロトコル（ARP）要求のフラッディングによる悪影響から保護することも一部であることは注目に値します。
Subnet prefixes longer than a /64 are not able to use stateless auto-configuration [RFC4862], so this approach is not suitable for use with hosts that are not statically configured.
/ 64よりも長いサブネットプレフィックスは、ステートレス自動構成[RFC4862]を使用できないため、このアプローチは、静的に構成されていないホストでの使用には適していません。
One very effective technique is to route the subnet to a discard interface (most modern router platforms can discard traffic in hardware / the forwarding plane) and then have individual hosts announce routes for their IP addresses into the network (or use some method to inject much more specific addresses into the local routing domain). For example, the network 2001:db8:1:2:3::/64 could be routed to a discard interface on "border" routers, and then individual hosts could announce 2001:db8:1:2:3::10/128, 2001:db8:1:2: 3::66/128 into the IGP. This is typically done by having the IP address bound to a virtual interface on the host (for example, the loopback interface), enabling IP forwarding on the host and having it run a routing daemon. For obvious reasons, host participation in the IGP makes many operators uncomfortable, but it can be a very powerful technique if used in a disciplined and controlled manner. One method to help address these concerns is to have the hosts participate in a different IGP (or difference instance of the same IGP) and carefully redistribute into the main IGP.
非常に効果的な手法の1つは、サブネットを破棄インターフェイスにルーティングし（最新のルータープラットフォームのほとんどはハードウェア/転送プレーンのトラフィックを破棄できる）、個々のホストにIPアドレスのルートをネットワークに通知させる（または何らかの方法を使用して大量に注入する）ローカルルーティングドメインへのより具体的なアドレス）。たとえば、ネットワーク2001：db8：1：2：3 :: / 64は「ボーダー」ルーターの破棄インターフェースにルーティングされ、個々のホストは2001：db8：1：2：3 :: 10 /をアナウンスできます。 128、2001：db8：1：2：3 :: 66/128をIGPに送信します。これは通常、IPアドレスをホストの仮想インターフェイス（たとえば、ループバックインターフェイス）にバインドし、ホストでIP転送を有効にし、ルーティングデーモンを実行させることで行われます。明白な理由で、IGPへのホストの参加は多くのオペレーターを不快にさせますが、統制のとれた制御された方法で使用される場合、それは非常に強力なテクニックになる可能性があります。これらの懸念に対処する1つの方法は、ホストを別のIGP（または同じIGPの別のインスタンス）に参加させ、メインIGPに慎重に再配布することです。
Many implementations provide a means to control the rate of resolution of unknown addresses. By tuning this rate, it may be possible to ameliorate the issue, as with most tuning knobs (especially those that deal with rate-limiting), the attack may be completed more quickly due to the lower threshold. By excessively lowering this rate, you may negatively impact how long the device takes to learn new addresses under normal conditions (for example, after clearing the Neighbor Cache or when the router first boots). Under attack conditions, you may be unable to resolve "legitimate" addresses sooner than if you had just left the parameter untouched.
多くの実装は、不明なアドレスの解決率を制御する手段を提供します。このレートを調整することで、問題を改善できる可能性があります。ほとんどの調整ノブ（特にレート制限を扱うもの）と同様に、しきい値が低いため、攻撃がより早く完了する可能性があります。このレートを過度に下げると、デバイスが通常の状態（たとえば、ネイバーキャッシュをクリアした後やルーターの最初の起動時）で新しいアドレスを学習するのにかかる時間に悪影響を与える可能性があります。攻撃の状況では、パラメータをそのままにしておいた場合よりも早く「正当な」アドレスを解決できない場合があります。
It is worth noting that this technique is worth investigating only if the device has separate queues for resolution of unknown addresses and the maintenance of existing entries.
この手法は、デバイスに不明なアドレスの解決と既存のエントリのメンテナンスのための個別のキューがある場合にのみ調査する価値があることに注意してください。
This section provides some recommendations to implementors of IPv6 Neighbor Discovery.
このセクションでは、IPv6近隣探索の実装者にいくつかの推奨事項を提供します。
At a high-level, implementors should program defensively. That is, they should assume that attackers will attempt to exploit implementation weaknesses, and they should ensure that implementations are robust to various attacks. In the case of Neighbor Discovery, the following general considerations apply: Manage Resources Explicitly: Resources such as processor cycles, memory, etc., are never infinite, yet with IPv6's large subnets, it is easy to cause NDP to generate large numbers of address resolution requests for nonexistent destinations. Implementations need to limit resources devoted to processing Neighbor Discovery requests in a thoughtful manner.
高レベルでは、実装者は防御的にプログラムする必要があります。つまり、攻撃者が実装の弱点を悪用しようとすることを想定し、実装がさまざまな攻撃に対して堅牢であることを確認する必要があります。近隣探索の場合、次の一般的な考慮事項が適用されます。リソースを明示的に管理します。プロセッササイクルやメモリなどのリソースは無限ではありませんが、IPv6の大規模なサブネットを使用すると、NDPで大量のアドレスを生成しやすくなります。存在しない宛先の解決要求。実装では、近隣探索要求の処理に専念するリソースを慎重に制限する必要があります。
Prioritize: Some NDP requests are more important than others. For example, when resources are limited, responding to Neighbor Solicitations for one's own address is more important than initiating address resolution requests that create new entries. Likewise, performing Neighbor Unreachability Detection, which by definition is only invoked on destinations that are actively being used, is more important than creating new entries for possibly nonexistent neighbors.
優先順位付け：一部のNDP要求は他の要求よりも重要です。たとえば、リソースが限られている場合、自分のアドレスに対する近隣要請に応答することは、新しいエントリを作成するアドレス解決要求を開始することよりも重要です。同様に、定義上はアクティブに使用されている宛先でのみ呼び出される近隣到達不能検出を実行することは、存在しない可能性のある近隣の新しいエントリを作成することよりも重要です。
Not all Neighbor Discovery activities are equally important. Specifically, requests to perform large numbers of address resolutions on non-existent Neighbor Cache Entries should not come at the expense of servicing requests related to keeping existing, in-use entries properly up to date. Thus, implementations should divide work activities into categories having different priorities. The following gives examples of different activities and their importance in rough priority order. If implemented, the operation and priority of these should be configurable by the operator.
すべての近隣探索活動が同じように重要であるわけではありません。具体的には、存在しない近隣キャッシュエントリに対して多数のアドレス解決を実行する要求は、既存の使用中のエントリを適切に最新の状態に保つことに関連する要求の処理を犠牲にしてはなりません。したがって、実装では、作業アクティビティを優先度の異なるカテゴリに分類する必要があります。以下に、さまざまなアクティビティの例と、それらの重要度を大まかな優先順位で示します。実装する場合、これらの操作と優先度は、オペレーターが構成できる必要があります。
1. It is critical to respond to Neighbor Solicitations for one's own address, especially for a router. Whether for address resolution or Neighbor Unreachability Detection, failure to respond to Neighbor Solicitations results in immediate problems. Failure to respond to NS requests that are part of NUD can cause neighbors to delete the NCE for that address and will result in follow-up NS messages using multicast. Once an entry has been flushed, existing traffic for destinations using that entry can no longer be forwarded until address resolution completes successfully. In other words, not responding to NS messages further increases the NDP load and causes ongoing communication to fail.
1. 自分のアドレス、特にルーターについては、近隣要請に応答することが重要です。アドレス解決であろうと近隣到達不能検出であろうと、近隣要請への応答に失敗すると、すぐに問題が発生します。 NUDの一部であるNS要求に応答しないと、ネイバーがそのアドレスのNCEを削除し、マルチキャストを使用したフォローアップNSメッセージが発生する可能性があります。エントリがフラッシュされると、そのエントリを使用する宛先への既存のトラフィックは、アドレス解決が正常に完了するまで転送できなくなります。つまり、NSメッセージに応答しないと、NDPの負荷がさらに増加し、進行中の通信が失敗します。
2. It is critical to revalidate one's own existing NCEs in need of refresh. As part of NUD, ND is required to frequently revalidate existing, in-use entries. Failure to do so can result in the entry being discarded. For in-use entries, discarding the entry will almost certainly result in a subsequent request to perform address resolution on the entry, but this time using multicast.
2. 更新が必要な自分の既存のNCEを再検証することが重要です。 NUDの一部として、NDは既存の使用中のエントリを頻繁に再検証する必要があります。そうしないと、エントリが破棄される可能性があります。使用中のエントリの場合、エントリを破棄すると、ほぼ確実に、エントリに対してアドレス解決を実行する後続の要求が発生しますが、今回はマルチキャストを使用します。
As above, once the entry has been flushed, existing traffic for destinations using that entry can no longer be forwarded until address resolution completes successfully.
上記のように、エントリがフラッシュされると、そのエントリを使用する宛先の既存のトラフィックは、アドレス解決が正常に完了するまで転送できなくなります。
3. To maintain the stability of the control plane, Neighbor Discovery activity related to traffic sourced by the router (as opposed to traffic being forwarded by the router) should be given high priority. Whenever network problems occur, debugging and making other operational changes requires being able to query and access the router. In addition, routing protocols dependent on Neighbor Discovery for connectivity may begin to react (negatively) to perceived connectivity problems, causing additional undesirable ripple effects.
3. コントロールプレーンの安定性を維持するために、（ルーターによって転送されるトラフィックではなく）ルーターによって送信されるトラフィックに関連する近隣探索アクティビティには高い優先度を与える必要があります。ネットワークの問題が発生したときはいつでも、デバッグやその他の運用上の変更を行うには、ルーターを照会してアクセスできる必要があります。また、接続の近隣探索に依存するルーティングプロトコルは、認識された接続の問題に（否定的に）反応し始め、追加の望ましくないリップル効果を引き起こす可能性があります。
4. Traffic to unknown addresses should be given lowest priority. Indeed, it may be useful to distinguish between "never seen" addresses and those that have been seen before, but that do not have a corresponding NCE. Specifically, the conceptual processing algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting NCEs under certain conditions. Rather than delete them completely, however, it might be useful to at least keep track of the fact that an entry at one time existed, in order to prioritize address resolution requests for such neighbors compared with neighbors that have never been seen before.
4. 不明なアドレスへのトラフィックには、最も低い優先順位を与える必要があります。実際、「見たことのない」アドレスと、以前に見られたが対応するNCEがないアドレスとを区別すると役立つ場合があります。具体的には、IPv6近隣探索[RFC4861]の概念的な処理アルゴリズムでは、特定の条件下でNCEを削除する必要があります。ただし、それらを完全に削除するのではなく、少なくとも一度にエントリが存在したという事実を追跡して、そのようなネイバーのアドレス解決要求を、これまでに見たことのないネイバーと比較して優先させると役立つ場合があります。
On implementations in which requests to NDP are submitted via a single queue, router vendors should provide operators with means to control both the rate of link-layer address resolution requests placed into the queue and the size of the queue. This will allow operators to tune Neighbor Discovery for their specific environment. The ability to set, or have per-interface or per-prefix queue limits at a rate below that of the global queue limit might restrict the damage to the Neighbor Discovery processing to the network targeted by the attack.
NDPへの要求が単一のキューを介して送信される実装では、ルーターベンダーは、キューに配置されるリンク層アドレス解決要求のレートとキューのサイズの両方を制御する手段をオペレーターに提供する必要があります。これにより、オペレーターは特定の環境に合わせて近隣探索を調整できます。グローバルキュー制限を下回るレートでインターフェイスごとまたはプレフィックスごとのキュー制限を設定または設定する機能は、攻撃の対象となるネットワークへのネイバー探索処理へのダメージを制限する可能性があります。
Setting those values must be a very careful balancing act -- the lower the rate of entry into the queue, the less load there will be on the ND process; however, it will take the router longer to learn legitimate destinations as a result. In a datacenter with 6,000 hosts attached to a single router, setting that value to be under 1000 would mean that resolving all of the addresses from an initial state (or something that invalidates the address cache, such as a Spanning Tree Protocol (STP) Topology Change Notification (TCN)) may take over 6 seconds. Similarly, the lower the size of the queue, the higher the likelihood of an attack being able to knock out legitimate traffic (but less memory utilization on the router).
これらの値を設定する場合は、非常に注意深くバランスを調整する必要があります。キューへのエントリレートが低いほど、NDプロセスへの負荷が少なくなります。ただし、その結果、ルータが正当な宛先を学習するのに時間がかかります。単一のルーターに6,000台のホストが接続されているデータセンターでは、その値を1000未満に設定すると、すべてのアドレスが初期状態（またはスパニングツリープロトコル（STP）トポロジなどのアドレスキャッシュを無効にするもの）から解決されます変更通知（TCN））には6秒以上かかる場合があります。同様に、キューのサイズが小さいほど、攻撃が正当なトラフィックをノックアウトできる可能性が高くなります（ただし、ルーターのメモリ使用率は低くなります）。
This document outlines mitigation options that operators can use to protect themselves from denial-of-service attacks. Implementation advice to router vendors aimed at ameliorating known problems carries the risk of previously unforeseen consequences. It is not believed that these mitigation techniques or the implementation of finer-grained queuing of NDP activity create additional security risks or DoS exposure.
このドキュメントでは、オペレーターがサービス拒否攻撃から自身を保護するために使用できる緩和オプションの概要を説明します。既知の問題を改善することを目的としたルーターベンダーへの実装のアドバイスには、以前に予期せぬ結果が生じるリスクがあります。これらの緩和技術またはNDPアクティビティのきめ細かいキューイングの実装が、追加のセキュリティリスクまたはDoS公開を引き起こすとは考えられていません。
The authors would like to thank Ron Bonica, Troy Bonin, John Jason Brzozowski, Randy Bush, Vint Cerf, Tassos Chatzithomaoglou, Jason Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow, and Suran De Silva. Special thanks to Thomas Narten and Ray Hunter for detailed review and (even more so) for providing text!
著者は、ロン・ボニカ、トロイ・ボニン、ジョン・ジェイソン・ブルゾゾフスキー、ランディ・ブッシュ、ヴィント・サーフ、タソス・チャツィトマオグル、ジェイソン・フェスラー、ウェス・ジョージ、エリック・クライン、ジャレッド・モーク、クリス・モロー、そしてスラン・デ・シルバに感謝します。詳細なレビューとテキストの提供について、Thomas NartenとRay Hunterに特に感謝します！
Apologies for anyone we may have missed; it was not intentional.
私たちが見逃したかもしれない人のための謝罪。それは意図的ではありませんでした。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011.
[RFC6164]河野雅人、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリッティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164、 2011年4月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157] Chown、T。、「IPv6のネットワークスキャンへの影響」、RFC 5157、2008年3月。
Authors' Addresses
著者のアドレス
Igor Gashinsky Yahoo! 45 W 18th St New York, NY USA
イゴールガシンスキーYahoo! 45 W 18th Stニューヨーク、ニューヨークアメリカ
EMail: igor@yahoo-inc.com
Joel Jaeggli Zynga 111 Evelyn Sunnyvale, CA USA
Joel Jaeggli Zynga 111 Evelyn Sunnyvale、CA米国
EMail: jjaeggli@zynga.com
Warren Kumari Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA USA
Warren Kumari Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA USA
EMail: warren@kumari.net