--- 1/draft-ietf-v6ops-tunnel-loops-05.txt 2011-03-30 10:16:03.000000000 +0200 +++ 2/draft-ietf-v6ops-tunnel-loops-06.txt 2011-03-30 10:16:03.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group G. Nakibly Internet-Draft National EW Research & Intended status: Informational Simulation Center -Expires: September 15, 2011 F. Templin +Expires: October 1, 2011 F. Templin Boeing Research & Technology - March 14, 2011 + March 30, 2011 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-ietf-v6ops-tunnel-loops-05.txt + draft-ietf-v6ops-tunnel-loops-06.txt 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 which can be abused as a vehicle for traffic amplification to facilitate 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 @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 15, 2011. + This Internet-Draft will expire on October 1, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -51,150 +51,165 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 - 3.1. Verification of end point existence . . . . . . . . . . . 6 - 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6 - 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7 - 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7 + 3.1. Verification of end point existence . . . . . . . . . . . 7 + 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 7 + 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 8 + 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 8 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 - 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 8 + 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 9 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 - 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 9 + 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 10 3.3. Destination and Source Address Checks . . . . . . . . . . 15 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 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 non-link-local 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. Ref. [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 poses a denial of - service risk as inconsistency between the IPv4 routing state and the - IPv6 routing state allows a routing loop to be formed. + 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. - An attacker can exploit this vulnerability by crafting a packet which - is routed over a tunnel to a node that is not participating in that - tunnel. 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 that 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]. + The looping vulnerability can be triggered accidentally or exploited + maliciously by an attacker crafting a packet which 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 that 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]. 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 ISATAP [RFC5214], 6to4 [RFC3056] and 6rd [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 [I-D.gont-6man-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 network, enterprise network, etc. Specific issues related to the attack which are derived from the operational environment are not considered in this document. + 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 can not take + place (see Section 3.2). + 2. A Detailed Description of the Attack - In this section we shall denote an IPv6 address of a node reached via - a given tunnel by the prefix of the tunnel and an IPv4 address of the - tunnel end point, 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. + 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 end + point, 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. - The two victims of this attack are routers - R1 and R2 - of two - different tunnels - T1 and T2. 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. + 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 # - ####### - // \ - T1 // 2 \ 1 - interface // \ - _______________//_ __\________________ - | | | | - | IPv4 Network | | IPv6 Network | - |__________________| |___________________| - \\ / - \\ / - T2 \\ 2 / 0,1 - interface \\ / - ####### - # R2 # - ####### + [ 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 Figure 1: The network setting of the attack - The attack is depicted in Figure 2. It is initiated by sending an - IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point - that appears to be reached via T2 and has IP1 as its IPv4 address, - i.e., Addr(Prf2, IP1). The source address of the packet is a T1 - 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 T2. + The attack is depicted in Figure 2. It is initiated by an + accidentally or maliciously produced IPv6 packet (packet 0 in + Figure 2) destined to a fictitious end point 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. - We assume that R2 is the packet's entry point to T2. R2 receives the - packet through its IPv6 interface and forwards it over its T2 - interface encapsulated 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 2.) 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 T1. + 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 2) 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. 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 T1, R1 will forward the packet onto a native IPv6 + is outside of Prf1, R1 will forward the packet onto a native IPv6 interface. The forwarded packet (packet 2 in Figure 2) 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 native IPv6 network. R1 may be connected to the IPv6 network through another tunnel. R1 R2 | | 0 | 1 |<------ |<===============| @@ -205,43 +220,43 @@ 1 - IPv4: IP2 --> IP1 IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) Legend: ====> - tunneled IPv6, ---> - native IPv6 Figure 2: Routing loop attack between two tunnels' routers The crux of the attack is as follows. The attacker exploits the fact - that R2 does not know that R1 does not take part of T2 and that R1 - does not know that R2 does not take part of T1. 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 can not 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 routes. + 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 can not + 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 routes. 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 path from R1 and R2. Therefore, the number + number of IPv6 routers on path from R1 to R2. Therefore, the number of loops is inversely proportional to the number of IPv6 hops between R1 and R2. - The tunnel pair T1 and T2 may be any combination of automatic tunnel - types, e.g., ISATAP, 6to4 and 6rd. This has the exception that both - tunnels can not be of type 6to4, since two 6to4 routers can not - belong to different tunnels (there is only one 6to4 tunnel 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. + 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 can not 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. 3. Proposed Mitigation Measures This section presents some possible mitigation measures for the attack described above. For each measure we shall discuss its advantages and disadvantages. The proposed measures fall under the following three categories: o Verification of end point existence @@ -624,21 +637,21 @@ due to scaling considerations. 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 - [I-D.templin-intarea-vet]. + [I-D.templin-aero]. 3.3. Destination and Source Address Checks Tunnel routers can use a source address check mitigation 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 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 @@ -660,24 +673,24 @@ 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 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. - This approach has the advantage that 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 + 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 o The checks incur an overhead which 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. @@ -771,23 +784,25 @@ This document aims at presenting possible solutions to the routing loop attack which 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. 7. Acknowledgments This work has benefited from discussions on the V6OPS, 6MAN and - SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry - Anipko, Dave Thaler and Fernando Gont are acknowledged for their - contributions. + SECDIR mailing lists. The document has further benefitted 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. 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains @@ -816,24 +831,24 @@ Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 8.2. Informative References [I-D.gont-6man-teredo-loops] Gont, F., "Mitigating Teredo Rooting Loop Attacks", draft-gont-6man-teredo-loops-00 (work in progress), September 2010. - [I-D.templin-intarea-vet] - Templin, F., "Virtual Enterprise Traversal (VET)", - draft-templin-intarea-vet-23 (work in progress), - January 2011. + [I-D.templin-aero] + Templin, F., "Asymmetric Extended Route Optimization + (AERO)", draft-templin-aero-00 (work in progress), + March 2011. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [USENIX09] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6