BGP announces reachability, but a route advertisement by itself does not prove that the originating Autonomous System is authorized to originate the prefix. Resource Public Key Infrastructure, or RPKI, adds signed resource authorization data that can be converted into records a router uses for origin validation.
The resulting check is deliberately narrow. It compares the route prefix and origin AS with validated ROA payloads, commonly called VRPs. The result can feed routing policy, but it does not authenticate every AS in AS_PATH and does not turn BGP into a path-validation protocol.
ROAs become local validation inputs
A Route Origin Authorization binds IP address resources to an AS that may originate routes for those resources. After an RPKI relying party validates the relevant signed objects, routers can receive VRPs from a local cache.
A VRP carries the prefix, an origin ASN, and a maximum prefix length. Origin validation therefore works on validated data rather than directly treating a received ROA file as router policy.
RFC 6811 defines the core comparison. A VRP covers a route when the route prefix is equal to or more specific than the VRP prefix. A match additionally requires the route prefix length to be no longer than the VRP maximum length and the route origin ASN to equal the VRP ASN.
That distinction makes maxLength security-relevant. A broad value authorizes more-specific announcements down to that length. RFC 9319 recommends limiting that authorization and avoiding maxLength except where operational requirements justify it.
Three states describe the comparison
Origin validation produces three states:
Valid
at least one VRP matches the route
Invalid
at least one VRP covers the route, but none matches it
NotFound
no VRP covers the route prefixInvalid does not mean that a cryptographic signature on the BGP UPDATE failed. It means the route conflicts with the locally available validated origin authorization data: the origin ASN may differ, the announced prefix may be too specific, or both.
NotFound is different again. It means the local VRP set has no covering authorization for that route. It is not equivalent to Invalid, and it is not a positive authorization result.
A route can also be covered by several VRPs. One matching VRP is sufficient for a Valid result even if other covering VRPs do not match.
Validation state and routing policy are separate
The validation algorithm assigns a state; operator policy decides what to do with it. RFC 8481 clarifies that policy must not be applied merely because origin validation is available. Filtering or preference changes require explicit configuration.
Operational guidance in RFC 7115 recommends that Invalid announcements normally not be used, while recognizing that special operational cases can require exceptions. It also distinguishes NotFound from Invalid, which matters during staged deployment and when RPKI data is incomplete or changing.
This separation prevents a useful security signal from silently becoming an undocumented routing decision. It also gives operators room to introduce validation, inspect effects, and then enforce policy appropriate to their network.
RPKI data changes can change route state
RPKI is distributed data. Caches fetch and validate repository content over time, so two caches can temporarily hold different views. RFC 7115 notes this loose synchronization explicitly.
When a validated prefix-to-AS mapping is added, removed, or changed, affected routes need revalidation. A route can therefore move among Valid, Invalid, and NotFound without receiving a new BGP announcement.
That property has practical consequences. Monitoring should distinguish routing changes from validation-data changes, and policy deployment should account for cache health and data freshness. A stale or incomplete local view can alter classification even when the route itself has not changed.
Origin validation does not validate the path
RPKI origin validation checks the AS claiming to originate the prefix. It does not verify that the sequence of autonomous systems in AS_PATH represents an authentic propagation path.
RFC 6811 calls out this boundary directly. An attacker able to construct a route with an authorized origin AS can evade the origin check even if the rest of the path is deceptive. Other mechanisms are required for cryptographic path validation.
This limitation does not make origin validation trivial. Accidental origin mistakes and many forged-origin announcements create exactly the prefix-to-origin mismatch that RPKI can classify. The control is valuable because its claim is specific, not because it solves every BGP security problem.
Export validation has its own origin detail
Origin validation can also be applied to routes sent to neighbors. RFC 8893 specifies an important detail for export policy: validation must consider the effective origin AS after outbound transformations that can change what the neighbor will see.
Operations such as private-AS removal or confederation handling can alter the effective origin. Reusing a classification calculated before those transformations can therefore produce a result for a different route representation.
Ingress and egress checks share the same authorization model, but the route being classified must correspond to the route state at the relevant policy point.
Tight authorization keeps the signal precise
RPKI origin validation is strongest when ROAs express the routing intent that operators actually need. Overly broad prefix-length authorization expands the set of announcements that can receive a Valid result. Missing authorization leaves covered routing intent absent from the local validation data.
A precise deployment therefore combines careful ROA scope, healthy relying-party caches, explicit router policy, and monitoring for state transitions. Each component has a separate job.
The central boundary remains simple: RPKI origin validation answers whether validated resource authorization data permits the observed prefix and origin AS combination. Routing policy acts on that answer. The AS path itself remains outside that claim.