Multiplexing Scheme Updates for QUIC
updates
Extracted elements (12)
QUIC bit greasing (RFC 9287) allows QUIC endpoints to set the fixed QUIC bit to any value, which would cause QUIC packets to appear in byte ranges [0..63] or [128..191], colliding with STUN, ZRTP, DTLS, and RTP/RTCP ranges. The multiplexing scheme therefore requires grease_quic_bit to be disabled by endpoints that share a port.
The 64–79 overlap between TURN channel packets and QUIC short-header packets does not require a protocol-level fix because TURN channel packets will only arrive from a TURN server to which the client has previously sent allocation and channel-binding requests. Other protocol types (SRTP, DTLS, QUIC) will never arrive from such a source address, so source-address checking provides unambiguous demultiplexing.
The multiplexing scheme described in this document is compatible with QUIC version 2 (RFC 9369) but is not compatible with QUIC bit greasing (RFC 9287). Implementations wishing to use port multiplexing must refrain from advertising or using the grease_quic_bit transport parameter.
Endpoints that wish to demultiplex QUIC on a shared socket MUST NOT send the grease_quic_bit transport parameter, as defined in RFC 9287. This is required because QUIC bit greasing makes the first-octet-based demultiplexing scheme unreliable.
If the first byte of an arriving packet does not match any known range, the packet MUST be dropped and an alert MAY be logged.
QUIC packets (in the absence of bit greasing) are assigned first-byte ranges [80..127] and [192..255] exclusively. The range [64..79], previously reserved solely for TURN channels, now also maps to QUIC when the source IP address and port do not match a responding TURN server.
The document describes three primary use cases for port multiplexing: (1) WebRTC peer-to-peer with SRTP keyed via DTLS-SRTP, requiring SRTP/SRTCP + STUN + TURN + DTLS + QUIC on one port; (2) SRTP keyed via future QUIC-SRTP, requiring SRTP/SRTCP + STUN + TURN + QUIC; (3) RTP/RTCP carried over QUIC, requiring STUN + TURN + QUIC.
TURN channel packets use a 4-byte prefix (versus the 36-byte STUN overhead) and have first-byte values in [64..79]. Disambiguation from QUIC packets in the same range is achieved by checking whether the source IP address and port match a TURN server that previously responded to allocation or channel-binding requests.
IANA updated the 'TLS ContentType' registry to replace references to RFC 7983 with references to this document (RFC 9443).
If the updated demultiplexing logic is misimplemented, packets could be misclassified, exposing individual protocol handlers (STUN, DTLS, SRTP, QUIC) to input of the wrong type. This is an additional risk beyond those described in RFC 7983.
When QUIC is used solely for data exchange, the TLS-within-QUIC handshake (RFC 9001) derives keys that protect only QUIC data packets and should not affect SRTP transport or DTLS-SRTP key derivation. However, if a future specification were to derive SRTP keys from the TLS-within-QUIC exchange, a vulnerability in the QUIC implementation could compromise both transport and SRTP key derivation.
The updated demultiplexing algorithm inspects the first byte of each arriving packet: [0..3] → STUN; [4..15] → DROP; [16..19] → ZRTP; [20..63] → DTLS; [64..79] → TURN Channel if source matches a responding TURN server, else QUIC; [80..127] → QUIC; [128..191] → RTP/RTCP; [192..255] → QUIC.