E. Rescorla RTFM, Inc. N. Modadugu INTERNET-DRAFT Stanford University December 2003 (Expires June 2004) Datagram Transport Layer Security Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (1999-2004). All Rights Reserved. Rescorla, Modadugu [Page 1] Contents Abstract This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the TLS protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. 1. Introduction TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the network layer. However, TLS must run over a reliable transport channel--typically TCP [TCP]. It therefore cannot be used to secure unreliable datagram traffic. However, over the past few years an increasing number of application layer protocols have been designed which UDP transport. In particular such protocols as the Session Initiation Protocol (SIP) [SIP], and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable). Currently, designers these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. SIP, for instance, uses a variant of S/MIME to secure its traffic. Unfortunately, application layer security protocols typically require a large amount of effort to design--by contrast to the relatively small amount of effort required to run the protocol over TLS. In many cases, the most desirable way to secure client/server applications would be to use TLS, however the requirement for datagram semantics automatically prohibits use of TLS. Thus, a datagram-compatible variant of TLS would be very desirable. This memo describes such a protocol: Datagram Transport Layer Security (DTLS). Rescorla, Modadugu [Page 2] DTLS is deliberately designed to be as similar to to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. 2. Usage Model The DTLS protocol is designed to secure data between communicating applications. It is designed to run in application space, without requiring any kernel modifications. While the design of the DTLS protocol does not preclude its use in securing arbitrary datagram traffic, it is primarily expected to secure communication based on datagram sockets. Datagram transport does not guarantee reliable or in-order delivery of data. The DTLS protocol preserves this property for payload data. Applications such as media streaming, Internet telephony and online gaming use datagram transport for communication due to the delay- sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or re-ordered data traffic. 3. Overview of DTLS The basic design philosophy of DTLS is to construct "TLS over datagram". The reason that TLS cannot be used directly in datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle this kind of unreliability and therefore TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new mechanisms, we attempt to do so in such a way that it preserves the style of TLS. Unreliability creates problems for TLS at two levels: 1. TLS's traffic encryption layer does not allow independent decryption of individual records. If record N is not received, then record N+1 cannot be decrypted. 2. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost. The rest of this section describes the approach that DTLS uses to solve these problems. Rescorla, Modadugu [Page 3] 3.1. Loss-insensitive messaging In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency: 1. Cryptographic context (CBC state, stream cipher key stream) is chained between records. 2. Anti-replay and message reordering protection are provided by a MAC which includes a sequence number, but the sequence numbers are implicit in the records. The fix for both of these problems is straightforward and well-known from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 [TLS11] is already adding explicit CBC state to TLS records. DTLS borrows that mechanism and adds explicit sequence numbers. 3.2. Providing Reliability for Handshake The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order and any other order is an error. Clearly, this is incompatible with reordering and message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of fragmentation. DTLS must provide fixes for both these problems. 3.2.1. Packet Loss DTLS uses a simple retransmission timer to handle packet loss. The following figure demonstrates the basic concept using the first phase of the DTLS handshake: Client Server ------ ------ ClientHello ------> X<-- HelloVerifyRequest (lost) [Timer Expires] ClientHello ------> (retransmit) Once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server. However, if the server's message is lost the client knows that either the ClientHello or the Rescorla, Modadugu [Page 4] HelloVerifyRequest has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. The server also maintains a retransmission timer and retransmits when that timer expires. 3.2.2. Reordering In DTLS, each handshake message is assigned a specific sequence number within that handshake. When a peer receives a handshake message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it up for future handling once all previous messages have been received. 3.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented message. DTLS optionally supports record replay detection. The technique used is the same as in IPsec AH/ESP, by maintaining a bitmap window of received records. Records that are too old to fit in the window and records that have been previously received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious, but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy. 4. Differences from TLS As mentioned in Section , DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we instead present it as a series of deltas from TLS 1.1 [TLS11]. Where we do not explicitly call out differences, DTLS is the same as TLS. 4.1. Record Layer The DTLS record layer is extremely similar to that of TLS 1.1. The only change is the inclusion of an explicit sequence number in the record. This sequence number allows the recipient to correctly verify the TLS MAC. The DTLS record format is shown below: Rescorla, Modadugu [Page 5] struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext; type Equivalent to the type field in a TLS 1.1 record. version The version of the protocol being employed. This document describes DTLS Version 1.0, which uses the version { 254, 255 }. The version value of 254.255 is the 1's complement of DTLS Version 1.0. This maximal spacing between TLS and DTLS version numbers ensures that records from the two protocols can be easily distinguished. epoch A counter value that is incremented on every cipher state change. sequence_number The sequence number for this record. length Identical to the length field in a TLS 1.1 record. As in TLS 1.1, the length should not exceed 2^14. fragment Identical to the fragment field of a TLS 1.1 record. DTLS uses an explicit rather than implicit sequence number, carried in the sequence_number field of the record. As with TLS, the sequence number is set to zero after each ChangeCipherSpec message is sent. If several handshakes are performed in close succession, there might be multiple records on the wire with the same sequence number but from different cipher states. The epoch field allows recipients to distinguish such packets. The epoch number is initially zero and is incremented each time the ChangeCipherSpec messages is sent. In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the maximum segment lifetime. In practice, TLS implementations rehandshake rarely and we therefore do not expect this to be a problem. Rescorla, Modadugu [Page 6] 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine the MTU and send records smaller than the MTU. DTLS implementations SHOULD provide a way for applications to determine the value of the MTU (optimally the maximum application datagram size, which is the PMTU minus the DTLS per-record overhead). If the application attempts to send a record larger than the MTU, the DTLS implementation MUST either generate an error or fragment the packet. 4.1.1.1. PMTU Discovery The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. 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 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 the Code indicating "fragmentation needed and DF set" (also known as a "Datagram Too Big" message). When a DTLS implementation receives a 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 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 is greater than the current PMTU, the Datagram Too Big message is ignored, as described in [RFC 1191]. A DTLS implementation may allow the application to occasionally request that PMTU discovery be performed again. This will reset the PMTU to the outgoing interface's MTU. Such requests SHOULD be rate limited, to one per two seconds, for example. Because some firewalls and routers screen out ICMP messages, it is difficult to distinguish packet loss from a large PMTU estimate. In order to allow connections under these circumstances, DTLS implementations MAY choose to back off their PMTU estimate during the retransmit backoff described in Section . For instance, if a large packet is being sent, after 3 retransmits a sender might choose to fragment the packet. 4.1.2. Record payload protection 4.1.2.1. MAC The DTLS MAC is the same as that of TLS 1.1. However, rather than using TLS's implicit sequence number, the sequence number used to Rescorla, Modadugu [Page 7] compute the MAC is the 64-bit value formed by concatenating the epoch and the sequence number in the order they appear on the wire. Note that the DTLS epoch + sequence number is the same length as the TLS sequence number. 4.1.2.2. Null or standard stream 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 randomly accessed. RC4 MUST NOT be used with DTLS. 4.1.2.3. Block Cipher DTLS block cipher encryption and decryption are performed exactly as with TLS 1.1. 4.1.2.4. Anti-Replay DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] The receiver packet counter for this session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record contains a Sequence Number that does not duplicate the Sequence Number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it has been matched to a session, to speed rejection of duplicate records. Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The "right" edge of the window represents the highest, validated Sequence Number value received on this session. Records that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in [RFC 2401]. Rescorla, Modadugu [Page 8] If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds. 4.2. The DTLS Handshake Protocol DTLS uses all of the same handshake messages and flows as TLS, with three principal changes: 1. A stateless cookie exchange to prevent denial of service attacks. 2. Modifications to the handshake header to handle message loss, reordering and fragmentation. 3. Retransmission timers to handle message loss. With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.1. 4.2.1. Denial of Service Countermeasures Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern: 1. An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially perform expensive cryptographic operations. 2. An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it. In order to prevent both of these attacks, DTLS borrows the stateless cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. Rescorla, Modadugu [Page 9] 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; Cookie cookie<0..32>; // New field CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; } 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: struct { Cookie cookie<0..32>; } HelloVerifyRequest; The HelloVerifyRequest message type is hello_verify_request(3). When responding to a HelloVerifyRequest the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as in the original ClientHello. The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt. Although DTLS servers are not required to do a cookie exchange, they SHOULD do so whenever a new handshake is performed in order to avoid being used as amplifiers. If the server is being operated in an environment where amplification is not a problem, the server MAY choose not to perform a cookie exchange. In addition, the server MAY Rescorla, Modadugu [Page 10] choose not do to a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake. 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 message 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) Rescorla, Modadugu [Page 11] ClientHello (seq=1) ------> (with cookie) <------ ServerHello (seq=1) <------ Certificate (seq=2) <------ ServerHelloDone (seq=3) [Rest of handshake] 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 , each DTLS message MUST fit within a single transport layer datagram. However, handshake messages are potentially bigger than the maximum record size. Therefore DTLS provides a mechanism for fragmenting a handshake message over a number of records. When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. These range must be no 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. 4.2.4. Timeout and Retransmission DTLS messages are grouped into a series of message flights, according the diagrams below. Although each flight of messages may consist of a Rescorla, Modadugu [Page 12] 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. Rescorla, Modadugu [Page 13] +--------+ | PREPAR | +---> | -ING | | | | | +--------+ | | | | | | Buffer next flight | | | \|/ | +---------+ | | | | | SENDING |<--------------------+ | | | | | +---------+ | Receive | | | next | | Send flight | flight | +-------+ | | | | Set retransmit timer | | | \|/ | | | +---------+ | | | | | | +--)--| WAITING |---------------------+ | | | | Timer expires | | | +---------+ | | | | | | | | | | | +------------------------+ | | Read retransmit Receive | | last | | flight | | | | \|/\|/ FINISH 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. Rescorla, Modadugu [Page 14] In the SENDING state, the implementation transmits the buffered flight of messages. Once the messages have been sent, the implementation then enters the FINISH state if this is the last flight in the handshake, or, if the implementation expects to receive more messages, sets a retransmit timer and then enters the WAITING state. There are three ways to exit the WAITING state: 1. The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. 2. The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost. 3. The implementation receives the next flight of messages: if this is the final flight of messages the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets. Because DTLS clients send the first message (ClientHello) they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer. 4.2.4.1. Timer Values Timer value choices are a local matter. We recommend that implementations use an initial timer value of 500 ms and double the value at each retransmission, up to 2MSL. Implementations SHOULD start the timer value at the initial value with each new flight of messages. 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. Rescorla, Modadugu [Page 15] 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 ARE included in the Finished MAC. A.1 Summary of new syntax This section includes specifications for the data structures that have changed between TLS 1.1 and DTLS. 4.2. Record Layer struct { ContentType type; ProtocolVersion version; uint16 epoch; // NEW uint48 sequence_number; // NEW uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext; struct { ContentType type; ProtocolVersion version; uint16 epoch; // NEW uint48 sequence_number; // NEW uint16 length; opaque fragment[DTLSCompressed.length]; } DTLSCompressed; struct { ContentType type; ProtocolVersion version; uint16 epoch; // NEW uint48 sequence_number; // NEW uint16 length; select (CipherSpec.cipher_type) { case block: GenericBlockCipher; } fragment; } DTLSCiphertext; Rescorla, Modadugu [Page 16] 4.3. Handshake Protocol enum { hello_request(0), client_hello(1), server_hello(2), hello_verify_request(3), // NEW certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; uint24 length; uint16 message_seq; // NEW uint24 fragment_offset; // NEW uint24 fragment_length; // NEW select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case hello_verify_request: HelloVerifyRequest; // NEW case certificate:Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done:ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished:Finished; } body; } Handshake; struct { Cookie cookie; } HelloVerifyRequest; 5. Security Considerations This document describes a variant of TLS 1.1 and therefore most of the security considerations are the same as TLS 1.1. The primary additional security consideration raised by DTLS is that of denial of service. DTLS includes a cookie exchange designed to protect against denial of service. However, implementations which do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers which do not use the cookie exchange may be used as attack amplifiers even if they themselves are not experiencing DoS. Therefore DTLS servers SHOULD use the cookie Rescorla, Modadugu [Page 17] exchange unless there is good reason to believe that amplification is not a threat in their environment. 6. IANA Considerations This document uses the same identifier space as 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 Normative References [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management Protocol", RFC 2521, March 1999. [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", RFC 1191, November 1990. [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999. [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", draft-ietf-tls-rfc2246-bis-05.txt, July 2003. Informative References [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2402, November 1998. [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram Congestion Control Protocol", draft-ietf-dccp-spec-05.txt, October 2003 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", in Proceedings of ISOC NDSS 2004, February 2004. [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Rescorla, Modadugu [Page 18] [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [POP] Myers, J., and Rose, M., "Post Office Protocol - Version 3", RFC 1939, May 1996. [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [TCP] Postel, J., "Transmission Control Protocol", RFC 793, September 1981. [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", draft-bellovin-useipsec-02.txt, October 2003 Authors' Address Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 Nagendra Modadugu Computer Science Department 353 Serra Mall Stanford University Stanford, CA 94305 Acknowledgements The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine Sapuntzakis, and Hovav Shacham for discussions and comments on the design of DTLS. Thanks to the anonymous NDSS reviewers of our original NDSS paper on DTLS [DTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify many points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Rescorla, Modadugu [Page 19] Full Copyright Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright Notice Copyright (C) The Internet Society (2003). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Rescorla, Modadugu [Page 20]