Network Working Group V. Narayanan Internet-Draft L. Dondeti Intended status: Standards Track QUALCOMM, Inc. Expires: April 19, 2007 October 16, 2006 Protocols for IPsec Gateway or Server Redundancy draft-vidya-ipsec-failover-redundancy-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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Recovering from failure of IPsec gateways or servers maintaining large numbers of SAs may take several minutes, if they need to re- establish the IPsec SAs by re-running the key management protocol, IKEv2. This draft proposes IPsec and IKEv2 SA storage and retrieval mechanisms to improve the recovery time after an IPsec gateway or server failure. Narayanan & Dondeti Expires April 19, 2007 [Page 1] Internet-Draft IPsec Failover/Redundancy October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of IPsec Redundancy . . . . . . . . . . . . . . . . . 5 4.1. SA Storage and Retrieval . . . . . . . . . . . . . . . . . 5 4.1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Endpoint IP Address Updates . . . . . . . . . . . . . . . 7 4.3. Outbound Packet Processing . . . . . . . . . . . . . . . . 7 4.4. Inbound Packet Processing . . . . . . . . . . . . . . . . 7 5. IPsec Failover Details . . . . . . . . . . . . . . . . . . . . 8 5.1. Payloads for state storage . . . . . . . . . . . . . . . . 8 5.2. SA_Stor and SA_Retr Message Format . . . . . . . . . . . . 8 5.3. Storage and Retrieval Details . . . . . . . . . . . . . . 8 5.4. Extensions to MOBIKE and IP address updates . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Narayanan & Dondeti Expires April 19, 2007 [Page 2] Internet-Draft IPsec Failover/Redundancy October 2006 1. Introduction The IKEv2 protocol while more efficient and involves fewer round trips compared to its predecessor is quite computationally intensive, especially when entity authentication is by way of public-key based certificates. IKEv2 also needs 2-3 round trips when using PSKs or public keys for authentication and 4 or more roundtrips when EAP is used for client authentication. Thus, the process of setting up IPsec SAs is an expensive process, in terms of the number of messages exchanged between the initiator and responder. When an IPsec entity has a large number of SAs with various other endpoints, establishing all the SAs again upon a failure recovery condition takes a long time. Examples of entities that manage a large number of IPsec SAs include IPsec remote access gateways, and application servers that use IPsec for protection of signaling traffic. For efficient recovery from gateway or server failure, it might make sense to allow those entities to maintain copies of IPsec and IKEv2 state (SAD, SPD, and associated state) on other servers. Either the recovered IPsec entity or other entities in the server pool may retrieve the stored IPsec and IKEv2 state for faster recovery. There is a need for an interoperable means of performing SA uploads and retrieval so that such IPsec redundancy can be implemented in an interoperable fashion. 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 [1]. This document uses terminology defined in [2], [3], and [4]. In addition, this document uses the following terms: 3. Applicability There are at least two cases where fast recovery from failure of an IPsec entity as defined in this document is applicable. IPsec Gateways -- The first case is that of an IPsec remote access gateway managing tunnel mode SAs with clients. The gateway may be enforcing access control to an enterprise network; this is the typical remote access VPN use case. The gateway could also be enforcing service provider network access control. In that case, Narayanan & Dondeti Expires April 19, 2007 [Page 3] Internet-Draft IPsec Failover/Redundancy October 2006 clients typically use EAP over IKEv2 to establish an IPsec session with a network access gateway. In either IPsec Gateway use case, the IPsec traffic itself flows from the VPN clients or Initiators to the VPN gateway; the gateway decapsulates the IPsec packets and forwards the cleartext packets based on inner IP headers. In the reverse direction, the VPN gateway uses the security policy database (SPD) to lookup the relevant IPsec, encapsulates the packets and sends to the appropriate VPN client. IPsec Servers -- The second use is that of an IPsec entity acting as a server for an application such as Mobile IP or SIP. In these cases, mobile IP binding messages or SIP signaling messages are protected using IPsec. Each Mobile IP Home Agent (HA) or a SIP server maintains a large number of transport or tunnel mode IPsec sessions with their respective clients. In this case, IPsec protected signaling messages are sent end-to-end, between Mobile IP or SIP client and HA or SIP server, respectively. In the security gateway mode, while there may be multiple security gateways serving a number of remote endpoints, a given remote endpoint is typically served by one security gateway. For instance, an IPsec VPN client typically maintains one or more SAs for remote access with one VPN gateway. However, when the serving gateway fails, it is desirable for one of the other gateways to seamlessly take over and serve the clients affected by the failure. In some deployments, there may be a backup gateway that can take over for the primary in case of a failure. Such gateways may be running a VRRP- like protocol to actually share the gateway IP address as known to the clients. In other deployments, a cluster of gateways may load balance to serve a number of clients. In such a case, one or more of the gateways in the cluster may take over clients associated with another gateway in the cluster in the event of a failure. When IPsec is used for protection of signaling between an application client and server, server redundancy is often an important consideration. As in the gateway model, it is necessary for another server to be able to seamlessly take over clients being served by a failed server. In all these cases outlined above, it may be feasible to perform secure IPsec and IKEv2 state transfer across endpoints to provide smoother failure recovery. Today, such redundancy operations are performed in a vendor specific manner and are not interoperable. This document aims at defining a protocol for secure, interoperable IPsec redundancy operation. Narayanan & Dondeti Expires April 19, 2007 [Page 4] Internet-Draft IPsec Failover/Redundancy October 2006 4. Overview of IPsec Redundancy The proposed protocol for IPsec redundancy is composed of two parts. One part specifies SA storage and retrieval operation across IPsec entities. The other part specifies a means of updating any change of identities and IP addresses between IPsec endpoints. The latter is applicable only when the IP address of the backend entity changes due to a server/gateway switchover under failure conditions. 4.1. SA Storage and Retrieval This protocol is intended to serve as a standardized means of sharing (storing and retrieving) IPsec and IKEv2 state among backend entities. Backend entities here refer to IPsec gateways or servers that may be serving one or more remote IPsec endpoints. One model of the SA storage and retrieval across backend entities may be to use a highly available platform as a master SA storage entity that may contain the master SPD, SAD and IKEv2 SA entries. Such a master store would then be kept updated with the SA state. Another model may be for each backend entity to locally have a logical SA storage entity. These models are largely deployment specific and this document does not intend to get into details of either model. This document merely aims at specifying a protocol for storing and retrieving IPsec/IKEv2 state. In cases where IPsec is used for replay protection, replay window state needs to be updated very frequently, essentially every time a packet is received. The other option is to only replicate IKEv2 state precisely, and re-establish IPsec state using the CREATE_CHILD_SA exchange, in the event of a failure. Two messages are to be defined for the purposes of state storage and retrieval - SA_Stor and SA_Retr. As much as feasible, already defined payloads can be used to carry the parameters needed to be stored. A few new payloads are to be defined to accommodate storage of some required parameters that may not map to any of the existing payloads. These messages MUST be protected by an IPsec SA when exchanged between two different entities. These messages are carried over UDP port TBD. In such a model of state storage and retrieval across different entities for sake of redundancy, SPI collisions may occur. In accordance with [2], unicast SAs are indexed by the SPI alone, while multicast SAs are indexed by a combination of either the SPI and destination address (any source multicast) or the SPI, destination and source addresses (source specific multicast). In order to preserve the packet processing as specified by [2], this model of SAD indexing must be preserved. Hence, SPI management becomes a critical factor for IPsec redundancy. This can be resolved in different ways. Narayanan & Dondeti Expires April 19, 2007 [Page 5] Internet-Draft IPsec Failover/Redundancy October 2006 One option is to establish the IKEv2 and IPsec SAs with a master entity, which then distributes the SAs to other backend entities. Here, the SPI space is always managed by the master entity, thereby avoiding collisions. Another option is to partition the SPI space among the backend entities. This document acknowledges that the actual method of SPI management may be implementation dependent and does not mandate any particular method. The requirement, however, is that SPI collisions MUST NOT occur among the backend entities that belong to the redundancy cluster. The storage and retrieval of state must allow indexing by two mechanims. Bulk storage and retrieval of state corresponding to a given backend entity MUST be indexed using a Server ID. The Server ID used may be an IP address or FQDN of the server. Storage or retrieval of state corresponding to specific SAs MUST be indexed using SPIs. Storage or retrieval of state corresponding to an SPI MUST include the corresponding SPD entries and the IKEv2 SA. 4.1.1. Discussion How to index the stored SA state is an interesting question to think about. In the simplest case, clients send a request to the server and the server responds. This is a subset of the IPsec Server failover case described in Section 3. If the client's request is protected with IPsec, and an IPsec server failure occurred, the new server or the recovered server can lookup the IPsec/IKEv2 SA (Stored IPsec plus IKEv2 SA state and the SPD) corresponding to the SPI in the received IPsec protected packet. The open issue here is that of the client knowing the replacement server's address. In some applications, the address is available through out of band means. For instance, Mobile IP allows for a Home Agent (HA) Switch message to be sent to clients to force the client to move to a different HA. In that case, it is feasible for the client to send an IPsec protected packet to the new server before the server has acquired the corresponding SA. The general case of traffic originating from either side is somewhat harder to solve. One possibility is to assume that the SPD state is up to date and that the recovered gateway/server or the replacement gateway will fetch all the SPD state corresponding to the failed gateway, and the IKEv2 state and possibly the IPsec state as well. When a packet hits the gateway from the "protected" side, in the best case, the IPsec SA is available or in the worst case, the gateways initiates IKEv2 CREATE_CHILD_SA exchange to establish the IPsec SA(s). This requires fewer roundtrips compared to having to establish the IPsec SA(s) using a full IKEv2 (and possibly an IKEv2- EAP) exchange. Narayanan & Dondeti Expires April 19, 2007 [Page 6] Internet-Draft IPsec Failover/Redundancy October 2006 4.2. Endpoint IP Address Updates After recovering from failover, if the IP address of the serving backend entity is different from that of the previous backend entity, the IP address SHOULD be updated to the IPsec host endpoint. While this can be accomplished using MOBIKE [4], some extensions to MOBIKE are required in order to support this scenario. MOBIKE requires the initiator of the IKEv2 SA to always be the entity specifying the use of a particular IP address. In the case of a backend failover, the initiator may not be in the best position to detect it first. The initiator may only learn about the failover after detecting packet loss or lack of reachability of the initial IP address of the responder (for e.g., using liveness probes as described in [4]). This is often a slow process and does not aid in seamless and fast recovery after a gateway failure. Also, MOBIKE was only designed to allow for the use of multiple IP addresses of a multi-homed server/ gateway and hence requires all the IP addresses of the responder being known to the initiator at the time of IKEv2 SA creation. In the case of a responder failover, such an IP address may not have been available to the initiator earlier. Hence, for a failure recovery situation where a different backend entity takes over an SA, the IP address updates must always be triggered by the backend entity that took over for the failed entity. Further, such IP address updates must be applicable to transport mode SAs. In order to allow transport mode IP address updates, a MOBIKE update must be decoupled from tunnel outer IP address updates. The update simply updates the SA endpoint (and hence, the appropriate SPD entry to allow appropriate outbound SA application). Details on the IP address updates will be provided in future revisions of this document. 4.3. Outbound Packet Processing Outbound packet processing at the IPsec endpoints is the same as described in [2]. 4.4. Inbound Packet Processing Inbound packet processing at the initiator is the same as described in [2]. At the responder, when an inbound packet arrives, it may not have an SA corresponding to the SPI in the packet. Typically, if a matching SAD entry is not found, it will result in the packet being discarded. However, when backend server redundancy is used, it is feasible that the SA corresponding to the SPI has not yet been retrieved by the entity. Hence, in this case, the server MUST perform an SA_Retr upon receiving an inbound packet with an SPI that lacks a matching SAD entry. The details of such SA_Retr will be Narayanan & Dondeti Expires April 19, 2007 [Page 7] Internet-Draft IPsec Failover/Redundancy October 2006 described in future revisions of this document. If the SA_Retr is successful, the processing of the inbound packet must resume as described in [2]. If the SA_Retr fails, the packet MUST be discarded. 5. IPsec Failover Details 5.1. Payloads for state storage 5.2. SA_Stor and SA_Retr Message Format 5.3. Storage and Retrieval Details 5.4. Extensions to MOBIKE and IP address updates 6. Security Considerations There are several security considerations involved with the mechanisms proposed in this document. We highlight a few of the important ones below (a more thorough analysis will be provided in a future revision): o First, all SA storage and retrieval between the backend entities must be protected using IPsec ESP with non-NULL encryption. More specifically between the backend entities all storage and retrieval must happen via a secure channel that has the following properties: confidentiality, integrity protection, and replay protection. o In the client-server model, where the client always initiates the secure communication, it can do so by finding the new server address through external means. Subsequent MOBIKE signaling will allow the client to verify the server's address by verifying the proof of possession of the IKEv2 key material at the new server. Until then the client must consider the new server's address as a "provisional" address and specifically it must not update the IKEv2 server address until after the MOBIKE verification succeeds. o For replay protection, it is best for the replacement server to assume that the IPsec SA state is outdated and reestablish the IPsec SA using the CREATE_CHILD_SA exchange. (Perhaps this can be relaxed after a more in-depth analysis). Narayanan & Dondeti Expires April 19, 2007 [Page 8] Internet-Draft IPsec Failover/Redundancy October 2006 7. IANA Considerations IANA considerations will be provided in a future version of this document. 8. Acknowledgments 9. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. Authors' Addresses Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Narayanan & Dondeti Expires April 19, 2007 [Page 9] Internet-Draft IPsec Failover/Redundancy October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Narayanan & Dondeti Expires April 19, 2007 [Page 10]