Border Gateway Protocol was designed in an era when the networks exchanging routes largely knew and trusted each other. That assumption no longer holds. Today any autonomous system can announce a route claiming to originate a prefix, and historically its neighbors had no cryptographic way to check whether the claim was true. Route Origin Validation, built on the Resource Public Key Infrastructure (RPKI), is the mechanism the industry adopted to fix that. This article explains what RPKI is, how origin validation works, and how operators are now running that validation on their own infrastructure.
The problem RPKI solves
When a router receives a BGP announcement, it learns that some AS is originating a prefix. Without validation, it accepts that at face value. If an operator misconfigures a filter, or a malicious party deliberately announces address space it does not hold, the false route can spread across the internet and pull traffic away from its rightful destination.
These are not hypothetical failures. In a well-documented 2008 event, a single operator’s more specific announcement for YouTube’s address space leaked worldwide and took the service offline for about two hours. The mechanism was trivial. A more specific prefix was preferred by routers everywhere, and there was nothing in the protocol to say the announcement was unauthorized.
What RPKI actually is
RPKI, standardized in RFC 6480, is a public key infrastructure that ties internet number resources to the organizations that hold them. The core object is the Route Origin Authorization, or ROA. A ROA is a signed statement from the legitimate holder of a prefix that says, in effect, “this prefix may be originated by this AS number, up to this maximum length.”
The five Regional Internet Registries (RIRs) publish the trust anchors used by the RPKI system. Resource holders create Route Origin Authorizations (ROAs) through their RIR, declaring which AS is authorized to originate their prefixes. RPKI validators retrieve these signed objects and cryptographically verify them before routers use the resulting validation state
How Route Origin Validation works
Route Origin Validation, defined in RFC 6811, is what a router does with that information. For each announcement, the router compares the origin AS and prefix length against the set of valid ROAs and assigns one of three states:
- Valid means a ROA authorizes this origin for this prefix.
- Invalid means a ROA exists but the announcement contradicts it, either the wrong origin AS or a prefix more specific than the ROA allows.
- Not Found means no ROA covers this prefix at all.
Operators typically configure their routers to reject Invalid routes while still accepting Valid and Not-found ones. That single policy blocks the most common origin hijacks and fat-finger leaks.
A quick worked example
Suppose your organization holds 203.0.113.0/24 and originates it from AS64500. You publish a ROA authorizing AS64500 to originate 203.0.113.0/24 with a maximum prefix length of /24. Any router performing Route Origin Validation will classify the legitimate announcement as Valid.
Now imagine another network, AS64510, announces 203.0.113.128/25, a more specific prefix within your address space. Without Route Origin Validation, many networks would prefer the more specific route, potentially diverting traffic away from its intended destination. A router performing Route Origin Validation checks the announcement against the published ROA and determines that it is Invalid because the origin AS is not authorized to announce the prefix. In this example, the announcement also exceeds the ROA’s maximum prefix length, reinforcing the Invalid result. If the operator’s routing policy rejects Invalid routes—as many now do—the unauthorized announcement is discarded before it can influence routing decisions.
This illustrates the core value of RPKI: instead of trusting every BGP origin announcement by default, networks can cryptographically verify whether the originating AS has been authorized by the legitimate holder of the IP address space before accepting the route.
Adoption has reached a tipping point
For years the argument against deploying RPKI was that too little of the internet used it to matter. That has changed. By late 2025, more than half of globally visible routes were covered by valid RPKI origin information, and deployment continues to grow steadily. Many large network operators now perform Route Origin Validation and reject Invalid routes as part of their routing policy. Publishing ROAs for your own prefixes and rejecting Invalids at your borders is no longer advanced practice. It is becoming the baseline expectation.
There is a newer piece worth knowing about too: ASPA builds on RPKI by allowing network operators to publish their legitimate provider relationships, making it possible to detect many forms of route leaks that Route Origin Validation alone cannot. ASPA is now transitioning from specification into operational deployment as vendor and ecosystem support continues to expand.
Running validation on your own infrastructure
Configuring your routers to reject Invalids is the enforcement side. The other side is visibility: knowing when an Invalid or otherwise suspicious announcement appears for a prefix you care about, and being able to investigate it with full context. That usually means correlating RPKI status with ownership records, routing history, and live BGP data, which normally live in separate tools.
This is the gap FastNetMon built Netomics to close. It is on-premises routing intelligence that ingests live BGP Monitoring Protocol feeds and joins them with RPKI validation, IRR, WHOIS, RIR and geofeed data, plus ASPA status, in one queryable platform that runs entirely inside the operator’s network. Because it is self-hosted, there are no external rate limits and no routing data leaving your infrastructure, and validation results arrive already attached to the prefixes they describe.
FastNetMon founder Pavel Odintsov described the reasoning behind it: “Internet routing has become critical operational infrastructure, yet many organisations still depend on multiple external services to understand what is happening in their own networks. We built Netomics to give operators complete ownership of their routing intelligence while making it easier to troubleshoot incidents, automate workflows and improve routing security.” The platform was introduced in FastNetMon’s announcement of Netomics this month.
Putting it together
If you operate a network, the practical checklist is short and increasingly non-negotiable. Create ROAs for every prefix you originate so others can validate you. Configure Route Origin Validation on your routers and reject Invalids. And put monitoring in place that shows you, with context and in real time, when an announcement for your address space does not match what you authorized.
RPKI turned routing from pure trust into something verifiable. The remaining work for most teams is making that verification visible in their own operations, on infrastructure they control.
About the author
Pavel Odintsov is the founder of FastNetMon, a network-visibility and DDoS-detection company whose tools are used by ISPs, hosting providers and cloud operators worldwide. He has worked on BGP and large-scale network monitoring for over a decade.
