3 ms·
Nice review. Just a theoretical question: Wasn't IPsec supposed to do the encryption right in the IP layer? I wonder how this compares with the handshake roundt
by ktpsns 8y ago
Nice review. Just a theoretical question: Wasn't IPsec supposed to do the encryption right in the IP layer? I wonder how this compares with the handshake roundtrip time needed (for IPsec, for TCP).
- pas 8y agoWell, the problem is complex. For security you need integrity, authenticity and anonimity/secrecy. Crypto of course is the way we implement all that, via keys and other kind of information theoretic tokens that somehow build upon a pre-shared secret. You need an anchor, a mutual trust foundation to build your secure channel upon. If you want to put security on/into IP, you suddenly need the whole key management thing, and if you want it to be automatic, you need to somehow cobble together the assignment, provisioning, allocation, publication, revocation of keys with IP addresses (or hostnames, domain names, and you just put DNS into IP). Eventually it means either you need manual key management (thus IPsec becames a hard to manage old rusty and poorly supported concept from an old era) or you just descended into the recursive pit of all hells of circular dependencies. Sure, it can be done, we can put keys into DNS, and we can use that, but then we're back to QUIC or DTLS basically.
- rocqua 8y agoThe issue is that IP is generally handeled by the OS. This means that IPsec also needs to be handled by the OS. The thing is, how you set up (mutual) authentication is very much an application level thing. Do you want certs, an SSH key, passwords, hardware tokens, SIM based authentication, or something else? These aren't things the OS can decide, and they aren't so simple we could tell the OS what we want with a few flags.
- dcbadacd 8y agoDoesn't IPsec suffer from legacy cruft and outdated implementations?