RPKI (Resource Public Key Infrastructure)
1. Overview
RPKI (Resource Public Key Infrastructure) is a public key infrastructure that cryptographically proves the ownership and delegation of Internet number resources—such as IP address blocks (prefixes) and Autonomous System Numbers (ASNs)—using an X.509 certificate system, so that "which AS is authorized to announce which prefix" becomes verifiable. The procedure by which a router checks the origin of a BGP route on top of this is called ROV (Route Origin Validation), and RPKI constitutes the skeleton that provides the trust basis for this ROV.
The backdrop to RPKI's emergence is the structural weakness that BGP, the inter-domain routing protocol of the Internet, is inherently built on "trust-by-default." BGP works such that when each AS tells its neighbors "I own this prefix and can reach it via this path," the neighbors accept the statement without separate verification and propagate it worldwide. When networks were small, with hundreds of mutually acquainted organizations in the late 1980s, this optimistic trust worked well enough, but in today's environment where more than 70,000 ASes interconnect anonymously, a single operator's misconfiguration or malicious announcement spreads into prefix hijacking, causing incidents where traffic bound for a particular service is swallowed wholesale into the wrong place. The 2008 incident where Pakistan Telecom mis-announced YouTube's prefix and paralyzed YouTube worldwide for hours, and the 2018 incident where an attacker hijacked Amazon Route53 DNS prefixes to steal funds from users of the MyEtherWallet cryptocurrency wallet, symbolically show why this "propagation without verification" is dangerous.
To counter such threats, a router, when it receives a route announcement, must be able to cryptographically confirm "whether the origin AS of this announcement actually holds the authority to announce the given prefix." Since the root of that authority ultimately lies in the delegation hierarchy descending through IANA→RIR (Regional Internet Registry)→ISP/organization that distributes number resources, one can simply transpose this delegation relationship directly into a certificate system to build a structure where "only the holder of a resource can sign for it." RPKI starts from exactly this idea and is a PKI that maps the allocation hierarchy of number resources onto the trust hierarchy of public key certificates. The IETF SIDR/SIDROPS working group standardized it around RFC 6480 (architecture); the ROA (Route Origin Authorization) profile that declares route authority was defined in RFC 6482 and later updated by RFC 9582; the router's origin validation procedure is specified in RFC 6811, and delivery between router and validator in RFC 8210 (RPKI-to-Router).
RPKI's necessity becomes clear along three axes. First, authenticity of origin, converting a "claim of ownership made by word alone" into "authority proven by signature." Second, automatic blocking of misconfigurations and accidents, filtering out even benign fat-finger announcements and preventing a large share of routing incidents in advance. Third, restoration of ecosystem trust, placing routing security—which once relied solely on the goodwill of individual operators—on a verifiable common foundation. However, as seen later, RPKI only validates the 'origin' and does not guarantee the 'entire path (AS-PATH),' so knowing that boundary precisely is especially important from a professional engineer's perspective.
The essential characteristics that distinguish RPKI from other security technologies can be summarized as resource-based trust, hierarchical delegation, and separation of validation from enforcement. It differs from general PKI in that it proves ownership of number resources rather than identity; it differs from a horizontal web of trust in that trust flows along the resource-delegation path of IANA→RIR→operator; and it bypasses router performance constraints in that the heavy validation is handled entirely by the RP while the router only performs lightweight lookups. These three characteristics are the key that simultaneously explains the "origin-only" limitation and the "trust concentration" governance burden discussed later.
2. RPKI Trust Structure and Components
The key to understanding RPKI is the structural correspondence that "the delegation hierarchy of number resources was transposed directly onto the trust hierarchy of certificates." That is, the fact that an organization is authorized to announce a particular prefix is proven by the certificate path for that prefix signed down from RIR→upstream operator→the organization. The overall system is broadly divided into "the side that declares authority (resource holders issue and publish ROAs)" and "the side that consumes that declaration (RPs validate and routers enforce)," with repositories and the RPKI-RTR protocol connecting the two. The overall structure diagram below shows the resource certificate hierarchy (top) together with the path by which routers are supplied validation material on top of it (bottom).
flowchart TB
subgraph TRUST["RPKI trust hierarchy (resource certificates)"]
TA["Trust anchor: 5 RIRs (APNIC/RIPE/ARIN/LACNIC/AFRINIC)"]
ISP["ISP/org CA (delegated resources)"]
ROA["ROA: (prefix, maxLength, origin ASN) digitally signed"]
TA --> ISP
ISP --> ROA
end
subgraph VAL["Validation and propagation system"]
PUB["RPKI repository (RRDP/rsync)"]
RP["RP validator (Routinator/rpki-client/FORT)"]
VRP["VRP (validated ROA list)"]
RTR["RPKI-RTR protocol (RFC 8210)"]
RTR2["BGP router (performs ROV)"]
ROA -.publish.-> PUB
PUB --> RP
RP --> VRP
VRP --> RTR
RTR --> RTR2
end
A. Resource certificate hierarchy and trust anchors
The root of RPKI trust is the trust anchor operated by the 5 RIRs (APNIC, RIPE NCC, ARIN, LACNIC, AFRINIC). Each RIR issues a top-level certificate covering the entire address/AS resource pool delegated to it by IANA, and below that signs down subordinate certificates—bearing the RFC 3779 extension (listing IP/ASN resources in the certificate)—to ISPs, NIRs (national registries), and large organizations that have been allocated resources. The key point here is that the certificate proves 'resources,' not 'identity.' Whereas an ordinary web PKI certificate guarantees "this public key belongs to example.com," an RPKI certificate guarantees "the owner of this public key is authorized to use 192.0.2.0/24 and AS64500." That is why RPKI is called a resource PKI.
Thanks to this hierarchical structure, forging authority is hard. For an organization to create a ROA for a particular prefix, that prefix must be included in the resource list of its own certificate, and that certificate must in turn connect up to the parent RIR via a signature chain. If anywhere in the middle something falls outside the resource range or the signature breaks, the validator judges the entire path invalid. However, as the deeper section later discusses, this structure simultaneously carries the governance burden that trust is concentrated in a small set of entities called RIRs.
The certificate hierarchy also has the advantage that it can directly express sub-allocation of resources. For instance, if an RIR allocates a /16 to a large carrier and that carrier re-allocates a /20 to a subsidiary organization, the certificate too is signed down one more step with the same inclusion relationship. Because it was designed so that "the path along which resources flow" and "the path along which trust flows" coincide, RPKI reuses the very distribution system of number resources as the basis of security, without any separate identity registration authority. Conversely, if an upper certificate expires or is revoked, all subordinate objects beneath it become invalid at once, so managing the renewal cycle and re-issuing before expiry (roll-over) of certificates becomes a very important operational task.
B. ROA (Route Origin Authorization)
A ROA is an object that digitally signs the authority declaration that "a given origin AS may announce a given prefix." One ROA consists of three elements: (origin ASN, one or more prefixes, the maxLength of each prefix). For example, if an organization announces 203.0.113.0/24 as AS64500, that organization issues a ROA (AS64500, 203.0.113.0/24, maxLength 24). Here maxLength means "down to how many bits may this prefix be split (subnetted) and announced." Setting maxLength to 24 makes exactly /24 valid, but, for example, giving a /22 prefix a maxLength of 24 recognizes announcements of all sub-prefixes from /22 to /24 as valid. As seen later, setting this maxLength too loosely is a typical mistake that actually widens the attack surface.
The way a ROA is issued is divided into hosted and delegated according to the boundary of operational responsibility. In the hosted model, the resource holder creates a ROA with a few clicks on a portal provided by the RIR/NIR, and the RIR takes on the signing key and repository operation on their behalf. Its barrier to entry is low so most small and mid-sized operators choose it, accepting in exchange that key control rests with the RIR. In the delegated model, the organization runs its own CA and repository and controls the signing key itself; control is greater but it must shoulder certificate renewal, repository availability, and key protection on its own. In practice, under the typical trade-off of "control versus operational burden," the two models are chosen according to organizational scale and security requirements.
C. RP (Relying Party) validator and VRP
ROAs are published to distributed repositories operated by RIRs and operators, and the entity that collects and validates them is the RP (Relying Party) software. Validators such as Routinator (NLnet Labs), rpki-client (OpenBSD), FORT, and OctoRPKI are representative. Starting from the trust anchor, the RP downloads all certificates and ROAs in the repository, validates the signature chain and resource inclusion relationships, and then culls only the valid ones to produce the VRP (Validated ROA Payload, validated ROA list). The VRP is ultimately a set of "(origin ASN, prefix, maxLength)" tuples, which becomes the material the router actually uses for validation. Repository synchronization has shifted its center of gravity from the rsync-centric past to RRDP (RFC 8182, HTTPS-based), which efficiently receives only the changed portions, improving availability and scalability.
A point easily overlooked in RP operation is that the RP itself can become a single point of failure (SPOF) for routing security. If the RP cannot reach a particular RIR repository or stops during validation, the VRPs for that range drop out entirely, and normal routes can suddenly flip to NotFound or Invalid. For this reason, large operators deploy multiple RPs differing by region and implementation, and set policies such as graceful degradation that retain past VRPs for a certain time when repository access fails. Also, since the RP quietly filters out objects whose signatures are wrong or that fall outside the resource range, operators must be able to trace from the RP logs "why a particular ROA was not reflected in the VRP."
D. RPKI-RTR protocol and routers
Finally, the VRP produced by the RP is delivered to BGP routers via the RPKI-to-Router protocol (RFC 8210). The router does not perform heavy cryptographic operations (signature verification) directly; it receives only the VRP set from an RP that has already finished validation and performs ROV in the form of a lightweight lookup. This role separation is important: since it is unrealistic for a router to verify the signatures of hundreds of thousands of ROAs every time, computation-intensive validation is handled entirely by the RP and the router is designed to merely consume the result. This separation of "validation (RP) and enforcement (router)" is the essence of the RPKI operational architecture.
An RPKI-RTR session maintains state between the RP (server) and the router (client); initially it downloads the full VRP and thereafter incrementally transmits only the changes (delta), reducing the router's memory and session load. For the integrity and confidentiality of the session itself, it is also recommended to operate over a protected channel such as TCP-AO, SSH, or TLS, because if the "conduit that carries the validation results" is tampered with, ROV as a whole is neutralized. Operators usually configure a single router to connect simultaneously to multiple RP caches, providing redundancy so that even if one RP goes down, ROV continues with another RP's VRP.
| Component | Role | Representative implementation/standard |
|---|---|---|
| Trust anchor | Root of trust (top-level resource certificate) | 5 RIRs |
| Resource certificate | Proof of number-resource delegation (RFC 3779) | RFC 6487 |
| ROA | Declaration of an origin AS's announcement authority (signed) | RFC 6482 → RFC 9582 |
| RP validator | Collect/validate repository → produce VRP | Routinator/rpki-client/FORT |
| RPKI-RTR | Deliver VRP to routers | RFC 8210 |
| BGP router | VRP-based ROV and policy enforcement | RFC 6811 |
3. ROV (Route Origin Validation) Operating Procedure and Validation States
When a router receives a BGP route announcement from a neighbor, it compares the origin AS (the rightmost AS of the AS-PATH) and prefix contained in the announcement against the VRP set and judges it into one of three states. The detailed flow diagram below shows the process from announcement receipt to policy decision.
flowchart TD
A["Receive BGP route announcement (prefix + AS-PATH)"] --> B["Extract the announcement's origin AS and prefix"]
B --> C{"Is there a VRP entry covering this prefix?"}
C -->|"None"| D["NotFound (Unknown): no ROA registered"]
C -->|"Exists"| E{"Origin ASN matches & prefix length <= maxLength?"}
E -->|"Yes"| F["Valid: authorized announcement"]
E -->|"No"| G["Invalid: origin mismatch or excessive splitting"]
D --> H["Policy: usually accept (blocking risks mass disconnection)"]
F --> I["Policy: accept + may raise priority"]
G --> J["Recommended policy: drop"]
Valid is the case where the announcement's origin AS and prefix exactly match some VRP entry and the prefix length is also within maxLength. Invalid is the case where a ROA covering that prefix exists but the origin AS differs (an unauthorized AS is announcing) or the prefix exceeds maxLength and is split too finely—a state where hijacking is suspected. NotFound (or Unknown) is the state where there is no ROA at all for that prefix, so there is no basis to validate.
Among the three states, the one that has long occupied the largest share in reality is NotFound. This is because a substantial portion of the world's prefixes have not yet registered a ROA, and this very point creates the tension of "validate, but do not block rashly." Since reachability is the lifeblood of routing, discarding NotFound merely for lacking a basis severs the path to a perfectly fine destination. Thus the real effect of ROV lies not in dividing all routes into black and white but in surgically removing only the Invalid ones that clearly violate authority.
The important implication here, from a professional engineer's standpoint, is that "how Invalid is handled" directly governs the security effect. If one merely validates and accepts Invalid routes as-is, RPKI is practically just "sightseeing." Real defense occurs only when a policy of dropping Invalid routes is applied to the router. On the other hand, since NotFound occupies more than half of the world that has not yet created ROAs, blocking it unconditionally severs normal traffic en masse. Thus real-world operation converges on the asymmetric policy of "drop Invalid, accept NotFound, prefer Valid." For this reason, increasing ROA registration to reduce NotFound (expanding ROA coverage) and actually dropping the Invalid received (ROV enforcement) are split into two different tasks, and as the statistics later show, there is a large gap between the two.
In the operational field, rather than immediately dropping Invalid, one sometimes goes through a gradual transition of lowering BGP local-preference to demote it. Out of concern that an abrupt drop might cause mass disconnection due to misconfiguration, one first observes Invalid via logs and alarms to verify for false positives, and only once stable does one finally turn on the drop policy. This gradual application of "validate→observe→demote→drop" is a typical operational pattern that raises security while preserving availability.
4. RPKI's Limitations and Complementary Technologies — ROV vs. BGPsec vs. ASPA
The most fundamental limitation of RPKI/ROV is that it only validates the origin and does not guarantee the authenticity of the entire path (AS-PATH). The reason this difference arises is that a ROA declares only "who may be the starting point of this prefix." Therefore, a 'forged-origin hijack' in which an attacker appends the legitimate origin AS to the end of the path as a forgery, or a route leak in which a path is not forwarded as received but re-announced in violation of the rules, passes ROV unchanged. That is, ROV blocks "origin forgery" but not "intermediate path manipulation." In fact, if an excessive maxLength is left to broadly permit sub-prefix announcements, an attack in which the attacker announces a more-specific prefix within that range bearing a legitimate origin and draws in traffic can be judged Valid—the reason maxLength must be narrowed to the strictly necessary value.
The danger of a forged-origin hijack becomes clearer with concrete numbers. Suppose a legitimate holder announces 198.51.100.0/22 as AS64500 while setting the ROA loosely as (AS64500, 198.51.100.0/22, maxLength 24). The attacker can announce 198.51.100.0/24—a longer prefix within this range—while appending the legitimate AS64500 to the end of the AS-PATH. Since routers prefer the longer prefix (longest-prefix match), traffic rushes to the attacker's /24, yet because the origin AS is AS64500 and the length 24 is within maxLength, the ROV judgment is Valid. Had maxLength been narrowed only to the 22 actually used, the length-24 announcement would have exceeded maxLength and immediately become Invalid and been blocked. In this way a single line of maxLength setting decides whether an attack is possible, and this is the basis for the operating principle "maxLength to the strictly necessary minimum."
The complementary technologies that fill this gap are BGPsec and ASPA. BGPsec (RFC 8205) has each hop of the AS-PATH sign the path as it is forwarded to the next AS, thereby cryptographically guaranteeing the integrity of the entire path, but because signing and verification must be performed at every hop the router's computational and memory burden is large, and full-scale deployment is practically stalled. By contrast, ASPA (Autonomous System Provider Authorization) has each AS declare "who the upstream (provider) of this AS is" as an RPKI object, so it is designed to detect—with relatively light computation—whether a path has departed from the normal form of customer-provider relationships (= route leaks or some path manipulation), and to be effective even under partial deployment, drawing attention recently as the most promising alternative.
| Category | ROV (RPKI origin validation) | ASPA | BGPsec |
|---|---|---|---|
| Validation target | Origin AS only | Customer-provider path relationship | Entire AS-PATH (per-hop signing) |
| Threats blocked | Simple origin hijack/misconfig | Route leaks/some path manipulation | Path forgery in general |
| Computational burden | Low (router only looks up) | Medium | High (per-hop sign/verify) |
| Partial-deployment effect | Present | Present (relatively large) | Small |
| Maturity | Widely deploying | Standardizing/early deployment | Stalled |
The practical implication of this comparison is clear. None of them is a 'silver bullet' that blocks all threats; the realistic strategy is a layered, phased application of clearing origin threats with ROV, then complementing route leaks with ASPA, and in the long run adding BGPsec's path integrity.
Here the concept of the partial deployment effect divides the strategy choice. BGPsec is meaningful only when all ASes on the path participate in signing, so unless the whole world switches simultaneously the protective effect is minimal—this is the fundamental reason BGPsec deployment has practically halted. By contrast, with ROV and ASPA, even if only some ASes enforce them, those ASes can immediately filter the hijack/leak routes they receive, so the incentive "whoever adopts first benefits first" operates. The RPKI ecosystem vividly shows that the success or failure of a security technology hinges not on cryptographic strength alone but on deployability, and this is a perspective a professional engineer must consider when designing the introduction of a new technology.
5. Deep Dive: Deployment Status, Real Cases, Domestic and Global Trends
RPKI is a representative case of "the standard is in place but deployment is in progress." As of mid-2026, about two-thirds (around 67%) of the world's routing prefixes are measured to hold a ROA, with IPv6 (around 73%) having higher coverage than IPv4 (around 66%). However, the share of ASes that actually drop received Invalid (ROV enforcement) is much lower, at roughly 12–33% depending on measurement method. That is, while "the house that has declared authority (ROA)" has increased, "the house that actually locks its doors (ROV drop)" is still a minority, and this coverage–enforcement gap is the core issue of routing security at the present stage. These figures vary widely by source, point in time, and measurement method (APNIC Labs, Hurricane Electric, etc.), so they should be read as trends rather than as definitive.
Why this gap matters is revealed by simple arithmetic. Even if 100% of the world's prefixes registered a ROA (100% coverage), if the ASes through which traffic passes do not drop Invalid (0% ROV enforcement), hijack routes still propagate. Conversely, even if ROAs are still few, if core transit ASes enforce ROV, protection occurs immediately to the extent of the range they filter. That is, the felt effect of routing security appears as the product of "the house that registered a ROA (the victim side)" and "the house that drops Invalid (the propagation path side)," which is why the two metrics of coverage and enforcement must be managed separately.
Real cases show RPKI's utility and limits simultaneously. The 2018 MyEtherWallet incident revealed why ROV is necessary; the June 2024 incident in which Cloudflare's public DNS (1.1.1.1) suffered worldwide access failures as a hijack and a route leak overlapped revealed the limit that ROV alone cannot block route leaks. In 2025, a case was reported in which, rather than breaking RPKI, an attacker socially engineered their way through a gap in an upstream operator's lax customer identity-verification procedure to have transit opened for a hijacked ASN, which underscores the importance of operational and process security that cryptographic technology alone cannot fill. Domestically too, KISA/KRNIC, as the national registry under APNIC, provides a hosted RPKI CA for domestic resource holders, and carriers' ROA registration and ROV enforcement are gradually expanding. The international initiative that underpins the spread of such voluntary norms is MANRS, which presents four recommended actions: filtering, anti-spoofing, coordination, and RPKI-based global validation.
A noteworthy point in terms of trends is that the center of gravity of security is expanding from 'technology' to 'governance and process.' As the 2025 social-engineering case shows, the more cryptographically robust RPKI becomes, the more attackers—rather than breaking the crypto—aim at gaps in operators' customer-registration and transit-provisioning procedures. Also, as many large content and cloud operators (Google, Cloudflare, Netflix, etc.) place ROAs on their prefixes and demand ROV enforcement from interconnection partners, a trend emerges in which RPKI even establishes itself as a commercial negotiation condition. On the standards side, as the ROA profile is consolidated into RFC 9582 and ASPA moves into standardization and early deployment, routing security is maturing not as a single technology but as a combination of multiple objects and procedures.
6. Considerations and Implications (Professional Engineer's Perspective)
- Application strategy (phased maturation): RPKI adoption should be designed in the stages of "ROA registration → build RP validator → enforce Invalid-drop policy → complement with ASPA, etc." In particular, security is not completed just by creating ROAs; the effect occurs only when Invalid is actually dropped, so managing (as KPIs) the coverage metric and the enforcement metric separately is key.
- Trade-off (availability vs. security): The more strongly Invalid is blocked, the higher the security, but if normal routes are falsely blocked due to ROA/certificate misconfiguration or repository/RP failure, it can lead to widespread service disconnection. Therefore one should narrow maxLength to the minimum while jointly designing operational safeguards—RP redundancy, securing repository availability (RRDP), validation before changes—to balance security and availability.
- Governance and trust-concentration risk: Because trust is concentrated in a small number of RIR trust anchors, one must institutionally control the risk that when an upper certificate is changed or revoked—due to resource reclamation, disputes, national pressure, etc.—subordinate routes are invalidated en masse (the so-called kill-switch concern). This must be handled not as a pure technical problem but as a problem of resource governance and international cooperation.
- Outlook and related technologies: Routing security follows a layered roadmap expanding from origin validation (ROV) to path-relationship validation (ASPA) and further to path integrity (BGPsec). In the mid-to-long term, it is expected to develop toward a transition of signature algorithms to post-quantum cryptography (PQC), linkage with DDoS and route-anomaly detection, and, from a zero-trust network perspective, extending the principle "never trust, always verify" even to inter-domain routing.
- Linkage with regulation and policy: Routing security is being elevated beyond the choice of an individual company into a reliability issue of the national backbone network. Regulatory movements are appearing—such as the US requiring carriers to submit routing-security plans—and domestically too, a trend of turning ROA registration and ROV enforcement into inspection items from the perspectives of critical-information-infrastructure protection and telecommunications-disaster management is expected. A professional engineer must be able to design RPKI not as a single technical task but as routing-security governance that bundles in procurement, contracts (interconnection conditions), and compliance.
References
- IETF, "An Infrastructure to Support Secure Internet Routing" (RFC 6480) — https://www.rfc-editor.org/rfc/rfc6480
- IETF, "A Profile for Route Origin Authorizations (ROAs)" (RFC 9582) — https://www.rfc-editor.org/rfc/rfc9582
- IETF, "BGP Prefix Origin Validation" (RFC 6811) — https://www.rfc-editor.org/rfc/rfc6811
- IETF, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1" (RFC 8210) — https://www.rfc-editor.org/rfc/rfc8210
- MANRS, "RPKI ROV Deployment Reaches Major Milestone" — https://manrs.org/2024/05/rpki-rov-deployment-reaches-major-milestone/
- APNIC Blog, "RPKI vs social engineering: A case study in route hijacking" — https://blog.apnic.net/2026/03/31/rpki-vs-social-engineering-a-case-study-in-route-hijacking/
In one line: RPKI maps the delegation hierarchy of IP/AS resources onto a certificate trust hierarchy to prove "only an authorized AS announces a prefix," and the ROV on top of it blocks origin hijacks and misconfigurations but does not guarantee the entire path, so the crux is phased, layered application together with ASPA/BGPsec and the enforcement of 'dropping Invalid.'