Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 3. Enhanced IPSec Features > Dead Peer Detection

Dead Peer Detection

Dead peer detection (DPD), defined in RFC 3706, is an alternative mechanism that is more scalable than the IKE keepalives in detecting dead IPSec peers. Unlike the keepalive mechanism, DPD does not send periodic messages to check liveliness of a peer. The fundamental premise behind DPD is that DPD is a traffic-based detection method. In other words, DPD specifies that when traffic is occurring between the peers; there is no need to send a keepalive to check for liveliness of the peer, as the IPSec traffic serves as implicit proof of the availability of the peer.

If, on the other hand, a period of time elapses during which no traffic is exchanged between the peers, the liveliness of each peer is questionable. Note also that liveliness of a peer is needed only if traffic is to be sent to the peer. For example, if SPOKE-1-EAST in Figure 3-1 has sent outbound IPSec packets towards the VPN-GW1-EAST and has not received any IPSec packets inbound from VPN-GW1-EAST for a period of idle time, you might expect that SPOKE-1-EAST will initiate a DPD exchange. However, if SPOKE-1-EAST does not have data traffic to send to VPN-GW1-EAST, it really does not need to know if it is alive.

By delaying the DPD exchange (which, when sent, is sent in parallel with the start of the data traffic), DPD avoids sending extra messages and allows more time for an intermediate network outage to recover. After all, if the intermediate network is not needed at a given time, why detect that it is currently down? Doing so might force IPSec re-keying before it is necessary.

DPD capability is negotiated between IPSec peers during IKE negotiation by using a DPD vendor ID, as shown in Figure 3-2.

Figure 3-2. DPD Vendor ID


The DPD vendor ID is 16 bytes long. The first 14 bytes are the HASHED_VENDOR_ID field, and take the value HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}. Even though this field is called HASHED_VENDOR_ID, the value of that this field is fixed, so it is not really vendor-specific. The last two bytes represent the current major (MJR) and minor (MNR) version of the protocol. An IKE peer must send the vendor ID if it wishes to take part in DPD exchanges.

Figure 3-3 shows the bidirectional DPD message exchange between the initiator and the responder, which means that for an R_U_THERE message, there should be a corresponding ACK.

Figure 3-3. DPD Message Exchange


The DPD message format is shown in Figure 3-4.

Figure 3-4. DPD Message Format


The protocol ID is set to 500 for ISAKMP, and the SPI length should be set to 16, which is equal to the length of the ISAKMP cookies—which, as we know from Chapter 2, “IPSec Overview,” serves as the SPI for IKE/ISAKMP. Table 3-1 lists the ISAKMP Notify message types.

Table 3-1. DPD ISAKMP Notify Message Types
NotifyMessage Value
R-U-THERE36136
R-U-THERE-ACK36137


Example 3-2 shows the DPD configuration on SPOKE-1-EAST. The configuration is essentially the same as the IKE keepalive configuration, except that two more timer parameters are provided to configure idle interval and retransmit interval.

Example 3-2. DPD Configuration

spoke-1-east

version 12.2
service log backtrace
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname spoke-1-east
!
enable password lab
!
clock timezone EST 0
ip subnet-zero
!
!
ip domain name cisco.com
!
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 9.1.1.35
crypto isakmp key Cisco address 9.1.1.36
crypto isakmp keepalive 60 2                                                            
!
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 ipsec-isakmp
 set peer 9.1.1.35
 set peer 9.1.1.36
 set transform-set test
 match address 100
!
interface Serial0/0
 ip address 9.1.1.146 255.255.255.252
 crypto map vpn
!
interface Ethernet0/1
 ip address 10.0.68.1 255.255.255.0
 half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145

!
access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255
!
!
line con 0
line aux 0
line vty 0 4
 password lab
 login
!
!
end

spoke-1-east#


spoke-1-east#show cry isa sa det
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication

Conn id Local           Remote         Encr Hash Auth DH Lifetime Capabilities
1       9.1.1.146       9.1.1.35       des  sha  psk  1  23:59:39 D                     

spoke-1-east# debug crypto isakmp

ISAKMP (0:1): purging node 942371640
ISAKMP: received ke message (4/1)
ISAKMP: DPD received kei with flags 0x8
ISAKMP (0:1): more than 60 seconds since last inbound data. Sending DPD.                
ISAKMP (0:1): DPD Sequence number 0x17815542
ISAKMP: set new node -1912932512 to QM_IDLE
ISAKMP (0:1): sending packet to 9.1.1.35 my_port 500 peer_port 500 (I) QM_IDLE          
ISAKMP (0:1): purging node -1912932512
ISAKMP (0:1): received packet from 9.1.1.35 dport 500 sport 500 (I) QM_IDLE
ISAKMP: set new node -1385918665 to QM_IDLE
ISAKMP (0:1): processing HASH payload. message ID = -1385918665
ISAKMP (0:1): processing NOTIFY R_U_THERE_ACK protocol 1                                
					        spi 0, message ID = -1385918665, sa = 82CFB8F8                                  
					ISAKMP (0:1): DPD/R_U_THERE_ACK received from peer 9.1.1.35, sequence 0x17815542        
ISAKMP (0:1): deleting node -1385918665 error FALSE reason "informational (in) state 1"
ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
ISAKMP (0:1): Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE


					  

The idle interval timer facilitates the fault detection and recovery of idle resources in the absence of a valid connection. Idle interval is the configured time wherein the peer (SPOKE-1-EAST) has not received any inbound data on its SA from the remote peer (VPN-GW1-EAST). As you can see from the debugs in Example 3-2, once the interval is hit, an R_U_THERE_MESSAGE is sent and the initiator expects an ACK back. If the ACK is not received, the R_U_THERE message will be retransmitted three times, depending on the retransmit interval, before the initiator declares the remote peer dead. In the case of Example 3-2, you can see that R_U_THERE_ACK was received from VPN-GW1-EAST.

Note

Note that two conditions have to be met before a DPD R_U_THERE_MESSAGE is sent. First, the idle timer must expire, and second, the router has to have data going out to the peer. If the second condition is not met, the message is not sent. This policy conserves resources.


The lack of data or a response from the remote peer (VPN-GW1-EAST) will cause the local peer (SPOKE-1-EAST) to clear the local IPSec connection and recover the security association resources assigned. After clearing the resources, it may attempt to reestablish a connection with the same peer or with an alternate peer (VPN-GW2-EAST).

The characteristics of dead peer detection make the protocol a much more scalable fault-detection mechanism than IKE keepalives, especially in the context of addressing the state of IPSec connections to thousands of remote peers. The detection of an invalid IPSec security association may occur quickly by setting the idle interval and retry interval to a fairly low value with relatively few retries. The key advantage to DPD is that the periodic polling that is seen in IKE keepalives is suppressed in DPD, saving system resources.

Note

If one of peers supports only the original IKE keepalive mechanism while the other peer supports the DPD mechanism, the peer running DPD will fall back to the traditional periodic ISAKMP keepalive method. It is important to note that there are cases in which periodic IKE keepalives are necessary. These cases occur when there is Network Address Translation (NAT) or a firewall between the two peers. In such cases, periodic keepalives are required to refresh the state entries on the NAT or the firewall box. In the section “NAT Traversal (NAT-T),” which appears later in this chapter, you will examine a feature known as NAT Traversal. NAT Traversal has a NAT keepalive mechanism that negates the need for periodic IKE keepalive messages for maintaining state information on the NAT or firewall box.


Both IKE keepalives and DPD are useful mechanisms, but each has its limitations. For instance, they only detect if the IKE SAs and the endpoints are alive. They are useful if the path between the IKE peer fails for some reason, and the peer endpoints are not reachable from one another. On the other hand, if the IKE endpoints are reachable but the protected networks behind the endpoints are not, then these mechanisms cannot prevent the black-holing of traffic after it reaches the IKE endpoint.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint