draft-ietf-ipsecme-ikev2-redirect-09.txt   draft-ietf-ipsecme-ikev2-redirect-10.txt 
Network Working Group V. Devarapalli Network Working Group V. Devarapalli
Internet-Draft WiChorus Internet-Draft WiChorus
Intended status: Standards Track K. Weniger Intended status: Standards Track K. Weniger
Expires: November 12, 2009 May 11, 2009 Expires: November 20, 2009 May 19, 2009
Redirect Mechanism for IKEv2 Redirect Mechanism for IKEv2
draft-ietf-ipsecme-ikev2-redirect-09.txt draft-ietf-ipsecme-ikev2-redirect-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 12, 2009. This Internet-Draft will expire on November 20, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IKEv2 Initial Exchange with Redirect . . . . . . . . . . . . . 4 3. IKEv2 Initial Exchange with Redirect . . . . . . . . . . . . . 4
4. Use of Anycast Addresses with the Redirect Mechanism . . . . . 6 4. Use of Anycast Addresses with the Redirect Mechanism . . . . . 6
5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 7 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 7
6. Redirect During IKE_AUTH Exchange . . . . . . . . . . . . . . 7 6. Redirect During IKE_AUTH Exchange . . . . . . . . . . . . . . 7
7. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 8 7. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 8
7.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 9 7.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 8
7.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 10 7.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 10
8. Use of the Redirect Mechanism between IKEv2 Peers . . . . . . 11 8. Use of the Redirect Mechanism between IKEv2 Peers . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
IKEv2 [2] is used for setting up IPsec-based VPNs. The IP address of IKEv2 [2] is used for setting up IPsec-based VPNs. The IP address of
the VPN gateway can be configured on the VPN client. But this does the VPN gateway can be configured on the VPN client. But this does
not scale well, when the number of VPN gateways is large. Dynamic not scale well, when the number of VPN gateways is large. Dynamic
discovery of VPN gateways using DNS is quite widely used too. discovery of VPN gateways using DNS is quite widely used too.
However, using DNS is not flexible when it comes to assigning a VPN 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. The gateway to the VPN client based on the load on the VPN gateways. The
VPN client typically tries to connect to the IP address of the VPN VPN client typically tries to connect to the IP address of the VPN
gateways that appears first in the DNS response. If the VPN tunnel gateway that appears first in the DNS response. If the VPN tunnel
setup fails, then the VPN client tries to attach to the other VPN setup fails, then the VPN client tries to attach to the other VPN
gateways returned in the DNS response. gateways returned in the DNS response.
This document proposes a redirect mechanism for IKEv2 that enables a This document proposes a redirect mechanism for IKEv2 that enables a
VPN gateway to redirect the VPN client to another VPN gateway, for VPN gateway to redirect the VPN client to another VPN gateway, for
example, based on the load condition. The redirect can be done example, based on the load condition. The redirect can be done
during the IKE_SA_INIT or the IKE_AUTH exchange. Gateway-initiated during the IKE_SA_INIT or the IKE_AUTH exchange. Gateway-initiated
redirect in the middle of a session is also supported. The redirect redirect in the middle of a session is also supported. The redirect
mechanism can also be used in conjunction with anycast addresses. In mechanism can also be used in conjunction with anycast addresses. In
this case, anycast address for the cluster of VPN gateways is stored this case, anycast address for the cluster of VPN gateways is stored
skipping to change at page 5, line 36 skipping to change at page 5, line 36
[IDr,]AUTH, SAi2, TSi, TSr} --> [IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_R:500 -> IP_I:500) (IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH, <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr} SAr2, TSi, TSr}
In particular, the client MUST use the same Peer Authorization In particular, the client MUST use the same Peer Authorization
Database (PAD) and Security Policy Database (SPD) entries as it would Database (PAD) and Security Policy Database (SPD) entries as it would
have used with the original gateway. Receiving a redirect have used with the original gateway. Receiving a redirect
notification MUST NOT result in the modification of any PAD or SPD notification MUST NOT result in the modification of any PAD or SPD
entries. In practice, this means the new gateway either has to entries. In practice, this means the new gateway either has to use
either use the same responder identity (IDr) as the original gateway, the same responder identity (IDr) as the original gateway, or both
or both should be part of a group of responders that are authorized should be part of a group of responders that are authorized by the
by the same PAD entry. See section 4.4.3.1 of [8] on using DNS names same PAD entry. See section 4.4.3.1 of [8] on using DNS names to
to represent a group of peers in a PAD entry. represent a group of peers in a PAD entry.
When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home
Agent (HA), redirecting the IKEv2 exchange to another HA is not Agent (HA), redirecting the IKEv2 exchange to another HA is not
enough; the Mobile IPv6 signalling also needs to be sent to the new enough; the Mobile IPv6 signalling also needs to be sent to the new
HA address. The MN MAY treat the information received in the HA address. The MN MAY treat the information received in the
IKE_SA_INIT response in similar way as it would treat HA discovery IKE_SA_INIT response in similar way as it would treat HA discovery
information received from other unauthenticated (and potentially information received from other unauthenticated (and potentially
untrustworthy) sources (such as DNS lookups not protected with untrustworthy) sources (such as DNS lookups not protected with
DNSSEC). However, if the MN has authenticated information about its DNSSEC). However, if the MN has authenticated information about its
Home Agent, it MUST NOT be updated based on the IKE_SA_INIT response. Home Agent, it MUST NOT be updated based on the IKE_SA_INIT response.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
gateway. gateway.
6. Redirect During IKE_AUTH Exchange 6. Redirect During IKE_AUTH Exchange
If the gateway decides to redirect the client during the IKE_AUTH If the gateway decides to redirect the client during the IKE_AUTH
exchange, based on the identity presented by the client in the exchange, based on the identity presented by the client in the
IKE_AUTH request message, it prevents the creation of a CHILD SA and IKE_AUTH request message, it prevents the creation of a CHILD SA and
sends the REDIRECT payload in the IKE_AUTH response. When the client sends the REDIRECT payload in the IKE_AUTH response. When the client
receives the IKE_AUTH response with the REDIRECT payload, it SHOULD receives the IKE_AUTH response with the REDIRECT payload, it SHOULD
delete the existing IKEv2 security association with the gateway by delete the existing IKEv2 security association with the gateway by
sending an Informational mesage with a DELETE payload. The gateway sending an Informational message with a DELETE payload. The gateway
MUST verify the client's AUTH payload before sending the Redirect MUST verify the client's AUTH payload before sending the Redirect
payload, and the client MUST verify the gateway's AUTH payload before payload, and the client MUST verify the gateway's AUTH payload before
acting on the Redirect payload. acting on the Redirect payload.
Initiator Responder ( VPN GW) Initiator Responder ( VPN GW)
--------- ------------------- --------- -------------------
(IP_I:500 -> IP_R:500) (IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, --> HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_SUPPORTED) N(REDIRECTED_SUPPORTED)
skipping to change at page 8, line 34 skipping to change at page 8, line 34
described in Section 2.16 of RFC 4306 [2], or multiple authentication described in Section 2.16 of RFC 4306 [2], or multiple authentication
methods as described in RFC 4739 [6], the gateway may decide to methods as described in RFC 4739 [6], the gateway may decide to
redirect the client based on the interaction with the AAA server or redirect the client based on the interaction with the AAA server or
the external authentication server. In this case, the gateway MUST the external authentication server. In this case, the gateway MUST
send the REDIRECT Notification payload in either the first or the send the REDIRECT Notification payload in either the first or the
last IKE_AUTH response. The client and the gateway MUST verify the last IKE_AUTH response. The client and the gateway MUST verify the
AUTH payloads as described above. AUTH payloads as described above.
When EAP is used, the gateway MAY also redirect the client based on When EAP is used, the gateway MAY also redirect the client based on
the unauthenticated identity presented by the client in the first the unauthenticated identity presented by the client in the first
IKE_AUTH exchange itself. presented by the client in the first
IKE_AUTH exchange itself. Since EAP is used as the authentication IKE_AUTH exchange itself. Since EAP is used as the authentication
mechanism, the client does not include AUTH payload to authenticate mechanism, the client does not include AUTH payload to authenticate
his identity, but the server still MUST include his own AUTH payload, his identity, but the server still MUST include his own AUTH payload,
and client MUST verify it. Note that the IKEv2 SA is not created in and client MUST verify it. Note that the IKEv2 SA is not created in
this case and the client does not have to explicitly delete the IKEv2 this case and the client does not have to explicitly delete the IKEv2
SA. SA.
In all of the cases above, the client MUST accept the REDIRECT In all of the cases above, the client MUST accept the REDIRECT
notification only in the first IKE_AUTH response or the last IKE_AUTH notification only in the first IKE_AUTH response or the last IKE_AUTH
response. It MUST NOT accept the REDIRECT notification in an response. It MUST NOT accept the REDIRECT notification in an
skipping to change at page 12, line 28 skipping to change at page 12, line 17
The use of REDIRECTED_FROM payload is intended to discourage a rogue The use of REDIRECTED_FROM payload is intended to discourage a rogue
VPN gateway from redirecting a large number of VPN clients to a VPN gateway from redirecting a large number of VPN clients to a
particular VPN gateway. It does not prevent such a DoS attack. particular VPN gateway. It does not prevent such a DoS attack.
The redirect mechanism MUST NOT update any state on the client apart The redirect mechanism MUST NOT update any state on the client apart
from the VPN gateway information. When used with Mobile IPv6, care from the VPN gateway information. When used with Mobile IPv6, care
must be taken to ensure that the home agent information that the must be taken to ensure that the home agent information that the
mobile node has configured is not modified wrongly by the redirect mobile node has configured is not modified wrongly by the redirect
message. message.
Redirecting based on the unauthenticated identities might leak out The client could end up getting redirected multiple times in a
information about the user when active attacker can get information sequence, either because of wrong configuration or a DoS attack. The
to which gateway user was redirected to. If redirection is based on client could even end up in a loop with two or more gateways
some internal information of the user, it might leak information to redirecting the client to each other. This could deny service to the
client. To prevent this, the client should be configured not to
accept more a certain number of redirects within a short time period.
This should be configurable on the client.
Redirecting based on the unauthenticated identities from the client
might leak out information about the user when an active attacker,
pretending to be a VPN client can get information to which gateway
the real user was redirected to. If redirection is based on some
internal information of the user, it might leak information to
attacker about the user which might not available otherwise. To attacker about the user which might not available otherwise. To
protect against this kind of attack the redirection based on the ID prevent these kind of attacks, redirection based on unauthenticated
should happen only after client has also authenticated himself. ID should be avoided and should be done only after the client has
also authenticated itself.
10. IANA Considerations 10. IANA Considerations
This document defines three new IKEv2 Notification Message types as This document defines three new IKEv2 Notification Message types as
described in Section 7. The three Notify Message Types must be described in Section 7. The three Notify Message Types must be
assigned values between 16396 and 40959. assigned values between 16396 and 40959.
o REDIRECT_SUPPORTED o REDIRECT_SUPPORTED
o REDIRECT o REDIRECT
o REDIRECTED_FROM o REDIRECTED_FROM
skipping to change at page 13, line 10 skipping to change at page 13, line 10
Type". This is used to indicate the type of information regarding Type". This is used to indicate the type of information regarding
the VPN gateway that is carried in the REDIRECT (Section 7.2) and the VPN gateway that is carried in the REDIRECT (Section 7.2) and
REDIRECTED_FROM (Section 7.3) Notification payloads. The following REDIRECTED_FROM (Section 7.3) Notification payloads. The following
values are assigned. values are assigned.
1 - IPv4 address of the new VPN gateway 1 - IPv4 address of the new VPN gateway
2 - IPv6 address of the new VPN gateway 2 - IPv6 address of the new VPN gateway
3 - FQDN 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 Values '0', and 4-255 are reserved. New values can be allocated by
expert review. expert review. A specification that extends this registry MUST also
mention which of the new values are valid in which Notification
payload.
11. Acknowledgements 11. Acknowledgements
The use of anycast address with IKEv2 was first described in [7]. It The use of anycast address with IKEv2 was first described in [7]. It
was then added to an early draft version of RFC 5026 and later was then added to an early draft version of RFC 5026 and later
removed before the RFC was published. Therefore the authors of [7] removed before the RFC was published. Therefore the authors of [7]
and RFC 5026 are acknowledged. and RFC 5026 are acknowledged.
Thanks to Pasi Eronen, with whom the solution described in this Thanks to Pasi Eronen, with whom the solution described in this
document was extensively discussed. Thanks to Tero Kivinen for document was extensively discussed. Thanks to Tero Kivinen for
 End of changes. 11 change blocks. 
19 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/