[AONOG] Fwd: RPKI's 2023 Year in Review - growth, governments, and innovation
dc at darwincosta.com
dc at darwincosta.com
Wed Jan 3 22:05:07 CET 2024
FYI!
Begin forwarded message:
> From: Job Snijders via NANOG <nanog at nanog.org>
> Date: 3 January 2024 at 21:53:54 CET
> To: nanog at nanog.org
> Subject: RPKI's 2023 Year in Review - growth, governments, and innovation
> Reply-To: Job Snijders <job at fastly.com>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nogalliance.org/pipermail/aonog-members/attachments/20240103/5bafcd07/attachment.htm>
More information about the AONOG-members
mailing list