BGP Route Leak Detection and Response

What Is a Route Leak

A BGP route leak occurs when a network operator (AS) re-advertises routes it has received from one neighbor to another neighbor in violation of routing policy. The leaked routes attract traffic that should be flowing through a different path, causing suboptimal routing, congestion, and sometimes outright outages.

BGP routing basics:

BGP (Border Gateway Protocol) is the routing protocol that connects the internet's autonomous systems (ASes) — networks operated by ISPs, cloud providers, CDNs, and enterprises. Each AS advertises the IP prefixes (address ranges) it can reach. Other ASes use these advertisements to decide how to route traffic.

Normal routing policy follows the valley-free rule:

Customer → Provider → Provider → Customer

An AS should not re-advertise a provider's routes to another provider (this would make you a transit AS that you are not paid to be), and should not re-advertise a peer's routes to another peer.

Types of route leaks:

Impact on Internet Traffic

Route leaks range from harmless misrouting to significant internet outages depending on the scale of the leaking AS and the attractiveness of the leaked routes.

Real-world impact timeline:

1. Seconds 0-60 — Route propagates through BGP. BGP convergence is slow (minutes for global propagation).
2. Minutes 1-10 — Traffic begins shifting to the leaked path. If the leaking AS lacks capacity, congestion starts.
3. Minutes 10-60 — If the leaking AS is small, it collapses under unexpected traffic. If large (Google, China Telecom), it may handle the load — traffic is misrouted but not dropped.
4. Resolution — The leaking AS withdraws the routes, the originating AS or upstream providers filter them, or operators manually intervene. BGP re-convergence takes minutes to hours.

Effect on performance:

• Latency increase — Traffic takes a longer path through an unexpected AS
• Packet loss — The leaking AS becomes congested and drops packets
• Complete outage — Small leaking AS becomes overwhelmed

Detection with Looking Glass Tools

Looking glasses provide real-time BGP routing views from major network vantage points. During an incident, they show whether routes are being seen from unexpected ASes.

# Hurricane Electric BGP Toolkit (free, comprehensive)
# https://bgp.he.net/

# Check who is announcing a prefix
curl -s "https://bgp.he.net/net/8.8.8.0%2F24#_peers" | grep -A5 "Origin"

# RIPE RIS Looking Glass
# https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-looking-glass

# Route Views (University of Oregon)
# Telnet to route-views.routeviews.org (no auth required)
telnet route-views.routeviews.org
# At the prompt:
show ip bgp 8.8.8.0/24

# BGPlay — visual BGP history
# https://bgplay.massimo.ufmg.br/bgplay/
# Shows routing changes over time for any prefix

Identifying a route leak with looking glasses:

1. Look up the prefix in question on bgp.he.net.
2. Check the AS paths being advertised. Normal: short paths through Tier-1 providers. Anomaly: paths with unexpected ASes in the middle.
3. Compare the AS path length. A leak often shows unusually long paths or paths through geographically distant networks.

# Normal AS path for 8.8.8.0/24
15169 (Google)

# Leaked path
701 7018 3356 15169   ← Multiple transit providers in path = potentially leaked route

Using RIPE Stat API:

# Query RIPE Stat for routing data
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=8.8.8.0/24" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(json.dumps(d['data'], indent=2))"

# Check announced prefixes for an ASN
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS15169" | \
  python3 -m json.tool | grep "prefix" | head -20

RPKI and ROA Validation

RPKI (Resource Public Key Infrastructure) allows IP address holders to cryptographically sign which ASes are authorized to originate their prefixes. Route Origin Authorizations (ROAs) are these signed records.

# Check if a prefix has a valid ROA
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS15169&prefix=8.8.8.0/24" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d['data']['status'])"
# Returns: valid, invalid, or unknown

# Check RPKI status for multiple prefixes
curl -s "https://rpki-validator.ripe.net/api/v1/validity/AS15169/8.8.8.0/24"

# Bulk validation with routinator (open source RPKI validator)
# Install routinator
sudo apt install routinator
routinator init
routinator server --rtr 127.0.0.1:3323

# Validate against routinator
rtrclient --addr 127.0.0.1 --port 3323 --check AS15169 8.8.8.0/24

RPKI validity states:

ISPs that implement RPKI-based Route Origin Validation (ROV) automatically reject invalid routes. This prevents many route leaks and all origin hijacks. If your ISP does not filter RPKI-invalid routes, traffic may be misrouted even when a valid ROA exists.

Incident Response Steps

If you operate an AS or are affected by a route leak:

As the operator of the affected prefix:

1. Confirm the leak — Use looking glasses to verify your prefix is being seen from unexpected ASes.
2. Identify the leaking AS — The AS in the middle of the path that should not be there.
3. Contact the leaking AS NOC — Use PeeringDB (peeringdb.com) to find NOC contacts. Include: your ASN, the affected prefix, the anomalous AS path you are seeing.
4. Contact your upstream providers — Ask them to filter the leaked routes. They can apply a more specific prefix filter.
5. Publish a ROA if you have not already — This allows RPKI-enabled networks to automatically reject invalid announcements.

# Find NOC contact for an AS
curl -s "https://peeringdb.com/api/net?asn=12345" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d['data'][0].get('noc_email','N/A'))"

As the leaking AS (if you discover you are causing the leak):

1. Immediately withdraw the leaked routes — Apply a route filter or clear the BGP session.
2. Notify affected parties — Proactive communication limits damage to relationships.
3. Root cause analysis — Was it a misconfigured route map? Missing prefix list? A new peering session without proper filters?
4. Apply BCOP (Best Current Operational Practices) — MANRS (Mutually Agreed Norms for Routing Security) guidelines.

Historical Case Studies

2010: China Telecom (AS23724) — 15-minute hijack

China Telecom briefly announced approximately 50,000 prefixes (including US government and military) through a misconfiguration. Traffic from parts of the world was briefly rerouted through China. Root cause: incorrect route redistribution in a network policy change.

2012: Indosat (AS4761) — Indonesian ISP leaks routes

Indosat accidentally announced 3,000 prefixes belonging to Google, Level 3, and others. Traffic destined for these networks in parts of Asia was rerouted through Indonesia. Duration: ~10 minutes.

2019: MainOne (AS37282) — Cloudflare, Facebook, Amazon traffic rerouted through China

A small West African ISP leaked routes to Cloudflare, Facebook, and Amazon. The routes propagated through China Telecom to the global internet. Duration: ~2 hours. Impact: significant degradation of access to these services.

Lessons learned:

1. Route filters (prefix lists, AS-path filters) prevent most leaks.
2. RPKI ROV prevents many leaks automatically when widely deployed.
3. BGP communities can signal routing policy and help neighbors apply appropriate filters.
4. Monitoring with BGPmon, RIPE Stat alerts, or Cloudflare Radar provides early warning.

Prevention Strategies

Operational controls:

# Cisco IOS: Apply inbound prefix list to customer sessions
router bgp 65001
 neighbor 192.0.2.1 prefix-list CUSTOMER-IN in
 neighbor 192.0.2.1 prefix-list CUSTOMER-OUT out

# Limit number of prefixes a customer can advertise (prevents table pollution)
 neighbor 192.0.2.1 maximum-prefix 100 80 warning-only

# Apply the GSHUT community before maintenance (graceful shutdown)
 neighbor 192.0.2.1 send-community

Technical prevention:

1. Prefix lists — Only accept prefixes the customer is authorized to announce (IRR-registered prefixes).
2. AS-path filtering — Accept only paths that start with the customer's ASN.
3. RPKI ROV — Reject RPKI-invalid routes. Major providers including AT&T, Verizon, and Comcast now implement this.
4. IRR registration — Register your routes in an Internet Routing Registry (RIPE, ARIN, RADB) so others can build filters.
5. BGP Monitoring — Subscribe to BGPmon or set up Routinator with alerting to detect anomalous announcements of your prefixes.
6. MANRS participation — Mutually Agreed Norms for Routing Security (manrs.org) is an industry initiative with concrete technical requirements.