Network Working Group                                     Camilo Cardona
Internet-Draft                                       IMDEA Networks/UC3M
Intended status: Informational                           Pierre Francois
Expires: August 17, 2014 February 5, 2015                                 IMDEA Networks
                                                           Paolo Lucente
                                                           Cisco Systems
                                                       February 13,
                                                          August 4, 2014

            Making BGP filtering a habit: Impact on policies
                  draft-ietf-grow-filtering-threats-02
                  draft-ietf-grow-filtering-threats-03

Abstract

   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 document describes how unexpected traffic flows can emerge in
   across an autonomous system, as the result of other autonomous
   systems due to filtering, or restricting the filtering propagation of overlapping
   BGP prefixes by neighboring domains.
   prefixes.  We provide a review of the techniques to detect the
   occurrence of this issue and defend against it.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 17, 2014. February 5, 2015.

Copyright Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Filtering overlapping prefixes  . . . . .
     1.1.  Terminology . . . . . . . . . .   3
     2.1.  Local filtering . . . . . . . . . . . . . . . . .   3
   2.  Unexpected Traffic Flows  . . . .   3
     2.2.  Remotely triggered filtering . . . . . . . . . . . . . .   6
   3.  Uses of overlapping prefix   4
     2.1.  Local filtering that create unexpected
       traffic flows . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.   4
       2.1.1.  Unexpected traffic Flows flows caused by local filtering of
               overlapping prefixes  . . . . . . . . . . . . . . . .   7
       3.1.1.  Unexpected traffic flows caused by local   5
     2.2.  Remote filtering of
               overlapping prefixes  . . . . . . . . . . . . . . . .   8
       3.1.2. . . . .   6
       2.2.1.  Unexpected traffic flows caused by remotely triggered
               filtering of overlapping prefixes . . . . . . . . . .  12
   4.   7
   3.  Techniques to detect unexpected traffic flows caused by
       filtering of overlapping prefixes . . . . . . . . . . . . . .  15
     4.1.  Being the 'victim'   8
     3.1.  Existence of unexpected traffic flows within an AS  . . . . .  15
     4.2.  Being a contributor   8
     3.2.  Contribution to the existence of unexpected traffic flows
           in other networks another AS . . . . . . . . . . . . .  15
   5. . . . . . . . . .   9
   4.  Techniques to counter unexpected traffic flows due to the
       filtering of overlapping prefixes  . . . . . . .  10
     4.1.  Reactive counter-measures . . . . . . .  16
     5.1.  Reactive . . . . . . . . .  11
     4.2.  Anticipant counter-measures . . . . . . . . . . . . . . .  12
       4.2.1.  Access lists  .  17
     5.2.  Anticipant counter-measures . . . . . . . . . . . . . . .  18
       5.2.1.  Access lists . . . .  12
       4.2.2.  Neighbor-specific forwarding  . . . . . . . . . . . .  13
   5.  Conclusions . . . . .  18
       5.2.2.  Automatic overlapping prefix filtering . . . . . . .  19
       5.2.3.  Neighbor-specific forwarding . . . . . . . . . . . .  19 .  13
   6.  Conclusions  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . .  19
   7.  References . . . . . .  14
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . .  20
     7.1. . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . .   0
     7.2.  URIs . .  14
     9.1.  References  . . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  URIs  .  20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   It is common practice for . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   It is common practice for network operators to propagate overlapping
   prefixes a more
   specific (overlapping) prefix in the BGP routing system, along with
   the prefixes covering prefix 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.

   While BGP makes independent, policy driven decisions for the
   selection of the best path to be used for a given IP prefix.  However, prefix, routers
   must forward packets using the longest-prefix-match rule, which
   "precedes" any BGP policy (RFC1812 [1]).  Indeed, the  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). p'.  When an Autonomous System filters overlapping prefixes and
   forwards packets according to the covering prefix, the discrepancy in
   the routing policies applied to covering and overlapping prefixes can
   create unexpected traffic flows that infringe the policies of other ASes
   ASes, still holding a path towards the overlapping prefix.

   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 possible side effects
   associated with overlapping prefix filtering by making the routing community aware filtering.  This document presents
   examples of the
   cases where the such side effects of filtering might turn and discusses approaches towards
   solutions to be negative for the business of Internet Service Providers (ISPs). problem.

   The rest of the document is organized as follows: Section 2
   illustrates the motivation to filter overlapping prefixes. In Section 3, 2 we
   provide some scenarios in which the filtering of overlapping prefixes lead
   leads to the creation of unexpected traffic flows
   on other ASes. flows.  Section 4 3 and
   Section 5 4 discuss some techniques that ASes can use for,
   respectively, detect and react to unexpected traffic flows.

2.  Filtering overlapping prefixes

   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
   conclude in Section 5.

1.1.  Terminology

   Overlapping prefix: A prefix in which the
   filtering routing table with an address
   range that is performed locally from those where covered by another prefix present in the filtering is
   triggered remotely.  These scenarios will be used as a base routing table.

   Covering prefix: A prefix in
   Section 3 for describing side effects bound the routing table with such practices.

2.1.  Local filtering

   Let us first analyze an address range
   partially covered by other prefixes.

   We re-use the scenario depicted in Figure 1.  AS1 and AS2
   are two autonomous systems spanning a large geographical area definitions of customer-transit peering and settlement-
   free peering in 3 different physical locations.  Let AS1 announce of RFC4384 [2].

   Selective advertisement: The behavior of only advertising a self
   originated BGP path for a 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.

   To receive the traffic destined to prefix 10.0.0.0/24 on strict subset of the link
   closer to this subnet, AS1 could announce eBGP
   sessions of the overlapping prefix AS.

   Selective propagation: The behavior of only propagating a BGP path
   for a prefix over this specific session.  At the time a strict subset of the establishment eBGP sessions of the
   peering, it can be defined by both ASes that hot potato routing would
   happen in both directions an AS.

   Local filtering: The behavior of traffic.  In other words, it was agreed explicitly ignoring a BGP path
   received over an eBGP session.

   Remote filtering: The behavior of triggering selective propagation of
   a BGP path at a distant AS.  Note that each AS will deliver this is typically achieved by
   tagging a self-originated path with BGP communities defined by the
   distant AS.

   Unexpected traffic to flow: Traffic flowing between two neighboring ASes
   of an AS, although the other transit policy of that AS on the nearest
   peering link.  In this scenario, it becomes relevant to AS2 is to
   enforce such practice by detecting the described situations and
   automatically issuing the appropriate filtering.  In this case, by
   implementing not provide
   connectivity between these automatic procedures, AS2 would legitimately
   detect and filter prefix 10.0.0.0/24.

                ___....-----------....___
           ,.--' 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 |
          `._                       |........._.'
             `--..__                   _,,.--'
                    `'''-----------''''

                Figure 1: Basic scenario two neighbors.  A traffic flow across an
   AS, between two of local filtering

   Local filtering could be required in other cases.  For example, its transit providers, or between a
   dual homed AS receiving an overlapping prefix from only transit
   provider and one of its
   providers.  Figure 2 depicts a simple example settlement-free peers, are classical examples
   of this case.

                       _..._
                    ,'     `.
                   /   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    \
                   |         |
                    \       /
                     `-...-'

                Figure 2: Basic scenario of local filtering

   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.

   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.

   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 [3].  The relevance of such practice led to investigate
   automated filtering procedures in I-D.WHITE [2].

2.2.  Remotely triggered filtering

   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 [1].

   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.
   Figure 3 illustrates an example of this case.

    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    \
                    |         |
                     \       /
                      `-...-'

                   Figure 3: Remote triggered filtering

   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.

   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 unexpected traffic flows at other, distant, ASes.

3.  Uses of overlapping prefix filtering that create unexpected traffic
    flows

   In this section, we define the concept of unexpected 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.

3.1.  Unexpected traffic Flows

   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 (RFC4384 [3]).  We briefly illustrate this operation in
   Figure 4.  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 AS1.  In the figure, we
   also show a customer of AS2, AS4, which is announcing prefix P4/p4.
   AS2 propagates this prefix to AS1.

       ,-----.             ,-----.             ,-----.
     ,'       `.         ,'       `.         ,'       `.
    / AS1       \       / AS2       \       / AS3       \
   (             )-----(             )-----(             )
    \           / P4/p4 \           /       \     P3/p3 /
     `.       ,'         `.       ,'         `.       ,'
       '-----'             '-----'             '-----'
                              |
                              |
                              |
                           ,-----.
                         ,'       `.
                        / AS4       \
                       (             )
                        \     P4/p4 /
                         `.       ,'
                           '-----'

          Figure 4: Prefix exchange among four autonomous systems

   Although ISPs usually implement the aforementioned policies,
   unexpected traffic flows may still appear.  In Figure 4, unexpected
   traffic flows are created, when, despite AS2's policy, traffic
   arriving from peer AS1 is received and transported to AS3 by AS2.
   These types 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 unexpected traffic flows on ASes.
   We provide examples of these cases in the next sections.

3.1.1.  Unexpected traffic flows caused by local filtering of
        overlapping prefixes

   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 unexpected traffic flows.

3.1.1.1.  Initial setup

   We start by describing the basic scenario of this case in Figure 5.

                          ____,,................______
                _,.---''''                            `''---..._
            ,-''   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                ``-.
                                 /'                          `.
                                 `.                         _,
                                   `-.._               _,,,'
                                        `''---------'''

                       Figure 5: Initial Setup Local

   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 as best path to AS1 the one
   received from AS3.

3.1.1.2.  Unexpected traffic flows by local filtering - Case 1

   In the next scenarios, we show that if AS4 filters the incoming
   overlapping prefix from AS5, there is a situation in which unexpected
   traffic flows are created on other ASes.

                          ____,,................______
                _,.---''''                            `''---..._
            ,-''   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                ``-.
                                 /'                          `.
                                 `.                         _,
                                   `-.._               _,,,'
                                        `''---------'''

      Figure 6:

2.  Unexpected Traffic Flows

   In this section, we describe how overlapping prefix filtering can
   lead to unexpected traffic flows by local in other, remote, ASes.  We
   differentiate cases in which the filtering - Case 1

   Let us assume is performed locally from
   those where the scenario illustrated in Figure 6.  For this case,
   AS1 filtering is triggered remotely.

2.1.  Local filtering

   Local filtering can be motivated by different reasons, such as: (1)
   Traffic engineering, where an AS wants to control their local
   outbound traffic distribution using only propagates the overlapping prefix policy applied to AS3.  AS4 receives the
   overlapping prefix only from its transit provider, AS5.

   AS4 now
   covering prefix. (2) Enforcing contract compliance, where, for
   instance, an AS avoids a settlement-free peer to attract traffic to
   one link by using selective advertisement, when this is in not allowed
   by their peering agreement.

   Figure 1 illustrates a situation scenario in which it would be favorable for it one AS is motivated to
   filter the announcement of prefix 10.0.0.0/24 from AS5.
   Subsequently, traffic from AS4
   perform local filtering due to prefix 10.0.0.0/24 outbound traffic engineering.  The
   figure depicts AS64504, and two of its neighboring ASes, AS64502 and
   AS64505.  AS 64504 has a settlement-free peering with AS64502 and is forwarded
   towards AS2.  Because AS2
   a customer of AS64505.  AS64504 receives from AS64505 prefixes
   2001:DB8::/32 and 2001:DB8::/34, covering and overlapping prefixes,
   respectively.  AS64504 receives only the more specific covering prefix
   2001:DB8::/32 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 AS64502.

                 ,-----.
                /       \
               ( AS64505 )
                \       /
                 `--+--'
    2001:DB8::/32 | |
    2001:DB8::/34 v |
                    |
                 ,--+--.  2001:DB8::/32  ,-----.
                /       \           <-- /       \
               ( AS64504 )-------------( AS64502 )
                \       /               \       /
                 `-----'                 `-----'

                         Figure 1: Local Filtering

   Due to avoid using
   itself economical reasons, AS64504 might prefer to exchange send traffic between AS4 and AS3.  However, due to the
   discrepancies
   AS64502 instead of routes AS64505.  However, even if paths received from the overlapping and covering prefixes,
   unexpected traffic flows between AS4 and AS3
   AS64502 are given a large local preference, routers in AS64504 will
   still exist on AS2's
   network. send traffic to prefix 2001:DB8::/34 via neighbor AS64505.
   This situation may push AS64504 to apply an inbound filter for the
   overlapping prefix, 2001:DB8::/34, on the session with AS64505.
   After the filter is economically detrimental for AS2, since
   it forwards applied, traffic from a peer to a non-customer neighbor.

3.1.1.3. the overlapping prefix will
   be sent to AS64502

2.1.1.  Unexpected traffic flows caused by local filtering - Case 2
                            ____,,................______
                  _,.---''''                            `''---..._
              ,-''   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                ``-.
                                   /'                          `.
                                   `.                         _,
                                     `-.._               _,,,'
                                          `''---------'''

     Figure 7: Unexpected traffic flows after of
        overlapping prefixes

   In this section, we show how the decision of AS64504 to perform local
   filtering - Case creates unexpected traffic flows in AS64502.  Figure 2

   Let us assume a second case
   shows the whole picture of the scenario; where AS2 AS64501 is a customer
   of AS64503 and AS3 are not peering AS64502.  AS64503 is a settlement-free peer with
   AS64502.  AS64503 and AS1
   only propagates AS64502 are customers of AS64505.  The AS
   originating the overlapping prefix to AS3.  AS4 receives two prefixes, AS64501, performs selective
   advertisement with the overlapping prefix and only from its transit provider, AS5.  This case is
   illustrated in Figure 7.

   Similar to the scenario described in Section 3.1.1.2, AS4 is in a
   situation in which announces it would be favorable to filter
   AS64503.

   After AS64504 locally filters the announcement
   of prefix 10.0.0.0/24 from AS5.  Subsequently, overlapping prefix, traffic from AS4
   AS64504 to prefix 10.0.0.0/24 would be 2001:DB8::/34 is forwarded towards AS2.  Due to the
   existence of a route to prefix 10.0.0.0/24, AS2 AS64502.
   Because AS64502 receives the traffic
   heading to this more specific prefix from AS4 and sends it to AS5.  This situation
   creates unexpected traffic flows that contradict AS2's BGP policy,
   since the AS ends up forwarding AS64503,
   traffic from a peer AS64504 to a transit
   network.

3.1.2.  Unexpected traffic flows caused by remotely triggered filtering
        of overlapping prefixes

   We present a configuration scenario in which an AS, using 2001:DB8::/34 follows the
   mechanism described in Section 2.2, informs its provider path
   AS64504-AS64502-AS64503-AS64501.  AS64502's BGP policies are
   implemented to
   selectively propagate an overlapping prefix, leading avoid transporting traffic between AS64504 and
   AS64503.  However, due to the creation discrepancies of routes from the
   overlapping and covering prefixes, unexpected traffic flows in another AS.

3.1.2.1.  Initial setup

   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.

   Both AS2 and AS3 select A1's path as best, and propagate it to their
   customers, providers, between
   AS64504 and peers.  Some remote ASes will route traffic
   destined to 10.0.0.1 through AS2 while others will route traffic
   through AS3.

         \         /                  \         /
      /22 \       / /22            /22 \ AS64503 exist in AS64502's network.

                          ____,,................______
                _,.---''''                            `''---..._
            ,-''   AS64505                                      `-.
            [                                                      / /22
            ,-----.                     ,-----.
             -.._                                             __.-'
              .  `'---....______                ______...---''
            + |/32              `'''''''''''''''         |
            | |/34               + |/32                  |
            v |                  v |/34                  |
              |                    |                   ^ |
              |                  ^ |/32                | |/32
              |                  + |                   + |/34
       _,,---.:_               _,,---.._              _,,---.._
     ,'         `.           ,'         `.          ,'         `.
    / AS2  AS64504    \           /22     <-+ / AS3       \
        (             )-------------(             )  AS64502    \        /  /22  AS64503    \           /
    |             |_________|             |________|             |
    |             |     /32 |             |/32  /32|             |
    '.           ,'          .           ,'     /34 .           ,'
      `.       ,'             `.       ,'
            '-----;                  /  '-----'
                   \                /
                    \              /
          10.0.0.0/22\            /10.0.0.0/22
                      \          /
                       \ ,-----.'  +->  <-+  `.       ,'
        ``---''                 ``---''                ``---''
                                    |                  ^ |
                                  ^ |2001:DB8::/32     | |2001:DB8::/32
                                  | |                  + |2001:DB8::/34
                                  + | _....---------...._|
                                   ,-'AS64501            ``-.
                                 /'                          `.
                      / AS1       \
                     (             )
                      \           /
                                 `.       ,'
                         '-----'                         _,
                                   `-.._               _,,,'
                                        `''---------'''

         Figure 2: Unexpected traffic flows due to local filtering

2.2.  Remote filtering

   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 [1].  Some ISPs allow their customers to
   use such communities to let the receiving AS not export the path to
   some selected neighboring ASes.  By combining communities, the prefix
   could be advertised only to a given peer of the AS providing this
   feature.  Remote filtering can be leveraged by an AS to, for
   instance, limit the scope of prefixes and hence perform a more
   granular inbound traffic engineering.

   Figure 8: Example 3 illustrates a scenario

3.1.2.2.  Injection of in which an AS uses BGP communities
   to command its provider to selectively propagate an overlapping
   prefix.  Let AS64501 be a customer of AS64502 and AS64503.  AS64501
   originates prefix 2001:DB8::/32, which it advertises through AS64502
   and AS64503.  AS64502 and AS64503 are settlement-free peers.  Let AS1 advertise 10.0.0.0/24
   AS64501 do selective advertisement and only propagate 2001:DB8::/34
   over AS3 only.  AS3 AS64503.  AS64503 would normally propagate this prefix to its
   customers, providers, and peers, including AS2.

   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 AS64502.

   Let us consider that AS64501 decides to limit the /24 that contains
   AS3 and AS2.  Some multi-homed customers scope 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.

                \         /               /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       \
                            (             )
                             \           /
                              `.       ,'
                                '-----'

                 Figure 9: Injection of
   overlapping prefix

   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 prefix.  AS64501 can make this case.  AS3 could receive traffic
   destined to 10.0.0.0/24 from its customers, providers, and peers,
   which it directly forwards to decision based on its customer AS1.

3.1.2.3.  Creation of unexpected
   traffic flows by limiting the scope of engineering strategy.  To achieve this, AS64501 can tag the
   overlapping prefix

   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 Section 2.2.

          ,-------.
        ,'         `.
       /  AS5        \
      (   /22:AS2     ) with a set of communities that leads AS64503 to
   only propagate the path to AS64502.

      ^     \         /
        `.         ,'
          '-------'     ^       ^    \         /    ^
      |  /32 \       /
                 /22 \       //22             /22 /32  |       | /32 \       //22       / /32 |
               ,-----.                     ,-----.
             ,'       `.            /22                 ,'       `.
            / AS2 AS64502   \           /24               / AS3 AS64503   \
           (  /22:AS1             )-------------(  /22:AS1             )
            \ /24:AS3           /  /22 /32       /32 \ /24:AS1           /
                /22 /`.
             `.       ,'   ->       /34  `.       ,'
                /24/
               '-----;              <-  /  '-----'
                  /
                      \                /
            ,---./
                    ^  \              /
           /     \   10.0.0.0/22\            /10.0.0.0/22
          (  AS4  )    ^
                    |   \            / 10.0.0.0/24     |
                    |    \          /      |
                    |     \ ,-----.'
            `---'       |  2001:DB8::/32
                    |     ,'       `.      |  2001:DB8::/34
      2001:DB8::/32 +--  / AS1 AS64501   \   --+
                        (             )
                         \           /
                          `.       ,'
                            '-----'

                   Figure 10: More Specific Injection

   From AS2's point 3: Remote triggered filtering

2.2.1.  Unexpected traffic flows caused by remotely triggered filtering
        of view, such a path is a "peer path" overlapping prefixes

   Figure 4 expands the scenario from Figure 3 and will only
   be advertised by AS2 includes other AS
   peering with ASes 64502 and 64503.  Due to its customers. the limitation on the
   scope performed on the overlapping prefix, ASes that are not
   customers of AS2 AS64502 will not receive a path for
   10.0.0.0/24. 2001:DB8::/34.
   These ASes will forward packets destined to 10.0.0.0/24 2001:DB8::/34 according
   to their routing state for 10.0.0.0/22. 2001:DB8::/32.  Let us assume that
   AS5 AS64505
   is such an AS, and that its best path towards 10.0.0.0/22 2001:DB8::/32 is
   through AS2.  Then, packets AS64502.  Packets sent towards 10.0.0.1 2001:DB8::1 by AS5 AS64505 will
   eventually
   reach AS2. AS64502.  However, in the data-plane of the nodes of
   AS2, AS64502,
   the longest prefix match for 10.0.0.1 2001:DB8::1 is 10.0.0.0/24, 2001:DB8::/34, which is
   reached through AS3, AS64503, a settlement-free peer of AS2. AS64502.  Since AS5
   AS64505 is not in the customer branch of AS2, AS64502, we are in a
   situation in which traffic flows between non-customer ASes take place
   in AS2.

4. AS64502.

                  ,-----.
                ,'       `.
               / AS64505   \
              (             )
               \           /
                `.       ,'
                  '-----'
                    ^    \         /     ^       ^    \         /    ^
                    | /32 \       / /32  |       | /32 \       / /32 |
                    +       ,-----.      +       +      ,-----.      +
                          ,'       `.                 ,'       `.
                         / AS64502   \               / AS64503   \
                        (             )-------------(             )
        ,-----.          \           / /32       /32 \           /
      ,'       `.---------`.       ,'  +->       /34  `.       ,'
     / AS64504   \    /32   '-----;              <-+ /  '-----'
    (             )   /34          \                /
     \           /    <-+        ^  \              /    ^
      `.       ,'                |   \            /     |
        '-----;                  |    \          /      |
                                 |     \ ,-----.'       |  2001:DB8::/32
                                 |     ,'       `.      |  2001:DB8::/34
                   2001:DB8::/32 +--+ / AS64501   \  +--+
                                     (             )
                                      \           /
                                       `.       ,'
                                         '-----'

   Figure 4: Unexpected traffic flows due to remote triggered filtering

3.  Techniques to detect unexpected traffic flows caused by filtering of
    overlapping prefixes

   We differentiate the techniques available for detecting

3.1.  Existence of unexpected traffic flows caused by the described scenarios from the cases in
   which the interested within an AS

   To detect if unexpected traffic flows are taking place in its
   network, an ISP can monitor its traffic data to check if it is
   providing transit between two of its peers, although his policy is
   configured to not provide such transit.  IPFIX (RFC7011 [3]) is an
   example of a technology that can be used to export information
   regarding traffic flows across the network.  Traffic information must
   be analyzed under the victim or contributor perspective of the business relationships with
   neighboring ASes.  Open source tools such
   operations.

4.1.  Being as [4] can be used to this
   end.

   Note that the AS detecting the 'victim' of unexpected traffic flows

   To detect if unexpected 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 may simply
   realize that his policy configuration is forwarded to
   a non-customer next-hop.

   As mentioned in Section 3.1, broken.  The first
   recommended action upon detection of an unexpected traffic flows might appear
   due flow is to different situations.  To discover
   verify the correctness of the BGP configuration.

   Once it has been assessed that the local configuration is correct,
   the operator should check if the problem arose after detected in the data-plane
   arose due to filtering of prefixes BGP paths by neighboring ASes, an ASes.  The
   operator can
   analyze available BGP data.  For instance, should check if the destination address of the unexpected
   traffic flow is locally routed as per an ISP can seek for overlapping prefixes for which prefix only
   received from non-customer peers.  The operator should also checks if
   there are paths to a covering prefix received from a customer, and
   hence propagated to peers.  If these two situations happen at the next-hop
   same time, the neighboring AS at the entry point of the unexpected
   flow is through a provider (or
   peer), while routing the traffic based on the next-hop for their covering prefix(es) prefix, although
   the ISP is through a
   client.  Direct communication actually forwarding the traffic via non-customer links.

   To detect the origin of the problem, human interaction or looking
   glasses can be used in order to check find out whether non-customer neighboring ASes are propagating a path towards
   the covering prefix and not the path towards local filtering,
   remote filtering, or selective propagation was performed on the
   overlapping prefix.
   This situation should trigger a warning, as this would mean that ASes
   in  Due to the distributed nature and restricted
   visibility of the steering of BGP policies, such analysis is deemed
   to not identify the surrounding area origin of the current AS problem with guaranteed accuracy.
   We are forwarding packets
   based on the routing entry for not aware, at the less specific prefix only.

4.2.  Being a contributor time of this writing, of any openly
   available tool that can automatically perform this operation.

3.2.  Contribution to the existence of unexpected traffic flows in other networks
      another AS

   It can be considered problematic to be causing unexpected traffic
   flows on in other ASes.  This situation may appear as an abuse to the
   network resources of other ISPs.

   There may be justifiable reasons for one ISP to perform filtering, 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 relationship implementations.
   Restricting such the use of these features for the sake of avoiding the
   creation of unexpected traffic flows is not a practical option.

   Traffic data does not help an ISP detect that it is acting as a
   contributor of the creation of the unexpected traffic flow.

   It is
   thus advisable for an AS to obtain assess the risks of filtering
   overlapping prefixes before implementing them by obtaining as much
   data information as possible about the
   Internet environment its surrounding routing
   environment.  The AS would need information of the AS routing policies
   and assess the risks relationships among external ASes to detect if its actions
   could trigger the appearance of filtering unexpected traffic flows.  With this
   information, the operator could detect other ASes receiving the
   overlapping prefixes before implementing them.

   Monitoring prefix from non-customer ASes, while announcing the
   covering prefix to other non-customer ASes.  If the manipulation filtering of the communities that implement
   overlapping prefix leads other ASes to send traffic for the
   scoping of prefixes
   overlapping prefix to these ASes, an unexpected traffic flow can
   arise.  However, the information required for this operation is recommended
   difficult to obtain, due to the ISPs that provide these
   features.  The monitored behavior should then be compared with their
   terms distributed nature of use.

5. BGP policies.
   We are not aware, at the time of this writing, of any openly
   available tool that can automatically perform this procedure.

4.  Techniques to counter unexpected traffic flows due to the filtering
    of overlapping prefixes

   Network Operators can adopt different approaches with respect to
   unexpected traffic flows.  Note that due the complexity of inter-
   domain routing policies, there is not a single solution that can be
   applied to all situations.  We provide potential solutions that ISPs
   must evaluate against each particular case.  We classify these
   actions according to whether they are anticipant or reactive.

   Reactive approaches are those in which the operator tries to detect
   the situations via monitoring and solve unexpected traffic flows,
   manually, on a case-by-case basis.

   Anticipant or preventive approaches are those in which the routing
   system will not let the unexpected traffic flows actually take place
   when the configuration scenario is set up. arises.

   We use the scenario depicted in Figure 11 5 to describe these two kinds
   of approaches.  Based on our analysis, we observe that anticipant
   approaches can be complex to implement and can lead to undesired
   repercussions.
   effects.  Therefore, we conclude that the reactive approach is the
   more reasonable recommendation to deal with unexpected flows.

                         ____,,................______
               _,.---''''                            `''---..._
           ,-''   AS5   AS64505                                      `-.
           [                                                      /
            -.._                                             __.-'
             .  `'---....______                ______...---''
                |/22
           + |/32              `'''''''''''''''         |
                |/24                 |/22
           | |/34               + |/32                  |
           v |                  v |/34                  |                    |/24
             |                    |                   ^ |
             |                  ^ |/32                |                    |/22                  |/22 |/32
             |                  + |                     |/24                   + |/34
      _,,---.:_               _,,---.._              _,,---.._
    ,'         `.           ,'         `.          ,'         `.
   /  AS4  AS64504    \     <-+ /  AS2  AS64502    \        /  AS3  AS64503    \
   |             |_________|             |        |             |
   |             |     /22     /32 |             |        |             |
   '.           ,'          .           ,'         .           ,'
     `.       ,'             `.       ,'            `.       ,'
       ``---''                 ``---''                ``---''
                                   |                  ^ |
                                 ^ |2001:DB8::/32     |                    |10.0.0.0/24
                                      |10.0.0.0/22         |10.0.0.0/22
                                        _;,..---------...._|
                                     ,-'AS1 |2001:DB8::/32
                                 | |                  + |2001:DB8::/34
                                 + | _....---------...._|
                                  ,-'AS64501            ``-.
                                /'                          `.
                                `.                         _,
                                  `-.._               _,,,'
                                       `''---------'''

      Figure 11: Anticipant counter-measures 5: Counter-measures for unexpected traffic flows - Base
                                  example

5.1.

4.1.  Reactive counter-measures

   An operator who detects unexpected traffic flows originated by any of
   the cases described in Section 3 2 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.

   If the situation remains, the operator can implement prefix filtering
   in order to stop the unexpected flows.  The operator can decide to
   perform this action over the session with the operator announcing the
   overlapping prefix or over the session with the neighboring AS from
   which it is receiving the traffic.  Each of these options carry a
   different repercussion for the affected AS.  We describe briefly the
   two alternatives.

   o  An operator can decide to stop announcing the covering prefix at
      the peering session with the neighboring AS from which it is
      receiving traffic to the overlapping prefix.  In the example of
      Figure 11, AS2 5, AS64502 would filter out the prefix 10.0.0.0/22 2001:DB8::/32 from
      the eBGP session with AS4. AS64504.  In this case, not all the traffic
      heading to the prefix 10.0.0.0/22 2001:DB8::/32 from AS1 AS64501 would not no longer
      traverse AS2.
      AS2 AS64502.  AS64502 should evaluate if solving the inconvenient issues
      originated by the unexpected traffic flows are worth the loss of
      this traffic share.

   o  An operator can decide to filter-out filter out the concerned overlapping prefix at the
      peering session over which it was received.  In the example of
      Figure 11, AS2 5, AS64502 would filter out the incoming prefix
      10.0.0.0/24
      2001:DB8::/34 from the eBGP session with AS5. AS64505.  As a result,
      the traffic destined to that /24 /32 would be forwarded by AS2 AS64502
      along its link with AS1, AS64501, despite the actions performed by AS1
      AS64501 to have this traffic coming in through its link with AS3.
      AS64503.  However, as AS2 AS64502 will no longer possess know a route to the
      overlapping prefix, it risks losing the traffic share from
      customers different from AS1 AS64501 to that prefix.  Furthermore,
      this action can generate conflicts between
      AS2 AS64502 and AS1, AS64501,
      since AS2 AS64502 does not follow the policy routing information expressed by AS1
      AS64501 in its BGP announcements.

   It is possible that the behavior from of the neighboring AS that is causing the
   unexpected traffic flows opposes the peering agreement.  In this
   case, an operator can could account the amount of traffic that has been
   subject to the unexpected flows flows, using traffic measurement protocols
   such as IPFIX, and charge the peer for that traffic.  That is, the
   operator can claim that it has been a provider of that peer for the
   traffic that transited between the two ASes.

5.2.

4.2.  Anticipant counter-measures

5.2.1.

4.2.1.  Access lists

   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 unexpected traffic flows.
   In the example of Figure 11, AS2 5, AS64502 would install an access-list
   denying packets matching 10.0.0.0/24 2001:DB8::/34 associated with the interface
   connecting to AS4. AS64504.  As a result, traffic destined to that prefix
   would be dropped, despite the existence of a valid route towards 10.0.0.0/22.

   Note that this
   2001:DB8::/32.

   This technique actually lets packets destined to a valid prefix be
   dropped while they are sent from a neighboring AS that
   cannot may not know
   about the policy conflicts conflict and hence had no means to avoid the
   creation of unexpected traffic flows.

5.2.2.  Automatic overlapping prefix filtering

   As described in Section 3, filtering of overlapping prefixes can in
   some scenarios lead to unexpected traffic flows.  Nevertheless,
   depending on the autonomous system implementing such practice,  For this
   operation can prevent these cases.  This reason, this
   technique can be illustrated using the
   example described in Figure 11: if AS2 or AS3 filter prefix 10.0.0.0/
   24, there would be no unexpected traffic flow in AS2.  Nevertheless,
   as described in Section 5.1, the filtering of overlapping prefixes
   can generate conflicts between AS1 considered harmful and AS2, since AS2 would is thus not
   forward traffic according to AS1's policy.  Additionally, AS2 can
   lose traffic share recommended for the overlapping prefix from customers
   different from AS1.

5.2.3.
   implementation.

4.2.2.  Neighbor-specific forwarding

   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.

   As an example, let us analyze the scenario of Figure 11 5 from the point
   of view of AS2. AS64502.  The edge router connecting to the AS4 forward AS64504
   forwards packets destined to prefix 10.0.0.0/24 2001:DB8::/34 towards AS5. AS64505.
   Likewise, it
   will forward forwards packets destined to prefix 10.0.0.0/22 2001:DB8::/32
   towards AS1. AS64501.  The router, however, only propagates the path of
   the covering prefix
   (10.0.0.0/22) (2001:DB8::/32) to AS4. AS64504.  An operator could
   implement the necessary techniques to force the edge router to
   forward packets coming from
   AS4 AS64504 based only on the paths
   propagated to AS4. AS64504.  Thus, the edge router would forward packets
   destined to 10.0.0.0/24 2001:DB8::/34 towards AS1 AS64501 in which case no unexpected
   traffic flow would occur.

   Different techniques could provide the functionality just described; this functionality; however, their
   technical implementation can be complex to design and operate.  An
   operator could, for instance, employ Virtual Routing Forwarding (VRF)
   tables RFC4364 [4] to store the routes announced to a neighbor and
   forward traffic exclusively based on those routes. [2] describes an approach to implement this behavior.
   Similar
   solution and provides a description of its limitations.  In the
   future, new network protocols and architectures could provide this
   functionality with less overhead for management and device resources.

   Note that similarly to the solution described in Section 5.2.2, 4.1, this
   approach could create conflicts between AS2 AS64502 and AS1, AS64501, since
   the traffic forwarding performed by A2 AS64502 goes against the policy
   of AS1.

6. AS64501.

5.  Conclusions

   In this document, we described threats to policies of autonomous
   systems caused by how the filtering of overlapping
   prefixes performed by
   external networks. can potentially create unexpected traffic flows in remote
   ASes.  We provide provided examples of scenarios in which unexpected traffic
   flows are caused by these practices and introduce some techniques for
   their detection and prevention.  Analyzing the different options for
   dealing with this kind of problems, we recommend potential victims ASes affected by
   unexpected traffic flows to implement monitoring systems that can
   detect them and react to them according to the specific situation.
   Although we observe that there are reasonable situations in which
   ASes could filter overlapping prefixes, we encourage that network
   operators to implement this type of filters only after considering the cases
   described in this document.

6.  Security Considerations

   It is possible for an AS to use any of the methods described in this
   document to deliberately reroute traffic flowing through another AS.
   The objective of this document is to inform on this potential routing
   security issue.

7.  IANA Considerations

   This document has no IANA actions.

8.  Acknowledgments

   The authors would like to thank Wes George, Jon Mitchell, and Bruno
   Decraene for their useful suggestions and comments.

9.  References

9.1.  References

   [1]        Donnet, B. and O. Bonaventure, "On BGP Communities", ACM
              SIGCOMM Computer Communication Review vol. 38, no. 2, pp.
              55-59, April 2008.

   [2]        Vanbever, L., Francois, P., Bonaventure, O., and J.
              Rexford, "Customized BGP Route Selection Using BGP/MPLS
              VPNs", Cisco Systems, Routing Symposium
              http://www.cs.princeton.edu/~jrex/talks/cisconag09.pdf,
              October 2009.

   [3]        "INIT7-RIPE63", <http://ripe63.ripe.net/presentations/48
              -How-more-specifics-increase-your-transit-bill-v0.2.pdf>.

7.2. <http://ripe63.ripe.net/presentations/48-
              How-more-specifics-increase-your-transit-bill-v0.2.pdf>.

   [4]        "pmacct project: IP accounting iconoclasm",
              <http://www.pmacct.net>.

9.2.  URIs

   [1] http://www.ietf.org/rfc/rfc1812.txt

   [2] http://tools.ietf.org/html/draft-white-grow-overlapping-routes-02

   [3] http://www.ietf.org/rfc/rfc4384.txt

   [3] http://www.ietf.org/rfc/rfc7011.txt

   [4] http://www.ietf.org/rfc/rfc4364.txt

Authors' Addresses

   Camilo Cardona
   IMDEA Networks/UC3M
   Avenida del Mar Mediterraneo, 22
   Leganes  28919
   Spain

   Email: juancamilo.cardona@imdea.org

   Pierre Francois
   IMDEA Networks
   Avenida del Mar Mediterraneo, 22
   Leganes  28919
   Spain

   Email: pierre.francois@imdea.org

   Paolo Lucente
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: plucente@cisco.com