Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
obsoleted by
- rfc-7022 — Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (18)
Per-session RTCP CNAMEs provide a limited form of privacy by preventing traffic analysis that correlates separate RTP sessions, at the cost of preventing legitimate third-party monitoring (e.g., network management tools correlating QoS across sessions). Implementations that wish to discourage monitoring should generate a unique CNAME per session.
The document does not allow implementors to define their own alternative CNAME generation methods; any future alternative must be reviewed and approved via the standards process to ensure uniqueness and consistency across correlated RTP sessions.
The RFC 3550 recommendation to use FQDNs or IPv4 addresses as the 'host' part of RTCP CNAMEs is no longer sufficient to guarantee uniqueness. FQDNs can be shared across endpoints in large service provider networks, and IPv4 addresses can be duplicated behind NAT devices or through RFC 1918 private address reuse.
There is no backwards compatibility issue with RFC 3550-compatible implementations because RTCP CNAMEs are opaque strings to remote peers; changing the generation method does not affect interoperability with existing endpoints.
An RTP endpoint that emits multiple related RTP streams requiring synchronization MUST use the same RTCP CNAME for all streams to be synchronized. This applies, for example, to lip-sync of audio and video streams in a multimedia session.
An RTP endpoint wishing to generate a long-term persistent RTCP CNAME MUST generate and store a UUID (version 1, 2, or 4 per RFC 4122) with the 'urn:uuid:' prefix stripped, yielding a 36-octet printable string used as the 'host' part.
An RTP endpoint wishing to generate a per-session RTCP CNAME MUST apply the Section 5 procedure for each new RTP session, take the least significant 96 bits of the SHA-256 output, and Base64-encode them, resulting in a 16-octet string. The 'user@' part MUST be omitted.
An RTP endpoint wishing to generate a short-term persistent RTCP CNAME MUST either use the numeric representation of the layer-2 MAC address of the initiating interface, or generate an identifier via the Section 5 procedure; the least significant 48 bits are formatted as colon-separated hex (e.g., '00:23:32:af:9b:aa'), yielding a 17-octet string.
The mechanisms defined in this document MUST be used only to generate RTCP CNAMEs and MUST NOT be used for generating general-purpose unique identifiers, limiting the scope of the defined procedures.
Using the numeric representation of an IPv4 address as the 'host' part of an RTCP CNAME is NOT RECOMMENDED, because it is difficult or impossible for a host to determine if it is behind NAT, and public IPv4 addresses can also be shared by multiple hosts.
A fixed (persistent) RTCP CNAME allows separate RTP sessions to be correlated, undermining IPv6 privacy addresses (RFC 4941) and IPv4 NAPT obfuscation. In telephony and similar environments, implementations should either encrypt SRTCP or use per-session CNAMEs to mitigate session correlation.
SRTP mandates SRTCP integrity protection but not encryption; thus SRTCP CNAME values remain observable unless encryption is explicitly enabled. Applications in environments where session correlation is a concern SHOULD encrypt SRTCP.
The RTCP CNAME is a persistent transport-level identifier for an RTP endpoint, distinct from the SSRC (which may change on collision or restart). CNAMEs are opaque strings to remote peers, enabling synchronization across related RTP streams and long-term endpoint identification.
The unique identifier generation procedure (Section 5) uses: (1) current 64-bit NTP timestamp, (2) modified EUI-64 or MAC-derived identifier, (3) for per-session CNAMEs, also the initial SSRC plus source/destination IP addresses and ports, all concatenated and hashed with SHA-256 to yield a 256-bit output.
Implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for any essential security services. Any participant can choose any CNAME value, allowing impersonation; no CNAME generation scheme can prevent this because an attacker can simply set the CNAME directly.
No confidentiality is provided on the inputs to the RTCP CNAME generation algorithm. An attacker who observes an RTCP CNAME may be able to reverse-engineer the inputs (NTP timestamp, EUI-64, etc.) used to generate that value.
The SHA-256 hash used in CNAME generation is not assumed to provide collision resistance, preimage resistance, or pseudorandomness in an adversarial setting; it is used solely for its randomness properties to achieve high-probability uniqueness, not for cryptographic security guarantees.
Long-term persistent RTCP CNAME: UUID (RFC 4122 version 1, 2, or 4) with 'urn:uuid:' stripped, 36-octet printable ASCII string, optionally prefixed with 'user@'. Short-term persistent: 17-octet colon-separated hex MAC, e.g., '00:23:32:af:9b:aa'. Per-session: 16-octet Base64 string from 96 LSBs of SHA-256 output.