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

Document Type RFC - Informational (February 2004; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3706 (Informational)
Telechat date
Responsible AD Russ Housley
Send notices to <byfraser@cisco.com>, <tytso@mit.edu>
Network Working Group                                           G. Huang
Request for Comments: 3706                                   S. Beaulieu
Category: Informational                                     D. Rochefort
                                                     Cisco Systems, Inc.
                                                           February 2004

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

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document describes the method detecting a dead Internet Key
   Exchange (IKE) peer that is presently in use by a number of vendors.
   The method, called Dead Peer Detection (DPD) uses IPSec traffic
   patterns to minimize the number of IKE messages that are needed to
   confirm liveness.  DPD, like other keepalive mechanisms, is needed to
   determine when to perform IKE peer failover, and to reclaim lost
   resources.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Document Roadmap . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Rationale for Periodic Message Exchange for Proof of
       Liveliness . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Keepalives vs.  Heartbeats . . . . . . . . . . . . . . . . . .  3
       4.1.  Keepalives . . . . . . . . . . . . . . . . . . . . . . .  3
       4.2.  Heartbeats . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . .  6
       5.1.  DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . .  7
       5.2.  Message Exchanges. . . . . . . . . . . . . . . . . . . .  7
       5.3.  NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . .  8
       5.4.  Impetus for DPD Exchange . . . . . . . . . . . . . . . .  9
       5.5.  Implementation Suggestion. . . . . . . . . . . . . . . .  9
       5.6.  Comparisons. . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Resistance to Replay Attack and False Proof of Liveliness. . . 10
       6.1.  Sequence Number in DPD Messages. . . . . . . . . . . . . 10

Huang, et al.                Informational                      [Page 1]
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
Show full document text