A BGP announcement can name an origin AS without proving that the holder of the advertised address space authorized that AS to originate the route. Resource Public Key Infrastructure, or RPKI, supplies signed routing objects from which relying parties derive validated authorization data. BGP origin validation compares that data with the route seen by a router.
The check is deliberately narrow. It evaluates the route prefix and origin AS against validated records. It does not authenticate every AS in AS_PATH, prove that the observed path is legitimate, or determine whether export policy was followed.
A ROA expresses origin authorization
RFC 9582 defines the current Route Origin Authorization profile. A ROA is a digitally signed RPKI object through which an IP address block holder authorizes an AS to originate routes for one or more prefixes within that block.
After cryptographic and resource validation, routing systems commonly consume a derived representation called a Validated ROA Payload, or VRP. The fields relevant to origin validation can be represented as:
VRP = {
prefix,
maxLength,
originAS
}prefix identifies the authorized address block. originAS identifies the authorized origin. maxLength limits the length of more-specific route prefixes covered by that authorization.
That last field is security-sensitive. An authorization for 203.0.113.0/24 with a maximum length of /24 does not authorize a /25. A maximum length of /25 can permit /24 and /25 routes covered by the VRP, subject to the origin AS match.
Validation distinguishes coverage from a match
RFC 6811 defines the core classification around whether a VRP covers a route and whether a covering VRP also matches its origin and prefix length constraints.
A compact view is:
no covering VRP
-> NotFound
covering VRP + at least one match
-> Valid
covering VRP + no match
-> InvalidA route is covered when its prefix falls within the VRP prefix at an equal or longer prefix length. A match additionally requires the route prefix length not to exceed the VRP maximum length and the route origin ASN to equal the VRP ASN.
Multiple VRPs may cover the same route. A single matching VRP is sufficient for the Valid state even when another covering VRP does not match. Invalid applies when coverage exists but none of the covering VRPs matches.
NotFound is not the same as Invalid
The distinction between NotFound and Invalid is operationally important. NotFound means the validation data available to the router contains no VRP covering the route prefix. It does not state that the route is authorized or unauthorized.
Invalid carries a different signal. At least one VRP covers the route prefix, but none authorizes the observed combination of prefix length and origin AS. The mismatch can come from the origin ASN, an overly specific prefix, or both.
These states are inputs to local routing policy. RFC 6811 requires implementations to make validation state usable by route policy and does not mandate automatic rejection merely because a route is Invalid. Operators choose the resulting policy, including whether a state affects acceptance or preference.
The authorization data changes over time
RPKI is a distributed system. Repositories, relying-party software, caches, and routers do not all refresh at the same instant. RFC 6811 notes that different caches can temporarily hold different views because retrieval and update timing differ.
A router therefore needs to re-evaluate affected routes when its validated prefix-to-AS data changes. A newly available VRP can turn a previous NotFound route into Valid or Invalid; removal or replacement of authorization data can change the classification again.
This temporal property matters during operational changes. Publishing or modifying a ROA and changing BGP announcements are separate actions whose propagation is not instantaneous. Routing policy that rejects Invalid routes makes coordination of those changes especially consequential for reachability.
Export validation uses the effective origin
Origin validation is not limited to received routes. RFC 8893 specifies RPKI origin validation for BGP export and points out that export processing can alter the origin AS visible in the route.
Operations such as private-AS removal or confederation handling can change the effective origin used for the route being sent. Egress validation therefore has to classify the route after relevant outbound transformations, using the effective origin that the neighbor will receive rather than an earlier internal form.
This is a subtle boundary: validating an inbound representation does not automatically validate a modified outbound representation.
Origin validation does not validate the path
A Valid state makes one constrained statement: validated authorization data permits the observed route prefix and origin AS combination. It does not certify the intermediate AS sequence.
An attacker or misconfiguration can preserve an authorized origin while introducing an incorrect path. A route leak can also retain a legitimate origin while violating an intended propagation relationship. Those cases sit outside the property checked by origin validation.
Other routing-security mechanisms address different surfaces. BGP Roles and the OTC attribute target route-leak propagation policy. Path-validation mechanisms make separate claims again. Treating origin validation as path validation would extend its assurance beyond the data it checks.
Availability depends on both data and policy
RPKI validation adds a trusted-data pipeline to routing decisions: signed objects are retrieved, cryptographically validated, converted into usable payloads, delivered to routing systems, and applied through policy. Failures or stale state at any stage can affect classification.
That does not make origin validation ineffective; it defines its operational boundary. The router’s decision is based on the validated data currently available to it and the policy configured for each state.
The useful security claim remains precise. RPKI origin validation can detect a BGP route whose prefix and origin AS conflict with available validated authorization data. It cannot establish that the entire interdomain path is authentic, policy-compliant, or free from manipulation.