Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)
updated by
- rfc-9443 — Multiplexing Scheme Updates for QUIC
updates
- rfc-5764 — Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
Extracted elements (17)
Having overlapping ranges across IANA registries creates a hidden inter-registry coordination requirement whenever a new codepoint is allocated. The document argues this is organizationally undesirable, and proposes that IANA registry experts raise a flag when an allocation would irrevocably prevent multiplexing, even if multiplexing is not the immediate motivation.
RFC 5764 did not account for ZRTP [RFC6189], a media-path Diffie-Hellman key agreement protocol multiplexed on the same port as RTP. This document allocates first-byte values 16–19 to ZRTP to prevent future protocol collisions in the unused range.
RFC 5764 did not handle TURN channel packets, whose first byte falls in [64..127]. Implementations had been silently violating RFC 5764 by treating these as TURN data anyway. This document formalizes first-byte values 64–79 as TURN Channel to match deployed behavior, while restricting the usable TURN channel space.
RFC 5764 implicitly treated TLS ContentType values 20–63 as DTLS without warning that allocations outside this range (0–19 and 64–255) would break demultiplexing. This document adds coordination requirements to those ranges in the TLS ContentType registry.
RFC 5764 only allocated first-byte values 0 and 1 for STUN, which implicitly restricted STUN method codepoints to 0x000–0x07F, reducing available IETF Review slots from 2048 to 128 and eliminating the Designated Expert range entirely. This document allocates values 2 and 3 to STUN to preserve the Designated Expert codepoint range.
Current implementations of RFC 5764 already violate its demultiplexing rules for first-byte values 64–127 (inclusive) by parsing them as TURN channel data instead of rejecting them. RFC 7983 retroactively allocates 64–79 to TURN to align the standard with deployed practice.
Even after ICE selects a non-relayed path, a TURN server may continue forwarding data (e.g., STUN connectivity checks during an ICE restart or with aggressive nomination). Implementations must be prepared to receive TURN channel packets even on ostensibly direct paths.
RFC 5764 has been widely deployed and other documents such as RFC 7345 and the SDP BUNDLE draft inherited its flawed demultiplexing scheme. Those documents also require correction using the updates this document provides.
Any extension or revision to DTLS that causes its first byte to fall outside the range 20–63 SHOULD consider the impact on RFC 5764-style multiplexing and what values may appear in the leading byte.
If the first byte of a received packet does not match any known demultiplexing range, the packet MUST be dropped and an alert MAY be logged.
The updated demultiplexing algorithm inspects the first byte of every received packet: [0..3] → STUN, [16..19] → ZRTP, [20..63] → DTLS, [64..79] → TURN Channel, [128..191] → RTP/RTCP. Packets outside these ranges are dropped.
TURN channels use a 4-byte prefix rather than the standard 36-byte STUN overhead (per RFC 5766, Section 2.5). Their first byte falls in [64..79] under the updated multiplexing scheme, restricting the number of usable TURN channel bindings when combined with RFC 5764 demultiplexing.
The STUN Methods registry is updated: 0x000–0x07F requires IETF Review, 0x080–0x0FF requires Designated Expert, and 0x100–0xFFF is Reserved for DTLS-SRTP multiplexing collision avoidance and cannot be assigned without IETF Review.
The TLS ContentType registry is updated so that values 0–19 and 64–255 carry a 'Requires coordination; see RFC 7983' notice, reflecting that allocations in these ranges could break DTLS-SRTP demultiplexing.
The TURN Channel Numbers registry reserves values 0x5000–0xFFFF for DTLS-SRTP multiplexing collision avoidance, preventing their use in contexts where RFC 5764-style demultiplexing is employed.
RFC 7983 updates IANA registries and adds a TURN channel range to the demultiplexing algorithm but introduces no new security considerations beyond those already documented in RFC 5764.
Demultiplexing is performed on the leading byte (B) of the UDP datagram. STUN uses B in [0..3], ZRTP uses B in [16..19], DTLS uses B in [20..63], TURN Channel uses B in [64..79], and RTP/RTCP uses B in [128..191].