11.2. Multicast (one sender) (组播 - 单发送者)

11.2. Multicast (one sender) (组播 - 单发送者)

与 (未受保护的) RTP 一样, 在大型组中由于发送者可能需要处理的 SRTCP 接收者报告数量可能非常大而产生可扩展性问题。在 SRTP 中, 发送者可能必须为每个接收者保持状态 (密码学上下文), 或更准确地说, 为用于保护接收者报告的 SRTCP 保持状态。开销与组的大小成正比增加。特别是, 重新密钥需要特别关注, 见下文。

首先考虑一个小型接收者组。在接收者之间分配主密钥有几种可能的设置。给定一个单一的 RTP 会话, 一种可能性是接收者根据第 9.1 节共享相同的主密钥, 以保护所有各自的 RTCP 流量。这个共享的主密钥可以与发送者用于保护其出站 SRTP 流量的密钥相同。或者, 它可以是仅在接收者之间共享并仅用于其 SRTCP 流量的主密钥。两种选择都要求接收者相互信任。

考虑到 SRTCP 和密钥存储, 建议使用低速率 (或零) key_derivation (强制性的初始派生除外), 以便发送者不需要存储太多会话密钥 (否则每个 SRTCP 流在给定时间点可能具有不同的会话密钥, 因为 SRTCP 源在不同时间发送)。因此, 如果希望对 SRTP 进行密钥派生, 则可以将 SRTP 的密码学上下文与 SRTCP 密码学上下文分开保存, 以便 SRTCP 的 key_derivation_rate 可以为 0, 而 SRTP 的值为非零。

对于大多数应用, 建议使用 MKI 进行重新密钥 (参见第 8.1 节)。

如果有多个 SRTP/SRTCP 流 (在同一 RTP 会话内) 共享主密钥, 则 2^48 个 SRTP 数据包 / 2^31 个 SRTCP 数据包的上限意味着, 在其中一个流达到其最大数据包数之前, 必须在共享主密钥的所有流上触发重新密钥。(从严格的安全角度来看, 只有达到最大值的流需要重新密钥, 但那样流将不再共享主密钥, 这不是本意。) 发送方侧的本地策略应该以不在任何流上达到最大数据包限制的方式强制重新密钥。建议使用 MKI 进行重新密钥。

在具有一个发送者的大型组播中, 与小型组播相同的考虑适用。此场景中最大的问题是发送方侧增加的负载, 这是由于必须为发送回 RTCP 接收者报告的每个接收者维护状态 (密码学上下文)。至少, 可能需要为每个 RTCP 源维护一个重放窗口。