Résumé

  • La RFC 5124 nomme SAVPF la composition du profil de retour AVPF et du profil sécurisé SAVP.
  • AVPF continue de décider quand un paquet RTCP peut partir ; SAVP applique ensuite le traitement SRTCP.
  • Tous les paquets RTCP de SAVPF doivent suivre l’encapsulation SRTCP de la RFC 3711.
  • Les champs de sécurité ajoutent couramment de 10 à 20 octets dans le cadre décrit, 14 octets constituant le cas par défaut cité.
  • Cette taille doit alimenter avg_rtcp_size, faute de quoi l’ordonnanceur surestime le nombre de retours possibles.
  • Dans l’approximation N <= B*T/R, une hausse de R réduit les événements signalables avant l’échéance T.
  • Un profil sécurisé choisi ne prouve pas que l’offre et la réponse ont résisté à une attaque de repli.
  • Proposer ensemble des solutions sûres et non sûres impose de protéger correctement la signalisation de négociation.
  • La sélection se fait par description de média ; une ligne vidéo rejetée n’annule pas nécessairement une ligne audio acceptée.
  • L’intégrité SRTCP est obligatoire, mais le chiffrement peut être nul et une clé de groupe ne désigne pas toujours un émetteur unique.
  • Le choix du profil ne prouve ni l’établissement des clés, ni l’acceptation du paquet, ni son arrivée utile, ni la réparation du média.
  • Le registre opérationnel doit conserver séparément offre, protection du choix, clés, taille, mode de retour, délai, action et résultat rendu.

L’attaque précède parfois le premier paquet sécurisé

Deux terminaux savent employer SAVPF. L’offreur souhaite pourtant rester compatible avec un ancien équipement et présente aussi une possibilité AVPF non sécurisée. Sur le papier, la préférence est claire : la solution sûre vient en premier. Sur le réseau, un adversaire qui peut altérer la signalisation peut supprimer cette possibilité avant que SRTP ou SRTCP ne protège quoi que ce soit.

La RFC 5124 situe exactement cette couture. Elle recommande de préférer les profils sûrs et déconseille de mêler, dans une même offre, alternatives sûres et non sûres. Si cette coexistence est néanmoins proposée, la signalisation de négociation doit être protégée de manière appropriée. La préférence locale ne suffit donc pas. Il faut une preuve d’intégrité couvrant l’offre, l’ordre des choix, les attributs de retour et la réponse.

Un résultat final en SAVPF démontre qu’un profil a été retenu pour une description de média. Il ne démontre pas, à lui seul, que personne n’a modifié les alternatives abandonnées. À l’inverse, une session finalement non sécurisée ne prouve pas automatiquement une attaque : l’autre extrémité peut réellement ne pas prendre SAVPF en charge. L’enquête a besoin du transcript signé ou autrement protégé, et non d’une couleur finale dans l’interface.

Une composition, pas une nouvelle magie cryptographique

SAVPF superpose deux mécanismes déjà définis. AVPF, issu de la RFC 4585, modifie les règles temporelles RTCP et ajoute des formats de retour. SAVP, issu de la RFC 3711, fournit le traitement SRTP et SRTCP. La RFC 5124 précise que le fonctionnement de la couche AVPF ne change pas : elle planifie un paquet, puis la couche sécurisée le transforme.

Cette séparation est fondamentale pour l’observation. Le journal AVPF peut prouver qu’un NACK devait partir tôt. Le journal SRTCP peut prouver que le paquet a reçu un index, une étiquette d’authentification et éventuellement un chiffrement. Aucun des deux, isolément, ne prouve que le destinataire l’a accepté dans le contexte cryptographique attendu.

SAVPF hérite des propriétés de SAVP sans ajouter ni retrancher de service de sécurité. Il ne définit ni nouveau algorithme, ni nouveau système de gestion des clés, ni identité de bout en bout. Les attributs SDP de gestion de clés et de retour restent régis par leurs documents respectifs. C’est une architecture minimale : la composition commune est normalisée, les mécanismes voisins gardent leurs limites.

Les octets protégés ont un prix temporel

Le retour RTCP partage une enveloppe de bande passante. La fréquence possible dépend notamment de cette enveloppe, de la taille du groupe et de la taille moyenne des paquets. SRTCP ajoute au paquet RTCP un index et des champs liés à la sécurité. Dans le cadre décrit par la RFC 5124, le supplément est probablement d’au moins 10 à 20 octets, avec 14 octets dans le cas par défaut. D’autres tailles de champs ou transformations peuvent modifier ce coût.

La conséquence normative est directe : la variable avg_rtcp_size doit refléter la taille des paquets SRTCP. Sans cette correction, l’ordonnanceur raisonne sur un paquet imaginaire plus petit que celui transmis. Il attribue ainsi plus d’occasions de retour que le budget n’en permet réellement.

La RFC 4585 résume le mode de retour immédiat par l’inégalité approximative N <= B*T/R. Pour une bande passante B et une fenêtre T données, augmenter la taille moyenne R réduit le nombre N d’événements rapportables. La cryptographie peut être parfaitement correcte et rendre malgré tout le retour moins fréquent. Ce n’est pas un argument contre la sécurité ; c’est un argument pour l’intégrer honnêtement au calcul.

AVPF distingue retour immédiat, RTCP anticipé et RTCP régulier. Dans le premier mode, chaque événement pertinent peut pratiquement être signalé. Dans le deuxième, il faut choisir : tout ne remonte plus. Dans le troisième, un retour individuel perd son utilité compte tenu de l’échelle temporelle ou du groupe. Une modification de taille protégée peut rapprocher la session d’une autre zone sans faire tomber la connexion.

T_max_fb_delay est l’échéance propre à l’application au-delà de laquelle le retour ne sert plus. La RFC 5124 ne lui donne pas une valeur universelle. Un rapport reçu et authentifié après cette limite reste une réussite cryptographique, mais peut être un échec de réparation.

Quatre profils, un choix par média

Pour une description de média, AVP, AVPF, SAVP et SAVPF sont des choix mutuellement exclusifs. Si l’offreur emploie SAVPF et que le répondant ne le prend pas en charge, ce média doit être rejeté. Si le répondant désire SAVPF alors que l’offre ne l’a pas proposé, il doit également rejeter la ligne et peut lancer plus tard une contre-offre. Il ne peut pas faire passer un changement de profil pour une simple acceptation.

La portée est la ligne m=. Un son sécurisé peut être accepté tandis qu’une vidéo échoue. D’autres sessions RTP peuvent employer d’autres profils. Le mot « appel » est donc trop grossier comme clé d’audit. Il faut conserver, pour chaque média, l’offre exacte, la réponse, le profil, le mécanisme de clés, l’adresse de transport et l’époque de configuration.

La compatibilité interne possède aussi une limite précise. Des entités SAVP et SAVPF peuvent coexister dans une même session RTP sécurisée ; les règles d’interfonctionnement AVPF s’appliquent. De même, AVP et AVPF peuvent coexister dans une session non sécurisée. En revanche, les familles RTP et SRTP ne doivent pas être mélangées dans la même session. « Compatible » ne signifie donc pas « toute combinaison est possible ».

Ce que signifie réellement « sécurisé »

La RFC 3711 permet confidentialité, intégrité ou authentification de message et protection contre le rejeu. L’intégrité SRTCP est obligatoire parce qu’une altération des messages de contrôle peut perturber le flux. Mais le chiffrement reste une propriété distincte, et un algorithme de chiffrement NULL existe. La simple présence de SAVPF ne doit donc pas devenir l’affirmation publique que chaque octet de contrôle était confidentiel.

Dans certains groupes, une étiquette valide peut montrer que le paquet vient d’un détenteur de la clé partagée sans identifier lequel. La RFC 3711 prévient elle-même que « authentification » peut alors désigner surtout l’intégrité. L’identité de l’émetteur dépend du modèle de clés, pas de la force rhétorique du mot.

Le contexte réel comprend les algorithmes, les clés maîtresses et de session, l’index SRTCP, la fenêtre de rejeu, les durées de validité et, le cas échéant, l’identifiant de clé. Un paquet peut être correctement formé et néanmoins rejeté parce que l’époque de clé diffère ou parce que l’index tombe hors fenêtre. Une capture du token SDP n’explique pas cet échec.

Trois chemins de signalisation, trois preuves

Dans le modèle offre-réponse, les deux parties négocient par média. Dans le scénario RTSP décrit par la RFC 5124, le client choisit exactement un profil par flux dans SETUP et le serveur confirme ou refuse. Changer ensuite de profil exige, dans cette procédure historique, de démonter puis de rétablir le flux. Ce changement est une coupure potentielle, une nouvelle négociation de clés et une nouvelle identité de transport, pas une mutation cosmétique.

Une annonce non interactive par SAP, courrier ou page web ne reçoit pas de réponse. L’initiateur doit alors fournir des descriptions utilisables et protéger la distribution des paramètres. La RFC 4568 est sans ambiguïté : des clés incluses dans une description de sécurité peuvent être lues si le canal de distribution ne garantit pas la confidentialité. Protéger ensuite les paquets avec une clé déjà exposée ne restaure rien.

Les RFC 8866 et 7826 ont depuis remplacé les spécifications historiques de SDP et RTSP citées dans le document, tandis que les RFC 5763 et 5764 ont normalisé le contexte DTLS-SRTP évoqué à l’état de travaux. Ces évolutions documentaires n’actualisent pas automatiquement la RFC 5124 et ne prouvent aucune mise en œuvre actuelle.

Une chaîne de reçus vérifiable

Le premier reçu est la capacité déclarée de chaque extrémité. Le deuxième est l’offre exacte. Le troisième est la protection de la signalisation. Le quatrième est le choix confirmé par média. Le cinquième est l’établissement des clés et du contexte. Le sixième est l’acceptation du paquet SRTCP. Le septième est son coût réel dans le budget RTCP. Le huitième est son arrivée avant l’échéance utile. Le neuvième est l’action de l’émetteur. Le dixième est la récupération observée par le décodeur et l’utilisateur.

Le registre IANA prouve l’allocation de paramètres. La fiche RFC prouve le statut de Proposed Standard et l’absence d’un document déclaré comme mise à jour ou obsolescence. Aucune source capturée ne prouve une part de marché, un produit, une interopérabilité mesurée ou une amélioration contemporaine de la qualité. Cette absence impose une analyse du mécanisme, pas une histoire inventée de déploiement.

Sources