Pangram verdict · v3.3
We believe that this document is primarily human-written, with a small amount of AI-assisted content detected
AI likelihood · overall
HumanArticle text · 1,190 words · 5 segments analyzed
Border Gateway Protocol (BGP) lacks built-in trust, leaving the Internet routing layer exposed to accidental or malicious prefix hijacks. Resource Public Key Infrastructure (RPKI) addresses that problem by letting address space holders cryptographically authorize which Autonomous System (AS) may originate their prefixes, via Route Origin Authorizations (ROAs) published through a chain of trust anchored at the five Regional Internet Registries (RIRs).
While most ROAs are published directly by the RIRs, a long tail of smaller, independently operated publication servers (run by cloud providers, ISPs, hobbyists, educational institutions, and RPKI as a Service (RPKIaaS) companies) also contributes to the global RPKI dataset. In this post, we investigate who operates those small servers and why.
What is RPKI and why should you care?
Every time you open a website, your traffic hops across dozens of routers guided by BGP. BGP is the glue of the Internet: It tells routers where to send packets to reach any IP address on the planet. The trouble is that BGP was designed for an era when networks trusted each other, and misbehaviour was still uncommon. Any network can (accidentally or maliciously) announce that it owns an IP prefix it does not actually control. That is called a routing incident, and it can cause your traffic to be silently redirected to the wrong destination.
RPKI is (one of) the Internet’s answers to that problem. It works by letting the rightful owners of IP address blocks cryptographically sign a ROA; a small record that says: ‘IP prefix X is authorized to be announced by Autonomous System Number (ASN) Y.’ Routers that implement Route Origin Validation (ROV) then use those signed records to check incoming BGP announcements and drop the ones that don’t match.
The entire system rests on a chain of trust anchored at the five Regional Internet Registries (RIRs): ARIN (North America), RIPE NCC (Europe/Middle East/Central Asia), APNIC (Asia Pacific), LACNIC (Latin America) and AFRINIC (Africa). Those bodies issue IP address space to networks and operate the top-level RPKI Certification Authorities (CAs). ROA objects can be published directly from the RIR servers, or from smaller, independent publication servers.
Small RPKI publication servers
Most ROA objects are published by the five RIRs, which are well-resourced, professionally maintained and globally trusted. But alongside those giants sits a long tail of smaller publication servers run by cloud providers, hobbyists, educational institutions, Internet Service Providers (ISPs) and RPKIaaS companies. During the research described in this post, we examined these ‘small’ servers to see what we can learn from them, why they operate and why they exist in the first place.
Defining ‘small’
The first methodological challenge was defining what makes a server ‘small’. We used a straightforward, ROA-count-based definition:
A server is classified as ‘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 Amazon Web Services (AWS)) account for most ROAs. The 1,300-ROA cut-off captures the natural break between those large players and the rest.
One notable exclusion: The AWS RPKI Repository Delta Protocol (RRDP) servers. Amazon constructs its RPKI publication infrastructure unusually. Their architecture is distinct enough from the other small servers that it was kept out of scope. Whether that construction offers operational advantages remains an open question for future research.
Why would anyone run their own RPKI server?
The existence of small servers naturally raises the question: Why bother? The RIRs already provide publication services as part of membership.
The answer is that there are several legitimate reasons to operate independently; the table below lists a few examples.
ReasonExplanationRPKIaaSOffer RPKI as a managed service with a uniform REST API, enabling customers to automate resource management without interacting with RIR portals directly or juggling multiple APIs.Cross-RIR simplicityOrganizations with IP allocations from multiple RIRs (for example, ARIN and RIPE) can update all their ROAs from a single interface instead of maintaining accounts at each registry.Research and educationAcademic institutions and hobbyists can run Krill (NLnet Labs’ open-source CA software) to experiment with RPKI, test configurations, or contribute to deployment research.Operational controlFull control over publication schedules, object signing and infrastructure, useful for organizations with strict security requirements or custom routing setups.Fun / learningRunning your own RPKI server is a legitimate way to deepen your understanding of the Internet routing infrastructure. Many of the smallest servers in the dataset appear to be personal or hobby setups.Table 1 — Reasons to operate an independent RPKI publication server.
The dataset: IP space statistics
Using the Routinator API (version 0.15.1), we fetched all ROA objects from each qualifying publication server as of 23 April 2026. The resulting dataset spans 2,467 unique ROAs covering 3,778 prefixes across 1,163 unique ASes. Table 2 summarizes the key numbers.
Valid: At least one Validated ROA Payload (VRP) covering the announced prefix exists (same or less specific, within max length) with a matching origin AS.
Invalid: A Validated ROA Payload (VRP) covering that prefix space exists, but part of the information in the VRP is incorrect, or the object has expired.
Unknown: No VRP was found, or an incorrect VRP was found and has been dropped.
MetricValueNoteIPv4 prefixes with ROA coverage1,409Covering ~698,000 individual addressesIPv6 prefixes with ROA coverage2,369Covering an astronomical address rangeIPv4 fraction of Internet0.0162%A tiny but non-trivial sliceTotal ROA objects analysed3,778Across 1,163 unique ASesValid ROA objects3,444 (91%)Passing cryptographic validationInvalid ROA objects48 (1.2%)Not passing cryptographic validationUnknown286 (7.6%)Excluded from further analysisROAs using maxLength53.98%The set maxLength is set lower than the set bits of the prefixmaxLength using ROAs with no BGP coverage19.6%Potentially at risk of sub-prefix hijackTable 2 — Key statistics for the small RPKI server dataset (data collected 23 April 2026).
A few figures stand out. The covered IPv4 space (698,000 addresses, or 0.016% of all IPv4 addresses) and IPv6 space (addresses or %) both look small, but it is far from insignificant. The dataset includes prefixes hosting government services (such as gov.ai, the official domain of the Government of Anguilla) and potentially other services people rely on daily. The failure of such servers would not break the Internet, but it could quietly make parts of it unverifiable for a subset of users.
None of the unknown ROA objects had active BGP announcements. That is good news, since it would indicate that the prefixes in question are vulnerable to BGP-hijacks.
Inside the numbers: The server overview
Table 3 condenses the per-server statistics from the research. Each row represents one publication server, with columns showing prefix counts, validity breakdown, maxLength usage, BGP reachability and Firehol (a company that combines lists of different abuse lists to try and create a comprehensive and complete list of prefixes to block to ensure an acceptable level of safety) blocklist overlap.
A few rows are shown below as examples.
Server Prefixes Valid Invalid Unknown MaxLength BGP % At-risk Firehol r.magellan.ipxo.com 776 755 18 3 164 100% 103 4 cloudie-repo.rpki.app 504 504 0 0 424 80.8% 147 2 rpki.admin.freerangecloud.com 476 476 0 0 48 100% 28 0 rpki.sub.apnic.net 390 254 28 108 91 98.2% 27 4 krill.47272.net 388 388 0 0 143 96.6% 69 0