idnits 2.17.1 draft-jenkins-ipsec-rekeying-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 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 175: '... implementation SHOULD begin using th...' RFC 2119 keyword, line 176: '...ound traffic and SHOULD continue to su...' RFC 2119 keyword, line 783: '... -initiator MUST use INITIAL-CONT...' RFC 2119 keyword, line 795: '... -initiator MUST NOT use INITIAL-...' RFC 2119 keyword, line 796: '... -responder MUST detect that this...' (3 more instances...) 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 (April 14, 1999) is 9144 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 1049, but not defined ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Tim Jenkins 2 IP Security Working Group TimeStep Corporation 3 Internet Draft April 14, 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). All Rights Reserved. 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.........................................4 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-Set Up........................................8 52 2.2.1.1 Normal Conditions.........................................8 53 2.2.1.2 Dropped Packet Conditions................................10 54 2.2.1.3 Failed Negotiation.......................................11 55 2.2.1.4 Responder Pre-Set Up Security Hole.......................11 56 2.2.2 Recommended Re-keying Method...............................12 57 2.2.2.1 Dropped Quick Mode 3 Message.............................13 58 2.2.2.2 Absence of Traffic.......................................13 59 2.2.2.3 Compatibility With Observed Behaviours...................14 60 2.2.2.4 Compatibility with Commit Bit............................14 61 2.2.2.5 Implementation Notes.....................................15 62 2.3 Conclusions..................................................15 63 3. Phase 1 Re-keying.............................................15 64 3.1 Phase 1 Re-keying Requirements...............................15 65 3.1.1 Multiple SA Usage..........................................16 66 3.1.2 INITIAL-CONTACT Notification...............................17 67 3.1.3 DELETE Notification........................................17 68 3.1.4 Re-keying Timing...........................................17 69 4. Next IPSec Version Recommendations............................17 70 4.1 Re-transmission Rules........................................18 71 4.1.1 Main Mode Re-Transmission Rules............................18 72 4.1.2 Aggressive Mode Re-Transmission Rules......................19 73 4.1.3 Quick Mode Re-Transmission Rules...........................19 74 4.2 SA Delete Mode...............................................19 75 4.3 Phase 1 Re-keying for IPSecond...............................20 76 4.4 Phase 2 Re-keying for IPSecond...............................20 77 4.4.1 Oldest Phase 2 SA First....................................21 78 4.4.2 Phase 2 Re-keying Illustration.............................21 79 4.5 Commit Bit Replacement.......................................24 80 4.5.1 DEFER_USAGE Notification...................................24 81 4.5.2 Allow Usage Mode...........................................25 82 4.5.3 CONNECTED Notification.....................................25 83 5. Acknowledgements..............................................26 84 6. References....................................................26 86 1. Introduction 88 This document has three primary objectives. 90 The first objective is to illustrate problems and issues associated 91 with re-keying within the confines of the current set of IPSec 92 documents. For a number of reasons, re-keying in IPSec has become 93 problematic, such that packets can get dropped by IPSec 94 implementations during re-keying. Worse, there exists the 95 possibility that IPSec implementations from different vendors may 96 not be interoperable because of the way they re-key. 98 The second objective of this paper is to propose methods of 99 performing both phase 1 and phase 2 re-keying for IPSec 100 implementations in such a way as to minimise packet loss and to 101 maximize compatibility. 103 The initial focus of the first two objectives is on phase 2 re- 104 keying; it is then extended to phase 1 re-keying. The need for this 105 document in each case is initially discussed, followed by a 106 recommendation for re-keying within the protocol framework 107 established by the initial version of the IPSec documents. 109 Finally, the third objective of the document is to provide 110 recommendations for the next version of the IPSec protocols. These 111 recommendations are made to best solve the re-keying problems in a 112 manner that is not possible within the constraints of the existing 113 IPSec documents. 115 2. Phase 2 SA Re-keying 117 This section discusses phase 2 re-keying issues and makes 118 recommendations to minimize the impact of these issues within the 119 current IPSec document set. 121 2.1 Phase 2 Re-keying Issues 123 The issues associated with phase 2 re-keying are listed below. Some 124 of the points are expanded upon later. 126 1) There is no specification defining how re-keying is to be done. 128 2) The existing drafts appear contradictory in their 129 recommendations on the usage of multiple phase 2 SAs. 131 3) Some recent implementations have shipped with a method of re- 132 keying that will not perform reliably under real world network 133 conditions. 135 4) The use of the DELETE notification is not required. 137 5) A variety of re-keying behaviours have been observed, some of 138 which are incompatible. 140 6) The commit bit is not yet widely implemented, and its use as 141 described is confusing. Further, while the documentation 142 requires its support, its use is not required. 144 7) A race condition exists at SA set up, exacerbating re-keying 145 issues. 147 2.1.1 Inconsistent SA Use Recommendation 149 The issue of inconsistent SA usage recommendations is examined 150 further here. 152 From paragraph 2 of Section 9 of [IKE]: 154 An implementation may wish to negotiate a range of SAs when 155 performing Quick Mode. By doing this they can speed up the "re- 156 keying". Quick Mode defines how KEYMAT is defined for a range of 157 SAs. When one peer feels it is time to change SAs they simply use 158 the next one within the stated range. A range of SAs can be 159 established by negotiating multiple SAs (identical attributes, 160 different SPIs) with one Quick Mode. 162 While the document does not define what "... the next one ..." 163 means, this paragraph strongly implies that there is no required 164 order for the use of phase 2 SAs that have been negotiated within a 165 phase 1 SA, and that multiple SAs may be pre-negotiated and used at 166 will. 168 However, this appears to be contradicted by paragraph 3 of section 169 4.3 of [ISAKMP]: 171 Modification of a Protocol SA (phase 2 negotiation) follows the 172 same procedure as creation of a Protocol SA. The creation of a new 173 SA is protected by the existing ISAKMP SA. There is no 174 relationship between the two Protocol SAs. A protocol 175 implementation SHOULD begin using the newly created SA for 176 outbound traffic and SHOULD continue to support incoming traffic 177 on the old SA until it is deleted or until traffic is received 178 under the protection of the newly created SA. As stated previously 179 in this section, deletion of an old SA is then dependent on local 180 security policy. 182 Many implementations have interpreted this to mean that the new SA 183 should be used for outbound in preference to the old SA. In other 184 words, the old SA should be abandoned as soon as possible. 186 This interpretation of [ISAKMP] is in direct conflict with the usage 187 implied by [IKE], resulting in potential problems. 189 2.1.2 Observed Behaviours 191 The following behaviours have been observed by various vendors' 192 implementations when devices have set up a second phase 2 SA. The 193 behaviours listed below are not mutually exclusive. 195 1) The device continues to use the old SA until it naturally 196 expires, then switches to the new SA. 198 2) The device immediately begins using the new SA. 200 3) The device immediately drops the old SA. 202 4) The device never sends a DELETE notification. 204 5) The device always sends a DELETE notification. 206 6) The device deletes the old SA some time after re-keying, but 207 before the end of its natural lifetime. 209 7) A device wants to keep more than one SA up all the time. 211 All of these behaviours are permitted under the current documents. 212 However, even when quick mode packets are not lost, it can be seen 213 that interoperability is not always possible with some combinations 214 of behaviours listed above. 216 2.1.3 SA Set-up Race Condition 218 Further, behaviour 2 above is not a good behaviour, as illustrated 219 below. In this example, the initiator is a gateway capable of 220 handling full T3 bandwidth rates, while the responder is a PC 221 running a software IPSec implementation, and it is overloaded. 223 In the illustration, QM1 refers to the first quick mode message, QM2 224 to the second quick mode message and QM3 to the third quick mode 225 message. 227 Initiator Responder 229 QM1 sent ---- 230 ------- 231 ------------- 232 ---------------> QM1 received 233 | 234 | 235 | QM1 processed 236 | 237 | 238 ---------------- QM2 sent 239 ------------- 240 ------- 241 QM2 rec. <---- 242 process | 243 QM3 sent ----- 244 * ------- 245 packet on new SA ------------- 246 _____ ---------------> QM3 received 247 _______ | 248 _____________ | QM3 processing 249 _______________| 250 | packet dropped 251 | 252 * new SA set up 254 Figure 2-1 Race Condition Sequence Chart 256 By the time the responder has set up the new SA, packets protected 257 by that SA have already started arriving from the initiator. This 258 causes them to be dropped by the responder. This case is further 259 complicated by the possibility of packets taking different paths 260 through the network, so theoretically, the third quick mode message 261 could arrive after packets protected by the new SA. 263 Additionally, since all IKE packets are based on UDP, there is no 264 guarantee that QM3 even arrives at the peer, so making assumptions 265 about new SA use based on the transmission time of a packet will 266 still lead to failures in the field. 268 To reduce the effects of packet loss, some implementations were 269 observed to blindly transmit QM3 multiple times, back to back. 271 This can reduce the probability that the peer does not get QM3, but 272 cannot eliminate it. Nor can it eliminate race conditions due to 273 path differences or processing times. 275 If the behaviour of the initiator was to delay usage of the new SA 276 for outbound traffic, this would cause failures for those 277 implementations that immediately delete the old SA. Therefore, the 278 behaviour of delaying use of the new SA and immediately deleting the 279 old SA are incompatible. 281 2.1.4 Commit Bit Interaction 283 The use of the commit bit can solve the race condition illustrated 284 in the previous section when asserted by the responder during quick 285 mode. However, it suffers from the following problems: 287 1) Use of the commit bit is not well defined. The present 288 documentation specifies its use for phase 1 and phase 2, but 289 mentions phase 2 specific details. There are also issues 290 related to how the subsequent CONNECTED notification fits in 291 with the quick mode exchange. 293 2) While its support is required, its use is not. 295 3) Its use may make implementations susceptible to a denial of 296 service attack by forcing initiators to wait for a CONNECTED 297 notification that may never come. While this is only one of 298 many very basic possible denial of service attacks on IKE, this 299 is not an excuse to leave the existing implementation as it is. 301 4) There is no defined way to recover from the loss of the 302 CONNECTED notification. 304 5) Some implementations are using the commit bit for the wrong 305 reasons. 307 Point 1 is being addressed by the working group; future versions of 308 the IPSec documents should clarify these issues. 310 Point 3 happens because the commit bit is in the ISAKMP header, and 311 the ISAKMP header is not authenticated, so is susceptible to 312 modification. 314 Point 5 above needs some elaboration. In a previous section, it was 315 mentioned that the loss of the third quick mode message can cause 316 problems, since the responder will not set up the SA at all. Because 317 of this, some implementations have chosen to set the commit bit as a 318 mechanism to force the re-transmission of the third quick mode 319 message. 321 This is wrong for two reasons. First, it is not the stated purpose 322 of the commit bit. The purpose of the commit bit is to delay the 323 usage of an SA, for whatever reason. This implies that it is not a 324 good mechanism to cause re-transmission of the third quick mode 325 message. 327 Secondly, it does not solve the packet loss problem; it only defers 328 it. The logic of the improper usage is that the initiator will 329 resend the third quick mode message until it receives the CONNECTED 330 notification (which is now effectively the fourth quick mode 331 message). 333 The problem with this is that it leaves no mechanism for demanding 334 the re-transmission of the CONNECTED notification itself. It can be 335 dropped just as the third quick mode message can. This means that 336 the problem that was intended to be solved by the use of the commit 337 bit is simply pushed out to being the problem of solving the dropped 338 CONNECTED notification. 340 Sections 2.2.2.1 and 4.1 describe a mechanism for solving the 341 dropped third quick mode message problem. 343 2.2 Solution Examination 345 This section details the operation of some possible behaviours, with 346 the intent of arriving at a best possible phase 2 re-keying 347 mechanism under the constraints of the existing documents. 349 In all the examples, the term "sets up a new outbound SA" means that 350 the new outbound SA will be chosen in favour of the old one. Whether 351 the SA is actually created before that time or not is implementation 352 dependent. 354 2.2.1 Responder Pre-Set Up 356 As a starting point, the responder pre-set up method of re-keying is 357 examined. Note that it will work with most of the behaviours 358 observed in the field. 360 In this method, SAs are treated separately as inbound and outbound, 361 as well as old and new. Further, it takes advantage of the fact that 362 the responder knows what the SA is going to be after the second 363 quick mode message is sent. By using this information, it allows the 364 responder to set up the new inbound SA before having received the 365 third quick mode message. 367 Implicit acknowledgement of the reception of the third quick mode 368 message by the responder is provided by use of the new SA in the 369 initiator's inbound direction. The initiator should not use its new 370 outbound SA before that time. 372 Additionally, it does not require use of the CONNECTED notification 373 for prevention of the race condition, or the use of the DELETE 374 notification for removal of the old SA. This is important since, 375 even if they are always sent, they are unacknowledged UDP packets 376 and may be lost. 378 2.2.1.1 Normal Conditions 380 Figure 2-2 shows the operation under normal (successful) conditions. 382 Initiator Responder 384 Inbound Outbound Inbound Outbound 385 | | | | 386 1 ----------------- | | 387 | | ------------ | | 388 | | -------------------> 2 389 | | | | | 390 | | -------------------- 3 391 | | ------------ | *4 | 392 5 <--------------- | | | 393 | | | | | | 394 6 ---------------- | | | 395 | *7 | ------------ | | | 396 | | | -------------------> 8 397 | | | | | | | 398 | | | | | | * 399 | | | | | | *9 400 | | | | | *10 | 401 | | | | | | 402 | *11 | | | | 403 | | | *12 | | | 404 | | *13 | | | | 405 *14| | | | | 406 | | | *15 | 407 | | *16| | 408 | | | | 410 Figure 2-2 SA Pre-Set Up Sequence Chart 412 Events 414 1) Initiator sends first quick mode message. 416 2) Responder receives first quick mode message. 418 3) Responder sends second quick mode message. 420 4) Responder sets up new inbound SA. This is to handle the case 421 where the initiator starts transmitting on the new SA 422 immediately after sending the third quick mode message. 424 5) Initiator receives second quick mode message. 426 6) Initiator sends third quick mode message. 428 7) Initiator sets up new inbound SA. 430 8) Responder receives third quick mode message. 432 9) Responder sets up new outbound SA. 434 10) Responder deletes old outbound SA. 436 11) Traffic from responder to initiator arrives at initiator on new 437 SA. 439 12) Initiator sets up new outbound SA. 441 13) Initiator deletes old outbound SA. 443 14) Initiator deletes old inbound SA. 445 15) Traffic from initiator to responder arrives at responder on new 446 SA. 448 16) Responder deletes old inbound SA. 450 While appearing complicated, it enables the lossless transfer from 451 one SA to another while supporting almost all other behaviours. 453 Support for and use of the DELETE notification is unchanged. 455 2.2.1.2 Dropped Packet Conditions 457 In this case, the event list is modified to show what happens when 458 each packet is dropped once. The event numbers refer to those 459 illustrated in Figure 2-2. 461 1) Initiator sends first quick mode message. 463 e) Packet is dropped during transmission. 465 1b) Initiator times out waiting for second quick mode message. 467 1) Initiator re-sends first quick mode message. 469 2) Responder receives first quick mode message. 471 3) Responder sends second quick mode message. 473 4) Responder sets up new inbound SA. This is to handle the case 474 where the initiator starts transmitting on the new SA 475 immediately after sending the third quick mode message. 477 e) Packet is dropped during transmission. 479 1b) or 7b) Responder times out waiting for third quick mode 480 message. 482 1) or 3) Responder re-sends second quick mode message. 484 5) Initiator receives second quick mode message. 486 6) Initiator sends third quick mode message. 488 7) Initiator sets up new inbound SA. 490 e) Packet is dropped during transmission. 492 7b) Responder times out waiting for third quick mode message. 494 3) Responder re-sends second quick mode message. 496 5) Initiator receives second quick mode message again. 498 6) Initiator re-sends third quick mode message. 500 8) Responder receives third quick mode message. 502 and so on, as for normal operation. 504 2.2.1.3 Failed Negotiation 506 In this case, the second quick mode packet has an invalid hash, and 507 the initiator sends the notification to the peer. Again, the event 508 numbers refer to those illustrated in Figure 2-2. 510 1) Initiator sends first quick mode message. 512 2) Responder receives first quick mode message. 514 3) Responder sends second quick mode message. 516 4) Responder sets up new inbound SA. This is to handle the case 517 where the initiator starts transmitting on the new SA 518 immediately after sending the third quick mode message. 520 5) Initiator receives second quick mode message. 522 e) Hash (or other parameter) fails. 524 e1) Initiator sends notification to responder. 526 e2) Responder receives notification. 528 e3) Responder deletes new inbound SA. 530 A similar operation would occur if retry counters expire for packet 531 re-transmissions. 533 2.2.1.4 Responder Pre-Set Up Security Hole 535 In the failed negotiation case, the need to delete the invalid 536 inbound SA raises the issue of a temporary hole, in that the 537 responder allows inbound packets while waiting for the third quick 538 mode message. However, if the inbound SA is not set up ahead of 539 time, initiators that immediately transmit on the new outbound SA 540 will cause packets to be dropped. 542 It also illustrates why the proposal above made the usage of the 543 outbound SA by the initiator wait until there is an indication of 544 the use of the SA by the responder. 546 2.2.2 Recommended Re-keying Method 548 In this method, the previous method is modified to remove the risk 549 of the security hole. It also simplifies the operation somewhat, but 550 at the expense of lost packets if the initiator's behaviour is such 551 that it immediately uses the new SA for its outbound traffic. 553 Initiator Responder 555 Inbound Outbound Inbound Outbound 556 | | | | 557 1 ----------------- | | 558 | | ------------ | | 559 | | -------------------> 2 560 | | | | | 561 | | -------------------- 3 562 | | ------------ | | 563 4 <--------------- | | 564 | | | | | 565 5 ---------- | | | 566 | *6 ------------------ | | 567 | | | -------------------> 7 568 | | | | | | 569 | | | | | * 570 | | | | *8 | 571 | | | | | | *9 572 | | | | | *10 | 573 | | | | | | 574 | *11 | | | | 575 | | | *12 | | | 576 | | *13 | | | | 577 *14| | | | | 578 | | | *15 | 579 | | *16| | 580 | | | | 582 Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 584 1) Initiator sends first quick mode message. 586 2) Responder receives first quick mode message. 588 3) Responder sends second quick mode message. 590 4) Initiator receives second quick mode message. 592 5) Initiator sends third quick mode message. 594 6) Initiator sets up new inbound SA. 596 7) Responder receives third quick mode message. 598 8) Responder set up new inbound SA. 600 9) Responder sets up new outbound SA. 602 10) Responder deletes old outbound SA. 604 11) Traffic from responder to initiator arrives at initiator on new 605 SA. 607 12) Initiator sets up new outbound SA. 609 13) Initiator deletes old outbound SA. 611 14) Initiator deletes old inbound SA. 613 15) Traffic from initiator to responder arrives at responder on new 614 SA. 616 16) Responder deletes old inbound SA. 618 Note that deletion of the old inbound SA by the initiator could be 619 further delayed if protection against loss of packets using the old 620 SA on different and slower network paths is desired. 622 2.2.2.1 Dropped Quick Mode 3 Message 624 In cases where the third quick mode message is dropped, the 625 responder must request re-transmission of it by re-sending the 626 second quick mode message. The existence of traffic on the new 627 inbound SA at the initiator should not be used as an implicit 628 acknowledgement for the following reasons: 630 1) There may be no traffic for the responder to send. 632 2) The responder may be designed to use the old SA until its 633 natural expiration. 635 This implies that implementations must be able to respond to the re- 636 transmission of the second quick mode message even after having sent 637 the third quick mode message. 639 2.2.2.2 Absence of Traffic 641 The proposed implementation uses the presence of traffic from the 642 responder on new SAs to provide an implied acknowledgement for the 643 purposes of switching to the new SA. However, if there is no traffic 644 from the responder, the implied acknowledgement will not appear. 646 A similar behaviour is exhibited by implementations that continue to 647 use old SAs until their natural expiration. 649 However, due to the number of implementations that delete old SAs 30 650 seconds after negotiating a new one, the same behaviour has the best 651 chance of interoperability, and of not dropping packets when traffic 652 does restart. 654 Therefore, it is recommended that implementations delete old SAs and 655 start using new SAs 30 seconds after negotiating new SAs in the 656 absence of traffic. Use of the DELETE notification is strongly 657 recommended in cases where the peer implementation is continuing to 658 use the old SA. 660 2.2.2.3 Compatibility With Observed Behaviours 662 When operating with behaviours that use the new SA immediately, this 663 method performs equivalently when this method is used by the 664 responder. When used by the initiator, the performance will depend 665 on when the responder deletes the old inbound SA. 667 When operating with behaviours that continue to use the old SA, this 668 method performs as described in the dropped quick mode three example 669 above when used by the initiator. When used by the responder, there 670 is no change in operation, since the responder will wait until the 671 new SA is used before deleting the old SA. 673 However, as stated in a previous section, it is recommended that the 674 initiator keep the old SA (both inbound and outbound) for only 30 675 seconds after creation of the new SA in cases where traffic is not 676 detected on the new SA. 678 2.2.2.4 Compatibility with Commit Bit 680 If the commit bit is set by the responder with this proposal, some 681 of the problems described in Section 2.1.4 may occur. To reduce the 682 effects of these problems, following rules should be followed: 684 1) The initiator should set up its inbound SA immediately after 685 sending the third quick mode message regardless of the state of 686 the commit bit. 688 2) Sensing of traffic on the initiator's new inbound SA should 689 trigger the use of the new outbound SA to detect cases when the 690 CONNECTED notification is dropped. 692 The recommended proposal does not allow built-in support of the 693 commit bit. It does allow responders that use the commit bit to 694 detect reception of the CONNECTED notification by the initiator due 695 to the presence of traffic on its new inbound SA. However, this 696 works only if there is traffic, so it cannot be considered a useful 697 method to perform this function. 699 The recommended proposal does cause the initiator to delay usage of 700 a new SA until it is set up. This is the primary use of the commit 701 bit, so use of this proposal makes the use of the commit bit 702 unnecessary except for the setting up of the first phase 2 SA. 704 2.2.2.5 Implementation Notes 706 The presence of traffic on the new SA can be part of the expiration 707 checking operation, and does not need to occur instantaneously, 708 although it must occur before the 30 second no traffic SA deletion 709 criteria. As long as the new SA is negotiated with enough time 710 before the expiration of the old one, the detection of traffic on 711 the new SA can be on the order of seconds with no ill effects. 713 Since SAs will likely have traffic counters anyway, this method 714 requires only the addition of a flag that indicates it is a new SA. 715 When the expiration process checks for ageing and expired SAs, it 716 can also check for new SAs with a non-zero traffic count. When 717 detected, the SA is marked as non-new, and the remaining operations 718 can be performed. 720 2.3 Conclusions 722 The final re-keying method is the best compromise for 723 interoperability within the framework of the current IPSec documents 724 without compromising security. 726 3. Phase 1 Re-keying 728 This section makes a proposal for main mode re-keying. This proposal 729 is necessary for many of the same reasons a phase 2 re-keying 730 proposal is necessary. 732 1) The rules for phase 1 re-keying are not specified in the 733 drafts. 735 2) Adhoc implementations have lead to poor implementations and 736 possible interoperability issues. 738 The goal of the proposed phase 1 re-keying method is to provide 739 secure, lossless communications. This means that there should be no 740 dropped traffic during re-keying, but also that there should be no 741 further traffic if re-keying fails. 743 3.1 Phase 1 Re-keying Requirements 745 The two reasons for re-keying a phase 1 SA are for freshness (time 746 or traffic) of the phase 1 keying material (affecting its ability to 747 protect phase 2 negotiations) and for re-authentication of the 748 encrypting devices. 750 This implies that there is no inherent need to delete phase 2 SAs 751 created by an expired phase 1 SA as long as there is another phase 1 752 SA available to verify the authentication of the peers. 754 Therefore, in order to re-key phase 1 SAs, it is recommended that 755 peers negotiate a new phase 1 SA before the old phase 1 SA expires, 756 at some percentage of the SA's lifetime. 758 Note that this automatic re-keying of phase 1 SAs means that SAs 759 could live independent of traffic, since re-keying of both phase 1 760 and phase 2 SAs takes place with no traffic triggers (if they expire 761 by time). In other words, SAs that are no longer necessary may never 762 disappear. If an implementation waits until traffic starts using 763 pre-existing phase 2 SAs before re-keying a phase 1 SA, that traffic 764 could be allowed to pass unauthenticated for the time that it takes 765 to negotiate. The difference between this case and the case of 766 immediately renegotiating is that the traffic could be flowing at 767 some arbitrary time after the phase 1 SA has expired (but before the 768 phase 2 SA has expired) and outside the authenticated time, while in 769 the other case, re-authentication of the SAs effectively happens 770 near the end of their authenticated lifetime. 772 This suggests that a traffic monitoring capability should be part of 773 implementations that need to delete idle or unused SAs. As such, it 774 is not given further consideration, since it is beyond the scope of 775 this document. 777 The existence of the INITIAL-CONTACT notification determines whether 778 it should delete any phase 2 SAs it has with the peer. 780 Summarised, the rules for phase 1 re-keying are: 782 Initial Phase 1 SA Negotiation: 783 -initiator MUST use INITIAL-CONTACT notification 784 -responder may use INITIAL-CONTACT notification 785 -responder deletes any pre-existing phase 1 SA with the peer when 786 authentication of peer complete 787 -responder deletes all previously existing phase 2 SAs with the 788 peer, if any 790 Phase 1 SA Ages: 791 -end point that first detects this negotiates new phase 1 SA; 792 becomes new initiator 794 New Phase 1 SA Negotiation: 795 -initiator MUST NOT use INITIAL-CONTACT notification 796 -responder MUST detect that this is a re-key and MUST NOT use 797 INITIAL-CONTACT notification 798 -responder SHOULD mark its existing phase 1 SA as re-keyed, so as 799 to not re-key again 800 -since no INITIAL-CONTACT notification is used by either end; 801 phase 2 SAs are kept 803 Phase 1 SA Expiration: 804 -DELETE notification SHOULD be sent for phase 1 SA only 806 Note that any information that may be associated with pre-existing 807 phase 1 SAs should be carried over into the new SA. Examples of this 808 type of information are addresses passed using the Configuration 809 Exchange mode. 811 3.1.1 Multiple SA Usage 813 When there is more than one phase 1 SA between peers, it is 814 recommended that the oldest SA be used for subsequent traffic 815 requiring phase 1 SAs. This allows full use of the keying material 816 generated and reduces race conditions. It also means that no special 817 expiration conditions are required when the phase 1 SAs expire by 818 traffic only, as the old SA will eventually expire on its own due to 819 usage. 821 3.1.2 INITIAL-CONTACT Notification 823 As stated above, the INITIAL-CONTACT notification should be used 824 only on the very first phase 1 that is negotiated between two peers. 826 If used on subsequent negotiations, it means that all pre-existing 827 SAs (phase 1 and phase 2) held between the peers should be deleted. 829 As an example, this is the mechanism used to detect when an SA end 830 point has crashed and is now alive again. 832 3.1.3 DELETE Notification 834 As currently defined by the IPSec documents, this notification is an 835 advisory only and is optional and unacknowledged. 837 Given that it is optional, UDP based, and not used by some existing 838 implementations, it should never be considered necessary. 840 However, even though its use is of dubious value, it SHOULD be sent 841 when any SA (phase 1 or phase 2) is deleted, since the expiration of 842 SAs may not occur at the same time at both ends to increase the 843 probability that both ends are synchronised with respect to SA 844 usage. 846 3.1.4 Re-keying Timing 848 To reduce the probability of simultaneous re-keying, each device 849 should re-key at a variable time with respect to the SA's expiration 850 limit, in case they are the same. These recommendations apply to 851 both phase 1 and phase 2 SAs. 853 An example of this is that the end with the higher IP address re- 854 keys at 95% of the lifetime, while the end with lower IP address re- 855 keys at 85% of the lifetime. 857 Whatever rule is chosen, it is recommended that the rule be 858 deterministic in order to have predictable and consistent behaviour 859 between peers. If the rule had used the SPI as the determining 860 factor (as an example did in the first version of this document), 861 different peers would be doing the re-keying at different times. 863 In any case, simultaneous attempts at re-keying should be supported 864 in one form or another, since it can never be guaranteed that this 865 will not happen. 867 4. Next IPSec Version Recommendations 869 The recommendations made in sections 2 and 3 of this document have 870 limitations in their ability to provide lossless, reliable and 871 interoperable SA re-keying due to restrictions of existing 872 implementations and the existing IPSec documentation. 874 This section makes recommendations for explicit re-transmission 875 rules, phase 1 and phase 2 re-keying, and introduces a new mode for 876 reliable SA deletion in order to better provide reliable, lossless 877 and interoperable re-keying. 879 Also, a replacement for the commit bit is proposed. 881 4.1 Re-transmission Rules 883 In systems that use an even number of exchanges, the rules for re- 884 transmission are relatively obvious. Simply put, a packet is re-sent 885 if the expected response to it is not received within a certain 886 period of time. 888 However, IPSec has a number of modes that have an odd number of 889 packets. This can lead to confusion as to when the re-transmission 890 rules should be applied. This in turn can lead to the dropping of 891 aggressive and quick modes' third messages. It is recommended that 892 each of these modes have specific rules applied to them to avoid re- 893 transmission issues. 895 These rules will be applied based on request-response pairs. Packets 896 are defined as a request or a response in an exchange. The requestor 897 is responsible for re-sending the request in order to solicit the 898 response. The responder (not to be confused with an SA negotiation 899 responder) is responsible for re-sending the response as it receives 900 the initial and subsequent transmissions of the request. Note that 901 the responder must exist after transmitting a response in case that 902 response is dropped. 904 In the modes with an odd number of packets, the request-response 905 pair must be applied across the odd number of packets. This means 906 that at least one packet must be considered the response to the 907 previous packet, and must also be considered the request of the next 908 request-response pair. 910 This means that an implementation must be able to perform re- 911 transmission of packets after it normally would have considered 912 itself to be done with an exchange or a mode. Further, any timers 913 set by the transmission of the final message of an exchange should 914 be reset when re-transmission occurs. 916 4.1.1 Main Mode Re-Transmission Rules 918 In main mode, there are effectively three completely separate 919 exchanges. The first request-response pair contains the SA 920 proposals, the second pair contains the keying material, and the 921 third pair contains the authentication material. (These descriptions 922 are generalised for the purposes of stating what the exchanges are, 923 and are not intended to create discussion on the actual contents of 924 the exchanges.) 926 As an example of the separation of the exchanges, there is no need 927 to resend the second main message to solicit the third main mode 928 message, since the responder should not send the fourth main mode 929 message until receiving the third main mode message. The absence of 930 the fourth main mode message will cause the initiator to resend the 931 third main mode message. 933 Keeping the exchanges separate from a re-transmission point of view 934 should simplify implementations. 936 4.1.2 Aggressive Mode Re-Transmission Rules 938 In aggressive mode, the second message is the message that is both a 939 response and a request. Therefore, the responder in a phase 1 940 negotiation that uses aggressive mode must re-transmit the second 941 aggressive mode message to solicit a third aggressive mode message 942 that it perceives as lost. 944 4.1.3 Quick Mode Re-Transmission Rules 946 In quick mode, the second message is the message that is both a 947 response and a request. Therefore, the responder in a phase 1 948 negotiation must re-transmit the second quick mode message to 949 solicit a third quick mode message that it perceives as lost. 951 These rules must apply independently of the state of the commit bit, 952 since there are currently no timing restrictions on the transmission 953 of the CONNECTED notification. 955 4.2 SA Delete Mode 957 The purpose of the SA Delete mode is to unambiguously delete SAs 958 used as pairs for phase 2 SAs, or a single SA for a phase 1 SA. It 959 is called a mode for syntactical consistency with quick mode, new 960 group mode and so on. 962 This mode consists of two packets, a delete request and a delete 963 acknowledgement. 965 The delete request's format is the same as the DELETE notification, 966 and may or may not refer to multiple phase 2 SAs or a single phase 1 967 SA. It is interpreted to mean the following: 969 "I am not sending anymore traffic on this SA (or these SA pairs). 970 Would you please stop sending traffic on it (or them), and send me 971 an delete acknowledgement when you are done?" 973 The receiver of the delete request then switches his outbound 974 traffic to another SA (the next oldest), deletes both inbound and 975 outbound SAs and sends the delete acknowledgement. 977 This is interpreted to mean: 979 "I am also not sending anymore traffic on this SA (or these SA 980 pairs). You may delete it (or them)." 982 The receiver of the delete acknowledgement may then delete the 983 inbound SA. The outbound SA should have already been deleted or 984 somehow not used before the sending of the delete request. 986 Note that re-transmission rules apply to the request-acknowledge 987 pair. That is, if the initiator of the delete mode does not get the 988 delete acknowledgement, the delete request should be re-transmitted. 989 Similarly, if the responder of the delete request receives multiple 990 copies, multiple copies of the delete acknowledgement should be 991 sent. 993 If the retry counter for the delete request expires, the SAs 994 indicated in the request should be unilaterally deleted. 996 Both messages must be sent encrypted under the protection of a phase 997 1 SA. 999 Note that there is a race condition for the delete request and 1000 delete acknowledgement packets if an implementation sends them 1001 immediately after sending a packet on one of the SAs to be deleted. 1002 The race occurs if the packet order gets changed in the network and 1003 the delete mode packets arrive before packets sent on the SAs to 1004 which the deletes refer. 1006 The delete request-acknowledgement pair should also be applied to 1007 phase 1 SAs. In this case, the phase 1 SA is not completely torn 1008 down until the reception of the delete acknowledgement message. 1010 As a specific clarification, the binding between the inbound and the 1011 outbound phase 2 SAs is not weakened. In the messages used, the SA 1012 specified in the delete request is that of the sender's inbound SA. 1013 In other words, the SPI sent to be deleted is the SPI that was 1014 generated by the sender. This is simply to be consistent with the 1015 format of the current delete notification. It may be more reasonable 1016 to specify both inbound and outbound SPIs in the SA delete mode 1017 messages. 1019 When the delete mode is used to delete phase 1 SAs, the SPI values 1020 used are the cookies of the phase 1 SA to be deleted. 1022 The introduction of this mode does not eliminate the use for the 1023 existing DELETE notification. It could still be used if an 1024 implementation determines it needs to immediately (and impolitely) 1025 delete an SA. Implementations must still recognise that it is sent 1026 over UDP and may be dropped. 1028 4.3 Phase 1 Re-keying for IPSecond 1030 The phase 1 re-keying method described in Section 3 requires only 1031 one change for IPSecond. That is the required use of the new delete 1032 mode. 1034 The Delete mode must be used in association with phase 1 when an 1035 implementation intends to delete a phase 1 SA for any reason. 1037 4.4 Phase 2 Re-keying for IPSecond 1039 The phase 2 re-keying proposal described in Section 2, while 1040 necessary under the circumstances, is not the ideal method of re- 1041 keying. It forces the specific transfer times of SAs, thus making 1042 the intent of paragraph 2, section 9 of [IKE] impossible. 1044 This section describes proposals related to re-keying for the next 1045 version of the IPSec protocols. The purpose is to precisely define 1046 re-keying so that implementations are lossless and perfectly 1047 interoperable during re-keying. It also allows the spirit of 1048 paragraph 2, section 9 of [IKE] to be used. Further, it meets the 1049 requirements of paragraph 3 of section 4.3 of [ISAKMP]. 1051 A summary of the recommendations is: 1053 1) Define and require that the normal procedure is to use the 1054 oldest phase 2 SA first, and to use it until its natural 1055 expiration. 1057 2) Use the recommended re-transmission request rules for quick 1058 mode. 1060 3) Make use of the delete mode a requirement. 1062 4.4.1 Oldest Phase 2 SA First 1064 The concept of using the oldest phase 2 SA first for outbound 1065 traffic allows the maximum use of negotiated keys and allows for the 1066 pre-negotiation of an arbitrary number of phase 2 SAs to be made 1067 available for later use. 1069 Additionally, it decouples new phase 2 SA negotiation from old phase 1070 2 SA deletion, and the need to transfer to the new SA during re- 1071 keying. 1073 It also eliminates the race condition that occurs during SA set up 1074 during re-keying. This means that use of the commit bit to avoid the 1075 race condition is not necessary except when the very first phase 2 1076 SA is set up. 1078 The oldest SA is defined as the first negotiated of the available 1079 SAs. In cases of simultaneous and near simultaneous SA negotiation, 1080 the use of the delete mode and the ability to overlap SAs for an 1081 arbitrary period of time should make this condition manageable. 1083 4.4.2 Phase 2 Re-keying Illustration 1085 This section illustrates the events when re-keying occurs using the 1086 above proposals. Note the simplifications due to the decoupling of 1087 SA negotiation and old SA deletion. 1089 Initiator Responder 1091 Inbound Outbound Inbound Outbound 1092 | | | | 1093 1 ----------------- | | 1094 | | ------------ | | 1095 | | -------------------> 2 1096 | | | | | 1097 | | -------------------- 3 1098 | | ------------ | | 1099 4 <--------------- | | 1100 | | | | | 1101 5 ---------------- | | 1102 | *6 | ------------ | | 1103 | | | ------------------> 7 1104 | | | | | 1105 | | | | *8 | 1106 | | | | | | 1107 9 1108 | | | | | | 1109 | | *10 *10 | | | 1110 11 ----------------- | | | | 1111 | | ------------ | | | 1112 | | | -------------------> 12 1113 | | | | | | 1114 | | | | | *13 * 13 1115 | | | | | | 1116 | | | | | | 1117 | | | -------------------- 14 1118 | | ------------ *15| | 1119 16 <--------------- | | | 1120 | | | | | 1121 *17| | | | 1122 | | | | 1124 Figure 4-1 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1125 Initiator Expiration 1127 1) Initiator sends first quick mode message. 1129 2) Responder receives first quick mode message. 1131 3) Responder sends second quick mode message. 1133 4) Initiator receives second quick mode message. 1135 5) Initiator sends third quick mode message. 1137 6) Initiator sets up new inbound SA. Implementations may choose to 1138 set up the new outbound SA at this time, as long as they do not 1139 use it. 1141 7) Responder receives third quick mode message. 1143 8) Responder set up new inbound SA. Implementations may choose to 1144 set up the new outbound SA at this time, as long as they do not 1145 use it. 1147 9) Initiator's old SA pair expires. 1149 10) Initiator starts using new outbound SA and stops using old 1150 outbound SA. 1152 11) Initiator sends first SA delete mode message. 1154 12) Responder receives first SA delete mode message. 1156 13) Responder sets up new outbound SA. 1158 13) Responder deletes old outbound SA and starts using new outbound 1159 SA. 1161 14) Responder sends second SA delete mode message. 1163 15) Responder deletes old inbound SA. 1165 16) Initiator receives second SA delete mode message. 1167 17) Initiator deletes old inbound SA. 1169 If the responder's old SA expires first, the events are as follows. 1171 Initiator Responder 1173 Inbound Outbound Inbound Outbound 1174 | | | | | | 1175 9 1176 | | | | | | 1177 | | | | | *10 *10 1178 | | | | | | 1179 | | | -------------------< 11 1180 | | | ------------ | | | 1181 12 <--------------- | | | 1182 | | | | | | 1183 | | *13 *13 | | | 1184 | | | | | | 1185 | | | | | | 1186 | | | | | | 1187 14 >--------------- | | | | 1188 15 * | ------------ | | | 1189 | | -------------------> 16 1190 | | | | | 1191 | | 17 * | | 1192 | | | | 1194 Figure 4-2 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1195 Responder Expiration 1197 9) Responder's old SA pair expires. 1199 10) Responder starts using new outbound SA and stops using old 1200 outbound SA. 1202 11) Responder sends first SA delete mode message. 1204 12) Initiator receives first SA delete mode message. 1206 13) Initiator sets up new outbound SA. 1208 13) Initiator deletes old outbound SA and starts using new outbound 1209 SA. 1211 14) Initiator sends second SA delete mode message. 1213 15) Initiator deletes old inbound SA. 1215 16) Responder receives second SA delete mode message. 1217 17) Responder deletes old inbound SA. 1219 4.5 Commit Bit Replacement 1221 The intent of this section is to propose a mechanism to allow 1222 implementations to delay the usage of negotiated SAs. Its use may 1223 eliminate the need for the commit bit, and will not suffer from any 1224 of the problems of the commit bit. 1226 This is done by introducing a new mechanism to indicate to a peer 1227 that usage of a newly negotiated SA should be deferred. Then, 1228 depending on the deferral time intended, one of two mechanisms is 1229 introduced to indicate that the SA may be used. 1231 As this time, this proposal refers only to phase 2 SAs; however, 1232 there is no reason the same concepts could not be applied to phase 1 1233 SAs. 1235 These mechanisms are preferred over the commit bit for the following 1236 reasons: 1238 o They receive the full protection of phase 1 SAs, and as such 1239 provide the maximum resistance to denial of service attacks. 1241 o Their use is clearly and unambiguously defined. 1243 o They are resistant to the possibilities of dropped packets. 1245 4.5.1 DEFER_USAGE Notification 1247 The indication that an SA should not be made available for use 1248 immediately can be indicated by the addition of a new notify payload 1249 to the quick mode that negotiated the SA. To allow a single quick 1250 mode to negotiate multiple SAs, the DEFER_USAGE notification 1251 explicitly names the SA whose use is to be deferred, in the same 1252 manner as the current DELETE notification. 1254 The DEFER_USAGE notification payload should be added by the peer 1255 wishing to delay usage of an SA. 1257 On reception of the DEFER_USAGE notification, the newly negotiated 1258 SA should be set aside until reception of the allow usage mode, 1259 described in the next section, or the reception of the CONNECTED 1260 notification. 1262 The expected response depends on which type of DEFER_USAGE 1263 notification is sent. These types are termed long and short. A short 1264 DEFER_USAGE notification causes quick mode to become a for message 1265 mode, as with the intended use of the commit bit. A long DEFER_USAGE 1266 notification causes quick mode to proceed normally, with usage of 1267 the specified SA deferred until the sender of the DEFER_USAGE 1268 notification sends the first allow usage mode packet. 1270 Implementations should be prepared to received the long DEFER_USAGE 1271 notification for the same SA (pair) that they send it for; in other 1272 words, usage of the both SAs of the negotiated pairs may be deferred 1273 simultaneously by both peers. 1275 There are no time constraints associated with the sending of the 1276 long DEFER_USAGE notification and the subsequent reception of the 1277 allow usage mode. 1279 Usage of the short DEFER_USAGE notification is restricted to quick 1280 mode responders only. 1282 4.5.2 Allow Usage Mode 1284 Like the delete mode, this exchange is called a mode for syntactical 1285 consistency. 1287 The purpose of this mode is to indicate to a peer that an SA may now 1288 be used. Normally, usage of the SA by the peer would have been 1289 deferred by the use of the long DEFER_USAGE notify payload, 1290 described in the previous section. However, reception of this mode 1291 for an SA whose usage has not been deferred is not considered an 1292 error. 1294 This mode consists of two packets. The first packet is an 1295 ALLOW_USAGE notification. It specifies a previously negotiated SA 1296 that may be used, and is similar to the delete request packet in 1297 format. 1299 The response packet to this packet is the 1300 ALLOW_USAGE_ACKNOWLEDGEMENT notification. 1302 The initiator of the exchange re-transmits the ALLOW_USAGE 1303 notification until it receives the ALLOW_USAGE_ACKNOWLEDGEMENT 1304 notification or exceeds its re-try counter. 1306 The mode should always be sent under the protection of a phase 1 SA. 1308 4.5.3 CONNECTED Notification 1310 The intended use of the commit was to eliminate the race condition 1311 that occurs at the end of a quick mode. In this context, the allow 1312 usage mode adds more overhead than is necessary. Therefore, in this 1313 case, the response to the DEFER_USAGE may be the 1315 5. Acknowledgements 1317 Some of the concepts presented in this document are based on work 1318 done by TimeStep Corporation's engineering group. 1320 Others are taken from concepts discussed within the IPSec working 1321 group, particularly some of the concerns expressed about problems 1322 with the commit bit. 1324 6. References 1326 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1327 RFC2409, November 1998 1329 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1330 "Internet Security Association and Key Management Protocol 1331 (ISAKMP)", RFC2408, November 1998 1333 Revision History 1335 September 23, 1998 Initial Release 1337 April 7, 1999 -clarification of objectives of document 1338 -more commit bit comments 1339 -change phase 1 re-keying discussion to explicitly 1340 allow multiple phase 1 SAs between peers; previous 1341 version explicitly allowed only 1 phase 1 between 1342 peers 1343 -other miscellaneous changes 1345 Security Considerations 1347 This document is associated with the IPSec family of documents. As 1348 such, security considerations permeate the document. 1350 Author's Address 1352 Tim Jenkins 1353 tjenkins@timestep.com 1354 TimeStep Corporation 1355 362 Terry Fox Drive 1356 Kanata, ON 1357 Canada 1358 K2K 2P5 1359 +1 (613) 599-3610 1361 The IPSec working group can be contacted via the IPSec working 1362 group's mailing list (ipsec@tis.com) or through its chairs: 1364 Robert Moskowitz 1365 rgm@icsa.net 1366 International Computer Security Association 1368 Theodore Y. Ts'o 1369 tytso@MIT.EDU 1370 Massachusetts Institute of Technology 1372 This document expires October 14, 1999