BGP Route Leak Protection: Stop Traffic Hijacking with RPKI

BGP route leak protection and RPKI validation are the mechanisms I rely on to stop misrouted or hijacked prefixes from pulling traffic into the wrong AS path. A route leak happens when a network accidentally advertises prefixes it learned from one neighbor back out to another, and without Origin Validation via RPKI, downstream routers have no cryptographic proof the announcement is legitimate. The fix is to deploy Resource Public Key Infrastructure validation, reject invalid ROA-covered prefixes at the edge, and tighten prefix-lists so only expected routes propagate. Here's how I configure this in production.

What Is a BGP Route Leak and Why It Hurts

A route leak is not the same as a full prefix hijack. A hijack is malicious — someone announces a prefix they don't own. A leak is usually accidental: a customer or peer starts advertising routes they received from their upstream to everyone else, and because BGP trusts by default, those routes spread globally.

The damage is real. I've seen incidents where a small ISP in Southeast Asia leaked routes for major CDNs, and traffic from half the internet started flowing through a single 10G link that saturated in minutes. DNS lookups timed out, payment gateways went dark, and nobody noticed until customers started calling.

The classic cases:

• YouTube Pakistan Telecom (2008): Pakistan accidentally leaked a /24 for YouTube globally to block it domestically. Traffic worldwide hit their routers.
• MainOne / Google (2018): A Nigerian ISP leaked routes for Google, Cloudflare, Amazon. Large chunks of the internet redirected through Nigeria for nearly two hours.
• China Telecom (2010, 2019): Multiple leaks where traffic from western networks got pulled through Chinese infrastructure.

Every one of these could have been contained with RPKI Origin Validation.

How RPKI Prevents Route Leaks

RPKI (Resource Public Key Infrastructure) lets a prefix owner cryptographically sign a Route Origin Authorization (ROA). The ROA binds a specific prefix to an Origin AS and specifies the maximum prefix length allowed. When my edge routers receive a BGP announcement, they check the ROA against a local validation cache and mark the route as Valid, Invalid, or NotFound.

• Valid: The origin AS in the BGP update matches the ROA. Accept it.
• Invalid: The origin AS doesn't match, or the prefix length exceeds what the ROA allows. Drop it.
• NotFound: No ROA exists for this prefix. Accept but don't trust blindly.

The key point: rejecting Invalid routes at the edge is what actually stops leaks. If you accept them but assign a lower local-pref, a leak can still attract traffic during path selection. I reject Invalids outright on every external peering session.

As I mentioned before in my VLAN isolation post (https://furkanikkan.com/urun/vlan-yapilandirmasi-ag-trafigini-dogru-sekilde-izole-etme-60), segmentation only works if the enforcement boundary is clean. RPKI is that boundary at the BGP layer.

Setting Up RPKI Validation with FRRouting

I run FRRouting on Linux for several edge routers. Here's the configuration I use to pull a RPKI cache and reject invalid routes.

First, install and start a local RPKI validator. I use Routinator 3000:

# Install Routinator on Debian/Ubuntu
apt install routinator
systemctl enable --now routinator
# It listens on port 3323 for RTR connections

Then configure FRR to use the cache and apply validation:

router bgp 65000
 bgp rpki server 127.0.0.1 port 3323
 neighbor 192.0.2.1 remote-as 64512
 neighbor 192.0.2.1 ebgp-requires-policy
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map RPKI-IN in
 exit-address-family
!
route-map RPKI-IN permit 10
 match rpki invalid
 set local-preference 0
!
route-map RPKI-IN deny 20
 match rpki invalid
!
route-map RPKI-IN permit 30

Note: In FRR 8.4+, you can use bgp rpki policy import reject-invalid for a cleaner one-liner instead of the route-map approach. I still use route-maps on older deployments for consistency.

Cisco IOS-XE RPKI Configuration

For my Cisco edge routers running IOS-XE, the config is straightforward. You point the router at an RPKI cache and then use a route-map to reject invalids:

router bgp 65000
 bgp rpki server tcp 127.0.0.1 port 3323 refresh 300
 neighbor 192.0.2.1 remote-as 64512
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map RPKI-REJECT in
 exit-address-family
!
ip extcommunity-list standard RPKI-INVALID permit rt 65000:0
route-map RPKI-REJECT deny 10
 match extcommunity RPKI-INVALID
route-map RPKI-REJECT permit 20

Prefix-Lists and IRR Filtering: Defense in Depth

RPKI alone won't catch everything. Not every prefix has a ROA published, and NotFound routes still get accepted. I layer IRR (Internet Routing Registry) filtering on top to cover the gaps.

My approach for every external peer:

1. Pull the peer's AS-SET from their IRR record using bgpq4.
2. Generate a prefix-list that allows only the prefixes they're authorized to announce.
3. Apply that prefix-list inbound on the peering session.
4. Refresh the filter daily via cron — AS-SETs change.

Here's a quick example with bgpq4:

bgpq4 -b -4 -l PEER-IN AS-EXAMPLE
# Generates a Bird-format prefix-list you can convert for your platform

Warning: IRR databases themselves can be poisoned. Anyone can register objects in some databases. Always combine IRR with RPKI, never rely on IRR alone.

Monitoring and Alerting for Route Leaks

Even with RPKI and IRR filtering, I want to know immediately if something looks wrong. I monitor for:

• Unexpected route churn: Sudden spikes in BGP updates from a single peer usually mean a leak or a misconfiguration upstream.
• New prefixes from existing peers: If a peer suddenly starts announcing prefixes outside their AS-SET, my filter catches it — but I want an alert, not just a silent drop.
• RPKI cache health: If the cache goes down, my router can't validate. I alert on cache connection failures.

I use bgpstream from CAIDA for real-time monitoring of global routing changes, and a simple Prometheus exporter for per-peer route counts. If a peer's route count jumps by more than 20% in five minutes, I get paged.

As I covered in my MTTD guide (https://furkanikkan.com/urun/veri-ihlalini-ne-kadar-hizli-tespit-edersiniz-mttd-rehberi-57), detection time matters. A route leak detected in 30 seconds is a non-event. Detected in 30 minutes, it's an outage report.

Practical Checklist for RPKI Deployment

If you're starting from scratch, here's the order I recommend:

1. Generate ROAs for your own prefixes through your RIR (RIPE, ARIN, APNIC). This protects you from being leaked by others.
2. Deploy a local RPKI validator — don't rely on your upstream's validation. Routinator or OctoRPKI both work well.
3. Enable RPKI validation on edge routers and start by logging Invalids without dropping them. Watch for false positives.
4. Switch to reject mode after a week of clean logs.
5. Add IRR-based prefix filtering for peers without ROA coverage.
6. Set up monitoring for cache health and route count anomalies.

I went through steps 3 and 4 carefully on my own network. The first week of logging caught three Invalid routes from a transit provider — all were stale announcements from a deprecated AS. No false positives on legitimate traffic. Once I moved to reject mode, the transition was invisible.

Final Thoughts

BGP was designed in an era where trust was assumed. That assumption has caused billions of dollars in outage damage over the past two decades. RPKI isn't perfect — adoption is still growing, and NotFound routes remain a gap — but rejecting Invalid routes at the edge is the single most effective change I've made to harden my BGP infrastructure. If you're still accepting every route your peers send you, you're one misconfiguration away from being part of the next global incident.

Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line