idnits 2.17.1 draft-ietf-tls-dtls-heartbeat-02.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 (July 11, 2011) is 4672 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 Appl. Sciences 5 Expires: January 12, 2012 M. Williams 6 July 11, 2011 8 Transport Layer Security (TLS) and Datagram Transport Layer Security 9 (DTLS) Heartbeat Extension 10 draft-ietf-tls-dtls-heartbeat-02.txt 12 Abstract 14 This document describes the Heartbeat Extension for the Transport 15 Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 16 protocol. 18 The Heartbeat Extension provides a new protocol for TLS/DTLS allowing 19 the usage of keep-alive functionality without performing a 20 renegotiation and a basis for path maximum transmission unit (PMTU) 21 discovery for DTLS. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 12, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3 59 3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5 61 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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] and their adoptions 77 to specific transport protocol as described in [RFC3436], [RFC5238], 78 and [RFC6083]. 80 DTLS is designed to secure traffic running on top of unreliable 81 transport protocols. Usually such protocols have no session 82 management. The only mechanism available at the DTLS layer to figure 83 out if a peer is still alive is performing a costly renegotiation. 84 If the application uses unidirectional traffic there is no other way. 85 Furthermore, DTLS needs to perform path maximum transmission unit 86 (PMTU) discovery but has no specific message type to realize it 87 without affecting user message transfer. 89 TLS is based on reliable protocols but there is not necessarily a 90 feature available to keep the connection alive without continuous 91 data transfer. 93 The Heartbeat Extension as described in this document overcomes these 94 limitations. The user can use the new HeartbeatRequest message which 95 has to be answered by the peer with a HeartbeartResponse immediately. 96 To perform PMTU discovery, HeartbeatRequest messages containing 97 padding can be used as probe packets as described in [RFC4821]. 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 HeartbeatRequest 110 messages and respond with HeartbeatResponse messages or only to send 111 HeartbeatRequest messages. The former is indicated by using 112 peer_allowed_to_send as the HeartbeatMode, the latter is indicated by 113 using peer_not_allowed_to_send as the Heartbeat mode. This decision 114 can be changed with every renegotiation. HeartbeatRequest messages 115 MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If 116 an endpoint has indicated peer_not_allowed_to_send and receives a 117 HeartbeatRequest message SHOULD drop the message silently and MAY 118 send an unexpected_message Alert message. 120 The format of the Heartbeat Hello Extension is defined by: 122 enum { 123 peer_allowed_to_send(1), 124 peer_not_allowed_to_send(2), 125 (255) 126 } HeartbeatMode; 128 struct { 129 HeartbeatMode mode; 130 } HeartbeatExtension; 132 Upon reception of an unknown mode, an error Alert message using 133 illegal_parameter as its AlertDescription MUST be sent in response. 135 3. Heartbeat Protocol 137 The Heartbeat protocol is a new protocol on top of the Record Layer. 138 The protocol itself consists of two message types: HeartbeatRequest 139 and HeartbeatResponse. 141 enum { 142 heartbeat_request(1), 143 heartbeat_response(2), 144 (255) 145 } HeartbeatMessageType; 147 Like the ChangeCipherSpec message, a HeartbeatRequest message can 148 arrive at any time during the lifetime of a connection. Whenever a 149 HeartbeatRequest message is received, it has to be answered with a 150 corresponding HeartbeatResponse message immediately. 152 However, a HeartbeatRequest message SHOULD NOT be sent during 153 handshakes. If a handshake is initiated while a HeartbeatRequest is 154 still in flight, the sending peer MUST stop the retransmission timer 155 for it. The receiving peer SHOULD discard it silently, if it arrives 156 during or after the handshake. HeartbeatRequest messages from older 157 epochs SHOULD be discarded. 159 There MUST NOT be more than one HeartbeatRequest message in flight at 160 a time. A HeartbeatRequest message is considered to be in flight 161 until the corresponding HeartbeatResponse message is received, or 162 until the retransmit timer expires. 164 When using an unreliable transport protocol like DCCP or UDP, 165 HeartbeatRequest messages MUST be retransmitted using the simple 166 timeout and retransmission scheme DTLS uses for flights as described 167 in Section 4.2.4 of [RFC4347]. In particular, after a number of 168 retransmissions without receiving a corresponding HeartbeatResponse 169 message having the expected payload the DTLS connection SHOULD be 170 terminated. The threshold used for this SHOULD be the same as for 171 DTLS handshake messages. Please note, that after the timer 172 supervising a HeartbeatRequest messages expires, this message is no 173 longer considered in flight. Therefore the HeartbeatRequest message 174 is eligible for retransmission. The retransmission scheme in 175 combination with the restriction that only one HeartbeatRequest is 176 allowed to be in flight ensures that the congestion control is 177 handled appropriately in case of the transport protocol not providing 178 one, like in the case of DTLS over UDP. 180 When using a reliable transport protocol like SCTP or TCP, 181 HeartbeatRequest messages only need to be sent once. The transport 182 layer will handle retransmissions. If no corresponding 183 HeartbeatResponse message has been received after a user configured 184 amount of time, the DTLS/TLS connection SHOULD be terminated. 186 4. Heartbeat Request and Response Messages 188 The Heartbeat protocol messages consist of their type and an 189 arbitrary payload and padding. 191 struct { 192 HeartbeatMessageType type; 193 uint16 payload_length; 194 opaque payload[HeartbeatMessage.payload_length]; 195 opaque padding[padding_length]; 196 } HeartbeatMessage; 198 The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or 199 max_fragment_length when negotiated as defined in [RFC6066]. 201 type: The message type, either heartbeat_request or 202 heartbeat_response. 204 payload_length: The length of the payload. 206 payload: The payload consists of arbitrary content. 208 padding: The padding is additional arbitrary content which MUST be 209 ignored by the receiver. The padding_length is 210 TLSPlaintext.length - payload_length - 3 with TLS and 211 DTLSPlaintext.length - payload_length - 3 with DTLS. 213 When a HeartbeatRequest message is received, a corresponding 214 HeartbeatResponse message MUST be sent carrying an exact copy of the 215 payload of the HeartbeatRequest. The padding of the received 216 HeartbeatRequest message MUST be ignored. It MUST NOT be included in 217 the HeartbeatResponse message, i.e. the padding field of the 218 HeartbeatResponse message MUST have a length of zero. 220 If a received HeartbeatResponse message does not contain the expected 221 payload the message MUST be discarded silently. If it does contain 222 the expected payload the retransmission timer MUST be stopped. 224 If payload_length is either shorter than expected and thus indicates 225 padding in a HeartbeatResponse or exceeds the actual message length 226 in any message type, an error Alert message using illegal_parameter 227 as its AlertDescription MUST be sent in response. 229 5. Use Cases 231 5.1. Path MTU Discovery 233 DTLS performs path MTU discovery as described in Section 4.1.1.1 of 234 [RFC4347]. A detailed description how to perform path MTU discovery 235 is given in [RFC4821]. The necessary probe packets are the 236 HeartbeatRequest messages. 238 This method using HeartbeatRequest messages for DTLS is similar to 239 the one for the Stream Control Transmission Protocol (SCTP) using the 240 padding chunk (PAD-chunk) defined in [RFC4820]. 242 5.2. Liveliness check 244 Sending HeartbeatRequest messages allows the sender to make sure that 245 it can reach the peer and the peer is alive. Even in case of TLS/TCP 246 this allows this check at a much higher rate than the TCP keepalive 247 feature would allow. 249 Besides making sure that the peer is still reachable, sending 250 HeartbeatRequest messages refreshes the NAT state of all involved 251 NATs. 253 HeartbeatRequest messages SHOULD only be sent after an idle period 254 that is at least multiple round trip times long. 256 6. IANA Considerations 258 [NOTE to RFC-Editor: 260 "RFCXXXX" is to be replaced by the RFC number you assign this 261 document. 263 ] 265 IANA needs to assign the heartbeat content type (value TBD) from the 266 TLS ContentType Registry as specified in [RFC5246]. The reference 267 should be RFCXXXX. 269 IANA needs to maintain a new registry for Heartbeat Message Types. 270 The message types are numbers in the range from 0 to 255 (decimal). 271 Initially IANA needs to assign the heartbeat_request (suggested value 272 1) and the heartbeat_response (suggested value 2) message type. The 273 values 0 and 255 should be reserved. This registry uses the 274 Specification Required policy as described in [RFC5226]. The 275 reference should be RFCXXXX. 277 IANA needs to assign the heartbeat extension type (value TBD) from 278 the TLS Extension Type Registry as specified in [RFC5246]. The 279 reference should be RFCXXXX. 281 IANA needs to maintain a new registry for Heartbeat Modes. The modes 282 are numbers in the range from 0 to 255 (decimal). Initially IANA 283 needs to assign the peer_allowed_to_send (suggested value 1) and the 284 peer_not_allowed_to_send (suggested value 2) modes. The values 0 and 285 255 should be reserved. This registry uses the Specification 286 Required policy as described in [RFC5226]. The reference should be 287 RFCXXXX. 289 7. Security Considerations 291 This document does not add any additional security considerations in 292 addition to the ones given in [RFC4347] and [RFC5246]. 294 8. Acknowledgments 296 The authors wish to thank Pasi Eronen, Adam Langley, Tom Petch, Eric 297 Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their 298 invaluable comments. 300 9. References 301 9.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 307 Security", RFC 4347, April 2006. 309 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 310 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 311 May 2008. 313 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 314 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 316 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 317 Extension Definitions", RFC 6066, January 2011. 319 9.2. Informative References 321 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 322 Layer Security over Stream Control Transmission Protocol", 323 RFC 3436, December 2002. 325 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 326 Parameter for the Stream Control Transmission Protocol 327 (SCTP)", RFC 4820, March 2007. 329 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 330 Discovery", RFC 4821, March 2007. 332 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 333 the Datagram Congestion Control Protocol (DCCP)", 334 RFC 5238, May 2008. 336 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 337 Transport Layer Security (DTLS) for Stream Control 338 Transmission Protocol (SCTP)", RFC 6083, January 2011. 340 Authors' Addresses 342 Robin Seggelmann 343 Muenster University of Applied Sciences 344 Stegerwaldstr. 39 345 48565 Steinfurt 346 DE 348 Email: seggelmann@fh-muenster.de 350 Michael Tuexen 351 Muenster University of Applied Sciences 352 Stegerwaldstr. 39 353 48565 Steinfurt 354 DE 356 Email: tuexen@fh-muenster.de 358 Michael Williams 360 Email: michael.glenn.williams@gmail.com