--- 1/draft-ietf-v6ops-tunnel-loops-01.txt 2011-01-25 00:22:49.000000000 +0100 +++ 2/draft-ietf-v6ops-tunnel-loops-02.txt 2011-01-25 00:22:49.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group G. Nakibly Internet-Draft National EW Research & Intended status: Informational Simulation Center -Expires: May 13, 2011 F. Templin +Expires: July 28, 2011 F. Templin Boeing Research & Technology - November 9, 2010 + January 24, 2011 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-ietf-v6ops-tunnel-loops-01.txt + draft-ietf-v6ops-tunnel-loops-02.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,54 +29,53 @@ 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 May 13, 2011. + This Internet-Draft will expire on July 28, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. A Detailed Description of the Attack . . . . . . . . . . . . . 3 + 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 3.1. Destination and Source Address Checks . . . . . . . . . . 6 - 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 7 + 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 8 3.2. Verification of end point existence . . . . . . . . . . . 8 3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8 3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9 - 3.2.3. Neighbor Reachability Check . . . . . . . . . . . . . 9 - 3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 10 + 3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 9 3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10 3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 @@ -95,26 +94,31 @@ service risk as inconsistency between the IPv4 routing state and the IPv6 routing state allows a routing loop to be formed. 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. + 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 are vulnerable to - such an attack including ISATAP [RFC5214], 6to4 [RFC3056] and 6rd - [RFC5569]. + tunnels that are based on protocol-41 encapsulation [RFC4213] are + vulnerable to such an attack including ISATAP [RFC5214], 6to4 + [RFC3056] and 6rd [RFC5569]. 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. @@ -227,21 +231,21 @@ 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 two categories: + The proposed measures fall under the following three categories: o Destination and source addresses checks o Verification of end point existence o Operational measures 3.1. Destination and Source Address Checks Tunnel routers can use a source address check mitigation when they @@ -272,36 +276,43 @@ 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 inherit limitations: + 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. + 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 The checks should be performed for the IPv6 address formats of every existing automatic IPv6 tunnel protocol (which uses protocol-41 encapsulation). Hence, the checks must be updated as new protocols are defined. 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 can not determine if an IPv6 address is a - 6rd one, hence a configuration is needed at the router. + 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 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. 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. @@ -339,88 +350,67 @@ The routing loop attack relies on the fact that a router does not know whether there is an end point that can reached via its tunnel that has the source or destination address of the packet. This category includes mitigation measures which aim to verify that there is a node which participate in the tunnel and its address corresponds to the packet's destination or source addresses, as appropriate. 3.2.1. Neighbor Cache Check - One way to verify that an end point exists in a tunnel is by checking - whether a valid entry exists for it in the Neighbor Cache of the - corresponding tunnel interface. A valid entry may exist in the - Neighbor Cache for legitimate end hosts if they generate traffic - towards the router upon startup. For example, an initial RS/RA - exchange to facilitate Stateless Address Auto configuration (as in - the ISATAP case). This allows the router to keep valid Neighbor - Cache entry for each legitimate end host in the tunnel. - - By keeping track of the legitimate hosts in the tunnel via the - Neighbor Cache, a router can perform the following simple checks: - - o When the router forwards a packet into the tunnel with an IPv6 - destination address that matches an on-link prefix and that embeds - the IPv4 address IP1, it discards the packet if there is no - corresponding neighbor cache entry. + 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. - o When the router receives a packet on the tunnel's interface with - an IPv6 source address that matches an on-link prefix and that - embeds the IPv4 address IP2, it discards the packet if there is no - corresponding neighbor cache entry. + The neighbor cache entry can be populated through, e.g., an initial + reachability check, receipt of neighbor discovery messages, + administrative configuration, etc. - This approach is easy to implement, and naturally leverages the fact - that an end host must successively send RSs in order to refresh - configuration information as on-link prefix information. However, - this requires the router to retain entries for a duration that is at - least as long as the router's advertised prefix lifetimes. This may - require an implementation to adjust its garbage-collection interval - for stale neighbor cache entries. + 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 + subseqent packets and returns ICMP destination unreachable + indications as specified in Section 7.2.2 of [RFC4861]. - Finally, this approach assumes that the neighbor cache will remain + Note that this approach assumes that the neighbor cache will remain coherent and not 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 RS messages - with a spoofed source address. + attacker to subvert the neighbor cache is to send false neighbor + discovery messages with a spoofed source address. 3.2.2. Known IPv4 Address Check 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 that are authorized to use the tunnel. Upon this configuration the router can perform the following simple checks: 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 When the router receives an IPv6 packet on the tunnel's interface with a source address that matches a 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. -3.2.3. Neighbor Reachability Check - - Yet another approach that allows a router to verify that an end host - exists and can be reached via the tunnel is by performing an initial - reachability confirmation, e.g., as specified in the second paragraph - of Section 8.4 of [RFC5214]. This procedure 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 neighbor responds to the address and - packets may be forwarded to it. Otherwise, the router returns ICMP - destination unreachable indications as specified in Section 7.2.2 of - [RFC4861]. - 3.3. Operational Measures The following measures can be taken by the network operator. Their aim is to configure the network in such a way that the attacks can not take place. 3.3.1. Avoiding a Shared IPv4 Link As noted above, the attack relies on having an IPv4 network as a shared link-layer between more than one tunnel. From this the @@ -431,25 +421,31 @@ 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. 3.3.1.2. Operational Avoidance of Multiple Tunnels This measure mitigates the attack by simply allowing for a single - IPv6 tunnel to operate in a bounded IPv4 network (e.g., a small home - IPv4 network behind a residential gateway serving as a tunnel - router). In particular, 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 tunnel to operate in a bounded IPv4 network. For example, the + attack can not take place in broadband home networks. In such cases + there is a small home network having a single residential gateway + which 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 can not 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. 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. 3.3.2. A Single Border Router It is reasonable to assume that a tunnel router shall accept or forward tunneled packets only over its tunnel interface. It is also @@ -461,21 +457,22 @@ router. The above condition ensures that an encapsulated packet which 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 which 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. + network and the IPv4 network to which it is attached (as in broadband + home network scenario mentioned above). 4. Recommendations In light of the mitigation measures proposed above we make the following recommendations in decreasing order: 1. When possible, it is recommended that the attacks are operationally eliminated (as per one of the measures proposed in Section 3.3). @@ -483,27 +480,27 @@ cache which includes all legitimate end-points of the tunnel, we recommend exercising the Neighbor Cache Check. 3. For tunnel routers that can implement the Neighbor Reachability Check, we recommend exercising it. 4. For tunnels having small and static list of end-points we recommend exercising Known IPv4 Address Check. 5. For all other cases we recommend the Destination and Source - Address Checks. + Address Checks. This is the least preferable measure since it + generally can not mitigate routing loops with 6rd routers. As noted earlier, tunnels may be deployed in various operational - environments. There is a possibility that other mitigation measures - may be allowed is specific deployment scenarios. The above - recommendations are general and do not attempt to cover such - scenarios. + environments. There is a possibility that other mitigations may be + feasible in specific deployment scenarios. The above recommendations + are general and do not attempt to cover such scenarios. 5. IANA Considerations This document has no IANA considerations. 6. Security Considerations 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 @@ -521,33 +518,48 @@ 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 via IPv4 Clouds", RFC 3056, February 2001. + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", RFC 4213, October 2005. + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 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. + + [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 Tunnels", USENIX WOOT, August 2009. Authors' Addresses Gabi Nakibly National EW Research & Simulation Center P.O. Box 2250 (630) Haifa 31021