RFC 5238

Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) 🦋

okay bestie, this is RFC 5238 🎀 It's from the Network Working Group, written by T. Phelan at Sonus Networks. It's on the Standards Track and dates from May 2008. The title block doesn't list any Obsoletes or Updates entries, so this one isn't replacing or changing anything else in the header. ✨

Status of This Memo

okay so this is an Internet standards track protocol for the Internet community 💅 It also asks for discussion and suggestions for improvements. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) edition that's current. And the best part: distribution of this memo is unlimited 🌈

Abstract

this doc is all about running Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) 🔥 DTLS gives privacy to apps that use datagram transports, so client/server apps can talk in a way that's built to stop eavesdropping and catch tampering or message forgery 🫶 DCCP is a transport protocol that gives you a congestion-controlled unreliable datagram service ✨

Table of Contents

1. Introduction ....................................................2
2. Terminology .....................................................2
3. DTLS over DCCP ..................................................2
   3.1. DCCP and DTLS Sequence Numbers .............................3
   3.2. DCCP and DTLS Connection Handshakes ........................3
   3.3. Effects of DCCP Congestion Control .........................4
   3.4. Relationships between DTLS Sessions/Connections and DCCP
        Connections ................................................5
   3.5. PMTU Discovery .............................................6
   3.6. DCCP Service Codes .........................................7
   3.7. New Versions of DTLS .......................................8
4. Security Considerations .........................................8
5. Acknowledgments .................................................8
6. References ......................................................9
   6.1. Normative References .......................................9
   6.2. Informative References .....................................9

---

1. Introduction ✨

this section is about carrying app payloads with DTLS, as specified in [RFC4347], inside DCCP, as specified in [RFC4340] 🦋

DTLS is basically a glow-up of Transport Layer Security (TLS, [RFC4346]) that's been adapted for UDP, which is unreliable transport 💖 TLS is the protocol that lets client/server apps talk in a way designed to prevent eavesdropping and detect tampering and message forgery. DTLS can be thought of as TLS-plus-adaptations-for-unreliability 💅

DCCP gives you an unreliable transport service, kind of like UDP, but with adaptive congestion control, kind of like TCP and the Stream Control Transmission Protocol (SCTP) 🌸 You can see DCCP as either UDP-plus-congestion-control or TCP-minus-reliability, and it's equally valid either way. (The difference from TCP is that DCCP offers multiple congestion control algorithms 👑)

so put DTLS and DCCP together and apps using DCCP get transport security similar to what TCP, UDP, and SCTP already have 🔥

2. Terminology

okay the BCP 14 key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 🎀 whenever they show up in this doc, read them the way [RFC2119] says to 🫶

3. DTLS over DCCP 🧚

the approach here is super straightforward 💅 DTLS records get sent in the Application Data fields of DCCP-Data and DCCP-DataAck packets. (For the rest of the doc, assume "DCCP-Data packet" means "DCCP-Data or DCCP-DataAck packet" 💖)

Multiple DTLS records MAY be sent in one DCCP-Data packet 🌈 but only as long as the result fits within the Path Maximum Transfer Unit (PMTU) currently in force for normal data packets, if fragmentation isn't allowed (that's when the Don't Fragment (DF) bit is set for IPv4, or no fragmentation extension headers are being used for IPv6). If fragmentation is allowed, it has to fit within the current DCCP maximum packet size instead. (See Section 3.5 for more on PMTU Discovery 🔍)

the big rule: a single DTLS record MUST be fully contained in a single DCCP-Data packet 🚫 it MUST NOT be split over multiple packets. no exceptions, bestie 💀

3.1. DCCP and DTLS Sequence Numbers

both DCCP and DTLS put sequence numbers in their packets/records 🔢 they overlap a bit, but not completely 🙈 so there's no link between the sequence number of a DCCP packet and the sequence number of a DTLS record inside it. And there's no link between sequence number stuff like DCCP synchronization and DTLS anti-replay protection either. two separate lanes, no drama ✨

3.2. DCCP and DTLS Connection Handshakes

unlike UDP, DCCP is connection-oriented 🦋 it has a connection handshake that comes before any DCCP-Data or DCCP-DataAck packets get sent. DTLS is connection-oriented too, and it has its own handshake that must precede sending actual application info 💜 If you follow the rule from Section 3 above (mapping DTLS records onto DCCP-Data and DCCP-DataAck packets), the two handshakes end up happening in series: DCCP first, then DTLS. Honestly, that's exactly how TLS over TCP works 🌸

but here's the plot twist 😭 the DCCP handshake packets, DCCP-Request and DCCP-Response, have Application Data fields and can carry user data during the DCCP handshake. That opens the door to doing the handshakes partially in parallel ⭐ DTLS client implementations MAY choose to send one or more DTLS records (usually DTLS handshake messages, or parts of them) in the DCCP-Request packet. A DTLS server implementation MAY choose to process those records as usual, and if it has DTLS records to send back (again, usually handshake messages or parts of them), it MAY include them in the DCCP-Response packet. DTLS servers MAY also choose to hold off on responding until the DCCP handshake finishes, and then send the DTLS response in a DCCP-Data packet 🎀

okay now the reliability tea ☕ the DCCP handshake is reliable (handshake messages get retransmitted as needed if they're lost), but the Application Data in DCCP-Request and DCCP-Response packets is NOT necessarily reliable 💀 For example, DCCP servers are free to throw away Application Data they got in DCCP-Request packets. And if DCCP-Request or DCCP-Response packets need retransmitting, the DCCP implementation may choose not to include the Application Data from the first message 🙈

the DTLS handshake is reliable too, so it works fine across DCCP's data delivery unreliability (after all, one of DTLS's main jobs is working over unreliable transport 💖). If the DTLS records holding handshake messages get lost, DTLS retransmits them ✨ That's true whether those messages went out in DCCP-Response/DCCP-Request packets or in DCCP-Data packets. The catch: the only way DTLS can retransmit records that were first sent in DCCP-Request/DCCP-Response packets (when those packets or their responses got lost somehow) is to wait for the DCCP handshake to complete and then resend the records in DCCP-Data packets. That's because of how DCCP works: the next chance to send data after sending data in a DCCP-Request only comes once the connection handshake completes 🫠

DCCP and DTLS use similar strategies for retransmitting handshake messages 🔁 If there's no response to the original request (a DCCP-Request, or any DTLS handshake message where a response is expected) within normally 1 second, the message gets retransmitted. The timer then doubles and the process repeats until a response arrives or a maximum time is exceeded ⏱️

so if DTLS records got sent in a DCCP-Request packet, and the DCCP-Request or DCCP-Response message gets lost, the DCCP and DTLS handshakes could be timing out on similar schedules 😬 The DCCP-Request packets get retransmitted on timeout, but the DTLS records can't be retransmitted until the DCCP handshake completes (there's no way to add new Application Data to a DCCP-Request retransmission). To keep multiple DTLS retransmissions from piling up before the first one can be sent, DTLS over DCCP MUST wait until the DCCP handshake completes before restarting its DTLS handshake retransmission timer 💅

3.3. Effects of DCCP Congestion Control

the DTLS handshake messages can be pretty big 📦 so it's possible that DCCP congestion control throttles the handshake transmission so much that it can't finish before the DTLS timeout and retransmission procedures kick in 😩 Adding retransmitted messages to an already congested situation might only make things worse and delay connection establishment 🙃

heads up: a DTLS over UDP app pushing handshake data into that same network situation won't necessarily get better throughput, and it might actually see worse effective throughput 💀

and without the pacing of slow-start and congestion control, a UDP app might be making congestion worse and lowering the effective throughput it gets 📉

as [RFC4347] puts it, "mishandling of the [retransmission] timer can lead to serious congestion problems" 🚨 that stays just as true for DTLS over DCCP as it is for DTLS over UDP 😭

DTLS over DCCP implementations SHOULD take steps to avoid retransmitting a request that's been queued but not yet actually transmitted by DCCP, when the underlying DCCP implementation can provide that information 🫶 For example, DTLS could delay starting the retransmission timer until DCCP indicates the message has been transferred from DCCP to the IP layer.

there's another wrinkle 🧶 if the throughput needs of the actual application data differ from the needs of the DTLS handshake, the handshake transfer could leave DCCP congestion control in a state that isn't immediately suitable for the application data that comes next. For example, DCCP Congestion Control Identifier (CCID) 2 ([RFC4341]) uses an Additive Increase Multiplicative Decrease (AIMD) algorithm, similar to TCP congestion control. If it's used, a big handshake could cause a multiplicative decrease that wouldn't have happened with the application data. The app might then get throttled while it waits for additive increase to bring throughput back to acceptable levels 😖

apps where this might be a problem should consider using DCCP CCID 3 ([RFC4342]) 💖 CCID 3 implements TCP-Friendly Rate Control (TFRC, [RFC3448])). TFRC varies the allowed throughput more slowly than AIMD, and it might avoid the discontinuities that are possible with CCID 2 🦋

3.4. Relationships between DTLS Sessions/Connections and DCCP Connections ✨

okay so DTLS has two concepts that are easy to mix up: sessions and connections 💅 A DTLS connection is what upper-layer endpoints actually use to swap data over a transport protocol. A DTLS session holds cached state, which is the secret sauce for cutting down the roundtrips and computation needed to spin up multiple DTLS connections between the same endpoints 🧚

In DTLS over DCCP, a DTLS connection rides on a DCCP connection 🦋 Usually the DCCP connection gets set up and then DTLS connection setup happens right after (either a brand-new DTLS session with a full handshake, or resuming an existing session). On the way out, DTLS connection termination is immediately followed by DCCP connection termination. BUT that's not the only possible vibe 🙈

The life of a DTLS over DCCP connection is totally contained inside the life of its underlying DCCP connection. If the DCCP connection terminates, the DTLS connection cannot keep going, so no sneaky survival 💀 However, multiple DTLS connections can be resumed from the same DTLS session, with each one running over its own DCCP connection. The session resumption features of DTLS are widely used, so expect this pattern in lots of use cases 🌸 It's also possible to resume a DTLS session with a new DTLS connection running over a different transport.

Also, an application can start a DCCP connection by sending unprotected packets and then switch over to DTLS after some time 🎀 This is likely to be handy for apps that want to negotiate whether to use DTLS or not, and it has implications for the choice of DCCP Service Code. See Section 3.6 for more information.

Here's the tea ☕ Many DTLS Application Programming Interfaces (APIs) don't stop an application from sending a mix of encrypted and clear packets over the same transport connection. That is a big no-no: applications MUST NOT send unprotected data on a DCCP connection while it's also carrying a DTLS connection, because that opens up a vulnerability to packet insertion attacks 🚫🔥

Many DTLS APIs also let an application start multiple DTLS connections over one transport connection in series, where one DTLS connection ends and then another begins 🔁 Processing a DTLS handshake is pretty CPU intensive, so an app doing this is open to an attacker who keeps starting and immediately stopping sessions 😭 So apps using this strategy SHOULD limit the potential burden on the system by some means. For example, the application could enforce a minimum time of 1 second between session initiations ⏱️

3.5. PMTU Discovery 🌈

Each DTLS record must fit within a single DCCP-Data packet 📦 DCCP packets are normally sent with the DF (Don't Fragment) bit set for IPv4 (or without fragmentation extension headers for IPv6). Because of this, DCCP performs Path Maximum Transmission Unit (PMTU) Discovery.

DTLS also normally uses the DF bit and does its own PMTU Discovery, using an algorithm that is strongly similar to the one DCCP uses 👯 A DTLS over DCCP implementation MAY use the DCCP-managed value for PMTU and skip doing its own PMTU Discovery. HOWEVER, implementations that choose to use the DCCP-managed PMTU value SHOULD keep following the procedures of Section 4.1.1.1 of [RFC4347] when it comes to fragmenting handshake messages during handshake retransmissions. Or, alternatively, a DTLS over DCCP implementation MAY choose to use its own PMTU Discovery calculations, as specified in [RFC4347], but it MUST NOT use a value greater than the one determined by DCCP 🙅‍♀️

DTLS implementations normally let applications reset the PMTU estimate back to the initial state. When that happens, DTLS over DCCP implementations SHOULD also reset the DCCP PMTU estimation 🔄

DTLS implementations also sometimes let applications control the use of the DF bit (when running over IPv4) or the use of fragmentation extension headers (when running over IPv6). DTLS over DCCP implementations SHOULD control the use of the DF bit or fragmentation extension headers by DCCP in concert with the application's indications, when the DCCP implementation supports this 💖 Note that DCCP implementations are not required to support sending fragmentable packets.

Now, the DCCP Maximum Packet Size (MPS in [RFC4340]) is bounded by the current congestion control state (Congestion Control Maximum Packet Size, CCMPS in [RFC4340]) 📏 Even when the DF bit is not set and DCCP packets may then get fragmented, the MPS may still be less than the 65,535 bytes normally used in UDP. The DCCP CCMPS, and therefore the MPS, can also change over time as congestion conditions shift 🌊 So DTLS over DCCP implementations MUST NOT use a DTLS record size that is greater than the DCCP MPS currently in force. Non-negotiable, bestie 😤

3.6. DCCP Service Codes 🎟️

The DCCP connection handshake includes a field called Service Code, which is meant to describe "the application-level service to which the client application wants to connect". And "Service Codes are intended to provide information about which application protocol a connection intends to use, thus aiding middleboxes and reducing reliance on globally well-known ports" [RFC4340] 🧠

It's expected that lots of middleboxes will give different privileges to applications running DTLS over DCCP versus just plain DCCP 👀 So applications that sometimes use DTLS over DCCP and other times just DCCP SHOULD register and use different Service Codes for each mode of operation. Applications that use both DCCP and DTLS over DCCP MAY listen for incoming connections on the same DCCP port and tell the two modes apart by the offered Service Code 🦄

Some applications may start out using DCCP without DTLS and then optionally switch to DTLS over the same connection. Since there's no way to change the Service Code for a connection after it's established, these applications will use one Service Code 🔒

3.7. New Versions of DTLS 🆕

As DTLS matures, revisions to and updates for [RFC4347] can be expected ✨ DTLS includes mechanisms for identifying the version in use, and presumably future versions will either include backward compatibility modes or at least not allow connections between dissimilar versions. Since DTLS over DCCP simply encapsulates the DTLS records transparently, these changes should not affect this document, and the methods of this document should apply to future versions of DTLS 🫶

So, unless this document gets a revision, it's assumed to apply to all future versions of DTLS. This document will only be revised if a revision to DTLS or DCCP (including its related CCIDs) makes a revision to the encapsulation necessary 📝

It is RECOMMENDED that an application migrating to a new version of DTLS keep the same DCCP Service Code it used for the old version and let DTLS provide the version negotiation support 🤝 If a new version of DTLS provides significant new capabilities to the application that could change how middleboxes treat the application, an application developer MAY register a new Service Code 🌟

4. Security Considerations 🔐

Security considerations for DTLS are specified in [RFC4347], and for DCCP they're in [RFC4340]. The combination of DTLS and DCCP introduces no new security considerations. Phew 😮‍💨 (Still read those two RFCs, though. They're the real security bibles. 🙏)

5. Acknowledgments 💜

The author would like to thank Eric Rescorla for initial guidance on adapting DTLS to DCCP, and Gorry Fairhurst, Pasi Eronen, Colin Perkins, Lars Eggert, Magnus Westerlund, and Tom Petch for comments on the document 🫶🌸

6. References 📚

6.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
• [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
• [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.

6.2. Informative References

• [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
• [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
• [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.

---

Author's Address 🖊️

Tom Phelan
Sonus Networks
7 Technology Park Dr.
Westford, MA USA 01886
Phone: 978-614-8456
Email: tphelan@sonusnet.com

Full Copyright Statement ©️

The legal bits, verbatim, because they matter 📜

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌🌈