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

Abstract

According to 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) 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.

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.

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

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

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.

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

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

6. IANA Considerations

TBD.

7. Security Considerations

TBD.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses