The Role of RPKI In Strengthening Global Routing Security

Traffic across networks on the internet is routed according to BGP (Border Gateway Protocol). BGP assumes that each Autonomous System (AS) is being honest about the IP prefixes it controls when advertising. That trust model is weak. Rogue announcements, misconfigurations or deliberate attacks may announce prefixes they do not control. This leads to prefix hijacking or route leaks.

To harden this, Resource Public Key Infrastructure (RPKI) was developed. It is a cryptographic system that allows IP prefix holders to assert which AS may originate route announcements for their prefixes. Other networks can then validate BGP updates against those assertions.

RPKI’s core building block is the Route Origin Authorisation (ROA). A ROA claims that an AS is allowed to advertise a certain prefix, and may include a maximum prefix length. When a BGP update arrives, networks running Route Origin Validation (ROV) compare incoming announcements to existing ROAs, classifying them as valid, invalid, or unknown.

Today, only origin validation is supported—validating the AS path (i.e., the precise route the packet followed) is a different, more involved mechanism (BGPsec) that is much less widely deployed.

In brief: RPKI provides a means to assert a stronger ground truth regarding who is authorised to advertise what IP blocks. That adds a guardrail to global routing.

History, standards and governance

RPKI and its supporting standards emerged through the IETF’s SIDR (Secure Inter-Domain Routing) working group.

Key reference documents include RFC 6480 (the RPKI architecture), RFC 6482/6483 (ROA profiles and validation), and RFC 6810 (the RPKI-to-Router protocol).

Each of them the RIR can be considered a trust anchor. They issue resource certificates to Local Internet Registries (LIRs) or other resource holders, reflecting their allocation of IP prefixes and AS numbers. Those resource certificates form a hierarchy that underlies ROA issuance.

Operators may choose to run their own certificate authorities or delegate to a hosted RPKI service offered by the RIR.

On the consumer side, routers fetch validated data from relying-party validators. These validators collect ROA data from the distributed RPKI repositories (via protocols such as rsync or RRDP — the RPKI Repository Delta Protocol).

But there is no single organisation enforcing uptake. The effectiveness of RPKI is strongly dependent on network effects: as more networks adopt both origin signing and validation, the value increases for each participant.

Benefits of RPKI for routing security

Preventing obvious hijacks and misconfigurations

A major gain is in catching unauthorised origin announcements. If a network tries to announce a prefix it doesn’t have rights over, peers running ROV can label that announcement invalid and drop or deprioritise it. This reduces the risk of straightforward prefix hijack.

Even many routing errors stem from simple misconfigurations or “fat finger” mistakes. RPKI helps mitigate those.

Containing blast radius

Because routing is interdependent, one misbehaving network can cause disruption far beyond itself. By rejecting invalid origins early, RPKI can help contain the damage.

Signalling trust and accountability

Having ROAs publicly recorded provides transparency. Other network operators can see which prefixes are signed, and that sends a message about operational discipline and network hygiene.

Enabling future enhancements (and path validation)

While RPKI today is largely about origin validation, it forms part of the groundwork for more advanced routing security, including BGPsec (path validation) or extensions like ASPA (AS Path Authorization).

In the longer term, a global infrastructure of RPKI could raise the cost of route hijacks to attackers and improve overall trust in interdomain routing.

Current state of adoption & challenges Deployment statistics and gaps

Coverage of ROAs has grown but remains partial. As of recent measurements, roughly 40–50 % of IPv4 prefixes have valid ROAs, and a similar or slightly higher share for IPv6.

However, fewer networks actively enforce ROV at their routers. Cloudflare, for instance, maintains data on “origin signing” versus “origin validation” adoption.

The discrepancy between signing and validation is a critical gap: the protection works only when both sides engage.

Operational fear: false positives and connectivity loss

One reason some operators hesitate is fear of false positives — misconfigured ROAs might wrongly label legitimate announcements as invalid, causing unintended route drops.

Operators may also worry that enforcing invalid-route rejection could disconnect them from destinations. These risks require cautious planning, staging, and fallback policies.

Relying-party and repository vulnerabilities

Recent research has uncovered vulnerabilities in RPKI validator software (“relying parties”). For example, CUREanalysis found flaws enabling route poisoning or the disabling of validation logic.

Another attack class (Stalloris) showed how an attacker might block the retrieval of repository data, forcing routers to fallback to insecure operation.

A 2024 systemic study noted that 56 % of global RPKI validators suffer at least one documented vulnerability.

One effort to mitigate is Byzantine-secure relying party (BRP) design, which seeks to decentralise validation and improve resilience.

Fragmented policies and inconsistent enforcement

ROA and validation logic include ambiguous or underspecified cases in RFCs. That has led to divergent behaviours across implementations.

Some networks enforce filtering strictly, others use only monitoring, and yet others partially enforce based on prefix categories.

Because routing is global, inconsistent policies reduce the security gains. If only some routers drop invalids, malicious announcements may still propagate through lenient paths.

Scalability, automation, and tooling

Some operators cite ease, complexity, and lack of tooling as obstacles. Automating ROA management, synchronising validator caches, and integrating with routing platforms remain challenges.

Moreover, the reliance on rsync for repository synchronisation is considered insecure or inefficient by some experts—leading to proposals to favour RRDP.

Some networks delay ROA issuance until validation is widely adopted; but that perpetuates slow uptake.

Best practices for operators deploying RPKI

Start with monitoring mode
Deploy ROV passively (mark invalid but don’t drop). Monitor for unintended invalids before enforcing.
Careful ROA design
Use conservative maxLength settings. Avoid overly broad or overly strict prefixes that may accidentally invalidate legitimate announcements.
Staged enforcement and fallback
Begin rejecting invalid routes only after sufficient observation and with fallback paths. Gradually tighten enforcement.
Robust validator infrastructure
Use multiple validator instances, choose reliable software, monitor gaps, and consider fallback to resilient systems like BRP.
Keep ROA and validator data fresh
Synchronise frequently, watch for repository failure, and ensure mitigations when data is stale.
Coordinate with peers and upstreams
Encourage others in the path to validate. Participation by many networks reinforces the benefit.
Follow community initiatives like MANRS
Standards such as routing hygiene guidelines complement RPKI adoption.
Audit and update regularly
ROAs should be reviewed periodically. Changes in AS ownership, mergers or IP reallocation demand updates.

The “network effect” dilemma and incentives

A big obstacle is that the benefit accrues only when many networks validate. An operator that signs but its peers don’t is less protected. Conversely, enforcing validation risks breaking connectivity to non-conforming networks. This tension slows deployment.
Some argue that regulation or industry incentives may help. Others suggest economic reasons: network operators offering “secure transit” may charge a premium if they enforce ROV. Also, content providers may demand ROV compliance from hosting providers for security.
Legal concerns also arise. One paper on legal barriers noted that courts would rarely find RPKI certificates defective if the RIRs follow IETF standards.

Key limitations and residual risks

Even with perfect origin validation, RPKI does not prevent all BGP attacks:
- Path manipulation: RPKI does not check every AS hop; attackers may still falsify AS paths. That is addressed by proposed BGPsec, which remains largely unimplemented.
- Downgrade attacks and repository interference: If attackers block RPKI repositories or prevent validator access, networks may default back to insecure routing.
- Vulnerable validator software: As seen in recent audits (CURE), bugs may lead to mis-validations or route poisoning.
- Partial or inconsistent policies: If parts of the Internet do not enforce or sign ROAs, invalid routes may still slip through lenient corridors.
- Operational mistakes: Misconfigured ROAs or neglecting updates can cause collateral damage.
Thus, RPKI is an important improvement, not a panacea. Its full value emerges when combined with other measures like route filtering, peer-level hygiene, and eventually path validation systems.

The road ahead: what needs to happen

Validator resilience and decentralisation: Broad use of robust architectures (e.g., BRP) to mitigate dependence on single points of failure.
Improved tooling and automation: Better interfaces, integration with routing systems, alerts, and lifecycle ROA management tools.
Community coordination and incentives: Peers, IXPs and operators signing mutual agreements, or even stipulating ROV compliance for interconnects.
Increased awareness and training: Many ISPs and network teams still lack familiarity with RPKI.
Complementary standards deployment: ASPA, BGPsec and related standards must mature and see real adoption.

If the above align, the Internet’s routing fabric becomes much more robust against hijack and leaks over time.

FAQs: RPKI and routing security

1. What does it mean when a route is declared “invalid”?
If a BGP announcement is invalid per ROV (i.e. not covered by any ROA, or the origin AS does not match), routers may drop it, deprioritise it, or place it in a lower preference.

2. Can a prefix have more than one ROA?
Yes. Multiple ROAs may exist for the same prefix (with potentially different valid origin ASes). The validation logic must handle union or conflicts carefully.

3. Does RPKI guarantee complete routing security?
No. RPKI covers only origin assurance, not full path verification. Attackers may still spoof AS paths or cause other anomalies.

4. What if validator data is stale or unreachable?
Routers may default to treating announcements as unknown (i.e. permit them). But if connectivity fails, that fallback could be abused (a downgrade vector).

5. How can small networks or content hosts adopt RPKI?
They can use hosted RPKI services from their upstream ISP or RIR. Even if they don’t run their own validator, they can issue ROAs and signal origin authorisation.