Internet DRAFT - draft-krywaniuk-ipsec-heartbeats
draft-krywaniuk-ipsec-heartbeats
Internet Engineering Task Force Andrew Krywaniuk
IP Security Working Group Newbridge Networks Corporation
Internet Draft T. Kivinen
SSH Communications Security
March 8, 2000
Using Isakmp Heartbeats for Dead Peer Detection
<draft-krywaniuk-ipsec-heartbeats-00.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 September 5, 2000 [Page 1]
Internet Draft ISAKMP Heartbeats March 8, 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 March 8, 2000
Table of Contents
1. Introduction....................................................4
2. Specification of Requirements...................................4
3. Goals of the Heartbeat Protocol.................................4
3.1 Primary Goals..................................................4
3.2 Secondary Goals................................................5
4. General Approach................................................5
4.1 Security Considerations........................................5
4.2 Design Considerations..........................................6
5. Terminology.....................................................7
6. Heartbeat Packet Format.........................................8
6.1 The SEQ_NO Payload.............................................9
6.2 The HASH Payload..............................................10
6.3 The NOTIFY(Still Connected) Payload...........................10
6.4 The SPI_LIST Payload..........................................11
7. Heartbeat Protocol Usage.......................................13
7.1 Sending Heartbeat Packets.....................................13
7.2 Managing the Sequence Number..................................14
7.3 Receiving Heartbeat Packets...................................15
7.4 Filtering Heartbeat Packets...................................15
7.5 Receiver Background Tasks.....................................15
7.6 Stopping the Heartbeats.......................................16
7.7 Use of the SPI List...........................................17
7.8 Suggested Values for Heartbeat Parameters.....................18
8. Heartbeat Negotiation Protocol.................................18
8.1 Dependence on ISAKMP-Config...................................19
8.2 Heartbeat Configuration Attributes............................19
8.3 Rules for Negotiation.........................................21
8.4 Sample Heartbeat Negotiations.................................22
8.5 Sender Stateless Operation....................................23
9. Use of Values from the Private Range...........................24
10. Security Considerations.......................................24
11. Acknowledgments...............................................25
12. References....................................................25
Appendix A. Future Considerations.................................26
Appendix B. Other Dead Peer Detection Techniques..................28
B.1 Terminology Used in This Section..............................28
B.2 Design Alternatives...........................................29
IPsec Working Group [Page 3]
Internet Draft ISAKMP Heartbeats March 8, 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. 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.
3.1 Primary Goals
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.
IPsec Working Group [Page 4]
Internet Draft ISAKMP Heartbeats March 8, 2000
3.2 Secondary Goals
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.
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.
4. 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.
4.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.
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
IPsec Working Group [Page 5]
Internet Draft ISAKMP Heartbeats March 8, 2000
adversary spoofs a packet, the peer will detect the invalid hash
information and he will reject the packet.
4.2 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.
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
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.
IPsec Working Group [Page 6]
Internet Draft ISAKMP Heartbeats March 8, 2000
The negotiation protocol also provides a mechanism for modifying or
extending the heartbeat protocol in the future.
Appendix B discusses some of the other general approaches to
heartbeat packets that we considered.
5. Terminology
This document defines a 'heartbeat' as a packet 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).
The term 'keep-alive' is often used to mean the same thing; however,
it is not used in this document because it is ambiguous and
misleading (the heartbeat packet is not meant to keep the peer or
connection alive, only to detect if it goes down).
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.
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).
IPsec Working Group [Page 7]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
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.
6. Heartbeat Packet Format
The heartbeat exchange is unidirectional. In other words, it is a one
packet exchange.
IPsec Working Group [Page 8]
Internet Draft ISAKMP Heartbeats March 8, 2000
The format of the packet looks like this:
Sender Receiver
----------- -----------
HDR*, SEQ_NO, HASH,
NOTIFY(Still Connected) -->
[, SPI_LIST(s)]
An implementation MUST use the above payload order.
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.
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.
The SPI_LIST payload provides a finer granularity of dead peer
detection by allowing peers to compare their lists of known IPsec
SPIs. It is described in section 6.4. Support for this payload is
optional.
Multiple SPI_LIST payloads may be included in a single heartbeat
packet.
6.1 The SEQ_NO Payload
The SEQ_NO payload is a new ISAKMP payload with value 217 (from the
private range).
IPsec Working Group [Page 9]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
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)
IPsec Working Group [Page 10]
Internet Draft ISAKMP Heartbeats March 8, 2000
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 SHOULD be included in the Notification Data,
although it MAY be omitted if it is included elsewhere in the
heartbeat packet (as is done with the Heartbeat Exchange mode).
6.4 The SPI_LIST Payload
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. Implementations are NOT REQUIRED to
parse this payload (but they must recognize and ignore it).
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.
IPsec Working Group [Page 11]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
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.
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 7.7 for some
suggestions on how to split the list into pages.
IPsec Working Group [Page 12]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
Note that the above paragraph is justification for why the SPI_LIST
lists the sender's outbound SPIs. If the SPI_LIST had used the
sender's inbound SPIs (receiver's outbound) then the receiver would
have been unable to send the delete notification.
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 MUST be ignored.
7. Heartbeat Protocol Usage
The text in this section assumes that the reader is familiar with the
terminology introduced in section 5.
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.
In order to avoid race conditions due to setup times, the sender MAY
choose to send the first heartbeat packet at any time during [HB_I/2,
HB_I]. Correspondingly, the receiver SHOULD begin listening for
heartbeats as soon as possible after the negotiation completes.
IPsec Working Group [Page 13]
Internet Draft ISAKMP Heartbeats March 8, 2000
For subsequent heartbeat packets, 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.
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.
Implementation Hint:
In cases where the precise time on the host is sensitive information
(e.g. it is being used as a seed for the random number generator),
the sender SHOULD be careful not to leak this information through the
timing of the heartbeat packets.
E.g. The task scheduler should be told to wake up and send the
heartbeat "in approximately 30 seconds" not "at 3:57:05pm".
Note that the use of time as a source of entropy is, in general,
discouraged.
7.2 Managing the Sequence Number
[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.]
The receiver MUST store the pre-negotiated initial sequence number
value as his LKG_SN. This implies that the sender MUST increment his
sequence number before sending the first heartbeat packet (i.e. the
first packet should use SN_0 + 1).
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
IPsec Working Group [Page 14]
Internet Draft ISAKMP Heartbeats March 8, 2000
ensures that at least 2^31 heartbeat packets can be sent on the
ISAKMP SA.
In the unlikely event that this extraordinary packet count is ever
reached, the sender MUST stop sending heartbeats and the receiver
MUST stop expecting them. The sender SHOULD attempt to rekey the
ISAKMP SA long before this happens.
7.3 Receiving Heartbeat Packets
The receiver SHOULD begin listening for heartbeat packets immediately
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 the
sequence number window. If either one of these two conditions fails,
the receiver MUST discard the packet.
If the packet passes these tests then the receiver MUST update his
LKG_SN variable to the sequence number value contained in the packet.
Also, he SHOULD maintain a state for the time at which the LKG_SN
variable was last updated.
7.4 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.
7.5 Receiver Background Tasks
IPsec Working Group [Page 15]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
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 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
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.
7.6 Stopping the Heartbeats
Currently, there is no standardized way to stop transmission of
heartbeats except by deleting the ISAKMP SA. (See Appendix A for some
suggestions regarding how this feature could be added in the future.)
Some implementations have been referred to 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
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.
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 (TO_I is suggested) and periodically
IPsec Working Group [Page 16]
Internet Draft ISAKMP Heartbeats March 8, 2000
retransmit it if he continues to receive heartbeat traffic on the
deleted SA.
7.7 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
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
IPsec Working Group [Page 17]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
7.8 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
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).
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
IPsec Working Group [Page 18]
Internet Draft ISAKMP Heartbeats March 8, 2000
negotiation protocol to indicate support for optional payloads, such
as the SPI_LIST.
8.1 Dependence on ISAKMP-Config
The negotiation of heartbeat parameters is 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.
In order to use the Heartbeat Negotiation Protocol, an 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.
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
HEARTBEAT_PROPOSAL_ACCEPTED = 22568
SEQUENCE_NUMBER = 22569
An implementation using the Heartbeat Negotiation Protocol MUST
support all of these attributes.
IPsec Working Group [Page 19]
Internet Draft ISAKMP Heartbeats March 8, 2000
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
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
IPsec Working Group [Page 20]
Internet Draft ISAKMP Heartbeats March 8, 2000
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 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
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 future use range
(i.e. the initiator is using a newer version of the Heartbeat
IPsec Working Group [Page 21]
Internet Draft ISAKMP Heartbeats March 8, 2000
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 (if
he has a backwards compatibility mode) should retry the negotiation
using the old heartbeat type.
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.
8.4 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 22]
Internet Draft ISAKMP Heartbeats March 8, 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)
8.5 Sender Stateless Operation
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.
IPsec Working Group [Page 23]
Internet Draft ISAKMP Heartbeats March 8, 2000
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
9. 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.
Use of these constants is enabled by the exchange of a the following
vendor id, which is a truncated MD5 hash of the string: "draft-ietf-
krywaniuk-ipsec-heartbeats-00.txt":
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.
10. Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
IPsec Working Group [Page 24]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
11. 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.
12. 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)
IPsec Working Group [Page 25]
Internet Draft ISAKMP Heartbeats March 8, 2000
[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.
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.
IPsec Working Group [Page 26]
Internet Draft ISAKMP Heartbeats March 8, 2000
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
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
IPsec Working Group [Page 27]
Internet Draft ISAKMP Heartbeats March 8, 2000
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
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
IPsec Working Group [Page 28]
Internet Draft ISAKMP Heartbeats March 8, 2000
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):
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.
IPsec Working Group [Page 29]
Internet Draft ISAKMP Heartbeats March 8, 2000
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.
Authors' Addresses
Andrew Krywaniuk
Newbridge Networks Corporation
362 Terry Fox Drive
Kanata, ON
Canada, K2K 2P5
+1 (613) 599-3610 x4237
E-mail: akrywani@newbridge.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 September 8, 2000.
IPsec Working Group [Page 30]