summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3706.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3706.txt')
-rw-r--r--doc/rfc/rfc3706.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3706.txt b/doc/rfc/rfc3706.txt
new file mode 100644
index 0000000..3198e5e
--- /dev/null
+++ b/doc/rfc/rfc3706.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group G. Huang
+Request for Comments: 3706 S. Beaulieu
+Category: Informational D. Rochefort
+ Cisco Systems, Inc.
+ February 2004
+
+
+ A Traffic-Based Method of Detecting Dead Internet
+ Key Exchange (IKE) Peers
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes the method detecting a dead Internet Key
+ Exchange (IKE) peer that is presently in use by a number of vendors.
+ The method, called Dead Peer Detection (DPD) uses IPSec traffic
+ patterns to minimize the number of IKE messages that are needed to
+ confirm liveness. DPD, like other keepalive mechanisms, is needed to
+ determine when to perform IKE peer failover, and to reclaim lost
+ resources.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Rationale for Periodic Message Exchange for Proof of
+ Liveliness . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . 3
+ 4.1. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4.2. Heartbeats . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. Message Exchanges. . . . . . . . . . . . . . . . . . . . 7
+ 5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . . 8
+ 5.4. Impetus for DPD Exchange . . . . . . . . . . . . . . . . 9
+ 5.5. Implementation Suggestion. . . . . . . . . . . . . . . . 9
+ 5.6. Comparisons. . . . . . . . . . . . . . . . . . . . . . . 10
+ 6. Resistance to Replay Attack and False Proof of Liveliness. . . 10
+ 6.1. Sequence Number in DPD Messages. . . . . . . . . . . . . 10
+
+
+
+Huang, et al. Informational [Page 1]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ 6.2. Selection and Maintenance of Sequence Numbers. . . . . . 11
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
+ 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 9.1. Normative Reference. . . . . . . . . . . . . . . . . . . 12
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 12
+ 10. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1. Introduction
+
+ When two peers communicate with IKE [2] and IPSec [3], the situation
+ may arise in which connectivity between the two goes down
+ unexpectedly. This situation can arise because of routing problems,
+ one host rebooting, etc., and in such cases, there is often no way
+ for IKE and IPSec to identify the loss of peer connectivity. As
+ such, the SAs can remain until their lifetimes naturally expire,
+ resulting in a "black hole" situation where packets are tunneled to
+ oblivion. It is often desirable to recognize black holes as soon as
+ possible so that an entity can failover to a different peer quickly.
+ Likewise, it is sometimes necessary to detect black holes to recover
+ lost resources.
+
+ This problem of detecting a dead IKE peer has been addressed by
+ proposals that require sending periodic HELLO/ACK messages to prove
+ liveliness. These schemes tend to be unidirectional (a HELLO only)
+ or bidirectional (a HELLO/ACK pair). For the purpose of this
+ document, the term "heartbeat" will refer to a unidirectional message
+ to prove liveliness. Likewise, the term "keepalive" will refer to a
+ bidirectional message.
+
+ The problem with current heartbeat and keepalive proposals is their
+ reliance upon their messages to be sent at regular intervals. In the
+ implementation, this translates into managing some timer to service
+ these message intervals. Similarly, because rapid detection of the
+ dead peer is often desired, these messages must be sent with some
+ frequency, again translating into considerable overhead for message
+ processing. In implementations and installations where managing
+ large numbers of simultaneous IKE sessions is of concern, these
+ regular heartbeats/keepalives prove to be infeasible.
+
+ To this end, a number of vendors have implemented their own approach
+ to detect peer liveliness without needing to send messages at regular
+ intervals. This informational document describes the current
+ practice of those implementations. This scheme, called Dead Peer
+ Detection (DPD), relies on IKE Notify messages to query the
+ liveliness of an IKE peer.
+
+
+
+
+Huang, et al. Informational [Page 2]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC-2119 [1].
+
+2. Document Roadmap
+
+ As mentioned above, there are already proposed solutions to the
+ problem of detecting dead peers. Section 3 elaborates the rationale
+ for using an IKE message exchange to query a peer's liveliness.
+ Section 4 examines a keepalives-based approach as well as a
+ heartbeats-based approach. Section 5 presents the DPD proposal
+ fully, highlighting differences between DPD and the schemes presented
+ in Section 4 and emphasizing scalability issues. Section 6 examines
+ security issues surrounding replayed messages and false liveliness.
+
+3. Rationale for Periodic Message Exchange for Proof of Liveliness
+
+ As the introduction mentioned, it is often necessary to detect that a
+ peer is unreachable as soon as possible. IKE provides no way for
+ this to occur -- aside from waiting until the rekey period, then
+ attempting (and failing the rekey). This would result in a period of
+ loss connectivity lasting the remainder of the lifetime of the
+ security association (SA), and in most deployments, this is
+ unacceptable. As such, a method is needed for checking up on a
+ peer's state at will. Different methods have arisen, usually using
+ an IKE Notify to query the peer's liveliness. These methods rely on
+ either a bidirectional "keepalive" message exchange (a HELLO followed
+ by an ACK), or a unidirectional "heartbeat" message exchange (a HELLO
+ only). The next section considers both of these schemes.
+
+4. Keepalives vs. Heartbeats
+
+4.1. Keepalives:
+
+ Consider a keepalives scheme in which peer A and peer B require
+ regular acknowledgements of each other's liveliness. The messages
+ are exchanged by means of an authenticated notify payload. The two
+ peers must agree upon the interval at which keepalives are sent,
+ meaning that some negotiation is required during Phase 1. For any
+ prompt failover to be possible, the keepalives must also be sent at
+ rather frequent intervals -- around 10 seconds or so. In this
+ hypothetical keepalives scenario, peers A and B agree to exchange
+ keepalives every 10 seconds. Essentially, every 10 seconds, one peer
+ must send a HELLO to the other. This HELLO serves as proof of
+ liveliness for the sending entity. In turn, the other peer must
+ acknowledge each keepalive HELLO. If the 10 seconds elapse, and one
+ side has not received a HELLO, it will send the HELLO message itself,
+ using the peer's ACK as proof of liveliness. Receipt of either a
+
+
+
+Huang, et al. Informational [Page 3]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ HELLO or ACK causes an entity's keepalive timer to reset. Failure to
+ receive an ACK in a certain period of time signals an error. A
+ clarification is presented below:
+
+ Scenario 1:
+ Peer A's 10-second timer elapses first, and it sends a HELLO to B.
+ B responds with an ACK.
+
+ Peer A: Peer B:
+ 10 second timer fires; ------>
+ wants to know that B is alive;
+ sends HELLO.
+ Receives HELLO; acknowledges
+ A's liveliness;
+ <------ resets keepalive timer, sends
+ ACK.
+ Receives ACK as proof of
+ B's liveliness; resets timer.
+
+ Scenario 2:
+ Peer A's 10-second timer elapses first, and it sends a HELLO to B.
+ B fails to respond. A can retransmit, in case its initial HELLO is
+ lost. This situation describes how peer A detects its peer is dead.
+
+ Peer A: Peer B (dead):
+
+ 10 second timer fires; ------X
+ wants to know that B is
+ alive; sends HELLO.
+
+ Retransmission timer ------X
+ expires; initial message
+ could have been lost in
+ transit; A increments
+ error counter and
+ sends another HELLO.
+
+ ---
+
+ After some number of errors, A assumes B is dead; deletes SAs and
+ possibly initiates failover.
+
+ An advantage of this scheme is that the party interested in the other
+ peer's liveliness begins the message exchange. In Scenario 1, peer A
+ is interested in peer B's liveliness, and peer A consequently sends
+
+
+
+
+
+
+Huang, et al. Informational [Page 4]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ the HELLO. It is conceivable in such a scheme that peer B would
+ never be interested in peer A's liveliness. In such a case, the onus
+ would always lie on peer A to initiate the exchange.
+
+4.2. Heartbeats:
+
+ By contrast, consider a proof-of-liveliness scheme involving
+ unidirectional (unacknowledged) messages. An entity interested in
+ its peer's liveliness would rely on the peer itself to send periodic
+ messages demonstrating liveliness. In such a scheme, the message
+ exchange might look like this:
+
+ Scenario 3: Peer A and Peer B are interested in each other's
+ liveliness. Each peer depends on the other to send periodic HELLOs.
+
+
+ Peer A: Peer B:
+ 10 second timer fires; ------>
+ sends HELLO. Timer also
+ signals expectation of
+ B's HELLO.
+ Receives HELLO as proof of A's
+ liveliness.
+
+ <------ 10 second timer fires; sends
+ HELLO.
+ Receives HELLO as proof
+ of B's liveliness.
+
+ Scenario 4:
+ Peer A fails to receive HELLO from B and marks the peer dead. This
+ is how an entity detects its peer is dead.
+
+ Peer A: Peer B (dead):
+ 10 second timer fires; ------X
+ sends HELLO. Timer also
+ signals expectation of
+ B's HELLO.
+
+ ---
+
+ Some time passes and A assumes B is dead.
+
+ The disadvantage of this scheme is the reliance upon the peer to
+ demonstrate liveliness. To this end, peer B might never be
+ interested in peer A's liveliness. Nonetheless, if A is interested
+ B's liveliness, B must be aware of this, and maintain the necessary
+ state information to send periodic HELLOs to A. The disadvantage of
+
+
+
+Huang, et al. Informational [Page 5]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ such a scheme becomes clear in the remote-access scenario. Consider
+ a VPN aggregator that terminates a large number of sessions (on the
+ order of 50,000 peers or so). Each peer requires fairly rapid
+ failover, therefore requiring the aggregator to send HELLO packets
+ every 10 seconds or so. Such a scheme simply lacks scalability, as
+ the aggregator must send 50,000 messages every few seconds.
+
+ In both of these schemes (keepalives and heartbeats), some
+ negotiation of message interval must occur, so that each entity can
+ know how often its peer expects a HELLO. This immediately adds a
+ degree of complexity. Similarly, the need to send periodic messages
+ (regardless of other IPSec/IKE activity), also increases
+ computational overhead to the system.
+
+5. DPD Protocol
+
+ DPD addresses the shortcomings of IKE keepalives- and heartbeats-
+ schemes by introducing a more reasonable logic governing message
+ exchange. Essentially, keepalives and heartbeats mandate exchange of
+ HELLOs at regular intervals. By contrast, with DPD, each peer's DPD
+ state is largely independent of the other's. A peer is free to
+ request proof of liveliness when it needs it -- not at mandated
+ intervals. This asynchronous property of DPD exchanges allows fewer
+ messages to be sent, and this is how DPD achieves greater
+ scalability.
+
+ As an elaboration, consider two DPD peers A and B. If there is
+ ongoing valid IPSec traffic between the two, there is little need for
+ proof of liveliness. The IPSec traffic itself serves as the proof of
+ liveliness. If, on the other hand, a period of time lapses during
+ which no packet exchange occurs, the liveliness of each peer is
+ questionable. Knowledge of the peer's liveliness, however, is only
+ urgently necessary if there is traffic to be sent. For example, if
+ peer A has some IPSec packets to send after the period of idleness,
+ it will need to know if peer B is still alive. At this point, peer A
+ can initiate the DPD exchange.
+
+ To this end, each peer may have different requirements for detecting
+ proof of liveliness. Peer A, for example, may require rapid
+ failover, whereas peer B's requirements for resource cleanup are less
+ urgent. In DPD, each peer can define its own "worry metric" - an
+ interval that defines the urgency of the DPD exchange. Continuing the
+ example, peer A might define its DPD interval to be 10 seconds.
+ Then, if peer A sends outbound IPSec traffic, but fails to receive
+ any inbound traffic for 10 seconds, it can initiate a DPD exchange.
+
+
+
+
+
+
+Huang, et al. Informational [Page 6]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ Peer B, on the other hand, defines its less urgent DPD interval to be
+ 5 minutes. If the IPSec session is idle for 5 minutes, peer B can
+ initiate a DPD exchange the next time it sends IPSec packets to A.
+
+ It is important to note that the decision about when to initiate a
+ DPD exchange is implementation specific. An implementation might
+ even define the DPD messages to be at regular intervals following
+ idle periods. See section 5.5 for more implementation suggestions.
+
+5.1. DPD Vendor ID
+
+ To demonstrate DPD capability, an entity must send the DPD vendor ID.
+ Both peers of an IKE session MUST send the DPD vendor ID before DPD
+ exchanges can begin. The format of the DPD Vendor ID is:
+
+ 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! !M!M!
+ ! HASHED_VENDOR_ID !J!N!
+ ! !R!R!
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,
+ 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond
+ to the current major and minor version of this protocol (1 and 0
+ respectively). An IKE peer MUST send the Vendor ID if it wishes to
+ take part in DPD exchanges.
+
+5.2. Message Exchanges
+
+ The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The
+ exchange is defined as:
+
+ Sender Responder
+ -------- -----------
+ HDR*, NOTIFY(R-U-THERE), HASH ------>
+
+ <------ HDR*, NOTIFY(R-U-THERE-
+ ACK), HASH
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al. Informational [Page 7]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK
+ corresponds to an "ACK." Both messages are simply ISAKMP Notify
+ payloads, and as such, this document defines these two new ISAKMP
+ Notify message types:
+
+ Notify Message Value
+ R-U-THERE 36136
+ R-U-THERE-ACK 36137
+
+ An entity that has sent the DPD Vendor ID MUST respond to an R-U-
+ THERE query. Furthermore, an entity MUST reject unencrypted R-U-
+ THERE and R-U-THERE-ACK messages.
+
+5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format
+
+ When sent, the R-U-THERE message MUST take the following form:
+
+ 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Domain of Interpretation (DOI) !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Protocol-ID ! SPI Size ! Notify Message Type !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! !
+ ~ Security Parameter Index (SPI) ~
+ ! !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Notification Data !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and
+ Payload Length fields should be set accordingly. The remaining
+ fields are set as:
+
+ - Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.
+
+ - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP.
+
+ - SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of
+ two octet-sized ISAKMP cookies.
+
+ - Notify Message Type (2 octets) - MUST be set to R-U-THERE
+
+
+
+
+
+
+Huang, et al. Informational [Page 8]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+ - Security Parameter Index (16 octets) - SHOULD be set to the
+ cookies of the Initiator and Responder of the IKE SA (in that
+ order)
+
+ - Notification Data (4 octets) - MUST be set to the sequence number
+ corresponding to this message
+
+ The format of the R-U-THERE-ACK message is the same, with the
+ exception that the Notify Message Type MUST be set to R-U-THERE-ACK.
+ Again, the Notification Data MUST be sent to the sequence number
+ corresponding to the received R-U-THERE message.
+
+5.4. Impetus for DPD Exchange
+
+ Again, rather than relying on some negotiated time interval to force
+ the exchange of messages, DPD does not mandate the exchange of R-U-
+ THERE messages at any time. Instead, an IKE peer SHOULD send an R-
+ U-THERE query to its peer only if it is interested in the liveliness
+ of this peer. To this end, if traffic is regularly exchanged between
+ two peers, either peer SHOULD use this traffic as proof of
+ liveliness, and both peers SHOULD NOT initiate a DPD exchange.
+
+ A peer MUST keep track of the state of a given DPD exchange. That
+ is, once it has sent an R-U-THERE query, it expects an ACK in
+ response within some implementation-defined period of time. An
+ implementation SHOULD retransmit R-U-THERE queries when it fails to
+ receive an ACK. After some number of retransmitted messages, an
+ implementation SHOULD assume its peer to be unreachable and delete
+ IPSec and IKE SAs to the peer.
+
+5.5. Implementation Suggestion
+
+ Since the liveliness of a peer is only questionable when no traffic
+ is exchanged, a viable implementation might begin by monitoring
+ idleness. Along these lines, a peer's liveliness is only important
+ when there is outbound traffic to be sent. To this end, an
+ implementation can initiate a DPD exchange (i.e., send an R-U-THERE
+ message) when there has been some period of idleness, followed by the
+ desire to send outbound traffic. Likewise, an entity can initiate a
+ DPD exchange if it has sent outbound IPSec traffic, but not received
+ any inbound IPSec packets in response. A complete DPD exchange
+ (i.e., transmission of R-U-THERE and receipt of corresponding R-U-
+ THERE-ACK) will serve as proof of liveliness until the next idle
+ period.
+
+ Again, since DPD does not mandate any interval, this "idle period"
+ (or "worry metric") is left as an implementation decision. It is not
+ a negotiated value.
+
+
+
+Huang, et al. Informational [Page 9]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+5.6. Comparisons
+
+ The performance benefit that DPD offers over traditional keepalives-
+ and heartbeats-schemes comes from the fact that regular messages do
+ not need to be sent. Returning to the examples presented in section
+ 4.1, a keepalive implementation such as the one presented would
+ require one timer to signal when to send a HELLO message and another
+ timer to "timeout" the ACK from the peer (this could also be the
+ retransmit timer). Similarly, a heartbeats scheme such as the one
+ presented in section 4.2 would need to keep one timer to signal when
+ to send a HELLO, as well as another timer to signal the expectation
+ of a HELLO from the peer. By contrast a DPD scheme needs to keep a
+ timestamp to keep track of the last received traffic from the peer
+ (thus marking beginning of the "idle period"). Once a DPD R-U-THERE
+ message has been sent, an implementation need only maintain a timer
+ to signal retransmission. Thus, the need to maintain active timer
+ state is reduced, resulting in a scalability improvement (assuming
+ maintaining a timestamp is less costly than an active timer).
+ Furthermore, since a DPD exchange only occurs if an entity has not
+ received traffic recently from its peer, the number of IKE messages
+ to be sent and processed is also reduced. As a consequence, the
+ scalability of DPD is much better than keepalives and heartbeats.
+
+ DPD maintains the HELLO/ACK model presented by keepalives, as it
+ follows that an exchange is initiated only by an entity interested in
+ the liveliness of its peer.
+
+6. Resistance to Replay Attack and False Proof of Liveliness
+
+6.1. Sequence Number in DPD Messages
+
+ To guard against message replay attacks and false proof of
+ liveliness, a 32-bit sequence number MUST be presented with each R-
+ U-THERE message. A responder to an R-U-THERE message MUST send an
+ R-U-THERE-ACK with the same sequence number. Upon receipt of the R-
+ U-THERE-ACK message, the initial sender SHOULD check the validity of
+ the sequence number. The initial sender SHOULD reject the R-U-
+ THERE-ACK if the sequence number fails to match the one sent with the
+ R-U-THERE message.
+
+ Additionally, both the receiver of the R-U-THERE and the R-U-THERE-
+ ACK message SHOULD check the validity of the Initiator and Responder
+ cookies presented in the SPI field of the payload.
+
+
+
+
+
+
+
+
+Huang, et al. Informational [Page 10]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+6.2. Selection and Maintenance of Sequence Numbers
+
+ As both DPD peers can initiate a DPD exchange (i.e., both peers can
+ send R-U-THERE messages), each peer MUST maintain its own sequence
+ number for R-U-THERE messages. The first R-U-THERE message sent in a
+ session MUST be a randomly chosen number. To prevent rolling past
+ overflowing the 32-bit boundary, the high-bit of the sequence number
+ initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST
+ increment the sequence number by one. Sequence numbers MAY reset at
+ the expiry of the IKE SA, moving to a newly chosen random number.
+ Each entity SHOULD also maintain its peer's R-U-THERE sequence
+ number, and an entity SHOULD reject the R-U-THERE message if it fails
+ to match the expected sequence number.
+
+ Implementations MAY maintain a window of acceptable sequence numbers,
+ but this specification makes no assumptions about how this is done.
+ Again, it is an implementation specific detail.
+
+7. Security Considerations
+
+ As the previous section highlighted, DPD uses sequence numbers to
+ ensure liveliness. This section describes the advantages of using
+ sequence numbers over random nonces to ensure liveliness.
+
+ While sequence numbers do require entities to keep per-peer state,
+ they also provide an added method of protection in certain replay
+ attacks. Consider a case where peer A sends peer B a valid DPD R-U-
+ THERE message. An attacker C can intercept this message and flood B
+ with multiple copies of the messages. B will have to decrypt and
+ process each packet (regardless of whether sequence numbers or nonces
+ are in use). With sequence numbers B can detect that the packets are
+ replayed: the sequence numbers in these replayed packets will not
+ match the incremented sequence number that B expects to receive from
+ A. This prevents B from needing to build, encrypt, and send ACKs.
+ By contrast, if the DPD protocol used nonces, it would provide no way
+ for B to detect that the messages are replayed (unless B maintained a
+ list of recently received nonces).
+
+ Another benefit of sequence numbers is that it adds an extra
+ assurance of the peer's liveliness. As long as a receiver verifies
+ the validity of a DPD R-U-THERE message (by verifying its incremented
+ sequence number), then the receiver can be assured of the peer's
+ liveliness by the very fact that the sender initiated the query.
+ Nonces, by contrast, cannot provide this assurance.
+
+
+
+
+
+
+
+Huang, et al. Informational [Page 11]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+8. IANA Considerations
+
+ There is no IANA action required for this document. DPD uses notify
+ numbers from the private range.
+
+9. References
+
+9.1. Normative Reference
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+9.2. Informative References
+
+ [2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+ RFC 2409, November 1998.
+
+ [3] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+10. Editors' Addresses
+
+ Geoffrey Huang
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ Phone: (408) 525-5354
+ EMail: ghuang@cisco.com
+
+
+ Stephane Beaulieu
+ Cisco Systems, Inc.
+ 2000 Innovation Drive
+ Kanata, ON
+ Canada, K2K 3E8
+
+ Phone: (613) 254-3678
+ EMail: stephane@cisco.com
+
+
+ Dany Rochefort
+ Cisco Systems, Inc.
+ 124 Grove Street, Suite 205
+ Franklin, MA 02038
+
+ Phone: (508) 553-8644
+ EMail: danyr@cisco.com
+
+
+
+Huang, et al. Informational [Page 12]
+
+RFC 3706 Detecting Dead IKE Peers February 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Huang, et al. Informational [Page 13]
+