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 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). DPD is sent over the IKE (phase 1) SA, so it does not explicitly verify the health of any negotiated phase 2 SA.
If there is incoming data traffic on ANY phase 2 selector from the IKE peer, FortiGate WILL NOT send DPD_R_U_THERE under any circumstance.
If phase1 configuration has 'set dpd on-idle': FortiGate will send DPD_R_U_THERE if it does not receive any IPsec (data) traffic from the remote peer. If multiple IPsec (phase 2) selectors are configured but only one has incoming data traffic, no DPD will be sent. If no IPsec SA is available, FortiGate WILL send DPD_R_U_THERE.
If phase1 configuration has 'set dpd on-demand': This is the default configuration. The behavior is like DPD 'idle', but with the additional requirement that FortiGate will only send the DPD_R_U_THERE if it has also sent data traffic over the IPsec tunnel during the previous DPD interval.
The device does not check whether the incoming traffic is related to the outgoing traffic. If there is incoming traffic on one phase2 selector and outgoing on another, FortiGate WILL NOT send DPD_R_U_THERE. If no phase2 selector is available, FortiGate WILL NOT send DPD_R_U_THERE.
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 the 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.
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.
