BGP was designed in an era when every AS operator was trusted. There's no built-in mechanism to verify that an AS is authorized to advertise a particular prefix, or that the AS-path hasn't been manipulated. This fundamental trust model has led to repeated incidents: accidental route leaks that redirect traffic through the wrong network, and deliberate prefix hijacks that intercept or blackhole traffic for malicious purposes.
Route Leaks
A route leak occurs when an AS advertises routes it learned from one peer or provider to another peer or provider in violation of the intended routing policy. The most common scenario: a customer AS receives full routes from Provider A, then accidentally re-advertises all of them to Provider B (becoming a de facto transit provider).
How It Happens
- Missing outbound filter: The customer doesn't have an outbound prefix-list limiting what they advertise to Provider B
- Route-map misconfiguration: An outbound route-map permits more than intended
- Redistribution gone wrong: BGP routes redistributed into another BGP session without filtering
- Default-originate vs full table: Customer receives full table but was supposed to get only a default
Impact
When a small AS leaks thousands of routes with a short AS-path, remote ASes may prefer the leaked path (shorter AS-path at step 4). Traffic that should traverse the original provider now funnels through the leaking AS, which likely doesn't have the bandwidth to handle it. The result: congestion, packet loss, and potential outage for affected prefixes.
Prefix Hijacking
A prefix hijack occurs when an AS originates a BGP advertisement for IP space it doesn't own. This can be accidental (fat-finger a network command) or deliberate (redirect traffic for interception or disruption).
Types of Hijacks
- Exact-prefix hijack: Attacker advertises the same prefix (/16) as the legitimate owner. Some ASes prefer the hijacked route (shorter AS-path, closer in IGP terms), others keep the legitimate one. Partial impact.
- More-specific hijack: Attacker advertises more-specific prefixes (/24s within a /16). Longest match wins in the forwarding table, so the hijacked /24s always beat the legitimate /16 globally. Full impact.
- AS-path manipulation: Attacker forges the AS-path to make the hijack look legitimate or to bypass AS-path-based loop detection.
Prevention: Your Network
Outbound Filtering (Prevent Yourself from Leaking)
! Only advertise your own prefixes — nothing else
ip prefix-list OUR-SPACE seq 10 permit 10.1.0.0/16
ip prefix-list OUR-SPACE seq 20 permit 10.2.0.0/16
!
router bgp 65001
neighbor 172.16.0.2 prefix-list OUR-SPACE out
neighbor 172.16.0.6 prefix-list OUR-SPACE outThis is the single most important BGP security measure you can take. If every AS filtered outbound correctly, route leaks would be virtually eliminated.
Inbound Filtering (Protect Yourself from Others' Leaks)
! Accept only what your peer should send
ip prefix-list ISP-A-EXPECTED seq 10 permit 100.64.0.0/10 le 24
ip prefix-list ISP-A-EXPECTED seq 900 deny 0.0.0.0/0 le 32
!
! Bogon filtering
ip prefix-list BOGONS seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 30 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 40 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS seq 50 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 60 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 70 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS seq 900 permit 0.0.0.0/0 le 32See BGP Route Filtering with Prefix Lists for detailed filtering examples.
Maximum-Prefix Limits
R1-HQ(config-router)# neighbor 172.16.0.2 maximum-prefix 10000 80 restart 5If the peer sends more than 10,000 prefixes, log a warning at 80%. If the limit is exceeded, tear down the session and restart after 5 minutes. This protects against a peer accidentally dumping their full table to you.
Prevention: Internet-Wide
RPKI (Resource Public Key Infrastructure)
RPKI is the strongest defense against prefix hijacking. It allows prefix owners to cryptographically sign Route Origin Authorizations (ROAs) that declare which ASes are authorized to originate specific prefixes. We cover the full configuration in BGP RPKI and Route Origin Validation on IOS XE.
IRR (Internet Routing Registry)
Register your routes in an IRR database (RADB, ARIN, RIPE). Many transit providers build prefix filters from IRR data. If your routes are registered and your provider filters based on IRR, hijacked routes from unauthorized ASes are blocked.
BGP Community-Based Blackholing
If your prefix is being hijacked, you can advertise a /32 host route with the RTBH (Remotely Triggered Blackhole) community to your upstream. The upstream drops traffic to that specific IP at their edge, limiting the hijack's impact. Common community: provider-ASN:666.
Detection
- BGP monitoring tools: BGPStream, RIPE RIS, RouteViews provide real-time visibility into global BGP announcements. Set up alerts for your prefixes.
- RPKI monitoring: Monitor ROV (Route Origin Validation) status of your prefixes across multiple vantage points.
- Show commands: If you suspect a leak affecting your traffic, check the AS-path for unexpected ASes:
R1-HQ# show ip bgp regexp _65099_
! Look for routes transiting an AS that shouldn't be thereKey Takeaways
- BGP has no built-in origin validation — any AS can advertise any prefix. Route leaks and hijacks are a real and ongoing threat.
- Outbound prefix filtering is the single most effective defense — only advertise your own space.
- Inbound bogon filtering and maximum-prefix limits protect against accidental leaks from peers.
- RPKI with ROAs is the strongest hijack prevention mechanism — cryptographically proves which AS is authorized to originate a prefix.
- Register your routes in IRR databases and monitor your prefix announcements with BGPStream or RIPE RIS for early detection of hijacks.