Internet Backbone Routing Security: RPKI Route Origin Validation and Hijack Defense
Learn how RPKI Route Origin Authorizations identify an AS permitted to originate an IP prefix and how routers classify routes as Valid, Invalid, or NotFound. Operators choose how to handle Invalid routes; origin validation does not attest the full AS path or guarantee reachability.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Autonomous systems exchange reachable IP prefixes and path attributes using BGP. Route Origin Validation (ROV) checks the advertised origin AS against validated RPKI data for the prefix. This is a limited origin-authorization check: it does not prove that the complete AS path is safe or that a destination is reachable, and operators decide how validation states affect routing policy.
1. BGP Trust Model and Structural Risks of Route Hijacking
BGP exchanges reachable IP prefixes and path attributes between autonomous systems. Origin validation checks whether the originating AS is authorized for that prefix.
2. Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs)
RPKI connects certificates for Internet number resources with verifiable route-origin data. RFC 6480 describes the certificate-based infrastructure; RFC 6811 specifies how validated route-origin information is compared with a BGP route. A Route Origin Authorization (ROA) states a prefix, a maximum prefix length, and an authorized origin AS. Resource holders manage authorization issuance, while routers consume validated data; the route-validation procedure does not mean that a router holds the resource holder’s signing key.
3. Edge Router Route Origin Validation (ROV) Mechanics and Tri-State Logic
RFC 6811 defines three outcomes by comparing a route’s prefix and origin AS with validated route-origin payloads (VRPs). NotFound means no VRP covers the route prefix. Valid means at least one covering VRP matches the origin AS and prefix-length constraint. Invalid means a VRP covers the prefix but none matches. The RFC does not require every Invalid route to be rejected; it leaves that action to local policy. ROV checks origin authorization only and does not establish that the full path is safe or that the destination is reachable.
4. Practitioner perspective: policy and operational limits
How an operator applies ROV results depends on the network and its risk policy. RFC 6811 discusses rejecting Invalid routes but warns that bad validation data can mark legitimate routes Invalid and create a denial-of-service risk. Monitor validator connectivity and data-update failures, and pair any rejection policy with change control and a recovery path. RIPE NCC treats ROA management and origin validation as distinct operational tasks: address holders maintain accurate authorizations, while network operators decide how routers use the resulting validation state.
RFC 6811 has since been updated by RFC 8481 and RFC 8893. RFC 8481 clarifies that validation state must not drive policy unless the operator configured it. RFC 8893 covers export validation that uses the effective origin AS after outbound policy changes. An operational review should therefore check validator freshness, keep NotFound distinct from Invalid, identify affected prefixes, and define a ROA correction or policy rollback path. RFC 8481 RFC 8893