Skip to main content

6. Security Considerations

The security considerations of [RFC3550] apply to this memo.

6.1. Considerations on Uniqueness of RTCP CNAMEs​

The considerations in this section apply to random RTCP CNAMEs.

The recommendations given in this document for RTCP CNAME generation ensure that a set of cooperating participants in an RTP session will, with very high probability, have unique RTCP CNAMEs. However, neither [RFC3550] nor this document provides any way to ensure that participants will choose RTCP CNAMEs appropriately; thus, implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for any essential security services. This is consistent with [RFC3550], which does not require that RTCP CNAMEs are unique within a session but instead says that condition SHOULD hold. As described in the Security Considerations section of [RFC3550], because each participant in a session is free to choose its own RTCP CNAME, they can do so in such a way as to impersonate another participant. That is, participants are trusted not to impersonate each other. No recommendation for generating RTCP CNAMEs can prevent this impersonation, because an attacker can neglect the stipulation. Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP session, but it does not aim to prevent impersonation attacks from authorized entities.

Because of the properties of the PRNG, there is no significant privacy/linkability difference between long and short RTCP CNAMEs. However, the requirement to generate unique RTCP CNAMEs implies a certain minimum length. A length of 96 bits allows on the order of 2^{40} RTCP CNAMEs globally before there is a large chance of collision (there is about a 50% chance of one collision after 2^{48} RTCP CNAMEs).

6.2. Session Correlation Based on RTCP CNAMEs​

Earlier recommendations for RTCP CNAME generation allowed a fixed RTCP CNAME value, which allows an attacker to easily link separate RTP sessions, eliminating the obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 Network Address Port Translation (NAPT) [RFC3022].

This specification no longer describes a procedure to generate fixed RTCP CNAME values, so RTCP CNAME values no longer provide such linkage between RTP sessions. This was necessary to eliminate such linking by an attacker, but of course complicates linking by traffic analysis devices (e.g., devices that are looking for dropped or delayed packets).

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 in RFC 6222.

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.

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

  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

8.2. Informative References​

  • [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, April 2011.

  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., 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.

  • [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

  • [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

  • [ARCH] Rescorla, E., "WebRTC Security Architecture", Work in Progress, July 2013.

  • [RESCORLA] Rescorla, E., "Random algorithm for RTP CNAME generation", Work in Progress, July 2012.

Last updated on