[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01
Network Working Group Pierre Francois
Internet-Draft Bruno Quoitin
Intended status: Informational Universite catholique de Louvain
Expires: January 7, 2010 July 6, 2009
Threat to BGP Policies : limited-scope more specific prefix injection
draft-francois-limited-scope-specifics-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 1]
Internet-Draft Limited-scope more specifics : Threats July 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This draft describes potential threats to the respect of Internet
routing policies by the routers of one ISP, that are due to a
restricted propagation of more specific BGP prefixes by its
neighboring domains.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Limiting the scope of prefix advertisement . . . . . . . . . . 3
3. Uses of limited scope more specifics that violate policies . . 4
3.1. Initial setup . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Injection of a more specific . . . . . . . . . . . . . . . 5
3.3. Limiting the scope of the more specific . . . . . . . . . . 6
3.4. Techniques to detect dataplane-based policy violations . . 8
3.5. Techniques to counter such violations . . . . . . . . . . . 8
3.5.1. Reactions . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. Anticipant counter-measures . . . . . . . . . . . . . . 9
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 2]
Internet-Draft Limited-scope more specifics : Threats July 2009
1. Introduction
BGP policy configuration within an ISP network drives the control
plane decisions on the nexthop to be used to reach a given prefix.
However, in the data plane, the longest prefix match forwarding rule
"precedes" the application of such policies. In other words, the
existence of a prefix p' that is more specific than a prefix p in the
Routing Information Base will let packets whose destination matches
p' be forwarded according to the best nexthop obtained for p',
disregarding the policies applied in the control plane for selection
of the best nexthop for p.
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.
This document presents such potential threats, and discusses
solutions to the problem. It also describes the opportunities bound
with that aspect of BGP routing.
2. Limiting the scope of prefix advertisement
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.
Some ISPs allow their direct and indirect customers to use such
communities so as to let the receiving AS not export the path to some
selected neighboring AS. Sometimes, such communities can be
combined, so as to have the prefix advertised only to a given peer of
the AS providing the "feature".
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.
Aggregation practices, such as "XXX reserves the right to aggregate
any announcement for a network smaller than /length when advertising
to external peers such as YYY", may implicetly lead to a limitation
of the scope of the advertisement of a path towards a given prefix.
Any such feature available to the customers of an AS, AS B, which
allow the routing in AS B to result in the propagation of a given
prefix to a neighboring AS, AS A, only, lets AS A face a potential
violation of its policies in the data-plane.
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 3]
Internet-Draft Limited-scope more specifics : Threats July 2009
More generally, any such features available to the customers of AS B,
which allow the routing in AS B to result in the propagation of a
given prefix to a neighboring AS, AS A, but not to some ASes outside
the customer branch of A and B, lets AS A face a potential violation
of its policies in the data-plane.
3. Uses of limited scope more specifics that violate policies
In this section, we present a configuration scenario that leads to a
data-plane violation of the policies of an AS, AS A. We incrementally
build the scenario for the ease of understanding. Note that this
example does not capture all the cases where such policy violation
can take place. More examples will be provided in the future version
of the document.
3.1. Initial setup
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.
Both AS A and AS B select that customer path as best, and propagate
that path to their customers, providers, and peers.
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).
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 4]
Internet-Draft Limited-scope more specifics : Threats July 2009
\ / \ /
/22 \ //22 /22 \ //22
,-----. ,-----.
,' `. ,' `.
/ A \ /22 / B \
( )-------------( )
\ / /22 \ /
`. ,' `. ,'
'-----; / '-----'
\ /
\ /
10.0.0.0/22\ /10.0.0.0/22
\ /
\ ,-----.'
,' `.
/ Cust \
( )
\ /
`. ,'
'-----'
Figure 1: Example scenario
3.2. Injection of a more specific
Let us assume that AS A and AS B are peers.
Let AS_cust advertise 10.0.0.0/24 over AS B only. AS B propagate a
path to 10.0.0.0/24 to its customers, provider and peers, including
AS A.
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.
All the 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
relayed that path to other ASes than its customers.
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.
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 5]
Internet-Draft Limited-scope more specifics : Threats July 2009
\ / /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 \
( )
\ /
`. ,'
'-----'
Figure 2: More Specific Injection
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.
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.
3.3. Limiting the scope of the more specific
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 Section 2.
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 6]
Internet-Draft Limited-scope more specifics : Threats July 2009
,-------.
,' `.
/ 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 \
( )
\ /
`. ,'
'-----'
Figure 3: More Specific Injection
From AS A's point of view, such a path is a "peer path", so that this
path will only be advertised to the customers of AS A by AS A.
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.
All 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 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, that is reached through AS B, a peer of AS
A.
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
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 7]
Internet-Draft Limited-scope more specifics : Threats July 2009
traffic along peering links, which is a violation of its policies.
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, and which
select a path through AS A to reach 10.0.0.0/22
3.4. Techniques to detect dataplane-based policy violations
Detecting such a violation can be done by monitoring NetFlow data in
the ISP so as to see if flows entering the ISP network through a non-
customer link is being forwarded to a non-customer nexthop.
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,
looking glasses around the providers and peers of the current AS
should be consulted to see if these ASes are propagating a path
towards P/p' (and not towards P/p) to their own customer, 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.
3.5. Techniques to counter such violations
Operators can adopt different positions regarding such kind of policy
violations. We classify such positions according to whether they are
anticipant or reactive.
Reactive positions are those such that the operator tries to detect
such situations and solves the policy violation through other means
than using the routing system.
Anticipant positions are those such that the routing system will not
let the policy violation actually take place when the configuration
scenario is set up.
3.5.1. Reactions
An operator who detects that its policies have been violated can
contact the operators that are likely to have performed the
propagation tweaks so as to change the behavior.
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 8]
Internet-Draft Limited-scope more specifics : Threats July 2009
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.
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 Figure 3, 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.
3.5.2. Anticipant counter-measures
3.5.2.1. Neighbor-specific forwarding
An operator can technically ensure that the traffic destined to a
given prefix will be forwarded from an entry point of the AS, only on
the basis of the set of paths that have been advertised over that
entry point.
3.5.2.2. Neighbor-specific filtering
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.
In the example of Figure 3, 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.
4. References
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 9]
Internet-Draft Limited-scope more specifics : Threats July 2009
Authors' Addresses
Pierre Francois
Universite catholique de Louvain
Place Ste Barbe, 2
Louvain-la-Neuve 1348
BE
Email: pierre.francois@uclouvain.be
URI: http://inl.info.ucl.ac.be/pfr
Bruno Quoitin
Universite catholique de Louvain
Place Ste Barbe, 2
Louvain-la-Neuve 1348
BE
Email: bruno.quoitin@uclouvain.be
URI: http://inl.info.ucl.ac.be/bqu
Pierre Francois & Bruno Quoitin Expires January 7, 2010 [Page 10]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/