Hello,
In the interest of stimulating a positive IPSec WG debate on the next version of IKE, I would like to offer a few key observations that my colleagues and I have found in a review of the IKEv2 proposal (February 2002; Harkin, Kaufman, Perlman, et al).
A first observation in evaluating the merits of any proposal is the state of or possibility of implementation given what we read. This aspect was the intellectual or common sense criteria we looked for first. Of the 3 proposals discussed at the last meeting (Salt Lake City), only the IKEv2 proposal had enough detail, in our opinion, for organizations to implement the protocol (not just the key exchange) as written. Perhaps by now, March 5, 2002, the other proposals too have been substantially detailed so that the same thing may be said of their work. Thanks to Mr. Paul Hoffman, Director-VPN Consortium, for providing a useful link where this material may be found.
A second observation or concern was a proposal's ability to be compatible with deployed devices using IKEv1. Investment costs would indeed be heavy if all v1-enabled devices could no longer play in the next version of the IKE world. The IKEv2 proposal as written offers a methodology whereby an IKEv2/IKEv1 device (or node) can interact with an IKEv1 only device by detecting that single version characteristic and communicate only in v1. This attribute preserves the usability of v1 devices and the end user's huge equipment investment.
Some other observations that we found and wish to share with the membership are listed below. They are not ranked in any particular order of importance.
· The proposal seems a straightforward key and SA management protocol for IPsec while providing critical functionality. Some of the functionalities that my colleagues and I find important are; inexpensive and graceful rekeying, dead peer detection, support for multiple services co-located at an IP address, and negotiation of peer-dependent IPsec policies.
· IKEv2 cryptographic negotiation makes it possible to deploy a new algorithm should that become necessary. This flexibility is in contrast to a situation where a server stipulates the algorithm to use without the benefit of negotiation.
· From our analysis, we believe IKEv2 is a complete proposal and doesn't refer to any of the previous documents. (One stop shopping.) It appeared to cleanse or selectively remove the problem areas of v1 without resorting to total amputation of the old.
· We believe that it is a positive development to preserve some legacy code that is used and accepted today rather than jettison v1 completely. What works now and is preserved in v2 creates a more acceptable market climate for both vendors and end users as it lessens implementation costs (and fears).
· We also see that it provides capability to create multiple phase 2 SAs piggybacking off a single phase 1 SA. Further, the proposal offers clean and low cost rekeying as well as traffic selector negotiation.
· IKEv2 hides both identities, and doesn't give proof that the parties intentionally communicated with each other.
· Since IKEv2 is a complete proposal, it appears that the authors have thoroughly groomed the v1 protocol and removed the more objectionable bugs. We didn't find in v2 the same v1 problems with traffic selector negotiation and message Ids. Did others find this observation to be true?
The authors of JFK have, to their credit, achieved name recognition and favorable press attention in the last several months. Being fairly new to the IETF and IPSec WG in December 2001, it appeared that there was only one alternative to v1 and that was JFK. Further WG involvement and analysis suggests this is not the case and I would invite other members to comment or expand upon the pros or cons listed above. We owe it to ourselves to make an informed decision based on the usability of what we read.
Cheers,
Dennis Beard
613-768-0323