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).