Route Leaks and Policy Abuse

Route Leaks and Policy Abuse

While prefix hijacking involves the illegitimate origination of IP address space, route leaks represent a distinct, highly disruptive class of interdomain routing anomalies. Route leaks violate commercial routing policy agreements, causing traffic to flow through unauthorized networks without changing the authoritative origin ASN.

What Is a Route Leak and How It Differs From Hijacking

Formally defined in RFC 7908, a route leak is: > “The propagation of routing announcement(s) beyond their intended scope. That is, an announcement from an Autonomous System (AS) of a learned BGP route to another AS in violation of the intended rules of the receiver, the sender, and/or one of the preceding ASes in the path.”

The critical distinction between a hijack and a leak:

Characteristic	Origin Hijack	Route Leak
Origin ASN	Illegitimate; changed to attacker’s ASN	Legitimate; original authoritative ASN preserved
AS_PATH	Forged or newly originated (\([AS_{\text{bad}}]\))	Contains valid origin, but path contains an illegal valley
Root Cause	Malicious injection or misorigination	Policy violation / export filter omission
RPKI ROV Defense	Effective (evaluates prefix vs. origin ASN)	Ineffective (origin ASN is valid!)

Because RPKI Route Origin Validation only checks the rightmost (origin) ASN in the AS_PATH, ROV cannot prevent or detect a standard route leak.

The Customer-Concentrator-Provider Leak Pattern

The most damaging and widespread route leak pattern is the Customer-Provider Leak (RFC 7908 Type 1):

       +-----------------------+              +-----------------------+
       | Upstream Transit ISP1 |              | Upstream Transit ISP2 |
       |     (e.g., Level3)    |              |     (e.g., Telia)     |
       +-----------+-----------+              +-----------+-----------+
                   |                                      ^
                   | 1. Sends full routing table          | 3. Illegitimate Leak!
                   |    to Customer AS                    |    Customer exports ISP1
                   v                                      |    routes to ISP2!
       +-----------+--------------------------------------+-----------+
       |                  Multihomed Customer AS                      |
       |                     (Small Enterprise)                       |
       +--------------------------------------------------------------+

1. Multihomed Customer AS purchases transit from ISP1 and ISP2.
2. ISP1 announces a full global routing table (over 900,000 routes) to Customer.
3. Customer accidentally misconfigures its outbound export route-map on its session to ISP2, failing to restrict exports to its own locally originated prefixes.
4. Customer advertises ISP1’s routes to ISP2.
5. In ISP2’s BGP decision process:
   • Routes learned from Customer have a higher LOCAL_PREF (e.g., \(200\), customer route) than routes learned from peers (\(150\)) or other transit providers (\(100\)).
6. ISP2 accepts the leaked routes and directs all traffic destined for those prefixes into Customer’s network!

Accidental vs. Intentional Policy Violations

• Accidental Leaks: Caused by missing outbound prefix-lists, regex typos in BGP community filters, or software crashes during route-map recompilation.
• Intentional / Adversarial Leaks: An adversary intentionally leaks routes to:
  • Force competitor traffic onto saturated links (economic sabotage).
  • Act as a transparent Man-in-the-Middle (MitM) snooping node between two major transit backbones.
  • Exploit asymmetric peering billing structures.

Propagation Patterns and Impact on Reachability

When a route leak occurs: 1. Traffic Funneling: Upstream providers divert petabits of planetary transit traffic through the leaking AS. 2. Buffer Exhaustion and Packet Loss: The leaking network’s edge routers, typically provisioned with 1 Gbps or 10 Gbps uplinks, are instantly overwhelmed by 500+ Gbps of incoming traffic. Queues drop 99.9% of packets. 3. Global Service Collapse: Remote users attempting to reach major cloud providers, CDNs, or financial hubs experience total timeouts.

Prevention Through Policy, Filtering and Community Tags

Mitigating route leaks requires defense in depth:

1. Strict Outbound Prefix Filtering

Every non-transit customer must configure strict outbound export filters that only allow the exact prefixes originated by the organization:

ip prefix-list OWN-PREFIXES permit 198.51.100.0/24
!
route-map EXPORT-TO-TRANSIT permit 10
 match ip address prefix-list OWN-PREFIXES
route-map EXPORT-TO-TRANSIT deny 20

2. BGP Communities for Leak Prevention

Operators use communities to classify routes upon ingress and reject them upon egress: - Tag all routes learned from Transit/Peers with COMMUNITY 65000:TRANSIT. - Drop any route carrying 65000:TRANSIT before advertising to any other Transit/Peer.

3. RFC 9234: Autonomous System Provider Authorization (ASPA) and Only to Customer (OTC)

RFC 9234 defines the Only to Customer (OTC) BGP attribute: - When a provider or peer advertises a route to a customer or lateral peer, it attaches the OTC attribute set to its own ASN. - If a downstream network receives a route with an OTC attribute from a customer or lateral peer, it recognizes an illegal “valley” path and automatically rejects the route.

Detection via Monitoring and Analysis

Route leaks are detected by analyzing AS_PATH patterns across public collectors: - Valley Detection: Identifying sequences in the AS_PATH where a route moves from Customer \(\to\) Provider \(\to\) Customer \(\to\) Provider. - Volume Anomalies: Sudden spikes in prefix count advertised by small stub ASes (e.g., an AS normally originating 3 prefixes suddenly originates 400,000 prefixes).