IPSec VPN Design [Electronic resources] نسخه متنی

IKE Keepalives

IPSec is a peer-to-peer type of technology; IP reachability between IPSec peers is required for an IPSec session to be established between them. It is possible that IP connectivity may be lost between the peers due to routing problems, peer reloading, or some other situation. In such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. The IPSec control plane protocol (IKE) is based on UDP and is, therefore, inherently connectionless; the IKE and IPSec security associations (SAs) established between the peers can remain until their lifetimes naturally expire. This lack of IPSec session liveliness creates "black holes" where traffic is lost. It is highly desirable to recognize these "black holes" as soon as possible, primarily because the IPSec SAs consume expensive CPU cycles when one side of the session continues to encrypt traffic to its unreachable peer. Also, the lack of failure detection of a peer may prevent the activation of an alternate backup peer. Finally, when reachability to the peer is restored, the peer may have no IKE or IPSec SAs, and the encrypted packets destined to the peer will be dropped by the peer, as it has no valid SA. Hence, the old IKE and IPSec SAs that are still present are really invalid and may preclude the creation of new IPSec SAs.

A keepalive mechanism, wherein the peers exchange some type of message to inform each other that they are alive, will help resolve these issues. Interestingly enough, the IKE protocol specification has no notion of such a keepalive mechanism. Cisco IOS allows the configuration of an IKE periodic keepalive mechanism that can be configured between IOS IPSec peers. Example 3-1 shows the configuration of an IKE keepalive in IOS from SPOKE-1-EAST's standpoint.

Example 3-1. IKE Keepalive Configuration on SPOKE-1-EAST

spoke-1-east
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 3

IKE keepalive messages are exchanged periodically by each peer to declare their availability. If three consecutive keepalive messages are unacknowledged, the associated peer is unreachable and the associated SAs should be removed and an IPSec tunnel built to a backup peer if one is present. In the above example, keepalives are sent every 60 seconds and the retry is a default value of 3, which means that it will take 180 seconds (60 times 3) to declare the IPSec endpoint dead. IKE keepalives are encrypted and authenticated, just like other IKE IPSec packets.

Note

The IKE keepalive mechanism has its limitations. The mechanism is able to detect the status of only the IKE SAs and endpoints. However, there may be cases in which the IKE peer is reachable, but its protected networks behind the peer are not. In that case, IKE keepalives do not help.

The IKE keepalive mechanism works fine to detect dead IKE peers and prevent "black holes" and conserve expensive CPU resources; however, one of the limitations of the IKE keepalive mechanism is its scalability. An IPSec router that is terminating a few thousand site-to-site IPSec sessions with IKE keepalives turned on will consume expensive CPU cycles for the housekeeping of the IKE keepalive messages, thereby limiting the scalability of the number of IPSec sessions that can be terminated by this router. An alternative mechanism to the IKE keepalive is known as Dead Peer Detection (DPD), discussed in the next section.