11.2. Multicast (one sender) (Multicast - ein Sender)
11.2. Multicast (one sender) (Multicast - ein Sender)
Wie bei (ungeschütztem) RTP entsteht in großen Gruppen ein Skalierbarkeitsproblem aufgrund der möglicherweise sehr großen Menge an SRTCP-Empfängerberichten, die der Sender möglicherweise verarbeiten muss. In SRTP muss der Sender möglicherweise für jeden Empfänger einen Zustand (den kryptografischen Kontext) aufrechterhalten, oder genauer gesagt, für das SRTCP, das zum Schutz der Empfängerberichte verwendet wird. Der Overhead steigt proportional zur Größe der Gruppe. Insbesondere erfordert das erneute Schlüsseln besondere Aufmerksamkeit, siehe unten.
Betrachten Sie zunächst eine kleine Gruppe von Empfängern. Es gibt einige mögliche Konfigurationen mit der Verteilung von Hauptschlüsseln unter den Empfängern. Bei einer einzelnen RTP-Sitzung besteht eine Möglichkeit darin, dass die Empfänger gemäß Abschnitt 9.1 denselben Hauptschlüssel teilen, um ihren gesamten jeweiligen RTCP-Verkehr zu sichern. Dieser gemeinsam genutzte Hauptschlüssel könnte dann derselbe sein, der vom Sender zum Schutz seines ausgehenden SRTP-Verkehrs verwendet wird. Alternativ könnte es ein Hauptschlüssel sein, der nur unter den Empfängern geteilt und ausschließlich für ihren SRTCP-Verkehr verwendet wird. Beide Alternativen erfordern, dass die Empfänger einander vertrauen.
In Anbetracht von SRTCP und Schlüsselspeicherung wird empfohlen, eine key_derivation mit niedriger Rate (oder null) zu verwenden (außer der obligatorischen anfänglichen), damit der Sender nicht zu viele Sitzungsschlüssel speichern muss (jeder SRTCP-Stream könnte andernfalls zu einem bestimmten Zeitpunkt einen anderen Sitzungsschlüssel haben, da die SRTCP-Quellen zu unterschiedlichen Zeiten senden). Wenn also eine Schlüsselableitung für SRTP gewünscht wird, kann der kryptografische Kontext für SRTP vom SRTCP-Kryptokontext getrennt gehalten werden, sodass es möglich ist, eine key_derivation_rate von 0 für SRTCP und einen Wert ungleich null für SRTP zu haben.
Die Verwendung des MKI für das erneute Schlüsseln wird für die meisten Anwendungen EMPFOHLEN (siehe Abschnitt 8.1).
Wenn es mehr als einen SRTP/SRTCP-Stream gibt (innerhalb derselben RTP-Sitzung), der den Hauptschlüssel teilt, bedeutet die Obergrenze von 2^48 SRTP-Paketen / 2^31 SRTCP-Paketen, dass, bevor einer der Streams seine maximale Anzahl von Paketen erreicht, das erneute Schlüsseln auf ALLEN Streams ausgelöst werden MUSS, die den Hauptschlüssel teilen. (Aus streng sicherheitstechnischer Sicht müsste nur der Stream, der das Maximum erreicht, neu verschlüsselt werden, aber dann würden die Streams den Hauptschlüssel nicht mehr teilen, was die Absicht ist.) Eine lokale Richtlinie auf der Senderseite sollte das erneute Schlüsseln so erzwingen, dass das maximale Paketlimit auf keinem der Streams erreicht wird. Die Verwendung des MKI für das erneute Schlüsseln wird EMPFOHLEN.
Bei großem Multicast mit einem Sender gelten dieselben Überlegungen wie für kleinen Gruppen-Multicast. Das größte Problem in diesem Szenario ist die zusätzliche Last auf der Senderseite aufgrund des Zustands (kryptografische Kontexte), der für jeden Empfänger aufrechterhalten werden muss, der RTCP-Empfängerberichte zurücksendet. Mindestens muss möglicherweise für jede RTCP-Quelle ein Wiederholungsfenster aufrechterhalten werden.