Internet-Draft Route Leak Detection March 2024
Gu, et al. Expires 4 September 2024 [Page]
Network Working Group
Intended Status:
Standards Track
Y. Gu
H. Chen
China Telecom Co., Ltd.
D. Ma
N. Geng
S. Zhuang

BMP for BGP Route Leak Detection


According to Route-Leak Problem Definition [RFC7908], Route leaks refer to the 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 prevent the happening of BGP [RFC4271] route leaks. However, the real-time route leak detection if any occurs is important as well, and serves as the basis for leak mitigation. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks at the prefix level.

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

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 4 September 2024.

Table of Contents

1. Terminology

BMP: BGP Monitoring Protocol

BMS: BGP Monitoring Station

C2P: Customer to Provider

ISP: Internet Service Provider

P2C: Provider to Customer

P2P: Peer to Peer

RIB: Routing Information Base

RLP: Route Leak Protection

RLD: Route Leak Detection

2. Introduction

RFC7908 [RFC7908] 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, routing 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 transit provider for traffic sent between the two ASes. In return, the customer gains access to the ASes that the transit provider can reach, including those which the transit provider reaches through its own transit providers. In a P2P relationship, the peering ASes gain access to each other's customers, typically without either AS paying the other AS Relationships, Customer Cones, and Validation [Luckie].

More precisely, the route leaks we discuss in this draft, referring to Type 1, 2, 3, and 4 Route Leaks defined in RFC7908 [RFC7908], can be summarized as: a route leak occurs when a route received from a transit provider or a lateral peer is propagated to another transit provider or a lateral peer.

2.1. Actions Against Route Leaks

There are several types of approaches against route leak from different perspectives. In this draft, we mainly discuss the following three types:

The above mentioned actions can be used alone or in combination, depending on the entities (routing devices, network manager) that execute the actions, and the relative positions of the executing entities from the leaking point (local or downstream).

2.2. Challenges of the Current Actions against Route Leaks

Route Leak Prevention [I-D.ietf-idr-bgp-open-policy] updates the BGP Open negotiation process with a new BGP capability to exchange the BGP Roles between two BGP speakers, and also proposes to use a new BGP attribute, called the iOTC (Internal Only To Customer) Path attribute to mark routes according to the BGP Roles established in Open Message. The iOTC attribute of the incoming route is set at the ingress node of the local AS, and is conveyed with the BGP Update to the egress node of the local AS for outbound filtering to prevent route leaks in the local AS. This attribute is removed at the egress node before the BGP Update is sent to eBGP neighbors. For representation simplification, we use iOTC to refer to the method specified in Route Leak Prevention [I-D.ietf-idr-bgp-open-policy].

Route-Leak Detection and Mitigation [I-D.ietf-grow-route-leak-detection-mitigation] describes a route leak detection and mitigation solution based on conveying route-leak protection (RLP) information in a well-known transitive BGP community, called the RLP community. The RLP community helps with detection and mitigation of route leaks that happen at the upstream AS (per the BGP routes propagation), as an Inter-AS solution. For representation simplification, we use RLP to refer to the method specified in Route-Leak Detection and Mitigation [I-D.ietf-grow-route-leak-detection-mitigation].

The above two drafts provide solutions for route leak prevention, detection and mitigation. To summarize:

Thus, there lacks method for local AS route leak detection.

3. Route Leak Detection (RLD) Design Considerations

Considering the challenges facing the existing approaches, this draft proposes a method called Route Leak Detection (RLD). It utilizes the BGP Monitoring Protocol (BMP) to convey the RLD information from to the BMP server to realize centralized leak detection. BMP is currently deployed by OTT and carriers to monitor the BGP routes, such as monitoring BGP Adj-RIB-In using the process defined in RFC7854 [RFC7854], and monitoring BGP Adj-RIB-Out using the process defined in RFC8671 [RFC8671]. On the other hand, the RLD information is in fact a representation of the business relationships between the local AS and its neighboring AS. It does not involve any information disclosure issue regarding third parties. Thus, a single ISP can deploy RLD without relying on any information from either other ISPs or other third parties.

4. BMP Support for RLD

4.1. RLD TLV Format

A RLD TLV is defined for the BMP Route Monitoring Message. Considering that the AS relationships are sometimes per route based instead of per peer/AS based, this TLV is appended to each route, following the BGP Update Message. The order of placing the RLD TLV among other BMP supported TLVs is out of the scope of this draft. The TLV format is defined as follows:

 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
|      Type (2 octets)          |     Length (2 octets)         |
| Value(1 octet)|

                       Figure 1: RLD TLV
| Value | Business    |
|       | Relationship|
|   0   |  P2C        |
|   1   |  C2P        |
|   2   |  P2P        |
|   3   |  I2I        |

Table 1: Business relationship value

4.2. RLD TLV Usage

The RLD TLV, presenting the business relationship between the neighbor AS and the local AS of the incoming route, SHOULD be prepended to the Adj-RIB-In at the ingress node of the local AS. The RLD TLV, representing the business relationship between the local AS and the neighbor AS of the outgoing route, SHOULD also be prepended to the Adj-RIB-Out at the egress node of the local AS. The BMP server, by analyzing the above two RLD TLVs of the same route, can use the rules defined in RFC7908 [RFC7908] to detect the existence of any route leak. As example is shown in Figure 2.

                            | BMP server |
                     +------>      +     +<-------+
                     |      | RLD server |        |
                     +      +------------+        +
             BMP Adj_RIB_In:                 BMP Adj_RIB_Out:
             (AS2 --> AS1)                   (AS1 --> AS4)
              P2C                            C2P
                     |                            +
                  ***|*********************       |
                  *  |                    *     "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 2: RLD depolyment by a single ISP

As shown in Figure 2, with the RLD 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 RLD TLV in R1's Adj_RIB_In message indicates a value of "0", and the RLD TLV in R4's Adj_RIB_Out message indicates a value of "1", then the RLD server knows there exists a route leak.

4.3. Coordination with iOTC and RLP

RLD can be used as a complementary method to the existing methods against route leaks. More specifically, RLD can coordination with both iOTC and RLP.

5. Acknowledgements

6. Contributors

Haibo Wang



7. IANA Considerations

This document defines the following new BMP Route Monitoring message TLV type (Section 4.1):

8. Security Considerations

It is not believed that this document adds any additional security considerations.

9. References

9.1. Normative References

Sriram, K. and A. Azimov, "Methods for Detection and Mitigation of BGP Route Leaks", Work in Progress, Internet-Draft, draft-ietf-grow-route-leak-detection-mitigation-10, , <>.
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-open-policy-24, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <>.
Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <>.
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, , <>.
Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, , <>.

9.2. Informative References

claffy, M. L. M. L. A. D. V. G. K., "AS Relationships, Customer Cones, and Validation", .
Ramirez, M. S. S. D. M. M. Y. R. S. X. M. W., "Route Leak Detection Using Real-Time Analytics on local BGP Information", .

Authors' Addresses

Yunan Gu
Huawei Bld., No.156 Beiqing Rd.
Huanan Chen
China Telecom Co., Ltd.
109 Zhongshan W Ave
Di Ma
4 South 4th St. Zhongguancun
Nan Geng
Huawei Bld., No.156 Beiqing Rd.
Shunwan Zhuang
Huawei Bld., No.156 Beiqing Rd.