<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 5 Oct 2021, 10:42 Job Snijders via routing-wg, <<a href="mailto:routing-wg@ripe.net">routing-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If at this point there still are undocumented gotcha's, they aren't<br>
gonna be found in a vacuum. Lowering barriers (by for example making it<br>
easier to manage BGPsec in the RPKI dashboard) will increase the number<br>
of people able to take a look at BGPsec, and subsequently improve the<br>
technology.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I would like to see router signing key publishing support in the RPKI dashboard.</div><div dir="auto"><br></div><div dir="auto">Matthew Walster</div><div dir="auto">(Now you see why I'm called waffle...)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>