Network Working Group L. Dondeti Internet-Draft V. Narayanan Intended status: Standards Track QUALCOMM, Inc. Expires: August 29, 2007 February 25, 2007 IPsec Gateway Failover and Redundancy Protocol draft-dondeti-ipsec-failover-sol-00 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IPsec gateways and servers maintaining SAs with large number of clients can quickly recover from failover using the protocols and procedures specified in this document. These techniques also facilitate IPsec clients to move from one gateway to another and resume operation without having to rerun IKEv2. The idea is to maintain IKEv2 and IPsec SA state at either the client or one or more backup servers to reduce the communication and computation overhead associated with reestablishing the SAs from scratch. Client to Dondeti & Narayanan Expires August 29, 2007 [Page 1] Internet-Draft IPsec Failover Redundancy Solution February 2007 server SA state storage retrieval mechanisms and client-initiated or server-initiated failover recovery protocols are specified. This document, however, does not define an inter-gateway transport mechanism to transfer the state across entities at the backend. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Recovering from a Remote Access Gateway Failover . . . . . 5 3.2. Recovering from an Application Server Failover . . . . . . 7 4. IKEv2 Session Resumption Protocol Details . . . . . . . . . . 8 4.1. Capability Negotiation and State Transfer . . . . . . . . 8 4.1.1. Extensions to the IKE_INIT_SA message . . . . . . . . 9 4.1.2. Extensions to the IKE_AUTH Exchange . . . . . . . . . 9 4.1.3. Capability Negotiation and State Transfer via an Informational Exchange . . . . . . . . . . . . . . . . 11 4.1.4. IKEv2 Ticket . . . . . . . . . . . . . . . . . . . . . 12 4.2. IKEv2 Session Resumption . . . . . . . . . . . . . . . . . 13 4.2.1. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 14 4.2.2. Replay Protection of Session Resumption Exchange . . . 15 4.2.3. Processing IKE_SESSION_RESUME messages . . . . . . . . 16 5. Message Types and Formats . . . . . . . . . . . . . . . . . . 18 5.1. IKEv2 Header with Gateway Switch Count . . . . . . . . . . 18 5.2. SESSION_RESUMPTION_SUPPORTED Notify Message Type . . . . . 19 5.3. Other Payload Specifications . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. Properties of the Secure Domain . . . . . . . . . . . . . 20 6.2. Properties of Capability Negotiation . . . . . . . . . . . 20 6.3. Properties of SA Ticket Creation, Distribution and Use . . 21 6.4. Properties of the Session Resumption Protocol . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Dondeti & Narayanan Expires August 29, 2007 [Page 2] Internet-Draft IPsec Failover Redundancy Solution February 2007 1. Introduction Recovering from failure of IPsec gateways or servers maintaining SAs with large numbers of clients may take several minutes, if they need to re-establish the IPsec SAs by re-running the key management protocol, IKEv2. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The computational and communication latency in running IKEv2 or IKEv2 with EAP for client authentication is significant, leading to a need for a faster and yet secure failover solution. The problem statement and goals for a failover solution are described in [1]. When an IPsec gateway fails or otherwise unreachable for a client, the situation may be temporary or long lasting. The client should be able to recover in either scenario. In other words, the client may go back to the original gateway or alternatively, it may go to another gateway to re-establish the session. The new gateway needs access to the IKEv2 SA that the client and the old gateway established with each other. The new gateway may acquire the SA from the old gateway or another infrastructure entity where the old gateway has stored the SA. The only other possibility for SA storage and retrieval is for the old gateway to store the SA at the client itself in the form of a "ticket." The client then presents the ticket to the new or the old gateway. To facilitate such SA storage and retrieval, the gateways must share security associations between themselves or with an infrastructure entity. For convenience we call gateways that share a security association with each other either directly or through another entity, as belonging to a secure domain. When the SA state is stored at the client, the infrastructure is "stateless" until the client restores the SA with one of the gateways within the secure domain; thus, we refer to SA resumption with SA storage at the client as stateless session resumption. When the infrastructure maintains SA state, we refer to the process as stateful session resumption. We identify three components to an efficient failover solution: In the first part, the client and the gateway negotiate failover support. More specifically, the client indicates supports for failover and any related capabilities. The gateway verifies its policy and may accept or reject support for failover for the client; if it accepts the request, it indicates its own capabilities in supporting the failover. The gateway may include a list of backup gateways in its response; when the gateway does not return a list of alternative gateways, the clients are expected to discover the backup gateways or servers through a mechanism external to IPsec key management. Capability Dondeti & Narayanan Expires August 29, 2007 [Page 3] Internet-Draft IPsec Failover Redundancy Solution February 2007 negotiation can be piggybacked on the IKE_AUTH exchange. The client indicates whether it supports failover in the IKE_AUTH request message via a notify payload; the gateway indicates whether it supports failover for that client and may send a list of other gateways in the secure domain, all via notify payloads in the IKE_AUTH response message. In the second part, the gateway creates a ticket and stores it in the infrastructure or supplies it to the client, if the client had indicated support for it and the gateway's policy allows storing state in the client for that particular client. The gateway may send the ticket via a notify payload included in the IKE_AUTH response message. The third part is session re-establishment itself: When a client discovers that it cannot reach a gateway or application server with which it has an IPsec SA, it attempts to reach another gateway within the same secure domain as the initial gateway. In other cases, the client may have gone dormant and could be resuming the session with the original gateway. For session re- establishment, we specify a new IKE exchange, IKE_SESSION_RESUME, which is quite similar to CREATE_CHILD_SA in many ways, but with some crucial differences also. In simple terms, processing IKE_SESSION_RESUME request is a cross between processing IKE_SA_INIT and CREATE_CHILD_SA. For the scope of this work, it is assumed that the gateways in the secure domain do not share the same IP address and may not share the same view of the network, i.e., they may be connected to different DHCP servers. Thus, the client may need to acquire a new IP address upon reestablishing an IKE session with a new gateway. It is assumed that in this case, the original IKEv2 exchange used the Configuration Payload to acquire configuration information. Note that it is plausible to run the capability negotiation and ticket request/response via a information exchange after the SA has been established. Another possibility is to piggyback the negotiation and ticket request/response on a CREATE_CHILD_SA exchange. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses terminology defined in [3], [4], and [5]. In addition, this document uses the following terms: Dondeti & Narayanan Expires August 29, 2007 [Page 4] Internet-Draft IPsec Failover Redundancy Solution February 2007 Secure domain: A secure domain comprises a set of gateways that are able to resume an IKEv2 session that may have been established any other gateway within the domain. All the gateways in the secure domain are expected to share a security association -- either with each other or through a trusted third party -- so they can verify the validity of the ticket and can extract the IKEv2 policy and session key material from the ticket. IKEv2 ticket: An IKEv2 ticket is a data structure that contains all the necessary information that allows any gateway within the same secure domain as the gateway that created the ticket to verify the validity of the ticket and extract IKEv2 policy and session keys to re-establish an IKEv2 session. Stateless failover: When the IKEv2 session state is stored at the client, the infrastructure is "stateless" until the client restores the SA with one of the gateways within the secure domain; thus, we refer to SA resumption with SA storage at the client as stateless session resumption. Stateful failover: When the infrastructure maintains IKEv2 session state, we refer to the process of IKEv2 SA re-establishment as stateful session resumption. 3. Usage Scenarios This specification envisions two usage scenarios for efficient IKEv2 and IPsec SA session re-establishment: The first is similar to the use case specified in Section 1.1.3 of the IKEv2 specification [4], where IPsec tunnel mode is to establish a secure channel between a remote access client and a gateway; the traffic flow may be between the client and entities beyond the gateway. The second use case is somewhat different from any of the use cases defined in the IKEv2 specification: at the IP layer, two endpoints use transport (or tunnel) mode to communicate between themselves. The two endpoints have a client-server relationship with respect to a protocol that runs using the protections afforded by the IPsec SA. 3.1. Recovering from a Remote Access Gateway Failover Dondeti & Narayanan Expires August 29, 2007 [Page 5] Internet-Draft IPsec Failover Redundancy Solution February 2007 (a) +-+-+-+-+-+ +-+-+-+-+-+ ! ! IKEv2/IKEv2-EAP ! ! Protected ! Remote !<------------------------>! Remote ! Subnet ! Access ! ! Access !<--- and/or ! Client !<------------------------>! Gateway ! Internet ! ! IPsec tunnel ! ! +-+-+-+-+-+ +-+-+-+-+-+ (b) +-+-+-+-+-+ +-+-+-+-+-+ ! ! IKE_SESSION_RESUME ! ! ! Remote !<------------------------>! New/Old ! ! Access ! ! Gateway ! ! Client !<------------------------>! ! ! ! IPsec tunnel ! ! +-+-+-+-+-+ +-+-+-+-+-+ Figure 1: Remote Access Gateway Failure In this scenario, an endhost (an entity with a host implementation of IPsec [3] ) establishes a tunnel mode IPsec SA with a gateway in a remote network using IKEv2. The endhost in this scenario is sometimes referred to as a remote access client. When the remote gateway fails, all the clients associated with the gateway either need to re-establish IKEv2 sessions with another gateway within the same secure domain of the original gateway, or with the original gateway if the server is back online soon. The clients may choose to establish IPsec SAs using a full IKEv2 exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). In this scenario, the client needs to get an IP address from the remote network so that traffic can be encapsulated by the remote access gateway before reaching the client. In the initial exchange, the gateway may acquire IP addresses from the address pool of a local DHCP server. The new gateway that a client gets associated may not receive addresses from the same address pool. Thus, the session resumption protocol needs to be able to support for new IP address assignment. Dondeti & Narayanan Expires August 29, 2007 [Page 6] Internet-Draft IPsec Failover Redundancy Solution February 2007 3.2. Recovering from an Application Server Failover (a) +-+-+-+-+-+ +-+-+-+-+-+ ! App. ! IKEv2/IKEv2-EAP ! App. ! ! Client !<------------------------>! Server ! ! & ! ! & ! ! IPsec !<------------------------>! IPsec ! ! host ! IPsec transport/ ! host ! +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ (b) +-+-+-+-+-+ +-+-+-+-+-+ ! App. ! IKE_SESSION_RESUME ! New ! ! Client !<------------------------>! Server ! ! & ! ! & ! ! IPsec !<------------------------>! IPsec ! ! host ! IPsec transport/ ! host ! +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ Figure 2: Application Server Failover The second usage scenario is as follows: two entities with IPsec host implementations establish an IPsec transport or tunnel mode SA between themselves; this is similar to the model described in Section 1.1.2. of [4]. At the application level, one of the entities is always the client and the other is a server. From that view point, the IKEv2 exchange is always initiated by the client. This allows the Initiator (the client) to authenticate itself using EAP, as long as the Responder (or the application server) allows it. If the application server fails, the client may find other servers within the same secure domain for service continuity. It may use a full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- establish the IPsec SAs for secure communication required by the application layer signaling. The client-server relationship at the application layer ensures that one of the entities in this usage scenario is unambiguously always the Initiator and the other the Responder. This role determination also allows the Initiator to request an address in the Responder's network using the Configuration Payload mechanism of the IKEv2 protocol. If the client has thus received an address during the Dondeti & Narayanan Expires August 29, 2007 [Page 7] Internet-Draft IPsec Failover Redundancy Solution February 2007 initial IKEv2 exchange, when it associates with a new server upon failure of the original server, it needs to request an address, specifying its assigned address. The server may allow the client to use the original address or if it is not permitted to use that address, assigns a new address. 4. IKEv2 Session Resumption Protocol Details The IKEv2 session resumption protocol specified in this document has three components: capability negotiation, state transfer, and session resumption. Capability negotiation and state transfer are extensions to the IKEv2 base exchange. IKE_SESSION_RESUME exchange is new; it is modelled after the CREATE_CHILD_SA, but looks slightly different in transit and has different processing semantics. It does share a majority of the structure, format and processing semantics of the CREATE_CHILD_SA exchange, but also has some fundamental differences. 4.1. Capability Negotiation and State Transfer IKEv2 session resumption capabilities -- whether the client and server support session resumption, whether the client needs the gateway list and whether the client can store state-- are negotiated via notify payloads. The Initiator uses a notify payload to indicate what it supports and what it needs: for session resumption, the client MUST send a notify payload of type SESSION_RESUMPTION_SUPPORTED. The notification data filed of this type of notify payload defines two flags: the Initiator may indicate support for client side state storage (in other words, request an IKEv2 ticket) setting the flag CLIENT_SIDE_STORAGE_SUPPORTED and may request the list of backup gateways from the Responder, by setting the flag CLIENT_REQUEST_GW_LIST. The Responder processes the notify payload and if it supports session resumption for the client in question, then it returns a notify payload of type SESSION_RESUMPTION_SUPPORTED. In addition, if the Initiator request a list of gateways, the Responder SHOULD send a notify payload of type ALT_GW_LIST, with a list of gateway addresses belonging to the same secure domain. Finally, if the Responder supports client side state storage, it sends a ticket via a notify payload of type IKEv2_TICKET. Capability negotiation can be piggybacked on the IKE_SA_INIT, the IKE_AUTH or an Informational exchange after the base exchange is complete. Session state transfer cannot occur until mutual authentication and IKE SA establishment is complete. Thus, session state transfer can be piggybacked on the IKE_AUTH exchange or an Informational exchange after the base exchange is complete. Dondeti & Narayanan Expires August 29, 2007 [Page 8] Internet-Draft IPsec Failover Redundancy Solution February 2007 4.1.1. Extensions to the IKE_INIT_SA message The initiator indicates support for session resumption by including the Notify payload of type SESSION_RESUMPTION_SUPPORTED in the IKE_INIT_SA request message. If the responder does not support such a capability, it MUST ignore the session resumption notify payload. A responder that supports failover and is willing to offer that support to the client MUST return a notify payload of type SESSION_RESUMPTION_SUPPORTED in the IKE_INIT_SA response message. If the Initiator sets the flag CLIENT_REQUEST_GW_LIST, the responder typically returns a list of gateways in a separate notify payload, of type ALT_GW_LIST. Implementations support session transfer MAY support extensions to the IKE_INIT_SA messages. If the responder does not respond to capability negotiation during the IKE_INIT_SA exchange, the initiator may choose to try again during the IKE_AUTH exchange. The capability negotiation is authenticated as part of the mutual authentication processes during the IKE_AUTH exchange. If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the Responder may send the state via a notify payload of type IKEv2_TICKET as part of the subsequent IKE_AUTH exchange. See Section 4.1.2 for additional details. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, N(SESSION_RESUMPTION_SUPPORTED) --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], N(SESSION_RESUMPTION_SUPPORTED) Figure 3: Piggybacking over IKE_INIT_SA messages 4.1.2. Extensions to the IKE_AUTH Exchange Capability negotiation and the state transfer can together be piggybacked on the IKE_AUTH exchange, in the 4-message version or the version where EAP is used for client authentication. The ticket can in fact be sent in the clear -- more on that later -- but it is simpler to include it within the SK payload of the IKE_AUTH message and that allows us to make minimal modifications to the IKE_AUTH message processing semantics. Dondeti & Narayanan Expires August 29, 2007 [Page 9] Internet-Draft IPsec Failover Redundancy Solution February 2007 If the Initiator supports ticket storage, it is RECOMMENDED that the IKE_AUTH exchange be used for capability negotiation and state transfer. The capability negotiation and state transfer semantics are as specified in Section Section 4.1.1. The exchange is protected by the MAC in the IKE_AUTH exchange. Note that when the capability exchange is piggybacked on the IKE_SA_INIT exchange the protection afforded to the negotiation is the same as that afforded to the IKE SA parameter negotiation and when it is piggybacked on the IKE_AUTH exchange, the protections afforded are the same as that to the Child SA parameter negotiation. Initiator Responder ----------- ----------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, [N(SESSION_RESUMPTION_SUPPORTED)]} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi TSr, [N(SESSION_RESUMPTION_SUPPORTED), N(IKEv2_TICKET)]} Figure 4: Piggybacking over the IKE_AUTH Exchange Dondeti & Narayanan Expires August 29, 2007 [Page 10] Internet-Draft IPsec Failover Redundancy Solution February 2007 Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr [N(SESSION_RESUMPTION_SUPPORTED)]} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr [N(SESSION_RESUMPTION_SUPPORTED), N(IKEv2_TICKET)]} Figure 5: Piggyback over IKE_AUTH with EAP for Client Authentication If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the Responder MAY send the state via a notify payload of type IKEv2_TICKET in the IKE_AUTH response message. In case of IKEv2-EAP exchange the request for session resumption support is indicated in the first message of the IKE_AUTH sequence of messages from the initiator and the response is included in the last message from the responder. The client is expected the store the ticket and present it to the gateway with which it is resuming the session. The IKE_SESSION_RESUME exchange is used for that purpose. The Ticket is included as part of a Notify message and can be opaque or conformant to the format specified in this document. 4.1.3. Capability Negotiation and State Transfer via an Informational Exchange An initiator may choose to wait until the IKEv2 and IPsec SA establishment is complete before negotiating the IKEv2 session transfer support. The initiator then uses an informational exchange to indicate support for session resumption and the responder can Dondeti & Narayanan Expires August 29, 2007 [Page 11] Internet-Draft IPsec Failover Redundancy Solution February 2007 agree to support the capability and may send the ticket in response, as applicable. The negotiation is protected as the Notify payloads are within the SK payload of IKEv2. Initiator Responder ----------- ----------- HDR, SK { N(SESSION_RESUMPTION_SUPPORTED), [N(SPI)]} --> <-- HDR, SK {N(SESSION_RESUMPTION_SUPPORTED), [N(IKEv2_TICKET)]} Figure 6: Informational Exchange for Session Resumption Negotiation 4.1.4. IKEv2 Ticket To enable clients to present the IKEv2 ticket received from one gateway to another, the contents of the ticket need to specified. The ticket structure may be used by a gateway to send state to the client or to another gateway or SA store. In the event of backend storage of state, the SA store may be present in a highly available centralized entity or distributed across the backup gateways. This document does not provide a protocol to upload or download state to/ from the SA store. However, such an exchange MUST be encrypted, authenticated and replay protected. In the simplest IKEv2 session, there is an IKE SA and a single IPsec SA. The IKEv2 ticket may have been sent by the gateway during the base exchange or via an Informational exchange. If either the IPsec SA or the IKE SA is rekeyed, the gateway sends the new ticket to the client. The ticket is then associated with the IPsec SA in that when an SA is deleted, the corresponding ticket is also expected to be deleted, even if the ticket has not expired. The ticket contains all the necessary information for a gateway to restore the IKE SA; more specifically, it contains the negotiated IKE SA parameters and the corresponding attributes where applicable. There is also a lifetime to the ticket, which takes the form of a timestamp after which the ticket is no longer valid. The ticket itself is protected -- encrypted and integrity protected -- with a security association created specifically for generating and validating tickets within a given secure domain. The ticket generation SA (TGS) is identified with the TGS-SPI and that is included in the clear with the ticket. The TGS-SPI allows the new gateway to identify the SA to use in validating the ticket. The TGS- SPI is a blob that only the entities within a secure domain need to Dondeti & Narayanan Expires August 29, 2007 [Page 12] Internet-Draft IPsec Failover Redundancy Solution February 2007 understand; for instance, if the gateways within a secure domain form a multicast group and use a group IPsec SA, the SPI may contain the destination address (group's multicast address) and a 32-bit random value. The ticket may also contain the identity of the gateway/ domain issuing it. When multiple IPsec SAs are created, the gateway MAY send a new ticket in each CREATE_CHILD_SA response message. It is not clear whether the fields within the ticket, other than the lifetime of the ticket will be different. The ticket may contain IPsec specific information such as the tunnel inner address (TIA) assigned by the gateway. In that case, each ticket is different. Whether there is a need to include the TIA in the ticket is for discussion. 4.2. IKEv2 Session Resumption When a client discovers that the gateway it is associated with is unreachable, according to the IKEv2 specification the client needs to verify the liveness of the gateway through IKEv2. If the client determines that the gateway is unreachable, it is to delete the IKE SA and all associated CHILD SAs. This specification modifies that behavior. If session resumption capability has been negotiated for the IKE SA, the client MAY reestablish the session with a backup gateway instead of deleting it. The client needs to first find an alternative gateway: we refer to this step as gateway discovery. There are a few possible ways of gateway discovery: Preconfiguration: The client may have been pre-configured with a list of backup gateways. In other words, the client learns of the backup gateways just as it does the address of the original gateway. Discovery through IKEv2: First, the client may have requested and received a list of gateways during the capability negotiation phase. In this case, the list of gateways is provided by the original gateway and the discovery has the protection of an IKEv2 exchange. Discovery through application: The client may discover that a gateway has failed and a new gateway must be used for connectivity through application layer messages. An example of this is the Mobile IPv6 Home Agent (HA) discovery, where the client may discover the HA via MIP6 bootstrapping mechanisms. The IKEv2 specification has details on expected behavior on receiving Dondeti & Narayanan Expires August 29, 2007 [Page 13] Internet-Draft IPsec Failover Redundancy Solution February 2007 unauthenticated information about gateway unreachability. Those rules still apply in this case, in that the client should verify the non-reachability before initiating a switch to the new gateway. 4.2.1. IKE_SESSION_RESUME Exchange Subsequent to discovering gateway failure and alternative gateways to contact, a client may choose to run a full IKEv2 exchange to establish a new IKEv2 session or to resume the use of the previously established SA at the new gateway. There are two cases to consider: in the first, the client has received an IKEv2_ticket from the original gateway and presents that to the new gateway. In the second case, the client has no ticket to present and therefore simply attempts to reestablish the session with the new gateway. Note that it is impractical for all the gateways to be in synchrony with each other on all the replay protection state at each entity. Thus we need a special IKE SA created for session reestablishment and use that in the IKEv2 ticket or we need to tweak the IKEv2 replay protection mechanism as the client moves between gateways. Next, the new gateway may not be able to support the same tunnel inner address as the original gateway. Finally, for stateless failover, the new gateway will need to supply the next IKEv2_ticket to the client. Thus, the session resumption exchange comprises an IPsec SA establishment, optional IKEv2 SA rekeying, optional IP address assignment, and optional ticket delivery from the gateway to the client. For the purposes of this specification, we assume that the client always initiates SA reestablishment. We consider the case of gateway initiating SA recovery out of scope of the specification. We specify a new IKEv2 exchange type called IKE_SESSION_RESUME of type IANA-TBA. Initiator Responder ----------- ----------- HDR, [N(IKEv2_Ticket)], [N,] SK { SA, Ni, [KEi], [TSi, TSr], [CP(CFG_Request)], [N(UPDATE_SA_ADDRESSES)]} --> <-- HDR, SK {SA, Nr, [KEr], [TSi, TSr], [CP(CFG_REPLY)], [N(IKEv2_Ticket)]} Figure 7: IKE_SESSION_RESUME Exchange The HDR contains the Initiator's SPI as a random number of 8 octets Dondeti & Narayanan Expires August 29, 2007 [Page 14] Internet-Draft IPsec Failover Redundancy Solution February 2007 chosen by the Initiator. The Responder's SPI is set to zero. The new gateway will pick the SPI and include it in the return message. The exchange type is set to 'IKE_SESSION_RESUME'. We use a message ID of structure Gateway_Switch_Count (GSC) || message_ID, where Gateway_Switch_Count indicates the number of gateways the client has switched with the given IKE SA and message_ID is zero (or a suitable default value). In case of stateless failover, the client MUST include the IKEv2_Ticket payload. For stateful failover, the client MUST include a Notify payload with the original IKEv2 SPI pair so that the new gateway can look up the SA and verify the validity of the IKE_SESSION_RESUME message. Only one of these payloads MUST be present. Note that the IKEv2_Ticket payload and the Notify payload containing the SPI values are included after the header, but, outside the encrypted data. This allows for integrity protection of these payloads and not encryption. The Responder must be able to read these payloads before it can decrypt the SK payload in the IKE_SESSION_RESUME message. If the client is contacting the same gateway to resume the IKE session, it may not require a new IP address or any configuration parameters. For the purpose of this document, gateways that have the same view of the backend and are capable of supporting the same IP address for the clients are viewed as being a single gateway. If the client does not know whether the new gateway can assign the same tunnel inner IP address and then it MUST include the CFG_Request Configuration Payload, indicating the need for an IP address. It MAY include the original tunnel inner address in the request. For tunnel mode IPsec, this is the tunnel inner address of the client. If the local address of the client (tunnel outer address in tunnel mode) has also changed in the meantime, the client MUST include the UPDATE_SA_ADDRESSES notify payload defined in [5] in the session reestablishment Request message. 4.2.2. Replay Protection of Session Resumption Exchange IKEv2, as defined in [4] provides replay protection between the initiator and the responder using sequence numbers. Each entity maintains its own sequence number space and the sequence number is incremented after transmission of a request message. When one of the entities involved in the IKEv2 exchange may change within the same IKE session, replay protection will require per packet update of state to continue to use the same model of sequence numbers specified in [4]. Per packet state updates are impractical and also do not always work. It is plausible for the SA endpoints to fall out of sync or fail before an update is done, effectively opening up the possibility of replays. Dondeti & Narayanan Expires August 29, 2007 [Page 15] Internet-Draft IPsec Failover Redundancy Solution February 2007 In order to provide replay protection even when one of the entities is changing mid-session, this document proposes a structure to the message ID field of the IKEv2 header. The message ID field is composed as GSC||s_message_ID, where the GSC is a 4-bit value and the s_message_ID is a 28-bit value; the s_message_ID has the same semantics as the IKEv2 message ID except for the smaller size. The s_message_ID starts at zero (or a suitable constant) every time the client switches to a new gateway. The initiator and the responder initialize the GSC to zero at the time of establishment of the IKE SA. In case of stateless failover, the responder includes the GSC in the IKEv2_Ticket. The initiator increments the GSC and uses GSC||s_message_ID as the IKEv2 message_ID in theIKE_SESSION_RESUME exchange. The responder uses the same message ID in the response. When a failover or switch to another gateway occurs, this count is incremented. Note that the GSC is incremented even if the client has visited the "new" gateway in the past under the protection of the same IKE SA. Continuing with the case of stateless failover, the responder includes the new GSC in the new ticket and includes the new ticket along with the IKE_SESSION_RESUME response message. If the initiator never receives the response, it may use the same GSC in a future IKE_SESSION_RESUME exchange with the same or a different gateway. In case of stateful failover, the responder maintains the GSC value independent of the initiator and thus the initiator must increment the GSC for use with every fresh IKE_SESSION_RESUME request message. Note that the responder increments its local value of the GSC as soon as it responds with an IKE_SESSION_RESUME response message and updates the SA state of the client with the new GSC value. A new gateway MUST only accept an IKE_SESSION_RESUME request message, if the GSC value in the message ID is greater than the GSC value present as part of the state. The presence of the GSC provides replay protection across gateways without per packet state updates. The IKE_SA MUST be re-keyed before the GSC overflows. The IKE_SA MUST also be re-keyed before the 28- bit sequence number overflows, as required by [4]. This re-keying, however, may be done off the critical path, instead of at the time of failover. 4.2.3. Processing IKE_SESSION_RESUME messages IKE_SESSION_RESUME messages are treated much like IKE_SA_INIT messages in that the first step in processing them is not looking up the SA. In case of IKE_SA_INIT, the responder processes the entire message and sends a response either by challenging the initiator to prove liveness or by sending the IKE_SA_INIT response message. In Dondeti & Narayanan Expires August 29, 2007 [Page 16] Internet-Draft IPsec Failover Redundancy Solution February 2007 case of IKE_SESSION_RESUME message case, the first step is to process the message partially, provisionally revive the old SA to verify the session resumption request and process the rest of the message; the result of the processing, assuming everything is in order, is to install an IKE SA and one or more IPsec SAs at both ends. The responder follows the steps below in processing an IKE_SESSION_RESUME request message: o When an IKEv2 entity receives a message of exchange type 'IKE_SESSION_RESUME' it first verifies the consistency of the message. The Initiator's SPI must be non-NULL; the Responder's SPI can be ignored. The GSC must be greater than 1. The message must have either an N payload or the IKEv2_Ticket payload followed by an SK payload. o The next step is to recover the SA to be reestablished. If the received message contains an IKEv2_Ticket payload, the receiver validates the ticket. It uses the TGS-SPI of the ticket to lookup the SA that protects the ticket. It then verifies the integrity of the ticket. It then verifies that the ticket is fresh and not invalidated by policy. The next step is to verify whether the received session resumption request itself is fresh: the received GSC must be greater than the GSC within the ticket. o If the received message contains a Notify payload, the SPIs within the payload are used to lookup the SA that protects the received session resumption request message. The responder retrieves the SA from the SA store. It then verifies that the received GSC is greater than the local GSC. o After replay verification, the next step is to verify the integrity of the session resumption request message itself. If the integrity checksum is valid, the purported sender of the message in fact has access to the IKE SA corresponding to the SPI in the N payload or the IKE SA contained in the IKEv2_Ticket. o The responder then proceeds to process the rest of the IKE_SESSION_RESUME just as it would process a CREATE_CHILD_SA request message. It first decrypts the SK payload. The first encrypted payload is not an N payload (if it is, the responder returns an error message to the initiator) and so the message is treated as a request to create a new IPsec SA. o In response to a session resumption request message, the responder sends a message that is quite similar to a CREATE_CHILD_SA response Dondeti & Narayanan Expires August 29, 2007 [Page 17] Internet-Draft IPsec Failover Redundancy Solution February 2007 message. There are some subtle differences between the CREATE_CHILD_SA response and an IKE_SESSION_RESUME response message. The IKE_SESSION_RESUME response message is composed as follows: the responder picks an SPI and includes it in the Responder's SPI field of the IKEv2 header. The message ID is the same as the message ID in the request message. In case of stateless failover the responder creates a new IKEv2_ticket and includes the current GSC in the ticket. The new ticket is included within the SK as one of the encrypted payloads. Encryption of the new ticket prevents an attacker from attempting to present the ticket to another gateway before the client has had a chance to use it. 5. Message Types and Formats 5.1. IKEv2 Header with Gateway Switch Count 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Initiator's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Responder's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !GSC| S-Message ID (28 bits) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IKEv2 Header with GSC GSC - This 4-bit field indicates the Gateway Switch Count. It is initialized to zero when the IKE_SA is created and incremented by one every time a CREATE_CHILD_SA failover request message is sent by an IKE peer. S-Message ID - This is a 28-bit field that has the same semantics as the message ID field of the IKEv2 header. Dondeti & Narayanan Expires August 29, 2007 [Page 18] Internet-Draft IPsec Failover Redundancy Solution February 2007 5.2. SESSION_RESUMPTION_SUPPORTED Notify Message Type The SESSION_RESUMPTION_SUPPORTED Notify message type may be present in a Notify payload and indicates the support for failover at an IKE peer. The Notify Message Type value is IANA-TBD. The Notification Data contains an 8 bit flags field, the format of which is defined below. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|L| Reserved | +-+-+-+-+-+-+-+-+ Figure 9: SESSION_RESUMPTION_SUPPORTED Notification Data The S (CLIENT_SIDE_STORAGE_SUPPORTED) flag is set by the IKE peer to indicate support for stateless failover operation. The gateway MUST NOT set this flag if it does not also include a STATE_TICKET Notify payload in the response message. [***NOTE: Are we allowing not supporting the GSC? If so, we need to include the GW ID in the exchange and also defined how it is used in the IDr payload] The L(CLIENT_REQUEST_GW_LIST) flag is set by the IKE peer to indicate a message that requests or contains the list of gateways. 5.3. Other Payload Specifications TBD. 6. Security Considerations IKEv2 establishes an IKE SA and an IPsec SA in a 4 (or 6 message) base exchange. The number of messages can be larger than that if EAP is used for client authentication. The goal of this document is to specify a fast session resumption protocol. The session resumption protocol enables an IPsec client to quickly resume the use of the IKE SA and establish a new IPsec SA with the original gateway (after it fails and recovers) or another gateway within a secure domain. If the new gateway is in perfect synchrony with the old gateway, the only thing that changes is the IP address of one of the parties to the IKE exchange. A protocol similar to MOBIKE may be used to signal the change in the IP address of one of the end points of the session. Perfect synchronization is impractical and thus there is a need to Dondeti & Narayanan Expires August 29, 2007 [Page 19] Internet-Draft IPsec Failover Redundancy Solution February 2007 design an IKEv2 session resumption protocol. It is plausible that the new gateway obtains the SA state from within the secure domain, either from the old gateway or from another entity to which the old gateway has sent the SA state. It is also plausible for the old gateway to send the state to the client itself so it can present the state to the new gateway. There are several components to the solution: we need to define a secure domain, identify the security properties required for session resumption capability negotiation, identify the security properties required for SA storage or ticket creation, distribution and use, and finally identify the requirements of a session resumption protocol. Replay protection for the IKE SA as it is used across gateways is a crucial component of the ticket use and session resumption protocol. 6.1. Properties of the Secure Domain A secure domain consists of a pool of gateways that are able to resume SAs created by any gateway belonging to the same domain. It is not necessary for any two gateways to share the same IP address or have the same view of the network. All the gateways in the secure domain must share a security association for state storage and retrieval purposes. Such a security association must provide confidentiality, integrity and replay protection for the state stored or retrieved. The gateways may share a group SA or each gateway in the secure domain may share an individual SA with a central entity. In the case of stateful session resumption, the central entity may act as the SA store. In the case of stateless session resumption, such a central SA manager will imply that the tickets are protected with an SA known only to the central entity and each gateway needs to contact the central entity to encrypt or decrypt the contents of the tickets. 6.2. Properties of Capability Negotiation The failover solution described here relies on a capability exchange occurring as part of the initial IKEv2 exchange. The capability for failover support may be indicated by the initiator as part of the IKE_INIT or IKE_AUTH exchange and the failover support and any corresponding information (such as list of gateways or state) is included by the gateway as part of the IKE_AUTH exchange. The capability negotiation is authenticated as part of the mutual authentication processes during the IKE_AUTH exchange or is integrity protected by the MAC in the SK payload. Further, if the responder includes a ticket containing the session Dondeti & Narayanan Expires August 29, 2007 [Page 20] Internet-Draft IPsec Failover Redundancy Solution February 2007 state, that ticket is encrypted and integrity protected in a self- contained manner. This is so that upon session resumption, the gateway can verify the validity of the ticket. The SA used to encrypt and integrity protect the ticket depends on the type of SAs used in the secure domain, as described in Section 6.1. 6.3. Properties of SA Ticket Creation, Distribution and Use For the purpose of stateless session resumption, the gateway may distribute a ticket containing the SA state to the client. Any gateway in the secure domain may then allow the client to resume the IKE session upon successful processing of the ticket and installation of the SA. There are some security properties to consider in such ticket creation and distribution. The ticket must contain information that will allow the gateway resuming the session to determine the validity of the ticket based on the lifetime policies of the secure domain. The ticket itself may also contain information necessary to determine its lifetime that is allowed by the issuing gateway. This will prevent a ticket from being indefinitely used. All the contents of the ticket, except the SPI that indicates the SA to be used, must be encrypted and a MAC must be generated on the encrypted data. This prevents an eavesdropper from obtaining the contents of the ticket. In addition to the confidentiality of the ticket contents itself, ticket revocation is an issue that cannot be easily addressed without some gateway side state. If a ticket needs to be revoked and the client needs to be denied access, the gateways in the secure domain must contain some state or must be able to obtain the necessary information from a trusted source elsewhere. This will allow the infrastructure to reject resumption of a session after a client has been revoked access. Every time the SA state is updated or the client attaches to a new gateway, it receives a new ticket which is supposed to be used for subsequent session resumption. However, there is no way the gateways in the secure domain can ensure that the client always presents the latest ticket, unless some state on the ticket itself is maintained in the secure domain. While such state will be significantly less than storing the entire SA, that still somewhat negates the goal of remaining stateless. Hence, if the infrastructure is completely stateless on the tickets, it is feasible for the client to re-use old tickets. For the client itself, there is typically no incentive in using an older ticket, as Dondeti & Narayanan Expires August 29, 2007 [Page 21] Internet-Draft IPsec Failover Redundancy Solution February 2007 opposed to a newer one and hence, it is less of a problem. However, the possibility of ticket re-use leads to possible message replays. An attacker would be able to capture an IKE_SESSION_RESUME request message and replay it at a later time. Since the ticket contains an older value of the Gateway Switch Count (GSC), the message will be accepted by the gateway, as long as the lifetime of the ticket is still valid. While this would result in the IKE SA being installed on the gateway, it will result in a new IPsec SA being created, which will not be available to the attacker. Hence, replay of IPsec packets is not feasible in this case. Hence, the worst impact of message replays with old tickets is the installation of the IKE_SA at the gateway and creation of a new IPsec SA. It should be noted that if that gateway happens to be still serving the client to which the ticket actually belongs, it will most likely lead to re-installation of the same IKE SA or rejection of the replayed IKE_SESSION_RESUME since a different IKE SA for the same client is already present. Hence, ticket re-use is not a serious problem, although it could result in consumption of unnecessary resources at the gateway. If an attacker replayed a message with a ticket and successfully created state at the gateway and the client attempted to re-connect to that gateway, its request may be rejected by the gateway. Hence, depending on the timing of the replay, it is feasible to cause a DoS attack on the legitimate client. 6.4. Properties of the Session Resumption Protocol This document defines an IKE_SESSION_RESUME exchange to allow resumption of an already established IKE SA. The security properties of this exchange are largely similar to that of the IKE_CREATE_CHILD_SA exchange. The only difference is that before the creation of the IPsec SA, the recipient processing session resume request message first needs to provisionally install the IKE SA corresponding to the request. This IKE SA may be retrieved from the SA store or from the ticket presented by the client. The gateway must first install this SA and verify the validity of the IKE_SESSION_RESUME Request message. If the session resume request message is valid, the installed SA is kept; otherwise it is deleted and any related state updates are rolled back. When the validity check succeeds, the processing of the rest of the message and creation of the IPsec SA is analogous to processing an IKE_CREATE_CHILD_SA message. 7. IANA Considerations This document specifies a new IKEv2 exchange type and several notify payload types. Detailed instructions to IANA will be provided when Dondeti & Narayanan Expires August 29, 2007 [Page 22] Internet-Draft IPsec Failover Redundancy Solution February 2007 the protocol specification becomes more stable. 8. Acknowledgments Thanks to Paul Hoffman for his valuable input to discussions on the design of this protocol. 9. Normative References [1] Narayanan, V., "IPsec Gateway Failover and Redundancy - Problem Statement and Goals", draft-vidya-ipsec-failover-ps-00 (work in progress), December 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [5] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. Authors' Addresses Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Dondeti & Narayanan Expires August 29, 2007 [Page 23] Internet-Draft IPsec Failover Redundancy Solution February 2007 Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Dondeti & Narayanan Expires August 29, 2007 [Page 24] Internet-Draft IPsec Failover Redundancy Solution February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dondeti & Narayanan Expires August 29, 2007 [Page 25]