Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/19 4:41 PM, Jeffrey Haas wrote: I'm not someone qualified, but I'll regurgitate what I've distilled from past conversations with those who are.:-) Presuming your key is strong enough, it may be infeasible to break it in a time that's of interest to the parties involved. The primary issue is the usual issue of trying to keep anything secret: eventually disclosure becomes an issue. And if you have no procedure for periodically updating your keys, it becomes a problem. Going back to my thought of using IKE vs. a static SPI, we run into the same problem with rekeying the long-term secret. If it's symmetric, you have to get both parties involved. That will be true if it's IKE with a PSK, a static SPI, or TCP-MD5. I guess the meat of my question is, given modern cryptography (algorithms, best practices, actual system implementations, etc.), is the periodic re-keyed offered by IKE with PSK any better than simply establishing a static SPI (treating the SPI session secret as a slightly less human-friendly PSK)? If not, then you can do away with IKE entirely which drastically simplifies things. It's also the status quo for many implementations of OSPFv3-over-IPsec that I've seen. My impression is that any means by which a long-lived session using the same symmetric cipher secret can compromise the security of either that session or any other session keyed using the same "parent" keying material is now considered a weakness in the cipher or cryptosystem, as appropriate, and modern ciphers and systems as such do not exhibit such deficiencies. It's also no worse than TCP-MD5 which, as you pointed out, requires both ends to cooperate in a re-keying, too. I'm not even aware of any mechanisms to allow key overlap during a re-keying process in TCP-MD5 which might otherwise be one advantage of IKE using PSK. If your SPI secret gets disclosed, you re-key manually. If your TCP-MD5 secret gets disclosed, you rep-key manually. If your IKE PSK secret gets disclosed, you re-key manually. My only real goal, here, is to be as good or better than TCP-MD5 to address earlier concerns about people not liking TCP options while also not resorting to TLS. (As a note, I'm thinking out loud with all this, not trying to suggest policy proposal) -- Brandon Martin
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
> On Oct 21, 2019, at 4:17 PM, Brandon Martin wrote: > > 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? Absolutely. In the SP sector? Less clear. >> 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. I'm not someone qualified, but I'll regurgitate what I've distilled from past conversations with those who are. :-) Presuming your key is strong enough, it may be infeasible to break it in a time that's of interest to the parties involved. The primary issue is the usual issue of trying to keep anything secret: eventually disclosure becomes an issue. And if you have no procedure for periodically updating your keys, it becomes a problem. The problem is exacerbated by the fact that inter-provider key sharing is a PITA. If you're having situations where you have to hit this list as a NOC of last resort, now try to imagine a regular cadence of conversations to update your key. And then deal with the fact that key rotation for TCP-MD5 can be hit or miss. In practice, this means that if you had someone that knew your keys and was kicked out of your company, they have the ability to do bad stuff. The ability to more easily update your session keys is one of the big wins for tcp-ao. A lot of the issues behind transport security are mitigated - and this is a point I end up raising to various IETF security reviewers on a regular basis when talking about control plane protocols: - It's possible to reduce the attack surface by using things like GTSM. You've acquired the key somehow? Great - now get packets to that link. - Similarly, protecting the link itself through things like MACSEC is a way to reduce the attack surface. - What are the actual attacks they can do? For BGP, knocking over the session is often the goal. The necessary man in the middle for an active hijack if you can insert yourself into the conversation is absolutely doable... but you're better off just hijacking a router through another compromise and then simply injecting bad routing data. Where much of this puts us is iBGP is of far more interest to an active attacker. Protection of internal routing infrastructure, including firewalls that are properly configured, again can help here. And this becomes even more tasty if you're in an environment making use of SDN-ish stuff. > > OSPFv3 hopefully taught people some lessons with its initial lack of built-in > authentication. "Just use ipsec". This one, IMNSHO, can be blamed on specific IETF religion at the time. The fallouts around this are one of my more favored examples of "this needed operational review". > >> 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. Believe me, implementors are happy to have some extra cycles available. However, too many target platforms are either still under-powered or have operational requirements that push them toward slower CPUs. And even for large enough platforms, security computation can eat every spare cycle you have. Generally, a conversation with crypto experts will eventually devolve to "key lengths/cipher is now considered weak, use the next one" - which is shorthand for saying "if you have available cpu, you're not using strong enough crypto". :-) -- Jeff
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
This was one thing I highlighted to the people telling me how I secure my network wrong. If it's HTTP and you lose a few clients maybe they don't care. If it's BGP I have one client and I care a lot and that session dropping can be gigs to tbps of traffic. Sent from my iCar > On Oct 21, 2019, at 4:20 PM, Jeffrey Haas wrote: > > Exactly how the cert lifetime interacts with peering sessions is likely to be > several flavors of ugly.
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
> On Oct 21, 2019, at 3:25 PM, Brandon Martin wrote: > > On 10/21/19 11:30 AM, Keith Medcalf wrote: >> Why cannot one just put the MD5 authenticated connection inside a TLS >> connection? What is the advantage to be gained by replacing the >> authentication mechanism with weaker certificate authentication method >> available with TLS? > > Self-issued certificates with either CA pinning or end-certificate hash > pinning is arguably more secure than a shared passphrase as used by TCP-MD5 > in that someone with knowledge of the secrets of one end cannot use it to > impersonate the other end whereas a shared passphrase is inherently shared > and symmetric in that respect. Whether that really provides much value in > the context of a BGP session is perhaps questionable. Considering a lot of hand-wringing from the various security conscious folk is over the ability to easily re-key, I think it mostly just complicates things. Certs are effectively a much nicer single use key. Exactly how the cert lifetime interacts with peering sessions is likely to be several flavors of ugly. > > Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations > and difficulty of configuration aside)? It would also solve the TCP-RST > injection issues that TCP-MD5 was intended to resolve. You can use null > encryption with ESP or even just AH if you want authentication without > confidentiality, too. Or are we all going to admit that ipsec is almost dead > in that it's just too darned complex? Just run BGP over TCP as normal and > install a security policy that says it must use ipsec with appropriate > (agreed-upon) authentication. "Just", right? BGP over ipsec works fine. But that said, it's mostly done with pre-shared keys. 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. 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. -- Jeff
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
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
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/2019 1:25 PM, Brandon Martin wrote: Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations and difficulty of configuration aside)? It would also solve the TCP-RST injection issues that TCP-MD5 was intended to resolve. You can use null encryption with ESP or even just AH if you want authentication without confidentiality, too. Or are we all going to admit that ipsec is almost dead in that it's just too darned complex? Just run BGP over TCP as normal and install a security policy that says it must use ipsec with appropriate (agreed-upon) authentication. "Just", right? I've used BGP over IPSec before in my labs between EdgeRouter models for testing purposes. Other then making sure there is either a connected route or static route (if doing multihop) to the other side, its works. But like you said, interop issues and all may cause issues... Speaking of issues, if you run StrongSwan for IPSec with BGP on the same router/system, make sure to disable charon's processing of routes or you'll be burning major CPU cycles. See: https://wiki.strongswan.org/issues/1196 -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 10/21/19 11:30 AM, Keith Medcalf wrote: > Why cannot one just put the MD5 authenticated connection inside a TLS > connection? What is the advantage to be gained by replacing the > authentication mechanism with weaker certificate authentication method > available with TLS? Self-issued certificates with either CA pinning or end-certificate hash pinning is arguably more secure than a shared passphrase as used by TCP-MD5 in that someone with knowledge of the secrets of one end cannot use it to impersonate the other end whereas a shared passphrase is inherently shared and symmetric in that respect. Whether that really provides much value in the context of a BGP session is perhaps questionable. As has been pointed out elsewhere in the thread, TLS does also support PSK-based authentication and keying rather than certificates. It's not commonly used since the normal uses of TLS are one-server<->many-clients which doesn't lend itself well to such things, but it's at least defined. Wouldn't ipsec be a "cleaner" solution to this (buginess of implementations and difficulty of configuration aside)? It would also solve the TCP-RST injection issues that TCP-MD5 was intended to resolve. You can use null encryption with ESP or even just AH if you want authentication without confidentiality, too. Or are we all going to admit that ipsec is almost dead in that it's just too darned complex? Just run BGP over TCP as normal and install a security policy that says it must use ipsec with appropriate (agreed-upon) authentication. "Just", right? -- Brandon Martin
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On Mon, Oct 21, 2019, at 17:30, Keith Medcalf wrote: > Why do you need to do anything? TLS is Transport Layer Security and > it's sole purpose is to protect communications from eavesdropping or > modification by wiretappers on/in the line between points A and B. MD5 > in BGP is used for authentication (rudimentary, but authentication > nonetheless). TLS can also be used for authentication (in several ways), even if it's not the most appropriate for this situation.
RE: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
>On 21/10/19 6:30 pm, Bjørn Mork wrote: >> Yes, and I really like Julien's proposal. It even looks pretty >> complete. There are just a few details missing around how to make the >> MD5 => TLS transition smooth. >At least for those systems that run on Linux (which is most all of the >major's except Juniper) I suspect if we went to the relevant kernel folk >with a clear plan on how handling TCP-MD5 in a way that would make >transitions much easier they'd listen. Why do you need to do anything? TLS is Transport Layer Security and it's sole purpose is to protect communications from eavesdropping or modification by wiretappers on/in the line between points A and B. MD5 in BGP is used for authentication (rudimentary, but authentication nonetheless). Why cannot one just put the MD5 authenticated connection inside a TLS connection? What is the advantage to be gained by replacing the authentication mechanism with weaker certificate authentication method available with TLS? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On 21/10/19 6:30 pm, Bjørn Mork wrote: > Christopher Morrow writes: > >> isn't julien's idea more akin to DOT then DOH ? > > Yes, and I really like Julien's proposal. It even looks pretty > complete. There are just a few details missing around how to make the > MD5 => TLS transition smooth. At least for those systems that run on Linux (which is most all of the major's except Juniper) I suspect if we went to the relevant kernel folk with a clear plan on how handling TCP-MD5 in a way that would make transitions much easier they'd listen. The troll response at the top of my post was actually based on a response from one of the kernel folk, who dislike TCP options even more than network operators. > Sorry for any confusion caused by an attempt to make a joke on DoH. I > didn't anticipate the sudden turn to serious discussion :-) Which > obviously was a good one. I am all for BGP over TLS, so let's discuss > https://laptop006.livejournal.com/60532.html If anyone is at all interested in this I'm happy to discuss and flesh out anything that's not clear. After I wrote this (over a few bottles of red on the flight to linux.conf.au this year) I sent it to a bunch of people that had expressed interest, including a few BGP implementations, but nobody bit.
