Internship report: Who's running all those tiny RPKI servers?

What is RPKI and why should you care?

Every time you open a website, your traffic hops across dozens of routers guided by the Border Gateway Protocol (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.

The Resource Public Key Infrastructure (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 Route Origin Authorization (ROA); a small record that says: "IP prefix X is authorised to be announced by Autonomous System (AS) number 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. 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 RPKI as a Service (RPKIaaS) companies. During the research described in this blog, we had a look at 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.

Table A: 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. The table below summarises the key numbers.

Valid: at least one 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.

Table B: 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 (adresses 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

The table below 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.

Table C: Condensed overview of analysed RPKI publication servers (top 15 by prefix count). 'At-Risk' = maxLength ROAs with no corresponding BGP announcement for the authorised sub-prefixes.

In the remainder of this section, we will point out some servers that exhibit strange behaviours and describe the uncommon behaviours they exhibit.

r.magellan.ipxo.com: the largest and most complex

With 776 prefixes, the Magellan server operated by the company IPXO is the largest in the dataset. All 776 are IPv4, and 100% are BGP-reachable, but 103 are flagged as at-risk due to broad maxLength settings without full BGP coverage of the authorised range.

Repo.rpki.space: spam infrastructure

With 8 Firehol level 1 blocklist matches out of only 79 prefixes, repo.rpki.space stands out immediately. Inspection of BGP Tools DNS records for this server reveals a high density of mailing domains, strongly suggesting that spam mailing infrastructure is hosted across the prefixes in question. One potential reason a spam operator would run their own RPKI server: the RIRs have active abuse prevention procedures, and having an independent publication server adds an extra step in the takedown chain; a layer of 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, meaning all 99 failed cryptographic validation. Nevertheless, of the valid objects, 100% are BGP-reachable and 64 use maxLength..

rpki-01.pdxnet.uk: the maxLength puzzle

This server announces almost half of its prefixes with maxLength set to 32 (IPv4) or 128 (IPv6): the maximum possible prefix length. That means that every IP address within the announced range is formally authorised. In practice, that is not exploitable: BGP does not 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 unusual configuration remains unexplained.

Where does the IP space come from?

One of the most interesting structural findings concerns the RIR origin of prefixes announced by small servers. When an organisation publishes ROAs on its own server, a natural expectation might be that it has cross-RIR allocations (i.e. IP space from multiple registries), which would make a single publication point convenient. The data tells a more nuanced story.

Table D: RIR origin presence per publication server (condensed first 18 servers). A checkmark indicates that at least one prefix from that RIR was present in the server's ROA set.

A sizable proportion of servers announce prefixes from only a single RIR (mainly RIPE). For servers that draw 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 authorise announcements for prefixes more specific than the one listed in the ROA. RFC 9319 explicitly discourages that practice.

An ROA for 103.0.0.0/22 with maxLength /24 does not just authorise the /22; it authorises every /23 and /24 within that block, 103.0.0.0/24 through 103.0.3.0/24, without requiring a separate ROA for each. From a BGP perspective, the most specific matching prefix wins. So, if an attacker who controls the authorised AS number announces 103.0.0.0/24 (in principle), every relying party will mark it valid. The broader ROA has authorised the hijack (if there is no competing BGP announcement that is faster, and the announcement is RPKI valid).

Of the ROAs with a broad maxLength setting, approximately 80% already have the more specific sub-prefixes covered by existing BGP announcements, meaning the actual exposure is limited in most cases.

However, the remaining 19.6% have no BGP announcement covering the authorised sub-prefixes. Those represent potentially at-risk configurations: a sub-prefix hijack using the legitimate origin of the ASN could pass RPKI validation unchallenged (again if there is no competing BGP announcement that is faster, and the announcement is RPKI valid).

The fix is straightforward in principle: create a separate ROA for each prefix you intend to announce and set maxLength equal to the prefix length itself. The downside is that that increases ROA count significantly: exactly the opposite of the aggregation benefit that maxLength was designed to provide.

BGPsec

BGPsec is a method that verifies whether the announced BGP route has been cryptographically validated by every single AS in its path. That means that BGPsec verifies whether every AS in the announced path agrees that the path is valid. Even though BGPsec has been standardised since 2017, we found that (not only in our dataset) BGPsec is simply not deployed (having only a single AS announcing its routing keys) as also noted by Lisa Bruder in her blog post: BGPsec - Could you run it if you wanted to?.

A word from one of the operators

We have reached out to one of the bigger operators (Axivora which operates: rpki.cc, krill.accuristechnologies.ca and rpki.folf.systems) to understand why they run their own RRDP notification server, and we got the following response:

The short answer is that we originally started running our own RPKI publication infrastructure because we were (and still are) Internet enthusiasts who wanted to understand how the system actually works.

Axivora still leases two dedicated IPv6 PA /40 allocations for educational and research purposes. Within those prefixes, they delegate smaller allocations to individuals who want their own independent address space. They handle the logistics of creating the corresponding ROA and IRR records for them, and they eliminate the need for them to operate their own ASN.

The original reason for running their own publication infrastructure was to get a better understanding of the RPKI ecosystem and to learn how ROAs propagate through the internet.

Today, all their business prefixes use RIPE's PaaS services, yet they continue to operate their own publisher server for research, educational and experimental purposes.

And, admittedly, we still think it's pretty cool.

Conclusion

Taken together, the data suggests that small RPKI publication servers cover a relatively modest corner of the internet. Even though the prefixes they cover are tiny in aggregate, they include some crucial services such as government domains. While the failure of such servers would not break entire the internet, it would have ramifications for the verifiability of the internet and potentially break specific prefixes, making them unreachable.

On the validation side, the picture seems relatively healthy: 92.4% of the ROA objects are valid and, of those objects, 91% carry an active and matching BGP announcement. The only notable metric here is that the unknown rate of 7.6% is relatively high.

A clearer area that raises some concern is the usage of maxLength. More than half of the ROA objects did not adhere to the recommendations of RFC 9319, which is not inherently problematic. However, 19.6% of those did not have BGP announcements that covered all sub-prefixes they permitted. Leaving a relatively limited but relevant risk of sub-prefix hijacks. That risk is, however, not exclusive to those publication servers and could very well exist with larger publication servers as well.

Other protective technologies had similarly not been deployed on the set of servers we studied. BGPsec was not deployed at all.

As for why operators choose to run their own infrastructure; the data broadly suggests cross-RIR simplicity as the dominant reason, but not the only one. Educational purposes proved to be a less common motivation than initially expected.