RFC 8835

Transports for WebRTC

📅 published January 2021, from ietf

RFC 8835: Transports for WebRTC 🎀✨

Okay bestie, let's get into it. This is RFC 8835, and it's giving "the transport layer rules for WebRTC" 💅. It's a Standards Track doc from the IETF, written by H. Alvestrand at Google, and it was published in January 2021. It's an official IETF spec, not just vibes, and it doesn't obsolete or update any other RFCs 🦋. The ISSN is 2070-1721 if you're into that kind of thing 🤓.

Abstract

This doc describes the data transport protocols that WebRTC uses 🌈, including the protocols for talking to middleboxes like firewalls, relays, and NAT boxes 🧚.

Status of This Memo

This is an Internet Standards Track document 💜. It's a product of the IETF, it represents consensus from the IETF community, and it went through public review and got approved by the IESG. If you want more info on Internet Standards, check Section 2 of RFC 7841 🍓.

Info about the current status, errata, and feedback lives at https://www.rfc-editor.org/info/rfc8835 ✨.

Copyright (c) 2021 IETF Trust and 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) as they were on the publication date. Read those carefully, bestie, because they set out your rights and restrictions 🫶. Any Code Components pulled from this doc need Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty 🔥.

Table of Contents

1. Introduction 2. Requirements Language 3. Transport and Middlebox Specification 3.1. System-Provided Interfaces 3.2. Ability to Use IPv4 and IPv6 3.3. Usage of Temporary IPv6 Addresses 3.4. Middlebox-Related Functions 3.5. Transport Protocols Implemented 4. Media Prioritization 4.1. Local Prioritization 4.2. Usage of Quality of Service -- DSCP and Multiplexing 5. IANA Considerations 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgements Author's Address

1. Introduction 🌸

WebRTC is a protocol suite for real-time multimedia exchange 🎥. It works between browsers, and between browsers and other entities too 👑.

WebRTC is described in the WebRTC overview document [RFC8825], which also defines the terms "WebRTC endpoint" and "WebRTC browser" 💅. Terminology for RTP sources comes from [RFC7656] 🧚.

This doc focuses on the data transport protocols that conforming implementations use 🦋. That includes the protocols for talking to intermediate boxes like firewalls, relays, and NAT boxes 🍓.

This protocol suite is meant to satisfy the security considerations in the WebRTC security documents, [RFC8826] and [RFC8827] 🔥. Lowkey important stuff 🙈.

This document describes requirements that apply to all WebRTC endpoints 💖. When something only applies to WebRTC browsers, the doc calls it out explicitly ✨.

2. Requirements Language 🫶

Okay, so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174] 💜. But only when they show up in all capitals, exactly like that 🌈. Lowercase versions are just regular words, no cap 💀.

3. Transport and Middlebox Specification 👑

3.1. System-Provided Interfaces 💅

The protocol specs here assume these protocols are available to WebRTC implementations 🎀:

UDP [RFC0768]: This is the protocol assumed by most protocol elements described 🦋.

TCP [RFC0793]: This is used for HTTP/WebSockets, as well as TURN/TLS and ICE-TCP 🧚.

Both protocols are assumed to support IPv4 and IPv6 🌈.

For UDP, the spec assumes you can set the Differentiated Services Code Point (DSCP) on sockets opened on a per-packet basis 🍓. That's how you get the prioritizations described in [RFC8837] (see Section 4.2 of this doc) when multiple media types are multiplexed ✨. It does not assume the DSCPs will be honored 💀. It does assume they may be zeroed or changed, since that's a local configuration issue 🫶.

Platforms that don't give access to these interfaces won't be able to support a conforming WebRTC endpoint 🙈. Not it 💅.

This spec does not assume the implementation has access to ICMP or raw IP 🔥.

These protocols may be used, but a WebRTC endpoint can implement them itself, so they aren't defined as "system-provided interfaces" 💖:

TURN: Traversal Using Relays Around NAT [RFC8656] 🧚

STUN: Session Traversal Utilities for NAT [RFC5389] 🦋

ICE: Interactive Connectivity Establishment [RFC8445] 💜

TLS: Transport Layer Security [RFC8446] 🌸

DTLS: Datagram Transport Layer Security [RFC6347] ✨

3.2. Ability to Use IPv4 and IPv6 🌈

Web apps running in a WebRTC browser MUST be able to use both IPv4 and IPv6 where available 👑. So if two peers only have IPv4 connectivity to each other, or only IPv6 connectivity, apps in the WebRTC browser MUST still be able to communicate 😭. No excuses, periodt 💅.

When TURN is used, and the TURN server has IPv4 or IPv6 connectivity to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported 🎀. The "Happy Eyeballs" spec for ICE [RFC8421] SHOULD be supported 🦋.

3.3. Usage of Temporary IPv6 Addresses 🧚

Okay this one is giving privacy 🙈. The IPv6 default address selection spec [RFC6724] says temporary addresses [RFC4941] are preferred over permanent addresses ✨. That's a change from the rules in [RFC3484] 💅. For apps that pick a single address, this is usually handled by the IPV6_PREFER_SRC_TMP preference flag from [RFC5014] 🌈.

But here's the tea: this rule is meant to make sure privacy-enhanced addresses get used over static ones, and it doesn't quite work in ICE 💀. ICE gathers all addresses and reveals them to the app, so the rule doesn't have the right effect 🍓. So the doc applies this rule instead 🔥:

When a WebRTC endpoint gathers all IPv6 addresses on its host, and both nondeprecated temporary addresses and permanent addresses of the same scope are present, the WebRTC endpoint SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724].
If some, but not all, of the temporary IPv6 addresses are marked deprecated, the WebRTC endpoint SHOULD discard the deprecated addresses, unless they are used by an ongoing connection. In an ICE restart, deprecated addresses that are currently in use MAY be retained.

The main way to handle middleboxes is ICE 💜. It's the right tool for NAT boxes and firewalls that accept traffic from the inside, but only let outside traffic in if it's responding to inside traffic (simple stateful firewalls) 🌸.

ICE [RFC8445] MUST be supported ✨. The implementation MUST be a full ICE implementation, not ICE-Lite 👑. A full ICE implementation can interwork with both ICE and ICE-Lite implementations when they're deployed properly 🫶.

For situations where both parties are behind NATs that do endpoint-dependent mapping (as defined in Section 2.4 of [RFC5128]), TURN [RFC8656] MUST be supported 🔥.

WebRTC browsers MUST support configuring STUN and TURN servers, from both browser configuration and an application 🎀.

Other work exists around STUN and TURN server discovery and management, including [RFC8155] for server discovery, and [RETURN] 🧚.

For firewalls that block all UDP traffic, the mode of TURN that uses TCP between the WebRTC endpoint and the TURN server MUST be supported 😭. The mode of TURN that uses TLS over TCP between the WebRTC endpoint and the TURN server MUST also be supported 💖. See Section 3.1 of [RFC8656] for details 🦋.

For situations where one party is on an IPv4 network and the other is on an IPv6 network, TURN extensions for IPv6 MUST be supported 🌈.

TURN TCP candidates, where the connection from the WebRTC endpoint's TURN server to the peer is a TCP connection, [RFC6062] MAY be supported 🍓.

However, these candidates aren't seen as giving any significant benefit, for a few reasons 💅.

First, TURN TCP candidates would only matter when both peers are required to use TCP to set up a connection 🙈.

Second, that use case is handled a different way, by both sides setting up UDP relay candidates using TURN over TCP to connect to their relay servers 🧚.

Third, using TCP between the WebRTC endpoint's TURN server and the peer may cause more performance problems than UDP, e.g., because of head of line blocking 💀.

ICE-TCP candidates [RFC6544] MUST be supported 🔥. This may let apps talk to peers with public IP addresses across UDP-blocking firewalls without using a TURN server ✨.

If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets 🫶. That includes RTP packets, DTLS packets carrying data channels, and STUN connectivity check packets 🌸.

The ALTERNATE-SERVER mechanism in Section 11 of [RFC5389] (300 Try Alternate) MUST be supported 👑.

The WebRTC endpoint MAY support accessing the Internet through an HTTP proxy 💜. If it does, it MUST include the "ALPN" header as specified in [RFC7639] 🎀, and proxy authentication as described in Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported 😭.

Part 1 of 3. More parts coming, so stay tuned, bestie 💖🦋

Okay bestie, picking up right where we left off 💖 Section 3.5 is where the transport stuff gets really real, so let's go! ✨

3.5. Transport Protocols Implemented 🎀

Okay so for moving media around, we use secure RTP 🦋. The full scoop on the RTP profile is in "Media Transport and Use of RTP in WebRTC" [RFC8834], which MUST use a circuit breaker [RFC8083] and congestion control (check out [RFC8836] if you want more guidance, it's giving very helpful vibes 💅).

Key exchange MUST be done using DTLS-SRTP, as described in [RFC8827]. No cap, this part is non-negotiable 🔥.

For data transport over the WebRTC data channel [RFC8831], WebRTC endpoints MUST support SCTP over DTLS over ICE 🫶. This encapsulation is specified in [RFC8261]. Negotiating this transport in the Session Description Protocol (SDP) is defined in [RFC8841]. The SCTP extension for I-DATA [RFC8260] MUST be supported too 🌈.

The setup protocol for WebRTC data channels described in [RFC8832] MUST be supported 💜.

Note: The interaction between DTLS-SRTP as defined in [RFC5764] and ICE as defined in [RFC8445] is described in Section 6 of [RFC8842]. The effect of this specification is that all ICE candidate pairs associated with a single component are part of the same DTLS association. Thus, there will only be one DTLS handshake, even if there are multiple valid candidate pairs. 🧚

WebRTC endpoints MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], Section 5.1.2, with clarifications in [RFC7983] 🍓. All application-layer protocol payloads over this DTLS connection are SCTP packets, so it's all one vibe ✨.

Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [RFC8833] 🙈.

4. Media Prioritization 👑

Okay this section is my absolute favorite, it's giving priority queue drama 😭. In the WebRTC prioritization model, the application tells the WebRTC endpoint how important each piece of media and data is, and all of that is controlled from the API 💅.

Here's the lingo: a "flow" is the unit that gets a specific priority through the WebRTC API 🦋.

For media, a "media flow" (which can be an "audio flow" or a "video flow") is what [RFC7656] calls a "media source". That results in a "source RTP stream" plus one or more "redundancy RTP streams". This spec doesn't describe prioritization between the RTP streams that come from a single media source, so that's a plot twist for another day 🌸.

All media flows in WebRTC are assumed to be interactive, as defined in [RFC4594]. There's no browser API support for saying whether media is interactive or noninteractive, so everything is treated as interactive 💖.

A "data flow" is the outgoing data on a single WebRTC data channel 🎀.

The priority of a media flow or data flow is classified as "very-low", "low", "medium", or "high". There are only four priority levels in the API, so keep it simple bestie 🧚.

The priority settings affect two pieces of behavior: packet send sequence decisions and packet markings. Each one gets its own section below 🌈.

4.1. Local Prioritization 🦋

Local prioritization happens at the local node, before the packet is sent. Because of that, the prioritization has full access to the data about the individual packets and can choose different treatment based on the stream each packet belongs to. Main character energy 👑.

When a WebRTC endpoint has packets to send on multiple streams that are congestion controlled under the same congestion control regime, the WebRTC endpoint SHOULD cause data to be emitted so that each stream at each level of priority gets approximately twice the transmission capacity (measured in payload bytes) of the level below it 🌸.

So when congestion happens, a high-priority flow can send 8 times as much data as a very-low-priority flow, as long as both have data to send. This prioritization doesn't depend on the media type ✨. The details of which packet goes first are implementation defined 🙈.

For example, say there's a high-priority audio flow sending 100-byte packets and a low-priority video flow sending 1000-byte packets, and outgoing capacity exists for sending more than 5000 payload bytes. It would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video in a single pass of sending decisions 🎀.

Now flip it. If the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending more than 2500 payload bytes 💜.

If there are two high-priority audio flows, each one can send 4000 bytes in the same period where a low-priority video flow can send 1000 bytes. Iconic distribution 💅.

Two example implementation strategies are:

  • When the available bandwidth is known from the congestion control algorithm, configure each codec and each data channel with a target send rate that fits its share of the available bandwidth 🦋.
  • When congestion control indicates that a specified number of packets can be sent, send the packets that are ready using a weighted round-robin scheme across the connections 🍓.

Any combination of these, or other schemes that have the same effect, is valid, as long as the distribution of transmission capacity is approximately correct ✨.

For media, it's usually inappropriate to use deep queues for sending. It's more useful to, for instance, skip intermediate frames that have no dependencies on them, so you get a lower bitrate 🌈. For reliable data, queues are useful 🫶.

Note that this specification doesn't dictate when disparate streams are to be "congestion controlled under the same congestion control regime". The issue of coupling congestion controllers is explored further in [RFC8699] 🧚.

4.2. Usage of Quality of Service -- DSCP and Multiplexing 💖

When a packet is sent, the network makes decisions about queueing and/or discarding it, and those decisions can affect the quality of the call. The sender can try to set the DSCP field of the packet to influence those decisions 🎀.

Implementations SHOULD attempt to set QoS on the packets they send, following the guidelines in [RFC8837]. It's fine to depart from this recommendation when running on platforms where QoS marking isn't implemented 🌸.

The implementation MAY turn off DSCP markings if it detects symptoms of unexpected behavior, such as priority inversion or blocking of packets with certain DSCP markings. Some examples of these behaviors are described in [ANRW16]. How to detect these conditions is implementation dependent 🙈.

A particularly hard problem is when one media transport uses multiple DSCPs, where one may be blocked and another allowed. This is allowed even within a single media flow for video in [RFC8837]. Implementations need to diagnose this scenario 😭. One possible approach is to send initial ICE probes with DSCP 0, and then send ICE probes on all the DSCPs that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be done at the same time as the initial media traffic; on failure, the initial data may need to be resent. This switch will, of course, invalidate any congestion information gathered up to that point 💀.

Failures can also start happening during the lifetime of the call. This case is expected to be rarer and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart 🦋.

Note that when a DSCP causes nondelivery, you have to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCPs, don't need to change 💅.

All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP. The code point used SHOULD be the one recommended by [RFC8837] for the highest-priority data channel carried. Note that this means all data packets, no matter their relative priority, will be treated the same by the network 🫶.

All packets on one TCP connection, no matter what it carries, MUST use a single DSCP 🌈.

More advice on using DSCPs with RTP, plus the relationship between DSCP and congestion control, is given in [RFC7657] 🧚.

There are a bunch of QoS schemes that don't depend only on DSCPs. Some of them classify traffic into flows based on a 5-tuple (source address, source port, protocol, destination address, destination port) or a 6-tuple (5-tuple + DSCP). Under different conditions, it may make sense for a sending application to choose any of the following configurations 👑:

  • Each media stream carried on its own 5-tuple
  • Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple)
  • All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCPs

In each of the configurations mentioned, data channels may be carried on their own 5-tuple or multiplexed together with one of the media flows 🎀.

More complex setups are also possible, like sending a high-priority video stream on one 5-tuple and all other video streams multiplexed together over another 5-tuple. More information on mapping media flows to 5-tuples can be found in [RFC8834] 🦋.

A sending implementation MUST be able to support the following configurations:

  • Multiplex all media and data on a single 5-tuple (fully bundled)
  • Send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled)

The sending implementation MAY choose to support other configurations, such as bundling each media type (audio, video, or data) into its own 5-tuple (bundling by media type) 🌸.

Sending data channel data over multiple 5-tuples is not supported 🙅.

A receiving implementation MUST be able to receive media and data in all of these configurations 💜.

5. IANA Considerations 🍓

This document has no IANA actions ✨.

6. Security Considerations 🔥

Okay this one is SERIOUS bestie 😭 Security is not something to vibe-check, so read these carefully!

WebRTC security considerations are enumerated in [RFC8826] 🔒.

Security considerations pertaining to the use of DSCP are enumerated in [RFC8837] 🛡️.

7. References 📚

7.1. Normative References 📚

okay bestie, these are the must-read refs that the spec leans on, so they're basically load-bearing 🫶

7.2. Informative References 🌸

these ones are the extra-credit reading, the stuff that gives context but isn't strictly needed to build the thing 🧚

Acknowledgements 🫶

this doc is built on earlier draft versions that got embedded in [RFC8825], and those drafts came from loads of RTCWEB Working Group members. so many brains, honestly iconic 👑

special shoutout to the people who reviewed earlier drafts: Eduardo Gueiros, Magnus Westerlund, Markus Isomaki, and Dan Wing 💖 and Andrew Hutton's contributions deserve a special mention too ✨

Author's Address 💌

Harald Alvestrand Google

Email: harald@alvestrand.no

📦 where this page comes from