1 2 3 4 5 6 7Network Working Group G. Huang 8Request for Comments: 3706 S. Beaulieu 9Category: Informational D. Rochefort 10 Cisco Systems, Inc. 11 February 2004 12 13 14 A Traffic-Based Method of Detecting Dead Internet 15 Key Exchange (IKE) Peers 16 17Status of this Memo 18 19 This memo provides information for the Internet community. It does 20 not specify an Internet standard of any kind. Distribution of this 21 memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2004). All Rights Reserved. 26 27Abstract 28 29 This document describes the method detecting a dead Internet Key 30 Exchange (IKE) peer that is presently in use by a number of vendors. 31 The method, called Dead Peer Detection (DPD) uses IPSec traffic 32 patterns to minimize the number of IKE messages that are needed to 33 confirm liveness. DPD, like other keepalive mechanisms, is needed to 34 determine when to perform IKE peer failover, and to reclaim lost 35 resources. 36 37Table of Contents 38 39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 3 41 3. Rationale for Periodic Message Exchange for Proof of 42 Liveliness . . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 4. Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . 3 44 4.1. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 3 45 4.2. Heartbeats . . . . . . . . . . . . . . . . . . . . . . . 5 46 5. DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6 47 5.1. DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . . 7 48 5.2. Message Exchanges. . . . . . . . . . . . . . . . . . . . 7 49 5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . . 8 50 5.4. Impetus for DPD Exchange . . . . . . . . . . . . . . . . 9 51 5.5. Implementation Suggestion. . . . . . . . . . . . . . . . 9 52 5.6. Comparisons. . . . . . . . . . . . . . . . . . . . . . . 10 53 6. Resistance to Replay Attack and False Proof of Liveliness. . . 10 54 6.1. Sequence Number in DPD Messages. . . . . . . . . . . . . 10 55 56 57 58Huang, et al. Informational [Page 1] 59 60RFC 3706 Detecting Dead IKE Peers February 2004 61 62 63 6.2. Selection and Maintenance of Sequence Numbers. . . . . . 11 64 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 65 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Normative Reference. . . . . . . . . . . . . . . . . . . 12 68 9.2. Informative References . . . . . . . . . . . . . . . . . 12 69 10. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 70 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 71 721. Introduction 73 74 When two peers communicate with IKE [2] and IPSec [3], the situation 75 may arise in which connectivity between the two goes down 76 unexpectedly. This situation can arise because of routing problems, 77 one host rebooting, etc., and in such cases, there is often no way 78 for IKE and IPSec to identify the loss of peer connectivity. As 79 such, the SAs can remain until their lifetimes naturally expire, 80 resulting in a "black hole" situation where packets are tunneled to 81 oblivion. It is often desirable to recognize black holes as soon as 82 possible so that an entity can failover to a different peer quickly. 83 Likewise, it is sometimes necessary to detect black holes to recover 84 lost resources. 85 86 This problem of detecting a dead IKE peer has been addressed by 87 proposals that require sending periodic HELLO/ACK messages to prove 88 liveliness. These schemes tend to be unidirectional (a HELLO only) 89 or bidirectional (a HELLO/ACK pair). For the purpose of this 90 document, the term "heartbeat" will refer to a unidirectional message 91 to prove liveliness. Likewise, the term "keepalive" will refer to a 92 bidirectional message. 93 94 The problem with current heartbeat and keepalive proposals is their 95 reliance upon their messages to be sent at regular intervals. In the 96 implementation, this translates into managing some timer to service 97 these message intervals. Similarly, because rapid detection of the 98 dead peer is often desired, these messages must be sent with some 99 frequency, again translating into considerable overhead for message 100 processing. In implementations and installations where managing 101 large numbers of simultaneous IKE sessions is of concern, these 102 regular heartbeats/keepalives prove to be infeasible. 103 104 To this end, a number of vendors have implemented their own approach 105 to detect peer liveliness without needing to send messages at regular 106 intervals. This informational document describes the current 107 practice of those implementations. This scheme, called Dead Peer 108 Detection (DPD), relies on IKE Notify messages to query the 109 liveliness of an IKE peer. 110 111 112 113 114Huang, et al. Informational [Page 2] 115 116RFC 3706 Detecting Dead IKE Peers February 2004 117 118 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC-2119 [1]. 122 1232. Document Roadmap 124 125 As mentioned above, there are already proposed solutions to the 126 problem of detecting dead peers. Section 3 elaborates the rationale 127 for using an IKE message exchange to query a peer's liveliness. 128 Section 4 examines a keepalives-based approach as well as a 129 heartbeats-based approach. Section 5 presents the DPD proposal 130 fully, highlighting differences between DPD and the schemes presented 131 in Section 4 and emphasizing scalability issues. Section 6 examines 132 security issues surrounding replayed messages and false liveliness. 133 1343. Rationale for Periodic Message Exchange for Proof of Liveliness 135 136 As the introduction mentioned, it is often necessary to detect that a 137 peer is unreachable as soon as possible. IKE provides no way for 138 this to occur -- aside from waiting until the rekey period, then 139 attempting (and failing the rekey). This would result in a period of 140 loss connectivity lasting the remainder of the lifetime of the 141 security association (SA), and in most deployments, this is 142 unacceptable. As such, a method is needed for checking up on a 143 peer's state at will. Different methods have arisen, usually using 144 an IKE Notify to query the peer's liveliness. These methods rely on 145 either a bidirectional "keepalive" message exchange (a HELLO followed 146 by an ACK), or a unidirectional "heartbeat" message exchange (a HELLO 147 only). The next section considers both of these schemes. 148 1494. Keepalives vs. Heartbeats 150 1514.1. Keepalives: 152 153 Consider a keepalives scheme in which peer A and peer B require 154 regular acknowledgements of each other's liveliness. The messages 155 are exchanged by means of an authenticated notify payload. The two 156 peers must agree upon the interval at which keepalives are sent, 157 meaning that some negotiation is required during Phase 1. For any 158 prompt failover to be possible, the keepalives must also be sent at 159 rather frequent intervals -- around 10 seconds or so. In this 160 hypothetical keepalives scenario, peers A and B agree to exchange 161 keepalives every 10 seconds. Essentially, every 10 seconds, one peer 162 must send a HELLO to the other. This HELLO serves as proof of 163 liveliness for the sending entity. In turn, the other peer must 164 acknowledge each keepalive HELLO. If the 10 seconds elapse, and one 165 side has not received a HELLO, it will send the HELLO message itself, 166 using the peer's ACK as proof of liveliness. Receipt of either a 167 168 169 170Huang, et al. Informational [Page 3] 171 172RFC 3706 Detecting Dead IKE Peers February 2004 173 174 175 HELLO or ACK causes an entity's keepalive timer to reset. Failure to 176 receive an ACK in a certain period of time signals an error. A 177 clarification is presented below: 178 179 Scenario 1: 180 Peer A's 10-second timer elapses first, and it sends a HELLO to B. 181 B responds with an ACK. 182 183 Peer A: Peer B: 184 10 second timer fires; ------> 185 wants to know that B is alive; 186 sends HELLO. 187 Receives HELLO; acknowledges 188 A's liveliness; 189 <------ resets keepalive timer, sends 190 ACK. 191 Receives ACK as proof of 192 B's liveliness; resets timer. 193 194 Scenario 2: 195 Peer A's 10-second timer elapses first, and it sends a HELLO to B. 196 B fails to respond. A can retransmit, in case its initial HELLO is 197 lost. This situation describes how peer A detects its peer is dead. 198 199 Peer A: Peer B (dead): 200 201 10 second timer fires; ------X 202 wants to know that B is 203 alive; sends HELLO. 204 205 Retransmission timer ------X 206 expires; initial message 207 could have been lost in 208 transit; A increments 209 error counter and 210 sends another HELLO. 211 212 --- 213 214 After some number of errors, A assumes B is dead; deletes SAs and 215 possibly initiates failover. 216 217 An advantage of this scheme is that the party interested in the other 218 peer's liveliness begins the message exchange. In Scenario 1, peer A 219 is interested in peer B's liveliness, and peer A consequently sends 220 221 222 223 224 225 226Huang, et al. Informational [Page 4] 227 228RFC 3706 Detecting Dead IKE Peers February 2004 229 230 231 the HELLO. It is conceivable in such a scheme that peer B would 232 never be interested in peer A's liveliness. In such a case, the onus 233 would always lie on peer A to initiate the exchange. 234 2354.2. Heartbeats: 236 237 By contrast, consider a proof-of-liveliness scheme involving 238 unidirectional (unacknowledged) messages. An entity interested in 239 its peer's liveliness would rely on the peer itself to send periodic 240 messages demonstrating liveliness. In such a scheme, the message 241 exchange might look like this: 242 243 Scenario 3: Peer A and Peer B are interested in each other's 244 liveliness. Each peer depends on the other to send periodic HELLOs. 245 246 247 Peer A: Peer B: 248 10 second timer fires; ------> 249 sends HELLO. Timer also 250 signals expectation of 251 B's HELLO. 252 Receives HELLO as proof of A's 253 liveliness. 254 255 <------ 10 second timer fires; sends 256 HELLO. 257 Receives HELLO as proof 258 of B's liveliness. 259 260 Scenario 4: 261 Peer A fails to receive HELLO from B and marks the peer dead. This 262 is how an entity detects its peer is dead. 263 264 Peer A: Peer B (dead): 265 10 second timer fires; ------X 266 sends HELLO. Timer also 267 signals expectation of 268 B's HELLO. 269 270 --- 271 272 Some time passes and A assumes B is dead. 273 274 The disadvantage of this scheme is the reliance upon the peer to 275 demonstrate liveliness. To this end, peer B might never be 276 interested in peer A's liveliness. Nonetheless, if A is interested 277 B's liveliness, B must be aware of this, and maintain the necessary 278 state information to send periodic HELLOs to A. The disadvantage of 279 280 281 282Huang, et al. Informational [Page 5] 283 284RFC 3706 Detecting Dead IKE Peers February 2004 285 286 287 such a scheme becomes clear in the remote-access scenario. Consider 288 a VPN aggregator that terminates a large number of sessions (on the 289 order of 50,000 peers or so). Each peer requires fairly rapid 290 failover, therefore requiring the aggregator to send HELLO packets 291 every 10 seconds or so. Such a scheme simply lacks scalability, as 292 the aggregator must send 50,000 messages every few seconds. 293 294 In both of these schemes (keepalives and heartbeats), some 295 negotiation of message interval must occur, so that each entity can 296 know how often its peer expects a HELLO. This immediately adds a 297 degree of complexity. Similarly, the need to send periodic messages 298 (regardless of other IPSec/IKE activity), also increases 299 computational overhead to the system. 300 3015. DPD Protocol 302 303 DPD addresses the shortcomings of IKE keepalives- and heartbeats- 304 schemes by introducing a more reasonable logic governing message 305 exchange. Essentially, keepalives and heartbeats mandate exchange of 306 HELLOs at regular intervals. By contrast, with DPD, each peer's DPD 307 state is largely independent of the other's. A peer is free to 308 request proof of liveliness when it needs it -- not at mandated 309 intervals. This asynchronous property of DPD exchanges allows fewer 310 messages to be sent, and this is how DPD achieves greater 311 scalability. 312 313 As an elaboration, consider two DPD peers A and B. If there is 314 ongoing valid IPSec traffic between the two, there is little need for 315 proof of liveliness. The IPSec traffic itself serves as the proof of 316 liveliness. If, on the other hand, a period of time lapses during 317 which no packet exchange occurs, the liveliness of each peer is 318 questionable. Knowledge of the peer's liveliness, however, is only 319 urgently necessary if there is traffic to be sent. For example, if 320 peer A has some IPSec packets to send after the period of idleness, 321 it will need to know if peer B is still alive. At this point, peer A 322 can initiate the DPD exchange. 323 324 To this end, each peer may have different requirements for detecting 325 proof of liveliness. Peer A, for example, may require rapid 326 failover, whereas peer B's requirements for resource cleanup are less 327 urgent. In DPD, each peer can define its own "worry metric" - an 328 interval that defines the urgency of the DPD exchange. Continuing the 329 example, peer A might define its DPD interval to be 10 seconds. 330 Then, if peer A sends outbound IPSec traffic, but fails to receive 331 any inbound traffic for 10 seconds, it can initiate a DPD exchange. 332 333 334 335 336 337 338Huang, et al. Informational [Page 6] 339 340RFC 3706 Detecting Dead IKE Peers February 2004 341 342 343 Peer B, on the other hand, defines its less urgent DPD interval to be 344 5 minutes. If the IPSec session is idle for 5 minutes, peer B can 345 initiate a DPD exchange the next time it sends IPSec packets to A. 346 347 It is important to note that the decision about when to initiate a 348 DPD exchange is implementation specific. An implementation might 349 even define the DPD messages to be at regular intervals following 350 idle periods. See section 5.5 for more implementation suggestions. 351 3525.1. DPD Vendor ID 353 354 To demonstrate DPD capability, an entity must send the DPD vendor ID. 355 Both peers of an IKE session MUST send the DPD vendor ID before DPD 356 exchanges can begin. The format of the DPD Vendor ID is: 357 358 1 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 ! !M!M! 362 ! HASHED_VENDOR_ID !J!N! 363 ! !R!R! 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 366 where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 367 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond 368 to the current major and minor version of this protocol (1 and 0 369 respectively). An IKE peer MUST send the Vendor ID if it wishes to 370 take part in DPD exchanges. 371 3725.2. Message Exchanges 373 374 The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The 375 exchange is defined as: 376 377 Sender Responder 378 -------- ----------- 379 HDR*, NOTIFY(R-U-THERE), HASH ------> 380 381 <------ HDR*, NOTIFY(R-U-THERE- 382 ACK), HASH 383 384 385 386 387 388 389 390 391 392 393 394Huang, et al. Informational [Page 7] 395 396RFC 3706 Detecting Dead IKE Peers February 2004 397 398 399 The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK 400 corresponds to an "ACK." Both messages are simply ISAKMP Notify 401 payloads, and as such, this document defines these two new ISAKMP 402 Notify message types: 403 404 Notify Message Value 405 R-U-THERE 36136 406 R-U-THERE-ACK 36137 407 408 An entity that has sent the DPD Vendor ID MUST respond to an R-U- 409 THERE query. Furthermore, an entity MUST reject unencrypted R-U- 410 THERE and R-U-THERE-ACK messages. 411 4125.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format 413 414 When sent, the R-U-THERE message MUST take the following form: 415 416 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 ! Next Payload ! RESERVED ! Payload Length ! 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ! Domain of Interpretation (DOI) ! 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ! Protocol-ID ! SPI Size ! Notify Message Type ! 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 ! ! 426 ~ Security Parameter Index (SPI) ~ 427 ! ! 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ! Notification Data ! 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 432 As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and 433 Payload Length fields should be set accordingly. The remaining 434 fields are set as: 435 436 - Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI. 437 438 - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP. 439 440 - SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of 441 two octet-sized ISAKMP cookies. 442 443 - Notify Message Type (2 octets) - MUST be set to R-U-THERE 444 445 446 447 448 449 450Huang, et al. Informational [Page 8] 451 452RFC 3706 Detecting Dead IKE Peers February 2004 453 454 455 - Security Parameter Index (16 octets) - SHOULD be set to the 456 cookies of the Initiator and Responder of the IKE SA (in that 457 order) 458 459 - Notification Data (4 octets) - MUST be set to the sequence number 460 corresponding to this message 461 462 The format of the R-U-THERE-ACK message is the same, with the 463 exception that the Notify Message Type MUST be set to R-U-THERE-ACK. 464 Again, the Notification Data MUST be sent to the sequence number 465 corresponding to the received R-U-THERE message. 466 4675.4. Impetus for DPD Exchange 468 469 Again, rather than relying on some negotiated time interval to force 470 the exchange of messages, DPD does not mandate the exchange of R-U- 471 THERE messages at any time. Instead, an IKE peer SHOULD send an R- 472 U-THERE query to its peer only if it is interested in the liveliness 473 of this peer. To this end, if traffic is regularly exchanged between 474 two peers, either peer SHOULD use this traffic as proof of 475 liveliness, and both peers SHOULD NOT initiate a DPD exchange. 476 477 A peer MUST keep track of the state of a given DPD exchange. That 478 is, once it has sent an R-U-THERE query, it expects an ACK in 479 response within some implementation-defined period of time. An 480 implementation SHOULD retransmit R-U-THERE queries when it fails to 481 receive an ACK. After some number of retransmitted messages, an 482 implementation SHOULD assume its peer to be unreachable and delete 483 IPSec and IKE SAs to the peer. 484 4855.5. Implementation Suggestion 486 487 Since the liveliness of a peer is only questionable when no traffic 488 is exchanged, a viable implementation might begin by monitoring 489 idleness. Along these lines, a peer's liveliness is only important 490 when there is outbound traffic to be sent. To this end, an 491 implementation can initiate a DPD exchange (i.e., send an R-U-THERE 492 message) when there has been some period of idleness, followed by the 493 desire to send outbound traffic. Likewise, an entity can initiate a 494 DPD exchange if it has sent outbound IPSec traffic, but not received 495 any inbound IPSec packets in response. A complete DPD exchange 496 (i.e., transmission of R-U-THERE and receipt of corresponding R-U- 497 THERE-ACK) will serve as proof of liveliness until the next idle 498 period. 499 500 Again, since DPD does not mandate any interval, this "idle period" 501 (or "worry metric") is left as an implementation decision. It is not 502 a negotiated value. 503 504 505 506Huang, et al. Informational [Page 9] 507 508RFC 3706 Detecting Dead IKE Peers February 2004 509 510 5115.6. Comparisons 512 513 The performance benefit that DPD offers over traditional keepalives- 514 and heartbeats-schemes comes from the fact that regular messages do 515 not need to be sent. Returning to the examples presented in section 516 4.1, a keepalive implementation such as the one presented would 517 require one timer to signal when to send a HELLO message and another 518 timer to "timeout" the ACK from the peer (this could also be the 519 retransmit timer). Similarly, a heartbeats scheme such as the one 520 presented in section 4.2 would need to keep one timer to signal when 521 to send a HELLO, as well as another timer to signal the expectation 522 of a HELLO from the peer. By contrast a DPD scheme needs to keep a 523 timestamp to keep track of the last received traffic from the peer 524 (thus marking beginning of the "idle period"). Once a DPD R-U-THERE 525 message has been sent, an implementation need only maintain a timer 526 to signal retransmission. Thus, the need to maintain active timer 527 state is reduced, resulting in a scalability improvement (assuming 528 maintaining a timestamp is less costly than an active timer). 529 Furthermore, since a DPD exchange only occurs if an entity has not 530 received traffic recently from its peer, the number of IKE messages 531 to be sent and processed is also reduced. As a consequence, the 532 scalability of DPD is much better than keepalives and heartbeats. 533 534 DPD maintains the HELLO/ACK model presented by keepalives, as it 535 follows that an exchange is initiated only by an entity interested in 536 the liveliness of its peer. 537 5386. Resistance to Replay Attack and False Proof of Liveliness 539 5406.1. Sequence Number in DPD Messages 541 542 To guard against message replay attacks and false proof of 543 liveliness, a 32-bit sequence number MUST be presented with each R- 544 U-THERE message. A responder to an R-U-THERE message MUST send an 545 R-U-THERE-ACK with the same sequence number. Upon receipt of the R- 546 U-THERE-ACK message, the initial sender SHOULD check the validity of 547 the sequence number. The initial sender SHOULD reject the R-U- 548 THERE-ACK if the sequence number fails to match the one sent with the 549 R-U-THERE message. 550 551 Additionally, both the receiver of the R-U-THERE and the R-U-THERE- 552 ACK message SHOULD check the validity of the Initiator and Responder 553 cookies presented in the SPI field of the payload. 554 555 556 557 558 559 560 561 562Huang, et al. Informational [Page 10] 563 564RFC 3706 Detecting Dead IKE Peers February 2004 565 566 5676.2. Selection and Maintenance of Sequence Numbers 568 569 As both DPD peers can initiate a DPD exchange (i.e., both peers can 570 send R-U-THERE messages), each peer MUST maintain its own sequence 571 number for R-U-THERE messages. The first R-U-THERE message sent in a 572 session MUST be a randomly chosen number. To prevent rolling past 573 overflowing the 32-bit boundary, the high-bit of the sequence number 574 initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST 575 increment the sequence number by one. Sequence numbers MAY reset at 576 the expiry of the IKE SA, moving to a newly chosen random number. 577 Each entity SHOULD also maintain its peer's R-U-THERE sequence 578 number, and an entity SHOULD reject the R-U-THERE message if it fails 579 to match the expected sequence number. 580 581 Implementations MAY maintain a window of acceptable sequence numbers, 582 but this specification makes no assumptions about how this is done. 583 Again, it is an implementation specific detail. 584 5857. Security Considerations 586 587 As the previous section highlighted, DPD uses sequence numbers to 588 ensure liveliness. This section describes the advantages of using 589 sequence numbers over random nonces to ensure liveliness. 590 591 While sequence numbers do require entities to keep per-peer state, 592 they also provide an added method of protection in certain replay 593 attacks. Consider a case where peer A sends peer B a valid DPD R-U- 594 THERE message. An attacker C can intercept this message and flood B 595 with multiple copies of the messages. B will have to decrypt and 596 process each packet (regardless of whether sequence numbers or nonces 597 are in use). With sequence numbers B can detect that the packets are 598 replayed: the sequence numbers in these replayed packets will not 599 match the incremented sequence number that B expects to receive from 600 A. This prevents B from needing to build, encrypt, and send ACKs. 601 By contrast, if the DPD protocol used nonces, it would provide no way 602 for B to detect that the messages are replayed (unless B maintained a 603 list of recently received nonces). 604 605 Another benefit of sequence numbers is that it adds an extra 606 assurance of the peer's liveliness. As long as a receiver verifies 607 the validity of a DPD R-U-THERE message (by verifying its incremented 608 sequence number), then the receiver can be assured of the peer's 609 liveliness by the very fact that the sender initiated the query. 610 Nonces, by contrast, cannot provide this assurance. 611 612 613 614 615 616 617 618Huang, et al. Informational [Page 11] 619 620RFC 3706 Detecting Dead IKE Peers February 2004 621 622 6238. IANA Considerations 624 625 There is no IANA action required for this document. DPD uses notify 626 numbers from the private range. 627 6289. References 629 6309.1. Normative Reference 631 632 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 633 Levels", BCP 14, RFC 2119, March 1997. 634 6359.2. Informative References 636 637 [2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 638 RFC 2409, November 1998. 639 640 [3] Kent, S. and R. Atkinson, "Security Architecture for the 641 Internet Protocol", RFC 2401, November 1998. 642 64310. Editors' Addresses 644 645 Geoffrey Huang 646 Cisco Systems, Inc. 647 170 West Tasman Drive 648 San Jose, CA 95134 649 650 Phone: (408) 525-5354 651 EMail: ghuang@cisco.com 652 653 654 Stephane Beaulieu 655 Cisco Systems, Inc. 656 2000 Innovation Drive 657 Kanata, ON 658 Canada, K2K 3E8 659 660 Phone: (613) 254-3678 661 EMail: stephane@cisco.com 662 663 664 Dany Rochefort 665 Cisco Systems, Inc. 666 124 Grove Street, Suite 205 667 Franklin, MA 02038 668 669 Phone: (508) 553-8644 670 EMail: danyr@cisco.com 671 672 673 674Huang, et al. Informational [Page 12] 675 676RFC 3706 Detecting Dead IKE Peers February 2004 677 678 67911. Full Copyright Statement 680 681 Copyright (C) The Internet Society (2004). This document is subject 682 to the rights, licenses and restrictions contained in BCP 78 and 683 except as set forth therein, the authors retain all their rights. 684 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 687 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 688 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 689 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 693Intellectual Property 694 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed 697 to pertain to the implementation or use of the technology 698 described in this document or the extent to which any license 699 under such rights might or might not be available; nor does it 700 represent that it has made any independent effort to identify any 701 such rights. Information on the procedures with respect to 702 rights in RFC documents can be found in BCP 78 and BCP 79. 703 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use 707 of such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository 709 at http://www.ietf.org/ipr. 710 711 The IETF invites any interested party to bring to its attention 712 any copyrights, patents or patent applications, or other 713 proprietary rights that may cover technology that may be required 714 to implement this standard. Please address the information to the 715 IETF at ietf-ipr@ietf.org. 716 717Acknowledgement 718 719 Funding for the RFC Editor function is currently provided by the 720 Internet Society. 721 722 723 724 725 726 727 728 729 730Huang, et al. Informational [Page 13] 731 732