<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><div>FYI!</div></div><div dir="ltr"><br>Begin forwarded message:<br><br></div><blockquote type="cite"><div dir="ltr"><b>From:</b> Job Snijders via NANOG <nanog@nanog.org><br><b>Date:</b> 3 January 2024 at 21:53:54 CET<br><b>To:</b> nanog@nanog.org<br><b>Subject:</b> <b>RPKI's 2023 Year in Review - growth, governments, and innovation</b><br><b>Reply-To:</b> Job Snijders <job@fastly.com><br><br></div></blockquote><blockquote type="cite"><div dir="ltr"><span>Dear all,</span><br><span></span><br><span>Happy new year everyone! Having just closed chapter 2023 - let's look</span><br><span>back at the previous year.</span><br><span></span><br><span>In this memo I'll share some RPKI statistics, summarize highlights from</span><br><span>the IETF Standards Development process, and reflect on emerging trends.</span><br><span></span><br><span></span><br><span>Year to Year Growth of the distributed RPKI database</span><br><span>===============================================================</span><br><span></span><br><span>A straight-forward method to compare to last year is to look at the</span><br><span>RPKI's absolute numbers.</span><br><span></span><br><span>The below table was constructed by comparing two December 31st</span><br><span>RPKIviews.org snapshots [1] of validated RPKI caches, primed with the</span><br><span>ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.</span><br><span></span><br><span> 2022-12-31 2023-12-31</span><br><span>Total cache size (KiB): 1,240,572 1,546,728 (+25%)</span><br><span>Total number of files (objects): 242,969 309,802 (+27%)</span><br><span>Publication servers (FQDNs): 52 63 (+21%)</span><br><span>Certification authorities: 34,901 40,511 (+16%)</span><br><span>Route origin authorizations: 138,323 188,345 (+36%)</span><br><span>Unique VRPs: 390,752 497,341 (+27%)</span><br><span>IPv4 addresses covered: 1,354,270,410 2,502,293,068 (+85%)</span><br><span>IPv6 addresses covered: 9,447 * 10^30 17,263 * 10^30 (+83%)</span><br><span>Unique origin ASNs in ROAs: 34,455 40,656 (+18%)</span><br><span></span><br><span>The number of IP addresses covered by ROAs almost doubled compared to</span><br><span>last year. More than half the ASes in the global Internet routing system</span><br><span>are listed as Origin AS in at least one ROA. EOY'23 more unique IPv6</span><br><span>prefix-origin pairs in the DFZ are covered by ROAs than not, with IPv4</span><br><span>likely to follow crossing this threshold in Q1 2024.</span><br><span></span><br><span>Kentik [2] estimates that more than half of IP traffic is destined</span><br><span>towards ROA covered destinations. APNIC Labs [3] estimates the global</span><br><span>"I-Rov Filtering Rate" to be at 22.69% now. These numbers mean it will</span><br><span>be worth your while to create and use ROAs for BGP Origin Validation.</span><br><span></span><br><span>In short: it's all up and to the right. :-)</span><br><span></span><br><span></span><br><span>Increased Government Interest in Internet Routing Security</span><br><span>===============================================================</span><br><span></span><br><span>Following the FCC's launch of an inquiry into Internet Routing</span><br><span>Vulnerabilities in 2022, in 2023 the agency followed up with a BGP</span><br><span>Security Workshop hosted by the Public Safety and Homeland Security</span><br><span>Bureau [4], the industry seemed well represented with key players</span><br><span>participating.</span><br><span></span><br><span>While the USG is still sizing up the industry's posture and</span><br><span>contemplating whether regulation is warranted, in the Netherlands the</span><br><span>government itself aspires to lead by example: in 2023 the Dutch</span><br><span>government committed to use RPKI by the end of 2024 on all new and</span><br><span>existing IT systems it operates [5]. Note that this ambition includes</span><br><span>both signing ROAs and validating BGP messages! I hope they succeed.</span><br><span></span><br><span>Will more governments follow the Dutch lead in 2024?</span><br><span></span><br><span></span><br><span>The Rise Of Initiatives Re-evaluating The RPKI Trust Model</span><br><span>===============================================================</span><br><span></span><br><span>As the industry saw unprecedented turmoil in the realm of governance of</span><br><span>Regional Internet Registries in 2023, two interesting initiatives arose,</span><br><span>both aiming to reduce the risk surface associated with blindly trusting</span><br><span>'the RPKI Roots'.</span><br><span></span><br><span>In the RPKI hierarchical structure, a Trust Anchor (a root) is an</span><br><span>authority for which trust is assumed and not derived. The phrase</span><br><span>"assumed trust" means that violation of that trust is out-of-scope for</span><br><span>the threat model. On the other hand, the phrase "derived trust" refers</span><br><span>to trust automatically and securely computed with subjective logic. In</span><br><span>the context of the RPKI, trust is derived according to the rules for</span><br><span>validation of RPKI Certificates and Signed Objects.</span><br><span></span><br><span>One initiative is to impose 'locally configured constraints' which limit</span><br><span>the effective signing authority of an RIR. The other initiative is to</span><br><span>instantiate a sixth RPKI trust anchor - which chains up to the existing</span><br><span>RIR-operated infrastructure - and impose inter-RIR consensus-driven</span><br><span>constraints on that arc.</span><br><span></span><br><span>Initiative #1 - operator imposed constraints:</span><br><span>Cover letter & discussion: https://mailman.nanog.org/pipermail/nanog/2023-September/223354.html</span><br><span>Running code - rpki-client 8.7 & higher</span><br><span> https://cdn.openbsd.org/pub/OpenBSD/rpki-client/rpki-client-8.7.txt</span><br><span>An internet-draft detailing the implementation:</span><br><span> https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors</span><br><span></span><br><span>Initiative #2 - externally imposed constraints:</span><br><span>Cover letter: https://labs.apnic.net/index.php/2023/12/13/models-of-trust-in-the-rpki/</span><br><span>Running code: https://labs.apnic.net/nro-ta/</span><br><span>A proposal for the validation algorithm to be less rigid & more robust:</span><br><span> https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-validation-update</span><br><span></span><br><span>I personally don't care much *who* imposes constraints, but at the</span><br><span>end of the day - someone's gotta do it. Keep watching this space!</span><br><span></span><br><span></span><br><span>SIDROPS - Working Group developments</span><br><span>===============================================================</span><br><span></span><br><span>Some quick updates from the IETF working group responsible for</span><br><span>development and maintenance of the RPKI technology stack!</span><br><span></span><br><span>Running code - now a requirement</span><br><span>--------------------------------</span><br><span>The SIDROPS working group set a new rule: Standards Track internet-drafts</span><br><span>can only progress towards RFC publication - after - interoperability was</span><br><span>demonstrated between at least two independent implementations of the</span><br><span>specification:</span><br><span>https://mailarchive.ietf.org/arch/msg/sidrops/54iqtt-Ug2lzMbr9KpQOnWsh2JM/</span><br><span></span><br><span>My expectation is that - because of this new rule - we'll see higher</span><br><span>quality documents: the proposals more thoroughly tested, increased</span><br><span>readability of the internet-draft texts, and less ambiguity in the</span><br><span>specifications. Basing Standards Track documents on real implementation</span><br><span>experiences (as opposed to gaining real experiences only after</span><br><span>publication of as RFC) seems to be the right way to do things.</span><br><span></span><br><span>ASPA - where we at?</span><br><span>-------------------</span><br><span>In early 2023 a Canadian IXP, YYCIX, became the first to deploy ASPA</span><br><span>validation on its IX Route Servers [6] - while this may seem a leap</span><br><span>forward towards wider deployment, things are not all said and done.</span><br><span>The IETF SIDROPS working group continues to expostulate over things like</span><br><span>the ASPA RPKI-To-Router PDU layout. Still, my hope and expectation is</span><br><span>that all ASPA-related documents can be finalized in the next few months.</span><br><span></span><br><span>I continue to stand by this timeline:</span><br><span>https://www.manrs.org/2023/05/estimating-the-timeline-for-aspa-deployment/</span><br><span></span><br><span>Optimizing RSYNC</span><br><span>----------------</span><br><span>RPKI data can be transported in two ways — an HTTPS-based distribution</span><br><span>protocol called RRDP, and via RSYNC. Some argue that RSYNC is not the</span><br><span>best fit for transport of RPKI files, but unfortunately RRDP isn't</span><br><span>without its own issues either. With neither transport protocol being</span><br><span>flawless, turns out RSYNC is perfect as a backup option for RRDP! As</span><br><span>long as RSYNC is around, we should care for it and continue maintenance</span><br><span>& innovation.</span><br><span></span><br><span>Rpki-client as validator, and RIPE NCC & APNIC as publishers implemented</span><br><span>a mechanism to smoothen switching from RRDP to RSYNC:</span><br><span>https://blog.apnic.net/2023/12/04/using-timestamps-inside-rpki-objects-to-optimize-rrdp-rsync-transport-switchovers/</span><br><span>https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-cms-signing-time</span><br><span></span><br><span>My hope is that more validator projects and RIR repositories adopt this</span><br><span>mechanism!</span><br><span></span><br><span></span><br><span>Final words</span><br><span>===============================================================</span><br><span></span><br><span>As more and more networks adopt RPKI, perhaps motivated by government</span><br><span>pressure, our collective dependency on RPKI functioning properly and</span><br><span>safely increases too. It is awesome to see so many volunteers contribute</span><br><span>their valueable time to study, tinker & propose improvements to this</span><br><span>wonderful global system. See you next year!</span><br><span></span><br><span>- Job</span><br><span></span><br><span></span><br><span>Sources:</span><br><span></span><br><span>[1]: RPKI Views - http://rpkiviews.org/</span><br><span> http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2022/12/31/rpki-20221231T103540Z.tgz</span><br><span> http://dango.attn.jp/rpkidata/2023/12/31/rpki-20231231T235150Z.tgz </span><br><span>[2]: https://www.kentik.com/blog/exploring-the-latest-rpki-rov-adoption-numbers/</span><br><span>[3]: https://stats.labs.apnic.net/rpki</span><br><span>[4]: https://www.fcc.gov/news-events/events/2023/07/bgp-security-workshop</span><br><span>[5]: https://www.forumstandaardisatie.nl/nieuws/secured-internet-routing-dutch-government-end-2024</span><br><span>[6]: https://mailman.nanog.org/pipermail/nanog/2023-February/221471.html</span><br></div></blockquote></body></html>