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/