Hi Alper, 2009/12/12 Alper Yegin <alper.ye...@yegin.org>: > Hi Hui, > >> 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. > > We are having this discussion in IETF right now. So, there is no point in > telling us to go elsewhere. If the discussions is here, it is here.
> >> 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, > > Is this a real scenario? I'd like to understand how a user moves from a > non-IPsec to IPsec. It is not handover case, it is just physical link sometime is securied enough sometime it is, and some user support this, other are not support this. > > >> I also found you didn't classify different access authenticaiton >> protocol. > > Could you please elaborate on what exactly you are asking about? I mean normally we won't do two different type authentication mechanism for the same device. > > >> this is not a granularity issue, how could your proposal to support >> this scenario and migration scenarios simultaneously? > > If you can explain to us what migration scenarios you have, we can discuss > them. Secenario above. thanks -Hui > > Thanks. > > Alper > > > > > >> >> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
