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]