draft-ietf-v6ops-tunnel-loops-00.txt   draft-ietf-v6ops-tunnel-loops-01.txt 
Network Working Group G. Nakibly Network Working Group G. Nakibly
Internet-Draft National EW Research & Internet-Draft National EW Research &
Intended status: Informational Simulation Center Intended status: Informational Simulation Center
Expires: March 16, 2011 F. Templin Expires: May 13, 2011 F. Templin
Boeing Research & Technology Boeing Research & Technology
September 12, 2010 November 9, 2010
Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and
Proposed Mitigations Proposed Mitigations
draft-ietf-v6ops-tunnel-loops-00.txt draft-ietf-v6ops-tunnel-loops-01.txt
Abstract Abstract
This document is concerned with security vulnerabilities in IPv6-in- This document is concerned with security vulnerabilities in IPv6-in-
IPv4 automatic tunnels. These vulnerabilities allow an attacker to IPv4 automatic tunnels. These vulnerabilities allow an attacker to
take advantage of inconsistencies between the IPv4 routing state and take advantage of inconsistencies between the IPv4 routing state and
the IPv6 routing state. The attack forms a routing loop which can be the IPv6 routing state. The attack forms a routing loop which can be
abused as a vehicle for traffic amplification to facilitate DoS abused as a vehicle for traffic amplification to facilitate DoS
attacks. The first aim of this document is to inform on this attack 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 and its root causes. The second aim is to present some possible
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1. Destination and Source Address Checks . . . . . . . . . . 6 3.1. Destination and Source Address Checks . . . . . . . . . . 6
3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 7 3.1.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 7
3.2. Verification of end point existence . . . . . . . . . . . 8 3.2. Verification of end point existence . . . . . . . . . . . 8
3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8 3.2.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 8
3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9 3.2.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 9
3.2.3. Neighbor Reachability Check . . . . . . . . . . . . . 9 3.2.3. Neighbor Reachability Check . . . . . . . . . . . . . 9
3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 10 3.3. Operational Measures . . . . . . . . . . . . . . . . . . . 10
3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10 3.3.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 10
3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10 3.3.2. A Single Border Router . . . . . . . . . . . . . . . . 10
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
IPv6-in-IPv4 tunnels are an essential part of many migration plans 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 for IPv6. They allow two IPv6 nodes to communicate over an IPv4-only
network. Automatic tunnels form a category of tunnels in which a network. Automatic tunnels that use stateless address mapping
packet's egress node's IPv4 address is embedded within the (hereafter called "automatic tunnels") are a category of tunnels in
destination IPv6 address of the packet. A tunnel's router is a which a tunneled packet's egress IPv4 address is embedded within the
router that encapsulates and decapsulates the IPv6 packets into and destination IPv6 address of the packet. An automatic tunnel's router
out of the tunnel, respectively. Ref. [USENIX09] pointed out the is a router that respectively encapsulates and decapsulates the IPv6
existence of a vulnerability in the design of IPv6 automatic tunnels. packets into and out of the tunnel.
Tunnel routers operate on the implicit assumption that the
destination address of an incoming IPv6 packet is always an address Ref. [USENIX09] pointed out the existence of a vulnerability in the
of a valid node that can be reached via the tunnel. This assumption design of IPv6 automatic tunnels. Tunnel routers operate on the
poses a security vulnerability since it may result in an implicit assumption that the destination address of an incoming IPv6
inconsistency between the IPv4 routing state and the IPv6 routing packet is always an address of a valid node that can be reached via
state there by allowing a routing loop to be formed. 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 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 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 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 native IPv6 network. There the packet is routed back to the ingress
point that forwards it back into the tunnel. Consequently, the point that forwards it back into the tunnel. Consequently, the
packet loops in and out of the tunnel. The loop terminates only when 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 the Hop Limit field in the IPv6 header of the packet is decremented
to zero. 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 tunnels that are based on protocol-41 encapsulation are vulnerable to
such an attack, in particular, ISATAP [RFC5214], 6to4 [RFC3056] and such an attack including ISATAP [RFC5214], 6to4 [RFC3056] and 6rd
6rd [RFC5569]. The aim of this document is to shed light on the [RFC5569].
routing loop attack and present some possible mitigation measures
that should be considered by operators of current IPv6 automatic The aim of this document is to shed light on the routing loop attack
tunnels and by designers of future ones. We note that tunnels may be and describe possible mitigation measures that should be considered
deployed in various operational environments, e.g. service provider by operators of current IPv6 automatic tunnels and by designers of
network, enterprise network, etc. Specific issues related to the future ones. We note that tunnels may be deployed in various
attack which are derived from the operational environment are not operational environments, e.g. service provider network, enterprise
considered in this document. 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 2. A Detailed Description of the Attack
In this section we shall denote an IPv6 address of a node reached via 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 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 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 address may or may not be part of the prefix (depending on the
specification of the tunnel's protocol). The IPv6 address may be specification of the tunnel's protocol). The IPv6 address may be
dependent on additional bits in the interface ID, however for our dependent on additional bits in the interface ID, however for our
discussion their exact value is not important. discussion their exact value is not important.
 End of changes. 9 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/