BGP Route Leak prevention and detection via roles in UPDATE and OPEN Messages – RFC 9234

RFC 9234 introduces a novel mechanism that leverages the BGP Role to prevent and detect route leaks. BGP leaks occur when incorrect routing information is spread through the BGP system, causing unintended traffic redirection. Simply put, it’s akin to a highway sign pointing in the wrong direction, leading traffic to the wrong destination.

Typically, route leaks occur due to misconfigurations or errors made by network operators or Internet Service Providers (ISPs). For instance, as an ISP, a route leak can occur if its customer forgets to create ingress or egresses filters.

BGP leaks are a frequent occurrence in the realm of internet routing. The BGP Stream monitoring service provides a comprehensive view to gain insight into these leaks. For example, between March 17th, 2023, and October 3rd, 2023, the service detected a total of 207 BGP leaks.

Route Leaks Explanation

In a provider-to-customer relationship, the transit provider announces all internet routes to the customer. In contrast, the customer only announces its own prefix or the prefixes of its customers to the provider. BGP leaks occur when the customer advertises a received prefix to another provider or its peer instead of limiting the advertisement to its downstream customers. If this happens, traffic may be routed through unexpected paths, leading to potential delays, congestion, or interception of sensitive data.

Similarly, in a peer-to-peer relationship, when two Autonomous Systems (ASs) exchange routing information, they should only advertise their own prefixes or the prefixes of their customers. It is important that they do not advertise prefixes from their upstream provider to their peers. By doing so, they can avoid potential BGP leaks.

BGP Roles and OTC

RFC 9234 describes a new in-band approach to preventing and detecting route leaks. For this purpose, the RFC defines a new BGP capability, the BGP role, and a new BGP attribute, only-to-customer (OTC).

The BGP Role characterizes the relationship between the eBGP speakers forming a BGP session. A network operator can configure one of the five BGP roles listed below for each eBGP session based on the knowledge of the local AS role. If the Role is configured, the eBGP speaker advertises a BGP Role Capability in the BGP OPEN message during BGP peering establishment. If both eBGP routers implement RFC 9234, they will confirm their BGP roles with each other. This exchange allows the BGP routers to understand the AS relationship between the local and the remote AS.

Figure 1 depicts the BGP OPEN message with optional BGP role capability. A value of 4 indicates that the BGP role Peer is configured on the local router.

If the BGP Role Capability is advertised, and one is also received from the peer, the Roles must correspond to the relationships in Table 1.

Local AS Role	Remote AS Role
Provider	Customer
Customer	Provider
RS	RS-Client
RS-Client	RS
Peer	Peer

Let us illustrate the concept of BGP Roles on the simple network topology shown in Figure 2. ISP1 and ISP2 are the transit providers for Customer (R1). Therefore, we need to configure the Customer role for both BGP neighbors of R1.

R1

router bgp 64502
   no bgp ebgp-requires-policy
   neighbor 192.168.1.1 remote-as 64501
   neighbor 192.168.1.1 local-role customer
   neighbor 192.168.2.1 remote-as 64503
   neighbor 192.168.2.1 local-role customer

ISP1

We must also configure the local-role Provider on both ISP routers for AS 64502.

In addition, we will also configure the “network” statement on ISP1 to announce the route 100.100.100.0/24 to R1. This configuration will allow us to observe how the route is propagated when the OTC attribute is set.

router bgp 64501
    no bgp ebgp-requires-policy
    neighbor 192.168.1.2 remote-as 64502
    neighbor 192.168.1.2 local-role provider

address-family ipv4 unicast
    network 100.100.100.0/24
    exit-address-family

ISP2

router bgp 64503
   no bgp ebgp-requires-policy
   neighbor 192.168.2.2 remote-as 64502
   neighbor 192.168.2.2 local-role provider

What if the roles don’t align with the relationships specified in Table 1? For instance, let’s consider a situation where we modify the local role on R1 from ‘Customer’ to ‘Peer’ for AS64501. In such a scenario, the BGP speaker will reject the connection and send a Role Mismatch Notification (code 2, subcode 11), as depicted in Figure 3. In simple terms, the eBGP speakers cannot establish a peer connection.

BGP Only-to-Customer (OTC) Attribute

When BGP routers have established a session and mutually comprehend the AS relationship between the local and remote AS, the next step is to decide whether a route should be propagated or not.

For this purpose, RFC 9234 defines a new optional transitive Path attribute only-to-customer (OTC). The purpose of this attribute is to enforce that once a route is sent to a Customer, a Peer, or an RS-Client, it will subsequently go only to Customers. The attribute’s value is AS number and does not change during its lifetime.

To detect and prevent route leaks, RFC 9234 defines ingress and egress procedures that apply to the processing of the OTC Attribute on route receipt/advertise, as shown in Figure 4:

Let’s apply this concept to our topology, as shown in Figure 2. Previously, we configured the ISP1 router for the Provider role. As a result, the ISP1 router will send a BGP UPDATE message to R1, which is configured for the Customer role. This message will include the OTC Attribute, 64501, with its AS number 64501.

R1 verifies whether the OTC Attribute is set. Since the route is received from the Provider, it is not considered a route leak. Therefore, R1 installs the route in its BGP table, as depicted in Figure 5.

Since the ISP2 role is Provider, R1 refrains from advertising the route to ISP2 due to the presence of the OTC Attribute. The presence of an OTC 64501 Attribute indicates to R1 that the route is learned from the Provider (or Peer and RS), and it can be advertised only to the R1 customers (with OTC 64501). As shown in Figure 6, the ISP2 router has not received any prefix from R1.

Conclusion

RFC 9234 utilizes BGP roles and OTC attributes to ensure that routes received from a provider or a peer are only propagated to customers. One of the key advantages of this solution is its straightforward configuration. The BGP speaker automatically sets the presence of OTC based on its configured role, eliminating the need for manual configuration. The BGP speaker then determines whether to advertise a prefix or not based on the OTC presence in the BGP Update message.

However, it remains to be seen whether network operators or ISPs will widely adopt this new approach for detecting and preventing route leaks in the future.