--- 1/draft-ietf-v6ops-tunnel-loops-00.txt 2010-11-09 21:16:40.000000000 +0100 +++ 2/draft-ietf-v6ops-tunnel-loops-01.txt 2010-11-09 21:16:40.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group G. Nakibly Internet-Draft National EW Research & Intended status: Informational Simulation Center -Expires: March 16, 2011 F. Templin +Expires: May 13, 2011 F. Templin Boeing Research & Technology - September 12, 2010 + November 9, 2010 Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-ietf-v6ops-tunnel-loops-00.txt + draft-ietf-v6ops-tunnel-loops-01.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 March 16, 2011. + This Internet-Draft will expire on May 13, 2011. Copyright Notice Copyright (c) 2010 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 @@ -61,65 +61,69 @@ 3.1. Destination and Source Address Checks . . . . . . . . . . 6 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 7 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.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10 3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 - network. Automatic tunnels form a category of tunnels in which a - packet's egress node's IPv4 address is embedded within the - destination IPv6 address of the packet. A tunnel's router is a - router that encapsulates and decapsulates the IPv6 packets into and - out of the tunnel, respectively. 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. This assumption - poses a security vulnerability since it may result in an - inconsistency between the IPv4 routing state and the IPv6 routing - state there by allowing a routing loop to be formed. + network. Automatic tunnels that use stateless address mapping + (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. 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. - Unless proper security measures are in place all IPv6 automatic + Without compensating security measures in place, all IPv6 automatic tunnels that are based on protocol-41 encapsulation are vulnerable to - such an attack, in particular, ISATAP [RFC5214], 6to4 [RFC3056] and - 6rd [RFC5569]. The aim of this document is to shed light on the - routing loop attack and present some 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. + such an attack including ISATAP [RFC5214], 6to4 [RFC3056] and 6rd + [RFC5569]. + + 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. 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.