Skip to main content

5. SCTP over DTLS over UDP Considerations

The important features of SCTP in the WebRTC context are the following:

  • Usage of TCP-friendly congestion control.
  • Modifiable congestion control for integration with the SRTP media stream congestion control.
  • Support of multiple unidirectional streams, each providing its own notion of ordered message delivery.
  • Support of ordered and out-of-order message delivery.
  • Support of arbitrarily large user messages by providing fragmentation and reassembly.
  • Support of PMTU discovery.
  • Support of reliable or partially reliable message transport.

The WebRTC data channel mechanism does not support SCTP multihoming. The SCTP layer will simply act as if it were running on a single-homed host, since that is the abstraction that the DTLS layer (a connection-oriented, unreliable datagram service) exposes.

The encapsulation of SCTP over DTLS defined in [RFC8261] provides confidentiality, source authentication, and integrity-protected transfers. Using DTLS over UDP in combination with Interactive Connectivity Establishment (ICE) [RFC8445] enables middlebox traversal in IPv4- and IPv6-based networks. SCTP as specified in [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and provides the following features for transporting non-media data between browsers:

  • Support of multiple unidirectional streams.
  • Ordered and unordered delivery of user messages.
  • Reliable and partially reliable transport of user messages.

Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTC context, the PPID is used to distinguish between UTF-8 encoded user data, binary-encoded user data, and the Data Channel Establishment Protocol (DCEP) defined in [RFC8832]. Please note that the PPID is not accessible via the JavaScript API.

The encapsulation of SCTP over DTLS, together with the SCTP features listed above, satisfies all the requirements listed in Section 4.

The layering of protocols for WebRTC is shown in Figure 2.

              +------+------+------+
              | DCEP | UTF-8|Binary|
              |      | Data | Data |
              +------+------+------+
              |        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|                ICE               |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ...         |
+----------------------------------+

Figure 2: WebRTC Protocol Layers

This stack (especially in contrast to DTLS over SCTP [RFC6083] and in combination with SCTP over UDP [RFC6951]) has been chosen for the following reasons:

  • supports the transmission of arbitrarily large user messages;
  • shares the DTLS connection with the SRTP media channels of the PeerConnection; and
  • provides privacy for the SCTP control information.

Referring to the protocol stack shown in Figure 2:

  • the usage of DTLS 1.0 over UDP is specified in [RFC4347];
  • the usage of DTLS 1.2 over UDP in specified in [RFC6347];
  • the usage of DTLS 1.3 over UDP is specified in an upcoming document [TLS-DTLS13]; and
  • the usage of SCTP on top of DTLS is specified in [RFC8261].

Please note that the demultiplexing Session Traversal Utilities for NAT (STUN) [RFC5389] vs. SRTP vs. DTLS is done as described in Section 5.1.2 of [RFC5764], and SCTP is the only payload of DTLS.

Since DTLS is typically implemented in user application space, the SCTP stack also needs to be a user application space stack.

The ICE/UDP layer can handle IP address changes during a session without needing interaction with the DTLS and SCTP layers. However, SCTP SHOULD be notified when an address change has happened. In this case, SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state. In the case of window-based congestion control like the one specified in [RFC4960], this means setting the congestion window and slow-start threshold to its initial values.

Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore, SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] by using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 bytes for IPv6.

In general, the lower-layer interface of an SCTP implementation should be adapted to address the differences between IPv4 and IPv6 (being connectionless) or DTLS (being connection oriented).

When the protocol stack shown in Figure 2 is used, DTLS protects the complete SCTP packet, so it provides confidentiality, integrity, and source authentication of the complete SCTP packet.

SCTP provides congestion control on a per-association basis. This means that all SCTP streams within a single SCTP association share the same congestion window. Traffic not being sent over SCTP is not covered by SCTP congestion control. Using a congestion control different from the standard one might improve the impact on the parallel SRTP media streams.

SCTP uses the same port number concept as TCP and UDP. Therefore, an SCTP association uses two port numbers, one at each SCTP endpoint.

Last updated on