Hacker News Reader

> IPsec is extremely difficult to use correctly, or even at all.

No, it's not.

Some IPsec implementations are kludgy and lack proper granularity/control over their configurations. It is also very flexible, so you can of course misconfigure it to the point where the whole setup becomes a royal clusterf#ck, but doesn't mean it is "extremely difficult to use correctly". It works really well for a wide range of common scenarios, each of which is not that hard to configure once one knows what they are doing.

Some of the obstacles really hit you when your working with different systems, if you connect the same systems then just mirror the config but when each end uses different terminology it can get confusing unless you know what you're doing. I don't think I'd agree that it's extremely difficult but it's nontrivial sometimes.

Try to connect TLS/SSL VPNs from different vendors....

BITW ("bump in the wire") is easy to use. Trivial. It's just devices you insert in a point-to-point link to encrypt it. You don't even need IPsec for that, but whatever.

SG ("security gateway", aka VPN) is reasonably easy to use, especially if you assign users /32s (for IPv4) and inject those into you IGP -- then you cannot have the attack I mentioned.

Transport mode is very difficult to use correctly and safely, or even at all, in any network with more than a few nodes or with fluid IP address assignments.

For transport mode, the best answer, really, would be to use BTNS [0] and connection latching [1] so that you can just use IPsec from the application (via socket options or moral equivalent), performing channel binding to application-layer authentication, or else certificate chain validation and authorization at the application layer. But this hasn't been implemented. Solaris/Illumos has some IPsec-related socket options, and it will create and/or latch SPD entries (what traffic to protect and how) policy, but not SAD entries (how to authenticate peers) nor PAD entries (how to authorize peers) -- i.e., half-way to RFC5660 :(

[0] https://tools.ietf.org/html/rfc5386 [1] https://tools.ietf.org/html/rfc5660

> This means that part of a TCP connection's packet flows may be protected by SAs with one peer, and later by SAs with... a different peer

Honest question, why is this a problem? If I really care about protecting my application traffic I am going to use TLS.

I skimmed the RFC, and it mentions applications that "rely on IPsec for session protection". So is it targeted more towards protecting HTTP traffic and other insecure protocols that are still in use today?

> If I really care about protecting my application traffic I am going to use TLS.

One might say that you'll use TLS because IPsec doesn't cut it for application traffic. Well, OK, so what traffic is IPsec good for? (ICMPs.)

If you're using TLS and IPsec then you're wasting resources by using two layers of session cryptography.

If you're using only TLS you leak some plaintext that you wouldn't with IPsec (e.g., port numbers).

If you're using only IPsec then you're not scaling to Internet scale.

> I skimmed the RFC, and it mentions applications that "rely on IPsec for session protection". So is it targeted more towards protecting HTTP traffic and other insecure protocols that are still in use today?

That was an allusion to iSCSI, which requires IPsec and uses only IPsec for transport security.

HTTP could use it too, but the chances of getting IPsec deployed at Internet scale (with BTNS or WebPKI or whatever) are roughly zero. iSCSI, on the other hand, could really use this. NFSv4 too.

Now, to use BTNS and connection latching in iSCSI or NFSv4 you'd need to use channel binding, but now we're getting a bit off-topic.

>Another part of the problem is that IPsec protects IP, not TCP and friends. This means that part of a TCP connection's packet flows may be protected by SAs with one peer, and later by SAs with... a different peer -- this may sound strange

Let me stop you there. The only reason it sounds strange is because you are building a presumption that IPSEC has a primary role in protecting second hop TCP traffic. We have TLS and certificates for a reason, and when employed properly (verify certs, TOFU, GSM suite, TLS 1.2...) the problems you go to mention are mitigated.

If you use IPSEC for what it is made for, it is neither hard to understand nor difficult to implement.

It's "IPsec", not "IPSEC", FYI. (Some people really care about this, and will stop listening to you if you don't get this right.)

I don't agree with you. You'd have to review a lot of history to make that sort of assertion about the purpose of IPsec, and you'd have to ignore transport mode. Transport mode clearly exists to protect end-to-end... In transport mode the purpose of IPsec really is to protect all upper level protocol packet flows covered by local IPsec policy.

Also, since both, transport-mode IPsec and TLS are end-to-end, using both would be a serious waste of resources -- in practice few ever use transport mode, because any non-VPN, non-BITS/BITW uses of IPsec are just ETOOHARD to deploy and scale.

Of course, encrypting multiple times at different layers, but only once end-to-end, is not wasteful.