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]