Border Gateway Protocol carries the routes that decide where Internet traffic goes, but the protocol itself does not prove that an autonomous system is authorized to announce a prefix. A router can accept a plausible route even when the origin is wrong. Resource Public Key Infrastructure, or RPKI, gives operators a way to attach signed origin information to address space and reject announcements that contradict it.
The result is not a complete routing security system. It is a narrow, useful check on one part of a BGP announcement. Teams that understand that boundary can deploy it without overstating what it protects.
What origin validation checks
An address-space holder creates a Route Origin Authorization, or ROA, that associates a prefix with one or more autonomous system numbers and a maximum prefix length. Validators collect these signed objects and produce a validation state for each learned route. RFC 6811 defines the process: a route whose origin and prefix length fit a covering ROA is valid; a route with no covering ROA is not found; and a route that conflicts with a covering ROA is invalid.
That distinction matters in operations. Most prefixes will initially be not found because only some address holders publish ROAs. An invalid result, by contrast, means the router has evidence that the announcement conflicts with an authorization for the same address space. Operators can set policy to prefer valid routes and deprioritize or reject invalid ones, while keeping not-found routes available.
The check applies to the origin AS, not the entire AS path. An attacker who can influence the path can still create problems, and an authorized origin can still announce a route for the wrong operational reason. RPKI origin validation reduces a class of accidental and malicious origin mistakes; it does not authenticate every hop, detect every route leak, or replace prefix filtering.
Build the data path before changing policy
The first production decision is where validation happens. A router may receive validated data from an RPKI-to-Router server, while an external validator or route collector may be used for observation. This creates two distinct operational paths: the evidence path that produces validation states, and the policy path that changes route preference or acceptance.
Teams should monitor both. If the validator loses its cache or cannot refresh, routes may become not found even though the underlying ROAs have not changed. A router that treats not found as invalid would then create an outage from a data-plane independence failure. RFC 8481 calls out clarifications needed for consistent interpretation of origin validation, including the difference between a route that lacks validation data and one that has been evaluated as not found.
Start in observation mode. Compare validation states across routers and address families, record disagreements, and trace them back to the validator and the exact ROA set. Alert on changes in the population of valid, not found, and invalid routes rather than only on a single invalid event. A sudden shift across many prefixes often points to a validator, transport, or policy problem.
Write policy that fails predictably
There is no universal policy for invalid routes. Some networks drop them, while others lower local preference or use them only as a signal. The choice should depend on the network's tolerance for reachability loss, the quality of the validation feed, and the ability to respond out of band.
For invalid routes, document the action, the exception process, and the rollback. A route that is invalid because of a stale or malformed ROA should not force an operator to disable validation globally. Provide a controlled way to override a single route or prefix and require a second person to approve it.
For valid and not-found routes, check that policy does not accidentally turn validation into a hidden default route. The not-found state is expected in a partly deployed RPKI ecosystem. Treating it as a rejection signal turns incomplete adoption into an availability incident.
Test the behavior with signed ROAs for lab prefixes and with deliberately contradictory announcements. Confirm what the router logs, what the monitoring sees, and how quickly a policy change takes effect. A validation implementation that is visible only in a vendor dashboard is difficult to debug during a routing event.
Connect route evidence to change control
RPKI changes when address assignments, peering relationships, and provider responsibilities change. A ROA that is correct after a transfer may become stale when a customer moves to a new AS. An automated validator will report the resulting invalid or not-found state, but someone must connect that signal to the organization that controls the prefix.
Maintain an inventory that maps prefixes to business owners, authorized origin AS numbers, and the provider or routing team that can change them. When monitoring reports an invalid route, the response should identify the announcement source and the owner before anyone changes router policy. The same inventory helps during acquisitions, provider migrations, and emergency prefix withdrawals.
Use change windows for ROA edits and watch the validation population across multiple vantage points. A single collector can be wrong or stale. A regional view can reveal that an operator is seeing the intended route while another region sees an older or conflicting announcement.
What RPKI does not solve
Origin validation cannot prove that a network is trustworthy after traffic arrives. It does not protect BGP sessions from unauthorized configuration changes, and it does not make a route path trustworthy. It also does not remove the need to filter customer and peer announcements against an explicit policy.
The strongest deployment treats RPKI as one input among several: prefix and AS-path filters, maximum-prefix limits, route monitoring, ROA ownership records, and a tested response plan. That combination gives engineers a clear explanation for why a route was accepted or rejected and a bounded way to recover when the evidence is incomplete.
The practical goal is not a perfect trust score. It is a routing control that can be observed, explained, and reversed during an incident.