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

> On 6 Oct 2021, at 12:55, Matthew Walster <matthew at walster.org> wrote:
> 
> 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.

A fundamental issue that I see is that BGPSec validation only has 'valid' or 'invalid'.

If memory serves me well this is because a downgrade attack exists where the signature by an ASN is simply removed.

As a result however...
1- BGPSec fails hard, not open
2- incremental deployment is hard

@1- BGPSec fails hard, not open

Contrary to Route Origin Validation (with ROAs) there is no 'not found' state. 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.

@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.

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 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.

Kind regards,

Tim