Step 1
A clean baseline
All three observers receive 203.0.113.0/24 over both providers and pick Provider B's shorter path. Nobody validates anything yet: the RPKI pieces exist, but no router talks to a validator.
The story, in nine steps
The guide is one story: three attacks, and which check stops each one. AS64500 is multihomed and prefers Provider B; it prepends twice towards Provider A, its backup. Three observers receive its prefix over both providers. The screenshots below are the panel at each step.
Step 2
The naive hijack wins
AS666 announces the origin's prefix as its own. Its path, 666, is one hop long against two and four, and nothing else tells the routes apart. The attacker's links turn orange: the observers are using its route.
Without validation, BGP has no way to tell a hijack from the real thing.
Step 3
ROV enters, marking what looks wrong
The origin creates its ROAs in Krill, and the observers deploy origin validation in its safe first form: invalid routes are only marked and demoted. The hijack becomes Invalid with local_pref 10, and Provider B's path is selected again.
Deploying ROV takes three pieces on any router: an RTR session, a test on every route, and an action on the result.
Step 4
The forged path
AS666 now announces 666 64500, writing the real origin at the end of the path. ROV only checks the last AS, so it says Valid, and the forged route wins the tie with Provider B.
Origin validation can't tell two paths apart when the origin is the same.
Step 5
ASPA enters, also marking first
The origin publishes an ASPA object listing only Provider A, and the observers deploy ASPA verification. The forged path becomes Invalid: the hop 64500→666 was never authorized. But so does Provider B's legitimate path, and the observers fall back to the backup.
An ASPA object must list every provider. Forgetting one diverts the origin's own traffic.
Step 6
You forgot a provider
Adding Provider B to the object fixes it: both legitimate paths are Valid again and Provider B is selected, while the forged path stays demoted. The fix reaches the routers through republication and revalidation alone.
Step 7
The peer leaks
A legitimate peer passes the origin's routes, learned over private peering, on to Provider A. Nothing is forged: 64501 64499 64500 is Valid for ROV and Invalid for ASPA, because 64499 is not one of the origin's providers.
In a leak nobody lies about the origin; what's wrong is where the route went. ROV can't see it, ASPA can.
Step 8
Deploying for real: drop
Both checks switch from marking to dropping, the way a production router is configured. The forged and the leaked routes disappear. Provider A's own path is still missing, though: Provider A keeps advertising the leak instead, and no policy on the observers can change that.
Marking only helps while a valid alternative exists. Dropping is what protects the network.
Step 9
Put it away
The peer fixes its export policy and Provider A's own path comes back. The observers stay fully deployed, with ROV and ASPA both dropping.
What caught what
| Attack | AS_PATH | ROV | ASPA |
|---|---|---|---|
| Naive hijack | 666 | catches it | nothing to check |
| Forged path | 666 64500 | fooled | catches it |
| Route leak | 64501 64499 64500 | can't see it | catches it |
