idnits 2.17.00 (12 Aug 2021) /tmp/idnits18040/draft-rescorla-dtls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 900. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 267: '... implementations MUST NOT allow the sa...' RFC 2119 keyword, line 274: '...Each DTLS record MUST fit within a sin...' RFC 2119 keyword, line 275: '... IP fragmentation [MOGUL], DTLS implementations SHOULD determine the...' RFC 2119 keyword, line 277: '... SHOULD provide a way for applicatio...' RFC 2119 keyword, line 280: '... the MTU, the DTLS implementation MUST...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MOGUL' is mentioned on line 275, but not defined == Missing Reference: 'RFC 1191' is mentioned on line 299, but not defined == Missing Reference: 'RFC 2402' is mentioned on line 342, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC 2401' is mentioned on line 367, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 600, but not defined == Unused Reference: 'RFC1191' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'AH' is defined on line 822, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 2521 (ref. 'PHOTURIS') ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == Outdated reference: draft-ietf-tls-rfc2246-bis has been published as RFC 4346 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. 'TLS11') -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: draft-ietf-dccp-spec has been published as RFC 4340 -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: draft-bellovin-useipsec has been published as RFC 5406 Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 RTFM, Inc. 4 N. Modadugu 5 INTERNET-DRAFT Stanford University 6 December 2003 (Expires June 2004) 8 Datagram Transport Layer Security 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (1999-2004). All Rights Reserved. 36 Contents 38 Abstract 40 This document specifies Version 1.0 of the Datagram Transport Layer 41 Security (DTLS) protocol. The DTLS protocol provides communications 42 privacy for datagram protocols. The protocol allows client/server 43 applications to communicate in a way that is designed to prevent 44 eavesdropping, tampering, or message forgery. The DTLS protocol is 45 based on the TLS protocol and provides equivalent security 46 guarantees. Datagram semantics of the underlying transport are 47 preserved by the DTLS protocol. 49 1. Introduction 51 TLS [TLS] is the most widely deployed protocol for securing network 52 traffic. It is widely used for protecting Web traffic and for e-mail 53 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of 54 TLS is that it provides a transparent channel. Thus, it is easy to 55 secure an application protocol by inserting TLS between the 56 application layer and the network layer. However, TLS must run over a 57 reliable transport channel--typically TCP [TCP]. It therefore cannot 58 be used to secure unreliable datagram traffic. 60 However, over the past few years an increasing number of application 61 layer protocols have been designed which UDP transport. In particular 62 such protocols as the Session Initiation Protocol (SIP) [SIP], and 63 electronic gaming protocols are increasingly popular. (Note that SIP 64 can run over both TCP and UDP, but that there are situations in which 65 UDP is preferable). Currently, designers these applications are faced 66 with a number of unsatisfactory choices. First, they can use IPsec 67 [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], 68 this is only suitable for some applications. Second, they can design 69 a custom application layer security protocol. SIP, for instance, uses 70 a variant of S/MIME to secure its traffic. Unfortunately, application 71 layer security protocols typically require a large amount of effort 72 to design--by contrast to the relatively small amount of effort 73 required to run the protocol over TLS. 75 In many cases, the most desirable way to secure client/server 76 applications would be to use TLS, however the requirement for 77 datagram semantics automatically prohibits use of TLS. Thus, a 78 datagram-compatible variant of TLS would be very desirable. This memo 79 describes such a protocol: Datagram Transport Layer Security (DTLS). 81 DTLS is deliberately designed to be as similar to to TLS as possible, 82 both to minimize new security invention and to maximize the amount of 83 code and infrastructure reuse. 85 2. Usage Model 87 The DTLS protocol is designed to secure data between communicating 88 applications. It is designed to run in application space, without 89 requiring any kernel modifications. While the design of the DTLS 90 protocol does not preclude its use in securing arbitrary datagram 91 traffic, it is primarily expected to secure communication based on 92 datagram sockets. 94 Datagram transport does not guarantee reliable or in-order delivery 95 of data. The DTLS protocol preserves this property for payload data. 96 Applications such as media streaming, Internet telephony and online 97 gaming use datagram transport for communication due to the delay- 98 sensitive nature of transported data. The behavior of such 99 applications is unchanged when the DTLS protocol is used to secure 100 communication, since the DTLS protocol does not compensate for lost 101 or re-ordered data traffic. 103 3. Overview of DTLS 105 The basic design philosophy of DTLS is to construct "TLS over 106 datagram". The reason that TLS cannot be used directly in datagram 107 environments is simply that packets may be lost or reordered. TLS has 108 no internal facilities to handle this kind of unreliability and 109 therefore TLS implementations break when rehosted on datagram 110 transport. The purpose of DTLS is to make only the minimal changes to 111 TLS required to fix this problem. To the greatest extent possible, 112 DTLS is identical to TLS. Whenever we need to invent new mechanisms, 113 we attempt to do so in such a way that it preserves the style of TLS. 115 Unreliability creates problems for TLS at two levels: 117 1. TLS's traffic encryption layer does not allow independent 118 decryption of individual records. If record N is not received, 119 then record N+1 cannot be decrypted. 121 2. The TLS handshake layer assumes that handshake messages are 122 delivered reliably and breaks if those messages are lost. 124 The rest of this section describes the approach that DTLS uses to 125 solve these problems. 127 3.1. Loss-insensitive messaging 129 In TLS's traffic encryption layer (called the TLS Record Layer), 130 records are not independent. There are two kinds of inter-record 131 dependency: 133 1. Cryptographic context (CBC state, stream cipher key stream) is 134 chained between records. 136 2. Anti-replay and message reordering protection are provided by a 137 MAC which includes a sequence number, but the sequence numbers are 138 implicit in the records. 140 The fix for both of these problems is straightforward and well-known 141 from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 142 [TLS11] is already adding explicit CBC state to TLS records. DTLS 143 borrows that mechanism and adds explicit sequence numbers. 145 3.2. Providing Reliability for Handshake 147 The TLS handshake is a lockstep cryptographic handshake. Messages 148 must be transmitted and received in a defined order and any other 149 order is an error. Clearly, this is incompatible with reordering and 150 message loss. In addition, TLS handshake messages are potentially 151 larger than any given datagram, thus creating the problem of 152 fragmentation. DTLS must provide fixes for both these problems. 154 3.2.1. Packet Loss 156 DTLS uses a simple retransmission timer to handle packet loss. The 157 following figure demonstrates the basic concept using the first phase 158 of the DTLS handshake: 160 Client Server 161 ------ ------ 162 ClientHello ------> 164 X<-- HelloVerifyRequest 165 (lost) 167 [Timer Expires] 169 ClientHello ------> 170 (retransmit) 172 Once the client has transmitted the ClientHello message, it expects 173 to see a HelloVerifyRequest from the server. However, if the server's 174 message is lost the client knows that either the ClientHello or the 176 HelloVerifyRequest has been lost and retransmits. When the server 177 receives the retransmission, it knows to retransmit. The server also 178 maintains a retransmission timer and retransmits when that timer 179 expires. 181 3.2.2. Reordering 183 In DTLS, each handshake message is assigned a specific sequence 184 number within that handshake. When a peer receives a handshake 185 message, it can quickly determine whether that message is the next 186 message it expects. If it is, then it processes it. If not, it queues 187 it up for future handling once all previous messages have been 188 received. 190 3.3. Message Size 192 TLS and DTLS handshake messages can be quite large (in theory up to 193 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams 194 are often limited to <1500 bytes. In order to compensate for this 195 limitation, each DTLS handshake message may be fragmented over 196 several DTLS records. Each DTLS handshake message contains both a 197 fragment offset and a fragment length. Thus, a recipient in 198 possession of all bytes of a handshake message can reassemble the 199 original unfragmented message. 200 DTLS optionally supports record replay detection. The technique used 201 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 202 received records. Records that are too old to fit in the window and 203 records that have been previously received are silently discarded. 204 The replay detection feature is optional, since packet duplication is 205 not always malicious, but can also occur due to routing errors. 206 Applications may conceivably detect duplicate packets and accordingly 207 modify their data transmission strategy. 209 4. Differences from TLS 211 As mentioned in Section , DTLS is intentionally very similar to TLS. 212 Therefore, instead of presenting DTLS as a new protocol, we instead 213 present it as a series of deltas from TLS 1.1 [TLS11]. Where we do 214 not explicitly call out differences, DTLS is the same as TLS. 216 4.1. Record Layer 218 The DTLS record layer is extremely similar to that of TLS 1.1. The 219 only change is the inclusion of an explicit sequence number in the 220 record. This sequence number allows the recipient to correctly verify 221 the TLS MAC. The DTLS record format is shown below: 223 struct { 224 ContentType type; 225 ProtocolVersion version; 226 uint16 epoch; 227 uint48 sequence_number; 228 uint16 length; 229 opaque fragment[DTLSPlaintext.length]; 230 } DTLSPlaintext; 232 type 233 Equivalent to the type field in a TLS 1.1 record. 235 version 236 The version of the protocol being employed. This document 237 describes DTLS Version 1.0, which uses the version { 254, 255 238 }. The version value of 254.255 is the 1's complement of DTLS 239 Version 1.0. This maximal spacing between TLS and DTLS version 240 numbers ensures that records from the two protocols can be 241 easily distinguished. 243 epoch 244 A counter value that is incremented on every cipher state 245 change. 247 sequence_number 248 The sequence number for this record. 250 length 251 Identical to the length field in a TLS 1.1 record. As in TLS 252 1.1, the length should not exceed 2^14. 254 fragment 255 Identical to the fragment field of a TLS 1.1 record. 257 DTLS uses an explicit rather than implicit sequence number, carried 258 in the sequence_number field of the record. As with TLS, the sequence 259 number is set to zero after each ChangeCipherSpec message is sent. 261 If several handshakes are performed in close succession, there might 262 be multiple records on the wire with the same sequence number but 263 from different cipher states. The epoch field allows recipients to 264 distinguish such packets. The epoch number is initially zero and is 265 incremented each time the ChangeCipherSpec messages is sent. In order 266 to ensure that any given sequence/epoch pair is unique, 267 implementations MUST NOT allow the same epoch value to be reused 268 within two times the maximum segment lifetime. In practice, TLS 269 implementations rehandshake rarely and we therefore do not expect 270 this to be a problem. 272 4.1.1. Transport Layer Mapping 274 Each DTLS record MUST fit within a single datagram. In order to avoid 275 IP fragmentation [MOGUL], DTLS implementations SHOULD determine the 276 MTU and send records smaller than the MTU. DTLS implementations 277 SHOULD provide a way for applications to determine the value of the 278 MTU (optimally the maximum application datagram size, which is the 279 PMTU minus the DTLS per-record overhead). If the application attempts 280 to send a record larger than the MTU, the DTLS implementation MUST 281 either generate an error or fragment the packet. 283 4.1.1.1. PMTU Discovery 285 The PMTU SHOULD be initialized from the interface MTU that will be 286 used to send packets. 288 To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment 289 (DF) bit. As specified in [RFC 1191], when a router receives a packet 290 with DF set that is larger than the next link's MTU, it sends an ICMP 291 Destination Unreachable message to the source of the datagram with 292 the Code indicating "fragmentation needed and DF set" (also known as 293 a "Datagram Too Big" message). When a DTLS implementation receives a 294 Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU 295 value given in the ICMP message. If the MTU given in the message is 296 zero, the sender chooses a value for PMTU using the algorithm 297 described in Section 7 of [RFC 1191]. If the MTU given in the message 298 is greater than the current PMTU, the Datagram Too Big message is 299 ignored, as described in [RFC 1191]. 301 A DTLS implementation may allow the application to occasionally 302 request that PMTU discovery be performed again. This will reset the 303 PMTU to the outgoing interface's MTU. Such requests SHOULD be rate 304 limited, to one per two seconds, for example. 306 Because some firewalls and routers screen out ICMP messages, it is 307 difficult to distinguish packet loss from a large PMTU estimate. In 308 order to allow connections under these circumstances, DTLS 309 implementations MAY choose to back off their PMTU estimate during the 310 retransmit backoff described in Section . For instance, if a large 311 packet is being sent, after 3 retransmits a sender might choose to 312 fragment the packet. 314 4.1.2. Record payload protection 316 4.1.2.1. MAC 318 The DTLS MAC is the same as that of TLS 1.1. However, rather than 319 using TLS's implicit sequence number, the sequence number used to 321 compute the MAC is the 64-bit value formed by concatenating the epoch 322 and the sequence number in the order they appear on the wire. Note 323 that the DTLS epoch + sequence number is the same length as the TLS 324 sequence number. 326 4.1.2.2. Null or standard stream cipher 328 The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher. 330 The only stream cipher described in TLS 1.1 is RC4, which cannot be 331 randomly accessed. RC4 MUST NOT be used with DTLS. 333 4.1.2.3. Block Cipher 335 DTLS block cipher encryption and decryption are performed exactly as 336 with TLS 1.1. 338 4.1.2.4. Anti-Replay 340 DTLS records contain a sequence number to provide replay protection. 341 Sequence number verification SHOULD be performed using the following 342 sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402] 344 The receiver packet counter for this session MUST be initialized to 345 zero when the session is established. For each received record, the 346 receiver MUST verify that the record contains a Sequence Number that 347 does not duplicate the Sequence Number of any other record received 348 during the life of this session. This SHOULD be the first check 349 applied to a packet after it has been matched to a session, to speed 350 rejection of duplicate records. 352 Duplicates are rejected through the use of a sliding receive window. 353 (How the window is implemented is a local matter, but the following 354 text describes the functionality that the implementation must 355 exhibit.) A MINIMUM window size of 32 MUST be supported; but a window 356 size of 64 is preferred and SHOULD be employed as the default. 357 Another window size (larger than the MINIMUM) MAY be chosen by the 358 receiver. (The receiver does NOT notify the sender of the window 359 size.) 361 The "right" edge of the window represents the highest, validated 362 Sequence Number value received on this session. Records that contain 363 Sequence Numbers lower than the "left" edge of the window are 364 rejected. Packets falling within the window are checked against a 365 list of received packets within the window. An efficient means for 366 performing this check, based on the use of a bit mask, is described 367 in [RFC 2401]. 369 If the received record falls within the window and is new, or if the 370 packet is to the right of the window, then the receiver proceeds to 371 MAC verification. If the MAC validation fails, the receiver MUST 372 discard the received record as invalid. The receive window is updated 373 only if the MAC verification succeeds. 375 4.2. The DTLS Handshake Protocol 377 DTLS uses all of the same handshake messages and flows as TLS, with 378 three principal changes: 380 1. A stateless cookie exchange to prevent denial of service 381 attacks. 383 2. Modifications to the handshake header to handle message loss, 384 reordering and fragmentation. 386 3. Retransmission timers to handle message loss. 388 With these exceptions, the DTLS message formats, flows, and logic are 389 the same as those of TLS 1.1. 391 4.2.1. Denial of Service Countermeasures 393 Datagram security protocols are extremely susceptible to a variety of 394 denial of service (DoS) attacks. Two attacks are of particular 395 concern: 397 1. An attacker can consume excessive resources on the server by 398 transmitting a series of handshake initiation requests, causing 399 the server to allocate state and potentially perform expensive 400 cryptographic operations. 402 2. An attacker can use the server as an amplifier by sending 403 connection initiation messages with a forged source of the victim. 404 The server then sends its next message (in DTLS, a Certificate 405 message, which can be quite large) to the victim machine, thus 406 flooding it. 408 In order to prevent both of these attacks, DTLS borrows the stateless 409 cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When 410 the client sends its ClientHello message to the server, the server 411 MAY respond with a HelloVerifyRequest message. This message contains 412 a stateless cookie generated using the technique of [PHOTURIS]. The 413 client MUST retransmit the ClientHello with the cookie added. The 414 server then verifies the cookie and proceeds with the handshake only 415 if it is valid. 417 The exchange is shown below: 419 Client Server 420 ------ ------ 421 ClientHello ------> 423 <----- HelloVerifyRequest 424 (contains cookie) 426 ClientHello ------> 427 (with cookie) 429 [Rest of handshake] 431 DTLS therefore modifies the ClientHello message to add the cookie 432 value. 434 struct { 435 ProtocolVersion client_version; 436 Random random; 437 SessionID session_id; 438 Cookie cookie<0..32>; // New field 439 CipherSuite cipher_suites<2..2^16-1>; 440 CompressionMethod compression_methods<1..2^8-1>; 441 } ClientHello; 443 If the client does not have a cookie for a given server, it should 444 use a zero-length cookie. 446 The definition of HelloVerifyRequest is as follows: 448 struct { 449 Cookie cookie<0..32>; 450 } HelloVerifyRequest; 452 The HelloVerifyRequest message type is hello_verify_request(3). 454 When responding to a HelloVerifyRequest the client MUST use the same 455 parameter values (version, random, session_id, cipher_suites, 456 compression_method) as in the original ClientHello. The server SHOULD 457 use those values to generate its cookie and verify that they are 458 correct upon cookie receipt. 460 Although DTLS servers are not required to do a cookie exchange, they 461 SHOULD do so whenever a new handshake is performed in order to avoid 462 being used as amplifiers. If the server is being operated in an 463 environment where amplification is not a problem, the server MAY 464 choose not to perform a cookie exchange. In addition, the server MAY 466 choose not do to a cookie exchange when a session is resumed. Clients 467 MUST be prepared to do a cookie exchange with every handshake. 469 4.2.2. Handshake Message Format 471 In order to support message loss, reordering, and fragmentation DTLS 472 modifies the TLS 1.1 handshake header: 474 struct { 475 HandshakeType msg_type; 476 uint24 length; 477 uint16 message_seq; // New field 478 uint24 fragment_offset; // New field 479 uint24 fragment_length; // New field 480 select (HandshakeType) { 481 case hello_request: HelloRequest; 482 case client_hello: ClientHello; 483 case hello_verify_request: HelloVerifyRequest; // New message type 484 case server_hello: ServerHello; 485 case certificate:Certificate; 486 case server_key_exchange: ServerKeyExchange; 487 case certificate_request: CertificateRequest; 488 case server_hello_done:ServerHelloDone; 489 case certificate_verify: CertificateVerify; 490 case client_key_exchange: ClientKeyExchange; 491 case finished:Finished; 492 } body; 493 } Handshake; 495 The first message each side transmits in each handshake always has 496 message_seq = 0. Whenever each new message is generated, the 497 message_seq value is incremented by one. When a message is 498 retransmitted, the same message_seq value is used. For example. 500 Client Server 501 ------ ------ 502 ClientHello (seq=0) ------> 504 X<-- HelloVerifyRequest (seq=0) 505 (lost) 507 [Timer Expires] 509 ClientHello (seq=0) ------> 510 (retransmit) 512 <------ HelloVerifyRequest (seq=0) 514 ClientHello (seq=1) ------> 515 (with cookie) 517 <------ ServerHello (seq=1) 518 <------ Certificate (seq=2) 519 <------ ServerHelloDone (seq=3) 521 [Rest of handshake] 523 DTLS implementations maintain (at least notionally) a 524 next_receive_seq counter. This counter is initially set to zero. When 525 a message is received, if its sequence number matches 526 next_receive_seq, next_receive_seq is incremented and the message is 527 processed. If the sequence number is less than next_receive_seq the 528 message MUST be discarded. If the sequence number is greater than 529 next_receive_seq, the implementation SHOULD queue the message but MAY 530 discard it. (This is a simple space/bandwidth tradeoff). 532 4.2.3. Message Fragmentation and Reassembly 534 As noted in Section , each DTLS message MUST fit within a single 535 transport layer datagram. However, handshake messages are potentially 536 bigger than the maximum record size. Therefore DTLS provides a 537 mechanism for fragmenting a handshake message over a number of 538 records. 540 When transmitting the handshake message, the sender divides the 541 message into a series of N contiguous data ranges. These range must 542 be no larger than the maximum handshake fragment size and MUST 543 jointly contain the entire handshake message. The ranges SHOULD NOT 544 overlap. The sender then creates N handshake messages, all with the 545 same message_seq value as the original handshake message. Each new 546 message is labelled with the fragment_offset (the number of bytes 547 contained in previous fragments) and the fragment_length (the length 548 of this fragment). The length field in all messages is the same as 549 the length field of the original message. An unfragmented message is 550 a degenerate case with fragment_offset=0 and fragment_length=length. 552 When a DTLS implementation receives a handshake message fragment, it 553 MUST buffer it until it has the entire handshake message. DTLS 554 implementations MUST be able to handle overlapping fragment ranges. 555 This allows senders to retransmit handshake messages with smaller 556 fragment sizes during path MTU discovery. 558 4.2.4. Timeout and Retransmission 560 DTLS messages are grouped into a series of message flights, according 561 the diagrams below. Although each flight of messages may consist of a 563 number of messages, they should be viewed as monolithic for the 564 purpose of timeout and retransmission. 566 Client Server 567 ------ ------ 569 ClientHello --------> Flight 1 571 <------- HelloVerifyRequest Flight 2 573 ClientHello --------> Flight 3 575 ServerHello \ 576 Certificate* \ 577 ServerKeyExchange* Flight 4 578 CertificateRequest* / 579 <-------- ServerHelloDone / 581 Certificate* \ 582 ClientKeyExchange \ 583 CertificateVerify* Flight 5 584 [ChangeCipherSpec] / 585 Finished --------> / 587 [ChangeCipherSpec] \ Flight 6 588 <-------- Finished / 589 Figure 1: Message flights for full handshake 591 Client Server 592 ------ ------ 594 ClientHello --------> Flight 1 596 ServerHello \ 597 [ChangeCipherSpec] Flight 2 598 <-------- Finished / 600 [ChangeCipherSpec] \Flight 3 601 Finished --------> / 602 Figure 2: Message flights for session resuming handshake (no cookie exchange) 604 DTLS uses a simple timeout and retransmission scheme with the 605 following state machine. 607 +--------+ 608 | PREPAR | 609 +---> | -ING | 610 | | | 611 | +--------+ 612 | | 613 | | 614 | | Buffer next flight 615 | | 616 | \|/ 617 | +---------+ 618 | | | 619 | | SENDING |<--------------------+ 620 | | | | 621 | +---------+ | 622 Receive | | | 623 next | | Send flight | 624 flight | +-------+ | 625 | | | Set retransmit timer | 626 | | \|/ | 627 | | +---------+ | 628 | | | | | 629 +--)--| WAITING |---------------------+ 630 | | | | Timer expires | 631 | | +---------+ | 632 | | | | 633 | | | | 634 | | +------------------------+ 635 | | Read retransmit 636 Receive | | 637 last | | 638 flight | | 639 | | 640 \|/\|/ 642 FINISH 643 Figure 3: DTLS timeout and retransmission state machine 645 The state machine has three basic states. 647 In the PREPARING state the implementation does whatever computations 648 are necessary to prepare the next flight of messages. It then buffers 649 them up for transmission (emptying the buffer first) and enters the 650 SENDING state. 652 In the SENDING state, the implementation transmits the buffered 653 flight of messages. Once the messages have been sent, the 654 implementation then enters the FINISH state if this is the last 655 flight in the handshake, or, if the implementation expects to receive 656 more messages, sets a retransmit timer and then enters the WAITING 657 state. 659 There are three ways to exit the WAITING state: 661 1. The retransmit timer expires: the implementation transitions to 662 the SENDING state, where it retransmits the flight, resets the 663 retransmit timer, and returns to the WAITING state. 665 2. The implementation reads a retransmitted flight from the peer: 666 the implementation transitions to the SENDING state, where it 667 retransmits the flight, resets the retransmit timer, and returns 668 to the WAITING state. The rationale here is that the receipt of a 669 duplicate message is the likely result of timer expiry on the peer 670 and therefore suggests that part of one's previous flight was 671 lost. 673 3. The implementation receives the next flight of messages: if 674 this is the final flight of messages the implementation 675 transitions to FINISHED. If the implementation needs to send a new 676 flight, it transitions to the PREPARING state. Partial reads 677 (whether partial messages or only some of the messages in the 678 flight) do not cause state transitions or timer resets. 680 Because DTLS clients send the first message (ClientHello) they start 681 in the PREPARING state. DTLS servers start in the WAITING state, but 682 with empty buffers and no retransmit timer. 684 4.2.4.1. Timer Values 686 Timer value choices are a local matter. We recommend that 687 implementations use an initial timer value of 500 ms and double the 688 value at each retransmission, up to 2MSL. Implementations SHOULD 689 start the timer value at the initial value with each new flight of 690 messages. 692 4.2.5. ChangeCipherSpec 694 As with TLS, the ChangeCipherSpec message is not technically a 695 handshake message but MUST be treated as part of the same flight as 696 the associated Finished message for the purposes of timeout and 697 retransmission. 699 4.2.6. Finished messages 701 Finished messages have the same format as in TLS. However, in order 702 to remove sensitivity to fragmentation, the Finished MAC MUST be 703 computed as if each handshake message had been sent as a single 704 fragment. Note that in cases where the cookie exchange is used, the 705 initial ClientHello and HelloVerifyRequest ARE included in the 706 Finished MAC. 708 A.1 Summary of new syntax 710 This section includes specifications for the data structures that 711 have changed between TLS 1.1 and DTLS. 713 4.2. Record Layer 714 struct { 715 ContentType type; 716 ProtocolVersion version; 717 uint16 epoch; // NEW 718 uint48 sequence_number; // NEW 719 uint16 length; 720 opaque fragment[DTLSPlaintext.length]; 721 } DTLSPlaintext; 723 struct { 724 ContentType type; 725 ProtocolVersion version; 726 uint16 epoch; // NEW 727 uint48 sequence_number; // NEW 728 uint16 length; 729 opaque fragment[DTLSCompressed.length]; 730 } DTLSCompressed; 732 struct { 733 ContentType type; 734 ProtocolVersion version; 735 uint16 epoch; // NEW 736 uint48 sequence_number; // NEW 737 uint16 length; 738 select (CipherSpec.cipher_type) { 739 case block: GenericBlockCipher; 740 } fragment; 741 } DTLSCiphertext; 743 4.3. Handshake Protocol 745 enum { 746 hello_request(0), client_hello(1), server_hello(2), 747 hello_verify_request(3), // NEW 748 certificate(11), server_key_exchange (12), 749 certificate_request(13), server_hello_done(14), 750 certificate_verify(15), client_key_exchange(16), 751 finished(20), (255) 752 } HandshakeType; 754 struct { 755 HandshakeType msg_type; 756 uint24 length; 757 uint16 message_seq; // NEW 758 uint24 fragment_offset; // NEW 759 uint24 fragment_length; // NEW 760 select (HandshakeType) { 761 case hello_request: HelloRequest; 762 case client_hello: ClientHello; 763 case server_hello: ServerHello; 764 case hello_verify_request: HelloVerifyRequest; // NEW 765 case certificate:Certificate; 766 case server_key_exchange: ServerKeyExchange; 767 case certificate_request: CertificateRequest; 768 case server_hello_done:ServerHelloDone; 769 case certificate_verify: CertificateVerify; 770 case client_key_exchange: ClientKeyExchange; 771 case finished:Finished; 772 } body; 773 } Handshake; 775 struct { 776 Cookie cookie; 777 } HelloVerifyRequest; 779 5. Security Considerations 781 This document describes a variant of TLS 1.1 and therefore most of 782 the security considerations are the same as TLS 1.1. 784 The primary additional security consideration raised by DTLS is that 785 of denial of service. DTLS includes a cookie exchange designed to 786 protect against denial of service. However, implementations which do 787 not use this cookie exchange are still vulnerable to DoS. In 788 particular, DTLS servers which do not use the cookie exchange may be 789 used as attack amplifiers even if they themselves are not 790 experiencing DoS. Therefore DTLS servers SHOULD use the cookie 792 exchange unless there is good reason to believe that amplification is 793 not a threat in their environment. 795 6. IANA Considerations 797 This document uses the same identifier space as does TLS [TLS11], so 798 no IANA registries are required beyond those for TLS. Identifiers MAY 799 NOT be assigned for DTLS that conflict with TLS. 801 References 803 Normative References 805 [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management 806 Protocol", RFC 2521, March 1999. 808 [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", 809 RFC 1191, November 1990. 811 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 812 Internet Protocol", RFC2401, November 1998. 814 [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 815 RFC 2246, January 1999. 817 [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 818 draft-ietf-tls-rfc2246-bis-05.txt, July 2003. 820 Informative References 822 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", 823 RFC 2402, November 1998. 825 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 826 Congestion Control Protocol", draft-ietf-dccp-spec-05.txt, 827 October 2003 829 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 830 of Datagram TLS", in Proceedings of ISOC NDSS 2004, 831 February 2004. 833 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 834 Payload (ESP)", RFC 2406, November 1998. 836 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 837 RFC 2409, November 1998. 839 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 840 4rev1", RFC 3501, March 2003. 842 [POP] Myers, J., and Rose, M., "Post Office Protocol - 843 Version 3", RFC 1939, May 1996. 845 [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., 846 Peterson, J., Sparks, R., Handley, M., Schooler, E., 847 "SIP: Session Initiation Protocol", RFC 3261, 848 June 2002. 850 [TCP] Postel, J., "Transmission Control Protocol", 851 RFC 793, September 1981. 853 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 854 draft-bellovin-useipsec-02.txt, October 2003 856 Authors' Address 858 Eric Rescorla 859 RTFM, Inc. 860 2064 Edgewood Drive 861 Palo Alto, CA 94303 863 Nagendra Modadugu 864 Computer Science Department 865 353 Serra Mall 866 Stanford University 867 Stanford, CA 94305 869 Acknowledgements 871 The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine 872 Sapuntzakis, and Hovav Shacham for discussions and comments on the 873 design of DTLS. Thanks to the anonymous NDSS reviewers of our 874 original NDSS paper on DTLS [DTLS] for their comments. Also, thanks 875 to Steve Kent for feedback that helped clarify many points. The 876 section on PMTU was cribbed from the DCCP specification [DCCP]. 878 Full Copyright Statement 880 The IETF takes no position regarding the validity or scope of any 881 Intellectual Property Rights or other rights that might be claimed to 882 pertain to the implementation or use of the technology described in 883 this document or the extent to which any license under such rights 884 might or might not be available; nor does it represent that it has 885 made any independent effort to identify any such rights. Information 886 on the procedures with respect to rights in RFC documents can be 887 found in BCP 78 and BCP 79. 889 Copies of IPR disclosures made to the IETF Secretariat and any 890 assurances of licenses to be made available, or the result of an 891 attempt made to obtain a general license or permission for the use of 892 such proprietary rights by implementers or users of this 893 specification can be obtained from the IETF on-line IPR repository at 894 http://www.ietf.org/ipr. 896 The IETF invites any interested party to bring to its attention any 897 copyrights, patents or patent applications, or other proprietary 898 rights that may cover technology that may be required to implement 899 this standard. Please address the information to the IETF at ietf- 900 ipr@ietf.org. 902 Copyright Notice 903 Copyright (C) The Internet Society (2003). This document is subject 904 to the rights, licenses and restrictions contained in BCP 78, and 905 except as set forth therein, the authors retain all their rights. 907 This document and the information contained herein are provided on an 908 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 909 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 910 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 911 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 912 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 913 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.