Dead Peer Detection (DPD) is a method that allows detection of unreachable Internet Key Exchange (IKE) peers.
This RFC describes DPD negotiation procedure and two new ISAKMP NOTIFY messages. Specifically, DPD is negotiated via an exchange of the DPD ISAKMP Vendor ID payload, which is sent in the ISAKMP MM messages 3 and 4 or ISAKMP AM messages 1 and 2. DPD Requests are sent as ISAKMP R-U-THERE messages and DPD Responses are sent as ISAKMP R-U-THERE-ACK messages.
Configure Dead peer detection in Cisco ASA firewall.
Configure dead peer detection in Cisco router.
Let’s understand Dead peer detection (DPD) with scenario-
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.
The primary idea of DPD is as follows:
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.
It is important to note that the decision about when to initiate a DPD exchange is implementation specific. IKE peer should send an R-U-THERE query to its peer if it is interested in the liveliness of this peer. An implementation might even define the DPD messages to be at regular intervals following idle periods.
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.
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.
Thus it does not define specific DPD timers, retry intervals, retry counts or even algorithm to be used to initiate a DPD exchange. Almost everything is left to an implementation. DPD parameters are not negotiated by peers.