idnits 2.17.00 (12 Aug 2021) /tmp/idnits44601/draft-ietf-ipsec-heartbeats-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 186: '...n implementation MUST use the above pa...' RFC 2119 keyword, line 188: '...ld in the ISAKMP header MUST be set to...' RFC 2119 keyword, line 200: '... A host MAY choose to add extra payl...' RFC 2119 keyword, line 201: '..., these payloads SHOULD be ignored unl...' RFC 2119 keyword, line 220: '... sequence number MUST be 32 bits long ...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2000) is 7974 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bradner97' is mentioned on line 116, but not defined == Missing Reference: 'IKECFG' is mentioned on line 1052, but not defined == Missing Reference: 'Min SPI' is mentioned on line 563, but not defined == Missing Reference: 'Max SPI' is mentioned on line 563, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 601, but not defined == Unused Reference: 'DOI' is defined on line 1099, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ike-ext-meth-03 -- Possible downref: Normative reference to a draft: ref. 'EXT-METH' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'IKEv2' == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-notifymsg-02 -- Possible downref: Normative reference to a draft: ref. 'NOTIFY-DATA' == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ike-hash-revised-01 -- Possible downref: Normative reference to a draft: ref. 'REVISED-HASH' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Andrew Krywaniuk 3 IP Security Working Group Alcatel Networks Corporation 4 Internet Draft T. Kivinen 5 SSH Communications Security 6 July 14, 2000 8 Using Isakmp Heartbeats for Dead Peer Detection 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol Security 14 (IPsec) Working Group. Comments are solicited and should be addressed 15 to the working group mailing list (ipsec@lists.tislabs.com) or to the 16 editor. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or made obsolete by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 This document is a product of the IETF's IPsec Working Group. 39 Copyright (C) The Internet Society (2000). All Rights Reserved. 41 Abstract 43 This document describes a method for sending heartbeat packets 44 (sometimes called keep-alives) across an ISAKMP SA in order to detect 45 when a peer has crashed or has become otherwise unreachable. A method 46 for negotiating the heartbeat parameters is also provided. 48 Table of Contents 50 1. Introduction....................................................4 51 2. Specification of Requirements...................................4 52 3. Changes Since Last Revision.....................................4 53 4. Document Roadmap................................................4 54 5. Terminology Used Throughout This Document.......................5 55 6. Basic Packet Format.............................................5 56 6.1 The SEQ_NO Payload.............................................6 57 6.2 The HASH Payload...............................................7 58 6.3 The NOTIFY(Still Connected) Payload............................7 59 7. The Heartbeat Protocol..........................................8 60 7.1 Sending Heartbeat Packets......................................8 61 7.2 Receiving Heartbeat Packets....................................8 62 7.3 Receiver Background Tasks......................................8 63 8. Heartbeat Negotiation Protocol..................................9 64 8.1 Negotiation Transport..........................................9 65 8.2 Heartbeat Configuration Attributes.............................9 66 8.3 Sample Heartbeat Negotiations.................................11 67 9. The SPI_LIST Payload...........................................12 68 9.1 Payload Format................................................13 69 9.2 Using the SPI list............................................14 70 10. Use of Values from the Private Range..........................14 71 11. General Approach..............................................15 72 11.1 Security Considerations......................................15 73 11.2 Goals of the Heartbeat Protocol..............................16 74 11.3 Design Considerations........................................17 75 12. Implementation Hints..........................................18 76 12.1 Terminology Used in This Section.............................18 77 12.2 Suggested Values for Heartbeat Parameters....................19 78 12.3 Optimizing for Speed.........................................20 79 12.4 Optimizing for Reliability...................................20 80 12.5 Optimizing for State.........................................21 81 12.6 Filtering Heartbeat Packets..................................21 82 12.7 Managing the Sequence Number.................................22 83 12.8 Use of the SPI List..........................................22 84 12.9 Rules for Negotiation........................................23 85 12.10 Dealing with Dangling SAs...................................24 86 12.11 Dependence on ISAKMP-Config.................................25 87 13. Security Considerations.......................................25 88 14. Acknowledgments...............................................26 89 15. References....................................................26 90 Appendix A. Future Considerations.................................26 91 Appendix B. Other Dead Peer Detection Techniques..................29 92 B.1 Terminology Used in This Section..............................29 93 B.2 Design Alternatives...........................................29 95 1. Introduction 97 Heartbeat packets have often been used (particularly at the link 98 layer) to detect when a peer has crashed (hung up, etc.) in order 99 that the necessary corrective or cleanup action can be performed. 101 When the link is secured using the IPsec protocol suite, special 102 precautions must be taken in order to ensure that the heartbeat 103 packets are also sent in a secure manner. 105 This document describes a method for negotiating and implementing a 106 heartbeat protocol that runs on top of ISAKMP. This protocol prevents 107 an adversary from generating false proof of liveness/deadness in a 108 manner that is resistant to a variety of DoS attacks. 110 2. Specification of Requirements 112 This document shall use the keywords "MUST", "MUST NOT", 113 "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 114 "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They 115 are to be interpreted as described in [Bradner97]. 117 3. Changes Since Last Revision 119 The document has been reorganized based on comments since the initial 120 revision. Protocol specifications have been moved closer to the 121 beginning of the document; background information and implementation 122 hints have been moved closer to the end. The details of the protocol 123 have not been significantly altered, due to a lack of agreement among 124 WG members as to what, if any, changes are required. 126 4. Document Roadmap 128 Sections 5-10 provide the technical details of the protocol. 130 Section 11 provides background information regarding the protocol 131 design. It elucidates the goals of the protocol and it explains how 132 the protocol can be extended. 134 Section 12 provides a variety of implementation hints. Many of these 135 will aid in interoperability with existing IPsec implementations. 137 5. Terminology Used Throughout This Document 139 The term 'keep-alive' literally refers to an exchange which keeps a 140 connection open by periodically exchanging packets with the peer. 141 Over time, the term has also come to refer to an exchange which 142 detects if the connection is still open. If this detection mechanism 143 can trigger an action which will restore the connection when it goes 144 down then it is still, in effect, functioning as a keep-alive. 146 This document uses the term 'heartbeat' to refer to a category of 147 periodic keep-alive packets which can be used to determine the 148 current liveness or reachability of the peer (in the same way that a 149 doctor might use a heartbeat to determine if a patient is alive or 150 dead). However, a heartbeat does not attempt to keep the connection 151 open by defeating the peer's inactivity timeout mechanism. 153 A 'proof of liveness' is a payload or message which indicates that 154 the peer is still up and running, and is capable of sending and 155 receiving traffic on the given ISAKMP SA. 157 A 'dead peer' is a peer that has failed, rebooted, or is otherwise 158 unable to communicate with the host using the ISAKMP SA. For 159 convenience's sake, we include the case where the connection between 160 the peers has gone down (e.g. the user hung-up, there was a routing 161 error, the ISAKMP SA was deleted, etc). 163 The 'sender' is the term that is used to identify the host who sends 164 the heartbeat packets. Similarly, the 'receiver' is the host who 165 receives the heartbeats. 167 Throughout this memo, the 'initiator' refers to the host who 168 initiated the heartbeat negotiation (not the initiator of the ISAKMP 169 SA). The term 'responder' is interpreted likewise. Note that 170 currently the initiator will always be the receiver of heartbeats and 171 the responder will always be the sender. 173 6. Basic Packet Format 175 The heartbeat exchange is unidirectional. In other words, it is a one 176 packet exchange. 178 The format of the packet looks like this: 180 Sender Receiver 181 ----------- ----------- 182 HDR*, SEQ_NO, HASH, 183 NOTIFY(Still Connected) --> 184 [,EXTRA PAYLOADS] 186 An implementation MUST use the above payload order. 188 The Exchange Type field in the ISAKMP header MUST be set to 189 HEARTBEAT_MODE. HEARTBEAT_MODE has been assigned the value 251 from 190 the private range. 192 The SEQ_NO payload allows the receiver to discard packets that may 193 have been spoofed or replayed. It is described in section 6.1. 195 The HASH payload is described in section 6.2. 197 The NOTIFY(Still Connected) payload is what actually provides the 198 liveness proof. It is described in section 6.3. 200 A host MAY choose to add extra payloads to the end of the message. 201 However, these payloads SHOULD be ignored unless they have been 202 enabled via the Heartbeat Negotiation Protocol or by a vendor- 203 specific extension mechanism. 205 6.1 The SEQ_NO Payload 207 The SEQ_NO payload is a new ISAKMP payload with value 217 (from the 208 private range). 210 It has this format: 212 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 ! Next Payload ! RESERVED ! Payload Length ! 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ! Sequence Number ! 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 The sequence number MUST be 32 bits long unless otherwise negotiated 221 (no negotiation mechanism is currently provided). This implies that 222 the payload length will normally be 8 bytes. 224 6.2 The HASH Payload 226 The HASH is calculated according to the recommendations in [REVISED- 227 HASH]. 229 HASH = prf(SKEYID_a, PAYLOAD_FRAG_1 | HASH_0 | PAYLOAD_FRAG_2) 231 Where: 233 PAYLOAD_FRAG_1 is the set of ISAKMP payloads that precede the HASH. 234 HASH_0 is a HASH payload with an empty hash (all 0s). 235 PAYLOAD_FRAG_2 is the set of ISAKMP payloads that follow the HASH. 237 In the typical case: 239 PAYLOAD_FRAG_1 = HDR | SEQ_NO 240 HASH_0 = Payload Header | sizeof(HASH) bytes of 0 241 PAYLOAD_FRAG_1 = NOTIFY(Still Connected) [| SPI_LIST(s)] 243 6.3 The NOTIFY(Still Connected) Payload 245 The NOTIFY(Still Connected) payload is a standard ISAKMP Notify 246 payload with a new notify type, STILL-CONNECTED. The value of the new 247 notify type is 34793 (from the private range for status notifies) 249 The format of the notify is shown below: 251 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ! Next Payload ! RESERVED ! Payload Length ! 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ! Domain of Interpretation (DOI) ! 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ! Protocol-ID ! SPI Size = 0 ! Notify Message Type ! 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ! ! 261 ~ Notification Data ~ 262 ! ! 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 The DOI for this notify SHOULD normally be IPsec. The Protocol-ID 266 SHOULD be PROTO_ISAKMP. The optional SPI field SHOULD be omitted and 267 the SPI size SHOULD therefore be set to 0. 269 The sequence number MAY be included in the Notification Data. 270 However, since parsing of the Notification Data is not required, the 271 SEQ_NO payload at the top of the packet is the master copy. 273 7. The Heartbeat Protocol 275 Section 6 described the format of the heartbeat packets. This section 276 describes the processing required to handle the packets. 278 [The text in this section assumes that the sequence number will 279 always be 32 bits. If this limit is increased in the future, the text 280 will be modified to reflect the new value.] 282 7.1 Sending Heartbeat Packets 284 After agreeing to use heartbeats (using the Heartbeat Negotiation 285 Protocol or some other mechanism), the sender MUST begin sending 286 heartbeat packets at the negotiated interval. 288 Each packet contains a sequence number, which is incremented for 289 successive packets. Note that the sender MUST increment the initial 290 sequence number BEFORE sending the first heartbeat packet. 292 The sequence number is not allowed to wrap from 0xffffffff to 0. If 293 this does happen then the heartbeats MUST be stopped and the sender 294 SHOULD attempt to rekey the ISAKMP SA. To avoid this possibility, 295 choose a sequence number that is less than 2^31. 297 7.2 Receiving Heartbeat Packets 299 Because there may be race conditions due to setup times, the receiver 300 SHOULD begin listening for heartbeats as soon as possible after the 301 negotiation completes. 303 Each time a heartbeat packet arrives, the receiver must verify the 304 hash information and ensure that the sequence number falls within an 305 acceptable window. If either one of these two conditions fails, the 306 packet is invalid and should be discarded. 308 If the packet passes these tests then the receiver must update his 309 last-known-good sequence number variable to the value contained in 310 the packet. Also, he should maintain a state for the time at which 311 the last valid heartbeat was received. 313 7.3 Receiver Background Tasks 315 The receiver must periodically check the stored heartbeat state in 316 order to verify that the timeout interval has not elapsed without the 317 reception of a valid heartbeat packet from the peer. 319 If this happens then the ISAKMP SA and any corresponding IPsec SAs 320 SHOULD be deleted. Delete notifications MAY be sent, but they will 321 presumably not be understood by the peer, since the connection is 322 verifiably dead. The receiver MAY also attempt to rekey the SA. 324 The receiver SHOULD also periodically check for time slippage (the 325 sequence number should increase at a rate proportional to the elapsed 326 time). 328 8. Heartbeat Negotiation Protocol 330 In order to promote interoperability, this memo also includes a 331 standardized method of negotiating heartbeat parameters. 333 Of the various parameters, the only one that MUST be agreed upon by 334 the two hosts is the heartbeat interval. However, we also use the 335 negotiation protocol to indicate support for optional payloads, such 336 as the SPI_LIST. 338 In general, the sender (responder) has the final decision regarding 339 the heartbeat parameters. The initiator may propose values for the 340 heartbeat options and heartbeat interval in the Config Request, but 341 the responder MAY ignore these values where it makes sense to do so. 343 8.1 Negotiation Transport 345 The negotiation of heartbeat parameters can be accomplished using the 346 technique described in the ISAKMP Configuration Method [IKECFG]. 347 However, the implementer is NOT REQUIRED to use ISAKMP-Config for 348 other purposes, such as assigning internal network addresses. 350 ISAKMP-Config may be replaced with a similar generic attribute 351 exchange protocol in the future. If support for an alternate protocol 352 can be verified (e.g. by a vendor id) then the initiator may use that 353 protocol instead. 355 8.2 Heartbeat Configuration Attributes 357 We define the following new configuration attributes (taken from the 358 private range): 360 HEARTBEAT_TYPE = 22565 361 HEARTBEAT_OPTIONS = 22566 362 HEARTBEAT_INTERVAL = 22567 363 HEARTBEAT_PROPOSAL_ACCEPTED = 22568 364 SEQUENCE_NUMBER = 22569 366 An implementation using the Heartbeat Negotiation Protocol MUST 367 recognize all of these attributes. 369 The attributes should be interpreted as follows: 371 a) HEARTBEAT_TYPE (4 bytes, enum) 373 Value Meaning 374 ----- --------------------------------- 375 0 RESERVED 376 1 Standard 377 2-32767 Reserved for future use 378 32768-65535 Reserved for private use 380 The HEARTBEAT_TYPE will be used to upgrade the heartbeat protocol in 381 the future. New versions of this document may deprecate the current 382 standard heartbeat type by defining a new value from the future use 383 range. 385 Consenting parties (as defined in [EXT-METH]) may choose to negotiate 386 a completely different heartbeat mechanism by using values from the 387 private use range. 389 This attribute MUST be included in every heartbeat negotiation packet 390 (and it SHOULD be the first attribute in the list). This enables the 391 peer to quickly identify an ISAKMP-Config packet as part of a 392 heartbeat negotiation. 394 b) HEARTBEAT_OPTIONS (4 bytes, bitfield) 396 Value Meaning 397 ------------ --------------------------------- 398 0x00000001 Support SPI_LIST 399 0x00000002 Authentication Only 400 0xFFFFFFFC Reserved for future use 402 No private usage range is defined. Consenting parties wishing to 403 negotiate private options MAY define a new ISAKMP-Config attribute. 405 An implementation SHOULD ignore any proposed options which it does 406 not understand. Reception of an unrecognized option SHOULD NOT cause 407 the negotiation to fail. 409 The Authentication Only option may be deprecated by a future version 410 of this draft (in a backwards-compatible manner) if the working group 411 decides that encryption MUST be either on or off for heartbeat 412 packets. 414 c) HEARTBEAT_INTERVAL (4 bytes, # of seconds) 416 This attribute MUST be negotiated by the peers. If the sender and 417 receiver do not use the same heartbeat interval, the heartbeat 418 protocol will not work properly. 420 d) HEARTBEAT_PROPOSAL_ACCEPTED (4 bytes, Boolean) 422 This attribute confirms that the peer has agreed to do heartbeats 423 with the negotiated parameters. 425 Value Meaning 426 ----- --------------------------------- 427 0 Rejected 428 1 Accepted 429 2-65535 RESERVED 431 To maintain compatibility with future versions of this document, an 432 implementation SHOULD normally send HEARTBEAT_PROPOSAL_ACCEPTED=0 433 when rejecting a heartbeat proposal. The inclusion of the Proposal 434 Rejected attribute indicates to the initiator that he SHOULD NOT 435 retry the negotiation. 437 e) SEQUENCE_NUMBER (variable size (4 bytes is standard), int) 439 This is the initial sequence number, which is used as a seed for the 440 responder's LKG_SN. It SHOULD be chosen randomly from the range [0, 441 2^31]. 443 8.3 Sample Heartbeat Negotiations 445 Example of a simple configuration exchange: 447 Initiator Responder 448 -------------- ----------------- 449 REQUEST(HEARTBEAT_TYPE=Standard) --> 451 <-- REPLY(HEARTBEAT_TYPE=Standard, 452 HEARTBEAT_INTERVAL=30, 453 SEQUENCE_NUMBER=1234, 454 HEARTBEAT_PROPOSAL_ACCEPTED=1) 456 Example where the initiator proposes some values: 458 Initiator Responder 459 -------------- ----------------- 460 REQUEST(HEARTBEAT_TYPE=Standard, 461 HEARTBEAT_INTERVAL=20, 462 HEARTBEAT_OPTIONS=Send SPI list) --> 464 <-- REPLY(HEARTBEAT_TYPE=Standard, 465 HEARTBEAT_INTERVAL=30, 466 HEARTBEAT_OPTIONS=Send SPI list, 467 SEQUENCE_NUMBER=1234, 468 HEARTBEAT_PROPOSAL_ACCEPTED=1) 470 Example where the responder doesn't want to send heartbeats: 472 Initiator Responder 473 -------------- ----------------- 474 REQUEST(HEARTBEAT_TYPE=Standard) --> 475 <-- REPLY(HEARTBEAT_TYPE=Standard, 476 HEARTBEAT_PROPOSAL_ACCEPTED=0) 478 Example where the initiator is using a newer version of the heartbeat 479 protocol: 481 Initiator Responder 482 -------------- ----------------- 483 REQUEST(HEARTBEAT_TYPE=2) --> 484 <-- REPLY(HEARTBEAT_TYPE=1) 485 REQUEST(HEARTBEAT_TYPE=1) --> 487 <-- REPLY(HEARTBEAT_TYPE=1, 488 HEARTBEAT_INTERVAL=30, 489 SEQUENCE_NUMBER=1234, 490 HEARTBEAT_PROPOSAL_ACCEPTED=1) 492 9. The SPI_LIST Payload 494 The SPI list is an optional payload which allows the peers to 495 synchronize SAD information during the heartbeat exchange. In 496 conjunction with the basic Heartbeat Protocol, this allows an IPsec 497 host to be more fully self-stabilizing. 499 9.1 Payload Format 501 The SPI_LIST payload is a new ISAKMP payload with value 218 (from the 502 private range). It provides information about which SPIs are 503 currently known to the peer. 505 Its format is similar to that of the ISAKMP Delete payload, but its 506 function is almost the exact opposite. Whereas the delete 507 notification tells the peer that all SPIs on the list are no longer 508 valid, the SPI list tells the peer that any SPIs NOT on the list are 509 no longer valid. 511 The format of the SPI_LIST payload is as follows: 513 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 ! Next Payload ! RESERVED ! Payload Length ! 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 ! Domain of Interpretation (DOI) ! 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 ! Protocol-ID ! SPI Size ! # of SPIs ! 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ! ! 523 ~ Min SPI for this Page ~ 524 ! ! 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 ! ! 527 ~ Max SPI for this Page ~ 528 ! ! 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ! ! 531 ~ Ordered List of SPIs ~ 532 ! ! 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 The DOI for this payload should normally be IPsec. The Protocol-ID 536 SHOULD be either PROTO_IPSEC_ESP or PROTO_IPSEC_AH, so the SPI Size 537 would normally be 4 bytes. The SPI list MAY also be used to track 538 IPCOMP SAs, in which case the SPI size would be 2 bytes. 540 The SPI Size determines the width of the Min SPI and Max SPI fields. 541 It also determines the width of each entry in the ordered list. The 542 'Number of SPIs' field only refers to the number of SPIs in the 543 ordered list; the Min SPI and Max SPI fields are not counted. 545 The ordered list MUST ONLY include outbound SPIs (relative to the 546 sender). The reason for this is explained below. Also, the list MUST 547 always be sorted in ascending order. 549 9.2 Using the SPI list 551 The SPI list may be included in the "Optional Payloads" section of 552 the Heartbeat packet. Implementations are NOT REQUIRED to parse this 553 payload (but they must recognize and ignore it). 555 In cases where the number of SAs between a pair of host is small (the 556 normal case), it may be acceptable to include all of the SPIs inside 557 a single SPI_LIST payload. In this case, the Min and Max SPI field 558 SHOULD be set to 0 and 0xFFFFFFFF respectively (for 32 bit SPIs). 560 If, however, there is a large number of IPsec SAs between the two 561 hosts, it may be desirable to split the list of SPIs into multiple 562 'pages'. In this case, the ordered list MUST ONLY contain those SPIs 563 which fall within [Min SPI, Max SPI]. See section 12.8 for some 564 suggestions on how to split the list into pages. 566 Also, a SPI_LIST payload is bound to only one Protocol and DOI. To 567 send SPI lists for multiple protocols, multiple SPI_LIST payloads are 568 required. 570 The receiver of the SPI List SHOULD search his SA database(s) for 571 inbound SPIs matching the criteria of (DOI, Protocol, [Min SPI, Max 572 SPI]). If the peers are correctly synchronized, this list should 573 match the outbound SPI list from the heartbeat packet. 575 If, however, the two lists differ, then some corrective action SHOULD 576 be taken. If an SA from the packet is missing from the SAD then a 577 delete notification SHOULD be sent. If an SA from the SAD is missing 578 from the packet then the SA should be deleted from the SAD. 580 10. Use of Values from the Private Range 582 This memo describes a protocol that is still in the experimental 583 stages. As such, all protocol-specific constants have been assigned 584 from the private range. 586 Use of these constants is enabled by the exchange of the following 587 vendor id: 589 Vendor Id = 0x8DB7A41811221660 591 If and when this document is accepted by the IETF for incorporation 592 into the set of IPsec standards, all or some of the following will 593 occur: 595 The heartbeat exchange mode, SEQ_NO payload, SPI_LIST payload, STILL- 596 CONNECTED notify type, and all the ISAKMP-Config attributes will be 597 assigned permanent values by the IANA or the editors of the relevant 598 drafts. 600 The description of the SEQ_NO and SPI_LIST payloads will be added to 601 [ISAKMP]. 603 The descriptions of the ISAKMP-Config attributes will be added to 604 [IKECFG]. 606 Text will be added to [NOTIFY-DATA] to describe the additional data 607 section of the STILL-CONNECTED notify. 609 The vendor id will no longer be needed. 611 11. General Approach 613 The conceptual idea behind the heartbeat protocol is simple: 615 A host wishes to detect, in a timely fashion, when a peer has crashed 616 or is otherwise unreachable. In order to accomplish this, he asks the 617 peer to send him periodic 'heartbeat' packets on a secure connection. 618 If the heartbeats stop, then the connection is no longer valid and 619 some corrective or diagnostic action should be taken. 621 11.1 Security Considerations 623 When the heartbeats mechanism is being used in conjunction with a 624 security protocol, there are a few additional wrinkles to be 625 considered: 627 Firstly, an adversary must not be able to provide false proof of 628 liveness by replaying old packets. This implies that the packet must 629 include some kind of shared state which proves to the recipient that 630 it was generated recently. 632 Since it would be over-ambitious to assume that the system time is 633 synchronized with GMT on every host, we do not rely on a timestamp to 634 provide the liveness proof. Instead, we use a monotonically 635 increasing sequence number. If the adversary replays an old packet, 636 the peer will detect the old sequence number and he will reject the 637 packet. 639 Secondly, an adversary must not be able to provide false proof of 640 liveness by spoofing packets. Therefore, each packet must be 641 authenticated using a keyed hash. This is accomplished by sending 642 heartbeats under the protection of an existing ISAKMP SA. If the 643 adversary spoofs a packet, the peer will detect the invalid hash 644 information and he will reject the packet. 646 11.2 Goals of the Heartbeat Protocol 648 This protocol was designed with certain specific goals in mind. 650 This version of the protocol aims satisfy all of the primary goals 651 and as many of the secondary goals as possible without sacrificing 652 simplicity. 654 The future considerations section (Appendix A) suggests extensions 655 that may be used in the future in order to satisfy more of the 656 secondary goals. These extensions will be evaluated based on comments 657 from vendors who have implemented working prototypes of the protocol. 659 The primary goals of the heartbeat protocol are: 661 a) To provide a simple dead peer detection protocol that is easy to 662 implement. 663 b) To not weaken the security of existing IPsec protocols. 664 c) To promote interoperability between vendors by using an 665 unambiguous packet format. 667 The secondary goals of the heartbeat protocol are: 669 d) To ensure that the protocol is not subject to packet spoofing, 670 replay, or flooding attacks. 671 e) To detect the dead peer in as timely a manner as possible. 673 f) To detect missing IPsec SAs (due, perhaps, to lost deletes or to 674 crashed IPsec devices). 675 g) To provide a flexible negotiation scheme for the heartbeat 676 protocol. 677 h) To ensure that neither of the two parties is overloaded by the 678 heartbeat packets. 680 11.3 Design Considerations 682 In order to make the heartbeat protocol more modular, we have 683 separated the design into three layers, where each layer is only 684 dependent on the layer directly below it. 686 This means that the heartbeat protocol could be adapted to other 687 situations. Implementers wishing to use one of the other possible 688 heartbeat types (see Appendix B) could redefine layers 1 and 2 (by 689 using a different heartbeat type during negotiation) or layer 3 (by 690 sending a different vendor id during phase 1 negotiation). 692 LAYER 1 (Content): At the lowest level, we define a proof of liveness 693 payload (Notify Still Connected). This payload provides proof of 694 liveness whenever it is transmitted over a secure channel along with 695 a valid sequence number. 697 LAYER 2 (Transport): As a standard method of delivering the liveness 698 proof, we define a heartbeat exchange mode. The heartbeat exchange 699 uses the security of an existing ISAKMP SA to transport the Notify 700 Still Connected payload and the sequence number. 702 LAYER 3 (Negotiation): In order to negotiate the use of the heartbeat 703 exchange, we define a standard heartbeat negotiation protocol. This 704 protocol uses ISAKMP-Config to communicate important parameters and 705 options to the peer. 707 The proof of liveness payload we have chosen is a new notify type 708 called Notify Still Connected. Reception of this Notify payload (with 709 a valid sequence number and on a secure connection) is enough to 710 guarantee that the peer is alive and that the connection is still 711 valid. 713 Of course, there is no corresponding 'proof of deadness' payload; a 714 peer that is dead will generally be unable to send such a payload (at 715 least not in a secure manner). Proof of deadness is achieved when the 716 peer fails to provide proof of liveness within a given timeout 717 interval. 719 The heartbeat exchange provides a standard transport mechanism for 720 the notify payloads. It ensures reliable delivery, protects against 721 some kinds of DoS attacks and provides additional features, such as 722 the ability to recover from lost ISAKMP Delete notifications or to 723 detect crashed IPsec devices. 725 The standard way of negotiating to use the heartbeat exchange is via 726 the heartbeat negotiation protocol. This protocol allows the peers to 727 agree on important parameters, such as the frequency with which 728 heartbeat packets are sent, and support for optional payloads. 730 The negotiation protocol also provides a mechanism for modifying or 731 extending the heartbeat protocol in the future. 733 12. Implementation Hints 735 Although, the Heartbeat framework is fairly generic, we expect that 736 most implementations will choose the same basic approach. 738 For example, a logical constraint for dead peer detection is fixed 739 worst case response. By controlling various implementation constants, 740 we can ensure that a dead peer is always detected within a given 741 timeout interval. 743 12.1 Terminology Used in This Section 745 The 'heartbeat interval' (HB_I) is the negotiated rate (in seconds 746 per packet) at which the sender has agreed to send heartbeat packets. 748 The 'timeout interval' (TO_I) is the elapsed time (in seconds) after 749 which the receiver should consider the sender to be dead (if no 750 heartbeat is received during this period). 752 The 'lost packet tolerance' (LP_T) is the number of heartbeats that 753 must be lost before the receiver should consider the sender to be 754 dead. 756 The 'packet transmission window' (PT_W) is the maximum reasonable 757 time (in seconds) that it should take for a packet to be generated by 758 the sender, transmitted across the Internet, and processed by the 759 receiver. 761 The logical relationship between these values SHOULD be as follows: 763 TO_I = HB_I x LP_T + PT_W 764 SN_W = LP_T + 1 766 The 'last known good sequence number' (LKG_SN) is the stored value of 767 the sequence number from the last heartbeat packet from the peer that 768 passed all authentication and validity checks. 770 The 'initial sequence number' (SN_0) is the pre-negotiated sequence 771 number which is used as the original value of LKG_SN. 773 The 'sequence number window' (SN_W) is the maximum acceptable jump in 774 the sequence number between consecutive valid heartbeat packets. The 775 receiver should discard any incoming packets when the sequence number 776 does not fall within the range of [LKG_SN + 1, LKG_SN + SN_W]. 778 The 'time slippage window' (TS_W) is the maximum acceptable 779 discrepancy between the current sequence number and the current time. 780 After N heartbeat packets have been sent, the sequence number should 781 have increased by N and the time should have increased by HB_I x N. 783 If (elapsed time) - HB_I x (LKG_SN - SN_0) > TS_W then you have 784 possible evidence of tampering by an intermediate router. 786 12.2 Suggested Values for Heartbeat Parameters 788 Choosing the values for the various heartbeat parameters is, for the 789 most part, a matter of local policy. However, here we present a list 790 of constraints and suggested values for these parameters. 792 A suggested value for the lost packet tolerance is 3. It seems 793 unlikely that, under normal circumstances, three consecutive packets 794 would be lost (especially when they are spaced out at regular 795 intervals). 797 A suggested value for the packet transmission window is 5 seconds. 798 This includes a fairly substantial safety margin. 800 A suggested value for the heartbeat interval is 20 seconds. Using the 801 standard formula (TO_I = HB_I x LP_T + PT_W), this implies that the 802 suggested value of the timeout interval will be 65 seconds. 804 Some possible methods for reducing the timeout interval in the future 805 are discussed in Appendix A. 807 Using these values, we expect that heartbeat packets will not place 808 undue load on either the sender or the receiver. Assuming an average 809 of 100 bytes per heartbeat packet, heartbeat packets will amount to 810 only 5 bytes of traffic per second per channel. 812 In the case of a large deployment, a host that is sending or 813 receiving heartbeat traffic on 1000 simultaneous channels will only 814 be burdened with 5kb/s (50 packets/s) of extra traffic. 816 A suggested value for the time slippage window is 200 seconds. The 817 value of this parameter is not critical, but it SHOULD be greater 818 than TO_I. Also, the upper bound on this parameter SHOULD be set 819 relative to the ISAKMP SA lifetime (e.g. it should not be more than 820 10% of the SA lifetime). 822 12.3 Optimizing for Speed 824 Since the heartbeat protocol is unidirectional and not reliant on any 825 interaction with the peer, heartbeat packets may be built in advance 826 (during spare CPU cycles) and then stored until they are scheduled to 827 be sent. 829 A host MAY choose to use unencrypted heartbeat packets. However, he 830 may only do so if this option has been specifically negotiated with 831 the peer. 833 Unencrypted heartbeats provide faster throughput in the normal case, 834 but encrypted packets may provide faster rejection of spoofed packets 835 unless some other DoS resistance technique is being used (see 836 Appendix A). The security ramifications of using unencrypted packets 837 are discussed in the Security Considerations section. 839 12.4 Optimizing for Reliability 841 The sender MUST attempt to send the packet within a short window of 842 the heartbeat interval. If the receiver does not consistently receive 843 the packet within PT_W of the negotiated interval then the 844 reliability of the heartbeat protocol will be diminished, since the 845 lost packet tolerance will effectively be reduced by 1. 847 The receiver SHOULD also periodically check that the time slippage 848 window has not been exceeded. If this check fails, it may indicate 849 that an intermediate router is storing packets and delaying their 850 transmission in order to setup a future false proof of liveness. 852 When the adversary is an intermediate router, little can be done to 853 ensure the reliable and timely delivery of packets. One possible 854 remedy is to send the heartbeat packets with the Type of Service 855 field set to high reliability. This increases the probability that 856 some heartbeat packets will manage to avoid passing through the 857 malicious router. 859 12.5 Optimizing for State 861 It is theoretically possible for the sender of the heartbeat packets 862 to operate in an essentially stateless manner. 864 To do this, the sender must always choose the same heartbeat interval 865 and he must keep a global sequence number state. 867 Although it is recommended that the responder choose a heartbeat 868 interval that is no less than the one the initiator proposed, the 869 stateless heartbeat sender MAY break this rule. 871 In this case, the receiver MAY compensate by choosing to only parse 872 every Nth heartbeat packet. To do this, he SHOULD adjust his normal 873 heartbeat parameters as follows: 875 HB_I = HB_I x N 876 LP_T = LP_T x N 877 SN_W = SN_W x N 879 12.6 Filtering Heartbeat Packets 881 The receiver may use a variety of mechanisms in order to speed up his 882 rejection of invalid heartbeat packets (thereby reducing his 883 vulnerability to DoS attacks). Use of these filtering techniques is 884 NOT REQUIRED. 886 He MAY ignore heartbeat packets that arrive when a heartbeat is not 887 expected (i.e. within HB_I - PT_W of the last valid heartbeat). 889 He MAY ignore a packet if the NEXT_PAYLOAD field in the ISAKMP Header 890 is not set to SEQ_NO. 892 He MAY ignore a packet after decrypting the first block if the 893 sequence number is out of range. 895 He SHOULD check that the encryption bit in the ISAKMP Header is off 896 if he has negotiated to use authentication only. 898 Other possible filtering mechanisms are suggested in Appendix A. 900 12.7 Managing the Sequence Number 902 For security reasons, the sequence number must not be allowed to 903 cycle through all 2^32 possible values. This would allow an adversary 904 to successfully replay an old, stored packet. 906 For practical reasons, we do not allow the sequence number to wrap 907 from 0xffffffff to 0, since this would require added complexity in 908 the algorithm that checks the sequence window. 910 A suggested algorithm for generating the initial sequence number is 911 to choose a random 32 bit number and then set the high bit to 0. This 912 ensures that at least 2^31 heartbeat packets can be sent on the 913 ISAKMP SA. 915 12.8 Use of the SPI List 917 Generally speaking, reception of the Still Connected Notify only 918 provides proof that the peer's ISAKMP process is still up and 919 running. In order to provide a finer granularity of dead peer 920 detection, the SPI list can be used to ensure that the SADs of the 921 two peers also remain synchronized. 923 This may be useful when the ISAKMP process is running on a different 924 machine from the IPsec process(es). It may be possible for one or 925 more of the IPsec devices to crash or otherwise delete its SAs, even 926 though the ISAKMP process continues to send valid heartbeat packets. 928 If the SPI List is used, the ISAKMP process SHOULD periodically query 929 each IPsec process in order to verify that it is still working 930 correctly and that local cached copies of the SAD are properly 931 synchronized. 933 Since support for the SPI_LIST payload is optional, it should not be 934 used unless the peer has indicated support for it (via the Heartbeat 935 Negotiation protocol or by some other mechanism). 937 Depending on the number of IPsec SAs that exist between the two 938 peers, the complete SPI list(s) may grow quite large and it may not 939 be desirable to include all the SPIs in every heartbeat packet. 940 Therefore, one or more of the following approaches is suggested: 942 a) Include the SPI list only occasionally (e.g. in every Nth 943 packet). 944 b) Split the SPI list into N equal 'pages' and send one page in 945 each packet (this requires a stored state). 946 c) For each packet, generate a random Min SPI and use it to choose 947 a random page of fixed size (this requires no extra stored 948 state). 949 d) Send the SPI list when the ISAKMP process detects that one of 950 the IPsec devices has crashed. 951 e) Send the SPI list after receiving a large number of packets with 952 invalid SPIs. 954 Implementation Hint: 956 When sending a page of SPIs, don't just set the Min and Max SPI 957 variables to the first and last entries in the ordered list. The 958 purpose of the SPI list is to indicate which SPIs are not being used; 959 therefore, the range of SPI values should be as wide as possible. 961 Note that the reason why the SPI_LIST lists the sender's outbound 962 SPIs is that the receiver may need to send a delete notification. If 963 the SPI_LIST had used the sender's inbound SPIs (receiver's outbound) 964 then the receiver might have been unable to correlate the invalid 965 outbound SPI with the appropriate invalid inbound SPI. 967 If the missing SPI is part of an SA bundle (as defined in [ARCH]), it 968 may be permissible for the receiver to delete the entire bundle. 969 However, this SHOULD NOT be done unless the peer has indicated 970 support for this behaviour (e.g. through a private heartbeat option). 972 It is unclear what an implementation should do if a reserved SPI 973 value (e.g. 0-255) is included in the SPI_LIST. Documents which 974 allocate SPI values from the reserved range SHOULD specify this 975 behaviour. If no specific behaviour is specified then these SPI 976 values SHOULD be ignored. 978 12.9 Rules for Negotiation 980 In general, the sender (responder) has the final decision regarding 981 the heartbeat parameters. The initiator may propose values for the 982 heartbeat options and heartbeat interval in the Config Request, but 983 the responder MAY ignore these values where it makes sense to do so. 985 If the initiator proposes a value for the heartbeat interval, the 986 responder SHOULD normally either accept that value or choose a longer 987 interval (slower frequency). 989 If the initiator does not propose to use the SPI List, the responder 990 SHOULD choose NOT to send it. There is no value in sending the SPI 991 List if the receiver has indicated that he will not parse it. 993 Support for the authentication only mode of heartbeat is NOT 994 REQUIRED. Therefore, if the initiator does not propose this mode, the 995 responder MUST NOT use it. 997 If the initiator proposes a heartbeat type from the private or future 998 use ranges (i.e. the initiator is using a different version of the 999 Heartbeat Negotiation Proposal), the responder SHOULD respond by 1000 setting the HEARTBEAT_TYPE to his standard value, but he SHOULD NOT 1001 send HEARTBEAT_PROPOSAL_ACCEPTED=0. This indicates that the initiator 1002 SHOULD retry the negotiation using the responder's preferred 1003 heartbeat type (if he supports it). 1005 The Heartbeat Negotiation Protocol only negotiates unidirectional 1006 heartbeats. If both peers wish to receive heartbeats, they should 1007 each initiate heartbeat negotiation exchanges (the two exchanges will 1008 be independent of each other). 1010 The negotiated heartbeat protocol is bound to an ISAKMP SA. If the SA 1011 is rekeyed, the heartbeat protocol SHOULD be renegotiated using the 1012 new ISAKMP SA. If there is more than one ISAKMP SA between the peers, 1013 it is not necessary to send heartbeats on both of them. 1015 The heartbeat negotiation process is currently not replay resistant. 1016 Therefore, once heartbeats have been successfully negotiated with a 1017 peer, the implementation MUST ignore all subsequent heartbeat 1018 requests on the same phase 1 SA. 1020 Possible extensions to the protocol to make the negotiation process 1021 replay resistant are suggested in Appendix A. 1023 12.10 Dealing with Dangling SAs 1025 Some implementations have been categorized as 'dangling SA' hosts. 1026 This means that they will delete Isakmp SAs under some conditions 1027 (e.g. low memory) when corresponding IPsec SAs still exist. This 1028 behaviour has been deemed acceptable by the IPsec Working Group, and 1029 therefore it MUST be supported. 1031 Although heartbeats cannot be sent under these conditions, the 1032 heartbeat protocol has been specifically designed to ensure that 1033 termination of the heartbeats will not cause the peer to delete the 1034 IPsec SAs. 1036 When either peer deletes the ISAKMP SA, the heartbeats MUST be 1037 stopped. Therefore, it is imperative that the delete notification be 1038 sent over a reliable delivery mechanism. Use of the Acknowledged 1039 Informational exchange (see [IKEv2]) for this purpose is encouraged. 1041 In the case where the receiver of the heartbeats sends the delete 1042 using an unacknowledged notify message, he SHOULD store the delete 1043 notification for a limited time and periodically retransmit it if he 1044 continues to receive heartbeat traffic on the deleted SA. 1046 12.11 Dependence on ISAKMP-Config 1048 If an implementation wishes to use ISAKMP-Config to transport the 1049 Heartbeat Negotiation Protocol, that implementation MUST implement 1050 the basic framework for sending and receiving ISAKMP-Config messages. 1052 According to the text of [IKECFG], an implementation is REQUIRED to 1053 recognize all mandatory ISAKMP-Config attributes (e.g. 1054 INTERNAL_IP4_ADDRESS, APPLICATION_VERSION). 1056 However, actual support for these features is not required. If the 1057 host does not implement full support for the attribute sent in the 1058 CONFIG-REQUEST, he may indicate that the option is not available by 1059 simply removing the attribute from the CONFIG-REPLY. 1061 13. Security Considerations 1063 The focus of this document is security; hence security considerations 1064 permeate this specification. 1066 This document discusses a method of sending heartbeat traffic across 1067 a secure channel. Use of an insecure heartbeat protocol would allow 1068 an adversary to provide false proof of liveness. 1070 The ability to provide false proof of liveness might assist the peer 1071 in performing a DoS attack or in preventing an implementation from 1072 minimizing the damage done when a key is compromised. 1074 Also, in the absence of a standardized dead peer detection protocol, 1075 an implementer might be tempted to rely on insecure mechanisms, such 1076 as unauthenticated INVALID-SPI or INVALID-COOKIE notifications, which 1077 can be used to provide false proof of deadness. 1079 Implementations which use the authentication only mode of heartbeats 1080 should be aware that an adversary will have access to the SPI list 1081 and to a large number of known-plaintext hash outputs. The use of 1082 encryption guarantees an equivalent level of security to Quick Mode 1083 or other phase 2 [IKE] modes. 1085 14. Acknowledgments 1087 The authors would like to thank the members of the IPsec working 1088 group who contributed ideas for the design of this protocol, 1089 especially Jan Vilhuber, Bronislav Kavsan, Paul Koning, Chris 1090 Trobridge, and Michael Richardson. Also, special thanks to Tim 1091 Jenkins, Stephane Beaulieu, and Carson Sutton for many sanity checks 1092 along the way. 1094 15. References 1096 [ARCH] Kent, S., Atkinson, R., "Security Architecture for the 1097 Internet Protocol", RFC 2401, November 1998 1099 [DOI] Piper, D., "The Internet IP Security Domain of Interpretation 1100 for ISAKMP", RFC 2407, November 1998 1102 [EXT-METH] T. Kivinen, "ISAKMP & IKE Extension Methods", draft-ietf- 1103 ipsec-ike-ext-meth-03.txt (WORK IN PROGRESS) 1105 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 1106 RFC 2409, November 1998 1108 [IKEv2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1109 draft-ietf-ipsec-ike-01.txt (WORK IN PROGRESS) 1111 [IKECFG]R. Pereira, "The ISAKMP Configuration Method", draft-ietf- 1112 ipsec-isakmp-cfg-05 (WORK IN PROGRESS) 1114 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J., 1115 "Internet Security Association and Key Management Protocol 1116 (ISAKMP)", RFC 2408, November 1998 1118 [NOTIFY-DATA] S. Kelly, T. Kivinen, "Content Requirements for ISAKMP 1119 Notify Messages", draft-ietf-ipsec-notifymsg-02.txt (WORK IN 1120 PROGRESS) 1122 [REVISED-HASH] T. Kivinen, "Fixing IKE Phase 1 Authentication HASH", 1123 draft-ietf-ipsec-ike-hash-revised-01.txt (WORK IN PROGRESS) 1125 Appendix A. Future Considerations 1127 One of the goals of the heartbeat protocol was simplicity of design. 1128 Although this document is of fairly substantial length, much of the 1129 text is of an explanatory nature; the protocol itself is still 1130 relatively simple. 1132 For the sake of simplicity, many potentially useful features were 1133 omitted from this specification. The most common reason for not 1134 including a feature was that it was doubtful whether the feature 1135 would actually be used. 1137 Below, we list some of the features which were rejected for this 1138 version of the specification. Support for these features may be 1139 revisited later, pending comments from implementers. 1141 a) The ability to stop the heartbeats, perhaps by sending a 1142 NOTIFY(Stop Heartbeats) message. 1144 This might be useful for the case where a physical link (e.g. dialup 1145 connection) goes down gracefully, but we want the ISAKMP SA to 1146 remain. 1148 In this case, we would probably also want to have a NOTIFY(Restart 1149 Heartbeats) message. This would require special protection against 1150 replay attacks. 1152 Currently, the only way to terminate the heartbeats gracefully is to 1153 delete the ISAKMP SA. 1155 b) The ability to negotiate an action to take when the heartbeats 1156 stop. 1158 Similarly, it might not always be desirable to delete the ISAKMP SA 1159 when the heartbeats stop abruptly. 1161 There are a number of possible actions a host might want to take when 1162 it ceases to receive proof of liveness. These include: stop billing, 1163 hang-up phone, retry later, use alternate route. 1165 c) Support for other types of heartbeat mode (see Appendix B). 1167 In this instance, it seems more important to promote interoperability 1168 between vendors than to provide an ultra-flexible protocol. 1170 If it becomes apparent that more than one heartbeat mode is actually 1171 needed then new HEARTBEAT_TYPE values will be added. However, 1172 preference will be given to solutions that work within the existing 1173 heartbeat framework. 1175 d) The use of a query protocol for faster detection of dead peers. 1177 The use of a request/reply protocol for transport of heartbeats is 1178 sub-optimal. However, once the peer has been flagged as 'probably 1179 dead' (because a heartbeat has been missed), a replay-protected 1180 request/reply protocol could be used to safely speed up the timeout 1181 process. 1183 Using this technique, the timeout interval could be reduced to: 1185 TO_I = HB_I + LP_T x PT_W 1187 One way to add this feature to the heartbeat protocol in an 1188 unobtrusive manner would be to add a new notify type, NOTIFY(Missed 1189 Heartbeat). This would command the sender to retransmit the heartbeat 1190 packet (replay protection would be provided by including the sequence 1191 number in the notification). 1193 e) Faster packet throughput (especially in the DoS case). 1195 One of the goals of this protocol was to not reduce the security of 1196 existing IPsec protocols. Although there is no precise reason why 1197 confidentiality of the heartbeat packet is required, encrypting it 1198 gives us a level of security equivalent to that provided by other 1199 exchange modes. 1201 Currently, the performance impact of using encryption is unclear. 1202 Overall throughput will certainly decrease, but resistance to DoS 1203 attacks may improve, depending on the precise set of cryptographic 1204 algorithms that is being used. 1206 Due to the large number of heartbeat packets that will be available 1207 for replay, some kind of anti-clogging mechanism is needed. In this 1208 case, the most effective variety of anti-clogging device is the time- 1209 variant (or sequence-based) token. This is a value which will be 1210 unpredictable to an adversary, but easy to calculate (or predict) for 1211 the receiver. 1213 The current heartbeat format implements this feature by including an 1214 encrypted copy of the sequence number early in the packet. However, 1215 this technique has sub-optimal performance characteristics because a 1216 prf must be calculated (to generate the IV) before the spoofed packet 1217 can be discarded. 1219 For optimal performance against DoS attacks, the anti-clogging token 1220 should be sent as a plaintext value, and the receiver should 1221 calculate the expected value ahead of time (or set of possible 1222 expected values). 1224 One obvious way to accomplish this would be to generate the message 1225 ids sequentially, based on a pre-shared prf algorithm. This is a very 1226 fast packet-rejection technique, which could potentially also be 1227 applied to [IKE] exchanges such as quick mode (if the notion of a 1228 lost packet tolerance was also added to [IKE]). 1230 Appendix B. Other Dead Peer Detection Techniques 1232 Before settling on the current heartbeat protocol, we explored a 1233 number of different general approaches. These are listed below, along 1234 with the reasons why they were not chosen. 1236 B.1 Terminology Used in This Section 1238 The following terms are used to describe potential heartbeat 1239 protocols: 1241 A unidirectional protocol is one in which packets are sent in only 1242 one direction (this implies that the heartbeat exchange must be a one 1243 packet exchange). 1245 A request/reply protocol is one in which the sender proves his 1246 liveness by responding to a query from the receiver. 1248 A stateful protocol is one in which the sender and receiver maintain 1249 a shared heartbeat state. 1251 A stateless protocol is the opposite. Generally only the receiver 1252 needs to keep a state. 1254 A phase 1 protocol is one in which the heartbeats are sent under the 1255 protection of an ISAKMP SA. 1257 A phase 2 protocol is one in which the heartbeats are sent under the 1258 protection of an IPsec SA. 1260 An out of band (OOB) protocol is one in which the heartbeats are 1261 authenticated using a public key signature. 1263 An insecure protocol is one in which the heartbeats are not 1264 authenticated. 1266 The heartbeat protocol described in this document is of the stateful 1267 unidirectional phase 1 variety. 1269 B.2 Design Alternatives 1271 The Insecure Heartbeat (a.k.a. clear ping): 1273 The problem with this heartbeat mode is that it is insecure. It is 1274 undesirable for a security protocol to use an insecure heartbeat 1275 mechanism. 1277 The Out-of-Band Heartbeat: 1279 This heartbeat mode saves time and state on the sender, but consumes 1280 valuable time and state on the receiver. This makes it particularly 1281 vulnerable to DoS attacks. Since a session key is not used, key 1282 exposure is a concern. Also, identity protection and non-reputability 1283 are not provided. 1285 The Phase 2 Heartbeat: 1287 This heartbeat mode has many advantages. Unfortunately, it requires 1288 extra complexity to negotiate. If negotiation is not used, the peer 1289 system must have policy holes to let the packets through. 1291 This mode allows the host to save memory if the heartbeats are mixed 1292 in with user traffic, but this behaviour makes it difficult to 1293 maintain billing information such as byte counts. If a dedicated SA 1294 is used for heartbeats then this memory advantage is nullified. 1296 The Stateless (Request/Reply) Phase 1 Heartbeat: 1298 This heartbeat mode is simple to implement, but it is very vulnerable 1299 to DoS attacks. If the sender does not keep a state, he cannot detect 1300 replayed heartbeat requests. 1302 The Stateful Request/Reply Phase 1 Heartbeat: 1304 When used properly (with a sequence number and a query interval), 1305 this heartbeat mode is similar to the one described in this document. 1306 The main difference is that it requires double the bandwidth to do 1307 the same thing. 1309 Authors' Addresses 1311 Andrew Krywaniuk 1312 Alcatel Networks Corporation 1313 600 March Rd. 1314 Kanata, ON 1315 Canada, K2K 2P5 1316 +1 (613) 599-3610 x4237 1317 E-mail: andrew.krywaniuk@alcatel.com 1319 Tero Kivinen 1320 SSH Communications Security Ltd. 1321 Tekniikantie 12 1322 FIN-02150 ESPOO 1323 Finland 1324 E-mail: kivinen@ssh.fi 1326 The IPsec working group can be contacted via the IPsec working 1327 group's mailing list (ipsec@lists.tislabs.com) or through its chair: 1329 Theodore Y. Ts'o 1330 tytso@MIT.EDU 1331 Massachusetts Institute of Technology 1333 Expiration 1335 This document expires January 14, 2001.