Dead Peer Detection

Document

Jan 29, 2010 3:59 AM
Jan 29th, 2010

All information is based on a series of tests and provided "AS IS" without warranty of any kind.

Contents

  • 1 Introduction
  • 2 DPD on routers
  • 3 DPD on ASA
  • 4 DPD in IPSec VPN Client 4.8 - 5.0.04.0300
  • 5 DPD in IPSec VPN Client 5.0.05.0290
  • 6 Relevant Cisco VPN Client Parameters
  • 7 Common Pitfalls

Introduction

Dead Peer Detection (DPD) is a method that allows detection of unreachable Internet Key Exchange (IKE) peers. DPD is described in the informational RFC 3706: "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers" authored by G. Huang, S. Beaulieu, D. Rochefort.

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.


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 the RFC doesn't 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.


Thanks authors. We now have at least four (!) different implementations of DPD on Cisco gear.

DPD on routers

Cisco routers support two DPD types: On-demand DPD and Periodic DPD:

crypro isakmp keepalive <threshold> <retry-interval> {[on-demand] | periodic}

In case of on-demand DPD a router sends its R-U-THERE message to a peer if there is a traffic to send to the peer and the peer was idle for <threshold> seconds (i.e. there was no traffic from the peer for <threshold> seconds). On-demand DPD was introduced in IOS 12.2(8)T and the implementation has changed multiple times since then.

In case of periodic DPD a router sends its R-U-THERE messages at regular intervals. It doesn't take into consideration traffic coming from peer. This is the only Cisco platform that supports true periodic DPD. Periodic DPD was introduced in IOS 12.3(7)T and the implementation has changed multiple times since then.

Specifically, in the DDTS CSCin76641 (IOS 12.3(09.08)T) a decision was made to not send R-U-THERE request when the periodic DPD is configured and a traffic is received from the peer. Finally, it has reverted to the original behavior. See DDTS CSCsh12853 (12.4(13.11)T 12.4(11)T02 12.4(09)T05 12.4(06)T08) for details.

Periodic DPD can improve convergence in some scenarios.

DPD is disabled by default on Cisco routers. The default mode is "on-demand" if not specified.

If the peer doesn't respond with the R-U-THERE-ACK the router starts retransmitting R-U-THERE messages every <retry-interval> seconds with a maximum of five retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on Cisco routers.

Also, it is possible to configure DPD in ISAKMP profiles. The caveat, however, is that there are no "periodic" and "on-demand" configuration options. So, the ISAKMP profile will inherit global setting. I.e., if you enable periodic DPD globally, all your ISAKMP profiles will operate in "periodic" DPD mode with profile-specific DPD timers.

crypto isakmp profile QQQ
keepalive <interval> retry <retry-interval>

Another caveat is that you cannot disable DPD completely. DPD is always negotiated, even if not configured or disabled in ISAKMP profile with "no keepalive". In this case the router will answer DPD requests with R-U-THERE-ACK, but will not initiate DPD requests with R-U-THERE ("one-way" mode).


In brief, on routers we have the following:

  • true periodic DPD and on-demand DPD
  • DPD cannot be completely disabled
  • one-way mode is supported and is the default mode
  • retry interval can be configured
  • retry count cannot be configured and equals to five

DPD on ASA

ASA and PIX firewalls support "semi-periodic" DPD only. I.e. they send R-U-THERE message to a peer if the peer was idle for <threshold> seconds. ASA may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every <threshold> seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.

Unlike routers, you can completely disable DPD on ASA and it will not negotiate it with a peer ("disable" configuration option).

Also, you can configure "one-way" DPD mode on ASA. The ASA will respond to R-U-THERE messages, but will not initiate DPD exchange ("threshold infinite" configuration option).

isakmp keepalive {disable | threshold <threshold> retry <retry-interval> | threshold infinite}

If the peer doesn't respond with the R-U-THERE-ACK the ASA starts retransmitting R-U-THERE messages every <retry-interval> seconds with a maximum of three retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on ASA.

DPD is enabled by default on ASA for both L2L and RA IPSec:

tunnel-group DefaultL2LGroup ipsec-attributes
isakmp keepalive threshold 10 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
isakmp keepalive threshold 300 retry 2

In brief, on ASA we have the following:

  • only "semi-periodic" DPD is supported
  • DPD can be completely disabled
  • one-way mode is supported
  • bidirectional mode is the default one
  • retry interval can be configured
  • retry count cannot be configured and equals to three

DPD in IPSec VPN Client 4.8 - 5.0.04.0300

It seems that Cisco VPN Client sends its R-U-THERE message to a peer if it has sent traffic to the peer, but hasn't received response back within ten seconds. This basically means that R-U-THERE messages are not sent if the VPN session is completely idle or the peer responds in a timely manner.

If the peer doesn't respond with the R-U-THERE-ACK the VPN Client starts retransmitting R-U-THERE messages every five seconds until "Peer response timeout" is reached. After that the peer is declared dead.

The only parameter that can be configured on the Cisco VPN Client is "Peer response timeout".

You cannot disable DPD in Cisco VPN Client GUI or configuration files. DPD is always used if negotiated with a peer. I.e. to disable DPD disable it on the peer.


In brief, on Cisco VPN Client we have the following:

  • very specific DPD algorithm is implemented
  • DPD can be disabled if disabled on a peer
  • most of DPD parameters cannot be configured
  • retry interval equals to five seconds
  • retry count is not used
  • "peer response timeout", which equals to 90 seconds by default, is used instead

DPD in IPSec VPN Client 5.0.05.0290

It seems that this version of Cisco VPN Client uses different DPD algorithm, which is similar to ASA "semi-periodic" DPD. I.e. the VPN Client sends its R-U-THERE message to a peer if the peer was idle for approximately ten seconds. The VPN Client may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every ten seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.


In brief, in this version we have the following:

  • in this version "semi-periodic" DPD is implemented
  • DPD can be disabled if disabled on a peer
  • most of DPD parameters cannot be configured
  • retry interval equals to five seconds
  • retry count is not used
  • "peer response timeout", which equals to 90 seconds by default, is used instead

Relevant Cisco VPN Client Parameters

Cisco VPN Client Parameters

ForceKeepAlives

There are rumors that this parameter does nothing since 4.6. However, it is still compiled into the VPN Client code even in the latest version. Also, this parameter is mentioned in the DDTS CSCso05782. Testing reveals that DPD bahavior is not changed whether you set it to 0 or 1 (at least on Windows XP). Your mileage may vary.

PeerTimeout

This is the "Peer response timeout" configured in the Cisco VPN Client GUI (the number of seconds to wait before terminating a connection because the VPN central-site device on the other end of the tunnel is not responding).

UseLegacyIKEPort

This parameter is set to 0 by default since 4.8.01. This means that the source UDP port, which is used by ISAKMP, will be greater than 1023. In this case VPN Client need not stop Microsoft IPSec Service on GUI startup. If the parameter is set to 1, then the source UDP port will be 500 (or 4500 if NAT-T is used) and the Client will stop Microsoft IPSec Service on GUI startup.

ForceNatT

Causes the VPN Client to negotiate NAT-T, even if there is no NAT device involved in the connection attempt. This helps with some firewalls' disconnecting the VPN Client unexpectedly.

Also, please note that NAT-T has its own keepalive mechanism which is used by Cisco VPN Client by default.

Common Pitfalls

The most common problem with DPD is Windows or network firewall that blocks server to client communications over UDP.

As mentioned above the VPN Client doesn't send R-U-THERE requests if it receives traffic from a server. The UDP state is not updated on the firewall and expires quickly. This results in the server not being able to propagate its R-U-THERE request to the client and the tunnel is dropped.

In this case it is possible to use "ForceNatT" parameter to encapsulate data into UDP. Now data traffic, DPD and NAT-T keepalives will be sent over UDP and the above situation is unlikely.


Also, watch out the following bugs:

  • CSCso05782 - Vista VPN client disconnect after few minutes - DPD enabled
  • CSCsz22256 - ASA disconnects IPSec VPN client at P2 rekey with vlan mapping in grppol
Average Rating: 5 (1 ratings)

Comments

d.serra Fri, 02/26/2010 - 06:52

I have yet to find a Doc that explains the timer values of this feature.  This one is no exception.  An example would be the command 'crypto isakmp keepalive 10 3'.  We know that keepalives will be sent every 10 seconds (when the router isn't getting a response in on-demand mode) and in the event of missed keepalives it will retry with 3 second intervals.  Which would be a more agressive polling.  But what I don't know and have seen no documentation from Cisco or in the RFC is how many 10 second polls does it have to miss before considering it a failure and moving to the more agressive mode polling every 3 seconds.  Are we to assume that if 1 poll is missed it will then 1 more agressive poll after 3 seconds and that is it?  This could cause much instability if a packet were lost in stransit.

CISCO, CAN YOU PLEASE CLARIFY THE TIMERS BETTER!?!?

otipisov Fri, 02/26/2010 - 09:07 (reply to d.serra)

This can easily be verified with a test and "debug crypto isakmp". For routers single lost keepalive should turn aggressive mode on. But you're right, there are many questions regarding timers. For example, how long should a router try to establish a tunnel to a non-responding peer? For example, if we have 3 "set peer" statements, the first peer is declared dead by DPD and the second peer doesn't respond to our connection attempts too. (So far as I know, initial attempt and 5 retries every 10 seconds and this is hardcoded. YMMV.)

emilio1973 Wed, 04/18/2012 - 04:24

One question: where is DPD configured?  Headend device or both (remote office and Headquarters). Thanks

mz331wcisco Fri, 01/18/2013 - 02:06

Hello

Regarding ASA DPDs, in the post mentions that if I put the command 'isakmp  keepalive disable' it will disable DPD, but testing showed that this is  not always the case.

Lab used:

ASA1 runs 8.0(2), ASA2 runs 8.4(2)

case 1

ASA1 (DPD enabled) --- ASA2 (DPD enabled)

test 1

ASA1 initiates the VPN

result:  one device sends (R-U-THERE) while the other peer will only reply  (R-U-THERE-ACK). Sometimes the devices will swap the roles during a VPN  session.

case 2

ASA1 (DPD enabled) --- ASA2 (DPD disabled)

test 1

ASA1 initiates the VPN

result: there are no DPDs exchanged

test 2

ASA2 initiates the VPN

result: ASA1 only sends DPDs (R-U-THERE). ASA2 only replies (R-U-THERE-ACK)

case 3

ASA1 (DPD disabled) --- ASA2 (DPD enabled)

test 1

ASA1 initiates the VPN

result: ASA2 only sends DPDs (R-U-THERE). ASA1 only replies (R-U-THERE-ACK)

Note - During the IKE P1 negotiation, after message 4 (MM) both peers send DPD VID as I see in the ASA1 debug:

'constructing dpd vid payload'

'Received DPD VID'

test 2

ASA2 initiates the VPN

result: there are no DPDs exchanged

Note - During the IKE P1 negotiation, after message 4 (MM) I see on ASA2:

'constructing dpd vid payload'

but on ASA1 I only see 'Received DPD VID'

so the command 'crypto isakmp disable' looks like it prevents the ASA from sending DPD VID when it is the responder

case 4

ASA1 (DPD disabled) --- ASA2 (DPD disabled)

result: no DPDs are exchanged between the 2 peers

Conclusions (unless GSN3 is fooling me):

  • If both peers have DPD enabled (default), there are DPDs exchanged.
  • If  only one side has DPD enabled, then only if peer who has DPD disabled  initiates the VPN tunnel will be DPDs exchanged. If the peer who has DPD  enabled initiates the tunnel there are no DPDs exchanged.
  • If both peers have DPD disabled, there are no DPDs exchanged.

What is not clear to me is why the peer which has DPD disabled still sends the DPD VID when initiates the tunnel.

Any thoughts on the above will be welcomed

Regards

Mikis

Actions

Login or Register to take actions

This Document

Posted January 29, 2010 at 3:59 AM
Stats:
Comments:4 Avg. Rating:5
Views:52970 Contributors:4
Shares:2
Categories: ASA
+

Related Content

Documents Leaderboard

Rank Username Points
1 65
2 56
3 55
4 30
5 24
Rank Username Points
5