11.2. Multicast (one sender)
11.2. Multicast (one sender)
Tout comme avec RTP (non protégé), un problème de passage à l'échelle se pose dans les grands groupes en raison de la quantité potentiellement très importante de rapports de récepteur SRTCP que l'émetteur peut avoir besoin de traiter. Dans SRTP, l'émetteur peut avoir à maintenir un état (le contexte cryptographique) pour chaque récepteur, ou plus précisément, pour le SRTCP utilisé pour protéger les rapports de récepteur. La surcharge augmente proportionnellement à la taille du groupe. En particulier, le renouvellement des clés nécessite une attention particulière, voir ci-dessous.
Considérons d'abord un petit groupe de récepteurs. Il existe quelques configurations possibles avec la distribution des clés maîtresses parmi les récepteurs. Étant donné une seule session RTP, une possibilité est que les récepteurs partagent la même clé maîtresse selon la section 9.1 pour sécuriser tout leur trafic RTCP respectif. Cette clé maîtresse partagée pourrait alors être la même que celle utilisée par l'émetteur pour protéger son trafic SRTP sortant. Alternativement, il pourrait s'agir d'une clé maîtresse partagée uniquement entre les récepteurs et utilisée uniquement pour leur trafic SRTCP. Les deux alternatives exigent que les récepteurs se fassent mutuellement confiance.
En ce qui concerne SRTCP et le stockage des clés, il est recommandé d'utiliser une key_derivation à faible débit (ou nulle) (sauf celle initiale obligatoire), de sorte que l'émetteur n'ait pas besoin de stocker trop de clés de session (chaque flux SRTCP pourrait autrement avoir une clé de session différente à un moment donné, car les sources SRTCP envoient à des moments différents). Ainsi, si une dérivation de clé est souhaitée pour SRTP, le contexte cryptographique pour SRTP peut être maintenu séparé du contexte cryptographique SRTCP, de sorte qu'il soit possible d'avoir un key_derivation_rate de 0 pour SRTCP et une valeur non nulle pour SRTP.
L'utilisation du MKI pour le renouvellement des clés est RECOMMANDÉE pour la plupart des applications (voir section 8.1).
S'il y a plus d'un flux SRTP/SRTCP (dans la même session RTP) qui partagent la clé maîtresse, la limite supérieure de 2^48 paquets SRTP / 2^31 paquets SRTCP signifie qu'avant qu'un des flux n'atteigne son nombre maximum de paquets, le renouvellement des clés DOIT être déclenché sur TOUS les flux partageant la clé maîtresse. (D'un point de vue de sécurité strict, seul le flux atteignant le maximum aurait besoin d'être re-clé, mais alors les flux ne partageraient plus la clé maîtresse, ce qui est l'intention.) Une politique locale côté émetteur devrait forcer le renouvellement des clés de manière à ce que la limite maximale de paquets ne soit pas atteinte sur aucun des flux. L'utilisation du MKI pour le renouvellement des clés est RECOMMANDÉE.
Dans une grande diffusion multidestination avec un émetteur, les mêmes considérations que pour la diffusion multidestination de petit groupe s'appliquent. Le plus gros problème dans ce scénario est la charge supplémentaire placée côté émetteur, en raison de l'état (contextes cryptographiques) qui doit être maintenu pour chaque récepteur, renvoyant des rapports de récepteur RTCP. Au minimum, une fenêtre de rejeu pourrait devoir être maintenue pour chaque source RTCP.