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
