Résumé

  • RFC 3395 a ajouté les verbes applicatifs aux identifiants de protocole RMON, mais une opération pouvait s’étendre sur plusieurs paquets et dans les deux sens d’un échange.
  • RMON exigeait néanmoins qu’un paquet soit compté une seule fois sous une feuille complète. Si plusieurs verbes y figuraient, la sonde devait en retenir un selon une règle locale non normalisée.

Il suffit d’un paquet SNMP Response pour faire disparaître l’illusion de la lecture directe. Le paquet indique qu’une réponse est revenue. Il ne dit pas, à lui seul, si elle répondait à Get ou à GetNext. Pour inscrire ses octets dans le bon compteur, l’appareil doit retrouver une requête antérieure, observée dans le sens opposé. Le chiffre affiché à la fin contient donc un morceau de mémoire.

Publié en septembre 2002 sur la voie de normalisation, RFC 3395 mettait à jour la référence des identifiants de protocole de RFC 2895. Les moniteurs RMON savaient déjà reconnaître des empilements de protocoles. Or « HTTP » ou « SNMP » restait trop large pour comparer le comportement de transactions dont le coût et la portée différaient. Le texte normalisa un vocabulaire d’opérations sans créer de nouveau module MIB ni de nouvel objet administrable.

Dans le modèle hérité de RMON-2, chaque couche ajoutait quatre octets à protocolDirID et un octet à protocolDirParameters. La concaténation décrivait l’encapsulation jusqu’à une feuille. RFC 3395 fit du verbe applicatif une couche supplémentaire : quatre octets composés d’un octet réservé à zéro, puis d’une énumération non signée sur 24 bits en ordre réseau.

Les valeurs explicites allaient de 1 à 16 777 215. Elles devaient être uniques à l’intérieur du protocole parent et, de préférence, attribuées sans grands trous. L’octet de paramètre ajouté valait zéro : inutile au verbe, il maintenait la forme régulière de l’identifiant. L’entrée ne prenait pas en charge la configuration de la table d’adresses, tandis que les capacités de suivi par hôte et par matrice pouvaient être déclarées séparément.

La valeur zéro était déjà occupée. Chaque protocole applicatif possédait implicitement connect(0) pour le trafic d’établissement et de terminaison qui ne relevait d’aucun autre verbe. On ne pouvait pas redéfinir cette énumération. Le nom, lui, n’était pas réservé dans l’absolu : l’exemple HTTP définissait aussi le CONNECT explicite sous connect(8). Parent, valeur et nom formaient ensemble la preuve d’identité de l’étiquette.

La macro VERB-IDENTIFIER reliait un protocole parent à une description, éventuellement à une référence autorisée, et obligatoirement à une liste de couples nom-valeur. La casse des noms comptait. Les termes du protocole d’origine devaient être repris lorsqu’ils existaient. Deux constructeurs pouvaient ainsi nommer une opération de la même façon ; rien ne garantissait encore que leurs sondes la reconnaîtraient au même instant.

Sur TCP, cet instant pouvait arriver tard. Une opération applicative se répartit parfois sur plusieurs segments. La sonde devait suivre le flux et en reconstituer assez pour décider. Si la décision de capturer dépendait du verbe, les premiers paquets risquaient de précéder leur propre classification. Il fallait les conserver dans un tampon préalable, ou accepter qu’une capture dite spécifique à l’opération commence trop tard.

Le mot « verbe » ne désignait donc ni un simple opcode, ni forcément une commande ou un type de PDU. Une transaction pouvait réunir plusieurs types de messages. Elle pouvait même traverser plusieurs entrées du répertoire : avec FTP, le dialogue de contrôle et la connexion de données participent à une même action utile. L’étiquette appartenait au modèle de mesure, pas à un champ toujours présent sur le fil.

Malgré cette ambiguïté, la comptabilité imposait une sortie unique. Chaque paquet contribuait une seule fois à une encapsulation feuille complète, pour sa taille entière. Il n’était pas permis de distribuer ses octets entre plusieurs compteurs de verbes. Si plusieurs opérations cohabitaient, l’agent devait en choisir une.

RFC 3395 évoquait quatre arbitrages possibles : le premier verbe, le plus fréquent, celui qui occupait le plus d’octets, ou celui que la connaissance du protocole rendait le plus intéressant. Il ne consacrait aucune méthode. Deux sondes conformes, alimentées par la même trace, pouvaient donc produire des répartitions différentes. Elles partageaient le dictionnaire et la contrainte d’unicité, non la totalité de leur jugement.

Les exemples consacrés à FTP, POP3, SNMP, HTTP et SMTP montraient l’intérêt du dispositif tout autant que sa limite. Le compteur GET n’atteste ni l’intention d’une personne, ni son autorisation, ni le succès de la transaction. Il n’indique pas nécessairement que la charge utile complète était visible. Il atteste qu’un agent, avec son état disponible et sa politique, a rangé le paquet sous cette feuille.

La section de sécurité ne prétendait pas que cette granularité était neutre. Le RFC n’ajoutait aucune opération MIB, mais les collections révélaient désormais quelles opérations applicatives étaient utilisées. Ce renseignement pouvait justifier une protection plus forte que les totaux par protocole. Raffiner un compteur, c’était aussi raffiner ce qu’un observateur apprenait.

RFC 4502 a ensuite remplacé RFC 2021 comme définition de RMON-2. Cette filiation situe le cadre ; elle ne prouve ni l’adoption commerciale de RFC 3395, ni la profondeur de réassemblage d’un produit, ni son comportement lorsque la table d’état déborde. Un standard décrit ce qu’il faut vérifier, pas ce qui s’exécute déjà.

Le principe de spécification initiale minimale de Lu Heng éclaire ce partage. La norme figeait ce qui devait voyager entre implémentations : encodage, parent, noms, valeur zéro, capacités et obligation de compter une seule feuille. Les délais, la mémoire, la reconstruction et la préférence entre verbes restaient des décisions locales susceptibles d’évoluer avec les protocoles et les ressources.

La primauté du code en fonctionnement impose alors de joindre au compteur ses conditions de fabrication : version du décodeur, limites d’état, pertes, politique de réassemblage et règle de sélection. Sans cette provenance, un tableau de bord stable peut masquer un changement complet du classificateur.

RFC 3395 n’a pas rendu la mesure arbitraire. Il a rendu visible sa chaîne de responsabilité. Avant que le compteur dise GET, la sonde avait dû se souvenir, attendre et choisir. Le nombre observait le réseau ; il documentait aussi, silencieusement, la machine qui l’avait produit.

Sources