Route Leak Detection and Prevention Mechanisms

Route Leak Detection and Prevention Mechanisms

Route leaks remain one of the most volatile disruptions on the global Internet. Because traditional RPKI ROV does not detect route leaks, the industry has developed architectural standards, automated telemetry systems, and industry self-regulation frameworks to systematically detect and prevent them.

Community-Based Leak Prevention and RFC 9234

Operators have long relied on proprietary BGP communities to tag routes. However, proprietary communities do not cross organizational boundaries: upstream ISP \(A\) strips or ignores customer \(B\)’s internal communities.

To standardize leak prevention across administrative domains, the IETF published RFC 9234: Route Leak Prevention and Detection Using BGP Roles:

+-----------------------------------------------------------+
|               BGP Role Negotiation (RFC 9234)             |
|                                                           |
|  Provider AS                                  Customer AS |
|     Role: Provider <=========================> Role: Customer
|                                                           |
|  - When Provider advertises route to Customer:            |
|    Attaches "Only to Customer" (OTC) Attribute: OTC=Provider_ASN
|                                                           |
|  - When Customer advertises route to another Provider:    |
|    Second Provider inspects OTC attribute:                |
|    "Wait! This route has an OTC set, but I received it    |
|     from a Customer/Peer! This is an illegal leak!"       |
|    --> ROUTE REJECTED AT BORDER!                          |
+-----------------------------------------------------------+

1. Role Negotiation: When establishing a BGP session, peers negotiate their commercial relationship in the OPEN message: Provider, Customer, Peer, or RS-Client.
2. OTC Attribute: When a route moves down a hierarchy (Provider \(\to\) Customer) or laterally across peers (Peer \(\leftrightarrow\) Peer), the router attaches the Only to Customer (OTC) path attribute (Type 35), recording its own ASN.
3. Automatic Leak Rejection: If an upstream router receives a route from a customer or lateral peer that already contains an OTC attribute, it detects an illegal “valley” path and automatically rejects the route, neutralizing the leak in software without requiring complex manual prefix-lists.

Automated Leak Detection via Route Collectors and Monitors

When route leaks occur, real-time monitoring algorithms detect them through anomalous propagation signatures: - Valley-Path Algorithms: Automated telemetry engines inspect the AS_PATH streams received by RIPE RIS and RouteViews. By maintaining a global inferred topology map (customer-provider pairs), algorithms flag any path containing a Customer \(\to\) Provider \(\to\) Customer sequence as a probable route leak. - Traffic Shift Probes: Automated synthetic measurement networks (e.g., RIPE Atlas, ThousandEyes) detect sudden 200ms latency spikes and buffer-bloat jitter on paths that previously converged in 15ms.

BGPsec Route Leak Prevention Potential

While BGPsec (RFC 8205) was designed to protect path integrity by having each AS cryptographically sign its announcement to the next hop, base BGPsec does not inherently prevent route leaks: - In a route leak, the customer legally received the route from Provider \(A\) with a valid cryptographic signature. - The customer appends its own valid signature and passes it to Provider \(B\). - The signature chain is mathematically flawless! - To prevent leaks, cryptographic protocols must incorporate role metadata (such as ASPA or signed OTC attributes) into the signature envelope.

MANRS Principles and Their Implementation Status

The Mutually Agreed Norms for Routing Security (MANRS) is a global, industry-led initiative operated under the Internet Society (ISOC) that establishes a baseline of routing hygiene:

MANRS Action	Technical Requirement	Operational Focus
Action 1: Filtering	Prevent propagation of incorrect routing information	Strict prefix-lists on customer sessions; RPKI ROV enforcement
Action 2: Anti-Spoofing	Prevent traffic with spoofed source IP addresses	Unicast Reverse Path Forwarding (uRPF, RFC 3704) on edge access links
Action 3: Coordination	Facilitate global operational communication	Accurate, maintained contact info in PeeringDB and RIR WHOIS
Action 4: Global Validation	Publicly document routing policy	Publish valid ROAs in RPKI and maintained route/as-set objects in IRR

MANRS participation has become a mandatory procurement requirement for Tier-1 telcos, major cloud operators, and financial enterprises.

Coordination and Incident Response When Leaks Occur

When a severe leak bypasses filters and floods a network: 1. Out-of-Band NOC Communication: Operators contact the leaking network’s 24/7 Network Operations Center (NOC) via phone numbers published in PeeringDB. 2. Session Teardown: If the leaking customer does not answer, the upstream provider immediately executes shutdown on the BGP neighbor session. 3. Emergency Disaggregation: The victim network temporarily announces more-specific /24 subprefixes to reclaim its traffic until the leak converges out of the global DFZ.