On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: > > The "Do phase 1 first, and phase 2 as traffic demands it" motivation is > > from the remote access VPN domain (though may be useful for others). > > > > The "Do only phase 1, because we don't need encryption and MAC, just > > peer authentication" motivation is from the 3GPP (though it could be > > useful for others) > > > > The "Do only phase 1 to discover if we're in or out of the secure > > network (then do phase 2 if we're out)" motivation is also mostly a > > remote access VPN thing. > > > > The other motivations were from suggestions by others, and will be > > hashed out (or taken out of the document) should this become a WG > > document. > > I'm particularly concerned about reinventing the wheel aspect with your > second bullet, as I elaborated in response to Hui in my previous email. > > As for the other motivations, I'm not sure the savings are worth the effort. > Imho....
Suppose you want a combination of "peer authentication only" for some traffic and "peer authentication + ESP/AH" for other kinds of traffic (think of this as differentiated services). Then to use PANA for one and IPsec for the other seems silly. I don't see why an applicability statement should not suffice to prevent the scenario that you dislike (which I think is: IKEv2 displacing PANA where IKEv2 should be considered to not be applicable). But see below. The issue to settle here, as I see it, is: are there any uses of childless IKEv2 SAs that justify the work? Of the various use case scenarios given in the I-D the first is the most convincing, though the lack of childless IKEv2 SAs hardly seems problematic there. The last use case is very interesting, but very forward looking. The next to last use case is specific to an EAP method, thus not very interesting to this WG (IMO) except as a way to keep divergence between base spec and the EAP method to a minimum. The other use case scenarios seem to encroach on the applicability of PANA. Just based on that my support is lukewarm. Quite aside from that, I question the applicability statement that you seem to be making. PANA and IKEv2-with-childless-SAs seem roughly equivalent, with IKEv2 being more general. Why should we forbid use of the latter for network access control? Certainly having two such protocols is not exactly desirable, but it's not clear to me that PANA is the protocol that should win. What's really not desirable is non- interoperability, and that, I believe, we can achieve by making PANA the required to implement network access protocol. I don't see why we couldn't let IKEv2 have a go at displacing PANA in the marketplace. If there is support in the WG for it, so be it. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
