Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
updated by
Extracted elements (23)
DTLS compression is prohibited because SCTP performs its own segmentation and reassembly based on the path MTU; if DTLS compressed the SCTP payload, the apparent message sizes would no longer correspond to actual IP packet sizes, breaking SCTP's MTU-based fragmentation logic.
SCTP associations over DTLS are constrained to be single-homed because DTLS does not expose any address management to its upper layer, making it impossible for SCTP to use multiple IP addresses for multihoming as it would over IPv4/IPv6 directly.
The inability to process ICMP or ICMPv6 messages does not introduce a security issue. When SCTP runs over connectionless layers (IPv4, IPv6, UDP), processing ICMP is required to protect other non-SCTP nodes; since DTLS is connection-oriented, that protection is unnecessary.
Partial reliability (RFC 3758) and additional PR-SCTP policies (RFC 7496), stream reset (RFC 6525), and message interleaving (RFC 8260) extensions can all be used in combination with DTLS encapsulation without restrictions beyond those stated for the base protocol.
The procedures defined in RFC 6951 (UDP encapsulation of SCTP) for dealing with UDP port numbers do not apply to SCTP over DTLS. When using DTLS encapsulation, SCTP is entirely unaware of the protocols used below DTLS.
The SCTP authentication extension (RFC 4895) can be used with DTLS encapsulation but does not provide any additional security benefit, since DTLS already provides authentication and integrity protection.
A DTLS connection MUST be established before an SCTP association can be set up. Multiple SCTP associations MAY be multiplexed over a single DTLS connection using SCTP port numbers for demultiplexing.
All SCTP associations over DTLS are single-homed because DTLS does not expose address management to its upper layer. It is RECOMMENDED to set the SCTP parameter path.max.retrans equal to association.max.retrans.
An implementation of SCTP over DTLS MUST implement and use a path MTU discovery method that functions without ICMP, to provide SCTP/DTLS with an MTU estimate. Implementation of Packetization Layer Path MTU Discovery (RFC 4821) in SCTP or DTLS is RECOMMENDED.
If path MTU discovery is performed by the SCTP layer over IPv4 and the DF bit cannot be controlled, a safe path MTU value MUST be used. It is RECOMMENDED that this safe value not exceed 1200 bytes, noting that RFC 1122 only requires hosts to reassemble fragments up to 576 bytes.
If the dynamic address reconfiguration extension (RFC 5061) is used, ASCONF chunks MUST use wildcard addresses only, because DTLS does not expose explicit IP addresses to SCTP.
If the SCTP layer is notified about a path change by its lower layers, SCTP SHOULD retest the path MTU and reset the congestion state (congestion window and slow-start threshold) to initial values.
The DTLS implementation MUST support DTLS 1.0 (RFC 4347) and SHOULD support the most recently published version of DTLS (DTLS 1.2 at time of publication). This latter requirement applies to all future versions of DTLS when published as RFCs.
The DTLS implementation SHOULD allow the DTLS user to set the DSCP value for sent IP packets. Only a single DSCP value can be used for all packets belonging to the same SCTP association.
The DTLS layer MUST NOT use any compression algorithm. Because SCTP performs segmentation and reassembly based on the path MTU, DTLS compression would interfere with SCTP's operation.
The DTLS layer MUST support sending messages larger than the current path MTU, which may result in sending IP-level fragmented messages.
The implementation MUST NOT rely on processing ICMP or ICMPv6 packets, since the SCTP layer most likely is unable to access the SCTP common header in the plaintext that triggered the ICMP message. This applies in particular to path MTU discovery performed by SCTP.
The INIT and INIT-ACK chunks MUST NOT contain any IPv4 Address or IPv6 Address parameters. The INIT chunk MUST NOT contain the Supported Address Types parameter.
Using ECN in SCTP requires the DTLS layer and its lower layer to pass ECN bits through and expose access to them for sent and received packets. If this is not possible due to implementation restrictions, ECN cannot be used by SCTP.
When the SCTP layer performs path MTU discovery per RFC 4821, the SCTP padding extension (RFC 4820) MUST be supported and used for probe packets — specifically HEARTBEAT chunks bundled with PADDING chunks.
SCTP over DTLS stacks SCTP directly on top of DTLS, which runs over ICE/UDP. The complete SCTP packet (common header plus chunks) is treated as the application-layer payload of DTLS. SCTP is unaware of the protocols below DTLS, so all associations are single-homed.
SCTP should not process the IP addresses used for the underlying DTLS communication because DTLS provides no guarantees about those addresses. The combination of SCTP and DTLS introduces no new security considerations beyond those specified for each protocol individually.
When an SCTP packet is passed to the DTLS layer, the entire SCTP common header followed by all SCTP chunks is carried as the DTLS application-layer protocol payload. On receipt, the DTLS layer extracts that payload and passes it up to SCTP unchanged.