How to Prevent BGP Route Leaks and Hijacks
A BGP hijack announces someone else's prefix; a leak propagates routes outside the allowed relationship. Defenses: RPKI ROV, IRR filters, max-prefix, peerlock.
Last updated:
You prevent BGP route leaks and hijacks with layered announcement filtering: RPKI-based route origin validation (RFC 6811), prefix and AS-path filters built from IRR data, max-prefix limits, and AS-path protection (peerlock). No single control is enough. A hijack is an unauthorized AS originating someone else's prefix, while a leak is the propagation of otherwise valid routes outside the permitted business relationship (RFC 7908). Real resilience comes only from combining these techniques.
RPKI and route origin validation (ROV)
RPKI (RFC 6480) lets a resource holder sign a ROA (Route Origin Authorization) binding a prefix to an authorized AS number and a maximum prefix length. Routers performing ROV (RFC 6811) classify each route as Valid, Invalid or NotFound. Invalid routes are rejected, which blocks most origin-based hijacks. A validator (such as Routinator or rpki-client) feeds the router over the RTR protocol (RFC 8210).
- Create ROAs for all your own IPv4 and IPv6 prefixes in your RIR's LIR portal (in Europe: RIPE NCC)
- Set maxLength sensibly. Too wide a range makes sub-prefix hijacking easier
- Reject Invalid routes on every eBGP session
- Run at least two independent validators for redundancy
- NotFound does not block a route. Cover that gap with IRR filtering
IRR filtering, max-prefix and AS-path protection
RPKI only validates a route's origin, not the full AS path. So build prefix and AS-path filters from route and route6 objects and as-sets in the IRR databases (such as RADb or RIPE), and generate the lists with tools like bgpq4. A max-prefix limit tears down a session when a neighbor suddenly announces an unnaturally large number of routes, a classic leak symptom. AS-path protection (peerlock) drops routes whose path contains a Tier-1 AS number where it should never appear.
MANRS actions and routing hygiene
MANRS (Mutually Agreed Norms for Routing Security) defines four actions for network operators: filtering (correctness of announced and accepted routes), anti-spoofing (BCP 38 / RFC 2827 and uRPF), coordination (current contact data in PeeringDB and the RIR database), and global validation (publishing ROAs and complete IRR objects). Applying all four at every network edge is now a baseline industry standard.
Secure routing on the AS202520 SkyPass network
AS202520 SkyPass applies these principles on every eBGP session. On IP transit and peering ports we reject RPKI Invalid routes, enforce IRR filters and max-prefix limits, and as a MANRS participant we keep ROAs and PeeringDB records current. Customers connecting through our Warsaw and Wrocław PoPs or via remote access to THINX, TPIX, WRIX, POZIX and 1-IX inherit this protection by default. Our Looking Glass lets you check how your prefixes are seen and validated inside our network.
Frequently asked questions
Does RPKI alone prevent hijacks?
Not fully. RPKI ROV only validates a route's origin (authorized AS and prefix length), so it blocks origin-based hijacks. It does not protect against full AS-path manipulation or leaks. Those require IRR filtering and AS-path protection.
What is the difference between a route leak and a hijack?
A hijack is an unauthorized AS announcing someone else's prefix. A leak (RFC 7908) is propagating otherwise valid routes outside the permitted business relationship, e.g. re-announcing one transit provider's routes to another. Leaks are best caught by filters and max-prefix limits.
How do I set a max-prefix limit?
Set the threshold slightly above the expected number of routes from a neighbor, with headroom for growth. A peering session has a far lower limit than a full transit table (over a million IPv4 routes). Also configure a warning threshold before the session is torn down.
What is peerlock?
Peerlock is an AS-path filtering technique that rejects routes containing Tier-1 AS numbers in positions where they should not appear. It effectively stops leaks where a small network accidentally re-advertises routes between large operators.