Port Mapping between Unicast and Multicast RTP Sessions
Extracted elements (29)
The Relative Expiration Time field in the Port Mapping Response is conveyed in cleartext (not included in the HMAC) so the client can proactively request a new Token before expiry. This is a deliberate design tradeoff: an attacker can modify this field, but the absolute expiration (used for HMAC validation) remains protected.
The Token is opaque to the client and based on the client's IP address (as seen by the server), a client-supplied random nonce, and an absolute expiration time. Using the client's source IP address as seen by the server (rather than as reported by the client) prevents an attacker from redirecting unicast streams to a victim with a different IP address.
Token-based port mapping was introduced because the Offer/Answer Model requires round-trip exchanges that introduce undesirable delay in real-time applications, and is burdensome when endpoints run large numbers of concurrent unicast sessions. The Token mechanism lets receivers choose their own UDP ports without offer/answer exchange while protecting against DoS and packet amplification attacks.
Token-based port mapping is not applicable when TCP is used as the transport protocol in the unicast sessions; for TCP-based media transport scenarios, RFC 4145 should be used instead.
When using 'portmapping-req' in SDP offer/answer, an answerer that supports the Token approach MUST echo the attribute unchanged; an answerer that does not implement this specification silently ignores the attribute and can still join the multicast session but cannot use Token-protected unicast services.
A client SHOULD use separate receive ports for subsequent unicast sessions unless each stream has a distinct SSRC. After a sufficient time (two minutes is RECOMMENDED), a previously used port can be reused.
If HMAC-SHA1 is used for Token construction, the HMAC key MUST be at least 160 bits long and generated using a cryptographically secure random source per RFC 4086.
Implementations MUST encode into the Token at minimum: the client's IP address as seen by the server (32/128 bits for IPv4/IPv6), the client-provided nonce (64 bits), and the absolute expiration time as an NTP timestamp (64 bits) to protect against replay attacks.
In the unicast session, traffic from server to client (both RTP and RTCP sent from port P3 towards port c1) MUST be multiplexed on the same port per RFC 5761.
It is strongly RECOMMENDED that the client uses the same port for c0 (multicast RTCP reports) and c1 (unicast feedback/receive port), because periodic RTCP reports from c0 keep the NAT binding alive and conserve NAT port bindings.
Port P4 (RTCP port for unicast session receiver/extended reports) MUST be different from port P3 (RTCP feedback target port). Port PT (Token request port) MAY be equal to port P3.
RTCP messages that trigger transmission of RTP packets in a port-mapped unicast session are REQUIRED to be authenticated by using a Token when the Token capability is declared in the session description. These include NACK messages and RAMS-R messages.
RTP traffic direction MUST be only from the server to the client in the unicast session. If the client wants to send RTP traffic back to the server, regular session establishment methods such as RFC 3264 must be used instead.
The client MUST NOT send a Token Verification Request message with a Token that has expired.
The client MUST use the same RTCP CNAME in both the multicast and unicast sessions, and the CNAME MUST be unique per RFC 6222, so the server can correlate receiver reports across sessions.
The server MUST validate the Token upon receipt of a Token Verification Request message; it reconstructs the Token from the received client IP, nonce, and expiration time and compares it against the submitted Token. If validation fails, the server MUST reply with a Token Verification Failure message.
To minimize cross-protocol attacks, a server MUST NOT use the same secret key it used for Token construction for any other purpose.
A new RTCP control packet type TOKEN (PT=210) is introduced with five-bit sub-message type (SMT) field to distinguish four message types: Port Mapping Request (SMT=1), Port Mapping Response (SMT=2), Token Verification Request (SMT=3), and Token Verification Failure (SMT=4). All fields are carried in network byte order.
The 'portmapping-req' SDP media-level attribute declares the port (and optionally address) from which a client must request a Token before establishing the unicast session. Its presence requires Token authentication for RTCP messages triggering or controlling the unicast session and mandates that unicast RTP/RTCP be received on the port from which the triggering RTCP was sent.
New SMT Values for TOKEN Packet Type Registry created, managed under IETF Review policy. Five-bit field yields 32 values; initialized with: 0=Reserved, 1=Port Mapping Request, 2=Port Mapping Response, 3=Token Verification Request, 4=Token Verification Failure, 5-30=Unassigned, 31=Reserved.
RAMS Response Code Space Registry updated with code 405 (Invalid Token), used when the Token included in a RAMS-R message is invalid.
RTCP Control Packet Types sub-registry updated to add TOKEN (value 210) for Port Mapping messages, in the Real-Time Transport Protocol (RTP) Parameters registry.
RTCP messages are susceptible to on-path or man-in-the-middle attacks that can modify Token-related fields. Attackers can alter the Relative Expiration Time to cause excessive Token requests, and the attack is detectable only by server-side monitoring. If MITM risk exists, RTCP messages SHOULD be protected by SRTCP (RFC 3711).
The 'portmapping-req' SDP attribute can be tampered with to redirect Token requests or prevent unicast session establishment. The SDP description MUST be integrity-protected and source-authenticated, e.g., via S/MIME, HTTPS, or SAP authentication.
The Token provides protection only against off-path DoS attacks. If an attacker obtains a valid Token for a victim and can spoof the victim's source address (e.g., when both share the same IP behind a large-scale NAT with no ingress filtering), replay attacks become feasible. Servers can mitigate this by using very short Token lifetimes at the cost of increased acquisition latency.
Port Mapping Request (SMT=1): fixed 128-bit packet containing V=2/P/SMT/PT=TOKEN(210)/Length=3 header word, 32-bit SSRC of packet sender, and a 64-bit Random Nonce generated per RFC 4086. The same nonce MUST be used in duplicate transmissions but a new nonce MUST be generated for each new request.
Port Mapping Response (SMT=2): contains V=2/P/SMT/PT=TOKEN header, 32-bit SSRC of server, 32-bit SSRC of requesting client, 64-bit Associated Nonce, variable-length Token Element (16-bit length-value, 32-bit aligned), 64-bit Absolute Expiration Time (NTP seconds), 32-bit Relative Expiration Time (seconds; zero means Token denied), and variable-length Packet Types Element (8-bit length-value listing RTCP types requiring authentication).
Token Verification Failure (SMT=4): fixed-length packet with Length=5, containing 32-bit SSRC of server (equals SSRC of multicast stream), 32-bit SSRC of requesting client, 8-bit Failed PT, 5-bit FMT, reserved bits, and 64-bit Associated Nonce (zero if no Token Verification Request was included). Sent from port P3 towards port c1.
Token Verification Request (SMT=3): contains V=2/P/SMT/PT=TOKEN header, 32-bit SSRC of client, 64-bit Associated Nonce, variable-length Token Element (as received in Port Mapping Response), and 64-bit Associated Absolute Expiration Time. This message accompanies RTCP feedback messages that trigger or control a unicast session.