Dear all, Happy new year everyone! 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, summarize 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 December 31st RPKIviews.org snapshots based on the the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors. 2023-12-31 2024-12-31 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: https://rpki-monitor.antd.nist.gov/ROV/20250103.00/All/All/6#div2 As predicted in last year's 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! Another new metric is "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.3 $ time rpki-client -P 1704066710 -n -d rpki-20231231T235150Z/data /tmp/ $ time rpki-client -P 1735689171 -n -d rpki-20241231T235251Z/data /tmp/ Onwards to the next metric, "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 underspecified. Perhaps appointment of an extra document editor would help? In last year's 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: https://mailarchive.ietf.org/arch/msg/sidrops/fwPjecfnlU5JYi_hU-Sh3o7WRHQ/ 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 behavior for some edge cases, resolving underspecification in older documents, and documenting optimizations. A quick overview of RFC publications in the last 12 months: * RFC 9582 - A Profile for Route Origin Authorizations (ROAs) https://www.rfc-editor.org/rfc/rfc9582.html 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 canonicalization procedure was specified for the content of ipAddrBlocks. * RFC 9589 - On the Use of the CMS Signing-Time Attribute in RPKI Signed Objects https://www.rfc-editor.org/rfc/rfc9589.html 9589 describes mechanism for a 'cross-layer optimization' 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: https://blog.apnic.net/2023/12/04/using-timestamps-inside-rpki-objects-to-op... * RFC 9674 - Same-Origin Policy for the RRDP https://www.rfc-editor.org/rfc/rfc9674.html 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 Desynchronization https://www.rfc-editor.org/rfc/rfc9697.html 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! Kinds regards, Job Snijders Data sources: RPKI Views - http://rpkiviews.org/ https://dango.attn.jp/rpkidata/2023/12/31/rpki-20231231T235150Z.tgz https://dango.attn.jp/rpkidata/2024/12/31/rpki-20241231T235251Z.tgz