Résumé

  • Le RFC 5345 décrit une chaîne de mesure SNMP en cinq étapes : capturer, convertir, filtrer, stocker puis analyser. La position de la sonde, les VLAN visibles, le filtre, la longueur capturée et la fenêtre temporelle bornent ce que l’absence d’un paquet peut signifier.
  • Le pcap brut permet de rejouer une conversion après la découverte d’un défaut. Les formats XML et CSV sont des projections différentes ; l’anonymisation protège l’opérateur tout en retirant parfois la structure nécessaire à l’analyse. Aucun fichier dérivé ne récupère une observation que la sonde n’a jamais faite.

Le dénominateur était hors champ

Le rapport comptait les messages avec méthode. Chaque ligne avait un horodatage, une adresse source, une destination, une version SNMP et un type d’opération. Le code était public et le calcul reproductible. Pourtant, la population mesurée n’était pas « le réseau ». C’était le trafic remis à un port de supervision déterminé.

Dans un LAN commuté, cette nuance est décisive. Le RFC 5345 demande que la sonde ait accès à tous les VLAN transportant le trafic de gestion et recommande de documenter les limites des fonctions de monitoring du pont. Une session passant par un segment non répliqué n’est pas une rareté statistique ; elle se trouve hors du dispositif.

L’erreur de gouvernance arrive après l’erreur de mesure. Une équipe conclut que les écritures directes n’existent pas et retire un contrôle. Une autre dimensionne le collecteur d’après un volume incomplet. Un auditeur assimile « aucun SET observé » à « aucun SET exécuté ». Le fichier n’a jamais prétendu cela ; le titre du rapport lui a donné une autorité qu’il ne possédait pas.

La bonne formulation transporte le champ d’observation : interfaces, sens, VLAN, ports, pertes, dates et hypothèses de transport. Une absence sans ce dénominateur est seulement une absence dans une vue.

Le filtre de capture est déjà une politique

Le document cite comme cas typique UDP et les ports 161 ou 162. « Typique » n’est pas « exhaustif ». Une infrastructure peut employer une autre cartographie de transport, un tunnel, un proxy, une adresse distincte ou une protection transport qui change le point observable.

Le filtre pcap décide donc quels paquets peuvent devenir des données. Une expression trop étroite ne produit pas une erreur de parsing ; elle produit un corpus silencieusement incomplet. Une expression trop large augmente l’exposition de données sans garantir que la sonde soit au bon endroit.

La longueur de capture a la même portée. Un paquet tronqué peut conserver assez d’en-tête pour être compté tout en perdant la valeur ou la liaison variable dont dépend l’analyse. Le RFC insiste sur la capture intégrale des paquets. Le snap length doit figurer dans la preuve, au même titre que le nombre de pertes et la capacité du port miroir.

Ces choix devraient être versionnés comme le code. Changer un filtre entre deux périodes peut fabriquer une tendance. Ajouter un VLAN à la supervision peut donner l’impression que le trafic augmente alors que seule la visibilité s’élargit.

Une semaine décrit une semaine

Le RFC 5345 recommande au moins une semaine complète afin d’inclure les rythmes diurnes et un cycle hebdomadaire. Il encourage des durées plus longues. Cette recommandation est utile précisément parce qu’elle reconnaît la temporalité du trafic.

Mais une semaine ne contient pas nécessairement la clôture mensuelle, la maintenance trimestrielle, un basculement, un incident rare ou une campagne de mise à jour. La période ne devient pas représentative par la seule force du calendrier.

La métadonnée doit mentionner les événements connus, pannes d’équipement et changements majeurs survenus pendant la collecte. Sans cette chronologie, une baisse de requêtes peut être attribuée à une optimisation alors qu’un système était arrêté. Une pointe peut ressembler à une nouvelle politique alors qu’un inventaire venait d’être reconstruit.

Le temps de capture n’est pas non plus le temps de l’état physique. Certains agents actualisent leurs compteurs selon des algorithmes adaptatifs, ni périodiquement ni à la demande. La réception d’une valeur à midi n’établit pas que l’instrumentation sous-jacente était fraîche à midi.

Le checksum erroné pouvait être une ombre de la machine

Une trace prise sur l’hôte qui émet peut montrer un checksum de transport incorrect parce que la carte réseau ne l’a pas encore calculé. L’offload déplace une partie du traitement après le point où le logiciel de capture observe le paquet.

Le RFC 5345 propose de désactiver cette fonction lorsque cela est possible, ou de corriger ou ignorer ces checksums pendant la conversion. Ce choix doit rester visible. Sinon, le même paquet peut être classé « corrompu » par une version du pipeline et « valide » par la suivante, puis être présenté comme un changement du réseau.

Les fragments IP posent un problème voisin. Une analyse des champs SNMP exige leur réassemblage. Une absence de réassemblage ne démontre pas une absence de message ; un réassemblage défectueux ne démontre pas un message authentique.

Un rapport sérieux sépare donc les erreurs sur le fil, les artefacts de capture, les politiques de correction et les échecs du parseur. Le mot « invalide » sans provenance est trop large pour guider une décision.

XML garde davantage ; CSV choisit davantage

Le format XML du RFC 5345 conserve les détails pertinents du message SNMP et une partie de l’encodage ASN.1/BER utile à l’étude des tailles. Son espace de noms est urn:ietf:params:xml:ns:snmp-trace-1.0.

Le CSV sert un autre objectif. Il garde des champs sélectionnés afin d’être compact et rapide. Cette réduction est légitime tant que la question reste compatible avec elle. Le document prévient que le CSV ne conserve pas l’information nécessaire pour comprendre les traps SNMPv1.

Une implémentation peut convertir ces traps vers la forme SNMPv2c/v3 selon le RFC 3584, mais l’activation de cette conversion relève du choix de l’utilisateur. Après cette étape, la trace représente un original interprété sous une règle connue. Elle ne doit pas être mélangée à des messages natifs comme si l’histoire n’avait pas changé.

La forme dérivée doit donc porter son contrat : schéma, version, convertisseur, règles de normalisation et champs perdus. La validation syntaxique n’atteste ni la couverture de la sonde ni la fidélité au réseau entier.

Le pcap brut est une possibilité de correction

Le RFC recommande de conserver le pcap original, compressé et chiffré, parce qu’un défaut d’outil peut être découvert après publication. Avec les octets retenus, on peut reconstruire XML, CSV et agrégats. Sans eux, le résultat erroné devient parfois irréfutable par simple disparition de sa source.

Le texte qualifie le pcap de source la plus authentique dans cette chaîne. Il ne faut pas gonfler cette formule. Le fichier ne contient pas le VLAN invisible, le paquet perdu, la période non capturée ou le transport exclu. Il est la meilleure preuve des octets vus par cette sonde.

La conservation brute a aussi un coût. Les traces SNMP exposent noms d’utilisateur, chaînes communautaires, adresses, valeurs d’objets et topologie. Le droit de la protection des données ou le risque de contrainte externe peut justifier leur suppression. La décision est légitime, mais elle abaisse irréversiblement la capacité de relecture.

Un registre de preuve devrait donc noter l’existence du brut, son gardien, sa durée, le hash, les droits d’accès et la date où toute reconstruction deviendra impossible.

L’anonymisation conserve parfois ce qu’elle voulait cacher

Les index de table peuvent intégrer des valeurs sensibles. Les en-têtes décrivent les endpoints. La métadonnée du point de mesure peut aider à localiser une cible. Retirer seulement les secrets les plus visibles ne suffit pas.

Le RFC propose un principe d’inclusion : ne garder une valeur que si son type est connu et si une transformation appropriée existe. Cette prudence protège contre l’hypothèse qu’un octet inconnu serait anodin.

Pour certaines analyses, il faut préserver l’ordre lexicographique des index. Les transformations qui conservent cet ordre offrent une utilité réelle, mais le document avertit que leur force d’anonymisation est généralement plus faible. La structure qui permet de classer peut aussi permettre de corréler.

Des exécutions indépendantes peuvent employer des clés différentes. Fusionner leurs pseudonymes comme s’ils formaient un identifiant mondial invente des continuités ou des ruptures. La portée de clé et les garanties de jointure appartiennent donc à la provenance.

« Anonymisé » n’est pas un état binaire. Il faut savoir quoi, comment, pour quelle analyse et avec quelle perte de protection.

Un compteur exact peut produire un débit fictif

Deux réponses SNMP peuvent contenir exactement les valeurs transmises par l’agent. Leur soustraction peut néanmoins être fausse si le compteur a subi une discontinuité.

Le RFC rappelle sysUpTime et ifCounterDiscontinuityTime. Un redémarrage, une réinitialisation d’interface ou un changement d’instrumentation peut casser la série. L’algorithme qui suppose une progression continue impose au dispositif une histoire que le protocole n’a pas confirmée.

Les données dérivées doivent garder les indicateurs de discontinuité, les trous de collecte, les wraps possibles et la sémantique exacte du type. Quand ces éléments disparaissent, un chiffre décimal propre devient moins fiable qu’un intervalle explicitement incertain.

Le même principe vaut pour un error-status égal à zéro. Il prouve une valeur de réponse dans un échange observé. Il ne prouve pas l’autorité humaine, la persistance de la configuration, l’état physique ou le résultat commercial.

L’enregistrement IANA ne certifie pas une étude

IANA a enregistré l’espace de noms XML du format. Cette action coordonne un nom et sa référence. Elle évite que deux vocabulaires distincts revendiquent le même identifiant.

Elle ne certifie pas un capteur, un fichier, un parseur ou une publication. Elle ne mesure pas l’adoption. Elle ne transforme pas le RFC 5345 en norme Internet. La note IESG dit explicitement le contraire : le document est informatif, issu de l’IRTF, et son aptitude à un usage n’a pas été avalisée par l’IETF.

Le registre dit « ce nom désigne cette spécification ». La preuve de déploiement dit qui l’utilise. La validation dit si un fichier respecte la grammaire. La reproductibilité dit si l’analyse peut être rejouée. Ces reçus ne sont pas interchangeables.

Une chaîne de preuve, pas un badge

La mesure défendable relie :

  1. la population annoncée ;
  2. la position et la visibilité de la sonde ;
  3. le filtre, la longueur, les pertes et la fenêtre ;
  4. l’identité du pcap brut ;
  5. les règles de checksum et de réassemblage ;
  6. la version du convertisseur et du format ;
  7. le filtrage et l’anonymisation ;
  8. le code d’analyse et ses paramètres ;
  9. le résultat avec son dénominateur ;
  10. une preuve distincte pour l’état ou l’autorité hors trafic.

Cette discipline ne ralentit pas l’automatisation. Elle l’empêche de transformer un angle mort en vérité institutionnelle.

Sources