idnits 2.17.1 draft-zhang-ipsecme-ipsecha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC6311, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2012) is 4337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4301' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC6027' is defined on line 305, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme R. Zhang, Ed. 3 Internet-Draft S. Zhou 4 Intended status: Standards Track ZTE Corporation 5 Expires: December 13, 2012 June 11, 2012 7 Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity 8 draft-zhang-ipsecme-ipsecha-00 10 Abstract 12 This document updates RFC 6311, Protocol Support for High 13 Availability of IKEv2/IPsec. This document analyzes RFC 6311, and 14 proposes some updates. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 13, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Security Analysis of RFC 6311 . . . . . . . . . . . . . . . . . 3 53 2.1. Observation 1: State Data of the New Active Member 54 Being Stale and Unreliable . . . . . . . . . . . . . . . . 3 55 2.2. Observation 2: A Parameter Flaw in Section 5.1: 56 Processing Rules for IKE Message ID Synchronization . . . . 4 57 2.3. Observation 3: Mishandling of Simultaneous Failover . . . . 5 58 3. Update to RFC 6311, Avoiding Simultaneous Failover . . . . . . 6 59 4. Update to RFC 6311, Section 5.1: Processing Rules for IKE 60 Message ID Synchronization . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 RFC 6311 [RFC6311] defines an extension to the IKEv2 protocol to 71 solve the main issues of "IPsec Cluster Problem Statement" in the 72 commonly deployed hot standby cluster, and provides implementation 73 advice for other issues. The main issues solved are the 74 synchronization of IKEv2 Message ID counters, and of IPsec replay 75 counters. This document analyzes RFC 6311, and proposes some 76 updates. 78 1.1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Security Analysis of RFC 6311 86 Note: this section is just for informative purpose, and should be 87 removed or moved to Appendix in the subsequent versions. 89 2.1. Observation 1: State Data of the New Active Member Being Stale and 90 Unreliable 92 Since normally synchronization is carried out periodically between 93 the active cluster member and standby members, the state data of the 94 new active member is stale. The state data of the new active member 95 just reflects the state data of the old active member at the last 96 state synchronization time point T1 before the failover events 97 occurs, rather than at the time point T2 when the failover event 98 happens. So the state data of the new active member can NOT reflect 99 the actual state data of the old active member at T2. This implies 100 that the state data of the new active member is NOT reliable. 101 Specifically, the new active member does NOT know what messages the 102 old active member has sent and received from T1 and T2, and does NOT 103 know the next sender's Message ID value of the old active member, and 104 does NOT know the last Message ID value recevied from the peer of the 105 old active member, and does NOT know whether requested messages from 106 T1 to T2 by the old active member have been acknowledged, and does 107 NOT know whether the old active member has acknowledged requested 108 messages from T1 to T2 from the peer. Further, this implies that the 109 new active member does NOT know whether some new IPsec SAs have been 110 created, and whether some old IPsec SAs have been deleted and some 111 old IPsec SAs have been updated, and whether the old IKE SA has been 112 deleted and a new IKE SA has been created from T1 to T2. 114 2.2. Observation 2: A Parameter Flaw in Section 5.1: Processing Rules 115 for IKE Message ID Synchronization 117 In RFC 6311 [RFC6311], M1, P1, M2 and P2 are set as follows. 119 1. M1 is the next sender's Message ID to be used by the member. M1 120 MUST be chosen so that it is larger than any value known to have 121 been used. It is RECOMMENDED to increment the known value at 122 least by the size of the IKE sender window. 124 2. P1 SHOULD be 1 more than the last Message ID value received from 125 the peer, but may be any higher value. 127 3. M2 MUST be at least the higher of the received M1, and one more 128 than the highest sender value received from the cluster. This 129 includes any previous received synchronization messages. 131 4. P2 MUST be the higher of the received P1 value, and one more than 132 the highest sender value used by the peer. 134 The setting of M2 is wrong, the reason is as follows. In the 135 following disccussion, suppose the peer is a IPsec client or VPN 136 gateway, not a IPsec cluster. First, based on observation 1, M1 137 chosen by the new active member is NOT accurate or reliable. Under 138 some circumstances, M1 may be much lower than the highest sender 139 value received from the cluster, if a lot of IKEv2 messages are 140 exchanged from T1 to T2. Second, one more than the highest sender 141 value received from the cluster just covers the received messages, 142 does NOT cover the sent but unreached messages from the old active 143 member. Suppose the highest sender value received from the cluster 144 is RN0, and the sender window of the cluster is SW. Then the old 145 active member may have sent SW messages with message ID RNO+1, ... 146 RNO+SW messages, and these SW messages may have NOT reached the peer. 147 If M2 is set as RN0+1, then the Message ID of the new active number 148 will start from RNO+1. Since RNO+1 is lower than RNO+SW, this will 149 cause some problems. 151 1. Case A: since RNO+1 is lower than RNO+SW, the Message ID of the 152 first sent message from the new active member is lower than the 153 Messsage ID of the last message sent by the old active member. 154 This means that the message ID are NOT monotonically incremental. 156 2. Case B: the message IDs RNO+1,RNO+2,..., RNO+SW will be used 157 twice in the two groups of messages sent by the old active member 158 and new active member. This means that the peer may receive two 159 different request messages with the same Message ID. 161 3. Case C: the new active member may receive an acceptable but 162 mismatched response message for a request message with message ID 163 within RNO+1,RNO+2,..., RNO+SW. For example, the peer may 164 generate a response message to a request from the old active 165 member with a Message ID RNO+2, and the new active member may 166 receive this message as the response for its request message with 167 the same Message ID. Under some circumstances, this may cause 168 some security risks. 170 When the peer can act as a reliable archor point, the flaw can be 171 fixed. 173 2.3. Observation 3: Mishandling of Simultaneous Failover 175 When simultaneous failover happens, the state data of new active 176 members of the two clusters are NOT reliable, and can NOT act as 177 reliable archor points to perform the IKEv2 message ID 178 synchronization. Suppose there exists two clusters: X and Y. And the 179 old and new active member of X is x1 and x2, respectively. The old 180 and new active member of Y is y1 and y2, respectively. And suppose 181 x2 initiates the synchronization process. First, based on 182 observation 1, M1 chosen by x2 is NOT accurate or reliable. 183 Additionally, because y2's state data is stale, y2's highest sender 184 value received from the cluster X is not exactly identical to that of 185 y1's. Under some circumstances, y2's highest sender value received 186 from the cluster X may be much lower than y1's, if a lot of IKEv2 187 messages are exchanged between X1 and Y1 from T1 to T2. As a 188 consequence, M2 chosen by y2 may be NOT reliable. Second, based on 189 the same reason, P1 chosen by x2 is NOT accurate or reliable. The 190 reason is that x2's last Message ID value received from cluster Y may 191 be much lower than x1's. Similarily, the highest sender value used 192 by y2 may be much lower than the highest sender value used by y1. As 193 a consequence, P2 chosen by y2 may be NOT reliable, and may be even 194 lower than some message IDs used by y1. Overall, the mishanling of 195 simultaneous failover may cause some problems. 197 1. Case A: the Message ID of the first sent message from x2 are 198 lower than the Messsage ID of the last message sent by x1. This 199 means that the message ID are NOT monotonically incremental. 201 2. Case B: Some message IDs will be used twice in the two groups of 202 messages sent by x1 and x2. This means that Y2 may receive two 203 different request messages with the same Message ID. 205 3. Case C: x2 may receive an acceptable but mismatched response 206 message for a request message. 208 4. Case D: x2 may accept a request message sent by y1. When y2's P2 209 is lower than the message IDs used by y1, the request message of 210 y1 with a Message ID greater than P2 will be accepted by x2. 211 This indicates that a request message from y1 may be accepted 212 twice, one by x1, and one by x2. 214 5. Case E: y2 may accept a response message sent by x1. When y2's 215 P2 is lower than the message IDs used by y1, the response message 216 of x1 with a Message ID greater than P2 may be accepted by y2. 217 Under some circumstances, this may cause some security risks. 219 6. Case F: from T1 to T2, x1 and y1 may have deleted the old IKE SA, 220 and created a new IKE SA. However, since x2 and y2 have NOT 221 updated their state data, after the simulateous failover event 222 occurs, x2 and y2 may still use the old IKE SA. This may cause 223 some security risks 225 Unlike observation 2, in the case of simulatenous failover, the flaw 226 can NOT be easily fixed. 228 3. Update to RFC 6311, Avoiding Simultaneous Failover 230 When a failover event occurs, the synchronization state of the new 231 active member should be set to UNSYNED. Meanwhile, the new active 232 member should generate a synchronization request message and send it 233 to the peer. When a cluster member in UNSYNED state receives a 234 synchronization request, it should reply a Simultaneous Failover 235 Failure response message to the peer to avoid the simultaneous 236 failover failure, and terminates the synchronization process. 237 Correspondingly, when the new active member of the peer cluster in 238 UNSYNED state receives the Simultaneous Failover Failure message, it 239 will terminate the synchronization process as well. 241 Note: the details of message type and protocol will be done in the 242 subsequent versions. A new parameter called synchronization state is 243 integrated into the IKE SA state data. After the failover event 244 occurs, the synchronization state is set to UNSYNED. And after the 245 synchronization process is finished, the synchronization state is set 246 to SYNED. A simple state machine is introduced.The synchronization 247 state of a IPsec VPN and IPsec gateway is always SYNED. The initial 248 state of a new active member is UNSYNED. After the success of 249 synchronization, the synchronization of the new active member will be 250 changed to SYNED. An IPsec party in SYNED state is capable of 251 performing synchronization for the opposite party in UNSYNED state. 253 4. Update to RFC 6311, Section 5.1: Processing Rules for IKE Message ID 254 Synchronization 256 1. Parameter modification: M2 MUST be at least the higher of the 257 received M1 and M1', where M1' is the peer cluster's sender 258 window size plus the highest sender value received from the peer 259 cluster. This includes any previous received synchronization 260 messages. This modification ensures that M2 is larger than the 261 largest Message ID sent by the old active member. 263 5. Security Considerations 265 Security implications will be discussed in the subsequent versions. 267 6. IANA Considerations 269 This document introduces a new IKEv2 Notification Message type: 270 Simultaneous Failover Failure. This new type needs to be assigned a 271 value. 273 +-------------------------------+-------------------------------+ 274 | Name | Value | 275 +-------------------------------+-------------------------------+ 276 | Simultaneous Failover Failure | TBA | 277 +-------------------------------+-------------------------------+ 279 7. References 281 7.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 287 Internet Protocol", RFC 4301, December 2005. 289 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 290 December 2005. 292 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 293 RFC 4303, December 2005. 295 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 296 "Internet Key Exchange Protocol Version 2 (IKEv2)", 297 RFC 5996, September 2010. 299 [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. 300 Zhang, "Protocol Support for High Availability of IKEv2/ 301 IPsec", RFC 6311, July 2011. 303 7.2. Informative References 305 [RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, 306 October 2010. 308 Authors' Addresses 310 Ruishan Zhang (editor) 311 ZTE Corporation 312 889 Bibo Rd, Zhangjiang Hi-Tech Park 313 Shanghai 201203 314 R.R.China 316 Email: zhang.ruishan@zte.com.cn 318 Sujing Zhou 319 ZTE Corporation 320 No.68 Zijinghua Rd. Yuhuatai District 321 Nanjing, Jiang Su 210012 322 R.R.China 324 Email: zhou.sujing@zte.com.cn