3 ms·

> 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

• cryptonector 8y ago
  > 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.