On Thu, Mar 25, 2021 at 02:05:39PM -0700, Joseph Touch wrote: > >> IMO, what IPsec got wrong was tunnel mode; it should have just been > >> transport mode and IP-IP tunneling (RFC 3884 explains why). > > > > But IPsec also got transport mode wrong because what it really got wrong > > was authentication and authorization. > ... > > A better approach would have been to have had connection latching (RFC > > 5660) and IPsec-specific socket options so that IPsec would do no > > authorization in transport mode. > ... > > But I'm the author of RFC 5660, so call me biased. The above opinion > > has been a minority view since the inception of the now-concluded BTNS > > WG. > > And given I created BTNS, you’ll get no argument from me ;-) :) > But that seems like more of an argument against IKE than IPsec. I don't see anything wrong with IKEv2. The problem isn't the KE, the problem, and neither is ESP. The problem is the architecture, and the parts of it relating to authorization that get implemented by the KE (or related service). In RFC 5660 I described two ways to do the binding of IKE authentication and ESP+ULP flows using SAs instantiated by the KE. One of those completely eliminates or sidesteps a lot of RFC 4301, while the other one works within the RFC 4301 framework by editing configuration on the fly and automatically to obtain the same result. A system that only uses IPsec in the RFC 5660 way basically wouldn't even need to expose anything like the PAD, or even the SPD. Nico --
