--- 1/draft-ietf-ipsecme-ipsecha-protocol-04.txt 2011-03-29 20:15:49.000000000 +0200 +++ 2/draft-ietf-ipsecme-ipsecha-protocol-05.txt 2011-03-29 20:15:49.000000000 +0200 @@ -1,58 +1,58 @@ Network Working Group R. Singh, Ed. Internet-Draft G. Kalyani Intended status: Standards Track Cisco -Expires: September 3, 2011 Y. Nir +Expires: September 30, 2011 Y. Nir Check Point Y. Sheffer Independent D. Zhang Huawei - March 2, 2011 + March 29, 2011 Protocol Support for High Availability of IKEv2/IPsec - draft-ietf-ipsecme-ipsecha-protocol-04 + draft-ietf-ipsecme-ipsecha-protocol-05 Abstract The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This - document attempts to resolve these issues with the least possible - change to the protocol. + document resolves these issues with the least possible change to the + protocol. - This document proposes an extension to the IKEv2 protocol to solve - the main issues of "IPsec Cluster Problem Statement" in the commonly + This document defines an extension to the IKEv2 protocol to solve the + main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for - other issues. The main issues to be solved are the synchronization - of IKEv2 Message ID counters, and of IPsec Replay Counters. + other issues. The main issues solved are the synchronization of + IKEv2 Message ID counters, and of IPsec Replay Counters. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 3, 2011. + This Internet-Draft will expire on September 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -104,24 +104,24 @@ A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22 A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22 A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The IPsec protocol suite, including IKEv2, is a major building block of virtual private networks (VPNs). In order to make such VPNs highly available, more scalable and failure-resistant, these VPNs are - implemented as IKEv2/IPsec Highly Available (HA) cluster. However - there are many issues with the IKEv2/IPsec HA cluster. The problem - statement draft Section 4 enumerates the issues around the IKEv2/ - IPsec HA cluster solution. + implemented as IKEv2/IPsec Highly Available (HA) clusters. However + there are many issues with the IKEv2/IPsec HA cluster. Section 4 + below enumerates the issues around the IKEv2/IPsec HA cluster + solution. In the case of a hot-standby cluster implementation of IKEv2/IPsec based VPNs, the IKEv2/IPsec session is first established between the peer and the active member of the cluster. Later, the active member continuously syncs/updates the IKE/IPsec SA state to the standby member of the cluster. This primary SA state sync-up takes place upon each SA bring-up and/or rekey. Performing the SA state synchronization/update for every single IKE and IPsec message is very costly, so normally it is done periodically. As a result, when the failover event happens, this is first detected by the standby member @@ -164,21 +164,21 @@ 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 [1]. "SA Counter Synchronization Request/Response" are the request viz. response of the informational exchange defined in this document to synchronize the IKEv2/IPsec SA counter information between one member of the cluster and the peer. - Some of the terms listed below are reused from [2] with further + Some of the terms listed below are reused from [4] with further clarification in the context of the current document. o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of the members is active at any one time. This member is also referred to as the "active" member, whereas the other(s) are referred to as "standby" members. VRRP [5] is one method of building such a cluster. The goal of the Hot Standby Cluster is to create the illusion of a single virtual gateway to the peer(s). o "Active Member" is the primary member in the Hot-Standby cluster. It is responsible for forwarding packets on behalf of the virtual @@ -206,21 +206,21 @@ The generic term "IKEv2/IPsec SA Counters" is used throughout this document. This term refers to both IKEv2 Message ID counters and IPsec replay counters. According to the IPsec standards, the IKEv2 Message ID counter is mandatory, and used to ensure reliable delivery as well as to protect against message replay in IKEv2; the IPsec SA replay counters are optional, and are used to provide the IPsec anti- replay feature. 3. Issues Resolved from IPsec Cluster Problem Statement - The IPsec Cluster Problem Statement [2] enumerates the problems + The IPsec Cluster Problem Statement [4] enumerates the problems raised by IPsec clusters. The following table lists the problem statement's sections that are resolved by this document. o 3.2. Lots of Long Lived State o 3.3. IKE Counters o 3.4. Outbound SA Counters o 3.5. Inbound SA Counters o 3.6. Missing Synchronization Messages o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members * 3.7.1. Outbound SAs using counter modes o 3.8. Different IP addresses for IKE and IPsec @@ -269,32 +269,32 @@ of the problem statement) multiple members may need to send traffic with the same selectors. To actually use the same SA the cluster would have to synchronize the Replay Counter after every packet, and that would impose unreasonable requirements on the synch connection. A far better solution would be to not synchronize the outbound SA, and create multiple outbound SAs, one for each member. The problem with this option is that the peer might view these multiple parallel SAs as redundant, and tear down all but one of them. - Section 2.8 of [3] specifically allows multiple parallel SAs, but the + Section 2.8 of [2] specifically allows multiple parallel SAs, but the reason given for this is to have multiple SAs with different QoS attributes. So while this is not a new requirement of IKEv2 implementations, we re-iterate here that IPsec peers MUST accept the long-term existence of multiple parallel SAs, even when QoS mechanisms are not in use. 3.3. Avoiding Collisions in SPI Number Allocation Section 3.9 of the problem statement describes the problem of two cluster members allocating the same SPI number for two different SAs. - This would violate section 4.4.2.1 of [4]. There are several schemes + This would violate section 4.4.2.1 of [3]. There are several schemes to allow implementations to avoid such collisions, such as partitioning the SPI space, a request-response over the synch channel, and locking mechanisms. We believe that these are sufficiently robust and available so that we don't need to make an exception to RFC 4301, and we can leave this problem for the implementations to solve. Cluster members MUST NOT generate multiple inbound SAs with the same SPI. 3.4. Interaction with Counter Modes @@ -307,21 +307,21 @@ failing over from one member to another. See [9] for a discussion of this problem in another context. Just as in the SPI collision problem, there are ways to avoid a collision of initial vectors, and this is left up to implementations. In the context of load sharing, parallel SAs are a simple solution to this problem as well. 4. The IKEv2/IPsec SA Counter Synchronization Problem - The IKEv2 protocol [3] states that "An IKE endpoint MUST NOT exceed + The IKEv2 protocol [2] states that "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests". All IKEv2 messages are required to follow a request-response paradigm. The initiator of an IKEv2 request MUST retransmit the request, until it has received a response from the peer. IKEv2 introduces a windowing mechanism that allows multiple requests to be outstanding at a given point of time, but mandates that the sender's window should not move until the oldest message it has sent is acknowledged. Loss of even a single message leads to repeated retransmissions followed by an IKEv2 SA teardown if the @@ -531,21 +531,21 @@ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 - of [3]. The 'SPI Size' field MUST be set to 0 to indicate that the + of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data associated with this notification. 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification @@ -556,21 +556,21 @@ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 - of [3] . The 'SPI Size' field MUST be set to 0 to indicate that the + of [2] . The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no data associated with this notification. 6.3. The IKEV2_MESSAGE_ID_SYNC Notification @@ -607,21 +607,21 @@ 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification This notification payload type (value TBD by IANA) is defined to synchronize the IPsec SA Replay Counters between the newly-active (formerly standby) cluster member and the peer. Since there may be numerous IPsec SAs established under a single IKE SA, we do not directly synchronize the value of each one. Instead, a delta value is sent and all Replay Counters for Child SAs of this IKE SA are incremented by the same value. Note that this solution requires that all these Child SAs either use or do not use Extended Sequence - Numbers [4]. This notification is only sent by the cluster. + Numbers [3]. This notification is only sent by the cluster. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming IPsec SA delta value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -879,38 +879,38 @@ Added comment in Introduction to discuss the window sync process on WG mailing list to solve some concerns. 15. References 15.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, - October 2010. - - [3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key + [2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. - [4] Kent, S. and K. Seo, "Security Architecture for the Internet + [3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 15.2. Informative References + [4] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, + October 2010. + [5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for IKE", - draft-ietf-ipsecme-failure-detection-05 (work in progress), - February 2011. + draft-ietf-ipsecme-failure-detection-07 (work in progress), + March 2011. [7] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating