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.
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.
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.
Figure 1 – BGP OPEN Message Sent from Local AS 64502 with Capability BGP Role: Peer
| Local AS Role | Remote AS Role |
|---|---|
| Provider | Customer |
| Customer | Provider |
| RS | RS-Client |
| RS-Client | RS |
| Peer | Peer |
Table 1 – Allowed Pairs of Role Capabilities
Figure 2 – Customer – R1 with two Providers – ISP1 and ISP2
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
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
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.
Figure 3 – BGP Notification Message code 2, subcode 11
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:
Figure 4 – Ingress and Egress Procedures for Processing OTC Attribute Defined by RFC 9234
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.
Figure 5 – Route 100.100.100.0/24 Installed in BGP Table of R1 with OTC 64501 (ISP1 AS Number)
Figure 6 – No Prefix Received from Customer R1
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.