On 24/3/21 8:05 PM, Michael Thomas wrote:
On 3/24/21 4:57 PM, Joseph Touch wrote:
On Mar 24, 2021, at 4:10 PM, Michael Thomas <mike@xxxxxxxx> wrote:
On 3/24/21 3:23 PM, Keith Moore wrote:
On 3/24/21 5:36 PM, Michael Thomas wrote:
IPsec certainly suffered this fate, though with filtering I'm not
sure if it would have the right security properties for tunnel
mode. Certainly had we used transport mode IPsec instead of SSL we
wouldn't be coming back 25 years later worried about the TCP
checksum.
IMO IPsec was DOA because it didn't actually consider the needs of
applications.
Well there's no actual reason why IPsec needs to be run in the
kernel except for maybe some issues with IP protocol numbers (can't
remember if they could be exposed up at that time).
Beyond that IPsec in transport mode doesn't seem to be much
different than TLS other than covering the transport headers too.
Turns out that can be important for things like BGP (that’s why we
had TCP-MD5 and now TCP-AO).
IMO, what IPsec got wrong was tunnel mode; it should have just been
transport mode and IP-IP tunneling (RFC 3884 explains why).
Ah, interesting point. On the other hand for most VPN applications
I've often wondered why they need to advertise/configure specific
tunnel endpoints. Why can't you just follow normal routing to the
destination and send back an ICMP to say they need to be
authenticated/encrypted if need be. It seems it would solve a lot of
weird problems that tunnels cause.
Sounds to me as a terrific idea.
Mike
