On 6/9/20 5:12 PM, Nico Williams wrote:
On Tue, Jun 09, 2020 at 04:32:38PM -0700, Michael Thomas wrote:
On 6/8/20 12:02 PM, Nico Williams wrote:
Also, IPsec got a lot of things wrong. It's simply not usable at
Internet scale as originally intended because... it's IP-layer, so it
deals in discrete packets and IP addresses. Well, discrete packets do
not define application connections/sessions[*], IP addresses are too
dynamic and useless for authentication and authorization[**], and
configuration is ETOOHARD.
Yes, but that's a feature not a bug in this particular case. I really don't
find it believable app developers would have had a hard time with making the
OS calls needed anymore than making the calls that the TLS libraries
require. And as always: when something is widely used, it gets care and
feeding. So if ipsec is still clunky, and says it's because it's not being
widely used, and the niche cases of vpn's can suck it up.
The IPsec model is busted even for VPNs. To mitigate the issues that
arise in VPNs you really need to assign a unique internal address to
each user or accept that authorized users may mount certain attacks on
each other.
Ok, i'm confused. The demultiplexing of the 5-tuple deals with that,
right? Just like with TLS which implicitly uses that demultiplexing the
OS provides as well.
But there's nothing about ESP itself that relegates it to VPN usage
only! Only the IPsec architecture (RFC 4301) causes that, not anything
about ESP.
ESP would have been _great_ for transport-mode IPsec and widespread
application use if RFC 5660 or something like it had been widely
implemented earlier (earlier even than it was written). The relevant
idea was invented in the 90s, even, the Solaris/Illumos IP_SEC_OPT
socket option (invented by Dan McDonald, I believe).
Yeah, I certainly was a fan of the idea of transport mode ESP. But it
lost and that is that... until suddenly... though i would be being
overly dramatic to say this was some sort of killer problem.
So, I wouldn't say that IPsec being needlessly difficult to use is a
feature. No, it's a bug. TLS offload is necessarily harder to
implement than ESP offload, so we've missed a valuable opportunity to
increase the performance of network security, thus hindered its
adoption.
I would call that a small disaster, honestly. Not a feature. A bug.
But bugs can be fixed. And especially if enough love is thrown at them.
So the long and short of this entire issue seems to be is, is the
uncaught error rate serious enough that warrant rethinking weak
transport and frankly L2 layer error detection? Crypto hashes certainly
are a gigantic cannon to make that problem go away if used correctly.
considering they are becoming almost table stakes for most IP traffic,
killing two birds with one stone my not be so bad.
Mike
