Estimating the Timeline for ASPA Deployment
Someone asked the question recently on the Secure Inter-Domain Routing Operations (SIDROPS) mailing list as to when it’s likely that Autonomous System Provider Authorization (ASPA) will be widely adopted as part of Resource Public Key Infrastructure (RPKI).
I shared my views (based on merely gutfeel, I can’t vouch for accuracy) in the thread but thought this forum also would be suitable to open the discussion.
Read: Unpacking the First Route Leak Prevented by ASPA
What Needs to Happen Where?
There are a few categories of ‘moving parts’ in the global Internet routing system that need upgrades for ASPA to see widespread adoption (Table 1):
| Category | (Non-exhaustive) list of implementations |
|---|---|
| Relaying Party packages | OpenBSD rpki-client, NLnet Labs Routinator, LACNIC/NicMX FORT, Cloudflare OctoRPKI, Mikhail Puzanov’s rpki-prover, ZDNS RPSTIR2 |
| Signer implementations | NLnet Labs Krill, Dragon Labs rpki.net, and a number of Regional Internet Registries (RIRs) have their own in-house Signer solutions. |
| BGP implementations | OpenBSD OpenBGPD, NIC.CZ BIRD, FRRouting, Nokia SR-OS, Cisco IOS XR, Juniper Junos, and many others, see the BGP speakers list |
| Standalone RTR servers | StayRTR, NLnet Labs RTRTR, GoRTR, rpkirtr |
| Integrated RTR servers | FORT, Routinator |
For there to be any ASPA deployment, at least one ASPA-capable implementation in all of the RP, Signer, and BGP categories is needed.
Without a Signer there isn’t anything for the RP to validate, without an RP there isn’t any for the BGP speaker to verify BGP UPDATEs against.
This is a great example of why the IETF process is so valuable: this process has brought together many stakeholders from different corners of the ecosystem each with different roles to jointly develop a solution for BGP route leaks.
Timeline
Below is a proposed timeline of how we could get to the widespread use of ASPA.
| 2023 | The early wave: ASPA support arrives in select BGP, RP, RTR, and Signer implementations. At the time of writing OpenBSD rpki-client and OpenBGPD; NLnet Labs Routinator, Krill and RTRTR, StayRTR, rpki-prover, and RIPE NCC have either already released ASPA-capable software or are in advanced stages to do so. These ‘early wave’ implementations are incredible achievements as there weren’t any examples for the developers to look at, they were building across unchartered territory. One Internet Exchange Point managed to deploy a fully ASPA-capable Route Server stack using bleeding edge software, however, this effort should be considered an outliner from a timeline perspective. |
| 2024 | The IETF ratifies ASPA by publishing a series of RFC documents detailing the specification. While SIDROPS at this moment in time is in the late stages of specifying the ASPA standard, the Internet Engineering Steering Group (IESG) and RFC Editor still need to review the draft documents — this might take another 6-10 months (from now). BGP monitoring software such as BGPAlerter and BGP. Tools might take an interest and start using ASPA data to enhance their alerting capabilities: a growing amount of ASPA data (which can be used to identify route leaks) is becoming available through the ‘delegated’ (permissionless) RPKI distribution channels. |
| 2025 | Having access to both published RFCs and multiple battle-tested RP implementations (which originated in the ‘early wave’), more and more RIRs will feel comfortable scheduling and committing development time to productize an ASPA offering for their respective RPKI dashboard/web portal/API services. Why 2025? RIRs oftentimes are somewhat conservative and like to see which way the wind blows before offering new services to their constituents. This is understandable as for an RIR to offer ASPA, the work involved is significantly more than just developing the technical Signer software. RIRs need to design (web-based) user interfaces, which is a big hurdle because for the first time, RIRs will move away from a ‘ROA-centric’ user interface to ‘the RPKI offers multiple applications’ (such as ASPA). As often is the case, going from 0 to 1 is extremely hard, from 1 to 2 still hard, and from 3 onwards it’s smoother sailing. RIRs also need time to develop training courses for their internal staff, for external outreach such as capacity building. An RIR can’t offer a new feature without explaining to its constituents what new technology does, how to use it, and how to troubleshoot it. It’ll take time before RIRs feel comfortable answering questions about ASPA anyone might have. |
| 2026 | General availability in commercial off-the-shelf (COTS) BGP speaker implementations (I expect most open-source implementations to be part of the ‘early wave’ or soon thereafter). Similar to how the RIRs need to develop training and documentation accessible for newcomers to ASPA, the COTS vendors need to develop ASPA-capable software, update procedures in Technical Assistance Centers, update and translate documentation to many languages, and train pre-sales engineers. The larger the COTS vendor the more work incorporating technology like ASPA as part of the product offering is. |
| 2027 | Large nationwide and international ISPs deploy ASPA verification. By now, many people will have flown around the world explaining the benefits of ASPA to ISPs both large and small, urging everyone to deploy ASPA verification and drop ASPA-invalid routes. Standing on the shoulders of giants: the published RFCs (by now three years old), the early wave RP/RTR implementations, the RIRs supporting ASPA in their hosted offerings since 2025, and now the recently gained access to commercially supported COTS BGP software in hand all contributed towards this moment. The large ISPs can deploy ASPA in their quality assurance environments, assess the revenue impact of deploying “if ASPA-Invalid then drop” EBGP routing policies, and schedule ASPA deployment through the ‘once-a-year-sw-upgrade’-window applicable to most of their critical equipment. |
I’m Optimistic
Of course, come 2027, many people on social media might be asking their ISPs “Why haven’t you deployed ASPA verification yet?!?!” without realizing that deploying something like ASPA at a global scale depends on a complicated long supply chain (complicated both in the technical realm expressed as software and in the realm of human-to-human conversation, such as training and outreach).
There are lessons I’ve learned from the global deployment of RPKI-ROV, a few of which I’d like to share publicly:
- There was an unfortunate long gap between people being able to create ROAs (without consequence, as for years virtually no organization was performing RPKI-ROV), and large ISPs truly being able to deploy well-tested stable software to do Route Origin Validation at their EBGP edge; that by the time 2019/2020 rolled around this ‘gap’ had resulted in many BGP routes being considered ROV-invalid due to (by then inconsequential and forgotten) ROA misconfigurations. This latter aspect, in turn, made large ISPs extremely hesitant to deploy RPKI-ROV “invalid = drop” EBGP routing policies as a potential for customer outages (aka revenue impact) was perceived.
- It took building additional software (extensions to traffic analyzers such as pmacct.net and Kentik.com) to be able to gauge exactly what the operational and revenue impact of deploying RPKI-ROV would be before large ISP senior management buy-in happened.
- In the global RPKI-ROV deployment, the Internet routing community went from ‘zero to one‘ in the context of using anything RPKI-based. Much auxiliary infrastructure had to be built indirectly related to the production and consumption of ROAs: for example, RIRs had to learn how to operate key materials stored in HSMs, issuance of Root CA certificates, and other aspects of PKI.
All in all, I’m optimistic.
With the collective ‘first RPKI’ experience under our belts, a positive outlook on ASPA-capable open-source BGP software suitable for Internet Exchange Point deployments, and a solid and diverse set of participants in ‘the early wave’; universal deployment of ASPA verification will be quite the journey — but hopefully smoother because of our prior experiences.
See a full list of currently valid ASPA objects.
Job Snijders is an Internet Engineer at Fastly where he analyzes and architects global networks for future growth.
Adapted from the original post which appeared on the SIDROPS mailing list.
Leave a Comment