idnits 2.17.1 draft-ietf-ipsecme-ipsecha-protocol-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4931 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) == Missing Reference: 'CERT' is mentioned on line 311, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 311, but not defined == Missing Reference: 'IDr' is mentioned on line 311, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Downref: Normative reference to an Informational RFC: RFC 6027 == Outdated reference: A later version (-08) exists of draft-ietf-ipsecme-failure-detection-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Singh, Ed. 3 Internet-Draft G. Kalyani 4 Intended status: Standards Track Cisco 5 Expires: April 28, 2011 Y. Nir 6 Check Point 7 D. Zhang 8 Huawei 9 October 25, 2010 11 Protocol Support for High Availability of IKEv2/IPsec 12 draft-ietf-ipsecme-ipsecha-protocol-02 14 Abstract 16 The IPsec protocol suite is widely used for the deployment of virtual 17 private networks (VPNs). In order to make such VPNs highly 18 available, more scalable and failure-resistant, these VPNs are 19 implemented as IPsec High Availability (HA) clusters. However there 20 are many issues in IPsec HA clustering, and in particular in IKEv2 21 clustering. An earlier document, "IPsec Cluster Problem Statement", 22 enumerates the issues encountered in the IKEv2/IPsec HA cluster 23 environment. This document attempts to resolve these issues with the 24 least possible change to the protocol. 26 This document proposes an extension to the IKEv2 protocol to solve 27 the main issues of "IPsec Cluster Problem Statement" in the commonly 28 deployed hot-standby cluster, and provides implementation advice for 29 other issues. The main issues to be solved are the synchronization 30 of IKEv2 Message ID counters, and of IPsec Replay Counters. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 28, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 5 69 4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 5 70 5. Counter Synchronization Solution . . . . . . . . . . . . . . . 7 71 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 9 72 6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED . . . . . . . . . . . . . 9 73 6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED . . . . . . . . . . . 10 74 6.3. IKEV2_MESSAGE_ID_SYNC . . . . . . . . . . . . . . . . . . 10 75 6.4. IPSEC_REPLAY_COUNTER_SYNC . . . . . . . . . . . . . . . . 11 76 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 12 77 8. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 13 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 10. Interaction with other drafts . . . . . . . . . . . . . . . . 14 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 13.1. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 16 84 13.2. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 16 85 13.3. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 16 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 88 14.2. Informative References . . . . . . . . . . . . . . . . . . 17 89 Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 17 90 A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 17 91 A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 18 92 A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 The IPsec protocol suite, including IKEv2, is a major building block 98 of virtual private networks (VPNs). In order to make such VPNs 99 highly available, more scalable and failure-resistant, these VPNs are 100 implemented as IKEv2/IPsec Highly Available (HA) cluster. However 101 there are many issues with the IKEv2/IPsec HA cluster. The problem 102 statement draft Section 4 enumerates the issues around the IKEv2/ 103 IPsec HA cluster solution. 105 In the case of a hot-standby cluster implementation of IKEv2/IPsec 106 based VPNs, the IKEv2/IPsec session is first established between the 107 peer and the active member of the cluster. Later, the active member 108 continuously syncs/updates the IKE/IPsec SA state to the standby 109 member of the cluster. This primary SA state sync-up takes place 110 upon each SA bring-up and/or rekey. Performing the SA state 111 synchronization/update for every single IKE and IPsec message is very 112 costly, so normally it is done periodically. As a result, when the 113 failover event happens, this is first detected by the standby member 114 and, possibly after a considerable amount of time, it becomes the 115 active member. During this failover process the peer is unaware of 116 the failover event, and keeps sending IKE requests and IPsec packets 117 to the cluster, as in fact it is allowed to do because of the IKEv2 118 windowing feature. After the newly-active member starts, it detects 119 the mismatch in IKE Message ID values and IPsec replay counters and 120 needs to resolve this situation. Please see Section 4 for more 121 details of the problem. 123 This document proposes an extension to the IKEv2 protocol to solve 124 main issues of IKE Message ID synchronization and IPsec SA replay 125 counter synchronization and gives implementation advice for others. 126 Following is a summary of the solutions provided in this document: 128 o IKEv2 Message ID synchronization: this is done by syncing up the 129 expected send and receive Message ID values with the peer, and 130 updating the values at the newly active cluster member. 131 o IPsec Replay Counter synchronization: this is done by incrementing 132 the cluster's outgoing SA replay counter values by a "large" 133 number, and synchronizing these values with the peer. The peer 134 send its outgoing SA reply counter in the response. 136 Although this document describes the IKEv2 Message ID and IPsec 137 replay counter synchronization in the context of an IPsec HA cluster, 138 the solution provided is generic and can be used in other scenarios 139 where IKEv2 Message ID or IPsec SA replay counter synchronization may 140 be required. 142 Implementations differ on the need to synchronize the IKEv2 Message 143 ID and/or IPsec replay counters. Both of these problem are handled 144 separately, using a separate notification for each capability. This 145 provides the flexibility of implementing either or both of these 146 solutions. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 "SA Counter Synchronization Request/Response" are the request viz. 155 response of the information exchange defined in this document to 156 synchronize the IKEv2/IPsec SA counter information between one member 157 of the cluster and the peer. 159 Some of the terms listed below are reused from [RFC6027] with further 160 clarification in the context of the current document. 162 o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one 163 of the members is active at any one time. This member is also 164 referred to as the "active" member, whereas the other(s) are 165 referred to as "standby" members. VRRP [RFC5798] is one method of 166 building such a cluster. The goal of Hot Standby Cluster is that 167 it creates illusion of single virtual gateway to the peer(s). 168 o "Active Member" is the primary member in the Hot-Standby cluster. 169 It is responsible for forwarding packets on behalf of the virtual 170 gateway. 171 o "Standby Member" is the primary backup member. This member takes 172 control, i.e. becomes the active member, after the failover event. 173 o "Peer" is an IKEv2/IPsec endpoint that maintains a VPN connection 174 with the Hot-Standby cluster. The Peer identifies the cluster by 175 the cluster's (single) IP address. If a failover event occurs, 176 the standby member of the cluster becomes active, and the peer 177 normally doesn't notice that failover has taken place. 178 o "Failover Count" is a global failover event counter maintained by 179 the HA cluster and incremented by 1 upon each failover event in 180 the HA cluster. All members of the HA cluster share the failover 181 count. 182 o "Multiple failover" is the situation where, in a cluster with 183 three or more members, failover happens in rapid succession. It 184 is our goal that the implementation should be able to handle this 185 situation, i.e. to handle the new failover event even if it is 186 still processing the old failover. 187 o "Simultaneous failover" is the situation where two clusters have a 188 VPN connection between them, and failover happens at the both ends 189 at the same time. It is our goal that implementation should be 190 able to handle simultaneous failover. 192 The generic term "IKEv2/IPsec SA Counters" is used throughout this 193 document. This term refers to both IKEv2 Message ID counters 194 (mandatory, and used to ensure reliable delivery as well as to 195 protect against message replay in IKEv2) and IPsec SA replay counters 196 (optional, and used to provide the IPsec anti-replay feature). 198 3. Issues Resolved from IPsec Cluster Problem Statement 200 The IPsec Cluster Problem Statement [RFC6027] enumerates the problems 201 raised by IPsec clusters. The following table lists the problem 202 statement's sections that are resolved by this document. 203 o 3.2. Lots of Long Lived State 204 o 3.3. IKE Counters 205 o 3.4. Outbound SA Counters 206 o 3.5. Inbound SA Counters 207 o 3.6. Missing Synchronization Messages 208 o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members 209 * 3.7.1. Outbound SAs using counter modes 210 o 3.8. Different IP addresses for IKE and IPsec 211 o 3.9. Allocation of SPIs 213 The main problem areas are solved using the protocol extension 214 defined below, and additionally this document provides implementation 215 advice for other issues, given as follows. 216 o 3.2 This section mentions that there is a large amount of state 217 that needs to be synchronized. However if state is not 218 synchronized, this is not really an interesting cluster: failover 219 is equivalent to a reboot of the cluster member, and so the issue 220 need not be solved with protocol extensions. 221 o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see 222 Section 4, for more details. 223 o 3.7 is an implementation problem that needs to be solved while 224 building IPsec clusters. However, the peers should be required to 225 accept multiple parallel SAs for 3.7.1. 226 o 3.8 can be solved by using the IKEv2 Redirect mechanism [RFC5685]. 227 o 3.9 discusses the avoidance of collisions where the same SPI value 228 is used by multiple cluster members. This is outside the 229 document's scope since the problem needs to be solved internally 230 to the cluster and does not involve the peer. 232 4. The IKEv2/IPsec SA Counter Synchronization Problem 234 The IKEv2 protocol [RFC5996] states that "An IKE endpoint MUST NOT 235 exceed the peer's stated window size for transmitted IKE requests". 237 All IKEv2 messages are required to follow a request-response 238 paradigm. The initiator of an IKEv2 request MUST retransmit the 239 request, until it has received a response from the peer. IKEv2 240 introduces a windowing mechanism that allows multiple requests to be 241 outstanding at a given point of time, but mandates that the sender 242 window should not move until the oldest message sent from one peer to 243 another is acknowledged. Loss of even a single message leads to 244 repeated retransmissions followed by an IKEv2 SA teardown if the 245 retransmissions are unacknowledged. 247 An IPsec Hot Standby Cluster is required to ensure that in the case 248 of failover, the standby member becomes active immediately. The 249 standby member is expected to have the exact value of the Message ID 250 counter as the active member had before failover. Even assuming the 251 best effort to update the Message ID values from active to standby 252 member, the values at the standby member can still be stale due to 253 the following reasons: 254 o The standby member is unaware of the last message that was 255 received and acknowledged by the previously active member, as the 256 failover event could have happened before the standby member could 257 be updated. 258 o The standby member does not have information about on-going 259 unacknowledged requests received by the previously active member. 260 As a result after the failover event, the newly active member 261 cannot retransmit those requests. 263 When a standby member takes over as the active member, it can only 264 initialize the Message ID values from the previously updated values. 265 This would make it reject requests from the peer when these values 266 are stale. Conversely, the standby member may end up reusing a stale 267 Message ID value which would cause the peer to drop the request. 268 Eventually there is a high probability of the IKEv2 and corresponding 269 IPsec SAs getting torn down simply because of a transitory Message ID 270 mismatch and retransmission of requests, negating the benefits of the 271 high availability cluster despite the periodic update between the 272 cluster members. 274 A similar issue is also observed with IPsec anti-replay counters if 275 anti-replay protection/ESN is implemented, which is commonly the 276 case. Regardless of how well the ESP and AH SA counters are 277 synchronized from the active to the standby member, there is a chance 278 that the standby member would end up with stale counter values. The 279 standby member would then use those stale counter values when sending 280 IPsec packets. The peer would reject/drop such packets since when 281 the anti-replay protection feature is enabled, duplicate use of 282 counters is not allowed. Note that IPsec allows the sender to skip 283 some counter values and continue sending with higher counter values. 285 We conclude that a mechanism is required to ensure that the standby 286 member has correct Message ID and IPsec counter values when it 287 becomes active, so that sessions are not torn down as a result of 288 mismatched counters. 290 5. Counter Synchronization Solution 292 In general, when the standby member becomes the active member after 293 the failover event, the standby member sends an authenticated IKEv2 294 request to the peer, asking it to send its SA counter values. 296 The standby member then updates its own SA counter values and can 297 resume normally sending and receiving protocol messages. 299 First, the peer MUST negotiate its ability to support IKEv2 Message 300 ID synchronization with the active member of the cluster by sending 301 the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in the IKE_AUTH 302 exchange. 304 Similarly, to support IPsec Replay Counter synchronization, the peer 305 MUST negotiate this capability with the active member of the cluster 306 by sending the IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notification in 307 the IKE_AUTH exchange. 309 Peer Active Member 310 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 311 HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH, 312 [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] 313 [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] 314 SAi2, TSi, TSr} ----------> 316 <-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH, 317 [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] 318 [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] SAr2, TSi, TSr} 320 When the peer and active member both support SA counter 321 synchronization, the active member MUST inform the standby member of 322 the SA counter synchronization capability after the establishment of 323 the IKE SA. The standby member can then use this capability when it 324 becomes the active member after a failover event. 326 After the failover event, when the standby member becomes active, it 327 has to request the SA counters from the peer. The newly-active 328 member initiates the synchronization request with an Informational 329 exchange with Message ID zero containing either the notification 330 IKEV2_MESSAGE_ID_SYNC or the two notifications IKEV2_MESSAGE_ID_SYNC 331 and IPSEC_REPLAY_COUNTER_SYNC, depending on whether the 332 synchronization is to be done for IKEv2 Message IDs or for both IKEv2 333 Message IDs and IPsec replay counters. If the active member has only 334 negotiated synchronization of IPsec Replay Counters, the request is 335 sent as a regular IKEv2 Informational exchange (i.e. with a non-zero 336 Message ID) containing the notification IPSEC_REPLAY_COUNTER_SYNC. 338 The initiator of the IKEv2 Message ID synchronization request sends 339 its expected send and receive Message ID values and "failover count" 340 in a IKEV2_MESSAGE_ID_SYNC notification. The responder compares the 341 received values with its local values. For both send and receive 342 values, The higher between the cluster member's and the local value 343 is selected, and sent in the response message with the notification 344 IKEV2_MESSAGE_ID_SYNC. The initiator now updates its send and 345 receive IKEv2 Message IDs to the values received in the response and 346 can now start a normal IKEv2 message exchange. 348 The initiator of an IPsec Replay Counter synchronization sends the 349 incremented outgoing IPsec SA reply counter value and a "failover 350 count" in a IPSEC_REPLAY_COUNTER_SYNC notification in IKEv2 351 INFORMATIONAL exchange. The responder updates its incoming IPsec SA 352 counter values according to the received value. The responder now 353 sends its own incremented outgoing IPsec SA Replay Counter value in a 354 synchronization response message, with the same 355 IPSEC_REPLAY_COUNTER_SYNC notification. The initiator can now update 356 its incoming IPsec SA counter to values received in the response 357 message and can start normal IPsec data traffic. 359 The IKEV2_MESSAGE_ID_SYNC notification payload contain nonce data to 360 avoid a denial-of-service (DoS) attack due to replay of SA counter 361 synchronization response. The nonce values are selected randomly on 362 each new notification and MUST be validated by the receiver. The 363 nonce data sent in the response MUST match the nonce data sent by the 364 newly-active member in its request. If the nonce data received in 365 the response does not match the request's nonce data, the cluster 366 member MUST silently discard this response, and SHOULD revert to 367 normal IKEv2 behavior of retransmitting the request and waiting for a 368 genuine a reply from the peer. Eventually this might result in the 369 SA being torn down because of excessive retransmissions. 371 Standby [Newly Active] Member Peer 372 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 373 HDR, SK {N(IKEV2_MESSAGE_ID_SYNC), 374 [N(IPSEC_REPLAY_COUNTER_SYNC)]} --------> 375 <--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC), 376 [N(IPSEC_REPLAY_COUNTER_SYNC)]} 378 Alternatively, if only IPsec Replay Counter synchronization is 379 desired, a normal Information exchange is used, where the Message ID 380 is non-zero: 382 Standby [Newly Active] Member Peer 383 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 384 HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} --------> 386 <--------- HDR, SK {N(IPSEC_REPLAY_COUNTER_SYNC)} 388 6. IKEv2/IPsec Synchronization Notification Payloads 390 This section lists the new notification payloads types defined by 391 this extension. 393 6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED 395 IKEV2_MESSAGE_ID_SYNC_SUPPORTED: This notification payload is 396 included in the IKE_AUTH request/response to indicate support of the 397 IKEv2 Message ID synchronization mechanism described in this 398 document. 400 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Next Payload |C| RESERVED | Payload Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 409 'Notify Message Type' fields are the same as described in Section 3 410 of [RFC5996] . The 'SPI Size' field MUST be set to 0 to indicate 411 that the SPI is not present in this message. The 'Protocol ID' MUST 412 be set to 0, since the notification is not specific to a particular 413 security association. The 'Payload Length' field is set to the 414 length in octets of the entire payload, including the generic payload 415 header. The 'Notify Message Type' field is set to indicate 416 IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data 417 associated with this notification. 419 6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED 421 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED: This notification payload is 422 included in the IKE_AUTH request/response to indicate support for the 423 IPsec SA Replay Counter synchronization mechanism described in this 424 document. 426 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Next Payload |C| RESERVED | Payload Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 435 'Notify Message Type' fields are the same as described in Section 3 436 of [RFC5996] . The 'SPI Size' field MUST be set to 0 to indicate 437 that the SPI is not present in this message. The 'Protocol ID' MUST 438 be set to 0, since the notification is not specific to a particular 439 security association. The 'Payload Length' field is set to the 440 length in octets of the entire payload, including the generic payload 441 header. The 'Notify Message Type' field is set to indicate 442 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no 443 data associated with this notification. 445 6.3. IKEV2_MESSAGE_ID_SYNC 447 IKEV2_MESSAGE_ID_SYNC : This notification payload type (value TBD by 448 IANA) is defined to synchronize the IKEv2 Message ID values between 449 the newly-active (formerly standby) cluster member and the peer. 451 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Next Payload | RESERVED | Payload Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Failover Count | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Nonce Data | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | EXPECTED_SEND_REQ_MESSAGE_ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | EXPECTED_RECV_REQ_MESSAGE_ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 It contains the following data. 467 o Failover Count (4 octets): a running count of failover events 468 between cluster members, it is initialized to 0 when the cluster 469 is first set up, and incremented by 1 upon each failover event. 470 o Nonce Data (4 octets): the random nonce data. The data should be 471 identical in the synchronization request and response. 472 o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): this field is used by the 473 sender of this notification payload to indicate the Message ID it 474 will use in the next request that it will send to the other 475 protocol peer. 476 o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): this field is used by the 477 sender of this notification payload to indicate the Message ID it 478 is expecting in the next request to be received from the other 479 protocol peer. 481 6.4. IPSEC_REPLAY_COUNTER_SYNC 483 IPSEC_REPLAY_COUNTER_SYNC: This notification payload type (value TBD 484 by IANA) is defined to synchronize the IPsec SA Replay Counters 485 between the newly-active (formerly standby) cluster member and the 486 peer. Since there may be numerous IPsec SAs established under a 487 single IKE SA, we do not directly synchronize the value of each one. 488 Instead, a delta value is sent and all Replay Counters for child SAs 489 of this IKE SA are incremented by the same value. Note that this 490 solution requires that all these Child SAs either use or do not use 491 Extended Sequence Numbers [RFC4301]. 493 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Next Payload |E| RESERVED | Payload Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Outgoing IPsec SA counter | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 The notification payload contains the following data. 504 o E (1 bit): The ESN bit. This MUST be 1 if the IPsec SAs were 505 established with Extended Sequence Numbers. 506 o Outgoing IPsec SA delta value (4 or 8 octects): The sender will 507 increment the all the Child SA Replay Counters for its outgoing 508 traffic by this value. The size of this field depends on ESN bit: 509 if the ESN bit is 1, its size is 8 octets, otherwise it is 4 510 octets. 512 7. Implementation Details 514 The Message ID value used in the Informational exchange that contains 515 the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not 516 validated upon receipt as required by normal IKEv2 windowing. The 517 Message ID zero MUST be accepted only in an Informational exchange 518 that contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any 519 Informational exchange has a Message ID zero, but not this 520 notification type, such messages MUST be discarded upon decryption 521 and the INVALID_SYNTAX notification SHOULD be sent. Other payloads 522 MUST NOT be sent in this Informational exchange. Whenever an 523 IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification 524 payload is received with an invalid failover count or invalid nonce 525 data, the event SHOULD be logged. 527 The standby member can initiate the synchronization of IKEv2 Message 528 ID's under different circumstances. 529 o When it receives a problematic IKEv2/IPsec packet, i.e. a packet 530 outside its expected receive window. 531 o When it has to send the first IKEv2/IPsec packet after a failover 532 event. 533 o When it has just received control from active member and wishes to 534 update the values proactively, so that it need not start this 535 exchange later, when sending or receiving the request. 537 The standby member can initiate the synchronization of IPsec SA 538 Replay Counters: 539 o If there has been traffic using the IPsec SA in the recent past 540 and the standby member suspects that its Replay Counter may be 541 stale. 543 Since there can be a large number of sessions at the standby member, 544 and sending synchronization exchanges for all of them may result in 545 overload, the standby member can choose to initiate the exchange in a 546 "lazy" fashion: only when it has to send or receive the request. In 547 general, the standby member is free to initiate this exchange at its 548 discretion. 550 A cluster member which has not announced its capability by using 551 IKEV2_MESSAGE_ID_SYNC_SUPPORTED MUST NOT send or accept the 552 notification IKEV2_MESSAGE_ID_SYNC. 554 A cluster member which has not announced its capability by using 555 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED MUST NOT send or accept the 556 notification IPSEC_REPLAY_COUNTER_SYNC. 558 If a peer receives a IKEV2_MESSAGE_ID_SYNC or 559 IPSEC_REPLAY_COUNTER_SYNC request although it had not announced the 560 appropriate capability in the IKE_AUTH exchange, then it MUST 561 silently ignore this message. 563 As usual in IKEv2, if any of the notification payloads defined here 564 is malformed, the receiver must announce this fact using the 565 INVALID_SYNTAX notification. 567 8. Step by Step Details 569 This section goes through the sequence of steps of a typical failover 570 event, where the IKEv2 Message ID values are synchronized. 571 o The active cluster member and the peer device establish the 572 session. They both announce the capability to synchronize counter 573 information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED 574 notification in the IKE_AUTH Exchange. 575 o The active member dies, and a standby member takes over. The 576 standby member sends its own idea of the IKE Message IDs (both 577 incoming and outgoing) to the peer in an Informational message 578 exchange with Message ID zero. 579 o The peer first authenticates the message and then validates the 580 failover count. The peer compares the received values with the 581 values available locally and picks the higher value. It then 582 updates its Message IDs with the higher values and also propose 583 the same values in its response. 584 o The peer should not wait for any pending responses while 585 responding with the new Message ID values. For example, if the 586 window size is 5 and the peer's window is 3-7, and if the peer has 587 sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5, 588 6, 7 but not for 3, then it should include the value 8 in its 589 EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a 590 response to message 3 anymore. 591 o Similarly, the peer should also not wait for pending (incoming) 592 requests. For example if the window size is 5 and the peer's 593 window is 3-7 and if the peer has received requests 4, 5, 6, 7 but 594 not 3, then it should send the value 8 in the 595 EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to 596 receive message 3 anymore. 598 In case multiple successive failover events and sync request getting 599 lost, the failover count value at peer will not be updated and new 600 standby member will become active with incremented failover count 601 value. So, peer can receive valid failover count value which is not 602 just incremented by 1 in case of multiple failover. Accepting 603 incremented failover count within a range is allowed and increases 604 interoperability. 606 9. Security Considerations 608 Since Message ID synchronization messages need to be sent with 609 Message ID zero, they are potentially vulnerable to replay attacks. 610 Because of the semantics of this protocol, these can only be denial- 611 of-service (DoS) attacks, and we are aware of two variants. 612 o Replay of Message ID synchronization request: This is countered by 613 use of the Failover Count, since synchronization starts after the 614 failover event and each member of the cluster needs to be aware of 615 the failover event. The receiver of the synchronization request 616 should verify the received Failover Count and maintain its own 617 copy of it. If a peer receives a synchronization request with an 618 already observed Failover Count, it can safely discard the request 619 if it has already received valid IKEv2 request/response from other 620 side peer after sync exchange. The peer will be not be aware that 621 sync response has reached to other side till it receives a valid 622 IKEv2 request/response from other side. The peer can send the 623 cached response for sync request till it has not received valid 624 request/response from other side peer or failover count has not 625 increased. 626 o Replay of the Message ID synchronization response: This is 627 countered by sending the nonce data along with the synchronization 628 payload. The same nonce data has to be returned in response. 629 Thus the standby member will accept a reply only for the current 630 request. After it receives a valid response, it MUST NOT process 631 the same response again and MUST discard any additional responses. 633 10. Interaction with other drafts 635 The usage scenario of the IKEv2/IPsec SA counter synchronization 636 proposal is that an IKEv2 SA has been established between the active 637 member of a hot-standby cluster and a peer, then a failover event 638 occurred with the standby member becoming active. The proposal 639 further assumes that the IKEv2 SA state was continuously synchronized 640 between the active and standby members of the cluster before the 641 failover event. 642 o Session resumption [RFC5723] assumes that a peer (client or 643 initiator) detects the need to re-establish the session. In 644 IKEv2/IPsec SA counter synchronization, it is the newly-active 645 member (a gateway or responder) that detects the need to 646 synchronize the SA counter after the failover event. Also in a 647 hot-standby cluster, the peer establishes the IKEv2/IPsec session 648 with a single IP address that represents the whole cluster, so the 649 peer normally does not detect the event of failover in the cluster 650 unless the standby member takes too long to become active and the 651 IKEv2 SA times out by use of the IKEv2 liveness check mechanism. 652 To conclude, session resumption and SA counter synchronization 653 after failover are mutually exclusive. 654 o The IKEv2 Redirect mechanism for load-balancing [RFC5685] can be 655 used either during the initial stages of SA setup (the IKE_SA_INIT 656 and IKE_AUTH exchanges) or after session establishment. SA 657 counter synchronization is only useful after the IKE SA has been 658 established and a failover event has occurred. So, unlike 659 Redirect, it is irrelevant during the first two exchanges. 660 Redirect after the session has been established is mostly useful 661 for timed or planned shutdown/maintenance. A real failover event 662 cannot be detected by the active member ahead of time, and so 663 using Redirect after session establishment is not possible in the 664 case of failover. So, Redirect and SA counter synchronization 665 after failover are mutually exclusive. 666 o IKEv2 Failure Detection [I-D.ietf-ipsecme-failure-detection] 667 solves a similar problem where the peer can rapidly detect that a 668 cluster member has crashed based on a token. It is unrelated to 669 the current scenario because the goal in failover is for the peer 670 not to notice that a failure has occurred. 672 11. IANA Considerations 674 This document introduces four new IKEv2 Notification Message types as 675 described in Section 6.The new Notify Message Types must be assigned 676 values between 16396 and 40959. 677 o IKEV2_MESSAGE_ID_SYNC_SUPPORTED. 678 o IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED. 679 o IKEV2_MESSAGE_ID_SYNC. 680 o IPSEC_REPLAY_COUNTER_SYNC. 682 12. Acknowledgements 684 We would like to thank Pratima Sethi and Frederic Detienne for their 685 review comments and valuable suggestions for the initial version of 686 the document. 688 We would also like to thank the following people (in alphabetical 689 order) for their review comments and valuable suggestions: Dan 690 Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, Pekka 691 Riikonen, and Yaron Sheffer. 693 13. Change Log 695 This section lists all the changes in this document. 697 NOTE TO RFC EDITOR: Please remove this section before publication. 699 13.1. Draft -02 701 Addressed comments by Yaron Sheffer posted on the WG mailing list. 703 Numerous editorial changes. 705 13.2. Draft -01 707 Added "Multiple and Simultaneous failover' scenarios as pointed out 708 by Pekka Riikonen. 710 Now document provides a mechanism to sync either IKEv2 message or 711 IPsec replay counter or both to cater different types of 712 implementations. 714 HA cluster's "failover count' is used to encounter replay of sync 715 requests by attacker. 717 The sync of IPsec SA replay counter optimized to to have just one 718 global bumped-up outgoing IPsec SA counter of ALL Child SAs under an 719 IKEv2 SA. 721 The examples added for IKEv2 Message ID sync to provide more clarity. 723 Some edits as per comments on mailing list to enhance clarity. 725 13.3. Draft -00 727 Version 00 is identical to 728 draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document. 730 Added IPSECME WG HA design team members as authors. 732 Added comment in Introduction to discuss the window sync process on 733 WG mailing list to solve some concerns. 735 14. References 737 14.1. Normative References 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 743 Internet Protocol", RFC 4301, December 2005. 745 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 746 "Internet Key Exchange Protocol Version 2 (IKEv2)", 747 RFC 5996, September 2010. 749 [RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, 750 October 2010. 752 14.2. Informative References 754 [I-D.ietf-ipsecme-failure-detection] 755 Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A 756 Quick Crash Detection Method for IKE", 757 draft-ietf-ipsecme-failure-detection-01 (work in 758 progress), October 2010. 760 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 761 the Internet Key Exchange Protocol Version 2 (IKEv2)", 762 RFC 5685, November 2009. 764 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 765 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 766 January 2010. 768 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 769 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 771 Appendix A. IKEv2 Message ID Sync Examples 773 This (non-normative) section presents some examples that illustrate 774 how the IKEv2 Message ID values are synchronized. We use a tuple 775 notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and 776 EXPECTED_RECV_REQ_MESSAGE_ID on a member as 777 (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID). 779 A.1. Normal Failover - Example 1 781 Standby (Newly Active) Member Peer 782 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 783 Sync Request (2, 3) --------> 785 Peer has the values (4, 5) so it sends 786 <------------- (4, 5) as the Sync Response 788 A.2. Normal Failover - Example 2 790 Standby (Newly Active) Member Peer 791 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 792 Sync Request (2, 5) --------> 794 Peer has the values (2, 4) so it sends 795 <-------------(5, 4) as the Sync Response 797 A.3. Simultaneous Failover 799 In the case of simultaneous failover, both sides send the 800 synchronization request, but whichever side has the higher value will 801 be eventually synchronized. 803 Standby (Newly Active) Member Peer 804 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 806 Sync Request (4,4) -----> 808 <-------------- Sync Request (5,5) 810 Sync Response (5,5) ----> 812 <-------- Sync Response (5,5) 814 Authors' Addresses 816 Raj Singh (Editor) 817 Cisco Systems, Inc. 818 Divyashree Chambers, B Wing, O'Shaugnessy Road 819 Bangalore, Karnataka 560025 820 India 822 Phone: +91 80 4301 3320 823 Email: rsj@cisco.com 824 Kalyani Garigipati 825 Cisco Systems, Inc. 826 Divyashree Chambers, B Wing, O'Shaugnessy Road 827 Bangalore, Karnataka 560025 828 India 830 Phone: +91 80 4426 4831 831 Email: kagarigi@cisco.com 833 Yoav Nir 834 Check Point Software Technologies Ltd. 835 5 Hasolelim St. 836 Tel Aviv 67897 837 Israel 839 Email: ynir@checkpoint.com 841 Dacheng Zhang 842 Huawei Technologies Ltd. 844 Email: zhangdacheng@huawei.com