draft-ietf-v6ops-tunnel-loops-05.txt   draft-ietf-v6ops-tunnel-loops-06.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: September 15, 2011 F. Templin Expires: October 1, 2011 F. Templin
Boeing Research & Technology Boeing Research & Technology
March 14, 2011 March 30, 2011
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-05.txt draft-ietf-v6ops-tunnel-loops-06.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 September 15, 2011. This Internet-Draft will expire on October 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Detailed Description of the Attack . . . . . . . . . . . . . 4 2. A Detailed Description of the Attack . . . . . . . . . . . . . 4
3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6 3. Proposed Mitigation Measures . . . . . . . . . . . . . . . . . 6
3.1. Verification of end point existence . . . . . . . . . . . 6 3.1. Verification of end point existence . . . . . . . . . . . 7
3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 6 3.1.1. Neighbor Cache Check . . . . . . . . . . . . . . . . . 7
3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 7 3.1.2. Known IPv4 Address Check . . . . . . . . . . . . . . . 8
3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 7 3.2. Operational Measures . . . . . . . . . . . . . . . . . . . 8
3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8 3.2.1. Avoiding a Shared IPv4 Link . . . . . . . . . . . . . 8
3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 8 3.2.2. A Single Border Router . . . . . . . . . . . . . . . . 9
3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9 3.2.3. A Comprehensive List of Tunnel Routers . . . . . . . . 9
3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 9 3.2.4. Avoidance of On-link Prefixes . . . . . . . . . . . . 10
3.3. Destination and Source Address Checks . . . . . . . . . . 15 3.3. Destination and Source Address Checks . . . . . . . . . . 15
3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16 3.3.1. Known IPv6 Prefix Check . . . . . . . . . . . . . . . 16
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 that assign non-link-local IPv6 prefixes network. Automatic tunnels that assign non-link-local IPv6 prefixes
with stateless address mapping properties (hereafter called with stateless address mapping properties (hereafter called
"automatic tunnels") are a category of tunnels in which a tunneled "automatic tunnels") are a category of tunnels in which a tunneled
packet's egress IPv4 address is embedded within the destination IPv6 packet's egress IPv4 address is embedded within the destination IPv6
address of the packet. An automatic tunnel's router is a router that address of the packet. An automatic tunnel's router is a router that
respectively encapsulates and decapsulates the IPv6 packets into and respectively encapsulates and decapsulates the IPv6 packets into and
out of the tunnel. out of the tunnel.
Ref. [USENIX09] pointed out the existence of a vulnerability in the Ref. [USENIX09] pointed out the existence of a vulnerability in the
design of IPv6 automatic tunnels. Tunnel routers operate on the design of IPv6 automatic tunnels. Tunnel routers operate on the
implicit assumption that the destination address of an incoming IPv6 implicit assumption that the destination address of an incoming IPv6
packet is always an address of a valid node that can be reached via packet is always an address of a valid node that can be reached via
the tunnel. The assumption of path validity poses a denial of the tunnel. The assumption of path validity can introduce routing
service risk as inconsistency between the IPv4 routing state and the loops as the inconsistency between the IPv4 routing state and the
IPv6 routing state allows a routing loop to be formed. IPv6 routing state allows a routing loop to be formed. Although
those loops will not trap normal data, they will catch traffic
targeted at addresses that have become unavailable, and misconfigured
traffic can enter the loop.
An attacker can exploit this vulnerability by crafting a packet which The looping vulnerability can be triggered accidentally or exploited
is routed over a tunnel to a node that is not participating in that maliciously by an attacker crafting a packet which is routed over a
tunnel. This node may forward the packet out of the tunnel to the tunnel to a node that is not associated with the packet's
native IPv6 network. There the packet is routed back to the ingress destination. This node may forward the packet out of the tunnel to
point that forwards it back into the tunnel. Consequently, the the native IPv6 network. There the packet is routed back to the
packet loops in and out of the tunnel. The loop terminates only when ingress point that forwards it back into the tunnel. Consequently,
the Hop Limit field in the IPv6 header of the packet is decremented the packet loops in and out of the tunnel. The loop terminates only
to zero. This vulnerability can be abused as a vehicle for traffic when the Hop Limit field in the IPv6 header of the packet is
amplification to facilitate DoS attacks [RFC4732]. decremented to zero. This vulnerability can be abused as a vehicle
for traffic amplification to facilitate DoS attacks [RFC4732].
Without compensating security measures in place, all IPv6 automatic Without compensating security measures in place, all IPv6 automatic
tunnels that are based on protocol-41 encapsulation [RFC4213] are tunnels that are based on protocol-41 encapsulation [RFC4213] are
vulnerable to such an attack including ISATAP [RFC5214], 6to4 vulnerable to such an attack including ISATAP [RFC5214], 6to4
[RFC3056] and 6rd [RFC5969]. It should be noted that this document [RFC3056] and 6rd [RFC5969]. It should be noted that this document
does not consider non-protocol-41 encapsulation attacks. In does not consider non-protocol-41 encapsulation attacks. In
particular, we do not address the Teredo [RFC4380] attacks described particular, we do not address the Teredo [RFC4380] attacks described
in [USENIX09]. These attacks are considered in in [USENIX09]. These attacks are considered in
[I-D.gont-6man-teredo-loops]. [I-D.gont-6man-teredo-loops].
The aim of this document is to shed light on the routing loop attack The aim of this document is to shed light on the routing loop attack
and describe possible mitigation measures that should be considered and describe possible mitigation measures that should be considered
by operators of current IPv6 automatic tunnels and by designers of by operators of current IPv6 automatic tunnels and by designers of
future ones. We note that tunnels may be deployed in various future ones. We note that tunnels may be deployed in various
operational environments, e.g. service provider network, enterprise operational environments, e.g. service provider network, enterprise
network, etc. Specific issues related to the attack which are network, etc. Specific issues related to the attack which are
derived from the operational environment are not considered in this derived from the operational environment are not considered in this
document. document.
Routing loops pose a risk to the stability of a network.
Furthermore, they provide an opening for denial of service attacks
that exploit the existence of the loop to increase the traffic load
in the network. Section 3 of this document discusses a number of
mitigation measures. The most desirable mitigation, however, is to
operate the network in such a way that routing loops can not take
place (see Section 3.2).
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 by an IPv6
a given tunnel by the prefix of the tunnel and an IPv4 address of the prefix assigned to the tunnel and an IPv4 address of the tunnel end
tunnel end point, i.e., Addr(Prefix, IPv4). Note that the IPv4 point, i.e., Addr(Prefix, IPv4). Note that the IPv4 address may or
address may or may not be part of the prefix (depending on the may not be part of the prefix (depending on the specification of the
specification of the tunnel's protocol). The IPv6 address may be tunnel's protocol). The IPv6 address may be dependent on additional
dependent on additional bits in the interface ID, however for our bits in the interface ID, however for our discussion their exact
discussion their exact value is not important. value is not important.
The two victims of this attack are routers - R1 and R2 - of two The two victims of this attack are routers - R1 and R2 - that service
different tunnels - T1 and T2. Both routers have the capability to two different tunnel prefixes - Prf1 and Prf2. Both routers have the
forward IPv6 packets in and out of their respective tunnels. The two capability to forward IPv6 packets in and out of their respective
tunnels need not be based on the same tunnel protocol. The only tunnels. The two tunnels need not be based on the same tunnel
condition is that the two tunnel protocols be based on protocol-41 protocol. The only condition is that the two tunnel protocols be
encapsulation. The IPv4 address of R1 is IP1, while the prefix of based on protocol-41 encapsulation. The IPv4 address of R1 is IP1,
its tunnel is Prf1. IP2 and Prf2 are the respective values for R2. while the prefix of its tunnel is Prf1. IP2 and Prf2 are the
We assume that IP1 and IP2 belong to the same address realm, i.e., respective values for R2. We assume that IP1 and IP2 belong to the
they are either both public, or both private and belong to the same same address realm, i.e., they are either both public, or both
internal network. The following network diagram depicts the private and belong to the same internal network. The following
locations of the two routers. The numbers indicate the packets of network diagram depicts the locations of the two routers. The
the attack and the path they traverse as described below. numbers indicate the packets of the attack and the path they traverse
as described below.
####### [ Packet 1 ]
# R1 # v6src = Addr(Prf1, IP2) [ Packet 2 ]
####### v6dst = Addr(Prf2, IP1) v6src = Addr(Prf1, IP2)
// \ v4src = IP2; v4dst = IP1 +----------+ v6dst = Addr(Prf2, IP1)
T1 // 2 \ 1 //===========>| Router |-----------------\
interface // \ || | R1 | |
_______________//_ __\________________ || +----------+ v
| | | | .-. .-.
| IPv4 Network | | IPv6 Network | ,-( _)-. ,-( _)-.
|__________________| |___________________| .-(_ IPv4 )-. .-(_ IPv6 )-.
\\ / (__ Network ) (__ Network )
\\ / `-(______)-' `-(______)-'
T2 \\ 2 / 0,1 ^^ |
interface \\ / || +----------+ |
####### \\============| Router |<----------------/
# R2 # [ Packet 1 ] | R2 | [ Packets 0 and 2 ]
####### v6src = Addr(Prf1, IP2) +----------+ v6src = Addr(Prf1, IP2)
v6dst = Addr(Prf2, IP1) v6dst = Addr(Prf2, IP1)
v4src = IP2; v4dst = IP1
Figure 1: The network setting of the attack Figure 1: The network setting of the attack
The attack is depicted in Figure 2. It is initiated by sending an The attack is depicted in Figure 2. It is initiated by an
IPv6 packet (packet 0 in Figure 2) destined to a fictitious end point accidentally or maliciously produced IPv6 packet (packet 0 in
that appears to be reached via T2 and has IP1 as its IPv4 address, Figure 2) destined to a fictitious end point that appears to be
i.e., Addr(Prf2, IP1). The source address of the packet is a T1 reached via Prf2 and has IP1 as its IPv4 address, i.e., Addr(Prf2,
address with Prf1 as the prefix and IP2 as the embedded IPv4 address, IP1). The source address of the packet is an address with Prf1 as
i.e., Addr(Prf1, IP2). As the prefix of the destination address is the prefix and IP2 as the embedded IPv4 address, i.e., Addr(Prf1,
Prf2, the packet will be routed over the IPv6 network to T2. IP2). As the prefix of the destination address is Prf2, the packet
will be routed over the IPv6 network to R2.
We assume that R2 is the packet's entry point to T2. R2 receives the R2 receives the packet through its IPv6 interface and forwards it
packet through its IPv6 interface and forwards it over its T2 into the tunnel with an IPv4 header having a destination address
interface encapsulated with an IPv4 header having a destination derived from the IPv6 destination, i.e., IP1. The source address is
address derived from the IPv6 destination, i.e., IP1. The source the address of R2, i.e., IP2. The packet (packet 1 in Figure 2) is
address is the address of R2, i.e., IP2. The packet (packet 1 in routed over the IPv4 network to R1, which receives the packet on its
Figure 2.) is routed over the IPv4 network to R1, which receives the IPv4 interface. It processes the packet as a packet that originates
packet on its IPv4 interface. It processes the packet as a packet from one of the end nodes of Prf1.
that originates from one of the end nodes of T1.
Since the IPv4 source address corresponds to the IPv6 source address, Since the IPv4 source address corresponds to the IPv6 source address,
R1 will decapsulate the packet. Since the packet's IPv6 destination R1 will decapsulate the packet. Since the packet's IPv6 destination
is outside of T1, R1 will forward the packet onto a native IPv6 is outside of Prf1, R1 will forward the packet onto a native IPv6
interface. The forwarded packet (packet 2 in Figure 2) is identical interface. The forwarded packet (packet 2 in Figure 2) is identical
to the original attack packet. Hence, it is routed back to R2, in to the original attack packet. Hence, it is routed back to R2, in
which the loop starts again. Note that the packet may not which the loop starts again. Note that the packet may not
necessarily be transported from R1 over native IPv6 network. R1 may necessarily be transported from R1 over native IPv6 network. R1 may
be connected to the IPv6 network through another tunnel. be connected to the IPv6 network through another tunnel.
R1 R2 R1 R2
| | 0 | | 0
| 1 |<------ | 1 |<------
|<===============| |<===============|
skipping to change at page 5, line 45 skipping to change at page 6, line 23
1 - IPv4: IP2 --> IP1 1 - IPv4: IP2 --> IP1
IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1)
0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1) 0,2- IPv6: Addr(Prf1,IP2) --> Addr(Prf2,IP1)
Legend: ====> - tunneled IPv6, ---> - native IPv6 Legend: ====> - tunneled IPv6, ---> - native IPv6
Figure 2: Routing loop attack between two tunnels' routers Figure 2: Routing loop attack between two tunnels' routers
The crux of the attack is as follows. The attacker exploits the fact The crux of the attack is as follows. The attacker exploits the fact
that R2 does not know that R1 does not take part of T2 and that R1 that R2 does not know that R1 does not configure addresses from Prf2
does not know that R2 does not take part of T1. The IPv4 network and that R1 does not know that R2 does not configure addresses from
acts as a shared link layer for the two tunnels. Hence, the packet Prf1. The IPv4 network acts as a shared link layer for the two
is repeatedly forwarded by both routers. It is noted that the attack tunnels. Hence, the packet is repeatedly forwarded by both routers.
will fail when the IPv4 network can not transport packets between the It is noted that the attack will fail when the IPv4 network can not
tunnels. For example, when the two routers belong to different IPv4 transport packets between the tunnels. For example, when the two
address realms or when ingress/egress filtering is exercised between routers belong to different IPv4 address realms or when ingress/
the routes. egress filtering is exercised between the routes.
The loop will stop when the Hop Limit field of the packet reaches The loop will stop when the Hop Limit field of the packet reaches
zero. After a single loop the Hop Limit field is decreased by the zero. After a single loop the Hop Limit field is decreased by the
number of IPv6 routers on path from R1 and R2. Therefore, the number number of IPv6 routers on path from R1 to R2. Therefore, the number
of loops is inversely proportional to the number of IPv6 hops between of loops is inversely proportional to the number of IPv6 hops between
R1 and R2. R1 and R2.
The tunnel pair T1 and T2 may be any combination of automatic tunnel The tunnels used by R1 and R2 may be any combination of automatic
types, e.g., ISATAP, 6to4 and 6rd. This has the exception that both tunnel types, e.g., ISATAP, 6to4 and 6rd. This has the exception
tunnels can not be of type 6to4, since two 6to4 routers can not that both tunnels can not be of type 6to4, since two 6to4 routers
belong to different tunnels (there is only one 6to4 tunnel in the share the same IPv6 prefix, i.e., there is only one 6to4 prefix
Internet). For example, if the attack were to be launched on an (2002::/16) in the Internet. For example, if the attack were to be
ISATAP router (R1) and 6to4 relay (R2), then the destination and launched on an ISATAP router (R1) and 6to4 relay (R2), then the
source addresses of the attack packet would be 2002:IP1:* and Prf1:: destination and source addresses of the attack packet would be 2002:
0200:5EFE:IP2, respectively. IP1:* and Prf1::0200:5EFE:IP2, respectively.
3. Proposed Mitigation Measures 3. Proposed Mitigation Measures
This section presents some possible mitigation measures for the This section presents some possible mitigation measures for the
attack described above. For each measure we shall discuss its attack described above. For each measure we shall discuss its
advantages and disadvantages. advantages and disadvantages.
The proposed measures fall under the following three categories: The proposed measures fall under the following three categories:
o Verification of end point existence o Verification of end point existence
skipping to change at page 14, line 48 skipping to change at page 15, line 7
due to scaling considerations. due to scaling considerations.
In those cases, an on-demand routing capability can be enabled in In those cases, an on-demand routing capability can be enabled in
which ISATAP nodes send initial packets via an advertising ISATAP which ISATAP nodes send initial packets via an advertising ISATAP
router and receive redirection messages back. For example, when a router and receive redirection messages back. For example, when a
non-advertising ISATAP router 'B' has a packet to send to a host non-advertising ISATAP router 'B' has a packet to send to a host
located behind non-advertising ISATAP router 'D', it can send the located behind non-advertising ISATAP router 'D', it can send the
initial packets via advertising router 'A' which will return initial packets via advertising router 'A' which will return
redirection messages to inform 'B' that 'D' is a better first hop. redirection messages to inform 'B' that 'D' is a better first hop.
Protocol details for this ISATAP redirection are specified in Protocol details for this ISATAP redirection are specified in
[I-D.templin-intarea-vet]. [I-D.templin-aero].
3.3. Destination and Source Address Checks 3.3. Destination and Source Address Checks
Tunnel routers can use a source address check mitigation when they Tunnel routers can use a source address check mitigation when they
forward an IPv6 packet into a tunnel interface with an IPv6 source forward an IPv6 packet into a tunnel interface with an IPv6 source
address that embeds one of the router's configured IPv4 addresses. address that embeds one of the router's configured IPv4 addresses.
Similarly, tunnel routers can use a destination address check Similarly, tunnel routers can use a destination address check
mitigation when they receive an IPv6 packet on a tunnel interface mitigation when they receive an IPv6 packet on a tunnel interface
with an IPv6 destination address that embeds one of the router's with an IPv6 destination address that embeds one of the router's
configured IPv4 addresses. These checks should correspond to both configured IPv4 addresses. These checks should correspond to both
skipping to change at page 15, line 39 skipping to change at page 15, line 43
o When the router forwards an IPv6 packet into a tunnel interface, o When the router forwards an IPv6 packet into a tunnel interface,
it discards the packet if the IPv6 source address has an off-link it discards the packet if the IPv6 source address has an off-link
prefix but embeds one of the router's configured IPv4 addresses. prefix but embeds one of the router's configured IPv4 addresses.
o When the router receives an IPv6 packet on a tunnel interface, it o When the router receives an IPv6 packet on a tunnel interface, it
discards the packet if the IPv6 destination address has an off- discards the packet if the IPv6 destination address has an off-
link prefix but embeds one of the router's configured IPv4 link prefix but embeds one of the router's configured IPv4
addresses. addresses.
This approach has the advantage that that no ancillary state is This approach has the advantage that no ancillary state is required,
required, since checking is through static lookup in the lists of since checking is through static lookup in the lists of IPv4 and IPv6
IPv4 and IPv6 addresses belonging to the router. However, this addresses belonging to the router. However, this approach has some
approach has some inherent limitations inherent limitations
o The checks incur an overhead which is proportional to the number o The checks incur an overhead which is proportional to the number
of IPv4 addresses assigned to the router. If a router is assigned of IPv4 addresses assigned to the router. If a router is assigned
many addresses, the additional processing overhead for each packet many addresses, the additional processing overhead for each packet
may be considerable. Note that an unmitigated attack packet would may be considerable. Note that an unmitigated attack packet would
be repetitively processed by the router until the Hop Limit be repetitively processed by the router until the Hop Limit
expires, which may require as many as 255 iterations. Hence, an expires, which may require as many as 255 iterations. Hence, an
unmitigated attack will consume far more aggregate processing unmitigated attack will consume far more aggregate processing
overhead than per-packet address checks even if the router assigns overhead than per-packet address checks even if the router assigns
a large number of addresses. a large number of addresses.
skipping to change at page 18, line 8 skipping to change at page 18, line 16
This document aims at presenting possible solutions to the routing This document aims at presenting possible solutions to the routing
loop attack which involves automatic tunnels' routers. It contains loop attack which involves automatic tunnels' routers. It contains
various checks that aim to recognize and drop specific packets that various checks that aim to recognize and drop specific packets that
have strong potential to cause a routing loop. These checks do not have strong potential to cause a routing loop. These checks do not
introduce new security threats. introduce new security threats.
7. Acknowledgments 7. Acknowledgments
This work has benefited from discussions on the V6OPS, 6MAN and This work has benefited from discussions on the V6OPS, 6MAN and
SECDIR mailing lists. Remi Despres, Christian Huitema, Dmitry SECDIR mailing lists. The document has further benefitted from
Anipko, Dave Thaler and Fernando Gont are acknowledged for their comments received from members of the IESG during their review.
contributions. Dmitry Anipko, Fred Baker, Stewart Bryant, Remi Despres, Adrian
Farrell, Fernando Gont, Christian Huitema, Joel Jaeggli, and Dave
Thaler are acknowledged for their contributions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
skipping to change at page 19, line 5 skipping to change at page 19, line 16
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
8.2. Informative References 8.2. Informative References
[I-D.gont-6man-teredo-loops] [I-D.gont-6man-teredo-loops]
Gont, F., "Mitigating Teredo Rooting Loop Attacks", Gont, F., "Mitigating Teredo Rooting Loop Attacks",
draft-gont-6man-teredo-loops-00 (work in progress), draft-gont-6man-teredo-loops-00 (work in progress),
September 2010. September 2010.
[I-D.templin-intarea-vet] [I-D.templin-aero]
Templin, F., "Virtual Enterprise Traversal (VET)", Templin, F., "Asymmetric Extended Route Optimization
draft-templin-intarea-vet-23 (work in progress), (AERO)", draft-templin-aero-00 (work in progress),
January 2011. March 2011.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[USENIX09] [USENIX09]
Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6
 End of changes. 25 change blocks. 
105 lines changed or deleted 122 lines changed or added

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