12. Considérations de sécurité
Les paquets RTP utilisant le format de charge utile défini dans la présente spécification sont soumis aux considérations de sécurité générales discutées dans RTP [3], section 9.
Dans les scénarios courants de streaming, l'authentification des messages, l'intégrité des données, la protection contre la relecture et la confidentialité sont souhaitables.
L'absence d'authentification peut permettre des attaques de l'homme du milieu et par relecture, qui peuvent être très nuisibles pour la retransmission RTP. Par exemple : des paquets RTCP altérés peuvent déclencher des retransmissions inappropriées qui réduisent effectivement la part de débit binaire réellement allouée au flux de données d'origine, des paquets RTP de retransmission altérés pourraient provoquer le plantage du décodeur du client, et des demandes de retransmission altérées peuvent invalider le mécanisme d'association SSRC décrit à la section 5 du présent document. D'autre part, des paquets rejoués pourraient conduire à un faux réordonnancement et à des mesures de RTT (requises pour la stratégie de demande de retransmission) et peuvent provoquer le débordement de la mémoire tampon du récepteur.
En outre, pour assurer la confidentialité des données, la charge utile d'origine doit être chiffrée. Il n'y a en réalité pas besoin de chiffrer l'en-tête de charge utile de retransmission de 2 octets puisqu'il n'apporte aucune indication sur le contenu des données.
En outre, il est RECOMMENDED que les mécanismes cryptographiques utilisés pour ce format de charge utile fournissent une protection contre les attaques à texte clair connu. RTP recommande que l'horodatage RTP initial SHOULD être aléatoire pour sécuriser le flux contre les attaques à texte clair connu. Ce format de charge utile ne suit pas cette recommandation car l'horodatage initial sera l'horodatage média du premier paquet retransmis. Toutefois, comme l'horodatage initial du flux d'origine est lui-même aléatoire, si le flux d'origine est chiffré, l'horodatage du premier paquet retransmis serait aussi aléatoire pour un attaquant. La confidentialité ne serait donc pas compromise.
Si la cryptographie est utilisée pour fournir des services de sécurité sur le flux d'origine, alors les mêmes services, avec une force cryptographique équivalente, MUST être fournis sur le flux de retransmission. L'usage de la même clé pour le flux retransmis et le flux d'origine peut conduire à des problèmes de sécurité, par exemple des biffages à deux reprises (two-time pads). Se reporter à la section 9.1 du Secure Real-Time Transport Protocol (SRTP) [12] pour une discussion des implications des biffages à deux reprises et des moyens de les éviter.
Au moment de la rédaction du présent document, SRTP ne fournit pas tous les services de sécurité mentionnés. Il y a au moins deux raisons à cela : 1) la survenue de biffages à deux reprises et 2) le fait que ce format de charge utile fonctionne typiquement sous le profil RTP/AVPF alors que SRTP ne prend en charge que RTP/AVP. Une variante adaptée de SRTP devrait à l'avenir remédier à ces lacunes.
Les considérations de contrôle de congestion liées à l'usage de la retransmission sont traitées à la section 7 du présent document.