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.


> I also found you didn't classify different access authenticaiton
> protocol.

Could you please elaborate on what exactly you are asking about? 


> 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.

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

Reply via email to