RFC 8841

Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport

📅 published January 2021, from ietf

RFC 8841: Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport 🎀

Okay bestie, this is RFC 8841 💅, a Standards Track doc from January 2021 with ISSN 2070-1721. The authors are C. Holmberg (Ericsson), R. Shpount (TurboBridge), S. Loreto, and G. Camarillo (Ericsson). The header doesn't list any Obsoletes or Updates, so it isn't replacing or changing anything else 🦋

Table of Contents

   1.  Introduction
   2.  Conventions
   3.  SCTP Terminology
   4.  SDP Media Descriptions
     4.1.  General
     4.2.  Protocol Identifiers
     4.3.  Media-Format Management
     4.4.  Syntax
       4.4.1.  General
       4.4.2.  SDP Media Description Values
     4.5.  Example
   5.  SDP "sctp-port" Attribute
     5.1.  General
     5.2.  Syntax
     5.3.  Mux Category
   6.  SDP "max-message-size" Attribute
     6.1.  General
     6.2.  Syntax
     6.3.  Mux Category
   7.  UDP/DTLS/SCTP Transport Realization
   8.  TCP/DTLS/SCTP Transport Realization
   9.  Association and Connection Management
     9.1.  General
     9.2.  SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes
     9.3.  SCTP Association
     9.4.  DTLS Association (UDP/DTLS/SCTP and TCP/DTLS/SCTP)
     9.5.  TCP Connection (TCP/DTLS/SCTP)
   10. SDP Offer/Answer Procedures
     10.1.  General
     10.2.  Generating the Initial SDP Offer
     10.3.  Generating the SDP Answer
     10.4.  Offerer Processing of the SDP Answer
     10.5.  Modifying the Session
   11. Multihoming Considerations
   12. NAT Considerations
     12.1.  General
     12.2.  ICE Considerations
   13. Examples
     13.1.  Establishment of UDP/DTLS/SCTP Association
   14. Security Considerations
   15. IANA Considerations
     15.1.  New SDP Proto Values
     15.2.  New SDP Attributes
       15.2.1.  sctp-port
       15.2.2.  max-message-size
     15.3.  association-usage Name Registry
   16. References
     16.1.  Normative References
     16.2.  Informative References
   Acknowledgements
   Authors' Addresses

Abstract

Okay so SCTP 🧚 is a transport protocol used to set up associations between two endpoints. RFC 8261 explains how to run SCTP on top of DTLS, which it calls SCTP-over-DTLS 🔐.

This spec adds two new SDP proto values, "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" 💖. It also explains how to use those proto values with the SDP offer/answer mechanism to negotiate SCTP-over-DTLS associations ✨.

Status of This Memo

This is an Internet Standards Track document ✅.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 🌸.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8841 🍓.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction ✨

So the Session Description Protocol (SDP) [RFC4566] is the general-purpose format for describing multimedia sessions in announcements or invitations 🎬. "TCP-Based Media Transport in the Session Description Protocol (SDP)" [RFC4145] gives a general mechanism for describing and establishing TCP [RFC0793] streams. Then "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC8122] extends [RFC4145] to describe TCP-based media streams that are protected using TLS 🔒.

The Stream Control Transmission Protocol (SCTP) [RFC4960] is a reliable transport protocol. It moves data between two endpoints using SCTP associations 🚀.

[RFC8261] explains how SCTP can run on top of the Datagram Transport Layer Security (DTLS) protocol. The arrangement is called SCTP-over-DTLS 🦋.

This spec defines the new SDP [RFC4566] protocol identifiers (proto values) "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" 💜. It also explains how to use them with the SDP offer/answer mechanism [RFC3264] to negotiate SCTP-over-DTLS associations 🫶.

NOTE: Due to the characteristics of TCP, while multiple SCTP streams can still be used, usage of "TCP/DTLS/SCTP" will always force ordered and reliable delivery of the SCTP packets, which limits the usage of the SCTP options. Therefore, it is RECOMMENDED that TCP is only used in situations where UDP traffic is blocked 😭.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖.

3. SCTP Terminology

SCTP association: A protocol relationship between SCTP endpoints. It's made up of the two SCTP endpoints plus protocol state information, including verification tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses the endpoints use in the association 🧩.
SCTP stream: A unidirectional logical channel from one associated SCTP endpoint to another. All user messages inside it are delivered in sequence, except the ones sent using the unordered delivery service 🎀.
SCTP-over-DTLS: SCTP used on top of DTLS, as specified in [RFC8261] 🔐.

4. SDP Media Descriptions 🍓

4.1. General

This section defines the following new SDP media description ("m=" line) protocol identifiers (proto values) for describing an SCTP association: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". It also explains how an "m=" line tied to those proto values gets created 🌸.

The format for an "m=" line, as specified in [RFC4566], is:

m=<media> <port> <proto> <fmt> ...

The "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are a lot like "UDP" and "TCP" in one way: they only describe the transport-layer protocol, not the upper-layer protocol 🧚.

NOTE: When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are used, the underlying transport protocol is, respectively, UDP and TCP. SCTP is carried on top of DTLS, which sits on top of those transport-layer protocols 🫧.

4.2. Protocol Identifiers

The new proto values are defined like this:

The "UDP/DTLS/SCTP" proto value describes an SCTP association on top of a DTLS association on top of UDP, as defined in Section 7 💖.
The "TCP/DTLS/SCTP" proto value describes an SCTP association on top of a DTLS association on top of TCP, as defined in Section 8 💜.

4.3. Media-Format Management

[RFC4566] says that specs defining new proto values must define the rules for managing their media format (fmt) namespace. So here we go 📋.

An "m=" line with a proto value of "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" always describes a single SCTP association 🎯.

On top of that, such an "m=" line MUST further indicate the application-layer protocol using an "fmt" identifier. There MUST be exactly one fmt value per "m=" line tied to the proto values defined in this spec. The "fmt" namespace for those proto values describes the generic application usage of the entire SCTP association, including its SCTP streams 🫶.

When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are used, the "m=" line fmt value, which identifies the application-layer protocol, MUST be registered by IANA. Section 15.3 defines the IANA registry for the media-format namespace 🗂️.

NOTE: How to describe and manage individual SCTP streams inside an SCTP association is out of scope for this spec. [RFC8864] defines a mechanism for negotiating individual SCTP streams used to realize WebRTC data channels [RFC8831] 🌈.

4.4. Syntax

4.4.1. General

This section defines the values you can use inside an SDP media description ("m=" line) tied to an SCTP-over-DTLS association 📝.

This spec creates an IANA registry for "association-usage" values 🧾.

4.4.2. SDP Media Description Values

When the SCTP association is used to realize a WebRTC data channel [RFC8832], the <fmt> parameter value is 'webrtc-datachannel' 💬.

  +===========+===================================================+
  | "m=" line | parameter value(s)                                |
  | parameter |                                                   |
  +===========+===================================================+
  | <media>   | "application"                                     |
  +-----------+---------------------------------------------------+
  | <proto>   | "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"                |
  +-----------+---------------------------------------------------+
  | <port>    | UDP port number (for "UDP/DTLS/SCTP")             |
  |           | TCP port number (for "TCP/DTLS/SCTP")             |
  +-----------+---------------------------------------------------+
  | <fmt>     | A string denoting the association-usage, limited  |
  |           | to the syntax of a "token" as defined in RFC 4566 |
  +-----------+---------------------------------------------------+

Table 1: SDP Media Description Values 📊

4.5. Example

Here's what it looks like in the wild 👀:

m=application 12345 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port:5000
a=max-message-size:100000

NOTE: "webrtc-datachannel" indicates the WebRTC Data Channel Establishment Protocol defined in [RFC8832] 💅.

5.1. General ✨

okay bestie, this section introduces a brand new SDP media-level attribute called "sctp-port" 💖 It can hang off an SDP media description (that "m=" line) whenever the proto value is "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" 🦋 In that case the port on the "m=" line is the port of the underlying transport (UDP or TCP), and the "sctp-port" value is the SCTP port. Two ports, two jobs, super organized 💅

There is no default value for "sctp-port" 😭 So if the attribute isn't there, the "m=" line MUST be considered invalid. No attribute, no line, no cap.

⚠️ Heads up: this spec only covers using "sctp-port" with an "m=" line that has "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" as its proto value. Any other proto value needs its own separate spec 🙈

5.2. Syntax 🌸

Here's the registration template for "sctp-port", copied exactly so nobody can gaslight us later 🎀

Attribute name:  sctp-port

Type of attribute:  media

Mux category:  CAUTION

Subject to charset:  No

Purpose:  Indicate the SCTP port value associated with the SDP media
   description.

Appropriate values:  Integer

Contact name:  Christer Holmberg

Contact e-mail:  christer.holmberg@ericsson.com

Reference:  RFC 8841

Syntax:
   sctp-port-value = 1*5(DIGIT) ; DIGIT defined in RFC 4566

The SCTP port range is between 0 and 65535 (both included) 🍓 And leading zeroes MUST NOT be used, so no 0005 energy, bestie 💀

Example, because we love a good example ✨

a=sctp-port:5000

5.3. Mux Category 🦋

The mux category [RFC8859] for "sctp-port" is CAUTION 👀

Multiple SCTP associations stacked on a single DTLS association is outside the scope of this spec, so no mux rules are defined for "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" 🌈 BUT future extensions that figure out how to negotiate multiplexing of multiple SCTP associations on one DTLS association will also need to define mux rules for this attribute. Future-proofing is everything 💜

6. SDP "max-message-size" Attribute 🌈

6.1. General 💖

This section defines a new SDP media-level attribute called "max-message-size" ✨ It can be attached to an "m=" line to say the biggest SCTP user message (in bytes) that an SCTP endpoint is willing to receive on the SCTP association tied to that "m=" line. Each direction can have its own value, so you can be generous one way and strict the other 💅

An SCTP endpoint MUST NOT send an SCTP user message bigger than the size the peer indicated, because you can't just assume the peer will accept it 🙅‍♀️

If the "max-message-size" value is zero, that means the endpoint will handle messages of any size, subject to memory capacity, etc. Main character energy, no limits 👑

If the attribute isn't present, the default value is 64K 🍓

⚠️ Same deal as before: this spec only defines "max-message-size" for "m=" lines with "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" proto values. Other proto values need a separate spec 🙈

6.2. Syntax 🎀

The definition of the SDP "max-message-size" attribute, verbatim:

Attribute name:  max-message-size

Type of attribute:  media

Mux category:  CAUTION

Subject to charset:  No

Purpose:  Indicate the maximum message size (indicated in bytes) that
   an SCTP endpoint is willing to receive on the SCTP association
   associated with the SDP media description.

Appropriate values:  Integer

Contact name:  Christer Holmberg

Contact e-mail:  christer.holmberg@ericsson.com

Reference:  RFC 8841

Syntax:
   max-message-size-value = 1*DIGIT ; DIGIT defined in RFC 4566

Leading zeroes MUST NOT be used 💅

Example 🦋

a=max-message-size:100000

6.3. Mux Category 🌸

The mux category for "max-message-size" is CAUTION 🫶

Same as before: multiple SCTP associations on a single DTLS association is outside this spec's scope, so no mux rules are specified for "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" proto values 💫

7. UDP/DTLS/SCTP Transport Realization ✨

Okay so the UDP/DTLS/SCTP transport is built up in two layers 🧁

SCTP on top of DTLS is realized according to the procedures defined in [RFC8261]; and
DTLS on top of UDP is realized according to the procedures in [RFC6347].

⚠️ Note: [RFC8261] allows multiple SCTP associations on top of a single DTLS association, but THIS spec only supports negotiating a single SCTP association on top of any given DTLS association. One SCTP, one DTLS, no drama 🙅‍♀️

8. TCP/DTLS/SCTP Transport Realization 🧚

The TCP/DTLS/SCTP transport is also two layers, just a different bottom one 🌷

SCTP on top of DTLS is realized according to the procedures defined in [RFC8261]; and
DTLS on top of TCP is realized using the framing method defined in [RFC4571], with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in [RFC4571]. The length field defined in [RFC4571] precedes each DTLS message, and SDP signaling is done according to the procedures defined in this specification.

⚠️ Note: TLS on top of TCP WITHOUT the [RFC4571] framing method is outside the scope of this spec. A separate proto value would need to be registered for that kind of transport realization 🙈

9. Association and Connection Management 👑

9.1. General 💜

This section explains how to manage an SCTP association, DTLS association, and TCP connection using SDP attributes 🎀

These three are managed independently of each other. Each one can be established and closed without messing with the others. Independent queens 👸

The detailed SDP offer/answer [RFC3264] procedures for the SDP attributes are in Section 10 ✨

9.2. SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes 🙈

This spec doesn't define semantics for the SDP direction attributes [RFC4566]. Unless someone has defined what these attributes mean for an SCTP association usage, SDP direction attributes MUST be ignored if present. Ignored, bestie, they're not it 💀

9.3. SCTP Association 🦋

When an SCTP association is established, both SCTP endpoints MUST initiate it (both take the "active" role). Also, both endpoints MUST use the same SCTP port as client port AND server port, so that two separate SCTP associations can't get set up by accident 🫶

Since both endpoints take the "active" role, the SDP "setup" attribute [RFC4145] does NOT apply to SCTP association establishment 🙅‍♀️ The "setup" attribute DOES apply to establishing the underlying DTLS association and TCP connection, though.

⚠️ This is different from TCP, where one endpoint is "active", the other is "passive", and only the "active" one starts the TCP connection [RFC4145].

⚠️ Once the SCTP association is established, it's assumed that any NAT traversal procedures for the underlying transport protocol (UDP or TCP) have already been successfully performed 🌈

The SDP "connection" attribute [RFC4145] does NOT apply to the SCTP association. To close an existing SCTP association and set up a new one, the SDP "sctp-port" attribute (Section 5) carries a new SCTP port (one that's different from the ones currently in use). If one or both endpoints signal a new SCTP port, the existing SCTP association gets closed and a new one gets established 🔥 The "connection" attribute DOES apply to setting up the underlying TCP connections.

You can also close an SCTP association by using the SDP "sctp-port" attribute with a value of zero 🍓 Later on, a new SCTP association can be established using the procedures in this section for establishing an SCTP association.

SCTP associations might get closed without any SDP signaling (say, after a failure) 😭 The procedures in this section MUST be followed to establish a new SCTP association. This needs a new SDP offer/answer exchange. And the new SCTP ports (different from the ones currently used) MUST be used by both endpoints 💖

⚠️ Closing and establishing a new SCTP association with the SDP "sctp-port" attribute will NOT affect the state of the underlying DTLS association ✨

9.4. DTLS Association (UDP/DTLS/SCTP and TCP/DTLS/SCTP) 🌸

A DTLS association is managed according to the procedures in [RFC8842]. So the SDP "setup" attribute is used to negotiate the (D)TLS roles ("client" and "server") [RFC8122] 🎀

⚠️ The SDP "setup" attribute negotiates both the DTLS roles AND the TCP roles (Section 9.5) 👯‍♀️

⚠️ As described in [RFC8445], if the Interactive Connectivity Establishment (ICE) mechanism [RFC8445] is used, all ICE candidates tied to a DTLS association count as part of the same DTLS association. So switching from one candidate pair to another will NOT trigger a new DTLS association 🦋

9.5. TCP Connection (TCP/DTLS/SCTP) 🧚

The TCP connection is managed according to the procedures in [RFC4145]. So the SDP "setup" attribute negotiates the TCP roles ("active" and "passive"), and the SDP "connection" attribute says whether to reuse an existing TCP connection or make a new one 💅 The SDP "setup" attribute value "holdconn" MUST NOT be used 🙅‍♀️

⚠️ A change of TCP roles will also close the DTLS association and set up a new one, following the procedures in [RFC8842] 🌈

⚠️ As [RFC8842] specifies, the SDP "setup" attribute value "holdconn" is not allowed. So this spec forbids it for TCP too, since DTLS rides on top of TCP 🙈

10. SDP Offer/Answer Procedures 💜

10.1. General ✨

This section defines the SDP Offer/Answer [RFC3264] procedures for negotiating and setting up an SCTP-over-DTLS association 🫶 Unless it's explicitly said otherwise, these procedures apply to both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" "m=" line proto values.

Each endpoint MUST associate one or more certificate fingerprints with the "m=" line using the SDP "fingerprint" attribute, following the procedures in [RFC8122] 🔐

The authentication certificates are interpreted and validated as defined in [RFC8122]. Self-signed certificates can be used securely, as long as the integrity of the SDP description is assured, as defined in [RFC8122] 🌸

Each endpoint MUST associate an SDP "tls-id" attribute with the "m=" line, following the procedures in [RFC8842] 💖

10.2. Generating the Initial SDP Offer 🦋

When the offerer creates an initial offer, the offerer:

MUST associate an SDP "setup" attribute with the "m=" line;
MUST associate an SDP "sctp-port" attribute with the "m=" line;
MUST, in the case of TCP/DTLS/SCTP, associate an SDP "connection" attribute, with a "new" attribute value, with the "m=" line; and
MAY associate an SDP "max-message-size" attribute (Section 6) with the "m=" line.

10.3. Generating the SDP Answer 💌

okay so the answerer gets an offer with an "m=" line describing an SCTP-over-DTLS association 👀. If the answerer accepts that association, the answerer:

MUST insert a matching "m=" line in the answer, with an "m=" line proto value [RFC3264] identical to the value in the offer 🎀;
MUST associate an SDP "setup" attribute with the "m=" line 🧷;
MUST associate an SDP "sctp-port" attribute with the "m=" line 💅. If the offer contained a new SCTP port value (different than the one currently used), the answerer MUST also associate a new SCTP port value. If the offer contained a zero SCTP port value, or if the answerer does not accept the SCTP association, the answerer MUST also associate a zero SCTP port value; and
MAY associate an SDP "max-message-size" attribute (Section 6) with the "m=" line. The attribute value in the answer is independent of the value (if present) in the corresponding "m=" line of the offer ✨.

Once the answerer has sent the answer, the connection stuff kicks in 🦋:

in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established or an existing TCP connection is to be closed and replaced by a new one, the answerer MUST follow the procedures in [RFC4145] for closing and establishing a TCP connection;
if a DTLS association has not yet been established or an existing DTLS association is to be closed and replaced by a new one, the answerer MUST follow the procedures in [RFC8842] for closing the currently used DTLS association and establishing a new one; and
if an SCTP association has not yet been established or an existing SCTP association is to be closed and replaced by a new one, the answerer MUST initiate the closing of the existing SCTP association (if applicable) and establishment of the new association 🌸.

If the SDP "sctp-port" attribute in the answer contains an attribute value of zero, the answerer MUST NOT establish an SCTP association 🙅‍♀️. If an SCTP association exists, the offerer MUST close it.

If the answerer does not accept the "m=" line in the offer, it MUST assign a zero port value to the corresponding "m=" line in the answer, following the procedures in [RFC3264]. In addition, the answerer MUST NOT initiate the establishment of a TCP connection, a DTLS association, or a DTLS association associated with the "m=" line. Not me rejecting the whole thing 💀.

10.4. Offerer Processing of the SDP Answer 🧁

Once the offerer has received the answer, it's the offerer's turn to do the same dance 💃:

in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established or an existing TCP connection is to be closed and replaced by a new one, the offerer MUST follow the procedures in [RFC4145] for closing and establishing a TCP connection;
if a DTLS association has not yet been established or an existing DTLS association is to be closed and replaced by a new one, the offerer MUST follow the procedures in [RFC8842] for closing and establishing a DTLS association; and
if an SCTP association has not yet been established or an existing SCTP association is to be closed and replaced by a new one, the offerer MUST initiate the closing of the existing SCTP association (if applicable) and establishment of the new association.

If the SDP "sctp-port" attribute in the answer contains an attribute value of zero, the offerer MUST NOT establish an SCTP association. If, in addition, an SCTP association exists, the offerer MUST close it.

If the "m=" line in the answer contains a zero port value, the offerer MUST NOT initiate the establishment of a TCP connection, a DTLS association, or an SCTP association associated with the "m=" line. If, in addition, a TCP connection, DTLS association, or SCTP association exists, the offerer MUST close it 🫶.

10.5. Modifying the Session 🔄

When an offerer sends an updated offer to modify a previously established SCTP association, it follows the procedures in Section 10.2, with the following exceptions 🎀:

If the offerer wants to close an SCTP association and immediately establish a new SCTP association, it MUST associate an SDP "sctp-port" attribute with a new (different than the one currently used) attribute value. This will not impact the underlying DTLS association (or TCP connection, in the case of TCP/DTLS/SCTP).
If the offerer wants to close an SCTP association without immediately establishing a new SCTP association, it MUST associate an SDP "sctp-port" attribute with an attribute value of zero. This will not impact the underlying DTLS association (or TCP connection, in the case of TCP/DTLS/SCTP).
If the offerer wants to establish an SCTP association, and another SCTP association was previously closed, the offerer MUST associate an SDP "sctp-port" attribute with a new attribute value (different than the value associated with the previous SCTP association). If the previous SCTP association was closed successfully following use of an SDP "sctp-port" attribute with an attribute value of zero, the offerer MAY use the same attribute value for the new SCTP association that was used with the previous SCTP association before it was closed. This will not impact the underlying DTLS association (or TCP connection, in the case of TCP/DTLS/SCTP).
If the offerer wants to close an existing SCTP association and the underlying DTLS association (and the underlying TCP connection, in the case of TCP/DTLS/SCTP), it MUST assign a zero port value to the "m=" line associated with the SCTP and DTLS associations (and TCP connection, in the case of TCP/DTLS/SCTP), following the procedures in [RFC3264].
NOTE: This specification does not define a mechanism for explicitly closing a DTLS association while maintaining the overlying SCTP association. However, if a DTLS association is closed and replaced with a new DTLS association as a result of some other action [RFC8842], the state of the SCTP association is not affected 🧐.

The offerer follows the procedures in [RFC8842] regarding the DTLS association impacts when modifying a session. In the case of TCP/DTLS/SCTP, the offerer follows the procedures in [RFC4145] regarding the TCP connection impacts when modifying a session.

11. Multihoming Considerations 🏠

Multihoming is not supported when sending SCTP on top of DTLS, as DTLS does not expose address management of the underlying transport protocols (UDP or TCP) to its upper layer 🙈.

12. NAT Considerations 🌐

12.1. General

When SCTP-over-DTLS is used in a NAT environment, it relies on the NAT traversal procedures for the underlying transport protocol (UDP or TCP) 🧭.

12.2. ICE Considerations 🧊

When SCTP-over-DTLS is used with UDP-based ICE candidates [RFC8445], then the procedures for UDP/DTLS/SCTP (Section 7) are used.

When SCTP-over-DTLS is used with TCP-based ICE candidates [RFC6544], then the procedures for TCP/DTLS/SCTP (Section 8) are used.

In ICE environments, during the nomination process, endpoints go through multiple ICE candidate pairs until the most preferred candidate pair is found. During the nomination process, data can be sent as soon as the first working candidate pair is found, but the nomination process still continues, and selected candidate pairs can still change while data is sent. Furthermore, if endpoints roam between networks (for instance, when a mobile endpoint switches from mobile connection to WiFi), endpoints will initiate an ICE restart. This will trigger a new nomination process between the new set of candidates, which will likely result in the new nominated candidate pair 📡.

Implementations MUST treat all ICE candidate pairs associated with an SCTP association on top of a DTLS association as part of the same DTLS association. Thus, there will only be one SCTP handshake and one DTLS handshake even if there are multiple valid candidate pairs; shifting from one candidate pair to another, including switching between UDP and TCP candidate pairs, will not impact the SCTP or DTLS associations. If new candidates are added, they will also be part of the same SCTP and DTLS associations. When transitioning between candidate pairs, different candidate pairs can be currently active in different directions, and implementations MUST be ready to receive data on any of the candidates, even if this means sending and receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in different directions 🪄.

In order to maximize the likelihood of interoperability between the endpoints, all ICE-enabled SCTP-over-DTLS endpoints SHOULD implement support for UDP/DTLS/SCTP 🤝.

When an SDP offer or answer is sent with multiple ICE candidates during initial connection negotiation or after ICE restart, UDP-based candidates SHOULD be included, and the default candidate SHOULD be chosen from one of those UDP candidates. The proto value MUST match the transport protocol associated with the default candidate. If UDP transport is used for the default candidate, then the "UDP/DTLS/SCTP" proto value MUST be used. If TCP transport is used for the default candidate, then the "TCP/DTLS/SCTP" proto value MUST be used. Note that under normal circumstances, the proto value for offers and answers sent during ICE nomination SHOULD be "UDP/DTLS/SCTP" 🦋.

When a subsequent SDP offer or answer is sent after ICE nomination is complete, and it does not initiate ICE restart, it will contain only the nominated ICE candidate pair. In this case, the proto value MUST match the transport protocol associated with the nominated ICE candidate pair. If UDP transport is used for the nominated pair, then the "UDP/DTLS/SCTP" proto value MUST be used. If TCP transport is used for the nominated pair, then the "TCP/DTLS/SCTP" proto value MUST be used. Please note that if an endpoint switches between TCP-based and UDP-based candidates during the nomination process, the endpoint is not required to send an SDP offer for the sole purpose of keeping the proto value of the associated "m=" line in sync 💖.

NOTE: The text in the paragraph above only applies when the usage of ICE has been negotiated. If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time. 🚨

13. Examples ✨

13.1. Establishment of UDP/DTLS/SCTP Association ✨

okay bestie, here's the full handshake in action 🦋 the offerer is first up:

SDP Offer:

m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::A8FD
a=tls-id:abc3de65cddef001be82
a=setup:actpass
a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=sctp-port:5000
a=max-message-size:100000

the offerer says the UDP/DTLS/SCTP association is going to be used as defined for the "webrtc-datachannel" format value 🎀
the offerer's UDP port is 54111 💜
the offerer's SCTP port is 5000 ✨
the offerer says it can take either the client or the server DTLS role, so it's super flexible 🫶

SDP Answer:

m=application 64300 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::001D
a=tls-id:dbc8de77cddef001be90
a=setup:passive
a=fingerprint:SHA-256 \
3F:82:18:3B:49:6B:19:E5:7C:AB:4A:AD:B9:B1:12:DF:3E:5D:12:DF:54:02: \
49:6B:3E:5D:7C:AB:19:E5:AD:4A
a=sctp-port:6000
a=max-message-size:100000

quick heads up 🙈 the RFC formatting rules mean this doc splits the SDP across lines that would go past 72 characters. the backslash marks where that folding happened. the backslash, its trailing CRLF, and any whitespace would NOT show up in real SDP content, so don't copy them over!

the answerer's UDP port is 64300 🌸
the answerer's SCTP port is 6000 🧚
the answerer takes the server DTLS role 👑

14. Security Considerations 🔒

okay so [RFC4566] is the one with the general SDP security stuff, while [RFC3264], [RFC4145], and [RFC8122] cover the security bits when you're using the SDP offer/answer mechanism to negotiate media streams. it's giving thorough 🧐

[RFC4960] has the general SCTP security considerations, and [RFC8261] covers the security considerations for running SCTP on top of DTLS. literally a whole security team in one paragraph 💅

This specification does not introduce new security considerations in addition to those defined in the specifications listed above. so no new risks from this doc itself, but the ones in those other specs are still very much in play 😭🔥

15. IANA Considerations 🌈

15.1. New SDP Proto Values

this doc updates the "Session Description Protocol (SDP) Parameters" registry, following the procedures in [RFC4566]. we're adding these two values to the table in the SDP "proto" field registry 🦋

                   +=======+===============+===========+
                   |  Type |    SDP Name   | Reference |
                   +=======+===============+===========+
                   | proto | UDP/DTLS/SCTP |  RFC 8841 |
                   +-------+---------------+-----------+
                   | proto | TCP/DTLS/SCTP |  RFC 8841 |
                   +-------+---------------+-----------+

                     Table 2: SDP "proto" Field Values

15.2. New SDP Attributes ✨

15.2.1. sctp-port

this doc defines a brand new SDP media-level attribute called "sctp-port". all the details live in Section 5.2 🎀

15.2.2. max-message-size

this doc also defines a new SDP media-level attribute called "max-message-size". the full scoop is in Section 6.2 💖

15.3. association-usage Name Registry 💜

okay this one is new. this spec creates an IANA registry, following the procedures in [RFC8126], for the namespace tied to the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" protocol identifiers. each fmt value describes how an entire SCTP association gets used, including every SCTP stream inside that association 🧚

      |  NOTE: Usage indication of individual SCTP streams is outside
      |  the scope of this specification.

the fmt value "association-usage" used with these "proto" values is required. it's defined in Section 4 🫶

IANA keeps track of the following info for this registry:

association-usage name: the identifier of the subprotocol, which will be used as the fmt value 🌸
association-usage reference: a reference to the document where the association-usage is defined 📚

association-usage names are going to be subject to the "First Come First Served" IANA registration policy [RFC8126]. first come, first served, periodt 💅

IANA has already added the following initial value to the registry:

            +====================+====================+
            | Name               | Reference          |
            +====================+====================+
            | webrtc-datachannel | RFC 8832, RFC 8841 |
            +--------------------+--------------------+
            +--------------------+--------------------+

                    Table 3: IANA Initial Values

16. References 📚

16.1. Normative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.

[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-editor.org/info/rfc4145>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <https://www.rfc-editor.org/info/rfc4571>.

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.

[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, <https://www.rfc-editor.org/info/rfc8261>.

[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, <https://www.rfc-editor.org/info/rfc8842>.

[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.

16.2. Informative References

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.

[RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832, January 2021, <https://www.rfc-editor.org/info/rfc8832>.

[RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>.

Acknowledgements 🫶

big thank-yous to Harald Alvestrand, Randell Jesup, Paul Kyzivat, Michael Tüxen, Juergen Stoetzer-Bradler, Flemming Andreasen, and Ari Keränen for their comments and useful feedback 💖 Ben Campbell gave comments as part of his Area Director review, and Brian Carpenter did the Gen-ART review 🌈

Authors' Addresses 💌

Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: christer.holmberg@ericsson.com


Roman Shpount
TurboBridge
4905 Del Ray Avenue, Suite 300
Bethesda, MD 20814
United States of America

Phone: +1 (240) 292-6632
Email: rshpount@turbobridge.com


Salvatore Loreto
Ericsson
Grönlandsgatan 31
Kista
Sweden

Email: Salvatore.Loreto@ericsson.com


Gonzalo Camarillo
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: Gonzalo.Camarillo@ericsson.com

📦 where this page comes from

ietf: rfc8841 2021-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms