[routing-wg] Add BGPsec support to Hosted RPKI?

Hi all,

Please forgive me for top-posting (and trimming the recipients list).
There seems to be support for both BGPsec in Hosted RPKI and for “Publish in Parent" - RFC8181. 
As I’m currently working on the roadmap for Q1 2022, I will discuss with the team what needs to be done in order to implement both proposals, possible dependencies and other work.
In order to implement BGPsec for hosted RPKI for example, we also need to keep in mind UI work on the RPKI Dashboard to make this easy to use (and easy to understand).

Kind regards,
Nathalie Trenaman
RIPE NCC



> Op 11 okt. 2021, om 12:36 heeft Job Snijders via routing-wg <routing-wg at ripe.net> het volgende geschreven:
> 
> 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
>