Hello Hui, If the same box needs to be plugged into networks with different security characteristics, sure you need a stack that can handle all cases. Not sure how this relates to our discussion about hacking up IKEv2 vs using a proper protocol.
> I mean normally we won't do two different type authentication > mechanism for the same device. There are different authentication procedures authenticating different entities for different purposes -- all on the same node. You cannot say I have one authentication for all purposes.... Use IKEv2 to "authenticate" IKE peers for establishing IPsec SA, use EAP/foo to "authenticate" subscriber and the access network for network access AAA, use Mobile IP to "authenticate" MN and HA for mobility binding, etc. etc.... The minute you intend to use one as a substitute of another (or all), you are entering the hacking domain.... Alper > -----Original Message----- > From: Hui Deng [mailto:denghu...@gmail.com] > Sent: Monday, December 14, 2009 5:35 PM > To: Alper Yegin > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > 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
