FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
MS_TAM3_FTNT
Staff
Staff

Description
This article provides information on the Dead Peer Detection (DPD) mechanism and how it is used to establish " proof of liveliness" (that an IKE peer is active).


Scope
IPSEC VPN

Solution
The FortiGate unit provides a mechanism called Dead Peer Detection (DPD), to reestablish VPN tunnels on idle connections and clean up dead IKE peers if required.
This feature minimizes the traffic required to check if a VPN peer is available or unavailable (dead).

IPSec devices will send DPD_R_U_THERE only if it has sent data over the IPsec tunnel during the previous DPD interval, but has not received any returning traffic over the tunnel.
If the traffic is mostly bi-directional, then an IPSec device might never send DPD packets, not even a single DPD_R_U_THERE, eventhough DPD is enabled.

According to  https://tools.ietf.org/html/draft-ietf-ipsec-dpd-04 :

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.

It is important to note that the decision about when to initiate a DPD exchange is implementation specific. 

https://tools.ietf.org/html/draft-ietf-ipsec-dpd-04#section-6.4 :
 
6.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.
 
 
6.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.
  
Conclusion:

  • Each peer's DPD state is largely independent of the other's.
  • A FortiGate is free to request proof of liveliness when it needs it -- not at mandated intervals.  
Contributors