[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sriram-idr-route-leak-detection-mitigation) 00 01 02 03 04 05 06 07 08 09

IDR and SIDR                                              K. Sriram, Ed.
Internet-Draft                                                  USA NIST
Intended status: Standards Track                          A. Azimov, Ed.
Expires: January 3, 2019                                     Qrator Labs
                                                            July 2, 2018


        Methods for Detection and Mitigation of BGP Route Leaks
           draft-ietf-idr-route-leak-detection-mitigation-09

Abstract

   Problem definition for route leaks and enumeration of types of route
   leaks are provided in RFC 7908.  This document specifies BGP
   enhancements that significantly extend its route-leak detection and
   mitigation capabilities.  The solution involves each participating AS
   setting a route-leak protection (RLP) field in BGP updates.  The RLP
   fields are carried in a new optional transitive attribute, called BGP
   RLP Attribute.  The RLP Attribute helps with detection and mitigation
   of route leaks at ASes downstream from the leaking AS (in the path of
   BGP update).  This is an inter-AS (multi-hop) solution mechanism.
   This solution complements the intra-AS (local AS) route-leak
   avoidance solution 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 January 3, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Sriram & Azimov          Expires January 3, 2019                [Page 1]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   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.  Route-Leak Types that the Solution Must Address . . . . . . .   3
   3.  Mechanisms for Detection and Mitigation of Route Leaks  . . .   5
     3.1.  Ascertaining Peering Relationship . . . . . . . . . . . .   5
     3.2.  Route-Leak Protection (RLP) Field Encoding by Sending
           Router  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  BGP RLP Attribute . . . . . . . . . . . . . . . . . .   8
       3.2.2.  Carrying RLP Field Values in the BGPsec Flags . . . .   9
     3.3.  Recommended Actions at a Receiving Router for Detection
           and Mitigation of Route Leaks . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   RFC 7908 [RFC7908] provides a definition of the route leak problem,
   and enumerates several types of route leaks.  This document first
   examines which of those route-leak types are detected and mitigated
   by the existing Origin Validation (OV) [RFC6811] method.  OV
   [RFC6811] and BGPsec path validation [RFC8205] together offer
   mechanisms to protect against re-originations and hijacks of IP
   prefixes as well as man-in-the-middle (MITM) AS path modifications.
   Route leaks [RFC7908] are another type of vulnerability in the global
   BGP routing system against which OV offers very limited protection.
   BGPsec path validation provides cryptographic protection for some
   aspects of BGP update messages, but in its current form BGPsec does
   not offer any protection against route leaks.

   For the types of route leaks enumerated in RFC 7908 [RFC7908], where
   the OV method does not offer a solution, this document specifies BGP



Sriram & Azimov          Expires January 3, 2019                [Page 2]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   enhancements that significantly extend its route-leak detection and
   mitigation capabilities.  The solution involves each participating AS
   setting a route-leak protection (RLP) field in BGP updates.  The RLP
   fields are carried in a new optional transitive attribute, called BGP
   RLP Attribute.  The RLP Attribute helps with detection and mitigation
   of route leaks at ASes downstream from the leaking AS (in the path of
   BGP update).  This is an inter-AS (multi-hop) solution mechanism.
   This solution complements the intra-AS (local AS) route-leak
   avoidance solution that is described in
   [I-D.ietf-idr-bgp-open-policy].

   The RLP mechanism is backward compatible with BGP routers that are
   not upgraded to perform RLP.  Early adopters would see significant
   benefits.  If a group of big ISPs deploy RLP, then they would be
   helping each other by blocking route leaks originated within one's
   customer cone from propagating into a peer's AS or their customer
   cone.

   The inter-AS RLP solution is meant to be initially implemented as an
   enhancement of BGP without requiring BGPsec.  However, when BGPsec is
   deployed in the future, the solution should be incorporated in
   BGPsec, enabling cryptographic protection for the RLP fields.  That
   is one way of securing the solution against malicious route leaks.

2.  Route-Leak Types that the Solution Must Address

   Referring to the enumeration of route leaks discussed in [RFC7908],
   Table 1 summarizes the route-leak detection capability offered by OV
   and BGPsec for different types of route leaks.

   A detailed explanation of the contents of Table 1 is as follows.  It
   is readily observed that route leaks of Types 1, 2, 3, and 4 are not
   detected by OV or BGPsec in its current form.  Clearly, Type 5 route
   leak involves re-origination or hijacking, and hence can be detected
   by OV.  In the case of Type 5 route leak, there would be no existing
   ROAs to validate a re-originated prefix or more specific prefix, but
   instead a covering ROA would normally exist with the legitimate AS,
   and hence the update will be considered Invalid by OV.













Sriram & Azimov          Expires January 3, 2019                [Page 3]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   +---------------------------------+---------------------------------+
   | Type of Route Leak              | Current State of Detection      |
   |                                 | Coverage                        |
   +---------------------------------+---------------------------------+
   | Type 1: Hairpin Turn with Full  | Neither OV nor BGPsec (in its   |
   | Prefix                          | current form) detects Type 1.   |
   | ------------------------------- | ------------------------------- |
   | Type 2: Lateral ISP-ISP-ISP     | Neither OV nor BGPsec (in its   |
   | Leak                            | current form) detects Type 2.   |
   | ------------------------------- | ------------------------------- |
   | Type 3: Leak of Transit-        | Neither OV nor BGPsec (in its   |
   | Provider Prefixes to Peer       | current form) detects Type 3.   |
   | ------------------------------- | ------------------------------- |
   | Type 4: Leak of Peer Prefixes   | Neither OV nor BGPsec (in its   |
   | to Transit Provider             | current form) detects Type 4.   |
   | ------------------------------- | ------------------------------- |
   | Type 5: Prefix Re-Origination   | OV detects Type 5.              |
   | with Data Path to Legitimate    |                                 |
   | Origin                          |                                 |
   | ------------------------------- | ------------------------------- |
   | Type 6: Accidental Leak of      | For internal prefixes never     |
   | Internal Prefixes and More      | meant to be routed on the       |
   | Specific Prefixes               | Internet, OV helps detect their |
   |                                 | leak; they might either have no |
   |                                 | covering ROA or have an AS0-ROA |
   |                                 | to always filter them. In the   |
   |                                 | case of accidental leak of more |
   |                                 | specific prefixes, OV may offer |
   |                                 | some detection due to ROA       |
   |                                 | maxLength.                      |
   +---------------------------------+---------------------------------+

     Table 1: Examination of Route-Leak Detection Capability of Origin
               Validation and Current BGPsec Path Validation

   In the case of Type 6 leaks involving internal prefixes that are not
   meant to be routed in the Internet, they are likely to be detected by
   OV.  That is because such prefixes might either have no covering ROA
   or have an AS0-ROA to always filter them.  In the case of Type 6
   leaks that are due to accidental leak of more specific prefixes, they
   may be detected due to violation of ROA maxLength.  BGPsec (i.e.,
   path validation) in its current form does not detect Type 6.
   However, route leaks of Type 6 are least problematic due to the
   following reasons.  In the case of leak of more specific prefixes,
   the offending AS is itself the legitimate destination of the leaked
   more-specific prefixes.  Hence, in most cases of this type, the data
   traffic is not misrouted.  Also, leaked announcements of Type 6 are
   short-lived and typically withdrawn quickly following the



Sriram & Azimov          Expires January 3, 2019                [Page 4]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   announcements.  Further, the MaxPrefix limit may kick-in in some
   receiving routers and that helps limit the propagation of sometimes
   large number of leaked routes of Type 6.

   Realistically, BGPsec may take a much longer time being deployed than
   OV.  Hence, solution proposals for route leaks should consider both
   scenarios: (A) OV only (without BGPsec) and (B) OV plus BGPsec.
   Assuming an initial scenario A, and based on the above discussion and
   Table 1, it is evident that the solution method should focus
   primarily on route leaks of Types 1, 2, 3, and 4.

3.  Mechanisms for Detection and Mitigation of Route Leaks

   There are two considerations for route leaks: (1) Prevention of route
   leaks from a local AS [I-D.ietf-idr-bgp-open-policy], and (2)
   Detection and mitigation of route leaks in ASes that are downstream
   from the leaking AS (in the path of BGP update).  This document
   specifies the latter.

3.1.  Ascertaining Peering Relationship

   There are four possible peering relationships (i.e., roles) an AS can
   have with 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, the
   peering role types provider, customer, or lateral peer apply for
   different non-overlapping sets of prefixes.

   Operators rely on some form 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
   of prefixes for which they have different roles.
   [I-D.ietf-idr-bgp-open-policy] introduces a method of re-confirming
   the BGP Role during BGP OPEN messaging (except when the role is
   complex).  It defines a new BGP Role capability, which helps in re-
   confirming the relationship when it is provider, customer, or lateral
   peer.  BGP Role does not replace the OOB communication since it
   relies on the OOB communication to set the role type in the BGP OPEN
   message.  However, BGP Role provides a means to double check, and if
   there is a contradiction detected via the BGP Role messages, then a
   Role Mismatch Notification is sent [I-D.ietf-idr-bgp-open-policy].

   When the BGP relationship information has been correctly exchanged
   (i.e., free of contradictions) including the sets of prefixes with
   different roles (if complex), then this information SHOULD be used to



Sriram & Azimov          Expires January 3, 2019                [Page 5]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   automatically set the role per-prefix with each peer.  For example,
   if the local AS's role is Provider with a neighbor AS, then the per-
   prefix role is set to 'Provider' for all prefixes sent to the
   neighbor, and set to 'Customer' for all prefixes received from the
   neighbor.

   Once the per-prefix roles are set, this information is used in the
   RLP solution mechanism that is described in Section 3.2 and
   Section 3.3.

3.2.  Route-Leak Protection (RLP) Field Encoding by Sending Router

   The key principle is that, in the event of a route leak, a receiving
   router in a transit-provider AS (e.g., referring to Figure 1, ISP2
   (AS2) router) should be able to detect from the update message that
   its customer AS (e.g., AS3 in Figure 1) should not have forwarded the
   update (towards the transit-provider AS).  This means that at least
   one of the ASes in the AS path of the update signaled 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.  This signaling is achieved by a Route-Leak Protection
   (RLP) field as described below.


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

   * Design A:

   For route-leak detection and mitigation, the Route Leak Protection
   (RLP) field value MUST be set as follows:



Sriram & Azimov          Expires January 3, 2019                [Page 6]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   o  Insert the public registered local AS number and RLP = 0 when BGP
      UPDATE is forwarded to a transit provider,

   o  Insert the public registered local AS number and RLP = 1 when BGP
      UPDATE is forwarded to a customer or lateral peer.

   * Design B:

   For route-leak detection and mitigation, the Route Leak Protection
   (RLP) field value MUST be set as follows:

   o  Do not insert anything when BGP UPDATE is forwarded to a transit
      provider,

   o  Insert the public registered local AS number when BGP UPDATE is
      forwarded to a customer or lateral peer.

   Note: Design A requires all participating ASes in the path to
   indicate the direction in which the BGP UPDATE is sent.  On the other
   hand, Design B requires participating ASes to insert their AS number
   only when the BGP UPDATE is sent to a customer or lateral peer.
   After discussion in the WG, one of the designs will be finalized.  It
   will be discussed if the extra information provided in Design A adds
   value for route leak detection and mitigation.

   Note: In the rest of this document, by "RLP is set" it is meant that
   RLP = 1 for one or more ASes in the AS path (in Design A), or, that
   the RLP Attribute (with one or more AS numbers in it) is present (in
   Design B).  Further, in the context of either design, "RLP includes
   AS X" means that "RLP is set" by AS X which is in the path.  The
   intent of setting RLP is that the neighbor AS or any receiving AS
   along the subsequent AS path SHOULD NOT forward the UPDATE 'Up'
   towards its transit-provider AS or laterally towards its peer AS.

   The RLP fields are set on a per prefix basis.  This is because some
   peering relations between neighbors can be complex (see Section 3.1).

   Either Design A or B (described above) works for detection and
   mitigation of route leaks of Types 1, 2, 3, and 4 which are the focus
   here (see Section 3.3).

   An AS MUST NOT rewrite/reset the values set by any preceding ASes in
   their respective RLP fields.

   The RLP encoding MUST be carried in BGP-4 [RFC4271] updates in a new
   BGP optional transitive attribute (see Section 3.2.1).  In BGPsec, it
   must be carried in the Flags field (see Section 3.2.2).




Sriram & Azimov          Expires January 3, 2019                [Page 7]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   In partial deployment, there may be eBGP routers in the AS path that
   are not upgraded and hence do not participate in RLP.  However, the
   RLP mechanism is backward compatible.  Participating ASes can detect
   and mitigate route leaks while ASes not upgraded might remain
   vulnerable.  If big ISPs deploy RLP, then they would be helping each
   other by not allowing route leaks originated within one's customer
   cone to propagate into another's AS or their customer cone.  This
   accords significant benefit to early adopters.

3.2.1.  BGP RLP Attribute

   The BGP RLP Attribute is a new BGP optional transitive attribute.
   The attribute type code for the RLP Attribute is to be assigned by
   IANA.  The length field of this attribute is 2 octets.

   * RLP Attribute for Design A:

   The value field of the RLP Attribute is defined as a set of one or
   more pairs of ASN (4 octets) and RLP (one octet) fields as described
   below (Figure 2).


   +-----------------------+ -\
   | ASN: N                |   |
   +-----------------------+    >  (Most recently added)
   | RLP: N                |   |
   +-----------------------+ -/
    ...........
   +-----------------------+ -\
   | ASN: 1                |   |
   +-----------------------+    >  (Least recently added)
   | RLP: 1                |   |
   +-----------------------+ -/


                    Figure 2: BGP RLP Attribute format.

   The RLP Attribute value is a sequence of these two components (see
   Figure 2):

   ASN: Four octets encoding the public registered AS number of a BGP
   speaker.

   RLP Field: One octet encoding the RLP Field bits.  The value of the
   RLP Field octet can be 0 (decimal) or 1 (decimal) as described above
   in Section 3.2.1.  Its usage will be further discussed in subsequent
   sections.




Sriram & Azimov          Expires January 3, 2019                [Page 8]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   If all ASes in the AS_PATH of a route are upgraded to participate in
   RLP, then the ASNs in the RLP TLV in Figure 2 will correspond one-to-
   one with sequence of ASes in the AS_PATH (excluding prepends).  If
   some ASes do not participate, then one or more {ASN, RLP} tuples may
   be missing in the RLP Attribute relative to the AS_PATH.

   * RLP Attribute for Design B:

   The value field of the RLP Attribute is defined as a sequence of one
   or more ASN (4 octets) fields as described below (Figure 3).


   +-----------------------+
   | ASN: N                |   (Most recently added)
   +-----------------------+
   | ASN: N-1              |
   +-----------------------+
    ...........
   +-----------------------+
   | ASN: 2                |
   +-----------------------+
   | ASN: 1                |   (Least recently added)
   +-----------------------+


                    Figure 3: BGP RLP Attribute format.

   Thus, the RLP Attribute value is a sequence public registered AS
   numbers (see Figure 3).  The ASNs of only the participating
   (upgraded) ASes that sent the BGP UPDATE to a customer or lateral
   peer appear in the RLP Attribute.

3.2.2.  Carrying RLP Field Values in the BGPsec Flags

   In BGPsec-enabled routers that are also performing RLP, the RLP
   encoding MUST be accommodated in the existing Flags field in BGPsec
   updates.  The Flags field is part of the Secure_Path Segment in
   BGPsec updates [RFC8205].  One Flags field (one octet in size) is
   available for each AS hop, and currently only the first bit is used
   in BGPsec.  So, there are 7 bits that are currently unused in the
   Flags field.  One of these bits can be designated for the RLP field
   value (see Section 3.2.1).  This bit is set to 0 when the RLP Field
   value is 0 and set to 1 when the RLP Field value is 1.  Since the
   BGPsec protocol specification requires a sending AS to include the
   Flags field in the data that are signed over, the RLP field for each
   hop (since it would be part of the Flags field as described) will be
   protected under the sending AS's signature.




Sriram & Azimov          Expires January 3, 2019                [Page 9]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


3.3.  Recommended Actions at a Receiving Router for Detection and
      Mitigation of Route Leaks

   Route Leak Detection:

   When a customer route has at least one or more RLP fields set (to
   indicate 'do not propagate to provider or peer') by any AS(es)
   preceding the customer AS, then the route MUST be marked as route
   leak.  The same applies in the case of a peer route also.

   Route Leak Mitigation:

   For the most part, route leak mitigation policy can be set locally by
   a network operator.  However, the following rules MUST be included in
   any route leak mitigation policy.  These rules ensure stable route
   convergence and avoid the possibility of persistent route
   oscillations (see Section 3.1 in the route leak solution discussion
   document [RLP-Discussion] for an explanation).

   o  Rule 1: If ISP A receives a route r1 from customer AS C and
      another route r2 from provider (or peer) AS B (for the same
      prefix), and both routes r1 and r2 contain AS C and AS X (any X
      not equal to C) in the path and also contain [X] in their RLP
      Attributes, then prioritize the customer (AS C) route over the
      provider (or peer) route.

   o  Rule 2: If ISP A receives a route r1 from peer AS C and another
      route r2 from provider AS B (for the same prefix), and both routes
      r1 and r2 contain AS C and AS X (any X not equal to C) in the path
      and also contain [X] in their RLP Attributes, then prioritize the
      peer (AS C) route over the provider (AS B) route.

   Including the rules stated above, the RECOMMENDED route leak
   mitigation policy is as follows:

   1.  Given a choice between a customer route versus a provider (or
       peer) route,

       *  if no route leak is detected in the customer route, then
          prioritize the customer over the provider (or peer);

       *  else (i.e., when route leak is detected in the customer route)
          and the conditions of Rule 1 apply, then too prioritize the
          customer over the provider (or peer);

       *  else (i.e., when route leak is detected in the customer route
          and the conditions of Rule 1 DO NOT apply), then prioritize
          the provider (or peer) over the customer.



Sriram & Azimov          Expires January 3, 2019               [Page 10]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   2.  Given a choice between a peer route versus a provider route,

       *  if no route leak is detected in the peer route, then
          prioritize the peer over the provider;

       *  else (i.e., when route leak is detected in the peer route) and
          the conditions of Rule 2 apply, then too prioritize the peer
          over the provider;

       *  else (i.e., when route leak is detected in the peer route and
          the conditions of Rule 2 DO NOT apply), then prioritize the
          provider over the peer.

   In the case of choosing between a peer route and a provider route,
   network operators MAY apply a policy (different from the above) that
   they deem appropriate in their operating environment.

4.  Security Considerations

   The Route-Leak Protection (RLP) field requires cryptographic
   protection to prevent malicious route leaks.  In the future, in
   conjunction with BGPsec deployment, the RLP field will be included in
   the Flags field in the Secure_Path Segment in BGPsec updates.  So,
   the cryptographic security mechanisms in BGPsec will also apply to
   the RLP field.  The reader is therefore directed to the security
   considerations provided in [RFC8205].

5.  IANA Considerations

   IANA is requested to register a new optional, transitive attribute,
   named "Route Leak Protection (RLP) Attribute" in the BGP Path
   Attributes registry.  The attribute type code is TBD.  The reference
   for this new attribute is this document (i.e., the RFC that replaces
   this draft).  The length field of this attribute is 2 octets, and the
   length of the value field of this attribute is variable (see
   Figure 2) in Section 3.2.1 of this document).

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






Sriram & Azimov          Expires January 3, 2019               [Page 11]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


6.2.  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-03 (work in
              progress), June 2018.

   [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., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <https://www.rfc-editor.org/info/rfc7454>.

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

   [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-design-discussion-00, July 2018.

Acknowledgements

   The authors wish to thank Jared Mauch, Jeff Haas, Job Snijders,
   Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy
   Bush, Alexander Azimov, Ruediger Volk, Sue Hares, Wes George, Job
   Snijders, Chris Morrow, Sandy Murphy, Danny McPherson, and Eric



Sriram & Azimov          Expires January 3, 2019               [Page 12]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   Osterweil for comments, suggestions, and critique.  The authors are
   thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim 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







Sriram & Azimov          Expires January 3, 2019               [Page 13]


Internet-Draft     Route Leak Detection and Mitigation         July 2018


   Alexander Azimov (editor)
   Qrator Labs
   1-Y Magistral'nyy Tupik
   Moskva, XYZ  123007
   Russia

   Email: aa@qrator.net












































Sriram & Azimov          Expires January 3, 2019               [Page 14]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/