< draft-rescorla-dtls-02.txt   draft-rescorla-dtls-03.txt >
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
N. Modadugu N. Modadugu
INTERNET-DRAFT Stanford University INTERNET-DRAFT Stanford University
<draft-rescorla-dtls-02.txt> December 2003 (Expires June 2004) <draft-rescorla-dtls-03.txt> February 2004 (Expires August 2005)
Datagram Transport Layer Security Datagram Transport Layer Security
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999-2004). All Rights Reserved. Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
Contents
Abstract Abstract
This document specifies Version 1.0 of the Datagram Transport Layer This document specifies Version 1.0 of the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides communications Security (DTLS) protocol. The DTLS protocol provides communications
privacy for datagram protocols. The protocol allows client/server privacy for datagram protocols. The protocol allows client/server
applications to communicate in a way that is designed to prevent applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. The DTLS protocol is eavesdropping, tampering, or message forgery. The DTLS protocol is
based on the TLS protocol and provides equivalent security based on the TLS protocol and provides equivalent security
guarantees. Datagram semantics of the underlying transport are guarantees. Datagram semantics of the underlying transport are
preserved by the DTLS protocol. preserved by the DTLS protocol.
Contents
1. Introduction 1. Introduction
TLS [TLS] is the most widely deployed protocol for securing network TLS [TLS] is the most widely deployed protocol for securing network
traffic. It is widely used for protecting Web traffic and for e-mail 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 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of
TLS is that it provides a transparent channel. Thus, it is easy to TLS is that it provides a transparent connection-oriented channel.
secure an application protocol by inserting TLS between the Thus, it is easy to secure an application protocol by inserting TLS
application layer and the network layer. However, TLS must run over a between the application layer and the transport layer. However, TLS
reliable transport channel--typically TCP [TCP]. It therefore cannot must run over a reliable transport channel--typically TCP [TCP]. It
be used to secure unreliable datagram traffic. therefore cannot be used to secure unreliable datagram traffic.
However, over the past few years an increasing number of application However, over the past few years an increasing number of application
layer protocols have been designed which UDP transport. In particular layer protocols have been designed which UDP transport. In particular
such protocols as the Session Initiation Protocol (SIP) [SIP], and such protocols as the Session Initiation Protocol (SIP) [SIP], and
electronic gaming protocols are increasingly popular. (Note that SIP electronic gaming protocols are increasingly popular. (Note that SIP
can run over both TCP and UDP, but that there are situations in which can run over both TCP and UDP, but that there are situations in which
UDP is preferable). Currently, designers these applications are faced UDP is preferable). Currently, designers of these applications are
with a number of unsatisfactory choices. First, they can use IPsec faced with a number of unsatisfactory choices. First, they can use
[RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], IPsec [RFC2401]. However, for a number of reasons detailed in
this is only suitable for some applications. Second, they can design [WHYIPSEC], this is only suitable for some applications. Second, they
a custom application layer security protocol. SIP, for instance, uses can design a custom application layer security protocol. SIP, for
a variant of S/MIME to secure its traffic. Unfortunately, application instance, uses a subsert of S/MIME to secure its traffic.
layer security protocols typically require a large amount of effort Unfortunately, while application layer security protocols generally
to design--by contrast to the relatively small amount of effort provide superior security properties (e.g., end-to-end security in
required to run the protocol over TLS. 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 In many cases, the most desirable way to secure client/server
applications would be to use TLS, however the requirement for applications would be to use TLS; however the requirement for
datagram semantics automatically prohibits use of TLS. Thus, a datagram semantics automatically prohibits use of TLS. Thus, a
datagram-compatible variant of TLS would be very desirable. This memo datagram-compatible variant of TLS would be very desirable. This memo
describes such a protocol: Datagram Transport Layer Security (DTLS). describes such a protocol: Datagram Transport Layer Security (DTLS).
DTLS is deliberately designed to be as similar to to TLS as possible, 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 both to minimize new security invention and to maximize the amount of
code and infrastructure reuse. 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].
2. Usage Model 2. Usage Model
The DTLS protocol is designed to secure data between communicating The DTLS protocol is designed to secure data between communicating
applications. It is designed to run in application space, without applications. It is designed to run in application space, without
requiring any kernel modifications. While the design of the DTLS requiring any kernel modifications. While the design of the DTLS
protocol does not preclude its use in securing arbitrary datagram protocol does not preclude its use in securing arbitrary datagram
traffic, it is primarily expected to secure communication based on traffic, it is primarily expected to secure communication based on
datagram sockets. datagram sockets.
Datagram transport does not guarantee reliable or in-order delivery Datagram transport does not require or provide reliable or in-order
of data. The DTLS protocol preserves this property for payload data. delivery of data. The DTLS protocol preserves this property for
Applications such as media streaming, Internet telephony and online payload data. Applications such as media streaming, Internet
gaming use datagram transport for communication due to the delay- telephony and online gaming use datagram transport for communication
sensitive nature of transported data. The behavior of such due to the delay-sensitive nature of transported data. The behavior
applications is unchanged when the DTLS protocol is used to secure of such applications is unchanged when the DTLS protocol is used to
communication, since the DTLS protocol does not compensate for lost secure communication, since the DTLS protocol does not compensate for
or re-ordered data traffic. lost or re-ordered data traffic.
3. Overview of DTLS 3. Overview of DTLS
The basic design philosophy of DTLS is to construct "TLS over The basic design philosophy of DTLS is to construct "TLS over
datagram". The reason that TLS cannot be used directly in datagram datagram". The reason that TLS cannot be used directly in datagram
environments is simply that packets may be lost or reordered. TLS has environments is simply that packets may be lost or reordered. TLS has
no internal facilities to handle this kind of unreliability and no internal facilities to handle this kind of unreliability and
therefore TLS implementations break when rehosted on datagram therefore TLS implementations break when rehosted on datagram
transport. The purpose of DTLS is to make only the minimal changes to transport. The purpose of DTLS is to make only the minimal changes to
TLS required to fix this problem. To the greatest extent possible, TLS required to fix this problem. To the greatest extent possible,
skipping to change at page 4, line 46 skipping to change at page 5, line 4
of the DTLS handshake: of the DTLS handshake:
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
X<-- HelloVerifyRequest X<-- HelloVerifyRequest
(lost) (lost)
[Timer Expires] [Timer Expires]
ClientHello ------> ClientHello ------>
(retransmit) (retransmit)
Once the client has transmitted the ClientHello message, it expects Once the client has transmitted the ClientHello message, it expects
to see a HelloVerifyRequest from the server. However, if the server's to see a HelloVerifyRequest from the server. However, if the server's
message is lost the client knows that either the ClientHello or the message is lost the client knows that either the ClientHello or the
HelloVerifyRequest has been lost and retransmits. When the server HelloVerifyRequest has been lost and retransmits. When the server
receives the retransmission, it knows to retransmit. The server also receives the retransmission, it knows to retransmit. The server also
maintains a retransmission timer and retransmits when that timer maintains a retransmission timer and retransmits when that timer
expires. expires.
3.2.2. Reordering 3.2.2. Reordering
In DTLS, each handshake message is assigned a specific sequence In DTLS, each handshake message is assigned a specific sequence
number within that handshake. When a peer receives a handshake number within that handshake. When a peer receives a handshake
message, it can quickly determine whether that message is the next 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 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 it up for future handling once all previous messages have been
received. received.
3.3. Message Size 3.2.3. Message Size
TLS and DTLS handshake messages can be quite large (in theory up to 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 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams
are often limited to <1500 bytes. In order to compensate for this are often limited to <1500 bytes. In order to compensate for this
limitation, each DTLS handshake message may be fragmented over limitation, each DTLS handshake message may be fragmented over
several DTLS records. Each DTLS handshake message contains both a several DTLS records. Each DTLS handshake message contains both a
fragment offset and a fragment length. Thus, a recipient in fragment offset and a fragment length. Thus, a recipient in
possession of all bytes of a handshake message can reassemble the possession of all bytes of a handshake message can reassemble the
original unfragmented message. original unfragmented message.
3.3. Replay Detection
DTLS optionally supports record replay detection. The technique used DTLS optionally supports record replay detection. The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of 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 received records. Records that are too old to fit in the window and
records that have been previously received are silently discarded. records that have been previously received are silently discarded.
The replay detection feature is optional, since packet duplication is The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors. not always malicious, but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy. modify their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section , DTLS is intentionally very similar to TLS. As mentioned in Section 3., DTLS is intentionally very similar to
Therefore, instead of presenting DTLS as a new protocol, we instead TLS. Therefore, instead of presenting DTLS as a new protocol, we
present it as a series of deltas from TLS 1.1 [TLS11]. Where we do instead present it as a series of deltas from TLS 1.1 [TLS11]. Where
not explicitly call out differences, DTLS is the same as TLS. we do not explicitly call out differences, DTLS is the same as TLS.
4.1. Record Layer 4.1. Record Layer
The DTLS record layer is extremely similar to that of TLS 1.1. The 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 only change is the inclusion of an explicit sequence number in the
record. This sequence number allows the recipient to correctly verify record. This sequence number allows the recipient to correctly verify
the TLS MAC. The DTLS record format is shown below: the TLS MAC. The DTLS record format is shown below:
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; uint16 epoch; // New field
uint48 sequence_number; uint48 sequence_number; // New field
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
type type
Equivalent to the type field in a TLS 1.1 record. Equivalent to the type field in a TLS 1.1 record.
version version
The version of the protocol being employed. This document The version of the protocol being employed. This document
describes DTLS Version 1.0, which uses the version { 254, 255 describes DTLS Version 1.0, which uses the version { 254, 255
skipping to change at page 7, line 16 skipping to change at page 7, line 23
Each DTLS record MUST fit within a single datagram. In order to avoid Each DTLS record MUST fit within a single datagram. In order to avoid
IP fragmentation [MOGUL], DTLS implementations SHOULD determine the IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
MTU and send records smaller than the MTU. DTLS implementations MTU and send records smaller than the MTU. DTLS implementations
SHOULD provide a way for applications to determine the value of the SHOULD provide a way for applications to determine the value of the
MTU (optimally the maximum application datagram size, which is the MTU (optimally the maximum application datagram size, which is the
PMTU minus the DTLS per-record overhead). If the application attempts PMTU minus the DTLS per-record overhead). If the application attempts
to send a record larger than the MTU, the DTLS implementation MUST to send a record larger than the MTU, the DTLS implementation MUST
either generate an error or fragment the packet. either generate an error or fragment the packet.
Multiple DTLS records may be placed in a single datagram. They 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 4.1.1.1. PMTU Discovery
The PMTU SHOULD be initialized from the interface MTU that will be The PMTU SHOULD be initialized from the interface MTU that will be
used to send packets. used to send packets.
To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment
(DF) bit. As specified in [RFC 1191], when a router receives a packet (DF) bit. As specified in [RFC 1191], when a router receives a packet
with DF set that is larger than the next link's MTU, it sends an ICMP with DF set that is larger than the next link's MTU, it sends an ICMP
Destination Unreachable message to the source of the datagram with Destination Unreachable message to the source of the datagram with
the Code indicating "fragmentation needed and DF set" (also known as the Code indicating "fragmentation needed and DF set" (also known as
skipping to change at page 7, line 43 skipping to change at page 8, line 9
A DTLS implementation may allow the application to occasionally A DTLS implementation may allow the application to occasionally
request that PMTU discovery be performed again. This will reset the request that PMTU discovery be performed again. This will reset the
PMTU to the outgoing interface's MTU. Such requests SHOULD be rate PMTU to the outgoing interface's MTU. Such requests SHOULD be rate
limited, to one per two seconds, for example. limited, to one per two seconds, for example.
Because some firewalls and routers screen out ICMP messages, it is Because some firewalls and routers screen out ICMP messages, it is
difficult to distinguish packet loss from a large PMTU estimate. In difficult to distinguish packet loss from a large PMTU estimate. In
order to allow connections under these circumstances, DTLS order to allow connections under these circumstances, DTLS
implementations MAY choose to back off their PMTU estimate during the implementations MAY choose to back off their PMTU estimate during the
retransmit backoff described in Section . For instance, if a large retransmit backoff described in Section 4.2.4.. For instance, if a
packet is being sent, after 3 retransmits a sender might choose to large packet is being sent, after 3 retransmits a sender might choose
fragment the packet. to fragment the packet.
4.1.2. Record payload protection 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 4.1.2.1. MAC
The DTLS MAC is the same as that of TLS 1.1. However, rather than 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 using TLS's implicit sequence number, the sequence number used to
compute the MAC is the 64-bit value formed by concatenating the epoch 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 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 that the DTLS epoch + sequence number is the same length as the TLS
sequence number. sequence number.
4.1.2.2. Null or standard stream cipher 4.1.2.2. Null or standard stream cipher
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
The only stream cipher described in TLS 1.1 is RC4, which cannot be The only stream cipher described in TLS 1.1 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS. randomly accessed. RC4 MUST NOT be used with DTLS.
4.1.2.3. Block Cipher 4.1.2.3. Block Cipher
DTLS block cipher encryption and decryption are performed exactly as DTLS block cipher encryption and decryption are performed exactly as
with TLS 1.1. with TLS 1.1.
4.1.2.4. Anti-Replay 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. DTLS records contain a sequence number to provide replay protection.
Sequence number verification SHOULD be performed using the following Sequence number verification SHOULD be performed using the following
sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402]
The receiver packet counter for this session MUST be initialized to The receiver packet counter for this session MUST be initialized to
zero when the session is established. For each received record, the zero when the session is established. For each received record, the
receiver MUST verify that the record contains a Sequence Number that receiver MUST verify that the record contains a Sequence Number that
does not duplicate the Sequence Number of any other record received does not duplicate the Sequence Number of any other record received
during the life of this session. This SHOULD be the first check 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 applied to a packet after it has been matched to a session, to speed
rejection of duplicate records. rejection of duplicate records.
Duplicates are rejected through the use of a sliding receive window. Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following (How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must text describes the functionality that the implementation must
exhibit.) A MINIMUM window size of 32 MUST be supported; but a window 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. size of 64 is preferred and SHOULD be employed as the default.
Another window size (larger than the MINIMUM) MAY be chosen by the Another window size (larger than the minimum) MAY be chosen by the
receiver. (The receiver does NOT notify the sender of the window receiver. (The receiver does not notify the sender of the window
size.) size.)
The "right" edge of the window represents the highest, validated The "right" edge of the window represents the highest, validated
Sequence Number value received on this session. Records that contain Sequence Number value received on this session. Records that contain
Sequence Numbers lower than the "left" edge of the window are Sequence Numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described performing this check, based on the use of a bit mask, is described
in [RFC 2401]. in Appendix C of [RFC 2401].
If the received record falls within the window and is new, or if the 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 packet is to the right of the window, then the receiver proceeds to
MAC verification. If the MAC validation fails, the receiver MUST MAC verification. If the MAC validation fails, the receiver MUST
discard the received record as invalid. The receive window is updated discard the received record as invalid. The receive window is updated
only if the MAC verification succeeds. only if the MAC verification succeeds.
4.2. The DTLS Handshake Protocol 4.2. The DTLS Handshake Protocol
DTLS uses all of the same handshake messages and flows as TLS, with DTLS uses all of the same handshake messages and flows as TLS, with
three principal changes: three principal changes:
1. A stateless cookie exchange to prevent denial of service 1. A stateless cookie exchange has been added to prevent denial of
attacks. service attacks.
2. Modifications to the handshake header to handle message loss, 2. Modifications to the handshake header to handle message loss,
reordering and fragmentation. reordering and fragmentation.
3. Retransmission timers to handle message loss. 3. Retransmission timers to handle message loss.
With these exceptions, the DTLS message formats, flows, and logic are With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.1. the same as those of TLS 1.1.
4.2.1. Denial of Service Countermeasures 4.2.1. Denial of Service Countermeasures
skipping to change at page 11, line 4 skipping to change at page 11, line 30
parameter values (version, random, session_id, cipher_suites, parameter values (version, random, session_id, cipher_suites,
compression_method) as in the original ClientHello. The server SHOULD compression_method) as in the original ClientHello. The server SHOULD
use those values to generate its cookie and verify that they are use those values to generate its cookie and verify that they are
correct upon cookie receipt. correct upon cookie receipt.
Although DTLS servers are not required to do a cookie exchange, they 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 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 being used as amplifiers. If the server is being operated in an
environment where amplification is not a problem, the server MAY environment where amplification is not a problem, the server MAY
choose not to perform a cookie exchange. In addition, 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 choose not do to a cookie exchange when a session is resumed. Clients
MUST be prepared to do a cookie exchange with every handshake. MUST be prepared to do a cookie exchange with every handshake.
4.2.2. Handshake Message Format 4.2.2. Handshake Message Format
In order to support message loss, reordering, and fragmentation DTLS In order to support message loss, reordering, and fragmentation DTLS
modifies the TLS 1.1 handshake header: modifies the TLS 1.1 handshake header:
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
uint16 message_seq; // New field uint16 message_seq; // New field
uint24 fragment_offset; // New field uint24 fragment_offset; // New field
uint24 fragment_length; // New field uint24 fragment_length; // New field
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New message type case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello; case server_hello: ServerHello;
case certificate:Certificate; case certificate:Certificate;
case server_key_exchange: ServerKeyExchange; case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone; case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished:Finished; case finished:Finished;
} body; } body;
} Handshake; } Handshake;
skipping to change at page 12, line 25 skipping to change at page 12, line 50
next_receive_seq counter. This counter is initially set to zero. When next_receive_seq counter. This counter is initially set to zero. When
a message is received, if its sequence number matches a message is received, if its sequence number matches
next_receive_seq, next_receive_seq is incremented and the message is next_receive_seq, next_receive_seq is incremented and the message is
processed. If the sequence number is less than next_receive_seq the processed. If the sequence number is less than next_receive_seq the
message MUST be discarded. If the sequence number is greater than message MUST be discarded. If the sequence number is greater than
next_receive_seq, the implementation SHOULD queue the message but MAY next_receive_seq, the implementation SHOULD queue the message but MAY
discard it. (This is a simple space/bandwidth tradeoff). discard it. (This is a simple space/bandwidth tradeoff).
4.2.3. Message Fragmentation and Reassembly 4.2.3. Message Fragmentation and Reassembly
As noted in Section , each DTLS message MUST fit within a single As noted in Section 4.1.1., each DTLS message MUST fit within a
transport layer datagram. However, handshake messages are potentially single transport layer datagram. However, handshake messages are
bigger than the maximum record size. Therefore DTLS provides a potentially bigger than the maximum record size. Therefore DTLS
mechanism for fragmenting a handshake message over a number of provides a mechanism for fragmenting a handshake message over a
records. number of records.
When transmitting the handshake message, the sender divides the When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges. These range must message into a series of N contiguous data ranges. These range MUST
be no larger than the maximum handshake fragment size and MUST NOT be larger than the maximum handshake fragment size and MUST
jointly contain the entire handshake message. The ranges SHOULD NOT jointly contain the entire handshake message. The ranges SHOULD NOT
overlap. The sender then creates N handshake messages, all with the overlap. The sender then creates N handshake messages, all with the
same message_seq value as the original handshake message. Each new same message_seq value as the original handshake message. Each new
message is labelled with the fragment_offset (the number of bytes message is labelled with the fragment_offset (the number of bytes
contained in previous fragments) and the fragment_length (the length contained in previous fragments) and the fragment_length (the length
of this fragment). The length field in all messages is the same as of this fragment). The length field in all messages is the same as
the length field of the original message. An unfragmented message is the length field of the original message. An unfragmented message is
a degenerate case with fragment_offset=0 and fragment_length=length. a degenerate case with fragment_offset=0 and fragment_length=length.
When a DTLS implementation receives a handshake message fragment, it When a DTLS implementation receives a handshake message fragment, it
MUST buffer it until it has the entire handshake message. DTLS MUST buffer it until it has the entire handshake message. DTLS
implementations MUST be able to handle overlapping fragment ranges. implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller This allows senders to retransmit handshake messages with smaller
fragment sizes during path MTU discovery. 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.
4.2.4. Timeout and Retransmission 4.2.4. Timeout and Retransmission
DTLS messages are grouped into a series of message flights, according DTLS messages are grouped into a series of message flights, according
the diagrams below. Although each flight of messages may consist of a the diagrams below. Although each flight of messages may consist of a
number of messages, they should be viewed as monolithic for the number of messages, they should be viewed as monolithic for the
purpose of timeout and retransmission. purpose of timeout and retransmission.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> Flight 1 ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2 <------- HelloVerifyRequest Flight 2
skipping to change at page 13, line 47 skipping to change at page 14, line 44
ServerHello \ ServerHello \
[ChangeCipherSpec] Flight 2 [ChangeCipherSpec] Flight 2
<-------- Finished / <-------- Finished /
[ChangeCipherSpec] \Flight 3 [ChangeCipherSpec] \Flight 3
Finished --------> / Finished --------> /
Figure 2: Message flights for session resuming handshake (no cookie exchange) Figure 2: Message flights for session resuming handshake (no cookie exchange)
DTLS uses a simple timeout and retransmission scheme with the DTLS uses a simple timeout and retransmission scheme with the
following state machine. 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.
+--------+ +-----------+
| PREPAR | | PREPARING |
+---> | -ING | +---> | |
| | | | | |
| +--------+ | +-----------+
| | | |
| | | |
| | Buffer next flight | | Buffer next flight
| | | |
| \|/ | \|/
| +---------+ | +-----------+
| | | | | |
| | SENDING |<--------------------+ | | SENDING |<------------------+
| | | | | | | |
| +---------+ | | +-----------+ |
Receive | | | Receive | | |
next | | Send flight | next | | Send flight |
flight | +-------+ | flight | +--------+ |
| | | Set retransmit timer | | | | Set retransmit timer |
| | \|/ | | | \|/ |
| | +---------+ | | | +-----------+ |
| | | | | | | | | |
+--)--| WAITING |---------------------+ +--)--| WAITING |-------------------+
| | | | Timer expires | | | | | Timer expires |
| | +---------+ | | | +-----------+ |
| | | | | | | |
| | | | | | | |
| | +------------------------+ | | +------------------------+
| | Read retransmit | | Read retransmit
Receive | | Receive | |
last | | last | |
flight | | flight | |
| | | |
\|/\|/ \|/\|/
FINISH +-----------+
| |
| FINISHED |
| |
+-----------+
Figure 3: DTLS timeout and retransmission state machine Figure 3: DTLS timeout and retransmission state machine
The state machine has three basic states. The state machine has three basic states.
In the PREPARING state the implementation does whatever computations In the PREPARING state the implementation does whatever computations
are necessary to prepare the next flight of messages. It then buffers are necessary to prepare the next flight of messages. It then buffers
them up for transmission (emptying the buffer first) and enters the them up for transmission (emptying the buffer first) and enters the
SENDING state. SENDING state.
In the SENDING state, the implementation transmits the buffered In the SENDING state, the implementation transmits the buffered
flight of messages. Once the messages have been sent, the flight of messages. Once the messages have been sent, the
implementation then enters the FINISH state if this is the last implementation then enters the FINISHED state if this is the last
flight in the handshake, or, if the implementation expects to receive flight in the handshake, or, if the implementation expects to receive
more messages, sets a retransmit timer and then enters the WAITING more messages, sets a retransmit timer and then enters the WAITING
state. state.
There are three ways to exit the WAITING state: There are three ways to exit the WAITING state:
1. The retransmit timer expires: the implementation transitions to 1. The retransmit timer expires: the implementation transitions to
the SENDING state, where it retransmits the flight, resets the the SENDING state, where it retransmits the flight, resets the
retransmit timer, and returns to the WAITING state. retransmit timer, and returns to the WAITING state.
skipping to change at page 15, line 33 skipping to change at page 16, line 35
and therefore suggests that part of one's previous flight was and therefore suggests that part of one's previous flight was
lost. lost.
3. The implementation receives the next flight of messages: if 3. The implementation receives the next flight of messages: if
this is the final flight of messages the implementation this is the final flight of messages the implementation
transitions to FINISHED. If the implementation needs to send a new transitions to FINISHED. If the implementation needs to send a new
flight, it transitions to the PREPARING state. Partial reads flight, it transitions to the PREPARING state. Partial reads
(whether partial messages or only some of the messages in the (whether partial messages or only some of the messages in the
flight) do not cause state transitions or timer resets. 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 4.2.4.1. Timer Values
Timer value choices are a local matter. We recommend that Timer value choices are a local matter. We RECOMMEND that
implementations use an initial timer value of 500 ms and double the implementations use an initial timer value of 500 ms and double the
value at each retransmission, up to 2MSL. Implementations SHOULD value at each retransmission, up to twice the TCP Maximum Segment
start the timer value at the initial value with each new flight of Lifetime. [TCP] Implementations SHOULD start the timer value at the
messages. initial value with each new flight of messages.
4.2.5. ChangeCipherSpec 4.2.5. ChangeCipherSpec
As with TLS, the ChangeCipherSpec message is not technically a As with TLS, the ChangeCipherSpec message is not technically a
handshake message but MUST be treated as part of the same flight as handshake message but MUST be treated as part of the same flight as
the associated Finished message for the purposes of timeout and the associated Finished message for the purposes of timeout and
retransmission. retransmission.
4.2.6. Finished messages 4.2.6. Finished messages
Finished messages have the same format as in TLS. However, in order Finished messages have the same format as in TLS. However, in order
to remove sensitivity to fragmentation, the Finished MAC MUST be to remove sensitivity to fragmentation, the Finished MAC MUST be
computed as if each handshake message had been sent as a single computed as if each handshake message had been sent as a single
fragment. Note that in cases where the cookie exchange is used, the fragment. Note that in cases where the cookie exchange is used, the
initial ClientHello and HelloVerifyRequest ARE included in the initial ClientHello and HelloVerifyRequest MUST BE included in the
Finished MAC. Finished MAC.
A.1 Summary of new syntax A.1Summary of new syntax
This section includes specifications for the data structures that This section includes specifications for the data structures that
have changed between TLS 1.1 and DTLS. have changed between TLS 1.1 and DTLS.
4.2. Record Layer 4.2. Record Layer
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; // NEW uint16 epoch; // New field
uint48 sequence_number; // NEW uint48 sequence_number; // New field
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; // NEW uint16 epoch; // New field
uint48 sequence_number; // NEW uint48 sequence_number; // New field
uint16 length; uint16 length;
opaque fragment[DTLSCompressed.length]; opaque fragment[DTLSCompressed.length];
} DTLSCompressed; } DTLSCompressed;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 epoch; // NEW uint16 epoch; // New field
uint48 sequence_number; // NEW uint48 sequence_number; // New field
uint16 length; uint16 length;
select (CipherSpec.cipher_type) { select (CipherSpec.cipher_type) {
case block: GenericBlockCipher; case block: GenericBlockCipher;
} fragment; } fragment;
} DTLSCiphertext; } DTLSCiphertext;
4.3. Handshake Protocol 4.3. Handshake Protocol
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // NEW hello_verify_request(3), // New field
certificate(11), server_key_exchange (12), certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14), certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16), certificate_verify(15), client_key_exchange(16),
finished(20), (255) finished(20), (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
uint16 message_seq; // NEW uint16 message_seq; // New field
uint24 fragment_offset; // NEW uint24 fragment_offset; // New field
uint24 fragment_length; // NEW uint24 fragment_length; // New field
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // NEW case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate; case certificate:Certificate;
case server_key_exchange: ServerKeyExchange; case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone; case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished:Finished; case finished:Finished;
} body; } body;
} Handshake; } Handshake;
struct { struct {
Cookie cookie<H0..32>; Cookie cookie<H0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
5. Security Considerations 5. Security Considerations
This document describes a variant of TLS 1.1 and therefore most of This document describes a variant of TLS 1.1 and therefore most of
the security considerations are the same as TLS 1.1. 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 The primary additional security consideration raised by DTLS is that
of denial of service. DTLS includes a cookie exchange designed to of denial of service. DTLS includes a cookie exchange designed to
protect against denial of service. However, implementations which do protect against denial of service. However, implementations which do
not use this cookie exchange are still vulnerable to DoS. In not use this cookie exchange are still vulnerable to DoS. In
particular, DTLS servers which do not use the cookie exchange may be particular, DTLS servers which do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not used as attack amplifiers even if they themselves are not
experiencing DoS. Therefore DTLS servers SHOULD use the cookie experiencing DoS. Therefore DTLS servers SHOULD use the cookie
exchange unless there is good reason to believe that amplification is exchange unless there is good reason to believe that amplification is
not a threat in their environment. not a threat in their environment.
6. IANA Considerations 6. IANA Considerations
This document uses the same identifier space as does TLS [TLS11], so This document uses the same identifier space as TLS [TLS11], so no
no IANA registries are required beyond those for TLS. Identifiers MAY IANA registries are required beyond those for TLS. Identifiers MAY
NOT be assigned for DTLS that conflict with TLS. NOT be assigned for DTLS that conflict with TLS. When new identifiers
are assigned for TLS, authors MUST specify whether they are suitable
for DTLS.
References References
Normative References Normative References
[PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
Protocol", RFC 2521, March 1999. Protocol", RFC 2521, March 1999.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]
[RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery",
RFC 1191, November 1990. RFC 1191, November 1990.
[RFC2401] Kent, S., Atkinson, R., "Security Architecture for the [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC2401, November 1998. Internet Protocol", RFC2401, November 1998.
[TCP] Postel, J., "Transmission Control Protocol",
RFC 793, September 1981.
[TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-05.txt, July 2003. draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
Informative References Informative References
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", [AH] Kent, S., and Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
skipping to change at page 19, line 16 skipping to change at page 20, line 26
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[POP] Myers, J., and Rose, M., "Post Office Protocol - [POP] Myers, J., and Rose, M., "Post Office Protocol -
Version 3", RFC 1939, May 1996. Version 3", RFC 1939, May 1996.
[SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., Schooler, E., Peterson, J., Sparks, R., Handley, M., Schooler, E.,
"SIP: Session Initiation Protocol", RFC 3261, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[TCP] Postel, J., "Transmission Control Protocol",
RFC 793, September 1981.
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
draft-bellovin-useipsec-02.txt, October 2003 draft-bellovin-useipsec-02.txt, October 2003
Authors' Address Authors' Address
Eric Rescorla <ekr@rtfm.com> Eric Rescorla <ekr@rtfm.com>
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
Nagendra Modadugu <nagendra@cs.stanford.edu> Nagendra Modadugu <nagendra@cs.stanford.edu>
Computer Science Department Computer Science Department
353 Serra Mall 353 Serra Mall
Stanford University Stanford University
Stanford, CA 94305 Stanford, CA 94305
Acknowledgements Acknowledgements
The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
Sapuntzakis, and Hovav Shacham for discussions and comments on the Constantine Sapuntzakis, and Hovav Shacham for discussions and
design of DTLS. Thanks to the anonymous NDSS reviewers of our comments on the design of DTLS. Thanks to the anonymous NDSS
original NDSS paper on DTLS [DTLS] for their comments. Also, thanks reviewers of our original NDSS paper on DTLS [DTLS] for their
to Steve Kent for feedback that helped clarify many points. The comments. Also, thanks to Steve Kent for feedback that helped clarify
section on PMTU was cribbed from the DCCP specification [DCCP]. many points. The section on PMTU was cribbed from the DCCP
specification [DCCP].
Full Copyright Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 55 change blocks. 
123 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/