RPKI's 2023 Year in Review - growth, governments, and innovation

Wed Jan 3 20:52:44 UTC 2024

Dear all,

Happy new year everyone! Having just closed chapter 2023 - let's look
back at the previous year.

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 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 December 31st
RPKIviews.org snapshots [1] of validated RPKI caches, primed with the
ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.

                               2022-12-31      2023-12-31
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:     1,354,270,410   2,502,293,068 (+85%)
IPv6 addresses covered:     9,447 * 10^30  17,263 * 10^30 (+83%)
Unique origin ASNs in ROAs:        34,455          40,656 (+18%)

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 [2] estimates that more than half of IP traffic is destined
towards ROA covered destinations. APNIC Labs [3] 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 [4], 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 [5]. 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 & discussion: https://mailman.nanog.org/pipermail/nanog/2023-September/223354.html
Running code - rpki-client 8.7 & higher
    https://cdn.openbsd.org/pub/OpenBSD/rpki-client/rpki-client-8.7.txt
An internet-draft detailing the implementation:
    https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors

Initiative #2 - externally imposed constraints:
Cover letter: https://labs.apnic.net/index.php/2023/12/13/models-of-trust-in-the-rpki/
Running code: https://labs.apnic.net/nro-ta/
A proposal for the validation algorithm to be less rigid & more robust:
    https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-validation-update

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:
https://mailarchive.ietf.org/arch/msg/sidrops/54iqtt-Ug2lzMbr9KpQOnWsh2JM/

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 [6] - 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 finalized in the next few months.

I continue to stand by this timeline:
https://www.manrs.org/2023/05/estimating-the-timeline-for-aspa-deployment/

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 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 & APNIC as publishers implemented
a mechanism to smoothen switching from RRDP to RSYNC:
https://blog.apnic.net/2023/12/04/using-timestamps-inside-rpki-objects-to-optimize-rrdp-rsync-transport-switchovers/
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-cms-signing-time

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!

- Job

Sources:

[1]: RPKI Views - http://rpkiviews.org/
     http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2022/12/31/rpki-20221231T103540Z.tgz
     http://dango.attn.jp/rpkidata/2023/12/31/rpki-20231231T235150Z.tgz	
[2]: https://www.kentik.com/blog/exploring-the-latest-rpki-rov-adoption-numbers/
[3]: https://stats.labs.apnic.net/rpki
[4]: https://www.fcc.gov/news-events/events/2023/07/bgp-security-workshop
[5]: https://www.forumstandaardisatie.nl/nieuws/secured-internet-routing-dutch-government-end-2024
[6]: https://mailman.nanog.org/pipermail/nanog/2023-February/221471.html