[要約] 要約： RFC 6324は、IPv6自動トンネルを使用したルーティングループ攻撃の問題と提案された対策について説明しています。目的： このRFCの目的は、IPv6自動トンネルを使用したルーティングループ攻撃の問題を明確にし、その対策を提案することです。
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
IPv6自動トンネルを使用したルーティングループ攻撃：問題のステートメントと提案された緩和
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-in-IPV4自動トンネルのセキュリティの脆弱性に関係しています。これらの脆弱性により、攻撃者はIPv4ルーティング状態とIPv6ルーティング状態の間の矛盾を活用することができます。攻撃は、サービス拒否（DOS）攻撃を容易にするための交通増幅の手段として乱用できるルーティングループを形成します。この文書の最初の目的は、この攻撃とその根本原因について通知することです。2番目の目的は、いくつかの可能な緩和策を提示することです。この執筆時点では、これらの脆弱性を活用している悪意のある攻撃に関する既知の報告はないことに注意する必要があります。それにもかかわらず、これらの脆弱性は偶発的な誤解によって活性化することができます。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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-in-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自動トンネルは、このような攻撃に対して脆弱です。および6RD（IPv4インフラストラクチャのIPv6迅速な展開）[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.
このセクションでは、トンネルに割り当てられたIPv6プレフィックスによってノードのIPv6アドレスと、トンネルエンドポイントのIPv4アドレス、つまりADDR（Prefix、IPv4）を示します。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.
この攻撃の2人の犠牲者は、Router（R1とR2）が2つの異なるトンネルプレフィックス（PRF1とPRF2）にサービスを提供しています。両方のルーターには、それぞれのトンネルからIPv6パケットを内外に転送する機能があります。2つのトンネルは、同じトンネルプロトコルに基づいている必要はありません。唯一の条件は、2つのトンネルプロトコルがプロトコル-41カプセル化に基づいていることです。R1のIPv4アドレスはIP1ですが、トンネルのプレフィックスはPRF1です。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を介して到達し、IP1アドレス、つまりADDR（PRF2、IP1）としてIP1を搭載していると思われる架空のエンドポイントに運命づけられた偶然または悪意のあるIPv6パケット（図1のパケット0）によって開始されます。パケットのソースアドレスは、PRF1をプレフィックスとして、IP2を埋め込みIPv4アドレス、つまりaddr（PRF1、IP2）としてIP2を持つアドレスです。宛先アドレスのプレフィックスはPRF2であるため、パケットはIPv6ネットワークを介してR2にルーティングされます。
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宛先、つまりIP1から派生した宛先アドレスを持つIPv4ヘッダーを使用してトンネルに転送します。ソースアドレスは、R2のアドレス、つまりIP2です。パケット（図1のパケット1）は、IPv4ネットワークを介してR1にルーティングされ、IPv4インターフェイスでパケットを受信します。PRF1の最終ノードの1つから発生するパケットとしてパケットを処理します。
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からアドレスを構成しないことを知らないことをR2が知らないという事実を活用しています。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ルーターの数だけ減少します。したがって、ループの数は、R1とR2の間のIPv6ホップの数に反比例します。
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
R1とR2で使用されるトンネルは、自動トンネルタイプ、例えばISATAP、6TO4、6RDの任意の組み合わせである場合があります。これには、2つの6to4ルーターが同じIPv6プレフィックスを共有しているため、両方のトンネルをタイプ6to4にすることはできないという例外があります。たとえば、攻撃がある場合
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.
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.
ルーターがエンドホストが存在し、トンネルを介して到達できることを確認できる1つの方法は、対応するトンネルインターフェイスの近隣キャッシュに有効なエントリが存在するかどうかを確認することです。近隣キャッシュのエントリは、例えば、初期の到達可能性チェック、隣人ディスカバリーメッセージの受信、管理上の構成などを通じて入力できます。
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
ルーターに、近隣キャッシュエントリがない潜在的なトンネルホストに送信するパケットがある場合、[RFC5214]のセクション8.4の2番目の段落で指定されているように、パケットの宛先アドレスで初期到達可能性チェックを実行できます。。（ルーターは同様に、近隣キャッシュエントリがない潜在的なトンネルホストからパケットを受信したときにパケットのソースアドレスを「逆到達可能性」チェックを実行できます。）RFC4861]、つまり、ルーターは、到達可能性の確認が完了するのを待っているパケットの小さなキューを維持します。確認が成功した場合、ルーターは正当なトンネルが
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].
ホストはアドレスに応答します。それ以外の場合、ルーターは後続のパケットを破棄し、[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.
o ルーターが、オンリンクプレフィックスに一致し、IPv4アドレスIP1を埋め込む宛先アドレスを使用してIPv6パケットをトンネルインターフェイスに転送すると、IP1がIPv4アドレスの構成リストに属していない場合、パケットを破棄します。
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.
o トンネルのインターフェース上のルーターが、オンリンクプレフィックスと一致し、IPv4アドレスIP2を埋め込むソースアドレスを使用してトンネルのインターフェイスでIPv6パケットを受信すると、IP2がIPv4アドレスの構成リストに属していない場合、パケットを破棄します。
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ネットワークを複数のトンネル間の共有リンク層として持つことに依存しています。これから、次の2つの緩和策が生じます。
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
この測定では、トンネルルーターは、信頼されていないIPv4ネットワークに接続されているインターフェイス上で受信または送信されるすべてのIPv4プロトコル-41パケットをドロップする場合があります。これにより、共有リンクとしてIPv4ネットワークが遮断されます。この尺度には、シンプルさの利点があります。ただし、このような尺度は、すべてのインターフェイスでIPv4接続が不可欠であるシナリオに常に適しているとは限りません。最も顕著なのは、フィルタリングです
of IPv4 protocol-41 packets that belong to a 6to4 tunnel can have adverse effects on unsuspecting users [RFC6343].
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.
この測定値は、単一のIPv6トンネルが境界付きIPv4ネットワークで動作するだけで攻撃を軽減します。たとえば、ブロードバンドホームネットワークでは攻撃は行われません。そのような場合、トンネルルーターとして機能する単一の住宅用ゲートウェイを持つ小さなホームネットワークがあります。トンネルルーターは、インターネットへのパスを持つ少なくとも2つのインターフェイスがある場合にのみ、攻撃に対して脆弱です：トンネルインターフェイスとネイティブIPv6インターフェイス（図1に示すように）。ただし、住宅のゲートウェイには通常、インターネットへの単一のインターフェイスしかありません。したがって、攻撃は行われません。さらに、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パケットを受け入れるか、転送するものとすると想定することも合理的です。これらの2つのインターフェイスが物理的に異なる場合、ネットワークオペレーターは、次の条件が保持されるようにすることで攻撃を軽減できます。トンネルルーターを通過しないこれら2つのインターフェイスの間にパスはありません。
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.
このメジャーは、第6ボーダーリレーがISPのネットワーク内の他のトンネルのすべての既知のリレーアドレスをフィルターする[RFC5969]で第6回提案されたものと類似しています。
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や第6回などのサイト内トンネリングメカニズムに特に役立ちます。この緩和が適用される特定の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リンクにも適用できます。最後に、このメジャーは、IPv6（DHCPV6）[RFC3315]の動的ホスト構成プロトコルをサポートするISATAPリンクでのみ適用されます。次のセクションでは、測定を実装するために必要な運用構成について説明します。
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
ISATAPは、ループフリートポロジをさらに確保するための潜在的なルーターリスト（PRL）を提供します。サイトのPRLのメンバーであるルーターは、サイトに向かうISATAPインターフェイスを広告ルーターとして構成します
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.
インターフェイス（[rfc4861]、セクション6.2.2を参照）。したがって、ゼロ以外のルーターの寿命を含むルーター広告（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ノードは、[RFC5214]のセクション7.3で指定されたソースアドレス検証チェックを、ISATAPインターフェイスで受信したパケットの脱カプセル化の前提条件として使用します。このセクションで概説されているオンリンクプレフィックス回避手順を有効にするには、ISATAPノードが追加のソースアドレス検証チェックを使用する必要があります。つまり、ノードは、外側のIPv4ソースアドレスを内部IPv6ソースアドレスの正しいと見なします。
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）メッセージを送信します。ステートフルアドレスAutoconfiguration Servicesが利用可能になると、ホストは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.
アドレスを取得するために、ホストは標準のDHCPV6交換を実行し、IPv6 "ALL_DHCP_RELAY_AGENTS_AND_SERVERS"リンクスコープマルチキャストアドレスを広告ルーターのIPv4アドレスにマッピングします。また、ホストは、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
多くのユースケースシナリオ（例：エンタープライズネットワーク、モバイルアドホックネットワーク（MANETS）など）では、広告および非宣伝ISATAPルーターは、プロアクティブな動的なIPv6ルーティングプロトコル（例えば、ルーティング情報プロトコルの次世代のOSPFV3、
(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.
（RIPNG）など）ISATAPインターフェイス上でIPv6ルーティング/転送テーブルを入力できるようにし、ISATAPルーター間の標準IPv6転送を使用できます。他のシナリオ（大規模なエンタープライズネットワークなど）では、これはスケーリングの問題のために非現実的である可能性があります。プロアクティブなダイナミックルーティングプロトコルを使用できない場合、非広告ISATAPルーターはRSメッセージを送信して、広告ISATAPルーターからRAメッセージを取得します。すなわち、彼らは彼らの非広告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.
非広告ISATAPルーターは、例えば、DHCPV6プレフィックス委任[RFC3633]を使用して、ホストベースのDHCPV6ステートフルアドレスオートコンフィギュレーションについて上記と同じ方法で広告ルーターを介してDHCPV6プレフィックス委任[RFC3633]を使用することもできます。広告ルーターは、委任された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ネットワークトポロジを示しています。このシナリオでは、2つの広告ISATAPルーター（ 'A'、 'B'）、2つの非広告ISATAPルーター（ 'c'、 'e'）、ISATAPホスト（ 'g'）、および3つの通常のIPv6ホスト（ 'd'、' 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:")
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にアドレスを追加するように手配します。「A」は、IPv4インターフェイス上で、Link-Local IPv6アドレスFE80 :: 5EFE：192.0.2.1を使用して、Link-Local IPv6アドレスFE80を使用して広告ISATAPルーターインターフェイスを構成します。同じ方法で、「B」はIPv4インターフェイスアドレス192.0.2.2を構成し、PRLにアドレスを追加し、IPv6 ISATAPインターフェイスリンクローカルアドレスFE80 :: 5EFE：192.0.2.2を構成します。
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'は1つ以上のIPv6エッジネットワークに接続し、アドレス192.0.2.3を備えたIPv4インターフェイスを介してサイトに接続しますが、IPv4アドレスをサイトのPRLに追加しません。「C」次に、リンクローカルアドレスFE80 :: 5EFE：192.0.2.3を使用した非宣伝ISATAPルーターインターフェイスを構成し、その後、IPv6プレフィックス2001：dB8：0 ::/48を受信します。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プレフィックス委任を受信し、ルーター「C」と同じようにIPv6ルーティングプロトコルに従事します。特に、「E」はIPv4アドレス192.0.2.4、ISATAPリンクローカルアドレスFE80 :: 5EFE：192.0.2.4、および委任されたIPv6プレフィックス2001：db8：1 ::/48を構成します。'e'は最終的に接続されたエッジネットワークに接頭辞をサブディールします。ここで、IPv6ホスト 'f' autoconfigures 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インターフェイスを介してサイトに接続し、IPv4インターフェイス上でLink-LocalアドレスFE80 :: 5EFE：192.0.2.5を使用してISATAPホストインターフェイスを構成します。'g'次は、ネクストホップアドレスFE80を備えたデフォルトのIPv6ルートを構成します:: 5EFE：192.0.2.2 ISATAPインターフェイスを介して、「B」を介したDHCPV6アドレス構成交換からIPv6アドレス2001：db8：2 :: 1を受信します。。「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をAutoConfiguresで構成します。
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'.
このオートコンフィグレーションに続いて、ホスト「D」がホスト「F」に送信するIPv6パケットがある場合、ソースアドレス2001：db8：0 :: 1および宛先アドレス2001：db8：1 :: 1でパケットを準備します。パケットはエッジネットワークに移動し、最終的にはルーター「C」に転送されます。「C」は、ISATAPインターフェイスを介したダイナミックルーティングを介して次のホップ「E」で2001年へのルートを発見したため、ISATAPカプセル化を使用してパケットをルーター「E」に転送します。Router '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'.
同上。「C」は、ISATAPカプセル化を使用して、パケットをルーター「A」（つまり、「デフォルト」を宣伝するルーター）に転送し、パケットを「G」に転送します。この操作は、ISATAPリンク全体に2つのホップ（つまり、「C」から「A」から「A」から「G」から2つ目のホップを伴うことに注意してください。ただし、「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.
3番目のシナリオでは、「D」がIPv6インターネットで「H」をホストに送信するパケットがある場合、パケットは上記と同じ「C」に転送されます。「C」はパケットを「A」に転送し、パケットをIPv6インターネットに転送します。
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」をホストに送信するパケットがある場合、パケットは「B」に直接転送され、パケットがIPv6インターネットに転送されます。
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
そのような場合、ISATAPノードが広告ISATAPルーターを介して初期パケットを送信し、リダイレクトメッセージを返すために需要のあるルーティング機能を有効にすることができます。たとえば、非宣伝ISATAPルーター「B」に、非広告ISATAPルーター「D」の背後にあるホストに送信するパケットがある場合、送信できます。
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].
広告ルーター「A」を介した初期パケット。これにより、リダイレクトメッセージを返して、「b」が「d」がより良い最初のホップであることを通知します。この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アドレスの1つを埋め込むIPv6ソースアドレスを使用して、IPv6パケットをトンネルインターフェイスに転送するときに、ソースアドレスチェック緩和測定を使用できます。同様に、トンネルルーターは、ルーターの構成されたIPv4アドレスの1つを埋め込む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（任意のトンネルプロトコルの）が、6to4プレフィックス2002：IP1 ::/48に一致するIPv6ソースアドレスを持つトンネルインターフェイスにパケットを転送する場合、ルーターはIP1が独自の1つである場合、パケットを破棄しますIPv4アドレス。2番目の例では、トンネルルーターR2がトンネルインターフェイスでIPv6パケットを受信し、IPv6宛先アドレスをオフリンクプレフィックスとともに、ISATAPアドレスの接尾辞に一致するインターフェイス識別子を備えている場合、ルーターは捨てられます。IP2が独自のIPv4アドレスの1つである場合、パケット。
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.
o ルーターがIPv6パケットをトンネルインターフェイスに転送すると、IPv6ソースアドレスにオフリンクプレフィックスがあるが、ルーターの構成されたIPv4アドレスの1つを埋め込む場合、パケットを破棄します。
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.
o ルーターがトンネルインターフェイスでIPv6パケットを受信すると、IPv6宛先アドレスにオフリンクプレフィックスがあるが、ルーターの構成されたIPv4アドレスの1つを埋め込む場合、パケットを破棄します。
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:
このアプローチには、Routerに属する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
o チェックには、ルーターに割り当てられたIPv4アドレスの数に比例するオーバーヘッドが発生します。ルーターに多くのアドレスが割り当てられている場合、各パケットの追加処理オーバーヘッドはかなりの場合があります。ホップ制限までルーターによって繰り返し処理されることに注意してください
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.
有効期限が切れます。これには、最大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.
o チェックは、既存のすべての自動IPv6トンネルプロトコル（プロトコル-41カプセル化を使用）のIPv6アドレス形式で実行する必要があります。したがって、新しいプロトコルが定義されているため、チェックを更新する必要があります。
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アドレスが6番目のアドレスであるかどうかを判断することはできません。したがって、チェックを明確に適用するには、ルーターをすべての該当するすべての6番目のプレフィックス（非常に大きい場合がある）のリストで構成する必要があります。
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.
o 埋め込まれたIPv4アドレスがプライベートなアドレスである場合、チェックは実行できません[RFC1918]。つまり、プライベートアドレスは、別のルーティング領域の別のノードに合法的に割り当てられる場合があります。
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.
ルーターにアドレスの範囲を明確に決定できる情報がある場合、最後の制限が解放される場合があります。次のサブセクションのチェックは、この1つの例です。
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.
o ルーターがプライベートIPv4アドレスを埋め込み、プレフィックスリストにIPv6プレフィックスを一致させるソースアドレスでIPv6パケットをトンネルに転送すると、セクション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.
o ルーターがトンネルインターフェイスでIPv6パケットを受信し、プライベートIPv4アドレスを埋め込み、プレフィックスリストにIPv6プレフィックスを一致させる宛先アドレスを使用して、セクションで指定された宛先アドレスチェックを実行してパケットを破棄または転送するかどうかを判断します。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. 通常、宛先とソースアドレスのチェックを使用することはお勧めしません。これは、6番目のルーターを使用してルーティングループを軽減できないためです。したがって、これらのチェックは、第6ルーターを使用したルーティングループを防ぐために他の測定が行使されるという運用上の保証がない限り、単独で使用すべきではありません。
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のメンバーから受け取ったコメントからさらに恩恵を受けています。Dmitry Anipko、Fred Baker、Stewart Bryant、Remi Despres、Adrian Farrell、Fernando Gont、Christian Huitema、Joel Jaeggli、およびDave Thalerは、彼らの貢献が認められています。
[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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「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.、Simpson、W。、およびH. Soliman、「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] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（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、「IPv6インフラストラクチャのIPv6迅速な展開（6rd） - プロトコル仕様」、RFC 5969、2010年8月。
[AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization (AERO)", Work in Progress, June 2011.
[Aero] Templin、F.、ed。、「非対称拡張ルート最適化（AERO）」、2011年6月の作業。
[ISATAP-OPS] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Work in Progress, July 2011.
[ISATAP-OPS] Templin、F。、「ISATAPを使用したIPv4サイトでのIPv6展開の運用ガイダンス」、2011年7月の進行中。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、ed。、およびIAB、「インターネット拒否に関する考慮事項」、RFC 4732、2006年12月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343] Carpenter、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 Rooting Loop Attacksの緩和」、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
GABI NACIBLY NATIONAL EW Research＆Simulation Center Rafael -Advanced Defense Systems P.O.ボックス2250（630）ハイファ31021イスラエル
EMail: gnakibly@yahoo.com
Fred L. Templin Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリンボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: fltemplin@acm.org