RFC 6222

Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)

📅 published April 2011, from ietf

RFC 6222: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 🎀

Okay bestie, this is an Internet Standards Track doc from April 2011, so it's a real spec people build against 💅. It's by A. Begen (Cisco), C. Perkins (University of Glasgow), and D. Wing (Cisco). It's labelled ISSN 2070-1721 and it updates [RFC3550]. It doesn't list anything it obsoletes. Basically it's a glow-up for how RTP endpoints pick their RTCP CNAME 🦋

Abstract ✨

Okay so the RTCP CNAME is a persistent transport-level identifier for an RTP endpoint 🫶 Your SSRC can change if a collision happens or the RTP app restarts, but the CNAME is meant to stay the same, so endpoints can be uniquely identified and matched up with their RTP media streams. Lowkey the whole point is that CNAMEs should be unique among the participants in an RTP session. The problem is the old guidelines in the RTP standard aren't enough to make that happen 😭 So this memo updates those guidelines so endpoints can pick unique RTCP CNAMEs 💖

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6222.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

Table of Contents 📚

1. Introduction ....................................................2
2. Requirements Notation ...........................................2
3. Deficiencies with Earlier Guidelines for Choosing an
   RTCP CNAME ......................................................3
4. Choosing an RTCP CNAME ..........................................3
   4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs ......4
   4.2. Requirements ...............................................5
5. Procedure to Generate a Unique Identifier .......................6
6. Security Considerations .........................................7
   6.1. Considerations on Uniqueness of RTCP CNAMEs ................7
   6.2. Session Correlation Based on RTCP CNAMEs ...................7
7. Acknowledgments .................................................8
8. References ......................................................8
   8.1. Normative References .......................................8
   8.2. Informative References .....................................9

1. Introduction 💅

Okay so Section 6.5.1 of the RTP specification, [RFC3550], has a bunch of suggestions for picking a unique RTCP CNAME for an RTP endpoint 🙈 The catch is that in practice, some of those methods don't actually guarantee uniqueness. This memo updates the guidelines for choosing RTCP CNAMEs, and it supersedes the ones in Section 6.5.1 of [RFC3550]. Main character energy 👑

2. Requirements Notation 🍓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Iykyk, these are the official BCP 14 words, and they're the ones that carry real weight 🔥

3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME 🙃

Okay so [RFC3550] says to generate an RTCP CNAME in the form "user@host" for multiuser systems, or just "host" if there's no username. The "host" part is supposed to be the fully qualified domain name (FQDN) of the host the real-time data comes from. Honestly that made sense back when [RFC3550] was written 🌸 But FQDNs aren't necessarily unique anymore, and they can be shared across loads of endpoints in big service provider networks. This document replaces the use of FQDN as an RTCP CNAME with other mechanisms 💀

IPv4 addresses also got suggested for RTCP CNAMEs in [RFC3550]. There the "host" part is the numeric form of the IPv4 address of the interface the RTP data comes from. As [RFC3550] points out, private network address space [RFC1918] can give hosts addresses that aren't globally unique. It also happens with public IPv4 addresses if multiple hosts get the same public address and sit behind a Network Address Translation (NAT) device [RFC3022]. So whether the address is private or public, if multiple hosts share it, using the IPv4 address as the RTCP CNAME gives you CNAMEs that aren't necessarily unique 😭

[RFC3550] also notes that if hosts with private addresses and no direct IP connectivity to the public Internet get their RTP packets forwarded out through an RTP-level translator, they could end up with non-unique RTCP CNAMEs. The suggestion there is for those applications to offer a configuration option so the user can pick a unique RTCP CNAME. This approach puts the burden on the translator to rewrite RTCP CNAMEs from private to public addresses where needed, so private addresses don't leak. Experience has shown this doesn't work well in practice 🥲

4. Choosing an RTCP CNAME 🦋

It's hard, and sometimes impossible, for a host to tell whether there's a NAT between itself and its RTP peer. On top of that, even some public IPv4 addresses can be shared by multiple hosts on the Internet. So using the numeric form of the IPv4 address as the "host" part of the RTCP CNAME is NOT RECOMMENDED 🙅‍♀️

4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs 🧚

The RTCP CNAME can either stay the same across different RTP sessions for an RTP endpoint, or be unique per session. Per-session means the endpoint picks a different RTCP CNAME for each RTP session ✨

An RTP endpoint that's emitting multiple related RTP streams which need to be synchronized at the other endpoint(s) MUST use the same RTCP CNAME for all streams that are to be synchronized. This calls for a short-term persistent RTCP CNAME that's shared across several RTP streams, and maybe across several related RTP sessions 💜 A classic example is lip-syncing audio and video in a multimedia session, where one participant has to use the same RTCP CNAME for both its audio RTP session and its video RTP session. Another example is syncing the layers of a layered audio codec, where the same RTCP CNAME has to be used for each layer 🎀

A longer-term persistent RTCP CNAME is sometimes useful for third-party monitoring, consistent with [RFC3550]. One use might be letting network management tools correlate a participant's ongoing quality of service across multiple RTP sessions, for fault diagnosis and for understanding long-term network performance stats 📊 An implementation that wants to discourage this kind of third-party monitoring can generate a unique RTCP CNAME for each RTP session, or each group of related RTP sessions, that it joins. A per-session RTCP CNAME can't be used for traffic analysis, so it gives some limited privacy. (Note that there are non-RTP ways a third party can correlate RTP sessions, so per-session RTCP CNAMEs won't stop a determined traffic analyst from monitoring those sessions 👀)

This memo defines several different ways an implementation can choose an RTCP CNAME. It's possible, and totally legit, for independent implementations to pick different RTCP CNAMEs when they run on the same host. That can make third-party monitoring harder, unless some external means is provided to configure a persistent RTCP CNAME for those implementations 🌈

Also, there's no backwards compatibility issue (with [RFC3550]-compatible implementations) introduced in this memo, since RTCP CNAMEs are opaque strings to remote peers 🫶

4.2. Requirements ✨

Okay so RTP endpoints get to pick whether their RTCP CNAMEs are persistent or per-session 🎀. If an endpoint wants a persistent one, it MUST use one of the following two methods:

  • To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST generate and store a Universally Unique IDentifier (UUID) [RFC4122] for use as the "host" part of its RTCP CNAME. The UUID MUST be version 1, 2, or 4, as described in [RFC4122], with the "urn:uuid:" stripped, which gives you a 36-octet printable string 💖
  • To produce a short-term persistent RTCP CNAME, an RTP endpoint MUST either (a) use the numeric representation of the layer-2 (Media Access Control (MAC)) address of the interface used to initiate the RTP session as the "host" part of its RTCP CNAME, or (b) generate and use an identifier by following the procedure in Section 5. Either way, the procedure runs once per initialization of the software. After you get an identifier from (a) or (b), the least significant 48 bits get converted to the standard colon-separated hexadecimal format [RFC5342], e.g., "00:23:32:af:9b:aa", which is a 17-octet printable string 🦋

In both cases above, the user@ part of the RTCP CNAME MAY be omitted on single-user systems and MAY be replaced by an opaque token on multi-user systems, so privacy stays protected 🫶

Now, if an endpoint wants a per-session RTCP CNAME, it MUST use this method:

  • For every new RTP session, a new CNAME is generated following the procedure in Section 5. After that, the least significant 96 bits are used to make an identifier (a compromise between packet size and security), which gets converted to ASCII with Base64 encoding [RFC4648]. That's a 16-octet string. The RTCP CNAME cannot change over the life of an RTP session [RFC3550], so only the initial SSRC value the endpoint picked is used. The user@ part gets omitted when generating per-session RTCP CNAMEs 🍓

It's believed that getting uniqueness (with high probability) is a really important property and needs careful evaluation of the method 🧐 This document gives you a bunch of methods, and at least one of them is suitable for every deployment scenario. So the document doesn't let implementors define and select their own alternative method 💅

A future spec might define an alternative method for generating RTCP CNAMEs, as long as the proposed method has appropriate uniqueness and the methods used for multiple RTP sessions that need to be correlated stay consistent. But that kind of spec needs to be reviewed and approved before anyone deploys it 👑

The mechanisms in this document are for generating RTCP CNAMEs, and they are not to be used for generating general-purpose unique identifiers. Keep it in your lane, bestie 🙈

5. Procedure to Generate a Unique Identifier 🧚

This algorithm is meant for locally generated unique identifiers ✨

  1. Get the current time of day in 64-bit NTP format [RFC5905].
  2. Get a modified EUI-64 identifier from the system running this algorithm [RFC4291]. If that system doesn't exist, you can make an identifier from a 48-bit MAC address, as specified in [RFC4291]. If you can't get or create one, a suitably unique identifier, local to the node, should be used (e.g., system serial number) 🔧
  3. Concatenate the time of day with the system-specific identifier to create a key 🔑
  4. If you're generating a per-session CNAME, also concatenate the RTP endpoint's initial SSRC, the source and destination IP addresses, and ports to the key 🌸
  5. Compute the 256-bit output of the SHA-256 digest of the key, as specified in [RFC4634] 💜

6. Security Considerations 🔥

Okay, this part is serious bestie 😭 The security considerations of [RFC3550] apply to this memo.

6.1. Considerations on Uniqueness of RTCP CNAMEs

The recommendations here for RTCP CNAME generation make sure that a set of cooperating participants in an RTP session will, with very high probability, have unique RTCP CNAMEs. But neither [RFC3550] nor this document gives any way to make sure participants pick their RTCP CNAMEs properly, so implementations MUST NOT rely on the uniqueness of CNAMEs for any essential security services 🚨 This lines up with [RFC3550], which doesn't require RTCP CNAMEs to be unique within a session. Instead it says that condition SHOULD hold. As the Security Considerations section of [RFC3550] describes, every participant is free to choose its own RTCP CNAME, so they can pick one that impersonates someone else. In other words, participants are trusted not to impersonate each other. No recommendation for generating RTCP CNAMEs can stop this impersonation, because an attacker can just ignore the stipulation 💀 Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP session, but it doesn't aim to stop impersonation attacks from unauthorized entities.

This document uses a hash function to make RTCP CNAMEs unique. A cryptographic hash function is used because those functions provide the randomness properties that are needed. However, no security assumptions are made about the hash function. It isn't assumed to be collision resistant, preimage resistant, or second preimage resistant in an adversarial setting. As described above, an attacker trying an impersonation attack could just set the RTCP CNAME directly instead of attacking the hash function. Similarly, the hash function isn't assumed to be a one-way function or pseudorandom in a cryptographic sense 🧠

No confidentiality is provided on the data used as input to the RTCP CNAME generation algorithm. An attacker who observes an RTCP CNAME might be able to work out the inputs used to generate that value 👀

6.2. Session Correlation Based on RTCP CNAMEs

In some environments, notably telephony, a fixed RTCP CNAME value lets separate RTP sessions be correlated, and it kills the obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 Network Address Port Translation (NAPT) [RFC3022]. SRTP [RFC3711] can help prevent that correlation by encrypting Secure RTCP (SRTCP). But note that SRTP only mandates SRTCP integrity protection, not encryption. So RTP applications used in those environments should consider encrypting their SRTCP, or generate a per-session RTCP CNAME as discussed in Section 4.1 🦋

7. Acknowledgments 🫶

Thanks to Marc Petit-Huguenin, who suggested using UUIDs in generating RTCP CNAMEs 🌈 Also, thanks to David McGrew for providing text for the Security Considerations section 💜

8. References 📚

8.1. Normative References

[RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, July 2003.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
           Unique IDentifier (UUID) URN Namespace", RFC 4122,
           July 2005.

[RFC4634]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and HMAC-SHA)", RFC 4634, July 2006.

[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
           Encodings", RFC 4648, October 2006.

[RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
           "Network Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, June 2010.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, February 2006.

[RFC5342]  Eastlake 3rd, D., "IANA Considerations and IETF Protocol
           Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
           September 2008.

8.2. Informative References

[RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
           and E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

[RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
           Address Translator (Traditional NAT)", RFC 3022,
           January 2001.

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, March 2004.

[RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
           Extensions for Stateless Address Autoconfiguration in
           IPv6", RFC 4941, September 2007.

Authors' Addresses 🎀

Ali Begen
Cisco
181 Bay Street
Toronto, ON  M5J 2T3
CANADA

EMail:  abegen@cisco.com


Colin Perkins
University of Glasgow
School of Computing Science
Glasgow  G12 8QQ
UK

EMail:  csp@csperkins.org


Dan Wing
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA  95134
USA

EMail:  dwing@cisco.com
📦 where this page comes from