Hi Yaron, Thanks for the detailed review. Just responding to those that need more discussion or where I have comments.
On 4/11/09 1:02 AM, "Yaron Sheffer" wrote: > - 3: I suggest to start this section with an exhaustive list of locations > where the Redirect payload can occur (IKA_SA_INIT response, IKE_AUTH last > response, Informational from gateway). Section 1 already talks about all three. I think a better option would be re-name section 3 as "IKEv2 Initial Exchange with Redirect". The sections that come later are already called "Gateway Initiated Redirect" and "Redirect During IKE_AUTH Exchange". > - 3: "The VPN client indicates support for the IKEv2 redirect mechanism by > including..." -> By including ..., the VPN client indicates that it supports > the IKEv2 redirect mechanism and that it is willing to be redirected. Hmm... The client can always exclude the REDIRECT_SUPPORTED payload based on its configuration if it does not want to be redirected. So do we need to mention this? > - 3: The last paragraph (re: MIP6) is out of context here, and I was unable > to understand it. I suggest to clarify and extend it into a separate > section. When redirect is used with Mobile IPv6, there is a separate Home Agent discovery mechanism. So the Mobile IPv6 stack would have a home agent configured. If the IKEv2 redirect mechanism changes the gateway information, then the state becomes inconsistent. The original intent was talk about that. I replaced the paragraph with the following. When this mechanism is used with Mobile IPv6, care must be taken to ensure that the home agent information is consistent with the IKEv2 gateway information. The Mobile IPv6 home agent discovery mechanisms (for instance, RFC 5026 [4]) would have a configured the mobile node with a particular home agent. When the mobile node initiates an IKEv2 exchange with the home agent and is redirected to another gateway, the home agent information should also be updated, subject to the policy on the mobile node. > - 6.2: Now that we've appended the nonce, we should signal the length of the > Identity field explicitly (possibly by stealing 1 octet from the Identity > Type). Even though the client can theoretically compute it using the length > of the expected nonce. Good point. I added a 'GW Identity Length' field to both REDIRECT and REDIRECTED_FROM payloads. I added the field to the REDIRECTED_FROM payload also for consistency. Vijay _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
