idnits 2.17.1 draft-ietf-dccp-dtls-06.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 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. 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 (April 14, 2008) is 5849 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 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) -- 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 April 14, 2008 4 DTLS over DCCP 5 Internet Draft T. Phelan 6 Document: draft-ietf-dccp-dtls-06.txt Sonus Networks 7 Expires: October 2008 April 14, 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 and detect tampering or message forgery. 45 DCCP is a transport protocol that provides a congestion-controlled 46 unreliable 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 Relationships Between DTLS Sessions/Connections and DCCP 57 Connections....................................................6 58 3.5 PMTU Discovery.............................................7 59 3.6 DCCP Service Codes.........................................8 60 3.7 New Versions of DTLS.......................................8 61 4. Security Considerations........................................9 62 5. IANA Considerations............................................9 63 6. Acknowledgments................................................9 64 7. References.....................................................9 65 7.1 Normative References.......................................9 66 7.2 Informative References.....................................9 67 8. Author's Address..............................................10 68 1. Introduction 70 This document specifies how to use Datagram Transport Layer Security 71 (DTLS), as specified in [RFC4347], over the Datagram Congestion 72 Control Protocol (DCCP), as specified in [RFC4340]. 74 DTLS is an adaptation of Transport Layer Security (TLS, [RFC4346]) 75 that modifies TLS for use with the unreliable transport protocol UDP. 76 TLS is a protocol that allows client/server applications to 77 communicate in a way that is designed to prevent eavesdropping and 78 detect tampering and message forgery. DTLS can be viewed as TLS- 79 plus-adaptations-for-unreliability. 81 DCCP provides an unreliable transport service, similar to UDP, but 82 with adaptive congestion control, similar to TCP and SCTP. DCCP can 83 be viewed equally well as either UDP-plus-congestion-control or TCP- 84 minus-reliability (although, unlike TCP, DCCP offers multiple 85 congestion control algorithms). 87 The combination of DTLS and DCCP will offer transport security 88 capabilities to DCCP users similar to those available for TCP, UDP 89 and SCTP. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. DTLS over DCCP 99 The approach here is very straightforward -- DTLS records are 100 transmitted in the Application Data fields of DCCP-Data and DCCP- 101 DataAck packets (in the rest of the document assume that "DCCP-Data 102 packet" means "DCCP-Data or DCCP-DataAck packet"). Multiple DTLS 103 records MAY be sent in one DCCP-Data packet, as long as the resulting 104 packet is within the Path Maximum Transfer Unit (PMTU) currently in 105 force for normal data packets, if the Don't Fragment (DF) bit is 106 being used, or within the current DCCP maximum packet size if the DF 107 bit is not being used (see section 3.5 for more information on PMTU 108 Discovery). A single DTLS record MUST be fully contained in a single 109 DCCP-Data packet; it MUST NOT be split over multiple packets. 111 3.1 DCCP and DTLS Sequence Numbers 113 Both DCCP and DTLS use sequence numbers in their packets/records. 114 These sequence numbers serve somewhat, but not completely, 115 overlapping functions. Consequently, there is no connection between 116 the sequence number of a DCCP packet and the sequence number in a 117 DTLS record contained in that packet and no connection between 118 sequence number-related features such as DCCP synchronization and 119 DTLS anti-replay protection. 121 3.2 DCCP and DTLS Connection Handshakes 123 Unlike UDP, DCCP is connection-oriented, and has a connection 124 handshake procedure that precedes the transmission of DCCP-Data and 125 DCCP-DataAck packets. DTLS is also connection-oriented, and has a 126 handshake procedure of its own that must precede the transmission of 127 actual application information. Using the rule of mapping DTLS 128 records to DCCP-Data and DCCP-DataAck packets in section 3, above, 129 the two handshakes are forced to happen in series, with the DCCP 130 handshake first, followed by the DTLS handshake. This is how TLS 131 over TCP works. 133 However, the DCCP handshake packets DCCP-Request and DCCP-Response 134 have Application Data fields and can carry user data during the DCCP 135 handshake, and this creates the opportunity to perform the handshakes 136 partially in parallel. DTLS client implementations MAY choose to 137 transmit one or more DTLS records (typically containing DTLS 138 handshake messages or parts of them) in the DCCP-Request packet. A 139 DTLS server implementation MAY choose to process these records as 140 usual, and if it has one or more DTLS records to send as a response 141 (typically containing DTLS handshake messages or parts of them), it 142 MAY include those records in the DCCP-Response packet. DTLS servers 143 MAY also choose to delay the response until the DCCP handshake 144 completes and then send the DTLS response in a DCCP-Data packet. 146 Note that even though the DCCP handshake is a reliable process (DCCP 147 handshake messages are retransmitted as required if messages are 148 lost), the transfer of Application Data in DCCP-Request and DCCP- 149 Response packets is not necessarily reliable. For example, DCCP 150 server implementations are free to discard Application Data received 151 in DCCP-Request packets. And if DCCP-Request or DCCP-Response 152 packets need to be retransmitted, the DCCP implementation may choose 153 to not include the Application Data present in the initial message. 155 Since the DTLS handshake is also a reliable process, it will 156 interoperate across the data delivery unreliability of DCCP (after 157 all, one of the basic functions of DTLS is to work over unreliable 158 transport). If the DTLS records containing DTLS handshake messages 159 are lost, they will be retransmitted by DTLS. 161 This is regardless of whether the messages were sent in DCCP- 162 Response/Request packets or DCCP-Data packets. However, the only way 163 for DTLS to retransmit DTLS records that were originally transmitted 164 in DCCP-Request/Response packets (and they or the responses were lost 165 somehow) is to wait for the DCCP handshake to complete and then 166 resend the records in DCCP-Data packets. This is due to the 167 characteristic of DCCP that the next opportunity to send data after 168 sending data in a DCCP-Request is only after the connection handshake 169 completes. 171 DCCP and DTLS use similar strategies for retransmitting handshake 172 messages. If there is no response to the original request (DCCP- 173 Request or any DTLS handshake message where a response is expected) 174 within normally 1 second, the message is retransmitted. The timer is 175 then doubled and the process repeated until a response is received, 176 or a maximum time is exceeded. 178 Therefore, if DTLS records are sent in a DCCP-Request packet, and the 179 DCCP-Request or DCCP-Response message is lost, the DCCP and DTLS 180 handshakes could be timing out on similar schedules. The DCCP- 181 Request packets will be retransmitted on timeout, but the DTLS 182 records cannot be retransmitted until the DCCP handshake completes 183 (there is no possibility of adding new Application Data to a DCCP- 184 Request retransmission). In order to avoid multiple DTLS 185 retransmissions queuing up before the first retransmission can be 186 sent, DTLS over DCCP MUST wait until the completion of the DCCP 187 handshake before restarting its DTLS handshake retransmission timer. 189 3.3 Effects of DCCP Congestion Control 191 Given the large potential sizes of the DTLS handshake messages, it is 192 possible that DCCP congestion control could throttle the transmission 193 of the DTLS handshake to the point that the transfer cannot complete 194 before the DTLS timeout and retransmission procedures take effect. 195 Adding retransmitted messages to a congested situation might only 196 make matters worse and delay connection establishment. 198 Note that a DTLS over UDP application transmitting handshake data 199 into this same network situation will not necessarily receive better 200 throughput, and might actually see worse effective throughput. 201 Without the pacing of slow-start and congestion control, a UDP 202 application might be making congestion worse and lowering the 203 effective throughput it receives. 205 As stated in [RFC4347], "mishandling of the [retransmission] timer 206 can lead to serious congestion problems". This remains as true for 207 DTLS over DCCP as it is for DTLS over UDP. 209 DTLS over DCCP implementations SHOULD take steps to avoid 210 retransmitting a request that has been queued but not yet actually 211 transmitted by DCCP, when the underlying DCCP implementation can 212 provide this information. For example, DTLS could delay starting the 213 retransmission timer until DCCP indicates the message has been 214 transferred from DCCP to the IP layer. 216 In addition to the retransmission issues, if the throughput needs of 217 the actual application data differ from the needs of the DTLS 218 handshake, it is possible that the handshake transference could leave 219 the DCCP congestion control in a state that is not immediately 220 suitable for the application data that will follow. For example, 221 DCCP CCID 2 ([RFC4341]) congestion control uses an Additive Increase 222 Multiplicative Decrease (AIMD) algorithm similar to TCP congestion 223 control. If it is used then it is possible that transference of a 224 large handshake could cause a multiplicative decrease that would not 225 have happened with the application data. The application might then 226 be throttled while waiting for additive increase to return throughput 227 to acceptable levels. 229 Applications where this might be a problem should consider using DCCP 230 CCID 3 ([RFC4342]). CCID 3 implements TCP-Friendly Rate Control 231 (TFRC, [RFC3448])). TFRC varies the allowed throughput more slowly 232 than AIMD and might avoid the discontinuities possible with CCID 2. 234 3.4 Relationships Between DTLS Sessions/Connections and DCCP Connections 236 DTLS uses the concepts of sessions and connections. A DTLS 237 connection is used by upper-layer endpoints to exchange data over a 238 transport protocol. DTLS sessions contain cached state information 239 that is used to reduce the number of roundtrips and computation 240 required to create multiple DTLS connections between the same 241 endpoints. 243 In DCCP over DTLS, a DTLS connection is carried by a DCCP connection. 244 Often the DCCP connection establishment is immediately followed by 245 DTLS connection establishment (either creating a new DTLS session 246 with full handshake, or resuming an existing DTLS session) and the 247 DTLS connection termination is immediately followed by DCCP 248 connection termination, but this is not the only possibility. 250 The life of a DTLS over DCCP connection is completely contained 251 within the life of the underlying DCCP connection; a DTLS connection 252 cannot continue if its underlying DCCP connection terminates. 253 However, multiple DTLS connections can be resumed from the same DTLS 254 session, each running over its own DCCP connection. The session 255 resumption features of DTLS are widely used and this situation is 256 likely to occur in many use cases. It is also possible to resume a 257 DTLS session with a new DTLS connection running over a different 258 transport. 260 Note that it is possible for an application to start a DCCP 261 connection by transferring unprotected packets, and then switch to 262 DTLS after some time. This is likely to be useful for applications 263 that would like negotiate using DTLS or not and has implications for 264 the choice of DCCP Service Code. See section 3.6 for more 265 information on this. 267 Many DTLS Application Programming Interfaces (APIs) do not prevent an 268 application from sending a mix of encrypted and clear packets over 269 the same transport connection. Applications MUST NOT send 270 unprotected data on a DCCP connection while it is also carrying a 271 DTLS connection, since this presents a vulnerability to packet 272 insertion attacks. 274 Many DTLS APIs also allow an application to start multiple DTLS 275 connections over one transport connection in series, with the 276 termination of one DTLS connection followed the start of another. 277 Processing a DTLS handshake is relatively CPU intensive. An 278 application that uses this strategy is open to an attacker that 279 repeatedly starts and immediately stops sessions. Therefore 280 applications that use this strategy SHOULD limit the potential burden 281 on the system by some means. For example, the application could 282 enforce a minimum time of 1 second between session initiations. 284 3.5 PMTU Discovery 286 Each DTLS record must fit within a single DCCP-Data packet. DCCP 287 packets are normally transmitted with the DF (Don't Fragment) bit set 288 for IPv4 (or without fragmentation extension headers for IPv6). 289 Because of this, DCCP performs Path Maximum Transmission Unit (PMTU) 290 Discovery. 292 DTLS also normally uses the DF bit and performs PMTU Discovery on its 293 own, using an algorithm that is strongly similar to the one used by 294 DCCP. A DTLS over DCCP implementation MAY use the DCCP-managed value 295 for PMTU and not perform PMTU Discovery on its own. However, 296 implementations that choose to use the DCCP-managed PMTU value SHOULD 297 continue to follow the procedures of [RFC4347] section 4.1.1.1 with 298 regard to fragmenting handshake messages during handshake 299 retransmissions. Alternatively, a DTLS over DCCP implementation MAY 300 choose to use its own PMTU Discovery calculations, as specified in 301 [RFC4347], but MUST NOT use a value greater than the value determined 302 by DCCP. 304 DTLS implementations normally allow applications to reset the PMTU 305 estimate back to the initial state. When that happens, DTLS over 306 DCCP implementations SHOULD also reset the DCCP PMTU estimation. 308 DTLS implementations also sometimes allow applications to control the 309 use of the DF bit (when running over IPv4) or the use of 310 fragmentation extension headers (when running over IPv6). DTLS over 311 DCCP implementations SHOULD control the use of the DF bit or 312 fragmentation extension headers by DCCP in concert with the 313 application's indications, when the DCCP implementation supports 314 this. Note that DCCP implementations are not required to support 315 sending fragmentable packets. 317 Note that the DCCP Maximum Packet Size (MPS in [RFC4340]) is bounded 318 by the current congestion control state (Congestion Control Maximum 319 Packet Size, CCMPS in [RFC4340]). Even when the DF bit is not set 320 and DCCP packets may then be fragmented, the MPS may be less than the 321 65,535 bytes normally used in UDP. It is also possible for the DCCP 322 CCMPS, and thus the MPS, to vary over time as congestion conditions 323 change. DTLS over DCCP implementations MUST NOT use a DTLS record 324 size that is greater than the DCCP MPS currently in force. 326 3.6 DCCP Service Codes 328 The DCCP connection handshake includes a field called Service Code 329 that is intended to describe "the application-level service to which 330 the client application wants to connect". Further, "Service Codes 331 are intended to provide information about which application protocol 332 a connection intends to use, thus aiding middleboxes and reducing 333 reliance on globally well-known ports" [RFC4340]. 335 It is expected that many middleboxes will give different privileges 336 to applications running DTLS over DCCP versus just DCCP. Therefore, 337 applications that use DTLS over DCCP sometimes and just DCCP other 338 times SHOULD register and use different Service Codes for each mode 339 of operation. Applications that use both DCCP and DTLS over DCCP MAY 340 choose to listen for incoming connections on the same DCCP port and 341 distinguish the mode of the request by the offered Service Code. 343 Some applications may start out using DCCP without DTLS, and then 344 optionally switch to using DTLS over the same connection. Since 345 there is no way to change the Service Code for a connection after it 346 is established, these applications will use one Service Code. 348 3.7 New Versions of DTLS 350 As DTLS matures, revisions to and updates for [RFC4347] can be 351 expected. DTLS includes mechanisms for identifying the version in 352 use and presumably future versions will either include backward 353 compatibility modes or at least not allow connections between 354 dissimilar versions. Since DTLS over DCCP simply encapsulates the 355 DTLS records transparently, these changes should not affect this 356 document and the methods of this document should apply to future 357 versions of DTLS. 359 Therefore, in the absence of a revision to this document, this 360 document is assumed to apply to all future versions of DTLS. This 361 document will only be revised if a revision to DTLS or DCCP 362 (including its related CCIDs) makes a revision to the encapsulation 363 necessary. 365 It is RECOMMENDED that an application migrating to a new version of 366 DTLS keep the same DCCP Service Code used for the old version and 367 allow DTLS to provide the version negotiation support. If a new 368 version of DTLS provides significant new capabilities to the 369 application that could change the behavior of middleboxes with regard 370 to the application, an application developer MAY register a new 371 Service Code. 373 4. Security Considerations 375 Security considerations for DTLS are specified in [RFC4347] and for 376 DCCP in [RFC4340]. The combination of DTLS and DCCP introduces no 377 new security considerations. 379 5. IANA Considerations 381 There are no IANA actions required for this document. 383 6. Acknowledgments 385 The author would like to thank Eric Rescorla for initial guidance on 386 adapting DTLS to DCCP, and Gorry Fairhurst, Pasi Eronen, Colin 387 Perkins, Lars Eggert, Magnus Westerlund and Tom Petch for comments on 388 the document. 390 7. References 392 7.1 Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", RFC 2119, March 1997. 397 [RFC4340] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion 398 Control Protocol (DCCP)", RFC 4340, March 2006. 400 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 401 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 402 [RFC4347] Rescorla, E., Modadugu, N. "Datagram Transport Layer 403 Security", RFC 4347, April 2006. 405 7.2 Informative References 407 [RFC3448] Handley, M., Floyd, S., Padhye, J., Widmer, J., " TCP 408 Friendly Rate Control (TFRC): Protocol Specification", 409 RFC 3448, January 2003. 411 [RFC4341] Floyd, S., Kohler, E., "Profile for Datagram Congestion 412 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 413 Congestion Control", RFC 4341, March 2006. 415 [RFC4342] Floyd, S., Kohler, E., Padhye, J., " Profile for Datagram 416 Congestion Control Protocol (DCCP) Congestion Control ID 417 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 418 2006. 420 8. Author's Address 422 Tom Phelan 423 Sonus Networks 424 7 Technology Park Dr. 425 Westford, MA USA 01886 426 Phone: 978-614-8456 427 Email: tphelan@sonusnet.com 428 Intellectual Property Statement 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the procedures with respect to rights in RFC documents can be 437 found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at ietf- 450 ipr@ietf.org. 452 Disclaimer of Validity 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 457 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 458 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 459 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 Copyright Statement 464 Copyright (C) The IETF Trust (2008). 466 This document is subject to the rights, licenses and restrictions 467 contained in BCP 78, and except as set forth therein, the authors 468 retain all their rights. 470 Acknowledgment 472 Funding for the RFC Editor function is currently provided by the 473 Internet Society.