Subject: [IPsec] Redirect -07 comments

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Apr 2009 11:02:40 +0300

Hi Vijay,

Here's a bunch of comments on the latest draft, some minor, some not so
minor.

Thanks,
	Yaron

- 1: During during -> during
- 1: Can be also be -> can also be
- 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).
- 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.
- 3: "It initiates a new IKE_SA_INIT exchange with the VPN gateway listed in
the REDIRECT payload", add: "provided this is allowed by its IPsec policy".
- 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.
- 5: "If the gateway decides to redirect the client during the IKE_AUTH
Exchange..." - this should start a new section.
- Same paragraph: add "The gateway MUST verify the client's AUTH payload
before sending the Redirect payload, and the client MUST verify the
gateway's AUTH payload before acting on the Redirect payload."
- "In case the IKE_AUTH exchange involves EAP authentication" - add: "The
gateway MUST NOT send and the client MUST NOT accept a redirect in any
earlier message."
- 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.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Apr 2009 12:27:25 -0700

Hi Yaron,

Thanks for the detailed review. Just responding to those that need more
discussion or where I have comments.

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

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

> to understand it. I suggest to clarify and extend it into a separate

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.

> Type). Even though the client can theoretically compute it using the length

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

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Apr 2009 00:04:19 +0300

Hi Vijay,

See comments to your comments below.

Thanks,
	Yaron

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Monday, April 13, 2009 22:27
> To: Yaron Sheffer; IPsecme WG
> Subject: Re: [IPsec] Redirect -07 comments
> 
> Hi Yaron,
> 
[YS] Sec. 1 is sort of conversational. A list would make it clear that ONLY
these 3 options are allowed.

> its configuration if it does not want to be redirected. So do we need to
[YS] I think it's a useful clarification. But I can live without it.
 
>    to the policy on the mobile node.
[YS] Much better. Thanks.

> Scanned by Check Point Total Security Gateway.