doc/protocol/rfc6520.txt

   1
   2
   3
   4
   5
   6
   7 Internet Engineering Task Force (IETF)                     R. Seggelmann
   8 Request for Comments: 6520                                     M. Tuexen
   9 Category: Standards Track               Muenster Univ. of Appl. Sciences
  10 ISSN: 2070-1721                                              M. Williams
  11                                                    GWhiz Arts & Sciences
  12                                                            February 2012
  13
  14
  15                    Transport Layer Security (TLS) and
  16       Datagram Transport Layer Security (DTLS) Heartbeat Extension
  17
  18 Abstract
  19
  20    This document describes the Heartbeat Extension for the Transport
  21    Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
  22    protocols.
  23
  24    The Heartbeat Extension provides a new protocol for TLS/DTLS allowing
  25    the usage of keep-alive functionality without performing a
  26    renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
  27
  28 Status of This Memo
  29
  30    This is an Internet Standards Track document.
  31
  32    This document is a product of the Internet Engineering Task Force
  33    (IETF).  It represents the consensus of the IETF community.  It has
  34    received public review and has been approved for publication by the
  35    Internet Engineering Steering Group (IESG).  Further information on
  36    Internet Standards is available in Section 2 of RFC 5741.
  37
  38    Information about the current status of this document, any errata,
  39    and how to provide feedback on it may be obtained at
  40    http://www.rfc-editor.org/info/rfc6520.
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Seggelmann, et al.           Standards Track                    [Page 1]
  59 \f
  60 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
  61
  62
  63 Copyright Notice
  64
  65    Copyright (c) 2012 IETF Trust and the persons identified as the
  66    document authors.  All rights reserved.
  67
  68    This document is subject to BCP 78 and the IETF Trust's Legal
  69    Provisions Relating to IETF Documents
  70    (http://trustee.ietf.org/license-info) in effect on the date of
  71    publication of this document.  Please review these documents
  72    carefully, as they describe your rights and restrictions with respect
  73    to this document.  Code Components extracted from this document must
  74    include Simplified BSD License text as described in Section 4.e of
  75    the Trust Legal Provisions and are provided without warranty as
  76    described in the Simplified BSD License.
  77
  78 Table of Contents
  79
  80    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  81    2.  Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
  82    3.  Heartbeat Protocol  . . . . . . . . . . . . . . . . . . . . . . 4
  83    4.  Heartbeat Request and Response Messages . . . . . . . . . . . . 5
  84    5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  85    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
  86    7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
  87    8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
  88    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  89
  90 1.  Introduction
  91
  92 1.1.  Overview
  93
  94    This document describes the Heartbeat Extension for the Transport
  95    Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
  96    protocols, as defined in [RFC5246] and [RFC6347] and their
  97    adaptations to specific transport protocols described in [RFC3436],
  98    [RFC5238], and [RFC6083].
  99
 100    DTLS is designed to secure traffic running on top of unreliable
 101    transport protocols.  Usually, such protocols have no session
 102    management.  The only mechanism available at the DTLS layer to figure
 103    out if a peer is still alive is a costly renegotiation, particularly
 104    when the application uses unidirectional traffic.  Furthermore, DTLS
 105    needs to perform path MTU (PMTU) discovery but has no specific
 106    message type to realize it without affecting the transfer of user
 107    messages.
 108
 109
 110
 111
 112
 113
 114 Seggelmann, et al.           Standards Track                    [Page 2]
 115 \f
 116 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 117
 118
 119    TLS is based on reliable protocols, but there is not necessarily a
 120    feature available to keep the connection alive without continuous
 121    data transfer.
 122
 123    The Heartbeat Extension as described in this document overcomes these
 124    limitations.  The user can use the new HeartbeatRequest message,
 125    which has to be answered by the peer with a HeartbeartResponse
 126    immediately.  To perform PMTU discovery, HeartbeatRequest messages
 127    containing padding can be used as probe packets, as described in
 128    [RFC4821].
 129
 130 1.2.  Conventions
 131
 132    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 133    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 134    document are to be interpreted as described in [RFC2119].
 135
 136 2.  Heartbeat Hello Extension
 137
 138    The support of Heartbeats is indicated with Hello Extensions.  A peer
 139    cannot only indicate that its implementation supports Heartbeats, it
 140    can also choose whether it is willing to receive HeartbeatRequest
 141    messages and respond with HeartbeatResponse messages or only willing
 142    to send HeartbeatRequest messages.  The former is indicated by using
 143    peer_allowed_to_send as the HeartbeatMode; the latter is indicated by
 144    using peer_not_allowed_to_send as the Heartbeat mode.  This decision
 145    can be changed with every renegotiation.  HeartbeatRequest messages
 146    MUST NOT be sent to a peer indicating peer_not_allowed_to_send.  If
 147    an endpoint that has indicated peer_not_allowed_to_send receives a
 148    HeartbeatRequest message, the endpoint SHOULD drop the message
 149    silently and MAY send an unexpected_message Alert message.
 150
 151    The format of the Heartbeat Hello Extension is defined by:
 152
 153    enum {
 154       peer_allowed_to_send(1),
 155       peer_not_allowed_to_send(2),
 156       (255)
 157    } HeartbeatMode;
 158
 159    struct {
 160       HeartbeatMode mode;
 161    } HeartbeatExtension;
 162
 163    Upon reception of an unknown mode, an error Alert message using
 164    illegal_parameter as its AlertDescription MUST be sent in response.
 165
 166
 167
 168
 169
 170 Seggelmann, et al.           Standards Track                    [Page 3]
 171 \f
 172 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 173
 174
 175 3.  Heartbeat Protocol
 176
 177    The Heartbeat protocol is a new protocol running on top of the Record
 178    Layer.  The protocol itself consists of two message types:
 179    HeartbeatRequest and HeartbeatResponse.
 180
 181    enum {
 182       heartbeat_request(1),
 183       heartbeat_response(2),
 184       (255)
 185    } HeartbeatMessageType;
 186
 187    A HeartbeatRequest message can arrive almost at any time during the
 188    lifetime of a connection.  Whenever a HeartbeatRequest message is
 189    received, it SHOULD be answered with a corresponding
 190    HeartbeatResponse message.
 191
 192    However, a HeartbeatRequest message SHOULD NOT be sent during
 193    handshakes.  If a handshake is initiated while a HeartbeatRequest is
 194    still in flight, the sending peer MUST stop the DTLS retransmission
 195    timer for it.  The receiving peer SHOULD discard the message
 196    silently, if it arrives during the handshake.  In case of DTLS,
 197    HeartbeatRequest messages from older epochs SHOULD be discarded.
 198
 199    There MUST NOT be more than one HeartbeatRequest message in flight at
 200    a time.  A HeartbeatRequest message is considered to be in flight
 201    until the corresponding HeartbeatResponse message is received, or
 202    until the retransmit timer expires.
 203
 204    When using an unreliable transport protocol like the Datagram
 205    Congestion Control Protocol (DCCP) or UDP, HeartbeatRequest messages
 206    MUST be retransmitted using the simple timeout and retransmission
 207    scheme DTLS uses for flights as described in Section 4.2.4 of
 208    [RFC6347].  In particular, after a number of retransmissions without
 209    receiving a corresponding HeartbeatResponse message having the
 210    expected payload, the DTLS connection SHOULD be terminated.  The
 211    threshold used for this SHOULD be the same as for DTLS handshake
 212    messages.  Please note that after the timer supervising a
 213    HeartbeatRequest messages expires, this message is no longer
 214    considered in flight.  Therefore, the HeartbeatRequest message is
 215    eligible for retransmission.  The retransmission scheme, in
 216    combination with the restriction that only one HeartbeatRequest is
 217    allowed to be in flight, ensures that congestion control is handled
 218    appropriately in case of the transport protocol not providing one,
 219    like in the case of DTLS over UDP.
 220
 221
 222
 223
 224
 225
 226 Seggelmann, et al.           Standards Track                    [Page 4]
 227 \f
 228 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 229
 230
 231    When using a reliable transport protocol like the Stream Control
 232    Transmission Protocol (SCTP) or TCP, HeartbeatRequest messages only
 233    need to be sent once.  The transport layer will handle
 234    retransmissions.  If no corresponding HeartbeatResponse message has
 235    been received after some amount of time, the DTLS/TLS connection MAY
 236    be terminated by the application that initiated the sending of the
 237    HeartbeatRequest message.
 238
 239 4.  Heartbeat Request and Response Messages
 240
 241    The Heartbeat protocol messages consist of their type and an
 242    arbitrary payload and padding.
 243
 244    struct {
 245       HeartbeatMessageType type;
 246       uint16 payload_length;
 247       opaque payload[HeartbeatMessage.payload_length];
 248       opaque padding[padding_length];
 249    } HeartbeatMessage;
 250
 251    The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
 252    max_fragment_length when negotiated as defined in [RFC6066].
 253
 254    type:  The message type, either heartbeat_request or
 255       heartbeat_response.
 256
 257    payload_length:  The length of the payload.
 258
 259    payload:  The payload consists of arbitrary content.
 260
 261    padding:  The padding is random content that MUST be ignored by the
 262       receiver.  The length of a HeartbeatMessage is TLSPlaintext.length
 263       for TLS and DTLSPlaintext.length for DTLS.  Furthermore, the
 264       length of the type field is 1 byte, and the length of the
 265       payload_length is 2.  Therefore, the padding_length is
 266       TLSPlaintext.length - payload_length - 3 for TLS and
 267       DTLSPlaintext.length - payload_length - 3 for DTLS.  The
 268       padding_length MUST be at least 16.
 269
 270    The sender of a HeartbeatMessage MUST use a random padding of at
 271    least 16 bytes.  The padding of a received HeartbeatMessage message
 272    MUST be ignored.
 273
 274    If the payload_length of a received HeartbeatMessage is too large,
 275    the received HeartbeatMessage MUST be discarded silently.
 276
 277
 278
 279
 280
 281
 282 Seggelmann, et al.           Standards Track                    [Page 5]
 283 \f
 284 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 285
 286
 287    When a HeartbeatRequest message is received and sending a
 288    HeartbeatResponse is not prohibited as described elsewhere in this
 289    document, the receiver MUST send a corresponding HeartbeatResponse
 290    message carrying an exact copy of the payload of the received
 291    HeartbeatRequest.
 292
 293    If a received HeartbeatResponse message does not contain the expected
 294    payload, the message MUST be discarded silently.  If it does contain
 295    the expected payload, the retransmission timer MUST be stopped.
 296
 297 5.  Use Cases
 298
 299    Each endpoint sends HeartbeatRequest messages at a rate and with the
 300    padding required for the particular use case.  The endpoint should
 301    not expect its peer to send HeartbeatRequests.  The directions are
 302    independent.
 303
 304 5.1.  Path MTU Discovery
 305
 306    DTLS performs path MTU discovery as described in Section 4.1.1.1 of
 307    [RFC6347].  A detailed description of how to perform path MTU
 308    discovery is given in [RFC4821].  The necessary probe packets are the
 309    HeartbeatRequest messages.
 310
 311    This method of using HeartbeatRequest messages for DTLS is similar to
 312    the one for the Stream Control Transmission Protocol (SCTP) using the
 313    padding chunk (PAD-chunk) defined in [RFC4820].
 314
 315 5.2.  Liveliness Check
 316
 317    Sending HeartbeatRequest messages allows the sender to make sure that
 318    it can reach the peer and the peer is alive.  Even in the case of
 319    TLS/TCP, this allows a check at a much higher rate than the TCP keep-
 320    alive feature would allow.
 321
 322    Besides making sure that the peer is still reachable, sending
 323    HeartbeatRequest messages refreshes the NAT state of all involved
 324    NATs.
 325
 326    HeartbeatRequest messages SHOULD only be sent after an idle period
 327    that is at least multiple round-trip times long.  This idle period
 328    SHOULD be configurable up to a period of multiple minutes and down to
 329    a period of one second.  A default value for the idle period SHOULD
 330    be configurable, but it SHOULD also be tunable on a per-peer basis.
 331
 332
 333
 334
 335
 336
 337
 338 Seggelmann, et al.           Standards Track                    [Page 6]
 339 \f
 340 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 341
 342
 343 6.  IANA Considerations
 344
 345    IANA has assigned the heartbeat content type (24) from the "TLS
 346    ContentType Registry" as specified in [RFC5246].  The reference is to
 347    RFC 6520.
 348
 349    IANA has created and now maintains a new registry for Heartbeat
 350    Message Types.  The message types are numbers in the range from 0 to
 351    255 (decimal).  IANA has assigned the heartbeat_request (1) and the
 352    heartbeat_response (2) message types.  The values 0 and 255 should be
 353    reserved.  This registry uses the Expert Review policy as described
 354    in [RFC5226].  The reference is to RFC 6520.
 355
 356    IANA has assigned the heartbeat extension type (15) from the TLS
 357    "ExtensionType Values" registry as specified in [RFC5246].  The
 358    reference is to RFC 6520.
 359
 360    IANA has created and now maintains a new registry for Heartbeat
 361    Modes.  The modes are numbers in the range from 0 to 255 (decimal).
 362    IANA has assigned the peer_allowed_to_send (1) and the
 363    peer_not_allowed_to_send (2) modes.  The values 0 and 255 should be
 364    reserved.  This registry uses the Expert Review policy as described
 365    in [RFC5226].  The reference is to RFC 6520.
 366
 367 7.  Security Considerations
 368
 369    The security considerations of [RFC5246] and [RFC6347] apply to this
 370    document.  This document does not introduce any new security
 371    considerations.
 372
 373 8.  Acknowledgments
 374
 375    The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen
 376    Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric
 377    Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their
 378    invaluable comments.
 379
 380 9.  References
 381
 382 9.1.  Normative References
 383
 384    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 385               Requirement Levels", BCP 14, RFC 2119, March 1997.
 386
 387    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
 388               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
 389               May 2008.
 390
 391
 392
 393
 394 Seggelmann, et al.           Standards Track                    [Page 7]
 395 \f
 396 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 397
 398
 399    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 400               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 401
 402    [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
 403               Extension Definitions", RFC 6066, January 2011.
 404
 405    [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 406               Security Version 1.2", RFC 6347, January 2012.
 407
 408 9.2.  Informative References
 409
 410    [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
 411               Layer Security over Stream Control Transmission Protocol",
 412               RFC 3436, December 2002.
 413
 414    [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
 415               Parameter for the Stream Control Transmission Protocol
 416               (SCTP)", RFC 4820, March 2007.
 417
 418    [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
 419               Discovery", RFC 4821, March 2007.
 420
 421    [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
 422               the Datagram Congestion Control Protocol (DCCP)",
 423               RFC 5238, May 2008.
 424
 425    [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
 426               Transport Layer Security (DTLS) for Stream Control
 427               Transmission Protocol (SCTP)", RFC 6083, January 2011.
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Seggelmann, et al.           Standards Track                    [Page 8]
 451 \f
 452 RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
 453
 454
 455 Authors' Addresses
 456
 457    Robin Seggelmann
 458    Muenster University of Applied Sciences
 459    Stegerwaldstr. 39
 460    48565 Steinfurt
 461    DE
 462
 463    EMail: seggelmann@fh-muenster.de
 464
 465
 466    Michael Tuexen
 467    Muenster University of Applied Sciences
 468    Stegerwaldstr. 39
 469    48565 Steinfurt
 470    DE
 471
 472    EMail: tuexen@fh-muenster.de
 473
 474
 475    Michael Glenn Williams
 476    GWhiz Arts & Sciences
 477    2885 Denise Court
 478    Newbury Park, CA, 91320
 479    USA
 480
 481    EMail: michael.glenn.williams@gmail.com
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Seggelmann, et al.           Standards Track                    [Page 9]
 507 \f