IDR and SIDR                                              K. Sriram, Ed.
Internet-Draft                                                  USA NIST
Intended status: Standards Track                          A. Azimov, Ed.
Expires: October 21, 2019 January 26, 2020                                         Yandex
                                                          April 19,
                                                           July 25, 2019

        Methods for Detection and Mitigation of BGP Route Leaks
           draft-ietf-grow-route-leak-detection-mitigation-00
           draft-ietf-grow-route-leak-detection-mitigation-01

Abstract

   Problem definition for route leaks and enumeration of types of route
   leaks are provided in RFC 7908. [RFC7908].  This document describes a solution new well-
   known Large Community that provides a way for detection and mitigation route leaks which is based on conveying
   route-leak protection (RLP) information in a Border Gateway Protocol
   (BGP) community.  The RLP information is carried in a new well-known
   transitive BGP community, called the RLP community. leak prevention,
   detection, and mitigation.  The RLP
   community helps configuration process for this
   Community can be automated with detection and mitigation of route leaks at ASes
   downstream from the leaking AS (in the path of the methodology for setting BGP update).  This
   is an inter-AS (multi-hop) solution mechanism.  This solution
   complements the intra-AS (local AS) route-leak avoidance solution roles
   that is described in ietf-idr-bgp-open-policy draft.

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 https://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 October 21, 2019. January 26, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://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.  Mechanisms for Detection and Mitigation of Route Leaks  . . .   3
     2.1.  Ascertaining  Peering Relationship . . Relationships . . . . . . . . . .   3
     2.2.  Route-Leak Protection (RLP) Semantics . . . . . . . . . .   4
       2.2.1.  Format of the RLP   2
   3.  Community vs Attribute  . . . . . . . . . . . . .   5
     2.3.  Route Leak Detection Rules and the Ingress Router
           (Receiver) Actions  . . . . . . . . . . . . . . . . . . .   6
     2.4.  Route Selection Policy  . . . . . . . . . . . . .   3
   4.  Down Only Community . . . .   6
     2.5.  Egress Router (Sender) Actions . . . . . . . . . . . . .   7
   3.  Pseudo Code . . . .   4
     4.1.  Route Leak Mitigation . . . . . . . . . . . . . . . . . .   5
     4.2.  Only Marking  . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8   6
   5.  IANA  Implementation Considerations . . . . . . . . . . . . . . . . . . . . .   8   6
   6.  References  . . .  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . .   8
     6.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     6.2.   7
   8.  Informative References  . . . . . . . . . . . . . . . . .   9 . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11   9

1.  Introduction

   RFC 7908

   [RFC7908] provides a definition of the route leak problem, problem and
   enumerates several types of route leaks.  For this document, the
   definition that is applied is that a route leak occurs when a route
   received from a transit provider or a lateral peer is forwarded
   (against commonly used policy) to another transit provider or a
   lateral peer.  The commonly used policy is that a route received from
   a transit provider or a lateral peer may MAY be forwarded "down only" only to
   customers.

   This document describes a solution for prevention, detection and
   mitigation route leaks which is based on conveying route-leak protection (RLP)
   information in a Border Gateway Protocol (BGP) community.  The RLP
   detection information is carried in a new well-known transitive BGP community,
   called the RLP community. Large Community.  The RLP community helps with detection and
   mitigation of route leaks at ASes downstream from the leaking AS (in
   the path of
   configuration process for the BGP update).  This is an inter-AS (multi-hop)
   solution mechanism. Large Community MUST be defined
   according to peering relations between ISPs.  This solution complements process can be
   automated with the intra-AS (local
   AS) route-leak avoidance solution methodology for setting BGP roles that is
   described in [I-D.ietf-idr-bgp-open-policy].

   Previously, an optional transitive BGP RLP Attribute was proposed to
   carry the RLP information (in earlier versions of this document).
   However,

   The techniques described in this updated document proposes a well-known transitive BGP
   community to carry the RLP information, with the intention of
   promoting faster adoption.

   The inter-AS RLP mechanism described here can be incrementally
   deployed.  Early adopters would see significant benefits.  If can be incrementally
   deployed.  If a group of big ISPs and/or Internet Exchanges (IXes)
   deploy RLP, the proposed techniques, then they would be helping each other
   by blocking route leaks originated within one's customer cone from
   propagating into that can happen between them.

2.  Peering Relationships

   As described in [I-D.ietf-idr-bgp-open-policy] there are several
   common peering relations between eBGP neighbors:

   o  Provider - sender is a transit provider of the neighbor;

   o  Customer - sender is a peer's AS or their customer cone.

2.  Mechanisms for Detection and Mitigation of the neighbor;

   o  Route Leaks

   There are two considerations for Server (RS) - sender is route leaks: (1) Prevention server at an internet exchange
      (IX)

   o  RS-client - sender is client of an RS at an IX

   o  Peer - sender and neighbor are lateral (non-transit) peers;

   If a route
   leaks is received from a local AS [I-D.ietf-idr-bgp-open-policy], and (2)
   Detection and mitigation of provider, peer or RS-client, it MUST
   follow the 'down only' rule, i.e., it MAY be advertised only to
   customers.  If a route leaks is sent to a customer, peer or RS-client, it
   also MUST follow the 'down only' rule at each subsequent AS in ASes the AS
   path.

   A standardized transitive route-leak detection signal is needed that are downstream
   will prevent Autonomous Systems (ASes) from the leaking AS (in and also inform a
   remote ISP (or AS) in the AS path of BGP update). that a received route violates
   'down only' policy.  This document
   specifies the latter.

2.1.  Ascertaining Peering Relationship

   There are four possible peering relationships (i.e., roles) an AS can
   have with signal would facilitate a neighbor AS: (1) Provider: transit-provider for all
   prefixes exchanged, (2) Customer: customer for all prefixes
   exchanged, (3) Lateral Peer: lateral peer (i.e., non-transit) for all
   prefixes exchanged, and (4) Complex: different relationships for
   different sets of prefixes [Luckie].  For the complex case, way to stop the
   peering role types provider, customer, or lateral peer apply for
   different non-overlapping sets
   propagation of leaked prefixes.

   Operators rely

   To improve reliability and cover for non-participating preceding
   neighbor, the signal should be set on some form both receiver and sender sides.

3.  Community vs Attribute

   This section presents a brief discussion of out-of-band (OOB) (i.e., external to
   BGP) communication to exchange information about their peering
   relationship, AS number, interface IP address, etc.  If the
   relationship is complex, the OOB communication also includes the sets advantages and
   disadvantages of prefixes communities and BGP path attributes for which they have different roles.
   [I-D.ietf-idr-bgp-open-policy] introduces a method the purpose
   of re-confirming route leak detection.

   A transitive path attribute is a native way to implement the route-
   leak detection signal.  Based on the way BGP Role during BGP OPEN messaging (except when protocol works, the role is
   complex).  It defines use
   of a transitive attribute makes it more certain that the route-leak
   detection signal would pass unaltered through non-participating
   (i.e., not updated) BGP routers.  The main disadvantage of this
   approach is that the deployment of a new BGP Role capability, which helps attribute requires a
   software update in re-
   confirming router OS which may delay wide adoption for years.

   On the relationship when it is provider, customer, or lateral
   peer. other hand, BGP Role does communities do not replace require a router OS update.
   The potential disadvantage of using a Community for the OOB communication since route-leak
   detection signal is that it
   relies on the OOB communication is more likely to set be dropped somewhere
   along the role type way in the BGP OPEN
   message.  However, BGP Role provides a means to double check, and if
   there is a contradiction detected via AS path.  Currently, the use of BGP Role messages, then a
   Role Mismatch Notification Communities
   is sent [I-D.ietf-idr-bgp-open-policy].

   When the somewhat overloaded.  BGP relationship information has been correctly exchanged
   including the sets of prefixes with Communities are already used for
   numerous applications: different roles (if complex),
   then types of route marking, route policy
   control, black-holing, etc.  It is observed that some ASes seem to
   purposefully or accidentally remove transitive communities on
   receipt, sometimes well-known ones.  Perhaps this information SHOULD issue may be used to automatically set the role
   per-prefix with each peer.  For example, if the local AS's role is
   Provider
   mitigated with a neighbor AS, then the per-prefix role is set to
   'Provider' for all prefixes sent strong policy guidance related to the neighbor, and set handling of
   Communities.

   Due to
   'Customer' for all prefixes received from the neighbor.

   Once the per-prefix roles are set, this information is used frequently occurring regional and global disruptions in the
   RLP
   Internet connectivity, it is critical to move forward with a solution mechanism
   that is described in this document.

2.2.  Route-Leak Protection (RLP) Semantics

   The key principle is that, viable in the event of a near term.  That solution would be route leak, a receiving
   router in a transit-provider AS (e.g., referring leak
   detection using BGP Community.

   Large Communities have much higher capacity, and therefore they are
   likely to Figure 1, ISP2
   (AS2) router) should be able less overloaded.  Hence, Large Community is proposed to detect from the RLP community in
   be used for route-leak detection.  This document suggests reserving
   <TBD1> class for the
   update message purpose of transitive well-known Large
   Communities that its customer AS (e.g., AS3 in Figure 1) should MUST not have forwarded the update (towards the transit-provider AS).
   Likewise when the update be stripped on ingress or egress.

   While it is received from a lateral peer.  This means
   that at least one not part of this document, the ASes route-leak detection
   signal described here can also be carried in the AS a BGP path of attribute,
   and the update put RLP
   information in RLP community to indicate that it sent the update to
   its customer or lateral peer, but forbade any subsequent 'Up'
   (customer to provider) or 'Lateral' (peer to peer) forwarding.

                                      /\              /\
                                       \ route-leak(P)/
                                        \ propagated /
                                         \          /
              +------------+    peer    +------------+
        ______| ISP1 (AS1) |----------->|  ISP2 (AS2)|---------->
       /       ------------+  prefix(P) +------------+ route-leak(P)
      | prefix |          \   update      /\        \  propagated
       \  (P)  /           \              /          \
        -------   prefix(P) \            /            \
                     update  \          /              \
                              \        /route-leak(P)  \/
                              \/      /
                           +---------------+
                           | customer(AS3) |
                           +---------------+

        Figure 1: Illustration of the basic notion of a route leak.

   The RLP information contained in the RLP community consists of one or
   two AS numbers (ASNs) same prevention and has the following semantics:

   1.  Down Only (DO) indication: ASN of the most recent RLP-aware AS in
       the path to assert that it sent the update to a customer or
       lateral peer;

   2.  Leak detected (L) indication: ASN of the first RLP-aware AS in
       the path to assert that it forwarded the route from a customer or
       lateral peer despite detecting a leak (to avoid unreachability).

   If the RLP community is present in an update, it will always contain
   a single DO.  However, L need not be always present.  (Note: mitigation techniques as described here
   would apply.  The bits
   designated to carry L may be always present along with a DO, except
   that authors are pursuing a default value (all zeros) is carried in L when no AS in the
   current AS path needed to assert L.)  Once an AS asserts L (Leak
   detected) by inserting its ASN value, it MUST not be changed
   subsequently as the update propagates.  But the ASN value separate internet draft in DO (Down
   Only) is changeable along
   the AS path per its definition above.

   Design assumption 1: Operators desire to avoid unreachability.  So, a
   design assumption here is IDR WG on that in approach.

4.  Down Only Community

   This section specifies the absence semantics of an alternative
   route, an AS may select route-leak-detection
   Community and forward a route that is detected to be a
   leak.  (Note: its usage.  This Community is given the reason Leak detected (L) indication is part
   of the design.)

   Design assumption 2: An AS that is RLP-aware (i.e., implements the
   RLP solution in this document) MUST also implement an intra-AS
   solution for route leak avoidance in the local AS. specific name
   Down Only (DO) Community.  The latter
   solution uses an intra-AS signaling mechanism (see
   [I-D.ietf-idr-bgp-open-policy], Section 3.7 of [RLP-Discussion]).  By
   doing this, the AS locally prevents the leaking of routes learned
   from a transit provider or lateral peer to another transit provider
   or lateral peer.  Why this is critical to the overall solution DO Community is
   made clear carried in slides 7 and 8 of [sriram2].

2.2.1.  Format of the RLP Community

   The format of the RLP community using a single BGP Large
   Community is with a format as shown in Figure 2. 1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Global Administrator  (IANA assigned        TBD1 (class for RLP) well-known transit communities)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Local Data Part 1 = DO (ASN value)                   TBD2 (subclass for DO)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Local Data Part 2 = L (ASN value)                             ASN                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: 1: Format of the RLP DO Community using a Large Community
                                [RFC8092].

2.3.  Route Leak Detection Rules

   The authors studied different options for route leak mitigation.  The
   main options considered are (1) drop detected route leaks and (2)
   deprioritize detected route leaks.  It can be demonstrated that the Ingress Router (Receiver)
      Actions

   A received
   loose mode that uses deprioritization is not safe.  Traffic
   Engineering (TE) technique which limit prefix visibility are quite
   common.  It may happen that a more specific TE prefix is sent only to
   downstream ASes or to IX(es)/selected peers, and a control Community
   is used to restrict its propagation.  If such a more specific prefix
   is leaked, deprioritization will not stop such a route leak from
   propagating.  In addition, propagation of leaked prefixes based on
   deprioritization may result in priority loops leading to BGP update wedgies
   [RFC4264] or even persistent route oscillations.

   So, the only truly safe way to implement route leak mitigation is determined to
   drop detected route leaks.  The ingress and egress policies
   corresponding to 'drop detected route leaks' is described in
   Section 4.1.  This policy SHOULD be used as a default behavior.

   Nevertheless, early adopters might want to deploy only the signaling
   and perhaps use it only for diagnostics before applying any route
   leak if:

   1.  if L mitigation policy.  They are also encouraged to use slightly
   limited marking, which is present described in Section 4.2.

4.1.  Route Leak Mitigation

   This section describes the update;

   2.  else (L eBGP ingress and egress policies that MUST
   be used to perform route leak prevention, detection and mitigation
   using the DO Community.

   The ingress policy MUST use the following procedure:

   1.  If a route with DO Community set (i.e., DO is absent), the update attached) is
       received from a customer Customer or RS-client, then it is a route leak
       and MUST be rejected.  The procedure halts.

   2.  If a route with DO
       is present;

   3.  else (L is absent), the update Community set is received from a lateral peer Peer (non-
       transit) and DO is present that is not the lateral peer's ASN.

   Note: Here by "L is present" we mean that its value is not equal to the
   default value (all zeros) but sending neighbor's ASN,
       then it is a proper ASN.  Effectively "L is
   absent" if its value is the default value.

   In steps 2 route leak and 3 above, MUST be rejected.  The procedure
       halts.

   3.  If a route is received from a Provider, Peer or RS, then the ingress router (receiver) DO
       Community MUST add L =
   local ANS.  Doing this prior be added with a value equal to the best path selection process is
   necessary.  Also, if sending
       neighbor's ASN.

   The egress policy MUST use the following procedure:

   1.  A route is selected as best path, then L is
   already with DO Community set correctly before the egress router (sender) acts on it.

2.4.  Route Selection Policy

   Minimum Default Policy: Whenever there MUST not be sent to Providers,
       Peers, and RS.

   2.  If a route is sent to a choice between Customer or Peer, then the DO Community
       MUST be added with a customer
   route value equal to the ASN of the sender.

   The above procedures comprehensively provide route-leak prevention,
   detection and mitigation.  Policy consisting of these procedures
   SHOULD be used as a provider route default behavior.

4.2.  Only Marking

   This section describes eBGP ingress and egress marking policies that are both detected to
   MUST be leaks (L used if an AS is
   present), then lower the LocalPref not performing route-leak mitigation (i.e.,
   dropping detected route leaks) as described in Section 4.1, but wants
   to X (TBD by operator) use only marking with DO Community.  The slightly limited DO
   marking (compared to that in Section 4.1) described below guarantees
   that this DO marking will not limit the leak detection opportunities
   for each of
   them.  Then shortest path criterion would typically make subsequent ASes in the customer AS path.

   The ingress policy MUST use the following procedure:

   1.  If a route preferred.  (Note: This would help mitigate any possibility of
   persistent oscillation; see slide #7 in [sriram1].)

   Generalized Minimum Default Policy: Whenever there with DO Community set is received from a Customer or
       RS-client, then it is a route leak.  The procedure halts.

   2.  If a route with DO Community set is received from a choice
   between multiple routes (customer/peer/provider) Peer and each DO
       value is detected not equal to be the sending neighbor's ASN, then it is a leak (L
       route leak.  The procedure halts.

   3.  If a route is present), received from a Provider, Peer or RS, then lower the LocalPref DO
       Community MUST be added with value equal to X TBD by
   operator) for each of them.  Then apply shortest path criterion.
   (Note: Some network operators may find this inadequate; see scenarios
   #3 and #6 in slides #14 and #16, respectively, in [sriram2].  But
   they may locally modify their policy while respecting the basic
   principle.)

2.5.  Egress Router (Sender) Actions

   After best path selection has been performed, a sender sending
       neighbor's ASN.

   The egress policy MUST perform use the following RLP-related actions on the update to be propagated: procedure:

   1.  When propagating  If a route originated by the local AS is sent to a customer Customer or lateral peer, add RS-client, then the DO = local ASN;
       Community MUST be added with value equal to the ASN of the
       sender.

   2.  Else, when propagating a  If DO Community is not set and the route that already includes is sent to a Peer, then
       the DO (i.e.,
       was received Community MUST be added with a DO) value equal to a customer or lateral peer, replace the ASN of the
       sender.

   These above procedures specify setting DO value with signal in a way that can be
   used to evaluate the local ASN.

3.  Pseudo Code

   [Begin: receiver action for potential impact of route leak detection]

   {Comment: This precedes route selection policy.}

      if received mitigation policy
   before deploying strict dropping of detected route includes L, then save leaks.

5.  Implementation Considerations

   It was observed that the route in RIB-in as is;

      else (L majority of BGP implementations does not
   support negative match for communities like a:b:!c.  Considering that
   it is absent), if suggested to replace the second rule from ingress policy with
   the following:

   If a route with DO Community set is received from a customer Peer and DO value
   is
      preset, equal to the sending neighbor's ASN, then add L = local ASN;

      else (L it is absent), if a valid route,
   otherwise it is a route leak.  The procedure halts.

   This rule is received from based on a weaker assumption that a lateral peer and
      DO is present that is not the lateral peer's ASN, then add L =
      local ASN

   {Comment: "Route does not include L" or "L doing
   marking is absent" only if L also doing filtering (dropping detected leaks).  That is
   either literally absent or has
   why networks that do not follow the default (all zeros) value.}

   [End: receiver action route leak mitigation policy in
   Section 4.1 MUST carefully follow marking rules described in
   Section 4.2.

6.  Security Considerations

   In specific circumstances in a state of partial adoption, route leak
   mitigation mechanism can result in Denial of Service (DoS) for route leak detection]

   ----------------------------------------------------------

   [Begin: route selection policy] the
   victim prefix.  Such a scenario may happen only for each route a prefix that includes L, lower has
   a single path from the LocalPref originator to X (TBD);
      apply best path selection policy*

   {*Comment: E.g., best path selection based on LocalPref first and
   then shortest path.}

   [End: route selection policy]

   ----------------------------------------------------------

   [Begin: sender action]

   {Comment: RLP (includes DO and L or just DO) is a *transitive* BGP
   community Tier-1 ISP and should propagate globally.} only when propagating the
   prefix is not covered with a less specific prefix with multiple paths
   to the Tier-1 ISP.  If, in such unreliable topology, route originated leak is
   injected somewhere inside this single path, then it may be rejected
   by local AS upper layer providers in the path, thus limiting prefix
   visibility.  While such anomaly is unlikely to a customer or
      lateral peer, add DO = local ASN;

      when propagating a route that includes a DO (i.e., was received
      with a DO) happen, such an issue
   should be easy to a customer or lateral peer, replace the DO value
      with debug, since it directly affects the local ASN;

   [End: sender action]

4.  Security Considerations sequence of
   originator's providers.

   With the use of BGP community, Community, there is often a concern that the
   community
   Community propagates beyond its intended perimeter and causes harm
   [streibelt].  However, that concern does not apply to the RLP
   community DO
   Community because it is a transitive community Community that must propagate as
   far as the update goes.

   The proposed Route-Leak Protection (RLP) information carried in the
   RLP community can benefit from cryptographic protection to prevent
   abuse by malicious actors in the AS path.  In the future, if there is
   BGPsec deployment, the RLP information can be encoded in the Flags
   field in the Secure_Path Segment in BGPsec updates [RFC8205].  So,
   the cryptographic security mechanisms in BGPsec can also secure the
   RLP information.  The reader is directed to the security
   considerations provided in [RFC8205].

5.

7.  IANA Considerations

   IANA is requested

   The draft suggests to register RLP in the reserve a Global Administrator ID <TBD1> for
   transitive well-known Large Community
   [RFC8092] registry (need help to clarify this). registry.  IANA is requested to
   allocate
   register a new Global Administrator ID subclass <TBD2> for the RLP community (Large
   Community) (see Figure 2 DO Community in this document).  Note that BGP Path
   Attribute value for Large Community is 32 (IANA allocated) [RFC8092].

6.  References
6.1.  Normative References

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

6.2. registry.

8.  Informative References

   [draft-dickson-sidr-route-leak-solns]
              Dickson, B., "Route Leaks -- Proposed Solutions",  IETF
              Internet Draft (expired), March 2012,
              <https://tools.ietf.org/html/
              draft-dickson-sidr-route-leak-solns-01>.

   [I-D.ietf-idr-bgp-open-policy]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
              Sriram, "Route Leak Prevention using Roles in Update and
              Open messages", draft-ietf-idr-bgp-open-policy-05 draft-ietf-idr-bgp-open-policy-06 (work in
              progress), February July 2019.

   [Luckie]   Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
              kc. claffy, "AS Relationships, Customer Cones, and
              Validation",  IMC 2013, October 2013,
              <http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC7454]  Durand, J., Pepelnjak, I.,

   [RFC4264]  Griffin, T. and G. Doering, Huston, "BGP Operations
              and Security", BCP 194, Wedgies", RFC 7454, 4264,
              DOI 10.17487/RFC7454,
              February 2015, <https://www.rfc-editor.org/info/rfc7454>. 10.17487/RFC4264, November 2005,
              <https://www.rfc-editor.org/info/rfc4264>.

   [RFC7908]  Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
              and B. Dickson, "Problem Definition and Classification of
              BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
              2016, <https://www.rfc-editor.org/info/rfc7908>.

   [RFC8092]  Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
              I., and N. Hilliard, "BGP Large Communities Attribute",
              RFC 8092, DOI 10.17487/RFC8092, February 2017,
              <https://www.rfc-editor.org/info/rfc8092>.

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <https://www.rfc-editor.org/info/rfc8205>.

   [RLP-Discussion]
              Sriram (Ed.), K., "Design Discussion of Route Leaks
              Solution Methods", Work in Progress, draft-sriram-idr-
              route-leak-solution-discussion-00, July 2018,
              <https://tools.ietf.org/html/
              draft-sriram-idr-route-leak-solution-discussion-00>.

   [sriram1]  Sriram et al., K., "Route Leaks Solution Merger of RLP and
              eOTC Drafts",  Presented at the IDR Working Group Meeting,
              IETF-102, Montreal, July 2018,
              <https://datatracker.ietf.org/meeting/102/materials/
              slides-102-idr-sessb-route-leaks-merged-solution-00>.

   [sriram2]  Sriram et al., K., "Solution for Route Leaks Using BGP
              Communities",  Authors Team Discussion Slides, October
              2018, <https://www.nist.gov/sites/default/files/
              documents/2018/10/22/rlp_using_bgp_community-v4.pdf>.

   [streibelt]
              Streibelt et al., F., "BGP Communities: Even more Worms in
              the Routing Can",  ACM IMC, October 2018,
              <https://archive.psg.com//181101.imc-communities.pdf>.

Acknowledgements

   The authors wish to thank John Scudder, Susan Hares, and Ruediger
   Volk Volk,
   Mat Ford, Greg Skinner for their review and comments.

Contributors

   The following people made significant contributions to this document
   and should be considered co-authors:

   Brian Dickson
   Independent
   Email: brian.peter.dickson@gmail.com

   Doug Montgomery
   USA National Institute of Standards and Technology
   Email: dougm@nist.gov

   Keyur Patel
   Arrcus
   Email: keyur@arrcus.com

   Andrei Robachevsky
   Internet Society
   Email: robachevsky@isoc.org

   Eugene Bogomazov
   Qrator Labs
   Email: eb@qrator.net

   Randy Bush
   Internet Initiative Japan
   Email: randy@psg.com

Authors' Addresses

   Kotikalapudi Sriram (editor)
   USA National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899
   United States of America

   Email: ksriram@nist.gov

   Alexander Azimov (editor)
   Yandex
   Ulitsa Lva Tolstogo 16
   Moscow  119021
   Russia

   Email: a.e.azimov@gmail.com