draft-ietf-grow-filtering-threats-02.txt		draft-ietf-grow-filtering-threats-03.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: August 17, 2014 IMDEA Networks		Expires: February 5, 2015 IMDEA Networks
	Paolo Lucente		Paolo Lucente
	Cisco Systems		Cisco Systems
	February 13, 2014		August 4, 2014
	Making BGP filtering a habit: Impact on policies		Making BGP filtering a habit: Impact on policies
	draft-ietf-grow-filtering-threats-02		draft-ietf-grow-filtering-threats-03
	Abstract		Abstract
	Network operators define their BGP policies based on the business		This document describes how unexpected traffic flows can emerge
	relationships that they maintain with their peers. By limiting the		across an autonomous system, as the result of other autonomous
	propagation of BGP prefixes, an autonomous system avoids the		systems filtering, or restricting the propagation of overlapping
	existence of flows between BGP peers that do not provide any		prefixes. We provide a review of the techniques to detect the
	economical gain. This draft describes how unexpected traffic flows		occurrence of this issue and defend against it.
	can emerge in autonomous systems due to the filtering of overlapping
	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 August 17, 2014.		This Internet-Draft will expire on February 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Filtering overlapping prefixes . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 3		2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
	2.2. Remotely triggered filtering . . . . . . . . . . . . . . 6		2.1. Local filtering . . . . . . . . . . . . . . . . . . . . . 4
	3. Uses of overlapping prefix filtering that create unexpected		2.1.1. Unexpected traffic flows caused by local filtering of
	traffic flows . . . . . . . . . . . . . . . . . . . . . . . . 6		overlapping prefixes . . . . . . . . . . . . . . . . 5
	3.1. Unexpected traffic Flows . . . . . . . . . . . . . . . . 7		2.2. Remote filtering . . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Unexpected traffic flows caused by local filtering of		2.2.1. Unexpected traffic flows caused by remotely triggered
	overlapping prefixes . . . . . . . . . . . . . . . . 8		filtering of overlapping prefixes . . . . . . . . . . 7
	3.1.2. Unexpected traffic flows caused by remotely triggered		3. Techniques to detect unexpected traffic flows caused by
	filtering of overlapping prefixes . . . . . . . . . . 12		filtering of overlapping prefixes . . . . . . . . . . . . . . 8
	4. Techniques to detect unexpected traffic flows caused by		3.1. Existence of unexpected traffic flows within an AS . . . 8
	filtering of overlapping prefixes . . . . . . . . . . . . . . 15		3.2. Contribution to the existence of unexpected traffic flows
	4.1. Being the 'victim' of unexpected traffic flows . . . . . 15		in another AS . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Being a contributor to the existence of unexpected		4. Techniques to counter unexpected traffic flows . . . . . . . 10
	traffic flows in other networks . . . . . . . . . . . . . 15		4.1. Reactive counter-measures . . . . . . . . . . . . . . . . 11
	5. Techniques to counter unexpected traffic flows due to the		4.2. Anticipant counter-measures . . . . . . . . . . . . . . . 12
	filtering of overlapping prefixes . . . . . . . . . . . . . . 16		4.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 12
	5.1. Reactive counter-measures . . . . . . . . . . . . . . . . 17		4.2.2. Neighbor-specific forwarding . . . . . . . . . . . . 13
	5.2. Anticipant counter-measures . . . . . . . . . . . . . . . 18		5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2.1. Access lists . . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	5.2.2. Automatic overlapping prefix filtering . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5.2.3. Neighbor-specific forwarding . . . . . . . . . . . . 19		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9.1. References . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. References . . . . . . . . . . . . . . . . . . . . . . . 0		9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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 a more
	prefixes along with the prefixes that they originate. It is also		specific (overlapping) prefix in the BGP routing system, along with
	possible for some Autonomous Systems (ASes) to apply different		the covering prefix that they originate. It is also possible for
	policies to the overlapping (more specific) and the covering (less		some Autonomous Systems (ASes) to apply different policies to the
	specific) prefix. Some ASes can even benefit from filtering the		overlapping and the covering prefix.
	overlapping prefixes.
	BGP makes independent, policy driven decisions for the selection of		While BGP makes independent, policy driven decisions for the
	the best path to be used for a given IP prefix. However, 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 [1]). Indeed, the existence of a		"precedes" any BGP policy (RFC1812 [1]). 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 overlapping
	overlapping 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' (the covering prefix). When an Autonomous System		for p'. When an Autonomous System filters overlapping prefixes and
	filters overlapping prefixes and forwards packets according to the		forwards packets according to the covering prefix, the discrepancy in
	covering prefix, the discrepancy in the routing policies applied to		the routing policies applied to covering and overlapping prefixes can
	covering and overlapping prefixes can create unexpected traffic flows		create unexpected traffic flows that infringe the policies of other
	that infringe the policies of other ASes still holding a path towards		ASes, still holding a path towards the overlapping prefix.
	the overlapping prefix.
	This document presents examples of such cases and discusses solutions
	to the problem. The objective of this draft is to shed light on the
	use of prefix filtering by making the routing community aware of the
	cases where the effects of filtering might turn to be negative for
	the business of Internet Service Providers (ISPs).
	The rest of the document is organized as follows: Section 2
	illustrates the motivation to filter overlapping prefixes. In
	Section 3, we provide some scenarios in which the filtering of
	overlapping prefixes lead to the creation of unexpected traffic flows
	on other ASes. Section 4 and Section 5 discuss some techniques that
	ASes can use for, respectively, detect and react to unexpected
	traffic flows.
	2. Filtering overlapping prefixes
	There are several scenarios where filtering an overlapping prefix is
	relevant to the operations of an AS. In this section, we provide
	examples of these scenarios. We differentiate cases in which the
	filtering is performed locally from those where the filtering is
	triggered remotely. These scenarios will be used as a base in
	Section 3 for describing side effects bound with such practices.
	2.1. Local filtering
	Let us first analyze the scenario depicted in Figure 1. AS1 and AS2
	are two autonomous systems spanning a large geographical area and
	peering in 3 different physical locations. Let AS1 announce prefix
	10.0.0.0/22 over all peering links with AS1. Additionally, let us
	define that there is part of AS1's network which exclusively uses
	prefix 10.0.0.0/24 and which is closer to a peering point than to
	others.
	To receive the traffic destined to prefix 10.0.0.0/24 on the link
	closer to this subnet, AS1 could announce the overlapping prefix only
	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
	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
	peering link. In this scenario, it becomes relevant to AS2 to
	enforce such practice by detecting the described situations and
	automatically issuing the appropriate filtering. In this case, by
	implementing these automatic procedures, AS2 would legitimately
	detect and filter prefix 10.0.0.0/24.
	___....-----------....___
	,.--' AS2 `--..
	,' `.
	| |
	`._ _.'
	`--..__ _,,.--'
	. `'''-----------'''' |
	| | |
	| | |
	10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22
	| ___....-----------....___ |10.0.0.0/24
	,.--'AS1 `--..
	,' ...........`.
	| |10.0.0.0/24 |
	`._ |........._.'
	`--..__ _,,.--'
	`'''-----------''''
	Figure 1: Basic scenario of local filtering
	Local filtering could be required in other cases. For example, a
	dual homed AS receiving an overlapping prefix from only one of its
	providers. Figure 2 depicts a simple example of this case.
	_..._		The objective of this draft is to shed light on possible side effects
	,' `.		associated with overlapping prefix filtering. This document presents
	/ AS4 \		examples of such side effects and discusses approaches towards
	| |		solutions to the problem.
	\ /
	,`-...-'.
	/ '.
	10.0.0.0/22 ,' \
	10.0.0.0/24 / \ 10.0.0.0/22
	..:_ >..._
	,' `. ,' `.
	/ AS2 \ / AS3 \
	| | | |
	\ / \ /
	`-...-', `-...-'
	\ /
	\ /
	10.0.0.0/22 \_..._ '10.0.0.0/22
	10.0.0.0/24,' `.
	/ AS1 \
	| |
	\ /
	`-...-'
	Figure 2: Basic scenario of local filtering		The rest of the document is organized as follows: In Section 2 we
			provide some scenarios in which the filtering of overlapping prefixes
			leads to the creation of unexpected traffic flows. Section 3 and
			Section 4 discuss some techniques that ASes can use for,
			respectively, detect and react to unexpected traffic flows. We
			conclude in Section 5.
	In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and		1.1. Terminology
	AS3. Both ASes propagate the prefix to AS4. Additionally, AS1
	advertises prefix 10.0.0.0/24 to AS2, which subsequently propagates
	the prefix to AS4.
	It is possible that AS4 resolves to filter the more specific prefix		Overlapping prefix: A prefix in the routing table with an address
	10.0.0.0/24. One potential motivation could be the economical		range that is covered by another prefix present in the routing table.
	preference of the path via AS2 over AS3. Another feasible reason is
	the existence of a technical policy by AS4 of aggregating incoming
	prefixes longer than /23.
	The above examples illustrate two of the many motivations to		Covering prefix: A prefix in the routing table with an address range
	configure routing within an AS with the aim of ignoring more specific		partially covered by other prefixes.
	prefixes. Operators have reported applying these filters in a manual
	fashion [3]. The relevance of such practice led to investigate
	automated filtering procedures in I-D.WHITE [2].
	2.2. Remotely triggered filtering		We re-use the definitions of customer-transit peering and settlement-
			free peering of RFC4384 [2].
	ISPs can tag the BGP paths that they propagate to neighboring ASes		Selective advertisement: The behavior of only advertising a self
	with communities, in order to tweak the propagation behavior of the		originated BGP path for a prefix over a strict subset of the eBGP
	ASes that handle these paths [1].		sessions of the AS.
	Some ISPs allow their direct and indirect customers to use such		Selective propagation: The behavior of only propagating a BGP path
	communities to let the receiving AS not export the path to some		for a prefix over a strict subset of the eBGP sessions of an AS.
	selected neighboring AS. By combining communities, the prefix could
	be advertised only to a given peer of the AS providing this feature.
	Figure 3 illustrates an example of this case.
	10.0.0.0/22 ,' \		Local filtering: The behavior of explicitly ignoring a BGP path
	10.0.0.0/24 / \ 10.0.0.0/22		received over an eBGP session.
	..:_ >..._
	,' `. ,' `.
	/ AS2 \________ / AS3 \
	| |/22 /22| |
	\ / \ /
	`-...-', `-...-'
	\ /
	\ /
	10.0.0.0/22 \_..._ '10.0.0.0/22
	10.0.0.0/24,' `.
	/ AS1 \
	| |
	\ /
	`-...-'
	Figure 3: Remote triggered filtering		Remote filtering: The behavior of triggering selective propagation of
			a BGP path at a distant AS. Note that this is typically achieved by
			tagging a self-originated path with BGP communities defined by the
			distant AS.
	AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic		Unexpected traffic flow: Traffic flowing between two neighboring ASes
	engineering purposes, AS1 could use communities to prevent AS2 from		of an AS, although the transit policy of that AS is to not provide
	announcing prefix 10.0.0.0/24 to AS3.		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 classical examples
			of unexpected traffic flows.
	Such technique is useful for operators to tweak routing decisions in		2. Unexpected Traffic Flows
	order to align with complex transit policies. We will see in later
	sections that by producing the same effect as filtering, they can
	also lead to unexpected traffic flows at other, distant, ASes.
	3. Uses of overlapping prefix filtering that create unexpected traffic		In this section, we describe how overlapping prefix filtering can
	flows		lead to unexpected traffic flows in other, remote, ASes. We
			differentiate cases in which the filtering is performed locally from
			those where the filtering is triggered remotely.
	In this section, we define the concept of unexpected traffic flows		2.1. Local filtering
	and describe three configuration scenarios that lead to their
	creation. Note that these examples do not capture all the cases
	where such issues can take place.
	3.1. Unexpected traffic Flows		Local filtering can be motivated by different reasons, such as: (1)
			Traffic engineering, where an AS wants to control their local
			outbound traffic distribution using only the policy applied to the
			covering prefix. (2) Enforcing contract compliance, where, for
			instance, an AS avoids a settlement-free peer to attract traffic to
			one link by using selective advertisement, when this is not allowed
			by their peering agreement.
	The BGP policy of an Internet Service provider includes all actions		Figure 1 illustrates a scenario in which one AS is motivated to
	performed over its originated routes and the routes received		perform local filtering due to outbound traffic engineering. The
	externally. One important part of the BGP policy is the selection of		figure depicts AS64504, and two of its neighboring ASes, AS64502 and
	the routes that are propagated to each neighboring AS. One of the		AS64505. AS 64504 has a settlement-free peering with AS64502 and is
	goals of these policies is to allow ISPs to avoid transporting		a customer of AS64505. AS64504 receives from AS64505 prefixes
	traffic between two ASes without economical gain. For instance, ISPs		2001:DB8::/32 and 2001:DB8::/34, covering and overlapping prefixes,
	typically propagate to their peers only routes coming from its		respectively. AS64504 receives only the covering prefix
	customers (RFC4384 [3]). We briefly illustrate this operation in		2001:DB8::/32 from AS64502.
	Figure 4. In the figure, AS2 is establishing a settlement free
	peering with AS1 and AS3. AS2 receives prefix P3/p3, from AS3. AS2,
	however, is not interested in transporting traffic from AS1 to AS3,
	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.
	AS2 propagates this prefix to AS1.
	,-----. ,-----. ,-----.		,-----.
	,' `. ,' `. ,' `.		/ \
	/ AS1 \ / AS2 \ / AS3 \		( AS64505 )
	( )-----( )-----( )		\ /
	\ / P4/p4 \ / \ P3/p3 /		`--+--'
	`. ,' `. ,' `. ,'		2001:DB8::/32 | |
	'-----' '-----' '-----'		2001:DB8::/34 v |
	|		|
	|		,--+--. 2001:DB8::/32 ,-----.
	|		/ \ <-- / \
	,-----.		( AS64504 )-------------( AS64502 )
	,' `.		\ / \ /
	/ AS4 \		`-----' `-----'
	( )
	\ P4/p4 /
	`. ,'
	'-----'
	Figure 4: Prefix exchange among four autonomous systems		Figure 1: Local Filtering
	Although ISPs usually implement the aforementioned policies,		Due to economical reasons, AS64504 might prefer to send traffic to
	unexpected traffic flows may still appear. In Figure 4, unexpected		AS64502 instead of AS64505. However, even if paths received from
	traffic flows are created, when, despite AS2's policy, traffic		AS64502 are given a large local preference, routers in AS64504 will
	arriving from peer AS1 is received and transported to AS3 by AS2.		still send traffic to prefix 2001:DB8::/34 via neighbor AS64505.
	These types of traffic flows can arise due to a number of reasons.		This situation may push AS64504 to apply an inbound filter for the
	Specifically, in this document we explain how the filtering of		overlapping prefix, 2001:DB8::/34, on the session with AS64505.
	overlapping prefixes might cause unexpected traffic flows on ASes.		After the filter is applied, traffic to the overlapping prefix will
	We provide examples of these cases in the next sections.		be sent to AS64502
	3.1.1. Unexpected traffic flows caused by local filtering of		2.1.1. Unexpected traffic flows caused by local filtering of
	overlapping prefixes		overlapping prefixes
	In this section, we describe cases in which an AS locally filters an		In this section, we show how the decision of AS64504 to perform local
	overlapping prefix. We show that, depending on the BGP policies		filtering creates unexpected traffic flows in AS64502. Figure 2
	applied by surrounding ASes, this decision can lead to unexpected		shows the whole picture of the scenario; where AS64501 is a customer
	traffic flows.		of AS64503 and AS64502. AS64503 is a settlement-free peer with
			AS64502. AS64503 and AS64502 are customers of AS64505. The AS
	3.1.1.1. Initial setup		originating the two prefixes, AS64501, performs selective
			advertisement with the overlapping prefix and only announces it to
	We start by describing the basic scenario of this case in Figure 5.		AS64503.
	____,,................______
	_,.---'''' `''---..._
	,-'' AS5 `-.
	[ /
	-.._ __.-'
	. `'---....______ ______...---''
	|/22 `''''''''''''''' |
	|/24 |/22 |
	| |/24 |
	| | |
	| |/22 |/22
	| |/24 |/24
	_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \
	| |_________| |________| |
	| | /22 | |/22 /22| |
	'. ,' /24 . ,'/24 /24 . ,'
	`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''
	| |
	|10.0.0.0/24 |10.0.0.0/24
	|10.0.0.0/22 |10.0.0.0/22
	| _....---------...._|
	,-'AS1 ``-.
	/' `.
	`. _,
	`-.._ _,,,'
	`''---------'''
	Figure 5: Initial Setup Local
	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
	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
	announce the two prefixes to their peers and transit providers. AS4
	receives both prefixes from its peer (AS2) and transit provider
	(AS5). We will consider that AS5 chooses as best path to AS1 the one
	received from AS3.
	3.1.1.2. Unexpected traffic flows by local filtering - Case 1
	In the next scenarios, we show that if AS4 filters the incoming		After AS64504 locally filters the overlapping prefix, traffic from
	overlapping prefix from AS5, there is a situation in which unexpected		AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502.
	traffic flows are created on other ASes.		Because AS64502 receives the more specific prefix from AS64503,
			traffic from AS64504 to 2001:DB8::/34 follows the path
			AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are
			implemented to avoid transporting traffic between AS64504 and
			AS64503. However, due to the discrepancies of routes from the
			overlapping and covering prefixes, unexpected traffic flows between
			AS64504 and AS64503 exist in AS64502's network.
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS5 `-.		,-'' AS64505 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	|/22 `''''''''''''''' |		+ |/32 `''''''''''''''' |
	|/24 |/22 |		| |/34 + |/32 |
	| |/24 |		v | v |/34 |
	| | |		| | ^ |
	| |/22 |/22		| ^ |/32 | |/32
	| | |/24		| + | + |/34
	_,,---.:_ _,,---.._ _,,---.._		_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \		/ AS64504 \ <-+ / AS64502 \ / AS64503 \
	| |_________| |________| |		| |_________| |________| |
	| | /22 | |/22 /22| |		| | /32 | |/32 /32| |
	'. ,' . ,' /24 . ,'		'. ,' . ,' /34 . ,'
	`. ,' `. ,' `. ,'		`. ,' `. ,' +-> <-+ `. ,'
	``---'' ``---'' ``---''		``---'' ``---'' ``---''
	| |		| ^ |
	| |10.0.0.0/24		^ |2001:DB8::/32 | |2001:DB8::/32
	|10.0.0.0/22 |10.0.0.0/22		| | + |2001:DB8::/34
	| _,,..---------...._|		+ | _....---------...._|
	,-'AS1 ``-.		,-'AS64501 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 6: Unexpected traffic flows by local filtering - Case 1		Figure 2: Unexpected traffic flows due to local filtering
	Let us assume the scenario illustrated in Figure 6. For this case,		2.2. Remote filtering
	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		ISPs can tag the BGP paths that they propagate to neighboring ASes
	filter the announcement of prefix 10.0.0.0/24 from AS5.		with communities, in order to tweak the propagation behavior of the
	Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is forwarded		ASes that handle these paths [1]. Some ISPs allow their customers to
	towards AS2. Because AS2 receives the more specific prefix from AS3,		use such communities to let the receiving AS not export the path to
	traffic from AS4 to prefix 10.0.0.0/24 follows the path		some selected neighboring ASes. By combining communities, the prefix
	AS4-AS2-AS3-AS1. AS2's BGP policies are implemented to avoid using		could be advertised only to a given peer of the AS providing this
	itself to exchange traffic between AS4 and AS3. However, due to the		feature. Remote filtering can be leveraged by an AS to, for
	discrepancies of routes from the overlapping and covering prefixes,		instance, limit the scope of prefixes and hence perform a more
	unexpected traffic flows between AS4 and AS3 still exist on AS2's		granular inbound traffic engineering.
	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		Figure 3 illustrates a scenario in which an AS uses BGP communities
	____,,................______		to command its provider to selectively propagate an overlapping
	_,.---'''' `''---..._		prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501
	,-'' AS5 `-.		originates prefix 2001:DB8::/32, which it advertises through AS64502
	[ /		and AS64503. AS64502 and AS64503 are settlement-free peers. Let
	-.._ __.-'		AS64501 do selective advertisement and only propagate 2001:DB8::/34
	. `'---....______ ______...---''		over AS64503. AS64503 would normally propagate this prefix to its
	|/22 `''''''''''''''' |		customers, providers, and peers, including AS64502.
	|/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		Let us consider that AS64501 decides to limit the scope of the
			overlapping prefix. AS64501 can make this decision based on its
			traffic engineering strategy. To achieve this, AS64501 can tag the
			overlapping prefix with a set of communities that leads AS64503 to
			only propagate the path to AS64502.
	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		| /32 \ / /32 | | /32 \ / /32 |
	overlapping prefix only from its transit provider, AS5. This case is		,-----. ,-----.
	illustrated in Figure 7.		,' `. ,' `.
			/ AS64502 \ / AS64503 \
			( )-------------( )
			\ / /32 /32 \ /
			`. ,' -> /34 `. ,'
			'-----; <- / '-----'
			\ /
			^ \ / ^
			| \ / |
			| \ / |
			| \ ,-----.' | 2001:DB8::/32
			| ,' `. | 2001:DB8::/34
			2001:DB8::/32 +-- / AS64501 \ --+
			( )
			\ /
			`. ,'
			'-----'
	Similar to the scenario described in Section 3.1.1.2, AS4 is in a		Figure 3: Remote triggered filtering
	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
	prefix 10.0.0.0/24 would be forwarded towards AS2. Due to the
	existence of a route to prefix 10.0.0.0/24, AS2 receives the traffic
	heading to this prefix from AS4 and sends it to AS5. This situation
	creates unexpected traffic flows that contradict AS2's BGP policy,
	since the AS ends up forwarding traffic from a peer to a transit
	network.
	3.1.2. Unexpected traffic flows caused by remotely triggered filtering		2.2.1. Unexpected traffic flows caused by remotely triggered filtering
	of overlapping prefixes		of overlapping prefixes
	We present a configuration scenario in which an AS, using the		Figure 4 expands the scenario from Figure 3 and includes other AS
	mechanism described in Section 2.2, informs its provider to		peering with ASes 64502 and 64503. Due to the limitation on the
	selectively propagate an overlapping prefix, leading to the creation		scope performed on the overlapping prefix, ASes that are not
	of unexpected traffic flows in another AS.		customers of AS64502 will not receive a path for 2001:DB8::/34.
			These ASes will forward packets destined to 2001:DB8::/34 according
	3.1.2.1. Initial setup		to their routing state for 2001:DB8::/32. Let us assume that AS64505
			is such an AS, and that its best path towards 2001:DB8::/32 is
	Let AS1 be a customer of AS2 and AS3. AS1 owns 10.0.0.0/22, which it		through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will
	advertises through AS2 and AS3. Additionally, AS2 and AS3 are peers.		reach AS64502. However, in the data-plane of the nodes of AS64502,
			the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is
	Both AS2 and AS3 select A1's path as best, and propagate it to their		reached through AS64503, a settlement-free peer of AS64502. Since
	customers, providers, and peers. Some remote ASes will route traffic		AS64505 is not in the customer branch of AS64502, we are in a
	destined to 10.0.0.1 through AS2 while others will route traffic		situation in which traffic flows between non-customer ASes take place
	through AS3.		in AS64502.
	\ / \ /
	/22 \ / /22 /22 \ / /22
	,-----. ,-----.
	,' `. ,' `.
	/ AS2 \ /22 / AS3 \
	( )-------------( )
	\ / /22 \ /
	`. ,' `. ,'
	'-----; / '-----'
	\ /
	\ /
	10.0.0.0/22\ /10.0.0.0/22
	\ /
	\ ,-----.'
	,' `.
	/ AS1 \
	( )
	\ /
	`. ,'
	'-----'
	Figure 8: Example scenario
	3.1.2.2. Injection of an overlapping prefix
	Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate
	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
	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
	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
	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.
	\ / /22\ / /22
	/22 \ / /22 /24 \ / /24
	,-----. ,-----.
	,' `. /22 ,' `.
	/ AS2 \ /24 / AS3 \
	( /22:AS1 )-------------( /22:AS1 )
	\ /24:AS3 / /22 \ /24:AS1 /
	/22 /`. ,' `. ,'
	/24/ '-----; / '-----'
	/ \ /
	,---./ \ /
	/ \ 10.0.0.0/22\ /10.0.0.0/22
	| AS4 ) \ / 10.0.0.0/24
	\ / \ ,-----.'
	`---' ,' `.
	/ AS1 \
	( )
	\ /
	`. ,'
	'-----'
	Figure 9: Injection of overlapping prefix
	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
	Internet Routing Policies in this case. AS3 could receive traffic
	destined to 10.0.0.0/24 from its customers, providers, and peers,
	which it directly forwards to its customer AS1.
	3.1.2.3. Creation of unexpected traffic flows by limiting the scope of
	the overlapping prefix
	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
	techniques described in Section 2.2.
	,-------.
	,' `.
	/ AS5 \
	( /22:AS2 )
	\ /
	`. ,'
	'-------' \ / \ /
	/22 \ //22 /22 \ //22
	,-----. ,-----.
	,' `. /22 ,' `.
	/ AS2 \ /24 / AS3 \
	( /22:AS1 )-------------( /22:AS1 )
	\ /24:AS3 / /22 \ /24:AS1 /
	/22 /`. ,' `. ,'
	/24/ '-----; / '-----'
	/ \ /
	,---./ \ /
	/ \ 10.0.0.0/22\ /10.0.0.0/22
	( AS4 ) \ / 10.0.0.0/24
	\ / \ ,-----.'
	`---' ,' `.
	/ AS1 \
	( )
	\ /
	`. ,'
	'-----'
	Figure 10: More Specific Injection
	From AS2's point of view, such a path is a "peer path" and will only		,-----.
	be advertised by AS2 to its customers.		,' `.
			/ AS64505 \
			( )
			\ /
			`. ,'
			'-----'
			^ \ / ^ ^ \ / ^
			| /32 \ / /32 | | /32 \ / /32 |
			+ ,-----. + + ,-----. +
			,' `. ,' `.
			/ AS64502 \ / AS64503 \
			( )-------------( )
			,-----. \ / /32 /32 \ /
			,' `.---------`. ,' +-> /34 `. ,'
			/ AS64504 \ /32 '-----; <-+ / '-----'
			( ) /34 \ /
			\ / <-+ ^ \ / ^
			`. ,' | \ / |
			'-----; | \ / |
			| \ ,-----.' | 2001:DB8::/32
			| ,' `. | 2001:DB8::/34
			2001:DB8::/32 +--+ / AS64501 \ +--+
			( )
			\ /
			`. ,'
			'-----'
	ASes that are not customers of AS2 will not receive a path for		Figure 4: Unexpected traffic flows due to remote triggered filtering
	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
	AS5 is such an AS, and that its best path towards 10.0.0.0/22 is
	through AS2. Then, packets sent towards 10.0.0.1 by AS5 will
	eventually reach AS2. However, in the data-plane of the nodes of
	AS2, the longest prefix match for 10.0.0.1 is 10.0.0.0/24, which is
	reached through AS3, a peer of AS2. Since AS5 is not in the customer
	branch of AS2, we are in a situation in which traffic flows between
	non-customer ASes take place in AS2.
	4. Techniques to detect unexpected traffic flows caused by filtering of		3. Techniques to detect unexpected traffic flows caused by filtering of
	overlapping prefixes		overlapping prefixes
	We differentiate the techniques available for detecting unexpected		3.1. Existence of unexpected traffic flows within an AS
	traffic flows caused by the described scenarios from the cases in
	which the interested AS is the victim or contributor of such
	operations.
	4.1. Being the 'victim' of unexpected traffic flows
	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 and validate if any flow		network, an ISP can monitor its traffic data to check if it is
	entering the ISP network through a non-customer link is forwarded to		providing transit between two of its peers, although his policy is
	a non-customer next-hop.		configured to not provide such transit. IPFIX (RFC7011 [3]) is an
			example of a technology that can be used to export information
			regarding traffic flows across the network. Traffic information must
			be analyzed under the perspective of the business relationships with
			neighboring ASes. Open source tools such as [4] can be used to this
			end.
	As mentioned in Section 3.1, unexpected traffic flows might appear		Note that the AS detecting the unexpected traffic flow may simply
	due to different situations. To discover if the problem arose after		realize that his policy configuration is broken. The first
	the filtering of prefixes by neighboring ASes, an operator can		recommended action upon detection of an unexpected traffic flow is to
	analyze available BGP data. For instance, an ISP can seek for		verify the correctness of the BGP configuration.
	overlapping prefixes for which the next-hop is through a provider (or
	peer), while the next-hop for their covering prefix(es) is through a
	client. Direct communication or looking glasses can be used to check
	whether non-customer neighboring ASes are propagating a path towards
	the covering prefix and not the path towards the overlapping prefix.
	This situation should trigger a warning, as this would mean that ASes
	in the surrounding area of the current AS are forwarding packets
	based on the routing entry for the less specific prefix only.
	4.2. Being a contributor to the existence of unexpected traffic flows		Once it has been assessed that the local configuration is correct,
	in other networks		the operator should check if the problem detected in the data-plane
			arose due to filtering of BGP paths by neighboring ASes. The
			operator should check if the destination address of the unexpected
			traffic flow is locally routed as per an overlapping prefix only
			received from non-customer peers. The operator should also checks if
			there are paths to a covering prefix received from a customer, and
			hence propagated to peers. If these two situations happen at the
			same time, the neighboring AS at the entry point of the unexpected
			flow is routing the traffic based on the covering prefix, although
			the ISP is actually forwarding the traffic via non-customer links.
			To detect the origin of the problem, human interaction or looking
			glasses can be used in order to find out whether local filtering,
			remote filtering, or selective propagation was performed on the
			overlapping prefix. Due to the distributed nature and restricted
			visibility of the steering of BGP policies, such analysis is deemed
			to not identify the origin of the problem with guaranteed accuracy.
			We are not aware, at the time of this writing, of any openly
			available tool that can automatically perform this operation.
			3.2. Contribution to the existence of unexpected traffic flows in
			another AS
	It can be considered problematic to be causing unexpected traffic		It can be considered problematic to be causing unexpected traffic
	flows on other ASes. This situation may appear as an abuse to the		flows in other ASes. This situation may appear as an abuse to the
	network resources of other ISPs.		network resources of other ISPs.
	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 relationships implementations.		trouble-shooting purposes to business relationship implementations.
	Restricting such features for the sake of avoiding the creation of		Restricting the use of these features for the sake of avoiding the
	unexpected traffic flows is not a practical option.		creation of unexpected traffic flows is not a practical option.
	Traffic data does not help an ISP detect that it is acting as a
	contributor of the creation of the unexpected traffic flow. It is
	thus advisable to obtain as much information as possible about the
	Internet environment of the AS and assess the risks of filtering
	overlapping prefixes before implementing them.
	Monitoring the manipulation of the communities that implement the		It is advisable for an AS to assess the risks of filtering
	scoping of prefixes is recommended to the ISPs that provide these		overlapping prefixes before implementing them by obtaining as much
	features. The monitored behavior should then be compared with their		data information as possible about its surrounding routing
	terms of use.		environment. The AS would need information of the routing policies
			and the relationships among external ASes to detect if its actions
			could trigger the appearance of unexpected traffic flows. With this
			information, the operator could detect other ASes receiving the
			overlapping prefix from non-customer ASes, while announcing the
			covering prefix to other non-customer ASes. If the filtering of the
			overlapping prefix leads other ASes to send traffic for the
			overlapping prefix to these ASes, an unexpected traffic flow can
			arise. However, the information required for this operation is
			difficult to obtain, due to the distributed nature of BGP policies.
			We are not aware, at the time of this writing, of any openly
			available tool that can automatically perform this procedure.
	5. Techniques to counter unexpected traffic flows due to the filtering		4. Techniques to counter unexpected traffic flows
	of overlapping prefixes
	Network Operators can adopt different approaches with respect to		Network Operators can adopt different approaches with respect to
	unexpected traffic flows. We classify these actions according to		unexpected traffic flows. Note that due the complexity of inter-
	whether they are anticipant or reactive.		domain routing policies, there is not a single solution that can be
			applied to all situations. We provide potential solutions that ISPs
			must evaluate against each particular case. We classify these
			actions according to whether they are anticipant 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 configuration scenario is set up.		when the scenario arises.
	We use the scenario depicted in Figure 11 to describe these two kinds		We use the scenario depicted in Figure 5 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		effects. Therefore, we conclude that the reactive approach is the
	the more reasonable recommendation to deal with unexpected flows.		more reasonable recommendation to deal with unexpected flows.
	____,,................______		____,,................______
	_,.---'''' `''---..._		_,.---'''' `''---..._
	,-'' AS5 `-.		,-'' AS64505 `-.
	[ /		[ /
	-.._ __.-'		-.._ __.-'
	. `'---....______ ______...---''		. `'---....______ ______...---''
	|/22 `''''''''''''''' |		+ |/32 `''''''''''''''' |
	|/24 |/22 |		| |/34 + |/32 |
	| |/24 |		v | v |/34 |
	| | |		| | ^ |
	| |/22 |/22		| ^ |/32 | |/32
	| | |/24		| + | + |/34
	_,,---.:_ _,,---.._ _,,---.._		_,,---.:_ _,,---.._ _,,---.._
	,' `. ,' `. ,' `.		,' `. ,' `. ,' `.
	/ AS4 \ / AS2 \ / AS3 \		/ AS64504 \ <-+ / AS64502 \ / AS64503 \
	| |_________| | | |		| |_________| | | |
	| | /22 | | | |		| | /32 | | | |
	'. ,' . ,' . ,'		'. ,' . ,' . ,'
	`. ,' `. ,' `. ,'		`. ,' `. ,' `. ,'
	``---'' ``---'' ``---''		``---'' ``---'' ``---''
	| |		| ^ |
	| |10.0.0.0/24		^ |2001:DB8::/32 | |2001:DB8::/32
	|10.0.0.0/22 |10.0.0.0/22		| | + |2001:DB8::/34
	_;,..---------...._|		+ | _....---------...._|
	,-'AS1 ``-.		,-'AS64501 ``-.
	/' `.		/' `.
	`. _,		`. _,
	`-.._ _,,,'		`-.._ _,,,'
	`''---------'''		`''---------'''
	Figure 11: Anticipant counter-measures - Base example		Figure 5: Counter-measures for unexpected traffic flows - Base
			example
	5.1. Reactive counter-measures		4.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 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
	overlapping prefix or over the session with the neighboring AS from		overlapping 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 describe briefly the		different repercussion for the affected AS. We describe briefly the
	two alternatives.		two alternatives.
	o An operator can decide to stop announcing the covering prefix at		o An operator can decide to stop announcing the covering prefix at
	the peering session with the neighboring AS from which it is		the peering session with the neighboring AS from which it is
	receiving traffic to the overlapping prefix. In the example of		receiving traffic to the overlapping prefix. In the example of
	Figure 11, AS2 would filter out the prefix 10.0.0.0/22 from the		Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from
	eBGP session with AS4. In this case, all the traffic heading to		the eBGP session with AS64504. In this case, not all traffic
	the prefix 10.0.0.0/22 from AS1 would not longer traverse AS2.		heading to the prefix 2001:DB8::/32 from AS64501 would no longer
	AS2 should evaluate if solving the inconvenient originated by the		traverse AS64502. AS64502 should evaluate if solving the issues
	unexpected traffic flows are worth the loss of this traffic share.		originated by the unexpected traffic flows are worth the loss of
			this traffic share.
	o An operator can decide to filter-out the concerned overlapping		o An operator can decide to filter out the overlapping prefix at the
	prefix at the peering session over which it was received. In the		peering session over which it was received. In the example of
	example of Figure 11, AS2 would filter out the incoming prefix		Figure 5, AS64502 would filter out the incoming prefix
	10.0.0.0/24 from the eBGP session with AS5. As a result, the		2001:DB8::/34 from the eBGP session with AS64505. As a result,
	traffic destined to that /24 would be forwarded by AS2 along its		the traffic destined to that /32 would be forwarded by AS64502
	link with AS1, despite the actions performed by AS1 to have this		along its link with AS64501, despite the actions performed by
	traffic coming in through its link with AS3. However, as AS2 will		AS64501 to have this traffic coming in through its link with
	no longer possess a route to the overlapping prefix, it risks		AS64503. However, as AS64502 will no longer know a route to the
	losing the traffic share from customers different from AS1 to that		overlapping prefix, it risks losing the traffic share from
	prefix. Furthermore, this action can generate conflicts between		customers different from AS64501 to that prefix. Furthermore,
	AS2 and AS1, since AS2 does not follow the policy expressed by AS1		this action can generate conflicts between AS64502 and AS64501,
	in its BGP announcements.		since AS64502 does not follow the routing information expressed by
			AS64501 in its BGP announcements.
	It is possible that the behavior from the neighboring AS that is		It is possible that the behavior of the neighboring AS causing the
	causing the unexpected traffic flows opposes the peering agreement.		unexpected traffic flows opposes the peering agreement. In this
	In this case, an operator can account the amount of traffic that has		case, an operator could account the amount of traffic that has been
	been subject to the unexpected flows and charge the peer for that		subject to the unexpected flows, using traffic measurement protocols
	traffic. That is, the operator can claim that it has been a provider		such as IPFIX, and charge the peer for that traffic. That is, the
	of that peer for the traffic that transited between the two ASes.		operator can claim that it has been a provider of that peer for the
			traffic that transited between the two ASes.
	5.2. Anticipant counter-measures		4.2. Anticipant counter-measures
	5.2.1. Access lists		4.2.1. Access lists
	An operator can configure its routers to install dynamically an		An operator can configure its routers to install dynamically an
	access-list made of the prefixes towards which the forwarding of		access-list made of the prefixes towards which the forwarding of
	traffic from that interface would lead to unexpected traffic flows.		traffic from that interface would lead to unexpected traffic flows.
	In the example of Figure 11, AS2 would install an access-list denying		In the example of Figure 5, AS64502 would install an access-list
	packets matching 10.0.0.0/24 associated with the interface connecting		denying packets matching 2001:DB8::/34 associated with the interface
	to AS4. As a result, traffic destined to that prefix would be		connecting to AS64504. As a result, traffic destined to that prefix
	dropped, despite the existence of a valid route towards 10.0.0.0/22.		would be dropped, despite the existence of a valid route towards
			2001:DB8::/32.
	Note that this technique actually lets packets destined to a valid
	prefix be dropped while they are sent from a neighboring AS that
	cannot know about policy conflicts and hence had no means to avoid
	the creation of unexpected traffic flows.
	5.2.2. Automatic overlapping prefix filtering
	As described in Section 3, filtering of overlapping prefixes can in		This technique actually lets packets destined to a valid prefix be
	some scenarios lead to unexpected traffic flows. Nevertheless,		dropped while they are sent from a neighboring AS that may not know
	depending on the autonomous system implementing such practice, this		about the policy conflict and hence had no means to avoid the
	operation can prevent these cases. This can be illustrated using the		creation of unexpected traffic flows. For this reason, this
	example described in Figure 11: if AS2 or AS3 filter prefix 10.0.0.0/		technique can be considered harmful and is thus not recommended for
	24, there would be no unexpected traffic flow in AS2. Nevertheless,		implementation.
	as described in Section 5.1, the filtering of overlapping prefixes
	can generate conflicts between AS1 and AS2, since AS2 would not
	forward traffic according to AS1's policy. Additionally, AS2 can
	lose traffic share for the overlapping prefix from customers
	different from AS1.
	5.2.3. 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 11 from the		As an example, let us analyze the scenario of Figure 5 from the point
	point of view of AS2. The edge router connecting to the AS4 forward		of view of AS64502. The edge router connecting to the AS64504
	packets destined to prefix 10.0.0.0/24 towards AS5. Likewise, it		forwards packets destined to prefix 2001:DB8::/34 towards AS64505.
	will forward packets destined to prefix 10.0.0.0/22 towards AS1. The		Likewise, it forwards packets destined to prefix 2001:DB8::/32
	router, however, only propagates the path of the covering prefix		towards AS64501. The router, however, only propagates the path of
	(10.0.0.0/22) to AS4. An operator could implement the necessary		the covering prefix (2001:DB8::/32) to AS64504. An operator could
	techniques to force the edge router to forward packets coming from		implement the necessary techniques to force the edge router to
	AS4 based only on the paths propagated to AS4. Thus, the edge router		forward packets coming from AS64504 based only on the paths
	would forward packets destined to 10.0.0.0/24 towards AS1 in which		propagated to AS64504. Thus, the edge router would forward packets
	case no unexpected traffic flow would occur.		destined to 2001:DB8::/34 towards AS64501 in which case no unexpected
			traffic flow would occur.
	Different techniques could provide the functionality just described;		Different techniques could provide this functionality; however, their
	however, their technical implementation can be complex to design and		technical implementation can be complex to design and operate. An
	operate. [2] describes an approach to implement this behavior.		operator could, for instance, employ Virtual Routing Forwarding (VRF)
	Similar to the solution described in Section 5.2.2, this approach		tables RFC4364 [4] to store the routes announced to a neighbor and
	could create conflicts between AS2 and AS1, since the traffic		forward traffic exclusively based on those routes. [2] describes this
	forwarding performed by A2 goes against the policy of AS1.		solution and provides a description of its limitations. In the
			future, new network protocols and architectures could provide this
			functionality with less overhead for management and device resources.
	6. Conclusions		Note that similarly to the solution described in Section 4.1, this
			approach could create conflicts between AS64502 and AS64501, since
			the traffic forwarding performed by AS64502 goes against the policy
			of AS64501.
	In this document, we described threats to policies of autonomous		5. Conclusions
	systems caused by the filtering of overlapping prefixes performed by
	external networks. We provide examples of scenarios in which		In this document, we described how the filtering of overlapping
	unexpected traffic flows are caused by these practices and introduce		prefixes can potentially create unexpected traffic flows in remote
	some techniques for their detection and prevention. Analyzing the		ASes. We provided examples of scenarios in which unexpected traffic
	different options for dealing with this kind of problems, we		flows are caused by these practices and introduce some techniques for
	recommend potential victims to implement monitoring systems that can		their detection and prevention. Analyzing the different options for
			dealing with this kind of problems, we recommend ASes affected by
			unexpected traffic flows 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 network
	operators implement this type of filters only after considering the		operators to implement this type of filters considering the cases
	cases described in this document.		described in this document.
	7. References		6. Security Considerations
			It is possible for an AS to use any of the methods described in this
			document to deliberately reroute traffic flowing through another AS.
			The objective of this document is to inform on this potential routing
			security issue.
			7. IANA Considerations
			This document has no IANA actions.
			8. Acknowledgments
			The authors would like to thank Wes George, Jon Mitchell, and Bruno
			Decraene for their useful suggestions and comments.
			9. References
			9.1. References
	[1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM		[1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM
	SIGCOMM Computer Communication Review vol. 38, no. 2, pp.		SIGCOMM Computer Communication Review vol. 38, no. 2, pp.
	55-59, April 2008.		55-59, April 2008.
	[2] Vanbever, L., Francois, P., Bonaventure, O., and J.		[2] 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
	http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf,		http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf,
	October 2009.		October 2009.
	[3] "INIT7-RIPE63", <http://ripe63.ripe.net/presentations/48		[3] "INIT7-RIPE63", <http://ripe63.ripe.net/presentations/48-
	-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.		How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
	7.2. URIs		[4] "pmacct project: IP accounting iconoclasm",
			<http://www.pmacct.net>.
			9.2. URIs
	[1] http://www.ietf.org/rfc/rfc1812.txt		[1] http://www.ietf.org/rfc/rfc1812.txt
	[2] http://tools.ietf.org/html/draft-white-grow-overlapping-routes-02		[2] http://www.ietf.org/rfc/rfc4384.txt
	[3] http://www.ietf.org/rfc/rfc4384.txt		[3] http://www.ietf.org/rfc/rfc7011.txt
			[4] http://www.ietf.org/rfc/rfc4364.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
End of changes. 83 change blocks.
	664 lines changed or deleted		456 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/