On Mon, Oct 11, 2021 at 11:33:40AM +0200, Tim Bruijnzeels wrote:
> Why now?
There are published RFC and running code. Time for the next step.
> RIPE NCC may have substantial resources, but they are applied
> sequentially. Perhaps RIPE NCC can shed a light on the effort
> involved, but I suspect it's more than we might think.
It is not clear to me what you mean with "more than we might think".
I think a standard PKCS#10 / PKCS#7 exchange is less involved than
implementing support for an entirely new Signed Object profile?
Additionally, to implement BGPsec support in the hosted environment, the
developers can take inspiration from prior-art. For ASPA no examples
exist yet.
> In that context, I am not against BGPSec as such, there are just
> things that I would like to see first:
Thank you for sharing your personal wishlist. The above 'context' seems
to depend on an assumption that work progresses sequentially.
> 1. Publication Service
>
> I think this has immediate applicability to anyone considering running a
> delegated
> CA. It's also in the interest of the ecosystem to limit the excessive growth
> in the
> number of repositories.
>
> 2. ASPA
>
> This is in draft status, but so were ROAs when the production system launched
> in
> January 2011.
I'll with the working group a brief overview of where ASPA is, which
should help understand why ASPA probably is more of a 2022/2023 project.
I'm personally involved as co-author of the ASPA specification.
* ASPA is 2 drafts, 0 RFCs:
https://datatracker.ietf.org/doc/search/?name=aspa&activedrafts=on&rfcs=on
This means that ASPA has not yet received review from the wider
IETF community.
* As of yet no codepoints have been assigned to ASPA
https://www.iana.org/assignments/rpki/rpki.xhtml
* No RPKI-to-Router protocol extension has been proposed for ASPA.
* At the IETF 111 SIDROPS meeting it was suggested to first
construct a testbed before moving ASPA forward. See slids 11 and
onwards:
https://datatracker.ietf.org/meeting/111/materials/slides-111-sidrops-running-code-sidrops-00
The testbed does not exist yet: https://github.com/SIDROPS/ASPA-testbed
* ASPA's running code status page still is empty
https://trac.ietf.org/trac/sidrops/wiki ("AspaImplementations?" is a
non-existing wiki page)
* Only a few months ago an issue was discovered in the ASPA
verification algorithm in relationship to IX Route Servers. This
has since been resolved (in -07 of the draft). To me it is an
indicator that ASPA's specification still is in flux.
All in all ASPA undeniably is making progress, I would love for a
RPKI-based routing policy signaling mechanism to exist, but there is a
lot of work yet to be done.
I would suggest to start a discussion about adding ASPA to the RPKI
Quarterly planning as soon as passed at least "IETF Working Group Last
Call".
Kind regards,
Job