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/