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
