Network Working Group V. Narayanan, Ed. Internet-Draft Qualcomm, Inc. Intended status: Informational February 27, 2007 Expires: August 31, 2007 IPsec Gateway Failover and Redundancy - Problem Statement and Goals draft-vidya-ipsec-failover-ps-01 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 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Recovering from failure of IPsec gateways 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. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The latency involved in this approach is significant, leading to a need for a faster and yet secure failover solution. This document describes the problem statement and the goals for an IPsec/IKEv2 gateway failover/ Narayanan Expires August 31, 2007 [Page 1]
Internet-Draft IPsec Failover/Redundancy PS February 2007 redundancy solution. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability and Problem Statement . . . . . . . . . . . . . 4 5. IPsec Failover Redundancy Solution Goals . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Narayanan Expires August 31, 2007 [Page 2]
Internet-Draft IPsec Failover/Redundancy PS February 2007 1. Contributors This document reflects contributions from and active discussions among the following individuals (in alphabetical order): Lakshminath Dondeti (ldondeti@qualcomm.com) Paul Hoffman (paul.hoffman@vpnc.org) Tero Kivinen (kivinen@iki.fi) Gregory Lebovitz (gregory.ietf@gmail.com) Marcus Leech (mleech@nortel.com) Cheryl Madson (cmadson@cisco.com) Michael Richardson (mcr@sandelman.ottawa.on.ca) Sheela Rowles (srowles@cisco.com) Yaron Sheffer (yaronf@checkpoint.com) Marcus Stenberg (mstenber@cisco.com) Brian Weis (bew@cisco.com) 2. 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 roundtrips 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 gateways (for stateful operation) or on the client itself (for stateless Narayanan Expires August 31, 2007 [Page 3]
Internet-Draft IPsec Failover/Redundancy PS February 2007 operation). Either the recovered IPsec entity or other entities in the gateway pool may retrieve the stored IPsec and IKEv2 state for faster recovery. There are a number of proprietary solutions for this problem in the industry, however, those solutions do not interoperate. Applications that need IPsec failover capability, such as Mobile IPv6 have solutions under development for interoperable Home Agent (HA) failover. Without interoperable (client to server and server to server) IPsec failover capability HA failover solutions are incomplete. Thus, 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. 3. 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: 4. Applicability and Problem Statement There are at least two cases where fast recovery from failure of an IPsec entity 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 use case. The gateway could also be enforcing service provider network access control. In that case, 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) or associated caches as per RFC4301, to lookup the relevant IPsec, encapsulates the packets and sends to the appropriate VPN client. Narayanan Expires August 31, 2007 [Page 4]
Internet-Draft IPsec Failover/Redundancy PS February 2007 Servers -- The second use is that of an IPsec entity acting as a server for an application such as Mobile IP. In these cases, Mobile IP messages are protected using IPsec. Each Mobile IP Home Agent (HA) 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 client and HA, respectively. In the security gateway mode, while there may be multiple security gateways serving a number of remote endpoints, a given remote endpoint is 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 addition to server failures, massive network failures of a short duration (minutes), followed by network recovery are also a concern. The network failure results in all clients being disconnected first (e.g. because of dead-peer detection), and then simultaneously attempting to reconnect. This can be classified as a subset of the gateway failure case for the purpose of this effort. In all these cases outlined above, it is 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. Also, lack of client involvement implies a failover mode that is transparent to the client. However, in the above cases, the failover cannot always be transparent to the client and hence, an interoperable protocol becomes very important. Narayanan Expires August 31, 2007 [Page 5]
Internet-Draft IPsec Failover/Redundancy PS February 2007 5. IPsec Failover Redundancy Solution Goals The following are goals for the IPsec Failover Redundancy solution. Note that the motivation for this effort is to develop mechanisms and perhaps protocols to facilitate failover capabilities. It is plausible that the design facilitates features such as load balancing, but additional signaling or protocol design to facilitate load balancing exclusively is outside the scope of this effort. o Distributed Failover Mechanism: Gateways may be located at different sites and may not share the same IP address or have the same view of the network. For instance, the various distributed gateways may be connected to different backend elements such as EAP servers, DHCP servers, etc. A failover mechanism must be able to allow such distributed gateways to take over the clients associated with a failed gateway. The idea here is that there is no need for a fully redundant gateway that only starts functioning in the event of a failure. It is more cost-effective to allow such failover to distributed gateways that may be functional on their own, serving other clients. The temporary increase in load on some gateways in the system may be acceptable to many deployments in the event of a failure. Such a mechanism across distributed gateways may also be used for client handoff to other gateways due to other reasons, e.g., load balancing. Gateways located on the same link with the same view of the network may be viewed as a subset. o Client Involvement: Given that the gateways may be distributed, the failover is not intended to be transparent to the client. The goal is to allow the client to initiate the switch to a different gateway. o Low Latency failover: One of the major goals is to allow a low latency failover, without having to re-establish all the IKEv2 and IPsec state all over again. The bottleneck here is the new IPsec gateway trying to handle a flood of IKEv2 exchanges upon a failover. Further, for applications such as Mobile IPv6 that use IKEv2/IPsec for securing the signaling, re-establishment of IKEv2 often adds unacceptable latencies. Ideally, a mechanism that does not need any new messages to exclusively support failover is desired. In general, the goal is to have significantly lower latency and to incur a lower computational overhead than a regular IKEv2 exchange. In cases where EAP is used for client authentication in IKEv2, the failover should not require EAP authentication, to avoid AAA overloading and possible user interaction. Narayanan Expires August 31, 2007 [Page 6]
Internet-Draft IPsec Failover/Redundancy PS February 2007 o Application Usage of IPsec: When IPsec is used to protect other protocols, the extent of failover interoperability that can be expected by such protocols greatly hinge on the interoperability of IPsec failover mechanisms. For e.g., Mobile IP Home Agent reliability [5] mechanisms are intended to be standardized for interoperability. However, it is incomplete without IPsec failover. So, it is important to allow applications that use IPsec to take advantage of the IPsec failover mechanism. It is not expected that the IPsec failover solution will address this, but a guidance needs to be provided to allow application specifications to specify the appropriate interface/interaction needed (e.g., if synchronization between application state and IPsec state is needed). o Interoperability: Client-gateway and gateway-gateway interoperability is required. This follows from the discussion on the other goals stated above. o Stateless Gateway Operation: The IPsec failover mechanism should specify a mode of operation that will allow the backup gateways to remain stateless until a failover occurs or during a temporary service interruption. This will allow for better scalability of the solution, since a given gateway only needs to store state for clients that are being served by it. This requires for an equally secure means of storing state in the clients and allowing the client to present it to the gateway for recovery. o Support for IPsec transport and tunnel modes: As noted in the applicability section of this document, the IPsec infrastructure endpoint may either be an IPsec VPN gateway employing tunnel mode SAs with the client or an application server that uses IPsec transport or tunnel mode to protect signaling exchanges with the client. Hence, a solution developed for failover must support failover of both transport and tunnel mode SAs. 6. Security Considerations This document provides the problem description and goals for an IPsec failover solution. The solution must ensure secure operation and there are several important points to consider for that. We highlight a few of the important ones below : o First, any SA storage and retrieval mechanisms specified between the backend entities must be protected with a secure channel that has the following properties: confidentiality, integrity protection, and replay protection. Narayanan Expires August 31, 2007 [Page 7]
Internet-Draft IPsec Failover/Redundancy PS February 2007 o In a client-server model, where the client always initiates the secure communication, the client is always the IKEv2 initiator. Solutions for failover in such cases, may allow the client to find the new gateway address through external means. Subsequently, the client must be able to verify that the new gateway possesses the IKEv2 key material. A client should be able to initiate a new IKEv2 SA with one or more auxiliary gateways without interrupting a connection to the currently used primary gateway. The client must consider the new gateway as a provisional one until it has verified a new gateway is the appropriate replacement for the primary gateway. o Any solution must adequately describe the consequences to replay protection as a result of IPsec failover. For replay protection, it may be best for the replacement gateway to assume that the IPsec SA state is outdated and reestablish the IPsec SA using an IKEv2 CREATE_CHILD_SA exchange. o IPsec failover facilitates the replacement of an IPsec GW serving a client with another GW. The design must take into account the possibility of an adversary creating a ping-ponging scenario where a client may be forced to move between two or more GWs persistently. 7. IANA Considerations No IANA action is required for this document. 8. Acknowledgments We thank Russ Housley, Jun Wang, Marcello Lioy, and Raymond Hsu for technical discussions and/or help with standardization aspects related to this work. We also thank Steve Kent for his review of the draft. 9. References 9.1. 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. Narayanan Expires August 31, 2007 [Page 8]
Internet-Draft IPsec Failover/Redundancy PS February 2007 [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. 9.2. Informative References [5] Wakikawa, R., "Home Agent Reliability Protocol", draft-ietf-mip6-hareliability-00 (work in progress), June 2006. Author's Address Vidya Narayanan (editor) Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Narayanan Expires August 31, 2007 [Page 9]
Internet-Draft IPsec Failover/Redundancy PS 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). Narayanan Expires August 31, 2007 [Page 10]