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

On Mon, 11 Oct 2021 at 10:33, Tim Bruijnzeels <tim at nlnetlabs.nl> wrote:

> ASPA is orthogonal to BGPSec. It lets AS holders declare who their
> upstreams are
> (in the context of BGP Path, not business relation). Even if this
> information is
> not yet used in routers in an automated way, a clear text validated output
> with
> this information can already be valuable to operators, e.g. for
> provisioning.
> (This is also how ROAs were oftentimes used in the early days).
>

ASPA without BGPsec is barely different to RPSL. Yes, I am squinting very
hard to make that conclusion, but essentially if I have to trust RIPE NCC
are doing the right thing with their RPKI trust anchor, I might as well
just get the results of the policy statements (aut-num records) without all
the cryptographical stuff in the way that does not help at all in terms of
ease of use.

With BGPsec, you're certifying that the AS Path seen in the path attributes
of a message is valid and hasn't been falsified by your peer. OV verifies
that the origin seen is the origin permitted, and is out-of-band. ASPA
verifies that the path seen is a valid and authorised path by that origin,
out-of-band. Without BGPsec, OV and ASPA provide no cryptographic
authentication of messages at all. That's fine today when most hijacks are
fat-finger incidents, but not when someone maliciously tries to either
steal a prefix or instigate a denial of service to a prefix.

Without BGPsec, we might as well just forget about RPKI entirely and ensure
all the RIR IRRdbs provide sufficient validation that only the true
operator of a prefix can publish information... And then abandon everything
because ~25 years of RPSL has proven that people can't be bothered to keep
records up to date because of insufficient value in doing so.


> Wrt BGPSec.. I am actually very happy to see that so many people are in
> favor of
> supporting it. I hope that router vendors are watching. To the best of my
> knowledge
> BGPSec has only been implemented in Bird and Quagga. The main value of
> supporting
> BGPSec in the hosted system would not be to test the protocol as such.
> This has
> already been done using Bird and Quagga and the RPKI tool set by Dragon
> Research
> Labs.
>

To support BGPsec today on a router with software support, you need to
create your own RPKI delegated repo, to establish keys that are regularly
rotated, to make sure your signing keys are regularly resigned and valid,
to ensure there is sufficient capacity on the server so that not only can
you support a thundering herd of relying party software pulling all the
updates but that you're protected from some script-kiddy performing a DDoS.
Not to mention having to run a public server somewhere, which would mean a
lot of hassle from their IT departments etc.

To support BGPsec in the hosted world, you... Upload your signing keys,
specifying which ASNs they are valid for.

In the former model, 95%+ of engineers can not be bothered with all the
hassle. In the latter model, 95% of engineers bung a couple of keys in the
portal from their router.

It's all about the level of effort required for the operator, and with a
hosted scenario it's almost no effort at all.


> It would really help to convince my idea of priority on this if at least a
> couple
> of router vendors would indicate that they are willing to listen to
> operator wishes
> here and implement.
>

Router vendors follow customer requests. Customers won't request things
that they don't consider important. Customers won't consider BGPsec
important unless it's either easy to do.

Literally all that is being suggested here is that router signing keys be
made possible to upload into the RPKI dashboard. It is a small amount of
effort that allows BGPsec to be trivial to try out. I genuinely don't
understand the reason for obstruction here, what am I missing?

Matthew Walster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20211011/487e73ea/attachment.html>