idnits 2.17.1 draft-jenkins-ipsec-rekeying-02.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? == 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 38 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 178: '... implementation SHOULD begin using th...' RFC 2119 keyword, line 179: '...ound traffic and SHOULD continue to su...' RFC 2119 keyword, line 836: '... -initiator MUST use INITIAL-CONT...' RFC 2119 keyword, line 837: '... -responder SHOULD use INITIAL-CO...' RFC 2119 keyword, line 849: '... -initiator MUST NOT use INITIAL-...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1532 has weird spacing: '...tely by peer ...' -- 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 (October 20, 1999) is 8954 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1326, but not defined == Missing Reference: 'IKEbis' is mentioned on line 1511, but not defined ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 TimeStep Corporation 3 Internet Draft October 20, 1999 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. 18 Distribution of this memo is unlimited. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or made obsolete by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) Tim Jenkins (1999). 41 Table of Contents 43 1. Introduction...................................................3 44 2. Phase 2 SA Re-keying...........................................3 45 2.1 Phase 2 Re-keying Issues......................................3 46 2.1.1 Inconsistent SA Use Recommendation..........................4 47 2.1.2 Observed Behaviours.........................................5 48 2.1.3 SA Set-up Race Condition....................................5 49 2.1.4 Commit Bit Interaction......................................7 50 2.2 Solution Examination..........................................8 51 2.2.1 Responder Pre-Setup.........................................8 52 2.2.1.1 Normal Conditions.........................................9 53 2.2.1.2 Dropped Packet Conditions................................11 54 2.2.1.3 Failed Negotiation.......................................12 55 2.2.1.4 Responder Pre-Setup Security Hole........................13 56 2.2.2 Recommended Re-keying Method...............................13 57 2.2.2.1 Dropped Quick Mode 3 Message.............................15 58 2.2.2.2 Absence of Traffic.......................................15 59 2.2.2.3 Compatibility With Observed Behaviours...................16 60 2.2.2.4 Compatibility with Commit Bit............................16 61 2.2.2.5 Implementation Notes.....................................17 62 2.3 Conclusions..................................................17 63 3. Phase 1 SA Re-keying..........................................17 64 3.1 Phase 1 SA Re-keying Requirements............................18 65 3.2 Continuous Channel Implementations...........................19 66 3.2.1 Identity Perfect Forward Secrecy...........................22 67 3.3 Dangling Phase 2 SA Implementations..........................22 68 3.4 Other Phase 1 SA Re-keying Issues............................25 69 3.4.1 Multiple SA Usage..........................................25 70 3.4.2 INITIAL-CONTACT Notification...............................25 71 3.4.3 DELETE Notification........................................26 72 3.4.4 Re-keying Timing...........................................26 73 4. Next IPSec Version Recommendations............................26 74 4.1 Re-transmission Rules........................................27 75 4.1.1 Main Mode Re-Transmission Rules............................28 76 4.1.2 Aggressive Mode Re-Transmission Rules......................28 77 4.1.3 Quick Mode Re-Transmission Rules...........................28 78 4.2 Acknowledged SA Deletion.....................................28 79 4.3 Phase 1 Re-keying for IPSecond...............................30 80 4.4 Phase 2 Re-keying for IPSecond...............................30 81 4.4.1 Oldest Phase 2 SA First....................................31 82 4.4.2 Phase 2 Re-keying Illustration.............................31 83 4.5 Commit Bit Replacement.......................................35 84 4.5.1 DEFER_USAGE Notify Payload.................................35 85 4.5.2 ALLOW_USAGE Notify Payload.................................36 86 5. Acknowledgements..............................................37 87 6. References....................................................37 89 1. Introduction 91 This document has three primary objectives. 93 The first objective is to illustrate problems and issues associated 94 with re-keying within the confines of the current set of IPSec 95 documents. For a number of reasons, re-keying in IPSec has become 96 problematic, such that packets can get dropped by IPSec 97 implementations during re-keying. Worse, there exists the 98 possibility that IPSec implementations from different vendors may 99 not be interoperable because of the way they re-key. 101 The second objective of this paper is to propose methods of 102 performing both phase 1 and phase 2 re-keying for IPSec 103 implementations in such a way as to minimise packet loss and to 104 maximize compatibility. 106 The initial focus of the first two objectives is on phase 2 re- 107 keying; it is then extended to phase 1 re-keying. The need for this 108 document in each case is initially discussed, followed by a 109 recommendation for re-keying within the protocol framework 110 established by the initial version of the IPSec documents. 112 Finally, the third objective of the document is to provide 113 recommendations for the next version of the IPSec protocols. These 114 recommendations are made to best solve the re-keying problems in a 115 manner that is not possible within the constraints of the existing 116 IPSec documents. 118 2. Phase 2 SA Re-keying 120 This section discusses phase 2 re-keying issues and makes 121 recommendations to minimise the impact of these issues within the 122 current IPSec document set. 124 2.1 Phase 2 Re-keying Issues 126 The issues associated with phase 2 re-keying are listed below. Some 127 of the points are expanded upon later. 129 1) There is no specification defining how re-keying is to be done. 131 2) The existing drafts appear contradictory in their 132 recommendations on the usage of multiple phase 2 SAs. 134 3) Some recent implementations have shipped with a method of re- 135 keying that will not perform reliably under real world network 136 conditions. 138 4) The use of the DELETE notification is not required. 140 5) A variety of re-keying behaviours have been observed, some of 141 which are incompatible. 143 6) The commit bit is not yet widely implemented, and its use as 144 described is confusing. Further, while the documentation 145 requires its support, its use is not required. 147 7) A race condition exists at SA set up, exacerbating re-keying 148 issues. 150 2.1.1 Inconsistent SA Use Recommendation 152 The issue of inconsistent SA usage recommendations is examined 153 further here. 155 From paragraph 2 of Section 9 of [IKE]: 157 An implementation may wish to negotiate a range of SAs when 158 performing Quick Mode. By doing this they can speed up the "re- 159 keying". Quick Mode defines how KEYMAT is defined for a range of 160 SAs. When one peer feels it is time to change SAs they simply use 161 the next one within the stated range. A range of SAs can be 162 established by negotiating multiple SAs (identical attributes, 163 different SPIs) with one Quick Mode. 165 While the document does not define what "... the next one ..." 166 means, this paragraph strongly implies that there is no required 167 order for the use of phase 2 SAs that have been negotiated within a 168 phase 1 SA, and that multiple SAs may be pre-negotiated and used at 169 will. 171 However, this appears to be contradicted by paragraph 3 of section 172 4.3 of [ISAKMP]: 174 Modification of a Protocol SA (phase 2 negotiation) follows the 175 same procedure as creation of a Protocol SA. The creation of a new 176 SA is protected by the existing ISAKMP SA. There is no 177 relationship between the two Protocol SAs. A protocol 178 implementation SHOULD begin using the newly created SA for 179 outbound traffic and SHOULD continue to support incoming traffic 180 on the old SA until it is deleted or until traffic is received 181 under the protection of the newly created SA. As stated previously 182 in this section, deletion of an old SA is then dependent on local 183 security policy. 185 Many implementations have interpreted this to mean that the new SA 186 should be used for outbound in preference to the old SA. In other 187 words, the old SA should be abandoned as soon as possible. 189 This interpretation of [ISAKMP] is in direct conflict with the usage 190 implied by [IKE], resulting in potential problems. 192 2.1.2 Observed Behaviours 194 The following behaviours have been observed by various vendors' 195 implementations when devices have set up a second phase 2 SA. The 196 behaviours listed below are not mutually exclusive. 198 1) The device continues to use the old SA until it naturally 199 expires, then switches to the new SA. 201 2) The device immediately begins using the new SA. 203 3) The device immediately drops the old SA. 205 4) The device never sends a DELETE notification. 207 5) The device always sends a DELETE notification. 209 6) The device deletes the old SA some time after re-keying, but 210 before the end of its natural lifetime. 212 7) A device wants to keep more than one SA up all the time. 214 All of these behaviours are permitted under the current documents. 215 However, even when quick mode packets are not lost, it can be seen 216 that interoperability is not always possible with some combinations 217 of behaviours listed above. 219 2.1.3 SA Set-up Race Condition 221 Further, behaviour 2 above is not a good behaviour, as illustrated 222 below. In this example, the initiator is a gateway capable of 223 handling full T3 bandwidth rates, while the responder is a PC 224 running a software IPSec implementation, and it is overloaded. 226 In the illustration, QM1 refers to the first quick mode message, QM2 227 to the second quick mode message and QM3 to the third quick mode 228 message. 230 By the time the responder has set up the new SA, packets protected 231 by that SA have already started arriving from the initiator. This 232 causes them to be dropped by the responder. This case is further 233 complicated by the possibility of packets taking different paths 234 through the network, so theoretically, the third quick mode message 235 could arrive after packets protected by the new SA. 237 Additionally, since all IKE packets are based on UDP, there is no 238 guarantee that QM3 even arrives at the peer, so making assumptions 239 about new SA use based on the transmission time of a packet will 240 still lead to failures in the field. 242 To reduce the effects of packet loss, some implementations were 243 observed to blindly transmit QM3 multiple times, back to back. 245 Initiator Responder 247 QM1 sent ---- 248 ------- 249 ------------- 250 ---------------> QM1 received 251 | 252 | 253 | QM1 processed 254 | 255 | 256 ---------------- QM2 sent 257 ------------- 258 ------- 259 QM2 rec. <---- 260 process | 261 QM3 sent ----- 262 * ------- 263 packet on new SA ------------- 264 _____ ---------------> QM3 received 265 _______ | 266 _____________ | QM3 processing 267 _______________| 268 | packet dropped 269 | 270 * new SA set up 272 Figure 2-1 Race Condition Sequence Chart 274 This can reduce the probability that the peer does not get QM3, but 275 cannot eliminate it. Nor can it eliminate race conditions due to 276 path differences or processing times. 278 If the behaviour of the initiator was to delay usage of the new SA 279 for outbound traffic, this would cause failures for those 280 implementations that immediately delete the old SA. Therefore, the 281 behaviour of delaying use of the new SA and immediately deleting the 282 old SA are incompatible. 284 2.1.4 Commit Bit Interaction 286 The use of the commit bit can solve the race condition illustrated 287 in the previous section when asserted by the responder during quick 288 mode. However, it suffers from the following problems: 290 1) Use of the commit bit is not well defined. The present 291 documentation ([ISAKMP]) specifies its use for phase 1 and 292 phase 2, but mentions phase 2 specific details. There are also 293 issues related to how the subsequent CONNECTED notification 294 fits in with the quick mode exchange. 296 2) While its support is required, its use is not. 298 3) Its use may make implementations susceptible to a denial of 299 service attack by forcing initiators to wait for a CONNECTED 300 notification that may never come. While this is only one of a 301 number of possible denial of service attacks on IKE, this is 302 not an excuse to leave the existing implementation as it is. 304 4) There is no defined way to recover from the loss of the 305 CONNECTED notification. 307 5) Some implementations are using the commit bit for the wrong 308 reasons. 310 Point 1 is being addressed by the working group; future versions of 311 the IPSec documents should clarify these issues. [IKEbis] has done 312 an excellent job of clarifying this issue. 314 Point 3 happens because the commit bit is in the ISAKMP header, and 315 the ISAKMP header is not authenticated, so is susceptible to 316 modification. 318 Point 5 above needs some elaboration. In a previous section, it was 319 mentioned that the loss of the third quick mode message can cause 320 problems, since the responder will not set up the SA at all. Because 321 of this, some implementations have chosen to set the commit bit as a 322 mechanism to force the re-transmission of the third quick mode 323 message. 325 This is wrong for two reasons. First, it is not the stated purpose 326 of the commit bit. The purpose of the commit bit is to delay the 327 usage of an SA, for whatever reason. This implies that it is not a 328 good mechanism to cause re-transmission of the third quick mode 329 message. 331 Secondly, it does not solve the packet loss problem; it only defers 332 it. The logic of the improper usage is that the initiator will 333 resend the third quick mode message until it receives the CONNECTED 334 notification (which is now effectively the fourth quick mode 335 message). 337 The problem with this is that it leaves no mechanism for demanding 338 the re-transmission of the CONNECTED notification itself. It can be 339 dropped just as the third quick mode message can. This means that 340 the problem that was intended to be solved by the use of the commit 341 bit is simply pushed out to being the problem of solving the dropped 342 CONNECTED notification. 344 Sections 2.2.2.1 and 4.1 describe a mechanism for solving the 345 dropped third quick mode message problem. 347 2.2 Solution Examination 349 This section details the operation of some possible behaviours, with 350 the intent of arriving at a best possible phase 2 re-keying 351 mechanism under the constraints of the existing documents. 353 In all the examples, the term "sets up a new outbound SA" means that 354 the new outbound SA will be chosen in favour of the old one. Whether 355 the SA is actually created before that time or not is implementation 356 dependent. 358 2.2.1 Responder Pre-Setup 360 As a starting point, the responder pre-setup method of re-keying is 361 examined. Note that it will work with most of the behaviours 362 observed in the field. 364 In this method, SAs are treated separately as inbound and outbound, 365 as well as old and new. Further, it takes advantage of the fact that 366 the responder knows what the SA is going to be after the second 367 quick mode message is sent. By using this information, it allows the 368 responder to set up the new inbound SA before having received the 369 third quick mode message. 371 Implicit acknowledgement of the reception of the third quick mode 372 message by the responder is provided by use of the new SA in the 373 initiator's inbound direction. The initiator should not use its new 374 outbound SA before that time. 376 Additionally, it does not require use of the CONNECTED notification 377 for prevention of the race condition, or the use of the DELETE 378 notification for removal of the old SA. This is important since, 379 even if they are always sent, they are unacknowledged UDP packets 380 and may be lost. 382 2.2.1.1 Normal Conditions 384 Figure 2-2 shows the operation under normal (successful) conditions. 386 While appearing complicated, it enables the lossless transfer from 387 one SA to another while supporting almost all other behaviours. 389 Support for and use of the DELETE notification is unchanged. 391 Initiator Responder 393 Inbound Outbound Inbound Outbound 394 | | | | 395 1 ----------------- | | 396 | | ------------ | | 397 | | -------------------> 2 398 | | | | | 399 | | -------------------- 3 400 | | ------------ | *4 | 401 5 <--------------- | | | 402 | | | | | | 403 6 ---------------- | | | 404 | *7 | ------------ | | | 405 | | | -------------------> 8 406 | | | | | | | 407 | | | | | | * 408 | | | | | | *9 409 | | | | | *10 | 410 | | | | | | 411 | *11 | | | | 412 | | | *12 | | | 413 | | *13 | | | | 414 *14| | | | | 415 | | | *15 | 416 | | *16| | 417 | | | | 419 Figure 2-2 Phase 2 SA Pre-Setup Sequence Chart 421 Events 423 1) Initiator sends first quick mode message. 425 2) Responder receives first quick mode message. 427 3) Responder sends second quick mode message. 429 4) Responder sets up new inbound SA. This is to handle the case 430 where the initiator starts transmitting on the new SA 431 immediately after sending the third quick mode message. 433 5) Initiator receives second quick mode message. 435 6) Initiator sends third quick mode message. 437 7) Initiator sets up new inbound SA. 439 8) Responder receives third quick mode message. 441 9) Responder sets up new outbound SA. 443 10) Responder deletes old outbound SA. 445 11) Traffic from responder to initiator arrives at initiator on new 446 SA. 448 12) Initiator sets up new outbound SA. 450 13) Initiator deletes old outbound SA. 452 14) Initiator deletes old inbound SA. 454 15) Traffic from initiator to responder arrives at responder on new 455 SA. 457 16) Responder deletes old inbound SA. 459 2.2.1.2 Dropped Packet Conditions 461 In this case, the event list is modified to show what happens when 462 each packet is dropped once. The event numbers refer to those 463 illustrated in Figure 2-2. 465 1) Initiator sends first quick mode message. 467 e) Packet is dropped during transmission. 469 1b) Initiator times out waiting for second quick mode message. 471 1) Initiator re-sends first quick mode message. 473 2) Responder receives first quick mode message. 475 3) Responder sends second quick mode message. 477 4) Responder sets up new inbound SA. This is to handle the case 478 where the initiator starts transmitting on the new SA 479 immediately after sending the third quick mode message. 481 e) Packet is dropped during transmission. 483 1b) or 7b) Responder times out waiting for third quick mode 484 message. 486 1) or 3) Responder re-sends second quick mode message. 488 5) Initiator receives second quick mode message. 490 6) Initiator sends third quick mode message. 492 7) Initiator sets up new inbound SA. 494 e) Packet is dropped during transmission. 496 7b) Responder times out waiting for third quick mode message. 498 3) Responder re-sends second quick mode message. 500 5) Initiator receives second quick mode message again. 502 6) Initiator re-sends third quick mode message. 504 8) Responder receives third quick mode message. 506 and so on, as for normal operation. 508 2.2.1.3 Failed Negotiation 510 In this case, the second quick mode packet has an invalid hash, and 511 the initiator sends the notification to the peer. Again, the event 512 numbers refer to those illustrated in Figure 2-2. 514 1) Initiator sends first quick mode message. 516 2) Responder receives first quick mode message. 518 3) Responder sends second quick mode message. 520 4) Responder sets up new inbound SA. This is to handle the case 521 where the initiator starts transmitting on the new SA 522 immediately after sending the third quick mode message. 524 5) Initiator receives second quick mode message. 526 e) Hash (or other parameter) fails. 528 e1) Initiator sends notification to responder. 530 e2) Responder receives notification. 532 e3) Responder deletes new inbound SA. 534 A similar operation would occur if retry counters expire for packet 535 re-transmissions. 537 2.2.1.4 Responder Pre-Setup Security Hole 539 In the failed negotiation case, the need to delete the invalid 540 inbound SA raises the issue of a temporary hole, in that the 541 responder allows inbound packets while waiting for the third quick 542 mode message. However, if the inbound SA is not set up ahead of 543 time, initiators that immediately transmit on the new outbound SA 544 will cause packets to be dropped. 546 It also illustrates why the proposal above made the usage of the 547 outbound SA by the initiator wait until there is an indication of 548 the use of the SA by the responder. 550 Note that this security hole is exactly what would result from an 551 attacker replaying the first quick mode message of an exchange. 553 2.2.2 Recommended Re-keying Method 555 In this method, the previous method is modified to remove the risk 556 of the security hole. It also simplifies the operation somewhat, but 557 at the expense of lost packets if the initiator's behaviour is such 558 that it immediately uses the new SA for its outbound traffic. 560 Note that deletion of the old inbound SA by the initiator could be 561 further delayed if protection against loss of packets using the old 562 SA on different and slower network paths is desired. 564 Initiator Responder 566 Inbound Outbound Inbound Outbound 567 | | | | 568 1 ----------------- | | 569 | | ------------ | | 570 | | -------------------> 2 571 | | | | | 572 | | -------------------- 3 573 | | ------------ | | 574 4 <--------------- | | 575 | | | | | 576 5 ---------- | | | 577 | *6 ------------------ | | 578 | | | -------------------> 7 579 | | | | | | 580 | | | | | * 581 | | | | *8 | 582 | | | | | | *9 583 | | | | | *10 | 584 | | | | | | 585 | *11 | | | | 586 | | | *12 | | | 587 | | *13 | | | | 588 *14| | | | | 589 | | | *15 | 590 | | *16| | 591 | | | | 593 Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 595 1) Initiator sends first quick mode message. 597 2) Responder receives first quick mode message. 599 3) Responder sends second quick mode message. 601 4) Initiator receives second quick mode message. 603 5) Initiator sends third quick mode message. 605 6) Initiator sets up new inbound SA. 607 7) Responder receives third quick mode message. 609 8) Responder sets up new inbound SA. 611 9) Responder sets up new outbound SA. 613 10) Responder deletes old outbound SA. 615 11) Traffic from responder to initiator arrives at initiator on new 616 SA. 618 12) Initiator sets up new outbound SA. 620 13) Initiator deletes old outbound SA. 622 14) Initiator deletes old inbound SA. 624 15) Traffic from initiator to responder arrives at responder on new 625 SA. 627 16) Responder deletes old inbound SA. 629 2.2.2.1 Dropped Quick Mode 3 Message 631 In cases where the third quick mode message is dropped, the 632 responder must request re-transmission of it by re-sending the 633 second quick mode message. The existence of traffic on the new 634 inbound SA at the initiator should not be used as an implicit 635 acknowledgement for the following reasons: 637 1) There may be no traffic for the responder to send. 639 2) The responder may be designed to use the old SA until its 640 natural expiration. 642 This implies that implementations must be able to respond to the re- 643 transmission of the second quick mode message even after having sent 644 the third quick mode message. 646 2.2.2.2 Absence of Traffic 648 The proposed implementation uses the presence of traffic from the 649 responder on new SAs to provide an implied acknowledgement for the 650 purposes of switching to the new SA. However, if there is no traffic 651 from the responder, the implied acknowledgement will not appear. 653 A similar behaviour is exhibited by implementations that continue to 654 use old SAs until their natural expiration. 656 However, due to the number of implementations that delete old SAs 30 657 seconds after negotiating a new one, the same behaviour has the best 658 chance of interoperability, and of not dropping packets when traffic 659 does restart. 661 Therefore, it is recommended that implementations delete old SAs and 662 start using new SAs 30 seconds after negotiating new SAs in the 663 absence of traffic. Use of the DELETE notification is strongly 664 recommended in cases where the peer implementation is continuing to 665 use the old SA. 667 2.2.2.3 Compatibility With Observed Behaviours 669 When operating with behaviours that use the new SA immediately, this 670 method performs equivalently when this method is used by the 671 responder. When used by the initiator, the performance will depend 672 on when the responder deletes the old inbound SA. 674 When operating with behaviours that continue to use the old SA, this 675 method performs as described in the dropped quick mode three example 676 above when used by the initiator. When used by the responder, there 677 is no change in operation, since the responder will wait until the 678 new SA is used before deleting the old SA. 680 However, as stated in a previous section, it is recommended that the 681 initiator keep the old SA (both inbound and outbound) for only 30 682 seconds after creation of the new SA in cases where traffic is not 683 detected on the new SA. 685 2.2.2.4 Compatibility with Commit Bit 687 If the commit bit is set by the responder with this proposal, some 688 of the problems described in Section 0 may occur. To reduce the 689 effects of these problems, following rules should be followed: 691 1) The initiator should set up its inbound SA immediately after 692 sending the third quick mode message regardless of the state of 693 the commit bit. 695 2) Sensing of traffic on the initiator's new inbound SA should 696 trigger the use of the new outbound SA to detect cases when the 697 CONNECTED notification is dropped. 699 The recommended proposal does not allow built-in support of the 700 commit bit. It does allow responders that use the commit bit to 701 detect reception of the CONNECTED notification by the initiator due 702 to the presence of traffic on its new inbound SA. However, this 703 works only if there is traffic, so it cannot be considered a useful 704 method to perform this function. 706 The recommended proposal does cause the initiator to delay usage of 707 a new SA until it is set up. This is the primary use of the commit 708 bit, so use of this proposal makes the use of the commit bit 709 unnecessary except for the setting up of the first phase 2 SA. 711 2.2.2.5 Implementation Notes 713 The presence of traffic on the new SA can be part of the expiration 714 checking operation, and does not need to occur instantaneously, 715 although it must occur before the 30 second no traffic SA deletion 716 criteria. As long as the new SA is negotiated with enough time 717 before the expiration of the old one, the detection of traffic on 718 the new SA can be on the order of seconds with no ill effects. 720 Since SAs will likely have traffic counters anyway, this method 721 requires only the addition of a flag that indicates it is a new SA. 722 When the expiration process checks for ageing and expired SAs, it 723 can also check for new SAs with a non-zero traffic count. When 724 detected, the SA is marked as non-new, and the remaining operations 725 can be performed. 727 2.3 Conclusions 729 The final re-keying method is the best compromise for 730 interoperability within the framework of the current IPSec documents 731 without compromising security. 733 3. Phase 1 SA Re-keying 735 This section makes a proposal for phase 1 SA re-keying. This 736 proposal is necessary for many of the same reasons a phase 2 SA re- 737 keying proposal is necessary. 739 1) The rules for phase 1 SA re-keying are not specified in the 740 drafts. 742 2) Adhoc implementations have lead to poor implementations and 743 possible interoperability issues. 745 The goal of the proposed phase 1 SA re-keying method is to provide 746 secure, lossless communications. This means that there should be no 747 dropped traffic during re-keying, but also that there should be no 748 further traffic if re-keying fails. 750 3.1 Phase 1 SA Re-keying Requirements 752 The two reasons for re-keying a phase 1 SA are for freshness (time 753 or traffic) of the phase 1 SA keying material (affecting its ability 754 to protect phase 2 SA negotiations) and for re-authentication (and 755 therefore authorisation) of the encrypting devices. 757 The second reason stated above has been deemed unimportant by the 758 working group as a factor in determining phase 1 SA re-keying for 759 two reasons: 761 1) System administrators understand IPsec well enough to configure 762 the combination of phase 1 and phase 2 SA lifetimes such that 763 terminating phase 2 SAs when authentication ends means the 764 unauthorised usage period is insignificant. 766 2) Many implementation will be required to produce a mechanism to 767 tear down SAs created by entities that are no longer authorised. 769 Originally, this document made the assumption that there must always 770 be a valid phase 1 SA in existence between entities to allow the 771 phase 2 SAs to continue to exist. This was driven primarily by the 772 desire to bound the authorised lifetime of phase 2 SAs by the 773 authorised lifetime of the phase 1 SA. However, as stated above, 774 this requirement has been considered unnecessary by the working 775 group. 777 Without that requirement, it was decided by the working group that a 778 valid phase 1 SA does not have to exist between two peers that have 779 valid phase 2 SAs. 781 In spite of this, this document asserts that there is still value in 782 making sure that a valid phase 1 SA exists at all times. This value 783 comes about from the fact that the existence of phase 1 SAs between 784 two entities creates a logical control channel for phase 2 SA 785 management between those entities. This method of phase 1 re-keying 786 will be called the continuous channel method. 788 The continuous channel method is implicitly recommended by RFC2408. 789 The following quote is from paragraph six of [ISAKMP]: 791 Third, having an ISAKMP SA in place considerably reduces the cost 792 of ISAKMP management activity - without the "trusted path" that 793 an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would 794 have to go through a complete re-authentication for each error 795 notification or deletion of an SA. 797 Unfortunately, the downside of this implementation is that it must 798 be aware of dangling phase 2 SA implementations due to the decision 799 of the working group. This document uses the term "dangling" to 800 describe phase 2 SAs that have no valid phase 1 SA between the two 801 peers. The differences between the two methods are further discussed 802 here. 804 3.2 Continuous Channel Implementations 806 Continuous channel implementations are those implementations that 807 attempt to always maintain at least one valid phase 1 SA between any 808 peers that have phase 2 SAs. 810 The primary advantage of the continuous existence of the logical 811 channel is that it allows cleaner management of phase 2 SAs, 812 particular if the two entities become unsynchronised for any reason. 814 Therefore, re-keying of phase 1 SAs requires that peers negotiate a 815 new phase 1 SA before the old phase 1 SA expires, at some percentage 816 of the SA's lifetime. 818 Note that this automatic re-keying of phase 1 SAs means that SAs 819 could live independent of traffic, since re-keying of both phase 1 820 and phase 2 SAs takes place with no traffic triggers (if they expire 821 by time). In other words, SAs that are no longer necessary may never 822 disappear. 824 This suggests that a traffic monitoring capability should be part of 825 implementations that need to delete idle or unused SAs. As such, it 826 is not given further consideration, since it is beyond the scope of 827 this document. 829 The existence of the INITIAL-CONTACT notification determines whether 830 it should delete any phase 2 SAs it has with the peer. 832 Summarised, the rules for phase 1 re-keying for continuous channel 833 implementations are: 835 Initial Phase 1 SA Negotiation: 836 -initiator MUST use INITIAL-CONTACT notification 837 -responder SHOULD use INITIAL-CONTACT notification (when 838 possible) 839 -responder deletes any pre-existing phase 1 SA with the peer when 840 authentication of peer complete 841 -responder deletes all previously existing phase 2 SAs with the 842 peer, if any 844 Phase 1 SA Ages: 845 -end point that first detects this negotiates new phase 1 SA; 846 becomes new initiator 848 New Phase 1 SA Negotiation: 849 -initiator MUST NOT use INITIAL-CONTACT notification 850 -responder MUST detect that this is a re-key and MUST NOT use 851 INITIAL-CONTACT notification 852 -responder SHOULD mark its existing phase 1 SA as re-keyed, so as 853 to not re-key again 854 -since no INITIAL-CONTACT notification is used by either end; 855 phase 2 SAs are kept 857 Phase 1 SA Expiration: 858 -DELETE notification SHOULD be sent for phase 1 SA only 860 Note that any information that may be associated with pre-existing 861 phase 1 SAs should be carried over into the new SA. Examples of this 862 type of information are addresses passed using the Configuration 863 Exchange mode. 865 Also, continuous channel implementations MUST delete all phase 2 SAs 866 with a peer when the last phase 1 SA between them expires. This 867 could happen due to administrative shut-down of the link between the 868 peers, or a policy change that caused the phase 1 SA re-keying to 869 fail, leaving no valid phase 1 SAs between them when the existing 870 phase 1 expired. 872 A difficulty arises here due to the optional and unacknowledged 873 transmission of the delete notification and the need to be dangling 874 SA aware. If the delete notification for any existing phase 2 SA is 875 dropped, the implementation must attempt to determine if the peer 876 uses the continuous channel method, or is an SA dangler. 878 A possible state machine for continuous channel implementations is 879 shown in Table 1. Note that this state machine does not cover error 880 conditions, simultaneous SA negotiations and other events, and is 881 provided for illustration only. It should not be considered a 882 complete design. 884 # SAs 885 P1 P2 Event Actions 886 ======================================================================= 887 0 0 -phase 1 negotiation -initiate phase 1 negotiation 888 from peer -use initial contact if allowed 889 -phase 1 SA needed 890 ======================================================================= 891 1 0 -phase 1 SA negotiation -respond to phase 1 negotiation 892 from peer -do not use initial contact 893 ----------------------------------------------------------------------- 894 -phase 1 SA deletion -delete phase 1 SA 895 from peer 896 ----------------------------------------------------------------------- 897 -phase 1 SA ages -re-key phase 1 SA (or not) 898 ----------------------------------------------------------------------- 899 -phase 1 SA expires -send delete notification for phase 1 SA 900 -delete phase 1 SA 901 ======================================================================= 902 1 1+ -phase 1 SA negotiation -respond to phase 1 negotiation 903 from peer -do not use initial contact 904 ----------------------------------------------------------------------- 905 -phase 1 SA ages -re-key phase 1 SA 906 ----------------------------------------------------------------------- 907 -phase 1 SA deletion -re-key phase 1 SA (1) 908 from peer -delete phase 1 SA 909 ----------------------------------------------------------------------- 910 -phase 1 SA expires -send deletes for all phase 2 SAs 911 -delete all phase 2 SAs 912 -send delete notification for phase 1 SA 913 -delete phase 1 SA 914 ======================================================================= 915 2+ 1+ -phase 1 SA negotiation -respond to phase 1 negotiation 916 from peer -do not use initial contact 917 ----------------------------------------------------------------------- 918 -phase 1 SA ages -re-key the phase 1 SA 919 ----------------------------------------------------------------------- 920 -phase 1 SA deletion -delete phase 1 SA 921 from peer 922 ----------------------------------------------------------------------- 923 -phase 1 SA expires -send delete notification for phase 1 SA 924 -delete phase 1 SA 925 ======================================================================= 926 0 1+ -phase 1 negotiation -delete all phase 2 SAs (3) 927 fails (2) -send no delete notifications 928 ======================================================================= 930 Table 1 Continuous Channel State/Event Table 932 Table Notes: 933 (1) This event's actions are a result of dangling SA awareness. 934 In a pure continuous channel system, the action here would be to 935 delete all phase 2 SAs and the phase 1 SA. 937 (2) This event may result from the action associated with the 938 previous note. Thus, this event is the result of a continuous 939 channel implementation attempting to be dangling SA aware. 941 (3) Implementations could choose to do nothing here, and behave 942 as an SA dangling implementation. However, if phase 1 SA negotiation 943 fails, in general it means that the control channel between the 944 peers cannot be maintained, suggesting that phase 2 SAs should also 945 be deleted. 947 3.2.1 Identity Perfect Forward Secrecy 949 Identity PFS is normally done by allowing the use of only a single 950 quick mode in a phase 1 SA. This is controlled by the deletion of 951 the phase 1 after a quick mode. 953 In a dangling SA implementation, this is not a problem, since the 954 absence of a valid phase 1 SA is permitted. However, in a continuous 955 channel implementation, this can lead to the absence of the channel. 957 This is solved by creating two phase 1 SAs before the first quick 958 mode is done. The first of these SAs is assigned the role of channel 959 management, and thus performs SA deletion and notification transfer. 960 The second SA is used to perform the quick mode, and is immediately 961 deleted. 963 The phase 1 SA that is assigned to channel management is re-keyed as 964 described here. Since it is the oldest phase 1 SA, it will naturally 965 be used for all management traffic even if another phase 1 SA 966 temporarily exists only for the purpose of performing a quick modes. 967 These other phase 1 SAs are created and used to generate phase 2 968 SAs, then immediately deleted. 970 3.3 Dangling Phase 2 SA Implementations 972 These implementations allow phase 2 SAs to exist without a valid 973 phase 1 SA between peers. They do this by allowing phase 1 SAs to 974 expire without re-keying them, and then re-keying them only when 975 necessary, such as when a phase 2 SA needs re-keying. 977 Unfortunately, this can lead to situations where phase 2 SAs cannot 978 be properly cleaned up. For example, if an implementation's policy 979 is changed to disallow a user access to a network, all SAs between 980 that user and the network should be terminated. However, if there 981 are no phase 1 SAs between them, none can be re-keyed, so the DELETE 982 notifications for the phase 2 SAs cannot be sent. This can lead to 983 the existence of invalid phase 2 SAs on one end, with the result 984 that encrypted traffic is send from that end that cannot be used. 985 Since phase 1 SAs cannot be created, the SAs cannot be explicitly 986 deleted by the peer. 988 (If this was a continuous channel implementation, the phase 2 SAs 989 could have been deleted when the change in authorisation was 990 discovered, or when the existing phase 1 SA expired.) 992 Summarised, the rules for phase 1 re-keying for dangling SA 993 implementations are: 995 Initial Phase 1 SA Negotiation: 996 -initiator MUST use INITIAL-CONTACT notification 997 -responder SHOULD use INITIAL-CONTACT notification (when 998 possible) 999 -responder deletes any pre-existing phase 1 SA with the peer when 1000 authentication of peer complete 1001 -responder deletes all previously existing phase 2 SAs with the 1002 peer, if any 1004 New Phase 1 SA Negotiation: 1005 -initiator MUST NOT use INITIAL-CONTACT notification 1006 -responder MUST detect that this is a re-key and MUST NOT use 1007 INITIAL-CONTACT notification 1008 -responder SHOULD mark all existing phase 1 SAs with same peer as 1009 re-keyed, so as to not re-key again 1010 -since no INITIAL-CONTACT notification is used by either end; 1011 phase 2 SAs are kept 1013 Phase 1 SA Expiration: 1014 -DELETE notification SHOULD be sent for phase 1 SA only 1016 Phase 2 SA Ages, and no existing phase 1 SA 1017 -attempt New Phase 1 SA Negotiation 1018 -if that succeeds, attempt new phase 2 SA negotiation 1020 A possible state machine for continuous channel implementations is 1021 shown in Table 2. Note that this state machine does not cover error 1022 conditions, simultaneous SA negotiations and other events, and is 1023 provided for illustration only. It should not be considered a 1024 complete design. 1026 # SAs 1027 P1 P2 Event Actions 1028 ======================================================================= 1029 0 0 -phase 1 negotiation -initiate phase 1 negotiation 1030 from peer -use initial contact if allowed 1031 -phase 1 SA needed 1032 ======================================================================= 1033 1 0 -phase 1 SA negotiation -respond to phase 1 negotiation 1034 from peer -do not use initial contact 1035 ----------------------------------------------------------------------- 1036 -phase 1 SA deletion -delete phase 1 SA 1037 from peer 1038 ----------------------------------------------------------------------- 1039 -phase 1 SA expires -send delete notification for phase 1 SA 1040 -delete phase 1 SA 1041 ======================================================================= 1042 1+ 1+ -phase 1 SA negotiation -respond to phase 1 negotiation 1043 from peer -do not use initial contact 1044 ----------------------------------------------------------------------- 1045 -phase 1 SA deletion -delete phase 1 SA 1046 from peer 1047 ----------------------------------------------------------------------- 1048 -phase 1 SA expires -send delete notification for phase 1 SA 1049 -delete phase 1 SA 1050 ======================================================================= 1051 0 1+ -phase 1 SA negotiation -respond to phase 1 negotiation 1052 from peer -do not use initial contact 1053 ----------------------------------------------------------------------- 1054 -phase 2 SA ages -attempt to re-negotiate phase 1 SA 1055 -re-key phase 2 SA if successful 1056 ----------------------------------------------------------------------- 1057 -phase 2 SA expires -attempt to re-negotiate phase 1 SA 1058 -send delete notification for phase 2 SA 1059 if successful 1060 -delete phase 2 SA unconditionally 1061 ======================================================================= 1063 Table 2 Dangling SA State/Event Table 1065 The differences between Table 1 and Table 2 are the following: 1067 -ageing detection of phase 1 SAs is unnecessary 1068 -the state table is not split based on having 1 or more than 1 1069 phase 1 SA for the event where a phase 1 SA deletion is received 1070 -the state table now depends on phase 2 SA events 1072 While there is more complexity in the continuous channel 1073 implementation, it is not excessive, and some of it is required to 1074 support the dangling SA implementation. 1076 3.4 Other Phase 1 SA Re-keying Issues 1078 This section describes other issues associated with phase 1 SA re- 1079 keying that are independent of the whether the implementation 1080 dangles phase 2 SAs or not. 1082 3.4.1 Multiple SA Usage 1084 When there is more than one phase 1 SA between peers, it is 1085 recommended that the oldest SA be used for subsequent traffic 1086 requiring phase 1 SAs. This allows full use of the keying material 1087 generated and reduces race conditions. It also means that no special 1088 expiration conditions are required when the phase 1 SAs expire by 1089 traffic only, as the old SA will eventually expire on its own due to 1090 usage. 1092 3.4.2 INITIAL-CONTACT Notification 1094 As stated above, the INITIAL-CONTACT notification should be used 1095 only on the very first phase 1 that is negotiated between two peers. 1097 If used on subsequent negotiations, it means that all pre-existing 1098 SAs (phase 1 and phase 2) held between the peers should be deleted. 1100 As an example, this is the mechanism used to detect when an SA end 1101 point has crashed and is now alive again. 1103 The use of INITIAL-CONTACT may be restricted by the mode used to 1104 negotiate phase 1 SAs. For these reasons, implementation may want to 1105 avoid the use of aggressive mode when possible. When it is used, it 1106 is recommended that the third aggressive mode message be encrypted 1107 so that the INITIAL-CONTACT notification can be added to it when 1108 needed. Note that the responder during aggressive mode is never 1109 allowed to use any notification, and this document's suggestion that 1110 the use of INITIAL-CONTACT is permitted by the initiator if the 1111 third aggressive mode packet is encrypted is possibly contrary to 1112 RFC2408. 1114 3.4.3 DELETE Notification 1116 As currently defined by the IPSec documents, the DELETE notification 1117 is advisory only and is optional and unacknowledged. 1119 Given that it is optional, UDP based, and not used by some existing 1120 implementations, it should never be considered necessary. 1122 However, even though its use is of dubious value, it SHOULD be sent 1123 when any SA (phase 1 or phase 2) is deleted, since the expiration of 1124 SAs may not occur at the same time at both ends to increase the 1125 probability that both ends are synchronised with respect to SA 1126 usage. 1128 Further, implementations should attempt to use the acknowledged 1129 notify exchange as described in [IKEbis]. 1131 3.4.4 Re-keying Timing 1133 To reduce the probability of simultaneous re-keying, each device 1134 should re-key at a variable time with respect to the SA's expiration 1135 limit, in case they are the same. These recommendations apply to 1136 both phase 1 and phase 2 SAs. 1138 An example of this is that the end with the higher IP address re- 1139 keys at 95% of the lifetime, while the end with lower IP address re- 1140 keys at 85% of the lifetime. 1142 Whatever rule is chosen, it is recommended that the rule be 1143 deterministic in order to have predictable and consistent behaviour 1144 between peers. If the rule had used the SPI as the determining 1145 factor (as an example did in the first version of this document), 1146 different peers would be doing the re-keying at different times. 1148 In any case, simultaneous attempts at re-keying should be supported 1149 in one form or another, since it can never be guaranteed that this 1150 will not happen under all circumstances. 1152 4. Next IPSec Version Recommendations 1154 The recommendations made in sections 2 and 3 of this document have 1155 limitations in their ability to provide lossless, reliable and 1156 interoperable SA re-keying due to restrictions of existing 1157 implementations and the existing IPSec documentation. 1159 This section makes recommendations for explicit re-transmission 1160 rules, phase 1 and phase 2 re-keying, and describes the use of a new 1161 mode for reliable SA deletion in order to better provide reliable, 1162 lossless and interoperable re-keying. 1164 Also, a replacement for the commit bit is proposed. 1166 4.1 Re-transmission Rules 1168 In systems that use exchanges that have an even number of packets, 1169 the rules for re-transmission are relatively obvious. Simply put, a 1170 packet is re-sent if the expected response to it is not received 1171 within a certain period of time. 1173 However, IPSec has a number of modes that have an odd number of 1174 packets. This can lead to confusion as to when the re-transmission 1175 rules should be applied, depending how the re-transmission rules are 1176 applied to the packets in the echange. This in turn can lead to the 1177 dropping of aggressive and quick modes' third messages. It is 1178 recommended that each of these modes have specific rules applied to 1179 them to avoid re-transmission issues. 1181 These rules will be applied based on request-response pairs. Packets 1182 are defined as a request or a response in an exchange. The requestor 1183 is responsible for re-sending the request in order to solicit the 1184 response. The responder (not to be confused with an SA negotiation 1185 responder) is responsible for re-sending the response as it receives 1186 the initial and subsequent transmissions of the request. Note that 1187 the responder must exist after transmitting a response in case that 1188 response is dropped. 1190 In the modes with an odd number of packets, the request-response 1191 pair must be applied across the odd number of packets. This means 1192 that at least one packet must be considered the response to the 1193 previous packet, and must also be considered the request of the next 1194 request-response pair. 1196 This means that an implementation must be able to perform re- 1197 transmission of packets after it normally would have considered 1198 itself to be done with an exchange or a mode. Further, any timers 1199 set by the transmission of the final message of an exchange should 1200 be reset when re-transmission occurs. 1202 4.1.1 Main Mode Re-Transmission Rules 1204 In main mode, there are effectively three completely separate 1205 exchanges. The first request-response pair contains the SA 1206 proposals, the second pair contains the keying material, and the 1207 third pair contains the authentication material. (These descriptions 1208 are generalised for the purposes of stating what the exchanges are, 1209 and are not intended to create discussion on the actual contents of 1210 the exchanges.) 1212 As an example of the separation of the exchanges, there is no need 1213 to re-send the second main message to solicit the third main mode 1214 message, since the responder should not send the fourth main mode 1215 message until receiving the third main mode message. The absence of 1216 the fourth main mode message will cause the initiator to re-send the 1217 third main mode message. 1219 Keeping the exchanges separate from a re-transmission point of view 1220 should simplify implementations. 1222 4.1.2 Aggressive Mode Re-Transmission Rules 1224 In aggressive mode, the second message is the message that is both a 1225 response and a request. Therefore, the responder in a phase 1 1226 negotiation that uses aggressive mode must re-transmit the second 1227 aggressive mode message to solicit a third aggressive mode message 1228 that it perceives as lost. 1230 4.1.3 Quick Mode Re-Transmission Rules 1232 In quick mode, the second message is the message that is both a 1233 response and a request. Therefore, the responder in a phase 1 1234 negotiation must re-transmit the second quick mode message to 1235 solicit a third quick mode message that it perceives as lost. 1237 These rules must apply independently of the state of the commit bit, 1238 since there are currently no timing restrictions on the transmission 1239 of the CONNECTED notification. 1241 4.2 Acknowledged SA Deletion 1243 A previous version of this document described a new mode called 1244 Delete Mode. This mode is no longer necessary, as the new proposed 1245 Acknowledged Informational exchange can be used with the delete 1246 payload to perform the same thing. (See section 6.4.2 of [IKEbis].) 1247 This section describes in detail how the Acknowledged Informational 1248 exchange is used when deleting SAs. 1250 The Acknowledged Informational exchange consists of two packets. The 1251 first packet is the transmission of a notify or delete payload. The 1252 second is the acknowledgement of that packet. 1254 When used with a delete payload, it is interpreted to mean the 1255 following: 1257 "I am not sending anymore traffic on this SA (or these SA pairs). 1258 Would you please stop sending traffic on it (or them), and send me 1259 an acknowledgement when you are done?" 1261 The receiver of the delete request then switches his outbound 1262 traffic to another SA, deletes both inbound and outbound SAs and 1263 sends the delete acknowledgement. 1265 This is interpreted to mean: 1267 "I am also not sending anymore traffic on this SA (or these SA 1268 pairs). You may delete it (or them)." 1270 The receiver of the delete acknowledgement may then delete the 1271 inbound SA. The outbound SA should have already been deleted or 1272 somehow not used before the sending of the delete request. 1274 Note that re-transmission rules apply to the request-acknowledge 1275 pair. That is, if the initiator of the delete mode does not get the 1276 delete acknowledgement, the delete request should be re-transmitted. 1277 Similarly, if the responder of the delete request receives multiple 1278 copies, multiple copies of the delete acknowledgement should be 1279 sent. 1281 If the retry counter for the delete request expires, the SAs 1282 indicated in the request should be unilaterally deleted. 1284 Note that there is a race condition for the delete request and 1285 delete acknowledgement packets if an implementation sends them 1286 immediately after sending a packet on one of the SAs to be deleted. 1287 The race occurs if the packet order gets changed in the network and 1288 the delete mode packets arrive before packets sent on the SAs to 1289 which the deletes refer. 1291 The delete request-acknowledgement pair should also be applied to 1292 phase 1 SAs. In this case, the phase 1 SA is not completely torn 1293 down until the reception of the delete acknowledgement message. 1295 As a specific clarification, the binding between the inbound and the 1296 outbound phase 2 SAs is not weakened. In the messages used, the SA 1297 specified in the delete request is that of the sender's inbound SA. 1298 In other words, the SPI sent to be deleted is the SPI that was 1299 generated by the sender. When phase 1 SAs are being deleted, the SPI 1300 values used are the cookies of the phase 1 SA to be deleted. 1302 The use of the Acknowledged Informational does not eliminate the use 1303 for the existing DELETE notification. It could still be used if an 1304 implementation determines it needs to immediately (and impolitely) 1305 delete an SA. Implementations must still recognise that it is sent 1306 over UDP and may be dropped. 1308 4.3 Phase 1 Re-keying for IPSecond 1310 The phase 1 re-keying method described in Section 3 requires only 1311 one change for IPSecond. That is the required use of the 1312 Acknowledged Informational exchange when deleting SAs. 1314 4.4 Phase 2 Re-keying for IPSecond 1316 The phase 2 re-keying proposal described in Section 2, while 1317 necessary under the circumstances, is not the ideal method of re- 1318 keying. It forces the specific transfer times of SAs, thus making 1319 the intent of paragraph 2, section 9 of [IKE] impossible. 1321 This section describes proposals related to re-keying for the next 1322 version of the IPSec protocols. The purpose is to precisely define 1323 re-keying so that implementations are lossless and perfectly 1324 interoperable during re-keying. It also allows the spirit of 1325 paragraph 2, section 9 of [IKE] to be used. Further, it meets the 1326 requirements of paragraph 3 of section 4.3 of [ISAKMP]. 1328 A summary of the recommendations is: 1330 1) Define and require that the normal procedure is to use the 1331 oldest phase 2 SA first, and to use it until its natural 1332 expiration. 1334 2) Use the recommended re-transmission request rules for quick 1335 mode. 1337 3) Make use of the Acknowledged Informational exchange a 1338 requirement for SA deletion. 1340 4.4.1 Oldest Phase 2 SA First 1342 The concept of using the oldest phase 2 SA first for outbound 1343 traffic allows the maximum use of negotiated keys and allows for the 1344 pre-negotiation of an arbitrary number of phase 2 SAs to be made 1345 available for later use. 1347 Additionally, it decouples new phase 2 SA negotiation from old phase 1348 2 SA deletion, and the need to transfer to the new SA during re- 1349 keying. 1351 It also eliminates the race condition that occurs during SA set up 1352 during re-keying. This means that use of the commit bit to avoid the 1353 race condition is not necessary except when the very first phase 2 1354 SA is set up. 1356 The oldest SA is defined as the first negotiated of the available 1357 SAs. In cases of simultaneous and near simultaneous SA negotiation, 1358 the use of the delete mode and the ability to overlap SAs for an 1359 arbitrary period of time should make this condition manageable. 1361 4.4.2 Phase 2 Re-keying Illustration 1363 This section illustrates the events when re-keying occurs using the 1364 above proposals. Note the simplifications due to the decoupling of 1365 SA negotiation and old SA deletion. 1367 Initiator Responder 1369 Inbound Outbound Inbound Outbound 1370 | | | | 1371 1 ----------------- | | 1372 | | ------------ | | 1373 | | -------------------> 2 1374 | | | | | 1375 | | -------------------- 3 1376 | | ------------ | | 1377 4 <--------------- | | 1378 | | | | | 1379 5 ---------------- | | 1380 | *6 | ------------ | | 1381 | | | ------------------> 7 1382 | | | | | 1383 | | | | *8 | 1384 | | | | | | 1385 9 1386 | | | | | | 1387 | | *10 *10 | | | 1388 11 ----------------- | | | | 1389 | | ------------ | | | 1390 | | | -------------------> 12 1391 | | | | | | 1392 | | | | | *13 * 13 1393 | | | | | | 1394 | | | | | | 1395 | | | -------------------- 14 1396 | | ------------ *15| | 1397 16 <--------------- | | | 1398 | | | | | 1399 *17| | | | 1400 | | | | 1402 Figure 4-1 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1403 Initiator Expiration 1405 1) Initiator sends first quick mode message. 1407 2) Responder receives first quick mode message. 1409 3) Responder sends second quick mode message. 1411 4) Initiator receives second quick mode message. 1413 5) Initiator sends third quick mode message. 1415 6) Initiator sets up new inbound SA. Implementations may choose to 1416 set up the new outbound SA at this time, as long as they do not 1417 use it. 1419 7) Responder receives third quick mode message. 1421 8) Responder set up new inbound SA. Implementations may choose to 1422 set up the new outbound SA at this time, as long as they do not 1423 use it. 1425 9) Initiator's old SA pair expires. 1427 10) Initiator starts using new outbound SA and stops using old 1428 outbound SA. 1430 11) Initiator sends first Acknowledged Informational exchange 1431 message with a delete payload. 1433 12) Responder receives first Acknowledged Informational exchange 1434 message. 1436 13) Responder sets up new outbound SA. 1438 13) Responder deletes old outbound SA and starts using new outbound 1439 SA. 1441 14) Responder sends second Acknowledged Informational exchange 1442 message. 1444 15) Responder deletes old inbound SA. 1446 16) Initiator receives second Acknowledged Informational exchange 1447 message. 1449 17) Initiator deletes old inbound SA. 1451 If the responder's old SA expires first, the events are as follows. 1453 Initiator Responder 1455 Inbound Outbound Inbound Outbound 1456 | | | | | | 1457 9 1458 | | | | | | 1459 | | | | | *10 *10 1460 | | | | | | 1461 | | | -------------------< 11 1462 | | | ------------ | | | 1463 12 <--------------- | | | 1464 | | | | | | 1465 | | *13 *13 | | | 1466 | | | | | | 1467 | | | | | | 1468 | | | | | | 1469 14 >--------------- | | | | 1470 15 * | ------------ | | | 1471 | | -------------------> 16 1472 | | | | | 1473 | | 17 * | | 1474 | | | | 1476 Figure 4-2 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1477 Responder Expiration 1479 9) Responder's old SA pair expires. 1481 10) Responder starts using new outbound SA and stops using old 1482 outbound SA. 1484 11) Responder sends first Acknowledged Informational exchange 1485 message with a delete payload. 1487 12) Initiator receives first Acknowledged Informational exchange 1488 message. 1490 13) Initiator sets up new outbound SA. 1492 13) Initiator deletes old outbound SA and starts using new outbound 1493 SA. 1495 14) Initiator sends second Acknowledged Informational exchange 1496 message. 1498 15) Initiator deletes old inbound SA. 1500 16) Responder receives second Acknowledged Informational exchange 1501 message. 1503 17) Responder deletes old inbound SA. 1505 4.5 Commit Bit Replacement 1507 The intent of this section is to propose a mechanism to allow 1508 implementations to delay the usage of negotiated SAs. Its use may 1509 eliminate the need for the commit bit, and will not suffer from any 1510 of the problems of the commit bit. While the commit bit usage is 1511 much better defined by [IKEbis], it is unable to solve all the 1512 difficulties associated with it. 1514 Replacement of the commit bit is done by introducing a new mechanism 1515 to indicate to a peer that usage of a newly negotiated SA should be 1516 deferred. Then, depending on the deferral time intended, one of two 1517 mechanisms is introduced to indicate that the SA may be used. 1519 These mechanisms are preferred over the commit bit for the following 1520 reasons: 1522 o They receive the full protection of phase 1 SAs, and as such 1523 provide the maximum resistance to denial of service attacks. 1525 o Their use is clearly and unambiguously defined. 1527 o They are resistant to the possibilities of dropped packets. 1529 4.5.1 DEFER_USAGE Notify Payload 1531 The indication that an SA should not be made available for use 1532 immediately by peer can be indicated by the addition of a new 1533 notify payload to the quick mode that negotiated the SA. To allow a 1534 single quick mode to negotiate multiple SAs, the DEFER_USAGE notify 1535 payload explicitly names the SA whose use is to be deferred, in the 1536 same manner as the current DELETE payload. 1538 The DEFER_USAGE notify payload should be added by the peer wishing 1539 to delay usage of an SA. 1541 On reception of the DEFER_USAGE notify payload, the newly negotiated 1542 SA should be set aside until reception of the ALLOW_USAGE notify 1543 payload, described in the next section, or the reception of the 1544 CONNECTED notification. 1546 The expected response depends on which type of DEFER_USAGE 1547 notification is sent. These types are termed long and short. A short 1548 DEFER_USAGE notification causes a quick mode to become four messages 1549 in length, as with the intended use of the commit bit. A long 1550 DEFER_USAGE notification causes quick mode to proceed normally, with 1551 usage of the specified SA deferred until the sender of the 1552 DEFER_USAGE notification sends the ALLOW_USAGE notify. 1554 Implementations should be prepared to received the long DEFER_USAGE 1555 notification for the same SA (pair) that they send it for; in other 1556 words, usage of both SAs (inbound and outbound) of the negotiated 1557 pairs may be deferred simultaneously by both peers. 1559 There are no time constraints associated with the sending of the 1560 long DEFER_USAGE notification and the subsequent reception of the 1561 allow usage mode. 1563 Usage of the short DEFER_USAGE notification is restricted to quick 1564 mode responders only. It causes the transmission of a CONNECTED 1565 notification as a fourth quick mode message in the same way that the 1566 commit bit does. 1568 4.5.2 ALLOW_USAGE Notify Payload 1570 The purpose of this notify is to indicate to a peer that an SA may 1571 now be used. Normally, usage of the SA by the peer would have been 1572 deferred by the use of the long DEFER_USAGE notify payload, 1573 described in the previous section. However, reception of this notify 1574 for an SA whose usage has not been deferred is not considered an 1575 error. 1577 This payload MUST be used only with the Acknowledged Informational 1578 exchange. 1580 The initiator of the exchange must start usage of the inbound SA of 1581 the pair when sending the first packet of the exchange. Usage of the 1582 initiator's outbound SA must wait until reception of the 1583 acknowledgement packet of the exchange. 1585 The responder of the exchange must start usage of its inbound SA of 1586 the pair before sending the acknowledgement, and may start usage of 1587 its outbound SA of the pair any time after receiving the first 1588 packet of the exchange. 1590 The initiator of the exchange re-transmits the ALLOW_USAGE 1591 notification until it receives the acknowledgement packet or exceeds 1592 its re-try counter. 1594 If use of the SA was deferred by both peers, two transactions of the 1595 ALLOW_USAGE notification are required (one in each direction) before 1596 the SAs involved may be used. 1598 5. Acknowledgements 1600 Some of the concepts presented in this document are based on work 1601 done by TimeStep Corporation's engineering group. 1603 Others are taken from concepts discussed within the IPSec working 1604 group, particularly some of the concerns expressed about problems 1605 with the commit bit. 1607 6. References 1609 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1610 RFC2409, November 1998 1612 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1613 "Internet Security Association and Key Management Protocol 1614 (ISAKMP)", RFC2408, November 1998 1616 [IKEbis]Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1617 draft-ietf-ipsec-ike-01.txt, May 1999 1619 Revision History 1621 September 23, 1998 Initial Release 1623 April 7, 1999 -clarification of objectives of document 1624 -more commit bit comments 1625 -change phase 1 re-keying discussion to explicitly 1626 allow multiple phase 1 SAs between peers; previous 1627 version explicitly allowed only 1 phase 1 between 1628 peers 1629 -other miscellaneous changes 1631 October 20, 1999 -separation of phase 1 re-keying into continuous 1632 channel and dangling SA implementations 1633 -use of Acknowledged Information exchange used 1634 where possible 1635 -other changes 1637 Security Considerations 1639 This document is associated with the IPSec family of documents. As 1640 such, security considerations permeate the document. 1642 Author's Address 1644 Tim Jenkins 1645 tjenkins@timestep.com 1646 TimeStep Corporation 1647 362 Terry Fox Drive 1648 Kanata, ON 1649 Canada 1650 K2K 2P5 1651 +1 (613) 599-3610 1653 The IPSec working group can be contacted via the IPSec working 1654 group's mailing list (ipsec@lists.tislabs.com) or through its 1655 chairs: 1657 Robert Moskowitz 1658 rgm@icsa.net 1659 International Computer Security Association 1661 Theodore Y. Ts'o 1662 tytso@MIT.EDU 1663 Massachusetts Institute of Technology 1665 This document expires April 20, 2000