ipsecme R. Zhang, Ed. Internet-Draft S. Zhou Intended status: Standards Track ZTE Corporation Expires: December 13, 2012 June 11, 2012 Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity draft-zhang-ipsecme-ipsecha-00 Abstract This document updates RFC 6311, Protocol Support for High Availability of IKEv2/IPsec. This document analyzes RFC 6311, and proposes some updates. 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 December 13, 2012. Copyright Notice Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect 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. Zhang & Zhou Expires December 13, 2012 [Page 1] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Analysis of RFC 6311 . . . . . . . . . . . . . . . . . 3 2.1. Observation 1: State Data of the New Active Member Being Stale and Unreliable . . . . . . . . . . . . . . . . 3 2.2. Observation 2: A Parameter Flaw in Section 5.1: Processing Rules for IKE Message ID Synchronization . . . . 4 2.3. Observation 3: Mishandling of Simultaneous Failover . . . . 5 3. Update to RFC 6311, Avoiding Simultaneous Failover . . . . . . 6 4. Update to RFC 6311, Section 5.1: Processing Rules for IKE Message ID Synchronization . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Zhang & Zhou Expires December 13, 2012 [Page 2] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 1. Introduction RFC 6311 [RFC6311] 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 solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. This document analyzes RFC 6311, and proposes some updates. 1.1. 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 [RFC2119]. 2. Security Analysis of RFC 6311 Note: this section is just for informative purpose, and should be removed or moved to Appendix in the subsequent versions. 2.1. Observation 1: State Data of the New Active Member Being Stale and Unreliable Since normally synchronization is carried out periodically between the active cluster member and standby members, the state data of the new active member is stale. The state data of the new active member just reflects the state data of the old active member at the last state synchronization time point T1 before the failover events occurs, rather than at the time point T2 when the failover event happens. So the state data of the new active member can NOT reflect the actual state data of the old active member at T2. This implies that the state data of the new active member is NOT reliable. Specifically, the new active member does NOT know what messages the old active member has sent and received from T1 and T2, and does NOT know the next sender's Message ID value of the old active member, and does NOT know the last Message ID value recevied from the peer of the old active member, and does NOT know whether requested messages from T1 to T2 by the old active member have been acknowledged, and does NOT know whether the old active member has acknowledged requested messages from T1 to T2 from the peer. Further, this implies that the new active member does NOT know whether some new IPsec SAs have been created, and whether some old IPsec SAs have been deleted and some old IPsec SAs have been updated, and whether the old IKE SA has been deleted and a new IKE SA has been created from T1 to T2. Zhang & Zhou Expires December 13, 2012 [Page 3] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 2.2. Observation 2: A Parameter Flaw in Section 5.1: Processing Rules for IKE Message ID Synchronization In RFC 6311 [RFC6311], M1, P1, M2 and P2 are set as follows. 1. M1 is the next sender's Message ID to be used by the member. M1 MUST be chosen so that it is larger than any value known to have been used. It is RECOMMENDED to increment the known value at least by the size of the IKE sender window. 2. P1 SHOULD be 1 more than the last Message ID value received from the peer, but may be any higher value. 3. M2 MUST be at least the higher of the received M1, and one more than the highest sender value received from the cluster. This includes any previous received synchronization messages. 4. P2 MUST be the higher of the received P1 value, and one more than the highest sender value used by the peer. The setting of M2 is wrong, the reason is as follows. In the following disccussion, suppose the peer is a IPsec client or VPN gateway, not a IPsec cluster. First, based on observation 1, M1 chosen by the new active member is NOT accurate or reliable. Under some circumstances, M1 may be much lower than the highest sender value received from the cluster, if a lot of IKEv2 messages are exchanged from T1 to T2. Second, one more than the highest sender value received from the cluster just covers the received messages, does NOT cover the sent but unreached messages from the old active member. Suppose the highest sender value received from the cluster is RN0, and the sender window of the cluster is SW. Then the old active member may have sent SW messages with message ID RNO+1, ... RNO+SW messages, and these SW messages may have NOT reached the peer. If M2 is set as RN0+1, then the Message ID of the new active number will start from RNO+1. Since RNO+1 is lower than RNO+SW, this will cause some problems. 1. Case A: since RNO+1 is lower than RNO+SW, the Message ID of the first sent message from the new active member is lower than the Messsage ID of the last message sent by the old active member. This means that the message ID are NOT monotonically incremental. 2. Case B: the message IDs RNO+1,RNO+2,..., RNO+SW will be used twice in the two groups of messages sent by the old active member and new active member. This means that the peer may receive two different request messages with the same Message ID. Zhang & Zhou Expires December 13, 2012 [Page 4] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 3. Case C: the new active member may receive an acceptable but mismatched response message for a request message with message ID within RNO+1,RNO+2,..., RNO+SW. For example, the peer may generate a response message to a request from the old active member with a Message ID RNO+2, and the new active member may receive this message as the response for its request message with the same Message ID. Under some circumstances, this may cause some security risks. When the peer can act as a reliable archor point, the flaw can be fixed. 2.3. Observation 3: Mishandling of Simultaneous Failover When simultaneous failover happens, the state data of new active members of the two clusters are NOT reliable, and can NOT act as reliable archor points to perform the IKEv2 message ID synchronization. Suppose there exists two clusters: X and Y. And the old and new active member of X is x1 and x2, respectively. The old and new active member of Y is y1 and y2, respectively. And suppose x2 initiates the synchronization process. First, based on observation 1, M1 chosen by x2 is NOT accurate or reliable. Additionally, because y2's state data is stale, y2's highest sender value received from the cluster X is not exactly identical to that of y1's. Under some circumstances, y2's highest sender value received from the cluster X may be much lower than y1's, if a lot of IKEv2 messages are exchanged between X1 and Y1 from T1 to T2. As a consequence, M2 chosen by y2 may be NOT reliable. Second, based on the same reason, P1 chosen by x2 is NOT accurate or reliable. The reason is that x2's last Message ID value received from cluster Y may be much lower than x1's. Similarily, the highest sender value used by y2 may be much lower than the highest sender value used by y1. As a consequence, P2 chosen by y2 may be NOT reliable, and may be even lower than some message IDs used by y1. Overall, the mishanling of simultaneous failover may cause some problems. 1. Case A: the Message ID of the first sent message from x2 are lower than the Messsage ID of the last message sent by x1. This means that the message ID are NOT monotonically incremental. 2. Case B: Some message IDs will be used twice in the two groups of messages sent by x1 and x2. This means that Y2 may receive two different request messages with the same Message ID. 3. Case C: x2 may receive an acceptable but mismatched response message for a request message. Zhang & Zhou Expires December 13, 2012 [Page 5] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 4. Case D: x2 may accept a request message sent by y1. When y2's P2 is lower than the message IDs used by y1, the request message of y1 with a Message ID greater than P2 will be accepted by x2. This indicates that a request message from y1 may be accepted twice, one by x1, and one by x2. 5. Case E: y2 may accept a response message sent by x1. When y2's P2 is lower than the message IDs used by y1, the response message of x1 with a Message ID greater than P2 may be accepted by y2. Under some circumstances, this may cause some security risks. 6. Case F: from T1 to T2, x1 and y1 may have deleted the old IKE SA, and created a new IKE SA. However, since x2 and y2 have NOT updated their state data, after the simulateous failover event occurs, x2 and y2 may still use the old IKE SA. This may cause some security risks Unlike observation 2, in the case of simulatenous failover, the flaw can NOT be easily fixed. 3. Update to RFC 6311, Avoiding Simultaneous Failover When a failover event occurs, the synchronization state of the new active member should be set to UNSYNED. Meanwhile, the new active member should generate a synchronization request message and send it to the peer. When a cluster member in UNSYNED state receives a synchronization request, it should reply a Simultaneous Failover Failure response message to the peer to avoid the simultaneous failover failure, and terminates the synchronization process. Correspondingly, when the new active member of the peer cluster in UNSYNED state receives the Simultaneous Failover Failure message, it will terminate the synchronization process as well. Note: the details of message type and protocol will be done in the subsequent versions. A new parameter called synchronization state is integrated into the IKE SA state data. After the failover event occurs, the synchronization state is set to UNSYNED. And after the synchronization process is finished, the synchronization state is set to SYNED. A simple state machine is introduced.The synchronization state of a IPsec VPN and IPsec gateway is always SYNED. The initial state of a new active member is UNSYNED. After the success of synchronization, the synchronization of the new active member will be changed to SYNED. An IPsec party in SYNED state is capable of performing synchronization for the opposite party in UNSYNED state. Zhang & Zhou Expires December 13, 2012 [Page 6] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 4. Update to RFC 6311, Section 5.1: Processing Rules for IKE Message ID Synchronization 1. Parameter modification: M2 MUST be at least the higher of the received M1 and M1', where M1' is the peer cluster's sender window size plus the highest sender value received from the peer cluster. This includes any previous received synchronization messages. This modification ensures that M2 is larger than the largest Message ID sent by the old active member. 5. Security Considerations Security implications will be discussed in the subsequent versions. 6. IANA Considerations This document introduces a new IKEv2 Notification Message type: Simultaneous Failover Failure. This new type needs to be assigned a value. +-------------------------------+-------------------------------+ | Name | Value | +-------------------------------+-------------------------------+ | Simultaneous Failover Failure | TBA | +-------------------------------+-------------------------------+ 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", Zhang & Zhou Expires December 13, 2012 [Page 7] Internet-Draft draft-zhang-ipsecme-ipsecha-00 June 2012 RFC 5996, September 2010. [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, July 2011. 7.2. Informative References [RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010. Authors' Addresses Ruishan Zhang (editor) ZTE Corporation 889 Bibo Rd, Zhangjiang Hi-Tech Park Shanghai 201203 R.R.China Email: zhang.ruishan@zte.com.cn Sujing Zhou ZTE Corporation No.68 Zijinghua Rd. Yuhuatai District Nanjing, Jiang Su 210012 R.R.China Email: zhou.sujing@zte.com.cn Zhang & Zhou Expires December 13, 2012 [Page 8]