idnits 2.17.1 draft-ietf-tls-dtls-heartbeat-04.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 (December 2, 2011) is 4528 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 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: June 4, 2012 M. Williams 6 December 2, 2011 8 Transport Layer Security (TLS) and Datagram Transport Layer Security 9 (DTLS) Heartbeat Extension 10 draft-ietf-tls-dtls-heartbeat-04.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 June 4, 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 . . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 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 [I-D.ietf-tls-rfc4347-bis] and 77 their adaptations to specific transport protocols described in 78 [RFC3436], [RFC5238], 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 that has indicated peer_not_allowed_to_send receives a 117 HeartbeatRequest message, the endpoint SHOULD drop the message 118 silently and MAY 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 A HeartbeatRequest message can arrive almost at any time during the 148 lifetime of a connection. Whenever a HeartbeatRequest message is 149 received, it SHOULD be answered with a corresponding 150 HeartbeatResponse message. 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 DTLS retransmission 155 timer for it. The receiving peer SHOULD discard it silently, if it 156 arrives during the handshake. In case of DTLS, HeartbeatRequest 157 messages from older 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 [I-D.ietf-tls-rfc4347-bis]. In particular, after 168 a number of retransmissions without receiving a corresponding 169 HeartbeatResponse message having the expected payload the DTLS 170 connection SHOULD be terminated. The threshold used for this SHOULD 171 be the same as for DTLS handshake messages. Please note, that after 172 the timer supervising a HeartbeatRequest messages expires, this 173 message is no longer considered in flight. Therefore the 174 HeartbeatRequest message is eligible for retransmission. The 175 retransmission scheme in combination with the restriction that only 176 one HeartbeatRequest is allowed to be in flight ensures that the 177 congestion control is handled appropriately in case of the transport 178 protocol not providing 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 some amount of 184 time, the DTLS/TLS connection MAY be terminated by the application 185 that initiated the sending of the HeartbeatRequest message. 187 4. Heartbeat Request and Response Messages 189 The Heartbeat protocol messages consist of their type and an 190 arbitrary payload and padding. 192 struct { 193 HeartbeatMessageType type; 194 uint16 payload_length; 195 opaque payload[HeartbeatMessage.payload_length]; 196 opaque padding[padding_length]; 197 } HeartbeatMessage; 199 The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or 200 max_fragment_length when negotiated as defined in [RFC6066]. 202 type: The message type, either heartbeat_request or 203 heartbeat_response. 205 payload_length: The length of the payload. 207 payload: The payload consists of arbitrary content. 209 padding: The padding is random content which MUST be ignored by the 210 receiver. The length of a HeartbeatMessage is TLSPlaintext.length 211 for TLS and DTLSPlaintext.length for DTLS. Furthermore the length 212 of the type field is 1 byte and the length of the payload_length 213 is 2. Therefore, the padding_length is TLSPlaintext.length - 214 payload_length - 3 for TLS and DTLSPlaintext.length - 215 payload_length - 3 for DTLS. The padding_length MUST be at least 216 16. 218 The sender of a HeartbeatMessage MUST use a random padding of at 219 least 16 bytes. The padding of a received HeartbeatMessage message 220 MUST be ignored. 222 If the payload_length of a received HeartbeatMessage is too large, 223 the received HeartbeatMessage MUST be discarded silently. 225 When a HeartbeatRequest message is received and sending a 226 HeartbeatResponse is not prohibited as described elsewhere in this 227 document, the receiver MUST send a corresponding HeartbeatResponse 228 message carrying an exact copy of the payload of the received 229 HeartbeatRequest. 231 If a received HeartbeatResponse message does not contain the expected 232 payload the message MUST be discarded silently. If it does contain 233 the expected payload the retransmission timer MUST be stopped. 235 5. Use Cases 237 Each endpoint sends HeartbeatRequest messages at a rate and with the 238 padding required for the particular use case. The endpoint should 239 not expect its peer to send HeartbeatRequests. The directions are 240 independent. 242 5.1. Path MTU Discovery 244 DTLS performs path MTU discovery as described in Section 4.1.1.1 of 245 [I-D.ietf-tls-rfc4347-bis]. A detailed description how to perform 246 path MTU discovery is given in [RFC4821]. The necessary probe 247 packets are the HeartbeatRequest messages. 249 This method using HeartbeatRequest messages for DTLS is similar to 250 the one for the Stream Control Transmission Protocol (SCTP) using the 251 padding chunk (PAD-chunk) defined in [RFC4820]. 253 5.2. Liveliness check 255 Sending HeartbeatRequest messages allows the sender to make sure that 256 it can reach the peer and the peer is alive. Even in case of TLS/TCP 257 this allows a check at a much higher rate than the TCP keep-alive 258 feature would allow. 260 Besides making sure that the peer is still reachable, sending 261 HeartbeatRequest messages refreshes the NAT state of all involved 262 NATs. 264 HeartbeatRequest messages SHOULD only be sent after an idle period 265 that is at least multiple round trip times long. This idle period 266 SHOULD to be configurable up to a period of multiple minutes and down 267 to a period of one second. A default value for the idle period 268 SHOULD be configurable but it SHOULD also be tunable on a per peer 269 basis. 271 6. IANA Considerations 273 [NOTE to RFC-Editor: 275 "RFCXXXX" is to be replaced by the RFC number you assign this 276 document. 278 ] 280 IANA needs to assign the heartbeat content type (value TBD) from the 281 TLS ContentType Registry as specified in [RFC5246]. The reference 282 should be RFCXXXX. 284 IANA needs to maintain a new registry for Heartbeat Message Types. 285 The message types are numbers in the range from 0 to 255 (decimal). 286 Initially IANA needs to assign the heartbeat_request (suggested value 287 1) and the heartbeat_response (suggested value 2) message type. The 288 values 0 and 255 should be reserved. This registry uses the Expert 289 Review policy as described in [RFC5226]. The reference should be 290 RFCXXXX. 292 IANA needs to assign the heartbeat extension type (value TBD) from 293 the TLS Extension Type Registry as specified in [RFC5246]. The 294 reference should be RFCXXXX. 296 IANA needs to maintain a new registry for Heartbeat Modes. The modes 297 are numbers in the range from 0 to 255 (decimal). Initially IANA 298 needs to assign the peer_allowed_to_send (suggested value 1) and the 299 peer_not_allowed_to_send (suggested value 2) modes. The values 0 and 300 255 should be reserved. This registry uses the Expert Review policy 301 as described in [RFC5226]. The reference should be RFCXXXX. 303 7. Security Considerations 305 This document does not add any additional security considerations in 306 addition to the ones given in [I-D.ietf-tls-rfc4347-bis] and 307 [RFC5246]. 309 8. Acknowledgments 311 The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen 312 Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric 313 Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their 314 invaluable comments. 316 9. References 318 9.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 324 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 325 May 2008. 327 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 328 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 330 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 331 Extension Definitions", RFC 6066, January 2011. 333 [I-D.ietf-tls-rfc4347-bis] 334 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 335 Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work 336 in progress), July 2011. 338 9.2. Informative References 340 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 341 Layer Security over Stream Control Transmission Protocol", 342 RFC 3436, December 2002. 344 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 345 Parameter for the Stream Control Transmission Protocol 346 (SCTP)", RFC 4820, March 2007. 348 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 349 Discovery", RFC 4821, March 2007. 351 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 352 the Datagram Congestion Control Protocol (DCCP)", 353 RFC 5238, May 2008. 355 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 356 Transport Layer Security (DTLS) for Stream Control 357 Transmission Protocol (SCTP)", RFC 6083, January 2011. 359 Authors' Addresses 361 Robin Seggelmann 362 Muenster University of Applied Sciences 363 Stegerwaldstr. 39 364 48565 Steinfurt 365 DE 367 Email: seggelmann@fh-muenster.de 369 Michael Tuexen 370 Muenster University of Applied Sciences 371 Stegerwaldstr. 39 372 48565 Steinfurt 373 DE 375 Email: tuexen@fh-muenster.de 377 Michael Williams 379 Email: michael.glenn.williams@gmail.com