RFC 3706 (rfc3706) - Page 2 of 13

A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

RFC 3706                Detecting Dead IKE Peers           February 2004


       6.2.  Selection and Maintenance of Sequence Numbers. . . . . . 11
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       9.1.  Normative Reference. . . . . . . . . . . . . . . . . . . 12
       9.2.  Informative References . . . . . . . . . . . . . . . . . 12
   10. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1.  Introduction

   When two peers communicate with IKE [2] and IPSec [3], the situation
   may arise in which connectivity between the two goes down
   unexpectedly.  This situation can arise because of routing problems,
   one host rebooting, etc., and in such cases, there is often no way
   for IKE and IPSec to identify the loss of peer connectivity.  As
   such, the SAs can remain until their lifetimes naturally expire,
   resulting in a "black hole" situation where packets are tunneled to
   oblivion.  It is often desirable to recognize black holes as soon as
   possible so that an entity can failover to a different peer quickly.
   Likewise, it is sometimes necessary to detect black holes to recover
   lost resources.

   This problem of detecting a dead IKE peer has been addressed by
   proposals that require sending periodic HELLO/ACK messages to prove
   liveliness.  These schemes tend to be unidirectional (a HELLO only)
   or bidirectional (a HELLO/ACK pair).  For the purpose of this
   document, the term "heartbeat" will refer to a unidirectional message
   to prove liveliness.  Likewise, the term "keepalive" will refer to a
   bidirectional message.

   The problem with current heartbeat and keepalive proposals is their
   reliance upon their messages to be sent at regular intervals.  In the
   implementation, this translates into managing some timer to service
   these message intervals.  Similarly, because rapid detection of the
   dead peer is often desired, these messages must be sent with some
   frequency, again translating into considerable overhead for message
   processing.  In implementations and installations where managing
   large numbers of simultaneous IKE sessions is of concern, these
   regular heartbeats/keepalives prove to be infeasible.

   To this end, a number of vendors have implemented their own approach
   to detect peer liveliness without needing to send messages at regular
   intervals.  This informational document describes the current
   practice of those implementations.  This scheme, called Dead Peer
   Detection (DPD), relies on IKE Notify messages to query the
   liveliness of an IKE peer.




Huang, et al.                Informational