RPKI's 2024 Year in Review
Job Snijders
job at sobornost.net
Fri Jan 17 08:15:11 UTC 2025
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 [1] 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-optimize-rrdp-rsync-transport-switchovers/
* 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
More information about the NANOG
mailing list