Internet DRAFT - draft-francois-limited-scope-specifics

draft-francois-limited-scope-specifics






Network Working Group                                    Pierre Francois
Internet-Draft                          Universite catholique de Louvain
Intended status: Informational                             Bruno Quoitin
Expires: April 29, 2010                                            UMons
                                                        October 26, 2009


 Threat to BGP Policies : limited-scope more specific prefix injection
               draft-francois-limited-scope-specifics-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 April 29, 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
   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



Pierre Francois & Bruno Quoitin  Expires April 29, 2010         [Page 1]

Internet-Draft   Limited-scope more specifics : Threats     October 2009


   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
   4.  Techniques to detect dataplane-based policy violations . . . .  8
     4.1.  Being the victim of the policy violation . . . . . . . . .  8
     4.2.  Being a contributor to the policy violation  . . . . . . .  8
   5.  Techniques to counter such violations  . . . . . . . . . . . .  9
     5.1.  Reactions  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Anticipant counter-measures  . . . . . . . . . . . . . . .  9
       5.2.1.  Neighbor-specific forwarding . . . . . . . . . . . . .  9
       5.2.2.  Neighbor-specific filtering  . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






























Pierre Francois & Bruno Quoitin  Expires April 29, 2010         [Page 2]

Internet-Draft   Limited-scope more specifics : Threats     October 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 April 29, 2010         [Page 3]

Internet-Draft   Limited-scope more specifics : Threats     October 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 April 29, 2010         [Page 4]

Internet-Draft   Limited-scope more specifics : Threats     October 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 April 29, 2010         [Page 5]

Internet-Draft   Limited-scope more specifics : Threats     October 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 April 29, 2010         [Page 6]

Internet-Draft   Limited-scope more specifics : Threats     October 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 April 29, 2010         [Page 7]

Internet-Draft   Limited-scope more specifics : Threats     October 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


4.  Techniques to detect dataplane-based policy violations

4.1.  Being the victim of the policy violation

   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.

   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.

4.2.  Being a contributor to the policy violation

   It can be considered as problematic to be a contributor of the policy
   violation as it is problematic to be the victim.

   There may be justifiable reasons for one ISP to provide the prefix
   advertisment scoping features which may lead to the policy violations
   documented in this draft.  These can vary from trouble-shooting
   purposes to business relationships implementations.  Hence
   restricting such features for the sake of avoiding to contribute to
   policy violations in a peer's network is a bad option.

   Netflow data does not help an ISP (ISP B in our example) to detect
   that it is acting as a contributor of the policy violation.

   Monitoring the manipulation of the communities that implement the



Pierre Francois & Bruno Quoitin  Expires April 29, 2010         [Page 8]

Internet-Draft   Limited-scope more specifics : Threats     October 2009


   scoping of prefixes in one's network is recommended to the ISPs which
   provide such features.  Such monitored behavior should then be faced
   against their terms of use.


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.

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 have them change the behavior.

   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.

5.2.  Anticipant counter-measures

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.




Pierre Francois & Bruno Quoitin  Expires April 29, 2010         [Page 9]

Internet-Draft   Limited-scope more specifics : Threats     October 2009


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.


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
   UMons
   Batiment Pentagone
   Avenue du Champ de Mars, 6
   Mons  7000
   BE

   Email: bruno.quoitin@UMons.ac.be














Pierre Francois & Bruno Quoitin  Expires April 29, 2010        [Page 10]