--- 1/draft-ietf-ipsecme-ikev2-redirect-09.txt 2009-05-20 01:12:04.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2-redirect-10.txt 2009-05-20 01:12:04.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group V. Devarapalli Internet-Draft WiChorus Intended status: Standards Track K. Weniger -Expires: November 12, 2009 May 11, 2009 +Expires: November 20, 2009 May 19, 2009 Redirect Mechanism for IKEv2 - draft-ietf-ipsecme-ikev2-redirect-09.txt + draft-ietf-ipsecme-ikev2-redirect-10.txt Status of this Memo 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, 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 than English. Internet-Drafts are working documents of the Internet Engineering @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -58,42 +58,42 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IKEv2 Initial Exchange with Redirect . . . . . . . . . . . . . 4 4. Use of Anycast Addresses with the Redirect Mechanism . . . . . 6 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 7 6. Redirect During IKE_AUTH Exchange . . . . . . . . . . . . . . 7 7. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 8 - 7.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 9 + 7.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 8 7.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 10 8. Use of the Redirect Mechanism between IKEv2 Peers . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 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 not scale well, when the number of VPN gateways is large. Dynamic discovery of VPN gateways using DNS is quite widely used too. 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 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 gateways returned in the DNS response. This document proposes a redirect mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. The redirect can be done during the IKE_SA_INIT or the IKE_AUTH exchange. Gateway-initiated redirect in the middle of a session is also supported. The redirect mechanism can also be used in conjunction with anycast addresses. In this case, anycast address for the cluster of VPN gateways is stored @@ -194,25 +194,25 @@ [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 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. + entries. In practice, this means the new gateway either has to 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. 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. @@ -298,21 +298,21 @@ gateway. 6. Redirect During IKE_AUTH Exchange If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the 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 receives the IKE_AUTH response with the REDIRECT payload, it SHOULD 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 payload, and the client MUST verify the gateway's AUTH payload before acting on the Redirect payload. Initiator Responder ( VPN GW) --------- ------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_SUPPORTED) @@ -332,21 +332,20 @@ described in Section 2.16 of RFC 4306 [2], or multiple authentication methods as described in RFC 4739 [6], the gateway may decide to redirect the client based on the interaction with the AAA server or the external authentication server. In this case, the gateway MUST send the REDIRECT Notification payload in either the first or the last IKE_AUTH response. The client and the gateway MUST verify the AUTH payloads as described above. When EAP is used, the gateway MAY also redirect the client based on 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 mechanism, the client does not include AUTH payload to authenticate 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 this case and the client does not have to explicitly delete the IKEv2 SA. 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 response. It MUST NOT accept the REDIRECT notification in an @@ -506,27 +505,37 @@ The use of REDIRECTED_FROM payload is intended to discourage a rogue VPN gateway from redirecting a large number of VPN clients to a particular VPN gateway. It does not prevent such a DoS attack. 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. - Redirecting based on the unauthenticated identities might leak out - information about the user when active attacker can get information - to which gateway user was redirected to. If redirection is based on - some internal information of the user, it might leak information to + The client could end up getting redirected multiple times in a + sequence, either because of wrong configuration or a DoS attack. The + client could even end up in a loop with two or more gateways + 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 - protect against this kind of attack the redirection based on the ID - should happen only after client has also authenticated himself. + prevent these kind of attacks, redirection based on unauthenticated + ID should be avoided and should be done only after the client has + also authenticated itself. 10. IANA Considerations This document defines three new IKEv2 Notification Message types as described in Section 7. The three Notify Message Types must be assigned values between 16396 and 40959. o REDIRECT_SUPPORTED o REDIRECT o REDIRECTED_FROM @@ -535,21 +544,23 @@ 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. + expert review. A specification that extends this registry MUST also + mention which of the new values are valid in which Notification + payload. 11. Acknowledgements 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 removed before the RFC was published. Therefore the authors of [7] and RFC 5026 are acknowledged. Thanks to Pasi Eronen, with whom the solution described in this document was extensively discussed. Thanks to Tero Kivinen for