The Long Tail of RPKI Publication Servers
Border Gateway Protocol (BGP) lacks built-in trust. Resource Public Key Infrastructure (RPKI) fixes that by letting IP address holders cryptographically authorize which Autonomous System (AS) may originate their prefixes via Route Origin Authorizations (ROAs). The trust chain anchors at five Regional Internet Registries (RIRs).
Most ROAs are published by the RIRs themselves. But a long tail of smaller, independently operated publication servers exists—run by cloud providers, ISPs, hobbyists, educational institutions, and RPKIaaS companies. APNIC researchers investigated who operates those small servers and why.
Defining "Small"
The researchers used a straightforward ROA-count-based definition: a server is "small" if it announces fewer than 1,300 ROA objects. That threshold was chosen by inspecting the empirical cumulative distribution function (ECDF) of ROA counts across all known RPKI servers. The distribution is heavily skewed—a handful of large providers (the five RIRs and AWS) account for most ROAs. The 1,300-ROA cutoff captures the natural break between those large players and the rest.
Notable exclusion: AWS RPKI Repository Delta Protocol (RRDP) servers. Amazon's RPKI publication infrastructure is architecturally distinct enough to warrant separate study.
Why Run Your Own Server?
| Reason | Explanation |
|---|---|
| RPKIaaS | Offer RPKI as a managed service with a uniform REST API, enabling customers to automate resource management without interacting with RIR portals directly. |
| Cross-RIR simplicity | Organizations with IP allocations from multiple RIRs can update all their ROAs from a single interface. |
| Research and education | Academic institutions and hobbyists can run Krill (NLnet Labs' open-source CA software) to experiment with RPKI. |
| Operational control | Full control over publication schedules, object signing, and infrastructure—useful for organizations with strict security requirements. |
| Fun / learning | Running your own RPKI server deepens understanding of internet routing infrastructure. |
The Data: 2,467 ROAs from 1,163 ASes
Using Routinator API (version 0.15.1), the researchers fetched all ROA objects from qualifying publication servers as of 23 April 2026. The dataset spans 2,467 unique ROAs covering 3,778 prefixes across 1,163 unique ASes.
| Metric | Value | Note |
|---|---|---|
| IPv4 prefixes with ROA coverage | 1,409 | Covering ~698,000 addresses |
| IPv6 prefixes with ROA coverage | 2,369 | Astronomical address range |
| IPv4 fraction of Internet | 0.0162% | Tiny but non-trivial |
| Total ROA objects | 3,778 | Across 1,163 unique ASes |
| Valid ROA objects | 3,444 (91%) | Passing cryptographic validation |
| Invalid ROA objects | 48 (1.2%) | Failing cryptographic validation |
| Unknown | 286 (7.6%) | Excluded from further analysis |
| ROAs using maxLength | 53.98% | The set maxLength is lower than the prefix bits |
| maxLength ROAs with no BGP coverage | 19.6% | Potentially at risk of sub-prefix hijack |
The covered IPv4 space (698,000 addresses, or 0.016% of all IPv4 addresses) and IPv6 space look small, but it's far from insignificant. The dataset includes prefixes hosting government services (e.g., gov.ai, the Government of Anguilla). Failure of these servers wouldn't break the Internet, but could quietly make parts of it unverifiable for a subset of users.
None of the unknown ROA objects had active BGP announcements—good news, since it indicates those prefixes aren't vulnerable to BGP hijacks.
Strange Servers in the Dataset
r.magellan.ipxo.com: Largest and Most Complex
With 776 prefixes, the Magellan server (operated by IPXO) is the largest in the dataset. All 776 are IPv4, 100% are BGP-reachable, but 103 are flagged as at-risk due to broad maxLength settings without full BGP coverage of the authorized range.
repo.rpki.space: Spam Infrastructure
With 8 Firehol level 1 blocklist matches out of only 79 prefixes, repo.rpki.space stands out. Inspection of BGP Tools DNS records reveals a high density of mailing domains—strongly suggesting spam mailing infrastructure is hosted across those prefixes. Why would a spam operator run their own RPKI server? The RIRs have active abuse prevention procedures; an independent publication server adds an extra step in the takedown chain, creating operational friction for abuse reporters.
ca.nat.moe: 99 Unknown Objects
This server is a striking outlier: every single one of its 99 ROA objects has unknown validity status—all 99 failed cryptographic validation. Despite that, 100% are BGP-reachable and 64 use maxLength.
rpki-01.pdxnet.uk: The maxLength Puzzle
This server announces almost half its prefixes with maxLength set to 32 (IPv4) or 128 (IPv6)—the maximum possible prefix length. That means every IP address within the announced range is formally authorized. In practice, it's not exploitable: BGP doesn't accept prefixes more specific than /24 for IPv4 or /48 for IPv6, and the underlying prefixes are already at those limits. The reason for this configuration remains unexplained.
Where Does the IP Space Come From?
When an organization publishes ROAs on its own server, a natural expectation is cross-RIR allocations (IP space from multiple registries) making a single publication point convenient. The data tells a more nuanced story.
A sizable proportion of servers announce prefixes from only a single RIR (mainly RIPE). For servers drawing exclusively from RIPE, one of the most compelling reasons for running a custom server (avoiding managing multiple RIR accounts) does not apply.
The maxLength Problem
More than half of all ROA objects in the dataset (53.98%) use the maxLength parameter to authorize announcements for prefixes more specific than the one listed in the ROA. RFC 9319 explicitly discourages this practice. An ROA for 103.0.0.0/22 with maxLength /24 does exactly what you'd expect—it authorizes any /24 within that /22. While convenient, it broadens the attack surface for sub-prefix hijacks.
What You Should Do
If you manage IP space and use RPKI, audit your ROAs for maxLength usage. If you operate a small RPKI server, check your cryptographic validity—ca.nat.moe shows it's possible to have 100% failure without noticing. For those considering running their own server, weigh the operational overhead against the convenience of cross-RIR management. The long tail of small servers is here to stay, but it needs better hygiene.
