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 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 {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3).
The server_version field is defined as in TLS.
When responding to a HelloVerifyRequest the client MUST use the same
parameter values (version, random, session_id, cipher_suites,
compression_method) as it did in the original ClientHello. The
server SHOULD use those values to generate its cookie and verify that
they are correct upon cookie receipt. The server MUST use the same
version number in the HelloVerifyRequest that it would use when
sending a ServerHello. Upon receipt of the ServerHello, the client
MUST verify that the server version values match.
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 that legitimate clients 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.
DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange. The default SHOULD be
that the exchange is performed, however. In addition, the server MAY
choose not to do 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) {
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.
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 ranges 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.
4.2.4. Timeout and Retransmission
DTLS messages are grouped into a series of message flights, according
to 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)
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.
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| 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 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, it 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.
When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest it transitions from FINISHED
to PREPARING to transmit the ClientHello.
4.2.4.1. Timer Values
Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if
many instances of a DTLS time out early and retransmit too quickly on
a congested link. Implementations SHOULD use an initial timer value
of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double
the value at each retransmission, up to no less than the RFC 2988
maximum of 60 seconds. Note that we recommend a 1-second timer
rather than the 3-second RFC 2988 default in order to improve latency
for time-sensitive applications. Because DTLS only uses
retransmission for handshake and not dataflow, the effect on
congestion should be minimal.
Implementations SHOULD retain the current timer value until a
transmission without loss occurs, at which time the value may be
reset to the initial value. After a long period of idleness, no less
than 10 times the current timer value, implementations may reset the
timer to the initial value. One situation where this might occur is
when a rehandshake is used after substantial data transfer.
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 NOT 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).
Implementations SHOULD detect when a peer is persistently sending bad
messages and terminate the local connection state after such
misbehavior is detected.
4.3. Summary of new syntax
This section includes specifications for the data structures that
have changed between TLS 1.1 and DTLS.
4.3.1. 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];
} DTLSCompressed;