idnits 2.17.1 draft-ietf-ipsecme-ipsecha-protocol-06.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 (May 6, 2011) is 4732 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) -- Looks like a reference, but probably isn't: 'CERT' on line 446 -- Looks like a reference, but probably isn't: 'CERTREQ' on line 446 -- Looks like a reference, but probably isn't: 'IDr' on line 446 ** Obsolete normative reference: RFC 5996 (ref. '2') (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). 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: November 7, 2011 Y. Nir 6 Check Point 7 Y. Sheffer 8 Porticor 9 D. Zhang 10 Huawei 11 May 6, 2011 13 Protocol Support for High Availability of IKEv2/IPsec 14 draft-ietf-ipsecme-ipsecha-protocol-06 16 Abstract 18 The IPsec protocol suite is widely used for business-critical network 19 traffic. In order to make IPsec deployments highly available, more 20 scalable and failure-resistant, they are often implemented as IPsec 21 High Availability (HA) clusters. However there are many issues in 22 IPsec HA clustering, and in particular in IKEv2 clustering. An 23 earlier document, "IPsec Cluster Problem Statement", enumerates the 24 issues encountered in the IKEv2/IPsec HA cluster environment. This 25 document resolves these issues with the least possible change to the 26 protocol. 28 This document defines an extension to the IKEv2 protocol to solve the 29 main issues of "IPsec Cluster Problem Statement" in the commonly 30 deployed hot-standby cluster, and provides implementation advice for 31 other issues. The main issues solved are the synchronization of 32 IKEv2 Message ID counters, and of IPsec Replay Counters. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 7, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 7 70 3.1. Large Amount of State . . . . . . . . . . . . . . . . . . 7 71 3.2. Multiple Members Using the Same SA . . . . . . . . . . . . 8 72 3.3. Avoiding Collisions in SPI Number Allocation . . . . . . . 8 73 3.4. Interaction with Counter Modes . . . . . . . . . . . . . . 8 74 4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 9 75 5. SA Counter Synchronization Solution . . . . . . . . . . . . . 10 76 5.1. Processing Rules for IKE Message ID Synchronization . . . 12 77 5.2. Processing Rules for IPsec Replay Counter 78 Synchronization . . . . . . . . . . . . . . . . . . . . . 13 79 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 13 80 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 14 81 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 14 82 6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 15 83 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 15 84 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 16 85 8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 17 86 8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 17 87 8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 17 88 8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 17 89 9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 18 90 10. Interaction with other specifications . . . . . . . . . . . . 18 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 94 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 14.1. Draft -06 . . . . . . . . . . . . . . . . . . . . . . . . 21 96 14.2. Draft -05 . . . . . . . . . . . . . . . . . . . . . . . . 21 97 14.3. Draft -04 . . . . . . . . . . . . . . . . . . . . . . . . 21 98 14.4. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 21 99 14.5. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 21 100 14.6. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 21 101 14.7. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 22 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 15.1. Normative References . . . . . . . . . . . . . . . . . . . 22 104 15.2. Informative References . . . . . . . . . . . . . . . . . . 22 105 Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 23 106 A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 23 107 A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 24 108 A.3. Normal Failover - Example 3 . . . . . . . . . . . . . . . 24 109 A.4. Simultaneous Failover . . . . . . . . . . . . . . . . . . 24 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 112 1. Introduction 114 The IPsec protocol suite, including IKEv2, is a major building block 115 of virtual private networks (VPNs). In order to make such VPNs 116 highly available, more scalable and failure-resistant, these VPNs are 117 implemented as IKEv2/IPsec Highly Available (HA) clusters. However 118 there are many issues with the IKEv2/IPsec HA cluster. Section 3 and 119 Section 4 below expand on the issues around the IKEv2/IPsec HA 120 cluster solution, issues which were first described in the Problem 121 Statement [4]. 123 In the case of a hot-standby cluster implementation of IKEv2/IPsec 124 based VPNs, the IKEv2/IPsec session is first established between the 125 peer and the active member of the cluster. Later, the active member 126 continuously syncs/updates the IKE/IPsec SA state to the standby 127 member of the cluster. This primary SA state sync-up takes place 128 upon each SA bring-up and/or rekey. Performing the SA state 129 synchronization/update for every single IKE and IPsec message is very 130 costly, so normally it is done periodically. As a result, when the 131 failover event happens, this is first detected by the standby member 132 and, possibly after a considerable amount of time, it becomes the 133 active member. During this failover process the peer is unaware of 134 the failover event, and keeps sending IKE requests and IPsec packets 135 to the cluster, as in fact it is allowed to do because of the IKEv2 136 windowing feature. After the newly-active member starts, it detects 137 the mismatch in IKE Message ID values and IPsec replay counters and 138 needs to resolve this situation. Please see Section 4 for more 139 details of the problem. 141 This document defines an extension to the IKEv2 protocol to solve the 142 main issues of IKE Message ID synchronization and IPsec SA replay 143 counter synchronization, and gives implementation advice to address 144 other issues. Following is a summary of the solutions provided in 145 this document: 147 o IKEv2 Message ID synchronization: this is done by syncing up the 148 expected send and receive Message ID values with the peer, and 149 updating the values at the newly active cluster member. 150 o IPsec Replay Counter synchronization: this is done by incrementing 151 the cluster's outgoing SA replay counter values by a "large" 152 number; in addition, the newly-active member requests the peer to 153 increment the replay counter values it is using for the peer's 154 outgoing traffic. 156 Although this document describes the IKEv2 Message ID and IPsec 157 replay counter synchronization in the context of an IPsec HA cluster, 158 the solution provided is generic and can be used in other scenarios 159 where IKEv2 Message ID or IPsec SA replay counter synchronization may 160 be required. 162 Implementations differ on the need to synchronize the IKEv2 Message 163 ID and/or IPsec replay counters. Both of these problems are handled 164 separately, using a separate notification for each capability. This 165 provides the flexibility of implementing either or both of these 166 solutions. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [1]. 174 "SA Counter Synchronization Request/Response" are the request viz. 175 response of the informational exchange defined in this document to 176 synchronize the IKEv2/IPsec SA counter information between one member 177 of the cluster and the peer. 179 Some of the terms listed below are reused from [4] with further 180 clarification in the context of the current document. 182 o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one 183 of the members is active at any one time. This member is also 184 referred to as the "active" member, whereas the other(s) are 185 referred to as "standby" members. VRRP [5] is one method of 186 building such a cluster. The goal of the Hot Standby Cluster is 187 to create the illusion of a single virtual gateway to the peer(s). 188 o "Active Member" is the primary member in the Hot-Standby cluster. 189 It is responsible for forwarding packets on behalf of the virtual 190 gateway. 191 o "Standby Member" is the primary backup member. This member takes 192 control, i.e. becomes the active member, after the failover event. 193 o "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec 194 connection with the Hot-Standby cluster. The Peer identifies the 195 cluster by the cluster's (single) IP address. If a failover event 196 occurs, the standby member of the cluster becomes active, and the 197 peer normally doesn't notice that failover has taken place. 198 Although we treat the peer as a single entity, it may also be a 199 cluster. 200 o "Multiple failover" is the situation where, in a cluster with 201 three or more members, multiple failover events happen in rapid 202 succession, e.g. from M1 to M2, and then to M3. It is our goal 203 that the implementation should be able to handle this situation, 204 i.e. to handle the new failover event even if it is still 205 processing the old failover. 207 o "Simultaneous failover" is the situation where two clusters have 208 an IPsec connection between them, and failover happens at both 209 ends at the same time. It is our goal that implementations should 210 be able to handle simultaneous failover. 212 The generic term "IKEv2/IPsec SA Counters" is used throughout this 213 document. This term refers to both IKEv2 Message ID counters and 214 IPsec replay counters. According to the IPsec standards, the IKEv2 215 Message ID counter is mandatory, and used to ensure reliable delivery 216 as well as to protect against message replay in IKEv2; the IPsec SA 217 replay counters are optional, and are used to provide the IPsec anti- 218 replay feature. 220 Some of these terms are used in the following architectural diagram. 222 +---------------+ 223 | | 224 | Hot Standby | 225 | Cluster | 226 | | 227 | +---------+ | 228 | | | | 229 | | Active | | 230 | | | | 231 | | Member | | 232 | | | | 233 | +---------+ | 234 | ^ | 235 +---------+ | Sync | | 236 | | | Channel | | 237 | IPsec | IKE/IPsec Traffic | | | 238 | | <=============================> | | | 239 | Peer | | | | 240 | | | | | 241 +---------+ | | | 242 | v | 243 | +---------+ | 244 | | | | 245 | | Standby | | 246 | | | | 247 | | Member | | 248 | | | | 249 | +---------+ | 250 +---------------+ 252 An IPsec Hot Standby Cluster 254 3. Issues Resolved from IPsec Cluster Problem Statement 256 The IPsec Cluster Problem Statement [4] enumerates the problems 257 raised by IPsec clusters. The following table lists the problem 258 statement's sections that are resolved by this document. 259 o 3.2. Lots of Long Lived State 260 o 3.3. IKE Counters 261 o 3.4. Outbound SA Counters 262 o 3.5. Inbound SA Counters 263 o 3.6. Missing Synchronization Messages 264 o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members 265 * 3.7.1. Outbound SAs using counter modes 266 o 3.8. Different IP addresses for IKE and IPsec 267 o 3.9. Allocation of SPIs 269 The main problem areas are solved using the protocol extension 270 defined below, starting with Section 5; additionally, this section 271 provides implementation advice for other issues in the following 272 subsections. Implementers should note that these subsections include 273 a number of new security-critical requirements. 275 3.1. Large Amount of State 277 Section 3.2 of the Problem Statement mentions that a lot of state 278 needs to be synchronized for a cluster to be transparent. The actual 279 volume of that data is very much implementation-dependent, and even 280 for the same implementation, the amounts of data may vary wildly. An 281 IPsec gateway used for inter-domain VPN with a dozen other gateways, 282 and having SAs that are rekeyed every 8 hours, will need a lot less 283 synchronization traffic than a similar gateway used for remote 284 access, and supporting 10,000 clients. This is because counter 285 synchronization is proportional to the number of SAs and requires 286 little data, and the setting up of an SA requires a lot of data. 287 Additionally, remote access IKE and IPsec SA setup tend to happen at 288 a particular time of day, so the example gateway with the 10,000 289 clients may see 30-50 IKE SA setups per second at 9:00 AM. This 290 would require very heavy synchronization traffic over that short 291 period of time. 293 If a large volume of traffic is necessary, it may be advisable to use 294 a dedicated high-speed network interface for synch traffic. When 295 packet loss can be made extremely low, it may be advisable to use a 296 stateless transport such as UDP, to minimize network overhead. 298 If these methods are insufficient, it may be prudent that for some 299 SAs the entire state is not synchronized. Instead, only an 300 indication of the SA's existence is synchronized. This, in 301 combination with a sticky solution (as described in section 3.7 of 302 the problem statement) ensures that the traffic from a particular 303 peer does not reach a different member before an actual failover 304 happens. When that happens, the method described in [6] can be used 305 to quickly force the peer to set up a new SA. 307 3.2. Multiple Members Using the Same SA 309 In a load-sharing cluster of the "duplicate" variety (see section 3.7 310 of the problem statement) multiple members may need to send traffic 311 with the same selectors. To actually use the same SA the cluster 312 would have to synchronize the Replay Counter after every packet, and 313 that would impose unreasonable requirements on the synch connection. 315 A far better solution would be to not synchronize the outbound SA, 316 and create multiple outbound SAs, one for each member. The problem 317 with this option is that the peer might view these multiple parallel 318 SAs as redundant, and tear down all but one of them. 320 Section 2.8 of [2] specifically allows multiple parallel SAs, but the 321 reason given for this is to have multiple SAs with different QoS 322 attributes. So while this is not a new requirement of IKEv2 323 implementations working with QoS, we re-iterate here that IPsec peers 324 MUST accept the long-term existence of multiple parallel SAs, even 325 when QoS mechanisms are not in use. 327 3.3. Avoiding Collisions in SPI Number Allocation 329 Section 3.9 of the problem statement describes the problem of two 330 cluster members allocating the same SPI number for two different SAs. 331 This would violate section 4.4.2.1 of [3]. There are several schemes 332 to allow implementations to avoid such collisions, such as 333 partitioning the SPI space, a request-response over the synch 334 channel, and locking mechanisms. We believe that these are 335 sufficiently robust and available so that we don't need to make an 336 exception to RFC 4301, and we can leave this problem for the 337 implementations to solve. Cluster members must not generate multiple 338 inbound SAs with the same SPI. 340 3.4. Interaction with Counter Modes 342 For SAs involving counter mode ciphers such as CTR [7] or GCM [8] 343 there is yet another complication. The initial vector for such modes 344 MUST NOT be repeated, and senders may use methods such as counters or 345 LFSRs to ensure this property. For an SA shared between multiple 346 active members (load sharing cases), implementations MUST ensure that 347 no initial vector is ever repeated. Similar concerns apply to an SA 348 failing over from one member to another. See [9] for a discussion of 349 this problem in another context. 351 Just as in the SPI collision problem, there are ways to avoid a 352 collision of initial vectors, and this is left up to implementations. 353 In the context of load sharing, parallel SAs are a simple solution to 354 this problem as well. 356 4. The IKEv2/IPsec SA Counter Synchronization Problem 358 The IKEv2 protocol [2] states that "An IKE endpoint MUST NOT exceed 359 the peer's stated window size for transmitted IKE requests". 361 All IKEv2 messages are required to follow a request-response 362 paradigm. The initiator of an IKEv2 request MUST retransmit the 363 request, until it has received a response from the peer. IKEv2 364 introduces a windowing mechanism that allows multiple requests to be 365 outstanding at a given point of time, but mandates that the sender's 366 window should not move until the oldest message it has sent is 367 acknowledged. Loss of even a single message leads to repeated 368 retransmissions followed by an IKEv2 SA teardown if the 369 retransmissions remain unacknowledged. 371 An IPsec Hot Standby Cluster is required to ensure that in the case 372 of failover, the standby member becomes active immediately. The 373 standby member is expected to have the exact value of the Message ID 374 counter as the active member had before failover. Even assuming the 375 best effort to update the Message ID values from active to standby 376 member, the values at the standby member can still be stale due to 377 the following reasons: 378 o The standby member is unaware of the last message that was 379 received and acknowledged by the previously active member, as the 380 failover event could have happened before the standby member could 381 be updated. 382 o The standby member does not have information about on-going 383 unacknowledged requests sent by the previously active member. As 384 a result after the failover event, the newly active member cannot 385 retransmit those requests. 387 When a standby member takes over as the active member, it can only 388 initialize the Message ID values from the previously updated values. 389 This would make it reject requests from the peer when these values 390 are stale. Conversely, the standby member may end up reusing a stale 391 Message ID value which would cause the peer to drop the request. 392 Eventually there is a high probability of the IKEv2 and corresponding 393 IPsec SAs getting torn down simply because of a transitory Message ID 394 mismatch and retransmission of requests, negating the benefits of the 395 high availability cluster despite the periodic update between the 396 cluster members. 398 A similar issue is also observed with IPsec anti-replay counters if 399 anti-replay protection is enabled, which is commonly the case. 400 Regardless of how well the ESP and AH SA counters are synchronized 401 from the active to the standby member, there is a chance that the 402 standby member would end up with stale counter values. The standby 403 member would then use those stale counter values when sending IPsec 404 packets. The peer would drop such packets since when the anti-replay 405 protection feature is enabled, duplicate use of counters is not 406 allowed. Note that IPsec allows the sender to skip some counter 407 values and continue sending with higher counter values. 409 We conclude that a mechanism is required to ensure that the standby 410 member has correct Message ID and IPsec counter values when it 411 becomes active, so that sessions are not torn down as a result of 412 mismatched counters. 414 5. SA Counter Synchronization Solution 416 This document defines two separate approaches to resolving the issues 417 of mismatched IKE Message ID values and IPsec counter values. 419 o In the case of IKE Message ID values, the newly active cluster 420 member and the peer negotiate a pair of new values so that future 421 IKE messages will not be dropped. 422 o For IPsec counter values, the newly-active member and the peer 423 both increment their respective counter values, "skipping forward" 424 by a large number, to ensure that no IPsec counters are ever 425 reused. 427 Although conceptually separate, the two synchronization processes 428 would typically take place simultaneously. 430 First, the peer and the active member of the cluster negotiate their 431 ability to support IKEv2 Message ID synchronization and/or IPsec 432 Replay Counter synchronization. This is done by exchanging one or 433 both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and 434 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH 435 exchange. When negotiating these capabilities, the responder MUST 436 NOT assert support of a capability unless such support was asserted 437 by the initiator. Only a capability whose support was asserted by 438 both parties can be used during the lifetime of the SA. The peer's 439 capabilities with regard to this extension are part of the IKEv2 SA 440 state, and thus MUST be shared between the cluster members. 442 This per-IKE SA information is shared with the other cluster members. 444 Peer Active Member 445 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 446 HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH, 447 [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] 448 [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] 449 SAi2, TSi, TSr} ----------> 451 <-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH, 452 [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] 453 [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] SAr2, TSi, TSr} 455 After a failover event, the standby member MAY use the IKE Message ID 456 and/or IPsec Replay Counter synchronization capability when it 457 becomes the active member, and provided support for the capabilities 458 used has been negotiated. Following that, the peer MUST respond to 459 any synchronization message it receives from the newly-active cluster 460 member, subject to the rules noted below. 462 After the failover event, when the standby member becomes active, it 463 has to synchronize its SA counters with the peer. There are now four 464 possible cases: 466 1. The cluster member wishes to only perform IKE Message ID value 467 synchronization. In this case it initiates an Informational 468 exchange, with Message ID zero and the sole notification 469 IKEV2_MESSAGE_ID_SYNC. 470 2. If the newly-active member wishes to perform only IPsec replay 471 counter synchronization, it generates a regular IKEv2 472 Informational exchange using the current Message ID values, and 473 containing the IPSEC_REPLAY_COUNTER_SYNC notification. 474 3. If synchronization of both counters is needed, the cluster member 475 generates a zero-Message ID message as in case #1, and includes 476 both notifications in this message. 477 4. Lastly, the peer may not support this extension. This is known 478 to the newly-active member (because the cluster members must 479 share this information, as noted earlier). This case is the 480 existing IKEv2 behavior, and the IKE and IPsec SAs may or may not 481 survive the failover, depending on the exact state on the peer 482 and the cluster member. 484 This figure contains the IKE message exchange used for SA counter 485 synchronization. The following subsections describe the details of 486 the sender and receiver processing of each message. 488 Standby [Newly Active] Member Peer 489 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 490 HDR, SK {N(IKEV2_MESSAGE_ID_SYNC), 491 [N(IPSEC_REPLAY_COUNTER_SYNC)]} --------> 493 <--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)} 495 Alternatively, if only IPsec Replay Counter synchronization is 496 desired, a normal Informational exchange is used, where the Message 497 ID is non-zero: 499 Standby [Newly Active] Member Peer 500 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 501 HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} --------> 503 <--------- HDR 505 5.1. Processing Rules for IKE Message ID Synchronization 507 The newly-active member sends a request containing two counter 508 values, one for the member (itself) and another for the peer, as well 509 as a random nonce. We denote the values M1 and P1. The peer 510 responds with a message containing two counter values, M2 and P2 511 (note that the values appear in the opposite order in the 512 notification's payload). The goal of the rules below is to prevent 513 an attacker from replaying a synchronization message, thereby 514 invalidating IKE messages that are currently in process. 516 o M1 is the next sender's Message ID to be used by the member. M1 517 MUST be chosen so that it is larger than any value known to have 518 been used. It is RECOMMENDED to increment the known value at 519 least by the size of the IKE sender window. 520 o P1 SHOULD be 1 more than the last Message ID value received from 521 the peer, but may be any higher value. 522 o The member SHOULD communicate the sent values to the other cluster 523 members, so that if a second failover event takes place, the 524 synchronization message is not replayed. Such a replay would 525 result in the eventual deletion of the IKE SA (see below). 526 o The peer MUST silently drop any received synchronization message 527 if M1 is lower than or equal to the highest value it has seen from 528 the cluster. This includes any previous received synchronization 529 messages. 530 o M2 MUST be at least the higher of the received M1, and one more 531 than the highest sender value received from the cluster. This 532 includes any previous received synchronization messages. 534 o P2 MUST be the higher of the received P1 value, and one more than 535 the highest sender value used by the peer. 536 o The request contains a Nonce field. This field MUST be returned 537 in the response, unchanged. A response MUST be silently dropped 538 if the received Nonce does not match the one that was sent. 539 o Both the request and the response MUST NOT contain any additional 540 payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC 541 notification in the request. 542 o The request and the response MUST both be sent with a Message ID 543 value of zero. 545 5.2. Processing Rules for IPsec Replay Counter Synchronization 547 Upon failover, the newly-active member MUST increment its own Replay 548 Counter (the counter used for outgoing traffic), so as to prevent the 549 case of its traffic being dropped by the peer as replay. We note 550 that IPsec allows the replay counter to skip forward by any amount. 551 The estimate is based on the outgoing IPsec bandwidth and the 552 frequency of synchronization between cluster members. In those 553 implementations where it is difficult to estimate this value, the 554 counter can be incremented by a very large number, e.g. 2**30. In 555 the latter case, a rekey SHOULD follow shortly afterwards, to ensure 556 that the counter never wraps around. 558 Next, the cluster member estimates the number of incoming messages it 559 might have missed, using similar logic. The member sends out a 560 IPSEC_REPLAY_COUNTER_SYNC notification, either stand-alone or 561 together with a IKEV2_MESSAGE_ID_SYNC notification. 563 If the IPSEC_REPLAY_COUNTER_SYNC is included in the same message as 564 IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID 565 notification first (which might cause the entire message to be 566 dropped as a replay). Then, it MUST increment the replay counters 567 for all Child SAs associated with the current IKE SA by the amount 568 requested by the cluster member. 570 6. IKEv2/IPsec Synchronization Notification Payloads 572 This section lists the new notification payload types defined by this 573 extension. 575 All multi-octet fields representing integers are laid out in big 576 endian order (also known as "most significant byte first", or 577 "network byte order"). 579 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification 581 This notification payload is included in the IKE_AUTH request/ 582 response to indicate support of the IKEv2 Message ID synchronization 583 mechanism described in this document. 585 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Next Payload |C| RESERVED | Payload Length | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 594 'Notify Message Type' fields are the same as described in Section 3 595 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the 596 SPI is not present in this message. The 'Protocol ID' MUST be set to 597 0, since the notification is not specific to a particular security 598 association. The 'Payload Length' field is set to the length in 599 octets of the entire payload, including the generic payload header. 600 The 'Notify Message Type' field is set to indicate 601 IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data 602 associated with this notification. 604 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification 606 This notification payload is included in the IKE_AUTH request/ 607 response to indicate support for the IPsec SA Replay Counter 608 synchronization mechanism described in this document. 610 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Next Payload |C| RESERVED | Payload Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 619 'Notify Message Type' fields are the same as described in Section 3 620 of [2] . The 'SPI Size' field MUST be set to 0 to indicate that the 621 SPI is not present in this message. The 'Protocol ID' MUST be set to 622 0, since the notification is not specific to a particular security 623 association. The 'Payload Length' field is set to the length in 624 octets of the entire payload, including the generic payload header. 625 The 'Notify Message Type' field is set to indicate 626 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no 627 data associated with this notification. 629 6.3. The IKEV2_MESSAGE_ID_SYNC Notification 631 This notification payload type (value TBD by IANA) is defined to 632 synchronize the IKEv2 Message ID values between the newly-active 633 (formerly standby) cluster member and the peer. 635 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Next Payload |C| RESERVED | Payload Length | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Nonce Data | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | EXPECTED_SEND_REQ_MESSAGE_ID | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | EXPECTED_RECV_REQ_MESSAGE_ID | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 It contains the following data. 652 o Nonce Data (4 octets): the random nonce data. The data should be 653 identical in the synchronization request and response. 654 o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): this field is used by the 655 sender of this notification payload to indicate the Message ID it 656 will use in the next request that it will send to the other 657 protocol peer. 658 o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): this field is used by the 659 sender of this notification payload to indicate the Message ID it 660 is expecting in the next request to be received from the other 661 protocol peer. 663 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification 665 This notification payload type (value TBD by IANA) is defined to 666 synchronize the IPsec SA Replay Counters between the newly-active 667 (formerly standby) cluster member and the peer. Since there may be 668 numerous IPsec SAs established under a single IKE SA, we do not 669 directly synchronize the value of each one. Instead, a delta value 670 is sent and all Replay Counters for Child SAs of this IKE SA are 671 incremented by the same value. Note that this solution requires that 672 either all Child SAs use Extended Sequence Numbers or else that no 673 Child SA uses Extended Sequence Numbers [3]. This notification is 674 only sent by the cluster. 676 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Next Payload |C| RESERVED | Payload Length | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Incoming IPsec SA delta value | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 The notification payload contains the following data. 688 o Incoming IPsec SA delta value (4 or 8 octets): The sender requests 689 that the peer should increment all the Child SA Replay Counters 690 for the sender's incoming (the peer's outgoing) traffic by this 691 value. The size of this field depends on the ESN bit associated 692 with the Child SAs: if the ESN bit is 1, the field's size is 8 693 octets, otherwise it is 4 octets. We note that this constrains 694 the Child SAs of each IKE SA to either all have the ESN bit on or 695 off. 697 7. Implementation Details 699 This protocol does not change any of the existing IKEv2 rules 700 regarding Message ID values. 702 The standby member can initiate the synchronization of IKEv2 Message 703 ID's under different circumstances. 704 o When it receives a problematic IKEv2/IPsec packet, i.e. a packet 705 outside its expected receive window. 706 o When it has to send the first IKEv2/IPsec packet after a failover 707 event. 708 o When it has just received control from the active member and 709 wishes to update the values proactively, so that it need not start 710 this exchange later, when sending or receiving the request. 712 To clarify the first alternative: the normal IKE behavior of 713 rejecting out-of-window messages is not changed, but such messages 714 can still be a valid trigger for the exchange defined in this 715 document. To avoid DoS attacks resulting from replayed messages, the 716 peer MUST NOT initiate counter synchronization for any particular IKE 717 SA more than once per failover event. 719 The standby member can initiate the synchronization of IPsec SA 720 Replay Counters: 721 o If there has been traffic using the IPsec SA in the recent past 722 and the standby member suspects that its Replay Counter may be 723 stale. 725 Since there can be a large number of sessions at the standby member, 726 and sending synchronization exchanges for all of them may result in 727 overload, the standby member can choose to initiate the exchange in a 728 "lazy" fashion: only when it has to send or expects to receive 729 traffic from each peer. In general, the standby member is free to 730 initiate this exchange at its discretion. Implementation 731 considerations include the ability to survive a certain amount of 732 traffic loss, and the capacity of a cluster member to initiate 733 counter synchronization simultaneously with a large number of peers. 735 8. IKE SA and IPsec SA Message Sequencing 737 The straightforward definitions of message sequence numbers, 738 retransmissions and replay protection in IPsec and IKEv2 are strained 739 by the failover scenarios described in this document. This section 740 describes some policy choices that need to be made by implementations 741 in this setting. 743 8.1. Handling of Pending IKE Messages 745 After sending its "receive" counter, the cluster member MUST reject 746 (silently drop) any incoming IKE messages that are outside its 747 declared window. A similar rule applies to the peer. Local policies 748 vary, and strict implementations will reject any incoming IKE message 749 arriving before Message ID synchronization is complete. 751 8.2. Handling of Pending IPsec Messages 753 For IPsec, there is often a trade-off between security and 754 reliability of the protected protocols. Here again there is some 755 leeway for local policy. Some implementations might accept incoming 756 traffic that is outside the replay window for some time after the 757 failover event, and until the counters had been synchronized. Strict 758 implementations will only accept traffic that's inside the "safe" 759 window. 761 8.3. IKE SA Inconsistencies 763 IKEv2 is normally a reliable protocol. As long as an IKE SA is 764 valid, both peers share a single, consistent view of the IKE SA and 765 all associated Child SAs. Failover situations as described in this 766 document may involve forced deletion of IKE messages, resulting in 767 inconsistencies, such as Child SAs that exist on only one of the 768 peers. Such SAs might cause an INVALID_SPI to be returned when used 769 by that peer. Note that Sec. 1.5 of [2] allows but does not mandate 770 sending an INVALID_SPI notification in this case. 772 The Working Group discussed at some point a proposed set of rules for 773 dealing with such situations. However we believe that these 774 situations should be rare in practice; as a result the "default" 775 behavior of tearing down the entire IKE SA is to be preferred over 776 the complexity of dealing with a multitude of edge cases. 778 9. Step by Step Details 780 This section goes through the sequence of steps of a typical failover 781 event, looking at a case where the IKEv2 Message ID values are 782 synchronized. 783 o The active cluster member and the peer device establish the 784 session. They both announce the capability to synchronize counter 785 information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED 786 notification in the IKE_AUTH Exchange. 787 o Some time later, the active member dies, and a standby member 788 takes over. The standby member sends its own idea of the IKE 789 Message IDs (both incoming and outgoing) to the peer in an 790 Informational message exchange with Message ID zero. 791 o The peer first authenticates the message. The peer compares the 792 received values with the values available locally and picks the 793 higher value. It then updates its Message IDs with the higher 794 values and also propose the same values in its response. 795 o The peer should not wait for any pending responses while 796 responding with the new Message ID values. For example, if the 797 window size is 5 and the peer's window is 3-7, and if the peer has 798 sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5, 799 6, 7 but not for 3, then it should include the value 8 in its 800 EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a 801 response to message 3 anymore. 802 o Similarly, the peer should also not wait for pending (incoming) 803 requests. For example if the window size is 5 and the peer's 804 window is 3-7 and if the peer has received requests 4, 5, 6, 7 but 805 not 3, then it should send the value 8 in the 806 EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to 807 receive message 3 anymore. 809 10. Interaction with other specifications 811 The usage scenario of this IKEv2/IPsec SA counter synchronization 812 solution is that an IKEv2 SA has been established between the active 813 member of a hot-standby cluster and a peer, followed by a failover 814 event occurring and the standby member becoming active. The solution 815 further assumes that the IKEv2 SA state was continuously synchronized 816 between the active and standby members of the cluster before the 817 failover event. 818 o Session resumption [10] assumes that a peer (client or initiator) 819 detects the need to re-establish the session. In IKEv2/IPsec SA 820 counter synchronization, it is the newly-active member (a gateway 821 or responder) that detects the need to synchronize the SA counter 822 after the failover event. Also in a hot-standby cluster, the peer 823 establishes the IKEv2/IPsec session with a single IP address that 824 represents the whole cluster, so the peer normally does not detect 825 the event of failover in the cluster unless the standby member 826 takes too long to become active and the IKEv2 SA times out by use 827 of the IKEv2 liveness check mechanism. To conclude, session 828 resumption and SA counter synchronization after failover are 829 mutually exclusive: they are not expected to be used together, and 830 both features can coexist within the same implementation without 831 affecting each other. 832 o The IKEv2 Redirect mechanism for load-balancing [11] can be used 833 either during the initial stages of SA setup (the IKE_SA_INIT and 834 IKE_AUTH exchanges) or after session establishment. SA counter 835 synchronization is only useful after the IKE SA has been 836 established and a failover event has occurred. So, unlike 837 Redirect, it is irrelevant during the first two exchanges. 838 Redirect after the session has been established is mostly useful 839 for timed or planned shutdown/maintenance. A real failover event 840 cannot be detected by the active member ahead of time, and so 841 using Redirect after session establishment is not possible in the 842 case of failover. So, Redirect and SA counter synchronization 843 after failover are mutually exclusive, in the sense described 844 above. 845 o IKEv2 Failure Detection [6] solves a similar problem where the 846 peer can rapidly detect that a cluster member has crashed based on 847 a token. It is unrelated to the current scenario because the goal 848 in failover is for the peer not to notice that a failure has 849 occurred. 851 11. Security Considerations 853 Since Message ID synchronization messages need to be sent with 854 Message ID zero, they are potentially vulnerable to replay attacks. 855 Because of the semantics of this protocol, these can only be denial- 856 of-service (DoS) attacks, and we are aware of two variants. 857 o Replay of Message ID synchronization request: This is countered by 858 the requirement that the Send counter sent by the cluster member 859 should always be monotonically increasing, a rule that the peer 860 enforces by silently dropping messages that contradict it. 861 o Replay of the Message ID synchronization response: This is 862 countered by sending the nonce data along with the synchronization 863 payload. The same nonce data has to be returned in the response. 864 Thus the standby member will accept a reply only for the current 865 request. After it receives a valid response, it MUST NOT process 866 the same response again and MUST discard any additional responses. 868 As mentioned in Section 7, trigerring counter synchronization by out- 869 of-window, potentially replayed messages, could open a DoS 870 vulnerability. This risk is mitigated by the solution described in 871 that section. 873 12. IANA Considerations 875 This document introduces four new IKEv2 Notification Message types as 876 described in Section 6. The new Notify Message Types must be 877 assigned values between 16396 and 40959. 879 +-------------------------------------+-------------+ 880 | Name | Value | 881 +-------------------------------------+-------------+ 882 | IKEV2_MESSAGE_ID_SYNC_SUPPORTED | TBD by IANA | 883 | IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | TBD by IANA | 884 | IKEV2_MESSAGE_ID_SYNC | TBD by IANA | 885 | IPSEC_REPLAY_COUNTER_SYNC | TBD by IANA | 886 +-------------------------------------+-------------+ 888 13. Acknowledgements 890 We would like to thank Pratima Sethi and Frederic Detienne for their 891 review comments and valuable suggestions for the initial version of 892 the document. 894 We would also like to thank the following people (in alphabetical 895 order) for their review comments and valuable suggestions: Dan 896 Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and 897 Pekka Riikonen. 899 14. Change Log 901 This section lists all the changes in this document. 903 NOTE TO RFC EDITOR: Please remove this section before publication. 905 14.1. Draft -06 907 Applied multiple review comments, from Pekka Riikonen, Alexey 908 Melnikov, Stephen Farrel, Robert Sparks, Pete Resnick, Russ Housley 909 and Adrian Farrel. Added an architectural reference diagram. Added 910 a MUST requirement for cluster members to share peers' support of 911 this protocol, which had been implicit in previous versions. 913 14.2. Draft -05 915 Applied Sean Turner's review comments. 917 14.3. Draft -04 919 Extended Sec. 3 for better coverage of other IPsec cluster-related 920 issues, and how they are resolved within the existing standards. 922 14.4. Draft -03 924 Clarified the rules for Message ID sync, so that replay attacks can 925 be avoided without a failover counter. 927 Added wording regarding inconsistent IKE state (basically choosing to 928 ignore the problem) and further rules dealing with pending traffic. 930 The IPsec replay counter delta value now refers to incoming traffic. 931 The associated notification is only sent from the cluster to the 932 peer, and not back. 934 14.5. Draft -02 936 Addressed comments by Yaron Sheffer posted on the WG mailing list. 938 Numerous editorial changes. 940 14.6. Draft -01 942 Added "Multiple and Simultaneous failover" scenarios as pointed out 943 by Pekka Riikonen. 945 Now document provides a mechanism to sync either IKEv2 message or 946 IPsec replay counter or both to cater different types of 947 implementations. 949 HA cluster's "failover count' is used to encounter replay of sync 950 requests by attacker. 952 The sync of IPsec SA replay counter optimized to to have just one 953 global bumped-up outgoing IPsec SA counter of ALL Child SAs under an 954 IKEv2 SA. 956 The examples added for IKEv2 Message ID sync to provide more clarity. 958 Some edits as per comments on mailing list to enhance clarity. 960 14.7. Draft -00 962 Version 00 is identical to 963 draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document. 965 Added IPSECME WG HA design team members as authors. 967 Added comment in Introduction to discuss the window sync process on 968 WG mailing list to solve some concerns. 970 15. References 972 15.1. Normative References 974 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 975 Levels", BCP 14, RFC 2119, March 1997. 977 [2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 978 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 980 [3] Kent, S. and K. Seo, "Security Architecture for the Internet 981 Protocol", RFC 4301, December 2005. 983 15.2. Informative References 985 [4] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, 986 October 2010. 988 [5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 989 for IPv4 and IPv6", RFC 5798, March 2010. 991 [6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick 992 Crash Detection Method for IKE", 993 draft-ietf-ipsecme-failure-detection-08 (work in progress), 994 April 2011. 996 [7] Housley, R., "Using Advanced Encryption Standard (AES) Counter 997 Mode With IPsec Encapsulating Security Payload (ESP)", 998 RFC 3686, January 2004. 1000 [8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) 1001 in IPsec Encapsulating Security Payload (ESP)", RFC 4106, 1002 June 2005. 1004 [9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating 1005 Security Payload (ESP) and Authentication Header (AH) to 1006 Protect Group Traffic", RFC 6054, November 2010. 1008 [10] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol 1009 Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010. 1011 [11] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the 1012 Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, 1013 November 2009. 1015 Appendix A. IKEv2 Message ID Sync Examples 1017 This (non-normative) section presents some examples that illustrate 1018 how the IKEv2 Message ID values are synchronized. We use a tuple 1019 notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and 1020 EXPECTED_RECV_REQ_MESSAGE_ID on each protocol party as 1021 (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID). 1023 Note that if the IKE message counters are already synchronized (as in 1024 the first example), we expect the numbers to be reversed between the 1025 two sides. If one protocol party intends to send the next request as 1026 4, then the other expects the next received request to be 4. 1028 A.1. Normal Failover - Example 1 1030 Standby (Newly Active) Member Peer 1031 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1032 Sync Request (0, 5) --------> 1034 Peer has the values (5, 0) so it sends 1035 <------------- (5, 0) as the Sync Response 1037 In this example, the peer has most recently sent an IKE request with 1038 Message ID 4, and has never received a request. So the peer's 1039 expected values for the next pair of messages are (5, 0). These are 1040 the same values as received from the member and therefore they are 1041 sent as-is. 1043 A.2. Normal Failover - Example 2 1045 Standby (Newly Active) Member Peer 1046 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1047 Sync Request (2, 3) --------> 1049 Peer has the values (4, 5) so it sends 1050 <------------- (4, 5) as the Sync Response 1052 In this example, the peer has most recently sent an IKE message with 1053 the Message ID 3, and received one with ID 4. So the peer's expected 1054 values for the next pair of messages are (4, 5). These are both 1055 higher than the corresponding values just received from the member 1056 (the order of tuple members is reversed when doing this comparison!), 1057 and therefore they are sent as-is. 1059 A.3. Normal Failover - Example 3 1061 Standby (Newly Active) Member Peer 1062 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1063 Sync Request (2, 5) --------> 1065 Peer has the values (2, 4) so it sends 1066 <-------------(5, 4) as the Sync Response 1068 In this example, the newly active member expects to send the next IKE 1069 message with ID 2. It sends an expected receive value of 5, which is 1070 higher than the last ID value it has seen from the peer, because it 1071 believes some incoming messages may have been lost. The peer has 1072 last sent a message with ID 1, and received one with ID 3, indicating 1073 that the a couple of messages sent by the previously active member 1074 had not been synchronized into the other member. So the peer's next 1075 expected (send, receive) values are (2, 4). The peer replies with 1076 the maximum of the received and the expected value for both send and 1077 receive counters: (max(2, 5), max(4, 2)) = (5, 4). 1079 A.4. Simultaneous Failover 1081 In the case of simultaneous failover, both sides send their 1082 synchronization requests simultaneously. The eventual outcome of 1083 synchronization consists of the higher counter values. This is 1084 demonstrated in the following figure. 1086 Standby (Newly Active) Member Peer 1087 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1089 Sync Request (4,4) -----> 1091 <-------------- Sync Request (5,5) 1093 Sync Response (5,5) ----> 1095 <-------- Sync Response (5,5) 1097 Authors' Addresses 1099 Raj Singh (Editor) 1100 Cisco Systems, Inc. 1101 Divyashree Chambers, B Wing, O'Shaugnessy Road 1102 Bangalore, Karnataka 560025 1103 India 1105 Phone: +91 80 4301 3320 1106 Email: rsj@cisco.com 1108 Kalyani Garigipati 1109 Cisco Systems, Inc. 1110 Divyashree Chambers, B Wing, O'Shaugnessy Road 1111 Bangalore, Karnataka 560025 1112 India 1114 Phone: +91 80 4426 4831 1115 Email: kagarigi@cisco.com 1117 Yoav Nir 1118 Check Point Software Technologies Ltd. 1119 5 Hasolelim St. 1120 Tel Aviv 67897 1121 Israel 1123 Email: ynir@checkpoint.com 1124 Yaron Sheffer 1125 Porticor Cloud Security 1127 Email: yaronf.ietf@gmail.com 1129 Dacheng Zhang 1130 Huawei Technologies Ltd. 1132 Email: zhangdacheng@huawei.com