idnits 2.17.1 draft-detienne-ikev2-recovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In IKEv2, when an IKE_SA is available between two peers, CHILD_SA's SHOULD not be out of sync thanks to the acknowledgement and retransmissons of notifies. IKEv2 however does not specify what to do when a peer does not eventually respond to protected DELETE_SPI notifies. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2009) is 5384 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: 'CERTREQ' is mentioned on line 1098, but not defined ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IESG F. Detienne 3 Internet-Draft P. Sethi 4 Expires: January 30, 2010 Cisco 5 Y. Nir 6 Check Point 7 July 29, 2009 9 Safe IKE Recovery 10 draft-detienne-ikev2-recovery-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 30, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The Internet Key Exchange protocol version 2 (IKEv2) suffers from the 59 limitation of not having a means to quickly recover from a stale 60 state known as dangling Security Associations (SA's) where one side 61 has SA's that the corresponding party does not have anymore. 63 This Draft proposes to address the limitation by offering an 64 immediate, DoS-free recovery mechanism for IKE that can be used in 65 all failover or post-crash situations. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Protocol requirements . . . . . . . . . . . . . . . . . . 4 72 2.1.1. Security level . . . . . . . . . . . . . . . . . . . . 4 73 2.1.2. Network scenarios . . . . . . . . . . . . . . . . . . 5 74 2.1.3. Lightweightness . . . . . . . . . . . . . . . . . . . 5 75 2.2. High level description . . . . . . . . . . . . . . . . . . 6 76 2.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.4. Protocol design guidelines . . . . . . . . . . . . . . . . 6 78 2.5. Protocol design rationale . . . . . . . . . . . . . . . . 7 79 3. IKE recovery . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.1. IKE Recovery options . . . . . . . . . . . . . . . . . . . 8 81 3.2. Stateless IKE Recovery . . . . . . . . . . . . . . . . . . 8 82 3.2.1. Introducing CHECK_SPI . . . . . . . . . . . . . . . . 8 83 3.2.2. Stateless recovery by invalid IKE packets . . . . . . 8 84 3.2.3. Wait before rekey . . . . . . . . . . . . . . . . . . 11 85 3.2.4. Stateless IKE Recovery cookie . . . . . . . . . . . . 11 86 3.3. Ticket based IKE recovery using Session Resumption . . . . 12 87 3.3.1. Ticket Based Recovery . . . . . . . . . . . . . . . . 12 88 3.3.2. Choice of Recovery Mechanism . . . . . . . . . . . . . 12 89 3.3.3. Ticket based recovery by invalid IKE packets . . . . . 13 90 3.4. IPsec SA recovery . . . . . . . . . . . . . . . . . . . . 15 91 3.4.1. In the presence of an IKE_SA . . . . . . . . . . . . . 15 92 3.4.2. In the absence of an IKE_SA . . . . . . . . . . . . . 16 93 3.5. Mandatory Initiators . . . . . . . . . . . . . . . . . . . 18 94 3.6. Recovery closure . . . . . . . . . . . . . . . . . . . . . 20 95 3.7. Dealing with race conditions . . . . . . . . . . . . . . . 20 96 4. Throttling and dampening . . . . . . . . . . . . . . . . . . . 20 97 4.1. Invalid SPI throttling . . . . . . . . . . . . . . . . . . 21 98 4.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 21 99 4.3. User controls . . . . . . . . . . . . . . . . . . . . . . 22 100 5. Negotiating IKE recovery . . . . . . . . . . . . . . . . . . . 22 101 6. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 23 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 104 9. Collapsed stateless exchange . . . . . . . . . . . . . . . . . 24 105 10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 25 106 10.1. Changes from draft-fdetienn-sir-02 . . . . . . . . . . . . 25 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. Introduction 114 If an IKEv2 ([IKEv2]) endpoint receives an IPsec packet that it does 115 not recognize (invalid SPI), a specific notify (INVALID_SPI) can be 116 sent back to the originating peer to take action. This payload is 117 typically only going to be trusted if it is protected by a IKE_SA as 118 unprotected notifies can easily be forged. Similarly, an IKEv2 119 endpoint receiving an unrecognized IKE message MAY send back an 120 INVALID_IKE_SPI notify to the originating peer. In order to validate 121 those unauthenticated messages, a polling sequence has to be started. 123 The polling sequence works as follow. When a peer doubts the 124 liveness of its remote peer, it can send empty informational 125 exchanges expecting a reply confirming liveness. This works as 126 informational exchanges are supposed to be acknowledged in IKEv2. 128 Practical mechanisms offered so far suffer from one of the following 129 limitations: 130 o poll based and slow to react or resource hungry 131 o based on unauthenticated packets and hence open to denial of 132 service attacks 133 o resource intensive (mostly CPU) 134 This memo proposes to decrease the time incurred by this sequence. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [Bra97]. 140 2. Protocol overview 142 2.1. Protocol requirements 144 Dangling SA's can arise from many situations and in many network 145 deployment contexts. The protocol described herein is meant to solve 146 the dangling SA problem in all possible contexts, without making any 147 assumption on resource availability that IKE does not already make. 148 Since speed is the main driver for this memo, the protocol must 149 minimize the time taken to identify then repair a dangling SA 150 condition. 152 2.1.1. Security level 154 The security level of the protocol is targeted to be at least as 155 secure as IKE itself; i.e., the recovery protocol MUST NOT offer an 156 entry point to an attack that IKE alone could resist to (sufficient 157 level of security). 159 2.1.2. Network scenarios 161 2.1.2.1. Remote access vs. lan-to-lan 163 The protocol must be independent of the network deployment. I.e., 164 the protocol must be usable in lan-to-lan as well as in remote-access 165 types of situations or any other use case that can be deployed. No 166 restriction must be made for the scope of the recovery protocol. 168 2.1.2.2. Failover pairs and clusters 170 The protocol must work in the presence of failover pairs or clusters. 171 Some network deployments will involve clusters of devices acting as a 172 single device and those clusters may be extremely large. No 173 assumption must be made as to the devices or group of devices that 174 will implement the protocols. No back-channel mechanism should be 175 necessary for the cluster to support the recovery protocol fully and 176 securely; it is not expected that the cluster will be practically 177 able to maintain communication between its elements, yet failover and 178 recovery between elements of the cluster must remain possible. 180 2.1.2.3. Transition smoothness 182 The protocol must cover for transitions; in particular, it must cover 183 what happens when the SA search indices are changed. For example, if 184 the (IKE_SPI,src_addr,dst_addr) tuple changes as would be the case in 185 an IKE rekey or a MOBIKE update, the recovery protocol must support 186 that transition smoothly. 188 Ideally, the protocol must be insensitive to SA index changes and 189 must avoid deleting state in order to preserve the data flow until 190 new SA's are in place to take care of it. 192 2.1.3. Lightweightness 194 The protocol should be lightweight and consume minimum amounts of 195 network, memory and computational resources to validate dangling 196 state. Ideally, the protocol should not consume anything that is not 197 strictly necessary to the security and validity of the protocol. 198 Also, the protocol should avoid state creation until absolutely 199 necessary. 201 This requirement is particularly important for resource constrained 202 devices as well as for multiprotocol devices whose memory and CPU is 203 claimed by and shared with other protocols or tasks. This 204 requirement is the main reason for ruling out Birth Certificates as 205 described in [BIRTHCERT]. 207 2.2. High level description 209 The recovery procedure works in 3 stages: 210 1. An invalid IKE or ESP packet is received by either peer 211 2. The remote peer is notified through a protected or unprotected 212 notify 213 * Protected notifies are implicitly trusted 214 * The remote peer attemps to confirm the legitimacy of 215 Unprotected Notifies 216 3. The remote peer deletes or recreates the SA's in error 218 2.3. Notation 220 The IKEv2 notation will be used throughout this document with one 221 notable addition. Parent SA describes an IKE_SA from which a 222 CHILD_SA has been derived. 224 The following notation is specific to this document: 225 o Cookie_X: a cookie generated by peer X that is to be reflected by 226 peer Y. 227 o CHECK_SPI(QUERY/ACK/NACK, Cookie): a contextual notation to 228 express that cookie data is attached to a CHECK_SPI payload 229 CHECK_SPI(QUERY/ACK/NACK). See Section 6. 231 2.4. Protocol design guidelines 233 The general approach to recovering from dangling SA situations is to 234 send proofs of desynchronization and liveness. It is admittedly 235 difficult for two gateways to demonstrate they did have SA's but have 236 lost them without a secure, authenticated channel to do so. It is 237 however relatively easy for these gateways to provide valuable hints 238 about the lost SA's. 240 This memo presents a protocol that builds enough trust for those 241 hints to be taken in account. The basic principle is that an 242 attacker taking advantage of this recovery procedure would have to be 243 positioned on the network such that it could perform more interesting 244 attacks than tackling recovery. I.e. the barrier for attacking IKE 245 recovery is as high or higher than other parts of the IKE protocol. 247 The recovery of SA's as outlined in this memo occurs in three phases: 248 o Unrecognized SPI's are detected 249 o The protocol collects clues of previous connectivity 250 o The SA's are repaired by [IKEv2] or by reconstructing the SA from 251 the "ticket" 253 This memo follows the below guidelines: 255 o event driven protocol -- no polling involved 256 o re-create SA's instead of deleting them upon error 257 o let the side that still has the SA's negotiate fresh SA's after a 258 failure 259 o do not generate state when it can be avoided; reduce CPU cost 261 2.5. Protocol design rationale 263 IKEv2 already specifies a poll-based peer liveness detection 264 mechanism. While this type of mechanism helps recovery in most 265 situations, the time taken for recovery tends to be high. 266 Convergence time requirements are getting shorter and faster 267 protocols are becoming a necessity. 269 The protocol in this memo is triggered when dangling SA's are 270 detected, i.e. when a peer receives unrecognized SPI's. This event 271 is in turn triggered when there is actual traffic to be sent so there 272 would be little point in just deleting SA's then hoping for the 273 systems to recreate them. Instead, these SA's SHOULD be repaired as 274 fast as possible in order for the underlying network traffic to be 275 forwarded. This protocol assumes that the dangling SA's are meant to 276 be rebuilt and not deleted. 278 The device that has the SA's also has all the information needed to 279 rekey them and becomes the defacto initiator at the end of the 280 recovery procedure. This is particularly important for systems with 281 dynamic security policies that do not specify how to build the SA; it 282 may not be obvious for those peers to determine which security 283 parameter they should use to recreate the SA they are now missing. 284 When recreating the SA, the peer that has SA's implicitly knows what 285 to rebuild and can use the old SA as a template. 287 The choice of the rekeyer also brings in an added security value. 288 The side that wants to transmit data or at least that pretends having 289 SA's has to demonstrate 'willingness' to actually transmit. 290 Correspondingly it also means that the gateway that does not have 291 SA's is not forced to negotiate anything it may not need. It is 292 important to note that the initial effort of setting up timers and 293 retransmitting, etc... is left to the side that wants to transmit 294 data. 296 Last but not least, the protocol can remain stateless until 297 sufficient proof of liveness is discovered. In fact, one of the 298 protocol variations in this memo allows full statelessness at the 299 expense of a round trip time. In an other variation, some small but 300 reboot-resistant storage (a key) is used to accelerate the recovery. 302 3. IKE recovery 304 3.1. IKE Recovery options 306 During their IKEv2 exchange, two peers negotiate support for IKE 307 Recovery. If both peers can store ephemeral information as well as 308 longer term additional information related to IKE Recovery, an 309 accelerated procedure for setting up new SAs can be used. This 310 procedure is called Ticket Based IKE Recovery and is described in 311 Section 3.3. 313 If either peer cannot store ephemeral or long term information, peers 314 fall back to Sateless IKE Recovery described in Section 3.2. 316 In either case, IKE Recovery is negotiated during the initial IKE 317 exchange by advertising capabilities as described in Section 5. 319 3.2. Stateless IKE Recovery 321 3.2.1. Introducing CHECK_SPI 323 In order to achieve stateless IKE recovery, this memo introduces a 324 new notify type called CHECK_SPI. The CHECK_SPI payload carries an 325 SPI (IKE_SA or Child SA) and one of three sub-types (QUERY, ACK, 326 NACK). The semantic of the CHECK_SPI subtypes is the following: 327 o QUERY: a peer queries the remote peer SA DB for the presence of 328 the SA whose value is in the payload 329 o ACK: a peer confirms it has the SA specified in the payload 330 o NACK: a peer confirms it does not have the SA specified in the 331 payload 333 The payload format of the CHECK_SPI notify is covered in Section 6. 335 3.2.2. Stateless recovery by invalid IKE packets 337 When an IKE peer X receives an IKE packet with an unknown IKE SPI 338 (A,B), that is not an initialization offer (IKE_SA_INIT), peer X 339 SHOULD send an unprotected INVALID_IKE_SPI notification. 341 Peer X Peer Y 343 HDR(A,B) ... 344 <-------------------------------------------- 346 HDR(A,B) INVALID_IKE_SPI(A,B) 347 --------------------------------------------> 349 Even if another IKE_SA exists with the remote peer Y, the 350 notification MUST NOT be sent protected since peer Y may not share 351 this SA either. 353 In order to limit the risk of Denial of Service attacks, the sending 354 of the INVALID_IKE_SPI notification MUST be rate limited. 356 When peer Y receives the unauthenticated INVALID_IKE_SPI referencing 357 the offending IKE SPI (A,B), Y MUST perform the following actions: 358 o verify that (A,B) is indeed an active IKE_SPI with X 359 o send to X a notify type CHECK_SPI(QUERY, (A,B), Cookie_Y) 361 Peer X Peer Y 363 HDR(A,B) INVALID_IKE_SPI(A,B) 364 --------------------------------------------> 366 HDR(A,B) CHECK_SPI(QUERY(A,B),Cookie_Y) 367 <-------------------------------------------- 369 The sending of the CHECK_SPI packet MUST be rate limited on a per 370 peer basis. 372 State SHOULD NOT have been generated by either X or Y at this point. 373 If the INVALID_IKE_SPI or CHECK_SPI notification gets lost, and X 374 indeed does not have the IKE SPI, the process will start over again 375 at the next protected IKE message sent by Y to X. 377 When peer X receives an unauthenticated CHECK_SPI(QUERY,(A,B)) 378 packet, it MUST perform a look up for (A,B) in its IKE_SA database. 379 Depending on whether X has or does not have the offending SA, it 380 SHOULD reply with an IKE packet CHECK_SPI(ACK/NACK,(A,B)). The 381 cookie data in the CHECK_SPI(ACK/NACK) packet is the same as that 382 recieved in the CHECK_SPI(QUERY), i.e. the cookie is reflected back 383 in the response. 385 Section 3.2.4 discusses cookie generation in greater detail. For 386 now, it is enough to know that the cookie should contain enough 387 information for peer Y to validate the CHECK_SPI(ACK/NACK) response 388 without having to keep any state. 390 Peer X Peer Y 392 HDR(A,B) CHECK_SPI(QUERY,(A,B),Cookie_Y) 393 <-------------------------------------------- 395 HDR(A,B) CHECK_SPI(ACK/NACK,(A,B),Cookie_Y) 396 [N(Cookie_X)] 397 --------------------------------------------> 399 When peer Y receives the CHECK_SPI(ACK/NACK, Cookie_Y) packet, it 400 MUST ensure Cookie_Y is valid. If it is not, the packet MUST be 401 dropped and a rate limited message MUST be logged. 403 If Cookie_Y is valid and the remote peer X confirms it has the IKE 404 SPI (via CHECK_SPI(ACK,...)), a rate limited message SHOULD be 405 logged; this could be a race condition or an attack from a spoofing 406 attacker. 408 If Cookie_Y is valid and the remote peer X confirms it does NOT have 409 the IKE SPI (via CHECK_SPI(NACK,..)), peer Y SHOULD initiate a new 410 IKE exchange to renegotiate the Parent SA. The parameters of the 411 negotiation SHOULD be taken primarily from the configuration 412 (security policy) and, if absent, taken from the confirmed dangling 413 SA. Renegotiation of CHILD_SA's SHOULD follow the Parent IKE_SA 414 creation. The original SA's SHOULD be deleted after successful 415 creation of the new SA's. 417 Peer X can also include an optional N(Cookie_X) payload in the 418 CHECK_SPI(ACK/NACK) packet. This Cookie MUST be reflected back by Y 419 in the new IKE exchange that completes the recovery. This additional 420 cookie saves one round trip between peers that require an anti- 421 spoofing Cookie exchange. 423 A complete recovery exchange for IKE SA's would look like: 425 Peer X Peer Y 427 HDR(A,B) ... 428 <-------------------------------------------- 430 HDR(A,B) INVALID_IKE_SPI(A,B) 431 --------------------------------------------> 433 HDR(A,B) CHECK_SPI(QUERY,(A,B), Cookie_Y) 434 <-------------------------------------------- 436 HDR(A,B) CHECK_SPI(NACK,(A,B), Cookie_Y) 437 [N(Cookie_X)] 438 --------------------------------------------> 440 HDR(A',0) SAi1, KEi, Ni, [N(Cookie_X)] 441 <-------------------------------------------- 443 ... 445 3.2.3. Wait before rekey 447 There exists a particular attack where a man-in-the-middle can snoop 448 and inject traffic but can not block or drop packets. This attack 449 can spoof INVALID_SPI (allegedly from X), forcing a CHECK_SPI(QUERY) 450 from Y. The attacker would spoof back CHECK_SPI(NACK) to force an 451 undue rekey. Since the attacker can not block packets, the 452 CHECK_SPI(QUERY) will also reach X, who will reply with 453 CHECK_SPI(ACK). 455 Y receives CHECK_SPI(NACK) first and MAY wait for a few msec before 456 creating a new SA. Y will eventually receive BOTH a CHECK_SPI(ACK) 457 and a CHECK_SPI(NACK). Which is dubious. The SIR process should 458 then stop and log an error, saving the SA. 460 The process is illustrated below: 462 X Attacker Y 463 Inv SPI 464 ------------------> 466 CHECK_SPI(QUERY) 467 <------------------------------------- 469 CHECK_SPI(NACK) 470 ------------------> Should rekey 471 but wait a few msec 473 CHECK_SPI(ACK) 474 -------------------------------------> Hint of attack 475 => no rekey 477 Ideally, the round-trip-time should be measured during the IKE 478 exchange and Y wait for a full RTT before initiating a rekey. 480 Given that IKE itself is subject to DH computation by a man-in-the- 481 middle, also considering that SA's are dampened after creation (see 482 Section 4.2), the staging complexity and limited interest of this 483 attack makes it rather impractical. An implementation MAY decide to 484 implement this final safety delay but this is strictly optional. 486 3.2.4. Stateless IKE Recovery cookie 488 The cookie information is chosen by the peer that emits it. As such, 489 the cookie has strictly no meaning for the remote peer and can thus 490 be chosen as seen fit. This section provides recommendations on how 491 to generate and validate those cookies. 493 When an IKE endpoint sends an unauthenticated CHECK_SPI, the cookie 494 payload following the notify is computed as follow: 496 Cookie = 497 | H( | CHECK_SPI(..., Query) 498 | ip.src | ip.dst 499 | udp.src | udp.dst) 501 where 502 o is a randomly generated secret known only to the 503 responder and periodically changed 504 o should be changed whenever is 505 regenerated 506 o CHECK_SPI(..., Query) is the content of the CHECK_SPI notify 507 payload where the operation subtype has been set to Query (cf. 508 Section 6) 509 o ip.src is the source ip address of the IKE packet 510 o ip.dst is the destination ip address of the IKE packet 511 o udp.src is the source udp post of the IKE packet 512 o udp.dst is the destination udp port of the IKE packet 514 Upon reception of a CHECK_SPI(ACK or NACK) response containing a 515 cookie, a peer can verify whether this is the reply to a Query it 516 placed by recomputing the cookie and comparing it to the cookie in 517 the CHECK_SPI message. 519 In order to minimize the range of cryptographic attacks on , 520 messages SHOULD have a limited life time. 522 3.3. Ticket based IKE recovery using Session Resumption 524 3.3.1. Ticket Based Recovery 526 If both peers can store ephemeral information and support IKE Session 527 Resumption as described in [IKERESUME], an accelerated procedure can 528 be used. This procedure is called Ticket Based IKE Recovery. 530 The ticket based IKE Recovery method relies on an unauthenticated 531 INVALID_IKE_SPI along with a cookie for detection of a dangling SA. 532 Recovery is effected using session resumption exchange described in 533 [IKERESUME]to recover from a Dangling SA condition. This memo 534 introduces a variation to the Session Resumption Exchange for 535 protection against Denial of Service Attacks 537 3.3.2. Choice of Recovery Mechanism 539 The choice of using Stateless IKE Recovery or Ticket Based Recovery 540 depends upon the capabilities of the endpoint and its peer as well. 542 It could also depend on policy. 544 During Recovery, the endpoint that has the SA, also knows about the 545 peers capabilities whereas the enpoint that has lost its SA can be 546 presumed to not know its peers capabilities. This endpoint only 547 offers a hint of its capabilities by responding to an invalid packet 548 with an INVALID_SPI followed by a cookie. 550 The endpoint that has the SA can choose to respond to an 551 unauthenticated INVALID_SPI based on its knowledge of the peer 552 capabiliries. If it has a session resumption ticket from the peer, 553 it SHOULD initiate an IKE_SESSION_RESUME exchange, else it SHOULD 554 send a CHECK_SPI query. If the peer is not capable of Safe IKE 555 Recovery, the endpoint SHOULD fall back to liveness checks or other 556 mechanisms recommended by [IKEv2]. 558 If the endpoint that receives an IKE_SESSION_RESUME packet is unable 559 to use the resumption ticket for any reason, it should respond with a 560 RESUME_NACK followed by the peer coookie it recieved in the clear. 561 This allows the peer to initiate a full IKEv2 exchange safely. 563 3.3.3. Ticket based recovery by invalid IKE packets 565 When a peer X receives an IKE packet with an unknown IKE_SPI, it 566 SHOULD send an unprotected INVALID_IKE_SPI notify to the sender Y. 567 The INVALID_IKE_SPI MUST be followed with a Cookie payload. The 568 cookie payload content is relevant only to the generator of the 569 cookie and a suggested format for it is described in Section 3.2.4. 571 When peer Y receives the INVALID_IKE_SPI referencing the IKE_SPI(A,B) 572 followed by CHECK_SPI(Cookie_X), it MUST perform the following 573 actions: 574 o verify that (A,B) is an active IKE_SA it has with X. If no such SA 575 exists a rate limited mesage SHOULD be logged. 576 o verify that it possesses a resumption ticket given to it by X and 577 initiate an IKE_SESSION_RESUME exchange with X. This memo requires 578 that the IKE_SESSION_RESUME packet MUST carry COOKIE_X received in 579 the INVALID_SPI packet encrypted in the SK payload. Y also 580 generates and sends another cookie COOKIE_Y in the clear. 582 Peer X Peer Y 584 HDR(A,B) ... 585 <-------------------------------------------- 587 (1) HDR(A,B) INVALID_IKE_SPI(A,B) 588 CHECK_SPI(COOKIE_X) 589 --------------------------------------------> 591 (2) HDR(A,B) Ni CHECK_SPI(COOKIE_Y) 592 N(TICKET) SK{IDi, IDr... CHECK_SPI(COOKIE_X)} 593 <-------------------------------------------- 595 (3) HDR(A,B) SK{Nr,IDr,SAr2... CHECK_SPI(COOKIE_Y)} 596 -----------------------------------------------> 598 SK{} 599 (4) <------------------------------------------- 600 ... 602 At step(1), If Peer Y does not support [IKERESUME], it MUST ignore 603 CHECK_SPI(COOKIE_X) and fall back to the stateless recovery method in 604 Section 3.2. Otherwise, on step (2), Peer Y responds to the invalid 605 SPI by sending back the resumption ticket as well as COOKIE_X under 606 the cover of SK. 608 Peer X, on receiving the TICKET_RESUME notify with a cookie payload 609 on step (2) MUST look up the SA (A,B) in its SA database. If the SA 610 exists, it MUST respond with a protected CHECK_SPI(ACK) that includes 611 the peer cookie COOKIE_Y and a rate limited message SHOULD be logged. 613 If the SA does not exist, X should decrypt the SK payload using the 614 contents of the ticket and validate COOKIE_X. If the cookie is not 615 valid the packet should be dropped and a rate limited message SHOULD 616 be logged. 618 If packet (2) is rejected for any other reason, Peer X responds with 619 a CHECK_SPI(NACK) containing COOKIE_Y and the exchange continues 620 statelessly as described in Section 3.2. 622 If packet (2) is finally accepted and validated, peer X sends back an 623 IKE_SESSION_RESUME response to create a new SA. The response packet 624 also includes CHECK_SPI(COOKIE_Y) which is simply sent back unchanged 625 but protected inside the SK payload. Peer X can also proceed to 626 computing and creating state for a new SA as described in 627 [IKERESUME]. A further cookie exchange as described in [IKERESUME] 628 is not required as the two peers have already reflected COOKIE_X. 630 Peer Y performs the following actions on Packet (3) depending on the 631 response it gets back from X 632 o On receiving a SESSION_RESUME response, Peer Y decrypts the SK 633 payload and validates the COOKIE2, and proceeds to create a new 634 SA. If the cookie is invalid a rate limiting message is logged 635 and the packet is dropped. 636 o If the Peer Y receives a CHECK_SPI(NACK) followed by the cookie 637 COOKIE_Y, Y MAY proceed to initiating a regular IKEv2 session. 638 o If a protected CHECK_SPI(ACK) response is received, a rate 639 limiting message is logged. 640 o If the Peer Y receives a N(TICKET_NACK) notification, Y MAY 641 initiate a regular IKEv2 exchange. 643 Packet (4) is an empty informational liveliness message sent from Y 644 to X using the newly installed SA, after a successful SESSION_RESUME 645 exchange. 647 Note: It is to be noted that the Stateful Ticket Recovery exchange 648 described above could be used without any change, to complete a 649 recovery even when if the QCD_TOKEN based method described in [QCD] 650 is used for detection of Invalid SAS. 652 3.4. IPsec SA recovery 654 We are now considering the case of an IKE endpoint Y sending an ESP 655 or AH packet (or any type of traffic supported by a CHILD_SA) to peer 656 X who does not have the corresponding phase 2 SA. We will 657 differentiate two subcases depending on the presence or not of an IKE 658 SA between the two peers. 660 The recovery procedure will be roughly the same as for the Dangling 661 Parent SA case but for children SA's, we send protected notifications 662 whenever we can. 664 Peer X Peer Y 666 ESP(SPI) ... 667 <-------------------------------------------- 669 On receiving an unrecognized ESP or AH packet, Peer X SHOULD notify 670 the remote peer Y. The method will be different, according to the 671 presence of an IKE_SA with Y. 673 3.4.1. In the presence of an IKE_SA 675 In IKEv2, when an IKE_SA is available between two peers, CHILD_SA's 676 SHOULD not be out of sync thanks to the acknowledgement and 677 retransmissons of notifies. IKEv2 however does not specify what to 678 do when a peer does not eventually respond to protected DELETE_SPI 679 notifies. 681 This section augments the IKEv2 specification in order to allow the 682 recovery of stale SA's in case peers decided to keep the Parent SA 683 nevertheless. 685 If an IKE_SA is available with the remote peer, peer X MUST send a 686 protected INVALID_SPI notification to the Y. The notification MUST be 687 protected by the Parent SA and MUST contain the SPI of the invalid 688 packet. 690 Peer X Peer Y 692 ESP(SPI) ... 693 <-------------------------------------------- 695 HDR(A,B) SK{INVALID_SPI(SPI)} 696 --------------------------------------------> 698 At this point, Y MUST check whether it has the offending SA. If so, 699 it SHOULD re-key or delete the child SA according to its security 700 policy. This document suggests that Y SHOULD delete the dangling SA 701 but MAY rekey if deemed adequate. If the offending SA is not to be 702 found, a message SHOULD be logged as the triggering ESP packet may be 703 an attack or the result of a race condition. The logging MUST be 704 rate limited. 706 3.4.2. In the absence of an IKE_SA 708 If an IKE_SA is not available with peer Y, an unprotected INVALID_SPI 709 notification MUST be sent. The notification MUST contain the SPI of 710 the invalid packet. 712 Peer X Peer Y 714 ESP(SPI) ... 715 <-------------------------------------------- 717 HDR(0,0) INVALID_SPI(SPI) 718 --------------------------------------------> 720 Note: An IKE SPI of (0,0) is used since there is no other IKE SPI to 721 use (by construction) 723 Peer Y MUST verify whether it has the offending CHILD_SA; if it does 724 not, Y MUST log a rate limited message and drop the notify. If Y 725 owns the offending SA, Y MUST perform the following: 727 o ensure the unauthenticated INVALID_SPI notify is legitimate 728 o rebuild the dangling SA's with the remote peer if needed 729 The following procedure will help determining whether the INVALID_SPI 730 notify is legitimate. 732 Peer Y MUST send a protected CHECK_SPI notify to X. Since Y has the 733 CHILD_SA, it MUST have its Parent SA by construction. 735 Peer X Peer Y 737 HDR(0,0) INVALID_SPI(SPI) 738 --------------------------------------------> 740 HDR(A,B) SK{CHECK_SPI(QUERY, SPI)} 741 <-------------------------------------------- 743 If X can decrypt the CHECK_SPI(QUERY) notification from Y, i.e it has 744 a valid IKE_SA(A,B), the situation can be either of the following: 745 o therY also generates and sends another cookie COOKIE_Y in the 746 cleare is a logic error on X as it should have sent the 747 INVALID_SPI protected 748 o the INVALID_SPI request that led to the CHECK_SPI notify has been 749 forged 750 o there was a race condition in an earlier exchange 752 X MUST try to identify which condition it has met, e.g. by checking 753 SPI is in the SA database and MUST log a message about a possible 754 security alert. 756 Under normal recovery circumstances, X will not have the PARENT SA. 757 In this case, X MUST reply with an unprotected INVALID_IKE_SPI(A,B) 758 and fall back into the Parent SA recovery procedure. 760 The Parent SA recovery procedure could use either stateless or Ticket 761 based recovery. The overall recovery scheme for CHILD_SA's using the 762 Stateless IKE recovery procedure can be summarized as follows: 764 Peer X Peer Y 766 ESP(SPI) ... 767 <-------------------------------------------- 769 HDR(0,0) INVALID_SPI(SPI) 770 --------------------------------------------> 772 HDR(A,B) SK{CHECK_SPI(QUERY,(SPI)) } 773 <-------------------------------------------- 775 HDR(A,B) INVALID_IKE_SPI (A,B) 776 --------------------------------------------> 778 HDR(A,B) CHECK_SPI(QUERY,(A,B),Cookie) 779 <-------------------------------------------- 781 HDR(A,B) CHECK_SPI(NACK,(A,B),Cookie) 782 --------------------------------------------> 784 HDR(A',0) SAi1, KEi, Ni 785 <-------------------------------------------- 787 3.5. Mandatory Initiators 789 There are cases where the side having the SA's cannot act as an 790 initiator in a recovery procedure and has to rely on the peer device 791 to initiate recovery. These exceptions include: 792 o Specific implementations, typically in remote access, that rely on 793 the 'client' to be a pure initiator. 794 o gateways that are behind a dynamic PAT device and that can not be 795 reached directly from outside. These devices have to be 796 initiators of the connection in order to set up the translation 797 rules. 799 We call such devices Mandatory Initiators and in the context of this 800 document, they will eventually become responsible for recovering the 801 SA's. 803 Mandatory Initiators SHOULD be determined by the system administrator 804 through their configuration or implicitly through the set of features 805 they are configured for. Mandatory Initiators MAY determine by 806 themselves whether they are behind a dynamic PAT device. The 807 determination can for instance arise from analyzing the NAT-T 808 payloads described in [NAT-T]. 810 Because Mandatory Initiators are actually IKEv2 initiators, they 811 typically know by configuration which peers they should have a 812 connection with, even if the SA's are missing. If this is indeed the 813 case, the following Mandatory Initiator recovery procedure SHOULD be 814 followed. 816 The recovery procedure for Mandatory Initiators is the same as for 817 other peers with change in the last step containing the 818 CHECK_SPI(NACK) where the Mandatory Initiator actually sends 819 initiates an an IKEv2 Initial Exchange along with the CHECK_SPI(NACK) 820 payload. 822 Example CHILD_SA recovery exchange with mandatory initiator (Parent 823 SA present): 825 Peer X Peer Y 827 HDR(A,B) ... 828 <-------------------------------------------- 830 HDR(A,B) INVALID_IKE_SPI(A,B) 831 --------------------------------------------> 833 HDR(A,B) CHECK_SPI(QUERY,(A,B), Cookie_X) 834 <-------------------------------------------- 836 HDR(A',0) SAi1, KEi, Ni, 837 CHECK_SPI(NACK,(A,B), Cookie_X) 838 --------------------------------------------> 840 ... 842 When Peer Y receives the Initial Offer, it MUST verify it has the IKE 843 SPI in the CHECK_SPI reply. In other words, the recovery procedure 844 HINTS the Mandatory Initiator about a need for resynchronizing the 845 SA's. This hint MAY be ignored, according to the local peer policy. 847 If it does not have the corresponding IKE SA, Y MUST log a rate 848 limited message and drop the message. If Y owns the IKE SPI, it MUST 849 validates the cookie as described in Section 3.2.4 and proceed with 850 the IKE exchange, according to its security policy. 852 In any case, X SHOULD NOT retransmit the Initial Offer. The process 853 will restart by itself if the IKE SA is indeed missing and further 854 offending ESP or IKE packets are emitted. If X receives a valid 855 Message 2, it can proceed with the rest of the IKEv2 negotiation and 856 retransmit as necessary. 858 Example CHILD_SA recovery exchange with mandatory initiator (no 859 Parent SA): 861 Peer X Peer Y 862 (Mandatory Initiator) 864 ESP(SPI) ... 865 <-------------------------------------------- 867 HDR(0,0) INVALID_SPI(SPI) 868 --------------------------------------------> 870 HDR(A,B) CHECK_SPI(QUERY,(SPI)) 871 <-------------------------------------------- 873 HDR(A,B) INVALID_IKE_SPI (A,B) 874 --------------------------------------------> 876 HDR(A,B) CHECK_SPI(QUERY,(A,B), Cookie) 877 <-------------------------------------------- 879 HDR(A',0) SAi1, KEi, Ni, 880 CHECK_SPI(NACK,(A,B),Cookie) 881 --------------------------------------------> 883 3.6. Recovery closure 885 In many cases, the outcome of the recovery procedure yields to the 886 creation of a new IKE_SA. Either side may be left with an old IKE_SA 887 and dangling CHILD_SA's. In order to recover entirely, the old 888 CHILD_SA's SHOULD be recreated (entirely renegotiated) under the 889 protection of the new Parent SA. After which, the old SA's (IKE_SA 890 and CHILD_SA's) SHOULD be entirely deleted. 892 3.7. Dealing with race conditions 894 When a peer deletes SA's, a DELETE payload is sent that MUST be 895 acknowldeged. Before the delete notify reaches the remote peer, 896 further ESP packets for the now deleted SPI may be received. These 897 ESP packets MUST be silently discarded as long the DELETE Notify can 898 be retransmitted. 900 4. Throttling and dampening 902 An important aspect of the security in IKE recovery has to do with 903 limitating the CPU utilization. In order to thwart flood types 904 denial of service attacks, strict rate limiting and throttling 905 mechanisms have to be enforced. 907 All the notifications that are exchanged during IKE recovery SHOULD 908 be rate limited. This paragraph provides information on the way rate 909 limiting should take place. 911 4.1. Invalid SPI throttling 913 The sending of all Invalid SPI notifies MUST be rate limited one way 914 or an other. The rate limiting SHOULD be performed on a per peer 915 basis but dynamic state creation SHOULD be avoided as much as 916 possible (it can be; this is an implementation matter). 918 Invalid SPI rate limiting protects against natural dangling SA 919 occurences. I.e. normal traffic conditions may cause unrecognized 920 SPI's to be received and this message is the most important to 921 protect. Indeed, it is not realistic to send one notification per 922 bad ESP packet received. On high speed links, this could mean 923 thousands of IKE notifies sent for the same offending SPI. 925 The receiving of unauthenticated Invalid SPI notifies MUST as well be 926 rate limited. Again, the rate limiting SHOULD be performed on a per 927 peer basis without dynamic state creation. In normal circumstances, 928 the peer receiving Invalid SPI notifies has an SA with the peer 929 sendig those notifies and already maintains peer-related data 930 structures that can help in maintaining adequate counters. 932 Authenticated Invalid SPI notifies can be accepted without 933 throttling. 935 4.2. Dampening 937 After one of the following conditions: 938 o the natural creation or rekey of one or more SA's 939 o the recovery of one or more SA's 940 o the failure in recovering an SA owned by the local security 941 gateway 942 o the logging of an error or warning message involving an SA owned 943 by the local security gateway 945 The peer with which SA's were created, attempted or against which a 946 log was emitted SHOULD be dampened, which means that all the 947 unauthenticated Invalid SPI and Check SPI messages emitted by that 948 peer MUST be ignored for a chosen duration. 950 This protection prevents a man-in-the-middle from forcing the fast 951 recreation of SA's and potentially depleting the entropy of systems 952 under attack. It also deals efficently with race conditions that may 953 occur after a rekey. 955 4.3. User controls 957 Because throttling at large is related to speed, the network 958 implementation around the security gateways has a major influence on 959 the pertinence of the paremeters controlling rate limiting. It is 960 difficult to provide good absolute values for the rate limiters, 961 considering that these are implementation dependent. 963 As such, for the sake of fitness in practical deployments, a system 964 implementing this memo MUST provide administrative controls over the 965 rate limiter parameters. 967 5. Negotiating IKE recovery 969 IKE recovery capabilities MUST be advertised through a Vendor ID 970 payload. 972 In the first two messages of the Parent SA negotiation, the Vendor ID 973 payload for this specification MUST be sent if supported (and it MUST 974 be received by both sides). The content of the payload is the ASCII 975 string: 977 SECURE IKE RECOVERY, or in hex: 53 45 43 55 52 45 20 49 4b 45 20 52 978 45 43 4F 56 45 52 59" 980 The peers' capbility for IKE Session Resumption is known implicitly 981 from receiving the resumption ticket. 983 Determining peer capability can be useful for two reasons at least. 984 First, this information MAY let a system decide to fallback to 985 another recovery mechanism, such as from Ticket based Recovery to 986 Stateless Safe IKE Recovery or falling back to the one embedded in 987 IKEv2 989 Knowledge of the peer's capabilities can be used by the 'live 990 peer'(the one that still has the SA's) in order to determine whether 991 it is normal or not to receive unauthenticated INVALID_SPI with or 992 without cookies or CHECK_SPI notifies. A peer that has lost 993 information about it's peer SHOULD go under the assumption that peer 994 does understand IKE Recovery as described in this memo. This 995 assumption implies that INVALI_SPI notifies with cookies and 996 CHECK_SPI notifies can be sent. If the remote peer does not support 997 IKE Recovery, it will just ignore these messages. 999 In general, it is useful for system administrators to monitor the 1000 capabilities of a remote system connecting to a local security 1001 gateway and there is an interest in advertising the IKE Recovery 1002 capability. 1004 6. Payload formats 1006 For reference, the Notify Payload is defined as follow 1008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 ! Next Payload !C! RESERVED ! Payload Length ! 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 ! Protocol ID ! SPI Size ! Notify Message Type ! 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 ! ! 1015 ~ Security Parameter Index (SPI) ~ 1016 ! ! 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 ! ! 1019 ~ Notification Data ~ 1020 ! ! 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 The meaning of the fields is the same as defined in [IKEv2]. 1025 This memo introduces a new Notify Message Type that is being 1026 developped with a Private Use Type: 1027 o CHECK_SPI: 32770 1029 An official IANA assigned number MUST be assigned if this document 1030 reaches final recommendation state. 1032 The notification data area is formatted as such: 1034 1 2 3 1035 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 ! Subtype ! CookieSize | RESERVED ! 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 ! Cookie ! 1040 ~ ~ 1041 ! ! 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 o Subtype (1 Octet) - This field determines the operation being 1045 performed (Query, Reply_ACK, Reply_NACK, Lone_Cookie) 1046 o CookieSize - The size of the optional cookie embedded in the 1047 CHECK_SPI notify. If there is no cookie, CookieSize is set to 0 1048 (zero). 1050 o Cookie - The optional cookie embedded in the payload. Its size 1051 depends on the value CookieSize. 1053 The list of operations and their corresponding value: 1054 o Query: 0 1055 o Reply_ACK: 1 1056 o NACK: 2 1058 7. IANA Considerations 1060 This document requires the following notification to be registered by 1061 IANA. The corresponding registry was established by IANA. 1062 o CHECK_SPI Notification type (Section 6). 1064 8. Security Considerations 1066 IKE recovery self-protection is discussed all along the document and 1067 contains many mechanism to thwart denial of service attacks. 1069 IKE recovery is subject to a man-in-the-middle attack that can let 1070 the attacker trigger a renegotiation. It has to be noticed that an 1071 attacker able to block ESP and/or IKE packets can cause IKE itself to 1072 also tear down and trigger a rekey of IKE SA's. With throttling and 1073 dampening enabled, IKE recovery is able to reduce the amount of 1074 rekeys/negotiations to as low a rate as IKEv2. 1076 Overall, IKE Recovery is not more vulnerable than IKEv2 and even 1077 improves on the security of IKEv2 by resynchronizing SA's more 1078 rapidly which is important with dynamic polices. 1080 9. Collapsed stateless exchange 1082 In order to save on round-trips, IKE Recovery can be collapsed into 1083 an IKEv2 exchange. The recovery case goes as follows: 1085 Peer X Peer Y 1087 (1) HDR(A,B) ... 1088 <-------------------------------------------- 1090 (2) HDR(A,B) INVALID_IKE_SPI(A,B), N(Cookie_X) 1091 --------------------------------------------> 1093 (3) HDR(A',0) HDR N(Cookie_X), 1094 CHECK_SPI(QUERY,(A,B)), N(Cookie_Y), SAi1, KEi, Ni 1095 <-------------------------------------------- 1097 (4) HDR(A',B') CHECK_SPI(NACK,(A,B)), N(Cookie_Y), 1098 SAr1, KEr, Nr, [CERTREQ], KEi, Ni 1099 --------------------------------------------> 1101 (5) HDR(A',B') SK {IDi, [CERT,] [CERTREQ,] [IDr,] 1102 AUTH, SAi2, TSi, TSr} 1103 <-------------------------------------------- 1105 ... 1107 In the exchange above, X sends an optional N(Cookie_X) in the 1108 INVALID_IKE_SPI notify if it expects cookies to be used when acting 1109 as a responder. Cookie_X is reflected by peer Y as in a normal IKE 1111 10. Change log 1113 NOTE TO RFC EDITOR: This section is to be removed in the final RFC 1115 10.1. Changes from draft-fdetienn-sir-02 1117 Minor changes around rate limiting. Removed implementation 1118 recommendation to keep only high level recommendation. 1120 11. References 1122 11.1. Normative References 1124 [Bra97] Bradner, S., "RFC 2119, Key Words for use in RFCs to 1125 indicate Requirement Levels", March 1997. 1127 [IKEv2] Kaufman, Ed., "RFC 4306, Internet Key Exchange (IKEv2) 1128 Protocol", December 2005. 1130 [NAT-T] Kivinen, "RFC 3947, Negotiation of NAT-Traversal in the 1131 IKE", January 2005. 1133 11.2. Informative References 1135 [BIRTHCERT] 1136 Harkins, D., Kauffman, C., Kivinen, T., Kent, S., and R. 1137 Perlman, "Design Rationale for IKEv2", July 2007. 1139 [IKERESUME] 1140 Sheffer, Y., "Stateless Session Resumption for the IKE 1141 Protocol", July 2007. 1143 [QCD] Nir, Y., "A Quick Crash Detection Method for IKE", 1144 Aug 2008. 1146 Authors' Addresses 1148 Frederic Detienne 1149 Cisco 1150 De Kleetlaan, 7 1151 Diegem B-1831 1152 Belgium 1154 Phone: +32 2 704 5681 1155 Email: fd@cisco.com 1157 Pratima Sethi 1158 Cisco 1159 O'Shaugnessy Road, 11 1160 Bangalore, Karnataka 560027 1161 India 1163 Phone: +91 80 4154 1654 1164 Email: psethi@cisco.com 1166 Yoav Nir 1167 Check Point Software Technologies Ltd. 1168 5 Hasolelim st. 1169 Tel Aviv 67897 1170 Israel 1172 Email: yir@checkpoint.com