[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                              Y. Gu
Internet-Draft                                                 S. Zhuang
Intended status: Standards Track                                  Huawei
Expires: April 25, 2019                                 October 22, 2018


                    BMP for BGP Route Leak Detection
               draft-gu-grow-bmp-route-leak-detection-00

Abstract

   According to RFC7908 [RFC7908], Route leaks refer to case that the
   delivery range of route advertisements is beyond the expected range.
   For many current security protection solutions, the ISPs (Internet
   Service Providers) are focusing on finding ways to detect the
   happening of route leaks.  However, the real-time route leak
   detection if any occurs is important as well.  This document extends
   the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing
   security scheme suitable for ISPs to detect BGP route leaks within
   their own networks.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 April 25, 2019.








Gu & Zhuang              Expires April 25, 2019                 [Page 1]


Internet-Draft            Route Leak Detection              October 2018


Copyright Notice

   Copyright (c) 2018 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  ISP Route Leak Prevention Methods . . . . . . . . . . . .   3
     2.2.  Challenge of the Current Route Leak Prevention Methods  .   4
   3.  Existing RLD Methods Discussion . . . . . . . . . . . . . . .   4
   4.  BMP Extension for RLD . . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Terminology

   BMP: BGP Monitoring Protocol

   BMS: BGP Monitoring Station

   C2P: Customer to Provider

   ISP: Internet Service Provider

   P2P: Peer to Peer

   RIB: Routing Information Base

   RLD: Route Leak Detection





Gu & Zhuang              Expires April 25, 2019                 [Page 2]


Internet-Draft            Route Leak Detection              October 2018


2.  Introduction

   RFC 7908 defines "Route Leak" as: A route leak is the propagation of
   routing announcement(s) beyond their intended scope, which can result
   in possible situations such as eavesdropping, device overload, route
   black hole and so on.  More specifically, the intended scope of route
   announcements is usually defined by local route filtering/
   distribution policies within devices.  These policies are designed to
   realise the pair-wise peering business relationships between ASes
   (autonomous systems), which include Customer to Provider (C2P), Peer
   to Peer (Peer to Peer), and Provider to Customer (P2C).  In a C2P
   relationship, the customer pays the provider for traffic sent between
   the two ASes.  In return, the customer gains access to the ASes the
   provider can reach, including those which the provider reaches
   through its own providers.  In a P2P relationship, the peering ASes
   gain access to each other's customers, typically without either AS
   paying the other[Luckie].  RFC 7908 classifies six typical route
   leaks situations based on the documented events.

2.1.  ISP Route Leak Prevention Methods

   Since BGP itself does not provide any route leak prevention/
   protection, in the current networks, network administrators/operators
   typically configure export policies on the AS border routers (ASBRs)
   to prevent route leak.  For example, refer to the topology in
   Figure 1, an export policy is configured at ASBR R2 of AS1.  The
   export strategy is, for example, "routes from AS2 can be sent to AS3
   and cannot be sent to AS4."  After ASBR R1 of AS1 receives a route A
   from AS2, R1 marks A with BGP community attribute stating that route
   A is received from AS2.  Then route A with this tag is transmitted to
   another ASBR R2 through the intermediate node of AS1.  Now at ASBR
   R2, it checks the export filter/policy to determine if Route A with
   the tag is allowed to be distributed to a certain AS.  This tag
   stands for the peering business relationship between AS 2 and AS 1,
   so that ASBR R2 of AS 1 can use it to determine which ASes Route A
   can and cannot be distributed to prevent route leak (i.e.,
   distributing Route A to the wrong AS).  Suppose the destination AS of
   the route A is AS4, then R2 will not distribute Route A to AS4 were
   the export policies correctly configured.












Gu & Zhuang              Expires April 25, 2019                 [Page 3]


Internet-Draft            Route Leak Detection              October 2018


                  *************************
                  *                       *
          Route A *          AS1          *
          --->    *                     -----> Send A to AS3
          +-----+ *  +---+         +---+  *  +-----+
   ... ---| AS2 |----|R1 |-----+---|R2 |-----| AS3 |--- ...
          +-----+ *  +---+\        +---+  *  +-----+
                  *    |   \\    //  |\  --X-- Not send A to AS4
                  *    |     \\//    | \  *  +-----+
   .              *    |     //\     |  \----| AS4 |--- ...
                  *    |   //   \\   |    *  +-----+
                  *    |  /       \  |    *
                  *  +---+         +---+  *
   .              ---|R3 |---------|R4 |  *
                  *  +---+         +---+  *
                  *                       *
                  *************************

               Figure 1: Routing between ISPs

2.2.  Challenge of the Current Route Leak Prevention Methods

   However, it could happen that the export policies configured at ASBRs
   to prevent route leak are incorrect.  Thus, when the route leak
   prevnetion methods do not work, there requires a valid method to
   detect any occurred leak in a timely manner so that the incorrect
   policies/configurations can be modified to avoid further leak
   affection.

3.  Existing RLD Methods Discussion

   There are some existing methods proposed for Route Leak Detection
   (RLD).

   Many attempts have been made to infer relationships and strategies
   between ASs, however, the accuracy of these techniques is often
   questioned.  It's mainly due to the fact that the knowledge base for
   inferring the AS relationships and their corresponding export
   policies is limited to the routing information available at the data
   collection points.  In particular, the increase in the number of
   Internet Exchange Points (IXPs) and their role in the recent
   "flattening" of the Internet topology, makes that a large fraction of
   AS relationships cannot be discovered using these data collection
   points [Siddiqui].

   Moreover, some other technologies extend existing routing protocols
   to realize RLD.  For example, modify the BGP update message, which
   may bring about compatibility problems involved in the implementation



Gu & Zhuang              Expires April 25, 2019                 [Page 4]


Internet-Draft            Route Leak Detection              October 2018


   of the solution.  Beside, new extension brings interoperation, device
   upgrade problems.  Thus, extending the routing protocols to do RLD
   should not be the first choice if there can be other options.

   Considering the implementation details, different ISPs may have
   concerns regarding security related data disclosure.  Some BGP
   monitoring tools, such as Looking Glass, not only require third-party
   information to be collected in multiple favorable locations, but also
   have limited knowledge of inter-domain routing status information
   (some ISPs are reluctant to provide some information for
   confidentiality reasons).  This has led to the current BGP monitoring
   tools not being well used by various ISPs.  For this reason, a RLD
   solution should try to avoid reliance on any third party ISP data
   availability.

   Summarizing the above discussions, we have identified the following
   requirements when design a RLD solution:

   Consideration 1: A route security protection scheme that a single
   carrier can deploy.

   Consideration 2: No changes required to control plane protocols
   (e.g., BGP);

   Consideration 3: No reliance on third party ISP information;

4.  BMP Extension for RLD
























Gu & Zhuang              Expires April 25, 2019                 [Page 5]


Internet-Draft            Route Leak Detection              October 2018


                               +--------+
                               | RLD    |
                               | Server |
                               +--|-----+
                                  |
                     *************|***********
                     *  ISP A     |          *
                     *  AS A1     |          *
             AS B1   *            |          *    AS E1
           +-------+ *  +---+     |   +---+  *  +-------+
    ... ---| ISP B |----|R1 |-----+---|R2 |-----| ISP E |--- ...
           +-------+ *  +---+\        +---+  *  +-------+
             AS C1   *   /|   \\    //  |    *    AS F1
           +-------+ * /  |     \\//    |    *  +-------+
    ... ---| ISP C |---   |     //\     |   /---| ISP F |--- ...
           +-------+ *    |   //   \\   |  / *  +-------+
             AS D1   *    |  /       \  | /  *    AS G1
           +-------+ *  +---+         +---+  *  +-------+
    ... ---| ISP D |----|R3 |---------|R4 |-----| ISP G |--- ...
           +-------+ *  +---+         +---+  *  +-------+
                     *                       *
                     *************************

               Figure 2: RLD Server for One ISP

   Considering the above mentioned factors, BMP is a good choice for
   RLD, which has no dependency on third-party ISP, and no extension
   required for routing protocols.  Beside, by collecting information
   using BMP from devices is not an RLD inferring method, which provides
   true validation of ASes' peering business relationships.

   We can use BMP (BGP Monitoring Protocol) to easily monitor BGP
   routes, such as monitoring BGP Adj-RIB-In using the process defined
   in [RFC7854], and monitoring BGP Adj-RIB-Out using the process
   defined in [I-D.ietf-grow-bmp-adj-rib-out].  BMP is a management
   plane protocol and a non-control plane protocol.  Therefore, the use
   of BMP does not impact the processing of BGP protocol, because BMP
   can monitor the BGP protocol after the BGP protocol converges.  This
   document ...

5.  Acknowledgements

   TBD.








Gu & Zhuang              Expires April 25, 2019                 [Page 6]


Internet-Draft            Route Leak Detection              October 2018


6.  IANA Considerations

   TBD.

7.  Security Considerations

   TBD.

8.  References

8.1.  Normative References

   [I-D.ietf-grow-bmp-adj-rib-out]
              Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S.
              Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
              Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-02 (work
              in progress), September 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.

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

8.2.  Informative References

   [Luckie]   "AS Relationships, Customer Cones, and Validation",
              October 2013.

   [Siddiqui]
              "Route Leak Detection Using Real-Time Analytics on local
              BGP Information", 2014.





Gu & Zhuang              Expires April 25, 2019                 [Page 7]


Internet-Draft            Route Leak Detection              October 2018


Authors' Addresses

   Yunan Gu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: guyunan@huawei.com


   Shunwan Zhuang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com

































Gu & Zhuang              Expires April 25, 2019                 [Page 8]


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