idnits 2.17.1 draft-ietf-dccp-dtls-05.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 438. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (February 6, 2008) is 5896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT DTLS over DCCP February 6, 2008 4 DTLS over DCCP 5 Internet Draft T. Phelan 6 Document: draft-ietf-dccp-dtls-05.txt Sonus Networks 7 Expires: August 2008 February 6, 2008 8 Intended status: Proposed Standard 10 Datagram Transport Layer Security (DTLS) over the Datagram 11 Congestion Control Protocol (DCCP) 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 6, 2008. 38 Abstract 40 This document specifies the use of Datagram Transport Layer Security 41 (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS 42 provides communications privacy for datagram protocols and allows 43 client/server applications to communicate in a way that is designed 44 to prevent eavesdropping, tampering, or message forgery. DCCP is a 45 transport protocol that provides a congestion-controlled unreliable 46 datagram service. 48 Table of Contents 50 1. Introduction...................................................3 51 2. Terminology....................................................3 52 3. DTLS over DCCP.................................................3 53 3.1 DCCP and DTLS Sequence Numbers.............................3 54 3.2 DCCP and DTLS Connection Handshakes........................4 55 3.3 Effects of DCCP Congestion Control.........................5 56 3.4 DTLS Sessions and DCCP Connections.........................6 57 3.5 PMTU Discovery.............................................7 58 3.6 DCCP Service Codes.........................................8 59 3.7 New Versions of DTLS.......................................8 60 4. Security Considerations........................................8 61 5. IANA Considerations............................................9 62 6. Acknowledgments................................................9 63 7. References.....................................................9 64 7.1 Normative References.......................................9 65 7.2 Informative References.....................................9 66 8. Author's Address...............................................9 67 1. Introduction 69 This document specifies how to use Datagram Transport Layer Security 70 (DTLS), as specified in [RFC4347], over the Datagram Congestion 71 Control Protocol (DCCP), as specified in [RFC4340]. 73 DTLS is an extension of Transport Layer Security (TLS, [RFC4346]) 74 that modifies TLS for use with the unreliable transport protocol UDP. 75 TLS is a protocol that allows client/server applications to 76 communicate in a way that is designed to prevent eavesdropping, 77 tampering and message forgery. DTLS can be viewed as TLS-plus- 78 adaptations-for-unreliability. 80 DCCP provides an unreliable transport service, similar to UDP, but 81 with adaptive congestion control, similar to TCP and SCTP. DCCP can 82 be viewed equally well as either UDP-plus-congestion-control or TCP- 83 minus-reliability (although, unlike TCP, DCCP offers multiple 84 congestion control algorithms). 86 The combination of DTLS and DCCP will offer transport security 87 capabilities to DCCP users similar to those available for TCP, UDP 88 and SCTP. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. DTLS over DCCP 98 The approach here is very straightforward -- DTLS records are 99 transmitted in the Application Data fields of DCCP-Data and DCCP- 100 DataAck packets (in the rest of the document assume that "DCCP-Data 101 packet" means "DCCP-Data or DCCP-DataAck packet"). Multiple DTLS 102 records MAY be sent in one DCCP-Data packet, as long as the resulting 103 packet is within the Path Maximum Transfer Unit (PMTU) currently in 104 force for normal data packets, if the Don't Fragment (DF) bit is 105 being used, or within the current DCCP maximum packet size if the DF 106 bit is not being used (see section 3.5 for more information on PMTU 107 Discovery). A single DTLS record MUST be fully contained in a single 108 DCCP-Data packet; it MUST NOT be split over multiple packets. 110 3.1 DCCP and DTLS Sequence Numbers 112 Both DCCP and DTLS use sequence numbers in their packets/records. 113 These sequence numbers serve somewhat, but not completely, 114 overlapping functions. Consequently, there is no connection between 115 the sequence number of a DCCP packet and the sequence number in a 116 DTLS record contained in that packet and no connection between 117 sequence number-related features such as DCCP synchronization and 118 DTLS anti-replay protection. 120 3.2 DCCP and DTLS Connection Handshakes 122 Unlike UDP, DCCP is connection-oriented, and has a connection 123 handshake procedure that precedes the transmission of DCCP-Data and 124 DCCP-DataAck packets. DTLS is also connection-oriented, and has a 125 handshake procedure of its own that must precede the transmission of 126 actual application information. Using the rule of mapping DTLS 127 records to DCCP-Data and DCCP-DataAck packets in section 3, above, 128 the two handshakes are forced to happen in series, with the DCCP 129 handshake first, followed by the DTLS handshake. This is how TLS 130 over TCP works. 132 However, the DCCP handshake packets DCCP-Request and DCCP-Response 133 have Application Data fields and can carry user data during the DCCP 134 handshake, and this creates the opportunity to perform the handshakes 135 partially in parallel. DTLS client implementations MAY choose to 136 transmit the ClientHello message in the DCCP-Request packet. DTLS 137 server implementations MAY choose to respond to a ClientHello message 138 received in a DCCP-Request packet with a HelloVerifyRequest message, 139 if denial of service countermeasures are to be used, or a ServerHello 140 message otherwise, in the DCCP-Response packet. DTLS servers MAY 141 also choose to delay the response until the handshake completes and 142 then send the response in a DCCP-Data packet. 144 DTLS handshake messages can be quite large, theoretically up to 2^24- 145 1 bytes and in practice often many kilobytes. Subsequently, unlike 146 other DTLS messages, the handshake messages may be fragmented over 147 multiple DTLS records. If the size of the ClientHello is too large 148 to transmit in its entirety in a DCCP-Request packet the ClientHello 149 MUST be sent in DCCP-Data packets after the DCCP handshake is 150 complete. Similarly, if the server response to a ClientHello is too 151 large to transmit in its entirety in a DCCP-Response packet, it MUST 152 be sent in DCCP-Data packets after the DCCP handshake is complete. 154 Transmission of subsequent DTLS handshake messages MUST wait for the 155 completion of the DCCP handshake and use DCCP-Data packets. 157 Note that even though the DCCP handshake is a reliable process 158 (handshake messages are retransmitted as required if messages are 159 lost), the transfer of Application Data in DCCP-Request and DCCP- 160 Response packets is not necessarily reliable. For example, DCCP 161 server implementations are free to discard Application Data received 162 in DCCP-Request packets. And if DCCP-Request or DCCP-Response 163 packets need to be retransmitted, the DCCP implementation may choose 164 to not include the Application Data present in the initial message. 166 Since the DTLS handshake is also a reliable process, it will 167 interoperate across the data delivery unreliability of DCCP (after 168 all, one of the basic functions of DTLS is to work over unreliable 169 transport). If ClientHello messages or the HelloVerifyRequest or 170 ServerHello messages are lost, the ClientHello message will be 171 retransmitted by DTLS. 173 This is regardless of whether the messages were sent in DCCP- 174 Response/Request packets or DCCP-Data packets. However, the only way 175 for DTLS to retransmit a ClientHello message that was originally 176 transmitted in a DCCP-Request packet (and it or the response was lost 177 somehow) is to wait for the DCCP handshake to complete and then send 178 the ClientHello in a DCCP-Data packet. This is due to the 179 characteristic of DCCP that the next opportunity to send data after 180 sending data in a DCCP-Request is only after the connection handshake 181 completes. 183 DCCP and DTLS use similar strategies for retransmitting handshake 184 messages. If there is no response to the original request (DCCP- 185 Request or ClientHello respectively) within normally 1 second, the 186 message is retransmitted. The timer is then doubled and the process 187 repeated until a response is received, or a maximum time is exceeded. 189 Therefore, if the ClientHello message is sent in a DCCP-Request 190 packet, and the DCCP-Request or DCCP-Response message is lost, the 191 DCCP and DTLS handshakes could be timing out on similar schedules. 192 The DCCP-Request packets will be retransmitted on timeout, but the 193 ClientHello packet cannot be retransmitted until the DCCP handshake 194 completes (there is no possibility of adding new Application Data to 195 a DCCP-Request retransmission). In order to avoid multiple 196 retransmissions queuing up before the first retransmission can be 197 sent, DTLS over DCCP MUST wait until the completion of the DCCP 198 handshake before restarting its DTLS handshake retransmission timer. 200 3.3 Effects of DCCP Congestion Control 202 Given the large potential sizes of the DTLS handshake messages, it is 203 possible that DCCP congestion control could throttle the transmission 204 of the DTLS handshake to the point that the transfer cannot complete 205 before the DTLS timeout and retransmission procedures take effect. 206 Adding retransmitted messages to a congested situation might only 207 make matters worse and delay connection establishment. 209 Note that a DTLS over UDP application transmitting handshake data 210 into this same network situation will not necessarily receive better 211 throughput, and might actually see worse effective throughput. 212 Without the pacing of slow-start and congestion control, a UDP 213 application might be making congestion worse and lowering the 214 effective throughput it receives. 216 As stated in [RFC4347], "mishandling of the [retransmission] timer 217 can lead to serious congestion problems". This remains as true for 218 DTLS over DCCP as it is for DTLS over UDP. 220 DTLS over DCCP implementations SHOULD take steps to avoid 221 retransmitting a request that has been queued but not yet actually 222 transmitted by DCCP, when the underlying DCCP implementation can 223 provide this information. For example, DTLS could delay starting the 224 retransmission timer until DCCP indicates the message has been 225 transferred from DCCP to the IP layer. 227 In addition to the retransmission issues, if the throughput needs of 228 the actual application data differ from the needs of the DTLS 229 handshake, it is possible that the handshake transference could leave 230 the DCCP congestion control in a state that is not immediately 231 suitable for the application data that will follow. For example, 232 DCCP CCID 2 ([RFC4341]) congestion control uses an Additive Increase 233 Multiplicative Decrease (AIMD) algorithm similar to TCP congestion 234 control. If it is used then it is possible that transference of a 235 large handshake could cause a multiplicative decrease that would not 236 have happened with the application data. The application might then 237 be throttled while waiting for additive increase to return throughput 238 to acceptable levels. 240 Applications where this might be a problem should consider using DCCP 241 CCID 3 ([RFC4342]). CCID 3 implements TCP-Friendly Rate Control 242 (TFRC, [RFC3448])). TFRC varies the allowed throughput more slowly 243 than AIMD and might avoid the discontinuities possible with CCID 2. 245 3.4 DTLS Sessions and DCCP Connections 247 There is no necessary relationship between the life of a DTLS session 248 and the life of a DCCP connection. Often the session and connection 249 lives start and stop together (DCCP connection establishment 250 immediately followed by DTLS session establishment, DTLS session 251 termination immediately followed by DCCP connection termination), but 252 this is not the only possibility. 254 A single DTLS session may span multiple DCCP connections using the 255 DTLS session resumption features. The session resumption feature of 256 DTLS is widely used and this situation is likely to occur frequently. 257 It is even possible to resume a DTLS session over a different 258 transport. 260 DCCP cannot differentiate different types of application data sent 261 over a DCCP connection. If the application performs appropriate 262 multiplexing, a DCCP connection could conceivable contain both DTLS 263 and non-DTLS data in parallel or series, or several different DTLS 264 sessions in series. However, multiple DTLS sessions cannot be 265 carried in parallel over the same DCCP connection since [RFC4347] 266 provides no way to demultiplex the different associations. 268 A special case of this DCCP connection flexibility is an application 269 that starts up transferring non-DTLS data, and then switches to DTLS 270 after some time. This is likely to be useful and has implications 271 for the choice of DCCP Service Code. See section 3.6 for more 272 information on this. 274 3.5 PMTU Discovery 276 Each DTLS record must fit within a single DCCP-Data packet. DCCP 277 packets are normally transmitted with the DF (Don't Fragment) bit set 278 for IPv4 (or without fragmentation extension headers for IPv6). 279 Because of this, DCCP performs Path Maximum Transmission Unit (PMTU) 280 Discovery. 282 DTLS also normally uses the DF bit and performs PMTU Discovery on its 283 own, using an algorithm that is strongly similar to the one used by 284 DCCP. A DTLS over DCCP implementation MAY use the DCCP-managed value 285 for PMTU and not perform PMTU Discovery on its own. However, 286 implementations that choose to use the DCCP-managed PMTU value SHOULD 287 continue to follow the procedures of [RFC4347] section 4.1.1.1 with 288 regard to fragmenting handshake messages during handshake 289 retransmissions. Alternatively, a DTLS over DCCP implementation MAY 290 choose to use its own PMTU Discovery calculations, as specified in 291 [RFC4347], but MUST NOT use a value greater than the value determined 292 by DCCP. 294 DTLS implementations normally allow applications to reset the PMTU 295 estimate back to the initial state. When that happens, DTLS over 296 DCCP implementations SHOULD also reset the DCCP PMTU estimation. 298 DTLS implementations also sometimes allow applications to control the 299 use of the DF bit (when running over IPv4) or the use of 300 fragmentation extension headers (when running of IPv6). DTLS over 301 DCCP implementations SHOULD control the use of the DF bit or 302 fragmentation extension headers by DCCP in concert with the 303 application's indications, when the DCCP implementation supports 304 this. Note that DCCP implementations are not required to support 305 sending fragmentable packets. 307 Note that the DCCP Maximum Packet Size (MPS in [RFC4340]) is bounded 308 by the current congestion control state (Congestion Control Maximum 309 Packet Size, CCMPS in [RFC4340]). Even when the DF bit is not set 310 and DCCP packets may then be fragmented, the MPS may be less than the 311 65,535 bytes normally used in UDP. It is also possible for the DCCP 312 CMPS, and thus the MPS, to vary over time as congestion conditions 313 change. DTLS over DCCP implementations MUST NOT use a DTLS record 314 size that is greater than the DCCP MPS currently in force. 316 3.6 DCCP Service Codes 318 The DCCP connection handshake includes a field called Service Code 319 that is intended to describe "the application-level service to which 320 the client application wants to connect". Further, "Service Codes 321 are intended to provide information about which application protocol 322 a connection intends to use, thus aiding middleboxes and reducing 323 reliance on globally well-known ports" [RFC4340]. 325 It is expected that many middleboxes will give different privileges 326 to applications running DTLS over DCCP versus just DCCP. Therefore, 327 applications that use DTLS over DCCP sometimes and just DCCP other 328 times SHOULD register and use different Service Codes for each mode 329 of operation. Applications that use both DCCP and DTLS over DCCP MAY 330 choose to listen for incoming connections on the same DCCP port and 331 distinguish the mode of the request by the offered Service Code. 333 Some applications may start out using DCCP without DTLS, and then 334 optionally switch to using DTLS over the same connection. Since 335 there is no way to change the Service Code for a connection after it 336 is established, these applications will use one Service Code. 338 3.7 New Versions of DTLS 340 As DTLS matures, revisions to and updates for [RFC4347] can be 341 expected. DTLS includes mechanisms for identifying the version in 342 use and presumably future versions will either include backward 343 compatibility modes or at least not allow connections between 344 dissimilar versions. Since DTLS over DCCP simply encapsulates the 345 DTLS records transparently, these changes should not affect this 346 document and the methods of this document should apply to future 347 versions of DTLS. 349 Therefore, in the absence of a revision to this document, this 350 document is assumed to apply to all future versions of DTLS. This 351 document will only be revised if a revision to DTLS makes a revision 352 to the encapsulation necessary. 354 It is RECOMMENDED that an application migrating to a new version of 355 DTLS keep the same DCCP Service Code used for the old version and 356 allow DTLS to provide the version negotiation support. If a new 357 version of DTLS provides significant new capabilities to the 358 application that could change the behavior of middleboxes with regard 359 to the application, an application developer MAY register a new 360 Service Code. 362 4. Security Considerations 364 Security considerations for DTLS are specified in [RFC4347] and for 365 DCCP in [RFC4340]. The combination of DTLS and DCCP introduces no 366 new security considerations. 368 5. IANA Considerations 370 There are no IANA actions required for this document. 372 6. Acknowledgments 374 The author would like to thank Eric Rescorla for initial guidance on 375 adapting DTLS to DCCP, and Gorry Fairhurst, Pasi Eronen, Colin 376 Perkins, Lars Eggert, Magnus Westerlund and Tom Petch for comments on 377 the document. 379 7. References 381 7.1 Normative References 383 [RFC4347] Rescorla, E., Modadugu, N. "Datagram Transport Layer 384 Security", RFC 4347, April 2006. 386 [RFC4340] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion 387 Control Protocol (DCCP)", RFC 4340, March 2006. 389 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 390 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", RFC 2119, March 1997. 395 7.2 Informative References 397 [RFC4341] Floyd, S., Kohler, E., "Profile for Datagram Congestion 398 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 399 Congestion Control", RFC 4341, March 2006. 400 [RFC4342] Floyd, S., Kohler, E., Padhye, J., " Profile for Datagram 401 Congestion Control Protocol (DCCP) Congestion Control ID 402 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 403 2006. 404 [RFC3448] Handley, M., Floyd, S., Padhye, J., Widmer, J., " TCP 405 Friendly Rate Control (TFRC): Protocol Specification", 406 RFC 3448, January 2003. 408 8. Author's Address 410 Tom Phelan 411 Sonus Networks 412 7 Technology Park Dr. 413 Westford, MA USA 01886 414 Phone: 978-614-8456 415 Email: tphelan@sonusnet.com 416 Intellectual Property Statement 418 The IETF takes no position regarding the validity or scope of any 419 Intellectual Property Rights or other rights that might be claimed to 420 pertain to the implementation or use of the technology described in 421 this document or the extent to which any license under such rights 422 might or might not be available; nor does it represent that it has 423 made any independent effort to identify any such rights. Information 424 on the procedures with respect to rights in RFC documents can be 425 found in BCP 78 and BCP 79. 427 Copies of IPR disclosures made to the IETF Secretariat and any 428 assurances of licenses to be made available, or the result of an 429 attempt made to obtain a general license or permission for the use of 430 such proprietary rights by implementers or users of this 431 specification can be obtained from the IETF on-line IPR repository at 432 http://www.ietf.org/ipr. 434 The IETF invites any interested party to bring to its attention any 435 copyrights, patents or patent applications, or other proprietary 436 rights that may cover technology that may be required to implement 437 this standard. Please address the information to the IETF at ietf- 438 ipr@ietf.org. 440 Disclaimer of Validity 442 This document and the information contained herein are provided on an 443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 445 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 446 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 447 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 448 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 450 Copyright Statement 452 Copyright (C) The IETF Trust (2008). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 Acknowledgment 460 Funding for the RFC Editor function is currently provided by the 461 Internet Society.