draft-ietf-grow-filtering-threats-08.txt		rfc7789.txt
	Network Working Group Camilo Cardona		Internet Engineering Task Force (IETF) C. Cardona
	Internet-Draft IMDEA Networks/UC3M		Request for Comments: 7789 IMDEA Networks/UC3M
	Intended status: Informational Pierre Francois		Category: Informational P. Francois
	Expires: May 11, 2016 Paolo Lucente		ISSN: 2070-1721 P. Lucente
	Cisco Systems		Cisco Systems
	November 08, 2015		April 2016
	Impact of BGP filtering on Inter-Domain Routing Policies		Impact of BGP Filtering on Inter-Domain Routing Policies
	draft-ietf-grow-filtering-threats-08
	Abstract		Abstract
	This document describes how unexpected traffic flows can emerge		This document describes how unexpected traffic flows can emerge
	across an autonomous system, as the result of other autonomous		across an autonomous system as the result of other autonomous systems
	systems filtering, or restricting the propagation of more specific		filtering or restricting the propagation of more-specific prefixes.
	prefixes. We provide a review of the techniques to detect the		We provide a review of the techniques to detect the occurrence of
	occurrence of this issue and defend against it.		this issue and defend against it.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on May 11, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7789.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4		2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
	2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4		2.1. Local Filtering . . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. Unexpected traffic flows caused by local filtering of		2.1.1. Unexpected Traffic Flows Caused by Local Filtering of
	more specific prefixes . . . . . . . . . . . . . . . 5		More-Specific Prefixes . . . . . . . . . . . . . . . 5
	2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6		2.2. Remote Filtering . . . . . . . . . . . . . . . . . . . . 6
	2.2.1. Unexpected traffic flows caused by remotely triggered		2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered
	filtering of more specific prefixes . . . . . . . . . 7		Filtering of More-Specific Prefixes . . . . . . . . . 7
	3. Techniques to detect unexpected traffic flows caused by		3. Techniques to Detect Unexpected Traffic Flows Caused by
	filtering of more specific prefixes . . . . . . . . . . . . . 8		Filtering of More-Specific Prefixes . . . . . . . . . . . . . 8
	3.1. Existence of unexpected traffic flows within an AS . . . 8		3.1. Existence of Unexpected Traffic Flows within an AS . . . 8
	3.2. Contribution to the existence of unexpected traffic flows		3.2. Contribution to the Existence of Unexpected Traffic Flows
	in another AS . . . . . . . . . . . . . . . . . . . . . . 9		in Another AS . . . . . . . . . . . . . . . . . . . . . . 9
	4. Techniques to Traffic Engineer unexpected flows . . . . . . . 10		4. Techniques to Traffic Engineer Unexpected Flows . . . . . . . 10
	4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11		4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
	4.2. Proactive measures . . . . . . . . . . . . . . . . . . . 12		4.2. Proactive Measures . . . . . . . . . . . . . . . . . . . 12
	4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12		4.2.1. Access Lists . . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13		4.2.2. Neighbor-Specific Forwarding . . . . . . . . . . . . 13
	5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Informative References . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	It is common practice for network operators to propagate a more		It is common practice for network operators to propagate a more-
	specific prefix in the BGP routing system, along with the less		specific prefix in the BGP routing system along with the less-
	specific prefix that they originate. It is also possible for some		specific prefix that they originate. It is also possible for some
	Autonomous Systems (ASes) to apply different policies to the more		Autonomous Systems (ASes) to apply different policies to the more
	specific and the less specific prefix.		specific and the less-specific prefix.
	Although BGP makes independent, policy driven decisions for the		Although BGP makes independent, policy-driven decisions for the
	selection of the best path to be used for a given IP prefix, routers		selection of the best path to be used for a given IP prefix, 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 [RFC1812]). The existence of a		"precedes" any BGP policy [RFC1812]. The existence of a prefix p
	prefix p that is more specific than a prefix p' in the Forwarding		that is more specific than a prefix p' in the Forwarding Information
	Information Base (FIB) will let packets whose destination matches p		Base (FIB) will let packets whose destination matches p be forwarded
	be forwarded according to the next hop selected as best for p (the		according to the next hop selected as best for p (the more-specific
	more specific prefix). This process takes place by disregarding the		prefix). This process takes place by disregarding the policies
	policies applied in the control plane for the selection of the best		applied in the control plane for the selection of the best next hop
	next-hop for p'. When an Autonomous System filters more specific		for p'. When an AS filters more-specific prefixes and forwards
	prefixes and forwards packets according to the less specific prefix,		packets according to the less-specific prefix, the discrepancy among
	the discrepancy among the routing policies applied to the less and		the routing policies applied to the less and the more-specific
	the more specific prefixes can create unexpected traffic flows.		prefixes can create unexpected traffic flows. These may infringe on
	These may infringe the policies of other ASes, still holding a path		the policies of other ASes still holding a path towards the more-
	towards the more specific prefix.		specific prefix.
	The objective of this draft is to shed light on possible side effects		The objective of this document is to shed light on possible side
	associated with more specific prefix filtering. Such actions can be		effects associated with more-specific prefix filtering. Such actions
	explained by traffic engineering action, misconfiguration, or		can be explained by traffic engineering action, misconfiguration, or
	malicious intent. This document presents examples of such side		malicious intent. This document presents examples of such side
	effects and discusses approaches towards solutions to the problem.		effects and discusses approaches towards solutions to the problem.
	The rest of the document is organized as follows: In Section 2 we		The rest of the document is organized as follows: in Section 2 we
	provide some scenarios in which the filtering of more specific		provide some scenarios in which the filtering of more-specific
	prefixes leads to the creation of unexpected traffic flows.		prefixes leads to the creation of unexpected traffic flows; Section 3
	Section 3 and Section 4 discuss some techniques that ASes can use		and Section 4 discuss some techniques that ASes can use for,
	for, respectively, detecting and reacting to unexpected traffic		respectively, detecting and reacting to unexpected traffic flows; and
	flows. The document concludes in Section 5.		the document concludes in Section 5.
	1.1. Terminology		1.1. Terminology
	More specific prefix: A prefix in the routing table with an address		More-specific prefix: A prefix in the routing table with an address
	range that is covered by a shorter prefix also present in the routing		range that is covered by a shorter prefix also present in the
	table.		routing table.
	Less specific prefix: A prefix in the routing table with an address		Less-specific prefix: A prefix in the routing table with an address
	range partially covered by other prefixes.		range partially covered by other prefixes.
	This document reuses the definitions of customer-transit peering and		Customer-provider peering: A peering arrangement in which a transit
	settlement-free peering of RFC4384 [RFC4384].		network provides connectivity to a customer in exchange of a fee,
			as derived from RFC 4384 [RFC4384].
	Selective advertisement: The behavior of only advertising a self		Settlement-free peering: A peering arrangement in which two networks
	originated BGP path for a prefix over a strict subset of the eBGP		agree on a settlement-free traffic exchange, typically covering
	sessions of the AS.		only their customer traffic, as derived from RFC 4384 [RFC4384].
	Selective propagation: The behavior of only propagating a BGP path		Selective advertisement: The behavior of only advertising a self
	for a prefix over a strict subset of the eBGP sessions of an AS.		originated BGP path for a prefix over a strict subset of the
			External BGP (eBGP) sessions of the AS.
	Local filtering: The behavior of explicitly ignoring a BGP path		Selective propagation: The behavior of only propagating a BGP path
	received over an eBGP session.		for a prefix over a strict subset of the eBGP sessions of an AS.
	Remote filtering: The behavior of triggering selective propagation of		Local filtering: The behavior of explicitly ignoring a BGP path
	a BGP path at a distant AS. Note that this is typically achieved by		received over an eBGP session.
	tagging a self-originated path with BGP communities defined by the
	distant AS.
	Unexpected traffic flow: Traffic flowing between two neighboring ASes		Remote filtering: The behavior of triggering selective propagation
	of an AS, although the transit policy of that AS is to not provide		of a BGP path at a distant AS. Note that this is typically
	connectivity between these two neighbors. A traffic flow across an		achieved by tagging a self-originated path with BGP communities
	AS, between two of its transit providers, or between a transit		defined by the distant AS.
	provider and one of its settlement-free peers, are classical examples
	of unexpected traffic flows.		Unexpected traffic flow: Traffic flowing between two neighboring
			ASes of an AS, although the transit policy of that AS is to not
			provide connectivity between these two neighbors. A traffic flow
			across an AS between two of its transit providers or between a
			transit provider and one of its settlement-free peers are classic
			examples of unexpected traffic flows.
	2. Unexpected Traffic Flows		2. Unexpected Traffic Flows
	In this section, we describe how more specific prefix filtering can		In this section, we describe how more-specific prefix filtering can
	lead to unexpected traffic flows in other, remote, ASes. We		lead to unexpected traffic flows in other, remote, ASes. We
	differentiate cases in which the filtering is performed locally from		differentiate cases in which the filtering is performed locally from
	those where the filtering is triggered remotely.		those where the filtering is triggered remotely.
	2.1. Local filtering		2.1. Local Filtering
	Different reasons motivate local filtering, for example: (1) Traffic		Different reasons motivate local filtering, for example:
	engineering, where an AS wants to control its local outbound traffic
	distribution using only the policy applied to the less specific		Traffic engineering: An ISP can decide to filter more-specific
	prefix. Such a practice was notably documented in [INIT7-RIPE63] (2)		prefixes when it wants to control their local outbound traffic
	Enforcing contract compliance, where, for instance, an AS avoids a		distribution using only the policy applied to the less-specific
	settlement-free peer to attract traffic to one link by using		prefix. Such a practice was notably documented in a presentation
	selective advertisement, when this is not allowed by their peering		by Init7 [INIT7-RIPE63].
	agreement. (3) The need for Forwarding Information Base memory
	preservation sometimes pushes ISP operators to filter more specific		Enforcing contract compliance: An ISP can decide to filter more-
	prefixes.		specific prefixes to enforce clauses of their peering agreements.
			For instance, a settlement-free peer of an ISP can use selective
			advertisement of more-specific prefixes to attract traffic to one
			link. If this practice is not allowed by their peering agreement,
			the ISP can filter the more-specific prefixes to prevent it.
			Memory preservation: An ISP can decide to filter more-specific
			prefixes in order to preserve FIB memory of their routers.
	Figure 1 illustrates a scenario where one AS performs local filtering		Figure 1 illustrates a scenario where one AS performs local filtering
	due to outbound traffic engineering. The figure depicts AS64504, and		due to outbound traffic engineering. The figure depicts AS64504 and
	two of its neighboring ASes, AS64502, and AS64505. AS64504 has a		two of its neighboring ASes, AS64502 and AS64505. AS64504 has a
	settlement-free peering with AS64502 and is a customer of AS64505.		settlement-free peering with AS64502 and is a customer of AS64505.
	AS64504 receives from AS64505 prefixes 2001:DB8::/32 and		AS64504 receives from AS64505 prefixes 2001:DB8::/32 and
	2001:DB8::/34. AS64504 only receives the less specific prefix		2001:DB8::/34. AS64504 only receives the less-specific prefix
	2001:DB8::/32 from AS64502.		2001:DB8::/32 from AS64502.
	,-----.		,-----.
	/ \		/ \
	( AS64505 )		( AS64505 )
	\ /		\ /
	`--+--'		`--+--'
	2001:DB8::/32 | |		2001:DB8::/32 | |
	2001:DB8::/34 v |		2001:DB8::/34 v |
	|		|
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	\ / \ /		\ / \ /
	`-----' `-----'		`-----' `-----'
	Figure 1: Local Filtering		Figure 1: Local Filtering
	Due to economic reasons, AS64504 might prefer to send traffic to		Due to economic reasons, AS64504 might prefer to send traffic to
	AS64502 instead of AS64505. However, even if paths received from		AS64502 instead of AS64505. However, even if paths received from
	AS64502 are given a large local preference, routers in AS64504 will		AS64502 are given a large local preference, routers in AS64504 will
	still send traffic to prefix 2001:DB8::/34 via neighbor AS64505.		still send traffic to prefix 2001:DB8::/34 via neighbor AS64505.
	This situation may push AS64504 to apply an inbound filter for the		This situation may push AS64504 to apply an inbound filter for the
	more specific prefix, 2001:DB8::/34, on the session with AS64505.		more-specific prefix, 2001:DB8::/34, on the session with AS64505.
	After applying the filter, AS64504 will send traffic for the more		After applying the filter, AS64504 will send traffic for the more-
	specific prefix to AS64502.		specific prefix to AS64502.
	2.1.1. Unexpected traffic flows caused by local filtering of more		2.1.1. Unexpected Traffic Flows Caused by Local Filtering of More-
	specific prefixes		Specific Prefixes
	In this section, we show how the decision of AS64504 to perform local		In this section, we show how the decision of AS64504 to perform local
	filtering creates unexpected traffic flows in AS64502. Figure 2		filtering creates unexpected traffic flows in AS64502. Figure 2
	shows the whole picture of the scenario; where AS64501 is a customer		shows the whole picture of the scenario where AS64501 is a customer
	of AS64503 and AS64502. AS64503 is a settlement-free peer with		of AS64503 and AS64502. AS64503 is a settlement-free peer with
	AS64502. AS64503 and AS64502 are customers of AS64505. The AS		AS64502. AS64503 and AS64502 are customers of AS64505. The AS
	originating the two prefixes, AS64501, performs selective		originating the two prefixes, AS64501, performs selective
	advertisement with the more specific prefix and only announces it to		advertisement with the more-specific prefix and only announces it to
	AS64503.		AS64503.
	After AS64504 locally filters the more specific prefix, traffic from		After AS64504 locally filters the more-specific prefix, traffic from
	AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502.		AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502.
	Because AS64502 receives the more specific prefix from AS64503,		Because AS64502 receives the more-specific prefix from AS64503,
	traffic from AS64504 to 2001:DB8::/34 follows the path		traffic from AS64504 to 2001:DB8::/34 follows the path
	AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are		AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are
	implemented to avoid transporting traffic between AS64504 and		implemented to avoid transporting traffic between AS64504 and
	AS64503. However, due to the discrepancies of routes between the		AS64503. However, due to the discrepancies of routes between the
	more and the less specific prefixes, unexpected traffic flows between		more and the less-specific prefixes, unexpected traffic flows between
	AS64504 and AS64503 exist in AS64502's network.		AS64504 and AS64503 exist in AS64502's network.
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS64505 `-.		,-'' AS64505 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	+ |/32 `''''''''''''''' |		+ |/32 `''''''''''''''' |
	| |/34 + |/32 |		| |/34 + |/32 |
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	| ^ |		| ^ |
	^ |2001:DB8::/32 | |2001:DB8::/32		^ |2001:DB8::/32 | |2001:DB8::/32
	| | + |2001:DB8::/34		| | + |2001:DB8::/34
	+ | _....---------...._|		+ | _....---------...._|
	,-'AS64501 ``-.		,-'AS64501 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 2: Unexpected traffic flows due to local filtering		Figure 2: Unexpected Traffic Flows Due to Local Filtering
	2.2. Remote filtering		2.2. Remote 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 [on_BGP_communities]. Some ISPs allow		ASes that handle these paths; see a paper from 2008 by Donnet and
	their customers to use such communities to let the receiving AS not		Bonaventure [on_BGP_communities]. Some ISPs allow their customers to
	export the path to some selected neighboring ASes. By combining		use such communities to let the receiving AS not export the path to
	communities, the prefix could be advertised only to a given peer of		some selected neighboring ASes. By combining communities, the prefix
	the AS providing this feature. A network operator can leverage		could be advertised only to a given peer of the AS providing this
	remote filtering to, for instance, limit the scope of prefixes and		feature. A network operator can leverage remote filtering to, for
	hence perform a more granular inbound traffic engineering.		instance, limit the scope of prefixes and hence perform more granular
			inbound traffic engineering.
	Figure 3 illustrates a scenario in which an AS uses BGP communities		Figure 3 illustrates a scenario in which an AS uses BGP communities
	to command its provider to selectively propagate a more specific		to command its provider to selectively propagate a more-specific
	prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501		prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501
	originates prefix 2001:DB8::/32, which it advertises to AS64502 and		originates prefix 2001:DB8::/32, which it advertises to AS64502 and
	AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501		AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501
	do selective advertisement and only propagate 2001:DB8::/34 over		do selective advertisement and only propagate 2001:DB8::/34 over
	AS64503. AS64503 would normally propagate this prefix to its		AS64503. AS64503 would normally propagate this prefix to its
	customers, providers, and peers, including AS64502.		customers, providers, and peers, including AS64502.
	Let us consider that AS64501 decides to limit the scope of the more		Let us consider that AS64501 decides to limit the scope of the more-
	specific prefix. AS64501 can make this decision based on its traffic		specific prefix. AS64501 can make this decision based on its traffic
	engineering strategy. To achieve this, AS64501 can tag the more		engineering strategy. To achieve this, AS64501 can tag the more-
	specific prefix with a set of communities that leads AS64503 to only		specific prefix with a set of communities that leads AS64503 to only
	propagate the path to AS64502.		propagate the path to AS64502.
	^ \ / ^ ^ \ / ^		^ \ / ^ ^ \ / ^
	| /32 \ / /32 | | /32 \ / /32 |		| /32 \ / /32 | | /32 \ / /32 |
	,-----. ,-----.		,-----. ,-----.
	,' `. ,' `.		,' `. ,' `.
	/ AS64502 \ / AS64503 \		/ AS64502 \ / AS64503 \
	( )-------------( )		( )-------------( )
	\ / /32 /32 \ /		\ / /32 /32 \ /
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 41 ¶
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ ,-----.' | 2001:DB8::/32		| \ ,-----.' | 2001:DB8::/32
	| ,' `. | 2001:DB8::/34		| ,' `. | 2001:DB8::/34
	2001:DB8::/32 +-- / AS64501 \ --+		2001:DB8::/32 +-- / AS64501 \ --+
	( )		( )
	\ /		\ /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 3: Remote triggered filtering		Figure 3: Remote-Triggered Filtering
	2.2.1. Unexpected traffic flows caused by remotely triggered filtering		2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered Filtering
	of more specific prefixes		of More-Specific Prefixes
	Figure 4 expands the scenario from Figure 3 and includes other ASes		Figure 4 expands the scenario from Figure 3 and includes other ASes
	peering with AS64502 and AS64503. Due to the limitation on the scope		peering with AS64502 and AS64503. Due to the limitation on the scope
	performed on the more specific prefix, ASes that are not customers of		performed on the more-specific prefix, ASes that are not customers of
	AS64502 will not receive a path for 2001:DB8::/34. These ASes will		AS64502 will not receive a path for 2001:DB8::/34. These ASes will
	forward packets destined to 2001:DB8::/34 according to their routing		forward packets destined to 2001:DB8::/34 according to their routing
	state for 2001:DB8::/32. Let us assume that AS64505 is such an AS,		state for 2001:DB8::/32. Let us assume that AS64505 is such an AS
	and that its best path towards 2001:DB8::/32 is through AS64502.		and that its best path towards 2001:DB8::/32 is through AS64502.
	Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502.		Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502.
	However, in the data-plane of the nodes of AS64502, the longest		However, in the data plane of the nodes of AS64502, the longest
	prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached		prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached
	through AS64503, a settlement-free peer of AS64502. Since AS64505 is		through AS64503, a settlement-free peer of AS64502. Since AS64505 is
	not in the customer branch of AS64502, traffic flows between two non-		not in the customer branch of AS64502, traffic flows between two
	customer ASes in AS64502.		noncustomer ASes in AS64502.
	,-----.		,-----.
	,' `.		,' `.
	/ AS64505 \		/ AS64505 \
	( )		( )
	\ /		\ /
	,`. ,' \		,`. ,' \
	/ '-----' \		/ '-----' \
	/ ^ ^ \		/ ^ ^ \
	/32 | | /32 '		/32 | | /32 '
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 40 ¶
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ ,-----.' | 2001:DB8::/32		| \ ,-----.' | 2001:DB8::/32
	| ,' `. | 2001:DB8::/34		| ,' `. | 2001:DB8::/34
	2001:DB8::/32 +--+ / AS64501 \ +--+		2001:DB8::/32 +--+ / AS64501 \ +--+
	( )		( )
	\ /		\ /
	`. ,'		`. ,'
	'-----'		'-----'
	Figure 4: Unexpected traffic flows due to remote triggered filtering		Figure 4: Unexpected Traffic Flows Due to Remote-Triggered Filtering
	3. Techniques to detect unexpected traffic flows caused by filtering of		3. Techniques to Detect Unexpected Traffic Flows Caused by Filtering of
	more specific prefixes		More-Specific Prefixes
	3.1. Existence of unexpected traffic flows within an AS		3.1. Existence of Unexpected Traffic Flows within an AS
	To detect if unexpected traffic flows are taking place in its		To detect if unexpected traffic flows are taking place in its
	network, an ISP can monitor its traffic data to check if it is		network, an ISP can monitor its traffic data to check if it is
	providing transit between two of its peers, although this policy is		providing transit between two of its peers, although its policy is
	configured to not provide such transit. IPFIX (RFC7011 [RFC7011]) is		configured to not provide such transit. IPFIX [RFC7011] is an
	an example of a technology that can be used to export information		example of a technology that can be used to export information
	regarding traffic flows across the network. Traffic information must		regarding traffic flows across the network. Traffic information must
	be analyzed under the perspective of the business relationships with		be analyzed under the perspective of the business relationships with
	neighboring ASes to detect the flows not fitting the policy.		neighboring ASes to detect the flows not fitting the policy.
	Operators can use collection systems that combine traffic statistics		Operators can use collection systems that combine traffic statistics
	with policy information for this end. Check [PMACCT] for an open		with policy information for this end. See the pmacct project
	source application meeting these requirements.		[PMACCT] for an open-source application meeting these requirements.
	Note that the AS detecting the unexpected traffic flow may simply		Note that the AS detecting the unexpected traffic flow may simply
	realize that this policy configuration is broken. The first		realize that its policy configuration is broken. The first
	recommended action upon detection of an unexpected traffic flow is to		recommended action upon detection of an unexpected traffic flow is to
	verify the correctness of the BGP configuration.		verify the correctness of the BGP configuration.
	Once the local configuration is confirmed correct, the operator		Once the local configuration is confirmed correct, the operator
	should check if the unexpected flow arose due to filtering of BGP		should check if the unexpected flow arose due to filtering of BGP
	paths for more-specific prefixes by neighboring ASes. This can be		paths for more-specific prefixes by neighboring ASes. This can be
	performed in two steps. First, the operator should check whether the		performed in two steps. First, the operator should check whether the
	neighboring AS originating the unexpected flow is forwarding traffic		neighboring AS originating the unexpected flow is forwarding traffic
	using a less-specific prefix that is announced to it by the affected		using a less-specific prefix that is announced to it by the affected
	network. The second step is to try to infer the reason why the		network. The second step is to try to infer the reason why the
	neighboring AS does not use the more specific path for forwarding,		neighboring AS does not use the more-specific path for forwarding,
	i.e., finding why the more specific prefix was filtered. Due to the		i.e., finding why the more-specific prefix was filtered. Due to the
	distributed nature and restricted visibility of the steering of BGP		distributed nature and restricted visibility of the steering of BGP
	policies, this second step does not identify the origin of the		policies, this second step does not identify the origin of the
	problem with guaranteed accuracy.		problem with guaranteed accuracy.
	For the first step, the operator should check if the destination		For the first step, the operator should check if the destination
	address of the unexpected traffic flow is locally routed as per a		address of the unexpected traffic flow is locally routed as per a
	more specific prefix only received from non-customer peers. The		more-specific prefix only received from noncustomer peers. The
	operator should also check if there are paths to a less specific		operator should also check if there are paths to a less-specific
	prefix received from a customer, and hence propagated to peers. If		prefix received from a customer and hence propagated to peers. If
	these two situations happen at the same time, the neighboring AS at		these two situations happen at the same time, the neighboring AS at
	the entry point of the unexpected flow is routing the traffic based		the entry point of the unexpected flow is routing the traffic based
	on the less specific prefix, although the ISP is actually forwarding		on the less-specific prefix, although the ISP is actually forwarding
	the traffic via non-customer links.		the traffic via noncustomer links.
	For the second step, one can rely on human interaction or looking		For the second step, one can rely on human interaction or looking
	glasses to find out whether local filtering, remote filtering, or		glasses to find out whether local filtering, remote filtering, or
	selective propagation was performed on the more specific prefix. No		selective propagation was performed on the more-specific prefix. No
	openly available tools that can automatically perform this operation		openly available tools that can automatically perform this operation
	have been identified.		have been identified.
	3.2. Contribution to the existence of unexpected traffic flows in		3.2. Contribution to the Existence of Unexpected Traffic Flows in
	another AS		Another AS
	It can be considered problematic to trigger unexpected traffic flows		It can be considered problematic to trigger unexpected traffic flows
	in another AS. It is thus advisable for an AS to assess the risks of		in another AS. It is thus advisable for an AS to assess the risks of
	filtering more specific prefixes before implementing them, by		filtering more-specific prefixes before implementing them by
	obtaining as much information as possible about its surrounding		obtaining as much information as possible about its surrounding
	routing environment.		routing environment.
	There may be justifiable reasons for one ISP to perform filtering;		There may be justifiable reasons for one ISP to perform filtering:
	either to enforce established policies or to provide prefix		either to enforce established policies or to provide prefix-
	advertisement scoping features to its customers. These can vary from		advertisement scoping features to its customers. These can vary from
	trouble-shooting purposes to business relationship implementations.		troubleshooting purposes to business-relationship implementations.
	Restricting the use of these features for the sake of avoiding the		Restricting the use of these features for the sake of avoiding the
	creation of unexpected traffic flows is not a practical option.		creation of unexpected traffic flows is not a practical option.
	In order to assess the risk of filtering more specific prefixes, the		In order to assess the risk of filtering more-specific prefixes, the
	AS would need information on the routing policies and the		AS would need information on the routing policies and the
	relationships among external ASes, to detect if its actions could		relationships among external ASes to detect if its actions could
	trigger the appearance of unexpected traffic flows. With this		trigger the appearance of unexpected traffic flows. With this
	information, the operator could detect other ASes receiving the more		information, the operator could detect other ASes receiving the more-
	specific prefix from non-customer ASes, while announcing the less		specific prefix from noncustomer ASes while announcing the less-
	specific prefix to other non-customer ASes. If the filtering of the		specific prefix to other noncustomer ASes. If the filtering of the
	more specific prefix leads other ASes to send traffic for the more		more-specific prefix leads other ASes to send traffic for the more-
	specific prefix to these ASes, an unexpected traffic flow can arise.		specific prefix to these ASes, an unexpected traffic flow can arise.
	However, the information required for this operation is difficult to		However, the information required for this operation is difficult to
	obtain since it is frequently considered confidential.		obtain since it is frequently considered confidential.
	4. Techniques to Traffic Engineer unexpected flows		4. Techniques to Traffic Engineer Unexpected Flows
	Network Operators can adopt different approaches with respect to		Network operators can adopt different approaches with respect to
	unexpected traffic flows. Note that due the complexity of inter-		unexpected traffic flows. Note that due to the complexity of inter-
	domain routing policies, there is not a single solution that can be		domain routing policies, there is not a single solution that can be
	applied to all situations. This section provides potential solutions		applied to all situations. This section provides potential solutions
	that ISPs must evaluate against each particular case. We classify		that ISPs must evaluate against each particular case. We classify
	these actions according to whether they are proactive or reactive.		these actions according to whether they are proactive or reactive.
	Reactive approaches are those in which the operator tries to detect		Reactive approaches are those in which the operator tries to detect
	the situations via monitoring and solve unexpected traffic flows,		the situations via monitoring and solve unexpected traffic flows
	manually, on a case-by-case basis.		manually on a case-by-case basis.
	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 scenario arises.		when the scenario arises.
	We use the scenario depicted in Figure 5 to describe these two kinds		We use the scenario depicted in Figure 5 to describe these two kinds
	of approaches. Since proactive approaches can be complex to		of approaches. Since proactive approaches can be complex to
	implement and can lead to undesired effects, the reactive approach is		implement and can lead to undesired effects, the reactive approach is
	the more reasonable recommendation to deal with unexpected flows.		the more reasonable recommendation to deal with unexpected flows.
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 35 ¶
	| ^ |		| ^ |
	^ |2001:DB8::/32 | |2001:DB8::/32		^ |2001:DB8::/32 | |2001:DB8::/32
	| | + |2001:DB8::/34		| | + |2001:DB8::/34
	+ | _....---------...._|		+ | _....---------...._|
	,-'AS64501 ``-.		,-'AS64501 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 5: Traffic Engineering of unexpected traffic flows - Base		Figure 5: Traffic Engineering of Unexpected Traffic Flows -
	example		Base Example
	4.1. Reactive Traffic Engineering		4.1. Reactive Traffic Engineering
	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 2 can contact the ASes that are likely		the cases described in Section 2 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.
	If the situation remains, the operator can implement prefix filtering		If the situation remains, the operator can implement prefix filtering
	in order to stop the unexpected flows. The operator can decide to		in order to stop the unexpected flows. The operator can decide to
	perform this action over the session with the operator announcing the		perform this action over the session with the operator announcing the
	more specific prefix or over the session with the neighboring AS from		more-specific prefix or over the session with the neighboring AS from
	which it is receiving the traffic. Each of these options carry a		which it is receiving the traffic. Each of these options carry a
	different repercussion for the affected AS. We briefly describe the		different repercussion for the affected AS. We briefly describe the
	two alternatives.		two alternatives.
	o An operator can decide to stop announcing the less specific prefix		o An operator can decide to stop announcing the less-specific prefix
	at the peering session with the neighboring AS from which it is		at the peering session with the neighboring AS from which it is
	receiving traffic to the more specific prefix. In the example of		receiving traffic to the more-specific prefix. In the example of
	Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from		Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from
	the eBGP session with AS64504. In this case, traffic heading to		the eBGP session with AS64504. In this case, traffic heading to
	the prefix 2001:DB8::/32 from AS64501 would no longer traverse		the prefix 2001:DB8::/32 from AS64501 would no longer traverse
	AS64502. AS64502 should evaluate if solving the issues originated		AS64502. AS64502 should evaluate if solving the issues originated
	by the unexpected traffic flows are worth the loss of this traffic		by the unexpected traffic flows are worth the loss of this traffic
	share.		share.
	o An operator can decide to filter out the more specific prefix at		o An operator can decide to filter out the more-specific prefix at
	the peering session over which it was received. In the example of		the peering session over which it was received. In the example of
	Figure 5, AS64502 would filter out the incoming prefix		Figure 5, AS64502 would filter out the incoming prefix
	2001:DB8::/34 from the eBGP session with AS64505. As a result,		2001:DB8::/34 from the eBGP session with AS64505. As a result,
	the traffic destined to that /32 would be forwarded by AS64502		the traffic destined to that /32 would be forwarded by AS64502
	along its link with AS64501, despite the actions performed by		along its link with AS64501, despite the actions performed by
	AS64501 to have this traffic coming in through its link with		AS64501 to have this traffic coming in through its link with
	AS64503. However, as AS64502 will no longer know a route to the		AS64503. However, as AS64502 will no longer know a route to the
	more specific prefix, it risks losing the traffic share from		more-specific prefix, it risks losing the traffic share from
	customers different from AS64501 to that prefix. Furthermore,		customers different from AS64501 to that prefix. Furthermore,
	this action can generate conflicts between AS64502 and AS64501,		this action can generate conflicts between AS64502 and AS64501,
	since AS64502 does not follow the routing information expressed by		since AS64502 does not follow the routing information expressed by
	AS64501 in its BGP announcements.		AS64501 in its BGP announcements.
	Note that it is possible that the behavior of the neighboring AS		Note that it is possible that the behavior of the neighboring AS
	causing the unexpected traffic flows violates a contractual agreement		causing the unexpected traffic flows violates a contractual agreement
	between the two networks.		between the two networks.
	4.2. Proactive measures		4.2. Proactive Measures
	4.2.1. Access lists		4.2.1. Access Lists
	An operator could install access-lists to prevent unexpected traffic		An operator could install access lists to prevent unexpected traffic
	flows from happening in the first place. In the example of Figure 5,		flows from happening in the first place. In the example of Figure 5,
	AS64502 would install an access-list denying packets matching		AS64502 would install an access list denying packets matching
	2001:DB8::/34 associated with the interface connecting to AS64504.		2001:DB8::/34 associated with the interface connecting to AS64504.
	As a result, traffic destined to that prefix would be dropped,		As a result, traffic destined to that prefix would be dropped despite
	despite the existence of a valid route towards 2001:DB8::/32.		the existence of a valid route towards 2001:DB8::/32.
	The operational overhead of such a solution is considered high, as		The operational overhead of such a solution is considered high, as
	the operator would have to constantly adapt these access-lists to		the operator would have to constantly adapt these access lists to
	accommodate inter-domain routing changes. Moreover, this technique		accommodate inter-domain routing changes. Moreover, this technique
	lets packets destined to a valid prefix be dropped while they are		lets packets destined to a valid prefix be dropped while they are
	sent from a neighboring AS that may not know about the policy		sent from a neighboring AS that may not know about the policy
	conflict, and hence had no means to avoid the creation of unexpected		conflict and hence had no means to avoid the creation of unexpected
	traffic flows. For this reason, this technique can be considered		traffic flows. For this reason, this technique can be considered
	harmful.		harmful.
	4.2.2. Neighbor-specific forwarding		4.2.2. 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 5 from the point		As an example, let us analyze the scenario of Figure 5 from the point
	of view of AS64502. The edge router connecting to the AS64504		of view of AS64502. The edge router connecting to the AS64504
	forwards packets destined to prefix 2001:DB8::/34 towards AS64505.		forwards packets destined to prefix 2001:DB8::/34 towards AS64505.
	Likewise, it forwards packets destined to prefix 2001:DB8::/32		Likewise, it forwards packets destined to prefix 2001:DB8::/32
	towards AS64501. The router, however, only propagates the path of		towards AS64501. The router, however, only propagates the path of
	the less specific prefix (2001:DB8::/32) to AS64504. An operator		the less-specific prefix (2001:DB8::/32) to AS64504. An operator
	could implement the necessary techniques to force the edge router to		could implement the necessary techniques to force the edge router to
	forward packets coming from AS64504 based only on the paths		forward packets coming from AS64504 based only on the paths
	propagated to AS64504. Thus, the edge router would forward packets		propagated to AS64504. Thus, the edge router would forward packets
	destined to 2001:DB8::/34 towards AS64501 in which case no unexpected		destined to 2001:DB8::/34 towards AS64501, in which case no
	traffic flow would occur.		unexpected traffic flow would occur.
	Different techniques could provide this functionality; however, their		Different techniques could provide this functionality; however, their
	technical implementation can be complex to design and operate. An		technical implementation can be complex to design and operate. An
	operator could, for instance, employ Virtual Routing Forwarding (VRF)		operator could, for instance, employ VPN Routing and Forwarding (VRF)
	tables (RFC4364 [RFC4364]) to store the routes announced to a		tables [RFC4364] to store the routes announced to a neighbor and
	neighbor and forward traffic exclusively based on those routes.		forward traffic exclusively based on those routes. A presentation
	[on_BGP_RS_VPNs] describes the use of such an architecture for		from 2009 [on_BGP_RS_VPNs] describes the use of such an architecture
	Internet routing, and provides a description of its limitations.		for Internet routing and provides a description of its limitations.
	In such architecture, packets received from a peer would be forwarded		In such architecture, packets received from a peer would be forwarded
	solely based on the paths that fit the path propagation policy for		solely based on the paths that fit the path propagation policy for
	that peer, and not based on the global routing table of the router.		that peer and not based on the global routing table of the router.
	As a result, a more specific path that would not be propagated to a		As a result, a more-specific path that would not be propagated to a
	peer will not be used to forward a packet from that peer, and the		peer will not be used to forward a packet from that peer, and the
	unexpected flow will not take place. Packets will be forwarded based		unexpected flow will not take place. Packets will be forwarded based
	on the policy compliant less specific prefix. However, note that an		on the policy-compliant, less-specific prefix. However, note that an
	operator must make sure that all their routers could support the		operator must make sure that all their routers could support the
	potential performance impact of this approach.		potential performance impact of this approach.
	Note that similarly to the solution described in Section 4.1, this		Note that similar to the solution described in Section 4.1, this
	approach could create conflicts between AS64502 and AS64501, since		approach could create conflicts between AS64502 and AS64501, since
	the traffic forwarding performed by AS64502 goes against the policy		the traffic forwarding performed by AS64502 goes against the policy
	of AS64501.		of AS64501.
	5. Conclusions		5. Conclusions
	This document describes how filtering and selective propagation of		This document describes how filtering and selective propagation of
	more-specific prefixes can potentially create unexpected traffic		more-specific prefixes can potentially create unexpected traffic
	flows across some ASes. We provided examples of scenarios where		flows across some ASes. We provided examples of scenarios where
	these practices lead to unexpected traffic flows, and introduce some		these practices lead to unexpected traffic flows and introduce some
	techniques for their detection and prevention. Although there are		techniques for their detection and prevention. Although there are
	reasonable situations in which ASes could filter more-specific		reasonable situations in which ASes could filter more-specific
	prefixes, network operators are encouraged to implement this type of		prefixes, network operators are encouraged to implement this type of
	filters considering the cases described in this document. Operators		filter considering the cases described in this document. Operators
	can implement monitoring systems to detect unexpected traffic flows		can implement monitoring systems to detect unexpected traffic flows
	and react to them according to their own policy.		and react to them according to their own policy.
	6. Security Considerations		6. Security Considerations
	It is possible for an AS to use any of the methods described in this		It is possible for an AS to use any of the methods described in this
	document to deliberately reroute traffic flowing through another AS.		document to deliberately reroute traffic flowing through another AS.
	This document informed on the potential routing security issue, and		This document described the potential routing security issue and
	analyzed ways for operators to defend against it.		analyzed ways for operators to defend against it.
	It must be noted that, at the time of this document, there are no		It must be noted that, at the time of this document, there are no
	existing or proposed tools to automatically protect against such		existing or proposed tools to automatically protect against such
	behavior. Operators can use network monitoring and collection tools		behavior. Operators can use network monitoring and collection tools
	to detect unexpected flows and deal with them on a case-by-case		to detect unexpected flows and deal with them on a case-by-case
	basis.		basis.
	7. IANA Considerations		7. References
	This document has no IANA actions.
	8. Acknowledgments
	The authors would like to thank Wes George, Jon Mitchell, Bruno
	Decraene, and Job Snijders for their useful suggestions and comments.
	9. References		7.1. Normative References
	9.1. Normative References		[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
			RFC 1812, DOI 10.17487/RFC1812, June 1995,
			<http://www.rfc-editor.org/info/rfc1812>.
	[RFC4384] Meyer, D., "BGP Communities for Data Collection", RFC		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	4384, February 2006.		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
			2006, <http://www.rfc-editor.org/info/rfc4364>.
	[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC		[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114,
	1812, June 1995.		RFC 4384, DOI 10.17487/RFC4384, February 2006,
			<http://www.rfc-editor.org/info/rfc4384>.
	[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of		[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
	the IP Flow Information Export (IPFIX) Protocol for the		"Specification of the IP Flow Information Export (IPFIX)
	Exchange of Flow Information", RFC 7011, September 2013.		Protocol for the Exchange of Flow Information", STD 77,
			RFC 7011, DOI 10.17487/RFC7011, September 2013,
			<http://www.rfc-editor.org/info/rfc7011>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		7.2. Informative References
	Networks (VPNs)", RFC 4364, February 2006.
	9.2. Informative References		[INIT7-RIPE63]
			Kunzler, F., "How More Specifics increase your transit
			bill (and ways to avoid it)", Reseaux IP Europeens
			(RIPE) 63rd Meeting, October 2011,
			<http://ripe63.ripe.net/presentations/48-How-more-
			specifics-increase-your-transit-bill-v0.2.pdf>.
	[on_BGP_communities]		[on_BGP_communities]
	Donnet, B. and O. Bonaventure, "On BGP Communities", ACM		Donnet, B. and O. Bonaventure, "On BGP Communities", ACM
	SIGCOMM Computer Communication Review vol. 38, no. 2, pp.		SIGCOMM Computer Communication Review, Volume 38, Number
	55-59, April 2008.		2, pp. 55-59, DOI 10.1145/1355734.1355743, April 2008,
			<http://www.sigcomm.org/sites/default/files/ccr/
			papers/2008/April/1355734-1355743.pdf>.
	[on_BGP_RS_VPNs]		[on_BGP_RS_VPNs]
	Vanbever, L., Francois, P., Bonaventure, O., and J.		Vanbever, L., Francois, P., Bonaventure, O., and J.
	Rexford, "Customized BGP Route Selection Using BGP/MPLS		Rexford, "Customized BGP Route Selection Using BGP/MPLS
	VPNs", Cisco Systems, Routing Symposium		VPNs", Cisco Systems, Routing Symposium, October 2009,
	http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf,		<http://inl.info.ucl.ac.be/system/files/
	October 2009.		Cisco_NAG_2009_ns_bgp.pdf>.
	[INIT7-RIPE63]
	"INIT7-RIPE63", <http://ripe63.ripe.net/presentations/48-
	How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
	[PMACCT] "pmacct project: IP accounting iconoclasm",		[PMACCT] "pmacct project: IP accounting iconoclasm",
	<http://www.pmacct.net>.		<http://www.pmacct.net>.
			Acknowledgements
			The authors would like to thank Wes George, Jon Mitchell, Bruno
			Decraene, and Job Snijders for their useful suggestions and comments.
	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
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		United States
	Email: pifranco@cisco.com		Email: pifranco@cisco.com
	Paolo Lucente		Paolo Lucente
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		United States
	Email: plucente@cisco.com		Email: plucente@cisco.com
End of changes. 106 change blocks.
	237 lines changed or deleted		254 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/