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. 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). 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. > > As you can see, a dozen years ago was already too late, but our idea > > then was to > > > > - construct protection guarantees for packet flows using IPsec, > > - to use anonymous or anonymous-like key exchanges to key IPsec, > > - and to use channel binding from application layer protocols that can > > authenticate more useful names than IP addresses. > > Had SSL/TLS not come along first, there would been immense pressure to make > this all work. That's likely true, but we can't really know. > These are OS implementation details, right? There is nothing > inherently impossible about filtering on 4-tuples where the app > supplies the root CA it likes to IKE, right? I mean, that's what TLS > is doing, but it's just doing it implicitly from the OS layer > filtering. RFC 5660 gives two implementation designs: tag packets as they move up (or down) the stack with relevant metadata, or "edit" the RFC 4301 SPD and PAD in very specific, simple, and narrow ways. Both schemes allow the host to guarantee continuity of protection to a logical packet flow -- a "connection". The primary scheme given (config "editing") is rather unintrusive, requiring not changes to how packets move up and down the stack. The alternative scheme (packet tagging) is potentially very intrusive for some operating systems, though it is the simpler scheme. Nico --
