What Is RPKI and Why Does It Matter?
Traffic across Internet networks is routed according to BGP (Border Gateway Protocol). BGP assumes that every Autonomous System (AS) is honest when announcing the IP prefixes it controls. This trust model is weak. Malicious announcements, configuration errors, or deliberate attacks can claim prefixes they do not control, causing prefix hijacks or route leaks.
To strengthen this security, Resource Public Key Infrastructure (RPKI)was developed. It is a cryptographic system that allows IP prefix holders to declare which AS may originate route announcements for their prefixes. Other networks can validate BGP updates against these declarations.
The central component of RPKI is a Route Origin Authorization (ROA). A ROA states that an AS is permitted to announce a given prefix and may include a maximum prefix length. When a BGP update arrives, networks performing Route Origin Validation (ROV) compare incoming announcements with existing ROAs and classify them as valid, invalid or unknown.
At present, only origin validationis supported; validating the complete AS path—the precise path a packet follows—requires BGPsec, a more complex mechanism with limited deployment.
In short, RPKI provides a way to establish stronger assurance about who is authorized to announce which IP blocks, adding a protective barrier to global routing.
History, Standards, and Governance
RPKI and its supporting standards emerged through the working group SIDR (Secure Inter-Domain Routing) of the IETF.
Key reference documents include:
RFC 6480: RPKI Architecture
RFC 6482/6483: ROA Profiles and Validation
RFC 6810: RPKI-to-Router Protocol
Each RIR (Regional Internet Registry) can be regarded as a trust anchor. They issue resource certificates to Local Internet Registries (LIRs) or other resource holders, reflecting the allocation of IP prefixes and AS numbers. These certificates form a hierarchy that supports the issuance of ROAs.
Operators may choose to run their own certificate authorities or delegate this function to a hosted RPKI service provided by the RIR.
On the consumer side, routers obtain validated data from relying-party validators, which collect ROA information from distributed RPKI repositories through protocols such as rsync or RRDP (RPKI Repository Delta Protocol).
However, no single organization enforces adoption. RPKI’s effectiveness depends heavily on network effects: the more networks adopt both origin signing and validation, the greater the value for every participant.
Benefits of RPKI for Routing Security
Preventing Obvious Hijacks and Configuration Errors
One of its principal benefits is detecting unauthorized origin announcements. If a network tries to announce a prefix over which it has no rights, peers performing ROV can mark that announcement invalid and discard or deprioritize it, thereby reducing the risk of prefix hijacking.
Many routing incidents also result from simple configuration errors or “fat-finger” mistakes. RPKI helps mitigate these problems.
Containing the Scope of Damage
Because routing is interdependent, a misbehaving network can cause disruption far beyond itself. By rejecting invalid origins early, RPKI helps contain the damage.
Signaling Trust and Accountability
Having publicly registered ROAs provides transparency. Other operators can see which prefixes are signed, signaling operational discipline and sound network hygiene.
Enabling Future Improvements and Path Validation
Although RPKI today focuses mainly on origin validation, it lays the foundation for more advanced routing security, including BGPsec (path validation) and extensions such as ASPA (AS Path Authorization).
Over the long term, a global RPKI infrastructure could increase the cost of route hijacking for attackers and improve overall confidence in interdomain routing.
Current Adoption and Challenges: Deployment Statistics and Gaps
Coverage by ROAs has grown, but remains incomplete. According to recent measurements, approximately 40–50% of IPv4 prefixes have valid ROAs, with a similar or slightly higher percentage observed for IPv6.
However, fewer networks actively enforce ROV on their routers. Cloudflare, for example, maintains data comparing the adoption of “origin signing” and “origin validation”.
The difference between signing and validation is a critical gap: protection works only when both sides participate actively.
Operational Concerns: False Positives and Loss of Connectivity
One reason some operators hesitate is fear of false positives: misconfigured ROAs could mark legitimate announcements as invalid and cause unintended route drops.
Operators may also worry that enforcing the rejection of invalid routes will disconnect them from certain destinations. These risks require careful planning, gradual deployment, and fallback policies.
Relying-Party and Repository Vulnerabilities
Recent research has uncovered vulnerabilities in RPKI validator software (the “relying parties”). For example, CUREanalysis identified flaws that could allow route poisoning or disable validation logic.
Another class of attack,Stalloris, showed how an attacker could block the retrieval of repository data, forcing routers to operate insecurely.
A systemic study in 2024 reported that 56% of global RPKI validators have at least one documented vulnerability.
One effort to mitigate these problems is the Byzantine-secure relying party (BRP)design, which seeks to decentralize validation and improve resilience.
Fragmented Policies and Inconsistent Implementation
The logic of ROAs and validation includes ambiguous or underspecified cases in the RFCs, leading to divergent behavior across implementations.
Some networks apply strict filtering, others only monitor, and still others enforce it partially according to prefix categories.
Because routing is global, inconsistent policies reduce the security benefits. If only some routers discard invalid routes, malicious announcements can still propagate through more permissive paths.
Scalability, Automation, and Tooling
Some operators cite usability, complexity, and limited tooling as obstacles. Automating ROA management, synchronizing validator caches, and integrating them with routing platforms remains challenging.
In addition, reliance on rsync for repository synchronization is considered insecure or inefficient by some experts, leading to proposals to favor RRDP.
Some networks delay issuing ROAs until validation is widely adopted; however, this perpetuates slow adoption.
Best Practices for Operators Deploying RPKI
Start in Monitoring Mode
Deploy ROV passively by marking invalid routes without discarding them. Monitor unintended invalids before enforcing the policy.
Design ROAs Carefully
Use conservative maxLength settings. Avoid prefixes that are too broad or too strict and might accidentally invalidate legitimate announcements.
Gradual Enforcement and Fallback Routes
Begin rejecting invalid routes only after sufficient observation and with fallback routes in place. Apply validation progressively.
Robust Validator Infrastructure
Use multiple validator instances, choose reliable software, monitor gaps, and consider resilient systems such as BRP.
Keep ROA and Validator Data Current
Synchronize frequently, watch for repository failures, and ensure mitigations are available when data becomes stale.
Coordinate with Peers and Upstreams
Encourage others along the path to validate. Participation by many networks strengthens the benefits.
Follow Community Initiatives Such as MANRS
Standards such as routing-hygiene guidelines complement RPKI adoption.
Audit and Update Regularly
Review ROAs regularly. Changes in AS ownership, mergers, or IP reassignments require updates.
The “Network Effect” Dilemma and Incentives
A major obstacle is that the benefit appears only when many networks validate. An operator that signs but whose peers do not validate receives less protection. Conversely, enforcing validation can break connectivity with noncompliant networks, which slows deployment.
Some argue that regulation or industry incentives could help. Others point to economic reasons: network operators offering “secure transit” could charge a premium if they enforce ROV. Content providers could also require ROV compliance from hosting providers for security reasons.
There are also legal concerns. A study of legal barriers noted that courts would rarely find RPKI certificates defective when RIRs follow IETF standards.
Key Limitations and Residual Risks
Even with perfect origin validation, RPKI does not prevent every BGP attack:
Path manipulation: RPKI does not verify every AS hop; attackers can still forge AS paths. This is addressed by BGPsec, which remains largely undeployed.
Downgrade attacks and repository interference: if attackers block RPKI repositories or prevent validators from accessing them, networks may fall back to insecure routing.
Vulnerable validator software: as recent CURE audits have shown, errors can cause incorrect validation or route poisoning.
Partial or inconsistent policies: if parts of the Internet neither enforce nor sign ROAs, invalid routes can still pass through permissive paths.
Operational errors: misconfigured ROAs or missing updates can cause collateral damage.
RPKI is therefore an important improvement, but not a complete solution. Its full value emerges when combined with other measures such as route filtering, peer-level hygiene, and eventually full-path validation systems.
The Road Ahead: What Needs to Happen
Validator Resilience and Decentralization: broad use of robust architectures, such as BRP, to reduce reliance on single points of failure.
Better Tooling and Automation: more efficient interfaces, integration with routing systems, alerts, and tools for managing the ROA lifecycle.
Community Coordination and Incentives: peers, IXPs , and operators signing mutual agreements or even requiring ROV compliance for interconnections.
Greater Awareness and Training: many ISPs and network teams are still unfamiliar with RPKI.
Deployment of Complementary Standards: ASPA, BGPsec , and related standards must mature and achieve real adoption.
If these elements align, Internet routing infrastructure will become far more resilient to hijacks and leaks over time.
Frequently Asked Questions: RPKI and Routing Security
What Does It Mean When a Route Is Declared “Invalid”?
If a BGP announcement is invalid under ROV—that is, it is not covered by any ROA or the origin AS does not match—routers may discard it, deprioritize it, or assign it a lower preference.Can a Prefix Have More Than One ROA?
Yes. There can be multiple ROAs for the same prefix with different valid origin AS values. Validation logic must handle unions or conflictscarefully.Does RPKI Guarantee Complete Routing Security?
No. RPKI covers only origin assurance, not complete path verification. Attackers can still spoof AS paths or cause other anomalies.What Happens If Validator Data Is Stale or Unavailable?
Routers may treat announcements as unknown and therefore allow them. If connectivity fails, however, this mechanism could be exploited as adowngrade vector.How Can Small Networks or Content Providers Adopt RPKI?
They can use hosted RPKI services from their ISP or RIR. Even without operating their own validator, they can issue ROAs and signal origin authorization.
