idnits 2.17.1 draft-ietf-dccp-dtls-04.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 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. 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 (December 21, 2007) is 5964 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 December 21, 2007 4 DTLS over DCCP 5 Internet Draft T. Phelan 6 Document: draft-ietf-dccp-dtls-04.txt Sonus Networks 7 Expires: June 2008 December 21, 2007 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 September 30, 2007. 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.........................................7 59 3.7 New Versions of DTLS.......................................8 60 4. Security Considerations........................................8 61 5. IANA Considerations............................................8 62 6. References.....................................................9 63 6.1 Normative References.......................................9 64 6.2 Informative References.....................................9 65 7. Author's Address...............................................9 66 1. Introduction 68 This document specifies how to use Datagram Transport Layer Security 69 (DTLS), as specified in [RFC4347], over the Datagram Congestion 70 Control Protocol (DCCP), as specified in [RFC4340]. 72 DTLS is an extension of Transport Layer Security (TLS, [RFC4346]) 73 that modifies TLS for use with the unreliable transport protocol UDP. 74 TLS is a protocol that allows client/server applications to 75 communicate in a way that is designed to prevent eavesdropping, 76 tampering and message forgery. DTLS can be viewed as TLS-plus- 77 adaptations-for-unreliability. 79 DCCP provides an unreliable transport service, similar to UDP, but 80 with adaptive congestion control, similar to TCP and SCTP. DCCP can 81 be viewed equally well as either UDP-plus-congestion-control or TCP- 82 minus-reliability (although, unlike TCP, DCCP offers multiple 83 congestion control algorithms). 85 The combination of DTLS and DCCP will offer transport security 86 capabilities to DCCP users similar to those available for TCP, UDP 87 and SCTP. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. DTLS over DCCP 97 The approach here is very straightforward -- DTLS records are 98 transmitted in the Application Data fields of DCCP-Data and DCCP- 99 DataAck packets (in the rest of the document assume that "DCCP-Data 100 packet" means "DCCP-Data or DCCP-DataAck packet"). Multiple DTLS 101 records MAY be sent in one DCCP-Data packet, as long as the resulting 102 packet is within the Path Maximum Transfer Unit (PMTU) currently in 103 force, if the Don't Fragment (DF) bit is being used, or within the 104 current DCCP maximum packet size if the DF bit is not being used (see 105 section 3.5 for more information on PMTU Discovery). A single DTLS 106 record MUST be fully contained in a single DCCP-Data packet; it MUST 107 NOT be split over multiple packets. 109 3.1 DCCP and DTLS Sequence Numbers 111 Both DCCP and DTLS use sequence numbers in their packets/records. 112 These sequence numbers serve somewhat, but not completely, 113 overlapping functions. Consequently, there is no connection between 114 the sequence number of a DCCP packet and the sequence number in a 115 DTLS record contained in that packet and no connection between 116 sequence number-related features such as DCCP synchronization and 117 DTLS anti-replay protection. 119 3.2 DCCP and DTLS Connection Handshakes 121 Unlike UDP, DCCP is connection-oriented, and has a connection 122 handshake procedure that precedes the transmission of DCCP-Data and 123 DCCP-DataAck packets. DTLS is also connection-oriented, and has a 124 handshake procedure of its own that must precede the transmission of 125 actual application information. Using the rule of mapping DTLS 126 records to DCCP-Data and DCCP-DataAck packets in section 3, above, 127 the two handshakes are forced to happen in series, with the DCCP 128 handshake first, followed by the DTLS handshake. This is how TLS 129 over TCP works. 131 However, the DCCP handshake packets DCCP-Request and DCCP-Response 132 have Application Data fields and can carry user data during the DCCP 133 handshake, and this creates the opportunity to perform the handshakes 134 partially in parallel. DTLS client implementations MAY choose to 135 transmit the ClientHello message in the DCCP-Request packet. DTLS 136 server implementations MAY choose to respond to a ClientHello message 137 received in a DCCP-Request packet with a HelloVerifyRequest message, 138 if denial of service countermeasures are to be used, or a 139 ServerHelloDone message otherwise, in the DCCP-Response packet. DTLS 140 servers MAY also choose to delay the response until the handshake 141 completes and then send the response in a DCCP-Data packet. 143 DTLS handshake messages can be quite large, theoretically up to 2^24- 144 1 bytes and in practice often many kilobytes. Subsequently, unlike 145 other DTLS messages, the handshake messages may be fragmented over 146 multiple DTLS records. If the size of the ClientHello is too large 147 to transmit in its entirety in a DCCP-Request packet the ClientHello 148 MUST be sent in DCCP-Data packets after the DCCP handshake is 149 complete. Similarly, if the server response to a ClientHello is too 150 large to transmit in its entirety in a DCCP-Response packet, it MUST 151 be sent in DCCP-Data packets after the DCCP handshake is complete. 153 Transmission of subsequent DTLS handshake messages MUST wait for the 154 completion of the DCCP handshake and use DCCP-Data packets. 156 Note that even though the DCCP handshake is a reliable process 157 (handshake messages are retransmitted as required if messages are 158 lost), the transfer of Application Data in DCCP-Request and DCCP- 159 Response packets is not necessarily reliable. For example, DCCP 160 Server implementations are free to discard Application Data received 161 in DCCP-Request packets. And if DCCP-Request or DCCP-Response 162 packets need to be retransmitted, the DCCP implementation may choose 163 to not include the Application Data present in the initial message. 165 Since the DTLS handshake is also a reliable process, it will 166 interoperate across the data delivery unreliability of DCCP (after 167 all, one of the basic functions of DTLS is to work over unreliable 168 transport). If ClientHello messages or the HelloVerifyRequest or 169 ServerHelloDone messages are lost, the ClientHello message will be 170 retransmitted by DTLS. 172 This is regardless of whether the messages were sent in DCCP- 173 Response/Request packets or DCCP-Data packets. However, the only way 174 for DTLS to retransmit a ClientHello message that was originally 175 transmitted in a DCCP-Request packet (and it or the response was lost 176 somehow) is to wait for the DCCP handshake to complete and then send 177 the ClientHello in a DCCP-Data packet. This is due to the 178 characteristic of DCCP that the next opportunity to send data after 179 sending data in a DCCP-Request is only after the connection handshake 180 completes. 182 DCCP and DTLS use similar strategies for retransmitting handshake 183 messages. If there is no response to the original request (DCCP- 184 Request or ClientHello respectively) within normally 1 second, the 185 message is retransmitted. The timer is then doubled and the process 186 repeated until a response is received, or a maximum time is exceeded. 188 Therefore, if the ClientHello message is sent in a DCCP-Request 189 packet, and the DCCP-Request or DCCP-Response message is lost, the 190 DCCP and DTLS handshakes could be timing out on similar schedules. 191 The DCCP-Request packets will be retransmitted on timeout, but the 192 ClientHello packet cannot be retransmitted until the DCCP handshake 193 completes (there is no possibility of adding new Application Data to 194 a DCCP-Request retransmission). In order to avoid multiple 195 retransmissions queuing up before the first retransmission can be 196 sent, DTLS over DCCP MUST wait until the completion of the DCCP 197 handshake before restarting its retransmission timer. 199 3.3 Effects of DCCP Congestion Control 201 Given the large potential sizes of the DTLS handshake messages, it is 202 possible that DCCP congestion control could throttle the transmission 203 of the DTLS handshake to the point that the transfer cannot complete 204 before the DTLS timeout and retransmission procedures take effect. 205 Adding retransmitted messages to a congested situation might only 206 make matters worse and delay connection establishment. 208 Note that a DTLS over UDP application transmitting handshake data 209 into this same network situation will not necessarily receive better 210 throughput, and might actually see worse effective throughput. 211 Without the pacing of slow-start and congestion control, a UDP 212 application might be making congestion worse and lowering the 213 effective throughput it receives. 215 As stated in [RFC4347], "mishandling of the [retransmission] timer 216 can lead to serious congestion problems". This remains as true for 217 DTLS over DCCP as it is for DTLS over UDP. 219 DTLS over DCCP implementations SHOULD take steps to avoid 220 retransmitting a request that has been queued but not yet actually 221 transmitted by DCCP, when the underlying DCCP implementation can 222 provide this information. For example, DTLS could delay starting the 223 retransmission timer until DCCP indicates the message has been 224 transferred from DCCP to the IP layer. 226 In addition to the retransmission issues, if the throughput needs of 227 the actual application data differ from the needs of the DTLS 228 handshake, it is possible that the handshake transference could leave 229 the DCCP congestion control in a state that is not immediately 230 suitable for the application data that will follow. For example, 231 DCCP CCID2 ([RFC4341]) congestion control uses an Additive Increase 232 Multiplicative Decrease (AIMD) algorithm similar to TCP congestion 233 control. If it is used then it is possible that transference of a 234 large handshake could cause a multiplicative decrease that would not 235 have happened with the application data. The application might then 236 be throttled while waiting for additive increase to return throughput 237 to acceptable levels. 239 Applications where this might be a problem should consider using DCCP 240 CCID3 ([RFC4342]). CCID3 implements TCP-Friendly Rate Control (TFRC, 241 [RFC3448])). TFRC varies the allowed throughput more slowly than 242 AIMD and might avoid the discontinuities possible with CCID2. 244 3.4 DTLS Sessions and DCCP Connections 246 There is no necessary relationship between the life of a DTLS session 247 and the life of a DCCP connection. Often the session and connection 248 lives start and stop together (DCCP connection establishment 249 immediately followed by DTLS session establishment, DTLS session 250 termination immediately followed by DCCP connection termination), but 251 this is not the only possibility. 253 A single DTLS session may span multiple DCCP connections using the 254 DTLS session resumption features. The session resumption feature of 255 DTLS is widely used and this situation is likely to occur frequently. 256 It is even possible to resume a DTLS session over a different 257 transport. 259 A DCCP connection has no knowledge of the type of application data it 260 is transferring. It could conceivably contain multiple DTLS sessions, 261 in series or even in parallel, while simultaneously transferring non- 262 DTLS data. In practice this could be difficult to demultiplex at the 263 application/DTLS level and support for this is likely to be rare to 264 nonexistent. [RFC4347] does not specifically exclude multiple DTLS 265 sessions simultaneously sharing the same underlying transport. 267 A special case of this DCCP connection flexibility is an application 268 that starts up transferring non-DTLS data, and then switches to DTLS 269 after some time. This is likely to be useful and has implications 270 for the choice of DCCP Service Code. See section 3.6 for more 271 information on this. 273 3.5 PMTU Discovery 275 Each DTLS record must fit within a single DCCP-Data packet. DCCP 276 packets are normally transmitted with the DF (Don't Fragment) bit set 277 for IPv4, and of course all IPv6 packets are unfragmentable in the 278 network. Because of this, DCCP performs Path Maximum Transmission 279 Unit (PMTU) Discovery. 281 DTLS also normally uses the DF bit and performs PMTU Discovery on its 282 own, using an algorithm that is strongly similar to the one used by 283 DCCP. A DTLS over DCCP implementation MAY use the DCCP-managed value 284 for PMTU and not perform PMTU Discovery on its own. Alternatively, a 285 DTLS over DCCP implementation MAY choose to use its own PMTU 286 Discovery calculations, as specified in [RFC4347], but MUST NOT use a 287 value greater than the value determined by DCCP. 289 DTLS implementations normally allow applications to reset the PMTU 290 estimate back to the initial state. When that happens, DTLS over 291 DCCP implementations SHOULD also reset the DCCP PMTU estimation. 293 DTLS implementations also sometimes allow applications to control the 294 use of the DF bit (when running over IPv4). DTLS over DCCP 295 implementations SHOULD control the use of the DF bit by DCCP in 296 concert with the application's indications, when the DCCP 297 implementation supports this. Note that DCCP implementations are not 298 required to support sending packets with the DF bit not set. 300 Note that the DCCP Maximum Packet Size (MPS in [RFC4340]) is bounded 301 by the current congestion control state (Congestion Control Maximum 302 Packet Size, CCMPS in [RFC4340]). Even when the DF bit is not set 303 and DCCP packets may then be fragmented, the MPS may be less than the 304 65,535 bytes normally used in UDP. It is also possible for the DCCP 305 CMPS, and thus the MPS, to vary over time as congestion conditions 306 change. DTLS over DCCP implementations MUST NOT use a DTLS record 307 size that is greater than the DCCP MPS currently in force. 309 3.6 DCCP Service Codes 311 The DCCP connection handshake includes a field called Service Code 312 that is intended to describe "the application-level service to which 313 the client application wants to connect". Further, "Service Codes 314 are intended to provide information about which application protocol 315 a connection intends to use, thus aiding middleboxes and reducing 316 reliance on globally well-known ports" [RFC4340]. 318 It is expected that many middleboxes will give different privileges 319 to applications running DTLS over DCCP versus just DCCP. Therefore, 320 applications that use DTLS over DCCP sometimes and just DCCP other 321 times MUST register and use different Service Codes for each mode of 322 operation. Applications that use both DCCP and DTLS over DCCP MAY 323 choose to listen for incoming connections on the same DCCP port and 324 distinguish the mode of the request by the offered Service Code. 326 Some applications may start out using DCCP without DTLS, and then 327 optionally switch to using DTLS over the same connection. Since 328 there is no way to change the Service Code for a connection after it 329 is established, these applications will use one Service Code. 331 3.7 New Versions of DTLS 333 As DTLS matures, revisions to and updates for [RFC4347] can be 334 expected. DTLS includes mechanisms for identifying the version in 335 use and presumably future versions will either include backward 336 compatibility modes or at least not allow connections between 337 dissimilar versions. Since DTLS over DCCP simply encapsulates the 338 DTLS records transparently, these changes should not affect this 339 document and the methods of this document should apply to future 340 versions of DTLS. 342 Therefore, in the absence of a revision to this document, it is 343 assumed to apply to all future versions of DTLS. This document will 344 only be revised if a revision to DTLS makes a revision to the 345 encapsulation necessary. 347 It is RECOMMENDED that an application migrating to a new version of 348 DTLS keep the same DCCP Service Code used for the old version and 349 allow DTLS to provide the version negotiation support. If the 350 application developers feel that the new version of DTLS provides 351 significant new capabilities to the application that will change the 352 behavior of middleboxes, they MAY use a new Service Code. 354 4. Security Considerations 356 Security considerations for DTLS are specified in [RFC4347] and for 357 DCCP in [RFC4340]. The combination of DTLS and DCCP introduces no 358 new security considerations. 360 5. IANA Considerations 362 There are no IANA actions required for this document. 364 6. References 366 6.1 Normative References 368 [RFC4347] Rescorla, E., "Datagram Transport Layer Security", RFC 369 4347, April 2006. 371 [RFC4340] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion 372 Control Protocol (DCCP)", RFC 4340, March 2006. 374 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 375 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", RFC 2119, March 1997. 380 6.2 Informative References 382 [RFC4341] Floyd, S., Kohler, E., "Profile for Datagram Congestion 383 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 384 Congestion Control", RFC 4341, March 2006. 385 [RFC4342] Floyd, S., Kohler, E., Padhye, J., " Profile for Datagram 386 Congestion Control Protocol (DCCP) Congestion Control ID 387 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 388 2006. 389 [RFC3448] Handley, M., Floyd, S., Padhye, J., Widmer, J., " TCP 390 Friendly Rate Control (TFRC): Protocol Specification", 391 RFC 3448, January 2003. 393 7. Author's Address 395 Tom Phelan 396 Sonus Networks 397 7 Technology Park Dr. 398 Westford, MA USA 01886 399 Phone: 978-614-8456 400 Email: tphelan@sonusnet.com 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at ietf- 423 ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on an 428 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 429 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 430 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 431 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 432 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The IETF Trust (2007). 439 This document is subject to the rights, licenses and restrictions 440 contained in BCP 78, and except as set forth therein, the authors 441 retain all their rights. 443 Acknowledgment 445 Funding for the RFC Editor function is currently provided by the 446 Internet Society.