On 3/24/21 5:06 PM, Joseph Touch wrote:
On Mar 24, 2021, at 5:05 PM, Michael Thomas <mike@xxxxxxxx> wrote:
On 3/24/21 4:57 PM, Joseph Touch wrote:
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.
On Mar 24, 2021, at 4:10 PM, Michael Thomas <mike@xxxxxxxx> wrote:Turns out that can be important for things like BGP (that’s why we had TCP-MD5 and now TCP-AO).
On 3/24/21 3:23 PM, Keith Moore wrote:
On 3/24/21 5:36 PM, Michael Thomas wrote: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).
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.
Beyond that IPsec in transport mode doesn't seem to be much different than TLS other than covering the transport headers too.
IMO, what IPsec got wrong was tunnel mode; it should have just been transport mode and IP-IP tunneling (RFC 3884 explains why).
See the recent discussions on int-area.
ICMPs are largely blocked.
I haven't really noticed that. But it isn't necessary to have it conveyed by ICMP. Heck, with current VPN's there's no concept of discovery at all so plain old static configuration is obviously possible.
Mike
