Résumé

  • Dans RFC 3486, comp=sigcomp s’attachait à l’URI du prochain saut ou à l’en-tête qui commandait une réponse et les échanges futurs ; chaque tronçon et chaque sens pouvaient donc faire un choix différent.
  • Le paramètre exprimait à la fois la capacité et la volonté présente de recevoir un message comprimé. Il ne prouvait ni les octets réellement envoyés, ni l’analyse SIP, ni la livraison, ni l’authentification, ni l’établissement de la session.

Le détail le plus révélateur de RFC 3486 n’est pas le mot « compression ». C’est le changement d’en-tête qui gouverne la décision. Pour une requête, le client regarde l’URI du prochain saut. Pour une réponse, le serveur regarde l’entrée Via la plus haute. Pour de futures requêtes dans le dialogue, Contact et Record-Route déplacent encore l’autorité. Le même jeton circule, mais sa portée ne cesse de changer.

Cette architecture répondait à un problème combinatoire. NAPTR et SRV permettaient déjà de choisir UDP, TCP ou SCTP. Ajouter dans le DNS chaque combinaison de transport, TLS et SigComp aurait multiplié les enregistrements. RFC 3486 plaça donc l’indication de compression dans SIP. Un même port pouvait recevoir du SIP ordinaire et du SigComp, le début du message comprimé fournissant les bits de discrimination.

Le paramètre comp=sigcomp ne signifiait pas seulement « je possède le logiciel ». Il associait support et volonté de recevoir des messages comprimés. Cette deuxième dimension empêchait de transformer une capacité installée en obligation permanente. Une entité pouvait être capable aujourd’hui et ne pas vouloir l’utiliser pour ce message ou ce chemin.

La règle négative était ferme : si le client ignorait si le serveur du prochain saut prenait SigComp en charge, il ne devait pas comprimer la requête. Il pouvait toutefois envoyer cette requête sans compression en ajoutant le paramètre dans son Via supérieur. Le serveur compatible pouvait alors comprimer la réponse. Une demande ordinaire pouvait donc négocier un retour comprimé sans prétendre que l’aller l’avait été.

Avant la création d’un dialogue, le client ne disposait pas encore du jeu de routes. RFC 3486 proposait une configuration manuelle ou un échange OPTIONS non comprimé avec le proxy sortant. Le proxy pouvait fournir dans Contact une autre URI munie du paramètre. Cette réponse établissait une voie proposée ; il fallait encore observer la requête suivante pour savoir si elle avait effectivement été comprimée.

Contact et Record-Route servaient ensuite de mémoire de routage. Un agent qui voulait recevoir de futures requêtes comprimées inscrivait son choix dans Contact. Un proxy souhaitant rester sur le chemin utilisait Record-Route. Lors du retour, il pouvait ajouter ou retirer le paramètre de sa propre entrée après avoir examiné le prochain saut en amont. La route future était donc recalculée, et non héritée comme une propriété intangible du dialogue.

L’exemple de l’RFC est une réfutation pratique de l’idée « bout en bout ». Quatre éléments participent à l’échange, plusieurs connaissent SigComp, mais seuls les messages 1, 6 et 7 sont comprimés. Un proxy reçoit un INVITE comprimé puis le transmet en clair. Une réponse passe d’abord sans compression, puis est comprimée pour le dernier tronçon à cause du Via supérieur. L’ACK suit encore une autre combinaison.

Le double Record-Routing ne rendait pas le chemin uniforme. Un proxy placé entre deux réseaux pouvait enregistrer deux interfaces afin d’éviter la réécriture, tout en acceptant des messages comprimés d’un côté et ordinaires de l’autre. S’il constatait que son prochain saut était lui-même, sans transmission réseau, il pouvait même renoncer à comprimer malgré le paramètre.

La panne révélait une asymétrie plus sévère. Un serveur ignorant SigComp pouvait ne rien comprendre au message comprimé, pas même atteindre Via pour savoir où envoyer une erreur SIP. Le silence n’identifiait donc pas la cause. Après expiration de la transaction, le client devait réessayer la même requête sans compression.

Sur TCP, ce nouvel essai exigeait une frontière supplémentaire : fermer l’ancienne connexion et en ouvrir une autre. Sans cela, le serveur incapable de SigComp risquait de ne pas retrouver le début du nouveau message dans le flux. Le délai, la nouvelle forme du message et la nouvelle connexion devaient rester trois preuves distinctes.

Le paramètre n’authentifiait pas non plus celui qui l’insérait. Un attaquant capable d’ajouter comp=sigcomp pouvait provoquer l’envoi de trafic comprimé vers une entité incompatible ; l’intégrité des messages était donc nécessaire. La décompression consommait aussi davantage de calcul et augmentait légèrement l’exposition au déni de service.

L’enregistrement IANA stabilisait le nom comp et la valeur sigcomp, pas leur utilisation réelle. RFC 3320 définit la machine de décompression, RFC 3485 le dictionnaire SIP/SDP immuable, et RFC 5049 mit ensuite RFC 3486 à jour avec des minima de ressources, des compartiments et une gestion d’état. RFC 4077, RFC 4896, RFC 5112 et RFC 5626 complètent d’autres dimensions. Aucun de ces textes ne transforme la présence d’un jeton en mesure de déploiement.

Une enquête sérieuse conserve donc l’URI exacte du prochain saut, le Via supérieur, Contact, Route et Record-Route, le sens du message, la protection d’intégrité, les octets effectivement transmis et l’identité de la connexion. Elle sépare la découverte OPTIONS de l’usage ultérieur, puis le délai du nouvel essai. Enfin seulement viennent la décompression, l’analyse SIP, l’authentification et le résultat de session.

La leçon historique est une leçon de portée. RFC 3486 a évité d’exploser le DNS en combinaisons et a laissé le destinataire influencer le choix. Mais il l’a fait en attachant l’autorité au prochain saut. Le paramètre voyageait dans la signalisation ; il ne transformait jamais le chemin entier en une seule vérité.

Sources