Check if a route is cryptographically valid before it hits the internet

What RPKI validation actually checks, and why it matters

Border Gateway Protocol was never designed with authentication in mind, which is why a single misconfigured router — or a deliberate route hijack — can redirect traffic meant for a bank, a hospital, or a government network to somewhere it was never supposed to go. Resource Public Key Infrastructure closes part of that gap. It lets the holder of an IP prefix cryptographically sign a Route Origin Authorization, or ROA, stating exactly which autonomous system is permitted to originate that prefix, and how specific the announcement is allowed to be. Anyone downstream, including this rpki validator, can then compare a real BGP announcement against the signed record and get one of three answers.

A route is Valid when its origin ASN and prefix length fall within a covering ROA. It is Invalid when a ROA exists for that prefix but the announcing ASN doesn't match, or the announcement is more specific than the ROA's max length allows — both are classic signatures of route leaks or hijacks. When no ROA covers the prefix at all, the result is Unknown, which simply means the space hasn't been signed yet, not that anything is wrong. Tools like Routinator, rpki-client, and the RIPE NCC RPKI Validator run this same comparison continuously inside a network's routing infrastructure, feeding the verdict to routers so they can reject Invalid announcements before they ever reach a forwarding table.

Testing a prefix manually is still useful even if your network already runs a validator, because it lets you confirm a ROA before you rely on it, debug why a new advertisement is being dropped by peers, or check a partner's routing hygiene before signing an interconnect agreement. A typical rpki test only needs two inputs: an origin ASN such as AS15169 and a prefix such as 8.8.8.0/24. Behind the scenes, this checks the same rpki roa records published by ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC, so the verdict here matches what a production validator would return.

If you're publishing your own ROAs for the first time, a few habits keep you out of trouble. Set the max length only as wide as you actually announce — a ROA that's too permissive still lets an attacker originate a more specific sub-prefix and pass validation. Cover every prefix you announce, including any temporary or backup ranges, since an unsigned prefix defaults to Unknown rather than blocking anything. And re-check after any renumbering or ASN change, because a stale ROA turns your own legitimate announcement Invalid the moment it goes out. Used this way, RPKI validation stops being a one-time compliance checkbox and becomes a routine part of keeping BGP announcements honest.