On 10/21/19 3:37 PM, Jeffrey Haas wrote:
BGP over ipsec works fine. But that said, it's mostly done with pre-shared keys.
Is anybody actually doing it in practice? Every transit and peering document I've ever seen just talks about TCP-MD5 (if it talks about authentication at all).
The ugly issue of ipsec is that the ecosystem really wants IKE to do the good things people associate with long lived sessions. I don't even vaguely pretend to be an ipsec/ike expert, but the wrangling over this and router bootstrapping issues generated a lot of heat and a small amount of light in IETF a while back.
Yes. ipsec (IP layer) itself isn't too bad. IKE is a complex mess. A functional mess, perhaps, but a mess nonetheless. I'd really like to hear from someone actually qualified on the cryptography side of things to chime in on whether long-lived symmetric keys are even really a problem anymore. If they're not, just generating a decent "session" key and statically defining an SPI is a lot more straightforward. OSPFv3 hopefully taught people some lessons with its initial lack of built-in authentication. "Just use ipsec". Ever tried to configure ipsec for multicast destinations/sources? Ugh. Authentication trailer is much simpler AND solves other issues as noted in the spec for it. Unfortunately, it's still new enough that getting gear that supports it can be somewhat difficult, and it certainly rules out most end-of-sale or extended-support gear that might otherwise be perfectly serviceable but isn't receiving feature updates.
And if you have a rather scaled out router, imagine the cpu melting that goes with a cold startup scenario where you have to get all of those IKE sessions up to start up your BGP. Now think what that does to your restart time.
Indeed, though I've seen a trend toward putting rather hefty CPUs on the control planes of "real" routers, nowadays, which I guess is welcome. It doesn't really contribute much to the overall cost of something that can push 100s of Gbps in hardware, anyway. -- Brandon Martin