Having just closed the 2023 chapter, let’s look back at the previous year. In this post, I’ll share some Resource Public Key Infrastructure (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 of comparing 2023 to the 2022 is to examine RPKI’s absolute numbers. Table 1 was constructed by comparing two 31 December RPKIviews snapshots (2022, 2023 .tgz) of validated RPKI caches, primed with the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.
| 31/12/2022 | 31/12/2023 | |
| Total cache size (KiB) | 1,240,572 | 1,546,728 (+25%) |
| Total number of files (objects) | 242,969 | 309,802 (+27%) |
| Publication servers (FQDNs) | 52 | 63 (+21%) |
| Certification authorities | 34,901 | 40,511 (+16%) |
| Route Origin Authorizations | 138,323 | 188,345 (+36%) |
| Unique VRPs | 390,752 | 497,341 (+27%) |
| IPv4 addresses covered | 2,217,685,134 | 2,502,293,068 (+12%) |
| Unique IPv4 addresses covered | 1,354,270,408 | 1,502,281,680 (+11%) |
| IPv6 addresses covered | 12,570 * 10^30 | 17,263 * 10^30 (+37%) |
| Unique IPv6 addresses covered | 9,447 * 10^30 | 15,128 * 10^30 (+60%) |
| Unique origin ASNs in ROAs | 34,455 | 40,656 (+18%) |
The number of IP addresses covered by Route Origin Authorizations (ROAs) almost doubled compared to last year. More than half the Autonomous Systems (ASes) in the global Internet routing system are listed as origin AS in at least one ROA. By 31 December 2023, more unique IPv6 prefix-origin pairs in the Default-Free Zone (DFZ) were covered by ROAs than not, with IPv4 likely to follow crossing this threshold in Q1 2024.
Kentik estimates that more than half of IP traffic is destined towards ROA-covered destinations. APNIC Labs estimates the global ‘I-Rov Filtering Rate’ to be at 22.69% now. These numbers mean it will be worth your while to create and use ROAs for BGP Origin Validation.
In short: It’s all up and to the right. 🙂
Increased government interest in Internet routing security
Following the US Federal Communications Commission’s launch of an inquiry into Internet Routing Vulnerabilities in 2022, in 2023, the agency followed up with a BGP Security Workshop hosted by the Public Safety and Homeland Security Bureau. The industry seemed well represented with key players participating.
While the United States government is still sizing up the industry’s posture and contemplating whether regulation is warranted, in the Netherlands the government itself aspires to lead by example. In 2023, the Dutch government committed to using RPKI by the end of 2024 on all new and existing IT systems it operates. Note that this ambition includes both signing ROAs and validating BGP messages! I hope they succeed.
Will more governments follow the Dutch lead in 2024?
The rise of initiatives re-evaluating the RPKI trust model
As the industry witnessed notable challenges in the governance of Regional Internet Registries (RIRs) in 2023, two interesting initiatives arose, both aiming to reduce the risk surface associated with blindly trusting ‘the RPKI roots’.
In the RPKI hierarchical structure, a Trust Anchor (a root) is an authority from which trust is assumed and not derived. The phrase ‘assumed trust’ means that violation of that trust is out-of-scope for the threat model. On the other hand, the phrase ‘derived trust’ refers to trust automatically and securely computed with subjective logic. In the context of the RPKI, trust is derived according to the rules for validation of RPKI certificates and signed objects.
One initiative is to impose ‘locally configured constraints’ that limit the effective signing authority of an RIR. The other initiative is to instantiate a sixth RPKI Trust Anchor — which chains up to the existing RIR-operated infrastructure — and impose inter-RIR consensus-driven constraints on that arc.
Initiative #1 — operator-imposed constraints:
- Cover letter discussion
- Running code, rpki-client 8.7 & higher
- An Internet draft detailing the implementation
Initiative #2 — externally imposed constraints:
I personally don’t care much *who* imposes constraints, but at the end of the day — someone’s gotta do it. Keep watching this space!
SIDROPS — Working Group developments
To follow are some quick updates from the IETF working group responsible for the development and maintenance of the RPKI technology stack!
Running code — now a requirement
The SIDROPS Working Group set a new rule: Standards Track Internet drafts can only progress towards RFC publication — after — interoperability was demonstrated between at least two independent implementations of the specification. Read the discussion.
My expectation is that, because of this new rule, we’ll see higher quality documents — the proposals are more thoroughly tested, there is increased readability of the Internet draft texts, and there is less ambiguity in the specifications. Basing Standards Track documents on real implementation experiences (as opposed to gaining real experiences only after the publication of RFC) seems to be the right way to do things.
ASPA — where we at?
In early 2023 a Canadian Internet Exchange provider (IXP), YYCIX, became the first to deploy Autonomous System Provider Authorization (ASPA) validation on its IX route servers. While this may seem a leap forward towards wider deployment, things are not all said and done. The IETF SIDROPS Working Group continues to expostulate over things like the ASPA RPKI-to-router Protocol Data Unit layout. Still, my hope and expectation is that all ASPA-related documents can be finalized in the next few months.
I continue to stand by this timeline.
Optimizing RSYNC
RPKI data can be transported in two ways — an HTTPS-based distribution protocol called RRDP, and via RSYNC. Some argue that RSYNC is not the best fit for the transport of RPKI files, but unfortunately, RRDP isn’t without its own issues either. With neither transport protocol being flawless, it turns out RSYNC is perfect as a backup option for RRDP! As long as RSYNC is around, we should care for it and continue to maintain and innovate.
Rpki-client as a validator, and RIPE NCC and APNIC as publishers, implemented a mechanism to smoothen switching from RRDP to RSYNC. Read the post and the Internet draft.
My hope is that more validator projects and RIR repositories adopt this mechanism!
Final words
As more and more networks adopt RPKI, perhaps motivated by government pressure, our collective dependency on RPKI functioning properly and safely increases too. It is awesome to see so many volunteers contribute their valuable time to study, tinker and propose improvements to this wonderful global system. See you next year!
Job Snijders (Twitter, Mastodon, homepage) is a Principal Engineer at Fastly where he analyses and architects global networks for future growth, and also an OpenBSD developer.
Adopted (and updated) from the original post on the NANOG mailing list.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.