3 ms·
>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 wit
by haloux 8y ago
>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.
- cryptonector 8y agoIt'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.