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/ |