]> Meta Platforms Inc.

philipp.hancke@googlemail.com

OpenAI

justin@uberti.name

Google

boivie@google.com

AREA Transport and Services Working Group sctp webrtc sdp WebRTC Data Channels use the Stream Control Transmission Protocol (SCTP) over a Datagram Transport Layer Security (DTLS) association. The standard SCTP connection establishment requires a handshake that introduces latency. This document specifies a method to accelerate the datachannel establishment by embedding the SCTP initialization parameters within the Session Description Protocol (SDP) offer/answer exchange. This reduces the time required to open a data channel by up to two network round-trip times. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines WebRTC Data Channels that allow the transport of arbitrary non-media data over a WebRTC PeerConnection. This uses SCTP and a DTLS encapsulation of SCTP packets . SCTP establishes its associations using a four-way handshake, which primarily serves to protect against half-open (SYN-flood) attacks. For WebRTC, SCTP runs encapsulated within DTLS , which establishes a secure, encrypted channel between the peers that prevents half-open attacks. The full connection setup between two entities using WebRTC, consisting of the exchange of SDP over the signaling channel, ICE and DTLS establishment and the SCTP handshake, is shown below (with annotations for the number of full round trips): | |<-1---------- SDP Answer -------------------| | | |<-2---------- ICE/Connectivity Checks ----->| | | |<------------ DTLS ClientHello -------------| |--3---------- DTLS ServerHello ------------>| |<------------ DTLS Finished ----------------| |--4---------- DTLS Finished --------------->| | | |------------- SCTP INIT ------------------->| |<-5---------- SCTP INIT ACK ----------------| |------------- SCTP COOKIE ECHO ------------>| |<-6---------- SCTP COOKIE ACK --------------| | | |------------- DCEP (Open Channel) --------->| |------------- "hello world"---------------->| |<------------ DCEP ACK ---------------------| | | ]]> Note that SCTP typically does a "simultaneous open", i.e. both sides take the active role, although only one direction is shown here for simplicity. Note: allows the packets with the COOKIE ECHO and COOKIE ACK to carry data. This means the second RTT is not strictly necessary but was observed in practice. When the SCTP INIT chunk is signaled in the SDP, using the "sctp-init" attribute described in this document, this flow can be reduced to the following exchange: | |<-1---------- SDP Answer (sctp-init)--------| | | |<-2---------- ICE/Connectivity Checks ----->| | | |<------------ DTLS ClientHello -------------| |--3---------- DTLS ServerHello ------------>| |<------------ DTLS Finished ----------------| |--4---------- DTLS Finished --------------->| | | |------------- DCEP (Open Channel) --------->| |------------- "hello world"---------------->| |<------------ DCEP ACK ---------------------| | | ]]>

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Terminology SCTP INIT: the SCTP INIT chunk as described in . SCTP INIT ACK: the SCTP INIT ACK chunk as described in . SCTP COOKIE ECHO: the SCTP COOKIE ECHO chunk as described in . SCTP COOKIE ACK: the SCTP COOKIE ACK chunk as described in . RTT: Round-Trip Time

SDP sctp-init attribute

General This section defines a new SDP media-level attribute, "sctp-init". The attribute can be associated with an SDP media description ("m=" line) with a "UDP/DTLS/SCTP" protocol identifier (defined in ) and the <fmt> parameter value of 'webrtc-datachannel' (defined in ). NOTE: This specification only defines the usage of the SDP "sctp-init" attribute when associated with an "m=" line containing one of the following proto values: "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP". Usage of the attribute with other proto values needs to be defined in a separate specification. An example follows, see for the full SDP exchange: This is equivalent to the following SCTP INIT chunk:

Syntax Attribute name: sctp-init Type of attribute: media Mux category: CAUTION Subject to charset: No Purpose: allows the SDP to carry the information contained in a SCTP INIT chunk Appropriate values: A base64-encoded value. The encoded octets are the INIT chunk exactly as defined in , including its network byte order. An implementation generating the value MAY include the trailing chunk padding described in . An implementation parsing the value MUST accept it both with and without the trailing padding. Syntax: sctp-init-value = base64 ; base64 defined in RFC 4566

SDP Offer/Answer Procedures

General This section defines how the "sctp-init" attribute can be negotiated using the SDP offer/answer mechanism.

Generating the Initial SDP Offer If the offering endpoint has created a WebRTC data channel, it MUST let the SCTP implementation generate a serialized INIT chunk that it would normally send over the network as a series of bytes. This message is then base64-encoded and added to the data "m=" section as an "a=sctp-init" line.

Answerer Processing of the SDP Offer If the answering endpoint negotiates a data "m=" section, it will parse the "a=sctp-init" line from the data "m=" section, if present. If the data is not properly base64-encoded this results in an error. The answering endpoint then informs its SCTP implementation of the series of bytes. The SCTP implementation is responsible for validating the format of the SCTP INIT chunk. If the series of bytes is not a valid SCTP INIT chunk this results in an error.

Generating the SDP Answer An endpoint not supporting the extension described in this document MUST NOT include a "a=sctp-init" attribute in its answer. If the answering endpoint negotiated a data "m=" section and detected a valid "a=sctp-init" line in the offer, as described above, it MUST let its SCTP implementation generate a serialized INIT chunk that it would normally send over the network as a series of bytes. This message is base64-encoded and added to the data "m=" section as a "a=sctp-init" line.

Offerer Processing of the SDP Answer If the answer negotiated a data "m=" section, the offering endpoint parses the "a=sctp-init" line, if present, from the data "m=" section. If the data is not properly base64-encoded this results in an error. The offering endpoint then informs its SCTP implementation of the series of bytes. The SCTP implementation is responsible for validating the format of the SCTP INIT chunk. If the series of bytes is not a valid SCTP INIT chunk this results in an error.

Modifying the Session Subsequent offers and answers MUST include the "a=sctp-init" line in the negotiated SDP with the same value as in the initial negotiation. Remote offers MAY negotiate a new "a=sctp-init" line in conjunction with either

• a new SCTP association as described in
• or a new DTLS association as described in .

Attempting to add an sctp-init attribute to an existing SCTP association results in an error.

SCTP considerations The creation of the "sctp-init" attribute SHOULD NOT change the state of the SCTP association into the COOKIE-WAIT state as described in and SHOULD NOT start the T1-init timer. Processing of the "sctp-init" attribute from the remote side SHOULD NOT change the state of the SCTP association and SHOULD NOT start any timer. When the "sctp-init" attribute has been negotiated and the DTLS handshake finishes, both endpoints initialize the SCTP association from the local and remote INIT chunks in the same way as from the INIT and INIT ACK chunks of a regular handshake, e.g. for the number of streams (see ). The association then SHOULD be considered to be in the ESTABLISHED state, as described in . The steps A-E described in can be skipped.

Example negotiation The offering client generates a SCTP INIT chunk with its supported parameters: This is encoded in the offer SDP as follows: In response, the answering client generates its SCTP INIT chunk with its supported parameters: This yields an answer SDP shown below:

Security Considerations SNAP removes SCTP's anti-amplification mechanism in order to accelerate connection startup. However, when SCTP runs atop DTLS as specified in , any attempt to send junk traffic over SCTP will fail as it will not be properly encrypted. Therefore SNAP does not add any new amplification risk. Exposing the content of the SCTP INIT chunk, in particular the "Initiate Tag", in the SDP does not introduce new security concerns since running SCTP atop DTLS protects against the off-path attacks described in . Exposing the content of the SCTP init tag to the application layer, e.g., JavaScript applications or the signaling channel in the case of WebRTC does allow these to add or remove variable-length parameters. Since these parameters are optional and used for feature negotiation, removing one is equivalent to the remote side not supporting the parameter and does not introduce a new security risk. Adding a parameter that is not supported may cause the remote side to send those but this is equivalent to receiving a packet for a feature that was not negotiated and hence does not introduce a new security concern.

IANA Considerations

New SDP attributes This document defines a new SDP media-level attribute, "sctp-init". The details of the attribute are defined in .

References Normative References This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed. The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete. The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations. This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, "tls-id". This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.

Acknowledgments The authors wish to thank Harald Alvestrand, Lennart Grahl, Jonas Oreland and Michael Tuexen for their invaluable comments.