RPKI 2023 Review - Growth, Governments, and Innovation

Year to year growth of the distributed RPKI database

A straight-forward method to compare to last year is to look at the RPKI's absolute numbers.

The below table was constructed by comparing two 31 December RPKIviews snapshots of validated RPKI caches, primed with the ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.

The number of IP addresses covered by ROAs almost doubled compared to last year. More than half the ASes in the global Internet routing system are listed as Origin AS in at least one ROA. EOY'23 more unique IPv6 prefix-origin pairs in the DFZ are 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 FCC'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 USG 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 use 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 saw unprecedented turmoil in the realm of governance of Regional Internet Registries 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 for 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' which 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 and discussion. Running code - rpki-client 8.7 and higher. An internet-draft detailing the implementation.

Initiative #2 - externally imposed constraints: Cover letter, running code, and a related proposal for the validation algorithm to be less rigid & more robust.

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

Some quick updates from the IETF working group responsible for 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.

My expectation is that - because of this new rule - we'll see higher quality documents: the proposals more thoroughly tested, increased readability of the internet-draft texts, and less ambiguity in the specifications. Basing Standards Track documents on real implementation experiences (as opposed to gaining real experiences only after publication of as RFC) seems to be the right way to do things.

ASPA - where we at?

In early 2023 a Canadian IXP, YYCIX, became the first to deploy 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 PDU layout. Still, my hope and expectation is that all ASPA-related documents can be finalised in the next few months.

I continue to stand by this timeline

Optimising 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 transport of RPKI files, but unfortunately RRDP isn't without its own issues either. With neither transport protocol being flawless, turns out RSYNC is perfect as a backup option for RRDP! As long as RSYNC is around, we should care for it and continue maintenance & innovation.

Rpki-client as validator, and RIPE NCC and APNIC as publishers implemented a mechanism to smoothen switching from RRDP to RSYNC. Read more in this blog post or 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 valueable time to study, tinker & propose improvements to this wonderful global system. See you next year!