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

On Tue, 5 Oct 2021, 10:42 Job Snijders via routing-wg, <routing-wg at ripe.net>
wrote:

> If at this point there still are undocumented gotcha's, they aren't
> gonna be found in a vacuum. Lowering barriers (by for example making it
> easier to manage BGPsec in the RPKI dashboard) will increase the number
> of people able to take a look at BGPsec, and subsequently improve the
> technology.
>

In general, I'm opposed to rushing into adding support for experimental
technologies in things like dashboards, as it can overcomplicate matters
and make people wary of giving things a try.

I have recently taken the time to understand BGPsec, and cleared up a
number of misconceptions I had around how it operates -- it's actually what
most people assume RPKI OV is doing. The barrier to entry is literally just
publishing public keys of the routers signing the messages, and ensuring
they are made available to routers (ok, BGP daemons) to do the checking.

To me, there's two main issues with BGPsec, and that is the memory
requirement of storing all the published keys, and the CPU impact of
signing and/or verifying so many things. These are things that may be
addressed over time with the natural progression of route processors
becoming more capable (time to retire that Cyrix 200 yet?) and utilising
BGPsec only on "sensitive" peers, such as at IXP route servers and with
customers etc.

What is abundantly clear, however, is that BGPsec will not gain any
traction at all unless it is easy to try. Operating a delegated RPKI repo
is sufficiently complex that most can't be bothered. That is why RPKI OV
has seen the uptake it has -- there is an easier route: use the hosted
repo.

Considering the only thing the RPKI repo needs to support BGPsec is the
router signing keys, with no risk of affecting existing ROAs etc, it seems
like minimal effort to add the ability to upload keys through the
dashboard. Enabling BGPsec validation on a router to try it out is then
even less effort than what is required to support RPKI RTR and OV that many
networks have ended up doing over the past couple of years.

In my opinion, the low level of effort required to support uploading of
keys to a hosted repo is more than repaid by the potential boost to support
BGPsec would receive, even if BGPsec would be radically changed in the
intervening time, the publication of signing keys is highly unlikely to
change.

Is this an action RIPE NCC *needs* to take? Of course not. I think it's
well within the remit though, has precedent with the whole whois/RDAP
story, does not open any "slippery slope" arguments because it's such a
minor change with clear benefit, and will need to be done anyway should
BGPsec gain widespread traction... As Job says, it's best to identify
problems now, while it's early. It lowers the barrier to entry, which
should encourage the authors of BGP daemons to support validation, and
maybe even support signing themselves. There is no appreciable downside
here.

I would like to see router signing key publishing support in the RPKI
dashboard.

Matthew Walster
(Now you see why I'm called waffle...)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20211006/5e6685fe/attachment.html>