Hi Vijay, See comments to your comments below.
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email protected]]
> Sent: Monday, April 13, 2009 22:27
> To: Yaron Sheffer; IPsecme WG
> Subject: Re: [IPsec] Redirect -07 comments
>
> 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".
>
[YS] Sec. 1 is sort of conversational. A list would make it clear that ONLY
these 3 options are allowed.
> > - 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?
>
[YS] I think it's a useful clarification. But I can live without it.
> > - 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.
>
[YS] Much better. Thanks.
> > - 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
>
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
