Résumé

  • La RFC 3320 confiait chaque message de signalisation à une machine virtuelle de décompression distincte et limitée, y compris lorsque l’émetteur fournissait le programme à exécuter.
  • Le décodage réussi ne suffisait pas à autoriser un état durable : l’application devait authentifier le résultat et fournir un identifiant de compartiment valide avant toute création d’état ou transmission de retour.

La compression transportait aussi un programme

Publiée en janvier 2003, la RFC 3320 décrit SigComp, ou Signaling Compression, pour des protocoles applicatifs comme SIP et RTSP. Son idée n’était pas simplement de choisir un algorithme commun, installé à l’avance chez tous les interlocuteurs. L’émetteur pouvait sélectionner une méthode et joindre le bytecode dont la machine virtuelle de décompression universelle, l’UDVM, avait besoin. Le récepteur devait donc accepter une certaine souplesse tout en empêchant cette computation pilotée à distance de devenir un accès sans limites à la machine.

Cela déplace la question historique. Il ne s’agit pas seulement de savoir combien d’octets un compresseur économise, mais aussi ce qu’un message entrant peut faire calculer au récepteur et ce qu’il peut lui faire retenir. Les RFC ne démontrent ni un taux d’adoption ni des économies mesurées en production. Elles définissent une frontière de protocole : l’expéditeur influence une exécution contrainte, tandis que le destinataire garde la maîtrise des ressources et de la mémoire qui survivra au message courant.

Une exécution neuve et bornée pour chaque message

Chaque message SigComp reçu déclenche une instance UDVM distincte. La mémoire consacrée à la décompression est limitée ; tout point d’extrémité doit offrir au moins 2 048 octets à cette fin. Le nombre d’instructions dépend de la taille du message et du paramètre cycles_per_bit. Pour un message de n octets, le maximum est (8*n + 1000) * cycles_per_bit; le paramètre ne peut descendre sous 16. Il s’agit d’une borne par message, non d’une garantie d’immunité contre tout déni de service ni d’un modèle complet des ressources de l’hôte.

L’instance neuve localise l’échec. Un message mal formé ou épuisant son quota n’enferme pas nécessairement le message valide suivant dans le même état d’exécution. Le récepteur n’est pas obligé de traiter une suite comme un décodeur unique qui s’enrichit indéfiniment. La reprise est explicite, même si le protocole autorise par ailleurs certains états sélectionnés à franchir la frontière entre messages.

Décoder et se souvenir sont deux permissions

SigComp distingue la mémoire temporaire de décompression de la mémoire d’état associée à un compartiment. L’application définit ces compartiments selon le contexte de communication et peut en libérer un lorsqu’il n’a plus lieu d’être. Un point d’extrémité qui ne veut rien conserver peut annoncer une capacité d’état nulle. La persistance n’est donc pas une condition nécessaire à la décompression.

La règle décisive intervient après le décodage. L’application reçoit le message reconstitué et peut lui appliquer l’authentification adaptée à son protocole et à son contexte. Ce n’est que si elle accepte de l’associer à un identifiant de compartiment valide que SigComp est autorisé à créer un nouvel état pour ce compartiment et à transmettre un retour au compresseur. Si la confiance n’est pas suffisante, l’application ne fournit pas d’identifiant valide. L’UDVM s’arrête alors sans enregistrer l’état demandé ni transmettre ce retour.

Le choix sémantique est ainsi confié à la bonne couche. La machine virtuelle peut décoder une séquence dans les limites imposées ; elle ne sait pas décider si le message SIP est authentique, s’il appartient au bon dialogue ou s’il doit influer sur des échanges futurs. L’application dispose de plus d’éléments et conserve le dernier mot. La RFC 4896 a ensuite précisé l’interface entre authentification et création d’état : la sortie du décodeur n’est pas en elle-même une décision de confiance.

L’accès à un état existant suit une autre voie

Une difficulté d’ordre se présente : l’application peut avoir besoin du message décodé pour l’authentifier, alors que la décompression pourrait bénéficier d’un état antérieur. SigComp sépare donc l’accès à l’état existant de la décision applicative prise après décodage. Les identifiants d’état dérivent d’un hachage des octets de cet état ; le récepteur vérifie cet identifiant avant d’exposer l’état à l’UDVM. Cette vérification préalable n’annule pas la règle ultérieure qui exige l’autorisation de l’application pour retenir un nouvel état.

Deux questions distinctes sont en jeu : « ce message peut-il lire un état de compression déjà établi ? » et « le message décodé peut-il créer ou modifier un état durable ? ». Elles surviennent à des moments différents et reposent sur des éléments différents. Les confondre peut donner l’impression d’une incohérence, alors que la première étape rend le décodage possible sous contrôle et que la seconde attend une confiance au niveau applicatif.

Les documents ultérieurs ont traité les problèmes voisins

La RFC 3321 ajoute des opérations et mécanismes d’acquittement ; sur un transport non fiable, le renvoi confirmé importe avant que l’émetteur ne s’appuie sur un état distant. La RFC 4077 décrit les acquittements négatifs pour signaler un échec de décompression. La RFC 5049 adapte les exigences à SIP : ses prescriptions propres à SIP ne doivent pas être généralisées à toutes les applications SigComp. La RFC 4464 sert de guide et la RFC 4465 rassemble des tests extrêmes. Ces textes apportent explications, retour d’erreur et profils applicatifs ; ils ne prouvent pas à eux seuls l’adoption ou les gains mesurés.

L’apport durable de la RFC 3320 est ce partage d’autorité. Un message peut solliciter un calcul limité. L’application décide si sa signification mérite de devenir une mémoire influençant les messages suivants. Séparer ces étapes rend visibles la frontière des ressources et celle de la confiance : « décodé » ne devient pas implicitement « conservé ».

Sources