RPKI Implementation
RPKI provides cryptographic verification of BGP route origins through digitally signed Route Origin Authorizations, preventing route hijacking attacks on internet routing.
Continue your mission
RPKI provides cryptographic verification of BGP route origins through digitally signed Route Origin Authorizations, preventing route hijacking attacks on internet routing.
# RPKI Implementation
Resource Public Key Infrastructure (RPKI) is a cryptographic framework that binds Internet number resources to their legitimate holders through digitally signed attestations, giving BGP operators a reliable mechanism to verify whether a route announcement is authorized before accepting it. The framework exists because BGP, designed in an era when network operators trusted one another implicitly, has no native authentication mechanism. Any network can announce any IP prefix, and without external validation, neighboring routers will often accept those announcements. RPKI closes that gap by providing a cryptographically verifiable chain of custody from the Regional Internet Registries down to the individual network operator, enabling routers to reject forged or misconfigured route announcements with mathematical confidence rather than policy hope.
RPKI operates through a trust hierarchy anchored at the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC), each of which acts as a trust anchor for the resources they administer. From those anchors, resource holders receive certificates that cryptographically bind their allocated prefixes and AS numbers to a public key they control. Holders then create Route Origin Authorizations (ROAs), which are signed objects stating that a specific AS number is authorized to originate a specific IP prefix up to a maximum prefix length.
RPKI is not a replacement for BGP security in its entirety. It validates only the origin AS in a BGP announcement, not the full AS path. It does not prevent route leaks caused by legitimate ASes propagating routes they should not, and it does not authenticate BGP session peers. BGPsec, a separate and far less deployed protocol, addresses AS path validation; RPKI is a prerequisite for BGPsec but distinct from it.
RPKI implementation involves four functional layers: certificate issuance, ROA creation, repository publication, and route origin validation at the router level. Each layer depends on the one below it, and failure at any layer breaks the chain of trust.
Certificate Issuance and ROA Creation
Resource holders authenticate to their RIR's RPKI portal and request a resource certificate covering their allocated prefixes and AS numbers. In hosted RPKI, the RIR generates and manages the certificate; the holder simply creates ROA objects through the portal interface. A ROA specifies three parameters: the IP prefix, the originating AS number, and an optional maximum prefix length. The maximum prefix length controls whether more-specific announcements from the same AS are considered valid. For example, a ROA for 192.0.2.0/24 with a max length of 24 authorizes only the /24 announcement from that AS; a max length of 28 would also authorize more-specific /25 through /28 announcements.
Setting max length too broadly is a common misconfiguration that partially defeats RPKI's protective value, because it permits route hijackers to announce more-specific prefixes within the authorized range. The most protective approach is to set max length to exactly match the prefixes you actually announce. If you only announce the /24, set max length to 24. If you announce the /24 and may need to announce a /25 during traffic engineering, set max length to 25.
ROAs are signed with the resource holder's private key and published to RPKI repositories. Each RIR operates its own repository using the RPKI Repository Delta Protocol (RRDP) or rsync. The publication point contains the signed ROA objects along with manifests that list all currently valid objects, enabling validators to detect missing or substituted objects.
Validator Deployment
Relying party software, commonly called validators, downloads the full RPKI repository data from all five RIR trust anchors and their delegated repositories. Validators verify the cryptographic chain from trust anchor to each ROA, check certificate validity periods, and check for revoked certificates using Certificate Revocation Lists (CRLs) and manifest completeness. Widely deployed validators include Routinator (from NLnet Labs), Fort Validator, and OctoRPKI. Validators typically run as dedicated processes within the operator's infrastructure, refreshing their local cache on a schedule aligned with repository publication intervals (typically every few minutes to every hour).
The output of the validator is a Verified ROA Payload (VRP): a list of prefix-origin-maxlength tuples that have passed cryptographic verification. This dataset is served to routers via the RPKI-to-Router (RTR) protocol, defined in RFC 6810 and updated in RFC 8210. RTR is a lightweight, connection-oriented protocol that allows routers to maintain a synchronized copy of the VRP table without performing cryptographic operations themselves. The protocol includes incremental updates, session reset capabilities, and error handling for certificate validation failures.
Route Origin Validation at the Router
Once a router has received the VRP table via RTR, it evaluates each incoming BGP route announcement against the table. The result is one of three states:
Operators configure local routing policies based on these states. The most protective posture is to drop Invalid routes at the border, prefer Valid routes over NotFound routes in tie-breaking, and accept NotFound routes with reduced local preference pending broader RPKI adoption. Most major router platforms (Cisco IOS-XR, Juniper Junos, Nokia SR OS, Arista EOS, and others) support ROV natively through BGP policy configuration.
Delegated RPKI and Certificate Authority Operations
While hosted RPKI covers most deployment scenarios, larger organizations may choose delegated RPKI, where they operate their own Certificate Authority (CA) under the RIR's trust anchor. Delegated RPKI provides more granular control over certificate issuance timing, allows for more complex organizational hierarchies, and enables integration with existing PKI infrastructure. The trade-off is significant operational complexity: the organization must run CA software (such as Krill from NLnet Labs), manage certificate renewals, publish to their own repository, and handle CRL generation.
Delegated RPKI makes sense for large ISPs, content delivery networks, or organizations with complex subsidiary structures where centralized ROA management through the RIR portal becomes unwieldy. For most enterprises, hosted RPKI provides equivalent security with dramatically lower operational overhead.
A Concrete Attack Scenario
Consider a financial services firm operating AS 65001 with customer-facing services on 203.0.113.0/24. The firm creates a ROA specifying AS 65001 as the origin and a max length of 24. A malicious actor operating AS 65099 announces 203.0.113.0/25 to their upstream provider, attempting to attract traffic destined for the /25 subset through longest-prefix-match routing (a more-specific hijack). Any router performing ROV with an up-to-date VRP table will classify that announcement as Invalid: a ROA exists for a covering prefix but the originating AS does not match. The hijacked route is dropped before propagation. Traffic continues reaching the legitimate AS 65001. Without RPKI, the more-specific announcement would propagate globally and traffic would be misdirected, potentially for hours until manual intervention by upstream providers.
BGP hijacking causes measurable, documented harm across every sector. Without RPKI-based route origin validation, any AS operator worldwide can announce your IP prefixes, and a meaningful percentage of the global routing table will accept those announcements within minutes. The consequences range from traffic interception (enabling man-in-the-middle attacks at the network layer) to complete denial of service (traffic blackholed at the attacker's network) to credential theft (users directed to attacker-controlled infrastructure impersonating legitimate services).
The 2018 BGP hijack targeting Amazon Route 53 DNS infrastructure illustrates the attack pattern clearly. The attacker announced more-specific prefixes covering Amazon's DNS resolvers, redirecting DNS queries to fraudulent resolvers that returned attacker-controlled IP addresses for a cryptocurrency exchange. Users attempting to access the exchange were directed to a phishing site that harvested credentials and private keys. The attack persisted for approximately two hours and was resolved only through manual intervention by upstream providers, not through any automated cryptographic protection. RPKI route origin validation, had it been widely deployed in enforcement mode by Amazon's upstream providers, would have caused routers to classify the fraudulent announcements as Invalid and drop them immediately.
A persistent industry misconception frames RPKI deployment as primarily the responsibility of large ISPs and content networks. This view is operationally backwards. Small and medium organizations with limited routing complexity can deploy RPKI (creating ROAs) in minutes through any RIR portal at zero cost. Large networks with thousands of prefixes, complex transit relationships, and legacy routing policies face significantly more implementation challenges. An unprotected /24 prefix belonging to a small organization represents a more attractive hijack target precisely because there is no cryptographic claim on record. Attackers seeking to abuse IP reputation, conduct spam campaigns, or establish man-in-the-middle positions preferentially target prefixes with no ROA coverage, because hijacks of those prefixes are classified as NotFound rather than Invalid by validating networks.
A second misconception treats RPKI as complete BGP security. RPKI validates origin AS only. It does not prevent route leaks, where a legitimate AS propagates routes beyond its intended scope (for example, a customer AS re-announcing its provider's full table to a peer). It does not authenticate the AS path between origin and destination. It does not prevent traffic analysis or BGP session hijacking. BGP security requires RPKI as a foundation, combined with prefix filtering based on Internet Routing Registry (IRR) data, AS path filtering, and eventually BGPsec deployment for cryptographic path validation.
CDA's Planetary Defense Model addresses RPKI implementation within the Vulnerability and Surface Defense (VSD) domain, guided by the Continuous Surface Reduction methodology: every surface you expose is a surface we eliminate. Internet routing infrastructure represents an attack surface that most organizations leave entirely undefended because routing security has traditionally been considered an ISP or carrier responsibility. CDA rejects that delegation as fundamentally flawed.
From a VSD perspective, an IP prefix without ROA coverage is an exposed attack surface with no compensating control. A missing ROA means that any announcement of your prefix by a third party will be classified as NotFound by validators worldwide, not Invalid. This distinction matters operationally: networks in strict enforcement mode drop Invalid routes but accept NotFound routes with reduced preference. Networks in monitoring-only mode accept both but may apply different policy treatment. Creating ROAs is not optional network hygiene; it is the minimum viable defensive action to ensure that RPKI-capable networks can distinguish between legitimate announcements and hijack attempts targeting your address space.
CDA's operational approach to RPKI implementation proceeds through four distinct phases within VSD engagements. First, comprehensive inventory: enumerate all AS numbers and IP prefixes the organization originates, controls, or has announced on its behalf by transit providers, including IPv6 allocations and historical assignments that may still appear in routing tables. Second, gap analysis: query public RPKI validators (such as Cloudflare's RPKI portal or RIPE NCC's validator interface) to identify prefixes with missing, expired, or misconfigured ROAs, and cross-reference against actual BGP announcements to identify operational mismatches. Third, systematic remediation: create ROAs for all originated prefixes with maximum prefix length values that match operational requirements exactly, avoiding overly permissive settings that would authorize unintended more-specific announcements. Fourth, validation and monitoring: deploy redundant RPKI validators within the organization's infrastructure, configure RTR sessions to border routers, verify VRP table accuracy against created ROAs, and confirm no self-originated routes are classified Invalid before enabling enforcement mode.
CDA distinguishes its approach by treating RPKI ROA coverage as a measurable surface reduction metric, not a best-effort recommendation. VSD engagements deliver explicit ROA coverage percentages, validator redundancy architectures, and RTR session monitoring as concrete defensive implementations. An organization without complete ROA coverage for all originated prefixes has a quantifiable routing attack surface that remains exposed until systematically closed through cryptographic binding.
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.