TTR Networks

Intermediate · RPKI and Route Origin Validation · section 7 of 8

Limits of ROV, and ASPA

✓ Lab-tested 17 October 2026 on FRR 10.2.1, StayRTR 0.6.4

ROV checks one thing: the origin AS. That makes it very effective against the most common incidents, accidental origin hijacks and fat-fingered more-specifics, and blind to others:

  • Forged-origin hijacks. An attacker puts the legitimate origin at the end of their path. The route validates.
  • Route leaks. Leaked routes keep their real origins, so they are Valid or NotFound. Leaks need IRR prefix filters, peer-locking and RFC 9234 roles (local-role / Only-to-Customer) to catch them.
  • Path manipulation of any kind further up the path.

What's next for routing security

  • ASPA (Autonomous System Provider Authorization). Each AS signs the list of its upstream providers. Routers can then check that an AS_PATH is "valley-free": every hop in the path was actually authorised as a provider. That catches forged-origin hijacks and many leaks. ASPA is still being standardised in the IETF; early implementations exist in validators and in some routing software.
  • BGPsec (RFC 8205). Every AS signs the path as the route passes through it. It is the most complete answer, but it needs every AS on the path to participate and costs significant router CPU, so it is barely deployed.

In the meantime, the defensive layers are: IRR filters for customers, ROV everywhere, max-prefix on every session, RFC 9234 roles, and tight maxLength on your own ROAs.

Diagram: What ROV stops, and what it doesn't — Step through four hijack attempts against a prefix protected by a ROA.
  1. The legitimate announcement. AS64501 originates 203.0.113.0/24. A VRP matches its prefix, length and origin, so it is Valid everywhere.
  2. Origin hijack: stopped. AS64511 originates the same /24 itself. A VRP covers the prefix but none authorises AS64511, so the route is Invalid and dropped.
  3. More-specific hijack: stopped. More-specifics win in forwarding, so attackers prefer them. 203.0.113.0/25 from AS64511 is Invalid twice over: wrong origin, and longer than maxLength 24.
  4. Forged origin: not stopped. AS64511 announces the /24 with the path "64511 64501", pretending to be AS64501's neighbour. The origin looks like AS64501, so the route is Valid. It competes with the real path; it's longer here, but closer to some networks.
  5. Why maxLength matters. Had the ROA said maxLength 25, the attacker could announce a forged-origin /25 that is Valid and more specific, beating the real /24 everywhere. Hence RFC 9319: keep maxLength equal to what you actually announce.
  6. What closes the gap. ASPA lets AS64501 publish a signed list of its real providers. AS64511 isn't on it, so a path showing AS64511 directly upstream of AS64501 can be rejected. BGPsec signs the full path, but sees little deployment.

Check your understanding

Which incident does ROV catch?

  • A customer leaking its other provider's full table to you
  • An attacker announcing your /24 with path "64511 64501" where 64501 is your AS
  • A network accidentally originating a more-specific of your ROA-covered prefix
  • An AS removing other ASes from the path