< draft-rescorla-dtls-01.txt   draft-rescorla-dtls-02.txt >
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
N. Modadugu N. Modadugu
INTERNET-DRAFT Stanford University INTERNET-DRAFT Stanford University
<draft-rescorla-dtls-01.txt> July 2004 (Expires December 2004) <draft-rescorla-dtls-02.txt> December 2003 (Expires June 2004)
Datagram Transport Layer Security Datagram Transport Layer Security
Copyright Notice Status of this Memo
Copyright (C) The Internet Society (2004). All Rights Reserved. By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
Status of this Memo Internet-Drafts are working documents of the Internet Engineering
By submitting this Internet-Draft, I certify that any applicable Task Force (IETF), its areas, and its working groups. Note that other
patent or other IPR claims of which I am aware have been disclosed, groups may also distribute working documents as Internet-Drafts.
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are draft documents valid for a maximum of six months
Task Force (IETF), its areas, and its working groups. Note that other and may be updated, replaced, or obsoleted by other documents at any
groups may also distribute working documents as Internet-Drafts. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
Internet-Drafts are draft documents valid for a maximum of six months The list of current Internet-Drafts can be accessed at
and may be updated, replaced, or obsoleted by other documents at any http://www.ietf.org/1id-abstracts.html
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
Contents
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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 privacy guarantees. based on the TLS protocol and provides equivalent security
Datagram semantics of the underlying transport are preserved by the guarantees. Datagram semantics of the underlying transport are
DTLS protocol. preserved by the DTLS protocol.
Contents
1 Introduction 3
2 Usage Model 3
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 5
3.3 Message Size 5
3.4 Replay Detection 6
4 Differences from TLS 6
4.1 Record Layer 6
4.1.1 Transport Layer Mapping 7
4.1.1.1 PMTU Discovery 7
4.1.2 Record payload protection 8
4.1.2.1 MAC 8
4.1.2.2 Null or standard stream cipher 8
4.1.2.3 Block Cipher 9
4.1.2.4 Anti-Replay 9
4.2 The DTLS Handshake Protocol 9
4.2.1 Denial of Service Countermeasures 10
4.2.2 Handshake Message Format 11
4.2.3 Message Fragmentation and Reassembly 13
4.2.4 Timeout and Retransmission 13
4.2.4.1 Timer Values 16
4.2.5 ChangeCipherSpec 16
4.2.6 Finished messages 17
4.2 Record Layer 17
4.3 Handshake Protocol 18
5 Security Considerations 18
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 channel. Thus, it is easy to
secure an application protocol by inserting TLS between the secure an application protocol by inserting TLS between the
application layer and the network layer. However, TLS must run over a application layer and the network layer. However, TLS must run over a
reliable transport channel--typically TCP [REF]. It therefore cannot reliable transport channel--typically TCP [TCP]. It therefore cannot
be used to secure unreliable datagram traffic. 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 using 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. Currently, electronic gaming protocols are increasingly popular. (Note that SIP
designers these applications are faced with a number of can run over both TCP and UDP, but that there are situations in which
unsatisfactory choices. First, they can use IPsec. However, for a UDP is preferable). Currently, designers these applications are faced
number of reasons detailed in [WHYIPSEC], this is only suitable for with a number of unsatisfactory choices. First, they can use IPsec
some applications. Second, they can design a custom application layer [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC],
security protocol. SIP, for instance, uses a variant of S/MIME to this is only suitable for some applications. Second, they can design
secure its traffic. Unfortunately, application layer security a custom application layer security protocol. SIP, for instance, uses
protocols typically require a large amount of effort to design--by a variant of S/MIME to secure its traffic. Unfortunately, application
contrast to the relatively small amount of effort required to run the layer security protocols typically require a large amount of effort
protocol over TLS. 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.
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 guarantee reliable or in-order delivery
of data. The DTLS protocol preserves this property for payload data. of data. The DTLS protocol preserves this property for payload data.
Applications such as media streaming, Internet telephony and online Applications such as media streaming, Internet telephony and online
gaming use datagram transport for communication due to the delay- gaming use datagram transport for communication due to the delay-
sensitive nature of transported data. The behaviour of such sensitive nature of transported data. The behavior of such
applications is unchanged when the DTLS protocol is used to secure applications is unchanged when the DTLS protocol is used to secure
communication, since the DTLS protocol does not compensate for lost communication, since the DTLS protocol does not compensate for lost
or re-ordered data traffic. 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
skipping to change at page 6, line 10 skipping to change at page 5, line 29
3.3. Message Size 3.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.4. 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, by maintaining a bitmap window of received is the same as in IPsec AH/ESP, by maintaining a bitmap window of
records. Records that are too old to fit in the window and records received records. Records that are too old to fit in the window and
that have been previously received are silently discarded. The replay records that have been previously received are silently discarded.
detection feature is optional, since packet duplication is not always The replay detection feature is optional, since packet duplication is
malicious, but can also occur due to routing errors. Applications may not always malicious, but can also occur due to routing errors.
conceivably detect duplicate packets and accordingly modify their Applications may conceivably detect duplicate packets and accordingly
data transmission strategy. modify their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section 3., DTLS is intentionally very similar to As mentioned in Section , DTLS is intentionally very similar to TLS.
TLS. Therefore, instead of presenting DTLS as a new protocol, we Therefore, instead of presenting DTLS as a new protocol, we instead
instead present it as a series of deltas from TLS 1.1 [TLS11]. Where present it as a series of deltas from TLS 1.1 [TLS11]. Where we do
we do not explicitly call out differences, DTLS is the same as TLS 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;
skipping to change at page 8, line 16 skipping to change at page 7, line 32
(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
a "Datagram Too Big" message). When a DTLS implementation receives a a "Datagram Too Big" message). When a DTLS implementation receives a
Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU
value given in the ICMP message. If the MTU given in the message is value given in the ICMP message. If the MTU given in the message is
zero, the sender chooses a value for PMTU using the algorithm zero, the sender chooses a value for PMTU using the algorithm
described in Section 7 of [RFC 1191]. If the MTU given in the message described in Section 7 of [RFC 1191]. If the MTU given in the message
is greater than the current PMTU, the Datagram Too Big message is is greater than the current PMTU, the Datagram Too Big message is
ignored, as described in [RFC 1191]. (We are aware that this may ignored, as described in [RFC 1191].
cause problems for DTLS endpoints behind certain firewalls.)
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 an overlarge PMTU estimate. difficult to distinguish packet loss from a large PMTU estimate. In
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 4.2.4.. For instance, if a retransmit backoff described in Section . For instance, if a large
large packet is being sent, after 3 retransmits a sender might choose packet is being sent, after 3 retransmits a sender might choose to
to fragment the packet. fragment the packet.
4.1.2. Record payload protection 4.1.2. Record payload protection
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
skipping to change at page 11, line 5 skipping to change at page 10, line 17
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
<----- HelloVerifyRequest <----- HelloVerifyRequest
(contains cookie) (contains cookie)
ClientHello ------> ClientHello ------>
(with cookie) (with cookie)
[Rest of handshake here] [Rest of handshake]
DTLS therefore modifies the ClientHello message to add the cookie DTLS therefore modifies the ClientHello message to add the cookie
value. value.
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
Cookie cookie<0..32>; // New field Cookie cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
} ClientHello; } ClientHello;
If the client does not have a cookie for a given server, it should
use a zero-length cookie.
The definition of HelloVerifyRequest is as follows: The definition of HelloVerifyRequest is as follows:
struct { struct {
Cookie cookie<0..32>; Cookie cookie<0..32>;
} HelloVerifyRequest; } HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3). The HelloVerifyRequest message type is hello_verify_request(3).
When responding to a HelloVerifyRequest the client MUST use the same When responding to a HelloVerifyRequest the client MUST use the same
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. 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;
skipping to change at page 13, line 9 skipping to change at page 12, line 25
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 4.1.1., each DTLS message MUST fit within a As noted in Section , each DTLS message MUST fit within a single
single transport layer datagram. However, handshake messages are transport layer datagram. However, handshake messages are potentially
potentially bigger than the maximum record size. Therefore DTLS bigger than the maximum record size. Therefore DTLS provides a
provides a mechanism for fragmenting a handshake message over a mechanism for fragmenting a handshake message over a number of
number of records. 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 be no 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
skipping to change at page 14, line 41 skipping to change at page 13, line 44
------ ------ ------ ------
ClientHello --------> Flight 1 ClientHello --------> Flight 1
ServerHello \ ServerHello \
[ChangeCipherSpec] Flight 2 [ChangeCipherSpec] Flight 2
<-------- Finished / <-------- Finished /
[ChangeCipherSpec] \Flight 3 [ChangeCipherSpec] \Flight 3
Finished --------> / Finished --------> /
Figure 2: Message flights for abbreviated 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.
+--------+ +--------+
| PREPAR | | PREPAR |
+---> | -ING | +---> | -ING |
| | | | | |
| +--------+ | +--------+
| | | |
skipping to change at page 17, line 14 skipping to change at page 16, line 14
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 ARE included in the
Finished MAC. Finished MAC.
A.1Summary of new syntax A.1 Summary 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
uint48 sequence_number; // NEW uint48 sequence_number; // NEW
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
uint48 sequence_number; // NEW uint48 sequence_number; // NEW
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
uint48 sequence_number; // NEW uint48 sequence_number; // NEW
uint16 length; uint16 length;
select (CipherSpec.cipher_type) { select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
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
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
skipping to change at page 19, line 4 skipping to change at page 18, line 4
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 TLS 1.1.
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
This document uses the same identifier space as does TLS [TLS11], so
no IANA registries are required beyond those for TLS. Identifiers MAY
NOT be assigned for DTLS that conflict with TLS.
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.
[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
Internet Protocol", RFC2401, November 1998.
[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.
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
Congestion Control Protocol", draft-ietf-dccp-spec-05.txt, Congestion Control Protocol", draft-ietf-dccp-spec-05.txt,
October 2003 October 2003
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", to appear in Proceedings of ISOC NDSS 2004, of Datagram TLS", in Proceedings of ISOC NDSS 2004,
February 2004. February 2004.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
skipping to change at page 20, line 22 skipping to change at page 19, line 30
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>
Gates Computer Science Computer Science Department
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, Constantine
Sapuntzakis, and Hovav Shacham for discussions and comments on the Sapuntzakis, and Hovav Shacham for discussions and comments on the
design of DTLS. Thanks to the anonymous NDSS reviewers of our design of DTLS. Thanks to the anonymous NDSS reviewers of our
original NDSS paper on DTLS [DTLS] for their comments. Also, thanks original NDSS paper on DTLS [DTLS] for their comments. Also, thanks
to Steve Kent for feedback that helped clarify many points. The to Steve Kent for feedback that helped clarify many points. The
section on PMTU was cribbed from the DCCP specification [DCCP]. section on PMTU was cribbed from the DCCP specification [DCCP].
Intellectual Property 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). This document is subject Copyright (C) The Internet Society (2003). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 44 change blocks. 
110 lines changed or deleted 97 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/