--- 1/draft-ietf-ipsecme-ipsecha-protocol-03.txt 2011-03-02 21:14:27.000000000 +0100 +++ 2/draft-ietf-ipsecme-ipsecha-protocol-04.txt 2011-03-02 21:14:27.000000000 +0100 @@ -1,24 +1,24 @@ Network Working Group R. Singh, Ed. Internet-Draft G. Kalyani Intended status: Standards Track Cisco -Expires: August 12, 2011 Y. Nir +Expires: September 3, 2011 Y. Nir Check Point Y. Sheffer Independent D. Zhang Huawei - February 8, 2011 + March 2, 2011 Protocol Support for High Availability of IKEv2/IPsec - draft-ietf-ipsecme-ipsecha-protocol-03 + draft-ietf-ipsecme-ipsecha-protocol-04 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 @@ -38,21 +38,21 @@ 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 August 12, 2011. + This Internet-Draft will expire on September 3, 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 @@ -60,53 +60,58 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6 - 4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 7 - 5. SA Counter Synchronization Solution . . . . . . . . . . . . . 8 - 5.1. Processing Rules for IKE Message ID Synchronization . . . 10 + 3.1. Large Amount of State . . . . . . . . . . . . . . . . . . 6 + 3.2. Multiple Members Using the Same SA . . . . . . . . . . . . 7 + 3.3. Avoiding Collisions in SPI Number Allocation . . . . . . . 7 + 3.4. Interaction with Counter Modes . . . . . . . . . . . . . . 8 + 4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 8 + 5. SA Counter Synchronization Solution . . . . . . . . . . . . . 9 + 5.1. Processing Rules for IKE Message ID Synchronization . . . 11 5.2. Processing Rules for IPsec Replay Counter - Synchronization . . . . . . . . . . . . . . . . . . . . . 11 - 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 11 - 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 11 - 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 12 - 6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 12 - 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 13 - 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 14 - 8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 14 - 8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 15 - 8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 15 - 8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 15 - 9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 15 - 10. Interaction with other drafts . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.1. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.2. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.3. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.4. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 19 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 20 - A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 20 - A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 20 - A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Synchronization . . . . . . . . . . . . . . . . . . . . . 12 + 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 12 + 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 12 + 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 13 + 6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 13 + 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 14 + 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 15 + 8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 16 + 8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 16 + 8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 16 + 8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 16 + 9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 16 + 10. Interaction with other drafts . . . . . . . . . . . . . . . . 17 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 14.1. Draft -04 . . . . . . . . . . . . . . . . . . . . . . . . 19 + 14.2. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 19 + 14.3. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 20 + 14.4. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 20 + 14.5. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 20 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 21 + 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. @@ -215,37 +220,104 @@ 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 o 3.9. Allocation of SPIs The main problem areas are solved using the protocol extension - defined below; additionally, this document provides implementation - advice for other issues, as follows. - o Section 3.2 of the Problem Statement mentions that there is a - large amount of state that needs to be synchronized. However if - state is not synchronized, this is not really an interesting - cluster: failover is equivalent to a reboot of the cluster member, - and so the issue need not be solved with a protocol extension. - o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see - Section 4, for more details. - o 3.7 is an implementation problem that needs to be solved while - building IPsec clusters. However, the peers should be required to - accept multiple parallel SAs for 3.7.1. - o 3.8 can be solved by using the IKEv2 Redirect mechanism [6]. - o 3.9 discusses the avoidance of collisions where the same SPI value - is used by multiple cluster members. This is outside the - document's scope since the problem needs to be solved internally - to the cluster and does not involve the peer. + defined below, starting with Section 5; additionally, this section + provides implementation advice for other issues in the following + subsections. + +3.1. Large Amount of State + + Section 3.2 of the Problem Statement mentions that a lot of state + needs to be synchronized for a cluster to be transparent. The actual + volume of that data is very much implementation-dependent, and even + for the same implementation, the amounts of data may vary wildly. An + IPsec gateway used for inter-domain VPN with a dozen other gateways, + and having SAs that are rekeyed every 8 hours, will need a lot less + synchronization traffic than a similar gateway used for remote + access, and supporting 10,000 clients. This is because counter + synchronization is proportional to the number of SAs and requires + little data, and the setting up of an SA requires a lot of data. + Additionally, remote access IKE and IPsec SA setup tend to happen at + a particular time of day, so the example gateway with the 10,000 + clients may see 30-50 IKE SA setups per second at 9:00 AM. This + would require very heavy synchronization traffic over that short + period of time. + + If a large volume of traffic is necessary, it may be advisable to use + a dedicated high-speed network interface for synch traffic. When + packet loss can be made extremely low, it may be advisable to use a + stateless transport such as UDP, to minimize network overhead. + + If these methods are insufficient, it may be prudent that for some + SAs the entire state is not synchronized. Instead, only an + indication of the SA's existence is synchronized. This, in + combination with a sticky solution (as described in section 3.7 of + the problem statement) ensures that the traffic from a particular + peer does not reach a different member before an actual failover + happens. When that happens, the method described in [6] can be used + to quickly force the peer to set up a new SA. + +3.2. Multiple Members Using the Same SA + + In a load-sharing cluster of the "duplicate" variety (see section 3.7 + 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 + 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 + 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 + + For SAs involving counter mode ciphers such as CTR [7] or GCM [8] + there is yet another complication. The initial vector for such modes + MUST NOT be repeated, and senders use methods such as counters or + LFSRs to ensure this property. For an SA shared between multiple + active members (load sharing cases), implementations MUST ensure that + no initial vector is ever repeated. Similar concerns apply to an SA + 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 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 @@ -666,45 +739,46 @@ 10. Interaction with other drafts The usage scenario of the IKEv2/IPsec SA counter synchronization proposal is that an IKEv2 SA has been established between the active member of a hot-standby cluster and a peer, then a failover event occurred with the standby member becoming active. The proposal further assumes that the IKEv2 SA state was continuously synchronized between the active and standby members of the cluster before the failover event. - o Session resumption [7] assumes that a peer (client or initiator) + o Session resumption [10] assumes that a peer (client or initiator) detects the need to re-establish the session. In IKEv2/IPsec SA counter synchronization, it is the newly-active member (a gateway or responder) that detects the need to synchronize the SA counter after the failover event. Also in a hot-standby cluster, the peer establishes the IKEv2/IPsec session with a single IP address that represents the whole cluster, so the peer normally does not detect the event of failover in the cluster unless the standby member takes too long to become active and the IKEv2 SA times out by use of the IKEv2 liveness check mechanism. To conclude, session resumption and SA counter synchronization after failover are mutually exclusive. - o The IKEv2 Redirect mechanism for load-balancing [6] can be used + + o The IKEv2 Redirect mechanism for load-balancing [11] can be used either during the initial stages of SA setup (the IKE_SA_INIT and IKE_AUTH exchanges) or after session establishment. SA counter synchronization is only useful after the IKE SA has been established and a failover event has occurred. So, unlike Redirect, it is irrelevant during the first two exchanges. Redirect after the session has been established is mostly useful for timed or planned shutdown/maintenance. A real failover event cannot be detected by the active member ahead of time, and so using Redirect after session establishment is not possible in the case of failover. So, Redirect and SA counter synchronization after failover are mutually exclusive. - o IKEv2 Failure Detection [8] solves a similar problem where the + o IKEv2 Failure Detection [6] solves a similar problem where the peer can rapidly detect that a cluster member has crashed based on a token. It is unrelated to the current scenario because the goal in failover is for the peer not to notice that a failure has occurred. 11. Security Considerations Since Message ID synchronization messages need to be sent with Message ID zero, they are potentially vulnerable to replay attacks. Because of the semantics of this protocol, these can only be denial- @@ -745,59 +819,64 @@ order) for their review comments and valuable suggestions: Dan Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and Pekka Riikonen. 14. Change Log This section lists all the changes in this document. NOTE TO RFC EDITOR: Please remove this section before publication. -14.1. Draft -03 +14.1. Draft -04 + + Extended Sec. 3 for better coverage of other IPsec cluster-related + issues, and how they are resolved within the existing standards. + +14.2. Draft -03 Clarified the rules for Message ID sync, so that replay attacks can be avoided without a failover counter. Added wording regarding inconsistent IKE state (basically choosing to ignore the problem) and further rules dealing with pending traffic. The IPsec replay counter delta value now refers to incoming traffic. The associated notification is only sent from the cluster to the peer, and not back. -14.2. Draft -02 +14.3. Draft -02 Addressed comments by Yaron Sheffer posted on the WG mailing list. Numerous editorial changes. -14.3. Draft -01 +14.4. Draft -01 Added "Multiple and Simultaneous failover' scenarios as pointed out by Pekka Riikonen. Now document provides a mechanism to sync either IKEv2 message or IPsec replay counter or both to cater different types of implementations. HA cluster's "failover count' is used to encounter replay of sync requests by attacker. The sync of IPsec SA replay counter optimized to to have just one global bumped-up outgoing IPsec SA counter of ALL Child SAs under an IKEv2 SA. The examples added for IKEv2 Message ID sync to provide more clarity. Some edits as per comments on mailing list to enhance clarity. -14.4. Draft -00 +14.5. Draft -00 Version 00 is identical to draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document. Added IPSECME WG HA design team members as authors. Added comment in Introduction to discuss the window sync process on WG mailing list to solve some concerns. 15. References @@ -814,31 +893,43 @@ Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [4] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 15.2. Informative References [5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. - [6] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the - Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, - November 2009. + [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. - [7] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol + [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 + Security Payload (ESP) and Authentication Header (AH) to + Protect Group Traffic", RFC 6054, November 2010. + + [10] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010. - [8] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick - Crash Detection Method for IKE", - draft-ietf-ipsecme-failure-detection-03 (work in progress), - January 2011. + [11] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the + Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, + November 2009. Appendix A. IKEv2 Message ID Sync Examples This (non-normative) section presents some examples that illustrate how the IKEv2 Message ID values are synchronized. We use a tuple notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and EXPECTED_RECV_REQ_MESSAGE_ID on a member as (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID). A.1. Normal Failover - Example 1