6. 安全考虑

[RFC3550] 的安全考虑适用于本备忘录.

6.1. RTCP CNAME 唯一性考虑

本节中的考虑适用于随机 RTCP CNAME.

本文档给出的 RTCP CNAME 生成建议确保 RTP 会话中的一组协作参与者将以非常高的概率拥有唯一 RTCP CNAME. 但是, [RFC3550] 和本文档都没有提供任何方法来确保参与者会适当地选择 RTCP CNAME; 因此, 实现不得 (MUST NOT) 依赖 RTCP CNAME 的唯一性来提供任何必要安全服务. 这与 [RFC3550] 一致, 后者并不要求 RTCP CNAME 在会话内唯一, 而是说该条件应当 (SHOULD) 成立. 如 [RFC3550] 安全考虑一节所述, 由于会话中的每个参与者都可以自由选择自己的 RTCP CNAME, 它们可以用这种方式冒充另一个参与者. 也就是说, 假定参与者不会相互冒充. 任何 RTCP CNAME 生成建议都无法防止这种冒充, 因为攻击者可以忽略规定. 安全 RTP (Secure RTP, SRTP) [RFC3711] 可将未授权实体排除在 RTP 会话之外, 但它并不旨在防止来自授权实体的冒充攻击.

由于 PRNG 的性质, 长 RTCP CNAME 和短 RTCP CNAME 之间没有显著的隐私/可关联性差异. 但是, 生成唯一 RTCP CNAME 的要求意味着需要某个最小长度. 96 位长度允许全局约 2^{40} 个 RTCP CNAME, 然后才会出现较大的冲突概率 (约在 2^{48} 个 RTCP CNAME 后有 50% 概率出现一次冲突).

6.2. 基于 RTCP CNAME 的会话关联

早期 RTCP CNAME 生成建议允许固定 RTCP CNAME 值, 这使攻击者能够轻易关联不同 RTP 会话, 从而消除 IPv6 隐私地址 [RFC4941] 或 IPv4 网络地址端口转换 (Network Address Port Translation, NAPT) [RFC3022] 所提供的混淆效果.

本规范不再描述生成固定 RTCP CNAME 值的过程, 因此 RTCP CNAME 值不再在 RTP 会话之间提供此类关联. 这对于消除攻击者进行这种关联是必要的, 但当然会使流量分析设备 (例如查找丢包或延迟包的设备) 进行关联变得更复杂.