Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 04 May 2009 14:44:40 -0700

Hi Pasi,

Thanks for the detailed review (again).

On 4/28/09 1:10 AM, "[email-masked]" wrote:

> 1) The new versions since the previous WGLC introduced a number of
> additional steps (e.g. nonce payload, clarifying PAD etc.) to the
> redirection process, but currently these are spread over the whole
> document, or in some cases, partly missing (e.g. the document never
> says what the client should do with the nonce data in the REDIRECT
> notification). IMHO these should be included in the overall flow in
> Section 3. Proposed text:

You are right. I guess I kept adding small amounts of text over multiple
versions. Your rewrite of section 3 is fine with me. I made one change.

> 3.  IKEv2 Initial Exchange with Redirect
> 
>    This section describes the use of Redirect mechanism during the
>    IKE_SA_INIT exchange.  Gateway-initiated redirect and the use of
>    redirect during IKE_AUTH exchange are explained in subsequent
>    sections.
> 
>    The VPN client indicates support for the IKEv2 redirect mechanism
>    and the willingness to be redirected by including a
>    REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT
>    request.  If the IKE_SA_INIT request did not include the
>    REDIRECT_SUPPORTED notification, the responder MUST NOT use the
>    redirect mechanism specified in this document.
> 
>    To redirect the IKEv2 session to another VPN gateway, the VPN
>    gateway that initially received the IKE_SA_INIT request selects
>    another VPN gateway (how the selection is made is beyond the scope
>    of this document), and replies with an IKE_SA_INIT response
>    containing a REDIRECT notification message. The notification
>    includes the address of the selected VPN gateway,

Changed this to "... information about the selected VPN gateway", since you
can send the FQDN of the new gateway instead of the IP address. But the
original text already had this bug.

> 2) As I already noted in my March 2 email, the document does not say
> exactly what information outside IPsec (i.e. Mobile IPv6) is being
> updated by the redirect, and the security implications if it.
> 
> Perhaps something like this, added to the end of Section 3:
> 
>    When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home
>    Agent (HA), redirecting the IKEv2 exchange to another HA is not
>    enough; the Mobile IPv6 signalling also needs to be sent to the new
>    HA address. The MN MAY treat the information received in the
>    IKE_SA_INIT response in similar way as it would treat HA discovery
>    information received from other unauthenticated (and potentially
>    untrustworthy) sources (such as DNS lookups not protected with
>    DNSSEC). However, if the MN has authenticated information about its
>    Home Agent, it MUST NOT be updated based on the IKE_SA_INIT
>    response.
> 
>    If the REDIRECT notification is received during the IKE_AUTH
>    exchange (after the HA has been authenticated; see Section 6), the
>    MN MAY pass the new address to Mobile IPv6 and treat it in similar
>    fashion as information from the Home Agent Switch Message
>    [RFC5142].
> 
>    Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL
>    exchanges (see Section 5) MUST NOT result in updating any Mobile
>    IPv6 state. In such cases, the Home Agent Switch Message specified
>    in [RFC5142] are used instead.
> 
> (I haven't fully thought through all the details, so comments are
> welcome...)

I like the above text. Couldn't think of anything else that might have been
missed.

> And the security considerations text needs something, too.

I added the following text...

   The redirect mechanism MUST NOT update any state on the client apart
   from the VPN gateway information.  When used with Mobile IPv6, care
   must be taken to ensure that the home agent information that the
   mobile node has configured is not modified wrongly by the redirect
   message.

> 3) Section 6, 1st paragraph: I think this text needs to be clearer
> about whether an IKE_SA is created or not (current the SHOULDs
> etc. make this somewhat unclear). IMHO if the client will always just
> close the IKE_SA, it doesn't make much sense to create it in the first
> place? But it looks like the intent of the current text might have
> been that the IKE_SA *is* created... If that's the case, then the
> message diagram below this paragraph should also show the
> INFORMATIONAL exchange with Delete payload.

The current text assumes that the IKE SA is created and needs to be deleted.
I don't think we need to show the INFORMATIONAL exchange. We are not
modifying anything in the delete procedure. We currently have the following
text

   When the client
   receives the IKE_AUTH response with the REDIRECT payload, it SHOULD
   delete the existing IKEv2 security association with the gateway.

Isn't this sufficient?

> 4) Section 6, last paragraph:
> 
>> In such cases, the gateway should send the REDIRECT notification
>> payload in the final IKE_AUTH response message that carries the AUTH
>> payload and the traffic selectors.  The gateway MUST NOT send and
>> the client MUST NOT accept a redirect in an earlier IKE_AUTH
>> message.
> 
> This is a bit confusing, since the first sentence says "should", and
> in this particular case, the final IKE_AUTH response does not
> actually have the traffic selectors! Also, if the intent was to allow
> redirect in the 1st IKE_AUTH response, this text doesn't do it.
> Perhaps something like this?
> 
>    In such cases, the gateway can include the REDIRECT notification
>    either in the first IKE_AUTH response, or the last IKE_AUTH
>    response. The gateway MUST NOT send, and the client MUST NOT
>    accept, the REDIRECT notification in any other IKE_AUTH response.

The gateway can always include the REDRIECT notification in the first
IKE_AUTH response. The text that you quoted follows the text that says the
redirect decision may be done based on the interaction with the AAA server
or an external authentication server. But Yoav also had a comment on the
same paragraph. This means it is not clear. So I am fine with adopting your
text above.

> 5) Section 9, last paragraph, is a bit confusing (even if the redirect
> message was always authenticated, we still wouldn't want to modify the
> PAD based on it), and in the wrong place (it's important part of the
> protocol, not just a security consideration). The proposed text for
> Section 3 included the essential parts, I think.

Ok, removed the last paragraph in section 9.

Vijay

> 
> Best regards,
> Pasi
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of ext Yaron Sheffer
>> Sent: 16 April, 2009 10:38
>> To: IPsecme WG
>> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
>> 
>> This is a 2 week working group last call for
>> draft-ietf-ipsecme-ikev2-redirect-08. The target status for this
>> document is
>> Proposed Standard. This is the document's second last call, following
>> comments by a number of people and several document revisions.
>> 
>> Please send your comments to the ipsec list by April 30, 2009, as
>> follow-ups
>> to this message.
>> 
>> Please clearly indicate the position of any issue in the Internet
>> Draft, and
>> if possible provide alternative text. Please also indicate the nature
>> or
>> severity of the error or correction, e.g. major technical, minor
>> technical,
>> nit, so that we can quickly judge the extent of problems with the
>> document.
>> 
>> The document can be accessed here:
>> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08.
>> 
>> Thanks,
>> Yaron
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 5 May 2009 08:26:21 +0300

>    delete the existing IKEv2 security association with the gateway.
No, it's not sufficient. Unfortunately the word "delete" is ambiguous, and
people can understand it either as "silently delete" or "delete and inform
the peer". So I'd rather have "it SHOULD delete ... using an Informational
exchange."

Thanks,
	Yaron

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 5 May 2009 01:59:33 -0400

Hi Yaron, 

> > modifying anything in the delete procedure. We currently have the 
> > following text
> > 
> >    When the client
> No, it's not sufficient. Unfortunately the word "delete" is 
> ambiguous, and people can understand it either as "silently 
> delete" or "delete and inform the peer". So I'd rather have 
> "it SHOULD delete ... using an Informational exchange."

The previous section already says this.

   Once the client sends an acknowledgement to the gateway, it SHOULD
   delete the existing security associations with the old gateway by
   sending an Informational message with a DELETE payload.  The gateway
   MAY also decide to delete the security associations without any
   signaling from the client, again by sending an Informational message
   with a DELETE payload. 

I guess you want this text repeated in section 6 too (?)

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 5 May 2009 09:56:06 +0300

Hi Vijay,

"It SHOULD delete ... using the same procedure as Sec. 6"?

Clarity of prose at the expense of the beauty :-(

Thanks,
	Yaron

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 9:00
> To: Yaron Sheffer; [email-masked]; [email-masked]
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
> 
> Hi Yaron,
> 
> Scanned by Check Point Total Security Gateway.