Hi 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
