Lion Cipher Lab

Validate BGP route origins with RPKI (stop route hijacks with ROAs and ROV)

• Cyber / Security Engineer
• Advanced
• ~75 min
• Free · no account required

Why it matters

Every other defence you build -- firewalls, segmentation, TLS -- assumes your packets actually reach the network you intended. BGP, the protocol that steers traffic between networks across the whole internet, was designed with no way to prove that the AS announcing a block of addresses is allowed to. Any autonomous system can stand up and announce any prefix, and by default its neighbours believe it. That single gap is the root of route hijacking: sometimes an accident (an operator leaks a more-specific prefix and unintentionally black-holes a chunk of a big provider), sometimes deliberate…

What you'll learn

• why BGP has no built-in origin authentication -- any autonomous system can announce any prefix, which is the root cause of both accidental and malicious route hijacks
• the RPKI trust model in plain terms: the five RIRs as trust anchors, CA certificates beneath them, and ROAs (signed statements that AS X may originate prefix P up to a maxLength L)
• running a real relying-party validator (NLnet Labs Routinator): initialising the trust anchor locators, serving validated ROA payloads (VRPs) over the RPKI-to-Router (RTR) feed, and reading them with routinator vrps
• seeding your own authorizations locally with a SLURM exceptions file so the lesson is reproducible without owning a real ASN or touching the global routing table
• wiring a validating router (FRRouting) to the validator over RTR and confirming the cache connection and prefix-table
• turning the three RFC 6811 origin-validation states -- valid, invalid, notfound -- into an enforced policy with a route-map that keeps valid + notfound and drops invalid
• proving it end to end with two of your own ASes: a matching announce is VALID and kept, a wrong-origin hijack of the same prefix is INVALID and dropped, and a prefix with no ROA is NOTFOUND and still accepted
• demonstrating the maxLength trap (RFC 9319): a too-loose maxLength lets a more-specific sub-prefix hijack ride in as VALID, and tightening it flips the same announce to INVALID
• the judgment: RPKI only CLASSIFIES so you must write the drop policy; ROV validates ORIGIN only, not the AS-path (so path spoofing survives -- why BGPsec/ASPA exist); and notfound dominance means combine ROV with prefix filters, IRR, and the MANRS actions

Steps in this lab

1. The threat: BGP believes whoever speaks up
2. The defence: the RPKI trust chain, ROAs, VRPs, RTR, and ROV
3. Lay out the lab: one validator, three routers, no real internet
4. Seed your own ROAs (SLURM) and run Routinator
5. Wire the validating router (FRR) to Routinator over RTR
6. Announce a legit prefix (VALID) and an unsigned one (NOTFOUND)
7. Write the policy: RPKI classifies, YOU decide (the route-map)
8. Launch the hijack: same prefix, wrong origin (INVALID, dropped)
9. The maxLength trap: how a loose ROA re-opens the door
10. The judgment: what ROV does not do, and how to do routing security right

Open the full interactive lab →