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

On Wed, Oct 06, 2021 at 04:08:00PM +0200, Tim Bruijnzeels wrote:
> Contrary to Route Origin Validation (with ROAs) there is no 'not
> found' state. 

I don't think it is helpful to attempt to put BGPsec and ROAs in the
same equivalance class, draw parallels and then conclude that the
'not-found' state is something problematic that is lacking in BGPsec.
The concepts and designs of both technologies are very different.

> This means that if there is large scale issue with RPKI itself or your
> ability to validate RPKI data, BGPSec will end up saying your path is
> invalid. I think this is a rather scary property.

Indeed, BGPsec has a hard dependency on the RPKI being up and healthy.
This is unavoidable consequence of the design decision to make one
technology (BGPsec) dependent on another technology (the RPKI
framework).

The same of course applies to Route Origin Authorizations: if there is a
large scale issue with the RPKI, one's ability to work with given RPKI
data is impacted. I think the RIRs and NIRs are increasingly
understanding that their RPKI services are expected to perform
flawlessly. Great operational discipline is expected from Trust Anchors.
(this applies to the TLS WebPKI too).

At the end of the day, BGPsec (and RPKI) will not fancy everyone or be
applicable for every possible situation, that's OK.

> @2- incremental deployment is hard
>
> BGPSec validation can only result in 'valid' if ALL ASNs on the path
> sign. Until that time the path will be 'invalid'. So BGPSec validation
> can only really be turned on after this point has been reached, and
> until this point has been reached there is no benefit and therefore no
> incentive to operators to buy BGP hardware that supports BGPSec, and
> publish their router keys as BGPSec certificates.

In practise the characteristic that you describe means that BGPsec
deployment can happen incrementally on (for example) private peering
between two companies. Indeed, not on 'full table transit' sessions.
For example, in at large-scale cloud provider to cloud provider peering
sessions, there often times are no downstream ASNs to be seen on either
side. The traffic volumes are high, the number of routes on each side
fairly low.

As BGPsec-signed paths cannot traverse non-BGPsec topology, partial
BGPsec deployment forms islands of assured paths. As islands grow to
touch each other, they become larger islands.

To do incremental deployment, both sides simply need to agree to use
BGPsec, and not permit non-BGPsec sessions to establish at the
particular intersection point. Keepin mind that a possible solution to
prevent 'downgrade attacks', is to not tolerate downgrades...

An analogy: I don't think anyone is expecting a BGP session to establish
if there is a mismatch in TCP-MD5, TCP-AO, or IPsec configuration
between two peers. The goal is for sessions NOT to establish if the
password is wrong.

> Because of the above I don't think that adding BGPSec support in the
> hosted interface will help. Don't get me wrong.. I would *love* for
> BGPSec to succeed. 

I believe the path to success starts with actually making the technology
available to increasingly larger groups of people. Literally making it
"as hard as possible" to deploy BGPsec (aka, "maintaining the status
quo"), will unsurprisingly lead to BGPsec 'not succeeding'. I don't know
what the future holds and whether BGPsec will 'succeed', but I do know
there is only one way to find out: making an honest effort to make it
work.

[ anecdote: I remember that in the early days of IPv6 it was quite hard
to get IPv6 blocks in the RIPE region. To receive an IPv6 PI block, you
had to be BGP multi-homed. This requirement did not exist for IPv4 PI
space. Consequently, many people continued to request IPv4 PI blocks not
spending any time on IPv6, because the RIR wouldn't give them IPv6 space
to deploy. ]

> I would like to be proven wrong in my interpretation. But as it stands
> I think a fundamental discussion is needed (in the IETF as well) on
> how it can be made incrementally deployable - such that there is
> benefit to early adopters - and get a safe landing in case of errors.
> If this can be achieved, or if someone can explain how this is already
> achieved, then I would be much less skeptical.

I don't know what your interpretation is based on, we clearly lack
common experience and perspective on BGP routing.

As for 'safe landing' (a nice sounding phrase), but in DNSsec there are
no safe landings either. It is possible to productively use and operate
systems in which the 'safe landing' would be to disable the system
entirely.

I recommend everyone to read https://datatracker.ietf.org/doc/html/rfc8374
and https://datatracker.ietf.org/doc/html/rfc8207 to get a feel for why
some choices were made and what gotcha's exist.

Kind regards,

Job