Network Working Group G. Nakibly Internet-Draft National EW Research & Intended status: Informational Simulation Center Expires: April 19, 2010 October 16, 2009 Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions draft-nakibly-v6ops-tunnel-loops-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document is concerned with security vulnerabilities in the ISATAP and 6to4 tunnels. These vulnerabilities allow an attacker to Nakibly Expires April 19, 2010 [Page 1] Internet-Draft ISATAP and 6to4 Routing Loops October 2009 take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We describe these security vulnerabilities and the attacks which exploit them. We further recommend on solutions to remove the vulnerabilities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Detailed Descriptions of the Attacks . . . . . . . . . . . . . 3 2.1. Attack #1: 6to4 Relay to ISATAP Router . . . . . . . . . . 4 2.2. Attack #2: ISATAP Router to 6to4 Relay . . . . . . . . . . 4 2.3. Attack #3: ISATAP Router to ISATAP Router . . . . . . . . . 4 3. Recommended Solutions . . . . . . . . . . . . . . . . . . . . . 4 3.1. Destination and Source Address Check . . . . . . . . . . . 4 3.2. Neighbor Cache Check . . . . . . . . . . . . . . . . . . . 4 3.3. Known IPv4 Address Check . . . . . . . . . . . . . . . . . 4 3.4. Known IPv6 Address Check . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Nakibly Expires April 19, 2010 [Page 2] Internet-Draft ISATAP and 6to4 Routing Loops October 2009 1. Introduction Recent research [USENIX09] has pointed out the existence of some security vulnerabilities in the design of the automatic tunnels ISATAP [RFC5214] and 6to4 [RFC3056]. These vulnerabilities allow a specially crafted packet to loop back and forth between ISATAP routers or 6to4 relays thereby overloading them. In automatic tunnels a packet's egress node's IPv4 address is computationally derived from the destination IPv6 address of the packet. This feature eliminates the need to keep an explicit routing table at the tunnel's end points. In particular, the end points do not have to be updated as peers join and leave the tunnel. In fact, the end points of an automatic tunnel do not know which other end points are currently part of the tunnel. However, all end points operate on the implicit assumption that once a packet arrives at the tunnel, its destination indeed is part of the tunnel. This assumption poses a security vulnerability since it may result in an inconsistency between a tunnel's overlay IPv6 routing state and the native IPv6 routing state there by allowing 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 a native IPv6 network. In that network, the packet is routed back to the ingress point that forwards it back into the tunnel. Consequently, the packet will loop in and out of the tunnel. A loop terminates only when the Hop Limit field in the IPv6 header of the packet is zeroed out. The maximum value that can be assigned to this field is 255. Note that when the packet is tunneled over IPv4 routers, the Hop Limit does not decrease. Every attack packet will traverse each hop along the loop 255/N times, where N is the number of IPv6 routers on the loop. As a result, the loops can be used as traffic amplification tools with a ratio of 255/N. The number of IPv6 routers on the loop is determined the positions of the two victims. The closer the two victims are, the larger the amplification ratio will be. 2. Detailed Descriptions of the Attacks This section details three attacks that exemplify how the security vulnerability described above may be exploited. Nakibly Expires April 19, 2010 [Page 3] Internet-Draft ISATAP and 6to4 Routing Loops October 2009 2.1. Attack #1: 6to4 Relay to ISATAP Router TBW 2.2. Attack #2: ISATAP Router to 6to4 Relay TBW 2.3. Attack #3: ISATAP Router to ISATAP Router TBW 3. Recommended Solutions This section describes the recommended solutions that mitigate the attacks above. For each solution we shall discuss its advantages and disadvantages. 3.1. Destination and Source Address Check TBW 3.2. Neighbor Cache Check TBW 3.3. Known IPv4 Address Check TBW 3.4. Known IPv6 Address Check TBW 4. IANA Considerations This document has no IANA considerations. 5. Security Considerations TBW Nakibly Expires April 19, 2010 [Page 4] Internet-Draft ISATAP and 6to4 Routing Loops October 2009 6. Acknowledgments This work has benefited from discussions with colleagues on the V6OPS, 6MAN and SECDIR mailing lists. 7. References 7.1. Normative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 7.2. Informative References [USENIX09] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Tunnels, USENIX WOOT", August 2009. Author's Address Gabi Nakibly National EW Research & Simulation Center P.O. Box 2250 (630) Haifa 31021 Israel Email: gnakibly@yahoo.com Nakibly Expires April 19, 2010 [Page 5]