| blob | 3198e5e9e56f3a479f72d0a75ce599bbb91f91f2 |
7 Network Working Group G. Huang
8 Request for Comments: 3706 S. Beaulieu
9 Category: Informational D. Rochefort
10 Cisco Systems, Inc.
11 February 2004
14 A Traffic-Based Method of Detecting Dead Internet
15 Key Exchange (IKE) Peers
17 Status of this Memo
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.
23 Copyright Notice
25 Copyright (C) The Internet Society (2004). All Rights Reserved.
27 Abstract
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.
37 Table of Contents
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
58 Huang, et al. Informational [Page 1]
59 \f
60 RFC 3706 Detecting Dead IKE Peers February 2004
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
72 1. Introduction
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.
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.
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.
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.
114 Huang, et al. Informational [Page 2]
115 \f
116 RFC 3706 Detecting Dead IKE Peers February 2004
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].
123 2. Document Roadmap
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.
134 3. Rationale for Periodic Message Exchange for Proof of Liveliness
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.
149 4. Keepalives vs. Heartbeats
151 4.1. Keepalives:
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
170 Huang, et al. Informational [Page 3]
171 \f
172 RFC 3706 Detecting Dead IKE Peers February 2004
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:
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.
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.
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.
199 Peer A: Peer B (dead):
201 10 second timer fires; ------X
202 wants to know that B is
203 alive; sends HELLO.
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.
212 ---
214 After some number of errors, A assumes B is dead; deletes SAs and
215 possibly initiates failover.
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
226 Huang, et al. Informational [Page 4]
227 \f
228 RFC 3706 Detecting Dead IKE Peers February 2004
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.
235 4.2. Heartbeats:
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:
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.
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.
255 <------ 10 second timer fires; sends
256 HELLO.
257 Receives HELLO as proof
258 of B's liveliness.
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.
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.
270 ---
272 Some time passes and A assumes B is dead.
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
282 Huang, et al. Informational [Page 5]
283 \f
284 RFC 3706 Detecting Dead IKE Peers February 2004
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.
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.
301 5. DPD Protocol
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.
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.
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.
338 Huang, et al. Informational [Page 6]
339 \f
340 RFC 3706 Detecting Dead IKE Peers February 2004
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.
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.
352 5.1. DPD Vendor ID
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:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
372 5.2. Message Exchanges
374 The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The
375 exchange is defined as:
377 Sender Responder
378 -------- -----------
379 HDR*, NOTIFY(R-U-THERE), HASH ------>
381 <------ HDR*, NOTIFY(R-U-THERE-
382 ACK), HASH
394 Huang, et al. Informational [Page 7]
395 \f
396 RFC 3706 Detecting Dead IKE Peers February 2004
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:
404 Notify Message Value
405 R-U-THERE 36136
406 R-U-THERE-ACK 36137
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.
412 5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format
414 When sent, the R-U-THERE message MUST take the following form:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
436 - Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.
438 - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP.
440 - SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of
441 two octet-sized ISAKMP cookies.
443 - Notify Message Type (2 octets) - MUST be set to R-U-THERE
450 Huang, et al. Informational [Page 8]
451 \f
452 RFC 3706 Detecting Dead IKE Peers February 2004
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)
459 - Notification Data (4 octets) - MUST be set to the sequence number
460 corresponding to this message
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.
467 5.4. Impetus for DPD Exchange
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.
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.
485 5.5. Implementation Suggestion
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.
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.
506 Huang, et al. Informational [Page 9]
507 \f
508 RFC 3706 Detecting Dead IKE Peers February 2004
511 5.6. Comparisons
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.
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.
538 6. Resistance to Replay Attack and False Proof of Liveliness
540 6.1. Sequence Number in DPD Messages
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.
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.
562 Huang, et al. Informational [Page 10]
563 \f
564 RFC 3706 Detecting Dead IKE Peers February 2004
567 6.2. Selection and Maintenance of Sequence Numbers
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.
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.
585 7. Security Considerations
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.
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).
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.
618 Huang, et al. Informational [Page 11]
619 \f
620 RFC 3706 Detecting Dead IKE Peers February 2004
623 8. IANA Considerations
625 There is no IANA action required for this document. DPD uses notify
626 numbers from the private range.
628 9. References
630 9.1. Normative Reference
632 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
633 Levels", BCP 14, RFC 2119, March 1997.
635 9.2. Informative References
637 [2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
638 RFC 2409, November 1998.
640 [3] Kent, S. and R. Atkinson, "Security Architecture for the
641 Internet Protocol", RFC 2401, November 1998.
643 10. Editors' Addresses
645 Geoffrey Huang
646 Cisco Systems, Inc.
647 170 West Tasman Drive
648 San Jose, CA 95134
650 Phone: (408) 525-5354
651 EMail: ghuang@cisco.com
654 Stephane Beaulieu
655 Cisco Systems, Inc.
656 2000 Innovation Drive
657 Kanata, ON
658 Canada, K2K 3E8
660 Phone: (613) 254-3678
661 EMail: stephane@cisco.com
664 Dany Rochefort
665 Cisco Systems, Inc.
666 124 Grove Street, Suite 205
667 Franklin, MA 02038
669 Phone: (508) 553-8644
670 EMail: danyr@cisco.com
674 Huang, et al. Informational [Page 12]
675 \f
676 RFC 3706 Detecting Dead IKE Peers February 2004
679 11. Full Copyright Statement
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.
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.
693 Intellectual Property
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.
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.
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.
717 Acknowledgement
719 Funding for the RFC Editor function is currently provided by the
720 Internet Society.
730 Huang, et al. Informational [Page 13]
731 \f