draft-ietf-grow-filtering-threats-03.txt   draft-ietf-grow-filtering-threats-04.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: February 5, 2015 IMDEA Networks Expires: August 13, 2015 IMDEA Networks
Paolo Lucente Paolo Lucente
Cisco Systems Cisco Systems
August 4, 2014 February 9, 2015
Making BGP filtering a habit: Impact on policies Impact of BGP filtering on Inter-Domain Routing Policies
draft-ietf-grow-filtering-threats-03 draft-ietf-grow-filtering-threats-04
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 filtering, or restricting the propagation of overlapping systems filtering, or restricting the propagation of more specific
prefixes. We provide a review of the techniques to detect the prefixes. We provide a review of the techniques to detect the
occurrence of this issue and defend against it. occurrence of 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 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 February 5, 2015. This Internet-Draft will expire on August 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
overlapping 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 overlapping 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 overlapping 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 counter unexpected traffic flows . . . . . . . 10 4. Techniques to counter unexpected traffic flows . . . . . . . 10
4.1. Reactive counter-measures . . . . . . . . . . . . . . . . 11 4.1. Reactive counter-measures . . . . . . . . . . . . . . . . 11
4.2. Anticipant counter-measures . . . . . . . . . . . . . . . 12 4.2. Proactive counter-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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. References . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Informative References . . . . . . . . . . . . . . . . . 14
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 (overlapping) prefix in the BGP routing system, along with specific prefix in the BGP routing system, along with the less
the covering prefix that they originate. It is also possible for specific prefix that they originate. It is also possible for some
some Autonomous Systems (ASes) to apply different policies to the Autonomous Systems (ASes) to apply different policies to the more
overlapping and the covering prefix. specific and the less specific prefix.
While BGP makes independent, policy driven decisions for the While 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 [1]). The existence of a prefix p "precedes" any BGP policy (RFC1812 [1]). The existence of a prefix p
that is more specific than a prefix p' in the Forwarding Information that is more specific than a prefix p' in the Forwarding Information
Base (FIB) will let packets whose destination matches p be forwarded Base (FIB) will let packets whose destination matches p be forwarded
according to the next hop selected as best for p (the overlapping according to the next hop selected as best for p (the more specific
prefix). This process takes place by disregarding the policies prefix). This process takes place by disregarding the policies
applied in the control plane for the selection of the best next-hop applied in the control plane for the selection of the best next-hop
for p'. When an Autonomous System filters overlapping prefixes and for p'. When an Autonomous System filters more specific prefixes and
forwards packets according to the covering prefix, the discrepancy in forwards packets according to the less specific prefix, the
the routing policies applied to covering and overlapping prefixes can discrepancy in the routing policies applied to the less and the more
create unexpected traffic flows that infringe the policies of other specific prefixes can create unexpected traffic flows that infringe
ASes, still holding a path towards the overlapping prefix. the policies of other ASes, still holding a path towards the more
specific prefix.
The objective of this draft is to shed light on possible side effects The objective of this draft is to shed light on possible side effects
associated with overlapping prefix filtering. This document presents associated with more specific prefix filtering. This document
examples of such side effects and discusses approaches towards presents examples of such side effects and discusses approaches
solutions to the problem. 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 overlapping prefixes provide some scenarios in which the filtering of more specific
leads to the creation of unexpected traffic flows. Section 3 and prefixes leads to the creation of unexpected traffic flows.
Section 4 discuss some techniques that ASes can use for, Section 3 and Section 4 discuss some techniques that ASes can use
respectively, detect and react to unexpected traffic flows. We for, respectively, detect and react to unexpected traffic flows. We
conclude in Section 5. conclude in Section 5.
1.1. Terminology 1.1. Terminology
Overlapping 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 another prefix present in the routing table. range that is covered by a shorter prefix also present in the routing
table.
Covering prefix: A prefix in the routing table with an address range Less specific prefix: A prefix in the routing table with an address
partially covered by other prefixes. range partially covered by other prefixes.
We re-use the definitions of customer-transit peering and settlement- We re-use the definitions of customer-transit peering and settlement-
free peering of RFC4384 [2]. free peering of RFC4384 [2].
Selective advertisement: The behavior of only advertising a self Selective advertisement: The behavior of only advertising a self
originated BGP path for a prefix over a strict subset of the eBGP originated BGP path for a prefix over a strict subset of the eBGP
sessions of the AS. sessions of the AS.
Selective propagation: The behavior of only propagating a BGP path Selective propagation: The behavior of only propagating a BGP path
for a prefix over a strict subset of the eBGP sessions of an AS. for a prefix over a strict subset of the eBGP sessions of an AS.
skipping to change at page 4, line 14 skipping to change at page 4, line 14
Unexpected traffic flow: Traffic flowing between two neighboring ASes Unexpected traffic flow: Traffic flowing between two neighboring ASes
of an AS, although the transit policy of that AS is to not provide of an AS, although the transit policy of that AS is to not provide
connectivity between these two neighbors. A traffic flow across an connectivity between these two neighbors. A traffic flow across an
AS, between two of its transit providers, or between a transit AS, between two of its transit providers, or between a transit
provider and one of its settlement-free peers, are classical examples provider and one of its settlement-free peers, are classical examples
of unexpected traffic flows. of unexpected traffic flows.
2. Unexpected Traffic Flows 2. Unexpected Traffic Flows
In this section, we describe how overlapping 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
Local filtering can be motivated by different reasons, such as: (1) Local filtering can be motivated by different reasons, such as: (1)
Traffic engineering, where an AS wants to control their local Traffic engineering, where an AS wants to control its local outbound
outbound traffic distribution using only the policy applied to the traffic distribution using only the policy applied to the less
covering prefix. (2) Enforcing contract compliance, where, for specific prefix. Such a practice was notably documented in [3] (2)
instance, an AS avoids a settlement-free peer to attract traffic to Enforcing contract compliance, where, for instance, an AS avoids a
one link by using selective advertisement, when this is not allowed settlement-free peer to attract traffic to one link by using
by their peering agreement. selective advertisement, when this is not allowed by their peering
agreement. (3) The need for Forwarding Information Base memory
preservation sometimes pushes ISP operators to filter more specific
prefixes.
Figure 1 illustrates a scenario in which one AS is motivated to Figure 1 illustrates a scenario in which one AS is motivated to
perform local filtering due to outbound traffic engineering. The perform local filtering due to outbound traffic engineering. The
figure depicts AS64504, and two of its neighboring ASes, AS64502 and figure depicts AS64504, and two of its neighboring ASes, AS64502 and
AS64505. AS 64504 has a settlement-free peering with AS64502 and is AS64505. AS64504 has a settlement-free peering with AS64502 and is a
a customer of AS64505. AS64504 receives from AS64505 prefixes customer of AS64505. AS64504 receives from AS64505 prefixes
2001:DB8::/32 and 2001:DB8::/34, covering and overlapping prefixes, 2001:DB8::/32 and 2001:DB8::/34, a less specific and a more specific
respectively. AS64504 receives only the covering prefix prefix, respectively. AS64504 receives only 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 |
| |
,--+--. 2001:DB8::/32 ,-----. ,--+--. 2001:DB8::/32 ,-----.
/ \ <-- / \ / \ <-- / \
( AS64504 )-------------( AS64502 ) ( AS64504 )-------------( AS64502 )
\ / \ / \ / \ /
`-----' `-----' `-----' `-----'
Figure 1: Local Filtering Figure 1: Local Filtering
Due to economical 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
overlapping prefix, 2001:DB8::/34, on the session with AS64505. more specific prefix, 2001:DB8::/34, on the session with AS64505.
After the filter is applied, traffic to the overlapping prefix will After the filter is applied, traffic to the more specific prefix will
be sent to AS64502 be sent to AS64502
2.1.1. Unexpected traffic flows caused by local filtering of 2.1.1. Unexpected traffic flows caused by local filtering of more
overlapping 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 overlapping prefix and only announces it to advertisement with the more specific prefix and only announces it to
AS64503. AS64503.
After AS64504 locally filters the overlapping 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 from the AS64503. However, due to the discrepancies of routes between the
overlapping and covering 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 50 skipping to change at page 6, line 50
with communities, in order to tweak the propagation behavior of the with communities, in order to tweak the propagation behavior of the
ASes that handle these paths [1]. Some ISPs allow their customers to ASes that handle these paths [1]. Some ISPs allow their customers to
use such communities to let the receiving AS not export the path to use such communities to let the receiving AS not export the path to
some selected neighboring ASes. By combining communities, the prefix some selected neighboring ASes. By combining communities, the prefix
could be advertised only to a given peer of the AS providing this could be advertised only to a given peer of the AS providing this
feature. Remote filtering can be leveraged by an AS to, for feature. Remote filtering can be leveraged by an AS to, for
instance, limit the scope of prefixes and hence perform a more instance, limit the scope of prefixes and hence perform a more
granular inbound traffic engineering. 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 an overlapping 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 through AS64502 originates prefix 2001:DB8::/32, which it advertises to AS64502 and
and AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501
AS64501 do selective advertisement and only propagate 2001:DB8::/34 do selective advertisement and only propagate 2001:DB8::/34 over
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 Let us consider that AS64501 decides to limit the scope of the more
overlapping prefix. AS64501 can make this decision based on its specific prefix. AS64501 can make this decision based on its traffic
traffic engineering strategy. To achieve this, AS64501 can tag the engineering strategy. To achieve this, AS64501 can tag the more
overlapping prefix with a set of communities that leads AS64503 to specific prefix with a set of communities that leads AS64503 to only
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 \ /
`. ,' -> /34 `. ,' `. ,' -> /34 `. ,'
'-----; <- / '-----' '-----; <- / '-----'
skipping to change at page 7, line 40 skipping to change at page 7, line 40
| ,' `. | 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 overlapping prefixes of more specific prefixes
Figure 4 expands the scenario from Figure 3 and includes other AS Figure 4 expands the scenario from Figure 3 and includes other AS
peering with ASes 64502 and 64503. Due to the limitation on the peering with ASes 64502 and 64503. Due to the limitation on the
scope performed on the overlapping prefix, ASes that are not scope performed on the more specific prefix, ASes that are not
customers of AS64502 will not receive a path for 2001:DB8::/34. customers of AS64502 will not receive a path for 2001:DB8::/34.
These ASes will forward packets destined to 2001:DB8::/34 according These ASes will forward packets destined to 2001:DB8::/34 according
to their routing state for 2001:DB8::/32. Let us assume that AS64505 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 is such an AS, and that its best path towards 2001:DB8::/32 is
through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will through AS64502. Packets sent towards 2001:DB8::1 by AS64505 will
reach AS64502. However, in the data-plane of the nodes of AS64502, 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 the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is
reached through AS64503, a settlement-free peer of AS64502. Since reached through AS64503, a settlement-free peer of AS64502. Since
AS64505 is not in the customer branch of AS64502, we are in a AS64505 is not in the customer branch of AS64502, we are in a
situation in which traffic flows between non-customer ASes take place situation in which traffic flows between non-customer ASes take place
skipping to change at page 8, line 40 skipping to change at page 8, line 40
| ,' `. | 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
overlapping 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 his policy is providing transit between two of its peers, although his policy is
configured to not provide such transit. IPFIX (RFC7011 [3]) is an configured to not provide such transit. IPFIX (RFC7011 [3]) is 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
skipping to change at page 9, line 16 skipping to change at page 9, line 16
Note that the AS detecting the unexpected traffic flow may simply Note that the AS detecting the unexpected traffic flow may simply
realize that his policy configuration is broken. The first realize that his 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 it has been assessed that the local configuration is correct, Once it has been assessed that the local configuration is correct,
the operator should check if the problem detected in the data-plane the operator should check if the problem detected in the data-plane
arose due to filtering of BGP paths by neighboring ASes. The arose due to filtering of BGP paths by neighboring ASes. The
operator should check if the destination address of the unexpected operator should check if the destination address of the unexpected
traffic flow is locally routed as per an overlapping prefix only traffic flow is locally routed as per a more specific prefix only
received from non-customer peers. The operator should also checks if received from non-customer peers. The operator should also checks if
there are paths to a covering prefix received from a customer, and there are paths to a less specific prefix received from a customer,
hence propagated to peers. If these two situations happen at the and hence propagated to peers. If these two situations happen at the
same time, the neighboring AS at the entry point of the unexpected same time, the neighboring AS at the entry point of the unexpected
flow is routing the traffic based on the covering prefix, although flow is routing the traffic based on the less specific prefix,
the ISP is actually forwarding the traffic via non-customer links. although the ISP is actually forwarding the traffic via non-customer
links.
To detect the origin of the problem, human interaction or looking To detect the origin of the problem, human interaction or looking
glasses can be used in order to find out whether local filtering, glasses can be used in order to find out whether local filtering,
remote filtering, or selective propagation was performed on the remote filtering, or selective propagation was performed on the more
overlapping prefix. Due to the distributed nature and restricted specific prefix. Due to the distributed nature and restricted
visibility of the steering of BGP policies, such analysis is deemed visibility of the steering of BGP policies, such analysis is deemed
to not identify the origin of the problem with guaranteed accuracy. to not identify the origin of the problem with guaranteed accuracy.
We are not aware, at the time of this writing, of any openly We are not aware, at the time of this writing, of any openly
available tool that can automatically perform this operation. available tool that can automatically perform this operation.
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 be causing unexpected traffic It can be considered problematic to be causing unexpected traffic
flows in 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 relationship implementations. trouble-shooting 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.
It is advisable for an AS to assess the risks of filtering It is advisable for an AS to assess the risks of filtering more
overlapping prefixes before implementing them by obtaining as much specific prefixes before implementing them by obtaining as much data
data information as possible about its surrounding routing information as possible about its surrounding routing environment.
environment. The AS would need information of the routing policies The AS would need information of the routing policies and the
and the relationships among external ASes to detect if its actions relationships among external ASes to detect if its actions could
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 information, the operator could detect other ASes receiving the more
overlapping prefix from non-customer ASes, while announcing the specific prefix from non-customer ASes, while announcing the less
covering prefix to other non-customer ASes. If the filtering of the specific prefix to other non-customer ASes. If the filtering of the
overlapping prefix leads other ASes to send traffic for the more specific prefix leads other ASes to send traffic for the more
overlapping prefix to these ASes, an unexpected traffic flow can specific prefix to these ASes, an unexpected traffic flow can arise.
arise. However, the information required for this operation is However, the information required for this operation is difficult to
difficult to obtain, due to the distributed nature of BGP policies. obtain, due to the distributed nature of BGP policies. We are not
We are not aware, at the time of this writing, of any openly aware, at the time of this writing, of any openly available tool that
available tool that can automatically perform this procedure. can automatically perform this procedure.
4. Techniques to counter unexpected traffic flows 4. Techniques to counter unexpected traffic 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 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. We provide potential solutions that ISPs applied to all situations. We provide potential solutions that ISPs
must evaluate against each particular case. We classify these must evaluate against each particular case. We classify these
actions according to whether they are anticipant or reactive. 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. Based on our analysis, we observe that anticipant of approaches. Based on our analysis, we observe that proactive
approaches can be complex to implement and can lead to undesired approaches can be complex to implement and can lead to undesired
effects. Therefore, we conclude that the reactive approach is the effects. Therefore, we conclude that the reactive approach is the
more reasonable recommendation to deal with unexpected flows. more reasonable recommendation to deal with unexpected flows.
____,,................______ ____,,................______
_,.---'''' `''---..._ _,.---'''' `''---..._
,-'' AS64505 `-. ,-'' AS64505 `-.
[ / [ /
-.._ __.-' -.._ __.-'
. `'---....______ ______...---'' . `'---....______ ______...---''
skipping to change at page 11, line 48 skipping to change at page 11, line 48
4.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 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
overlapping 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 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 less specific prefix
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 overlapping 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, not all traffic the eBGP session with AS64504. In this case, traffic heading to
heading to the prefix 2001:DB8::/32 from AS64501 would no longer the prefix 2001:DB8::/32 from AS64501 would no longer traverse
traverse AS64502. AS64502 should evaluate if solving the issues AS64502. AS64502 should evaluate if solving the issues originated
originated by the unexpected traffic flows are worth the loss of by the unexpected traffic flows are worth the loss of this traffic
this traffic share. share.
o An operator can decide to filter out the overlapping prefix at the o An operator can decide to filter out the more specific prefix at
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
overlapping 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.
It is possible that the behavior of the neighboring AS causing the It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows opposes the peering agreement. In this unexpected traffic flows opposes the peering agreement. In this
case, an operator could account the amount of traffic that has been case, an operator could account the amount of traffic that has been
subject to the unexpected flows, using traffic measurement protocols subject to the unexpected flows, using traffic measurement protocols
such as IPFIX, and charge the peer for that traffic. That is, the such as IPFIX, and charge the peer for that traffic. That is, the
operator can claim that it has been a provider of that peer for the operator can claim that it has been a provider of that peer for the
traffic that transited between the two ASes. traffic that transited between the two ASes.
4.2. Anticipant counter-measures 4.2. Proactive counter-measures
4.2.1. Access lists 4.2.1. Access lists
An operator can configure its routers to install dynamically an An operator could install access-lists to prevent unexpected traffic
access-list made of the prefixes towards which the forwarding of flows from happening in the first place. In the example of Figure 5,
traffic from that interface would lead to unexpected traffic flows. AS64502 would install an access-list denying packets matching
In the example of Figure 5, AS64502 would install an access-list 2001:DB8::/34 associated with the interface connecting to AS64504.
denying packets matching 2001:DB8::/34 associated with the interface As a result, traffic destined to that prefix would be dropped,
connecting to AS64504. As a result, traffic destined to that prefix despite the existence of a valid route towards 2001:DB8::/32.
would be dropped, despite the existence of a valid route towards
2001:DB8::/32.
This technique actually lets packets destined to a valid prefix be The operational overhead of such a solution is considered high as the
dropped while they are sent from a neighboring AS that may not know operator would have to constantly adapt these access-lists to
about the policy conflict and hence had no means to avoid the accommodate inter-domain routing changes. Moreover, this technique
creation of unexpected traffic flows. For this reason, this lets packets destined to a valid prefix be dropped while they are
technique can be considered harmful and is thus not recommended for sent from a neighboring AS that may not know about the policy
implementation. conflict, and hence had no means to avoid the creation of unexpected
traffic flows. For this reason, this technique can be considered
harmful and is thus not recommended for implementation.
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 covering prefix (2001:DB8::/32) to AS64504. An operator could the less specific prefix (2001:DB8::/32) to AS64504. An operator
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 unexpected
traffic flow would occur. 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 Virtual Routing Forwarding (VRF)
tables RFC4364 [4] to store the routes announced to a neighbor and tables (RFC4364 [4]) to store the routes announced to a neighbor and
forward traffic exclusively based on those routes. [2] describes this forward traffic exclusively based on those routes. [2] describes the
solution and provides a description of its limitations. In the use of such an architecture for Internet routing, and provides a
future, new network protocols and architectures could provide this description of its limitations.
functionality with less overhead for management and device resources.
Note that similarly to the solution described in Section 4.1, this In such an architecture, packets received from a peer would be
forwarded 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. 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 unexpected flow will not take place. Packets will be
forwarded based on the policy compliant less specific prefix.
However, note that an operator must make sure that all their routers
could support the potential performance impact of this approach.
note that similarly 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
In this document, we described how the filtering of overlapping In this document, we described how the filtering of more specific
prefixes can potentially create unexpected traffic flows in remote prefixes can potentially create unexpected traffic flows in remote
ASes. We provided examples of scenarios in which unexpected traffic ASes. We provided examples of scenarios in which unexpected traffic
flows are caused by these practices and introduce some techniques for flows are caused by these practices and introduce some techniques for
their detection and prevention. Analyzing the different options for their detection and prevention. Analyzing the different options for
dealing with this kind of problems, we recommend ASes affected by dealing with this kind of problems, we recommend ASes to implement
unexpected traffic flows to implement monitoring systems that can monitoring systems that can detect them and react to them according
detect them and react to them according to the specific situation. to the specific situation. Although we observe that there are
Although we observe that there are reasonable situations in which reasonable situations in which ASes could filter more specific
ASes could filter overlapping prefixes, we encourage network prefixes, we encourage network operators to implement this type of
operators to implement this type of filters considering the cases filters considering the cases described in this document.
described in this document.
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.
The objective of this document is to inform on this potential routing The objective of this document is to inform on this potential routing
security issue. security issue, and analyse ways for operators to defend against
them.
It must be noted that, at the time of this document, there are no
existing or proposed tools to automatically protect against such
behavior. Network monitoring allowing for the detection of
unexpected traffic flows exist, but automated configuration changes
to solve the problem do not.
7. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Wes George, Jon Mitchell, and Bruno The authors would like to thank Wes George, Jon Mitchell, and Bruno
Decraene for their useful suggestions and comments. Decraene for their useful suggestions and comments.
9. References 9. References
9.1. References 9.1. Informative 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.
 End of changes. 56 change blocks. 
137 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/