idnits 2.17.1 draft-jenkins-ipsec-rekeying-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 72 lines 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 164: '... implementation SHOULD begin using th...' RFC 2119 keyword, line 165: '...ound traffic and SHOULD continue to su...' 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 (September 28, 1998) is 9341 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) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-isakmp-oakley is -07, but you're referring to -08. ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-isakmp is -09, but you're referring to -10. ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Tim Jenkins 3 IP Security Working Group TimeStep Corporation 4 Internet Draft September 28, 1998 6 IPSec Re-keying Issues 7 9 Status of this Memo 11 Informational 13 This memo provides information for the Internet community. This memo 14 does not specify an Internet standard of any kind. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 Copyright Notice 38 Copyright (C) Tim Jenkins (1998). All Rights Reserved. 40 Table of Contents 42 1. Introduction...................................................3 43 2. Phase 2 SA Re-keying...........................................3 44 2.1 Phase 2 Re-keying Issues......................................3 45 2.1.1 Inconsistent SA Use Recommendation..........................4 46 2.1.2 Observed Behaviours.........................................5 47 2.1.3 SA Set-up Race Condition....................................5 48 2.1.4 Commit Bit Interaction......................................7 49 2.2 Solution Examination..........................................7 50 2.2.1 Responder Pre-Set Up........................................7 51 2.2.1.1 Normal Conditions.........................................8 52 2.2.1.2 Dropped Packet Conditions................................10 53 2.2.1.3 Failed Negotiation.......................................11 54 2.2.1.4 Responder Pre-Set Up Security Hole.......................11 55 2.2.2 Recommended Re-keying Method...............................11 56 2.2.2.1 Dropped Quick Mode 3 Message.............................13 57 2.2.2.2 Absence of Traffic.......................................13 58 2.2.2.3 Compatibility With Observed Behaviours...................14 59 2.2.2.4 Compatibility with Commit Bit............................14 60 2.2.2.5 Implementation Notes.....................................16 61 2.3 Conclusions..................................................16 62 3. Phase 1 Re-keying.............................................16 63 3.1 Phase 1 Re-keying Requirements...............................16 64 3.1.1 Initial Contact Notification...............................18 65 3.1.2 Delete Notification........................................18 66 3.1.3 Re-keying Timing...........................................19 67 4. IPSecond Recommendations......................................19 68 4.1 Re-transmission Rules........................................20 69 4.1.1 Aggressive Mode Re-Transmission Rules......................20 70 4.1.2 Quick Mode Re-Transmission Rules...........................20 71 4.2 SA Delete Mode...............................................21 72 4.3 Phase 1 Re-keying for IPSecond...............................22 73 4.4 Phase 2 Re-keying for IPSecond...............................23 74 4.4.1 Oldest Phase 2 SA First....................................23 75 4.4.2 Phase 2 Re-keying Illustration.............................24 76 5. Acknowledgements..............................................27 77 6. References....................................................27 79 Revision History 81 September 23, 1998 Initial Release 83 1. Introduction 85 For a number of reasons, re-keying in IPSec has become problematic, 86 such that packets can get dropped by IPSec implementations during 87 re-keying. Worse, there exists the possibility that IPSec 88 implementations from different vendors may not be interoperable 89 because of the way they re-key. 91 The purpose of this paper is to propose methods of performing both 92 phase 1 and phase 2 re-keying for IPSec implementations in such a 93 way to to minimize packet loss and to maximize compatibility. 95 The initial focus in on phase 2 re-keying; it is then extended to 96 phase 1 re-keying. The need for this document in each case is 97 initially discussed, followed by a recommendation for re-keying 98 within the protocol framework established by version 1.0 of the 99 IPSec documents. 101 Finally, recommendations for IPSecond are made to best solve the re- 102 keying problems in a manner that is not possible within the 103 constraints of the existing IPSec documents. 105 2. Phase 2 SA Re-keying 107 This section discusses phase 2 re-keying issues and makes 108 recommendations to minimize the impact of these issues. 110 2.1 Phase 2 Re-keying Issues 112 The issues associated with phase 2 re-keying listed below. Some of 113 the points are expanded upon later. 115 1) There is no specification how re-keying is to be done. 117 2) The existing drafts appear contradictory in their 118 recommendations on the usage of multiple phase 2 SAs. 120 3) Some recent implementations have shipped with a method of re- 121 keying that will not perform reliably under real world network 122 conditions. 124 4) The use of the Delete notification is not required. 126 5) A variety of re-keying behaviours have been observed, some of 127 which are incompatible. 129 6) The commit bit is not yet widely implemented, and its use as 130 described is confusing. Further, while the documentation 131 requires its support, its use is not required. 133 7) A race condition exists at SA set up, exacerbating re-keying 134 issues. 136 2.1.1 Inconsistent SA Use Recommendation 138 The issue of inconsistent SA usage recommendations is examined 139 further here. 141 From paragraph 2 of Section 9 of [IKE]: 143 An implementation may wish to negotiate a range of SAs when 144 performing Quick Mode. By doing this they can speed up the "re- 145 keying". Quick Mode defines how KEYMAT is defined for a range of 146 SAs. When one peer feels it is time to change SAs they simply use 147 the next one within the stated range. A range of SAs can be 148 established by negotiating multiple Sas (identical attributes, 149 different SPIs) with one Quick Mode. 151 While the document does not define what "... the next one ..." 152 means, this paragraph strongly implies that there is no required 153 order for the use of phase 2 SAs that have been negotiated in a 154 phase 1 SA, or that multiple SAs may be pre-negotiated and used at 155 will. 157 However, this appears to be contradicted by paragraph 3 of section 158 4.3 of [ISAKMP]: 160 Modification of a Protocol SA (phase 2 negotiation) follows the 161 same procedure as creation of a Protocol SA. The creation of a new 162 SA is protected by the existing ISAKMP SA. There is no 163 relationship between the two Protocol SAs. A protocol 164 implementation SHOULD begin using the newly created SA for 165 outbound traffic and SHOULD continue to support incoming traffic 166 on the old SA until it is deleted or until traffic is received 167 under the protection of the newly created SA. As stated previously 168 in this section, deletion of an old SA is then dependent on local 169 security policy. 171 Many implementations have interpreted this to mean that the new SA 172 should be used for outbound in preference to the old SA. In other 173 words, the old SA should be abandoned as soon as possible. 175 2.1.2 Observed Behaviours 177 The following behaviours have been observed by various vendors' 178 implementations when devices have set up a second phase 2 SA. 180 1) The device continues to use the old SA until it naturally 181 expires, then switches to the new SA. 183 2) The device immediately begins using the new SA. 185 3) The device immediately drops the old SA. 187 4) The device never sends a Delete notification. 189 5) The device always sends a Delete notification. 191 6) The device deletes the old SA some time after re-keying, but 192 before the end of its natural lifetime. 194 7) A device wants to keep more than one SA up all the time. 196 All of these behaviours are permitted under the current documents. 197 However, even when phase 2 exchange packets are not lost, it can be 198 seen that interoperability is not always possible due the 199 combinations of behaviours listed above. 201 2.1.3 SA Set-up Race Condition 203 Further, behaviour 2 above is not a good behaviour, as illustrated 204 below. In this example, the initiator is a gateway capable of 205 handling full T3 bandwidth rates, while the responder is a PC 206 running a software IPSec implementation, and it is overloaded. 208 In the illustration, QM1 refers to the first quick mode message, QM2 209 to the second quick mode message and QM3 to the third. 211 Initiator Responder 213 QM1 sent ---- 214 ------- 215 ------------- 216 ---------------> QM1 received 217 | 218 | 219 | QM1 processed 220 | 221 | 222 ---------------- QM2 sent 223 ------------- 224 ------- 225 QM2 rec. <---- 226 process | 227 QM3 sent ----- 228 * ------- 229 packet on new SA ------------- 230 _____ ---------------> QM3 received 231 _______ | 232 _____________ | QM3 processing 233 _______________| 234 | packet dropped 235 | 236 * new SA set up 238 Figure 2-1 Race Condition Sequence Chart 240 By the time the responder has set up the new SA, packets protected 241 by that SA have already started arriving from the initiator. This 242 causes them to be dropped by the responder. This case is further 243 complicated by the possibility of packets taking different paths 244 through the network, so theoretically, the third quick mode message 245 could arrive after packets protected by the new SA. 247 Additionally, since all IKE packets are based on UDP, there is no 248 guarantee that QM3 even arrives at the peer, so making assumptions 249 about new SA use based on the transmission time of a packet will 250 still lead to failures in the field. 252 To reduce the effects of packet loss, some implementations were 253 observed to blindly transmit QM3 multiple times, back to back. 255 This can reduce the probability that the peer does not get QM3, but 256 cannot eliminate it. 258 If the behaviour of the initiator was to delay usage of the new SA 259 for outbound traffic, this would cause failures for those 260 implementations that immediately delete the old SA. Therefore, the 261 behaviour of delaying use of the new SA and immediately deleting the 262 old SA are incompatible. 264 2.1.4 Commit Bit Interaction 266 The use of the commit bit can solve the race condition illustrated 267 in the previous section when asserted by the responder during quick 268 mode. However, it suffers from the following problems: 270 1) Use of the commit bit is not well defined. The present 271 documentation specifies its used for phase 1 and phase 2, but 272 mentions phase 2 specific details. There are also issues 273 related to how the subsequent Connected notification fits in 274 with the quick mode exchange. 276 2) While its support is required, its use is not. Current 277 indications are that its use is not widespread. 279 3) Its use may make implementations susceptible to a denial of 280 service attack by forcing initiators to wait for a Connected 281 notification that may never come. While this is only one of 282 many very basic possible denial of service attacks on IKE, this 283 is not an excuse to leave the existing implementation as it is. 285 2.2 Solution Examination 287 This section details the operation of some possible behaviours, with 288 the intent of arriving at a best possible phase 2 re-keying 289 mechanism under the constraints of the existing documents. 291 In all the examples, the term "sets up a new outbound SA" means that 292 the new outbound SA will be chosen in favour of the old one. Whether 293 the SA is actually created before that time or not is implementation 294 dependent. 296 2.2.1 Responder Pre-Set Up 298 As a starting point, the responder pre-set up method of re-keying is 299 examined. Note that it will work with most of the behaviours 300 observed in the field. 302 In this method, SAs are treated separately as inbound and outbound, 303 as well as old and new. Further, it takes advantage of the fact that 304 the responder knows what the SA is going to be after the second 305 quick mode message is sent. 307 Implicit acknowledgement of the reception of the third quick mode 308 message by the responder is provided by use of the new SA in the 309 outbound direction. The initiator should not use the new outbound SA 310 before that time. 312 Additionally, it does not require use of the Delete notification. 313 This is important since, even if it is always sent, it is an 314 unacknowledged UDP packet and can be lost. 316 2.2.1.1 Normal Conditions 318 The following is the operation under normal (successful) conditions. 320 Initiator Responder 322 Inbound Outbound Inbound Outbound 323 | | | | 324 1 ----------------- | | 325 | | ------------ | | 326 | | -------------------> 2 327 | | | | | 328 | | -------------------- 3 329 | | ------------ | *4 | 330 5 <--------------- | | | 331 | | | | | | 332 6 ---------------- | | | 333 | *7 | ------------ | | | 334 | | | -------------------> 8 335 | | | | | | | 336 | | | | | | * 337 | | | | | | *9 338 | | | | | *10 | 339 | | | | | | 340 | *11 | | | | 341 | | | *12 | | | 342 | | *13 | | | | 343 *14| | | | | 344 | | | *15 | 345 | | *16| | 346 | | | | 348 Figure 2-2 SA Pre-Set Up Sequence Chart 350 Events 352 1) Initiator sends first quick mode message. 354 2) Responder receives first quick mode message. 356 3) Responder sends second quick mode message. 358 4) Responder sets up new inbound SA. This is to handle the case 359 where the initiator starts transmitting on the new SA 360 immediately after sending the third quick mode message. 362 5) Initiator receives second quick mode message. 364 6) Initiator sends third quick mode message. 366 7) Initiator sets up new inbound SA. 368 8) Responder receives third quick mode message. 370 9) Responder sets up new outbound SA. 372 10) Responder deletes old outbound SA. 374 11) Traffic from responder to initiator arrives at initiator on new 375 SA. 377 12) Initiator sets up new outbound SA. 379 13) Initiator deletes old outbound SA. 381 14) Initiator deletes old inbound SA. 383 15) Traffic from initiator to responder arrives at responder on new 384 SA. 386 16) Responder deletes old inbound SA. 388 While appearing complicated, it enables the lossless transfer from 389 one SA to another while supporting almost all other behaviours. 391 Support for and use of the Delete notification is unchanged. 393 2.2.1.2 Dropped Packet Conditions 395 In this case, the event list is modified to show what happens when 396 each packet is dropped once. The event numbers refer to those 397 illustrated in Figure 2. 399 1) Initiator sends first quick mode message. 401 e) Packet is dropped during transmission. 403 1b) Initiator times out waiting for second quick mode message. 405 1) Initiator re-sends first quick mode message. 407 2) Responder receives first quick mode message. 409 3) Responder sends second quick mode message. 411 4) Responder sets up new inbound SA. This is to handle the case 412 where the initiator starts transmitting on the new SA 413 immediately after sending the third quick mode message. 415 e) Packet is dropped during transmission. 417 1b) or 7b) Responder times out waiting for third quick mode 418 message. 420 1) or 3) Responder re-sends second quick mode message. 422 5) Initiator receives second quick mode message. 424 6) Initiator sends third quick mode message. 426 7) Initiator sets up new inbound SA. 428 e) Packet is dropped during transmission. 430 7b) Responder times out waiting for third quick mode message. 432 3) Responder re-sends second quick mode message. 434 5) Initiator receives second quick mode message again. 436 6) Initiator re-sends third quick mode message. 438 8) Responder receives third quick mode message. 440 and so on, as for normal operation. 442 2.2.1.3 Failed Negotiation 444 In this case, the second quick mode packet has an invalid hash, and 445 the initiator sends the notification to the peer. Again, the event 446 numbers refer to those illustrated in Figure 2. 448 1) Initiator sends first quick mode message. 450 2) Responder receives first quick mode message. 452 3) Responder sends second quick mode message. 454 4) Responder sets up new inbound SA. This is to handle the case 455 where the initiator starts transmitting on the new SA 456 immediately after sending the third quick mode message. 458 5) Initiator receives second quick mode message. 460 e) Hash (or other parameter) fails. 462 e1) Initiator sends notification to responder. 464 e2) Responder receives notification. 466 e3) Responder deletes new inbound SA. 468 A similar operation would occur if retry counters expire for packet 469 re-transmissions. 471 2.2.1.4 Responder Pre-Set Up Security Hole 473 In the failed negotiation case, the need to delete the invalid 474 inbound SA raises the issue of a temporary hole, in that the 475 responder allows inbound packets while waiting for the third quick 476 mode message. However, if the inbound SA is not set up ahead of 477 time, initiators that immediately transmit on the new outbound SA 478 will cause packets to be dropped. 480 It also illustrates why the proposal above made the usage of the 481 outbound SA by the initiator wait until there is an indication of 482 the use of the SA by the responder. 484 2.2.2 Recommended Re-keying Method 486 In this method, the previous method is modified to remove the risk 487 of the security hole. It also simplifies the operation somewhat, but 488 at the expense of lost packets if the initiator's behaviour is such 489 that it immediately uses the new SA for its outbound traffic. 491 Initiator Responder 493 Inbound Outbound Inbound Outbound 494 | | | | 495 1 ----------------- | | 496 | | ------------ | | 497 | | -------------------> 2 498 | | | | | 499 | | -------------------- 3 500 | | ------------ | | 501 4 <--------------- | | 502 | | | | | 503 5 ---------- | | | 504 | *6 ------------------ | | 505 | | | -------------------> 7 506 | | | | | | 507 | | | | | * 508 | | | | *8 | 509 | | | | | | *9 510 | | | | | *10 | 511 | | | | | | 512 | *11 | | | | 513 | | | *12 | | | 514 | | *13 | | | | 515 *14| | | | | 516 | | | *15 | 517 | | *16| | 518 | | | | 520 Figure 2-3 Recommended Phase 2 Re-key Sequence Chart 522 1) Initiator sends first quick mode message. 524 2) Responder receives first quick mode message. 526 3) Responder sends second quick mode message. 528 4) Initiator receives second quick mode message. 530 5) Initiator sends third quick mode message. 532 6) Initiator sets up new inbound SA. 534 7) Responder receives third quick mode message. 536 8) Responder set up new inbound SA. 538 9) Responder sets up new outbound SA. 540 10) Responder deletes old outbound SA. 542 11) Traffic from responder to initiator arrives at initiator on new 543 SA. 545 12) Initiator sets up new outbound SA. 547 13) Initiator deletes old outbound SA. 549 14) Initiator deletes old inbound SA. 551 15) Traffic from initiator to responder arrives at responder on new 552 SA. 554 16) Responder deletes old inbound SA. 556 Note that deletion of the old inbound SA by the initiator could be 557 further delayed if protection against loss of packets on the old SA 558 from different and slower network paths is desired. 560 2.2.2.1 Dropped Quick Mode 3 Message 562 In cases where the third quick mode message is dropped, the 563 responder must request re-transmission of it by re-sending the 564 second quick mode message. The existence of traffic on the new 565 inbound SA at the initiator should not be used as an implicit 566 acknowledgement for the following reasons: 568 1) There may be no traffic for the responder to send. 570 2) The responder may be implemented to use the old SA until its 571 natural expiration. 573 2.2.2.2 Absence of Traffic 575 The proposed implementation uses the presence of traffic from the 576 responder on new SAs to provide an implied acknowledgement for the 577 purposes of switching to the new SA. However, if there is no traffic 578 from the responder, the implied acknowledgement will not appear. 580 A similar behaviour is exhibited by implementations that continue to 581 use old SAs until their natural expiration. 583 However, due to the number of implementations that delete old SAs 30 584 seconds after negotiating a new one, the same behaviour has the best 585 chance of interoperability, and of not dropping packets when traffic 586 does restart. 588 Therefore, it is recommended that implementations delete old SAs and 589 start using new SAs 30 seconds after negotiating new SAs. Use of the 590 Delete notification is strongly recommended in cases where the peer 591 implementation is continuing to use the old SA. 593 2.2.2.3 Compatibility With Observed Behaviours 595 When operating with behaviours that use the new SA immediately, this 596 method performs equivalently when this method is used by the 597 responder. When used by the initiator, the performance will depend 598 on when the responder deletes the old inbound SA. 600 When operating with behaviours that continue to use the old SA, this 601 method performs as described in the dropped quick mode three example 602 above when used by the initiator. When used by the responder, there 603 is no change in operation, since the responder will wait until the 604 new SA is used before deleting the old SA. 606 However, as stated in a previous section, it is recommended that the 607 initiator keep the old SA (both inbound and outbound) for only 30 608 seconds after creation of the new SA in cases where traffic is not 609 detected on the new SA. 611 2.2.2.4 Compatibility with Commit Bit 613 As stated earlier, use of the commit bit as described in the drafts 614 is confusing. 616 For the purposes of this document, its use is interpreted to mean 617 the following: 619 "I have set the commit bit. Do not use the SA created by this 620 negotiation until I send you the Connected notification." 622 In other words, the purpose of the commit is to delay a peer's usage 623 of its outbound SA until it has received the Connected notification. 625 While sounding simple, this suffers from some of the same problems 626 as the negotiation without the commit bit. When used as part of a 627 quick mode negotiation, the effect is that the Connected 628 notification is now similar to the third quick mode message with the 629 roles of the initiator and responder reversed (or not reversed if 630 set by the initiator). 632 Specifically, the Connected notification can still be dropped. This 633 will result in the intended receiver of the Connected notification 634 never sending on the new SA. Also, if the intended receiver of the 635 Connected notification does not set up the new SA until receiving 636 the Connected notification, the same race condition exists if the 637 sender of the notification starts using the new outbound SA 638 immediately after sending the notification. 640 This problem is further exacerbated by the lack of tight integration 641 of the Connected notification with quick mode. In other words, it 642 may not be possible to request re-transmission of the Connected 643 notification by re-sending the third quick mode message. 645 The impact of these effects can be eliminated by the following 646 rules: 648 1) The initiator should set up its inbound SA immediately after 649 sending the third quick mode message regardless of the state of 650 the commit bit. 652 2) Traffic sense on the initiator's new inbound SA should trigger 653 the use of the new outbound SA to detect cases when the 654 Connected notification is dropped. 656 The recommended proposal does not allow built-in support of the 657 commit bit. It does allow responders that use the commit bit to 658 detect reception of the Connected notification by the initiator due 659 to the presence of traffic on the inbound SA. However, this works 660 only if there is traffic, so it cannot be considered a usefull 661 method to perform this function. 663 The recommended proposal does cause the initiator to delay usage of 664 a new SA until it is set up. This is the primary use of the commit 665 bit, so use of this proposal makes the use of the commit bit 666 unnecessary except for the setting up of the first phase 2 SA. 668 However, other uses of the commit bit or its equivalent function may 669 appear, such as delaying of SA use in key recovery implementations. 670 In these cases, the re-keying method proposed here does not 671 interfere with commit bit usage. 673 2.2.2.5 Implementation Notes 675 The presence of traffic on the new SA can be part of the expiration 676 checking operation, and does not need to occur instantaneously, 677 although it must occur before the 30 second no traffic SA deletion 678 criteria. As long as the new SA is negotiated with enough time 679 before the expiration of the old one, the detection of traffic on 680 the new SA can be on the order of seconds with no ill effects. 682 Since SAs will likely have traffic counters anyway, this method 683 requires only the addition of a flag that indicates it is a new SA. 684 When the expiration process checks for aging and expired SAs, it can 685 also check for new SAs with a non-zero traffic count. When detected, 686 the SA is marked as non-new, and the remaining operations can be 687 performed. 689 2.3 Conclusions 691 The final re-keying method is the best compromise between security 692 and interoperability within the framework of the current IPSec 693 documents. 695 3. Phase 1 Re-keying 697 This section makes a proposal for main mode re-keying. This proposal 698 is necessary for many of the same reasons a phase 2 re-keying 699 proposal is necessary. 701 1) The rules for phase 1 re-keying are not specified in the 702 drafts. 704 2) Adhoc implementations have lead to poor implementations and 705 possible interoperability issues. 707 The goal of the proposed phase 1 re-keying method is to provide 708 secure, lossless communications. This means that there should be no 709 dropped traffic during re-keying, but also that there should be no 710 further traffic if re-keying fails. 712 3.1 Phase 1 Re-keying Requirements 714 The two reasons for re-keying a phase 1 SA are for freshness (time 715 or traffic) of the phase 1 keying material (affecting its ability to 716 protect phase 2 negotiations) and for re-authentication of the 717 encrypting devices. 719 This implies that there is no inherent need to delete other SAs 720 created by an expired phase 1 SA as long as an immediate attempt to 721 create a new phase 1 SA is made to verify authentication. If this 722 fails, then the SAs created within previous phase 1 SAs must be 723 deleted. This provides the authentication protection of the original 724 phase 1 SA. Note that this does not preclude any requirements for 725 early termination of SAs due to certificate revocation, for example. 727 However, the automatic re-keying of phase 1 SAs means that SAs could 728 live independent of traffic, since re-keying of both phase 1 and 729 phase 2 SAs takes place with no traffic triggers. In other words, 730 SAs that are no longer necessary may never disappear. If an 731 implementation waits until traffic starts using pre-existing phase 2 732 SAs before re-keying a phase 1 SA, that traffic could be allowed to 733 pass unauthenticated for the time that it takes to negotiate. The 734 difference between this case and the case of immediately 735 renegotiating is that the traffic could be flowing at some arbitrary 736 time after the phase 1 SA has expired (but before the phase 2 SA has 737 expired) and outside the authenticated time, while in the other 738 case, re-authentication of the SAs effectively happens at the end of 739 their authenticated lifetime. 741 This suggests that a traffic monitoring capability should be part of 742 implementations that need to delete idle or unused SAs. As such, it 743 is not given further consideration in this document, since it is 744 beyond the scope of this document. 746 A further implication of not deleting the phase 2 SAs is that there 747 is no need to overlap phase 1 SAs. That is, the second phase 1 SA 748 can be negotiated after the first phase 1 SA expires with no loss of 749 traffic since the phase 2 SA is still in place. 751 (There may be issues of simultaneous expiration of phase 1 and phase 752 2 SAs. Implementations should be able to handle this condition, 753 although some traffic loss may be unavoidable under this condition.) 755 Since the expiration times of the phase 1 SA at each end may not be 756 the same, any device that gets a phase 1 negotiation should abandon 757 the phase 1 SA that it already has with the peer, once the new SA 758 has been authenticated. The authenticated ID information is 759 necessary to determine if the new phase 1 SA is identical to an 760 existing phase 1 SA. 762 The existence of the Initial Contact notification determines whether 763 it should delete any phase 2 SAs it has with the peer. 765 Therefore, the rules for phase 1 re-keying are: 767 Initial Phase 1 Negotiation: 768 -responder deletes any pre-existing phase 1 SA with the peer when 769 authentication of peer complete 770 -initiator uses Initial Contact notification 771 -responder may also use Initial Contact notification 772 -responder deletes all phase 2 SAs with the peer 774 Phase 1 Expiration: 775 -Delete notification may be sent only if permanent deletion of 776 the phase 1 SA (and all its phase 2 SAs) is intended 778 New Phase 1 Negotiation: 779 -responder deletes any pre-existing phase 1 SA with the peer when 780 authentication of peer complete 781 -no Initial Contact notification; phase 2 SAs are kept 782 -if attempt fails, all other SAs are also deleted (no Delete 783 notification is used, since there is no valid SA) 784 -initiator should sent delete notification 786 Maximum of one Phase 1 SA between peers (except during SA set-up) 788 Note that any information that may be associated with pre-existing 789 phase 1 SAs should be carried over into the new SA. Examples of this 790 type of information are server addresses passed during using the 791 Configuration Exchange mode. 793 3.1.1 Initial Contact Notification 795 As stated above, the initial contact notification should be used 796 only on the very first phase 1 that is negotiated between two peers. 798 If used on subsequent negotiations, it means that all pre-existing 799 SAs (phase 1 and phase 2) held between the peers should be deleted. 801 This is the mechanism used to detect when an SA end point has 802 crashed and is now alive again, for example. 804 3.1.2 Delete Notification 806 As currently defined by the IPSec documents, this notification is an 807 advisory only and is optional and unacknowledged. 809 Given that it is optional, UDP based, and not used by some existing 810 implementations, it should never be considered necessary. Further, 811 its value is debatable, especially given that explicit SA re-keying 812 rules are being used. 814 Further, reception of a Delete notification for phase 1 should not 815 be used before re-keying, since the phase 1 SA is being re-keyed, 816 not deleted. It should be used only to indicate permanent deletion 817 of a phase 1 SA and all phase 2 SAs created by it. 819 Even though its use is of dubious value, it should be sent when 820 permanent deletion of phase 1 SAs is intended, if only as a place- 821 holder for the proposed Delete mode for IPSecond. 823 3.1.3 Re-keying Timing 825 To reduce the probability of simultaneous re-keying, each device 826 should re-key at a variable time with respect to the SA's expiration 827 time, in case they are the same. These recommendations apply to both 828 phase 1 and phase 2 SAs. 830 Examples of this include: 832 1) Re-keying at a random percentage of the lifetime of the SA, 833 such as 75% to 90%. 835 2) The end with the higher SPI re-keying at 95% of the lifetime, 836 while the end with lower SPI re-keying at 85% of the lifetime. 838 In any case, simultaneous attempts at re-keying should be supported 839 in one form or another, since it can never be guaranteed that this 840 will not happen. 842 4. IPSecond Recommendations 844 The recommendations made in sections 2 and 3 of this document have 845 limitations in their ability to provide lossless, reliable and 846 interoperable SA re-keying due to restrictions of existing 847 implementations and the existing IPSec documentation. 849 This section makes recommendations for explicit re-transmission 850 rules, phase 1 and phase 2 re-keying and introduces a new mode for 851 reliable SA deletion in order to better provide reliable, lossless 852 and interoperable re-keying. 854 4.1 Re-transmission Rules 856 In systems that use an even number of exchanges, the rules for re- 857 transmission are relatively obvious. Simply put, a packet is re-sent 858 if the expected response to it is not received within a certain 859 period of time. 861 However, IPSec has a number of modes that have an odd number of 862 packets. This can lead to confusion as to when the re-transmission 863 rules should be applied. This in turn can lead to the dropping of 864 aggressive and quick modes' third messages. It is recommended that 865 each of these modes have specific rules applied to them to avoid 866 issues these issues. 868 These rules will be applied based on request-response pairs. Packets 869 are defined as a request or a response in an exchange. The requestor 870 is responsible for re-sending the request in order to solicit the 871 response. The responder (not to be confused with an SA negotiation 872 responder) is responsible for re-sending the response as it receives 873 the initial and subsequent transmissions of the request. 875 In each of the cases of modes with an odd number of packets, the 876 request-response pair must be applied across the odd number of 877 packets. This means that at least one packet must be considered the 878 response to the previous packet, and must also be considered the 879 request of the next request-response pair. 881 This means that an implementation must be able to perform re- 882 transmission of packets after it normally would have considered 883 itself to be done with an exchange or a mode. Further, any timers 884 set by the transmission of the final message of an exchange should 885 be reset when re-transmission occurs. 887 4.1.1 Aggressive Mode Re-Transmission Rules 889 In aggressive mode, the second message is the message that is both a 890 response and a request. Therefore, the responder in a phase 1 891 negotiation that uses aggressive mode must re-transmit the second 892 aggressive mode message to solicit a third aggressive mode message 893 that it perceives as lost. 895 4.1.2 Quick Mode Re-Transmission Rules 897 In quick mode, the second message is the message that is both a 898 response and a request. Therefore, the responder in a phase 1 899 negotiation must re-transmit the second quick mode message to 900 solicit a third quick mode message that it perceives as lost. 902 4.2 SA Delete Mode 904 The purpose of the SA Delete mode is to unambiguously delete SAs 905 used as pairs. It is called a mode for syntactical consistency with 906 quick mode, new group mode and so on. 908 The Delete request notification's format is the same as the Delete 909 notification, and may or may not refer to multiple SAs. It is 910 interpreted to mean the following: 912 "I am not sending anymore traffic on this SA pair (or these SA 913 pairs). Would you please stop sending traffic on it (or them), and 914 send me an Delete acknowledgement when you are done?" 916 The receiver of the Delete request then switches his outbound 917 traffic to another SA (the next oldest), deletes both inbound and 918 outbound SAs and sends the Delete acknowledgement. 920 This is interpreted to mean: 922 "I am also not sending anymore traffic on this SA pair (or these 923 SA pairs). You may delete it (or them)." 925 The receiver of the Delete acknowledgement may then delete the 926 inbound SA. The outbound SA should have already been deleted or 927 somehow not used before the sending of the Delete request. 929 Note that re-transmission rules apply to the request-acknowledge 930 pair. That is, if the initiator of the Delete mode does not get the 931 Delete acknowledgement, the Delete request should be re-transmitted. 932 Similarly, if the responder of the Delete request receives multiple 933 copies, multiple copies of the Delete acknowledgement should be 934 sent. 936 If the retry counter for the Delete request expires, the SAs 937 indicated in the request should be unilaterally deleted. 939 Both messages must be sent encrypted under the protection of a phase 940 1 SA. 942 Note that there is a race condition for the Delete request and 943 Delete acknowledgement notifications if an implementation sends them 944 immediately after sending a packet on one of the SAs to be deleted. 945 The race occurs if the packet order gets changed in the network and 946 the notification packets arrive before packets sent on the SAs to 947 which the notifications refer. 949 The Delete request-acknowledgement pair should also be applied to 950 phase 1 SAs. In this case, the phase 1 SA is not completely torn 951 down until the reception of the Delete acknowledgement message. 953 As a specific clarification, the binding between the inbound and the 954 outbound SAs is not weakened. In the messages used, the SA specified 955 in the Delete notification is that of the sender's inbound SA. In 956 other words, the SPI sent to be deleted is the SPI that was 957 generated by the sender. This is simply to be consistent with the 958 format of the current Delete notification. It may be more reasonable 959 to specify both inbound and outbound SPIs in the SA Delete mode 960 messages. 962 Additionally, the Delete mode is used to delete phase 1 SAs as well. 963 In this case, the SPIs values used are the cookies of the phase 1 964 SA. 966 The introduction of this mode does not eliminate the use for the 967 existing Delete notification. It could still be used if an 968 implementation determines it needs to immediately (and impolitely) 969 delete an SA. Implementations must still recognise that it is sent 970 over UDP and may be dropped. 972 4.3 Phase 1 Re-keying for IPSecond 974 The phase 1 re-keying method described in Section 3 requires only 975 one change for IPSecond. That is the required use of the new Delete 976 mode. 978 The Delete mode must be used in association with phase 1 when an 979 implementation intends to permanently delete a phase 1 SA. This may 980 happen due to adminstration shut-down, policy change, remote client 981 session termination, re-keying failure or other reasons. 983 When used after a phase 1 re-keying failure, it is sent by the 984 initiator of the phase 1 negotiation. In this case, the Delete mode 985 uses the cookies of the expired phase 1 SA, rather than the cookies 986 of the SA negotiation that failed. It must also use the old phase 1 987 SA to protect the Delete mode. 989 The reasons for this are that the responder's phase 1 may not have 990 expired. The failure of the new phase 1 negotiation cannot be used 991 by the responder to delete its old phase 1 SA since it is likely 992 that authentication of the new phase 1 SA has not yet occurred. 994 Because of this, there is a logical overlap of phase 1 SAs that 995 implicitly ends upon successful negotiation of the new phase 1 SA. 997 4.4 Phase 2 Re-keying for IPSecond 999 The phase 2 re-keying proposal described in Section 2, while 1000 necessary under the circumstances, is not the ideal method of re- 1001 keying. It forces the specific transfer times of SAs, thus making 1002 the intent of paragraph 2, section 9 of [IKE] impossible. 1004 This section describes proposals related to re-keying for the next 1005 version of the IPSec protocols. The purpose is to precisely define 1006 re-keying so that implementations are lossless and perfectly 1007 interoperable during re-keying. It also allows the spirit of 1008 paragraph 2, section 9 of [IKE] to be used. Further, it meets the 1009 requirements of paragraph 3 of section 4.3 of [ISAKMP]. 1011 A summary of the recommendations is: 1013 1) Define and require that the normal procedure is to use the 1014 oldest phase 2 SA first, and to use it until its natural 1015 expiration. 1017 2) Use the recommended re-transmission request rules for quick 1018 mode. 1020 3) Make use of the Delete mode a requirement. 1022 4.4.1 Oldest Phase 2 SA First 1024 The concept of using the oldest phase 2 SA first for outbound 1025 traffic allows the maximum use of negotiated keys and allows for the 1026 pre-negotiation of an arbitrary number of phase 2 SAs to be made 1027 available for later use. 1029 The oldest SA is also defined as the first negotiated of the 1030 available SAs. 1032 Additionally, it decouples new phase 2 SA negotiation from old phase 1033 2 SA deletion, and the need to transfer to the new when the old SA 1034 is deleted. 1036 It also eliminates the race condition that occurs during SA set up 1037 during re-keying. This means that use of the commit bit to avoid the 1038 race condition is not necessary except when the very first phase 2 1039 SA is set up. 1041 4.4.2 Phase 2 Re-keying Illustration 1043 This section illustrates the events when re-keying occurs using the 1044 above proposals. Note the simplifications due to the decoupling of 1045 SA negotiation and old SA deletion. 1047 Initiator Responder 1049 Inbound Outbound Inbound Outbound 1050 | | | | 1051 1 ----------------- | | 1052 | | ------------ | | 1053 | | -------------------> 2 1054 | | | | | 1055 | | -------------------- 3 1056 | | ------------ | | 1057 4 <--------------- | | 1058 | | | | | 1059 5 ---------------- | | 1060 | *6 | ------------ | | 1061 | | | ------------------> 7 1062 | | | | | 1063 | | | | *8 | 1064 | | | | | | 1065 9 1066 | | | | | | 1067 | | *10 *10 | | | 1068 11 ----------------- | | | | 1069 | | ------------ | | | 1070 | | | -------------------> 12 1071 | | | | | | 1072 | | | | | *13 * 13 1073 | | | 14 * | | 1074 | | | | | 1075 | | | -------------------- 15 1076 | | ------------ | | 1077 16 <--------------- | | | 1078 | | | | | 1079 *17| | | | 1080 | | | | 1082 Figure 4-1 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1083 Initiator Expiration 1085 1) Initiator sends first quick mode message. 1087 2) Responder receives first quick mode message. 1089 3) Responder sends second quick mode message. 1091 4) Initiator receives second quick mode message. 1093 5) Initiator sends third quick mode message. 1095 6) Initiator sets up new inbound SA. Implementations may choose to 1096 set up the new outbound SA at this time, as long as they do not 1097 use it. 1099 7) Responder receives third quick mode message. 1101 8) Responder set up new inbound SA. Implementations may choose to 1102 set up the new outbound SA at this time, as long as they do not 1103 use it. 1105 9) Initiator's old SA pair expires. 1107 10) Initiator starts using new outbound SA and stops using old 1108 outbound SA. 1110 11) Initiator sends first SA Delete mode message. 1112 12) Responder receives first SA Delete mode message. 1114 13) Responder sets up new outbound SA. 1116 13) Responder deletes old outbound SA and starts using new outbound 1117 SA. 1119 14) Responder deletes old inbound SA. 1121 15) Responder sends second SA Delete mode message. 1123 16) Initiator receives second SA Delete mode message. 1125 17) Initiator deletes old inbound SA. 1127 If the responder's old SA expires first, the events are as follows. 1129 Initiator Responder 1131 Inbound Outbound Inbound Outbound 1132 | | | | | | 1133 9 1134 | | | | | | 1135 | | | | | *10 *10 1136 | | | | | | 1137 | | | -------------------< 11 1138 | | | ------------ | | | 1139 12 <--------------- | | | 1140 | | | | | | 1141 | | *13 *13 | | | 1142 | | | | | | 1143 14 * | | | | | 1144 | | | | | 1145 15 >--------------- | | | | 1146 | ------------ | | | 1147 | | -------------------> 16 1148 | | | | | 1149 | | 17 * | | 1150 | | | | 1152 Figure 4-2 Recommended IPSecond Phase 2 Re-key Sequence Chart, 1153 Responder Expiration 1155 9) Responder's old SA pair expires. 1157 10) Responder starts using new outbound SA and stops using old 1158 outbound SA. 1160 11) Responder sends first SA Delete mode message. 1162 12) Initiator receives first SA Delete mode message. 1164 13) Initiator sets up new outbound SA. 1166 13) Initiator deletes old outbound SA and starts using new outbound 1167 SA. 1169 14) Initiator deletes old inbound SA. 1171 15) Initiator sends second SA Delete mode message. 1173 16) Responder receives second SA Delete mode message. 1175 17) Responder deletes old inbound SA. 1177 5. Acknowledgements 1179 Some of the concepts presented in this memo are based on work done 1180 by TimeStep Corporation's engineering group. 1182 Others are taken from concepts discussed within the IPSec working 1183 group. 1185 6. References 1187 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," 1188 draft-ietf-ipsec-isakmp-oakley-08.txt. 1190 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1191 "Internet Security Association and Key Management Protocol 1192 (ISAKMP)," draft-ietf-ipsec-isakmp-10.{ps,txt}. 1194 Security Considerations 1196 This document is associated with the IPSec family of documents. As 1197 such, security considerations permeate the document. 1199 Author's Address 1201 Tim Jenkins 1202 tjenkins@timestep.com 1203 TimeStep Corporation 1204 362 Terry Fox Drive 1205 Kanata, ON 1206 Canada 1207 K2K 2P5 1208 +1 (613) 599-3610 1210 The IPSec working group can be contacted via the IPSec working 1211 group's mailing list (ipsec@tis.com) or through its chairs: 1213 Robert Moskowitz 1214 rgm@icsa.net 1215 International Computer Security Association 1217 Theodore Y. Ts'o 1218 tytso@MIT.EDU 1219 Massachusetts Institute of Technology