< draft-devarapalli-ipsec-ikev2-redirect-01.txt   draft-devarapalli-ipsec-ikev2-redirect-02.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: January 14, 2009 Panasonic Expires: January 15, 2009 Panasonic
P. Eronen P. Eronen
Nokia Nokia
July 13, 2008 July 14, 2008
Re-direct Mechanism for IKEv2 Re-direct Mechanism for IKEv2
draft-devarapalli-ipsec-ikev2-redirect-01.txt draft-devarapalli-ipsec-ikev2-redirect-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 14, 2009. This Internet-Draft will expire on January 15, 2009.
Abstract Abstract
IKEv2 is a popular protocol for setting up VPN tunnels from a remote IKEv2 is a popular protocol for setting up VPN tunnels from a remote
location to a gateway so that the VPN client can access services in location to a gateway so that the VPN client can access services in
the network behind the gateway. Currently there is no standard the network behind the gateway. Currently there is no standard
mechanism specified that allows an overloaded VPN gateway to re- mechanism specified that allows an overloaded VPN gateway to re-
direct the VPN client to attach to another gateway. This document direct the VPN client to attach to another gateway. This document
proposes a re-direct mechanism for IKEv2. The proposed mechanism can proposes a re-direct mechanism for IKEv2. The proposed mechanism can
also be used for Mobile IPv6 to enable the home agent to re-direct also be used for Mobile IPv6 to enable the home agent to re-direct
skipping to change at page 3, line 19 skipping to change at page 3, line 19
this does not scale well, when the number of VPN gateways is large. 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. 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 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 gateways 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 re-direct mechanism for IKEv2 that enables a This document proposes a re-direct mechanism for IKEv2 that enables a
VPN gateway to re-direct the VPN client to another VPN gateway, based VPN gateway to re-direct the VPN client to another VPN gateway, for
on load condition. The re-direct is done during the IKE_SA_INIT example, based on the load condition. The re-direct is done during
exchange. The re-direct mechanism can also be used in conjunction the IKE_SA_INIT exchange. The re-direct mechanism can also be used
with anycast addresses. In this case, anycast address for the in conjunction with anycast addresses. In this case, anycast address
cluster of VPN gateways is stored in the DNS instead of a list of for the cluster of VPN gateways is stored in the DNS instead of a
unicast IP addresses of the VPN gateways. list of unicast IP addresses of the VPN gateways.
The re-direct can also happen because of administrative or optimal The re-direct can also happen because of administrative or optimal
routing reasons. This document does not attempt to provide an routing reasons. This document does not attempt to provide an
exhaustive list of reasons for re-directing a VPN client to another exhaustive list of reasons for re-directing a VPN client to another
VPN gateway. VPN gateway.
Mobile IPv6 [3] may use IKEv2 for mutual authentication between the Mobile IPv6 [3] may use IKEv2 for mutual authentication between the
mobile node and the home agent. IKEv2 may also be used for home mobile node and the home agent. IKEv2 may also be used for home
address configuration and setting up IPsec security associations for address configuration and setting up IPsec security associations for
protecting Mobile IPv6 signaling messages [4]. The IKEv2 exchange protecting Mobile IPv6 signaling messages [4]. The IKEv2 exchange
skipping to change at page 6, line 19 skipping to change at page 6, line 19
HDR(A,0), SAi1, KEi, Ni) --> HDR(A,0), SAi1, KEi, Ni) -->
N(REDIRECT_SUPPORTED) N(REDIRECT_SUPPORTED)
(ANYCAST:500 -> IP_I:500) (ANYCAST:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, IP_R) <-- HDR(A,0), N(REDIRECT, IP_R)
If the destination address on the IKE_SA_INIT request is an anycast If the destination address on the IKE_SA_INIT request is an anycast
address, the VPN gateway that received the IKE_SA_INIT request MUST address, the VPN gateway that received the IKE_SA_INIT request MUST
include the REDIRECT payload to re-direct the VPN client to a unicast include the REDIRECT payload to re-direct the VPN client to a unicast
address of one of the VPN gateway. The VPN gateway that received the address of one of the VPN gateway. The VPN gateway that received the
IKE_SA_INIT request MAY re-direct the client to itself, if it is not IKE_SA_INIT request MAY re-direct the client to its own unicast
overloaded. address, if it is not overloaded.
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. Redirect Messages 5. Redirect Messages
5.1. REDIRECT_SUPPORTED 5.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.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
indicate that the SPI is not present in this message. indicate that the SPI is not present in this message.
The 'Payload Length' field MUST be set to either '13' or '25' The 'Payload Length' field MUST be set to either '13' or '25'
depending on whether an IPv4 or IPv6 address of the new VPN gateway depending on whether an IPv4 or IPv6 address of the new VPN gateway
is sent in the message. The 'Notify Message Type' field is set to is sent in the message. The 'Notify Message Type' field is set to
indicate the REDIRECT payload <value to be assigned by IANA>. The indicate the REDIRECT payload <value to be assigned by IANA>. The
'GW Identity Type' field indicates the type of information that is 'GW Identity Type' field indicates the type of information that is
sent to identify the new VPN gateway. The following values are sent to identify the new VPN gateway. The following values are
reserved by this document. reserved by this document.
1 - FQDN of the new VPN gateway 1 - IPv4 address of the new VPN gateway
2 - IPv4 address of the new VPN gateway 2 - IPv6 address of the new VPN gateway
3 - IPv6 address of the new VPN gateway 3 - FQDN of the new 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 new VPN gateway is carried in the 'New Responder The identity of the new VPN gateway is carried in the 'New Responder
GW Identity' field. GW Identity' field.
5.3. REDIRECTED_FROM 5.3. REDIRECTED_FROM
The REDIRECTED_FROM message type is included in the IKE_SA_INIT The REDIRECTED_FROM message type is included in the IKE_SA_INIT
request from the initiator to the new VPN gateway to indicate the IP request from the initiator to the new VPN gateway to indicate the IP
address of the original VPN gateway that re-directed the initiator. address of the original VPN gateway that re-directed the initiator.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
indicate that the SPI is not present in this message. indicate that the SPI is not present in this message.
The 'Payload Length' field MUST be set to either '13' or '25' The 'Payload Length' field MUST be set to either '13' or '25'
depending on whether an IPv4 or IPv6 address of the original VPN depending on whether an IPv4 or IPv6 address of the original VPN
gateway is sent in the message. The 'Notify Message Type' field is gateway is sent in the message. The 'Notify Message Type' field is
set to indicate the REDIRECTED_FROM payload <value to be assigned by set to indicate the REDIRECTED_FROM payload <value to be assigned by
IANA>. The 'GW Identity Type' field indicates the type of IANA>. The 'GW Identity Type' field indicates the type of
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 - FQDN of the original VPN gateway 1 - IPv4 address of the original VPN gateway
2 - IPv4 address of the original VPN gateway 2 - IPv6 address of the original VPN gateway
3 - 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. Security Considerations 6. 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
 End of changes. 8 change blocks. 
18 lines changed or deleted 17 lines changed or added

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