RPKI independent servers: control your routing

Over 1,300 Route Origin Authorizations defines the threshold separating substantial players from the long tail of small RPKI publication servers. This number isn't arbitrary; it's the inflection point where the global routing table shifts from centralized registry dominance to a fragmented landscape of independent operators. We need to talk about who runs these servers, why they matter for Route Origin Validation, and whether you should be hosting your own RPKI infrastructure instead of relying on managed services.

BGP has no inherent trust. It believes whatever path it hears first unless you force it to do otherwise. Resource Public Key Infrastructure fixes this by anchoring trust in five Regional Internet Registries using the X.509 certificate system. While these five bodies publish the bulk of records, a significant volume of ROA objects comes from independently operated servers. These aren't just noise; they provide the redundancy and diversity necessary to prevent single points of failure in the authorization chain.

You have three states: valid, invalid, or unknown. If you depend entirely on third-party managed services, you are blind to how those states are calculated or which publication servers influence your routing decisions. Deploying independent solutions like the InterLIR RPKI publication server gives you direct control over cryptographic assertions. It ensures your prefix announcements remain verifiable even if upstream providers or large cloud repositories suffer outages.

The Role of Independent RPKI Servers in Modern Routing Security

RPKI Chain of Trust and ROA Objects Defined

Resource Public Key Infrastructure (RPKI) replaces BGP's implicit trust with a cryptographic hierarchy rooted at Regional Internet Registries. This architecture extends the X.509 standard to bind IP address blocks and Autonomous System numbers to specific certificate holders. Address space holders cryptographically authorize which Autonomous System originates their prefixes, solving BGP's inherent trust deficit. The resulting Route Origin Authorization (ROA) object acts as a signed statement verifying that a prefix owner permits a specific AS to originate routes for that space. Network operators download these validated records to filter announcements, preventing malicious route hijacks and misconfigurations. Security depends on the legitimate resource holder possessing the private key required to sign valid ROAs, creating a verifiable link between address ownership and routing authority.

Incomplete data breaks this model. Routers default to an "unknown" state when a prefix lacks a corresponding ROA rather than rejecting the path. Such gaps leave networks vulnerable to accidental leaks despite available validation tools. The framework enables address space holders to issue ROA objects authorizing one or more Autonomous Systems to originate BGP routes for specific IP address blocks, basing routing decisions on cryptographic proof instead of implicit trust.

Identifying Small RPKI Servers via ECDF Thresholds

A small RPKI server announces fewer than 1,300 ROA objects, a threshold derived from empirical cumulative distribution function analysis. This metric distinguishes independent operators from substantial Regional Internet Registries and large cloud providers like Amazon Web Services (AWS). ECDF inspection reveals a natural break in the data distribution, separating the massive scale of RIRs from the long tail of independent publishers. AWS RPKI Repository Delta Protocol servers were excluded from the study due to distinct architecture.

Network operators using RPKI tools must recognize that independent servers often host Route Origin Authorizations for specific use cases, such as multi-RIR management or research. These smaller nodes offer granular control unlike the centralized pools managed by ARIN or RIPE NCC, yet they require vigilant monitoring to maintain validity. Strong routing security emerges across this fragmented publication environment where independent servers contribute to the global dataset alongside the five primary RIR anchors.

RIR Anchors Versus Independent Publication Servers

Five Territorial Internet Registries act as primary anchors for the global trust chain while independent servers extend dataset coverage. This hierarchical structure ensures that Route Origin Authorizations originate from ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC before propagating to the wider network. Operators categorize validation outcomes into exactly three states: valid, invalid, or unknown, based on cryptographic matches against these published records. Independent publication points run by cloud providers or ISPs contribute to the global pool but lack the inherent authority of the RIR trust anchors.

Organizations optimizing IPv4 utilization benefit from centralized management that abstracts these complex synchronization requirements without compromising the integrity of the global routing table. Network operators configure their Route Origin Validation (ROV) systems to accept valid ROAs from diverse sources while rejecting invalid announcements by understanding the distinction between RIR anchors and independent publishers.

Inside the Mechanics of Route Origin Authorization and Validation

X.509 Certificates and RFC 3779 Extensions in RPKI

RPKI adapts the existing X.509 public key infrastructure, the same standard utilized for TLS/SSL authentication, to secure Internet routing resources. This framework relies on RFC 5280 for base certificate rules while employing RFC 3779 extensions to embed IP address blocks and Autonomous System numbers directly into digital certificates. Binding these resources cryptographically creates a verifiable chain of trust that prevents BGP hijacking without requiring new protocol layers. A route achieves a "valid" state only when a Route Origin Authorization matches both the prefix and the originating AS number exactly.

Operational rigidity follows strict adherence to these cryptographic signatures; any mismatch in prefix length or AS number results in an "invalid" classification. Legitimate traffic drops if ROA records are not meticulously maintained. Network operators must balance this security gain against the risk of self-inflicted outages caused by stale or incorrect signing data.

Resolving Valid, Invalid, and Unknown Validation States

Routers categorize every BGP announcement into exactly three distinct states: valid, invalid, or unknown, based on cryptographic matches against published Route Origin Authorizations. This logic drives immediate enforcement actions across the network edge. Operators validate ROA objects by comparing incoming prefix and AS number pairs against a locally cached filter derived from the global RPKI dataset. A route achieves a valid status only when a matching ROA exists authorizing the specific origin AS for that exact prefix length.

Any deviation, such as an unauthorized origin or exceeded max-length, triggers an invalid state, signaling a potential hijack or configuration error. If no covering ROA exists, the system returns an unknown state, leaving the final routing decision to local policy rather than cryptographic proof. Network operators use these validation results to enforce strict filtering policies, often rejecting invalid paths while accepting valid ones. Unknown status resolution remains dependent on local policy until coverage expands.

The maxLength Parameter Risk and RFC 9319 Warnings

Configuring the maxLength parameter in Route Origin Authorization objects introduces specific validation gaps that broaden the attack surface for sub-prefix hijacking. Data indicates that 53.98% of existing ROA objects apply this parameter, a configuration practice explicitly discouraged due to inherent security trade-offs. The primary risk emerges when broad length settings authorize potential announcements that never materialize in normal operations.

Approximately 80% of ROAs with generous maxLength values have corresponding BGP announcements for those specific sub-prefixes, validating the broader scope. However, the remaining 19.6% possess no active BGP announcement covering the authorized sub-prefix space. This gap creates a condition where a malicious actor announcing a more specific sub-prefix can pass RPKI validation because the cryptographic signature technically permits the longer prefix length. Operators must recognize that cryptographic validation confirms authorization, not intent or active usage.

Strategic Advantages of Self-Hosted RPKI Infrastructure Over Managed Services

Defining Independent RPKI Server Motivations and Control Models

Independent RPKI servers exist primarily to enable RPKIaaS offerings that automate resource management through uniform REST APIs. This architecture allows providers to bypass direct interaction with RIR portals, streamlining operations for customers requiring programmatic control. Organizations managing IP allocations across multiple registries apply these systems for Cross-RIR simplicity, consolidating ROA updates into a single interface rather than maintaining disparate accounts. Academic institutions and hobbyists often deploy Krill software from NLnet Labs to enable Research and education, experimenting with routing security in isolated environments. A distinct driver remains Operational control, granting entities with strict security mandates full authority over publication schedules and infrastructure configuration.

The Internet Engineering Task Force (IETF) established the framework to secure origin information, yet centralized tools often lack the flexibility required for complex, multi-tenant environments. While RIR portals suffice for simple deployments, they introduce latency when coordinating changes across different regional policies. Independent servers resolve this by decoupling the signing mechanism from the registry user interface. However, this approach demands local expertise to maintain the publication point and ensure synchronization with upstream trust anchors.

Axivora Case Study: Educational Research and Dedicated IPv6 Allocations

Axivora leases two dedicated IPv6 PA /40 allocations specifically to support education and research initiatives. The operator stated they started running their own RPKI publication infrastructure because they were Internet enthusiasts who wanted to understand how the system works. While their commercial prefixes apply RIPE's PaaS services, they maintain a private server for fun and learning purposes. This hybrid approach illustrates that self-hosted solutions serve distinct research goals rather than replacing managed services for all use cases. The table below contrasts these operational models across key dimensions.

The Krill software from NLnet Labs enables this granular experimentation by providing an open-source CA platform. Deploying such infrastructure allows operators to validate BGP prefixes and prevent route hijacking attacks in controlled environments, similar to implementations at substantial exchange points demonstrating real-world feasibility. However, the trade-off is significant: independent operation demands continuous monitoring and updates that managed services absorb.

Single-RIR Versus Multi-RIR Server Deployment Strategies

Analysis shows a sizable proportion of servers announce prefixes from only a single RIR, mainly RIPE. For servers drawing exclusively from RIPE, the motivation of avoiding multiple RIR accounts does not apply, shifting the primary driver for self-hosting to achieving strict Operational control over publication schedules. Specific server origins include r.magellan.ipxo.com and cloudie-repo.rpki.app which apply ARIN and RIPE resources. This distinction dictates the architectural requirements for the publication server software stack.

Relying on a single RIR limits future expansion; adding APNIC or LACNIC space later requires significant re-architecture of the validation pipeline. The RPKI framework relies on X.509 certificates, meaning each additional RIR introduces a new root of trust to manage securely. Organizations must weigh current regional focus against potential global growth before locking into a simplified deployment model.

Implementing Automated ROA Management with Krill and REST APIs

Krill Software Architecture for Independent RPKI Servers

Krill is open-source CA software by NLnet Labs used to experiment with RPKI and establish independent publication points. This architecture grants operators full Operational control over signing schedules, a necessity for entities with strict security mandates or Cross-RIR simplicity requirements. Unlike centralized RIR portals, running your own server allows for automated ROA management via REST APIs without manual portal interaction. Notable implementations of such independent infrastructure include Axivora, which operates rpki.cc, krill.accuristechnologies.ca, and rpki.folf.systems.

The implementation process for Krill follows a specific sequence:

1. Install the software stack on a dedicated server environment.
2. Direct REST API calls replace manual RIR portal clicks to publish ROA objects instantly.

Operators script HTTP requests against a uniform interface, bypassing the varied web forms of regional registries like ARIN. This approach enables continuous integration pipelines to sign route origin authorizations automatically whenever prefix assignments change.

1. Authenticate to the local publication server using API keys.
2. Submit a JSON payload defining the prefix, ASN, and max length.
3. Trigger the signing process to update the local RPKI dataset.

This method supports Cross-RIR simplicity by aggregating multi-registry resources into one automated workflow. Analysis shows that valid ROA objects account for 3,444 (91%) of the dataset, suggesting automation reduces human error in configuration. However, relying on a single API endpoint introduces a central point of failure within the operator's own infrastructure. If the local controller loses connectivity, new route announcements cannot be authorized until service restoration. Deploying redundant API gateways helps maintain publication availability during local outages. Network architects must balance the efficiency of automated scripts against the risk of localized control plane failures.

Validating ROA Lifecycle States and BGP Coverage

Confirming that route objects transition from unknown to valid states prevents routing leaks before they impact traffic. Operators must verify that published data matches active BGP announcements to maintain integrity.

1. Query the local validator to categorize all prefixes into valid, invalid, or unknown states.
2. Audit maxLength parameters, as significant portions of these records often lack corresponding BGP coverage.
3. Cross-reference active announcements against the cryptographic filter to ensure no unauthorized sub-prefixes exist.

Uncovered maxLength entries represent a specific vulnerability where attackers could announce more specific prefixes. While most objects achieve valid status, the gap between signed authority and active routing remains a measurable risk. Automated lifecycle validation ensures IPv4 resources remain secure without manual polling. Relying on independent verification tools often introduces latency that centralized management avoids. Network operators should prioritize closing the gap between authorization and announcement to eliminate potential hijack vectors.

References

• Resource Public Key Infrastructure (RPKI) - American Registry for
• Resource Public Key Infrastructure (RPKI): Resource Public Key Infrastructure
• Enhancing Route Origin Validation by Aggregating Validated ROA Payloads