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

Reply via email to