On Tue, Jul 29, 2014 at 11:03 AM, Daniel Kahn Gillmor <[email protected]> wrote: > hi folks-- > > At the end of the wg meeting in toronto, Sharon Liu asked (as noted in > the minutes): > >> Can this problem be resolved in a different way? Why isn't IPsec used more >> widely? > > [...] > Has anyone on this list explored the merits and costs of IPsec as a > comparison with the other proposals?
IPsec for this might mean several different things: a) in-band ESP with an in-band KE (keys exchanged in TCP handshake or similar) b) ESP with an in-band KE -- like (a) but ESP at same layer as today c) ESP, IKE, but not the whole IPsec system -- like (b) but with IKE d) ESP, IKE, the whole IPsec shebang, but with automated SPD/PAD management to preserve continuity (see RFC5660) e) the whole IPsec enchilada w/o RFC5660 or similar f) something else? what? Let me take these in turns. a) Resembles the proposed protocol. Pros: uses off-the-shelf protocol elements (so would TLS, but I digress). Cons: more overhead? dunno. b) Pros: more protocol elements and code reuse. Cons: can't think of anything serious, but it does require some IPsec inbound/outbound packet handling changes (which amount to the equivalent of what RFC5660 does). c) Pros: more protocol elements and code reuse still. Cons: something like RFC5660 would have to be developed, so might as well go with (d) if you'd go with (c)! d) RFC5660 exists for just this sort of use case! Pros: even more protocol elements and code reuse; it's "pure" as far as IPsec goes. Cons: requires a full IPsec stack; no implementations exist (but then, much else would benefit from having implementations, so it's worth considering). e) Not secure or not scalable. The problem is that IPsec protects packets, not packet flows, and the only way to scale IPsec is to have very permissive policies (e.g., "all peers with certs from this CA get to claim any IP address in these blocks", or "any peer with any credential can claim any IP address in these blocks") which are not secure (a node could bump another off the network, take over it's claimed IP address, take over extant flows). This is what RFC5660 addresses. So there's no point to (e); pick (d) if you'd pick (e). f) If someone fills this out I could analyze it. In-lining the KE has its benefits: no externalities like impacts on firewall configuration (to permit IKE). There might be externalities to in-lining the KE, but I'll let someone more familiar with them describe them, if any. The biggest problem with an IPsec-based approach is that nobody cares. IPsec implementors mostly care about VPN first (arguably because IPsec for end-to-end didn't and couldn't have worked out, not w/o RFC5660 or similar). The tcpinc would-be implementors, if they aren't IPsec implementors, are likely to see IPsec as intolerably complex. On the other hand, use of IPsec for this wouldn't be that hard to pull off (most of the necessary code exists on all relevant platforms) -- the biggest hurdle is a social one, I think. Not using IPsec brings up all the same issues as using TLS in an IPsec end-to-end environment (double encryption or deep packet inspection or carefully crafted policy), but if IPsec end-to-end environments are rare, who cares? (A: anyone who wants to increase the reach of IPsec for end-to-end.) Really, an ECDH key exchange + a simple ESP-like authenticated encryption using AES in some decent AEAD mode is dead-simple by comparison to IPsec. It's hard to blame tcpinc's proponents for eschewing IPsec; I don't. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
