corrected copyright notices

[gnutls.git] / doc / protocol / draft-rescorla-dtls-04.txt

                                                           E. Rescorla
                                                              RTFM, Inc.
                                                             N. Modadugu
INTERNET-DRAFT                                       Stanford University
<draft-rescorla-dtls-04.txt>           April 2004 (Expires October 2005)

                   Datagram Transport Layer Security

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (1999-2004). All Rights Reserved.






Rescorla, Modadugu                                               [Page 1]\f


Abstract

   This document specifies Version 1.0 of the Datagram Transport
   Layer Security (DTLS) protocol. The DTLS protocol provides
   communications privacy for datagram protocols. The protocol
   allows client/server applications to communicate in a way that
   is designed to prevent eavesdropping, tampering, or message
   forgery. The DTLS protocol is based on the TLS protocol and
   provides equivalent security guarantees. Datagram semantics of
   the underlying transport are preserved by the DTLS protocol.


Contents

   1           Introduction                                          3
     1.1         Requirements Terminology                            3
   2           Usage Model                                           4
   3           Overview of DTLS                                      4
     3.1         Loss-insensitive messaging                          4
     3.2         Providing Reliability for Handshake                 5
       3.2.1       Packet Loss                                       5
       3.2.2       Reordering                                        6
       3.2.3       Message Size                                      6
     3.3         Replay Detection                                    6
   4           Differences from TLS                                  6
     4.1         Record Layer                                        7
       4.1.1       Transport Layer Mapping                           8
         4.1.1.1     PMTU Discovery                                  8
       4.1.2       Record payload protection                         9
         4.1.2.1     MAC                                             9
         4.1.2.2     Null or standard stream cipher                  9
         4.1.2.3     Block Cipher                                   10
         4.1.2.4     New Cipher Suites                              10
         4.1.2.5     Anti-Replay                                    10
     4.2         The DTLS Handshake Protocol                        11
       4.2.1       Denial of Service Countermeasures                11
       4.2.2       Handshake Message Format                         13
       4.2.3       Message Fragmentation and Reassembly             15
       4.2.4       Timeout and Retransmission                       16
         4.2.4.1     Timer Values                                   19
       4.2.5       ChangeCipherSpec                                 20
       4.2.6       Finished messages                                20
       4.2.7       Alert Messages                                   20
     4.2         Record Layer                                       20
     4.3         Handshake Protocol                                 21
   5           Security Considerations                              22
   6           IANA Considerations                                  22




Rescorla, Modadugu                                               [Page 2]\f


1. Introduction

   TLS [TLS] is the most widely deployed protocol for securing
   network traffic. It is widely used for protecting Web traffic
   and for e-mail protocols such as IMAP [IMAP] and POP [POP].
   The primary advantage of TLS is that it provides a transparent
   connection-oriented channel. Thus, it is easy to secure an
   application protocol by inserting TLS between the application
   layer and the transport layer. However, TLS must run over a
   reliable transport channel--typically TCP [TCP]. It therefore
   cannot be used to secure unreliable datagram traffic.

   However, over the past few years an increasing number of
   application layer protocols have been designed which UDP
   transport. In particular such protocols as the Session
   Initiation Protocol (SIP) [SIP], and electronic gaming
   protocols are increasingly popular. (Note that SIP can run
   over both TCP and UDP, but that there are situations in which
   UDP is preferable). Currently, designers of these applications
   are faced with a number of unsatisfactory choices. First, they
   can use IPsec [RFC2401]. However, for a number of reasons
   detailed in [WHYIPSEC], this is only suitable for some
   applications. Second, they can design a custom application
   layer security protocol. SIP, for instance, uses a subsert of
   S/MIME to secure its traffic. Unfortunately, while application
   layer security protocols generally provide superior security
   properties (e.g., end-to-end security in the case of S/MIME)
   it typically require a large amount of effort to design--by
   contrast to the relatively small amount of effort required to
   run the protocol over TLS.

   In many cases, the most desirable way to secure client/server
   applications would be to use TLS; however the requirement for
   datagram semantics automatically prohibits use of TLS. Thus, a
   datagram-compatible variant of TLS would be very desirable.
   This memo describes such a protocol: Datagram Transport Layer
   Security (DTLS). DTLS is deliberately designed to be as
   similar to to TLS as possible, both to minimize new security
   invention and to maximize the amount of code and
   infrastructure reuse.


1.1. Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
   NOT" and "MAY" that appear in this document are to be
   interpreted as described in RFC 2119 [REQ].




Rescorla, Modadugu                                               [Page 3]\f


2. Usage Model

   The DTLS protocol is designed to secure data between
   communicating applications. It is designed to run in
   application space, without requiring any kernel modifications.

   Datagram transport does not require or provide reliable or in-
   order delivery of data. The DTLS protocol preserves this
   property for payload data. Applications such as media
   streaming, Internet telephony and online gaming use datagram
   transport for communication due to the delay-sensitive nature
   of transported data. The behavior of such applications is
   unchanged when the DTLS protocol is used to secure
   communication, since the DTLS protocol does not compensate for
   lost or re-ordered data traffic.

3. Overview of DTLS

   The basic design philosophy of DTLS is to construct "TLS over
   datagram". The reason that TLS cannot be used directly in
   datagram environments is simply that packets may be lost or
   reordered. TLS has no internal facilities to handle this kind
   of unreliability and therefore TLS implementations break when
   rehosted on datagram transport. The purpose of DTLS is to make
   only the minimal changes to TLS required to fix this problem.
   To the greatest extent possible, DTLS is identical to TLS.
   Whenever we need to invent new mechanisms, we attempt to do so
   in such a way that it preserves the style of TLS.

   Unreliability creates problems for TLS at two levels:

      1. TLS's traffic encryption layer does not allow
      independent decryption of individual records. If record N
      is not received, then record N+1 cannot be decrypted.

      2. The TLS handshake layer assumes that handshake messages
      are delivered reliably and breaks if those messages are
      lost.

   The rest of this section describes the approach that DTLS uses
   to solve these problems.

3.1. Loss-insensitive messaging

   In TLS's traffic encryption layer (called the TLS Record
   Layer), records are not independent. There are two kinds of
   inter-record dependency:




Rescorla, Modadugu                                               [Page 4]\f


      1. Cryptographic context (CBC state, stream cipher key
      stream) is chained between records.

      2. Anti-replay and message reordering protection are
      provided by a MAC which includes a sequence number, but the
      sequence numbers are implicit in the records.

   The fix for both of these problems is straightforward and
   well-known from IPsec ESP [ESP]: add explicit state to the
   records. TLS 1.1 [TLS11] is already adding explicit CBC state
   to TLS records. DTLS borrows that mechanism and adds explicit
   sequence numbers.

3.2. Providing Reliability for Handshake

   The TLS handshake is a lockstep cryptographic handshake.
   Messages must be transmitted and received in a defined order
   and any other order is an error. Clearly, this is incompatible
   with reordering and message loss. In addition, TLS handshake
   messages are potentially larger than any given datagram, thus
   creating the problem of fragmentation. DTLS must provide fixes
   for both these problems.

3.2.1. Packet Loss

   DTLS uses a simple retransmission timer to handle packet loss.
   The following figure demonstrates the basic concept using the
   first phase of the DTLS handshake:

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                              X<-- HelloVerifyRequest
                                               (lost)

      [Timer Expires]

      ClientHello           ------>
      (retransmit)

   Once the client has transmitted the ClientHello message, it
   expects to see a HelloVerifyRequest from the server. However,
   if the server's message is lost the client knows that either
   the ClientHello or the HelloVerifyRequest has been lost and
   retransmits. When the server receives the retransmission, it
   knows to retransmit. The server also maintains a
   retransmission timer and retransmits when that timer expires.



Rescorla, Modadugu                                               [Page 5]\f


   Note: timeout and retransmission do not apply to the
   HelloVerifyRequest, because this requires creating state on
   the server.

3.2.2. Reordering

   In DTLS, each handshake message is assigned a specific
   sequence number within that handshake. When a peer receives a
   handshake message, it can quickly determine whether that
   message is the next message it expects. If it is, then it
   processes it. If not, it queues it up for future handling once
   all previous messages have been received.

3.2.3. Message Size

   TLS and DTLS handshake messages can be quite large (in theory
   up to 2^24-1 bytes, in practice many kilobytes). By contrast,
   UDP datagrams are often limited to <1500 bytes if
   fragmentation is not desired. In order to compensate for this
   limitation, each DTLS handshake message may be fragmented over
   several DTLS records. Each DTLS handshake message contains
   both a fragment offset and a fragment length. Thus, a
   recipient in possession of all bytes of a handshake message
   can reassemble the original unfragmented message.

3.3. Replay Detection

   DTLS optionally supports record replay detection. The
   technique used is the same as in IPsec AH/ESP, by maintaining
   a bitmap window of received records. Records that are too old
   to fit in the window and records that have been previously
   received are silently discarded. The replay detection feature
   is optional, since packet duplication is not always malicious,
   but can also occur due to routing errors. Applications may
   conceivably detect duplicate packets and accordingly modify
   their data transmission strategy.

4. Differences from TLS

   As mentioned in Section 3., DTLS is intentionally very similar
   to TLS. Therefore, instead of presenting DTLS as a new
   protocol, we instead present it as a series of deltas from TLS
   1.1 [TLS11]. Where we do not explicitly call out differences,
   DTLS is the same as TLS.







Rescorla, Modadugu                                               [Page 6]\f


4.1. Record Layer

   The DTLS record layer is extremely similar to that of TLS 1.1.
   The only change is the inclusion of an explicit sequence
   number in the record. This sequence number allows the
   recipient to correctly verify the TLS MAC. The DTLS record
   format is shown below:

       struct {
        ContentType type;
        ProtocolVersion version;
        uint16 epoch;               // New field
        uint48 sequence_number;       // New field
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
       } DTLSPlaintext;

      type
       Equivalent to the type field in a TLS 1.1 record.

      version
       The version of the protocol being employed. This document
       describes DTLS Version 1.0, which uses the version { 254, 255
       }. The version value of 254.255 is the 1's complement of DTLS
       Version 1.0. This maximal spacing between TLS and DTLS version
       numbers ensures that records from the two protocols can be
       easily distinguished.

      epoch
       A counter value that is incremented on every cipher state
       change.

      sequence_number
       The sequence number for this record.

      length
       Identical to the length field in a TLS 1.1 record. As in TLS
       1.1, the length should not exceed 2^14.

      fragment
       Identical to the fragment field of a TLS 1.1 record.

   DTLS uses an explicit rather than implicit sequence number,
   carried in the sequence_number field of the record. As with
   TLS, the sequence number is set to zero after each
   ChangeCipherSpec message is sent.





Rescorla, Modadugu                                               [Page 7]\f


   If several handshakes are performed in close succession, there
   might be multiple records on the wire with the same sequence
   number but from different cipher states. The epoch field
   allows recipients to distinguish such packets. The epoch
   number is initially zero and is incremented each time the
   ChangeCipherSpec messages is sent. In order to ensure that any
   given sequence/epoch pair is unique, implementations MUST NOT
   allow the same epoch value to be reused within two times the
   TCP maximum segment lifetime. In practice, TLS implementations
   rehandshake rarely and we therefore do not expect this to be a
   problem.

4.1.1. Transport Layer Mapping

   Each DTLS record MUST fit within a single datagram. In order
   to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
   determine the MTU and send records smaller than the MTU. DTLS
   implementations SHOULD provide a way for applications to
   determine the value of the PMTU (or alternately the maximum
   application datagram size, which is the PMTU minus the DTLS
   per-record overhead). If the application attempts to send a
   record larger than the MTU the DTLS implementation SHOULD
   generate an error, thus avoiding sending a packet which will
   be fragmented.

   Note that unlike IPsec, DTLS records do not contain any
   association identifiers. Applications must arrange to
   multiplex between associations. With UDP, this is presumably
   done with host/port number.

   Multiple DTLS records may be placed in a single datagram. hey
   are simply encoded consecutively. The DTLS record framing is
   sufficient to determine the boundaries. Note, however, that
   the first byte of the datagram payload must be the beginning
   of a record. Records may not span datagrams.

4.1.1.1. PMTU Discovery

   In general, DTLS's philosophy is to avoid dealing with PMTU
   issues. The general strategy is to start with a conservative
   MTU and then update it if events require it, but not actively
   probe for MTU values. PMTU discovery is left to the
   application.

   The PMTU SHOULD be initialized from the interface MTU that
   will be used to send packets. If the DTLS implementation
   receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
   message with the "fragmentation needed and DF set" Code



Rescorla, Modadugu                                               [Page 8]\f


   (otherwise known as Datagram Too Big) it should decrease its
   PMTU estimate to that given in the ICMP message. A DTLS
   implementation SHOULD allow the application to occasionally
   reset its PMTU estimate. The DTLS implementation SHOULD also
   allow applications to control the status of the DF bit. These
   controls allow the application to perform PMTU discovery.

   One special case is the DTLS handshake system. Handshake
   messages should be set with DF set. Because some firewalls and
   routers screen out ICMP messages, it is difficult for the
   handshake layer to distinguish packet loss from an overlarge
   PMTU estimate. In order to allow connections under these
   circumstances, DTLS implementations SHOULD back off handshake
   packet size during the retransmit backoff described in Section
   4.2.4.. For instance, if a large packet is being sent, after 3
   retransmits the handshake layer might choose to fragment the
   handshake message on retransmission. In general, choice of a
   conservative initial MTU will avoid this problem.

4.1.2. Record payload protection

   Like TLS, DTLS transmits data as a series of protected
   records. The rest of this section describes the details of
   that format.

4.1.2.1. MAC

   The DTLS MAC is the same as that of TLS 1.1. However, rather
   than using TLS's implicit sequence number, the sequence number
   used to compute the MAC is the 64-bit value formed by
   concatenating the epoch and the sequence number in the order
   they appear on the wire. Note that the DTLS epoch + sequence
   number is the same length as the TLS sequence number.

   Note that one important difference between DTLS and TLS MAC
   handling is that in TLS MAC errors must result in connection
   termination. In DTLS, the receiving implementation MAY simply
   discard the offending record and continue with the connection.
   This change is possible because DTLS records are not dependent
   on each other the way that TLS records are.


4.1.2.2. Null or standard stream cipher

   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL
   cipher.





Rescorla, Modadugu                                               [Page 9]\f


   The only stream cipher described in TLS 1.1 is RC4, which
   cannot be randomly accessed. RC4 MUST NOT be used with DTLS.

4.1.2.3. Block Cipher

   DTLS block cipher encryption and decryption are performed
   exactly as with TLS 1.1.

4.1.2.4. New Cipher Suites

   Upon registration, new TLS cipher suites MUST indicate whether
   they are suitable for DTLS usage and what, if any, adaptations
   must be made.

4.1.2.5. Anti-Replay

   DTLS records contain a sequence number to provide replay
   protection. Sequence number verification SHOULD be performed
   using the following sliding, window procedure, borrowed from
   Section 3.4.3 of [RFC 2402]

   The receiver packet counter for this session MUST be
   initialized to zero when the session is established. For each
   received record, the receiver MUST verify that the record
   contains a Sequence Number that does not duplicate the
   Sequence Number of any other record received during the life
   of this session. This SHOULD be the first check applied to a
   packet after it has been matched to a session, to speed
   rejection of duplicate records.

   Duplicates are rejected through the use of a sliding receive
   window. (How the window is implemented is a local matter, but
   the following text describes the functionality that the
   implementation must exhibit.) A minimum window size of 32 MUST
   be supported; but a window size of 64 is preferred and SHOULD
   be employed as the default. Another window size (larger than
   the minimum) MAY be chosen by the receiver. (The receiver does
   not notify the sender of the window size.)

   The "right" edge of the window represents the highest,
   validated Sequence Number value received on this session.
   Records that contain Sequence Numbers lower than the "left"
   edge of the window are rejected. Packets falling within the
   window are checked against a list of received packets within
   the window. An efficient means for performing this check,
   based on the use of a bit mask, is described in Appendix C of
   [RFC 2401].




Rescorla, Modadugu                                              [Page 10]\f


   If the received record falls within the window and is new, or
   if the packet is to the right of the window, then the receiver
   proceeds to MAC verification. If the MAC validation fails, the
   receiver MUST discard the received record as invalid. The
   receive window is updated only if the MAC verification
   succeeds.

4.2. The DTLS Handshake Protocol

   DTLS uses all of the same handshake messages and flows as TLS,
   with three principal changes:

      1. A stateless cookie exchange has been added to prevent
      denial of service attacks.

      2. Modifications to the handshake header to handle message
      loss, reordering and fragmentation.

      3. Retransmission timers to handle message loss.

   With these exceptions, the DTLS message formats, flows, and
   logic are the same as those of TLS 1.1.

4.2.1. Denial of Service Countermeasures

   Datagram security protocols are extremely susceptible to a
   variety of denial of service (DoS) attacks. Two attacks are of
   particular concern:

      1. An attacker can consume excessive resources on the
      server by transmitting a series of handshake initiation
      requests, causing the server to allocate state and
      potentially perform expensive cryptographic operations.

      2. An attacker can use the server as an amplifier by
      sending connection initiation messages with a forged source
      of the victim. The server then sends its next message (in
      DTLS, a Certificate message, which can be quite large) to
      the victim machine, thus flooding it.

   In order to counter both of these attacks, DTLS borrows the
   stateless cookie technique used by Photuris [PHOTURIS] and IKE
   [IKE]. When the client sends its ClientHello message to the
   server, the server MAY respond with a HelloVerifyRequest
   message. This message contains a stateless cookie generated
   using the technique of [PHOTURIS]. The client MUST retransmit
   the ClientHello with the cookie added. The server then
   verifies the cookie and proceeds with the handshake only if it



Rescorla, Modadugu                                              [Page 11]\f


   is valid. This mechanism forces the attacker/client to be able
   to receive the cookie, which makes DoS attacks with spoofed IP
   addresses difficult. This mechanism does not provide any
   defense against DoS attacks mounted from valid IP addresses.

   The exchange is shown below:

         Client                                   Server
         ------                                   ------
         ClientHello           ------>

                               <----- HelloVerifyRequest
                                      (contains cookie)

         ClientHello           ------>
         (with cookie)

         [Rest of handshake]

   DTLS therefore modifies the ClientHello message to add the
   cookie value.

      struct {
        ProtocolVersion client_version;
        Random random;
        SessionID session_id;
        opaque cookie<0..32>;                 // New field
        CipherSuite cipher_suites<2..2^16-1>;
        CompressionMethod compression_methods<1..2^8-1>;
      } ClientHello;

   When sending the first ClientHello, the client does not have a
   cookie yet; in this case, the Cookie field is left empty (zero
   length).

   The definition of HelloVerifyRequest is as follows:

      struct {
        Cookie cookie<0..32>;
      } HelloVerifyRequest;

   The HelloVerifyRequest message type is
   hello_verify_request(3).

   When responding to a HelloVerifyRequest the client MUST use
   the same parameter values (version, random, session_id,
   cipher_suites, compression_method) as in the original
   ClientHello. The server SHOULD use those values to generate



Rescorla, Modadugu                                              [Page 12]\f


   its cookie and verify that they are correct upon cookie
   receipt. The DTLS server SHOULD generate cookies in such a way
   that they can be verified without retaining any per-client
   state on the server. One technique is to have a randomly
   generated secret and generate cookies as:
   Cookie = HMAC(Secret, Client-IP, Client-Parameters)

   When the second ClientHello is received, the server can verify
   that the Cookie is valid and that the client can receive
   packets at the given IP address.
     One potential attack on this scheme is for the attacker to
   collect a number of cookies from different addresses and then
   reuse them to attack the server. The server can defend against
   this attack by changing the Secret value frequently, thus
   invalidating those cookies. If the server wishes legitimate
   clients to be able to handshake through the transition (e.g.,
   they received a cookie with Secret 1 and then sent the second
   ClientHello after the server has changed to Secret 2), the
   server can have a limited window during which it accepts both
   secrets. [IKEv2] suggests adding a version number to cookies
   to detect this case. An alternative approach is simply to try
   verifying with both secrets.

   Although DTLS servers are not required to do a cookie
   exchange, they SHOULD do so whenever a new handshake is
   performed in order to avoid being used as amplifiers. If the
   server is being operated in an environment where amplification
   is not a problem, the server MAY choose not to perform a
   cookie exchange. In addition, the server MAY choose not do to
   a cookie exchange when a session is resumed. Clients MUST be
   prepared to do a cookie exchange with every handshake.

   If HelloVerifyRequest is used, the initial ClientHello and
   HelloVerifyRequest are not included in the calculation of the
   verify_data for the Finished message.

4.2.2. Handshake Message Format

   In order to support message loss, reordering, and
   fragmentation DTLS modifies the TLS 1.1 handshake header:

      struct {
        HandshakeType msg_type;
        uint24 length;
        uint16 message_seq;                              // New field
        uint24 fragment_offset;                          // New field
        uint24 fragment_length;                          // New field
        select (HandshakeType) {



Rescorla, Modadugu                                              [Page 13]\f


      case hello_request: HelloRequest;
      case client_hello:  ClientHello;
      case hello_verify_request: HelloVerifyRequest;     // New type
      case server_hello:  ServerHello;
      case certificate:Certificate;
      case server_key_exchange: ServerKeyExchange;
      case certificate_request: CertificateRequest;
      case server_hello_done:ServerHelloDone;
      case certificate_verify:  CertificateVerify;
      case client_key_exchange: ClientKeyExchange;
      case finished:Finished;
        } body;
      } Handshake;

   The first message each side transmits in each handshake always
   has message_seq = 0. Whenever each new message is generated,
   the message_seq value is incremented by one. When a message is
   retransmitted, the same message_seq value is used. For
   example.

      Client                             Server
      ------                             ------
      ClientHello (seq=0)  ------>

                              X<-- HelloVerifyRequest (seq=0)
                                              (lost)

      [Timer Expires]

      ClientHello (seq=0)  ------>
      (retransmit)

                           <------ HelloVerifyRequest (seq=0)

      ClientHello (seq=1)  ------>
      (with cookie)

                           <------        ServerHello (seq=1)
                           <------        Certificate (seq=2)
                           <------    ServerHelloDone (seq=3)

      [Rest of handshake]

   Note, however, that from the perspective of the DTLS record
   layer, the retransmission is a new record. This record will
   have a new DTLSPlaintext.sequence_number value.





Rescorla, Modadugu                                              [Page 14]\f


   DTLS implementations maintain (at least notionally) a
   next_receive_seq counter. This counter is initially set to
   zero. When a message is received, if its sequence number
   matches next_receive_seq, next_receive_seq is incremented and
   the message is processed. If the sequence number is less than
   next_receive_seq the message MUST be discarded. If the
   sequence number is greater than next_receive_seq, the
   implementation SHOULD queue the message but MAY discard it.
   (This is a simple space/bandwidth tradeoff).

4.2.3. Message Fragmentation and Reassembly

   As noted in Section 4.1.1., each DTLS message MUST fit within
   a single transport layer datagram. However, handshake messages
   are potentially bigger than the maximum record size. Therefore
   DTLS provides a mechanism for fragmenting a handshake message
   over a number of records.

   When transmitting the handshake message, the sender divides
   the message into a series of N contiguous data ranges. These
   range MUST NOT be larger than the maximum handshake fragment
   size and MUST jointly contain the entire handshake message.
   The ranges SHOULD NOT overlap. The sender then creates N
   handshake messages, all with the same message_seq value as the
   original handshake message. Each new message is labelled with
   the fragment_offset (the number of bytes contained in previous
   fragments) and the fragment_length (the length of this
   fragment). The length field in all messages is the same as the
   length field of the original message. An unfragmented message
   is a degenerate case with fragment_offset=0 and
   fragment_length=length.

   When a DTLS implementation receives a handshake message
   fragment, it MUST buffer it until it has the entire handshake
   message. DTLS implementations MUST be able to handle
   overlapping fragment ranges. This allows senders to retransmit
   handshake messages with smaller fragment sizes during path MTU
   discovery.

   Note that as with TLS, multiple handshake messages may be
   placed in the same DTLS record, provided that there is room
   and that they are part of the same flight. Thus, there are two
   acceptable ways to pack two DTLS messages into the same
   datagram: in the same record or in separate records.







Rescorla, Modadugu                                              [Page 15]\f


4.2.4. Timeout and Retransmission

   DTLS messages are grouped into a series of message flights,
   according the diagrams below. Although each flight of messages
   may consist of a number of messages, they should be viewed as
   monolithic for the purpose of timeout and retransmission.

      Client                                          Server
      ------                                          ------

      ClientHello             -------->                           Flight 1

                              <-------    HelloVerifyRequest      Flight 2

     ClientHello              -------->                           Flight 3

                                                 ServerHello    \
                                                Certificate*     \
                                          ServerKeyExchange*      Flight 4
                                         CertificateRequest*     /
                              <--------      ServerHelloDone    /

      Certificate*                                              \
      ClientKeyExchange                                          \
      CertificateVerify*                                          Flight 5
      [ChangeCipherSpec]                                         /
      Finished                -------->                         /

                                          [ChangeCipherSpec]    \ Flight 6
                              <--------             Finished    /
            Figure 1: Message flights for full handshake


      Client                                           Server
      ------                                           ------

      ClientHello             -------->                          Flight 1

                                                 ServerHello    \
                                          [ChangeCipherSpec]     Flight 2
                               <--------             Finished    /

      [ChangeCipherSpec]                                         \Flight 3
      Finished                 -------->                         /
   Figure 2: Message flights for session resuming handshake (no
                          cookie exchange)





Rescorla, Modadugu                                              [Page 16]\f


   DTLS uses a simple timeout and retransmission scheme with the
   following state machine. Because DTLS clients send the first
   message (ClientHello) they start in the PREPARING state. DTLS
   servers start in the WAITING state, but with empty buffers and
   no retransmit timer.














































Rescorla, Modadugu                                              [Page 17]\f


                   +-----------+
                   | PREPARING |
             +---> |           |
             |     |           |
             |     +-----------+
             |           |
             |           |
             |           | Buffer next flight
             |           |
             |          \|/
             |     +-----------+
             |     |           |
             |     |  SENDING  |<------------------+
             |     |           |                   |
             |     +-----------+                   |
     Receive |           |                         |
        next |           | Send flight             |
      flight |  +--------+                         |
             |  |        | Set retransmit timer    |
             |  |       \|/                        |
             |  |  +-----------+                   |
             |  |  |           |                   |
             +--)--|  WAITING  |-------------------+
             |  |  |           |   Timer expires   |
             |  |  +-----------+                   |
             |  |         |                        |
             |  |         |                        |
             |  |         +------------------------+
             |  |                Read retransmit
     Receive |  |
        last |  |
      flight |  |
             |  |
            \|/\|/

         +-----------+
         |           |
         | FINISHED  |
         |           |
         +-----------+

      Figure 3: DTLS timeout and retransmission state machine


   The state machine has three basic states.

   In the PREPARING state the implementation does whatever
   computations are necessary to prepare the next flight of



Rescorla, Modadugu                                              [Page 18]\f


   messages. It then buffers them up for transmission (emptying
   the buffer first) and enters the SENDING state.

   In the SENDING state, the implementation transmits the
   buffered flight of messages. Once the messages have been sent,
   the implementation then enters the FINISHED state if this is
   the last flight in the handshake, or, if the implementation
   expects to receive more messages, sets a retransmit timer and
   then enters the WAITING state.

   There are three ways to exit the WAITING state:

      1. The retransmit timer expires: the implementation
      transitions to the SENDING state, where it retransmits the
      flight, resets the retransmit timer, and returns to the
      WAITING state.

      2. The implementation reads a retransmitted flight from the
      peer: the implementation transitions to the SENDING state,
      where it retransmits the flight, resets the retransmit
      timer, and returns to the WAITING state. The rationale here
      is that the receipt of a duplicate message is the likely
      result of timer expiry on the peer and therefore suggests
      that part of one's previous flight was lost.

      3. The implementation receives the next flight of messages:
      if this is the final flight of messages the implementation
      transitions to FINISHED. If the implementation needs to
      send a new flight, it transitions to the PREPARING state.
      Partial reads (whether partial messages or only some of the
      messages in the flight) do not cause state transitions or
      timer resets.

   Because DTLS clients send the first message (ClientHello) they
   start in the PREPARING state. DTLS servers start in the
   WAITING state, but with empty buffers and no retransmit timer.

4.2.4.1. Timer Values

   Timer value choices are a local matter. Implementations SHOULD
   use an initial timer value of 500 ms and double the value at
   each retransmission, up to twice the TCP maximum segment
   lifetime [TCP] (if the recommendations in [TCP] are followed,
   this will be 240 seconds). Implementations SHOULD start the
   timer value at the initial value with each new flight of
   messages.





Rescorla, Modadugu                                              [Page 19]\f


4.2.5. ChangeCipherSpec

   As with TLS, the ChangeCipherSpec message is not technically a
   handshake message but MUST be treated as part of the same
   flight as the associated Finished message for the purposes of
   timeout and retransmission.

4.2.6. Finished messages

   Finished messages have the same format as in TLS. However, in
   order to remove sensitivity to fragmentation, the Finished MAC
   MUST be computed as if each handshake message had been sent as
   a single fragment. Note that in cases where the cookie
   exchange is used, the initial ClientHello and
   HelloVerifyRequest MUST BE included in the Finished MAC.

4.2.7. Alert Messages

   Note that Alert messages are not retransmitted at all, even
   when they occur in the context of a handshake. However, a DTLS
   implementation SHOULD generate a new alert message if the
   offending record is received again (e.g., as a retransmitted
   handshake message).



A.1\bSummary of new syntax

   This section includes specifications for the data structures
   that have changed between TLS 1.1 and DTLS.

4.2. Record Layer
   struct {
     ContentType type;
     ProtocolVersion version;
     uint16 epoch;                                   // New field
     uint48 sequence_number;                         // New field
     uint16 length;
     opaque fragment[DTLSPlaintext.length];
   } DTLSPlaintext;

   struct {
     ContentType type;
     ProtocolVersion version;
     uint16 epoch;                                   // New field
     uint48 sequence_number;                         // New field
     uint16 length;
     opaque fragment[DTLSCompressed.length];



Rescorla, Modadugu                                              [Page 20]\f


   } DTLSCompressed;

   struct {
     ContentType type;
     ProtocolVersion version;
     uint16 epoch;                                   // New field
     uint48 sequence_number;                         // New field
     uint16 length;
     select (CipherSpec.cipher_type) {
   case block:  GenericBlockCipher;
     } fragment;
   } DTLSCiphertext;

4.3. Handshake Protocol

   enum {
     hello_request(0), client_hello(1), server_hello(2),
     hello_verify_request(3),                        // New field
     certificate(11), server_key_exchange (12),
     certificate_request(13), server_hello_done(14),
     certificate_verify(15), client_key_exchange(16),
     finished(20), (255)
   } HandshakeType;

   struct {
     HandshakeType msg_type;
     uint24 length;
     uint16 message_seq;                             // New field
     uint24 fragment_offset;                         // New field
     uint24 fragment_length;                         // New field
     select (HandshakeType) {
   case hello_request: HelloRequest;
   case client_hello:  ClientHello;
   case server_hello:  ServerHello;
   case hello_verify_request: HelloVerifyRequest;    // New field
   case certificate:Certificate;
   case server_key_exchange: ServerKeyExchange;
   case certificate_request: CertificateRequest;
   case server_hello_done:ServerHelloDone;
   case certificate_verify:  CertificateVerify;
   case client_key_exchange: ClientKeyExchange;
   case finished:Finished;
     } body;
   } Handshake;

   struct {
     ProtocolVersion client_version;
     Random random;



Rescorla, Modadugu                                              [Page 21]\f


     SessionID session_id;
     opaque cookie<0..32>;                 // New field
     CipherSuite cipher_suites<2..2^16-1>;
     CompressionMethod compression_methods<1..2^8-1>;
   } ClientHello;

   struct {
     Cookie cookie<0..32>;
   } HelloVerifyRequest;

5. Security Considerations

   This document describes a variant of TLS 1.1 and therefore
   most of the security considerations are the same as those of
   TLS 1.1 [TLS11], described in Appendices D, E, and F.

   The primary additional security consideration raised by DTLS
   is that of denial of service. DTLS includes a cookie exchange
   designed to protect against denial of service. However,
   implementations which do not use this cookie exchange are
   still vulnerable to DoS. In particular, DTLS servers which do
   not use the cookie exchange may be used as attack amplifiers
   even if they themselves are not experiencing DoS. Therefore
   DTLS servers SHOULD use the cookie exchange unless there is
   good reason to believe that amplification is not a threat in
   their environment.

6. IANA Considerations

   This document uses the same identifier space as TLS [TLS11],
   so no new IANA registries are required. When new identifiers
   are assigned for TLS, authors MUST specify whether they are
   suitable for DTLS.

   This document defines a new handshake message,
   hello_verify_request, whose value is to be allocated from the
   TLS HandshakeType registry defined in [TLS11]. The value "3"
   is suggested.

References

Normative References

   [RFC1191]  Mogul, J. C., Deering, S.E., "Path MTU Discovery",
              RFC 1191, November 1990.

   [RFC2401]  Kent, S., Atkinson, R., "Security Architecture for the
              Internet Protocol", RFC2401, November 1998.



Rescorla, Modadugu                                              [Page 22]\f


   [TCP]      Postel, J., "Transmission Control Protocol",
              RFC 793, September 1981.

   [TLS11]    Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
              draft-ietf-tls-rfc2246-bis-05.txt, July 2003.


Informative References

   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
              RFC 2402, November 1998.

   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
              Congestion Control Protocol", draft-ietf-dccp-spec-11.txt,
              10 March 2005

   [DNS]      Mockapetris, P.V., "Domain names - implementation and
              specification", RFC 1035, November 1987.

   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
              of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.

   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.


   [IKE]      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
              RFC 2409, November 1998.

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              draft-ietf-ipsec-ikev2-17.txt, September 2004.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

   [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
              Protocol", RFC 2521, March 1999.


   [POP]      Myers, J., and Rose, M., "Post Office Protocol -
              Version 3", RFC 1939, May 1996.


   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


   [SIP]      Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,



Rescorla, Modadugu                                              [Page 23]\f


              Peterson, J., Sparks, R., Handley, M., Schooler, E.,
              "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
              draft-bellovin-useipsec-02.txt, October 2003

Authors' Address

   Eric Rescorla <ekr@rtfm.com>
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA 94303

   Nagendra Modadugu <nagendra@cs.stanford.edu>
   Computer Science Department
   353 Serra Mall
   Stanford University
   Stanford, CA 94305



Acknowledgements

   The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ
   Housley, Constantine Sapuntzakis, and Hovav Shacham for
   discussions and comments on the design of DTLS. Thanks to the
   anonymous NDSS reviewers of our original NDSS paper on DTLS
   [DTLS] for their comments. Also, thanks to Steve Kent for
   feedback that helped clarify many points. The section on PMTU
   was cribbed from the DCCP specification [DCCP]. Pasi Eronen
   provided a detailed review of this specification.
















Rescorla, Modadugu                                              [Page 24]\f


Full Copyright Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Copyright Notice
   Copyright (C) The Internet Society (2003). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.















Rescorla, Modadugu                                              [Page 25]\f