Network Security

Who's Running All Those Tiny RPKI Servers? Understanding the Distributed Infrastructure Securing BGP Routes

Explore the landscape of small, independently operated RPKI publication servers supporting BGP route security, their operators, functions, and how understanding

Published 13 Aug 2026Updated 17 Aug 20267 min read

Reviewed by QCS Network & Security Engineering

Diagram showing the distributed ecosystem of RPKI servers with large RIR nodes and many smaller independent servers supporting BGP route validation

Direct answer

The tiny RPKI servers running alongside the five major Regional Internet Registries (RIRs) are operated by a diverse group including cloud providers, ISPs, educational institutions, hobbyists, and RPKI-as-a-Service companies. These small servers publish Route Origin Authorizations (ROAs) that cryptographically authorize Autonomous Systems (ASNs) to announce specific IP prefixes, supporting the global RPKI framework that secures BGP routing against prefix hijacks.

Operators run independent servers to achieve cross-RIR simplicity, operational control, research and learning, or to provide managed

Key Takeaways

  • RPKI servers are not just run by the five RIRs; many small, independent operators run servers publishing ROAs.
  • Small servers often serve organizations with IP space from multiple RIRs, providing a unified management interface.
  • More than half of ROAs use the maxLength parameter, which can increase risk of sub-prefix hijacks if misconfigured.
  • ROA validation rates are high (~92%), but some unknown and invalid objects suggest areas for scrutiny.
  • Running an independent RPKI server offers operational control, research opportunities, or managed RPKI services.
  • BGPsec is not yet deployed in practice, limiting path security beyond RPKI.

Terms Used in This Guide

RPKI
Resource Public Key Infrastructure, a cryptographic system that secures IP prefix announcements in BGP by authorizing which AS can originate specific IP prefixes.
ROA
Route Origin Authorization, a signed record stating that an AS is authorized to announce an IP prefix.
BGP
Border Gateway Protocol, the main routing protocol that determines how packets are routed across the internet among different Autonomous Systems.
ASN
Autonomous System Number, a unique identifier assigned to each network on the internet that participates in BGP routing.
maxLength
An optional ROA parameter that specifies the maximum prefix length an AS is authorized to announce, often used for prefix aggregation but can introduce risks if set too broadly.

What Is RPKI and Why Does It Matter?

The Border Gateway Protocol (BGP) directs internet traffic by announcing which networks (Autonomous Systems, ASNs) originate which IP prefixes. However, BGP inherently trusts these route announcements without verification, allowing accidental or malicious prefix hijacks. The Resource Public Key Infrastructure (RPKI) mitigates this risk by letting IP address holders cryptographically authorize which ASNs may originate their prefixes via Route Origin Authorizations (ROAs).

RPKI enables routers implementing Route Origin Validation (ROV) to drop invalid or unauthorized BGP announcements, improving routing security and preventing traffic interception or outages. [1]

  • BGP controls inter-domain routing but lacks built-in trust.
  • RPKI uses cryptographic signatures to authorize AS-originated prefixes.
  • ROAs specify allowed ASN-prefix mappings.
  • ROV-enabled routers validate BGP announcements against ROAs.
  • The trust anchor for RPKI is the five Regional Internet Registries (RIRs).

Who Runs the Small RPKI Publication Servers?

While the five RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) publish most ROAs, many small independent RPKI publication servers exist globally. These 'small' servers each publish fewer than 1,300 ROAs and are operated by a variety of organizations including cloud providers, ISPs, hobbyists, educational institutions, and specialized RPKI-as-a-Service (RPKIaaS) companies. Their existence supports diverse operational and security needs outside the centralized RIR infrastructure. [1]

  • Small RPKI servers are defined as those announcing fewer than 1,300 ROAs.
  • Operators include cloud providers, ISPs, hobbyists, universities, and RPKIaaS firms.
  • They often provide unified interfaces for organizations with IP allocations from multiple RIRs.
  • Some servers are personal or experimental setups by hobbyists and researchers.
  • This distributed model complements the centralized RIR servers to enhance route origin validation coverage.

Why Operate an Independent RPKI Server?

Organizations choose to run their own RPKI publication servers for various reasons. Some seek operational control over signing and publication for security or routing policy needs. Others offer RPKI as a managed service with consistent APIs simplifying ROA management for clients.

Managing multiple RIR allocations through one interface makes cross-RIR resource handling easier. Educational and research institutions run servers for experimentation. Hobbyists run servers to learn and contribute to internet infrastructure. [1]

  • Operational control for security and custom routing policies.
  • Simplify cross-RIR management for organizations with diverse IP allocations.
  • Offer RPKI as a managed service with unified API access for customers.
  • Research, experimentation, and learning by educational institutions and hobbyists.
  • Strengthen route security by expanding ROA publication beyond RIRs.

ROA Coverage, Validation, and Risks

Analysis of small RPKI servers shows they cover a modest but notable portion of the internet's IP space, including key services like government domains. Validation of ROAs is generally successful, with about 92% being cryptographically valid and 91% linked to active BGP announcements.

However, some ROAs are unknown or invalid, and over half use the maxLength parameter, which allows delegating announcements of more specific prefixes within the authorized range. Improper maxLength use can create vulnerabilities to sub-prefix hijacks, especially when authorized sub-prefixes lack current BGP announcements. [1]

  • Small servers cover around 0.016% of IPv4 addresses and significant IPv6 space.
  • 91% of ROAs publish cryptographically valid Route Origin Authorizations.
  • 7.6% of ROAs have unknown status (failed validation or expired).
  • Over 53% of ROAs use maxLength, which can aggregate prefix authorizations.
  • Approximately 19.6% of maxLength-using ROAs have at-risk sub-prefixes without BGP coverage.
  • Potential for sub-prefix hijacks if these configurations are exploited.

Operational Implications for ISP and Cloud Teams

Understanding who operates these small RPKI publication servers and how ROAs are published is critical when making changes to BGP, ISP, or cloud connectivity. ROA misconfigurations, especially involving maxLength, risk route-origin validation failures or sub-prefix hijacks, potentially causing traffic misdirection.

Teams should audit ROAs related to their prefixes, ensure maxLength settings align precisely with intended announcements, and consider consolidating or managing ROA publication consistently when spanning multiple RIRs or using RPKIaaS providers. Deploying ROV on routers is essential to leverage RPKI benefits. [1]

  • Audit all ROAs associated with your ASN and prefix space regularly.
  • Avoid broad maxLength values; set maxLength equal to the announced prefix length.
  • Use centralized or managed RPKI services to simplify cross-RIR resource management.
  • Implement Route Origin Validation (ROV) on routers to filter invalid BGP announcements.
  • Coordinate with small RPKI server operators if you rely on their services for ROA publication.
  • Be aware that failures or misconfigurations of small RPKI servers can impact route verification reliability.

Beyond RPKI: The Road Ahead for BGP Security

While RPKI provides cryptographic verification of route origins, comprehensive BGP security requires further measures. BGPsec, which authenticates the entire AS path cryptographically, remains undeployed due to complexity and operational challenges. Emerging mechanisms like Autonomous System Provider Authorization (ASPA) and AS path validation aim to mitigate route leaks and path manipulation but require broad adoption to be effective.

The current landscape is a patchwork, with RPKI as the primary practical defense. Vigilance and a layered security approach remain paramount. [1][3]

  • BGPsec cryptographically secures full AS paths but is not yet deployed.
  • AS path validation techniques (ASPA, PAVA) are under development.
  • Partial deployment limits the effectiveness of advanced BGP security mechanisms.
  • RPKI remains the foundational and widely adopted route-origin validation technology.
  • Network operators should plan for gradual adoption of additional security layers.
  • Continued monitoring and proactive ROA management reduce routing risks.

Practical Checklist

Identify all RPKI publication servers relevant to your IP prefixes and ASNs.

Verify ROA validity status, focusing on unknown and invalid objects.

Check ROA maxLength parameters; reduce to exact prefix length where feasible.

Consolidate ROA management if holding addresses from multiple RIRs.

Ensure routers implement Route Origin Validation (ROV).

Engage with RPKIaaS or consider deploying your own publication server for operational control.

Monitor ongoing research and developments in BGP security mechanisms beyond RPKI.

Questions Teams Ask

What is the role of small, independent RPKI servers compared to the RIR servers?

Small, independent RPKI servers complement the five major RIR servers by publishing ROAs for organizations operating across multiple RIR regions, offering managed services, enabling operational control, supporting research, and lowering dependencies on centralized systems. Although they cover a smaller address space, they enhance the diversity and reach of RPKI data, supporting BGP route origin validation. [1]

Why is the maxLength parameter in ROAs considered risky?

maxLength allows a ROA to authorize announcements of prefixes more specific than the main prefix. Overbroad maxLength settings increase risk of sub-prefix hijacks, where an attacker announces a more specific prefix within the authorized range but unauthorized by the owner, and this unauthorized prefix passes RPKI validation. It is recommended to set maxLength equal to the prefix length, or carefully manage sub-prefix announcements with separate ROAs to avoid this risk. [1]

What motivates organizations to operate their own RPKI publication servers?

Organizations run their own RPKI servers to gain full operational control over ROA publication schedules and keys, to unify management of IP resources from multiple RIRs, to offer RPKI as a service with consistent APIs, for research and experimentation, or simply for learning and contributing to routing security infrastructure. [1]

How effective is RPKI in preventing BGP prefix hijacks currently?

RPKI has proven effective in verifying route origins with about 92% of ROA objects valid and 91% corresponding to active BGP announcements. While it significantly reduces accidental or malicious prefix hijacks, limitations include incomplete deployment, unknown or invalid ROAs, and configuration issues such as improper maxLength usage, meaning complementary measures and ongoing vigilance are necessary. [1]

Is BGPsec widely deployed alongside RPKI?

No, BGPsec, which provides cryptographic validation of the full AS path, remains essentially unimplemented in the global internet despite its standardization in 2017. The complexity, partial deployment challenges, and operational overhead have hindered adoption, leaving RPKI route-origin validation as the primary practical BGP security measure today. [1][3]

Sources and Further Reading

How This Guide Was Prepared

Researched from the listed primary and official sources, written for operational decision-making, and reviewed through QCS editorial QA. Sources checked 2026-08-13.

Technical review: QCS Network & Security Engineering, Technical review team.

Continue the decision

Related network and security guidance

Turn this into action

Share your network context and QCS can help validate the next step.

Use the article as preparation. If the issue affects users, exposure, audit evidence, or client delivery, a focused review can turn it into a clear fix path.

Ready when you are. Share the issue and we will suggest the right next step.