idnits 2.17.1 draft-jenkins-ipsec-rekeying-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '... (b) There SHOULD be two kinds o...' RFC 2119 keyword, line 226: '... implementation SHOULD begin using th...' RFC 2119 keyword, line 227: '...ound traffic and SHOULD continue to su...' RFC 2119 keyword, line 825: '... compliant implementation MUST support...' RFC 2119 keyword, line 1541: '... This payload MUST be used only with...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 17, 2000) is 8777 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: 'ISAKMP' is mentioned on line 1283, but not defined == Missing Reference: 'IKEbis' is mentioned on line 1474, but not defined ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Tim Jenkins 2 IP Security Working Group Newbridge Networks Corporation 3 Internet Draft March 17, 2000 5 IPsec Re-keying Issues 6 8 This document is an Internet-Draft and is in full conformance with 9 all provisions of Section 10 of RFC2026. 11 Status of this Memo 13 Informational 15 This memo provides information for the Internet community. This memo 16 does not specify an Internet standard of any kind, nor is it 17 intended to specify an Internet standard. Future considerations 18 related to Internet standards are the opinions of the author, and 19 not the IPsec working group. 21 Distribution of this memo is unlimited. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or made obsolete by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 . 37 The list of Internet-Draft Shadow Directories can be accessed at 38 . 40 Copyright Notice 42 Copyright (C) Tim Jenkins (2000). 44 Table of Contents 46 1. Introduction..................................................3 47 2. Phase 2 SA Re-keying..........................................3 48 2.1 Phase 2 Re-keying Issues.....................................4 49 2.1.1 Inconsistent SA Use Recommendation.........................5 50 2.1.2 Observed Behaviours........................................6 51 2.1.3 SA Set-up Race Condition...................................6 52 2.1.4 Commit Bit Interaction.....................................8 53 2.2 Solution Examination.........................................9 54 2.2.1 Responder Pre-Set-up.......................................9 55 2.2.1.1 Normal Conditions......................................10 56 2.2.1.2 Dropped Packet Conditions..............................12 57 2.2.1.3 Failed Negotiation.....................................13 58 2.2.1.4 Responder Pre-Set-up Security Hole.....................14 59 2.2.2 Recommended Re-keying Method..............................14 60 2.2.2.1 Dropped Quick Mode 3 Message...........................16 61 2.2.2.2 Absence of Traffic.....................................16 62 2.2.2.3 Compatibility With Observed Behaviours.................17 63 2.2.2.4 Compatibility with Commit Bit..........................17 64 2.2.2.5 Implementation Notes...................................18 65 2.3 Conclusions.................................................18 66 3. Phase 1 SA Re-keying.........................................18 67 3.1 Phase 1 SA Re-keying Requirements...........................19 68 3.2 Phase 1 Re-keying Operation.................................20 69 3.3 A Note About Overlapping Phase 1 SAs........................21 70 3.3.1 Identity Perfect Forward Secrecy..........................23 71 3.4 Other Phase 1 SA Re-keying Issues...........................23 72 3.4.1 Multiple SA Usage.........................................23 73 3.4.2 INITIAL-CONTACT Notification..............................24 74 3.4.3 DELETE Notification.......................................24 75 3.4.4 Re-keying Timing..........................................25 76 4. Next IPsec Version Recommendations...........................25 77 4.1 Re-transmission Rules.......................................26 78 4.1.1 Main Mode Re-Transmission Rules...........................26 79 4.1.2 Aggressive Mode Re-Transmission Rules.....................27 80 4.1.3 Quick Mode Re-Transmission Rules..........................27 81 4.2 Acknowledged SA Deletion....................................27 82 4.3 Phase 1 Re-keying for Future Versions of IPsec..............29 83 4.4 Phase 2 Re-keying for Future Versions of IPsec..............29 84 4.4.1 Oldest Phase 2 SA First...................................29 85 4.4.2 Phase 2 Re-keying Illustration............................30 86 4.5 Commit Bit Replacement......................................34 87 4.5.1 DEFER_USAGE Notify Payload................................34 88 4.5.2 ALLOW_USAGE Notify Payload................................35 89 5. Acknowledgements.............................................36 90 6. References...................................................36 92 1. Introduction 94 This document discusses issues associated with the use of protocols 95 developed in the IETF's IPsec working group, specifically, RFC 2409 96 [IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is 97 familiar with those documents. 99 As stated earlier, this document does not specify standards of any 100 kind, and is intended as information for IPsec implementers. 102 This document has three primary objectives. 104 The first objective is to illustrate problems and issues associated 105 with re-keying within the confines of the current set of IPsec 106 documents. For a number of reasons, re-keying in IPsec has become 107 problematic, such that IPsec implementations can drop packets during 108 re-keying. Worse, there exists the possibility that IPsec 109 implementations from different vendors may not be interoperable 110 because of the way they re-key. 112 The second objective of this paper is to propose methods of 113 performing phase 2 re-keying for IPsec implementations in such a way 114 as to minimise packet loss and to maximise compatibility. Again, the 115 primary focus for this is in virtual private networking (VPN) and 116 remote access (RA) applications. 118 The initial focus of the first two objectives is on phase 2 re- 119 keying; it is then extended to phase 1 re-keying. The need for this 120 document in each case is initially discussed, followed by a 121 recommendation for re-keying within the protocol framework 122 established by the initial version of the IPsec documents. 124 Finally, the third objective of the document is to provide 125 recommendations for the next version of the IPsec protocols. These 126 recommendations are made to best solve the re-keying problems in a 127 manner that is not possible within the constraints of the existing 128 IPsec documents. 130 The document also discusses other issues related to SA negotiation, 131 such as SA deletion, packet acknowledgement and the commit bit. 133 2. Phase 2 SA Re-keying 135 This section discusses phase 2 re-keying issues and makes 136 recommendations to minimise the impact of these issues within the 137 current IPsec document set. 139 It is assumed that the purpose of re-keying is that the 140 implementation wants to allow the transfer of traffic processed by 141 the phase 2 SAs from the current phase 2 SA to a replacement phase 2 142 SA in such a way as to minimise the loss of user traffic. 144 It does not preclude the use of idle-timeouts, heartbeats or keep- 145 alives, resource management or other SA management techniques, as 146 may be required by the specific application of IPsec. Nor does it 147 make any specific recommendations about if or when implementations 148 should initiate re-keying. 150 It also does not assume that the implementation has specific 151 knowledge about the peer's behaviour. In other words, the peer's 152 behaviour is assumed to be any of those that may be potentially 153 allowed by the documents. 155 2.1 Phase 2 Re-keying Issues 157 The issues associated with phase 2 re-keying are listed below. Some 158 of the points are expanded upon later. 160 1) There is no specification explicitly defining how the transfer 161 of traffic from old to new SAs is to be done. 163 2) The existing drafts appear contradictory in their 164 recommendations on the usage of multiple phase 2 SAs. 166 3) Some implementations have shipped with a method of re-keying 167 that will not perform reliably under real world network 168 conditions. 170 4) The use of the DELETE notification is not required. 172 5) A variety of re-keying behaviours have been observed, some of 173 which are incompatible. 175 6) The commit bit is not yet widely implemented, and its use as 176 described is confusing. Further, while the documentation 177 requires its support, its use is not required. 179 7) A race condition exists at SA set up, exacerbating re-keying 180 issues. 182 RFC 2401 provides only this guidance (from section 4.4.3): 184 NOTE: The details of how to handle the refreshing of keys 185 when SAs expire is a local matter. However, one 186 reasonable approach is: 188 ... 190 (b) There SHOULD be two kinds of lifetime -- a soft 191 lifetime which warns the implementation to initiate 192 action such as setting up a replacement SA and a 193 hard lifetime when the current SA ends. 195 As such, it makes no recommendations as to how traffic should be 196 moved to the replacement SA. 198 2.1.1 Inconsistent SA Use Recommendation 200 The issue of inconsistent SA usage recommendations is examined 201 further here. 203 From paragraph 2 of Section 9 of [IKE]: 205 An implementation may wish to negotiate a range of SAs when 206 performing Quick Mode. By doing this they can speed up the "re- 207 keying". Quick Mode defines how KEYMAT is defined for a range of 208 SAs. When one peer feels it is time to change SAs they simply use 209 the next one within the stated range. A range of SAs can be 210 established by negotiating multiple SAs (identical attributes, 211 different SPIs) with one Quick Mode. 213 While the document does not define what "... the next one ..." 214 means, this paragraph strongly implies that there is no required 215 order for the use of phase 2 SAs that have been negotiated within a 216 phase 1 SA, and that multiple SAs may be pre-negotiated and used at 217 will. 219 However, this appears to be contradicted by paragraph 3 of section 220 4.3 of [ISAKMP]: 222 Modification of a Protocol SA (phase 2 negotiation) follows the 223 same procedure as creation of a Protocol SA. The creation of a new 224 SA is protected by the existing ISAKMP SA. There is no 225 relationship between the two Protocol SAs. A protocol 226 implementation SHOULD begin using the newly created SA for 227 outbound traffic and SHOULD continue to support incoming traffic 228 on the old SA until it is deleted or until traffic is received 229 under the protection of the newly created SA. As stated previously 230 in this section, deletion of an old SA is then dependent on local 231 security policy. 233 Many implementations have interpreted this to mean that the new SA 234 should be used for outbound traffic in preference to the old SA. 235 Extending this logic may have caused implementations to abandon the 236 old SA as soon as possible. 238 This interpretation of [ISAKMP] is in direct conflict with the usage 239 implied by [IKE], resulting in potential problems. 241 2.1.2 Observed Behaviours 243 The following behaviours have been observed by various vendors' 244 implementations when devices have set up a second phase 2 SA. The 245 behaviours listed below are not necessarily mutually exclusive. 247 1) The device continues to use the old SA until it naturally 248 expires, then switches to the new SA. 250 2) The device immediately begins using the new SA. 252 3) The device immediately drops the old SA. 254 4) The device never sends a DELETE notification. 256 5) The device always sends a DELETE notification. 258 6) The device deletes the old SA some time after re-keying, but 259 before the end of its natural lifetime. 261 7) A device wants to keep more than one SA up all the time. 263 All of these behaviours are permitted under the current documents. 264 However, even when quick mode packets are not lost, it can be seen 265 that interoperability is not always possible with some combinations 266 of behaviours listed above. 268 2.1.3 SA Set-up Race Condition 270 Further, behaviour 2 above is not a good behaviour, as illustrated 271 below. In this example, the initiator is a gateway capable of 272 handling full T3 bandwidth rates, while the responder is a PC 273 running a software IPsec implementation and it is overloaded. 275 In the illustration, QM1 refers to the first quick mode message, QM2 276 to the second quick mode message and QM3 to the third quick mode 277 message. 279 Initiator Responder 281 QM1 sent ---- 282 ------- 283 ------------- 284 ---------------> QM1 received 285 | 286 | 287 | QM1 processed 288 | 289 | 290 ---------------- QM2 sent 291 ------------- 292 ------- 293 QM2 rec. <---- 294 process | 295 QM3 sent ----- 296 * ------- 297 packet on new SA ------------- 298 _____ ---------------> QM3 received 299 _______ | 300 _____________ | QM3 processing 301 _______________| 302 | packet dropped 303 | 304 * new SA set up 306 Figure 2-1 Race Condition Sequence Chart 308 By the time the responder has set up the new SA, packets protected 309 by that SA have already started arriving from the initiator. This 310 causes them to be dropped by the responder. This case is further 311 complicated by the possibility of packets taking different paths 312 through the network, so the third quick mode message could arrive 313 after packets protected by the new SA. 315 Additionally, since all IKE packets are based on UDP, there is no 316 guarantee that QM3 even arrives at the peer, so making assumptions 317 about new SA use based on the transmission time of a packet will 318 still lead to failures in the field. 320 To reduce the effects of packet loss, some implementations were 321 observed to blindly transmit QM3 multiple times, back to back. 323 This can reduce the probability that the peer does not get QM3, but 324 cannot eliminate it. Nor can it eliminate race conditions due to 325 path differences or processing times. 327 If the behaviour of the initiator was to delay usage of the new SA 328 for outbound traffic, this would cause failures for those 329 implementations that immediately delete the old SA. Therefore, the 330 behaviours of delaying use of the new SA and immediately deleting 331 the old SA are incompatible. 333 2.1.4 Commit Bit Interaction 335 The use of the commit bit can solve the race condition illustrated 336 in the previous section when asserted by the responder during quick 337 mode. However, it suffers from the following problems: 339 1) Use of the commit bit is not well defined. The present 340 documentation ([ISAKMP]) specifies its use for phase 1 and 341 phase 2, but mentions phase 2 specific details. There are also 342 issues related to how the subsequent CONNECTED notification 343 fits in with the quick mode exchange. 345 2) While its support is required, its use is not. 347 3) Its use may make implementations susceptible to a denial of 348 service attack by forcing initiators to wait for a CONNECTED 349 notification that may never come. While this is only one of a 350 number of possible denial of service attacks on IKE, this is 351 not an excuse to leave the existing implementation as it is. 353 4) There is no defined way to recover from the loss of the 354 CONNECTED notification. 356 5) Some implementations are using the commit bit for the wrong 357 reasons. 359 The working group is addressing point 1; future versions of the 360 IPsec documents should clarify these issues. [IKEbis] has gone a 361 long way in clarifying this issue. 363 Point 3 happens because the commit bit is in the ISAKMP header, and 364 the ISAKMP header is not authenticated, so the commit bit is 365 susceptible to undetectable modification. 367 Point 5 above needs some elaboration. In a previous section, it was 368 mentioned that the loss of the third quick mode message could cause 369 problems, since the responder will not set up the SA at all. Because 370 of this, some implementations have chosen to set the commit bit as a 371 mechanism to force the re-transmission of the third quick mode 372 message. 374 This is wrong for two reasons. First, it is not the stated purpose 375 of the commit bit. The purpose of the commit bit is to delay the 376 usage of an SA, for whatever reason. This implies that it is not a 377 good mechanism to cause re-transmission of the third quick mode 378 message. 380 Secondly, it does not solve the packet loss problem; it only defers 381 it. The logic of the improper usage is that the initiator will re- 382 send the third quick mode message until it receives the CONNECTED 383 notification (which is now effectively the fourth quick mode 384 message). 386 The problem with this is that it leaves no mechanism for demanding 387 the re-transmission of the CONNECTED notification itself. It can be 388 dropped just as the third quick mode message can. This means that 389 the problem that was intended to be solved by the use of the commit 390 bit is simply pushed out to being the problem of solving the dropped 391 CONNECTED notification. 393 Sections 2.2.2.1 and 4.1 describe a mechanism for solving the 394 dropped third quick mode message problem. 396 2.2 Solution Examination 398 This section details the operation of some possible behaviours, with 399 the intent of arriving at a best possible phase 2 re-keying 400 mechanism under the constraints of the existing documents. 402 In all the examples, the term "sets up a new outbound SA" means that 403 the new outbound SA will be chosen in favour of the old one. Whether 404 the SA is actually created before that time or not is implementation 405 dependent. 407 2.2.1 Responder Pre-Set-up 409 As a starting point, the responder pre-set-up method of re-keying is 410 examined. Note that it will work with most of the behaviours 411 observed in the field. 413 In this method, SAs are treated separately as inbound and outbound, 414 as well as old and new. Further, it takes advantage of the fact that 415 the responder knows what the SA is going to be after the second 416 quick mode message is sent. By using this information, it allows the 417 responder to set up the new inbound SA before having received the 418 third quick mode message. 420 Implicit acknowledgement of the reception of the third quick mode 421 message by the responder is provided by use of the new SA in the 422 initiator's inbound direction. The initiator should not use its new 423 outbound SA before that time. 425 Additionally, it does not require use of the CONNECTED notification 426 for prevention of the race condition, or the use of the DELETE 427 notification for removal of the old SA. This is important since, 428 even if they are always sent, they are unacknowledged UDP packets 429 and may be lost. 431 2.2.1.1 Normal Conditions 433 Figure 2-2 shows the operation under normal (successful) conditions. 435 While appearing complicated, it enables the lossless transfer from 436 one SA to another while supporting almost all other behaviours. 438 Support for and use of the DELETE notification is unchanged. 440 Initiator Responder 442 Inbound Outbound Inbound Outbound 443 | | | | 444 1 ----------------- | | 445 | | ------------ | | 446 | | -------------------> 2 447 | | | | | 448 | | -------------------- 3 449 | | ------------ | *4 | 450 5 <--------------- | | | 451 | | | | | | 452 6 ---------------- | | | 453 | *7 | ------------ | | | 454 | | | -------------------> 8 455 | | | | | | | 456 | | | | | | * 457 | | | | | | *9 458 | | | | | *10 | 459 | | | | | | 460 | *11 | | | | 461 | | | *12 | | | 462 | | *13 | | | | 463 *14| | | | | 464 | | | *15 | 465 | | *16| | 466 | | | | 468 Figure 2-2 Phase 2 SA Pre-Setup Sequence Chart 470 Events 472 1) Initiator sends first quick mode message. 474 2) Responder receives first quick mode message. 476 3) Responder sends second quick mode message. 478 4) Responder sets up new inbound SA. This is to handle the case 479 where the initiator starts transmitting on the new SA 480 immediately after sending the third quick mode message. 482 5) Initiator receives second quick mode message. 484 6) Initiator sends third quick mode message. 486 7) Initiator sets up new inbound SA. 488 8) Responder receives third quick mode message. 490 9) Responder sets up new outbound SA. 492 10) Responder deletes old outbound SA. 494 11) Traffic from responder to initiator arrives at initiator on new 495 SA. 497 12) Initiator sets up new outbound SA. 499 13) Initiator deletes old outbound SA. 501 14) Initiator deletes old inbound SA. 503 15) Traffic from initiator to responder arrives at responder on new 504 SA. 506 16) Responder deletes old inbound SA. 508 2.2.1.2 Dropped Packet Conditions 510 In this case, the event list is modified to show what happens when 511 each packet is dropped once. The event numbers refer to those 512 illustrated in Figure 2-2. 514 1) Initiator sends first quick mode message. 516 e) Packet is dropped during transmission. 518 1b) Initiator times out waiting for second quick mode message. 520 1) Initiator re-sends first quick mode message. 522 2) Responder receives first quick mode message. 524 3) Responder sends second quick mode message. 526 4) Responder sets up new inbound SA. This is to handle the case 527 where the initiator starts transmitting on the new SA 528 immediately after sending the third quick mode message. 530 e) Packet is dropped during transmission. 532 1b) or 7b) Responder times out waiting for third quick mode 533 message. 535 1) or 3) Responder re-sends second quick mode message. 537 5) Initiator receives second quick mode message. 539 6) Initiator sends third quick mode message. 541 7) Initiator sets up new inbound SA. 543 e) Packet is dropped during transmission. 545 7b) Responder times out waiting for third quick mode message. 547 3) Responder re-sends second quick mode message. 549 5) Initiator receives second quick mode message again. 551 6) Initiator re-sends third quick mode message. 553 8) Responder receives third quick mode message. 555 and so on, as for normal operation. 557 2.2.1.3 Failed Negotiation 559 In this case, the second quick mode packet has an invalid hash, and 560 the initiator sends the notification to the peer. Again, the event 561 numbers refer to those illustrated in Figure 2-2. 563 1) Initiator sends first quick mode message. 565 2) Responder receives first quick mode message. 567 3) Responder sends second quick mode message. 569 4) Responder sets up new inbound SA. This is to handle the case 570 where the initiator starts transmitting on the new SA 571 immediately after sending the third quick mode message. 573 5) Initiator receives second quick mode message. 575 e) Hash (or other parameter) fails. 577 e1) Initiator sends notification to responder. 579 e2) Responder receives notification. 581 e3) Responder deletes new inbound SA. 583 A similar operation would occur if retry counters expire for packet 584 re-transmissions. 586 2.2.1.4 Responder Pre-Set-up Security Hole 588 In the failed negotiation case, the need to delete the invalid 589 inbound SA raises the issue of a temporary hole, in that the 590 responder allows inbound packets while waiting for the third quick 591 mode message. However, if the inbound SA is not set up ahead of 592 time, initiators that immediately transmit on the new outbound SA 593 will cause packets to be dropped. 595 It also illustrates why the proposal above made the usage of the 596 outbound SA by the initiator wait until there is an indication of 597 the use of the SA by the responder. 599 Note that this security hole is exactly what would result from an 600 attacker replaying the first quick mode message of an exchange. 602 2.2.2 Recommended Re-keying Method 604 In this method, the previous method is modified to remove the risk 605 of the security hole. It also simplifies the operation somewhat, but 606 at the expense of lost packets if the initiator's behaviour is such 607 that it immediately uses the new SA for its outbound traffic. 609 Note that deletion of the old inbound SA by the initiator could be 610 further delayed if protection against loss of packets using the old 611 SA on different and slower network paths is desired. 613 Initiator Responder 615 Inbound Outbound Inbound Outbound 616 | | | | 617 1 ----------------- | | 618 | | ------------ | | 619 | | -------------------> 2 620 | | | | | 621 | | -------------------- 3 622 | | ------------ | | 623 4 <--------------- | | 624 | | | | | 625 5 ---------- | | | 626 | *6 ------------------ | | 627 | | | -------------------> 7 628 | | | | | | 629 | | | | | * 630 | | | | *8 | 631 | | | | | | *9 632 | | | | | *10 | 633 | | | | | | 634 | *11 | | | | 635 | | | *12 | | | 636 | | *13 | | | | 637 *14| | | | | 638 | | | *15 | 639 | | *16| | 640 | | | | 642 Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 644 1) Initiator sends first quick mode message. 646 2) Responder receives first quick mode message. 648 3) Responder sends second quick mode message. 650 4) Initiator receives second quick mode message. 652 5) Initiator sends third quick mode message. 654 6) Initiator sets up new inbound SA. 656 7) Responder receives third quick mode message. 658 8) Responder sets up new inbound SA. 660 9) Responder sets up new outbound SA. 662 10) Responder deletes old outbound SA. 664 11) Traffic from responder to initiator arrives at initiator on new 665 SA. 667 12) Initiator sets up new outbound SA. 669 13) Initiator deletes old outbound SA. 671 14) Initiator deletes old inbound SA. 673 15) Traffic from initiator to responder arrives at responder on new 674 SA. 676 16) Responder deletes old inbound SA. 678 2.2.2.1 Dropped Quick Mode 3 Message 680 In cases where the third quick mode message is dropped, the 681 responder must request re-transmission of it by re-sending the 682 second quick mode message. The existence of traffic on the new 683 inbound SA at the initiator should not be used as an implicit 684 acknowledgement for the following reasons: 686 1) There may be no traffic for the responder to send. 688 2) The responder may be designed to use the old SA until its 689 natural expiration. 691 This implies that implementations must be able to respond to the re- 692 transmission of the second quick mode message even after having sent 693 the third quick mode message. 695 2.2.2.2 Absence of Traffic 697 The proposed implementation uses the presence of traffic from the 698 responder on new SAs to provide an implied acknowledgement for the 699 purposes of switching to the new SA. However, if there is no traffic 700 from the responder, the implied acknowledgement will not appear. 702 A similar behaviour is exhibited by implementations that continue to 703 use old SAs until their natural expiration. 705 However, due to the number of implementations that delete old SAs 30 706 seconds after negotiating a new one, the same behaviour has the best 707 chance of interoperability, and of not dropping packets when traffic 708 does restart. 710 Therefore, it is recommended that implementations delete old SAs and 711 start using new SAs 30 seconds after negotiating new SAs in the 712 absence of traffic. Use of the DELETE notification is strongly 713 recommended in cases where the peer implementation is continuing to 714 use the old SA. 716 2.2.2.3 Compatibility With Observed Behaviours 718 When responders use the proposed method and the initiator is an 719 implementation that uses the new SA immediately, there is no 720 difference in SA transfer performance compared to the responder also 721 using the new SA immediately. This is because the proposed method 722 tries to use the new SA immediately on inbound, so it will be ready 723 to receive on the new SA just as fast as an implementation that 724 starts using the new immediately under all conditions. However, 725 since the initiator is also using the new SA immediately, there is a 726 possibility that packets will arrive at the responder on the new SA 727 before the responder has time to set up the new SA. 729 When the initiator uses the proposed method, the performance (packet 730 loss when transferring to the new SA) will depend on when the 731 responder deletes the old inbound SA. 733 When operating with behaviours that continue to use the old SA, this 734 method performs as described in the dropped quick mode three example 735 above when used by the initiator. When used by the responder, there 736 is no change in operation, since the responder will wait until the 737 new SA is used before deleting the old SA. 739 However, as stated in a previous section, it is recommended that the 740 initiator keep the old SA (both inbound and outbound) for only 30 741 seconds after creation of the new SA in cases where traffic is not 742 detected on the new SA. 744 2.2.2.4 Compatibility with Commit Bit 746 If the responder sets the commit bit with this proposal, some of the 747 problems described in Section 2.1.4 may occur. To reduce the effects 748 of these problems, following rules should be followed: 750 1) The initiator should set up its inbound SA immediately after 751 sending the third quick mode message regardless of the state of 752 the commit bit. 754 2) Sensing of traffic on the initiator's new inbound SA should 755 trigger the use of the new outbound SA to detect cases when the 756 CONNECTED notification is dropped. 758 The recommended proposal does not allow built-in support of the 759 commit bit. It does allow responders that use the commit bit to 760 detect reception of the CONNECTED notification by the initiator due 761 to the presence of traffic on its new inbound SA. However, this 762 works only if there is traffic, so it cannot be considered a useful 763 method to perform this function. 765 The recommended proposal does cause the initiator to delay usage of 766 a new SA until it is set up. This is the primary use of the commit 767 bit, so use of this proposal makes the use of the commit bit 768 unnecessary except for the setting up of the first phase 2 SA. 770 2.2.2.5 Implementation Notes 772 The presence of traffic on the new SA can be part of the expiration 773 checking operation, and does not need to occur instantaneously, 774 although it must occur before the 30 second no traffic SA deletion 775 criteria. As long as the new SA is negotiated with enough time 776 before the expiration of the old one, the detection of traffic on 777 the new SA can be on the order of seconds with no ill effects. 779 Since SAs will likely have traffic counters anyway, this method 780 requires only the addition of a flag that indicates it is a new SA. 781 When the expiration process checks for ageing and expired SAs, it 782 can also check for new SAs with a non-zero traffic count. When 783 detected, the SA is marked as non-new, and the remaining operations 784 can be performed. 786 2.3 Conclusions 788 The final re-keying method is the best compromise for 789 interoperability within the framework of the current IPsec documents 790 without compromising security. 792 3. Phase 1 SA Re-keying 794 This section discusses phase 1 SA re-keying. This proposal is 795 necessary for many of the same reasons a phase 2 SA re-keying 796 proposal is necessary. 798 1) As mentioned above, the rules for phase 1 SA re-keying are not 799 specified in the drafts. 801 2) Adhoc implementations have lead to possible interoperability 802 issues. 804 This section discusses potential requirements of phase 1 re-keying, 805 and presents some options and issues associated with those options. 807 3.1 Phase 1 SA Re-keying Requirements 809 Two reasons for re-keying a phase 1 SA are for freshness (time or 810 other) of the phase 1 SA keying material (affecting its ability to 811 protect phase 2 SA negotiations and to generate phase keying 812 material) and for re-authentication (and therefore authorisation) of 813 the encrypting devices. 815 The authorisation lifetime restriction reason stated above was 816 inferred as necessary due to the following paragraph from 817 section 4.4.3 of RFC 2401 (the Security Associations being discussed 818 are phase 2 SAs): 820 o Lifetime of this Security Association: a time interval after 821 which an SA must be replaced with a new SA (and new SPI) or 822 terminated, plus an indication of which of these actions 823 should occur. This may be expressed as a time or byte count, 824 or a simultaneous use of both, the first lifetime to expire 825 taking precedence. A compliant implementation MUST support 826 both types of lifetimes, and must support a simultaneous use 827 of both. If time is employed, and if IKE employs X.509 828 certificates for SA establishment, the SA lifetime must be 829 constrained by the validity intervals of the certificates, 830 and the NextIssueDate of the CRLs used in the IKE exchange 831 for the SA. Both initiator and responder are responsible for 832 constraining SA lifetime in this fashion. 833 [REQUIRED for all implementations] 835 Note particularly the lifetime constraint comments in the last two 836 sentences. 838 However, this restriction reason stated above has been deemed 839 unimportant by the working group as a factor in determining how 840 phase 1 SAs are used and re-keyed for two reasons: 842 1) System administrators understand IPsec well enough to configure 843 the combination of phase 1 and phase 2 SA lifetimes such that 844 terminating phase 2 SAs when authentication ends means the 845 unauthorised usage period is insignificant. 847 2) Many implementations will be required to produce a mechanism to 848 tear down SAs created by entities that are no longer authorised. 849 This is considered manual intervention, and thus not important 850 for normal unattended operation. 852 The net result of this is that phase 1 SAs do not need to be 853 overlapped to provide a continuous indication of peer authorisation 854 to allow phase 2 SAs to continue to exist. 856 Therefore, the only reason to re-key phase 1 SAs is due to keying 857 material expiration. Further, it means that phase 1 SA and phase 2 858 SA lifetimes are unbound; that is, there are no requirements that a 859 phase 1 SA exist between two peers that have phase 2 SAs. 861 However, some applications may consider it advantageous to attempt 862 to keep a valid phase 1 SA up between peers at all times. This would 863 require overlapping of phase 1 SAs, and re-keying of old SAs before 864 they expire. However, these implementations must be aware that peers 865 may not be trying to do this, and in fact may be trying to reduce 866 unused resource requirements by deleting the phase 1 SA. 868 Factors to consider in determining how to re-key phase 1 SAs that 869 are not RFC-based requirements are resource issues (memory 870 requirements versus complex calculation requirements), SA usage with 871 respect to time (normal SA usage very short lived, for example), 872 reliability requirements, and other possible application specific 873 factors. 875 3.2 Phase 1 Re-keying Operation 877 Summarised, the procedure for phase 1 re-keying is: 879 Initial Phase 1 SA Negotiation: 880 -initiator must use INITIAL-CONTACT notification 881 -responder should use INITIAL-CONTACT notification (when 882 possible) 883 -responder deletes any pre-existing phase 1 SA with the peer when 884 authentication of peer is complete (in cases of simultaneous 885 initiation, the other "new" phase 1 SA should not be deleted) 886 -responder deletes all previously existing phase 2 SAs with the 887 peer, if any 889 Phase 1 SA Expiration: 890 -DELETE notification should be sent for phase 1 SA only 891 -phase 2 SAs between peers are left untouched 893 New Phase 1 SA Negotiation: 894 -initiator must not use INITIAL-CONTACT notification 895 -responder must detect that this is a re-key and must not use 896 INITIAL-CONTACT notification 897 -no INITIAL-CONTACT notification is used by either end, so phase 898 2 SAs are kept 900 Phase 2 SA Ages, and no existing phase 1 SA 901 -attempt New Phase 1 SA Negotiation 902 -if that succeeds, attempt new phase 2 SA negotiation 904 If an implementation wants to overlap phase 1 SAs, the following 905 procedure is recommended: 907 Phase 1 SA Ages: 908 -peer that first detects this or desires overlapping phase 1 SAs 909 negotiates new phase 1 SA; becomes new initiator 910 -responder should mark any existing phase 1 SAs as re-keyed, so 911 as to not re-key again if it also desires overlapping phase 1 SAs 913 3.3 A Note About Overlapping Phase 1 SAs 915 An earlier version of this document promoted having overlapping 916 phase 1 SAs at all times. This was presented as the continuous 917 channel model. Continuous channel implementations are those 918 implementations that attempt to always maintain at least one valid 919 phase 1 SA between any peers that have phase 2 SAs. 921 The reasons and advantages of this method are discussed here. 922 However, it must be re-iterated that there are no RFC-based 923 requirements that implementations follow this model. In fact, 924 implementations should not insist on this model due to the 925 possibility that the peer may be attempting to minimise resource 926 usage. 928 The continuous channel method is implicitly recommended by RFC 2408. 929 The following quote is from paragraph six of [ISAKMP]: 931 Third, having an ISAKMP SA in place considerably reduces the cost 932 of ISAKMP management activity - without the "trusted path" that 933 an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would 934 have to go through a complete re-authentication for each error 935 notification or deletion of an SA. 937 The primary advantage of the continuous existence of the logical 938 channel is that it allows cleaner management of phase 2 SAs, 939 particular if the two entities become unsynchronised for any reason. 941 It is useful whenever premature termination of communications occurs 942 when the phase 1 SAs cannot be re-created. These conditions occur 943 potentially under the following conditions: 945 1) A time-based policy is used that restricts user access to 946 specific hours of the day, and only phase 1 authorization catches 947 this. 949 2) A user's permissions are totally revoked. 951 3) A token card-based user removes the token card from the system. 953 4) Some other policy or configuration change. 955 A specific application for this model that provides distinct 956 advantages is with the use of token cards. For example, if a user�s 957 phase 1 authentication and authorisation is bound by the presence of 958 a token card in a reader, the removal of the card should result in 959 all SAs being torn down. Since there exists a continuous channel, 960 delete notifications (acknowledged or not) can be sent for all SAs 961 when the token card is removed from the system. However, if the 962 phase 1 SA was allowed to be deleted without being re-keyed, the 963 local end can only unilaterally delete its SAs, leaving the two end 964 points out of sync with each other. (It cannot send delete 965 notifications since the absence of the card makes it unable to re- 966 establish a phase 1 SA.) 968 Depending on the application, the above cases may fall under the 969 category of special events, and thus not having significant weight 970 when determining if the continuous channel model is the correct 971 implementation to be used. 973 The continuous channel model also allows a responder to initiate re- 974 keying under conditions where its SAs expire before the initiator's 975 and configuration does not allow it to normally initiate to the 976 peer. This situation is currently permitted by the RFCs if 977 implementation should choose to not send or support the use of the 978 RESPONDER-LIFETIME notification when the initiator's proposal has 979 longer lifetimes than the responder is willing to accept. 981 Also, this model more closely ties endpoint authorization to phase 2 982 SA lifetime. 984 The disadvantages of the continuous channel model of implementation 985 are that it uses more resources (always keeps a phase 1 SA, and 986 potentially uses more key generation), and is slightly more complex 987 to implement. 989 Finally, it must be aware of implementations that do not want or 990 need phase 1 SAs that are continuously available. 992 3.3.1 Identity Perfect Forward Secrecy 994 Allowing the use of only a single phase 2 negotiation in a phase 1 995 SA is how identity PFS is done. This is controlled by the deletion 996 of the phase 1 SA after a phase 2 negotiation. 998 In implementations that do not wish to delete all phase 1 SAs, this 999 can be done by creating two phase 1 SAs before the first phase 2 1000 negotiation is done. The first of these SAs is assigned the role of 1001 channel management, and thus performs SA deletion and notification 1002 transfer. The second SA is used to perform phase 2 negotiations, and 1003 is immediately deleted. 1005 The phase 1 SA that is assigned to channel management is re-keyed to 1006 create the overlapping phase 1 SAs. Since it is the oldest phase 1 1007 SA, it will naturally be used for all management traffic even if 1008 another phase 1 SA temporarily exists only for the purpose of 1009 performing a quick modes (see Section 3.4.1). Other phase 1 SAs are 1010 created and used to protect phase 2 negotiations and then they are 1011 immediately deleted. 1013 Since Identity PFS is not negotiated, it may not be possible to 1014 guarantee that the peer knows Identity PFS is being used. In this 1015 case, the initiator may be required to delete its channel management 1016 SA and create a new one if the peer uses that phase 1 SA to re-key a 1017 phase 2 SA. 1019 3.4 Other Phase 1 SA Re-keying Issues 1021 This section describes other issues associated with phase 1 SA re- 1022 keying that are independent of the whether the implementation 1023 intentionally overlaps phase 1 SAs or not. 1025 3.4.1 Multiple SA Usage 1027 When there is more than one phase 1 SA between peers, it is 1028 recommended that the oldest SA be used for subsequent traffic 1029 requiring phase 1 SAs. This allows full use of the keying material 1030 generated and reduces race conditions. It also means that no special 1031 expiration conditions are required when the phase 1 SAs expire by 1032 traffic or other usage dependent expirations only, as the old SA 1033 will eventually expire on its own due to usage. 1035 3.4.2 INITIAL-CONTACT Notification 1037 As stated above, the INITIAL-CONTACT notification should be used 1038 only with the very first phase 1 SA that is negotiated between two 1039 peers. 1041 If used on subsequent negotiations, it means that all pre-existing 1042 SAs (phase 1 and phase 2) held between the peers should be deleted. 1044 As an example, this is the mechanism used to detect when an SA end 1045 point has crashed and is now alive again. 1047 The use of INITIAL-CONTACT may be restricted by the mode used to 1048 negotiate phase 1 SAs. For these reasons, implementations may want 1049 to avoid the use of aggressive mode when possible. When it is used, 1050 it is recommended that the third aggressive mode message be 1051 encrypted so that the INITIAL-CONTACT notification can be added to 1052 it when needed. Note that the use of any notification by a responder 1053 during aggressive mode is not allowed, and this document's 1054 suggestion that the use of INITIAL-CONTACT is permitted by the 1055 initiator if the third aggressive mode packet is encrypted is 1056 possibly contrary to RFC2408. 1058 Alternatively, if notifications cannot be used within the phase 1 1059 modes at all, it is recommended that INITIAL-CONTACT be sent in a 1060 notification packet (preferably acknowledged) immediately after the 1061 phase 1 is complete. Reception of this notification (at any time) 1062 should indicate to the receiver that all other SAs, phase 1 and 1063 phase 2, with the sender must be deleted. (In other words, the SA 1064 that was used to encrypt the notification is the only SA that is not 1065 deleted.) 1067 3.4.3 DELETE Notification 1069 As currently defined by the IPsec documents, the DELETE notification 1070 is advisory only and is optional and unacknowledged. 1072 Given that it is optional, UDP based, and not used by some existing 1073 implementations, it should never be considered necessary. 1075 However, even though its use is of dubious value, it should be sent 1076 when any SA (phase 1 or phase 2) is deleted. Since the expiration of 1077 SAs might not occur at the same time at both ends for a number of 1078 reasons, use of the DELETE notification can increase the probability 1079 that both ends are synchronised with respect to SA usage. 1081 Further, implementations should attempt to use the acknowledged 1082 notify exchange as described in [IKEbis]. 1084 3.4.4 Re-keying Timing 1086 To reduce the probability of simultaneous re-keying, each device 1087 should re-key at a variable time with respect to the SA's expiration 1088 limit, in case they are the same. These recommendations apply to 1089 both phase 1 and phase 2 SAs. 1091 An example of this is that the end with the higher IP address re- 1092 keys at 95% of the lifetime, while the end with lower IP address re- 1093 keys at 85% of the lifetime. 1095 Whatever rule is chosen, it is recommended that the rule be 1096 deterministic in order to have predictable and consistent behaviour 1097 between peers. If the rule had used the SPI as the determining 1098 factor (as an example did in the first version of this document), 1099 different peers would be doing the re-keying at different times. 1101 In any case, simultaneous attempts at re-keying should be supported 1102 in one form or another, since it can never be guaranteed that this 1103 will not happen under all circumstances. 1105 4. Next IPsec Version Recommendations 1107 The recommendations made in sections 2 and 3 of this document have 1108 limitations in their ability to provide lossless, reliable and 1109 interoperable SA re-keying due to restrictions of existing 1110 implementations and the existing IPsec documentation. 1112 This section makes recommendations for explicit re-transmission 1113 rules, phase 1 and phase 2 re-keying, and describes the use of a new 1114 mode for reliable SA deletion in order to help provide reliable, 1115 lossless and interoperable re-keying. 1117 Also, a replacement for the commit bit is proposed. 1119 4.1 Re-transmission Rules 1121 In systems that use exchanges that have an even number of packets, 1122 the rules for re-transmission are relatively obvious. Simply put, a 1123 packet is re-sent if the expected response to it is not received 1124 within a certain period of time. 1126 However, IPsec has a number of modes that have an odd number of 1127 packets. This can lead to confusion as to when the re-transmission 1128 rules should be applied, depending how the re-transmission rules are 1129 applied to the packets in the exchange. This in turn can lead to the 1130 dropping of aggressive mode's and quick mode's third messages. It is 1131 recommended that each of these modes have specific rules applied to 1132 them to avoid re-transmission issues. 1134 These rules will be applied based on request-response pairs. Packets 1135 are defined as a request or a response in an exchange. The requestor 1136 is responsible for re-sending the request in order to solicit the 1137 response. The responder (not to be confused with an SA negotiation 1138 responder) is responsible for re-sending the response as it receives 1139 the initial and subsequent transmissions of the request. Note that 1140 the responder must exist after transmitting a response in case that 1141 response is dropped. 1143 In the modes with an odd number of packets, the request-response 1144 pair must be applied across the odd number of packets. This means 1145 that at least one packet must be considered the response to the 1146 previous packet, and must also be considered the request of the next 1147 request-response pair. 1149 This means that an implementation must be able to perform re- 1150 transmission of packets after it normally would have considered 1151 itself to be done with an exchange or a mode. Further, any timers 1152 set by the transmission of the final message of an exchange should 1153 be reset when re-transmission occurs. 1155 4.1.1 Main Mode Re-Transmission Rules 1157 In main mode, there are effectively three completely separate 1158 exchanges. The first request-response pair contains the SA 1159 proposals, the second pair contains the keying material, and the 1160 third pair contains the authentication material. (These descriptions 1161 are generalised for the purposes of stating what the exchanges are, 1162 and are not intended to create discussion on the actual contents of 1163 the exchanges.) 1164 As an example of the separation of the exchanges, there is no need 1165 to re-send the second main message to solicit the third main mode 1166 message, since the responder should not send the fourth main mode 1167 message until receiving the third main mode message. The absence of 1168 the fourth main mode message will cause the initiator to re-send the 1169 third main mode message. 1171 Keeping the exchanges separate from a re-transmission point of view 1172 should simplify implementations. 1174 4.1.2 Aggressive Mode Re-Transmission Rules 1176 In aggressive mode, the second message is the message that is both a 1177 response and a request. Therefore, the responder in a phase 1 1178 negotiation that uses aggressive mode must re-transmit the second 1179 aggressive mode message to solicit a third aggressive mode message 1180 that it perceives as lost. 1182 4.1.3 Quick Mode Re-Transmission Rules 1184 In quick mode, the second message is the message that is both a 1185 response and a request. Therefore, the responder in a phase 1 1186 negotiation must re-transmit the second quick mode message to 1187 solicit a third quick mode message that it perceives as lost. 1189 These rules must apply independently of the state of the commit bit, 1190 since there are currently no timing restrictions on the transmission 1191 of the CONNECTED notification. 1193 4.2 Acknowledged SA Deletion 1195 A previous version of this document described a new mode called 1196 Delete Mode. This mode is no longer necessary, as the new proposed 1197 Acknowledged Informational exchange can be used with the delete 1198 payload to perform the same thing. (See section 6.4.2 of [IKEbis].) 1200 This section (of this document) describes in detail how the 1201 Acknowledged Informational exchange should be used when deleting 1202 SAs. 1204 The Acknowledged Informational exchange consists of two packets. The 1205 first packet is the transmission of a notify or delete payload. The 1206 second is the acknowledgement of that packet. 1208 When used with a delete payload, it is interpreted to mean the 1209 following: 1211 "I am not sending anymore traffic on this SA (or these SAs). Would 1212 you please stop sending traffic on it (or them), and send me an 1213 acknowledgement when you are done?" 1215 The receiver of the delete request then switches his outbound 1216 traffic to another SA, deletes both inbound and outbound SAs and 1217 sends the delete acknowledgement. 1219 This is interpreted to mean: 1221 "I am also not sending anymore traffic on this SA (or these SAs). 1222 You may delete it (or them)." 1224 The receiver of the delete acknowledgement may then delete the 1225 inbound SA. The outbound SA should have already been deleted or 1226 somehow not used before the sending of the delete request. 1228 Note that re-transmission rules apply to the request-acknowledge 1229 pair. That is, if the initiator of the delete mode does not get the 1230 delete acknowledgement, the delete request should be re-transmitted. 1231 Similarly, if the responder of the delete request receives multiple 1232 copies, multiple copies of the delete acknowledgement should be 1233 sent. 1235 If the retry counter for the delete request expires, the SAs 1236 indicated in the request should be unilaterally deleted. 1238 Note that there is a race condition for the delete request and 1239 delete acknowledgement packets if an implementation sends them 1240 immediately after sending a packet on one of the SAs to be deleted. 1241 The race occurs if the packet order gets changed in the network and 1242 the delete mode packets arrive before packets sent on the SAs to 1243 which the deletes refer. 1245 The delete request-acknowledgement pair should also be applied to 1246 phase 1 SAs. In this case, the phase 1 SA is not completely torn 1247 down until the reception of the delete acknowledgement message. 1249 As a specific clarification, the binding between the inbound and the 1250 outbound phase 2 SAs is not weakened. In the messages used, the SA 1251 specified in the delete request is that of the sender's inbound SA. 1252 In other words, the SPI sent in the notification is the SPI that was 1253 generated by the sender. When phase 1 SAs are being deleted, the SPI 1254 values used are the cookies of the phase 1 SA to be deleted. 1256 The use of the Acknowledged Informational does not eliminate the use 1257 for the existing DELETE notification. It could still be used if an 1258 implementation determines it needs to immediately (and impolitely) 1259 delete an SA. Implementations must still recognise that it is sent 1260 over UDP and may be dropped. 1262 4.3 Phase 1 Re-keying for Future Versions of IPsec 1264 The phase 1 re-keying method described in Section 3 requires only 1265 one change for future versions of IPsec. That change is the addition 1266 of the required use of the Acknowledged Informational exchange when 1267 deleting SAs when it cannot be guaranteed that the peer's phase 1 SA 1268 lifetime is identical to the local lifetime. 1270 4.4 Phase 2 Re-keying for Future Versions of IPsec 1272 The phase 2 re-keying proposal described in Section 2, while 1273 necessary under the circumstances, is not the ideal method of re- 1274 keying. It forces the specific transfer times of SAs, thus making 1275 the intent of paragraph 2, section 9 of [IKE] impossible. It is also 1276 complicated to implement. 1278 This section describes proposals related to re-keying for the next 1279 version of the IPsec protocols. The purpose is to precisely define 1280 re-keying so that implementations are lossless and perfectly 1281 interoperable during re-keying. It also allows the spirit of 1282 paragraph 2, section 9 of [IKE] to be used. Further, it meets the 1283 requirements of paragraph 3 of section 4.3 of [ISAKMP]. 1285 A summary of the recommendations is: 1287 1) Define and require that the normal procedure is to use the 1288 oldest phase 2 SA first, and to use it until its natural 1289 expiration. 1291 2) Use the recommended re-transmission request rules for quick 1292 mode. 1294 3) Make use of the Acknowledged Informational exchange a 1295 requirement for SA deletion. 1297 4.4.1 Oldest Phase 2 SA First 1299 The concept of using the oldest phase 2 SA first for outbound 1300 traffic allows the maximum use of negotiated keys and allows for the 1301 pre-negotiation of an arbitrary number of phase 2 SAs to be made 1302 available for later use. 1304 Additionally, it decouples new phase 2 SA negotiation from old phase 1305 2 SA deletion, and the need to transfer to the new SA during re- 1306 keying. 1308 It also eliminates the race condition that occurs during SA set up 1309 during re-keying. This means that use of the commit bit to avoid the 1310 race condition is not necessary except when the very first phase 2 1311 SA is set up. 1313 Another advantage of being able to pre-negotiate phase 2 SAs is for 1314 applications that use large amounts of data in a period of time that 1315 would be too short for re-keying of the SA used to take place 1316 reliably. 1318 The oldest SA is defined as the first negotiated of the available 1319 SAs. In cases of simultaneous and near simultaneous SA negotiation, 1320 the use of the acknowledged DELETE notification and the ability to 1321 overlap SAs for an arbitrary period of time should make this 1322 condition manageable. 1324 4.4.2 Phase 2 Re-keying Illustration 1326 This section illustrates the events when re-keying occurs using the 1327 above proposals. Note the simplifications due to the decoupling of 1328 SA negotiation, old SA deletion and the transfer of traffic from the 1329 old to the new SA. 1331 Initiator Responder 1333 Inbound Outbound Inbound Outbound 1334 | | | | 1335 1 ----------------- | | 1336 | | ------------ | | 1337 | | -------------------> 2 1338 | | | | | 1339 | | -------------------- 3 1340 | | ------------ | | 1341 4 <--------------- | | 1342 | | | | | 1343 5 ---------------- | | 1344 | *6 | ------------ | | 1345 | | | ------------------> 7 1346 | | | | | 1347 | | | | *8 | 1348 | | | | | | 1349 9 1350 | | | | | | 1351 | | *10 *10 | | | 1352 11 ----------------- | | | | 1353 | | ------------ | | | 1354 | | | -------------------> 12 1355 | | | | | | 1356 | | | | | *13 * 13 1357 | | | | | | 1358 | | | -------------------- 14 1359 | | ------------ *15| | 1360 16 <--------------- | | | 1361 | | | | | 1362 *17| | | | 1363 | | | | 1365 Figure 4-1 Recommended Phase 2 Re-key Sequence Chart, Initiator 1366 Expiration, Future 1368 1) Initiator sends first quick mode message. 1370 2) Responder receives first quick mode message. 1372 3) Responder sends second quick mode message. 1374 4) Initiator receives second quick mode message. 1376 5) Initiator sends third quick mode message. 1378 6) Initiator sets up new inbound SA. Implementations may choose to 1379 set up the new outbound SA at this time, as long as they do not 1380 use it. 1382 7) Responder receives third quick mode message. 1384 8) Responder set up new inbound SA. Implementations may choose to 1385 set up the new outbound SA at this time, as long as they do not 1386 use it. 1388 9) Initiator's old SA pair expires. 1390 10) Initiator starts using new outbound SA and stops using old 1391 outbound SA. 1393 11) Initiator sends first Acknowledged Informational exchange 1394 message with a delete payload. 1396 12) Responder receives first Acknowledged Informational exchange 1397 message. 1399 13) Responder sets up new outbound SA. 1401 13) Responder deletes old outbound SA and starts using new outbound 1402 SA. 1404 14) Responder sends second Acknowledged Informational exchange 1405 message. 1407 15) Responder deletes old inbound SA. 1409 16) Initiator receives second Acknowledged Informational exchange 1410 message. 1412 17) Initiator deletes old inbound SA. 1414 If the responder's old SA expires first, the events are as follows. 1416 Initiator Responder 1418 Inbound Outbound Inbound Outbound 1419 | | | | | | 1420 9 1421 | | | | | | 1422 | | | | | *10 *10 1423 | | | | | | 1424 | | | -------------------< 11 1425 | | | ------------ | | | 1426 12 <--------------- | | | 1427 | | | | | | 1428 | | *13 *13 | | | 1429 | | | | | | 1430 | | | | | | 1431 | | | | | | 1432 14 >--------------- | | | | 1433 15 * | ------------ | | | 1434 | | -------------------> 16 1435 | | | | | 1436 | | 17 * | | 1437 | | | | 1439 Figure 4-2 Recommended Phase 2 Re-key Sequence Chart, Responder 1440 Expiration, Future 1442 9) Responder's old SA pair expires. 1444 10) Responder starts using new outbound SA and stops using old 1445 outbound SA. 1447 11) Responder sends first Acknowledged Informational exchange 1448 message with a delete payload. 1450 12) Initiator receives first Acknowledged Informational exchange 1451 message. 1453 13) Initiator sets up new outbound SA. 1455 13) Initiator deletes old outbound SA and starts using new outbound 1456 SA. 1458 14) Initiator sends second Acknowledged Informational exchange 1459 message. 1461 15) Initiator deletes old inbound SA. 1463 16) Responder receives second Acknowledged Informational exchange 1464 message. 1466 17) Responder deletes old inbound SA. 1468 4.5 Commit Bit Replacement 1470 The intent of this section is to propose a mechanism to allow 1471 implementations to delay the usage of negotiated SAs. Its use may 1472 eliminate the need for the commit bit, and will not suffer from any 1473 of the problems of the commit bit. While the commit bit usage is 1474 much better defined by [IKEbis], it is unable to solve all the 1475 difficulties associated with it. 1477 Replacement of the commit bit is done by the introduction of a new 1478 mechanism to indicate to a peer that usage of a newly negotiated SA 1479 should be deferred. Then, depending on the deferral time intended, 1480 one of two mechanisms is introduced to indicate that the SA may be 1481 used. 1483 These mechanisms are preferred over the commit bit for the following 1484 reasons: 1486 o They receive the full protection of phase 1 SAs, and as such 1487 provide the maximum resistance to denial of service attacks. 1489 o Their use is clearly and unambiguously defined. 1491 o They are resistant to the possibilities of dropped packets. 1493 4.5.1 DEFER_USAGE Notify Payload 1495 The indication that an SA should not be made available for use 1496 immediately by a peer can be indicated by the addition of a new 1497 notify payload to the quick mode that negotiated the SA. To allow a 1498 single quick mode to negotiate multiple SAs, the DEFER_USAGE notify 1499 payload explicitly names the SA whose use is to be deferred, in the 1500 same manner as the current DELETE payload. 1502 The DEFER_USAGE notify payload should be added by the peer wishing 1503 to delay usage of an SA. 1505 On reception of the DEFER_USAGE notify payload, the newly negotiated 1506 SA should be set aside until reception of the ALLOW_USAGE notify 1507 payload, described in the next section, or the reception of the 1508 CONNECTED notification. 1510 The expected response depends on which type of DEFER_USAGE 1511 notification is sent. These types are termed long and short. A short 1512 DEFER_USAGE notification causes a quick mode to become four messages 1513 in length, as with the intended use of the commit bit. A long 1514 DEFER_USAGE notification causes quick mode to proceed normally, with 1515 usage of the specified SA deferred until the sender of the 1516 DEFER_USAGE notification sends the ALLOW_USAGE notify. 1518 Implementations should be prepared to receive the long DEFER_USAGE 1519 notification for the same SA (pair) that they send it for; in other 1520 words, usage of both SAs (inbound and outbound) of the negotiated 1521 pairs may be deferred simultaneously by both peers. 1523 There are no time constraints associated with the sending of the 1524 long DEFER_USAGE notification and the subsequent reception of the 1525 ALLOW_USAGE notification. 1527 Usage of the short DEFER_USAGE notification is restricted to quick 1528 mode responders only. It causes the transmission of a CONNECTED 1529 notification as a fourth quick mode message in the same way that the 1530 commit bit does. 1532 4.5.2 ALLOW_USAGE Notify Payload 1534 The purpose of this notify is to indicate to a peer that an SA may 1535 now be used. Normally, usage of the SA by the peer would have been 1536 deferred by the use of the long DEFER_USAGE notify payload, 1537 described in the previous section. However, reception of this notify 1538 for an SA whose usage has not been deferred is not considered an 1539 error. 1541 This payload MUST be used only with the Acknowledged Informational 1542 exchange. 1544 The initiator of the exchange must start usage of the inbound SA of 1545 the pair when sending the first packet of the exchange. Usage of the 1546 initiator's outbound SA must wait until reception of the 1547 acknowledgement packet of the exchange. 1549 The responder of the exchange must start usage of its inbound SA of 1550 the pair before sending the acknowledgement, and may start usage of 1551 its outbound SA of the pair any time after receiving the first 1552 packet of the exchange. 1554 The initiator of the exchange re-transmits the ALLOW_USAGE 1555 notification until it receives the acknowledgement packet or exceeds 1556 its re-try counter. 1558 If both peers deferred use of the SA, two transactions of the 1559 ALLOW_USAGE notification are required (one in each direction) before 1560 the SAs involved may be used. 1562 5. Acknowledgements 1564 Some of the concepts presented in this document are based on work 1565 done by what was TimeStep Corporation's engineering group. 1567 Others are taken from concepts discussed within the IPsec working 1568 group, particularly some of the concerns expressed about problems 1569 with the commit bit, and also expressed concerns about the 1570 continuous channel model for phase 1 SA re-keying. 1572 Thanks also go to those implementers who have stated the value of 1573 this document, and made suggestions for it. 1575 6. References 1577 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1578 RFC2409, November 1998 1580 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1581 "Internet Security Association and Key Management Protocol 1582 (ISAKMP)", RFC2408, November 1998 1584 [IKEbis]Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1585 draft-ietf-ipsec-ike-01.txt, May 1999, work in progress 1587 Security Considerations 1589 This document is associated with the IPsec family of documents. As 1590 such, security considerations permeate the document. 1592 Author's Address 1594 Tim Jenkins 1595 tjenkins@catenanet.com 1596 Catena Networks, Inc. 1597 Suite 300 1598 320 March Rd. 1599 Kanata, ON 1600 Canada 1601 K2K 2E3 1602 +1 (613) 599-6430 1604 The IPsec working group can be contacted via the IPsec working 1605 group's mailing list (ipsec@lists.tislabs.com) or through its chair: 1607 Theodore Y. Ts'o 1608 tytso@MIT.EDU 1609 Massachusetts Institute of Technology 1611 This document expires September 17, 2000