On Mar 24, 2021, at 5:05 PM, Michael Thomas < mike@xxxxxxxx> 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.
See the recent discussions on int-area.
ICMPs are largely blocked.
Joe |
