One document matched: draft-cardona-filtering-threats-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr='trust200902' docName='draft-cardona-filtering-threats-00' category="info">
<front>
<title abbrev="Making BGP filtering an habit">Making BGP filtering an habit: Impact on policies</title>
<author surname="Camilo Cardona" name ="Cardona" fullname="Juan Camilo Cardona">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avenida del Mar Mediterraneo</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" name ="Francois" fullname="Pierre Francois">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avenida del Mar Mediterraneo</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="September" year="2012" />
<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 potential threats to the
Internet routing policies of an autonomous system
due to filtering of more specific BGP prefixes by its 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. On the other hand, it can be beneficial
for some Autonomous Systems (ASes) to filter
overlapping prefixes (such operation needs to be translated into various
requirements in order to be automatically 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, in the data plane, the
longest prefix match forwarding rule "precedes" the application of such
policies. The existence of a prefix p' that is more specific than a prefix p
in the Routing Information Base (RIB) will indeed 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 both covering and overlapping prefixes can lead to
a violation of 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 potential threats, and discusses
solutions to the problem. The objective of this draft is to enable the use of prefix filtering
while 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"/>
describes some cases in which it is favorable for an AS to filter overlapping prefixes.
In <xref target = "sec.uses"/>, we provide some scenarios in which the filtering of overlapping prefixes
lead to policy violations of other ASes. <xref target = "sec.detect"/> and <xref target = "sec.tecniques_to_counter"/>
introduce some techniques that ASes can use for, respectively, detect and react to policy violations.</t>
</section>
<section title ="Filtering overlapping prefixes" anchor="sec:scoping_technique">
<t>There are different scenarios where filtering an overlapping prefix is
relevant to the operations of an AS. In this section, we illustrate examples
of these scenarios. We differentiate cases in which the filtering is
performed locally from those where the filtering is triggered
remotely, by using BGP communities. These scenarios will be used as a base
in <xref target = "sec.uses"/> for describing side effects bound with such
practices, notably policy violations 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 large autonomous systems spanning a
large geographical area and peering in 3 different physical locations.
Let AS1 announce prefix 10.0.0.0/22 through the sessions established between
the two ASes over all peering links. 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 one specific peering point than to others (right peering link).
With the purpose of receiving the traffic from AS2 to prefix 10.0.0.0/24 on the
right peering link, AS1 could announce the overlapping
prefix on this specific peering point.
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 this scenario, it becomes relevant for AS2 to enforce such practice by
detecting the described situations and automatically issue the appropriate filtering. In this case,
by implementing these automatic procedures, AS2 would detect and filter prefix 10.0.0.0/24.</t>
<figure anchor="Basic_Scen1" title="Basic scenario local filtering 1" 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>There are other cases in which there could exist a need for local filtering.
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 local filtering 2" 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 AS propagate
the prefix to AS4. Additionally, AS1 advertises prefix 10.0.0.0/24
to AS3, which subsequently propagates the prefix to AS4.
10.0.0.0/22 is a covering prefix for 10.0.0.0/24.</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
routes. Operators have reported applying these filters in a manual fashion
<eref target='http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf'>INIT7-RIPE63</eref>.
The relevance of such practice led to investigate
automated filtering procedures (<eref target='http://tools.ietf.org/html/draft-white-grow-overlapping-routes-00'>DRAFT-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, so as to tweak the propagation behavior of the
ASes that handle such propagated paths <xref target='on_BGP_communities' />.</t>
<t>Some ISPs allow their direct and indirect customers to use such
communities in order 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 the later sections that by producing the same effect as filtering,
they can also lead to policy violations at other, distant, ASes. </t>
</section>
</section>
<section title = "Uses of more specific prefix filtering that violate policies" anchor = "sec.uses">
<t>We describe in this section three configuration scenarios which lead
to the violation of the policies of an AS. Note
that these examples do not capture all the cases where such policy
violation can take place. More examples will be provided in the
future revisions of this document.</t>
<section title = "Violation caused by Local filtering">
<t>In this section we describe cases in which an AS locally filters an
overlapping prefix. We show how, depending on the situations
of BGP policies, this decision leads to the violation
of the policies of neighboring ASes.
</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 `''''''''''''''' |/22
|/24 |/22 |/24
| |/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 free 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 will announce the two prefixes
to their peers and transit providers. AS4 receives both prefixes from its peer (AS2)
and transit provider (AS5).</t>
</section>
<section anchor = "sec:local_peering2_peering" title = "Violation of Policy - 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 the policies of other ASes are violated.
</t>
<figure anchor="AS_LOCAL_BASE_PEERING" title="Initial Setup Local " align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |/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 traffic provider, AS5.
</t>
<t>The described example places AS4 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 originating from AS4 to prefix 10.0.0.0/24 is forwarded to
AS2. As AS2 receives the more specific prefix from AS3, traffic originating from AS4
and heading to prefix 10.0.0.0/24 follows the path AS4-AS2-AS3-AS1. This violates the policy of
AS2, since it forwards traffic from a peer to a non-customer neighbor.
</t>
</section>
<section anchor="Violation_policy_2" title = "Violation of Policy - Case 2" >
<figure anchor="AS_LOCAL_BASE_TRANSIT" title="Initial Setup Local " align="center"><artwork><![CDATA[
____,,................______
_,.---'''' `''---..._
,-'' AS5 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
|/22 `''''''''''''''' |/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 traffic 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 originating from AS4 to prefix 10.0.0.0/24 is
forwarded to AS2. Traffic originating in AS4 and heading for prefix 10.0.0.0/24 would follow
the path AS4-AS2-AS5-AS3-AS1. This path violates the policy of
AS2, as this AS is forwarding traffic from a peer to a transit network.
</t>
</section>
</section>
<section anchor= "sec:violation_trigered" title = "Violation caused by remotely triggered filtering">
<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 announce a covering prefix,
leading to the violation of a policy of another AS.</t>
<section title = "Initial setup">
<t>Let AS_cust be a customer AS of AS A and AS B.
It owns 10.0.0.0/22, which it advertises through AS A and AS B.
Additionally, AS A and AS B are peers.</t>
<t>Both AS A and AS B select their customer path as best, and
propagate that path to their customers, providers, and peers.</t>
<t>Some remote ASes will route traffic destined to 10.0.0.0 through
(... A Cust 10.0.0.0/24) while some others will route traffic along
(... B Cust 10.0.0.0/24).
</t>
<figure anchor="AS_Base" title="Example scenario" align="center"><artwork><![CDATA[
\ / \ /
/22 \ //22 /22 \ //22
,-----. ,-----.
,' `. ,' `.
/ A \ /22 / B \
( )-------------( )
\ / /22 \ /
`. ,' `. ,'
'-----; / '-----'
\ /
\ /
10.0.0.0/22\ /10.0.0.0/22
\ /
\ ,-----.'
,' `.
/ Cust \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
</section>
<section title = "Injection of a more specific">
<t>Let AS_cust advertise 10.0.0.0/24 over AS B only. AS B propagates
this prefix to its customers, provider and peers,
including AS A.</t>
<t>From AS A's point of view, such a path is a "peer path", so
that this path will only be advertised to its customers.</t>
<t>All ASes that are not in the customer branch of AS A will
receive a path to the /24 that contains AS B, and not AS A, as AS
A has not propagated the prefix to other ASes than its customers. </t>
<t>The ASes that are in the customer branch of AS A will receive a
path to the /24 that contains AS B and AS A, as AS A has propagated
that path to its customers. Some multi-homed customers of ISP A
may also receive a path through ISP B, but not through ISP A, from
other peering or provider links.</t>
<figure anchor="AS_Spec" title="More Specific Injection" align="center"><artwork><![CDATA[
\ / /22\ //22
/22 \ //22 /24 \ / /24
,-----. ,-----.
,' `. /22 ,' `.
/ A \ /24 / B \
( /22:Cust )-------------( /22:Cust )
\ /24:B / /22 \ /24:Cust /
/22 /`. ,' `. ,'
/24/ '-----; / '-----'
/ \ /
,---./ \ /
/ \ 10.0.0.0/22\ /10.0.0.0/22
|Cust_2) \ / 10.0.0.0/24
\ / \ ,-----.'
`---' ,' `.
/ Cust \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
<t>Any remote AS that is not lying in the customer branch of A,
will receive a path for 10.0.0.0/24 through AS B and not through
AS A.</t>
<t>Routing is consistent with usual Internet Routing Policies
here, as AS A may only receive traffic destined to 10.0.0.0/24
from its customers, which it forwards to its peer AS B. AS B may
receive traffic destined to 10.0.0.0/24 from its customers,
providers, and peers, which it directly forwards to its customer
AS Cust.
</t>
</section>
<section title = "Limiting the scope of the more specific">
<t>Now, let us assume that 10.0.0.0/24, which is propagated by
AS_Cust to AS B, is tagged so as to have AS B only propagate that
path to AS A, 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[
,-------.
,' `.
/ AS_Src \
( /22:A )
\ /
`. ,'
'-------' \ / \ /
/22 \ //22 /22 \ //22
,-----. ,-----.
,' `. /22 ,' `.
/ A \ /24 / B \
( /22:Cust )-------------( /22:Cust )
\ /24:B / /22 \ /24:Cust /
/22 /`. ,' `. ,'
/24/ '-----; / '-----'
/ \ /
,---./ \ /
/ \ 10.0.0.0/22\ /10.0.0.0/22
(Cust_2 ) \ / 10.0.0.0/24
\ / \ ,-----.'
`---' ,' `.
/ Cust \
( )
\ /
`. ,'
'-----'
]]></artwork>
</figure>
<t>From AS A's point of view, such a path is a "peer path", so
that this path will only be advertised by
AS A to its customers.</t>
<t>All the ASes that are not in the customer branch of AS A nor in
the customer branch of AS B will NOT receive a path to
10.0.0.0/24.</t>
<t>All these ASes will forward packets destined to 10.0.0.0/24
according to their routing state for 10.0.0.0/22.</t>
<t>Let us assume that AS_Src is such an AS, and that its best path
towards 10.0.0.0/22 is through AS A. In that case, packets sent
towards 10.0.0.1 by AS_Src will eventually reach AS A. However, in
the dataplane of the nodes of AS A, the longest prefix match for
10.0.0.0 is 10.0.0.0/24, which is reached through AS B, a peer of
AS A. </t>
<t>As AS_Src is by definition not in the customer branch of AS A,
we are in a situation such that AS A is forwarding non customer
originated traffic along peering links, which violates 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 title = "Techniques to detect dataplane-based policy violations" anchor = "sec.detect">
<t>
We differentiate the techniques available for detecting policy violations from the
cases in which the interested AS is the victim or contributor of such operations.
</t>
<section title = "Being the victim of the policy violation">
<!--Netflow can be used to detect that someone is violating your policy-->
<t>To detect that its policies have been violated, one ISP can
monitor its NetFlow data so as to see if flows entering the ISP
network through a non-customer link is being forwarded to a
non-customer nexthop.</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>Detecting such a violation can be done by looking at BGP data
to see whether there exists in the RIB a prefix P/p' more
specific than P/p such that the nexthop for P/p' is through a
peer (or a provider) while P/p is routed through a
customer. For each such couple of prefixes, direct communication or
looking glasses can be used in order to check whether non-customer neighboring ASes are propagating a path towards
P/p (and not towards P/p') 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 policy violation">
<t>It can be considered as problematic to be a contributor of
the policy violation as it appears as an abuse of other's network resources.</t>
<t>There may be justifiable reasons for one ISP to perform filtering,
either to enforce establishing 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 contributing to potential policy violations in a peer's network
is a bad option.</t>
<t>Netflow data does not help an ISP to
detect that it is acting as a contributor of the policy
violation. It is thus advisable to obtain as much information as possible
of the Internet environment of the AS and assessing the risks of filtering of overlapping prefixes
before implementing them.</t>
<t>Monitoring the manipulation of the communities that implement
the scoping of prefixes in one's network is recommended to the
ISPs which 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 policy violations" anchor = "sec.tecniques_to_counter">
<t>Network Operators can adopt different approaches with respect to
policy violation. 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 solves the policy violation through
other means than using the routing system.</t>
<t>Anticipant or preventive approaches are those in which the routing system
will not let the policy violation actually take place when the
configuration scenario is set up.</t>
<section title = "Reactive counter-measures">
<t>An operator who detects that its policies have been violated
can contact the ASes that are likely to have performed the
propagation tweaks so as to have them change their behavior. </t>
<t>An operator can account the amount of traffic that has been
subject to policy violation, and charge the peer that received
the policy-violating traffic. That is, the operator can claim
that it has been a provider of that peer for that part of the
traffic that transited between the two ASes.</t>
<t>An operator can decide to filter-out the concerned more
specific prefix at the peering session over which it was
received. In the example of <xref target="AS_Scoped_Spec"/>, AS
A would filter out 10.0.0.0/24 in its eBGP in-filter associated
with the eBGP session with AS B. As a result, the traffic
destined to that /24 would be forwarded by AS A along its link
with AS_Cust, despite the actions performed by AS_Cust to have
this traffic coming in through it link with AS B.</t>
</section>
<section title="Anticipant counter-measures">
<section title = "Neighbor-specific forwarding">
<t>An operator can technically ensure that the traffic destined
to a given prefix will be forwarded from an entry point of its
AS, only on the basis of the set of paths that have been
advertised over that entry point.</t>
</section>
<section title = "Access lists">
<t>An operator can configure its routers so as to have them
dynamically install an access-list made of the prefixes towards
which the forwarding of traffic from that interface would lead
to a policy violation. 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 the policy
violation and hence had no means to avoid the policy violation.
</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_Scoped_Spec"/>, AS A
would install an access-list denying packets matching
10.0.0.0/24 associated with the interface connecting AS_Src. As
a result, the traffic destined to that /24 would be dropped,
despite the existence of a non policy-violating 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 policy violations.
Nevertheless, depending on the autonomous system implementing such practice, this operation can in fact
prevent these cases. This can be illustrated using the example described in <xref target='Violation_policy_2' />:
In <xref target='AS_LOCAL_BASE_TRANSIT' />, if AS2 or AS3 filter prefix 10.0.0.0/24, there would be no
policy violation for AS2.</t>
</section>
</section>
</section>
<section title = "Conclusions">
<t>In this document we described potential threats to policy violation of autonomous systems caused by
the filtering of overlapping prefixes by external networks. We provide examples of scenarios of policy violations caused by
these practices and introduce some techniques for their detection and
counter. 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 such threats.
</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>
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:26:36 |