ipsec May 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect

Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08

From: Vijay Devarapalli <vijay_at_nospam>
Date: Mon May 04 2009 - 22:32:47 GMT
To: Tero Kivinen <kivinen@iki.fi>, IPsecme WG <ipsec@ietf.org>


Hi Tero,

Thanks for the detailed review.

On 4/28/09 7:35 AM, "Tero Kivinen" wrote:

> Section 3 says:
>
> The gateway MUST include the nonce data from the Ni payload sent by
> the initiator in the REDIRECT payload. This prevents certain Denial-
>
> but the figures showing how redirect is done does not include Ni data
> in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is
> bit misleading to use IP_R in the payload, perhaps New_GW_ID would be
> better. I.e. it would be better to write the reply as:
>
> (Initial_IP_R:500 -> IP_I:500)
> <-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
>
> Similar change is also needed in later sections too.
>
> ---
>
> In section 5 it should be:
>
> <-- HDR, SK {N(REDIRECT, New_GW_ID,)}
>
> (also changed the N[] to N() as is used normally).
>
> ---
>
> In section 6 it should be:
>
> (IP_R:500 -> IP_I:500)
> <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
> N(REDIRECT, New_GW_ID,)}

Fixed all of the above.  

> (Again changed the N[] to N()). This section does not say whether the
> Ni is included in the response, but I assume it is omitted as there is
> no need for it. This section should make it clear whether it is
> included or omitted.

It is included only in the IKE_SA_INIT response. Section 7.2 says

   The 'Nonce Data' field
   is present in the REDIRECT payload only when the REDIRECT payload is    sent in the IKE_SA_INIT response message. It MUST NOT be included in    the REDIRECT payload if sent in an IKE_AUTH response or in a gatewayinitiated     redirect message.

I hope this is sufficient.

> In section 6 the text:
>
> 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.
>
> is bit confusing. First it says the gateway (lowercase) should send
> REDIRECT in final IKE_AUTH response that carries the AUTH payload and
> traffic selectors. Then it says that gateway MUST NOT send redirect in
> earlier messages.
>
> Firstly the final IKE_AUTH response willnot include the traffic
> selectors, as they are omitted if client is redirected. Thus it is
> misleading to say "that carries the AUTH payload and traffic
> selectors".

Please see my response to Pasi's email. This text has been updated. Redirect during the first IKE_AUTH response is always allowed even when EAP or multiple authentication is used.  

> Secondly, it is not clear whether the "In such cases" only refers to
> the cases wher gateway decides to do something (interact with AAA
> server/ use external authentication server), or in all cases where EAP
> or multiple authentication is used. If it is in all cases where EAP or
> multiple authentication is used, then that means gateway cannot
> redirect in first IKE_AUTH (which is fine for me, but I am not sure if
> that was meant). If it is only when gateway needs AAA/external
> authentication server, then how can client enforce the "MUST NOT
> accept redirect in an earlier IKE_AUTH message", if it does not know
> whether gateway needs to consult external authentication server or AAA
> server...
>
> In general the text is so confusing that I am not sure what is meant.
> One easy way to solve this problem is to say things clearly, i.e.
> either add one of the following texts:
>
> If multiple IKE_AUTH exchanges are used the REDIRECT notification
> payload MUST be in the IKE_AUTH response from gateway to the client,
> which also includes the gateways AUTH payload. With EAP, there is
> two possible places (first IKE_AUTH and last IKE_AUTH). With
> multiple authentication support there are AUTH payload after each
> authentication finished, thus server can redirect after each
> authentication step is finished. REDIRECT notification MUST NOT be
> sent or accepted in any other messages than those having AUTH
> payload.
>
> or
>
> If multiple IKE_AUTH exchanges are used the REDIRECT notification
> payload MUST be in the final IKE_AUTH response from the gateway to
> the client, i.e the one that contains the AUTH payload, and that
> would also contain the Child SA SA payload and traffic selectors,
> if connection would not have redirected. REDIRECT notification MUST
> NOT be sent or accepted in any of the earlier IKE_AUTH messages.

If the gateway decides to redirect after the first authentication, it would be the same as the exchange in section 6. The second authentication would not even happen. If the redirect is as a result of interaction with an external authentication server, then the redirect happens in the final IKE_AUTH message.

> In section 7.2 the first paragraph says that "The message includes the
> new responder's IP address.", but this payload can also include FQDN,
> I think it should be changed to "The message includes the
> new responder's IP address or DNS name.".

Fixed.

> In section 7.2. the GW Identity Type should be made to be IANA
> allocated registry. We have already had all kind of problems when we
> have such registries which are not clearly defined, and then someone
> wanted to add entries to there.

Creating an IANA registry is fine with me. I will add text in the IANA considerations section.

> It would also be good to explicitly say that IPv4 address are encoded
> as 4 octects, and IPv6 addresses are encoded as 16 octets, and that
> the FQDN of the new VPN gateway is encoded as dns name without any
> terminators (e.g., NUL, CR, etc). Perhaps it would be good to
> cut & paste the similar parts from the section 3.5 of the rfc4306.

I added the following text.

  The IPv4 address, the IPv6
  address or the FQDN of the new VPN gateway MUST be encoded as   described in section 3.5 of [RFC4306].

> ---
>
> In section 7.3 it is not clear whether this registry used for GW Ident
> Type is same as in section 7.2 or not. As it does not have same
> values, I assume it is supposed to be separate registry. In that case
> it would be better to use some different name for it, so there is no
> confusion which registry is used (for eaxmple "Original GW Ident
> Type").
>
> As a separate registry it also need to be set up to be IANA registry.

I think we should use the same IANA registry for both.  

> ---
>
> The example in section 9 about the wildcard is not good, as it is not
> mandatory to support such wildcard format. The section 4.4.3.1 or
> RFC4301 uses partial DNS names, thus it requires that omitted parts
> are separate dns labels (text from RFC4301):
>
> o DNS name (specific or partial)
> o Distinguished Name (complete or sub-tree constrained)
> o RFC 822 email address (complete or partially qualified)
> o IPv4 address (range)
> o IPv6 address (range)
> o Key ID (exact match only)
>
> The first three name types can accommodate sub-tree matching as well
> as exact matches. A DNS name may be fully qualified and thus match
> exactly one name, e.g., foo.example.com. Alternatively, the name may
> encompass a group of peers by being partially specified, e.g., the
> string ".example.com" could be used to match any DNS name ending in
> these two domain name components.
>
> This means that the text should not use "GW*.example.com" as an
> example, but use ".sgw.example.com" instead, as that conforms to
> mimimal requirements of the RFC4301.

Good point. In addition, RFC 4301 says

   Alternatively, the name may
   encompass a group of peers by being partially specified, e.g., the    string ".example.com" could be used to match any DNS name ending in    these two domain name components.

So we might not have to give an example at all. Here is the new text

   In particular, the client MUST use the same Peer Authorization    Database (PAD) and Security Policy Database (SPD) entries as it would    have used with the original gateway. Receiving a redirect    notification MUST NOT result in the modification of any PAD or SPD    entries. In practice, this means the new gateway either has to    either use the same responder identity (IDr) as the original gateway,    or both should be part of a group of responders that are authorized    by the same PAD entry. See section 4.4.3.1 of [8] on using DNS names    to represent a group of peers in a PAD entry.  

> Section 10 also needs to create those two "GW Ident Type" and
> "Original GW Ident Type" registries, and specify what allocation rules
> are required for them. I.e reserver numbers 4/3 - 240 to IANA,
> allocate numbers 241-255 to private use, and add text saying that
> "Changes and additions to any of those registries are by expert
> review.".

I added the following text to the IANA section.

   This document creates a new namespace called the "Gateway Identity    Type". This is used to indicate the type of information regarding    the VPN gateway that is carried in the REDIRECT Section 7.2 and    REDIRECTED_FROM Section 7.3 Notification payloads. The following    values are assigned. 1 - IPv4 address of the new VPN gateway 2 - IPv6 address of the new VPN gateway 3 - FQDN of the new VPN gateway

   Values '0', and 4-255 are reserved. New values can be allocated by    expert review.

Vijay



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec