Hello Yoav,

I'm particularly concerned about reinventing the wheel aspect with your
second bullet, as I elaborated in response to Hui in my previous email.

As for the other motivations, I'm not sure the savings are worth the effort.
Imho....

Alper 

> The "Do phase 1 first, and phase 2 as traffic demands it" motivation is
> from the remote access VPN domain (though may be useful for others).
>
> The "Do only phase 1, because we don't need encryption and MAC, just
> peer authentication" motivation is from the 3GPP (though it could be
> useful for others)
> 
> The "Do only phase 1 to discover if we're in or out of the secure
> network (then do phase 2 if we're out)" motivation is also mostly a
> remote access VPN thing.
> 
> The other motivations were from suggestions by others, and will be
> hashed out (or taken out of the document) should this become a WG
> document.
> 
> Hope this helps
> 
> Yoav
> 
> On Dec 9, 2009, at 9:46 PM, Alper Yegin wrote:
> 
> > 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


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to