idnits 2.17.1 draft-jenkins-ipsec-rekeying-04.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 are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 185: '... (b) There SHOULD be two kinds o...' RFC 2119 keyword, line 221: '... implementation SHOULD begin using th...' RFC 2119 keyword, line 222: '...ound traffic and SHOULD continue to su...' RFC 2119 keyword, line 821: '... compliant implementation MUST support...' RFC 2119 keyword, line 1537: '... 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 (February 15, 2000) is 8836 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 1279, but not defined == Missing Reference: 'IKEbis' is mentioned on line 1470, but not defined ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Tim Jenkins 3 IP Security Working Group Newbridge Networks Corporation 4 Internet Draft February 15, 2000 6 IPsec Re-keying Issues 7 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Status of this Memo 14 Informational 16 This memo provides information for the Internet community. This memo 17 does not specify an Internet standard of any kind. 19 Distribution of this memo is unlimited. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or made obsolete by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 . 35 The list of Internet-Draft Shadow Directories can be accessed at 36 . 38 Copyright Notice 40 Copyright (C) Tim Jenkins (2000). 42 Table of Contents 44 1. Introduction..................................................3 45 2. Phase 2 SA Re-keying..........................................3 46 2.1 Phase 2 Re-keying Issues.....................................4 47 2.1.1 Inconsistent SA Use Recommendation.........................5 48 2.1.2 Observed Behaviours........................................6 49 2.1.3 SA Set-up Race Condition...................................6 50 2.1.4 Commit Bit Interaction.....................................8 51 2.2 Solution Examination.........................................9 52 2.2.1 Responder Pre-Set-up.......................................9 53 2.2.1.1 Normal Conditions......................................10 54 2.2.1.2 Dropped Packet Conditions..............................12 55 2.2.1.3 Failed Negotiation.....................................13 56 2.2.1.4 Responder Pre-Set-up Security Hole.....................14 57 2.2.2 Recommended Re-keying Method..............................14 58 2.2.2.1 Dropped Quick Mode 3 Message...........................16 59 2.2.2.2 Absence of Traffic.....................................16 60 2.2.2.3 Compatibility With Observed Behaviours.................17 61 2.2.2.4 Compatibility with Commit Bit..........................17 62 2.2.2.5 Implementation Notes...................................18 63 2.3 Conclusions.................................................18 64 3. Phase 1 SA Re-keying.........................................18 65 3.1 Phase 1 SA Re-keying Requirements...........................19 66 3.2 Phase 1 Re-keying Operation.................................20 67 3.3 A Note About Overlapping Phase 1 SAs........................21 68 3.3.1 Identity Perfect Forward Secrecy..........................23 69 3.4 Other Phase 1 SA Re-keying Issues...........................23 70 3.4.1 Multiple SA Usage.........................................23 71 3.4.2 INITIAL-CONTACT Notification..............................24 72 3.4.3 DELETE Notification.......................................24 73 3.4.4 Re-keying Timing..........................................25 74 4. Next IPsec Version Recommendations...........................25 75 4.1 Re-transmission Rules.......................................26 76 4.1.1 Main Mode Re-Transmission Rules...........................26 77 4.1.2 Aggressive Mode Re-Transmission Rules.....................27 78 4.1.3 Quick Mode Re-Transmission Rules..........................27 79 4.2 Acknowledged SA Deletion....................................27 80 4.3 Phase 1 Re-keying for Future Versions of IPsec..............29 81 4.4 Phase 2 Re-keying for Future Versions of IPsec..............29 82 4.4.1 Oldest Phase 2 SA First...................................29 83 4.4.2 Phase 2 Re-keying Illustration............................30 84 4.5 Commit Bit Replacement......................................34 85 4.5.1 DEFER_USAGE Notify Payload................................34 86 4.5.2 ALLOW_USAGE Notify Payload................................35 87 5. Acknowledgements.............................................36 88 6. References...................................................36 90 1. Introduction 92 This document discusses issues associated with the use of protocols 93 developed in the IETF�s IPsec working group, specifically, RFC 2409 94 [IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is 95 familiar with those documents. 97 This document has three primary objectives. 99 The first objective is to illustrate problems and issues associated 100 with re-keying within the confines of the current set of IPsec 101 documents. For a number of reasons, re-keying in IPsec has become 102 problematic, such that IPsec implementations can drop packets during 103 re-keying. Worse, there exists the possibility that IPsec 104 implementations from different vendors may not be interoperable 105 because of the way they re-key. 107 The second objective of this paper is to propose methods of 108 performing phase 2 re-keying for IPsec implementations in such a way 109 as to minimise packet loss and to maximise compatibility. Again, the 110 primary focus for this is in virtual private networking (VPN) and 111 remote access (RA) applications. 113 The initial focus of the first two objectives is on phase 2 re- 114 keying; it is then extended to phase 1 re-keying. The need for this 115 document in each case is initially discussed, followed by a 116 recommendation for re-keying within the protocol framework 117 established by the initial version of the IPsec documents. 119 Finally, the third objective of the document is to provide 120 recommendations for the next version of the IPsec protocols. These 121 recommendations are made to best solve the re-keying problems in a 122 manner that is not possible within the constraints of the existing 123 IPsec documents. 125 The document also discusses other issues related to SA negotiation, 126 such as SA deletion, packet acknowledgement and the commit bit. 128 2. Phase 2 SA Re-keying 130 This section discusses phase 2 re-keying issues and makes 131 recommendations to minimise the impact of these issues within the 132 current IPsec document set. 134 It is assumed that the purpose of re-keying is that the 135 implementation wants to allow the transfer of traffic processed by 136 the phase 2 SAs from the current phase 2 SA to a replacement phase 2 137 SA in such a way as to minimise the loss of user traffic. 139 It does not preclude the use of idle-timeouts, heartbeats or keep- 140 alives, resource management or other SA management techniques, as 141 may be required by the specific application of IPsec. Nor does it 142 make any specific recommendations about if or when implementations 143 should initiate re-keying. 145 It also does not assume that the implementation has specific 146 knowledge about the peer's behaviour. In other words, the peer's 147 behaviour is assumed to be any of those that may be potentially 148 allowed by the documents. 150 2.1 Phase 2 Re-keying Issues 152 The issues associated with phase 2 re-keying are listed below. Some 153 of the points are expanded upon later. 155 1) There is no specification explicitly defining how the transfer 156 of traffic from old to new SAs is to be done. 158 2) The existing drafts appear contradictory in their 159 recommendations on the usage of multiple phase 2 SAs. 161 3) Some implementations have shipped with a method of re-keying 162 that will not perform reliably under real world network 163 conditions. 165 4) The use of the DELETE notification is not required. 167 5) A variety of re-keying behaviours have been observed, some of 168 which are incompatible. 170 6) The commit bit is not yet widely implemented, and its use as 171 described is confusing. Further, while the documentation 172 requires its support, its use is not required. 174 7) A race condition exists at SA set up, exacerbating re-keying 175 issues. 177 RFC 2401 provides only this guidance (from section 4.4.3): 179 NOTE: The details of how to handle the refreshing of keys 180 when SAs expire is a local matter. However, one 181 reasonable approach is: 183 ... 185 (b) There SHOULD be two kinds of lifetime -- a soft 186 lifetime which warns the implementation to initiate 187 action such as setting up a replacement SA and a 188 hard lifetime when the current SA ends. 190 As such, it makes no recommendations as to how traffic should be 191 moved to the replacement SA. 193 2.1.1 Inconsistent SA Use Recommendation 195 The issue of inconsistent SA usage recommendations is examined 196 further here. 198 From paragraph 2 of Section 9 of [IKE]: 200 An implementation may wish to negotiate a range of SAs when 201 performing Quick Mode. By doing this they can speed up the "re- 202 keying". Quick Mode defines how KEYMAT is defined for a range of 203 SAs. When one peer feels it is time to change SAs they simply use 204 the next one within the stated range. A range of SAs can be 205 established by negotiating multiple SAs (identical attributes, 206 different SPIs) with one Quick Mode. 208 While the document does not define what "... the next one ..." 209 means, this paragraph strongly implies that there is no required 210 order for the use of phase 2 SAs that have been negotiated within a 211 phase 1 SA, and that multiple SAs may be pre-negotiated and used at 212 will. 214 However, this appears to be contradicted by paragraph 3 of section 215 4.3 of [ISAKMP]: 217 Modification of a Protocol SA (phase 2 negotiation) follows the 218 same procedure as creation of a Protocol SA. The creation of a new 219 SA is protected by the existing ISAKMP SA. There is no 220 relationship between the two Protocol SAs. A protocol 221 implementation SHOULD begin using the newly created SA for 222 outbound traffic and SHOULD continue to support incoming traffic 223 on the old SA until it is deleted or until traffic is received 224 under the protection of the newly created SA. As stated previously 225 in this section, deletion of an old SA is then dependent on local 226 security policy. 228 Many implementations have interpreted this to mean that the new SA 229 should be used for outbound traffic in preference to the old SA. 231 Extending this logic may have caused implementations to abandon the 232 old SA as soon as possible. 234 This interpretation of [ISAKMP] is in direct conflict with the usage 235 implied by [IKE], resulting in potential problems. 237 2.1.2 Observed Behaviours 239 The following behaviours have been observed by various vendors' 240 implementations when devices have set up a second phase 2 SA. The 241 behaviours listed below are not necessarily mutually exclusive. 243 1) The device continues to use the old SA until it naturally 244 expires, then switches to the new SA. 246 2) The device immediately begins using the new SA. 248 3) The device immediately drops the old SA. 250 4) The device never sends a DELETE notification. 252 5) The device always sends a DELETE notification. 254 6) The device deletes the old SA some time after re-keying, but 255 before the end of its natural lifetime. 257 7) A device wants to keep more than one SA up all the time. 259 All of these behaviours are permitted under the current documents. 260 However, even when quick mode packets are not lost, it can be seen 261 that interoperability is not always possible with some combinations 262 of behaviours listed above. 264 2.1.3 SA Set-up Race Condition 266 Further, behaviour 2 above is not a good behaviour, as illustrated 267 below. In this example, the initiator is a gateway capable of 268 handling full T3 bandwidth rates, while the responder is a PC 269 running a software IPsec implementation and it is overloaded. 271 In the illustration, QM1 refers to the first quick mode message, QM2 272 to the second quick mode message and QM3 to the third quick mode 273 message. 275 Initiator Responder 277 QM1 sent ---- 278 ------- 279 ------------- 280 ---------------> QM1 received 281 | 282 | 283 | QM1 processed 284 | 285 | 286 ---------------- QM2 sent 287 ------------- 288 ------- 289 QM2 rec. <---- 290 process | 291 QM3 sent ----- 292 * ------- 293 packet on new SA ------------- 294 _____ ---------------> QM3 received 295 _______ | 296 _____________ | QM3 processing 297 _______________| 298 | packet dropped 299 | 300 * new SA set up 302 Figure 2-1 Race Condition Sequence Chart 304 By the time the responder has set up the new SA, packets protected 305 by that SA have already started arriving from the initiator. This 306 causes them to be dropped by the responder. This case is further 307 complicated by the possibility of packets taking different paths 308 through the network, so the third quick mode message could arrive 309 after packets protected by the new SA. 311 Additionally, since all IKE packets are based on UDP, there is no 312 guarantee that QM3 even arrives at the peer, so making assumptions 313 about new SA use based on the transmission time of a packet will 314 still lead to failures in the field. 316 To reduce the effects of packet loss, some implementations were 317 observed to blindly transmit QM3 multiple times, back to back. 319 This can reduce the probability that the peer does not get QM3, but 320 cannot eliminate it. Nor can it eliminate race conditions due to 321 path differences or processing times. 323 If the behaviour of the initiator was to delay usage of the new SA 324 for outbound traffic, this would cause failures for those 325 implementations that immediately delete the old SA. Therefore, the 326 behaviours of delaying use of the new SA and immediately deleting 327 the old SA are incompatible. 329 2.1.4 Commit Bit Interaction 331 The use of the commit bit can solve the race condition illustrated 332 in the previous section when asserted by the responder during quick 333 mode. However, it suffers from the following problems: 335 1) Use of the commit bit is not well defined. The present 336 documentation ([ISAKMP]) specifies its use for phase 1 and 337 phase 2, but mentions phase 2 specific details. There are also 338 issues related to how the subsequent CONNECTED notification 339 fits in with the quick mode exchange. 341 2) While its support is required, its use is not. 343 3) Its use may make implementations susceptible to a denial of 344 service attack by forcing initiators to wait for a CONNECTED 345 notification that may never come. While this is only one of a 346 number of possible denial of service attacks on IKE, this is 347 not an excuse to leave the existing implementation as it is. 349 4) There is no defined way to recover from the loss of the 350 CONNECTED notification. 352 5) Some implementations are using the commit bit for the wrong 353 reasons. 355 The working group is addressing point 1; future versions of the 356 IPsec documents should clarify these issues. [IKEbis] has gone a 357 long way in clarifying this issue. 359 Point 3 happens because the commit bit is in the ISAKMP header, and 360 the ISAKMP header is not authenticated, so the commit bit is 361 susceptible to undetectable modification. 363 Point 5 above needs some elaboration. In a previous section, it was 364 mentioned that the loss of the third quick mode message could cause 365 problems, since the responder will not set up the SA at all. Because 366 of this, some implementations have chosen to set the commit bit as a 367 mechanism to force the re-transmission of the third quick mode 368 message. 370 This is wrong for two reasons. First, it is not the stated purpose 371 of the commit bit. The purpose of the commit bit is to delay the 372 usage of an SA, for whatever reason. This implies that it is not a 373 good mechanism to cause re-transmission of the third quick mode 374 message. 376 Secondly, it does not solve the packet loss problem; it only defers 377 it. The logic of the improper usage is that the initiator will re- 378 send the third quick mode message until it receives the CONNECTED 379 notification (which is now effectively the fourth quick mode 380 message). 382 The problem with this is that it leaves no mechanism for demanding 383 the re-transmission of the CONNECTED notification itself. It can be 384 dropped just as the third quick mode message can. This means that 385 the problem that was intended to be solved by the use of the commit 386 bit is simply pushed out to being the problem of solving the dropped 387 CONNECTED notification. 389 Sections 2.2.2.1 and 4.1 describe a mechanism for solving the 390 dropped third quick mode message problem. 392 2.2 Solution Examination 394 This section details the operation of some possible behaviours, with 395 the intent of arriving at a best possible phase 2 re-keying 396 mechanism under the constraints of the existing documents. 398 In all the examples, the term "sets up a new outbound SA" means that 399 the new outbound SA will be chosen in favour of the old one. Whether 400 the SA is actually created before that time or not is implementation 401 dependent. 403 2.2.1 Responder Pre-Set-up 405 As a starting point, the responder pre-set-up method of re-keying is 406 examined. Note that it will work with most of the behaviours 407 observed in the field. 409 In this method, SAs are treated separately as inbound and outbound, 410 as well as old and new. Further, it takes advantage of the fact that 411 the responder knows what the SA is going to be after the second 412 quick mode message is sent. By using this information, it allows the 413 responder to set up the new inbound SA before having received the 414 third quick mode message. 416 Implicit acknowledgement of the reception of the third quick mode 417 message by the responder is provided by use of the new SA in the 418 initiator's inbound direction. The initiator should not use its new 419 outbound SA before that time. 421 Additionally, it does not require use of the CONNECTED notification 422 for prevention of the race condition, or the use of the DELETE 423 notification for removal of the old SA. This is important since, 424 even if they are always sent, they are unacknowledged UDP packets 425 and may be lost. 427 2.2.1.1 Normal Conditions 429 Figure 2-2 shows the operation under normal (successful) conditions. 431 While appearing complicated, it enables the lossless transfer from 432 one SA to another while supporting almost all other behaviours. 434 Support for and use of the DELETE notification is unchanged. 436 Initiator Responder 438 Inbound Outbound Inbound Outbound 439 | | | | 440 1 ----------------- | | 441 | | ------------ | | 442 | | -------------------> 2 443 | | | | | 444 | | -------------------- 3 445 | | ------------ | *4 | 446 5 <--------------- | | | 447 | | | | | | 448 6 ---------------- | | | 449 | *7 | ------------ | | | 450 | | | -------------------> 8 451 | | | | | | | 452 | | | | | | * 453 | | | | | | *9 454 | | | | | *10 | 455 | | | | | | 456 | *11 | | | | 457 | | | *12 | | | 458 | | *13 | | | | 459 *14| | | | | 460 | | | *15 | 461 | | *16| | 462 | | | | 464 Figure 2-2 Phase 2 SA Pre-Setup Sequence Chart 466 Events 468 1) Initiator sends first quick mode message. 470 2) Responder receives first quick mode message. 472 3) Responder sends second quick mode message. 474 4) Responder sets up new inbound SA. This is to handle the case 475 where the initiator starts transmitting on the new SA 476 immediately after sending the third quick mode message. 478 5) Initiator receives second quick mode message. 480 6) Initiator sends third quick mode message. 482 7) Initiator sets up new inbound SA. 484 8) Responder receives third quick mode message. 486 9) Responder sets up new outbound SA. 488 10) Responder deletes old outbound SA. 490 11) Traffic from responder to initiator arrives at initiator on new 491 SA. 493 12) Initiator sets up new outbound SA. 495 13) Initiator deletes old outbound SA. 497 14) Initiator deletes old inbound SA. 499 15) Traffic from initiator to responder arrives at responder on new 500 SA. 502 16) Responder deletes old inbound SA. 504 2.2.1.2 Dropped Packet Conditions 506 In this case, the event list is modified to show what happens when 507 each packet is dropped once. The event numbers refer to those 508 illustrated in Figure 2-2. 510 1) Initiator sends first quick mode message. 512 e) Packet is dropped during transmission. 514 1b) Initiator times out waiting for second quick mode message. 516 1) Initiator re-sends first quick mode message. 518 2) Responder receives first quick mode message. 520 3) Responder sends second quick mode message. 522 4) Responder sets up new inbound SA. This is to handle the case 523 where the initiator starts transmitting on the new SA 524 immediately after sending the third quick mode message. 526 e) Packet is dropped during transmission. 528 1b) or 7b) Responder times out waiting for third quick mode 529 message. 531 1) or 3) Responder re-sends second quick mode message. 533 5) Initiator receives second quick mode message. 535 6) Initiator sends third quick mode message. 537 7) Initiator sets up new inbound SA. 539 e) Packet is dropped during transmission. 541 7b) Responder times out waiting for third quick mode message. 543 3) Responder re-sends second quick mode message. 545 5) Initiator receives second quick mode message again. 547 6) Initiator re-sends third quick mode message. 549 8) Responder receives third quick mode message. 551 and so on, as for normal operation. 553 2.2.1.3 Failed Negotiation 555 In this case, the second quick mode packet has an invalid hash, and 556 the initiator sends the notification to the peer. Again, the event 557 numbers refer to those illustrated in Figure 2-2. 559 1) Initiator sends first quick mode message. 561 2) Responder receives first quick mode message. 563 3) Responder sends second quick mode message. 565 4) Responder sets up new inbound SA. This is to handle the case 566 where the initiator starts transmitting on the new SA 567 immediately after sending the third quick mode message. 569 5) Initiator receives second quick mode message. 571 e) Hash (or other parameter) fails. 573 e1) Initiator sends notification to responder. 575 e2) Responder receives notification. 577 e3) Responder deletes new inbound SA. 579 A similar operation would occur if retry counters expire for packet 580 re-transmissions. 582 2.2.1.4 Responder Pre-Set-up Security Hole 584 In the failed negotiation case, the need to delete the invalid 585 inbound SA raises the issue of a temporary hole, in that the 586 responder allows inbound packets while waiting for the third quick 587 mode message. However, if the inbound SA is not set up ahead of 588 time, initiators that immediately transmit on the new outbound SA 589 will cause packets to be dropped. 591 It also illustrates why the proposal above made the usage of the 592 outbound SA by the initiator wait until there is an indication of 593 the use of the SA by the responder. 595 Note that this security hole is exactly what would result from an 596 attacker replaying the first quick mode message of an exchange. 598 2.2.2 Recommended Re-keying Method 600 In this method, the previous method is modified to remove the risk 601 of the security hole. It also simplifies the operation somewhat, but 602 at the expense of lost packets if the initiator's behaviour is such 603 that it immediately uses the new SA for its outbound traffic. 605 Note that deletion of the old inbound SA by the initiator could be 606 further delayed if protection against loss of packets using the old 607 SA on different and slower network paths is desired. 609 Initiator Responder 611 Inbound Outbound Inbound Outbound 612 | | | | 613 1 ----------------- | | 614 | | ------------ | | 615 | | -------------------> 2 616 | | | | | 617 | | -------------------- 3 618 | | ------------ | | 619 4 <--------------- | | 620 | | | | | 621 5 ---------- | | | 622 | *6 ------------------ | | 623 | | | -------------------> 7 624 | | | | | | 625 | | | | | * 626 | | | | *8 | 627 | | | | | | *9 628 | | | | | *10 | 629 | | | | | | 630 | *11 | | | | 631 | | | *12 | | | 632 | | *13 | | | | 633 *14| | | | | 634 | | | *15 | 635 | | *16| | 636 | | | | 638 Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 640 1) Initiator sends first quick mode message. 642 2) Responder receives first quick mode message. 644 3) Responder sends second quick mode message. 646 4) Initiator receives second quick mode message. 648 5) Initiator sends third quick mode message. 650 6) Initiator sets up new inbound SA. 652 7) Responder receives third quick mode message. 654 8) Responder sets up new inbound SA. 656 9) Responder sets up new outbound SA. 658 10) Responder deletes old outbound SA. 660 11) Traffic from responder to initiator arrives at initiator on new 661 SA. 663 12) Initiator sets up new outbound SA. 665 13) Initiator deletes old outbound SA. 667 14) Initiator deletes old inbound SA. 669 15) Traffic from initiator to responder arrives at responder on new 670 SA. 672 16) Responder deletes old inbound SA. 674 2.2.2.1 Dropped Quick Mode 3 Message 676 In cases where the third quick mode message is dropped, the 677 responder must request re-transmission of it by re-sending the 678 second quick mode message. The existence of traffic on the new 679 inbound SA at the initiator should not be used as an implicit 680 acknowledgement for the following reasons: 682 1) There may be no traffic for the responder to send. 684 2) The responder may be designed to use the old SA until its 685 natural expiration. 687 This implies that implementations must be able to respond to the re- 688 transmission of the second quick mode message even after having sent 689 the third quick mode message. 691 2.2.2.2 Absence of Traffic 693 The proposed implementation uses the presence of traffic from the 694 responder on new SAs to provide an implied acknowledgement for the 695 purposes of switching to the new SA. However, if there is no traffic 696 from the responder, the implied acknowledgement will not appear. 698 A similar behaviour is exhibited by implementations that continue to 699 use old SAs until their natural expiration. 701 However, due to the number of implementations that delete old SAs 30 702 seconds after negotiating a new one, the same behaviour has the best 703 chance of interoperability, and of not dropping packets when traffic 704 does restart. 706 Therefore, it is recommended that implementations delete old SAs and 707 start using new SAs 30 seconds after negotiating new SAs in the 708 absence of traffic. Use of the DELETE notification is strongly 709 recommended in cases where the peer implementation is continuing to 710 use the old SA. 712 2.2.2.3 Compatibility With Observed Behaviours 714 When responders use the proposed method and the initiator is an 715 implementation that uses the new SA immediately, there is no 716 difference in SA transfer performance compared to the responder also 717 using the new SA immediately. This is because the proposed method 718 tries to use the new SA immediately on inbound, so it will be ready 719 to receive on the new SA just as fast as an implementation that 720 starts using the new immediately under all conditions. However, 721 since the initiator is also using the new SA immediately, there is a 722 possibility that packets will arrive at the responder on the new SA 723 before the responder has time to set up the new SA. 725 When the initiator uses the proposed method, the performance (packet 726 loss when transferring to the new SA) will depend on when the 727 responder deletes the old inbound SA. 729 When operating with behaviours that continue to use the old SA, this 730 method performs as described in the dropped quick mode three example 731 above when used by the initiator. When used by the responder, there 732 is no change in operation, since the responder will wait until the 733 new SA is used before deleting the old SA. 735 However, as stated in a previous section, it is recommended that the 736 initiator keep the old SA (both inbound and outbound) for only 30 737 seconds after creation of the new SA in cases where traffic is not 738 detected on the new SA. 740 2.2.2.4 Compatibility with Commit Bit 742 If the responder sets the commit bit with this proposal, some of the 743 problems described in Section 2.1.4 may occur. To reduce the effects 744 of these problems, following rules should be followed: 746 1) The initiator should set up its inbound SA immediately after 747 sending the third quick mode message regardless of the state of 748 the commit bit. 750 2) Sensing of traffic on the initiator's new inbound SA should 751 trigger the use of the new outbound SA to detect cases when the 752 CONNECTED notification is dropped. 754 The recommended proposal does not allow built-in support of the 755 commit bit. It does allow responders that use the commit bit to 756 detect reception of the CONNECTED notification by the initiator due 757 to the presence of traffic on its new inbound SA. However, this 758 works only if there is traffic, so it cannot be considered a useful 759 method to perform this function. 761 The recommended proposal does cause the initiator to delay usage of 762 a new SA until it is set up. This is the primary use of the commit 763 bit, so use of this proposal makes the use of the commit bit 764 unnecessary except for the setting up of the first phase 2 SA. 766 2.2.2.5 Implementation Notes 768 The presence of traffic on the new SA can be part of the expiration 769 checking operation, and does not need to occur instantaneously, 770 although it must occur before the 30 second no traffic SA deletion 771 criteria. As long as the new SA is negotiated with enough time 772 before the expiration of the old one, the detection of traffic on 773 the new SA can be on the order of seconds with no ill effects. 775 Since SAs will likely have traffic counters anyway, this method 776 requires only the addition of a flag that indicates it is a new SA. 777 When the expiration process checks for ageing and expired SAs, it 778 can also check for new SAs with a non-zero traffic count. When 779 detected, the SA is marked as non-new, and the remaining operations 780 can be performed. 782 2.3 Conclusions 784 The final re-keying method is the best compromise for 785 interoperability within the framework of the current IPsec documents 786 without compromising security. 788 3. Phase 1 SA Re-keying 790 This section discusses phase 1 SA re-keying. This proposal is 791 necessary for many of the same reasons a phase 2 SA re-keying 792 proposal is necessary. 794 1) As mentioned above, the rules for phase 1 SA re-keying are not 795 specified in the drafts. 797 2) Adhoc implementations have lead to possible interoperability 798 issues. 800 This section discusses potential requirements of phase 1 re-keying, 801 and presents some options and issues associated with those options. 803 3.1 Phase 1 SA Re-keying Requirements 805 Two reasons for re-keying a phase 1 SA are for freshness (time or 806 other) of the phase 1 SA keying material (affecting its ability to 807 protect phase 2 SA negotiations and to generate phase keying 808 material) and for re-authentication (and therefore authorisation) of 809 the encrypting devices. 811 The authorisation lifetime restriction reason stated above was 812 inferred as necessary due to the following paragraph from 813 section 4.4.3 of RFC 2401 (the Security Associations being discussed 814 are phase 2 SAs): 816 o Lifetime of this Security Association: a time interval after 817 which an SA must be replaced with a new SA (and new SPI) or 818 terminated, plus an indication of which of these actions 819 should occur. This may be expressed as a time or byte count, 820 or a simultaneous use of both, the first lifetime to expire 821 taking precedence. A compliant implementation MUST support 822 both types of lifetimes, and must support a simultaneous use 823 of both. If time is employed, and if IKE employs X.509 824 certificates for SA establishment, the SA lifetime must be 825 constrained by the validity intervals of the certificates, 826 and the NextIssueDate of the CRLs used in the IKE exchange 827 for the SA. Both initiator and responder are responsible for 828 constraining SA lifetime in this fashion. 829 [REQUIRED for all implementations] 831 Note particularly the lifetime constraint comments in the last two 832 sentences. 834 However, this restriction reason stated above has been deemed 835 unimportant by the working group as a factor in determining how 836 phase 1 SAs are used and re-keyed for two reasons: 838 1) System administrators understand IPsec well enough to configure 839 the combination of phase 1 and phase 2 SA lifetimes such that 840 terminating phase 2 SAs when authentication ends means the 841 unauthorised usage period is insignificant. 843 2) Many implementations will be required to produce a mechanism to 844 tear down SAs created by entities that are no longer authorised. 845 This is considered manual intervention, and thus not important 846 for normal unattended operation. 848 The net result of this is that phase 1 SAs do not need to be 849 overlapped to provide a continuous indication of peer authorisation 850 to allow phase 2 SAs to continue to exist. 852 Therefore, the only reason to re-key phase 1 SAs is due to keying 853 material expiration. Further, it means that phase 1 SA and phase 2 854 SA lifetimes are unbound; that is, there are no requirements that a 855 phase 1 SA exist between two peers that have phase 2 SAs. 857 However, some applications may consider it advantageous to attempt 858 to keep a valid phase 1 SA up between peers at all times. This would 859 require overlapping of phase 1 SAs, and re-keying of old SAs before 860 they expire. However, these implementations must be aware that peers 861 may not be trying to do this, and in fact may be trying to reduce 862 unused resource requirements by deleting the phase 1 SA. 864 Factors to consider in determining how to re-key phase 1 SAs that 865 are not RFC-based requirements are resource issues (memory 866 requirements versus complex calculation requirements), SA usage with 867 respect to time (normal SA usage very short lived, for example), 868 reliability requirements, and other possible application specific 869 factors. 871 3.2 Phase 1 Re-keying Operation 873 Summarised, the procedure for phase 1 re-keying is: 875 Initial Phase 1 SA Negotiation: 876 -initiator must use INITIAL-CONTACT notification 877 -responder should use INITIAL-CONTACT notification (when 878 possible) 879 -responder deletes any pre-existing phase 1 SA with the peer when 880 authentication of peer is complete (in cases of simultaneous 881 initiation, the other "new" phase 1 SA should not be deleted) 882 -responder deletes all previously existing phase 2 SAs with the 883 peer, if any 885 Phase 1 SA Expiration: 886 -DELETE notification should be sent for phase 1 SA only 887 -phase 2 SAs between peers are left untouched 889 New Phase 1 SA Negotiation: 890 -initiator must not use INITIAL-CONTACT notification 891 -responder must detect that this is a re-key and must not use 892 INITIAL-CONTACT notification 893 -no INITIAL-CONTACT notification is used by either end, so phase 894 2 SAs are kept 896 Phase 2 SA Ages, and no existing phase 1 SA 897 -attempt New Phase 1 SA Negotiation 898 -if that succeeds, attempt new phase 2 SA negotiation 900 If an implementation wants to overlap phase 1 SAs, the following 901 procedure is recommended: 903 Phase 1 SA Ages: 904 -peer that first detects this or desires overlapping phase 1 SAs 905 negotiates new phase 1 SA; becomes new initiator 906 -responder should mark any existing phase 1 SAs as re-keyed, so 907 as to not re-key again if it also desires overlapping phase 1 SAs 909 3.3 A Note About Overlapping Phase 1 SAs 911 An earlier version of this document promoted having overlapping 912 phase 1 SAs at all times. This was presented as the continuous 913 channel model. Continuous channel implementations are those 914 implementations that attempt to always maintain at least one valid 915 phase 1 SA between any peers that have phase 2 SAs. 917 The reasons and advantages of this method are discussed here. 918 However, it must be re-iterated that there are no RFC-based 919 requirements that implementations follow this model. In fact, 920 implementations should not insist on this model due to the 921 possibility that the peer may be attempting to minimise resource 922 usage. 924 The continuous channel method is implicitly recommended by RFC 2408. 925 The following quote is from paragraph six of [ISAKMP]: 927 Third, having an ISAKMP SA in place considerably reduces the cost 928 of ISAKMP management activity - without the "trusted path" that 929 an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would 930 have to go through a complete re-authentication for each error 931 notification or deletion of an SA. 933 The primary advantage of the continuous existence of the logical 934 channel is that it allows cleaner management of phase 2 SAs, 935 particular if the two entities become unsynchronised for any reason. 937 It is useful whenever premature termination of communications occurs 938 when the phase 1 SAs cannot be re-created. These conditions occur 939 potentially under the following conditions: 941 1) A time-based policy is used that restricts user access to 942 specific hours of the day, and only phase 1 authorization catches 943 this. 945 2) A user's permissions are totally revoked. 947 3) A token card-based user removes the token card from the system. 949 4) Some other policy or configuration change. 951 A specific application for this model that provides distinct 952 advantages is with the use of token cards. For example, if a user�s 953 phase 1 authentication and authorisation is bound by the presence of 954 a token card in a reader, the removal of the card should result in 955 all SAs being torn down. Since there exists a continuous channel, 956 delete notifications (acknowledged or not) can be sent for all SAs 957 when the token card is removed from the system. However, if the 958 phase 1 SA was allowed to be deleted without being re-keyed, the 959 local end can only unilaterally delete its SAs, leaving the two end 960 points out of sync with each other. (It cannot send delete 961 notifications since the absence of the card makes it unable to re- 962 establish a phase 1 SA.) 964 Depending on the application, the above cases may fall under the 965 category of special events, and thus not having significant weight 966 when determining if the continuous channel model is the correct 967 implementation to be used. 969 The continuous channel model also allows a responder to initiate re- 970 keying under conditions where its SAs expire before the initiator's 971 and configuration does not allow it to normally initiate to the 972 peer. This situation is currently permitted by the RFCs if 973 implementation should choose to not send or support the use of the 974 RESPONDER-LIFETIME notification when the initiator's proposal has 975 longer lifetimes than the responder is willing to accept. 977 Also, this model more closely ties endpoint authorization to phase 2 978 SA lifetime. 980 The disadvantages of the continuous channel model of implementation 981 are that it uses more resources (always keeps a phase 1 SA, and 982 potentially uses more key generation), and is slightly more complex 983 to implement. 985 Finally, it must be aware of implementations that do not want or 986 need phase 1 SAs that are continuously available. 988 3.3.1 Identity Perfect Forward Secrecy 990 Allowing the use of only a single phase 2 negotiation in a phase 1 991 SA is how identity PFS is done. This is controlled by the deletion 992 of the phase 1 SA after a phase 2 negotiation. 994 In implementations that do not wish to delete all phase 1 SAs, this 995 can be done by creating two phase 1 SAs before the first phase 2 996 negotiation is done. The first of these SAs is assigned the role of 997 channel management, and thus performs SA deletion and notification 998 transfer. The second SA is used to perform phase 2 negotiations, and 999 is immediately deleted. 1001 The phase 1 SA that is assigned to channel management is re-keyed to 1002 create the overlapping phase 1 SAs. Since it is the oldest phase 1 1003 SA, it will naturally be used for all management traffic even if 1004 another phase 1 SA temporarily exists only for the purpose of 1005 performing a quick modes (see Section 3.4.1). Other phase 1 SAs are 1006 created and used to protect phase 2 negotiations and then they are 1007 immediately deleted. 1009 Since Identity PFS is not negotiated, it may not be possible to 1010 guarantee that the peer knows Identity PFS is being used. In this 1011 case, the initiator may be required to delete its channel management 1012 SA and create a new one if the peer uses that phase 1 SA to re-key a 1013 phase 2 SA. 1015 3.4 Other Phase 1 SA Re-keying Issues 1017 This section describes other issues associated with phase 1 SA re- 1018 keying that are independent of the whether the implementation 1019 intentionally overlaps phase 1 SAs or not. 1021 3.4.1 Multiple SA Usage 1023 When there is more than one phase 1 SA between peers, it is 1024 recommended that the oldest SA be used for subsequent traffic 1025 requiring phase 1 SAs. This allows full use of the keying material 1026 generated and reduces race conditions. It also means that no special 1027 expiration conditions are required when the phase 1 SAs expire by 1028 traffic or other usage dependent expirations only, as the old SA 1029 will eventually expire on its own due to usage. 1031 3.4.2 INITIAL-CONTACT Notification 1033 As stated above, the INITIAL-CONTACT notification should be used 1034 only with the very first phase 1 SA that is negotiated between two 1035 peers. 1037 If used on subsequent negotiations, it means that all pre-existing 1038 SAs (phase 1 and phase 2) held between the peers should be deleted. 1040 As an example, this is the mechanism used to detect when an SA end 1041 point has crashed and is now alive again. 1043 The use of INITIAL-CONTACT may be restricted by the mode used to 1044 negotiate phase 1 SAs. For these reasons, implementations may want 1045 to avoid the use of aggressive mode when possible. When it is used, 1046 it is recommended that the third aggressive mode message be 1047 encrypted so that the INITIAL-CONTACT notification can be added to 1048 it when needed. Note that the use of any notification by a responder 1049 during aggressive mode is not allowed, and this document's 1050 suggestion that the use of INITIAL-CONTACT is permitted by the 1051 initiator if the third aggressive mode packet is encrypted is 1052 possibly contrary to RFC2408. 1054 Alternatively, if notifications cannot be used within the phase 1 1055 modes at all, it is recommended that INITIAL-CONTACT be sent in a 1056 notification packet (preferably acknowledged) immediately after the 1057 phase 1 is complete. Reception of this notification (at any time) 1058 should indicate to the receiver that all other SAs, phase 1 and 1059 phase 2, with the sender must be deleted. (In other words, the SA 1060 that was used to encrypt the notification is the only SA that is not 1061 deleted.) 1063 3.4.3 DELETE Notification 1065 As currently defined by the IPsec documents, the DELETE notification 1066 is advisory only and is optional and unacknowledged. 1068 Given that it is optional, UDP based, and not used by some existing 1069 implementations, it should never be considered necessary. 1071 However, even though its use is of dubious value, it should be sent 1072 when any SA (phase 1 or phase 2) is deleted. Since the expiration of 1073 SAs might not occur at the same time at both ends for a number of 1074 reasons, use of the DELETE notification can increase the probability 1075 that both ends are synchronised with respect to SA usage. 1077 Further, implementations should attempt to use the acknowledged 1078 notify exchange as described in [IKEbis]. 1080 3.4.4 Re-keying Timing 1082 To reduce the probability of simultaneous re-keying, each device 1083 should re-key at a variable time with respect to the SA's expiration 1084 limit, in case they are the same. These recommendations apply to 1085 both phase 1 and phase 2 SAs. 1087 An example of this is that the end with the higher IP address re- 1088 keys at 95% of the lifetime, while the end with lower IP address re- 1089 keys at 85% of the lifetime. 1091 Whatever rule is chosen, it is recommended that the rule be 1092 deterministic in order to have predictable and consistent behaviour 1093 between peers. If the rule had used the SPI as the determining 1094 factor (as an example did in the first version of this document), 1095 different peers would be doing the re-keying at different times. 1097 In any case, simultaneous attempts at re-keying should be supported 1098 in one form or another, since it can never be guaranteed that this 1099 will not happen under all circumstances. 1101 4. Next IPsec Version Recommendations 1103 The recommendations made in sections 2 and 3 of this document have 1104 limitations in their ability to provide lossless, reliable and 1105 interoperable SA re-keying due to restrictions of existing 1106 implementations and the existing IPsec documentation. 1108 This section makes recommendations for explicit re-transmission 1109 rules, phase 1 and phase 2 re-keying, and describes the use of a new 1110 mode for reliable SA deletion in order to help provide reliable, 1111 lossless and interoperable re-keying. 1113 Also, a replacement for the commit bit is proposed. 1115 4.1 Re-transmission Rules 1117 In systems that use exchanges that have an even number of packets, 1118 the rules for re-transmission are relatively obvious. Simply put, a 1119 packet is re-sent if the expected response to it is not received 1120 within a certain period of time. 1122 However, IPsec has a number of modes that have an odd number of 1123 packets. This can lead to confusion as to when the re-transmission 1124 rules should be applied, depending how the re-transmission rules are 1125 applied to the packets in the exchange. This in turn can lead to the 1126 dropping of aggressive mode's and quick mode's third messages. It is 1127 recommended that each of these modes have specific rules applied to 1128 them to avoid re-transmission issues. 1130 These rules will be applied based on request-response pairs. Packets 1131 are defined as a request or a response in an exchange. The requestor 1132 is responsible for re-sending the request in order to solicit the 1133 response. The responder (not to be confused with an SA negotiation 1134 responder) is responsible for re-sending the response as it receives 1135 the initial and subsequent transmissions of the request. Note that 1136 the responder must exist after transmitting a response in case that 1137 response is dropped. 1139 In the modes with an odd number of packets, the request-response 1140 pair must be applied across the odd number of packets. This means 1141 that at least one packet must be considered the response to the 1142 previous packet, and must also be considered the request of the next 1143 request-response pair. 1145 This means that an implementation must be able to perform re- 1146 transmission of packets after it normally would have considered 1147 itself to be done with an exchange or a mode. Further, any timers 1148 set by the transmission of the final message of an exchange should 1149 be reset when re-transmission occurs. 1151 4.1.1 Main Mode Re-Transmission Rules 1153 In main mode, there are effectively three completely separate 1154 exchanges. The first request-response pair contains the SA 1155 proposals, the second pair contains the keying material, and the 1156 third pair contains the authentication material. (These descriptions 1157 are generalised for the purposes of stating what the exchanges are, 1158 and are not intended to create discussion on the actual contents of 1159 the exchanges.) 1160 As an example of the separation of the exchanges, there is no need 1161 to re-send the second main message to solicit the third main mode 1162 message, since the responder should not send the fourth main mode 1163 message until receiving the third main mode message. The absence of 1164 the fourth main mode message will cause the initiator to re-send the 1165 third main mode message. 1167 Keeping the exchanges separate from a re-transmission point of view 1168 should simplify implementations. 1170 4.1.2 Aggressive Mode Re-Transmission Rules 1172 In aggressive mode, the second message is the message that is both a 1173 response and a request. Therefore, the responder in a phase 1 1174 negotiation that uses aggressive mode must re-transmit the second 1175 aggressive mode message to solicit a third aggressive mode message 1176 that it perceives as lost. 1178 4.1.3 Quick Mode Re-Transmission Rules 1180 In quick mode, the second message is the message that is both a 1181 response and a request. Therefore, the responder in a phase 1 1182 negotiation must re-transmit the second quick mode message to 1183 solicit a third quick mode message that it perceives as lost. 1185 These rules must apply independently of the state of the commit bit, 1186 since there are currently no timing restrictions on the transmission 1187 of the CONNECTED notification. 1189 4.2 Acknowledged SA Deletion 1191 A previous version of this document described a new mode called 1192 Delete Mode. This mode is no longer necessary, as the new proposed 1193 Acknowledged Informational exchange can be used with the delete 1194 payload to perform the same thing. (See section 6.4.2 of [IKEbis].) 1196 This section (of this document) describes in detail how the 1197 Acknowledged Informational exchange should be used when deleting 1198 SAs. 1200 The Acknowledged Informational exchange consists of two packets. The 1201 first packet is the transmission of a notify or delete payload. The 1202 second is the acknowledgement of that packet. 1204 When used with a delete payload, it is interpreted to mean the 1205 following: 1207 "I am not sending anymore traffic on this SA (or these SAs). Would 1208 you please stop sending traffic on it (or them), and send me an 1209 acknowledgement when you are done?" 1211 The receiver of the delete request then switches his outbound 1212 traffic to another SA, deletes both inbound and outbound SAs and 1213 sends the delete acknowledgement. 1215 This is interpreted to mean: 1217 "I am also not sending anymore traffic on this SA (or these SAs). 1218 You may delete it (or them)." 1220 The receiver of the delete acknowledgement may then delete the 1221 inbound SA. The outbound SA should have already been deleted or 1222 somehow not used before the sending of the delete request. 1224 Note that re-transmission rules apply to the request-acknowledge 1225 pair. That is, if the initiator of the delete mode does not get the 1226 delete acknowledgement, the delete request should be re-transmitted. 1227 Similarly, if the responder of the delete request receives multiple 1228 copies, multiple copies of the delete acknowledgement should be 1229 sent. 1231 If the retry counter for the delete request expires, the SAs 1232 indicated in the request should be unilaterally deleted. 1234 Note that there is a race condition for the delete request and 1235 delete acknowledgement packets if an implementation sends them 1236 immediately after sending a packet on one of the SAs to be deleted. 1237 The race occurs if the packet order gets changed in the network and 1238 the delete mode packets arrive before packets sent on the SAs to 1239 which the deletes refer. 1241 The delete request-acknowledgement pair should also be applied to 1242 phase 1 SAs. In this case, the phase 1 SA is not completely torn 1243 down until the reception of the delete acknowledgement message. 1245 As a specific clarification, the binding between the inbound and the 1246 outbound phase 2 SAs is not weakened. In the messages used, the SA 1247 specified in the delete request is that of the sender's inbound SA. 1248 In other words, the SPI sent in the notification is the SPI that was 1249 generated by the sender. When phase 1 SAs are being deleted, the SPI 1250 values used are the cookies of the phase 1 SA to be deleted. 1252 The use of the Acknowledged Informational does not eliminate the use 1253 for the existing DELETE notification. It could still be used if an 1254 implementation determines it needs to immediately (and impolitely) 1255 delete an SA. Implementations must still recognise that it is sent 1256 over UDP and may be dropped. 1258 4.3 Phase 1 Re-keying for Future Versions of IPsec 1260 The phase 1 re-keying method described in Section 3 requires only 1261 one change for future versions of IPsec. That change is the addition 1262 of the required use of the Acknowledged Informational exchange when 1263 deleting SAs when it cannot be guaranteed that the peer's phase 1 SA 1264 lifetime is identical to the local lifetime. 1266 4.4 Phase 2 Re-keying for Future Versions of IPsec 1268 The phase 2 re-keying proposal described in Section 2, while 1269 necessary under the circumstances, is not the ideal method of re- 1270 keying. It forces the specific transfer times of SAs, thus making 1271 the intent of paragraph 2, section 9 of [IKE] impossible. It is also 1272 complicated to implement. 1274 This section describes proposals related to re-keying for the next 1275 version of the IPsec protocols. The purpose is to precisely define 1276 re-keying so that implementations are lossless and perfectly 1277 interoperable during re-keying. It also allows the spirit of 1278 paragraph 2, section 9 of [IKE] to be used. Further, it meets the 1279 requirements of paragraph 3 of section 4.3 of [ISAKMP]. 1281 A summary of the recommendations is: 1283 1) Define and require that the normal procedure is to use the 1284 oldest phase 2 SA first, and to use it until its natural 1285 expiration. 1287 2) Use the recommended re-transmission request rules for quick 1288 mode. 1290 3) Make use of the Acknowledged Informational exchange a 1291 requirement for SA deletion. 1293 4.4.1 Oldest Phase 2 SA First 1295 The concept of using the oldest phase 2 SA first for outbound 1296 traffic allows the maximum use of negotiated keys and allows for the 1297 pre-negotiation of an arbitrary number of phase 2 SAs to be made 1298 available for later use. 1300 Additionally, it decouples new phase 2 SA negotiation from old phase 1301 2 SA deletion, and the need to transfer to the new SA during re- 1302 keying. 1304 It also eliminates the race condition that occurs during SA set up 1305 during re-keying. This means that use of the commit bit to avoid the 1306 race condition is not necessary except when the very first phase 2 1307 SA is set up. 1309 Another advantage of being able to pre-negotiate phase 2 SAs is for 1310 applications that use large amounts of data in a period of time that 1311 would be too short for re-keying of the SA used to take place 1312 reliably. 1314 The oldest SA is defined as the first negotiated of the available 1315 SAs. In cases of simultaneous and near simultaneous SA negotiation, 1316 the use of the acknowledged DELETE notification and the ability to 1317 overlap SAs for an arbitrary period of time should make this 1318 condition manageable. 1320 4.4.2 Phase 2 Re-keying Illustration 1322 This section illustrates the events when re-keying occurs using the 1323 above proposals. Note the simplifications due to the decoupling of 1324 SA negotiation, old SA deletion and the transfer of traffic from the 1325 old to the new SA. 1327 Initiator Responder 1329 Inbound Outbound Inbound Outbound 1330 | | | | 1331 1 ----------------- | | 1332 | | ------------ | | 1333 | | -------------------> 2 1334 | | | | | 1335 | | -------------------- 3 1336 | | ------------ | | 1337 4 <--------------- | | 1338 | | | | | 1339 5 ---------------- | | 1340 | *6 | ------------ | | 1341 | | | ------------------> 7 1342 | | | | | 1343 | | | | *8 | 1344 | | | | | | 1345 9 1346 | | | | | | 1347 | | *10 *10 | | | 1348 11 ----------------- | | | | 1349 | | ------------ | | | 1350 | | | -------------------> 12 1351 | | | | | | 1352 | | | | | *13 * 13 1353 | | | | | | 1354 | | | -------------------- 14 1355 | | ------------ *15| | 1356 16 <--------------- | | | 1357 | | | | | 1358 *17| | | | 1359 | | | | 1361 Figure 4-1 Recommended Phase 2 Re-key Sequence Chart, Initiator 1362 Expiration, Future 1364 1) Initiator sends first quick mode message. 1366 2) Responder receives first quick mode message. 1368 3) Responder sends second quick mode message. 1370 4) Initiator receives second quick mode message. 1372 5) Initiator sends third quick mode message. 1374 6) Initiator sets up new inbound SA. Implementations may choose to 1375 set up the new outbound SA at this time, as long as they do not 1376 use it. 1378 7) Responder receives third quick mode message. 1380 8) Responder set up new inbound SA. Implementations may choose to 1381 set up the new outbound SA at this time, as long as they do not 1382 use it. 1384 9) Initiator's old SA pair expires. 1386 10) Initiator starts using new outbound SA and stops using old 1387 outbound SA. 1389 11) Initiator sends first Acknowledged Informational exchange 1390 message with a delete payload. 1392 12) Responder receives first Acknowledged Informational exchange 1393 message. 1395 13) Responder sets up new outbound SA. 1397 13) Responder deletes old outbound SA and starts using new outbound 1398 SA. 1400 14) Responder sends second Acknowledged Informational exchange 1401 message. 1403 15) Responder deletes old inbound SA. 1405 16) Initiator receives second Acknowledged Informational exchange 1406 message. 1408 17) Initiator deletes old inbound SA. 1410 If the responder's old SA expires first, the events are as follows. 1412 Initiator Responder 1414 Inbound Outbound Inbound Outbound 1415 | | | | | | 1416 9 1417 | | | | | | 1418 | | | | | *10 *10 1419 | | | | | | 1420 | | | -------------------< 11 1421 | | | ------------ | | | 1422 12 <--------------- | | | 1423 | | | | | | 1424 | | *13 *13 | | | 1425 | | | | | | 1426 | | | | | | 1427 | | | | | | 1428 14 >--------------- | | | | 1429 15 * | ------------ | | | 1430 | | -------------------> 16 1431 | | | | | 1432 | | 17 * | | 1433 | | | | 1435 Figure 4-2 Recommended Phase 2 Re-key Sequence Chart, Responder 1436 Expiration, Future 1438 9) Responder's old SA pair expires. 1440 10) Responder starts using new outbound SA and stops using old 1441 outbound SA. 1443 11) Responder sends first Acknowledged Informational exchange 1444 message with a delete payload. 1446 12) Initiator receives first Acknowledged Informational exchange 1447 message. 1449 13) Initiator sets up new outbound SA. 1451 13) Initiator deletes old outbound SA and starts using new outbound 1452 SA. 1454 14) Initiator sends second Acknowledged Informational exchange 1455 message. 1457 15) Initiator deletes old inbound SA. 1459 16) Responder receives second Acknowledged Informational exchange 1460 message. 1462 17) Responder deletes old inbound SA. 1464 4.5 Commit Bit Replacement 1466 The intent of this section is to propose a mechanism to allow 1467 implementations to delay the usage of negotiated SAs. Its use may 1468 eliminate the need for the commit bit, and will not suffer from any 1469 of the problems of the commit bit. While the commit bit usage is 1470 much better defined by [IKEbis], it is unable to solve all the 1471 difficulties associated with it. 1473 Replacement of the commit bit is done by the introduction of a new 1474 mechanism to indicate to a peer that usage of a newly negotiated SA 1475 should be deferred. Then, depending on the deferral time intended, 1476 one of two mechanisms is introduced to indicate that the SA may be 1477 used. 1479 These mechanisms are preferred over the commit bit for the following 1480 reasons: 1482 o They receive the full protection of phase 1 SAs, and as such 1483 provide the maximum resistance to denial of service attacks. 1485 o Their use is clearly and unambiguously defined. 1487 o They are resistant to the possibilities of dropped packets. 1489 4.5.1 DEFER_USAGE Notify Payload 1491 The indication that an SA should not be made available for use 1492 immediately by a peer can be indicated by the addition of a new 1493 notify payload to the quick mode that negotiated the SA. To allow a 1494 single quick mode to negotiate multiple SAs, the DEFER_USAGE notify 1495 payload explicitly names the SA whose use is to be deferred, in the 1496 same manner as the current DELETE payload. 1498 The DEFER_USAGE notify payload should be added by the peer wishing 1499 to delay usage of an SA. 1501 On reception of the DEFER_USAGE notify payload, the newly negotiated 1502 SA should be set aside until reception of the ALLOW_USAGE notify 1503 payload, described in the next section, or the reception of the 1504 CONNECTED notification. 1506 The expected response depends on which type of DEFER_USAGE 1507 notification is sent. These types are termed long and short. A short 1508 DEFER_USAGE notification causes a quick mode to become four messages 1509 in length, as with the intended use of the commit bit. A long 1510 DEFER_USAGE notification causes quick mode to proceed normally, with 1511 usage of the specified SA deferred until the sender of the 1512 DEFER_USAGE notification sends the ALLOW_USAGE notify. 1514 Implementations should be prepared to receive the long DEFER_USAGE 1515 notification for the same SA (pair) that they send it for; in other 1516 words, usage of both SAs (inbound and outbound) of the negotiated 1517 pairs may be deferred simultaneously by both peers. 1519 There are no time constraints associated with the sending of the 1520 long DEFER_USAGE notification and the subsequent reception of the 1521 ALLOW_USAGE notification. 1523 Usage of the short DEFER_USAGE notification is restricted to quick 1524 mode responders only. It causes the transmission of a CONNECTED 1525 notification as a fourth quick mode message in the same way that the 1526 commit bit does. 1528 4.5.2 ALLOW_USAGE Notify Payload 1530 The purpose of this notify is to indicate to a peer that an SA may 1531 now be used. Normally, usage of the SA by the peer would have been 1532 deferred by the use of the long DEFER_USAGE notify payload, 1533 described in the previous section. However, reception of this notify 1534 for an SA whose usage has not been deferred is not considered an 1535 error. 1537 This payload MUST be used only with the Acknowledged Informational 1538 exchange. 1540 The initiator of the exchange must start usage of the inbound SA of 1541 the pair when sending the first packet of the exchange. Usage of the 1542 initiator's outbound SA must wait until reception of the 1543 acknowledgement packet of the exchange. 1545 The responder of the exchange must start usage of its inbound SA of 1546 the pair before sending the acknowledgement, and may start usage of 1547 its outbound SA of the pair any time after receiving the first 1548 packet of the exchange. 1550 The initiator of the exchange re-transmits the ALLOW_USAGE 1551 notification until it receives the acknowledgement packet or exceeds 1552 its re-try counter. 1554 If both peers deferred use of the SA, two transactions of the 1555 ALLOW_USAGE notification are required (one in each direction) before 1556 the SAs involved may be used. 1558 5. Acknowledgements 1560 Some of the concepts presented in this document are based on work 1561 done by what was TimeStep Corporation's engineering group. 1563 Others are taken from concepts discussed within the IPsec working 1564 group, particularly some of the concerns expressed about problems 1565 with the commit bit, and also expressed concerns about the 1566 continuous channel model for phase 1 SA re-keying. 1568 Thanks also go to those implementers who have stated the value of 1569 this document, and made suggestions for it. 1571 6. References 1573 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1574 RFC2409, November 1998 1576 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1577 "Internet Security Association and Key Management Protocol 1578 (ISAKMP)", RFC2408, November 1998 1580 [IKEbis]Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1581 draft-ietf-ipsec-ike-01.txt, May 1999, work in progress 1583 Revision History 1585 September 23, 1998 -initial release 1587 April 7, 1999 -clarification of objectives of document 1588 -more commit bit comments 1589 -change phase 1 re-keying discussion to explicitly 1590 allow multiple phase 1 SAs between peers; previous 1591 version explicitly allowed only 1 phase 1 between 1592 peers 1593 -other miscellaneous changes 1595 October 20, 1999 -separation of phase 1 re-keying into continuous 1596 channel and dangling SA implementations 1597 -use of Acknowledged Information exchange used 1598 where possible 1599 -other changes 1601 January 5, 2000 -withdrawal of continuous channel as primary 1602 recommended method of phase 1 SA re-keying 1603 �more clarifications of purpose and application 1604 �more typos fixed 1606 February 14, 2000-added more text to proposed phase 2 method 1607 comparison section 1608 �fixed one reference typo 1609 �changed author's email address 1611 Security Considerations 1613 This document is associated with the IPsec family of documents. As 1614 such, security considerations permeate the document. 1616 Author's Address 1618 Tim Jenkins 1619 timj@newbridge.com 1620 TimeStep Solutions Group 1621 Newbridge Networks Corporation 1622 362 Terry Fox Drive 1623 Kanata, ON 1624 Canada 1625 K2K 2P5 1626 +1 (613) 599-3600 1628 The IPsec working group can be contacted via the IPsec working 1629 group's mailing list (ipsec@lists.tislabs.com) or through its chair: 1631 Theodore Y. Ts'o 1632 tytso@MIT.EDU 1633 Massachusetts Institute of Technology 1635 This document expires August 15, 2000