Hi Alper, It seems that your argument goes to 3GPP only not this new work item, then I would suggest that you propose your solution to 3GPP HNB.
Back to your questions, the scenarios is that some user need this IKE/IPsec or other don't need IPsec for the first, and also could be upgraded to need IKE/IPsec, I also found you didn't classify different access authenticaiton protocol. this is not a granularity issue, how could your proposal to support this scenario and migration scenarios simultaneously? thanks -Hui 2009/12/10 Alper Yegin <alper.ye...@yegin.org>: > Hi Hui, > >> I am not convinced why vendor need implement two security mechanism to >> one product, >> just because the second one need some market to use it. > > Unfortunately, protocol classification is more granular than that. > You don't identify one protocol as "security protocol" and make it serve all > security related purposes: access authentication, IPsec SA establishment, > transport-layer security, application-layer security, mobility signaling > security, etc. etc. Obviously, you need several distinct protocols for these > things. > > So, saying we have IKEv2, and we'll twist and turn it into some other > protocol for some other purpose may make sense when you are looking at > things from within the box (that implements IKEv2), but it does not make > sense when you are looking from outside the box (like from IETF > perspective). > > Your proposal is for turning IKEv2 into an EAP transport for generic network > access authentication. It requires taking some stuff out, twisting some > stuff, and adding stuff. It's technically doable, but "IETF" needs to be > convinced why it needs to reinvent PANA by taking IKEv2 as the baseline. > > Alper > > > > > > > > > > > > > > > > > > > > > > >> >> -Hui >> >> 2009/12/10 Alper Yegin <alper.ye...@yegin.org>: >> > Hi Hui, >> > >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is not >> behind >> > all of the requirements, but you didn't respond to my question about >> which >> > one of the requirements are coming from 3GPP. >> > >> > >> > I object to this work, because it intends to create yet another >> network >> > access authentication protocol out of IKEv2. As you know, PANA is >> designed >> > for that purpose. IETF community needs to understand why PANA does >> not fit >> > the need, and why we need to turn IKEv2 into a general-purpose >> network >> > access authentication protocol. (IKE needs to get in line with the >> other >> > similar proposals, such as hacking up DHCP into access authentication >> > protocol, and even HTTP. I guess everyone has his/her favorite >> protocol to >> > hack.) >> > >> > Similar questions arise for the other motivations. "Liveness >> checking", and >> > "NAT detection".... Turning IKEv2 into a dedicated protocol for these >> > purposes is likely to grow IKE in many unintended directions. >> > >> > Alper >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On >> Behalf >> >> Of Hui Deng >> >> Sent: Wednesday, December 09, 2009 5:42 PM >> >> To: Yaron Sheffer >> >> Cc: ipsec@ietf.org >> >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> >> >> would like to co-author, thanks >> >> >> >> -Hui >> >> >> >> 2009/11/30 Yaron Sheffer <yar...@checkpoint.com>: >> >> > This draft proposes an IKEv2 extension to allow the setup of an >> IKE >> >> SA with no Child SA, a situation which is currently disallowed by >> the >> >> protocol. >> >> > >> >> > Proposed starting point: http://tools.ietf.org/id/draft-nir- >> ipsecme- >> >> childless-01.txt. >> >> > >> >> > Please reply to the list: >> >> > >> >> > - If this proposal is accepted as a WG work item, are you >> committing >> >> to review multiple versions of the draft? >> >> > - Are you willing to contribute text to the draft? >> >> > - Would you like to co-author it? >> >> > >> >> > Please also reply to the list if: >> >> > >> >> > - You believe this is NOT a reasonable activity for the WG to >> spend >> >> time on. >> >> > >> >> > If this is the case, please explain your position. Do not explore >> the >> >> fine technical details (which will change anyway, once the WG gets >> hold >> >> of the draft); instead explain why this is uninteresting for the WG >> or >> >> for the industry at large. Also, please mark the title clearly (e.g. >> >> "DES40-export in IPsec - NO!"). >> >> > _______________________________________________ >> >> > 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 >> > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
