what if the request is during the IKE authenticaiton, network side need to signal the fermto about whether to support IPsec or not? if not, will fall back to usual IPsec tunnel.
-Hui 2009/12/18 Alper Yegin <alper.ye...@yegin.org>: > Hi, > > I'm hoping by now it is understood that "childless IKE SA" is just a > technical detail of what is really on the table. The proposal on the table > is "designing a network access authentication protocol based on IKEv2". > That's what this WG and IETF should be discussing. > > Having multiple solutions for the very same problem space creates > interoperability problem. If IETF has defined a protocol for a given > problem, and if some other people come along and ask another solution be > standardized for the very same problem, IETF needs a justification. > Otherwise, we end up working "against" interoperability, not "for". > > The only justification I'm hearing is "we don't want to use PANA because it > is not implemented in my stack." This is an extremely poor justification. > One can say it for any new protocol, and choose to hack up whatever he/she > has. How can growing PANA out of IKEv2 be any better than using PANA. > > IKEv2 is defined and used for creating IPsec SAs. Yeah, it needs to perform > peer authentication, but that's for creating securing the IPsec SA creation. > There are many other protocols that authenticate the peers for the sake of > securely performing their own dedicated objectives. E.g., Mobile IP > authenticates MN and HA for securely creating binding caches; RFC 3118 > authenticates DHCP client and DHCP server for secure host configuration; > etc. etc. Taking the peer authentication parts of these protocols and use it > for totally different purposes is not right. > >> I don't see why we couldn't let IKEv2 have a go at displacing PANA in the > marketplace. > > Few folks want to twist IKEv2 into network access authentication protocol > (this proposal). > Few other folks want to twist DHCP into network access authentication > protocol (EAP-over-DHCP proposal). > Few other folks want to twist HTTP into network access authentication > protocol (EAP-over-HTTP proposal). > > They all have the exact same (poor) justification: We need EAP-over-Foo > because we already have Foo. > > The above list is what is already being entertained here and there. The list > is very likely to grow. > > How can that not be a problem if all were getting standardized (for the sake > of argument, let's forget about the technical brokenness of the last two > proposals). Every one of them think they were saving by implementing "one", > but in fact all are getting implemented eventually. Each access > authentication specific feature needs to be reproduced on each such > protocol. A multi-mode terminal (host) and NAS need to implement all..... > > >> 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. > > "We" (IETF) do not and cannot make PANA "required to implement" network > access authentication protocol. Other SDOs/platforms make such mandates. So, > I don't think saying "no" to redundant solutions is a bad thing that that > way. > > If someone is truly hung up on using IKEv2 purely for network access > authentication, why can't they already do so? So what if it creates an IPsec > SA. Just don't use it. > >> 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. > > Is this a real scenario? This is not the scenario Hui brought up. He's > talking about Femto AP connecting to femto access network via WAN; in one > case (a) WAN is already secured (e.g., via physical security) and he does > not need to use IPsec at all; in the other case (b) WAN is open Internet and > ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP > and he wants to use IKEv2 for that. And I say use PANA instead. > > So, PANA-based solution becomes this: > For case (a): Use PANA for Femto AP authentication. That's all you need. > For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting up > IPsec SA. > > > > .... > > I'm not disputing doability of this proposal. See, an even worse example is > 3GPP2 using Mobile IPv4 authentication for L3 network access authentication > between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't > come to IETF for tweaking RFC 4004 for that (they could get good number of > support, if we were going with that indication only). This can also made to > work, but IMHO there is much bigger harm than benefit in this case. > > Alper > > > > > > > > > > > > > > > > > > >> -----Original Message----- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Nicolas Williams >> Sent: Tuesday, December 15, 2009 8:38 PM >> To: Alper Yegin >> Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir' >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> 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 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
