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

Document Type Active Internet-Draft (individual)
Last updated 2019-03-11
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                              Y. Gu
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 H. Chen
Expires: September 12, 2019                      China Telecom Co., Ltd.
                                                               S. Zhuang
                                                                  Huawei
                                                          March 11, 2019

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

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 September 12, 2019.

Gu, et al.             Expires September 12, 2019               [Page 1]
Internet-Draft            Route Leak Detection                March 2019

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.  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.  Route Leak Detection Considerations . . . . . . . . . . . . .   4
   4.  Extending BMP for RLD . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   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, et al.             Expires September 12, 2019               [Page 2]
Internet-Draft            Route Leak Detection                March 2019

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, the bussiness relationship between AS2 and AS1 is P2C, and
   P2C between AS1 and AS3, and C2P between AS1 and AS4.  According to
   RFC 7908, for AS1, any route received from the provider AS (i.e., AS2
   here) and then distributed to its provider AS (i.e., AS4) is treated
   as route leak (Type 1 route leak).  Thus, to prevent such case from
   happening, an export policy is configured at ASBR R2 of AS1.  The
   export strategies are meant for the intention that "routes from AS2
   can be sent to AS3, and cannot be sent to AS4."  Routes received from
   AS2 at AS1 (i.e., R1 here) are marked with BGP community attributes
   so that when these routes arrive at any exit ASBR of AS1 (i.e., R2
   here) is filtered by the route leak policy configured at R2 by
   identifying the community attribute attached from R1.  This community
   attribute stands for the peering business relationship between AS2
   and AS1.  Suppose the destination of the route A is AS4, then R2 will
   not distribute Route A to AS4 were the export policies configured
   correctly.

Gu, et al.             Expires September 12, 2019               [Page 3]
Internet-Draft            Route Leak Detection                March 2019

                     *************************
                     *                       *       "Send Route
      Route A        *          AS1         +*+-----> A to AS3"
      +-->           *                     + *      +-----+
      +-----+        *  +---+         +---+  *+P2C+--|AS3 +----+ ...
   +--+ AS2 +---+P2C+*+-+ R1+---------+ R2|  *      +-----+
      +-----+        *  +-+-+\        +---+  *
                     *    |   \\    //  |\   *
                     *    |     \\//    | \  *       "Do not send
                     *    |     //\     |  \+-------> Route A to AS4"
                     *    |   //   \\   |    *      +-----+
                     *    |  /       \  |    *+C2P+--|AS4 +----+ ...
                     *  +-+-+         +-+-+  *      +-----+
                     +--+ R3+---------+ R4|  *
                     *  +---+         +---+  *
                     *                       *
                     *************************

             Figure 1: Route propagatin 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 misconfigured or simply out of date
   considering the changes of bussiness relationships between ASes.  For
   example, the export policies at R2 fails to filter Route A and
   distributes it to AS4, then a route leak happens.  Thus, in addition
   to such route leak prevention methods, there requires a valid
   detection method to detect any occurred leak in a timely manner so
   that the incorrect policies can be identified to avoid further leaks.

3.  Route Leak Detection Considerations

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

   It's straightforward to think of the idea of using a route's AS path
   combined with the business relationship information between ISPs/ASes
   to detect any route leak.  However, there exist implementation
   difficuties.

   First of all, the business relationship information between ISPs/ASes
   is not publicly disclosed due to confidentiality reasons.  Thus, many
   attempts have been made to infer relationships and strategies between
   ASs, however, the accuracy of these techniques is often questioned.
   In particular, the increase in the number of Internet Exchange Points
   (IXPs) and their role in the recent "flattening" of the Internet

Gu, et al.             Expires September 12, 2019               [Page 4]
Internet-Draft            Route Leak Detection                March 2019

   topology, makes that a large fraction of AS relationships cannot be
   discovered using these data collection points [Siddiqui].

   Secondly, the acquisition of BGP AS path information is also no easy
   work.  Some BGP monitoring tools, such as Looking Glass and Route
   View, the data accuracy or completeness remains to be an issue.  This
   has led to the such BGP monitoring tools not being well used by
   various ISPs.

   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 of the
   solution.  Besides, new extension brings interoperation, device
   upgrade issues.  Thus, extending the routing protocols is not the
   first choice for leak detection if there are other options.

   Summarizing the above discussions, we have identified the following
   considerations when designing a RLD solution:

   o  Consideration 1: The detection should not depend on inferred
      business relationship information, which leads to inaccurate
      detection;

   o  Consideration 2: The detection should not depend on inaccurate/
      incomplete AS path information , which leads to inaccurate
      detection or a detection miss;

   o  Consideration 3: The detection should try to avoid extension works
      of routing protocols considering the interoperation issues;

   BMP (BGP Monitoring Protocol) is currently deployed by OTT and
   operators to monitor the 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].
   Considering the above mentioned requirements of RLD design, extending
   BMP to collect the business relationships between an ISP and its
   neighboring ASes can be a good choice for this single ISP to do RLD.
   There are several merits:

   o  First of all, it does not involve data disclosure issue since the
      collected relationship information is only between itself and its
      neighboring ASes;

   o  Secondly, BMP provides accurate and complete BGP data monitoring
      within a singe AS;

   o  Thirdly, it does not require BGP extension work, and thus no
      interoperation concern.

Gu, et al.             Expires September 12, 2019               [Page 5]
Internet-Draft            Route Leak Detection                March 2019

   Thus, a single ISP can deploy this method to do RLD without relying
   on any other information from either other ISPs or third party tools.

4.  Extending BMP for RLD

                              +------------+
                              | BMP server |
                       +------>      +     +<-------+
                       |      | RLD ser^er |        |
                       +      +------------+        +
               BMP RM adj_rib_in:              BMP RM adj_rib_out:
               relationship between            relationship between
               AS2 and AS1                     AS1 and AS4
                       |                            +
                    ***|*********************       |
                    *  |                    *       |   "Send Route
     Route A        *  |       A 1         +*+---------> A to AS3"
     +-->           *  |                  + *       |  +-----+
     +-----+        *  +---+         +---+  *+P2C+-----+ AS3 +----+ ...
  +--+ AS2 +---+P2C+*+-+ R1+---------+ R2|  *       |  +-----+
     +-----+        *  +-+-+\        +---+  *       |
                    *    |   \\    //  |\   *       |
                    *    |     \\//    | \  *       |   "Do not send
                    *    |     //\     |  \+-----------> Route A to AS4"
                    *    |   //   \\   |    *       |  +-----+
                    *    |  /       \  |    *+C2P+-----+ AS4 +----+ ...
                    *  +-+-+         +-+-+  *       |  +-----+
                    +--+ R3+---------+ R4+----------+
                    *  +---+         +---+  *
                    *                       *
                    *************************

              Figure 2: RLD depolyment by a single ISP

   A Relationship TLV is defined for BMP Route Monitoring Message.
   Considering that the AS relationships are sometims per route based
   instead of per peer/AS based, this TLV is added at the end of each
   BGP Update Message, and then wrapped up by the BMP per peer header
   and comon header.  The TLV format is defined as follows:

          +-------------------------------+
          |      Type     |    Value      |
          +-------------------------------+

            Figure 3: Relationship TLV

Gu, et al.             Expires September 12, 2019               [Page 6]
Internet-Draft            Route Leak Detection                March 2019

   Type = TBD, the Relatiship TLV indicates that this TLV represents the
   business relationship between the AS that sends the route and the AS
   that receives the route.

   The Value field is a 2 bit field, and can be "00", "01", and "10",
   which represents three types of relationships, i.e., P2C, P2P, C2P,
   respectively.

   As shown in Figure 2, with the Relationship TLV attached to each
   Route Monitoring Message, the RLD server (also working as the BMP
   server) combines the BMP adj_rib_in message collected from R1 and the
   BMP adj_rib_out message collected from R4 to decide if there's a
   route leak.  For example, if the Relationship TLV in R1's adj_rib_in
   message indicates a value of "00", and the Relationship TLV in R4's
   adj_rib_out message indicates a value of "10", then the RLD server
   knows there exists a route leak.

5.  Acknowledgements

   TBD.

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

Gu, et al.             Expires September 12, 2019               [Page 7]
Internet-Draft            Route Leak Detection                March 2019

   [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]   claffy, M. L. M. L. A. D. V. G. K., "AS Relationships,
              Customer Cones, and Validation", October 2013.

   [Siddiqui]
              Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak
              Detection Using Real-Time Analytics on local BGP
              Information", 2014.

Authors' Addresses

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

   Email: guyunan@huawei.com

   Huanan Chen
   China Telecom Co., Ltd.
   109 Zhongshan W Ave
   Guangzhou  510630
   China

   Email: chenhn8.gd@chinatelecom.cn

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

   Email: zhuangshunwan@huawei.com

Gu, et al.             Expires September 12, 2019               [Page 8]