One document matched: draft-cardona-filtering-threats-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="no" ?>
<?rfc compact="yes"?>
<rfc ipr='trust200902' docName='draft-cardona-filtering-threats-02' category="info">
<front>
<title abbrev="Making BGP filtering a habit">Making BGP filtering a habit: Impact on policies</title>
<author surname="Camilo Cardona" fullname="Camilo Cardona">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avenida del Mar Mediterraneo, 22</street>
<city>Leganes</city> <code>28919</code>
<country>Spain</country>
</postal>
<!--><uri>http://inl.info.ucl.ac.be/pfr</uri><-->
<email>juancamilo.cardona@imdea.org</email>
</address>
</author>
<author surname="Pierre Francois" fullname="Pierre Francois">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avenida del Mar Mediterraneo, 22</street>
<city>Leganes</city> <code>28919</code>
<country>Spain</country>
</postal>
<!--><uri>http://inl.info.ucl.ac.be/pfr</uri><-->
<email>pierre.francois@imdea.org</email>
</address>
</author>
<!--
<author surname="Bruno Quoitin" name ="Quoitin" fullname="Bruno Quoitin">
<organization>UMons</organization>
<address>
<postal>
<street>Bâtiment Pentagone</street>
<street>Avenue du Champ de Mars, 6</street>
<city>Mons</city> <code>7000</code>
<country>BE</country>
</postal>
<email>bruno.quoitin@UMons.ac.be</email>
</address>
</author>
-->
<date month="July" year="2013" />
<area>General</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<!-- I just modified slightly this paragraph, we can
complete it later -->
<!--<t>This draft describes threats to the
Internet routing policies of an autonomous system
due to filtering of more specific BGP prefixes by its neighboring domains.
</t>-->
<t>Network operators define their BGP policies
based on the business relationships that they
maintain with their peers. By limiting the propagation
of BGP prefixes, an autonomous
system avoids the existence of flows between BGP
peers that do not provide any economical gain.
This draft describes how undesired flows
can emerge in autonomous systems due to the filtering
of overlapping BGP prefixes by neighboring domains.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is common practice for network operators to propagate
overlapping prefixes along with the prefixes that they originate. It is also possible for
some Autonomous Systems (ASes) to apply different policies to the overlapping (more specific)
and the covering (less specific) prefix. Some ASes can even benefit from
filtering the overlapping prefixes.
<!--On the other hand, it can be beneficial
for some Autonomous Systems (ASes) to filter overlapping prefixes.
This operation needs to be translated into various requirements
in order to be automallically performed <eref
target='http://tools.ietf.org/html/draft-white-grow-overlapping-routes-00'>DRAFT-WHITE</eref>.-->
</t>
<t>BGP makes independent, policy driven decisions for the selection of the best
path to be used for a given IP prefix. However, routers must forward packets using
the longest-prefix-match rule, which "precedes" any BGP policy (<eref target='http://www.ietf.org/rfc/rfc1812.txt'>RFC1812</eref>).
Indeed, the existence of a prefix p that is more specific than a prefix p' in the
Forwarding Information Base (FIB) will let packets whose
destination matches p be forwarded according to the next hop selected as best
for p (the overlapping prefix). This process takes place by disregarding
the policies applied in the control plane for the selection of the best
next-hop for p' (the covering prefix). When overlapping prefixes are filtered
and packets are forwarded according to the covering prefix, the discrepancy in
the routing policies applied to covering and overlapping prefixes can create undesired traffic flows
that infringe the policies of Internet
Service Providing (ISPs) still holding a path towards the overlapping prefix.</t>
<!--Due to the complex system created by the interplay of BGP
policies existing in the Internet-->
<!--<t>Furthermore, Through selected advertisements of a more specific prefix
by some other ISPs, the configured policies of an ISP can be
violated due to this essential data-plane/control-plane
difference.</t>-->
<t>This document presents examples of such cases and discusses
solutions to the problem. The objective of this draft is to shed light on the use of prefix filtering
by making the routing community aware of the cases where the effects of filtering might turn
to be negative for the business of ISPs.</t>
<t>The rest of the document is organized as follows: <xref target = "sec:scoping_technique"/>
illustrates the motivation to filter overlapping prefixes.
In <xref target = "sec.uses"/>, we provide some scenarios in which the filtering of overlapping prefixes
lead to the creation of undesired traffic flows on other ASes. <xref target = "sec.detect"/> and <xref target = "sec.tecniques_to_counter"/>
discuss some techniques that ASes can use for, respectively, detect and react to undesired traffic flows.</t>
</section>
<section title ="Filtering overlapping prefixes" anchor="sec:scoping_technique">
<t>There are several scenarios where filtering an overlapping prefix is
relevant to the operations of an AS. In this section, we provide examples
of these scenarios. We differentiate cases in which the filtering is
performed locally from those where the filtering is triggered
remotely. These scenarios will be used as a base
in <xref target = "sec.uses"/> for describing side effects bound with such
practices.</t> <!--notably the creation of undesired traffic flows that violate the policy in the ASes surrounding the AS
applying the procedure.</t>-->
<section title ="Local filtering" anchor="sec:local_scoping_technique">
<t>Let us first analyze the scenario depicted in <xref target = "Basic_Scen1"/>.
AS1 and AS2 are two autonomous systems spanning a
large geographical area and peering in 3 different physical locations.
Let AS1 announce prefix 10.0.0.0/22 over all peering links with AS1.
Additionally, let us define that there is part
of AS1's network which exclusively uses prefix 10.0.0.0/24 and
which is closer to a peering point than to others.</t>
<t>To receive the traffic destined to prefix 10.0.0.0/24 on the link closer to this subnet,
AS1 could announce the overlapping prefix only over this specific session.
At the time of the establishment of the peering, it can be defined by both ASes
that hot potato routing would happen in both directions of traffic. In other words, it was agreed that each AS will deliver the
traffic to the other AS on the nearest peering link.
In this scenario, it becomes relevant to AS2 to enforce such practice by
detecting the described situations and automatically issuing the appropriate filtering. In this case,
by implementing these automatic procedures, AS2 would legitimately detect and filter prefix 10.0.0.0/24.</t>
<figure anchor="Basic_Scen1" title="Basic scenario of local filtering" align="center"><artwork><![CDATA[
___....-----------....___
,.--' AS2 `--..
,' `.
| |
`._ _.'
`--..__ _,,.--'
. `'''-----------'''' |
| | |
| | |
10.0.0.0/22| 10.0.0.0/22| |10.0.0.0/22
| ___....-----------....___ |10.0.0.0/24
,.--'AS1 `--..
,' ...........`.
| |10.0.0.0/24 |
`._ |........._.'
`--..__ _,,.--'
`'''-----------''''
]]>
</artwork>
</figure>
<t>Local filtering could be required in other cases.
For example, a dual homed AS receiving an overlapping prefix from only one of its providers.
<xref target = "Basic_Scen2"/>
depicts a simple example of this case.</t>
<figure anchor="Basic_Scen2" title="Basic scenario of local filtering" align="center"><artwork><![CDATA[
_..._
,' `.
/ AS4 \
| |
\ /
,`-...-'.
/ '.
10.0.0.0/22 ,' \
10.0.0.0/24 / \ 10.0.0.0/22
..:_ >..._
,' `. ,' `.
/ AS2 \ / AS3 \
| | | |
\ / \ /
`-...-', `-...-'
\ /
\ /
10.0.0.0/22 \_..._ '10.0.0.0/22
10.0.0.0/24,' `.
/ AS1 \
| |
\ /
`-...-'
]]>
</artwork>
</figure>
<t>In this scenario, prefix 10.0.0.0/22 is advertised by AS1 to AS2 and AS3. Both ASes propagate
the prefix to AS4. Additionally, AS1 advertises prefix 10.0.0.0/24
to AS2, which subsequently propagates the prefix to AS4.</t>
<t>It is possible that AS4 resolves to filter
the more specific prefix 10.0.0.0/24. One potential
motivation could be the economical preference of the path via AS2 over AS3.
Another feasible reason is the existence of a technical policy by AS4
of aggregating incoming prefixes longer than /23.<!--Should we write that
this practice is "violating" the traffic engineering purposes of the originaring AS?--></t>
<t>The above examples illustrate two of the many motivations to
configure routing within an AS with the aim of ignoring more specific
prefixes. Operators have reported applying these filters in a manual fashion
<xref target='INIT7-RIPE63' />.
The relevance of such practice led to investigate
automated filtering procedures in <eref target='http://tools.ietf.org/html/draft-white-grow-overlapping-routes-00'>I-D.WHITE</eref>.</t>
</section>
<section title ="Remotely triggered filtering" anchor="sec:remote_scoping_technique">
<t>ISPs can tag the BGP paths that they propagate to neighboring
ASes with communities, in order to tweak the propagation behavior of the
ASes that handle these paths <xref target='on_BGP_communities' />.</t>
<t>Some ISPs allow their direct and indirect customers to use such
communities to let the receiving AS not export the path to
some selected neighboring AS. By combining communities, the prefix could
be advertised only to a given peer of the AS providing this feature.
<xref target = "example_remote_triggered"/>
illustrates an example of this case.</t>
<!--Sometimes, such communities can be
combined, so as to have the prefix advertised only to a given peer
of the AS providing the "feature".</t>
<t>Some operators also allow their
direct and indirect customers to use communities so as to let the
receiving AS not export that path to other ASes at all
-->
<figure anchor="example_remote_triggered" title="Remote triggered filtering" align="center"><artwork><![CDATA[
10.0.0.0/22 ,' \
10.0.0.0/24 / \ 10.0.0.0/22
..:_ >..._
,' `. ,' `.
/ AS2 \________ / AS3 \
| |/22 /22| |
\ / \ /
`-...-', `-...-'
\ /
\ /
10.0.0.0/22 \_..._ '10.0.0.0/22
10.0.0.0/24,' `.
/ AS1 \
| |
\ /
`-...-'
]]></artwork>
</figure>
<t>AS2 and AS3 are peers. Both ASes are providers of AS1. For traffic engineering purposes,
AS1 could use communities to prevent AS2 from announcing prefix 10.0.0.0/24 to AS3.
</t>
<t>Such technique is useful for operators to tweak
routing decisions in order to align with complex transit policies. We will
see in later sections that by producing the same effect as filtering,
they can also lead to undesired traffic flows at other, distant, ASes. </t>
</section>
</section>
<!--<section title = "Uses of more specific prefix filtering that violate policies" anchor = "sec.uses">-->
<section title = "Uses of overlapping prefix filtering that create undesired traffic flows" anchor = "sec.uses">
<t>In this section we define the concept of undesired traffic flows
and describe three configuration scenarios that lead to their creation. Note
that these examples do not capture all the cases where such issues
can take place. More examples will be provided in
future revisions of this document.</t>
<section title = "Undesired Traffic Flows" anchor="sec.unexpectedforwardingdefinition">
<t>The BGP policy of an Internet Service provider includes
all actions performed over its originated routes and the
routes received externally. One important part of the BGP policy is the
selection of the routes that are propagated to each
neighboring AS. One of the goals of these policies is to
allow ISPs to avoid transporting traffic between two ASes without economical gain. For instance, ISPs
typically propagate to their peers only routes coming
from its customers (<eref target='http://www.ietf.org/rfc/rfc4384.txt'>RFC4384</eref>).
<!--This policy attempts to avoid the existence of flows between two peers or between a peer and transit provider.-->
We briefly illustrate this operation in
<xref target = "UNEXPECTED_FORWARDING_S"/>. In the figure,
AS2 is establishing a settlement free peering with AS1 and
AS3. AS2 receives prefix P3/p3, from AS3. AS2, however, is
not interested in transporting traffic from AS1 to AS3,
therefore it does not propagate the prefix to AS3. In the figure, we also show a
customer of AS2, AS4, which is announcing prefix P4/p4. AS2 propagates this prefix to AS1.</t>
<figure anchor="UNEXPECTED_FORWARDING_S" title="Prefix exchange among four autonomous systems" align="center"><artwork><![CDATA[
,-'''-.. ,-'''-.. ,-'''-..
,' \ ,' \ ,' \
.' \ .' \ .' \
| |------| | ----| P3/p3 |
\ AS1 / P4/p4\ AS2 / \ AS3/
\ ,' \ ,' \ ,'
`-...-' `-...-' `-...-'
|
|
|
,-'''-..
,' P4/p4 \
.' \
| |
\ AS4 /
\ ,'
`-...-'
]]></artwork>
</figure>
<t>Although ISPs usually implement the aforementioned policies, undesired traffic flows may still appear. In <xref target = "UNEXPECTED_FORWARDING_S"/>,
undesired traffic flows are created, when, despite AS2’s policy, traffic arriving from peer AS1 is received and transported to AS3 by AS2. These type of traffic flows can arise due to a number of reasons. Specifically, in this document we explain how the filtering of overlapping prefixes might cause undesired traffic flows on ASes. We provide examples of these cases in the next sections.</t>
<section title = "Undesired traffic flows caused by local filtering of overlapping prefixes">
<t>In this section we describe cases in which an AS locally filters an
overlapping prefix. We show that, depending on the BGP policies applied by surrounding ASes, this decision
can lead to undesired traffic flows.</t>
<section title = "Initial setup">
<t>We start by describing the basic scenario of this case in <xref target = "AS_LOCAL_BASE"/>.</t>
<figure anchor="AS_LOCAL_BASE" title="Initial Setup Local " align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |
|/24 |/22 |
| |/24 |
| | |
| |/22 |/22
| |/24 |/24
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS4 \ / AS2 \ / AS3 \
| |_________| |________| |
| | /22 | |/22 /22| |
'. ,' /24 . ,'/24 /24 . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| |
|10.0.0.0/24 |10.0.0.0/24
|10.0.0.0/22 |10.0.0.0/22
| _....---------...._|
,-'AS1 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
]]></artwork>
</figure>
<t>AS1 is a customer of AS2 and AS3. AS2, AS3, and AS4 are customers
of AS5. AS2 is establishing a peering with AS3 and AS4. AS1 is announcing
a covering prefix, 10.0.0.0/22, and an overlapping prefix 10.0.0.0/24 to
its providers. In the initial setup, AS2 and AS3 announce the two prefixes
to their peers and transit providers. AS4 receives both prefixes from its peer (AS2)
and transit provider (AS5). We will consider
that AS5 chooses the path through AS3 to reach AS1.</t>
</section>
<section anchor = "sec:local_peering2_peering" title = "Undesired traffic flows by local filtering - Case 1">
<t>In the next scenarios, we show that if AS4
filters the incoming overlapping prefix from AS5, there is a situation
in which undesired traffic flows are created on other ASes.
</t>
<figure anchor="AS_LOCAL_BASE_PEERING" title="Undesired traffic flows by local filtering - Case 1" align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |
|/24 |/22 |
| |/24 |
| | |
| |/22 |/22
| | |/24
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS4 \ / AS2 \ / AS3 \
| |_________| |________| |
| | /22 | |/22 /22| |
'. ,' . ,' /24 . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| |
| |10.0.0.0/24
|10.0.0.0/22 |10.0.0.0/22
| _,,..---------...._|
,-'AS1 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
]]></artwork>
</figure>
<t>Let us assume the scenario illustrated in <xref target="AS_LOCAL_BASE_PEERING"/>.
For this case, AS1 only propagates the overlapping prefix
to AS3. AS4 receives the overlapping prefix only from its transit provider, AS5.
</t>
<t>AS4 now is in a situation in which it would be favorable for it
to filter the announcement of prefix 10.0.0.0/24 from AS5. Subsequently,
traffic from AS4 to prefix 10.0.0.0/24 is forwarded towards
AS2. Because AS2 receives the more specific prefix from AS3, traffic from AS4
to prefix 10.0.0.0/24 follows the path AS4-AS2-AS3-AS1.
AS2's BGP policies are implemented to avoid AS2 to exchange traffic between AS4 and AS3.
However, due to the discrepancies of routes from the overlapping and covering prefixes,
undesired traffic flows between AS4 and AS3 still exist on AS2's network.
This situation is economically detrimental for AS2, since it forwards traffic from a peer to a non-customer neighbor.
</t>
</section>
<section anchor="Violation_policy_2" title = "Undesired traffic flows by local filtering - Case 2" >
<figure anchor="AS_LOCAL_BASE_TRANSIT" title="Undesired traffic flows after local filtering - Case 2" align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |
|/24 |/22 |
| |/24 |
| | |
| |/22 |/22
| | |/24
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS4 \ / AS2 \ / AS3 \
| |_________| | | |
| | /22 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| |
| |10.0.0.0/24
|10.0.0.0/22 |10.0.0.0/22
_;,..---------...._|
,-'AS1 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
]]></artwork>
</figure>
<t>Let us assume a second case where AS2 and AS3 are not peering and
AS1 only propagates the overlapping prefix to AS3. AS4 receives the overlapping prefix only from its transit provider, AS5.
This case is illustrated in <xref target="AS_LOCAL_BASE_TRANSIT"/>.
</t>
<t>Similar to the scenario described in <xref target="sec:local_peering2_peering"/>, AS4 is
in a situation in which it would be favorable to filter the announcement
of prefix 10.0.0.0/24 from AS5. Subsequently, traffic from AS4 to prefix 10.0.0.0/24 is
forwarded towards AS2. Due to the existence of a route to prefix 10.0.0.0/24,
AS2 receives the traffic heading to this prefix from AS4, and sends it to AS5.
This situation creates undesired traffic flows that contradict AS2's BGP policy, since the AS
ends up forwarding traffic from a peer to a transit network.
</t>
</section>
</section>
<section anchor= "sec:violation_trigered" title = "Undesired traffic flows caused by remotely triggered filtering of overlapping prefixes">
<t>We present a configuration scenario in
which an AS, using the mechanism described in
<xref target="sec:remote_scoping_technique" />, informs
its provider to selectively propagate an overlapping prefix,
leading to the creation of undesired traffic flows in another AS.</t>
<section title = "Initial setup">
<t>Let AS1 be a customer of AS2 and AS3.
AS1 owns 10.0.0.0/22, which it advertises through AS2 and AS3.
Additionally, AS2 and AS3 are peers.</t>
<t>Both AS2 and AS3 select A1's path as best, and
propagate it to their customers, providers, and peers.
Some remote ASes will route traffic destined to 10.0.0.1 through
AS2 while others will route traffic through AS3.
</t>
<figure anchor="AS_Base" title="Example scenario" align="center"><artwork><![CDATA[
\ / \ /
/22 \ / /22 /22 \ / /22
,-----. ,-----.
,' `. ,' `.
/ AS2 \ /22 / AS3 \
( )-------------( )
\ / /22 \ /
`. ,' `. ,'
'-----; / '-----'
\ /
\ /
10.0.0.0/22\ /10.0.0.0/22
\ /
\ ,-----.'
,' `.
/ AS1 \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
</section>
<section title = "Injection of an overlapping prefix">
<t>Let AS1 advertise 10.0.0.0/24 over AS3 only. AS3 would propagate
this prefix to its customers, providers, and peers,
including AS2.</t>
<t>From AS2's point of view, the path towards 10.0.0.0/24 is a "peer path" and AS2 will
only advertise it to its customers. ASes in the customer branch of AS2 will receive a
path to the /24 that contains AS3 and AS2. Some multi-homed customers of AS2
may also receive a path through AS3, but not through AS2, from
other peering or provider links. Any remote AS that is not lying in the customer branch of AS2,
will receive a path for 10.0.0.0/24 through AS3 and not through
AS2.</t>
<figure anchor="AS_Spec" title="Injection of overlapping prefix" align="center"><artwork><![CDATA[
\ / /22\ / /22
/22 \ / /22 /24 \ / /24
,-----. ,-----.
,' `. /22 ,' `.
/ AS2 \ /24 / AS3 \
( /22:AS1 )-------------( /22:AS1 )
\ /24:AS3 / /22 \ /24:AS1 /
/22 /`. ,' `. ,'
/24/ '-----; / '-----'
/ \ /
,---./ \ /
/ \ 10.0.0.0/22\ /10.0.0.0/22
| AS4 ) \ / 10.0.0.0/24
\ / \ ,-----.'
`---' ,' `.
/ AS1 \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
<t>AS2 only receives traffic destined to 10.0.0.0/24
from its customers, which it forwards to its peer AS3. Routing is
consistent with usual Internet Routing Policies in this case. AS3
could receive traffic destined to 10.0.0.0/24 from its customers,
providers, and peers, which it directly forwards to its customer
AS1.
</t>
</section>
<section title = "Creation of undesired traffic flows by limiting the scope of the overlapping prefix">
<t>Now, let us assume that 10.0.0.0/24, which is propagated by
AS1 to AS3, is tagged to have AS3 only propagate that
path to AS2, using the techniques described in <xref
target="sec:remote_scoping_technique"/>.</t>
<figure anchor="AS_Scoped_Spec" title="More Specific Injection" align="center"><artwork><![CDATA[
,-------.
,' `.
/ AS5 \
( /22:AS2 )
\ /
`. ,'
'-------' \ / \ /
/22 \ //22 /22 \ //22
,-----. ,-----.
,' `. /22 ,' `.
/ AS2 \ /24 / AS3 \
( /22:AS1 )-------------( /22:AS1 )
\ /24:AS3 / /22 \ /24:AS1 /
/22 /`. ,' `. ,'
/24/ '-----; / '-----'
/ \ /
,---./ \ /
/ \ 10.0.0.0/22\ /10.0.0.0/22
( AS4 ) \ / 10.0.0.0/24
\ / \ ,-----.'
`---' ,' `.
/ AS1 \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
<t>From AS2's point of view, such a path is a "peer path" and will only be advertised by
AS2 to its customers.</t>
<t>ASes that are not customers of AS2 will
not receive a path for 10.0.0.0/24. These ASes will forward packets destined to 10.0.0.0/24
according to their routing state for 10.0.0.0/22. Let us assume that AS5 is such an AS, and that its best path
towards 10.0.0.0/22 is through AS2. Then, packets sent
towards 10.0.0.1 by AS5 will eventually reach AS2. However, in
the data-plane of the nodes of AS2, the longest prefix match for
10.0.0.1 is 10.0.0.0/24, which is reached through AS3, a peer of
AS2. Since AS5 is not in the customer branch of AS2, we are in a situation in which traffic flows
between non-customer AS take place in AS2.</t>
<!--Since AS5 is not in the customer branch of AS2,
we are in a situation where AS2 is forwarding non customer
originated traffic along peering links, which conflicts with its policies.</t>-->
<!--<t>If the path towards 10.0.0.0/24 is propagated by B to its
customers, the traffic originated by ASes in the customer branch
of AS A will not follow policy-violating data-plane paths as the
forwarding of traffic towards these destinations will always be
based on FIB entries for 10.0.0.0/24. However, policy-violation
can still take place for the traffic originated from all ASes that
are neither in the customer branch of A nor in the customer branch
of B.</t>-->
<!--and which select a path through AS A to reach 10.0.0.0/22</t>-->
</section>
</section>
</section>
</section>
<!--<section title = "Techniques to detect dataplane-based policy violations" anchor = "sec.detect">-->
<section title = "Techniques to detect undesired traffic flows caused by filtering of overlapping prefixes" anchor = "sec.detect">
<t>
We differentiate the techniques available for detecting undesired traffic flows caused by the described scenarios from the
cases in which the interested AS is the victim or contributor of such operations.
</t>
<section title = "Being the 'victim'">
<!--Netflow can be used to detect that someone is violating your policy-->
<t>To detect if undesired traffic flows are taking place in its network, an ISP can
monitor its traffic data and validate if any flow entering the ISP
network through a non-customer link is forwarded to a
non-customer next-hop.</t>
<!--(Another option?) is to analyze the RIB and check whether
a overlapping prefix is being a received from a non-customer AS, while the
covering one is received by one.
One could use looking glasses to check if neighbor peers or providers are propagating
the overlapping prefix and target triggers.-->
<!-- This is not included: one could say that this can find
possible bad situations, but not discard them-->
<t>As mentioned in <xref target='sec.unexpectedforwardingdefinition' />, undesired
traffic flows might appear due to different situations. To discover if the problem
arose after the filtering of prefixes by neighboring ASes,
an operator can analyze available BGP data.
For instance, an ISP can seek for overlapping prefixes for which the
next-hop is through a provider (or peer), while the next-hop for their
covering prefix(es) is through a client. Direct communication or
looking glasses can be used to check whether non-customer neighboring
ASes are propagating a path towards the covering prefix to their
own customers, peers, or providers. This should trigger a warning,
as this would mean that ASes in the surrounding area of
the current AS are forwarding packets based on the
routing entry for the less specific prefix only.</t>
</section><!-- Being the victim of the policy violation-->
<section title = "Being a contributor to the existence of undesired traffic flows in other networks">
<t>It can be considered problematic to be causing undesired traffic flows on other ASes.
This situation may appear as an abuse to the network resources of other ISPs.</t>
<t>There may be justifiable reasons for one ISP to perform filtering,
either to enforce established policies or to provide prefix advertisement scoping features to its
customers. These can vary from
trouble-shooting purposes to business relationships
implementations. Restricting such features for the sake of
avoiding the creation of undesired traffic flows is not a practical option.</t>
<t>Traffic data does not help an ISP detect that it is acting as a contributor of the creation of the undesired traffic flow.
It is thus advisable to obtain as much information as possible
about the Internet environment of the AS and assess the risks of filtering overlapping prefixes
before implementing them.</t>
<t>Monitoring the manipulation of the communities that implement
the scoping of prefixes is recommended to the
ISPs that provide these features. The monitored behavior should
then be faced against their terms of use.</t>
</section><!--Being a contributor to the policy violation-->
</section>
<section title = "Techniques to counter undesired traffic flows due to the filtering of overlapping prefixes" anchor = "sec.tecniques_to_counter">
<t>Network Operators can adopt different approaches with respect to
undesired traffic flows. We classify these actions according to whether
they are anticipant or reactive.</t>
<!--and provide examples for each one of them-->
<t>Reactive approaches are those in which the operator tries to
detect the situations and solve undesired traffic flows, manually,
on a case-by-case basis.</t>
<t>Anticipant or preventive approaches are those in which the routing system
will not let the undesired traffic flows actually take place when the
configuration scenario is set up.</t>
<t>We will describe these two kinds of approaches in the following part of this Section. We will use
the scenario depicted in <xref target='AS_MEAURES_EXAMPLE' />
to provide examples for the different techniques.
</t>
<figure anchor="AS_MEAURES_EXAMPLE" title="Anticipant counter-measures - Base example" align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |
|/24 |/22 |
| |/24 |
| | |
| |/22 |/22
| | |/24
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS4 \ / AS2 \ / AS3 \
| |_________| | | |
| | /22 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| |
| |10.0.0.0/24
|10.0.0.0/22 |10.0.0.0/22
_;,..---------...._|
,-'AS1 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
]]></artwork>
</figure>
<section title = "Reactive counter-measures">
<t>An operator who detects that its policies are threatened by undesired traffic flows
can contact the ASes that are likely to have performed the
propagation tweaks, inform them of the situation and persuade them to change their behavior. </t>
<t>For some cases, if the external ASes maintain their behavior,
an operator can account the amount of traffic that has been
subject to the undesired flows and charge the peer for that traffic.
That is, the operator can claim
that it has been a provider of that peer for the traffic
that transited between the two ASes.</t>
<t>An operator can decide to filter-out the concerned overlapping
prefix at the peering session over which it was
received. In the example of <xref target="AS_MEAURES_EXAMPLE"/>, AS2
would filter out the incoming prefix 10.0.0.0/24 from the eBGP
session with AS5. As a result, the traffic
destined to that /24 would be forwarded by AS2 along its link
with AS1, despite the actions performed by AS1 to have
this traffic coming in through its link with AS3.</t>
</section>
<section title="Anticipant counter-measures">
<section title = "Access lists">
<t>An operator can configure its routers to install dynamically an access-list made of the prefixes towards
which the forwarding of traffic from that interface would lead
to undesired traffic flows. Note that this technique actually lets
packets destined to a valid prefix be dropped while they are
sent from a neighboring AS that cannot know about policy
conflicts and hence had no means to avoid the creation of undesired traffic flows.
</t>
<!--Lets think about this example in the terms of local policy, I do not knwo if it will so easily work-->
<t> In the example of <xref target="AS_MEAURES_EXAMPLE"/>, AS2
would install an access-list denying packets matching
10.0.0.0/24 associated with the interface connecting to AS4. As
a result, traffic destined to that prefix would be dropped,
despite the existence of a valid route towards
10.0.0.0/22.
</t>
</section>
<section title = "Automatic filtering">
<t>As described in <xref target='sec.uses' />, filtering of overlapping prefixes can in some scenarios lead to undesired traffic flows.
Nevertheless, depending on the autonomous system implementing such practice, this operation can
prevent these cases. This can be illustrated using the example described in <xref target='AS_MEAURES_EXAMPLE' />:
if AS2 or AS3 filter prefix 10.0.0.0/24, there would be no
undesired traffic flow in AS2.</t>
</section>
<section title = "Neighbor-specific forwarding">
<t>An operator can technically ensure that traffic destined
to a given 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 point. </t>
<t>As an example, let us analyze the
scenario of <xref target="AS_MEAURES_EXAMPLE"/> from the point of view of
AS2. The edge router connecting to the AS4 forward packets destined to prefix 10.0.0.0/24 towards AS5.
Likewise, it will forward packets destined to prefix
10.0.0.0/22 towards AS1. The router, however,
only propagates the path of the covering prefix (10.0.0.0/22) to AS4. An operator
could implement the necessary techniques to force the edge router to
forward packets coming from AS4 based only on the paths propagated to AS4. Thus,
the edge router would forward packets destined to
10.0.0.0/24 towards AS1 in which case no undesired traffic flow would occur. This functionality
could be implemented in different ways. <xref target='on_BGP_RS_VPNs' /> describes an approach to implement this Behavior.</t>
</section>
</section>
</section>
<section title = "Conclusions">
<t>In this document, we described threats to policies of autonomous systems caused by
the filtering of overlapping prefixes by external networks. We provide examples of scenarios in which undesired traffic
flows are caused by
these practices and introduce some techniques for their detection and
prevention. We observe that there are reasonable situations in which
ASes could filter overlapping prefixes, however, we encourage that network operators implement
this type of filters only after considering the cases described in this document.
</t>
</section>
</middle>
<back>
<references>
<reference anchor='on_BGP_communities'>
<front>
<title>On BGP Communities</title>
<author initials='B.' surname='Donnet'
fullname='Benoit Donnet'>
<organization abbrev='UCLB'>
Universite catholique de Louvain, Belgium
</organization>
</author>
<author initials='O.' surname='Bonaventure'
fullname=' Olivier Bonaventure'>
<organization abbrev='UCLB'>
Universite catholique de Louvain, Belgium
</organization>
</author>
<date month='April' year='2008' />
</front>
<seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 38, no. 2, pp. 55-59' />
<!--<seriesInfo name='STD' value='1' />-->
<!--<format type='TXT' octets='94506'
target='ftp://ftp.isi.edu/in-notes/rfc2200.txt' />-->
</reference>
<reference anchor='on_BGP_RS_VPNs'>
<front>
<title>Customized BGP Route Selection Using BGP/MPLS VPNs</title>
<author initials='L.' surname='Vanbever'
fullname='Laurent Vanbever'>
<organization abbrev='UCLB'>
Universite catholique de Louvain, Belgium
</organization>
</author>
<author initials='P.' surname='Francois'
fullname='Pierre Francois'>
<organization abbrev='UCLB'>
Universite catholique de Louvain, Belgium
</organization>
</author>
<author initials='O.' surname='Bonaventure'
fullname=' Olivier Bonaventure'>
<organization abbrev='UCLB'>
Universite catholique de Louvain, Belgium
</organization>
</author>
<author initials='J.' surname='Rexford'
fullname='Jennifer Rexford'>
<organization abbrev='PRINCETON'>
Princeton, USA
</organization>
</author>
<date month='October' year='2009' />
</front>
<seriesInfo name='Cisco Systems, Routing Symposium' value='http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf' />
<!--<seriesInfo name='STD' value='1' />-->
<!--<format type='TXT' octets='94506'
target='ftp://ftp.isi.edu/in-notes/rfc2200.txt' />-->
</reference>
<reference anchor="INIT7-RIPE63" target="http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf">
<front>
<title>INIT7-RIPE63</title>
<author/>
<date/>
</front>
</reference>
<!--http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:27 |