Subject: [IPsec] Comments on re-direct mechanism for IKEv2

From: "fan zhao" <[email-masked]>
Date: Fri, 23 May 2008 18:02:03 -0700

Dear authors,

Thanks for writing this draft. Overall this is a very good and useful draft.
Please see some comments below.

Abstract
"...Currently there is no standard mechanism specified that allows an
overloaded VPN
gateway to re-direct the VPN client to attach to another gateway...The proposed
mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct
the mobile node to another home agent."

Fan> Load-balancing is a good motivation for this work. The current
version describes this
issue very well in the following text. IMO, there are other motivation
and scenarios that
need this redirect mechanism as well, especially those related to
Mobile IP operation.
For example, re-direct mechanism is useful to ensure a MN to use the
same HA/LMA during
handover. Assume that a MN powers up and obtains connectivity in a
PMIP domain, and
later it may handover to another access network where it needs to use
DSMIPv6. The MN
runs HA discovery and then sets up an IPSec SA with this HA. In order
to maintain
session continuity, normally the entity that acts as a HA should be the same one
that acts as a LMA before handover. This re-direct mechanism is useful
in this case because
it can reduce handover delay.

Fan> Another example is related to multi-homing. For example, a VPN
client/MN sets up
connectivity to a first network through a VPN gateway/HA. Then the VPN client/MN
wants to connect to a second network and discovers a different VPN
gateway/HA; however
the first VPN gateway/HA can be used for the VPN client/MN to access the second
network. This redirect mechanism is useful to redirect the client/MN
to the first VPN
gateway/HA so that the same IPSec SA established before can be
re-used, which reduces
states and overhead. IMO, these should be captured in various sections,
otherwise the usage of this mechanism may be unnecessarily limited to
certain scenarios.

1. Introduction
"...However, using DNS is not flexible when it comes to assigning a VPN
   gateway to the VPN client based on the load on the VPN gateways. ..."

Fan> This sentence is not wrong; however I felt it may cause confusion
because DNS can
provide some sort of load-balancing, for example the DNS server can
return the IP address
of a server selected from a pool based on the round-robin fashion. The
real issue IMO is
that the DNS is a separate infrastructure and it is practical
difficult for network operators to
update and advertise additional information to help the VPN client to
select an optimal VPN
gateway to be used via DNS. Thererfore, such selection made by the
client may not be optimal
because the client may not have as complete information as the network.

Fan> How about the following re-wording:
"...Typically, the VPN client tries to connect to the IP address of
the VPN gateways that
appears first in the DNS response. However, this cannot guarantee a
VPN gateway selected
is optimal or prefered by the network. Therefore, when the setup of
the VPN tunnel to the first VPN gateway
fails, e.g. due to this reason, then the VPN client has to try to
attach to the other VPN gateways
returned in the DNS response, which results in significant delay."

"...The re-direct is done during the IKE_SA_INIT exchange. "

Fan> IMO, the re-direct can also be done during the IKE_AUTH exchange,
during which
the client and gateway perform mutual authentication, therefore the
threats described
in section 6 can be eliminated. Furthermore, to enable load balancing,
some network
may have policy, like allocating/dedicating certain VPN gateways based
on the IDs of
VPN clients. Therefore, the re-direct decision can only be made after
the ID of VPN
client is authenticated. Please see more comments about this below.

"The re-direct mechanism can also be used in conjunction with anycast
addresses."

Fan> To make it clearer, I propose "Besides unicast addresses, the
re-direct mechanism
can also be used in conjunction with anycast addresses."

3.  IKEv2 Exchange with Redirect
"The VPN client indicates support for the IKEv2 redirect mechanism 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 payload, the responder MUST NOT send the REDIRECT
   payload to the VPN client."
This REDIRECT_SUPPORTED notification can be useful for compatibility issue.
However I am not sure it is needed.
Rfc 4306 already describes how to handle un-recongized payload, i.e.
if this is a critical payload (the C bit is set) and the payload type
is unrecognized, the

message MUST be rejected and the response MUST include a Notify payload

UNSUPPORTED_CRITICAL_PAYLOAD; or if the critical flag is not set and the
payload type is unsupported, that payload MUST be ignored.

There are at least two cases to consider:
an upgraded VPN client (i.e. a client supporting this re-direct
mechanism) connects to a legacy VPN gateway (i.e. a gateway with no
support of this
re-direct mechanism) and a legacy client connects to an upgraded GW.

In the following, I assume that if there are multiple VPN GWs in one network,
all or none of them are upgraded.

If a upgraded client sends to a legacy GW identified by a unicast address, if

REDIRECT_SUPPORTED is used and the C bit is set, the legacy GW will
reject this request
and return UNSUPPORTED_CRITICAL_PAYLOAD. And then client will have to
try again with the

same or different GW,
maybe without REDIRECT_SUPPORTED for this time. On the other hand, if
the upgraded client

does not
include REDIRECT_SUPPORTED, the setup can proceed. Since in this case
the GW cannot
provide re-direct support anyway, without indicating
REDIRECT_SUPPORTED, the signaling
procedure can be shortened.

If a upgraded client sends to a pool of legacy GWs identified by an
anycast address,
I think this case is not realistic because if VPN GWs do not support re-direct,
then the anycast should not be advertised in the DNS anyway.

If a legacy client sends to a upgraded GW identified by a unicast or
anycast address,
the GW can return the REDIRECT payload. If the C bit is set, the client
does not understand; thus it will try another GW. If the C bit is not set,
the client can ignore the REDIRECT payload and continue with the procedure.
Whether the C bit in the REDIRECT payload should be set or not is up to the
configuration of the GW. IMO, when using anycast address, the GW must return
a REDIRECT payload with the C bit set in order to discourage the legacy
client to continue with the next step.

To summarize analysis of all cases, first, I do not think it is
necessary to include the

REDIRECT_SUPPORTED payload in the message from the client, which only introduces
overhead. Second, if the IKE_SA_INIT request did not include the
REDIRECT_SUPPORTED
payload, if supported by the responder, the REDIRECT payload can be returned
to the VPN client with the C bit set or unset. In the case the client
sends to an
anycast address, the C bit must be set.

REDIRECTED_FROM
I understand the purpose of using the REDIRECTED_FROM payload. However it does
not help against potential attacks because an attacker can simply send
the first
IKE_SA_INIT message without the REDIRECTED_FROM payload, the VPN GW needs to
process such a message because this message could be from a legitimate
and legacy client.
furthermore, this payload causes additional overhead.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "fan zhao" <[email-masked]>
Date: Fri, 23 May 2008 18:29:49 -0700

Dear all,

I apologized for clicking the send button by mistake before I finish
formatting/revising.
Please ignore the previous email and see my comments below.
-----------------------------------------------------------------------------------------------------------------------------

Dear authors,

Abstract
"...Currently there is no standard mechanism specified that allows an
overloaded VPN gateway to re-direct the VPN client to attach to
another gateway...The proposed mechanism can also be used for Mobile
IPv6 to enable the home agent to re-direct the mobile node to another
home agent."

Fan> Load-balancing is a good motivation for this work. The current
version describes this issue very well in the following text. IMO,
there are other motivation and scenarios that need this redirect
mechanism as well, especially those related to Mobile IP operation.
For example, re-direct mechanism is useful to ensure a MN to use the
same HA/LMA during handover. Assume that a MN powers up and obtains
connectivity in a PMIP domain, and later it may handover to another
access network where it needs to use DSMIPv6. The MN runs HA
discovery and then sets up an IPSec SA with this HA. In order to
maintain session continuity, normally the entity that acts as a HA
should be the same one that acts as a LMA before handover. This
re-direct mechanism is useful in this case because it can reduce
handover delay.

Fan> Another example is related to multi-homing. For example, a VPN
client/MN sets up connectivity to a first network through a VPN
gateway/HA. Then the VPN client/MN wants to connect to a second
network and discovers a different VPN gateway/HA; however the first
VPN gateway/HA can be used for the VPN client/MN to access the
second network. This redirect mechanism is useful to redirect the
client/MN to the first VPN gateway/HA so that the same IPSec SA
established before can be re-used, which reduces states and
overhead. IMO, these should be captured in various sections,
otherwise the usage of this mechanism may be unnecessarily limited
to certain scenarios.

1. Introduction
"...However, using DNS is not flexible when it comes to assigning a
VPN gateway to the VPN client based on the load on the VPN gateways.
..."

Fan> This sentence is not wrong; however I felt it may cause confusion
because DNS can provide some sort of load-balancing, for example the
DNS server can return the IP address of a server selected from a pool
based on the round-robin fashion. IMO, DNS is a separate infrastructure
and it is practical difficult for network operators to update and
advertise additional information to help the VPN client to select an
optimal VPN gateway to be used via DNS. Thererfore, such selection made
by the client may not be optimal because the client may not have as
complete information as the network.

Fan> How about the following re-wording:
"...Typically, the VPN client tries to connect to the IP address of
the VPN gateways that appears first in the DNS response. However, this
cannot guarantee a VPN gateway selected is optimal or prefered by the
network. Therefore, when the setup of the VPN tunnel to the first VPN
gateway fails, e.g. due to this reason, then the VPN client has to
try to attach to the other VPN gateways returned in the DNS response,
which results in significant delay."

Fan> IMO, the re-direct can also be done during the IKE_AUTH exchange,
during which the client and gateway perform mutual authentication,
therefore the threats described in section 6 can be eliminated.
Furthermore, to enable load balancing, some network may have policy,
like allocating/dedicating certain VPN gateways based on the IDs of
VPN clients. Therefore, the re-direct decision can only be made
after the ID of VPN client is authenticated. The procedure can look
like as follows:

The Initiator		The Responder
HDR, SAi1, KEi, Ni	
		-->	
		<--	HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}	
		-->	
		<--	HDR, SK {IDr, [CERT,] AUTH, REDIRECT}

Fan> To make it clearer, I propose "Besides unicast addresses, the
re-direct mechanism can also be used in conjunction with anycast
addresses."

Fan> This REDIRECT_SUPPORTED notification can be useful for
compatibility issue. However I am not sure it is needed.

Fan> Rfc 4306 already describes how to handle un-recongized payload,
i.e. if this is a critical payload (the C bit is set) and the payload
type is unrecognized, the message MUST be rejected and the response
MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD; or if the
critical flag is not set and the payload type is unsupported, that
payload MUST be ignored.

Fan> There are at least two cases worth further considering:
an upgraded VPN client (i.e. a client supporting this re-direct
mechanism) connects to a legacy VPN gateway (i.e. a gateway with no
support of this re-direct mechanism) and a legacy client connects
to an upgraded GW.

Fan> In the following, I assume that if there are multiple VPN GWs
in one network, all or none of them are upgraded.

Fan> If a upgraded client sends to a legacy GW identified by a unicast
address, if REDIRECT_SUPPORTED is used and the C bit is set, the
legacy GW will reject this request and return UNSUPPORTED_CRITICAL_
PAYLOAD. And then client will have to try again with the same or
different GW, maybe without REDIRECT_SUPPORTED for this time. On the
other hand, if the upgraded client does not include REDIRECT_SUPPORTED,
the setup can proceed. Since in this case the GW cannot provide re-
direct support anyway, without indicating REDIRECT_SUPPORTED, the
signaling procedure can be shortened.

Fan> If a upgraded client sends to a pool of legacy GWs identified by
an anycast address, I think this case is not realistic because if VPN
GWs do not support re-direct, then the anycast should not be
advertised in the DNS anyway.

Fan> If a legacy client sends to a upgraded GW identified by a unicast
or anycast address, the GW can return the REDIRECT payload. If the C
bit is set, the client does not understand; thus it will try another
GW. If the C bit is not set, the client can ignore the REDIRECT
payload and continue with the procedure. Whether the C bit in the
REDIRECT payload should be set or not is up to the configuration
of the GW. IMO, when using anycast address, the GW must return
a REDIRECT payload with the C bit set in order to discourage the
legacy client to continue with the next step.

Fan> To summarize analysis of all cases, first, I am not sure it
is necessary to include the REDIRECT_SUPPORTED payload in the message
from the client, which introduces overhead. Second, if the
IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload,
if supported by the responder, the REDIRECT payload can be returned
to the VPN client with the C bit set or unset. In the case the
client sends to an anycast address, the C bit must be set.

REDIRECTED_FROM

Fan> I understand the purpose of using the REDIRECTED_FROM payload.
IMHO, it does not help against potential attacks because an attacker
can simply send the first IKE_SA_INIT message without the REDIRECTED_
FROM payload, the VPN GW needs to process such a message because this
message could be from a legitimate and legacy client. Furthermore,
this payload causes additional overhead.

Thanks again. Look forward to your reply.

Sincerely,
fan

---

From: <[email-masked]>
Date: Mon, 26 May 2008 10:31:29 +0300

> critical flag is not set and the payload type is unsupported, that

The 'C' bit operates at the payload type level (not at payload content
level), so per RFC 4306, it's always zero for all Notify payloads.
(But it would be, of course, possible to specify a new payload type.)

> legacy client to continue with the next step.

If the legacy client knows just one GW address, and it receives an
IKE_SA_INIT response containing only the REDIRECT notification (and
nothing else -- e.g. 2nd message in Section 3 of the draft), the
VPN connection would failed.

So if we don't have REDIRECT_SUPPORTED, the gateway needs to reply
with a full IKE_SA_INIT response that's acceptable to legacy clients,
too. That would require more processing and state for the gateway...

<snip>

> this payload causes additional overhead.

The situation addressed by REDIRECTED_FROM is not a malicious
initiator (who can indeed just remove the REDIRECTED_FROM payload),
but a malicious responder who redirects a large number of honest
clients to the victim.

Best regards,
Pasi

---

From: "fan zhao" <[email-masked]>
Date: Tue, 27 May 2008 18:23:05 -0700

Hi Pasi,

Sorry I could not reply earlier.
Please see my reply below.

> (But it would be, of course, possible to specify a new payload type.)

Fan> You are correct. Sorry for my mis-understanding on the meaning of
the 'C' bit.
I do not have strong oponion on whether to define a new type of
payload for redirect
information either, though such information could be "critical" in some sense.

> too. That would require more processing and state for the gateway...

Fan> I agree. Using REDIRECT_SUPPORTED will be helpful in this case,
if the VPN GW
wants to redirect the VPN client immediately during the IKE_INIT_SA exchange.

> but a malicious responder who redirects a large number of honest
Fan> I see. Nevertheless, attackers can frame an innocent VPN GW, by
forging and sending
many IKEv2 messages to the victim VPN GW with REDIRECTED_FROM payload
indicating
the IP address of the innocent VPN GW. Do I miss something?

Thanks a lot.

Sincerely,
fan