One document matched: draft-nakibly-v6ops-tunnel-loops-00.txt

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]