Résumé

  • La RFC 5153 est un guide Informational de 2008 fondé sur les RFC 5101 et 5102, depuis remplacées par les RFC 7011 et 7012.
  • Un Data Record IPFIX ne porte que des valeurs; le Template associé fournit l’ordre, le type et la longueur nécessaires à leur interprétation.
  • Le collecteur peut mettre en attente un Data Set qui référence un Template ID encore inconnu.
  • La RFC 5153 recommande un délai configurable, avec trente minutes par défaut, puis journalisation et suppression si le Template n’apparaît pas.
  • Pour SCTP et TCP, elle recommande aussi de réinitialiser la Transport Session après l’échec; ce choix n’est pas équivalent à la seule suppression.
  • Le délai de trente minutes est une recommandation historique, pas une obligation universelle pour les déploiements actuels.
  • Un Template ID n’est unique qu’à l’intérieur d’une Transport Session et d’un Observation Domain, et peut changer de sens après un redémarrage.
  • Un Template appris dans une session ne doit jamais servir à décoder les Data Sets d’une session suivante.
  • Plusieurs flux SCTP peuvent séparer l’arrivée des données, du Template et de son retrait malgré une livraison fiable.
  • UDP interdit Template Withdrawal et fait dépendre la cohérence de trois politiques: retransmission, expiration et réutilisation retardée.
  • Attendre plus longtemps augmente la chance de récupération, mais aussi le coût mémoire et le risque d’associer de vieux octets à une nouvelle génération.
  • La gouvernance doit conserver le délai appliqué, la génération de Template, le résultat de décodage et l’acceptation applicative comme preuves distinctes.

La durée transforme une anomalie de transport en politique de mémoire

Dans IPFIX, le Data Set n’explique pas seul ses champs. Son Set ID désigne un Template qui ordonne les types et les longueurs. Tant que ce Template manque, les octets sont présents mais leur découpage reste indéterminé. Le collecteur peut les conserver en attendant la définition.

Cette attente paraît technique. Elle décide pourtant quels événements pourront un jour devenir lisibles. Avant l’échéance, le système traite le Data Set comme une preuve potentielle. Après l’échéance, les mêmes octets deviennent une charge à supprimer. Le passage de l’un à l’autre n’est causé ni par le paquet observé ni par le Template lui-même, mais par une règle locale de temps et de capacité.

La RFC 5153 propose trente minutes par défaut et demande que la valeur soit configurable. Si le Template n’arrive pas, elle recommande de journaliser puis de supprimer les Data Records; avec SCTP ou TCP, elle recommande aussi une remise à zéro de la session. C’est une discipline d’implémentation, non une loi naturelle de la preuve.

Trente minutes ne valent pas la même chose pour toutes les décisions

Une donnée de capacité agrégée peut conserver une valeur après une attente prolongée. Une alerte de sécurité reçue trente minutes trop tard peut être exacte et néanmoins inutile pour contenir l’incident. Une entrée de facturation supprimée peut créer une perte financière; une entrée conservée trop longtemps peut saturer le collecteur.

Copier le délai historique sans définir l’usage revient à déléguer la politique de preuve à une constante logicielle. Il faut nommer le débit maximal des Data Sets inconnus, le budget mémoire, la latence décisionnelle, le risque de réutilisation du Template ID et la procédure de reprise.

Une échéance ne doit pas faire disparaître l’événement lui-même. Même lorsque les octets sont supprimés, le journal doit conserver le nombre de records, leur taille, leur session, leur Observation Domain, l’ID absent, les numéros de séquence et la cause de la décision. Le manque devient alors visible au lieu d’être confondu avec une période sans trafic.

L’ID est un nom local dont l’autorité expire

Le chiffre d’un Template ID n’a pas de signification permanente. L’Exporting Process l’alloue dans un espace limité par la Transport Session et l’Observation Domain. Deux domaines d’observation peuvent utiliser le même nombre pour deux structures différentes, y compris au sein d’une même session.

La fin d’une session SCTP ou TCP retire implicitement ses Templates. Une nouvelle session doit recevoir ses propres définitions. La RFC 7011 interdit au collecteur de reprendre un Template de la session précédente, même si l’exportateur et l’ID numérique semblent identiques.

La clé d’audit réelle comprend donc l’identité de l’exportateur et de la session, l’Observation Domain, le Template ID, la définition et sa génération. « Template 256 » n’est pas une référence reproductible. Il manque le livre, l’édition et la période pendant laquelle la page 256 faisait autorité.

Une arrivée tardive peut sauver les données ou les rendre ambiguës

Dans le cas simple, le Template manquant arrive avant l’échéance. Le collecteur reprend le Data Set, applique la définition et produit des records structurés. La conservation a rempli son rôle.

Mais le cycle de vie autorise aussi le retrait et la redéfinition. Le même ID peut être réutilisé après que l’ancien Template a cessé d’être valable. La RFC 7011 avertit que la mise en tampon de données sans Template peut conduire à une mauvaise interprétation lorsque retrait et redéfinition interviennent.

L’arrivée tardive ne suffit donc pas. Le collecteur doit prouver que la définition reçue était celle qui gouvernait les Data Sets lors de leur émission. Faute de génération ou de bornes temporelles, la récupération apparente peut être plus dangereuse qu’un échec explicite: elle produit des champs plausibles sous une structure fausse.

TCP livre une séquence, pas une définition éternelle

TCP ordonne et retransmet les octets. Pourtant l’exportateur n’est pas obligé de renvoyer régulièrement ses Templates pendant la connexion. Le collecteur doit les conserver pour toute la durée de cette connexion.

Si son état interne est perdu alors que le transport continue, les Data Sets suivants peuvent être fiables au sens TCP et indécodables au sens IPFIX. Si la connexion redémarre, les Templates de l’ancienne session ne traversent pas la frontière avec elle.

Réinitialiser la session après une longue attente, comme le suggère la RFC 5153, est donc un acte de récupération: il force un nouveau contexte. Il ne reconstitue pas les records déjà supprimés et ne prouve pas que l’application a consommé ceux qui furent décodés juste avant la rupture.

SCTP évite un blocage en abandonnant un ordre global

Une association SCTP peut comporter plusieurs streams. Cela réduit le head-of-line blocking et permet de séparer domaines ou catégories de données. IPFIX autorise cependant l’envoi d’un Template Set, d’un Data Set ou d’un retrait sur n’importe quel stream, et le collecteur doit accepter cette liberté.

Le protocole ne décrit pas la répartition choisie par l’exportateur; elle est configurée hors bande. Un retrait transmis sur un stream peut invalider un Template envoyé sur un autre. La fiabilité propre à chaque message ne crée pas un ordre unique entre streams.

La RFC 5153 conseille un délai d’environ une minute avant de réutiliser un ID retiré, afin de réduire les collisions avec des messages encore en transit. La RFC 7011 formalise davantage le séquencement. Dans les deux cas, l’exactitude dépend d’un historique, pas du simple fait que chaque message a fini par arriver.

UDP oblige l’opérateur à accorder trois horloges

UDP ne garantit pas la livraison du Template. La RFC 5153 impose sa retransmission périodique et recommande dix minutes par défaut, réglables entre une minute et une journée. Elle décrit aussi une cadence par paquets, avec vingt Data packets par défaut et une plage de un à mille.

Le collecteur maintient en parallèle une durée d’expiration. La RFC 5153 propose trois fois la cadence de rafraîchissement et, sans accord hors bande, une valeur initiale de soixante minutes. La RFC 7011 conserve le principe des trois intervalles observés, tout en déclarant les valeurs par défaut propres au déploiement et à l’application.

La troisième horloge est celle du tampon des Data Sets inconnus. Si elle expire avant le prochain refresh, les données sont perdues. Si elle dépasse trop largement la durée de vie du Template, elles risquent de rencontrer une réutilisation. Trois réglages individuellement raisonnables peuvent donc produire un système incohérent.

Un refresh trop fréquent peut empêcher les données de partir

Réduire l’intervalle de retransmission semble toujours améliorer la récupération. RFC 5153 décrit pourtant une limite. Si une cadence par paquets est calculée de sorte qu’elle expire avant que tous les Templates ou Options Data aient été envoyés, le système peut recommencer continuellement ce matériel et presque ne plus transmettre de Data.

La politique destinée à garantir la signification affame alors les valeurs qu’elle devait décrire. À l’inverse, une cadence trop longue oblige le collecteur à garder davantage d’octets inconnus et augmente le manque potentiel.

Le tableau de bord doit donc rapprocher débit de Template, débit de Data, taux de décodage et occupation du tampon. Mesurer seulement le nombre de Templates donne un faux signal positif précisément lorsque la répétition empêche les records d’avancer.

L’authentification ne choisit pas la bonne génération

La protection TLS ou DTLS et l’authentification mutuelle sont nécessaires lorsque les données de flux révèlent topologie, filtres ou traductions. Elles permettent d’établir quelles extrémités ont ouvert la Transport Session et de protéger le contenu transmis.

Elles ne déterminent pas si un Template manquant a été livré, s’il appartient au bon Observation Domain ou si l’ID a déjà été réutilisé. Un exportateur authentique peut redémarrer, perdre un datagramme, mal séquencer des actions ou comporter une erreur d’implémentation.

L’identité du locuteur et la validité de la référence sont deux reçus. Les fusionner transforme la confiance dans une organisation en confiance illimitée dans chaque état temporaire de son logiciel.

Décoder n’est pas observer le résultat du réseau

Lorsque le bon Template est enfin disponible, le collecteur peut découper les champs et produire un Flow record. Cette étape prouve que l’assertion de l’exportateur est devenue interprétable. Elle ne prouve pas encore le traitement réel d’un paquet, sa livraison à un utilisateur ou le résultat d’une application.

Le point d’observation, la clé de Flow, l’échantillonnage, l’agrégation, l’horloge, le placement par rapport aux middleboxes et les remises à zéro de compteurs limitent encore la portée. Les Sequence Numbers aident à détecter des trous; ils ne recréent ni Template perdu ni paquets non observés.

Pour une décision importante, la chaîne doit donc séparer la réception du transport, l’autorité du Template, le décodage, l’ingestion applicative et une observation indépendante du service revendiqué.

Sources

  1. RFC 5153, HTML
  2. RFC 5153, texte
  3. Notice RFC Editor
  4. Notice IETF Datatracker
  5. Historique de la RFC 5153
  6. Références de la RFC 5153
  7. Errata de la RFC 5153
  8. RFC 5101
  9. RFC 5102
  10. RFC 7011
  11. RFC 7012
  12. RFC 3917
  13. RFC 5470
  14. RFC 5471
  15. RFC 5473
  16. RFC 4960
  17. RFC 3758
  18. RFC 8085
  19. RFC 4346
  20. RFC 4347
  21. RFC 8446
  22. RFC 9147
  23. RFC 3954
  24. Registre IANA IPFIX
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy