draft-ietf-grow-filtering-threats-01.txt		draft-ietf-grow-filtering-threats-02.txt
	Network Working Group Camilo Cardona		Network Working Group Camilo Cardona
	Internet-Draft IMDEA Networks/UC3M		Internet-Draft IMDEA Networks/UC3M
	Intended status: Informational Pierre Francois		Intended status: Informational Pierre Francois
	Expires: April 21, 2014 IMDEA Networks		Expires: August 17, 2014 IMDEA Networks
	October 18, 2013		Paolo Lucente
			Cisco Systems
			February 13, 2014
	Making BGP filtering a habit: Impact on policies		Making BGP filtering a habit: Impact on policies
	draft-ietf-grow-filtering-threats-01		draft-ietf-grow-filtering-threats-02
	Abstract		Abstract
	Network operators define their BGP policies based on the business		Network operators define their BGP policies based on the business
	relationships that they maintain with their peers. By limiting the		relationships that they maintain with their peers. By limiting the
	propagation of BGP prefixes, an autonomous system avoids the		propagation of BGP prefixes, an autonomous system avoids the
	existence of flows between BGP peers that do not provide any		existence of flows between BGP peers that do not provide any
	economical gain. This draft describes how unexpected traffic flows		economical gain. This draft describes how unexpected traffic flows
	can emerge in autonomous systems due to the filtering of overlapping		can emerge in autonomous systems due to the filtering of overlapping
	BGP prefixes by neighboring domains.		BGP prefixes by neighboring domains.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 21, 2014.		This Internet-Draft will expire on August 17, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Filtering overlapping prefixes . . . . . . . . . . . . . . . . 3		2. Filtering overlapping prefixes . . . . . . . . . . . . . . . 3
	2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4		2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Remotely triggered filtering . . . . . . . . . . . . . . . 5		2.2. Remotely triggered filtering . . . . . . . . . . . . . . 6
	3. Uses of overlapping prefix filtering that create		3. Uses of overlapping prefix filtering that create unexpected
	unexpected traffic flows . . . . . . . . . . . . . . . . . . . 6		traffic flows . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . . 7		3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . 7
	3.1.1. Unexpected traffic flows caused by local filtering		3.1.1. Unexpected traffic flows caused by local filtering of
	of overlapping prefixes . . . . . . . . . . . . . . . 8		overlapping prefixes . . . . . . . . . . . . . . . . 8
	3.1.2. Unexpected traffic flows caused by remotely		3.1.2. Unexpected traffic flows caused by remotely triggered
	triggered filtering of overlapping prefixes . . . . . 11		filtering of overlapping prefixes . . . . . . . . . . 12
	4. Techniques to detect unexpected traffic flows caused by		4. Techniques to detect unexpected traffic flows caused by
	filtering of overlapping prefixes . . . . . . . . . . . . . . 14		filtering of overlapping prefixes . . . . . . . . . . . . . . 15
	4.1. Being the 'victim' of unexpected traffic flows . . . . . . 15		4.1. Being the 'victim' of unexpected traffic flows . . . . . 15
	4.2. Being a contributor to the existence of unexpected		4.2. Being a contributor to the existence of unexpected
	traffic flows in other networks . . . . . . . . . . . . . 15		traffic flows in other networks . . . . . . . . . . . . . 15
	5. Techniques to counter unexpected traffic flows due to the		5. Techniques to counter unexpected traffic flows due to the
	filtering of overlapping prefixes . . . . . . . . . . . . . . 16		filtering of overlapping prefixes . . . . . . . . . . . . . . 16
	5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17		5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17
	5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18		5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18
	5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . . 18		5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 18
	5.2.2. Automatic overlapping prefix filtering . . . . . . . . 19		5.2.2. Automatic overlapping prefix filtering . . . . . . . 19
	5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . . 19		5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . 19
	6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19		6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		7.1. References . . . . . . . . . . . . . . . . . . . . . . . 0
			7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	It is common practice for network operators to propagate overlapping		It is common practice for network operators to propagate overlapping
	prefixes along with the prefixes that they originate. It is also		prefixes along with the prefixes that they originate. It is also
	possible for some Autonomous Systems (ASes) to apply different		possible for some Autonomous Systems (ASes) to apply different
	policies to the overlapping (more specific) and the covering (less		policies to the overlapping (more specific) and the covering (less
	specific) prefix. Some ASes can even benefit from filtering the		specific) prefix. Some ASes can even benefit from filtering the
	overlapping prefixes.		overlapping prefixes.
	BGP makes independent, policy driven decisions for the selection of		BGP makes independent, policy driven decisions for the selection of
	the best path to be used for a given IP prefix. However, routers		the best path to be used for a given IP prefix. However, routers
	must forward packets using the longest-prefix-match rule, which		must forward packets using the longest-prefix-match rule, which
	"precedes" any BGP policy (RFC1812 [4]). Indeed, the existence of a		"precedes" any BGP policy (RFC1812 [1]). Indeed, the existence of a
	prefix p that is more specific than a prefix p' in the Forwarding		prefix p that is more specific than a prefix p' in the Forwarding
	Information Base (FIB) will let packets whose destination matches p		Information Base (FIB) will let packets whose destination matches p
	be forwarded according to the next hop selected as best for p (the		be forwarded according to the next hop selected as best for p (the
	overlapping prefix). This process takes place by disregarding the		overlapping prefix). This process takes place by disregarding the
	policies applied in the control plane for the selection of the best		policies applied in the control plane for the selection of the best
	next-hop for p' (the covering prefix). When an Autonomous System		next-hop for p' (the covering prefix). When an Autonomous System
	filters overlapping prefixes and forwards packets according to the		filters overlapping prefixes and forwards packets according to the
	covering prefix, the discrepancy in the routing policies applied to		covering prefix, the discrepancy in the routing policies applied to
	covering and overlapping prefixes can create unexpected traffic flows		covering and overlapping prefixes can create unexpected traffic flows
	that infringe the policies of other ASes still holding a path towards		that infringe the policies of other ASes still holding a path towards
	skipping to change at page 4, line 27		skipping to change at page 4, line 17
	over this specific session. At the time of the establishment of the		over this specific session. At the time of the establishment of the
	peering, it can be defined by both ASes that hot potato routing would		peering, it can be defined by both ASes that hot potato routing would
	happen in both directions of traffic. In other words, it was agreed		happen in both directions of traffic. In other words, it was agreed
	that each AS will deliver the traffic to the other AS on the nearest		that each AS will deliver the traffic to the other AS on the nearest
	peering link. In this scenario, it becomes relevant to AS2 to		peering link. In this scenario, it becomes relevant to AS2 to
	enforce such practice by detecting the described situations and		enforce such practice by detecting the described situations and
	automatically issuing the appropriate filtering. In this case, by		automatically issuing the appropriate filtering. In this case, by
	implementing these automatic procedures, AS2 would legitimately		implementing these automatic procedures, AS2 would legitimately
	detect and filter prefix 10.0.0.0/24.		detect and filter prefix 10.0.0.0/24.
	___....-----------....___		___....-----------....___
	,.--' AS2 `--..		,.--' AS2 `--..
	,' `.		,' `.
	| |		| |
	`._ _.'		`._ _.'
	`--..__ _,,.--'		`--..__ _,,.--'
	. `'''-----------'''' |		. `'''-----------'''' |
	| | |		| | |
	| | |		| | |
	10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22		10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22
	| ___....-----------....___ |10.0.0.0/24		| ___....-----------....___ |10.0.0.0/24
	,.--'AS1 `--..		,.--'AS1 `--..
	,' ...........`.		,' ...........`.
	| |10.0.0.0/24 |		| |10.0.0.0/24 |
	`._ |........._.'		`._ |........._.'
	`--..__ _,,.--'		`--..__ _,,.--'
	`'''-----------''''		`'''-----------''''
	Figure 1: Basic scenario of local filtering		Figure 1: Basic scenario of local filtering
	Local filtering could be required in other cases. For example, a		Local filtering could be required in other cases. For example, a
	dual homed AS receiving an overlapping prefix from only one of its		dual homed AS receiving an overlapping prefix from only one of its
	providers. Figure 2 depicts a simple example of this case.		providers. Figure 2 depicts a simple example of this case.
	_..._		_..._
	,' `.		,' `.
	/ AS4 \		/ AS4 \
	| |		| |
	\ /		\ /
	,`-...-'.		,`-...-'.
	/ '.		/ '.
	10.0.0.0/22 ,' \		10.0.0.0/22 ,' \
	10.0.0.0/24 / \ 10.0.0.0/22		10.0.0.0/24 / \ 10.0.0.0/22
	..:_ >..._		..:_ >..._
	,' `. ,' `.		,' `. ,' `.
	/ AS2 \ / AS3 \		/ AS2 \ / AS3 \
	| | | |		| | | |
	\ / \ /		\ / \ /
	`-...-', `-...-'		`-...-', `-...-'
	\ /		\ /
	\ /		\ /
	10.0.0.0/22 \_..._ '10.0.0.0/22		10.0.0.0/22 \_..._ '10.0.0.0/22
	10.0.0.0/24,' `.		10.0.0.0/24,' `.
	/ AS1 \		/ AS1 \
	| |		| |
	\ /		\ /
	`-...-'		`-...-'
	Figure 2: Basic scenario of local filtering		Figure 2: Basic scenario of local filtering
	In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and		In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and
	AS3. Both ASes propagate the prefix to AS4. Additionally, AS1		AS3. Both ASes propagate the prefix to AS4. Additionally, AS1
	advertises prefix 10.0.0.0/24 to AS2, which subsequently propagates		advertises prefix 10.0.0.0/24 to AS2, which subsequently propagates
	the prefix to AS4.		the prefix to AS4.
	It is possible that AS4 resolves to filter the more specific prefix		It is possible that AS4 resolves to filter the more specific prefix
	10.0.0.0/24. One potential motivation could be the economical		10.0.0.0/24. One potential motivation could be the economical
	preference of the path via AS2 over AS3. Another feasible reason is		preference of the path via AS2 over AS3. Another feasible reason is
	the existence of a technical policy by AS4 of aggregating incoming		the existence of a technical policy by AS4 of aggregating incoming
	prefixes longer than /23.		prefixes longer than /23.
	The above examples illustrate two of the many motivations to		The above examples illustrate two of the many motivations to
	configure routing within an AS with the aim of ignoring more specific		configure routing within an AS with the aim of ignoring more specific
	prefixes. Operators have reported applying these filters in a manual		prefixes. Operators have reported applying these filters in a manual
	fashion [3]. The relevance of such practice led to investigate		fashion [3]. The relevance of such practice led to investigate
	automated filtering procedures in I-D.WHITE [5].		automated filtering procedures in I-D.WHITE [2].
	2.2. Remotely triggered filtering		2.2. Remotely triggered filtering
	ISPs can tag the BGP paths that they propagate to neighboring ASes		ISPs can tag the BGP paths that they propagate to neighboring ASes
	with communities, in order to tweak the propagation behavior of the		with communities, in order to tweak the propagation behavior of the
	ASes that handle these paths [1].		ASes that handle these paths [1].
	Some ISPs allow their direct and indirect customers to use such		Some ISPs allow their direct and indirect customers to use such
	communities to let the receiving AS not export the path to some		communities to let the receiving AS not export the path to some
	selected neighboring AS. By combining communities, the prefix could		selected neighboring AS. By combining communities, the prefix could
	be advertised only to a given peer of the AS providing this feature.		be advertised only to a given peer of the AS providing this feature.
	Figure 3 illustrates an example of this case.		Figure 3 illustrates an example of this case.
	10.0.0.0/22 ,' \		10.0.0.0/22 ,' \
	10.0.0.0/24 / \ 10.0.0.0/22		10.0.0.0/24 / \ 10.0.0.0/22
	..:_ >..._		..:_ >..._
	,' `. ,' `.		,' `. ,' `.
	/ AS2 \________ / AS3 \		/ AS2 \________ / AS3 \
	| |/22 /22| |		| |/22 /22| |
	\ / \ /		\ / \ /
	`-...-', `-...-'		`-...-', `-...-'
	\ /		\ /
	\ /		\ /
	10.0.0.0/22 \_..._ '10.0.0.0/22		10.0.0.0/22 \_..._ '10.0.0.0/22
	10.0.0.0/24,' `.		10.0.0.0/24,' `.
	/ AS1 \		/ AS1 \
	| |		| |
	\ /		\ /
	`-...-'		`-...-'
	Figure 3: Remote triggered filtering		Figure 3: Remote triggered filtering
	AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic		AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic
	engineering purposes, AS1 could use communities to prevent AS2 from		engineering purposes, AS1 could use communities to prevent AS2 from
	announcing prefix 10.0.0.0/24 to AS3.		announcing prefix 10.0.0.0/24 to AS3.
	Such technique is useful for operators to tweak routing decisions in		Such technique is useful for operators to tweak routing decisions in
	order to align with complex transit policies. We will see in later		order to align with complex transit policies. We will see in later
	sections that by producing the same effect as filtering, they can		sections that by producing the same effect as filtering, they can
	skipping to change at page 7, line 14		skipping to change at page 7, line 14
	3.1. Unexpected traffic Flows		3.1. Unexpected traffic Flows
	The BGP policy of an Internet Service provider includes all actions		The BGP policy of an Internet Service provider includes all actions
	performed over its originated routes and the routes received		performed over its originated routes and the routes received
	externally. One important part of the BGP policy is the selection of		externally. One important part of the BGP policy is the selection of
	the routes that are propagated to each neighboring AS. One of the		the routes that are propagated to each neighboring AS. One of the
	goals of these policies is to allow ISPs to avoid transporting		goals of these policies is to allow ISPs to avoid transporting
	traffic between two ASes without economical gain. For instance, ISPs		traffic between two ASes without economical gain. For instance, ISPs
	typically propagate to their peers only routes coming from its		typically propagate to their peers only routes coming from its
	customers (RFC4384 [6]). We briefly illustrate this operation in		customers (RFC4384 [3]). We briefly illustrate this operation in
	Figure 4. In the figure, AS2 is establishing a settlement free		Figure 4. In the figure, AS2 is establishing a settlement free
	peering with AS1 and AS3. AS2 receives prefix P3/p3, from AS3. AS2,		peering with AS1 and AS3. AS2 receives prefix P3/p3, from AS3. AS2,
	however, is not interested in transporting traffic from AS1 to AS3,		however, is not interested in transporting traffic from AS1 to AS3,
	therefore it does not propagate the prefix to AS1. In the figure, we		therefore it does not propagate the prefix to AS1. In the figure, we
	also show a customer of AS2, AS4, which is announcing prefix P4/p4.		also show a customer of AS2, AS4, which is announcing prefix P4/p4.
	AS2 propagates this prefix to AS1.		AS2 propagates this prefix to AS1.
	,-----. ,-----. ,-----.		,-----. ,-----. ,-----.
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS1 \ / AS2 \ / AS3 \		/ AS1 \ / AS2 \ / AS3 \
	( )-----( )-----( )		( )-----( )-----( )
	\ / P4/p4 \ / \ P3/p3 /		\ / P4/p4 \ / \ P3/p3 /
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	'-----' '-----' '-----'		'-----' '-----' '-----'
	|		|
	|		|
	|		|
	,-----.		,-----.
	,' `.		,' `.
	/ AS4 \		/ AS4 \
	( )		( )
	\ P4/p4 /		\ P4/p4 /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 4: Prefix exchange among four autonomous systems		Figure 4: Prefix exchange among four autonomous systems
	Although ISPs usually implement the aforementioned policies,		Although ISPs usually implement the aforementioned policies,
	unexpected traffic flows may still appear. In Figure 4, unexpected		unexpected traffic flows may still appear. In Figure 4, unexpected
	traffic flows are created, when, despite AS2's policy, traffic		traffic flows are created, when, despite AS2's policy, traffic
	arriving from peer AS1 is received and transported to AS3 by AS2.		arriving from peer AS1 is received and transported to AS3 by AS2.
	These types of traffic flows can arise due to a number of reasons.		These types of traffic flows can arise due to a number of reasons.
	Specifically, in this document we explain how the filtering of		Specifically, in this document we explain how the filtering of
	overlapping prefixes might cause unexpected traffic flows on ASes.		overlapping prefixes might cause unexpected traffic flows on ASes.
	skipping to change at page 8, line 17		skipping to change at page 8, line 17
	In this section, we describe cases in which an AS locally filters an		In this section, we describe cases in which an AS locally filters an
	overlapping prefix. We show that, depending on the BGP policies		overlapping prefix. We show that, depending on the BGP policies
	applied by surrounding ASes, this decision can lead to unexpected		applied by surrounding ASes, this decision can lead to unexpected
	traffic flows.		traffic flows.
	3.1.1.1. Initial setup		3.1.1.1. Initial setup
	We start by describing the basic scenario of this case in Figure 5.		We start by describing the basic scenario of this case in Figure 5.
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS5 `-.		,-'' AS5 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	|/22 `''''''''''''''' |		|/22 `''''''''''''''' |
	|/24 |/22 |		|/24 |/22 |
	| |/24 |		| |/24 |
	| | |		| | |
	| |/22 |/22		| |/22 |/22
	| |/24 |/24		| |/24 |/24
	_,,---.:_ _,,---.._ _,,---.._		_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \		/ AS4 \ / AS2 \ / AS3 \
	| |_________| |________| |		| |_________| |________| |
	| | /22 | |/22 /22| |		| | /22 | |/22 /22| |
	'. ,' /24 . ,'/24 /24 . ,'		'. ,' /24 . ,'/24 /24 . ,'
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''		``---'' ``---'' ``---''
	| |		| |
	|10.0.0.0/24 |10.0.0.0/24		|10.0.0.0/24 |10.0.0.0/24
	|10.0.0.0/22 |10.0.0.0/22		|10.0.0.0/22 |10.0.0.0/22
	| _....---------...._|		| _....---------...._|
	,-'AS1 ``-.		,-'AS1 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 5: Initial Setup Local		Figure 5: Initial Setup Local
	AS1 is a customer of AS2 and AS3. AS2, AS3, and AS4 are customers of		AS1 is a customer of AS2 and AS3. AS2, AS3, and AS4 are customers of
	AS5. AS2 is establishing a peering with AS3 and AS4. AS1 is		AS5. AS2 is establishing a peering with AS3 and AS4. AS1 is
	announcing a covering prefix, 10.0.0.0/22, and an overlapping prefix		announcing a covering prefix, 10.0.0.0/22, and an overlapping prefix
	10.0.0.0/24 to its providers. In the initial setup, AS2 and AS3		10.0.0.0/24 to its providers. In the initial setup, AS2 and AS3
	announce the two prefixes to their peers and transit providers. AS4		announce the two prefixes to their peers and transit providers. AS4
	receives both prefixes from its peer (AS2) and transit provider		receives both prefixes from its peer (AS2) and transit provider
	(AS5). We will consider that AS5 chooses as best path to AS1 the one		(AS5). We will consider that AS5 chooses as best path to AS1 the one
	received from AS3.		received from AS3.
	3.1.1.2. Unexpected traffic flows by local filtering - Case 1		3.1.1.2. Unexpected traffic flows by local filtering - Case 1
	In the next scenarios, we show that if AS4 filters the incoming		In the next scenarios, we show that if AS4 filters the incoming
	overlapping prefix from AS5, there is a situation in which unexpected		overlapping prefix from AS5, there is a situation in which unexpected
	traffic flows are created on other ASes.		traffic flows are created on other ASes.
			____,,................______
			_,.---'''' `''---..._
			,-'' AS5 `-.
			[ /
			-.._ __.-'
			. `'---....______ ______...---''
			|/22 `''''''''''''''' |
			|/24 |/22 |
			| |/24 |
			| | |
			| |/22 |/22
			| | |/24
			_,,---.:_ _,,---.._ _,,---.._
			,' `. ,' `. ,' `.
			/ AS4 \ / AS2 \ / AS3 \
			| |_________| |________| |
			| | /22 | |/22 /22| |
			'. ,' . ,' /24 . ,'
			`. ,' `. ,' `. ,'
			``---'' ``---'' ``---''
			| |
			| |10.0.0.0/24
			|10.0.0.0/22 |10.0.0.0/22
			| _,,..---------...._|
			,-'AS1 ``-.
			/' `.
			`. _,
			`-.._ _,,,'
			`''---------'''
			Figure 6: Unexpected traffic flows by local filtering - Case 1
			Let us assume the scenario illustrated in Figure 6. For this case,
			AS1 only propagates the overlapping prefix to AS3. AS4 receives the
			overlapping prefix only from its transit provider, AS5.
			AS4 now is in a situation in which it would be favorable for it to
			filter the announcement of prefix 10.0.0.0/24 from AS5.
			Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is forwarded
			towards AS2. Because AS2 receives the more specific prefix from AS3,
			traffic from AS4 to prefix 10.0.0.0/24 follows the path
			AS4-AS2-AS3-AS1. AS2's BGP policies are implemented to avoid using
			itself to exchange traffic between AS4 and AS3. However, due to the
			discrepancies of routes from the overlapping and covering prefixes,
			unexpected traffic flows between AS4 and AS3 still exist on AS2's
			network. This situation is economically detrimental for AS2, since
			it forwards traffic from a peer to a non-customer neighbor.
			3.1.1.3. Unexpected traffic flows by local filtering - Case 2
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS5 `-.		,-'' AS5 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	|/22 `''''''''''''''' |		|/22 `''''''''''''''' |
	|/24 |/22 |		|/24 |/22 |
	| |/24 |		| |/24 |
	| | |		| | |
	| |/22 |/22		| |/22 |/22
	| | |/24		| | |/24
	_,,---.:_ _,,---.._ _,,---.._		_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \		/ AS4 \ / AS2 \ / AS3 \
	| |_________| |________| |		| |_________| | | |
	| | /22 | |/22 /22| |		| | /22 | | | |
	'. ,' . ,' /24 . ,'		'. ,' . ,' . ,'
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''		``---'' ``---'' ``---''
	| |		| |
	| |10.0.0.0/24		| |10.0.0.0/24
	|10.0.0.0/22 |10.0.0.0/22		|10.0.0.0/22 |10.0.0.0/22
	| _,,..---------...._|		_;,..---------...._|
	,-'AS1 ``-.		,-'AS1 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 6: Unexpected traffic flows by local filtering - Case 1
	Let us assume the scenario illustrated in Figure 6. For this case,
	AS1 only propagates the overlapping prefix to AS3. AS4 receives the
	overlapping prefix only from its transit provider, AS5.
	AS4 now is in a situation in which it would be favorable for it to
	filter the announcement of prefix 10.0.0.0/24 from AS5.
	Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is forwarded
	towards AS2. Because AS2 receives the more specific prefix from AS3,
	traffic from AS4 to prefix 10.0.0.0/24 follows the path AS4-AS2-AS3-
	AS1. AS2's BGP policies are implemented to avoid using itself to
	exchange traffic between AS4 and AS3. However, due to the
	discrepancies of routes from the overlapping and covering prefixes,
	unexpected traffic flows between AS4 and AS3 still exist on AS2's
	network. This situation is economically detrimental for AS2, since
	it forwards traffic from a peer to a non-customer neighbor.
	3.1.1.3. Unexpected traffic flows by local filtering - Case 2
	____,,................______
	_,.---'''' `''---..._
	,-'' AS5 `-.
	[ /
	-.._ __.-'
	. `'---....______ ______...---''
	|/22 `''''''''''''''' |
	|/24 |/22 |
	| |/24 |
	| | |
	| |/22 |/22
	| | |/24
	_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \
	| |_________| | | |
	| | /22 | | | |
	'. ,' . ,' . ,'
	`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''
	| |
	| |10.0.0.0/24
	|10.0.0.0/22 |10.0.0.0/22
	_;,..---------...._|
	,-'AS1 ``-.
	/' `.
	`. _,
	`-.._ _,,,'
	`''---------'''
	Figure 7: Unexpected traffic flows after local filtering - Case 2		Figure 7: Unexpected traffic flows after local filtering - Case 2
	Let us assume a second case where AS2 and AS3 are not peering and AS1		Let us assume a second case where AS2 and AS3 are not peering and AS1
	only propagates the overlapping prefix to AS3. AS4 receives the		only propagates the overlapping prefix to AS3. AS4 receives the
	overlapping prefix only from its transit provider, AS5. This case is		overlapping prefix only from its transit provider, AS5. This case is
	illustrated in Figure 7.		illustrated in Figure 7.
	Similar to the scenario described in Section 3.1.1.2, AS4 is in a		Similar to the scenario described in Section 3.1.1.2, AS4 is in a
	situation in which it would be favorable to filter the announcement		situation in which it would be favorable to filter the announcement
	of prefix 10.0.0.0/24 from AS5. Subsequently, traffic from AS4 to		of prefix 10.0.0.0/24 from AS5. Subsequently, traffic from AS4 to
	skipping to change at page 12, line 5		skipping to change at page 12, line 25
	3.1.2.1. Initial setup		3.1.2.1. Initial setup
	Let AS1 be a customer of AS2 and AS3. AS1 owns 10.0.0.0/22, which it		Let AS1 be a customer of AS2 and AS3. AS1 owns 10.0.0.0/22, which it
	advertises through AS2 and AS3. Additionally, AS2 and AS3 are peers.		advertises through AS2 and AS3. Additionally, AS2 and AS3 are peers.
	Both AS2 and AS3 select A1's path as best, and propagate it to their		Both AS2 and AS3 select A1's path as best, and propagate it to their
	customers, providers, and peers. Some remote ASes will route traffic		customers, providers, and peers. Some remote ASes will route traffic
	destined to 10.0.0.1 through AS2 while others will route traffic		destined to 10.0.0.1 through AS2 while others will route traffic
	through AS3.		through AS3.
	\ / \ /		\ / \ /
	/22 \ / /22 /22 \ / /22		/22 \ / /22 /22 \ / /22
	,-----. ,-----.		,-----. ,-----.
	,' `. ,' `.		,' `. ,' `.
	/ AS2 \ /22 / AS3 \		/ AS2 \ /22 / AS3 \
	( )-------------( )		( )-------------( )
	\ / /22 \ /		\ / /22 \ /
	`. ,' `. ,'		`. ,' `. ,'
	'-----; / '-----'		'-----; / '-----'
	\ /		\ /
	\ /		\ /
	10.0.0.0/22\ /10.0.0.0/22		10.0.0.0/22\ /10.0.0.0/22
	\ /		\ /
	\ ,-----.'		\ ,-----.'
	,' `.		,' `.
	/ AS1 \		/ AS1 \
	( )		( )
	\ /		\ /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 8: Example scenario		Figure 8: Example scenario
	3.1.2.2. Injection of an overlapping prefix		3.1.2.2. Injection of an overlapping prefix
	Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate		Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate
	this prefix to its customers, providers, and peers, including AS2.		this prefix to its customers, providers, and peers, including AS2.
	From AS2's point of view, the path towards 10.0.0.0/24 is a "peer		From AS2's point of view, the path towards 10.0.0.0/24 is a "peer
	path" and AS2 will only advertise it to its customers. ASes in the		path" and AS2 will only advertise it to its customers. ASes in the
	customer branch of AS2 will receive a path to the /24 that contains		customer branch of AS2 will receive a path to the /24 that contains
	AS3 and AS2. Some multi-homed customers of AS2 may also receive a		AS3 and AS2. Some multi-homed customers of AS2 may also receive a
	path through AS3, but not through AS2, from other peering or provider		path through AS3, but not through AS2, from other peering or provider
	links. Any remote AS that is not lying in the customer branch of		links. Any remote AS that is not lying in the customer branch of
	AS2, will receive a path for 10.0.0.0/24 through AS3 and not through		AS2, will receive a path for 10.0.0.0/24 through AS3 and not through
	AS2.		AS2.
	\ / /22\ / /22		\ / /22\ / /22
	/22 \ / /22 /24 \ / /24		/22 \ / /22 /24 \ / /24
	,-----. ,-----.		,-----. ,-----.
	,' `. /22 ,' `.		,' `. /22 ,' `.
	/ AS2 \ /24 / AS3 \		/ AS2 \ /24 / AS3 \
	( /22:AS1 )-------------( /22:AS1 )		( /22:AS1 )-------------( /22:AS1 )
	\ /24:AS3 / /22 \ /24:AS1 /		\ /24:AS3 / /22 \ /24:AS1 /
	/22 /`. ,' `. ,'		/22 /`. ,' `. ,'
	/24/ '-----; / '-----'		/24/ '-----; / '-----'
	/ \ /		/ \ /
	,---./ \ /		,---./ \ /
	/ \ 10.0.0.0/22\ /10.0.0.0/22		/ \ 10.0.0.0/22\ /10.0.0.0/22
	| AS4 ) \ / 10.0.0.0/24		| AS4 ) \ / 10.0.0.0/24
	\ / \ ,-----.'		\ / \ ,-----.'
	`---' ,' `.		`---' ,' `.
	/ AS1 \		/ AS1 \
	( )		( )
	\ /		\ /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 9: Injection of overlapping prefix		Figure 9: Injection of overlapping prefix
	AS2 only receives traffic destined to 10.0.0.0/24 from its customers,		AS2 only receives traffic destined to 10.0.0.0/24 from its customers,
	which it forwards to its peer AS3. Routing is consistent with usual		which it forwards to its peer AS3. Routing is consistent with usual
	Internet Routing Policies in this case. AS3 could receive traffic		Internet Routing Policies in this case. AS3 could receive traffic
	destined to 10.0.0.0/24 from its customers, providers, and peers,		destined to 10.0.0.0/24 from its customers, providers, and peers,
	which it directly forwards to its customer AS1.		which it directly forwards to its customer AS1.
	3.1.2.3. Creation of unexpected traffic flows by limiting the scope of		3.1.2.3. Creation of unexpected traffic flows by limiting the scope of
	the overlapping prefix		the overlapping prefix
	Now, let us assume that 10.0.0.0/24, which is propagated by AS1 to		Now, let us assume that 10.0.0.0/24, which is propagated by AS1 to
	AS3, is tagged to have AS3 only propagate that path to AS2, using the		AS3, is tagged to have AS3 only propagate that path to AS2, using the
	techniques described in Section 2.2.		techniques described in Section 2.2.
	,-------.		,-------.
	,' `.		,' `.
	/ AS5 \		/ AS5 \
	( /22:AS2 )		( /22:AS2 )
	\ /		\ /
	`. ,'		`. ,'
	'-------' \ / \ /		'-------' \ / \ /
	/22 \ //22 /22 \ //22		/22 \ //22 /22 \ //22
	,-----. ,-----.		,-----. ,-----.
	,' `. /22 ,' `.		,' `. /22 ,' `.
	/ AS2 \ /24 / AS3 \		/ AS2 \ /24 / AS3 \
	( /22:AS1 )-------------( /22:AS1 )		( /22:AS1 )-------------( /22:AS1 )
	\ /24:AS3 / /22 \ /24:AS1 /		\ /24:AS3 / /22 \ /24:AS1 /
	/22 /`. ,' `. ,'		/22 /`. ,' `. ,'
	/24/ '-----; / '-----'		/24/ '-----; / '-----'
	/ \ /		/ \ /
	,---./ \ /		,---./ \ /
	/ \ 10.0.0.0/22\ /10.0.0.0/22		/ \ 10.0.0.0/22\ /10.0.0.0/22
	( AS4 ) \ / 10.0.0.0/24		( AS4 ) \ / 10.0.0.0/24
	\ / \ ,-----.'		\ / \ ,-----.'
	`---' ,' `.		`---' ,' `.
	/ AS1 \		/ AS1 \
	( )		( )
	\ /		\ /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 10: More Specific Injection		Figure 10: More Specific Injection
	From AS2's point of view, such a path is a "peer path" and will only		From AS2's point of view, such a path is a "peer path" and will only
	be advertised by AS2 to its customers.		be advertised by AS2 to its customers.
	ASes that are not customers of AS2 will not receive a path for		ASes that are not customers of AS2 will not receive a path for
	10.0.0.0/24. These ASes will forward packets destined to 10.0.0.0/24		10.0.0.0/24. These ASes will forward packets destined to 10.0.0.0/24
	according to their routing state for 10.0.0.0/22. Let us assume that		according to their routing state for 10.0.0.0/22. Let us assume that
	AS5 is such an AS, and that its best path towards 10.0.0.0/22 is		AS5 is such an AS, and that its best path towards 10.0.0.0/22 is
	skipping to change at page 17, line 5		skipping to change at page 17, line 5
	Anticipant or preventive approaches are those in which the routing		Anticipant or preventive approaches are those in which the routing
	system will not let the unexpected traffic flows actually take place		system will not let the unexpected traffic flows actually take place
	when the configuration scenario is set up.		when the configuration scenario is set up.
	We use the scenario depicted in Figure 11 to describe these two kinds		We use the scenario depicted in Figure 11 to describe these two kinds
	of approaches. Based on our analysis, we observe that anticipant		of approaches. Based on our analysis, we observe that anticipant
	approaches can be complex to implement and can lead to undesired		approaches can be complex to implement and can lead to undesired
	repercussions. Therefore, we conclude that the reactive approach is		repercussions. Therefore, we conclude that the reactive approach is
	the more reasonable recommendation to deal with unexpected flows.		the more reasonable recommendation to deal with unexpected flows.
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS5 `-.		,-'' AS5 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	|/22 `''''''''''''''' |		|/22 `''''''''''''''' |
	|/24 |/22 |		|/24 |/22 |
	| |/24 |		| |/24 |
	| | |		| | |
	| |/22 |/22		| |/22 |/22
	| | |/24		| | |/24
	_,,---.:_ _,,---.._ _,,---.._		_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \		/ AS4 \ / AS2 \ / AS3 \
	| |_________| | | |		| |_________| | | |
	| | /22 | | | |		| | /22 | | | |
	'. ,' . ,' . ,'		'. ,' . ,' . ,'
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''		``---'' ``---'' ``---''
	| |		| |
	| |10.0.0.0/24		| |10.0.0.0/24
	|10.0.0.0/22 |10.0.0.0/22		|10.0.0.0/22 |10.0.0.0/22
	_;,..---------...._|		_;,..---------...._|
	,-'AS1 ``-.		,-'AS1 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 11: Anticipant counter-measures - Base example		Figure 11: Anticipant counter-measures - Base example
	5.1. Reactive counter-measures		5.1. Reactive counter-measures
	An operator who detects unexpected traffic flows originated by any of		An operator who detects unexpected traffic flows originated by any of
	the cases described in Section 3 can contact the ASes that are likely		the cases described in Section 3 can contact the ASes that are likely
	to have performed the propagation tweaks, inform them of the		to have performed the propagation tweaks, inform them of the
	situation, and persuade them to change their behavior.		situation, and persuade them to change their behavior.
	skipping to change at page 19, line 11		skipping to change at page 19, line 11
	prefix be dropped while they are sent from a neighboring AS that		prefix be dropped while they are sent from a neighboring AS that
	cannot know about policy conflicts and hence had no means to avoid		cannot know about policy conflicts and hence had no means to avoid
	the creation of unexpected traffic flows.		the creation of unexpected traffic flows.
	5.2.2. Automatic overlapping prefix filtering		5.2.2. Automatic overlapping prefix filtering
	As described in Section 3, filtering of overlapping prefixes can in		As described in Section 3, filtering of overlapping prefixes can in
	some scenarios lead to unexpected traffic flows. Nevertheless,		some scenarios lead to unexpected traffic flows. Nevertheless,
	depending on the autonomous system implementing such practice, this		depending on the autonomous system implementing such practice, this
	operation can prevent these cases. This can be illustrated using the		operation can prevent these cases. This can be illustrated using the
	example described in Figure 11: if AS2 or AS3 filter prefix		example described in Figure 11: if AS2 or AS3 filter prefix 10.0.0.0/
	10.0.0.0/24, there would be no unexpected traffic flow in AS2.		24, there would be no unexpected traffic flow in AS2. Nevertheless,
	Nevertheless, as described in Section 5.1, the filtering of		as described in Section 5.1, the filtering of overlapping prefixes
	overlapping prefixes can generate conflicts between AS1 and AS2,		can generate conflicts between AS1 and AS2, since AS2 would not
	since AS2 would not forward traffic according to AS1's policy.		forward traffic according to AS1's policy. Additionally, AS2 can
	Additionally, AS2 can lose traffic share for the overlapping prefix		lose traffic share for the overlapping prefix from customers
	from customers different from AS1.		different from AS1.
	5.2.3. Neighbor-specific forwarding		5.2.3. Neighbor-specific forwarding
	An operator can technically ensure that traffic destined to a given		An operator can technically ensure that traffic destined to a given
	prefix will be forwarded from an entry point of the network based		prefix will be forwarded from an entry point of the network based
	only on the set of paths that have been advertised over that entry		only on the set of paths that have been advertised over that entry
	point.		point.
	As an example, let us analyze the scenario of Figure 11 from the		As an example, let us analyze the scenario of Figure 11 from the
	point of view of AS2. The edge router connecting to the AS4 forward		point of view of AS2. The edge router connecting to the AS4 forward
	skipping to change at page 19, line 39		skipping to change at page 19, line 39
	will forward packets destined to prefix 10.0.0.0/22 towards AS1. The		will forward packets destined to prefix 10.0.0.0/22 towards AS1. The
	router, however, only propagates the path of the covering prefix		router, however, only propagates the path of the covering prefix
	(10.0.0.0/22) to AS4. An operator could implement the necessary		(10.0.0.0/22) to AS4. An operator could implement the necessary
	techniques to force the edge router to forward packets coming from		techniques to force the edge router to forward packets coming from
	AS4 based only on the paths propagated to AS4. Thus, the edge router		AS4 based only on the paths propagated to AS4. Thus, the edge router
	would forward packets destined to 10.0.0.0/24 towards AS1 in which		would forward packets destined to 10.0.0.0/24 towards AS1 in which
	case no unexpected traffic flow would occur.		case no unexpected traffic flow would occur.
	Different techniques could provide the functionality just described;		Different techniques could provide the functionality just described;
	however, their technical implementation can be complex to design and		however, their technical implementation can be complex to design and
	operate. [2] describes an approach to implement this behavior.		operate. [2] describes an approach to implement this behavior.
	Similar to the solution described in Section 5.2.2, this approach		Similar to the solution described in Section 5.2.2, this approach
	could create conflicts between AS2 and AS1, since the traffic		could create conflicts between AS2 and AS1, since the traffic
	forwarding performed by A2 goes against the policy of AS1.		forwarding performed by A2 goes against the policy of AS1.
	6. Conclusions		6. Conclusions
	In this document, we described threats to policies of autonomous		In this document, we described threats to policies of autonomous
	systems caused by the filtering of overlapping prefixes performed by		systems caused by the filtering of overlapping prefixes performed by
	external networks. We provide examples of scenarios in which		external networks. We provide examples of scenarios in which
	unexpected traffic flows are caused by these practices and introduce		unexpected traffic flows are caused by these practices and introduce
	skipping to change at page 20, line 13		skipping to change at page 20, line 12
	different options for dealing with this kind of problems, we		different options for dealing with this kind of problems, we
	recommend potential victims to implement monitoring systems that can		recommend potential victims to implement monitoring systems that can
	detect them and react to them according to the specific situation.		detect them and react to them according to the specific situation.
	Although we observe that there are reasonable situations in which		Although we observe that there are reasonable situations in which
	ASes could filter overlapping prefixes, we encourage that network		ASes could filter overlapping prefixes, we encourage that network
	operators implement this type of filters only after considering the		operators implement this type of filters only after considering the
	cases described in this document.		cases described in this document.
	7. References		7. References
	[1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM		[1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM
	Computer Communication Review vol. 38, no. 2, pp. 55-59,		SIGCOMM Computer Communication Review vol. 38, no. 2, pp.
	April 2008.		55-59, April 2008.
	[2] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford,		[2] Vanbever, L., Francois, P., Bonaventure, O., and J.
	"Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco		Rexford, "Customized BGP Route Selection Using BGP/MPLS
	Systems, Routing		VPNs", Cisco Systems, Routing Symposium
	Symposium http://www.cs.princeton.edu/~jrex/talks/		http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf,
	cisconag09.pdf, October 2009.		October 2009.
	[3] "INIT7-RIPE63", <http://ripe63.ripe.net/presentations/		[3] "INIT7-RIPE63", <http://ripe63.ripe.net/presentations/48
	48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.		-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
	[4] <http://www.ietf.org/rfc/rfc1812.txt>		7.2. URIs
	[5] <http://tools.ietf.org/html/		[1] http://www.ietf.org/rfc/rfc1812.txt
	draft-white-grow-overlapping-routes-02>
	[6] <http://www.ietf.org/rfc/rfc4384.txt>		[2] http://tools.ietf.org/html/draft-white-grow-overlapping-routes-02
			[3] http://www.ietf.org/rfc/rfc4384.txt
	Authors' Addresses		Authors' Addresses
	Camilo Cardona		Camilo Cardona
	IMDEA Networks/UC3M		IMDEA Networks/UC3M
	Avenida del Mar Mediterraneo, 22		Avenida del Mar Mediterraneo, 22
	Leganes 28919		Leganes 28919
	Spain		Spain
	Email: juancamilo.cardona@imdea.org		Email: juancamilo.cardona@imdea.org
	skipping to change at page 21, line 4		skipping to change at page 20, line 42
	Authors' Addresses		Authors' Addresses
	Camilo Cardona		Camilo Cardona
	IMDEA Networks/UC3M		IMDEA Networks/UC3M
	Avenida del Mar Mediterraneo, 22		Avenida del Mar Mediterraneo, 22
	Leganes 28919		Leganes 28919
	Spain		Spain
	Email: juancamilo.cardona@imdea.org		Email: juancamilo.cardona@imdea.org
	Pierre Francois		Pierre Francois
	IMDEA Networks		IMDEA Networks
	Avenida del Mar Mediterraneo, 22		Avenida del Mar Mediterraneo, 22
	Leganes 28919		Leganes 28919
	Spain		Spain
	Email: pierre.francois@imdea.org		Email: pierre.francois@imdea.org
			Paolo Lucente
			Cisco Systems
			170 W. Tasman Drive
			San Jose, CA 95134
			USA
			Email: plucente@cisco.com
End of changes. 35 change blocks.
	305 lines changed or deleted		310 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/