draft-ietf-ipsecme-ikev2-redirect-02.txt   draft-ietf-ipsecme-ikev2-redirect-03.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: June 14, 2009 Panasonic Expires: August 6, 2009 Panasonic
December 11, 2008 February 2, 2009
Re-direct Mechanism for IKEv2 Re-direct Mechanism for IKEv2
draft-ietf-ipsecme-ikev2-redirect-02.txt draft-ietf-ipsecme-ikev2-redirect-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 14, 2009. This Internet-Draft will expire on August 6, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
IKEv2 is a protocol for setting up VPN tunnels from a remote location IKEv2 is a protocol for setting up VPN tunnels from a remote location
to a gateway so that the VPN client can access services in the to a gateway so that the VPN client can access services in the
network behind the gateway. Currently there is no standard mechanism network behind the gateway. Currently there is no standard mechanism
specified that allows an overloaded VPN gateway or a VPN gateway that specified that allows an overloaded VPN gateway or a VPN gateway that
is being shut down for maintenance to re-direct the VPN client to is being shut down for maintenance to re-direct the VPN client to
attach to another gateway. This document proposes a re-direct attach to another gateway. This document proposes a re-direct
mechanism for IKEv2. The proposed mechanism can also be used in mechanism for IKEv2. The proposed mechanism can also be used in
skipping to change at page 2, line 16 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4 3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4
4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5 4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5
5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6
6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7 6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7
6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7 6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7
6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8 6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8
6.4. REDIRECT_ACK . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 13
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
The rest of the IKEv2 exchange is the same as described in Section 3. The rest of the IKEv2 exchange is the same as described in Section 3.
5. Gateway Initiated Redirect 5. Gateway Initiated Redirect
The re-direct mechanism may also be used by a VPN gateway to re- The re-direct mechanism may also be used by a VPN gateway to re-
direct the client to another VPN gateway in middle of a session. To direct the client to another VPN gateway in middle of a session. To
re-direct a client, the gateway should send an INFORMATIONAL message re-direct a client, the gateway should send an INFORMATIONAL message
with the REDIRECT Notify payload. The REDIRECT payload MUST carry with the REDIRECT Notify payload. The REDIRECT payload MUST carry
information about the new VPN gateway. When the client receives this information about the new VPN gateway. When the client receives this
message, it MUST send an INFORMATIONAL message with the REDIRECT_ACK message, it MUST send an empty message as an acknowledgement. Until
Notify payload. Until the client responds with an INFORMATIONAL the client responds with an acknowledgement, the gateway SHOULD re-
message with the REDIRECT_ACK payload, the gateway SHOULD re-transmit transmit the re-direct INFORMATIONAL message as described in [2].
the re-direct INFORMATIONAL message as described in [2]. The The following illustrates the INFORMATIONAL message exchange for
following illustrates the INFORMATIONAL message exchange for gateway- gateway-initiated redirect.
initiated redirect.
Initiator (VPN client) Responder (VPN GW) Initiator (VPN client) Responder (VPN GW)
---------------------- ------------------ ---------------------- ------------------
<-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]}
HDR, SK {N[REDIRECT_ACK]} --> HDR, SK {} -->
The INFORMATIONAL message exchange described above is protected by The INFORMATIONAL message exchange described above is protected by
the existing IKEv2 SA between the client and the gateway. the existing IKEv2 SA between the client and the gateway.
Once the client responds to the gateway with the REDIRECT_ACK Once the client sends an acknowledgement to the gateway, it SHOULD
payload, it SHOULD delete the existing security associations with the delete the existing security associations with the old gateway by
old gateway. The gateway MAY also decide to delete the security sending an Informational message with a DELETE payload. The gateway
associations without any signaling from the client. However, it MAY also decide to delete the security associations without any
should allow sufficient time for the client to setup the required signaling from the client. However, it should allow sufficient time
security associations with the new security gateway. This time for the client to setup the required security associations with the
period should be configurable on the gateway. new security gateway. This time period should be configurable on the
gateway.
6. Redirect Messages 6. Redirect Messages
6.1. REDIRECT_SUPPORTED 6.1. REDIRECT_SUPPORTED
The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT
request by the initiator to indicate support for the IKEv2 re-direct request by the initiator to indicate support for the IKEv2 re-direct
mechanism described in this document. mechanism described in this document.
1 2 3 1 2 3
skipping to change at page 9, line 38 skipping to change at page 9, line 38
information that is sent to identify the new VPN gateway. The information that is sent to identify the new VPN gateway. The
following values are reserved by this document. following values are reserved by this document.
1 - IPv4 address of the original VPN gateway 1 - IPv4 address of the original VPN gateway
2 - IPv6 address of the original VPN gateway 2 - IPv6 address of the original VPN gateway
All other values for this field are reserved and MUST NOT be used. All other values for this field are reserved and MUST NOT be used.
The identity of the original VPN gateway is carried in the 'Original The identity of the original VPN gateway is carried in the 'Original
Responder GW Identity' field. Responder GW Identity' field.
6.4. REDIRECT_ACK
The REDIRECT_ACK payload is included in the INFORMATIONAL message
sent by the VPN client to the gateway in response to a gateway
initiated redirect message as described in Section 5.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and
the 'Notify Message Type' fields are the same as described in Section
3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that
the SPI is not present in this message.
The 'Payload Length' field MUST be set to '8'. The 'Notify Message
Type' field is set to indicate the REDIRECT_ACK payload <value to be
assigned by IANA>.
7. Security Considerations 7. Security Considerations
An eavesdropper on the path between VPN client and server may send a An eavesdropper on the path between VPN client and server may send a
redirect to the client upon receiving an IKE_SA_INIT message from redirect to the client upon receiving an IKE_SA_INIT message from
this client. This is no problem regarding DoS attacks for the VPN this client. This is no problem regarding DoS attacks for the VPN
connection, since an on-path-attacker can as well drop the connection, since an on-path-attacker can as well drop the
IKE_SA_INIT requests to prevent VPN access for the client. But an IKE_SA_INIT requests to prevent VPN access for the client. But an
eavesdropper on the path between VPN client and server can redirect a eavesdropper on the path between VPN client and server can redirect a
large number of clients to a victim, which is then flooded with large number of clients to a victim, which is then flooded with
IKE_SA_INIT requests. Flooding only happens if many clients initiate IKE_SA_INIT requests. Flooding only happens if many clients initiate
skipping to change at page 10, line 42 skipping to change at page 10, line 20
8. IANA Considerations 8. IANA Considerations
This document defines four new IKEv2 Notification Message types as This document defines four new IKEv2 Notification Message types as
described in Section 6. The four Notify Message Types must be described in Section 6. The four 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
o REDIRECT_ACK
9. Acknowledgements 9. Acknowledgements
The use of anycast address with IKEv2 was first described in [6]. It The use of anycast address with IKEv2 was first described in [6]. 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 [6] removed before the RFC was published. Therefore the authors of [6]
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
skipping to change at page 12, line 4 skipping to change at page 11, line 24
Authors' Addresses Authors' Addresses
Vijay Devarapalli Vijay Devarapalli
WiChorus WiChorus
3590 North First St 3590 North First St
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: vijay@wichorus.com Email: vijay@wichorus.com
Killian Weniger Killian Weniger
Panasonic R&D Center Germany Panasonic R&D Center Germany
Monzastr. 4c Monzastr. 4c
Langen 63225 Langen 63225
Germany Germany
Email: kilian.weniger@eu.panasonic.com Email: kilian.weniger@eu.panasonic.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 14 change blocks. 
52 lines changed or deleted 37 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/