A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
Extracted elements (29)
A high-reachability configuration is defined for RTSP servers not behind NATs, allowing them to reduce their candidate set to one per (address family, media stream, component) tuple and suppress self-initiated checks until triggered by the client. This reduces load and mitigates STUN amplification DDoS, while still verifying client presence via triggered checks.
Aggressive nomination is recommended for RTSP ICE because, unlike SIP/SDP offer/answer, RTSP media delivery only begins after a separate PLAY request, so the risk of a path change while media is already flowing can be avoided by delaying PLAY until outstanding checks complete.
ICE was selected for RTSP NAT traversal over alternatives (evaluated in RFC 7604) for two main reasons: it supports RTSP servers that are themselves behind NATs, and it mitigates the security threat of using RTSP servers as DDoS amplification tools by requiring a connectivity check before media is delivered.
RTP/RTCP multiplexing is mandated alongside D-ICE for RTP because it halves the number of STUN connectivity check instances and candidate combinations per media stream, reducing ICE completion time by at least one round-trip per stream. The demultiplexer required for STUN/RTP separation makes the additional RTCP demux point relatively cheap.
A media-handling proxy splits each RTSP session into two media legs and MUST implement ICE-RTSP fully, acting as both controlling and controlled ICE peer. It SHALL include the 'setup.ice-d-m' feature tag in Proxy-Supported headers.
Using 'setup.ice-d-m' in the Proxy-Require header is NOT RECOMMENDED because it yields contradictory results: a media-handling non-ICE proxy aborts setup (desirable), but a non-media-handling non-ICE proxy also aborts (undesirable, since pass-through may have worked). Use Supported/Proxy-Supported instead.
A 150 response SHALL be sent within 200 milliseconds of receiving a PLAY request that cannot be fulfilled because ICE checks are still running, and subsequently every 3 seconds until the ICE connectivity checks conclude.
Both client and server SHALL use STUN keep-alive messages for the nominated candidate pair(s) following ICE §10 during steady state. This is critical because RTSP play sessions carry traffic only from server to client, so NAT bindings must be refreshed by client-to-server STUN traffic.
For RTP-based media streams, candidates for RTP MUST have component-id of 1 and candidates for RTCP MUST have component-id of 2, unless RTP/RTCP multiplexing is used in which case only component 1 is used. The rel-addr and rel-port fields MUST be present for server-reflexive, peer-reflexive, and relayed candidates, and MUST be omitted for host candidates.
ICE-Lite SHALL NOT be used in the context of RTSP. ICE-Lite is insufficient because it does not cause the media server to send a connectivity check, which is required to protect against the RTSP server being used as a denial-of-service tool.
If the RTSP session is in PLAYING state when a SETUP request requiring ICE restart is issued, the ICE connectivity checks SHALL use Regular nomination. Ongoing media delivery continues on previously nominated candidate pairs until new pairs are nominated.
Servers and clients that support the D-ICE lower-layer transport in combination with RTP SHALL also implement and use RTP and RTCP multiplexing as specified in RTSP 2.0 Appendix C.1.6.4 and RFC 5761.
The client SHALL initiate connectivity checks following ICE §6 after receiving the SETUP response. Aggressive nomination SHOULD be used during initial SETUP, since media delivery only starts on PLAY, avoiding mid-path-change risks present in SIP/SDP.
The RTSP client SHALL gather candidates for UDP transport per ICE §4.1.1 and for TCP-based candidates per ICE-TCP §5 for each media stream supporting ICE. Each media stream SHALL have its own unique combination of ICE candidates and ICE-ufrag in the SETUP request.
The server SHALL start connectivity checks per ICE §5.7-5.8 after receiving SETUP, unless configured for high-reachability (in which case it MAY wait for triggered checks from the client). The server SHALL use a single pacer queue for all media streams within each RTSP session.
There MUST be an ICE-Password and ICE-ufrag parameter for each media stream, chosen randomly at session start. The ICE-ufrag MUST contain at least 24 bits of randomness (minimum 4 characters), and ICE-Password MUST contain at least 128 bits of randomness (minimum 22 characters), with an upper limit of 256 characters each.
UDP-based transport candidates MUST be supported for the D-ICE lower layer. TCP-based candidates as defined by RFC 6544 are OPTIONAL.
When D-ICE is used as the lower layer, the 'candidates' transport parameter SHALL be included with at least one candidate, and the 'dest_addr' parameter MUST NOT be included since 'candidates' provides the address information.
Logging of NAT translations is operationally useful but can be privacy-invasive at Internet scale. Procedures for log flushing and privacy protection SHALL be in place, including consideration of log integrity, privacy protection, and retention/purging policies.
A feature tag 'setup.ice-d-m' is defined for the RTSP capabilities mechanism, indicating support for all mandatory functions of ICE-based datagram media transport NAT traversal. It applies to clients, servers, and proxies. Clients SHOULD include it in the Supported header of SETUP requests using D-ICE.
A new PLAY_NOTIFY Notify-Reason value 'ice-restart' is defined, allowing the server to notify the client that an ICE restart is needed on the identified resource and session, for example due to server-side load balancing or address change.
The D-ICE lower-layer transport is defined for use in RTSP transport specifications. It requires datagram-clean transport that can be demultiplexed from STUN messages, supports UDP-based candidates (mandatory) and TCP-based candidates (optional), and enables ICE to select among candidates before transporting datagrams.
The session-level SDP attribute 'a=rtsp-ice-d-m' indicates that the server supports ICE-based NAT traversal for RTSP-controlled media sessions. Servers SHOULD include this attribute in any SDP describing content they serve.
Two new RTSP status codes are defined: 150 (Server still working on ICE connectivity checks) used in response to PLAY requests while ICE checks are pending, and 480 (ICE Connectivity check failure) used in response to PLAY or SETUP requests when ICE processing has failed.
This document registers in six RTSP 2.0 and SDP registries: the feature tag 'setup.ice-d-m' (RTSP 2.0 Feature-tags); four transport identifiers RTP/AVP/D-ICE, RTP/AVPF/D-ICE, RTP/SAVP/D-ICE, RTP/SAVPF/D-ICE (Transport Protocol Identifiers); three transport parameters 'candidates', 'ICE-Password', 'ICE-ufrag' (RTSP Transport Parameters); status codes 150 and 480 (RTSP Status Codes); Notify-Reason value 'ice-restart'; and SDP session-level attribute 'rtsp-ice-d-m'.
RTSP signaling SHOULD be protected using TLS to prevent eavesdropping and modification of ICE candidate information. The STUN amplification attack (ICE §18.5.2) is mitigated by the high-reachability option, which limits server-initiated checks to addresses from which the server has already received an incoming check.
Without ICE, an attacker can forge RTSP SETUP requests using a victim's IP address and cause the media server to flood that victim with media packets. ICE connectivity checks require the client to confirm it wants media before delivery begins, directly mitigating this DDoS vector. ICE-Lite is explicitly excluded because it omits the server-initiated check that provides this protection.
The ICE-RTSP connectivity establishment follows the states: candidate gathering (client, then server after SETUP received), connectivity checks (server initiates per ICE §5.7-5.8; client initiates per ICE §6), nomination, and PLAY. PLAY can only succeed after both sides conclude checks; failures yield 150 (pending) or 480 (failed) responses.
The 'candidates' RTSP transport header parameter carries ICE candidates using the fields: foundation, component-id, transport, priority, connection-address, port, cand-type, optional rel-addr/rel-port, mandatory tcp-type-ext for TCP candidates, and optional extension attributes. Multiple candidates are semicolon-separated within a double-quoted string.