This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] Add BGPsec support to Hosted RPKI?
- Previous message (by thread): [routing-wg] Add BGPsec support to Hosted RPKI?
- Next message (by thread): [routing-wg] Add BGPsec support to Hosted RPKI?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at fastly.com
Mon Oct 11 12:36:19 CEST 2021
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
- Previous message (by thread): [routing-wg] Add BGPsec support to Hosted RPKI?
- Next message (by thread): [routing-wg] Add BGPsec support to Hosted RPKI?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]