RFC 8261

Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets

📅 published November 2017, from ietf

RFC 8261: Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets 💖

Stream: Internet Engineering Task Force (IETF) 🌸 Authors: M. Tuexen (Muenster Univ. of Appl. Sciences), R. Stewart (Netflix, Inc.), R. Jesup (WorldGate Communications), S. Loreto (Ericsson) 👯 Category: Standards Track 🏆 Date: November 2017 📅 ISSN: 2070-1721 Obsoletes / Updates: nothing is listed in the title block 🙅‍♀️

Abstract ✨

okay so SCTP (the Stream Control Transmission Protocol) was originally built to sit on top of IPv4 or IPv6. This doc explains how SCTP can run on top of DTLS (Datagram Transport Layer Security) instead 🔐. The big twist is that SCTP has no idea what's happening below DTLS, so it can't put explicit IP addresses in its control chunks 🙈. That means any SCTP associations carried over DTLS can only be single-homed (one address, no backup route) 💅.

Status of This Memo 📜

this is an Internet Standards Track document 🏆

this doc is a product of the Internet Engineering Task Force (IETF) 💜. It represents the consensus of the IETF community 🫶, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. If you want more info about Internet Standards, check out Section 2 of RFC 7841 📚.

for the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8261 🔗.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), which apply on the date this doc was published. Please read these carefully, because they spell out your rights and restrictions for this doc 🧾. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚖️.

Table of Contents 🗂️

1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Encapsulation and Decapsulation Procedure . . . . . . . . . .   3
4.  General Considerations  . . . . . . . . . . . . . . . . . . .   4
5.  DTLS Considerations . . . . . . . . . . . . . . . . . . . . .   4
6.  SCTP Considerations . . . . . . . . . . . . . . . . . . . . .   5
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Overview 🦋

okay bestie, so SCTP as defined in [RFC4960] is a transport protocol that runs on top of the network protocols IPv4 [RFC0791] or IPv6 [RFC8200] ✨. This doc is all about how SCTP gets used on top of Datagram Transport Layer Security (DTLS) 🔐. DTLS 1.0 is defined in [RFC4347], and the latest version when this RFC was published, DTLS 1.2, is defined in [RFC6347] 🧠. This encapsulation shows up in the WebRTC protocol suite (see [RTC-OVERVIEW] for an overview) for moving non-SRTP data between browsers 🌐. The architecture of this whole stack is covered in [DATA-CHAN] 💅.

                               +----------+
                               |   SCTP   |
                               +----------+
                               |   DTLS   |
                               +----------+
                               | ICE/UDP  |
                               +----------+

                       Figure 1: Basic Stack Diagram

this is giving layers 🍰. SCTP over DTLS over UDP (or ICE/UDP, see [RFC5245]) can work as a NAT traversal solution, and on top of that you get confidentiality, source authentication, and integrity-protected transfers 🛡️. Heads up, though: using ICE doesn't automatically mean the packet format on the wire is different 👀.

also, the procedures in [RFC6951] for handling UDP port numbers do not apply here 🙅‍♀️. With this encapsulation, SCTP is unaware of which protocols are used below DTLS 🫠.

2. Conventions 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here 🎀.

3. Encapsulation and Decapsulation Procedure 🎁

okay so when an SCTP packet gets handed to the DTLS layer 📦, the whole thing (the SCTP common header plus all of its SCTP chunks) gets treated as the payload of DTLS's application-layer protocol 💌. Once DTLS has processed a DTLS record carrying a message of that application-layer protocol, it passes the payload up to the SCTP layer 🚀. The SCTP layer expects to see an SCTP common header followed by a bunch of SCTP chunks 🧩.

4. General Considerations 🌷

this part is so important 😭. An implementation of SCTP over DTLS MUST implement and use a path maximum transmission unit (MTU) discovery method that works without ICMP, so SCTP/DTLS can get an MTU estimate 📏. Implementing "Packetization Layer Path MTU Discovery" [RFC4821], either in SCTP or in DTLS, is RECOMMENDED 💖.

when SCTP over DTLS is used for data channels, SCTP does the path MTU discovery (see Section 5 of [DATA-CHAN]) 🧁.

5. DTLS Considerations 🔐

the DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC came out 🫶. If there's no revision to this doc, that second requirement covers all future versions of DTLS once they're published as RFCs 🔮. This doc only gets revised if a change to DTLS or SCTP makes the encapsulation need a change 🔄.

SCTP does segmentation and reassembly based on the path MTU 🧩. Because of that, the DTLS layer MUST NOT use any compression algorithm 🙅‍♀️.

The DTLS MUST support sending messages larger than the current path MTU 📬. This might end up sending IP-level fragmented messages 🧷.

if path MTU discovery is done by the DTLS layer, the method described in [RFC4821] MUST be used 🎯. For probe packets, the extension defined in [RFC6520] MUST be used 💫.

if path MTU discovery is done by the SCTP layer and IPv4 is the network-layer protocol, the DTLS implementation SHOULD let the DTLS user force the corresponding IPv4 packet to go out with the Don't Fragment (DF) bit set 🚩. If controlling the DF bit isn't possible (say, because of implementation restrictions), the SCTP stack has to use a safe value for the path MTU 🛟. It is RECOMMENDED that this safe value not exceed 1200 bytes 📐. Please note that [RFC1122] only requires end hosts to be able to reassemble fragmented IP packets up to 576 bytes in length 🧐.

the DTLS implementation SHOULD let the DTLS user set the Differentiated Services Code Point (DSCP) used for outgoing IP packets (see [RFC2474]) 🏷️. This needs the DTLS implementation to pass the value through, and the lower layer has to allow setting it 🔧. If the lower layer can't set the DSCP, the DTLS user just ends up with the default value from the protocol stack 🤷‍♀️. Please note that a single DSCP value is used for all packets belonging to the same SCTP association 💅.

Using Explicit Congestion Notification (ECN) in SCTP requires the DTLS layer to pass the ECN bits through, and its lower layer has to expose access to them for sent and received packets (see [RFC3168]) 🌊. The DTLS and lower-layer implementations have to provide this support 🫡. If that isn't possible (for example, due to implementation restrictions), ECN can't be used by SCTP 😔.

6. SCTP Considerations 🧚

this section covers how the base protocol gets used and how well various SCTP extensions fit 🍓.

6.1. Base Protocol 🎀

this doc uses SCTP [RFC4960] with the following restrictions 💅. They're needed because the lower layer is DTLS instead of IPv4 and IPv6, and because SCTP doesn't deal with the IP addresses or the transport protocol used below DTLS 🫠:

  • 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 🌈. The SCTP port numbers are used for multiplexing and demultiplexing the SCTP associations carried over a single DTLS connection 🔀.
  • All SCTP associations are single-homed, because DTLS doesn't expose any address management to its upper layer 🏠. So, it is RECOMMENDED to set the SCTP parameter path.max.retrans to association.max.retrans 🎯.
  • The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or IPv6 Address parameters 🙅‍♀️. The INIT chunk MUST NOT contain the Supported Address Types parameter 🚫.
  • The implementation MUST NOT rely on processing ICMP or ICMPv6 packets 🙈. The SCTP layer most likely can't access the SCTP common header in the plain text of the packet that triggered the ICMP or ICMPv6 packet 🥲. This applies in particular to path MTU discovery when SCTP does it 📏.
  • If the SCTP layer gets notified about a path change by its lower layers, SCTP SHOULD retest the path MTU and reset the congestion state to the initial state 🔄. The window-based congestion control method in [RFC4960] resets the congestion window and slow-start threshold to their initial values 🪟.

6.2. Padding Extension 🧸

when the SCTP layer does path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be supported and used for probe packets (HEARTBEAT chunks bundled with PADDING chunks [RFC4820]) 🎁.

6.3. Dynamic Address Reconfiguration Extension 🏡

if the dynamic address reconfiguration extension defined in [RFC5061] is used, ASCONF chunks MUST use wildcard addresses only 🃏.

6.4. SCTP Authentication Extension 🔑

the SCTP authentication extension defined in [RFC4895] can be used with DTLS encapsulation, but it doesn't add any extra benefit 🤷‍♀️.

6.5. Partial Reliability Extension 🌤️

Partial reliability as defined in [RFC3758] can be used together with DTLS encapsulation 🧃. You can also use additional Partially Reliable Stream Control Transmission Protocol (PR-SCTP) policies, like the ones defined in [RFC7496] 🎈.

6.6. Stream Reset Extension 🔁

the SCTP stream reset extension defined in [RFC6525] can be used with DTLS encapsulation 💫. It's used to reset SCTP streams and add SCTP streams during the lifetime of the SCTP association 🌸.

6.7. Interleaving of Large User Messages

SCTP as defined in [RFC4960] does not support the interleaving of large user messages that need to be fragmented and reassembled by the SCTP layer. The protocol extension defined in [RFC8260] overcomes this limitation and can be used with DTLS encapsulation. 💅✨

7. IANA Considerations 🎀

This document does not require any IANA actions. 🌸

8. Security Considerations 🔐

Okay bestie, this part is SUPER important so pay attention 👀 Security considerations for DTLS are specified in [RFC4347] and for SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP and DTLS introduces no new security considerations. Lowkey iconic, no new drama 💖

SCTP should not process the IP addresses used for the underlying communication since DTLS provides no guarantees about them. 🙈 Don't go poking at those addresses, they're not protected by DTLS, so it's a no-go zone 🚫

It should be noted that the inability to process ICMP or ICMPv6 messages does not add any security issue. When SCTP is carried over a connection-less lower layer like IPv4, IPv6, or UDP, processing of these messages is required to protect other nodes not supporting SCTP. Since DTLS provides a connection-oriented lower layer, this kind of protection is not necessary. 🦋 So ICMP handling is a must on connectionless layers to protect other nodes, but DTLS is connection-oriented so we don't need that protection. Not me being like "wait, that's a whole thing" 😭

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

The authors wish to thank David Black, Benoit Claise, Spencer Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch, and Magnus Westerlund for their invaluable comments. Literal legends, the whole list 👑

Authors' Addresses 🌈

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany

Email: tuexen@fh-muenster.de

Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America

Email: randall@lakerest.net

Randell Jesup WorldGate Communications 3800 Horizon Blvd, Suite #103 Trevose, PA 19053-4947 United States of America

Phone: +1-215-354-5166 Email: randell-ietf@jesup.org

Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland

Email: Salvatore.Loreto@ericsson.com

📦 where this page comes from