Internet Engineering Task Force (IETF) G. Nakibly
Request for Comments: 6324 NEWRSC
Category: Informational F. Templin
ISSN: 2070-1721 Boeing Research & Technology
August 2011
Routing Loop Attack Using IPv6 Automatic Tunnels:
Problem Statement and Proposed Mitigations
Abstract
抽象
This document is concerned with security vulnerabilities in IPv6-in-IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial-of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration.
このマニュアルでは、IPv6インのIPv4自動トンネルにおけるセキュリティの脆弱性と懸念しています。これらの脆弱性は、攻撃者がIPv4ルーティング状態とIPv6ルーティング状態間の不整合を利用することを可能にします。攻撃は、サービス拒否（DoS）攻撃を容易にするトラフィック増幅のための手段として悪用することができるルーティング・ループを形成します。本書の最初の目的は、この攻撃とその根本原因に通知することです。第二の目的は、いくつかの可能な緩和策を提示することです。この記事の執筆時点では、これらの脆弱性を悪用する悪質な攻撃の既知の報告がないことに留意すべきです。それにもかかわらず、これらの脆弱性は、偶然の設定ミスによって活性化することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6324.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6324で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. A Detailed Description of the Attack ............................4
3. Proposed Mitigation Measures ....................................6
3.1. Verification of Endpoint Existence .........................6
3.1.1. Neighbor Cache Check ................................6
3.1.2. Known IPv4 Address Check ............................7
3.2. Operational Measures .......................................7
3.2.1. Avoiding a Shared IPv4 Link .........................7
3.2.2. A Single Border Router ..............................8
3.2.3. A Comprehensive List of Tunnel Routers ..............9
3.2.4. Avoidance of On-Link Prefixes .......................9
3.3. Destination and Source Address Checks .....................15
3.3.1. Known IPv6 Prefix Check ............................16
4. Recommendations ................................................17
5. Security Considerations ........................................17
6. Acknowledgments ................................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................19
IPv6-in-IPv4 tunnels are an essential part of many migration plans for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only network. Automatic tunnels that assign IPv6 prefixes with stateless address mapping properties (hereafter called "automatic tunnels") are a category of tunnels in which a tunneled packet's egress IPv4 address is embedded within the destination IPv6 address of the packet. An automatic tunnel's router is a router that respectively encapsulates and decapsulates the IPv6 packets into and out of the tunnel.
IPv6のインのIPv4トンネルは、IPv6のための多くの移行計画の重要な部分です。彼らは、2つのIPv6ノードがIPv4のみのネットワークを介して通信することを可能にします。ステートレスアドレスマッピングプロパティでのIPv6プレフィックスを割り当てる自動トンネルは、トンネリングされたパケットの出口のIPv4アドレスは、パケットの宛先IPv6アドレス内に埋め込まれたトンネルのカテゴリーである（以下、「自動トンネル」と呼ばれます）。自動トンネルのルータは、それぞれに、トンネルの外にIPv6パケットがカプセル化及びデカプセル化ルータです。
Reference [USENIX09] pointed out the existence of a vulnerability in the design of IPv6 automatic tunnels. Tunnel routers operate on the implicit assumption that the destination address of an incoming IPv6 packet is always an address of a valid node that can be reached via the tunnel. The assumption of path validity can introduce routing loops as the inconsistency between the IPv4 routing state and the IPv6 routing state allows a routing loop to be formed. Although those loops will not trap normal data, they will catch traffic targeted at addresses that have become unavailable, and misconfigured traffic can enter the loop.
参考文献[USENIX09]のIPv6自動トンネルの設計における脆弱性の存在を指摘しました。トンネルルータは、着信IPv6パケットの宛先アドレスが常にトンネルを介して到達することができる有効なノードのアドレスであることを暗黙の前提に動作します。 IPv4ルーティング状態とIPv6ルーティング状態との矛盾は、ルーティングループが形成されることを可能にするようにパス妥当性の仮定は、ルーティングのループを導入することができます。これらのループはトラップ通常のデータは、彼らが利用できなくなってきたアドレスをターゲットにトラフィックをキャッチしますないだろう、と誤って設定トラフィックは、ループに入ることができますが。
The looping vulnerability can be triggered accidentally, or exploited maliciously by an attacker crafting a packet that is routed over a tunnel to a node that is not associated with the packet's destination. This node may forward the packet out of the tunnel to the native IPv6 network. There, the packet is routed back to the ingress point, which forwards it back into the tunnel. Consequently, the packet loops in and out of the tunnel. The loop terminates only when the Hop Limit field in the IPv6 header of the packet is decremented to zero. This vulnerability can be abused as a vehicle for traffic amplification to facilitate DoS attacks [RFC4732].
ループ脆弱性が偶発トリガ、またはパケットの宛先に関連付けられていないノードへのトンネルを介してルーティングされたパケットを作り上げる攻撃者が悪意を持って利用することができます。このノードは、ネイティブIPv6ネットワークへのトンネルの外にパケットを転送することができます。そこでは、パケットが戻ってトンネルにそれを転送する入力点に戻されます。したがって、パケットは、トンネルの中と外ループ。ループは、パケットのIPv6ヘッダーのホップ制限フィールドがゼロにデクリメントされた場合にのみ終了します。この脆弱性は、DoS攻撃[RFC4732]を容易にするために、トラフィックの増幅のための手段として悪用することができます。
Without compensating security measures in place, all IPv6 automatic tunnels that are based on protocol-41 encapsulation [RFC4213] are vulnerable to such an attack, including the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], 6to4 [RFC3056], and 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) [RFC5969]. It should be noted that this document does not consider non-protocol-41 encapsulation attacks. In particular, we do not address the Teredo [RFC4380] attacks described in [USENIX09]. These attacks are considered in [TEREDO-LOOPS].
代わりに、セキュリティ対策を補償することなく、プロトコル41のカプセル化[RFC4213]に基づいているすべてのIPv6自動トンネルは、イントラサイト自動トンネルプロトコル（ISATAP）[RFC5214]の6to4 [RFC3056]をアドレス指定を含む、そのような攻撃に対して脆弱であり、そして6rd（IPv4の基盤のIPv6のRapid Deployment）[RFC5969]。この文書が非プロトコル-41のカプセル化攻撃を考慮していないことに留意すべきです。特に、我々は[USENIX09]で説明したのTeredo [RFC4380]の攻撃に対処するものではありません。これらの攻撃は、[TEREDO-LOOPS]で考慮されています。
The aim of this document is to shed light on the routing loop attack and describe possible mitigation measures that should be considered by operators of current IPv6 automatic tunnels and by designers of future ones. We note that tunnels may be deployed in various operational environments, e.g., service provider networks, enterprise networks, etc. Specific issues related to the attack that are derived from the operational environment are not considered in this document.
このドキュメントの目的は、ルーティングループ攻撃に光を当てると現在のIPv6自動トンネルのオペレータにより及び将来のものの設計者によって考慮されなければならない可能性緩和策を記述することです。私たちは、運用環境から導出された攻撃に関連した特定の問題は、このドキュメントでは考慮されていないなど、サービスプロバイダーのネットワーク、企業ネットワーク、など、トンネルは様々な運用環境に展開することができることに注意してください。
Routing loops pose a risk to the stability of a network. Furthermore, they provide an opening for denial-of-service attacks that exploit the existence of the loop to increase the traffic load in the network. Section 3 of this document discusses a number of mitigation measures. The most desirable mitigation, however, is to operate the network in such a way that routing loops cannot take place (see Section 3.2).
ルーティングループがネットワークの安定性に危険をもたらします。さらに、彼らは、ネットワーク内のトラフィック負荷を高めるために、ループの存在を利用するサービス拒否攻撃のための開口部を提供しています。このドキュメントのセクション3は、緩和措置の数について説明します。最も望ましい緩和は、しかし、ルーティングループが（3.2節を参照）場所を取ることができないような方法でネットワークを動作させることです。
In this section, we shall denote an IPv6 address of a node by an IPv6 prefix assigned to the tunnel and an IPv4 address of the tunnel endpoint, i.e., Addr(Prefix, IPv4). Note that the IPv4 address may or may not be part of the prefix (depending on the specification of the tunnel's protocol). The IPv6 address may be dependent on additional bits in the interface ID; however, for our discussion their exact value is not important.
このセクションでは、我々は、トンネル、トンネルエンドポイント、すなわち、ADDR（プレフィックスはIPv4）のIPv4アドレスに割り当てられたIPv6プレフィックスによってノードのIPv6アドレスを意味するものとします。 IPv4アドレスまたはプレフィックス（トンネルのプロトコルの仕様に応じて）の一部であってもなくてもよいことに留意されたいです。 IPv6アドレスは、インタフェースIDに追加のビットに依存してもよいです。しかし、我々の議論のために彼らの正確な値は重要ではありません。
The two victims of this attack are routers -- R1 and R2 -- that service two different tunnel prefixes -- Prf1 and Prf2. Both routers have the capability to forward IPv6 packets in and out of their respective tunnels. The two tunnels need not be based on the same tunnel protocol. The only condition is that the two tunnel protocols be based on protocol-41 encapsulation. The IPv4 address of R1 is IP1, while the prefix of its tunnel is Prf1. IP2 and Prf2 are the respective values for R2. We assume that IP1 and IP2 belong to the same address realm, i.e., they are either both public, or both private and belong to the same internal network. The following network diagram depicts the locations of the two routers. The numbers indicate the packets of the attack and the path they traverse, as described below.
R1とR2 - - そのサービス二つの異なるトンネルプレフィックス - PRF1とPRF2この攻撃の2人の犠牲者はルータです。ルータは両方ともに、それらのそれぞれのトンネルのうち、IPv6パケットを転送する機能を持っています。 2つのトンネルは、同じトンネルプロトコルに基づく必要はありません。唯一の条件は、2つのトンネルプロトコルはプロトコル-41のカプセル化に基づいていることがあります。そのトンネルのプレフィックスはPRF1であるR1のIPv4アドレス、IP1です。 IP2とPRF2は、R2のそれぞれの値です。私たちは、IP1とIP2はすなわち、同じアドレスレルムに属していることを前提とし、彼らは両方のパブリック、プライベートまたは両方のいずれかであり、同じ内部ネットワークに属しています。次のネットワーク図は、2つのルータの位置を示します。後述のように番号は、攻撃およびそれらが横切る経路のパケットを示します。
[ Packet 1 ]
v6src = Addr(Prf1, IP2) [ Packet 2 ]
v6dst = Addr(Prf2, IP1) v6src = Addr(Prf1, IP2)
v4src = IP2; v4dst = IP1 +----------+ v6dst = Addr(Prf2, IP1)
//===========>| Router |-----------------\
|| | R1 | |
|| +----------+ v
.-. .-.
,-( _)-. ,-( _)-.
.-(_ IPv4 )-. .-(_ IPv6 )-.
(__ Network ) (__ Network )
`-(______)-' `-(______)-'
^^ |
|| +----------+ |
\\============| Router |<----------------/
[ Packet 1 ] | R2 | [ Packets 0 and 2 ]
v6src = Addr(Prf1, IP2) +----------+ v6src = Addr(Prf1, IP2)
v6dst = Addr(Prf2, IP1) v6dst = Addr(Prf2, IP1)
v4src = IP2; v4dst = IP1
Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 1: The Network Setting of the Attack
図1：攻撃のネットワーク設定
The attack is initiated by an accidentally or maliciously produced IPv6 packet (packet 0 in Figure 1) destined to a fictitious endpoint that appears to be reached via Prf2 and has IP1 as its IPv4 address, i.e., Addr(Prf2, IP1). The source address of the packet is an address with Prf1 as the prefix and IP2 as the embedded IPv4 address, i.e., Addr(Prf1, IP2). As the prefix of the destination address is Prf2, the packet will be routed over the IPv6 network to R2.
攻撃はPRF2を介して到達することが表示され、そのIPv4アドレス、すなわち、ADDR（PRF2、IP1）としてIP1を有する架空のエンドポイントに宛て偶然または故意生成IPv6パケット（図1のパケット0）によって開始されます。パケットの送信元アドレスが埋め込まれたIPv4アドレス、すなわち、ADDR（PRF1、IP2）のような接頭辞とIP2としてPRF1とアドレスです。宛先アドレスのプレフィックスがPRF2であるため、パケットがR2にIPv6ネットワーク上でルーティングされます。
R2 receives the packet through its IPv6 interface and forwards it into the tunnel with an IPv4 header having a destination address derived from the IPv6 destination, i.e., IP1. The source address is the address of R2, i.e., IP2. The packet (packet 1 in Figure 1) is routed over the IPv4 network to R1, which receives the packet on its IPv4 interface. It processes the packet as a packet that originates from one of the end nodes of Prf1.
R2は、IPv6インタフェースを介してパケットを受信し、IPv6宛先に由来する宛先アドレスを持つIPv4ヘッダとトンネルにそれを転送し、即ち、IP1。送信元アドレスは、すなわち、IP2 R2のアドレスです。パケット（図1においてパケット1）は、そのIPv4インタフェース上でパケットを受信したR1にIPv4ネットワークを介してルーティングされます。これは、PRF1のエンドノードの一つから発信パケットとしてパケットを処理します。
Since the IPv4 source address corresponds to the IPv6 source address, R1 will decapsulate the packet. Since the packet's IPv6 destination is outside of Prf1, R1 will forward the packet onto a native IPv6 interface. The forwarded packet (packet 2 in Figure 1) is identical to the original attack packet. Hence, it is routed back to R2, in which the loop starts again. Note that the packet may not necessarily be transported from R1 over the native IPv6 network. R1 may be connected to the IPv6 network through another tunnel.
IPv4ソースアドレスは、IPv6送信元アドレスに対応するので、R1は、パケットをデカプセル化します。パケットのIPv6宛先はPRF1の外にあるので、R1は、ネイティブIPv6インターフェイスにパケットを転送します。転送されたパケット（図1のパケット2）は、元の攻撃パケットと同一です。したがって、ループが再び開始するには、R2に戻されます。パケットは必ずしもネイティブIPv6ネットワーク上R1から搬送されなくてもよいことに留意されたいです。 R1は、別のトンネルを介してIPv6ネットワークに接続することができます。
The crux of the attack is as follows. The attacker exploits the fact that R2 does not know that R1 does not configure addresses from Prf2 and that R1 does not know that R2 does not configure addresses from Prf1. The IPv4 network acts as a shared link layer for the two tunnels. Hence, the packet is repeatedly forwarded by both routers. It is noted that the attack will fail when the IPv4 network cannot transport packets between the tunnels, for example, when the two routers belong to different IPv4 address realms or when ingress/ egress filtering is exercised between the routers.
次のような攻撃の核心です。攻撃者は、R2はR1がPRF2からアドレスを設定しないことと、R1はR2はPRF1からアドレスを設定しないことを知らないことを知らないという事実を利用します。 IPv4ネットワークでは2つのトンネルの共有リンク層として作用します。したがって、パケットを繰り返し、両方のルータによって転送されます。 IPv4ネットワークは、例えば、トンネルの間でパケットを転送することができないときに、2つのルータが異なるIPv4アドレスレルムに属している場合、または入口/出口フィルタリングはルータ間行使されたときに攻撃は、失敗することに留意されたいです。
The loop will stop when the Hop Limit field of the packet reaches zero. After a single loop, the Hop Limit field is decreased by the number of IPv6 routers on the path from R1 to R2. Therefore, the number of loops is inversely proportional to the number of IPv6 hops between R1 and R2.
パケットのホップ制限フィールドがゼロに達したときにループが停止します。単一ループ後、ホップリミットフィールドは、R1からR2へのパス上のIPv6ルータの数だけ減少されます。したがって、ループの数は、IPv6の数R1とR2の間のホップに反比例します。
The tunnels used by R1 and R2 may be any combination of automatic tunnel types, e.g., ISATAP, 6to4, and 6rd. This has the exception that both tunnels cannot be of type 6to4, since two 6to4 routers share the same IPv6 prefix, i.e., there is only one 6to4 prefix (2002::/16) in the Internet. For example, if the attack were to be launched on an ISATAP router (R1) and 6to4 relay (R2), then the destination and source addresses of the attack packet would be 2002:IP1:* and Prf1::0200:5efe:IP2, respectively.
R1及びR2によって使用されるトンネルは、自動トンネルタイプ、例えば、ISATAP、6to4の、及び6rdの任意の組み合わせであってもよいです。これは、二つの6to4ルータが同一のIPv6プレフィックスを共有しているため、すなわち、唯一の6to4プリフィックス（2002 :: / 16）は、インターネットであり、両方のトンネルタイプの6to4のものでないことを例外を有しています。例えば、場合攻撃がISATAPルータ（R1）と6to4リレー（R2）上で起動されるようにして、その後、攻撃パケットの宛先と送信元アドレスは、2002年のようになります。IP1：*とPRF1 :: 0200：5EFE：IP2 、それぞれ。
This section presents some possible mitigation measures for the attack described above. We shall discuss the advantages and disadvantages of each measure.
このセクションでは、上記の攻撃のためのいくつかの可能な緩和策を提示します。私たちは、各小節の長所と短所を議論しなければなりません。
The proposed measures fall under the following three categories:
対策案は、次の3つのカテゴリに分類します：
o Verification of endpoint existence
エンドポイントの有無の検証O
o Operational measures
O運用対策
o Destination and source address checks
O送信先と送信元アドレスをチェック
The routing loop attack relies on the fact that a router does not know whether there is an endpoint that can be reached via its tunnel that has the source or destination address of the packet. This category includes mitigation measures that aim to verify that there is a node that participates in the tunnel and that its address corresponds to the packet's destination or source addresses, as appropriate.
ルーティングループ攻撃は、ルータがパケットの送信元または宛先アドレスを有し、そのトンネルを介して到達することができるエンドポイントが存在するか否かを知らないという事実に依存しています。このカテゴリには、トンネル内で、そのアドレスが適宜、パケットの宛先または送信元アドレスに対応することが関与するノードが存在することを確認することを目的と緩和措置を含みます。
One way that the router can verify that an end host exists and can be reached via the tunnel is by checking whether a valid entry exists for it in the neighbor cache of the corresponding tunnel interface. The neighbor cache entry can be populated through, e.g., an initial reachability check, receipt of neighbor discovery messages, administrative configuration, etc.
ルータはエンドホストが存在し、トンネルを介して到達できることを確認することができる一つの方法は、有効なエントリは、対応するトンネルインターフェイスの近隣キャッシュに存在するかどうかチェックすることです。近隣キャッシュエントリは、例えば、最初の到達性チェック、近隣探索メッセージ、管理構成などの領収書を通じて取り込むことができます
When the router has a packet to send to a potential tunnel host for which there is no neighbor cache entry, it can perform an initial reachability check on the packet's destination address, e.g., as specified in the second paragraph of Section 8.4 of [RFC5214]. (The router can similarly perform a "reverse reachability" check on the packet's source address when it receives a packet from a potential tunnel host for which there is no neighbor cache entry.) This reachability check parallels the address resolution specifications in Section 7.2 of [RFC4861], i.e., the router maintains a small queue of packets waiting for reachability confirmation to complete. If confirmation succeeds, the router discovers that a legitimate tunnel host responds to the address. Otherwise, the router discards subsequent packets and returns ICMP destination unreachable indications as specified in Section 7.2.2 of [RFC4861].
ルータは何の近隣キャッシュエントリが存在しないいる可能性トンネルホストに送信するパケットを持っている場合は、[RFC5214]の8.4節の第二段落に指定されているように、パケットの宛先アドレス、例えば上の最初の到達性チェックを実行することができます。 （それが近隣キャッシュ・エントリが存在しないいる可能性トンネルホストからパケットを受信すると、ルータは、同様に「逆到達可能」パケットの送信元アドレスのチェックを行うことができる。）この到達可能性チェックはセクション7.2でアドレス解決仕様に匹敵[ RFC4861]は、すなわち、ルータが到達可能性確認が完了するのを待っているパケットの小さなキューを維持します。確認が成功した場合、ルータは、正当なトンネルホストがアドレスに応答することを発見します。そうでない場合は、ルータは、後続のパケットを破棄し、[RFC4861]のセクション7.2.2で指定されたICMP宛先到達不能指標を返します。
Note that this approach assumes that the neighbor cache will remain coherent and not be subject to malicious attack, which must be confirmed based on specific deployment scenarios. One possible way for an attacker to subvert the neighbor cache is to send false neighbor discovery messages with a spoofed source address.
このアプローチは、近隣キャッシュはコヒーレントままで、特定の展開シナリオに基づいて確認しなければならない、悪意のある攻撃の対象にならないだろうことを前提としています。近隣キャッシュを破壊する攻撃者のための1つの可能な方法は、偽装された送信元アドレスを持つ偽の近隣探索メッセージを送信することです。
Another approach that enables a router to verify that an end host exists and can be reached via the tunnel is simply by pre-configuring the router with the set of IPv4 addresses and prefixes that are authorized to use the tunnel. Upon this configuration, the router can perform the following simple checks:
エンドホストが存在することを確認するためにルータを可能にし、トンネルを介して到達することができる別のアプローチは、単にトンネルを使用することが許可されたIPv4アドレスとプレフィクスのセットを事前設定ルータによるものです。この構成の際に、ルータは、次の簡単なチェックを行うことができます。
o When the router forwards an IPv6 packet into the tunnel interface with a destination address that matches an on-link prefix and that embeds the IPv4 address IP1, it discards the packet if IP1 does not belong to the configured list of IPv4 addresses.
ルータは、オンリンクプレフィックスに一致し、そのIPv4アドレスIP1を埋め込み宛先アドレスを持つトンネルインターフェースにIPv6パケットを転送するときIP1は、IPv4アドレスの構成リストに属していない場合、O、それはパケットを廃棄します。
o When the router receives an IPv6 packet on the tunnel's interface with a source address that matches an on-link prefix and that embeds the IPv4 address IP2, it discards the packet if IP2 does not belong to the configured list of IPv4 addresses.
ルータがオンリンクプレフィックスに一致し、それはIPv4アドレスIP2を埋め込む送信元アドレスを持つトンネルのインターフェイス上でIPv6パケットを受信するとIP2は、IPv4アドレスの構成されたリストに属していない場合は、O、それはパケットを廃棄します。
The following measures can be taken by the network operator. Their aim is to configure the network in such a way that the attacks cannot take place.
次の措置は、ネットワークオペレータによって撮影することができます。彼らの目的は、攻撃が行われないような方法でネットワークを構成することです。
As noted above, the attack relies on having an IPv4 network as a shared link layer between more than one tunnel. From this, the following two mitigation measures arise:
上述したように、攻撃は、複数のトンネルとの間の共有リンク層としてIPv4ネットワークを有することに依存します。このことから、次の二つの緩和措置が生じます。
In this measure, a tunnel router may drop all IPv4 protocol-41 packets received or sent over interfaces that are attached to an untrusted IPv4 network. This will cut off any IPv4 network as a shared link. This measure has the advantage of simplicity. However, such a measure may not always be suitable for scenarios where IPv4 connectivity is essential on all interfaces. Most notably, filtering of IPv4 protocol-41 packets that belong to a 6to4 tunnel can have adverse effects on unsuspecting users [RFC6343].
この測定では、トンネルルータは、すべてのIPv4プロトコル41受信または信頼されていないIPv4ネットワークに接続されているインターフェースを介して送信されるパケットをドロップすることができます。これは、共有リンクとして任意のIPv4ネットワークを切断します。この措置は、単純であるという利点があります。しかしながら、そのような指標は常にIPv4接続は、すべてのインターフェイス上で不可欠であるシナリオには適していません。最も顕著には、6to4トンネルに属するのIPv4プロトコル41パケットのフィルタリングは、疑いを持たないユーザーが[RFC6343]に悪影響を有することができます。
This measure mitigates the attack by simply allowing for a single IPv6 tunnel to operate in a bounded IPv4 network. For example, the attack cannot take place in broadband home networks. In such cases, there is a small home network having a single residential gateway that serves as a tunnel router. A tunnel router is vulnerable to the attack only if it has at least two interfaces with a path to the Internet: a tunnel interface and a native IPv6 interface (as depicted in Figure 1). However, a residential gateway usually has only a single interface to the Internet; therefore, the attack cannot take place. Moreover, if there are only one or a few tunnel routers in the IPv4 network and all participate in the same tunnel, then there is no opportunity for perpetuating the loop.
この尺度は、単に境界IPv4ネットワークで動作する単一のIPv6トンネルを可能にすることによって攻撃を軽減します。例えば、攻撃はブロードバンドホームネットワークに場所を取ることができません。このような場合、トンネルルータとして機能する単一のレジデンシャルゲートウェイを有する小型のホームネットワークがあります。トンネルインターフェイスとネイティブIPv6インタフェース（図1に示されるように）トンネルルータはインターネットへのパスを有する少なくとも2つのインターフェイスを有している場合にのみ、攻撃に対して脆弱です。しかし、レジデンシャルゲートウェイは通常、インターネットへの唯一の単一のインタフェースを持っています。そのため、攻撃は行われません。そこIPv4ネットワークにおける1つまたは少数のトンネルルータがあり、すべてが同じトンネルに参加する場合はまた、その後ループを永続化するための機会は存在しません。
This approach has the advantage that it avoids the attack profile altogether without need for explicit mitigations. However, it requires careful configuration management, which may not be tenable in large and/or unbounded IPv4 networks.
このアプローチは、それが明示的な緩和策を必要とせずに完全に攻撃プロファイルを回避するという利点を有します。しかし、それは大きなおよび/または無制限のIPv4ネットワークでの批判に耐えないかもしれないように注意構成管理が必要です。
It is reasonable to assume that a tunnel router shall accept or forward tunneled packets only over its tunnel interface. It is also reasonable to assume that a tunnel router shall accept or forward IPv6 packets only over its IPv6 interface. If these two interfaces are physically different, then the network operator can mitigate the attack by ensuring that the following condition holds: there is no path between these two interfaces that does not go through the tunnel router.
トンネルルータが受け入れるかだけそのトンネルインターフェイス上でトンネリングパケットを転送するものと仮定することは合理的です。トンネルルータが受け入れるかだけそのIPv6インタフェース上でIPv6パケットを転送するものと想定することも妥当です。これら二つのインターフェイスは、物理的に異なっている場合、ネットワークオペレータは、次の条件が成立することを確実にすることによって、攻撃を軽減することができる：トンネルルータを通過せず、これらの二つのインターフェースの間にパスが存在しません。
The above condition ensures that an encapsulated packet that is transmitted over the tunnel interface will not get to another tunnel router and from there to the IPv6 interface of the first router. The condition also ensures the reverse direction, i.e., an IPv6 packet that is transmitted over the IPv6 interface will not get to another tunnel router and from there to the tunnel interface of the first router. This condition is essentially translated to a scenario in which the tunnel router is the only border router between the IPv6 network and the IPv4 network to which it is attached (as in the broadband home network scenario mentioned above).
上記条件は、トンネルインターフェースを介して送信されるカプセル化されたパケットは、別のトンネルルータに、そこから最初のルータのIPv6インタフェースに到達しないことを保証します。条件はまた、IPv6インタフェースを介して送信されたIPv6パケットは、別のトンネルルータに、そこから最初のルータのトンネルインターフェイスに到達しないであろう、すなわち、逆方向を確実にします。この条件は、本質的にトンネルルータは、IPv6ネットワークと（上記ブロードバンドホームネットワークのシナリオのように）、それが結合しているIPv4ネットワークとの間の唯一の境界ルータであるシナリオに変換されます。
If a tunnel router can be configured with a comprehensive list of IPv4 addresses of all other tunnel routers in the network, then the router can use the list as a filter to discard any tunneled packets coming from or destined to other routers. For example, a tunnel router can use the network's ISATAP Potential Router List (PRL) [RFC5214] as a filter as long as there is operational assurance that all ISATAP routers are listed and that no other types of tunnel routers are present in the network.
トンネルルータはネットワーク内の他のすべてのトンネルルータのIPv4アドレスの包括的なリストを構成することができる場合、ルータはから来る又は他のルータ宛の任意のトンネリングパケットを廃棄するフィルタとしてリストを使用することができます。そこにすべてのISATAPルータがリストされている動作保証であり、トンネルルータの他のタイプのネットワーク内に存在しないことのように、例えば、トンネルルータであれば、フィルタのようなネットワークのISATAP潜在ルータリスト（PRL）[RFC5214]を使用することができます。
This measure parallels the one proposed for 6rd in [RFC5969] where the 6rd Border Relay filters all known relay addresses of other tunnels inside the ISP's network.
この措置は、6rdボーダーリレーは、ISPのネットワーク内の他のトンネルのすべての既知のリレーアドレスをフィルタリング[RFC5969]で6rdのために提案されている1に匹敵します。
This measure is especially useful for intra-site tunneling mechanisms, such as ISATAP and 6rd, since filtering can be exercised on well-defined site borders. A specific ISATAP operational scenario for which this mitigation applies is described in Section 3 of [ISATAP-OPS].
フィルタリングは、明確に定義されたサイトの境界を上に行使することができるので、この測定は、ISATAPと6rdとしてサイト内トンネリングメカニズムのために特に有用です。この緩和が適用される特定のISATAP動作シナリオは、[ISATAP-OPS]のセクション3に記載されています。
The looping attack exploits the fact that a router is permitted to assign non-link-local IPv6 prefixes on its tunnel interfaces, which could cause it to send tunneled packets to other routers that do not configure an address from the prefix. Therefore, if the router does not assign non-link-local IPv6 prefixes on its tunnel interfaces, there is no opportunity for it to initiate the loop. If the router further ensures that the routing state is consistent for the packets it receives on its tunnel interfaces, there is no opportunity for it to propagate a loop initiated by a different router.
ループの攻撃は、ルータがそれがプレフィックスからのアドレスを設定していない他のルータにトンネルパケットを送信する可能性があり、そのトンネルインターフェイス上の非リンクローカルIPv6プレフィックスを割り当てることが許可されたという事実を利用します。ルータがトンネルインターフェイス上の非リンクローカルIPv6プレフィックスを割り当てていない場合、したがって、それはループを開始するための機会は存在しません。ルータはさらにルーティング状態は、そのトンネルインターフェイスで受信するパケットのために一貫していることを保証する場合、それは別のルータによって開始されたループを伝播するための機会は存在しません。
This mitigation measure is available only to ISATAP routers, since the ISATAP stateless address mapping operates only on the Interface Identifier portion of the IPv6 address, and not on the IPv6 prefix. This measure is also only applicable on ISATAP links on which IPv4 source address spoofing is disabled. Finally, the measure is only applicable on ISATAP links on which nodes support the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. The following sections discuss the operational configurations necessary to implement the measure.
ISATAPステートレスアドレスマッピングのみ、IPv6アドレスのインタフェース識別子部分ではなく、IPv6プレフィックスで動作するので、この緩和措置は、唯一ISATAPルータに利用可能です。この措置は、IPv4送信元アドレスのスプーフィングを無効にしているISATAPリンクにものみ適用されます。最後に、測定値は、ISATAPリンクにのみ適用可能でIPv6（DHCPv6の）[RFC3315]のための動的ホスト構成プロトコルをサポートするノード。次のセクションでは、対策を実施するために必要な動作構成を議論します。
ISATAP provides a Potential Router List (PRL) to further ensure a loop-free topology. Routers that are members of the PRL for the site configure their site-facing ISATAP interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2), and therefore may send Router Advertisement (RA) messages that include non-zero Router Lifetimes. Routers that are not members of the PRL for the site configure their site-facing ISATAP interfaces as non-advertising router interfaces.
ISATAPは、さらにループのないトポロジを保証するために、潜在的なルータリスト（PRL）を提供します。したがって、（[RFC4861]、セクション6.2.2を参照）広告ルータインターフェイスとして自分のサイトに面したISATAPインターフェイスを設定サイトのPRLのメンバー、であり、ルータは非ゼロルータの有効期限が含まれ、ルータ広告（RA）メッセージを送信することができ。サイトのPRLのメンバーではないルータは、非広告ルータインターフェイスとして自分のサイトに面したISATAPインターフェイスを設定します。
ISATAP nodes employ the source address verification checks specified in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of packets received on an ISATAP interface. To enable the on-link prefix avoidance procedures outlined in this section, ISATAP nodes must employ an additional source address verification check; namely, the node also considers the outer IPv4 source address correct for the inner IPv6 source address if:
ISATAPノードはISATAPインターフェイス上で受信されたパケットをデカプセル化するための前提条件として、[RFC5214]のセクション7.3で指定されたソースアドレス検証チェックを採用しています。このセクションで概説オンリンクプレフィックス回避手順を可能にするために、ISATAPノードは追加のソースアドレス検証チェックを使用しなければなりません。すなわち、ノードは、もし内部IPv6ソースアドレスの正しい外側のIPv4ソースアドレスを考慮する。
o a forwarding table entry exists that lists the packet's IPv4 source address as the link-layer address corresponding to the inner IPv6 source address via the ISATAP interface.
O転送テーブルエントリは、ISATAPインタフェースを介してインナーIPv6ソースアドレスに対応するリンク層アドレスとしてパケットのIPv4ソースアドレスを示していますが存在します。
ISATAP hosts send Router Solicitation (RS) messages to obtain RA messages from an advertising ISATAP router as specified in [RFC4861] and [RFC5214]. When stateful address autoconfiguration services are available, the host can acquire IPv6 addresses using DHCPv6 [RFC3315].
ISATAPホストは、[RFC4861]と[RFC5214]で指定された広告ISATAPルータからRAメッセージを得るために、ルータ要請（RS）メッセージを送信します。ステートフルアドレス自動設定サービスが利用可能な場合、ホストは、DHCPv6の[RFC3315]を使用してIPv6アドレスを取得することができます。
To acquire addresses, the host performs standard DHCPv6 exchanges while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to the IPv4 address of the advertising router. The host should also use DHCPv6 Authentication in environments where authentication of the DHCPv6 exchanges is required.
広告ルータのIPv4アドレスにIPv6の「All_DHCP_Relay_Agents_and_Servers」リンクスコープのマルチキャストアドレスをマッピングしながら、アドレスを取得するには、ホストは、標準のDHCPv6交換を行います。ホストは、DHCPv6の交換の認証が必要な環境でDHCPv6の認証を使用する必要があります。
After the host receives IPv6 addresses, it assigns them to its ISATAP interface and forwards any of its outbound IPv6 packets via the advertising router as a default router. The advertising router in turn maintains IPv6 forwarding table entries that list the IPv4 address of the host as the link-layer address of the delegated IPv6 addresses.
ホストがIPv6アドレスを受信した後、そのISATAPインターフェイスに割り当てて、デフォルトルータとして広告ルータを経由してその発信IPv6パケットのいずれかを転送します。順番に広告ルータは、委任されたIPv6アドレスのリンク層アドレスとホストのIPv4アドレスをリストのIPv6フォワーディングテーブルエントリを維持します。
In many use case scenarios (e.g., enterprise networks, Mobile Ad Hoc Networks (MANETs), etc.), advertising and non-advertising ISATAP routers can engage in a proactive dynamic IPv6 routing protocol (e.g., OSPFv3, the Routing Information Protocol Next Generation (RIPng), etc.) over their ISATAP interfaces so that IPv6 routing/ forwarding tables can be populated and standard IPv6 forwarding between ISATAP routers can be used. In other scenarios (e.g., large enterprise networks, etc.), this might be impractical due to scaling issues. When a proactive dynamic routing protocol cannot be used, non-advertising ISATAP routers send RS messages to obtain RA messages from an advertising ISATAP router; i.e., they act as "hosts" on their non-advertising ISATAP interfaces.
多くのユース・ケース・シナリオ（例えば、企業ネットワーク、モバイルアドホックネットワーク（MANET）、等）において、広告および非広告ISATAPルータは、積極的な動的IPv6ルーティングプロトコル（例えば、OSPFv3の、ルーティング情報プロトコル次世代に係合することができます（RIPngの）、等）、それらのISATAPインターフェイス上のIPv6ルーティング/転送テーブルをポピュレートすることができ、ISATAPルータ間の標準IPv6転送を使用することができるようになっています。他のシナリオ（例えば、大規模な企業ネットワーク、等）において、これは、スケーリングの問題のため実用的でないかもしれません。積極的なダイナミックルーティングプロトコルを使用することができない場合は、非広告のISATAPルーターは、広告ISATAPルータからRAメッセージを得るために、RSメッセージを送信します。すなわち、彼らは非広告のISATAPインターフェイスの「ホスト」として機能します。
Non-advertising ISATAP routers can also acquire IPv6 prefixes, e.g., through the use of DHCPv6 Prefix Delegation [RFC3633] via an advertising router in the same fashion as described above for host-based DHCPv6 stateful address autoconfiguration. The advertising router in turn maintains IPv6 forwarding table entries that list the IPv4 address of the non-advertising router as the link-layer address of the next hop toward the delegated IPv6 prefixes.
ホストベースのDHCPv6ステートフルアドレス自動設定について上述したように、非広告ISATAPルータは、同じ方法で広告ルータを介して、DHCPv6のプレフィックス委譲[RFC3633]を使用することによって、例えば、IPv6プレフィックスを取得することができます。順番に広告ルータは、委任されたIPv6プレフィックスに向けた次のホップのリンク層アドレスなどの非広告ルータのIPv4アドレスをリストのIPv6フォワーディングテーブルエントリを維持します。
After the non-advertising router acquires IPv6 prefixes, it can sub-delegate them to routers and links within its attached IPv6 edge networks, then can forward any outbound IPv6 packets coming from its edge networks via other ISATAP nodes on the link.
非広告ルータがIPv6プレフィックスを取得した後、それはルータとその付属のIPv6エッジネットワーク内のリンクにそれらをサブ委任することができ、その後、リンク上の他のISATAPノードを介してそのエッジネットワークからのすべてのアウトバウンドIPv6パケットを転送することができます。
Figure 2 depicts a reference ISATAP network topology for operational avoidance of on-link non-link-local IPv6 prefixes. The scenario shows two advertising ISATAP routers ('A', 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration:
図2は、オンリンク非リンクローカルIPv6プレフィックスの動作回避のための基準ISATAPネットワークトポロジを示しています。シナリオは、（ 'A'、 'B'）、二つの非広告ISATAPルータ（ 'C'、 'E'）、ISATAPホスト（ 'G'）と、3つの通常のIPv6ホスト（ 'D 2台の広告ISATAPルータを示します典型的な配置構成において」、 'F'、 'H'）：
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host H |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | / fe80::*192.0.2.5
: | (ISATAP) | | (ISATAP) | ; 2001:db8:2::1
+ +------------+ +------------+ \ +--------------+
; fe80::*192.0.2.1 fe80::*192.0.2.2 : | (ISATAP) |
| ; | Host G |
: IPv4 Site -+-' +--------------+
`-. (PRL: 192.0.2.1, 192.0.2.2) .)
\ _)
`-----+--------)----+'----'
fe80::*192.0.2.3 fe80::*192.0.2.4 .-.
+--------------+ +--------------+ ,-( _)-.
| (ISATAP) | | (ISATAP) | .-(_ IPv6 )-.
| Router C | | Router E |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | IPv6 Host F |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host D |
`-(______)-' +-------------+
(* == "5efe:")
（* == "5EFE："）
Figure 2: Reference ISATAP Network Topology
図2：リファレンスISATAPネットワークトポロジ
In Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet, either directly or via a companion gateway. 'A' configures a provider network IPv4 interface with address 192.0.2.1 and arranges to add the address to the provider network PRL. 'A' next configures an advertising ISATAP router interface with link-local IPv6 address fe80::5efe:192.0.2.1 over the IPv4 interface. In the same fashion, 'B' configures the IPv4 interface address 192.0.2.2, adds the address to the PRL, then configures the IPv6 ISATAP interface link-local address fe80::5efe:192.0.2.2.
図2では、IPv4のサイト内の広告ISATAPルータ「A」および「B」は、直接またはコンパニオン・ゲートウェイを介して、IPv6インターネットに接続します。 「A」は、アドレス192.0.2.1とプロバイダネットワークのIPv4インターフェイスを設定し、プロバイダネットワークPRLにアドレスを追加するために配置します。 IPv4インタフェース経由192.0.2.1：「A」は次のリンクローカルIPv6アドレスFE80 :: 5EFEと広告ISATAPルータインターフェイスを設定します。 192.0.2.2：同じやり方では、「B」は、IPv4のインタフェースアドレス192.0.2.2を設定PRLにアドレスを追加し、その後、IPv6のISATAPインターフェイスのリンクローカルアドレスFE80 :: 5EFEを設定します。
Non-advertising ISATAP router 'C' connects to one or more IPv6 edge networks and also connects to the site via an IPv4 interface with address 192.0.2.3, but it does not add the IPv4 address to the site's PRL. 'C' next configures a non-advertising ISATAP router interface with link-local address fe80::5efe:192.0.2.3, then receives the IPv6 prefix 2001:db8:0::/48 through a DHCPv6 prefix delegation exchange via one of 'A' or 'B'. 'C' then engages in an IPv6 routing protocol over its ISATAP interface and announces the delegated IPv6 prefix. 'C' finally sub-delegates the prefix to its attached edge networks, where IPv6 host 'D' autoconfigures the address 2001:db8:0::1.
非広告ISATAPルーター「C」は一の以上のIPv6エッジネットワークに接続し、また、アドレス192.0.2.3をIPv4インタフェースを経由してサイトに接続し、それは、サイトのPRLにIPv4アドレスを追加しません。 「C」は次のリンクローカルアドレスFE80と非広告ISATAPルータインターフェイスを設定します:: 5EFE： "のうちの1つを介してDHCPv6のプレフィックス委譲交換により0 :: / 48：DB8：192.0.2.3は、その後、IPv6プレフィックス2001を受け取りますA」または 'B'。 「C」は、そのISATAPインタフェースを介してIPv6ルーティングプロトコルに係合し、委任IPv6プレフィックスを発表します。 「C」最後にサブ委譲IPv6ホスト「D」はアドレス自動構成2001の取り付けエッジネットワークのプレフィックス：DB8：0 :: 1。
Non-advertising ISATAP router 'E' connects to the site, configures its ISATAP interface, receives a DHCPv6 prefix delegation, and engages in the IPv6 routing protocol the same as for router 'C'. In particular, 'E' configures the IPv4 address 192.0.2.4, the ISATAP link-local address fe80::5efe:192.0.2.4, and the delegated IPv6 prefix 2001:db8:1::/48. 'E' finally sub-delegates the prefix to its attached edge networks, where IPv6 host 'F' autoconfigures IPv6 address 2001:db8:1::1.
非広告ISATAPルーター「E」は、サイトに接続し、そのISATAPインターフェイスを設定し、DHCPv6のプレフィックス委任を受けて、IPv6ルーティングプロトコルルータ「C」の場合と同じに取り組んでいます。 192.0.2.4、および委任IPv6プレフィックス2001：DB8：1 :: / 48具体的には、 'E' は、IPv4アドレス192.0.2.4、ISATAPリンクローカルアドレスFE80 :: 5EFEを設定します。 「E」最後にサブ代議員その付属エッジネットワークのプレフィックス、IPv6のホスト「F」自動構成IPv6アドレス2001：DB8：1 :: 1。
ISATAP host 'G' connects to the site via an IPv4 interface with address 192.0.2.5, and also configures an ISATAP host interface with link-local address fe80::5efe:192.0.2.5 over the IPv4 interface. 'G' next configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.2 via the ISATAP interface, then receives the IPv6 address 2001:db8:2::1 from a DHCPv6 address configuration exchange via 'B'. When 'G' receives the IPv6 address, it assigns the address to the ISATAP interface but does not assign a non-link-local IPv6 prefix to the interface.
ISATAPホスト「G」はアドレス192.0.2.5を持つIPv4インタフェースを経由してサイトに接続し、また、リンクローカルアドレスFE80 :: 5EFEとISATAPホストインタフェース設定します。IPv4インタフェースの上に192.0.2.5を。 「B」を介してDHCPv6のアドレス設定交換から2 :: 1：DB8：次に、IPv6アドレス2001受け取り、ISATAPインタフェースを介して192.0.2.2：「G」は、次のデフォルトのIPv6ネクストホップアドレスFE80 :: 5EFEのルートを設定します。 「G」は、IPv6アドレスを受信すると、ISATAPインタフェースにアドレスを割り当てるが、インターフェースに非リンクローカルIPv6プレフィックスを割り当てません。
Finally, IPv6 host 'H' connects to an IPv6 network outside of the ISATAP domain. 'H' configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the IPv6 address 2001:db8:3::1.
最後に、IPv6ホスト「H」はISATAPドメインの外側のIPv6ネットワークに接続します。 「H」は、それに接続IPv6リンクに特異的な様式で、そのIPv6インタフェースを構成し、IPv6アドレス自動構成2001：DB8：3 :: 1。
Following this autoconfiguration, when host 'D' has an IPv6 packet to send to host 'F', it prepares the packet with source address 2001:db8:0::1 and destination address 2001:db8:1::1, then sends the packet into the edge network where it will eventually be forwarded to router 'C'. 'C' then uses ISATAP encapsulation to forward the packet to router 'E', since it has discovered a route to 2001:db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP interface. Router 'E' finally forwards the packet to host 'F'.
、その後、送信1 :: 1：DB8：0 :: 1と宛先アドレス2001：DB8ホスト「D」が「F」をホストに送信するIPv6パケットを持っている場合、この自動設定に続き、それは送信元アドレス2001と、パケットを準備します最終的に「C」をルータに転送され、エッジネットワークにパケットを転送します。 「C」は、それが2001年までのルートを発見したので、「E」をルータにパケットを転送するISATAPカプセル化を使用する：DB8：1 :: / 48 ISATAPインタフェースを介して動的ルーティングを介して次のホップ「E」を有します。ルータのE 'は最終的には「F」をホストするためにパケットを転送します。
In a second scenario, when 'D' has a packet to send to ISATAP host 'G', it prepares the packet with source address 2001:db8:0::1 and destination address 2001:db8:2::1, then sends the packet into the edge network where it will eventually be forwarded to router 'C' the same as above. 'C' then uses ISATAP encapsulation to forward the packet to router 'A' (i.e., a router that advertises "default"), which in turn forwards the packet to 'G'. Note that this operation entails two hops across the ISATAP link (i.e., one from 'C' to 'A', and a second from 'A' to 'G'). If 'G' also participates in the dynamic IPv6 routing protocol, however, 'C' could instead forward the packet directly to 'G' without involving 'A'.
DB8：0 :: 1及び宛先アドレス2001：「D」はISATAPホストに送信するパケット「G」を有する第2のシナリオでは、送信元アドレス2001とのパケットを準備DB8：2 :: 1は、次に送信します最終的に上記と同様の「C」をルータに転送され、エッジネットワークにパケットを転送します。 「C」は、今度は「G」にパケットを転送「A」（「デフォルト」をアドバタイズすなわち、ルータ）を、ルータにパケットを転送するISATAPカプセル化を使用します。この操作はISATAPリンクを介して2つのホップを伴うことに注意してください（すなわち、「A」に「C」、及び「G」を「A」から第二から1）。 「G」は動的IPv6ルーティングプロトコルに参加する場合は、しかし、「C」が代わりに「A」を介さずに「G」に直接パケットを転送することができました。
In a third scenario, when 'D' has a packet to send to host 'H' in the IPv6 Internet, the packet is forwarded to 'C' the same as above. 'C' then forwards the packet to 'A', which forwards the packet into the IPv6 Internet.
「D」は、IPv6インターネットに「H」をホストに送信するパケットを有する場合に第3のシナリオでは、パケットは、上記と同じ「C」に転送されます。 「C」は、IPv6インターネットへパケットを転送する、「A」にパケットを転送します。
In a final scenario, when 'G' has a packet to send to host 'H' in the IPv6 Internet, the packet is forwarded directly to 'B', which forwards the packet into the IPv6 Internet.
「G」は、IPv6インターネットに「H」をホストに送信するパケットを有する場合、最終的なシナリオでは、パケットは、IPv6インターネットへパケットを転送する「B」に直接転送されます。
Figure 2 depicts an ISATAP network topology with only two advertising ISATAP routers within the provider network. In order to support larger numbers of non-advertising ISATAP routers and ISATAP hosts, the provider network can deploy more advertising ISATAP routers to support load balancing and generally shortest-path routing.
図2は、プロバイダ・ネットワーク内の2つのだけの広告ISATAPルータとISATAPネットワークトポロジーを示します。非広告ISATAPルーターとISATAPホストのより大きな数をサポートするために、プロバイダ・ネットワークは、負荷分散と一般最短パスルーティングをサポートするために、より多くの広告ISATAPルータを配備することができます。
Such an arrangement requires that the advertising ISATAP routers participate in an IPv6 routing protocol instance so that IPv6 address/prefix delegations can be mapped to the correct router. The routing protocol instance can be configured as either a full mesh topology involving all advertising ISATAP routers, or as a partial mesh topology with each advertising ISATAP router associating with one or more companion gateways. Each such companion gateway would in turn participate in a full mesh between all companion gateways.
このような構成は、IPv6アドレス/プレフィックス委譲が正しいルータにマッピングすることができるように、広告ISATAPルーターがIPv6ルーティングプロトコルインスタンスに参加することを要求します。ルーティングプロトコルのインスタンスは、すべての広告ISATAPルータを含むいずれかのフルメッシュトポロジとして、または1つ以上のコンパニオンゲートウェイと関連付ける各広告ISATAPルータと部分的メッシュトポロジとして構成することができます。それぞれのそのようなコンパニオンゲートウェイは、順番にすべてのコンパニオンゲートウェイ間のフルメッシュに参加します。
With respect to the reference operational scenario depicted in Figure 2, there will be many use cases in which a proactive dynamic IPv6 routing protocol cannot be used. For example, in large enterprise network deployments it would be impractical for all routers to engage in a common routing protocol instance, due to scaling considerations.
図2に示す基準動作シナリオに対して、積極的な動的IPv6ルーティングプロトコルが使用できない多くのユースケースが存在することになります。すべてのルータが共通のルーティングプロトコルインスタンスに従事するため、例えば、大企業のネットワーク展開では、スケーリングの考慮事項に起因非現実的であろう。
In those cases, an on-demand routing capability can be enabled in which ISATAP nodes send initial packets via an advertising ISATAP router and receive redirection messages back. For example, when a non-advertising ISATAP router 'B' has a packet to send to a host located behind non-advertising ISATAP router 'D', it can send the initial packets via advertising router 'A', which will return redirection messages to inform 'B' that 'D' is a better first hop. Protocol details for this ISATAP redirection are specified in [AERO].
ISATAPノードは広告ISATAPルーターを経由して、最初のパケットを送信し、バックリダイレクトメッセージを受信するような場合には、オンデマンドルーティング機能を有効にすることができます。非広告ISATAPルーター「B」は広告以外のISATAPルーター「D」の背後にあるホストに送信するパケットを持っている場合たとえば、それはリダイレクトメッセージを返すなる、広告ルータ「A」を経由して、最初のパケットを送信することができます「D」「B」を知らせるためには、より良い最初のホップです。このISATAPリダイレクションのためのプロトコルの詳細は[AERO]で指定されています。
Tunnel routers can use a source address check mitigation measure when they forward an IPv6 packet into a tunnel interface with an IPv6 source address that embeds one of the router's configured IPv4 addresses. Similarly, tunnel routers can use a destination address check mitigation measure when they receive an IPv6 packet on a tunnel interface with an IPv6 destination address that embeds one of the router's configured IPv4 addresses. These checks should correspond to both tunnels' IPv6 address formats, regardless of the type of tunnel the router employs.
それらはルータの構成IPv4アドレスのいずれかを埋め込むIPv6ソースアドレスとトンネルインターフェイスにIPv6パケットを転送する際、トンネルルータは、送信元アドレスチェック緩和対策を使用することができます。それらはルータの構成IPv4アドレスのいずれかを埋め込むIPv6宛先アドレスとトンネルインターフェイス上でIPv6パケットを受信したとき、同様に、トンネルルータは、宛先アドレスチェック緩和対策を使用することができます。これらのチェックは、ルータが使用するトンネルの種類に関係なく、両方のトンネルIPv6アドレス形式に対応しなければなりません。
For example, if tunnel router R1 (of any tunnel protocol) forwards a packet into a tunnel interface with an IPv6 source address that matches the 6to4 prefix 2002:IP1::/48, the router discards the packet if IP1 is one of its own IPv4 addresses. In a second example, if tunnel router R2 receives an IPv6 packet on a tunnel interface with an IPv6 destination address with an off-link prefix but with an interface identifier that matches the ISATAP address suffix ::0200:5efe:IP2, the router discards the packet if IP2 is one of its own IPv4 addresses.
（任意トンネルプロトコル）トンネルルータR1 2002の6to4プリフィックス一致IPv6ソースアドレスとトンネルインターフェイスにパケットを転送する場合、例えば：IP1 :: / 48をIP1は、独自のものである場合、ルータはパケットを廃棄しますIPv4アドレス。第2の例では、トンネルルータR2は、オフリンクプレフィックスを持つIPv6宛先アドレスを持つトンネルインターフェース上ではなくISATAPアドレスのサフィックスと一致するインターフェイス識別子:: 0200とIPv6パケットを受信した場合：5EFE：IP2、ルータ廃棄IP2であれば、パケットは、自身のIPv4アドレスの一つです。
Hence, a tunnel router can avoid the attack by performing the following checks:
したがって、トンネルルータは、以下のチェックを実行することによって、攻撃を回避することができます。
o When the router forwards an IPv6 packet into a tunnel interface, it discards the packet if the IPv6 source address has an off-link prefix but embeds one of the router's configured IPv4 addresses.
ルーターは、トンネルインターフェイスにIPv6パケットを転送するときにIPv6ソースアドレスがオフリンク・プレフィックスを有するが、ルータの設定されたIPv4アドレスのいずれかを埋め込む場合、O、それはパケットを廃棄します。
o When the router receives an IPv6 packet on a tunnel interface, it discards the packet if the IPv6 destination address has an off-link prefix but embeds one of the router's configured IPv4 addresses.
ルーターは、トンネルインターフェイス上でIPv6パケットを受信した場合にIPv6宛先アドレスがオフリンク・プレフィックスを有するが、ルータの設定されたIPv4アドレスのいずれかを埋め込む場合、O、それはパケットを廃棄します。
This approach has the advantage that no ancillary state is required, since checking is through static lookup in the lists of IPv4 and IPv6 addresses belonging to the router. However, this approach has some inherent limitations:
チェックはルータに属するIPv4アドレスとIPv6アドレスのリストに静的な検索を介してであるため、このアプローチは、何の補助的な状態が必要とされないという利点があります。しかし、このアプローチはいくつかの固有の制限があります。
o The checks incur an overhead that is proportional to the number of IPv4 addresses assigned to the router. If a router is assigned many addresses, the additional processing overhead for each packet may be considerable. Note that an unmitigated attack packet would be repetitively processed by the router until the Hop Limit expires, which may require as many as 255 iterations. Hence, an unmitigated attack will consume far more aggregate processing overhead than per-packet address checks even if the router assigns a large number of addresses.
チェックoをルータに割り当てられたIPv4アドレスの数に比例したオーバーヘッドを被ります。ルータは多くのアドレスが割り当てられている場合、各パケットのための追加の処理オーバーヘッドがかなりあってもよいです。できるだけ多く255回の繰り返しが必要な場合がありますされ、ホップ制限の有効期限が切れるまで、紛れもない攻撃パケットを繰り返しルータによって処理されることに注意してください。したがって、紛れもない攻撃は、ルータがアドレスの大きい番号を割り当てても、パケットごとのアドレスチェックよりもはるかに集約処理のオーバーヘッドを消費します。
o The checks should be performed for the IPv6 address formats of every existing automatic IPv6 tunnel protocol (that uses protocol-41 encapsulation). Hence, the checks must be updated as new protocols are defined.
チェックは、すべての既存の自動IPv6トンネルプロトコルのIPv6アドレス形式のために実行されるべきO（すなわち、使用するプロトコル-41カプセル）。新しいプロトコルが定義されているようしたがって、小切手を更新する必要があります。
o Before the checks can be performed, the format of the address must be recognized. There is no guarantee that this can be generally done. For example, one cannot determine if an IPv6 address is a 6rd one; hence, the router would need to be configured with a list of all applicable 6rd prefixes (which may be prohibitively large) in order to unambiguously apply the checks.
チェックを行うことができる前に、O、アドレスの形式が認識されなければなりません。これは、一般的に行うことができるという保証はありません。 IPv6アドレスが6rdものであれば、例えば、一方が決定することができません。したがって、ルータは、明確にチェックを適用するために（法外に大きくてもよい）、該当するすべての6rdプレフィックスのリストを設定する必要があります。
o The checks cannot be performed if the embedded IPv4 address is a private one [RFC1918], since it is ambiguous in scope. Namely, the private address may be legitimately allocated to another node in another routing region.
それはスコープで曖昧であるので、埋め込まれたIPv4アドレスは、プライベート1 [RFC1918]である場合、Oチェックを行うことができません。すなわち、プライベートアドレスが正当別のルーティング領域内の別のノードに割り当てることができます。
The last limitation may be relieved if the router has some information that allows it to unambiguously determine the scope of the address. The check in the following subsection is one example for this.
ルータは、それが明確にアドレスの範囲を決定することを可能にするいくつかの情報を持っている場合、最後の制約を緩和することができます。以下のサブセクションのチェックは、このための一例です。
A router may be configured with the full list of IPv6 subnet prefixes assigned to the tunnels attached to its current IPv4 routing region. In such a case, it can use the list to determine when static destination and source address checks are possible. By keeping track of the list of IPv6 prefixes assigned to the tunnels in the IPv4 routing region, a router can perform the following checks on an address that embeds a private IPv4 address:
ルータは、現在のIPv4ルーティング領域に取り付けられたトンネルに割り当てられたIPv6サブネット・プレフィックスの完全なリストを構成することができます。このような場合には、静的宛先と送信元アドレスチェックが可能であるときを決定するためにリストを使用できます。 IPv4ルーティング領域内のトンネルに割り当てられたIPv6プレフィックスのリストを追跡することにより、ルータは、プライベートIPv4アドレスを埋め込むアドレスに次のチェックを実行できます。
o When the router forwards an IPv6 packet into its tunnel with a source address that embeds a private IPv4 address and matches an IPv6 prefix in the prefix list, it determines whether the packet should be discarded or forwarded by performing the source address check specified in Section 3.3.
ルータは、プライベートIPv4アドレスを埋め込み、プレフィックスリストのIPv6プレフィックスに一致するソースアドレスとのトンネルにIPv6パケットを転送する場合、O、それはパケットがセクションで指定された送信元アドレスのチェックを行うことにより、廃棄されるか、または転送されるべきか否かを判断します3.3。
o When the router receives an IPv6 packet on its tunnel interface with a destination address that embeds a private IPv4 address and matches an IPv6 prefix in the prefix list, it determines whether the packet should be discarded or forwarded by performing the destination address check specified in Section 3.3.
ルータは、プライベートIPv4アドレスを埋め込み、プレフィックスリストのIPv6プレフィクスと一致する宛先アドレスとのトンネルインターフェイス上でIPv6パケットを受信すると、O、それは、パケットがで指定された宛先アドレスチェックを行うことにより、廃棄されるか、または転送されるべきか否かを判断します3.3節。
The disadvantage of this approach is that the administrative overhead for maintaining the list of IPv6 subnet prefixes associated with an IPv4 routing region may become unwieldy should that list be long and/or frequently updated.
このアプローチの欠点は、IPv4ルーティング領域に関連付けられたIPv6サブネット・プレフィックスのリストを維持するための管理オーバーヘッドが扱いにくくなることがあり、そのリストは、長いおよび/または頻繁に更新しなければならないということです。
In light of the mitigation measures proposed above, we make the following recommendations in decreasing order of importance:
上記で提案緩和策の光の中で、我々は、重要度の高い順に以下の提言を行います。
1. When possible, it is recommended that the attacks be operationally eliminated (as per the measures proposed in Section 3.2).
1.可能な場合、（セクション3.2で提案された方策に従って）攻撃が動作可能に排除することが推奨されます。
2. For tunnel routers that keep a coherent and trusted neighbor cache that includes all legitimate endpoints of the tunnel, we recommend exercising the neighbor cache check.
2.トンネルのすべての合法的な端点を含むコヒーレント、信頼近隣キャッシュを維持するトンネルルータの場合、我々は、近隣キャッシュのチェックを行使することをお勧めします。
3. For tunnel routers that can implement the Neighbor Reachability Check, we recommend exercising it.
3.ネイバー到達可能性チェックを実装することができトンネルルータの場合、我々はそれを行使することをお勧めします。
4. For tunnels having a small and static list of endpoints, we recommend exercising the known IPv4 address check.
4.エンドポイントの小さなおよび静的リストを持つトンネルのために、我々は知られているIPv4アドレスのチェックを行使することをお勧めします。
5. We generally do not recommend using the destination and source address checks, since they cannot mitigate routing loops with 6rd routers. Therefore, these checks should not be used alone unless there is operational assurance that other measures are exercised to prevent routing loops with 6rd routers.
5.私たちは、一般的に、彼らは6rdルータとルーティングループを軽減することができないため、送信先と送信元アドレスチェックを使用することはお勧めしません。他の手段が6rdルータとルーティングのループを防ぐために行使されていること動作保証がない限り、そのため、これらのチェックは、単独で使用されるべきではありません。
As noted earlier, tunnels may be deployed in various operational environments. There is a possibility that other mitigation measures may be feasible in specific deployment scenarios. The above recommendations are general and do not attempt to cover such scenarios.
先に述べたように、トンネルは、様々な運用環境に展開することができます。他の緩和策は、特定の展開シナリオに実現可能であるという可能性があります。上記の推奨事項は、一般的であり、そのようなシナリオをカバーしようとしないでください。
This document aims at presenting possible solutions to the routing loop attack that involves automatic tunnels' routers. It contains various checks that aim to recognize and drop specific packets that have strong potential to cause a routing loop. These checks do not introduce new security threats.
この文書では、自動トンネルルーターを必要とするルーティングループ攻撃に可能な解決策を提示することを目指しています。それは認識し、ルーティングループが発生する強い可能性を持っている特定のパケットをドロップすることを目指してさまざまなチェックが含まれています。これらのチェックは、新たなセキュリティ上の脅威を導入していません。
This work has benefited from discussions on the V6OPS, 6MAN, and SECDIR mailing lists. The document has further benefited from comments received from members of the IESG during their review. Dmitry Anipko, Fred Baker, Stewart Bryant, Remi Despres, Adrian Farrell, Fernando Gont, Christian Huitema, Joel Jaeggli, and Dave Thaler are acknowledged for their contributions.
この作品はV6OPS、6MAN、およびSECDIRメーリングリスト上の議論の恩恵を受けています。文書には、さらに彼らのレビュー中にIESGのメンバーから寄せられたコメントの恩恵を受けています。ドミトリーAnipko、フレッド・ベイカー、スチュワートブライアント、レミ・デプレ、エイドリアン・ファレル、フェルナンドGont、クリスチャンのHuitema、ジョエルJaeggli、とDaveターラーは、彼らの貢献のために認められています。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、 "IPv4の基盤のIPv6のRapid Deployment（6rd） - プロトコル仕様"、RFC 5969、2010年8月。
[AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization (AERO)", Work in Progress, June 2011.
[AERO]テンプリン、F.、エド。、 "非対称拡張ルート最適化（AERO）"、進歩、2011年6月での作業。
[ISATAP-OPS] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Work in Progress, July 2011.
[ISATAP-OPS]テンプリン、F.、 "IPv4のサイトでのIPv6の展開のための運用ガイダンスISATAPを使用する"、進歩、2011年7月での作業。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]大工、B.、 "6to4の展開のための諮問ガイドライン"、RFC 6343、2011年8月。
[TEREDO-LOOPS] Gont, F., "Mitigating Teredo Rooting Loop Attacks", Work in Progress, September 2010.
[TEREDO-LOOPS] Gont、F.、 "問題を緩和する要素のTeredo発根ループ攻撃"、進歩、2010年9月での作業。
[USENIX09] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Tunnels", USENIX WOOT, August 2009.
[USENIX09] Nakibly、G.およびM. Arov、 "IPv6トンネルを使用してルーティングループ攻撃"、USENIX WOOT、2009年8月。
Authors' Addresses
著者のアドレス
Gabi Nakibly National EW Research & Simulation Center Rafael - Advanced Defense Systems P.O. Box 2250 (630) Haifa 31021 Israel
ガビNakibly国立EWリサーチ＆シミュレーションセンターラファエル - 高度な防衛システムの私書箱ボックス2250（630）ハイファ31021イスラエル
EMail: gnakibly@yahoo.com
メールアドレス：gnakibly@yahoo.com
Fred L. Templin Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッド・L.テンプリンボーイング・リサーチ＆テクノロジー私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: fltemplin@acm.org
メールアドレス：fltemplin@acm.org