Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000021970D
Original Publication Date: 2004-Feb-01
Included in the Prior Art Database: 2005-May-21
Document File: 14 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Huang: AUTHOR [+3]

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 9% of the total text.

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 Seq...