Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
obsoletes
- rfc-6222 — Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (16)
RFC 3550's recommendation to use FQDNs as RTCP CNAMEs is no longer adequate because FQDNs are no longer necessarily unique across endpoints in large service provider networks. Similarly, IPv4 addresses fail because private addresses (RFC 1918) and NAT sharing mean multiple hosts may have the same address.
RFC 6222's algorithm was replaced because its CNAMEs were potentially linkable across multiple RTCP sessions even when a new CNAME was generated per session, which undermined the privacy property that per-session CNAMEs are supposed to provide.
The Section 5 algorithm is intentionally simple: generating a CSPRNG value of at least 96 bits replaces the more complex algorithm in RFC 6222 Section 5. Environments that already support TLS, ICE, or DTLS-SRTP already have a CSPRNG available, making this straightforward to implement.
There is no backwards compatibility issue with RFC 3550 implementations introduced by this memo, since RTCP CNAMEs are opaque strings to remote peers and the new generation methods produce strings that are syntactically valid under the existing RTP standard.
An RTP endpoint emitting multiple related RTP streams that require synchronization MUST use the same RTCP CNAME for all streams to be synchronized, such as the audio and video streams of a multimedia session.
For per-session RTCP CNAMEs, a new CNAME MUST be generated via the Section 5 procedure for every new RTP session, with the least significant 96 bits SHOULD be Base64-encoded. The 'user@' part MUST be omitted. The CNAME cannot change over the life of a session.
The 'user@' part of the RTCP CNAME MAY be omitted on single-user systems and MAY be replaced by an opaque token on multiuser systems to preserve privacy.
To locally produce a unique identifier, an implementation MUST generate a cryptographically pseudorandom value per RFC 4086. This value MUST be at least 96 bits.
To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST generate and store a UUID (RFC 4122) version 1, 2, or 4, with the 'urn:uuid:' prefix stripped, yielding a 36-octet printable string as the 'host' part.
To produce a short-term persistent RTCP CNAME, an RTP endpoint MUST generate an identifier using the CSPRNG procedure in Section 5, performing it at least once per software initialization. At minimum the least significant 96 bits SHOULD be Base64-encoded (RFC 4648), producing a 16-octet string.
Using the numeric representation of an IPv4 address as the 'host' part of an RTCP CNAME is NOT RECOMMENDED, because public IPv4 addresses can be shared by multiple hosts, and it is often impossible for a host to know if NAT is present.
Earlier fixed RTCP CNAME values allowed attackers to easily correlate separate RTP sessions, defeating the obfuscation of IPv6 privacy addresses and IPv4 NAPT. This specification eliminates fixed CNAMEs; per-session CNAMEs prevent such session linking, though non-RTP traffic analysis may still allow correlation by a determined analyst.
RTCP CNAMEs may be either persistent (long-term or short-term, used across sessions) or per-session (a new CNAME is generated for each RTP session). Per-session CNAMEs provide a limited form of privacy by preventing session correlation, but longer-term persistent CNAMEs facilitate third-party monitoring and network management.
The RTCP CNAME is a persistent transport-level identifier for an RTP endpoint. Unlike the SSRC, which may change on collision or restart, the RTCP CNAME is meant to remain unchanged so that endpoints can be uniquely identified and their RTP media streams associated.
A 96-bit RTCP CNAME length allows on the order of 2^40 globally unique CNAMEs before significant collision probability arises (approximately 50% chance of one collision after 2^48 CNAMEs), justifying the 96-bit minimum length requirement.
Implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for any essential security services. Any participant can choose any RTCP CNAME and can thus impersonate another participant; SRTP keeps unauthorized entities out of a session but does not prevent impersonation by authorized entities.