On Mon, 11 Oct 2021 at 10:33, Tim Bruijnzeels <[email protected]> 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
