Hi Dan I have no opinion about the level of review needed for changes to IKEv1, and I share your unhappiness with the way PAKE turned out.
If I had to guess the reasons for the slow adoption of IKEv2, I would guess that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and poor PSK support for mobile peers) just works. The big vendors have at least server-side support, and Microsoft has a client in Win7. I think EAP is a hindrance, because XAuth works better with older backend servers. Your proposal will be more secure than XAuth and require less round trips, but won't integrate with AAA servers. I think anyone who is going to go to the effort of implementing this (replace or update all IKEv1 endpoints) might as well move them to IKEv2. The big hurdle to implementing what you suggest for remote access is that XAuth works. What doesn't work is a gateway with a dynamic external IP address that doesn't have a certificate. But I don't see how upgrading the gateways to support your extension is easier than upgrading them to support IKEv2. Yoav On Mar 28, 2012, at 9:49 AM, Dan Harkins wrote: > > Hi, > > Let me answer David here in a response to Yaron.... > > To be equally blunt, it is because this PAKE work became extremely > political and I was, and still am, very unhappy with the way it turned > out. Repeating it, this time with an obsoleted protocol, would cause > (more) people to question my sanity-- i.e. doing the same thing and > expecting a different result. > > I'd like to just get a stable reference for this minor change that > has the potential to do good. I don't want to fight over it anymore. > > regards, > > Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
