Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (20)
DCCP and DTLS sequence numbers serve overlapping but not identical functions. There is no connection between the sequence number of a DCCP packet and the sequence number in a DTLS record, and no connection between DCCP synchronization and DTLS anti-replay protection.
DCCP CCID 2 uses AIMD congestion control similar to TCP, which can cause a multiplicative decrease after a large DTLS handshake transfer. Applications sensitive to this should consider CCID 3 (TFRC), which varies throughput more slowly and avoids discontinuities.
Since a DCCP Service Code cannot be changed after a connection is established, applications that start with plain DCCP and optionally switch to DTLS over the same connection will use a single Service Code for both modes.
Application Data in DCCP-Request and DCCP-Response packets is not necessarily reliable; DCCP server implementations are free to discard it, and retransmissions may not include the Application Data from the initial message.
Since DTLS over DCCP simply encapsulates DTLS records transparently, this document is assumed to apply to all future versions of DTLS without revision, unless a change to DTLS or DCCP makes a revision to the encapsulation necessary.
A DTLS over DCCP implementation MAY use the DCCP-managed PMTU value instead of performing its own PMTU Discovery, but MUST NOT use a value greater than the value determined by DCCP. Implementations using DCCP-managed PMTU SHOULD still follow RFC 4347 Section 4.1.1.1 for fragmenting handshake messages.
A single DTLS record MUST be fully contained in a single DCCP-Data packet; it MUST NOT be split over multiple packets.
Applications MUST NOT send unprotected data on a DCCP connection while it is also carrying a DTLS connection, since this presents a vulnerability to packet insertion attacks.
Applications that use DTLS over DCCP sometimes and just DCCP other times SHOULD register and use different DCCP Service Codes for each mode of operation, since middleboxes may grant different privileges based on the Service Code.
Applications that use multiple DTLS connections in series over one transport connection SHOULD limit the potential burden on the system by some means, such as enforcing a minimum time of 1 second between session initiations, to protect against attackers repeatedly starting and stopping sessions.
DTLS client implementations MAY transmit one or more DTLS records in the DCCP-Request packet; DTLS servers MAY process these records and include DTLS response records in the DCCP-Response packet.
DTLS over DCCP implementations MUST NOT use a DTLS record size greater than the DCCP MPS (Maximum Packet Size) currently in force, which is bounded by the congestion control maximum packet size (CCMPS) and can vary over time.
DTLS over DCCP implementations SHOULD take steps to avoid retransmitting a request that has been queued but not yet actually transmitted by DCCP, for example by delaying the retransmission timer until DCCP indicates the message has been passed to the IP layer.
DTLS over DCCP MUST wait until the completion of the DCCP handshake before restarting its DTLS handshake retransmission timer, to avoid multiple DTLS retransmissions queuing up before the first can be sent.
It is RECOMMENDED that an application migrating to a new version of DTLS keep the same DCCP Service Code and rely on DTLS's version negotiation, unless new DTLS capabilities would significantly change middlebox behavior.
When a DTLS implementation resets the PMTU estimate, DTLS over DCCP implementations SHOULD also reset the DCCP PMTU estimation.
A DTLS connection is carried by a DCCP connection. The life of a DTLS over DCCP connection is completely contained within the life of the underlying DCCP connection; multiple DTLS connections can be resumed from the same DTLS session, each over its own DCCP connection.
DTLS records are transmitted in the Application Data fields of DCCP-Data and DCCP-DataAck packets. Multiple DTLS records MAY be sent in one DCCP-Data packet as long as the resulting packet is within the PMTU currently in force.
The two connection handshakes (DCCP and DTLS) are forced to happen in series, with DCCP first, followed by DTLS. However, DTLS records MAY be included in DCCP-Request and DCCP-Response packets to allow partial parallelism.
Security considerations for DTLS are specified in RFC 4347 and for DCCP in RFC 4340. The combination of DTLS and DCCP introduces no new security considerations beyond those already documented for the individual protocols.