idnits 2.17.1 draft-ietf-tls-dtls-heartbeat-00.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 (June 18, 2010) is 5061 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 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 Applied Sciences 5 Expires: December 20, 2010 M. Williams 6 June 18, 2010 8 Transport Layer Security (TLS) and Datagram Transport Layer Security 9 (DTLS) Heartbeat Extension 10 draft-ietf-tls-dtls-heartbeat-00.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 December 20, 2010. 40 Copyright Notice 42 Copyright (c) 2010 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 1.1. Overview 73 This document describes the Heartbeat Extension for the Transport 74 Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 75 protocols, as defined in [RFC5246] and [RFC4347]. 77 DTLS is designed to secure traffic running on top of unreliable 78 transport protocols. Usually such protocols have no session 79 management. The only mechanism available at the DTLS layer to figure 80 out if a peer is still alive is performing a costly renegotiation. 81 If the application uses unidirectional traffic there is no other way. 82 Furthermore, DTLS needs to perform path maximum transmission unit 83 (PMTU) discovery but has no specific message type to realize it 84 without affecting user message transfer. 86 TLS is based on reliable protocols but there is not necessarily a 87 feature available to keep the connection alive without continuous 88 data transfer. 90 The Heartbeat Extension as described in this document overcomes these 91 limitations. The user can use the new HeartbeatRequest message which 92 has to be answered by the peer with a HeartbeartResponse immediately. 93 To perform PMTU discovery HeartbeatRequest messages containing 94 padding can be used as described in [RFC4821] for the Stream Control 95 Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) 96 defined in [RFC4820]. 98 1.2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Heartbeat Hello Extension 106 The support of Heartbeats is indicated with Hello Extensions. A peer 107 can not only indicate that its implementation supports Heartbeats, it 108 can also choose whether it is willing to receive and respond or only 109 to send them. This decision can be changed with every renegotiation. 110 HeartbeatRequests MUST NOT be sent to a peer denying acceptance. 112 enum { 113 peer_allowed_to_send(1), 114 peer_not_allowed_to_send(2), 115 (255) 116 } HeartbeatMode; 118 struct { 119 HeartbeatMode mode; 120 } HeartbeatExtension; 122 3. Heartbeat Protocol 124 The Heartbeat protocol is a new protocol on top of the Record Layer. 125 The protocol itself consists of two message types: HeartbeatRequest 126 and HeartbeatResponse. 128 enum { 129 heartbeat_request(1), 130 heartbeat_response(2), 131 (255) 132 } HeartbeatMessageType; 134 Like the ChangeCipherSpec message, a HeartbeatRequest message can 135 arrive at any time during the lifetime of a connection. Whenever a 136 HeartbeatRequest message is received, it has to be answered with a 137 corresponding HeartbeatResponse message immediately. 139 However, a HeartbeatRequest message SHOULD NOT be sent during 140 handshakes. 142 There MUST NOT be more than one HeartbeatRequest message in flight at 143 a time. 145 When using DTLS, HeartbeatRequest messages MUST be retransmitted 146 using the simple timeout and retransmission scheme DTLS uses for 147 flights. In particular, after a number of retransmissions without 148 receiving a corresponding HeartbeatResponse message having the 149 expected payload the DTLS connection SHOULD be terminated. The 150 threshold used for this SHOULD be the same as for DTLS handshake 151 messages. Please note, that after the timer supervising a 152 HeartbeatRequest messages expires, this message is not longer 153 considered in flight. Therefore the HeartbeatRequest message is 154 eligible for retransmission. 156 When using TLS, HeartbeatRequest messages only need to be sent once. 157 The transport layer will handle retransmissions. If no corresponding 158 HeartbeatResponse message has been received after a user configured 159 amount of time, the TLS connection SHOULD be terminated. 161 4. Heartbeat Request and Response Messages 163 The Heartbeat protocol messages consist of their type and an 164 arbitrary payload and padding. 166 struct { 167 HeartbeatMessageType type; 168 opaque payload<0..2^14-5>; 169 opaque padding<0..2^14-5>; 170 } HeartbeatMessage; 172 The length of payload and padding in total MUST NOT exceed 2^14-5 173 bytes. 175 When a HeartbeatRequest message is received, a corresponding 176 HeartbeatResponse message MUST be sent carrying an exact copy of the 177 payload of the HeartbeatRequest. The padding of the received 178 HeartbeatRequest message MUST be ignored. It MUST NOT be included in 179 the HeartbeatResponse message, i.e. the padding field of the 180 HeartbeatResponse message MUST have a length of zero. 182 If a received HeartbeatResponse message does not contain the expected 183 payload the message MUST be discarded silently. If it does contain 184 the expected payload the retransmission timer MUST be stopped. 186 5. IANA Considerations 188 The extension, content and message types have to be assigned by IANA. 190 6. Security Considerations 192 This document does not add any additional security considerations in 193 addition to the ones given in [RFC4347] and [RFC5246]. 195 7. Acknowledgments 197 The authors wish to thank Pasi Eronen, Eric Rescorla, and Peter 198 Saint-Andre for their invaluable comments. 200 8. References 201 8.1. Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 207 Security", RFC 4347, April 2006. 209 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 210 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 212 8.2. Informative References 214 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 215 Parameter for the Stream Control Transmission Protocol 216 (SCTP)", RFC 4820, March 2007. 218 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 219 Discovery", RFC 4821, March 2007. 221 Authors' Addresses 223 Robin Seggelmann 224 Muenster University of Applied Sciences 225 Stegerwaldstr. 39 226 48565 Steinfurt 227 DE 229 Email: seggelmann@fh-muenster.de 231 Michael Tuexen 232 Muenster University of Applied Sciences 233 Stegerwaldstr. 39 234 48565 Steinfurt 235 DE 237 Email: tuexen@fh-muenster.de 239 Michael Williams 241 Email: michael.glenn.williams@gmail.com