idnits 2.17.1 draft-ietf-tls-dtls-heartbeat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2011) is 4836 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) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Seggelmann 3 Internet-Draft M. Tuexen 4 Intended status: Standards Track Muenster Univ. of Applied 5 Expires: July 31, 2011 Sciences 6 M. Williams 7 January 27, 2011 9 Transport Layer Security (TLS) and Datagram Transport Layer Security 10 (DTLS) Heartbeat Extension 11 draft-ietf-tls-dtls-heartbeat-01.txt 13 Abstract 15 This document describes the Heartbeat Extension for the Transport 16 Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 17 protocol. 19 The Heartbeat Extension provides a new protocol for TLS/DTLS allowing 20 the usage of keep-alive functionality without performing a 21 renegotiation and a basis for path maximum transmission unit (PMTU) 22 discovery for DTLS. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 31, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3 60 3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 1.1. Overview 74 This document describes the Heartbeat Extension for the Transport 75 Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 76 protocols, as defined in [RFC5246] and [RFC4347]. 78 DTLS is designed to secure traffic running on top of unreliable 79 transport protocols. Usually such protocols have no session 80 management. The only mechanism available at the DTLS layer to figure 81 out if a peer is still alive is performing a costly renegotiation. 82 If the application uses unidirectional traffic there is no other way. 83 Furthermore, DTLS needs to perform path maximum transmission unit 84 (PMTU) discovery but has no specific message type to realize it 85 without affecting user message transfer. 87 TLS is based on reliable protocols but there is not necessarily a 88 feature available to keep the connection alive without continuous 89 data transfer. 91 The Heartbeat Extension as described in this document overcomes these 92 limitations. The user can use the new HeartbeatRequest message which 93 has to be answered by the peer with a HeartbeartResponse immediately. 94 To perform PMTU discovery, HeartbeatRequest messages containing 95 padding can be used as described in [RFC4821] for the Stream Control 96 Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) 97 defined in [RFC4820]. 99 1.2. Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Heartbeat Hello Extension 107 The support of Heartbeats is indicated with Hello Extensions. A peer 108 can not only indicate that its implementation supports Heartbeats, it 109 can also choose whether it is willing to receive and respond or only 110 to send them. This decision can be changed with every renegotiation. 111 HeartbeatRequests MUST NOT be sent to a peer denying acceptance. 113 enum { 114 peer_allowed_to_send(1), 115 peer_not_allowed_to_send(2), 116 (255) 117 } HeartbeatMode; 119 struct { 120 HeartbeatMode mode; 121 } HeartbeatExtension; 123 3. Heartbeat Protocol 125 The Heartbeat protocol is a new protocol on top of the Record Layer. 126 The protocol itself consists of two message types: HeartbeatRequest 127 and HeartbeatResponse. 129 enum { 130 heartbeat_request(1), 131 heartbeat_response(2), 132 (255) 133 } HeartbeatMessageType; 135 Like the ChangeCipherSpec message, a HeartbeatRequest message can 136 arrive at any time during the lifetime of a connection. Whenever a 137 HeartbeatRequest message is received, it has to be answered with a 138 corresponding HeartbeatResponse message immediately. 140 However, a HeartbeatRequest message SHOULD NOT be sent during 141 handshakes. 143 There MUST NOT be more than one HeartbeatRequest message in flight at 144 a time. 146 When using DTLS, HeartbeatRequest messages MUST be retransmitted 147 using the simple timeout and retransmission scheme DTLS uses for 148 flights. In particular, after a number of retransmissions without 149 receiving a corresponding HeartbeatResponse message having the 150 expected payload the DTLS connection SHOULD be terminated. The 151 threshold used for this SHOULD be the same as for DTLS handshake 152 messages. Please note, that after the timer supervising a 153 HeartbeatRequest messages expires, this message is no longer 154 considered in flight. Therefore the HeartbeatRequest message is 155 eligible for retransmission. 157 When using TLS, HeartbeatRequest messages only need to be sent once. 158 The transport layer will handle retransmissions. If no corresponding 159 HeartbeatResponse message has been received after a user configured 160 amount of time, the TLS connection SHOULD be terminated. 162 4. Heartbeat Request and Response Messages 164 The Heartbeat protocol messages consist of their type and an 165 arbitrary payload and padding. 167 struct { 168 HeartbeatMessageType type; 169 uint16 payload_length; 170 opaque payload[HeartbeatMessage.payload_length]; 171 opaque padding[padding_length]; 172 } HeartbeatMessage; 174 The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or 175 max_fragment_length when negotiated as defined in [RFC6066]. 177 type The message type, either heartbeat_request or 178 heartbeat_response. 180 payload_length The length of the payload. 182 payload The payload consists of arbitrary content. 184 padding The padding is additional arbitrary content which MUST be 185 ignored by the receiver. The padding_length is 186 TLSPlaintext.length - payload_length - 3 with TLS and 187 DTLSPlaintext.length - payload_length - 3 with DTLS. 189 When a HeartbeatRequest message is received, a corresponding 190 HeartbeatResponse message MUST be sent carrying an exact copy of the 191 payload of the HeartbeatRequest. The padding of the received 192 HeartbeatRequest message MUST be ignored. It MUST NOT be included in 193 the HeartbeatResponse message, i.e. the padding field of the 194 HeartbeatResponse message MUST have a length of zero. 196 If a received HeartbeatResponse message does not contain the expected 197 payload the message MUST be discarded silently. If it does contain 198 the expected payload the retransmission timer MUST be stopped. 200 If payload_length is either shorter than expected and thus indicates 201 padding in a HeartbeatResponse or exceeds the actual message length 202 in any message type, an illegal parameter alert MUST be sent in 203 response. 205 5. IANA Considerations 207 [NOTE to RFC-Editor: 209 "RFCXXXX" is to be replaced by the RFC number you assign this 210 document. 212 ] 214 IANA needs to assign the heartbeat content type (value TBD) from the 215 TLS ContentType Registry as specified in [RFC5246]. The reference 216 should be RFCXXXX. 218 IANA needs to maintain a new registry for Heartbeat Message Types. 219 Initially IANA needs to assign the heartbeat_request (suggested value 220 1) and the heartbeat_response (suggested value 2) message type. The 221 message types are numbers in the range from 0 to 255 (decimal). This 222 registry uses the Specification Required policy as described in 223 [RFC5226]. The reference should be RFCXXXX. 225 IANA needs to assign the heartbeat extension type (value TBD) from 226 the TLS Extension Type Registry as specified in [RFC5246]. The 227 reference should be RFCXXXX. 229 IANA needs to maintain a new registry for Heartbeat Modes. Initially 230 IANA needs to assign the peer_allowed_to_send (suggested value 1) and 231 the peer_not_allowed_to_send (suggested value 2) modes. The modes 232 are numbers in the range from 0 to 255 (decimal). This registry uses 233 the Specification Required policy as described in [RFC5226]. The 234 reference should be RFCXXXX. 236 6. Security Considerations 238 This document does not add any additional security considerations in 239 addition to the ones given in [RFC4347] and [RFC5246]. 241 7. Acknowledgments 243 The authors wish to thank Pasi Eronen, Adam Langley, Eric Rescorla, 244 Peter Saint-Andre, and Juho Vaehae-Herttua for their invaluable 245 comments. 247 8. References 248 8.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 254 Security", RFC 4347, April 2006. 256 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 257 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 258 May 2008. 260 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 261 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 263 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 264 Extension Definitions", RFC 6066, January 2011. 266 8.2. Informative References 268 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 269 Parameter for the Stream Control Transmission Protocol 270 (SCTP)", RFC 4820, March 2007. 272 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 273 Discovery", RFC 4821, March 2007. 275 Authors' Addresses 277 Robin Seggelmann 278 Muenster University of Applied Sciences 279 Stegerwaldstr. 39 280 48565 Steinfurt 281 DE 283 Email: seggelmann@fh-muenster.de 285 Michael Tuexen 286 Muenster University of Applied Sciences 287 Stegerwaldstr. 39 288 48565 Steinfurt 289 DE 291 Email: tuexen@fh-muenster.de 292 Michael Williams 294 Email: michael.glenn.williams@gmail.com