[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                         Andrew Krywaniuk
IP Security Working Group                   Alcatel Networks Corporation
Internet Draft                                                T. Kivinen
                                             SSH Communications Security
                                                           July 14, 2000



            Using Isakmp Heartbeats for Dead Peer Detection
                  <draft-ietf-ipsec-heartbeats-01.txt>

Status of this Memo

   This document is a submission to the IETF Internet Protocol Security
   (IPsec) Working Group. Comments are solicited and should be addressed
   to the working group mailing list (ipsec@lists.tislabs.com) or to the
   editor.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice


   This document is a product of the IETF's IPsec Working Group.
   Copyright (C) The Internet Society (2000).  All Rights Reserved.








Krywaniuk               Expires January 14, 2001                [Page 1]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


Abstract


   This document describes a method for sending heartbeat packets
   (sometimes called keep-alives) across an ISAKMP SA in order to detect
   when a peer has crashed or has become otherwise unreachable. A method
   for negotiating the heartbeat parameters is also provided.











































IPsec Working Group                                             [Page 2]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


Table of Contents

   1. Introduction....................................................4
   2. Specification of Requirements...................................4
   3. Changes Since Last Revision.....................................4
   4. Document Roadmap................................................4
   5. Terminology Used Throughout This Document.......................5
   6. Basic Packet Format.............................................5
   6.1 The SEQ_NO Payload.............................................6
   6.2 The HASH Payload...............................................7
   6.3 The NOTIFY(Still Connected) Payload............................7
   7. The Heartbeat Protocol..........................................8
   7.1 Sending Heartbeat Packets......................................8
   7.2 Receiving Heartbeat Packets....................................8
   7.3 Receiver Background Tasks......................................8
   8. Heartbeat Negotiation Protocol..................................9
   8.1 Negotiation Transport..........................................9
   8.2 Heartbeat Configuration Attributes.............................9
   8.3 Sample Heartbeat Negotiations.................................11
   9. The SPI_LIST Payload...........................................12
   9.1 Payload Format................................................13
   9.2 Using the SPI list............................................14
   10. Use of Values from the Private Range..........................14
   11. General Approach..............................................15
   11.1 Security Considerations......................................15
   11.2 Goals of the Heartbeat Protocol..............................16
   11.3 Design Considerations........................................17
   12. Implementation Hints..........................................18
   12.1 Terminology Used in This Section.............................18
   12.2 Suggested Values for Heartbeat Parameters....................19
   12.3 Optimizing for Speed.........................................20
   12.4 Optimizing for Reliability...................................20
   12.5 Optimizing for State.........................................21
   12.6 Filtering Heartbeat Packets..................................21
   12.7 Managing the Sequence Number.................................22
   12.8 Use of the SPI List..........................................22
   12.9 Rules for Negotiation........................................23
   12.10 Dealing with Dangling SAs...................................24
   12.11 Dependence on ISAKMP-Config.................................25
   13. Security Considerations.......................................25
   14. Acknowledgments...............................................26
   15. References....................................................26
   Appendix A. Future Considerations.................................26
   Appendix B. Other Dead Peer Detection Techniques..................29
   B.1 Terminology Used in This Section..............................29
   B.2 Design Alternatives...........................................29




IPsec Working Group                                             [Page 3]


Internet Draft            ISAKMP Heartbeats                July 14, 2000



1.   Introduction

   Heartbeat packets have often been used (particularly at the link
   layer) to detect when a peer has crashed (hung up, etc.) in order
   that the necessary corrective or cleanup action can be performed.

   When the link is secured using the IPsec protocol suite, special
   precautions must be taken in order to ensure that the heartbeat
   packets are also sent in a secure manner.

   This document describes a method for negotiating and implementing a
   heartbeat protocol that runs on top of ISAKMP. This protocol prevents
   an adversary from generating false proof of liveness/deadness in a
   manner that is resistant to a variety of DoS attacks.


2.   Specification of Requirements

   This document shall use the keywords "MUST", "MUST NOT",
   "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They
   are to be interpreted as described in [Bradner97].


3.   Changes Since Last Revision

   The document has been reorganized based on comments since the initial
   revision. Protocol specifications have been moved closer to the
   beginning of the document; background information and implementation
   hints have been moved closer to the end. The details of the protocol
   have not been significantly altered, due to a lack of agreement among
   WG members as to what, if any, changes are required.


4.   Document Roadmap

   Sections 5-10 provide the technical details of the protocol.

   Section 11 provides background information regarding the protocol
   design. It elucidates the goals of the protocol and it explains how
   the protocol can be extended.

   Section 12 provides a variety of implementation hints. Many of these
   will aid in interoperability with existing IPsec implementations.





IPsec Working Group                                             [Page 4]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


5.   Terminology Used Throughout This Document

   The term 'keep-alive' literally refers to an exchange which keeps a
   connection open by periodically exchanging packets with the peer.
   Over time, the term has also come to refer to an exchange which
   detects if the connection is still open. If this detection mechanism
   can trigger an action which will restore the connection when it goes
   down then it is still, in effect, functioning as a keep-alive.

   This document uses the term 'heartbeat' to refer to a category of
   periodic keep-alive packets which can be used to determine the
   current liveness or reachability of the peer (in the same way that a
   doctor might use a heartbeat to determine if a patient is alive or
   dead). However, a heartbeat does not attempt to keep the connection
   open by defeating the peer's inactivity timeout mechanism.

   A 'proof of liveness' is a payload or message which indicates that
   the peer is still up and running, and is capable of sending and
   receiving traffic on the given ISAKMP SA.

   A 'dead peer' is a peer that has failed, rebooted, or is otherwise
   unable to communicate with the host using the ISAKMP SA. For
   convenience's sake, we include the case where the connection between
   the peers has gone down (e.g. the user hung-up, there was a routing
   error, the ISAKMP SA was deleted, etc).

   The 'sender' is the term that is used to identify the host who sends
   the heartbeat packets. Similarly, the 'receiver' is the host who
   receives the heartbeats.

   Throughout this memo, the 'initiator' refers to the host who
   initiated the heartbeat negotiation (not the initiator of the ISAKMP
   SA). The term 'responder' is interpreted likewise. Note that
   currently the initiator will always be the receiver of heartbeats and
   the responder will always be the sender.


6.   Basic Packet Format

   The heartbeat exchange is unidirectional. In other words, it is a one
   packet exchange.









IPsec Working Group                                             [Page 5]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   The format of the packet looks like this:

       Sender                                 Receiver
     -----------                             -----------
       HDR*, SEQ_NO, HASH,
       NOTIFY(Still Connected)     -->
       [,EXTRA PAYLOADS]

   An implementation MUST use the above payload order.

   The Exchange Type field in the ISAKMP header MUST be set to
   HEARTBEAT_MODE. HEARTBEAT_MODE has been assigned the value 251 from
   the private range.

   The SEQ_NO payload allows the receiver to discard packets that may
   have been spoofed or replayed. It is described in section 6.1.

   The HASH payload is described in section 6.2.

   The NOTIFY(Still Connected) payload is what actually provides the
   liveness proof. It is described in section 6.3.

   A host MAY choose to add extra payloads to the end of the message.
   However, these payloads SHOULD be ignored unless they have been
   enabled via the Heartbeat Negotiation Protocol or by a vendor-
   specific extension mechanism.


6.1   The SEQ_NO Payload

   The SEQ_NO payload is a new ISAKMP payload with value 217 (from the
   private range).

   It has this format:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                       Sequence Number                         !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sequence number MUST be 32 bits long unless otherwise negotiated
   (no negotiation mechanism is currently provided). This implies that
   the payload length will normally be 8 bytes.




IPsec Working Group                                             [Page 6]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


6.2   The HASH Payload

   The HASH is calculated according to the recommendations in [REVISED-
   HASH].

     HASH = prf(SKEYID_a, PAYLOAD_FRAG_1 | HASH_0 | PAYLOAD_FRAG_2)

   Where:

     PAYLOAD_FRAG_1 is the set of ISAKMP payloads that precede the HASH.
     HASH_0 is a HASH payload with an empty hash (all 0s).
     PAYLOAD_FRAG_2 is the set of ISAKMP payloads that follow the HASH.

   In the typical case:

     PAYLOAD_FRAG_1 = HDR | SEQ_NO
     HASH_0 = Payload Header | sizeof(HASH) bytes of 0
     PAYLOAD_FRAG_1 = NOTIFY(Still Connected) [| SPI_LIST(s)]

6.3   The NOTIFY(Still Connected) Payload

   The NOTIFY(Still Connected) payload is a standard ISAKMP Notify
   payload with a new notify type, STILL-CONNECTED. The value of the new
   notify type is 34793 (from the private range for status notifies)

   The format of the notify is shown below:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-ID  !  SPI Size = 0 !      Notify Message Type      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                    Notification Data                          ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DOI for this notify SHOULD normally be IPsec. The Protocol-ID
   SHOULD be PROTO_ISAKMP. The optional SPI field SHOULD be omitted and
   the SPI size SHOULD therefore be set to 0.

   The sequence number MAY be included in the Notification Data.
   However, since parsing of the Notification Data is not required, the
   SEQ_NO payload at the top of the packet is the master copy.


IPsec Working Group                                             [Page 7]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


7.   The Heartbeat Protocol

   Section 6 described the format of the heartbeat packets. This section
   describes the processing required to handle the packets.

   [The text in this section assumes that the sequence number will
   always be 32 bits. If this limit is increased in the future, the text
   will be modified to reflect the new value.]


7.1   Sending Heartbeat Packets

   After agreeing to use heartbeats (using the Heartbeat Negotiation
   Protocol or some other mechanism), the sender MUST begin sending
   heartbeat packets at the negotiated interval.

   Each packet contains a sequence number, which is incremented for
   successive packets. Note that the sender MUST increment the initial
   sequence number BEFORE sending the first heartbeat packet.

   The sequence number is not allowed to wrap from 0xffffffff to 0. If
   this does happen then the heartbeats MUST be stopped and the sender
   SHOULD attempt to rekey the ISAKMP SA. To avoid this possibility,
   choose a sequence number that is less than 2^31.


7.2   Receiving Heartbeat Packets

   Because there may be race conditions due to setup times, the receiver
   SHOULD begin listening for heartbeats as soon as possible after the
   negotiation completes.

   Each time a heartbeat packet arrives, the receiver must verify the
   hash information and ensure that the sequence number falls within an
   acceptable window. If either one of these two conditions fails, the
   packet is invalid and should be discarded.

   If the packet passes these tests then the receiver must update his
   last-known-good sequence number variable to the value contained in
   the packet. Also, he should maintain a state for the time at which
   the last valid heartbeat was received.


7.3   Receiver Background Tasks

   The receiver must periodically check the stored heartbeat state in
   order to verify that the timeout interval has not elapsed without the
   reception of a valid heartbeat packet from the peer.


IPsec Working Group                                             [Page 8]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   If this happens then the ISAKMP SA and any corresponding IPsec SAs
   SHOULD be deleted. Delete notifications MAY be sent, but they will
   presumably not be understood by the peer, since the connection is
   verifiably dead. The receiver MAY also attempt to rekey the SA.

   The receiver SHOULD also periodically check for time slippage (the
   sequence number should increase at a rate proportional to the elapsed
   time).


8.   Heartbeat Negotiation Protocol

   In order to promote interoperability, this memo also includes a
   standardized method of negotiating heartbeat parameters.

   Of the various parameters, the only one that MUST be agreed upon by
   the two hosts is the heartbeat interval. However, we also use the
   negotiation protocol to indicate support for optional payloads, such
   as the SPI_LIST.

   In general, the sender (responder) has the final decision regarding
   the heartbeat parameters. The initiator may propose values for the
   heartbeat options and heartbeat interval in the Config Request, but
   the responder MAY ignore these values where it makes sense to do so.


8.1   Negotiation Transport

   The negotiation of heartbeat parameters can be accomplished using the
   technique described in the ISAKMP Configuration Method [IKECFG].
   However, the implementer is NOT REQUIRED to use ISAKMP-Config for
   other purposes, such as assigning internal network addresses.

   ISAKMP-Config may be replaced with a similar generic attribute
   exchange protocol in the future. If support for an alternate protocol
   can be verified (e.g. by a vendor id) then the initiator may use that
   protocol instead.


8.2   Heartbeat Configuration Attributes

   We define the following new configuration attributes (taken from the
   private range):

     HEARTBEAT_TYPE = 22565
     HEARTBEAT_OPTIONS = 22566
     HEARTBEAT_INTERVAL = 22567



IPsec Working Group                                             [Page 9]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


     HEARTBEAT_PROPOSAL_ACCEPTED = 22568
     SEQUENCE_NUMBER = 22569

   An implementation using the Heartbeat Negotiation Protocol MUST
   recognize all of these attributes.

   The attributes should be interpreted as follows:

   a) HEARTBEAT_TYPE (4 bytes, enum)

     Value          Meaning
     -----          ---------------------------------
       0            RESERVED
       1            Standard
       2-32767      Reserved for future use
       32768-65535  Reserved for private use

   The HEARTBEAT_TYPE will be used to upgrade the heartbeat protocol in
   the future. New versions of this document may deprecate the current
   standard heartbeat type by defining a new value from the future use
   range.

   Consenting parties (as defined in [EXT-METH]) may choose to negotiate
   a completely different heartbeat mechanism by using values from the
   private use range.

   This attribute MUST be included in every heartbeat negotiation packet
   (and it SHOULD be the first attribute in the list). This enables the
   peer to quickly identify an ISAKMP-Config packet as part of a
   heartbeat negotiation.

   b) HEARTBEAT_OPTIONS (4 bytes, bitfield)

     Value                 Meaning
     ------------          ---------------------------------
       0x00000001          Support SPI_LIST
       0x00000002          Authentication Only
       0xFFFFFFFC          Reserved for future use

   No private usage range is defined. Consenting parties wishing to
   negotiate private options MAY define a new ISAKMP-Config attribute.

   An implementation SHOULD ignore any proposed options which it does
   not understand. Reception of an unrecognized option SHOULD NOT cause
   the negotiation to fail.

   The Authentication Only option may be deprecated by a future version
   of this draft (in a backwards-compatible manner) if the working group


IPsec Working Group                                            [Page 10]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   decides that encryption MUST be either on or off for heartbeat
   packets.

   c) HEARTBEAT_INTERVAL (4 bytes, # of seconds)

   This attribute MUST be negotiated by the peers. If the sender and
   receiver do not use the same heartbeat interval, the heartbeat
   protocol will not work properly.

   d) HEARTBEAT_PROPOSAL_ACCEPTED (4 bytes, Boolean)

   This attribute confirms that the peer has agreed to do heartbeats
   with the negotiated parameters.

     Value          Meaning
     -----          ---------------------------------
       0            Rejected
       1            Accepted
       2-65535      RESERVED

   To maintain compatibility with future versions of this document, an
   implementation SHOULD normally send HEARTBEAT_PROPOSAL_ACCEPTED=0
   when rejecting a heartbeat proposal. The inclusion of the Proposal
   Rejected attribute indicates to the initiator that he SHOULD NOT
   retry the negotiation.

   e) SEQUENCE_NUMBER (variable size (4 bytes is standard), int)

   This is the initial sequence number, which is used as a seed for the
   responder's LKG_SN. It SHOULD be chosen randomly from the range [0,
   2^31].


8.3   Sample Heartbeat Negotiations

   Example of a simple configuration exchange:

     Initiator                                                 Responder
     --------------                                    -----------------
     REQUEST(HEARTBEAT_TYPE=Standard)  -->

                                     <--  REPLY(HEARTBEAT_TYPE=Standard,
                                                HEARTBEAT_INTERVAL=30,
                                                SEQUENCE_NUMBER=1234,
                                          HEARTBEAT_PROPOSAL_ACCEPTED=1)





IPsec Working Group                                            [Page 11]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   Example where the initiator proposes some values:

     Initiator                                                 Responder
     --------------                                    -----------------
     REQUEST(HEARTBEAT_TYPE=Standard,
             HEARTBEAT_INTERVAL=20,
             HEARTBEAT_OPTIONS=Send SPI list)  -->

                                     <--  REPLY(HEARTBEAT_TYPE=Standard,
                                                HEARTBEAT_INTERVAL=30,
                                        HEARTBEAT_OPTIONS=Send SPI list,
                                                SEQUENCE_NUMBER=1234,
                                          HEARTBEAT_PROPOSAL_ACCEPTED=1)

   Example where the responder doesn't want to send heartbeats:

     Initiator                                                 Responder
     --------------                                    -----------------
     REQUEST(HEARTBEAT_TYPE=Standard)  -->
                                     <--  REPLY(HEARTBEAT_TYPE=Standard,
                                          HEARTBEAT_PROPOSAL_ACCEPTED=0)

   Example where the initiator is using a newer version of the heartbeat
   protocol:

     Initiator                                                 Responder
     --------------                                    -----------------
     REQUEST(HEARTBEAT_TYPE=2)  -->
                                            <--  REPLY(HEARTBEAT_TYPE=1)
     REQUEST(HEARTBEAT_TYPE=1)  -->

                                            <--  REPLY(HEARTBEAT_TYPE=1,
                                                  HEARTBEAT_INTERVAL=30,
                                                   SEQUENCE_NUMBER=1234,
                                          HEARTBEAT_PROPOSAL_ACCEPTED=1)

9. The SPI_LIST Payload

   The SPI list is an optional payload which allows the peers to
   synchronize SAD information during the heartbeat exchange. In
   conjunction with the basic Heartbeat Protocol, this allows an IPsec
   host to be more fully self-stabilizing.








IPsec Working Group                                            [Page 12]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


9.1   Payload Format

   The SPI_LIST payload is a new ISAKMP payload with value 218 (from the
   private range). It provides information about which SPIs are
   currently known to the peer.

   Its format is similar to that of the ISAKMP Delete payload, but its
   function is almost the exact opposite. Whereas the delete
   notification tells the peer that all SPIs on the list are no longer
   valid, the SPI list tells the peer that any SPIs NOT on the list are
   no longer valid.

   The format of the SPI_LIST payload is as follows:

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-ID  !   SPI Size    !           # of SPIs           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                     Min SPI for this Page                     ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                     Max SPI for this Page                     ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                      Ordered List of SPIs                     ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DOI for this payload should normally be IPsec. The Protocol-ID
   SHOULD be either PROTO_IPSEC_ESP or PROTO_IPSEC_AH, so the SPI Size
   would normally be 4 bytes. The SPI list MAY also be used to track
   IPCOMP SAs, in which case the SPI size would be 2 bytes.

   The SPI Size determines the width of the Min SPI and Max SPI fields.
   It also determines the width of each entry in the ordered list. The
   'Number of SPIs' field only refers to the number of SPIs in the
   ordered list; the Min SPI and Max SPI fields are not counted.





IPsec Working Group                                            [Page 13]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   The ordered list MUST ONLY include outbound SPIs (relative to the
   sender). The reason for this is explained below. Also, the list MUST
   always be sorted in ascending order.


9.2   Using the SPI list

   The SPI list may be included in the "Optional Payloads" section of
   the Heartbeat packet. Implementations are NOT REQUIRED to parse this
   payload (but they must recognize and ignore it).

   In cases where the number of SAs between a pair of host is small (the
   normal case), it may be acceptable to include all of the SPIs inside
   a single SPI_LIST payload. In this case, the Min and Max SPI field
   SHOULD be set to 0 and 0xFFFFFFFF respectively (for 32 bit SPIs).

   If, however, there is a large number of IPsec SAs between the two
   hosts, it may be desirable to split the list of SPIs into multiple
   'pages'. In this case, the ordered list MUST ONLY contain those SPIs
   which fall within [Min SPI, Max SPI]. See section 12.8 for some
   suggestions on how to split the list into pages.

   Also, a SPI_LIST payload is bound to only one Protocol and DOI. To
   send SPI lists for multiple protocols, multiple SPI_LIST payloads are
   required.

   The receiver of the SPI List SHOULD search his SA database(s) for
   inbound SPIs matching the criteria of (DOI, Protocol, [Min SPI, Max
   SPI]). If the peers are correctly synchronized, this list should
   match the outbound SPI list from the heartbeat packet.

   If, however, the two lists differ, then some corrective action SHOULD
   be taken. If an SA from the packet is missing from the SAD then a
   delete notification SHOULD be sent. If an SA from the SAD is missing
   from the packet then the SA should be deleted from the SAD.


10. Use of Values from the Private Range

   This memo describes a protocol that is still in the experimental
   stages. As such, all protocol-specific constants have been assigned
   from the private range.








IPsec Working Group                                            [Page 14]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   Use of these constants is enabled by the exchange of the following
   vendor id:

     Vendor Id = 0x8DB7A41811221660

   If and when this document is accepted by the IETF for incorporation
   into the set of IPsec standards, all or some of the following will
   occur:

   The heartbeat exchange mode, SEQ_NO payload, SPI_LIST payload, STILL-
   CONNECTED notify type, and all the ISAKMP-Config attributes will be
   assigned permanent values by the IANA or the editors of the relevant
   drafts.

   The description of the SEQ_NO and SPI_LIST payloads will be added to
   [ISAKMP].

   The descriptions of the ISAKMP-Config attributes will be added to
   [IKECFG].

   Text will be added to [NOTIFY-DATA] to describe the additional data
   section of the STILL-CONNECTED notify.

   The vendor id will no longer be needed.


11.  General Approach

   The conceptual idea behind the heartbeat protocol is simple:

   A host wishes to detect, in a timely fashion, when a peer has crashed
   or is otherwise unreachable. In order to accomplish this, he asks the
   peer to send him periodic 'heartbeat' packets on a secure connection.
   If the heartbeats stop, then the connection is no longer valid and
   some corrective or diagnostic action should be taken.


11.1  Security Considerations

   When the heartbeats mechanism is being used in conjunction with a
   security protocol, there are a few additional wrinkles to be
   considered:

   Firstly, an adversary must not be able to provide false proof of
   liveness by replaying old packets. This implies that the packet must
   include some kind of shared state which proves to the recipient that
   it was generated recently.



IPsec Working Group                                            [Page 15]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   Since it would be over-ambitious to assume that the system time is
   synchronized with GMT on every host, we do not rely on a timestamp to
   provide the liveness proof. Instead, we use a monotonically
   increasing sequence number. If the adversary replays an old packet,
   the peer will detect the old sequence number and he will reject the
   packet.

   Secondly, an adversary must not be able to provide false proof of
   liveness by spoofing packets. Therefore, each packet must be
   authenticated using a keyed hash. This is accomplished by sending
   heartbeats under the protection of an existing ISAKMP SA. If the
   adversary spoofs a packet, the peer will detect the invalid hash
   information and he will reject the packet.


11.2  Goals of the Heartbeat Protocol

   This protocol was designed with certain specific goals in mind.

   This version of the protocol aims satisfy all of the primary goals
   and as many of the secondary goals as possible without sacrificing
   simplicity.

   The future considerations section (Appendix A) suggests extensions
   that may be used in the future in order to satisfy more of the
   secondary goals. These extensions will be evaluated based on comments
   from vendors who have implemented working prototypes of the protocol.

   The primary goals of the heartbeat protocol are:

     a) To provide a simple dead peer detection protocol that is easy to
       implement.
     b) To not weaken the security of existing IPsec protocols.
     c) To promote interoperability between vendors by using an
       unambiguous packet format.

   The secondary goals of the heartbeat protocol are:

     d) To ensure that the protocol is not subject to packet spoofing,
       replay, or flooding attacks.
     e) To detect the dead peer in as timely a manner as possible.









IPsec Working Group                                            [Page 16]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


     f) To detect missing IPsec SAs (due, perhaps, to lost deletes or to
       crashed IPsec devices).
     g) To provide a flexible negotiation scheme for the heartbeat
       protocol.
     h) To ensure that neither of the two parties is overloaded by the
       heartbeat packets.

11.3  Design Considerations

   In order to make the heartbeat protocol more modular, we have
   separated the design into three layers, where each layer is only
   dependent on the layer directly below it.

   This means that the heartbeat protocol could be adapted to other
   situations. Implementers wishing to use one of the other possible
   heartbeat types (see Appendix B) could redefine layers 1 and 2 (by
   using a different heartbeat type during negotiation) or layer 3 (by
   sending a different vendor id during phase 1 negotiation).

   LAYER 1 (Content): At the lowest level, we define a proof of liveness
   payload (Notify Still Connected). This payload provides proof of
   liveness whenever it is transmitted over a secure channel along with
   a valid sequence number.

   LAYER 2 (Transport): As a standard method of delivering the liveness
   proof, we define a heartbeat exchange mode. The heartbeat exchange
   uses the security of an existing ISAKMP SA to transport the Notify
   Still Connected payload and the sequence number.

   LAYER 3 (Negotiation): In order to negotiate the use of the heartbeat
   exchange, we define a standard heartbeat negotiation protocol. This
   protocol uses ISAKMP-Config to communicate important parameters and
   options to the peer.

   The proof of liveness payload we have chosen is a new notify type
   called Notify Still Connected. Reception of this Notify payload (with
   a valid sequence number and on a secure connection) is enough to
   guarantee that the peer is alive and that the connection is still
   valid.

   Of course, there is no corresponding 'proof of deadness' payload; a
   peer that is dead will generally be unable to send such a payload (at
   least not in a secure manner). Proof of deadness is achieved when the
   peer fails to provide proof of liveness within a given timeout
   interval.

   The heartbeat exchange provides a standard transport mechanism for
   the notify payloads. It ensures reliable delivery, protects against


IPsec Working Group                                            [Page 17]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   some kinds of DoS attacks and provides additional features, such as
   the ability to recover from lost ISAKMP Delete notifications or to
   detect crashed IPsec devices.

   The standard way of negotiating to use the heartbeat exchange is via
   the heartbeat negotiation protocol. This protocol allows the peers to
   agree on important parameters, such as the frequency with which
   heartbeat packets are sent, and support for optional payloads.

   The negotiation protocol also provides a mechanism for modifying or
   extending the heartbeat protocol in the future.


12.  Implementation Hints

   Although, the Heartbeat framework is fairly generic, we expect that
   most implementations will choose the same basic approach.

   For example, a logical constraint for dead peer detection is fixed
   worst case response. By controlling various implementation constants,
   we can ensure that a dead peer is always detected within a given
   timeout interval.


12.1  Terminology Used in This Section

   The 'heartbeat interval' (HB_I) is the negotiated rate (in seconds
   per packet) at which the sender has agreed to send heartbeat packets.

   The 'timeout interval' (TO_I) is the elapsed time (in seconds) after
   which the receiver should consider the sender to be dead (if no
   heartbeat is received during this period).

   The 'lost packet tolerance' (LP_T) is the number of heartbeats that
   must be lost before the receiver should consider the sender to be
   dead.

   The 'packet transmission window' (PT_W) is the maximum reasonable
   time (in seconds) that it should take for a packet to be generated by
   the sender, transmitted across the Internet, and processed by the
   receiver.









IPsec Working Group                                            [Page 18]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   The logical relationship between these values SHOULD be as follows:

     TO_I = HB_I x LP_T + PT_W
     SN_W = LP_T + 1

   The 'last known good sequence number' (LKG_SN) is the stored value of
   the sequence number from the last heartbeat packet from the peer that
   passed all authentication and validity checks.

   The 'initial sequence number' (SN_0) is the pre-negotiated sequence
   number which is used as the original value of LKG_SN.

   The 'sequence number window' (SN_W) is the maximum acceptable jump in
   the sequence number between consecutive valid heartbeat packets. The
   receiver should discard any incoming packets when the sequence number
   does not fall within the range of [LKG_SN + 1, LKG_SN + SN_W].

   The 'time slippage window' (TS_W) is the maximum acceptable
   discrepancy between the current sequence number and the current time.
   After N heartbeat packets have been sent, the sequence number should
   have increased by N and the time should have increased by HB_I x N.

   If (elapsed time) - HB_I x (LKG_SN - SN_0) > TS_W then you have
   possible evidence of tampering by an intermediate router.


12.2  Suggested Values for Heartbeat Parameters

   Choosing the values for the various heartbeat parameters is, for the
   most part, a matter of local policy. However, here we present a list
   of constraints and suggested values for these parameters.

   A suggested value for the lost packet tolerance is 3. It seems
   unlikely that, under normal circumstances, three consecutive packets
   would be lost (especially when they are spaced out at regular
   intervals).

   A suggested value for the packet transmission window is 5 seconds.
   This includes a fairly substantial safety margin.

   A suggested value for the heartbeat interval is 20 seconds. Using the
   standard formula (TO_I = HB_I x LP_T + PT_W), this implies that the
   suggested value of the timeout interval will be 65 seconds.

   Some possible methods for reducing the timeout interval in the future
   are discussed in Appendix A.

   Using these values, we expect that heartbeat packets will not place


IPsec Working Group                                            [Page 19]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   undue load on either the sender or the receiver. Assuming an average
   of 100 bytes per heartbeat packet, heartbeat packets will amount to
   only 5 bytes of traffic per second per channel.

   In the case of a large deployment, a host that is sending or
   receiving heartbeat traffic on 1000 simultaneous channels will only
   be burdened with 5kb/s (50 packets/s) of extra traffic.

   A suggested value for the time slippage window is 200 seconds. The
   value of this parameter is not critical, but it SHOULD be greater
   than TO_I. Also, the upper bound on this parameter SHOULD be set
   relative to the ISAKMP SA lifetime (e.g. it should not be more than
   10% of the SA lifetime).


12.3  Optimizing for Speed

   Since the heartbeat protocol is unidirectional and not reliant on any
   interaction with the peer, heartbeat packets may be built in advance
   (during spare CPU cycles) and then stored until they are scheduled to
   be sent.

   A host MAY choose to use unencrypted heartbeat packets. However, he
   may only do so if this option has been specifically negotiated with
   the peer.

   Unencrypted heartbeats provide faster throughput in the normal case,
   but encrypted packets may provide faster rejection of spoofed packets
   unless some other DoS resistance technique is being used (see
   Appendix A). The security ramifications of using unencrypted packets
   are discussed in the Security Considerations section.


12.4  Optimizing for Reliability

   The sender MUST attempt to send the packet within a short window of
   the heartbeat interval. If the receiver does not consistently receive
   the packet within PT_W of the negotiated interval then the
   reliability of the heartbeat protocol will be diminished, since the
   lost packet tolerance will effectively be reduced by 1.

   The receiver SHOULD also periodically check that the time slippage
   window has not been exceeded. If this check fails, it may indicate
   that an intermediate router is storing packets and delaying their
   transmission in order to setup a future false proof of liveness.

   When the adversary is an intermediate router, little can be done to
   ensure the reliable and timely delivery of packets. One possible


IPsec Working Group                                            [Page 20]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   remedy is to send the heartbeat packets with the Type of Service
   field set to high reliability. This increases the probability that
   some heartbeat packets will manage to avoid passing through the
   malicious router.


12.5  Optimizing for State

   It is theoretically possible for the sender of the heartbeat packets
   to operate in an essentially stateless manner.

   To do this, the sender must always choose the same heartbeat interval
   and he must keep a global sequence number state.

   Although it is recommended that the responder choose a heartbeat
   interval that is no less than the one the initiator proposed, the
   stateless heartbeat sender MAY break this rule.

   In this case, the receiver MAY compensate by choosing to only parse
   every Nth heartbeat packet. To do this, he SHOULD adjust his normal
   heartbeat parameters as follows:

     HB_I = HB_I x N
     LP_T = LP_T x N
     SN_W = SN_W x N


12.6  Filtering Heartbeat Packets

   The receiver may use a variety of mechanisms in order to speed up his
   rejection of invalid heartbeat packets (thereby reducing his
   vulnerability to DoS attacks). Use of these filtering techniques is
   NOT REQUIRED.

   He MAY ignore heartbeat packets that arrive when a heartbeat is not
   expected (i.e. within HB_I - PT_W of the last valid heartbeat).

   He MAY ignore a packet if the NEXT_PAYLOAD field in the ISAKMP Header
   is not set to SEQ_NO.

   He MAY ignore a packet after decrypting the first block if the
   sequence number is out of range.

   He SHOULD check that the encryption bit in the ISAKMP Header is off
   if he has negotiated to use authentication only.

   Other possible filtering mechanisms are suggested in Appendix A.



IPsec Working Group                                            [Page 21]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


12.7  Managing the Sequence Number

   For security reasons, the sequence number must not be allowed to
   cycle through all 2^32 possible values. This would allow an adversary
   to successfully replay an old, stored packet.

   For practical reasons, we do not allow the sequence number to wrap
   from 0xffffffff to 0, since this would require added complexity in
   the algorithm that checks the sequence window.

   A suggested algorithm for generating the initial sequence number is
   to choose a random 32 bit number and then set the high bit to 0. This
   ensures that at least 2^31 heartbeat packets can be sent on the
   ISAKMP SA.


12.8  Use of the SPI List

   Generally speaking, reception of the Still Connected Notify only
   provides proof that the peer's ISAKMP process is still up and
   running. In order to provide a finer granularity of dead peer
   detection, the SPI list can be used to ensure that the SADs of the
   two peers also remain synchronized.

   This may be useful when the ISAKMP process is running on a different
   machine from the IPsec process(es). It may be possible for one or
   more of the IPsec devices to crash or otherwise delete its SAs, even
   though the ISAKMP process continues to send valid heartbeat packets.

   If the SPI List is used, the ISAKMP process SHOULD periodically query
   each IPsec process in order to verify that it is still working
   correctly and that local cached copies of the SAD are properly
   synchronized.

   Since support for the SPI_LIST payload is optional, it should not be
   used unless the peer has indicated support for it (via the Heartbeat
   Negotiation protocol or by some other mechanism).

   Depending on the number of IPsec SAs that exist between the two
   peers, the complete SPI list(s) may grow quite large and it may not
   be desirable to include all the SPIs in every heartbeat packet.
   Therefore, one or more of the following approaches is suggested:

     a) Include the SPI list only occasionally (e.g. in every Nth
       packet).
     b) Split the SPI list into N equal 'pages' and send one page in
       each packet (this requires a stored state).
     c) For each packet, generate a random Min SPI and use it to choose


IPsec Working Group                                            [Page 22]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


       a random page of fixed size (this requires no extra stored
       state).
     d) Send the SPI list when the ISAKMP process detects that one of
       the IPsec devices has crashed.
     e) Send the SPI list after receiving a large number of packets with
       invalid SPIs.

   Implementation Hint:

   When sending a page of SPIs, don't just set the Min and Max SPI
   variables to the first and last entries in the ordered list. The
   purpose of the SPI list is to indicate which SPIs are not being used;
   therefore, the range of SPI values should be as wide as possible.

   Note that the reason why the SPI_LIST lists the sender's outbound
   SPIs is that the receiver may need to send a delete notification. If
   the SPI_LIST had used the sender's inbound SPIs (receiver's outbound)
   then the receiver might have been unable to correlate the invalid
   outbound SPI with the appropriate invalid inbound SPI.

   If the missing SPI is part of an SA bundle (as defined in [ARCH]), it
   may be permissible for the receiver to delete the entire bundle.
   However, this SHOULD NOT be done unless the peer has indicated
   support for this behaviour (e.g. through a private heartbeat option).

   It is unclear what an implementation should do if a reserved SPI
   value (e.g. 0-255) is included in the SPI_LIST. Documents which
   allocate SPI values from the reserved range SHOULD specify this
   behaviour. If no specific behaviour is specified then these SPI
   values SHOULD be ignored.


12.9  Rules for Negotiation

   In general, the sender (responder) has the final decision regarding
   the heartbeat parameters. The initiator may propose values for the
   heartbeat options and heartbeat interval in the Config Request, but
   the responder MAY ignore these values where it makes sense to do so.

   If the initiator proposes a value for the heartbeat interval, the
   responder SHOULD normally either accept that value or choose a longer
   interval (slower frequency).

   If the initiator does not propose to use the SPI List, the responder
   SHOULD choose NOT to send it. There is no value in sending the SPI
   List if the receiver has indicated that he will not parse it.

   Support for the authentication only mode of heartbeat is NOT


IPsec Working Group                                            [Page 23]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   REQUIRED. Therefore, if the initiator does not propose this mode, the
   responder MUST NOT use it.

   If the initiator proposes a heartbeat type from the private or future
   use ranges (i.e. the initiator is using a different version of the
   Heartbeat Negotiation Proposal), the responder SHOULD respond by
   setting the HEARTBEAT_TYPE to his standard value, but he SHOULD NOT
   send HEARTBEAT_PROPOSAL_ACCEPTED=0. This indicates that the initiator
   SHOULD retry the negotiation using the responder's preferred
   heartbeat type (if he supports it).

   The Heartbeat Negotiation Protocol only negotiates unidirectional
   heartbeats. If both peers wish to receive heartbeats, they should
   each initiate heartbeat negotiation exchanges (the two exchanges will
   be independent of each other).

   The negotiated heartbeat protocol is bound to an ISAKMP SA. If the SA
   is rekeyed, the heartbeat protocol SHOULD be renegotiated using the
   new ISAKMP SA. If there is more than one ISAKMP SA between the peers,
   it is not necessary to send heartbeats on both of them.

   The heartbeat negotiation process is currently not replay resistant.
   Therefore, once heartbeats have been successfully negotiated with a
   peer, the implementation MUST ignore all subsequent heartbeat
   requests on the same phase 1 SA.

   Possible extensions to the protocol to make the negotiation process
   replay resistant are suggested in Appendix A.


12.10 Dealing with Dangling SAs

   Some implementations have been categorized as 'dangling SA' hosts.
   This means that they will delete Isakmp SAs under some conditions
   (e.g. low memory) when corresponding IPsec SAs still exist. This
   behaviour has been deemed acceptable by the IPsec Working Group, and
   therefore it MUST be supported.

   Although heartbeats cannot be sent under these conditions, the
   heartbeat protocol has been specifically designed to ensure that
   termination of the heartbeats will not cause the peer to delete the
   IPsec SAs.

   When either peer deletes the ISAKMP SA, the heartbeats MUST be
   stopped. Therefore, it is imperative that the delete notification be
   sent over a reliable delivery mechanism. Use of the Acknowledged
   Informational exchange (see [IKEv2]) for this purpose is encouraged.



IPsec Working Group                                            [Page 24]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   In the case where the receiver of the heartbeats sends the delete
   using an unacknowledged notify message, he SHOULD store the delete
   notification for a limited time and periodically retransmit it if he
   continues to receive heartbeat traffic on the deleted SA.


12.11 Dependence on ISAKMP-Config

   If an implementation wishes to use ISAKMP-Config to transport the
   Heartbeat Negotiation Protocol, that implementation MUST implement
   the basic framework for sending and receiving ISAKMP-Config messages.

   According to the text of [IKECFG], an implementation is REQUIRED to
   recognize all mandatory ISAKMP-Config attributes (e.g.
   INTERNAL_IP4_ADDRESS, APPLICATION_VERSION).

   However, actual support for these features is not required. If the
   host does not implement full support for the attribute sent in the
   CONFIG-REQUEST, he may indicate that the option is not available by
   simply removing the attribute from the CONFIG-REPLY.


13.  Security Considerations

   The focus of this document is security; hence security considerations
   permeate this specification.

   This document discusses a method of sending heartbeat traffic across
   a secure channel. Use of an insecure heartbeat protocol would allow
   an adversary to provide false proof of liveness.

   The ability to provide false proof of liveness might assist the peer
   in performing a DoS attack or in preventing an implementation from
   minimizing the damage done when a key is compromised.

   Also, in the absence of a standardized dead peer detection protocol,
   an implementer might be tempted to rely on insecure mechanisms, such
   as unauthenticated INVALID-SPI or INVALID-COOKIE notifications, which
   can be used to provide false proof of deadness.

   Implementations which use the authentication only mode of heartbeats
   should be aware that an adversary will have access to the SPI list
   and to a large number of known-plaintext hash outputs. The use of
   encryption guarantees an equivalent level of security to Quick Mode
   or other phase 2 [IKE] modes.





IPsec Working Group                                            [Page 25]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


14.  Acknowledgments

   The authors would like to thank the members of the IPsec working
   group who contributed ideas for the design of this protocol,
   especially Jan Vilhuber, Bronislav Kavsan, Paul Koning, Chris
   Trobridge, and Michael Richardson. Also, special thanks to Tim
   Jenkins, Stephane Beaulieu, and Carson Sutton for many sanity checks
   along the way.


15.  References

   [ARCH]  Kent, S., Atkinson, R., "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998

   [DOI]   Piper, D., "The Internet IP Security Domain of Interpretation
           for ISAKMP", RFC 2407, November 1998

   [EXT-METH] T. Kivinen, "ISAKMP & IKE Extension Methods", draft-ietf-
           ipsec-ike-ext-meth-03.txt (WORK IN PROGRESS)

   [IKE]   Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
           RFC 2409, November 1998

   [IKEv2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
           draft-ietf-ipsec-ike-01.txt (WORK IN PROGRESS)

   [IKECFG]R. Pereira, "The ISAKMP Configuration Method", draft-ietf-
           ipsec-isakmp-cfg-05 (WORK IN PROGRESS)

   [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
           "Internet Security Association and Key Management Protocol
           (ISAKMP)", RFC 2408, November 1998

   [NOTIFY-DATA] S. Kelly, T. Kivinen, "Content Requirements for ISAKMP
           Notify Messages", draft-ietf-ipsec-notifymsg-02.txt (WORK IN
           PROGRESS)

   [REVISED-HASH] T. Kivinen, "Fixing IKE Phase 1 Authentication HASH",
           draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS)


Appendix A.    Future Considerations

   One of the goals of the heartbeat protocol was simplicity of design.
   Although this document is of fairly substantial length, much of the
   text is of an explanatory nature; the protocol itself is still
   relatively simple.


IPsec Working Group                                            [Page 26]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   For the sake of simplicity, many potentially useful features were
   omitted from this specification. The most common reason for not
   including a feature was that it was doubtful whether the feature
   would actually be used.

   Below, we list some of the features which were rejected for this
   version of the specification. Support for these features may be
   revisited later, pending comments from implementers.

     a) The ability to stop the heartbeats, perhaps by sending a
       NOTIFY(Stop Heartbeats) message.

   This might be useful for the case where a physical link (e.g. dialup
   connection) goes down gracefully, but we want the ISAKMP SA to
   remain.

   In this case, we would probably also want to have a NOTIFY(Restart
   Heartbeats) message. This would require special protection against
   replay attacks.

   Currently, the only way to terminate the heartbeats gracefully is to
   delete the ISAKMP SA.

     b) The ability to negotiate an action to take when the heartbeats
       stop.

   Similarly, it might not always be desirable to delete the ISAKMP SA
   when the heartbeats stop abruptly.

   There are a number of possible actions a host might want to take when
   it ceases to receive proof of liveness. These include: stop billing,
   hang-up phone, retry later, use alternate route.

     c) Support for other types of heartbeat mode (see Appendix B).

   In this instance, it seems more important to promote interoperability
   between vendors than to provide an ultra-flexible protocol.

   If it becomes apparent that more than one heartbeat mode is actually
   needed then new HEARTBEAT_TYPE values will be added. However,
   preference will be given to solutions that work within the existing
   heartbeat framework.

     d) The use of a query protocol for faster detection of dead peers.

   The use of a request/reply protocol for transport of heartbeats is
   sub-optimal. However, once the peer has been flagged as 'probably
   dead' (because a heartbeat has been missed), a replay-protected


IPsec Working Group                                            [Page 27]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   request/reply protocol could be used to safely speed up the timeout
   process.

   Using this technique, the timeout interval could be reduced to:

     TO_I = HB_I + LP_T x PT_W

   One way to add this feature to the heartbeat protocol in an
   unobtrusive manner would be to add a new notify type, NOTIFY(Missed
   Heartbeat). This would command the sender to retransmit the heartbeat
   packet (replay protection would be provided by including the sequence
   number in the notification).

     e) Faster packet throughput (especially in the DoS case).

   One of the goals of this protocol was to not reduce the security of
   existing IPsec protocols. Although there is no precise reason why
   confidentiality of the heartbeat packet is required, encrypting it
   gives us a level of security equivalent to that provided by other
   exchange modes.

   Currently, the performance impact of using encryption is unclear.
   Overall throughput will certainly decrease, but resistance to DoS
   attacks may improve, depending on the precise set of cryptographic
   algorithms that is being used.

   Due to the large number of heartbeat packets that will be available
   for replay, some kind of anti-clogging mechanism is needed. In this
   case, the most effective variety of anti-clogging device is the time-
   variant (or sequence-based) token. This is a value which will be
   unpredictable to an adversary, but easy to calculate (or predict) for
   the receiver.

   The current heartbeat format implements this feature by including an
   encrypted copy of the sequence number early in the packet. However,
   this technique has sub-optimal performance characteristics because a
   prf must be calculated (to generate the IV) before the spoofed packet
   can be discarded.

   For optimal performance against DoS attacks, the anti-clogging token
   should be sent as a plaintext value, and the receiver should
   calculate the expected value ahead of time (or set of possible
   expected values).

   One obvious way to accomplish this would be to generate the message
   ids sequentially, based on a pre-shared prf algorithm. This is a very
   fast packet-rejection technique, which could potentially also be
   applied to [IKE] exchanges such as quick mode (if the notion of a


IPsec Working Group                                            [Page 28]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   lost packet tolerance was also added to [IKE]).


Appendix B.    Other Dead Peer Detection Techniques

   Before settling on the current heartbeat protocol, we explored a
   number of different general approaches. These are listed below, along
   with the reasons why they were not chosen.


B.1   Terminology Used in This Section

   The following terms are used to describe potential heartbeat
   protocols:

   A unidirectional protocol is one in which packets are sent in only
   one direction (this implies that the heartbeat exchange must be a one
   packet exchange).

   A request/reply protocol is one in which the sender proves his
   liveness by responding to a query from the receiver.

   A stateful protocol is one in which the sender and receiver maintain
   a shared heartbeat state.

   A stateless protocol is the opposite. Generally only the receiver
   needs to keep a state.

   A phase 1 protocol is one in which the heartbeats are sent under the
   protection of an ISAKMP SA.

   A phase 2 protocol is one in which the heartbeats are sent under the
   protection of an IPsec SA.

   An out of band (OOB) protocol is one in which the heartbeats are
   authenticated using a public key signature.

   An insecure protocol is one in which the heartbeats are not
   authenticated.

   The heartbeat protocol described in this document is of the stateful
   unidirectional phase 1 variety.


B.2   Design Alternatives

   The Insecure Heartbeat (a.k.a. clear ping):



IPsec Working Group                                            [Page 29]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   The problem with this heartbeat mode is that it is insecure. It is
   undesirable for a security protocol to use an insecure heartbeat
   mechanism.

   The Out-of-Band Heartbeat:

   This heartbeat mode saves time and state on the sender, but consumes
   valuable time and state on the receiver. This makes it particularly
   vulnerable to DoS attacks. Since a session key is not used, key
   exposure is a concern. Also, identity protection and non-reputability
   are not provided.

   The Phase 2 Heartbeat:

   This heartbeat mode has many advantages. Unfortunately, it requires
   extra complexity to negotiate. If negotiation is not used, the peer
   system must have policy holes to let the packets through.

   This mode allows the host to save memory if the heartbeats are mixed
   in with user traffic, but this behaviour makes it difficult to
   maintain billing information such as byte counts. If a dedicated SA
   is used for heartbeats then this memory advantage is nullified.

   The Stateless (Request/Reply) Phase 1 Heartbeat:

   This heartbeat mode is simple to implement, but it is very vulnerable
   to DoS attacks. If the sender does not keep a state, he cannot detect
   replayed heartbeat requests.

   The Stateful Request/Reply Phase 1 Heartbeat:

   When used properly (with a sequence number and a query interval),
   this heartbeat mode is similar to the one described in this document.
   The main difference is that it requires double the bandwidth to do
   the same thing.















IPsec Working Group                                            [Page 30]


Internet Draft            ISAKMP Heartbeats                July 14, 2000


   Authors' Addresses

     Andrew Krywaniuk
     Alcatel Networks Corporation
     600 March Rd.
     Kanata, ON
     Canada, K2K 2P5
     +1 (613) 599-3610 x4237
     E-mail: andrew.krywaniuk@alcatel.com

     Tero Kivinen
     SSH Communications Security Ltd.
     Tekniikantie 12
     FIN-02150 ESPOO
     Finland
     E-mail: kivinen@ssh.fi




   The IPsec working group can be contacted via the IPsec working
   group's mailing list (ipsec@lists.tislabs.com) or through its chair:

     Theodore Y. Ts'o
     tytso@MIT.EDU
     Massachusetts Institute of Technology


Expiration


   This document expires January 14, 2001.


















IPsec Working Group                                            [Page 31]