Having just closed the book on another orbit around the sun - let's look back at how RPKI did in 2024! In this memo I'll share some RPKI statistics, summarise highlights from the IETF Standards Development process, and reflect on emerging trends.
Year-to-year growth of the distributed RPKI database
A straightforward method to compare 2023 and 2024 is to look at the absolute numbers. The below table was constructed by comparing two 31 December RPKIviews.org snapshots (2023, 2024) based on the the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.
| 2023-12-31 | 2024-12-31 | growth | |
|---|---|---|---|
| Total cache size (KiB) | 1,546,728 | 2,021,784 | +31% |
| Total number of files (objects) | 309,802 | 415,384 | +34% |
| Wall time validation run (seconds) | 163 | 228 | +40% |
| Publication servers (FQDNs) | 63 | 53 | -16% |
| Certification authorities | 40,511 | 44,935 | +11% |
| Route origin authorizations | 188,345 | 280,692 | +49% |
| Uniq VRPs | 497,341 | 639,909 | +29% |
| Average ROAIPAddresses per ROA | 2.7 | 2.3 | -15% |
| IPv4 addresses covered | 2,502,293,068 | 2,726,513,768 | +9% |
| Uniq IPv4 addresses covered | 1,502,281,680 | 1,658,281,248 | +10% |
| IPv6 addresses covered | 17,263 * 10^30 | 17,392 * 10^30 | +1% |
| Uniq IPv6 addresses covered | 15,128 * 10^30 | 15,139 * 10^30 | 0% |
| Uniq origin ASNs in ROAs | 40,656 | 47,282 | +16% |
| Uniq ASPA Customer ASIDs | 56 | 87 | +55% |
The number of IPv4 addresses covered by ROAs saw similar growth compared to 2023. It's not entirely clear to me what's going on with IPv6, but on the IPv6 side of the house growth seems to be stalling. The NIST RPKI Deployment Monitor seems to corroborate these observations.
As predicted in the 2023 review, nowadays more than half of both the IPv4 and IPv6 routes in the global routing system are covered by RPKI ROAs (~ 54%). Kentik estimates that around 74% of IP traffic is destined towards ROA covered destinations. These numbers mean it will be worth your while to create and use ROAs for BGP Origin Validation.
This year's report includes new metrics:
- Uniq ASPA Customer ASIDs
This field provides a simple indicator for global ASPA deployment on the signer side. At the moment about 0.001% of Autonomous Systems in the Internet global routing system published an ASPA record, so it's still very early days for ASPA!
- Wall time validation run (seconds)
To produce this metric the two snapshots are processed through the same (modern) RPKI cache implementation on the same hardware omitting any network operations. This metric suggests that as the RPKI grows in size and/or number of files, processing time also increases.
Please note that the wall time metric is not comparable between successive annual reports (for example, next year I might have a different laptop, or use a different validator implementation) - but within a single annual report the metric comparison is apples to apples. To reproduce:
$ rpki-client -V
rpki-client 9.4
$ time rpki-client -P 1704066710 -n -d rpki-20231231T235150Z/data /tmp/
$ time rpki-client -P 1735689171 -n -d rpki-20241231T235251Z/data /tmp/- Average ROAIPAddresses per ROA
This shows how many IP prefixes, on average, are contained within a single ROA object. The higher the number of ROAIPAddresses per ROA, the higher computational efficiency is.
"Efficiency" in this context arises from validators spending the computational cost of validating a single EE certificate and yielding more than 1 ROAIPAddress. Under the RIPE NCC TAL one yields 6.5 prefixes per ROA, while in the ARIN region this is number is 1.1 prefixes per ROA. As stewards of this technology, we need to keep an eye on the overall efficiency of the RPKI to ensure things don't get out of hand.
SIDROPS - Working Group developments
Some quick updates from the IETF working group responsible for development and maintenance of the RPKI technology stack!
ASPA - where we at?
While most of the ASPA specification documents are steadily moving towards completion, the RPKI-To-Router (RTR) specification unfortunately appears to be progressing with great difficulty. With so many people excited about the prospect of using ASPA to prevent route leaks, it's sad to see a select few individuals dragging their feet to dot the i's and cross the t's.
As things stand, some parts of the draft RTR specification are unimplementable and other parts appear under-specified. Perhaps appointment of an extra document editor would help?
In the 2023 report, I was more optimistic about the delivery timeline than I am this year. I now expect publication of the ASPA specs as RFCs not to happen earlier than 2026. For an overview of open action items, see here.
Finished work
The good news is that 2024 turned out to be a productive year in terms of tidying up various aspects of the RPKI technology stack. Tidying up in this context means resolving potentially detrimental system behaviour for some edge cases, resolving under-specification in older documents, and documenting optimisations. A quick overview of RFC publications in the last 12 months:
- RFC 9582 - A Profile for Route Origin Authorisations (ROAs)
The new ROA specification clarifies the requirements for IP address and AS identifier X.509 certificate extensions, its ASN.1 notation was revised with additional backwards compatible constraints, errata were incorporated, and a canonicalisation procedure was specified for the content of ipAddrBlocks. - RFC 9589 - On the Use of the CMS Signing-Time Attribute in RPKI Signed Objects
9589 describes mechanism for a 'cross-layer optimisation' which enables Relying Parties (RPs) - when switching from RRDP to RSYNC - to save on bandwidth consumption. All five RIRs and rpki-client support this mechanism. See the following deep-dive for more information. - RFC 9674 - Same-Origin Policy for the RRDP
A potential security issue was discovered in RRDP: from one RRDP server references could be made to resources hosted on another RRDP server, causing RPs to follow the reference and waste bandwidth. The solution turned out to be simple: RPs should not follow references to resources hosted on other origins. All actively-maintained RPs implementations adopted this approach. - RFC 9697 - Detecting RRDP Session Desynchronisation
For RRDP to work well, once Delta files are published, Deltas are not expected to change over time. Delta files are immutable. A mechanism was devised for RPs to detect occurrences of unexpected file mutations and how to recover. Most actively-maintained RP implementations adopted this approach.
Final words
RPKI has become the #1 tool in the toolbox to prevent routing incidents. Implementing RPKI allows operators to improve network reliability by strengthening the security and integrity of the global Internet routing system. I'm excited to see what the coming year will bring!
Comments 0