With 2022 in our rear mirror, I’d like to share some perspectives on how RPKI evolved in the last year.
Impact on the global internet routing system
Decision-makers might wonder — is investing time and resources in Resource Public Key Infrastructure (RPKI) worth it? What is the effectiveness of RPKI Route Origin Validation (ROV)? In the last year, a number of interesting reports were published.
Even though less than half of BGP routes are covered by RPKI Route Origin Authorizations (ROAs), based on flow data, Kentik estimates the majority of IP traffic is destined towards RPKI-valid BGP routes nowadays. Their follow-up report (analysing BGP control-plane data) suggests that evaluating a Border Gateway Protocol (BGP) route as RPKI-invalid reduces its propagation by between one-half to two-thirds.
Cloudflare published a report analysing data-plane connectivity between a select number of Autonomous Systems (ASes) and RPKI-invalid destinations. They estimate 6.5% (lower-bound) of residential Internet users enjoy the benefits of their ISP doing RPKI-ROV. But there is a caveat — the methodology might arrive at a lower coverage adoption rating due to suspected erroneous classification of RPKI-ROV enabled networks as ‘non-validating’ in case a default route (route of last resort) is present that facilitated a data-plane conduit. The presence of default routes does not in any way diminish the value of RPKI ROV, but it does distort some types of measurement.
Another experiment report (focused on data-plane connectivity between validators and RPKI-valid/RPKI-invalid destinations), concluded the existence of RPKI ROAs helped move 75% of test traffic towards the correct destination.
The above metrics might appear all over the place (6.5% up to 75%), but keep in mind these analyses are not mutually exclusive. Observations of the Internet’s topology are a function of the observer’s vantage point.
All the referenced reports agree on key points:
- ROAs have a measurable and significant impact on global IP traffic delivery.
- RPKI ROV helps reduce the ‘blast radius’ of BGP routing incidents.
- They recommend continuing the global deployment of RPKI ROV (rejecting RPKI invalid BGP routes) and creating ROAs for all IP address space.
Year-to-year growth of the distributed RPKI database
In comparison to ‘effectiveness’, the bare existence, size, contents, and number of signed objects in the globally distributed RPKI repository system is much easier to quantify.
The table below was constructed by comparing two 31 December 2022 RPKIviews snapshots (2021, 2022 .tgz) of validated RPKI caches, primed with the ARIN, AFRINIC, APNIC, LACNIC, and RIPE Trust Anchors.
31/12/2021 | 31/12/2022 | |
Total cache size (KiB) | 996,216 | 1,240,572 (+24%) |
Total number of files (objects) | 192,503 | 242,969 (+26%) |
Publication servers (FQDNs) | 36 | 52 (+44%) |
Certification authorities | 28,328 | 34,901 (+23%) |
Route Origin Authorizations | 101,645 | 138,323 (+36%) |
Unique VRPs | 302,025 | 390,752 (+29%) |
IPv4 addresses covered | 1,139,561,719 | 1,354,270,410 (+19%) |
IPv6 addresses covered | 7,499,405,083 | 9,446,853,925 (+26%) 10^24 |
Unique origin ASNs in ROAs | 27,174 | 34,455 (+27%) |
A healthy growth rate across the board!
With the ubiquitous availability of ‘Publication as a Service’ hosted by Regional Internet Registries (RIRs), I expect (and hope!) the growth of the number of distinct publication servers to stall, or even drop in 2023.
The number of Certification Authorities (CAs) closely corresponds to the number of RIR Members (RIR customers) who opted to enable RPKI services for their Internet Number Resources, making it a useful proxy metric to understand how many organizations are creating RPKI ROAs.
A single ROA can contain one or more Validated ROA Payloads (VRPs), and one or multiple ROAs can contain the same VRP information. ‘Unique’ in Table 1 indicates the metric’s underlying data was deduplicated.
Each ROA can only contain a single origin ASN. Multiple ROAs can refer to the same origin ASN value.
Innovation through standardization
The IETF SIDROPS Working Group (the designated forum in which volunteers collaborate to define and specify open standards for RPKI and RPKI-based technologies) was fairly productive in 2022 and managed to publish five RFCs:
- RFC 9286 — Manifests for the RPKI (revision)
- RFC 9255 — The ‘I’ in RPKI Does Not Stand for Identity (clarification)
- RFC 9319 — The Use of maxLength in the RPKI (clarification)
- RFC 9323 — A Profile for RPKI Signed Checklists (RSCs) (innovation)
- RFC 9324 — Policy Based on the RPKI without Route Refresh (innovation)
The above body of work consists mostly of revisions of older work or clarifications on how to use RPKI. To me, this demonstrates a somewhat conservative approach (rather than innovation at breakneck speed), which I consider a good thing.
Outlook and conclusion
Now that globally ROV has advanced as far as it has, the next obvious target is BGP path validation, to mitigate two distinct problems: BGP route leaks and BGP AS-PATH spoofing. Both are painful to network operators!
While projects like OpenBSD’s validator rpki-client and NLNet Labs’ signer Krill made significant headway to support both BGPsec and Autonomous System Provider Authorization (ASPA), the industry as a whole (especially the BGP implementations) still has a decent chunk of work ahead. Once the freshly created software runs on BGP routers and RIR portals offer BGPsec + ASPA functionality, operators need to investigate initial deployment strategies.
RPKI clearly is the technology of choice to improve the safety and security of the global Internet routing system. The adoption of RPKI continues to grow. I’m excited to learn how far we’ll be at the end of 2023!
Job Snijders (Twitter, Mastodon) is an Internet Engineer at Fastly where he analyses and architects global networks for future growth.
This post is adapted from the original at 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.