RPKI Explained: Who Is Allowed to Announce Your IP Addresses?

By Editorial Team Published Nov 4, 2026 8 min read

Miniature city on a network map beside a metal stamp and a glass card carrying a matching copper authorization seal.

Imagine someone installing a convincing road sign that sends visitors to your business down the wrong street. Your building is intact. Your name has not changed. The directions have become the problem.

Something similar can happen on the Internet. A network can announce a route to addresses it is not authorized to originate, whether through a configuration mistake or deliberate interference. Other networks may then steer traffic toward the wrong place.

Resource Public Key Infrastructure (RPKI) gives routing systems a way to check an important claim: is the announced origin network authorized to originate this IP prefix?

It is a powerful improvement to the Internet’s signposts. Understanding exactly what it checks is the key to understanding what it protects.

First, What Does a BGP Announcement Claim?

The Internet connects independently operated networks called autonomous systems. Each has an Autonomous System Number, or ASN. BGP exchanges reachability information between these networks, including destination prefixes and path attributes. [1]

A prefix identifies a block of addresses, such as 198.51.100.0/24. An announcement associates that prefix with routing information, including an origin AS derived from the AS_PATH attribute. The immediate neighbor sending the announcement may be a transit network rather than the origin itself.

That origin is the AS claiming to originate the route. It is a different concept from BGP’s separately named ORIGIN attribute.

Our BGP overview introduces the surrounding protocol. The security question here is narrower than choosing the best route: who is authorized to originate this destination?

What Does RPKI Add?

RPKI provides a certificate infrastructure tied to Internet number resources. Its hierarchy follows resource allocation and delegation, allowing verifiable authorizations to be grounded in control of address space. This is different from using a website certificate to authenticate a domain name. [2]

For route origin validation, the crucial signed object is a Route Origin Authorization (ROA). An address holder uses it to authorize an AS to originate specified prefixes. A ROA identifies one origin ASN and can contain multiple prefixes, each with an optional maximum prefix length. [3]

That authorization is published separately from BGP. It does not create the route, advertise it on your behalf, or sign every BGP UPDATE. Think of a verifiable permit that another network can compare with the claim on the signpost.

From a Signed ROA to a Router’s Decision

There are two streams of information: BGP tells a router about routes, while RPKI supplies authorization data against which their origins can be checked.

In a typical deployment:

The resource holder publishes ROAs through its RPKI certification and publication arrangements.
Relying-party software, often called a validator, checks the RPKI objects against configured trust anchors and the relevant certificate chains. Successful validation produces a usable set of authorization data.
The router receives validated payloads, commonly through RPKI-to-Router, or RPKI-RTR. A payload includes a prefix, an authorized origin ASN, and a maximum prefix length.
Route Origin Validation (ROV) compares a route with that data. The operator’s routing policy decides what to do with the resulting state.

These compact records are commonly called Validated ROA Payloads (VRPs). The validator handles the certificate and signature work; the router can then perform route-origin checks against the resulting data. It is not fetching a certificate from a distant registry for every packet. [4, 10]

Valid, Invalid, and NotFound

ROV has three outcomes. The distinction between “not authorized by the available data” and “no covering authorization data” matters enormously. [5]

State	What the comparison establishes
Valid	At least one covering VRP matches the announced origin ASN and permits the announced prefix length.
Invalid	At least one VRP covers the route’s prefix, but none authorizes that combination of origin ASN and prefix length.
NotFound	No VRP in the available validation data covers the route’s prefix.

Here, “covers” means that the route’s address block is equal to, or contained within, the VRP’s block.

Invalid does not prove an attack. A stale authorization or an incorrect prefix-length setting can produce that state. NotFound does not certify safety or wrongdoing. It says that this comparison has no covering authorization to work with.

A Small Example With a Surprisingly Important Slash

Assume a router has exactly one VRP relevant to our examples:

Prefix:       198.51.100.0/24
Origin ASN:   AS64496
Maximum length: 24

The addresses and ASNs here are reserved for documentation under RFC 5737 and RFC 5398. These are hypothetical announcements, not live routes to test.

Announced prefix	Announced origin	ROV result	Reason
`198.51.100.0/24`	AS64496	Valid	Prefix, ASN, and allowed length match.
`198.51.100.0/24`	AS64497	Invalid	The prefix is covered, but this origin ASN is not authorized.
`198.51.100.128/25`	AS64496	Invalid	The origin matches, but `/25` exceeds the allowed maximum length of 24.
`203.0.113.0/24`	AS64496	NotFound	Our assumed dataset contains no covering VRP for this different block.

The /25 identifies a smaller block inside the /24: more prefix bits describe a more specific destination. It is not automatically authorized merely because the containing /24 is authorized.

The displayed maximum length is part of the normalized VRP representation. In a ROA that authorizes only the exact prefix, the optional maxLength field can be omitted. [3]

These are ROV classifications, not promises that every peer will accept the routes under its other filters.

Now add an authorization for 198.51.100.128/25 from AS64496. The previously Invalid /25 can become Valid. One matching VRP is enough; a broader record that does not permit /25 does not overrule the matching authorization. There is no “most restrictive ROA wins” rule. [5]

The maxLength Trap: More Permission Than You Intended

Suppose you only announce the /24, but authorize that AS to originate every subprefix down to /32. You have created permissions for many announcements you do not actually use.

Why care? Origin validation does not establish that the AS_PATH is truthful. An attacker can forge an authorized ASN into the claimed origin. Broad permissions for unused, more-specific prefixes can therefore increase the opportunity for forged-origin hijacks that still pass ROV. [7]

RFC 9319 recommends minimal ROAs wherever possible: authorize the prefixes actually originated, with carefully considered exceptions. Treat maxLength as permission, not as a harmless compatibility setting.

There is a second operational trap. Publishing an authorization for a large block can make previously NotFound customer announcements inside it become Invalid if their actual origins lack matching authorizations. Inventory the legitimate announcements before introducing a covering authorization. [8]

Creating ROAs and Filtering Routes Are Two Separate Jobs

Publishing ROAs tells participating networks what you authorize. Running a validator and applying ROV-based policy helps your network evaluate the routes it receives. Doing one does not automatically accomplish the other.

The distinction also applies inside a router: classification is not enforcement. RFC 8481 explicitly separates setting a validation state from applying operator-configured policy. A router can know a route is Invalid while a permissive policy still accepts it. [6]

A defensive deployment normally rejects Invalid routes after the operator has checked its data and policy. NotFound requires separate treatment; treating it as Invalid can discard routes simply because no covering authorization is available. [8]

RPKI also does not replace your other filters, customer-prefix controls, or route-selection policy. A route can pass origin validation and still be unacceptable for another reason.

What RPKI Origin Validation Does Not Prove

A Valid result has a precise scope. It does not certify the complete AS_PATH, authenticate every intermediate network’s routing behavior, or guarantee that the destination service is healthy. Origin validation alone remains vulnerable to forged-origin claims. [8]

It also does not stop every route leak. A network can propagate a route beyond its intended scope while preserving the legitimate origin ASN. That route may remain ROV Valid: its origin authorization says nothing about whether this particular transit or export relationship was appropriate. RFC 7908 describes the route-leak problem and its different forms. [9]

Finally, ROV operates on routing information. It does not encrypt application traffic, inspect its contents, or replace TLS and other application-security controls.

The useful interpretation of Valid is therefore “this origin and prefix length match an available authorization,” not “everything about this route is trustworthy.”

What About Anycast and Multiple Origins?

Our anycast explainer shows why the same service address can be reachable through several locations. That is not inherently suspicious.

A ROA authorizes an ASN to originate prefixes; it does not enumerate every data center where that AS operates. Multiple locations using the same authorized origin can fit the same authorization. If a deployment legitimately uses different origin ASNs, the authorization set needs to accommodate those origins. Separate ROAs can authorize different ASNs for the same prefix. [2, 3]

RPKI is checking permission to originate, rather than insisting that every destination have one physical entrance.

A Practical Deployment Sequence

For a network operator, the concept becomes useful through coordinated operations:

Inventory actual origins and prefixes. Include customers, planned traffic engineering, anycast arrangements, and authorized mitigation services.
Publish appropriately scoped ROAs. Ensure every legitimate announced combination has a matching authorization; avoid opening unused ranges of more-specific permissions merely for convenience.
Operate reliable validation infrastructure. Monitor retrieval, validation health, data freshness, and the connection between validators and routers.
Observe before enforcing. Compare expected states with real announcements, investigate discrepancies, and then apply the intended rejection policy with a recovery plan.
Coordinate routing changes with authorization changes. Check that the new authorization is visible in the relevant validation systems before depending on it, and remove obsolete permissions when the transition is complete.

RPKI is distributed infrastructure with caches. Different validators and routers can temporarily see different data, and publication is not an instantaneous global switch. An alert should distinguish a genuine authorization mismatch from a data-availability or freshness problem. [4, 7, 8]

A Better Answer to “Why Should I Believe This Route?”

Internet routing depends on networks exchanging claims about how destinations can be reached. RPKI makes one of those claims checkable against a signed authorization grounded in Internet number resources.

It does not make every signpost honest. It gives operators a concrete reason to reject many that contradict the published permissions—and a clearer understanding of what the remaining signs still do not prove.

References and Further Reading

Network Encyclopedia Editorial Team

Every entry is written, reviewed and kept up to date by our editors. Spotted a mistake? We fix it in the open.

Editorial Mission · Correction Policy · Suggest a correction