<not wearing any hats>
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:
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, and the nonce
data from the Ni payload in the IKE_SA_INIT request.
Note that when the IKE_SA_INIT response includes the REDIRECT
notification, the exchange does not result in the creation of an
IKE_SA, and the responder SPI will be zero.
Initiator Responder (initial VPN GW)
--------- -------------------------
(IP_I:500 -> Initial_IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECT_SUPPORTED)
(Initial_IP_R:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, IP_R, nonce data)
When the client receives the IKE_SA_INIT response, it MUST verify
that the nonce data matches the value sent in the IKE_SA_INIT
request. If the values do not match, the client MUST silently
discard the response (and keep waiting for another response). This
prevents certain Denial-of-Service attacks on the initiator that
could be caused by an attacker injecting IKE_SA_INIT responses with
REDIRECT payloads.
Next, the client initiates a new IKE_SA_INIT exchange to the
address included in the REDIRECT payload. The VPN client includes
the IP address of the original VPN gateway that redirected the
client in the REDIRECTED_FROM notification. The IKEv2 exchange then
proceeds as it would have proceeded with the original VPN gateway.
Initiator Responder (Selected VPN GW)
--------- ---------------------------
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_FROM, Initial_IP_R)
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
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 practise, this means the new gateway either has to
either use the same responder identity (IDr) as the original
gateway, or the PAD entry must use wildcards (such as
gw*.example.com) that match multiple responder identities.
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...)
And the security considerations text needs something, too.
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.
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.
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.
Best regards,
Pasi
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
