RPKI Route Origin Validation for BGP Security

RPKI route origin validation gives network operators a way to check whether the autonomous system announcing an Internet route is authorized to originate its IP prefix. It addresses a specific weakness in Border Gateway Protocol (BGP): routes are exchanged between networks, but BGP alone does not prove that an announced prefix belongs to the originating network. This explainer covers the signed records, validator-to-router data flow, deployment choices, and important limits of the protection.

What Is RPKI Route Origin Validation?

The Resource Public Key Infrastructure (RPKI) is a system of cryptographically signed records that associate Internet number resources with their holders. A Route Origin Authorization (ROA) is one such record. It states that a particular autonomous system number (ASN) is authorized to originate a particular IP prefix, optionally including a maximum prefix length.

Route Origin Validation (ROV) compares a BGP route with the set of validated ROAs. For example, a ROA may authorize AS 3333 to originate 193.0.0.0/21. A route for that prefix with origin AS 3333 matches. A route for a more-specific prefix may also match if its length is within the ROA’s maxLength; another origin ASN does not match.

The RIPE NCC’s RPKI overview describes how resource holders publish these authorizations. The architecture is defined in RFC 6480, while RFC 6811 and its clarifications in RFC 8481 describe BGP prefix origin validation.

ROVs let a network make a more informed decision about a route. They do not change the BGP protocol into a fully authenticated path protocol, and they do not make all networks on the Internet reject bad announcements.

The Problem RPKI Solves

BGP is the inter-domain routing protocol that networks use to tell neighbors which IP prefixes they can reach. It is designed to exchange routes at global scale and support administrative policy, not to independently verify the right to originate every prefix. A network can therefore accidentally or maliciously announce a prefix it does not control. Other networks may accept and propagate that announcement, causing traffic to follow an unintended path or reach the wrong destination.

Traditional mitigations include prefix filters, routing policies, and coordination between operators. These remain essential, but filtering requires accurate information about peers and their permitted announcements. RPKI adds a cryptographically verifiable statement from the holder of the number resources. A receiving network can check that statement instead of relying only on a manually maintained prefix list.

This protection is intentionally narrow. It helps answer, “Is this origin ASN authorized to announce this prefix?” It does not determine whether every AS in the route’s AS_PATH is legitimate, whether a route leak has occurred, or whether a route is the best path for a particular network.

How RPKI Route Origin Validation Works

The system separates publication, validation, and routing:

1. A resource holder creates ROAs. The address or ASN holder publishes signed authorizations through its Regional Internet Registry (RIR) or delegated RPKI service.
2. A validator retrieves and verifies RPKI data. A relying-party validator follows certificate chains from configured trust anchors, checks signatures and validity, and processes repository updates.
3. The validator produces validated records. It converts valid ROAs into Validated ROA Payloads (VRPs), containing a prefix, maximum length, and authorized origin ASN.
4. A router obtains VRPs over RTR. The RPKI-to-Router protocol conveys the validated data to a router; the router does not need to retrieve and validate the complete RPKI repository itself. RFC 8210 specifies this protocol.
5. The router classifies BGP routes. The route’s prefix and origin ASN are checked against available VRPs. Local routing policy can then accept, reject, or otherwise rank the route.

The validator is an operational dependency: routers need current VRPs to make current decisions. Operators commonly run redundant validators and monitor their RTR sessions and repository refreshes so a cache failure does not go unnoticed.

Components and Validation States

An ROA covers a prefix and an origin ASN. Its maxLength permits announcements more specific than the ROA’s exact prefix, up to the stated prefix length. A validator checks the signed RPKI data and generates VRPs. The BGP router compares each route against those VRPs and assigns one of three origin-validation states:

“NotFound” is not the same as “Invalid.” It means there is no covering authorization to check against. An Invalid result can be caused by a hijack, but it can also be caused by an incorrect or incomplete ROA, a legitimate origin missing from the authorization, or a maxLength that is too restrictive. A route that is valid at one moment can become Invalid if the holder changes its ROAs without accounting for active announcements.

The Routinator documentation explains how a validator retrieves RPKI data and serves it to routers. The router’s policy is separate from validation itself: a router can learn that a route is Invalid and still accept it if its configuration permits it.

Real-World Uses

ROV is useful for networks that make routing decisions based on announcements from other autonomous systems. An ISP can reject routes whose origins conflict with published authorizations. A cloud provider, enterprise with multiple upstreams, or Internet exchange can use validation state as one signal in its import policy. Network operators can also check their own prefixes from outside their network to catch an incorrect ROA before it affects reachability.

ROV complements, rather than replaces, controls such as prefix limits, maximum-prefix safeguards, peer-specific filters, and monitoring. Each control addresses a different failure mode. Prefix filters constrain what a neighbor may announce; ROV checks whether a route’s origin is authorized; route monitoring helps operators notice unexpected changes.

The quality of ROA data matters. Resource holders must cover every legitimate origin ASN, including backup providers that may announce during failover. They should set maxLength only as broadly as necessary: an overly permissive value authorizes more-specific announcements, while an overly restrictive value can mark a legitimate route Invalid. These records should be reviewed alongside changes in address assignments and routing design, not treated as a one-time setup.

Getting Started: Check and Apply Validation

Start by inventorying public prefixes and the ASNs that actually originate them. Create ROAs through the relevant RIR or delegated service, keeping the authorized prefix and maxLength aligned with real announcements. Confirm both primary and backup origins before enabling rejection policy. The Routinator installation guide documents package installation; for example, on a supported Debian system with the NLnet Labs package repository configured:

sudo apt install routinator
sudo systemctl status routinator

Routinator serves validated data over RTR, normally on TCP port 3323. In FRRouting (FRR), configure a reachable validator and apply an inbound route map to the relevant BGP peer. This example rejects Invalid routes and permits the rest; replace the peer and validator addresses for your network. Check the FRR BGP manual for version-specific behavior:

rpki
 rpki cache tcp 127.0.0.1 3323 preference 1
 exit
!
router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 address-family ipv4
  neighbor 203.0.113.1 route-map RPKI-IN in
 exit-address-family
!
route-map RPKI-IN deny 10
 match rpki invalid
!
route-map RPKI-IN permit 20

Before deploying an import-policy change, verify the classification of a real prefix and ASN with the RIPEstat RPKI validation API. This request returns JSON whose data.status indicates valid, invalid, or not_found:

curl -G 'https://stat.ripe.net/data/rpki-validation/data.json' \
  --data-urlencode 'resource=AS3333' \
  --data-urlencode 'prefix=193.0.0.0/21'

In production, check that the router’s RTR session is established, VRPs are updating, and the route map has the intended effect. Monitor your own announcements from multiple networks, alert on Invalid results, and keep a recovery procedure for erroneous ROAs or validator outages. RPKI validation should be rolled out with normal change controls; a configuration that rejects routes before its own announcements are correct can cause the reachability problem it was meant to prevent.

Common Misconceptions

“RPKI makes BGP secure.” ROV adds a check for prefix origin authorization. It does not authenticate the entire path, encrypt BGP sessions, prevent denial of service, or fix routing policy errors.

“NotFound means the route is malicious.” NotFound only means no covering VRP is available. It is different from Invalid, and operators decide how to handle it.

“Publishing a ROA protects a prefix everywhere.” A ROA provides data that participating networks can use. A network must retrieve and validate that data, connect routers to a validator, and configure its own policy. Adoption and policy vary.

“A ROA is the same as a route announcement.” A ROA authorizes an origin; it does not announce a prefix or guarantee that the authorized network is currently advertising it.

Related Articles

• BGP Routing Fundamentals explains how autonomous systems exchange routes and apply routing policy.
• IP Address Management (IPAM) Systems covers how organizations track and allocate address prefixes.
• DNSSEC Explained describes a separate use of cryptographic signatures to validate DNS data.

Changelog

• Initial publication.