RPKI’s 2025 year in review

Happy New Year! If you want to know how Resource Public Key Infrastructure (RPKI) evolved throughout 2025, read on! 🙂

In this post, I’ll share some RPKI statistics, summarize highlights from the Internet Engineering Task Force (IETF) standards development process, and reflect on emerging trends.

Year-to-year growth of the distributed RPKI database

A straightforward method to compare 2024 and 2025 is to examine the absolute numbers. Table 1 was constructed using data collected by RPKIViews.org between 1 January and 31 December 2025, with the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors (TAs).

Table 1 — End-of-year 2024 and end-of-year 2025 snapshot differences.

The number of IP addresses covered by RPKI Route Origin Authorizations (ROAs) grew by 10%. This is similar to the 2024 report. However, the Autonomous System Provider Authorization (ASPA) object count absolutely skyrocketed in 2025! The ‘Uniq ASPA Customer ASIDs’ field is a simple gauge counter for global ASPA deployment on the signer side.

At the time of writing, an ASPA record is published for about 0.5% of Autonomous Systems (ASes) in the Internet global routing system. That’s a very interesting development. The ability to publish ASPA objects became readily available in the RIPE NCC region in 2025, and as of January 2026, is also fully available through ARIN Online. APNIC will deploy support for ASPA objects by the end of Q2, 2026.

The ‘wall time validation run (seconds)’ metric is produced by revalidating the data contained in the two snapshots multiple times. The benchmark uses the same modern multi-threaded RPKI cache implementation, on the same four CPU core machine, without performing any network operations (for example, offline validation mode). This metric relates to the hypothesis that as RPKI grows (in size and number of objects), without also improving efficiency (information density), the overall processing time to validate the complete dataset will increase.

The 2025 benchmark environment: Rpki-client 9.7, OpenSSL 3.5.4, Debian 13, on Intel Xeon.

With every RPKI Certificate Authority (CA), first 2024, then 2025:

 $ hyperfine -w2 'rpki-client -p4 -P 1735689171 -n -d rpki-20241231T235251Z/data /tmp'
    Time (mean ± σ):     46.514 s ±  0.172 s    [User: 173.345 s, System: 5.264 s]
    Range (min … max):   46.257 s … 46.756 s    10 runs
 $ hyperfine -w2 'rpki-client -p4 -P 1767225374 -n -d rpki-20251231T235614Z/data /tmp'
    Time (mean ± σ):     35.046 s ±  0.206 s    [User: 125.092 s, System: 5.894 s]
    Range (min … max):   34.756 s … 35.444 s    10 runs

Without the outlier CA, first 2024, then 2025:

$ hyperfine -w2 'rpki-client -p4 -P 1735689171 -n -d rpki-20241231T235251Z/data /tmp'
    Time (mean ± σ):     26.257 s ±  0.152 s    [User: 92.878 s, System: 4.590 s]
    Range (min … max):   26.069 s … 26.485 s    10 runs
$ hyperfine -w2 'rpki-client -p4 -P 1735689171 -n -d rpki-20251231T235614Z/data /tmp'
    Time (mean ± σ):     32.903 s ±  0.143 s    [User: 117.059 s, System: 5.444 s]
    Range (min … max):   32.635 s … 33.127 s    10 runs

In 2025, the ‘wall time’ metric seemingly deflated. Unfortunately, further investigation shows that the 2024 numbers were heavily skewed by the products issued by a specific large CA under ARIN, an outlier, so to speak. In the 2024 snapshot, that single CA had 50,125 Manifest entries and 15,944 Certificate Revocation List (CRL) entries. In the 2025 snapshot, the same CA had 48,896 Manifest entries and only 33 CRL entries.

The key observation here is that the impact of large CRLs becomes more pronounced with longer Manifests. In conclusion, and discounting the products of that one outlier CA, the overall processing time of the RPKI increased by 25%. 

Note: The ‘wall time’ metric is not comparable between successive annual reports (for example, next year I might use a different computer, or use a different validator implementation). Within the context of a single annual report, the comparison between the snapshots is like comparing apples to apples!

The ‘Average ROAIPAddresses per ROA’ metric shows how many IP prefixes, on average, are contained within a single ROA object. The higher the number of ‘ROAIPAddresses per ROA’ is, the higher computational efficiency is likely to be. ‘Efficiency’ in this context is how many ROAIPAddress entries are packed together and signed with a single End-Entity (EE) certificate. A higher number means more efficiency (and less relying party bandwidth consumption).

The RIPE NCC hosted CA system yields 6.6 prefixes per ROA, while the current ARIN and LACNIC approaches result in only 1.1 and 1.3 prefixes per ROA, respectively (almost the worst possible case). APNIC and its community lead in efficiency with 8.2 per ROA.

The impact that CA implementation choices have on the RPKI’s scalability remains an area of concern. Large CA operators (such as the Regional Internet Registries (RIRs)) need to take special care when deciding on parameters such as ROAIPAddress packing and certificate validity periods, in order to curb uneconomical Manifest and CRL growth. Issuing RPKI objects that aim for high information density helps improve predictable delivery trajectories towards relying parties.

Statistics on accumulating counters throughout the year

The statistics in Table 2 were produced using the RPKIViews 2024 amalgamation and RPKIViews 2025 amalgamation datasets. I believe these datasets are a near-complete collection of all signed RPKI data produced in those years. Almost every ROA! The objects in the Zenodo-hosted archives (2024, 2025) can be inspected with ‘rpki-client -jf’ (filemode).

Table 2 — Statistics on accumulating counters in 2025.

The numbers in Table 2 can be used to better understand RPKI transport protocol efficiency. More on that in 2026!

IETF SIDROPS: Working Group developments

Some fun updates from the IETF working group responsible for development and maintenance of the RPKI technology stack… SIDROPS.

This RPKI-focused design and implementation group now operates with a new charter. The most significant change is that RFC publication now requires multiple implementations to exist and interoperate.

ASPA — where are we at?

We are close to the Working Group’s last call! Depending on our luck, this might mean the specifications are published in late 2026. Word on the street is that various commercial-off-the-shelf hardware vendors are working on ASPA implementations, and several Border Gateway Protocol (BGP) open source projects already made ASPA verification implementations available to the wider public.

Other (new) work in SIDROPS

1. A new scalable data synchronization protocol called Erik Synchronization is in the works. It is an HTTP-based protocol using Merkle trees, a content-addressable naming scheme, and concurrency control using monotonically increasing sequence numbers.
2. What the Multi-Threaded Routing Toolkit (MRT) table dumps meant for researching BGP is what Canonical Cache Representation (CCR) is intended to be for the RPKI. CCR is a new, small, and efficient binary file format to record validation outcomes and hash markers.

SIDROPS finished work

One new clarification RFC was published: RFC 9829 — Handling of Resource Public Key.

Small point on housekeeping

The RPKIViews archive data collection approach and structure were revised at the start of 2026. Several RPKIviews gatherer nodes now use a Tar+Z standard spooling system to store raw data and associated snapshots in the CCR format.

The changes in how RPKIviews data is stored should have a positive effect, meaning more snapshots can be gathered per hour, while at the same time consuming less disk storage space than previously. I’m curious to see what this increase in data resolution might show us next year!

Final words

RPKI remains an important tool in the toolbox to identify and prevent routing incidents. Deployment of RPKI allows operators to improve network reliability by strengthening the security and integrity of their interconnection with the global Internet routing system. The system is working pretty well, and will continue to serve us well if special care is taken to continually monitor and optimize the RPKI’s data packing practises and delivery methods.

Shout out to Lee Hetherington, Matsuzaki ‘Maz’ Yoshinobu, Niels Bakker, Jeroen Lauwers, Jeroen Massar, Digital Ocean, Amazon Web Services, and Tom Scholl for their help with the RPKIViews.org project.

Job Snijders (Mastodon, homepage) is an Internet engineer who analyses and architects global networks for future growth. Job has been actively involved in the Internet community in both operational, engineering, and architectural capacities, as a frequent presenter at network operator events such as NANOG, ITNOG, DKNOG, RIPE, NLNOG, and APRICOT, and in several community projects for almost 20 years.

Adapted from the original at the SIDROPS mailing list.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.