Résumé

  • RFC 9607 enregistre audio/scip et video/scip, les associe à SDP et demande au réseau de relayer la charge SCIP variable sans transcodage, filtrage de forme ni modification.
  • La présence du sous-type dans l’offre SDP ne négocie pas les codecs internes ni l’état de sécurité ; arrivée RTP, réassemblage, contrôle d’intégrité, échange SCIP, identité et rendu sont des reçus différents.
  • Le texte précise que l’IETF n’a pas effectué d’examen de sécurité de SCIP et n’a donc pas vérifié les affirmations de sécurité du document.

Le pare-feu avait enfin appris à ne rien apprendre

Pendant longtemps, l’équipement intermédiaire avait traité tout pseudo-codec inconnu comme une erreur. Il supprimait la ligne scip de la déclaration SDP, transmettait le reste de la session et produisait un journal parfaitement propre. Aux deux extrémités, pourtant, les terminaux SCIP ne pouvaient plus démarrer.

La correction n’a pas consisté à enseigner le protocole secret au pare-feu. Elle a consisté à lui donner un nom stable et une limite de compétence. Il reconnaît audio/scip ou video/scip, applique la politique autorisant ce type de média, puis laisse passer les octets opaques. RFC 9607 transforme ainsi l’ignorance contrôlée en comportement interopérable.

Cette réussite demeure locale. Le journal du pare-feu prouve que le réseau n’a pas retiré la proposition et n’a pas altéré la charge. Il ne dit pas si le destinataire a réassemblé les paquets, si les versions SCIP étaient compatibles, si le pair attendu a été authentifié ou si la voix est devenue audible.

Une déclaration SDP ouvre une possibilité, pas une conversation

Le sous-type audio/scip utilise une horloge de 8000 Hz ; video/scip, 90000 Hz. La ligne m= nomme le média et a=rtpmap lie un numéro dynamique à scip et à l’horloge. Dans le modèle offre/réponse, l’ordre des numéros exprime une préférence.

Ces éléments ont une autorité précise : ils définissent comment les parties parlent de SCIP dans cette session RTP. Le numéro 96, par exemple, n’est pas une identité universelle ; il reçoit son sens de la correspondance négociée. La présence de cette correspondance ne choisit pas le codec audio ou vidéo encapsulé. SCIP effectue ensuite son propre échange de capacités et de versions dans le canal opaque.

Un outil qui colore en vert « média sécurisé » dès que l’offre et la réponse contiennent scip saute plusieurs transitions. Il lui manque le premier paquet, l’ordre complet, le réassemblage, l’acceptation cryptographique, la négociation de session, le décodage et le résultat utilisateur. La signalisation a ouvert un couloir ; elle n’a pas parcouru le couloir.

L’opacité protège aussi le futur

Le format de la charge SCIP varie avec l’état du protocole et le média interne. RFC 9607 interdit au réseau de transcoder, de compresser avec perte, de modifier ou de filtrer cette charge selon sa forme observée. Un boîtier qui reconnaît aujourd’hui une séquence de bits pourrait rejeter demain une version légitime qu’il ne connaît pas.

Le risque est l’ossification par commodité. Une signature de trafic devient une règle de sécurité, puis une condition contractuelle, puis un point de blocage installé dans chaque chemin. La mise à jour des terminaux ne suffit plus : il faut convaincre toute une chaîne d’intermédiaires que le nouveau chiffré est encore valide.

La discipline de RFC 9607 est plus modeste et plus robuste. Le réseau connaît le nom extérieur, les contraintes RTP et sa propre politique de ressources. Il ne s’arroge pas l’autorité de juger la syntaxe interne. L’évolution reste entre les extrémités qui exécutent réellement SCIP.

Un paquet sous la MTU n’est pas un message complet

La couche applicative SCIP veille à ne pas remettre à RTP un trafic dépassant la MTU. À la réception, la couche RTP SCIP identifie les paquets, les remet en ordre et réassemble l’unité. Si nécessaire, l’application détecte l’erreur et gère la retransmission.

Quatre mesures peuvent donc diverger. Le paquet émis respectait la taille. Il est arrivé avec un numéro de séquence. L’ensemble requis a été réassemblé. L’application a accepté le résultat avant son échéance. Une perte au bord d’un fragment, un doublon ou une récupération tardive peut laisser les compteurs RTP rassurants et le message absent.

Le reçu exploitable doit conserver la direction, le numéro de charge négocié, la plage de séquences, les fragments attendus, l’heure de clôture du réassemblage, le résultat d’intégrité et la décision de l’application. Une moyenne de perte ne peut pas reconstruire cette causalité après incident.

Le rejet d’intégrité est un veto, pas une attestation générale

Le texte indique que la charge SCIP est protégée en intégrité. Une modification est détectée par l’extrémité, entraîne une retransmission et peut aboutir à l’échec de la communication. Cette propriété interdit à un intermédiaire de transformer silencieusement le média chiffré.

Un échec d’intégrité prouve cependant une chose étroite : un objet n’a pas été accepté dans un état donné. Il n’attribue pas la cause à un adversaire. Il ne prouve pas que la retransmission a réussi. L’absence d’alarme ne prouve pas que tous les objets sont arrivés, que le bon correspondant détenait les clés ou que le décodeur a produit du sens.

Il faut donc séparer configuration, événement et résultat. « Intégrité activée » décrit une politique. « Objet rejeté » décrit une observation. « Remplacement reçu, accepté et rendu avant délai » décrit une récupération. Fusionner ces états retire précisément le pouvoir de diagnostic que le mécanisme fournit.

Le chiffré n’enveloppe pas tout RTP

SCIP chiffre le contenu transporté dans la charge RTP. Il ne protège pas pour autant l’en-tête RTP ni les paquets RTCP. Une application peut ajouter SRTP si ces surfaces doivent être protégées, mais RFC 9607 laisse ce choix optionnel.

Le profil RTP retenu est ainsi une donnée de sécurité à part entière. AVP, AVPF, SAVP et SAVPF n’offrent pas le même traitement des commandes et du retour. Les mécanismes de retour de perte AVPF ou SAVPF sont eux aussi optionnels, car SCIP récupère certains paquets à sa propre couche. La protection interne ne doit pas être projetée sur l’enveloppe externe.

Cette séparation évite aussi de dupliquer l’autorité. RTP transporte et ordonne. Un profil peut protéger certains éléments RTP/RTCP. SCIP négocie ses capacités et protège son contenu. La preuve d’une couche n’est pas le reçu d’une autre.

Le numéro du RFC n’est pas un label d’assurance

RFC 9607 énonce clairement que l’IETF n’a pas conduit de revue de sécurité de SCIP et n’a pas vérifié les affirmations correspondantes. La publication normalise le point d’interopérabilité RTP/SDP ; elle ne transforme pas le protocole interne en produit certifié.

Cette réserve permet une gouvernance plus exacte. On peut tester la conformité au document : sous-types, horloges, correspondance SDP, absence de transcodage, transparence du chemin et comportement RTP. Pour l’authentification du pair, la gestion des clés, la confidentialité ou la résistance à l’attaque, il faut une autre source, un autre essai et un autre responsable.

Une organisation qui inscrit seulement « conforme à RFC 9607 » dans un contrôle de sécurité achète une abstraction trop large. Elle devrait nommer la propriété voulue et le reçu qui la prouve. Le standard coordonne le passage ; l’assurance reste une décision locale appuyée sur l’exécution.

Sources