On 23/01/2026 1:58, Job Snijders via NANOG wrote: Crack in the Armor: Underlying Infrastructure Threats to RPKI Publication Point Reachability https://www.ndss-symposium.org/ndss-paper/crack-in-the-armor-underlying-infr... Regards, Hank

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.tg... 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-government... [4]: https://labs.ripe.net/author/tim_bruijnzeels/aspa-in-the-rpki-dashboard-a-ne... [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 _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/QLG35AUU...

Hi Hank, On Fri, Feb 20, 2026 at 08:40:02AM +0200, Hank Nussbacher via NANOG wrote:

Crack in the Armor: Underlying Infrastructure Threats to RPKI Publication Point Reachability https://www.ndss-symposium.org/ndss-paper/crack-in-the-armor-underlying-infr...

At first glance this seems a link to a report with contrived findings from a low-tier publication venue? I might be missing the point you wish to make. Kind regards, Job

Hi, We had F5 announce a /24 on our behalf.  We then asked F5 to withdraw that /24.  Route-views showed the /24 still being announced via an F5 path.  F5 claims that route-views is incorrect and the route had been properly withdrawn.  They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time. Have others seen this type of issues from route-views? Thanks, Hank

nanog@lists.nanog.org (Hank Nussbacher via NANOG) wrote:

We had F5 announce a /24 on our behalf.  We then asked F5 to withdraw that /24.  Route-views showed the /24 still being announced via an F5 path.  F5 claims that route-views is incorrect and the route had been properly withdrawn.

Local withdrawal does not result in *quick* global withdrawal. There's so much dampening involved, that you can get lucky, but that's not a given. If you still see the prefix two hours later, that's when I'd start thinking deeper about the heat death of the universe. Until then, it is what it is. El "correct me if I'm wrong, I just never believed in instant change, just because *I* made a change" mar.

saku@ytti.fi (Saku Ytti) wrote:

...

If you still see the prefix two hours later, that's when I'd start thinking deeper about the heat death of the universe. Until then, it is what it is.

Sir, are you saying Internet convergence typically takes hours?

Sir, following your explanation, I stand corrected and feel really old now. Elmar.

Hi, On Tue, 03 Mar 2026 at 10:13:53 +0200, Hank Nussbacher via NANOG wrote:

We had F5 announce a /24 on our behalf.  We then asked F5 to withdraw that /24.  Route-views showed the /24 still being announced via an F5 path.  F5 claims that route-views is incorrect and the route had been properly withdrawn.  They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time.

F5 has a (real time) looking glass (https://lg.as35280.net/) and their BGP communities are documented in their AS object (whois -h whois.ripe.net as35280). It should easily tell you if they actually withdrew your prefix and/or where they're learning it from. Ben -- Benjamin Collet

On Tue, 3 Mar 2026, Hank Nussbacher via NANOG wrote:

We had F5 announce a /24 on our behalf.  We then asked F5 to withdraw that /24.  Route-views showed the /24 still being announced via an F5 path.  F5 claims that route-views is incorrect and the route had been properly withdrawn.  They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time.

It does take time for route updates to propagate, and I've seen some providers/platforms take what seems like unreasonable minutes to drop routes after origination has ceased...but if they're hanging around longer than that, odds are [extremely high], F5 is still leaking the route to someone who's propagating it to the Internet (or at least to route-views) in order for route-views to see it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Almost no one uses dampening

about 9% of ASs use damping with the old pad parms. randy

F5 claims that route-views is incorrect and the route had been properly withdrawn.

Sounds like someone at F5 is trying to cover up an oops. On Tue, Mar 3, 2026 at 3:14 AM Hank Nussbacher via NANOG < nanog@lists.nanog.org> wrote:

Hi,

We had F5 announce a /24 on our behalf. We then asked F5 to withdraw that /24. Route-views showed the /24 still being announced via an F5 path. F5 claims that route-views is incorrect and the route had been properly withdrawn. They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time.

Have others seen this type of issues from route-views?

Thanks,

Hank

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GF6SKJK2...

(bgp.tools owner hat on) It's entirely possible that things do actually get stuck in routing tables, and there [are/have been] some persistent bugs in especially Extreme OS around this particular failure mode for several years, there are also some similar bugs in certain configurations of JunOS that can easily cause this, FRR configured with weird flap dampening parameters can also do this... Depending on the mission of the route collector collecting these stuck routes is either a feature ( it is interesting to study the propagation of these "stuck" routes ) or a bug ( it is annoying for customers to potentially see routes that are not really there ) To my understanding Route Views and RIS lean on the former category, bgp.tools tries (with some degree of success but not total) to remove the obviously stuck routes from the view because it has knock on issues for the usefulness of the rest of the platform On 3/3/26 08:13, Hank Nussbacher via NANOG wrote:

Hi,

We had F5 announce a /24 on our behalf.  We then asked F5 to withdraw that /24.  Route-views showed the /24 still being announced via an F5 path.  F5 claims that route-views is incorrect and the route had been properly withdrawn.  They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time.

Have others seen this type of issues from route-views?

Thanks,

Hank

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/ nanog@lists.nanog.org/message/GF6SKJK2X3NCOELFTAHZOTRO62DH5G6O/

I actually don't know what the "OBSERVED PATHS" is showing here, 35280 doesn't appear in any of them, so are they the paths "up to" 35280 ?

Presumably 'observed paths from inside 35280', but also think it's a misleading/confusing tool. From what I can see for that prefix ( 2a0d:3dc1:6789::/48 ) , origin is 4601 , paths is to 1299. ( 1299 25091 8298 4601 ) 1299 doesn't seem to have it anywhere in their LGs, but 174 sure does in Singapore and Washington, DC. Tue Mar 3 18:39:11.114 UTC BGP routing table entry for 2a0d:3dc1:6789::/48 Versions: Process bRIB/RIB SendTblVer Speaker 2021417067 2021417067 Last Modified: Feb 25 08:49:15.258 for 6d09h Paths: (1 available, best #1) Path #1: Received by speaker 0 1299 25091 8298 4601 2001:550:0:1000::261c:1d4 (metric 118081) from 2001:550:0:1000::9a36:42af (38.28.1.212) Origin IGP, metric 4294967294, localpref 100, valid, internal, best, group-best Received Path ID 0, Local Path ID 1, version 2021417067 Community: 174:10001 174:11700 174:20666 174:21100 174:22020 Originator: 38.28.1.212, Cluster list: 154.54.66.175, 154.54.136.66, 66.28.1.3, 38.28.1.123 RIPEStat has the withdrawl at 2026-03-02 15:20:08. So it seems like Cogent is where it's stuck. AS35280 presumably only has this route because AS174 is still advertising it. This ThousandEyes tool then saying 'This ASN is potentially retaining stuck routes' is kinda crap, since Cogent appears to be the actual place it's stuck. You see the same error message for any ASN that has a path from 174. On Tue, Mar 3, 2026 at 5:00 AM James Bensley via NANOG < nanog@lists.nanog.org> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi Hank,

It is possible for routes to get stuck in the global routing table, although it is pretty rare.

The is a project called the BGP Clock, they announce prefixes, then withdraw them, and then check if they are still visible anywhere, to see if the prefixes are "stuck". It's called the BGP Clock because they encode the time in the IPv6 prefix, so each prefix is unique and you can see when it was announced (and thus how long it's been lingering in the DFZ).

F5s ASN in one that shows as potentially having this problem according to this tool: https://www.thousandeyes.com/bgp-stuck-route-observatory/?asn=35280

Note that this can't be taken as any sort of guarantee and this is just a "hint" because there are many variables at play.

I actually don't know what the "OBSERVED PATHS" is showing here, 35280 doesn't appear in any of them, so are they the paths "up to" 35280 ?

With kind regards, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail

wsG5BAEBCgBtBYJpprDmCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnyVYZmSuscCtYL9o+a2kWUxr80kno5he9CLyu 5fHU+YkWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAdwYP/iFT17rN8rjspKHl 8ijluvP50a7inXWhr25tmkiOn1ZKpvYo4OGAbpiB2CQ3s+qS39B1zAozLyFB CtLYLBcd4rSsFh97JDB23PsX6iWCVMpbXpQXWg4bm/3WFE+Eb0JBU4cSHaLT bPqQ7qcL87VgUCO9TA9SiyDyyfKJqoDLWM/UIIfR0mGnEVyVOP2oM79orqlw v1xOsN5T66ApDytRbyAF41Yzzr6djS27IFdKbpgWvxRVGdhbSjbg5yM1azCZ UbgKOm+2LhhCg1nObGUO29zsCMeObC43ka5PS3zKV0C4ZNE3QtuzrZCbBPyj JjT+uiHCgBMEYDx7gdem7h4+PwkroC9fo8TVN1QyxeEWKfgb3dcrmA3IyGzT mhKEv4GXOT8weYg6nQHButZ8SisZjgW2SDltZ/0Ha79y568exDsw2pGQ6TS4 Xr0txoM+DUDefI/4LlLdsWm04o6MSJM9Nlntve41FZPJOXgPfU63XiTW72P0 DjQ4uqHbtnjRpixPpwECuwa0+jv6I750jMC8o/eVjsJYT4Z8dniLFMHDrpge b05YzJAYt5zPGIDp+9lW7aTcb8ZGmklb2XL6t1tl3aHpf+rzTAe/r3uO/4hx zLi4ii/OvOrfamZ7Yjs1IPgo69EzQRbytw0b0G24OQqFMl2CoWFQZVQKdfyd v2ObuYxL =pHnk -----END PGP SIGNATURE----- _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CFTB2TRX...

Is there a citation/paper for this claim?

...

...

Almost no one uses dampening about 9% of ASs use damping with the old pad parms.

of course. even for top posters :) Caitlin Gray, Clemens Mosig, Randy Bush, Cristel Pelsser, Matthew Roughan, Thomas Schmidt, Matthias Wählisch. BGP Beacons, Network Tomography, and Bayesian Computation to Locate Route Flap Damping, ACM IMC 2020 randy

i suppose that, if we knew the prefix and ASs, a bored researcher could try to figure out if it was/is a zombie, noction, f5 cover-up, or whatever. i am not that bored researcher. and what would we really learn that is useful? randy