Subject: [Sidrops] Fw: RPKI's 2025 Year in Review
From: Job Snijders <[email-masked]>
To: [email-masked]
Date: Fri, 23 Jan 2026 00:02:37 +0000
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>

FYI -

----- Forwarded message from Job Snijders <[email-masked]> -----

Date: Thu, 22 Jan 2026 23:58:43 +0000
From: Job Snijders <[email-masked]>
To: [email-masked]
Subject: RPKI's 2025 Year in Review

Dear all,

Happy new year! Wanna know how RPKI evolved throughout 2025? Read on! :)
In this memo I'll share some RPKI statistics, summarize highlights from
the IETF Standards Development process, and reflect on emerging trends.

Year to Year Growth of the distributed RPKI database
===============================================================

A straight-forward method to compare 2024 and 2025 is to look at the
absolute numbers. The below table was constructed using data collected
by RPKIViews.org between January 1st, 2025 and December 31st, 2025 with
the ARIN, AfriNIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.

EOY 2024 / EOY 2025 Snapshot differences:
-----------------------------------------
                                     2024-12-31      2025-12-31  ( diff)
Total validated cache size (KB):        767,245         923,058  (+ 20%)
Total number of files (object count):   415,384         493,707  (+ 19%)
Wall time validation run (seconds):          46              35  (- 23%)
Wall time without outliner CA (seconds):     26              33  (+ 27%)

Publication servers (FQDNs):                 53              60  (+ 13%)
Certification authorities:               44,935          49,721  (+ 11%)
Route Origin Authorizations (ROAs):     280,692         344,209  (+ 23%)

Uniq Validated ROA Payloads:            639,900         787,737  (+ 23%)
Average ROAIPAddresses per ROA:             2.3             1.8  (- 22%)

Unique origin ASNs in ROAs:              47,282          52,661  (+ 11%)
IPv4 addresses covered:           2,726,513,768   2,783,187,105  (+  2%)
Uniq IPv4 addresses covered:      1,658,281,248   1,818,913,944  (+ 10%)
IPv6 addresses covered:          17,392 * 10^30  18,684 * 10^30  (+  7%)
Uniq IPv6 addresses covered:     15,139 * 10^30  16,384 * 10^30  (+  8%)

Unique ASPA Customer ASIDs:                  87             556  (+539%)

The number of IP addresses covered by RPKI ROAs grew by 10%. This is
similar to last year's report. However, 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
moment of writing, for about 0.5% of Autonomous Systems in the Internet
global routing system an ASPA record is published. That's a very
interesting development. The ability to publish ASPA objects became
readily available [4] in the RIPE NCC region in 2025, and as of January
2026 also fully available through ARIN Online [5].

The "Wall time validation run (seconds)" metric is produced by
revalidating the data contained in the two snapshots multiple times in a
benchmark using the same modern multi-threaded RPKI cache implementation
on the same 4 CPU core machine, without performing any network
operations (i.e. offline validation mode). This metric relates to the
hypothesis that as the 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.

This year's benchmark environment:
	Rpki-client 9.7, OpenSSL 3.5.4, Debian 13, on Intel Xeon.

WITH EVERY RPKI 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

FIRST 2024 THEN 2025, WITHOUT THE OUTLINER CA:
  20241231T235251Z:
    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

  20251231T235614Z:
    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

This year the "wall time" metric _seemingly_ deflated...  but,
unfortunately, further sleuthing shows that the 2024 numbers were
heavily skewed by the products issued by a specific large CA under ARIN,
an outliner so to speak. In the 2024 snapshot that one CA had 50,125
Manifest entries and 15,944 CRL entries, while 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 outliner CA, 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) - but within the context of
  a single annual report the comparison between the snapshots is 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
likely is to be. "Efficiency" in this context is viewed as how many
ROAIPAddress entries are packed together and signed with a single EE
certificate. A higher number means more efficiency (and less RP bandwidth
consumption) The RIPE NCC hosted CA system yields 6.6 prefixes per ROA,
while the current ARIN and LACNIC approach 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 RIRs) need
to take special care when deciding on parameters such as ROAIPAddress
packing and certificate validity periods, in order to curb uneconomical
Manifest & CRL growth. Issuing RPKI objects aiming for high information
density helps improve predictable delivery trajectories towards relying
parties.

Statistics on accumulating counters throughout the year:
--------------------------------------------------------

The following statistics were produced using the RPKIViews 2024
Amalgamation [6] and RPKIViews 2025 Amalgamation [7] datasets. I believe
these datasets to be a near complete collection of all signed RPKI data
produced in those years. Almost every ROA! The objects in the Zenodo
hosted archives can be inspected with "rpki-client -jf" (filemode).

                                              2024         2025
Number of Rpkiviews snapshots produced:     64,923       90,523 (+ 39%)
Newly discovered RPKI objects:          56,586,149   61,524,413 (+  9%)
Avg number of new objects per second:         1.79         1.98 (+ 10%)
Median object size (bytes):                  1,924        1,924 (    -)
Mean object size (bytes):                    2,193        2,531 (+ 15%)
Cumulative size of all objects (KB):   121,211,067  152,094,584 (+ 25%)

The above numbers can be used to better understand RPKI transport
protocol efficiency. More on that next year!

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 & implementation group now operates with a new
charter. The most significant change in modus operandi being that RFC
publication now requires multiple implementations to exist and interoperate.
Read the full charter here: https://datatracker.ietf.org/wg/sidrops/about/

ASPA - where we at?
-------------------

Close to Working Group Last call! Depending our luck this might mean the
specifications are published in late 2026. Word on the streets is that
various commercial-off-the-shelf/hardware vendors are working on ASPA
implementations, and a number of BGP open source projects already made
ASPA verification implementations available to the wider public.

Other (New) Work in SIDROPS
---------------------------

1/ A new scalable data synchronisation protocol called Erik Synchronisation
   is in the works. It is a HTTP-based protocol using Merkle trees, a
   content-addressable naming scheme, and concurrency control using
   monotonically increasing sequence numbers.
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-erik-protocol

2/ What MRT Tabledumps meant for researching BGP, is what CCR is
   intended to be for the RPKI. CCR (Canonical Cache Representation) is
   a new small and efficient binary file format to record validation
   outcomes and hash markers.
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ccr

SIDROPS Finished work
---------------------

One new clarification RFC was published:

* RFC 9829 - Handling of Resource Public Key Infrastructure (RPKI)
  Certificate Revocation List (CRL) Number Extensions
  https://www.rfc-editor.org/rfc/rfc9829.html

Small Point On Housekeeping:
============================

The RPKIViews archive data collection approach and structure were
revised at the start of 2026. A number of rpkiviews gatherer nodes now
use a Tar+Zstandard spooling system to store raw data and associated
snapshots in Canonical Cache Representation 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
===============================================================

The RPKI remains an important tool in the toolbox to identify & 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 good and will continue to serve us well if special care
is taken to continually monitor and optimize the RPKI's data packing
practises & delivery methods.

Kinds regards,

Job Snijders

ps. Shout out to Lee Hetherington, Matsuzaki "maz" Yoshinobu, Niels
Bakker, Jeroen Lauwers, Jeroen Massar, Digital Ocean, and Tom Scholl for
their help to the RPKIViews.org project.

References:
RPKIViews - http://www.rpkiviews.org/
            https://dango.attn.jp/rpkidata/2024/12/31/rpki-20241231T235251Z.tgz
            https://josephine.sobornost.net/rpkidata/2025/12/31/rpki-20251231T235614Z.tgz
Last year's report: https://blog.apnic.net/2025/01/28/rpkis-2024-year-in-review/
2023 report: https://labs.ripe.net/author/job_snijders/rpki-2023-review-growth-governments-and-innovation/
[4]: https://labs.ripe.net/author/tim_bruijnzeels/aspa-in-the-rpki-dashboard-a-new-layer-of-routing-security/
[5]: https://www.arin.net/announcements/20260120/
[6]: Snijders, J., "RPKIViews 2024 Amalgamation". Zenodo. https://doi.org/10.5281/zenodo.18328474
[7]: Snijders, J., "RPKIViews 2025 Amalgamation". Zenodo. https://doi.org/10.5281/zenodo.18332099

----- End forwarded message -----