Heya NANOG,
I thought this email conversation might be of interest to the group:
https://mailarchive.ietf.org/arch/msg/sidrops/RdbccLbXEHUrmmdIS5K9GOdJFXA/
Kind regards,
Job
----- Forwarded message from Job Snijders <j...@fastly.com> -----
Date: Fri, 19 May 2023 20:54:26 +0200
From: Job Snijders <j...@fastly.com>
To: sidr...@ietf.org
Subject: Re: [Sidrops] Estimating timeline for ASPA Deployment
Dear Tony,
On Fri, May 19, 2023 at 10:18:58AM -0400, Tony Tauber wrote:
> I wonder what people think of likely soonest target dates for adoption
> of ASPA?
... Where do psychics go to dance?
The crystal ball ;-) ...
Disclaimer: The following is based on unsubstantiated information and/or
my gutfeeling, I can't vouch for accuracy.
I'd like to share some information categorized as 'here work needs to be
done', a timeline, and a conclusion referencing earlier RPKI
experiences.
What needs to happen where?
---------------------------
There are a few categories of 'moving parts' in the global Internet
routing system that need upgrades in order for ASPA to see widespread
adoption.
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 solution.
BGP implementations: OpenBSD OpenBGPD, NIC.CZ BIRD, FRRouting,
Nokia SR-OS, Cisco IOS XR, Juniper Junos, and
many others, see the 'BGP speakers' list at:
http://largebgpcommunities.net/implementations/
Standalone RTR servers: StayRTR, NLnet Labs RTRTR, GoRTR, rpkirtr
Integrated RTR servers: FORT, Routinator
In order 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
========
2023 - "the early wave": ASPA support arrives in select BGP, RP, RTR,
and Signer implementations.
At the moment of writing OpenBSD rpki-client & OpenBGPD; NLnet
Labs Routinator, Krill & RTRTR, StayRTR, rpki-prover, and RIPE
NCC have either already released ASPA-capable software or are in
an advanced stage 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 fully ASPA-capable
Route Server stack using bleeding edge software, however this
effort should be considered an outliner from a timeline perspective:
https://mailman.nanog.org/pipermail/nanog/2023-February/221471.html
2024 - The IETF ratifies ASPA by publishing a series of RFC documents
detailing the specification. While SIDROPS (this working group)
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; all in all
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 constitutes. This is very 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 ever RIRs will move away from an '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 their
constitutes 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 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, train
pre-sales engineers. The larger the COTS vendor the more work
incorporating a 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
3 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.
In conclusion:
Of course - come 2027 - many people on social media might be inquiring
their ISPs "why haven't you deployed ASPA-verification yet?!?!11" -
without realizing that deploying something like ASPA at 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 organisation 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 gauge exactly what the
operational and revenue impact of deploying RPKI-ROV would be, before
large ISP senior management buy-in happened.
Additionally, in the global RPKI-ROV deployment the Internet routing
community went from 'zero to one' in context of using *anything*
RPKI-based. Much auxiliary infrastructure had to be build 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, 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
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.
この調子でがんばれ！
Job
----- End forwarded message -----
