Résumé

  • Le projet de l’OPSAWG daté du 28 septembre est toujours un Internet-Draft, avec l’état I-D Exists ; ses nouveaux identifiants IPFIX restent proposés.
  • La révision 01 distingue quatre questions souvent fusionnées dans un tableau de bord : frontière du datagramme, traitement du paquet, présence du champ et omission à l’export.

À la lecture d'un relevé, une case vide paraît simple. En réalité, elle peut désigner une propriété qui n'existait pas, un champ que l'observateur ne pouvait pas lire, une capture trop courte, une version de QUIC qu'il ne sait pas délimiter, ou une valeur acquise puis retirée selon une règle locale. Si l'outil de restitution range tout sous « absent », il prête à la mesure une certitude qu'elle n'a jamais eue.

La révision 01 de draft-ietf-opsawg-ipfix-quic-header apporte une réponse de structure. Le texte antérieur proposait sept éléments d'information QUIC ; le nouveau en propose 24 et précise quatre profils d'export : observation du réseau, observation du paquet à l'extrémité, agrégation par flux et état de connexion facultatif. Le profil réseau part d'une unité physique définie : un paquet IP non fragmenté contenant un datagramme UDP complet. Une seule fiche principale représente ce datagramme. Les paquets QUIC coalescés qui peuvent être délimités deviennent des sous-fiches ordonnées, chacune avec son décalage. Les compter comme des fiches indépendantes ferait perdre leur contexte commun.

La distinction la plus utile pour la gouvernance de la mesure tient aux états. quicDatagramParseStatus concerne l'énumération des frontières de paquets dans le datagramme. quicProcessingStatus dit ce qu'il est advenu du traitement d'un paquet donné. quicExportFlags concerne autre chose : des données normalement disponibles que la politique locale n'a pas exportées, ou qu'une limite de taille ou de ressources a tronquées. On peut donc avoir une analyse complète des frontières, un paquet dont le traitement a échoué et, indépendamment, une exportation incomplète. Il ne s'agit pas de trois notes de confiance à additionner.

Un quatrième mécanisme résout l'ambiguïté du zéro. Avec un modèle IPFIX fixe, chaque champ annoncé doit avoir une place dans chaque enregistrement. Lorsque le bit quicFieldPresence est éteint, la valeur zéro ou vide qui occupe cette place n'est qu'un substitut à ignorer. Lorsque le bit est allumé, un zéro peut être une véritable valeur. Ainsi, une chaîne vide ne prouve pas qu'un identifiant ou un Token de longueur nulle a été observé, pas plus qu'elle ne prouve son absence dans le trafic. C'est la sémantique de la fiche qui tranche.

Le projet précise aussi le cas d'une version QUIC non prise en charge. Les champs invariants ne suffisent pas toujours à trouver la frontière suivante. L'exportateur peut conserver les paquets précédents correctement délimités et marquer une observation terminale partielle ; il ne doit pas présenter les éventuels paquets suivants comme inexistants. Dans le profil réseau, numéros de paquet, types de trame et identifiants de flux ne sont de toute façon pas exportés. Leur absence dans la fiche est une limite du profil, pas un constat sur le réseau.

Ces descriptions portent sur une proposition de format. Elles n'attestent ni déploiement, ni attribution définitive par l'IANA, ni capacité générale à reconnaître QUIC parmi tout le trafic UDP. La portée nouvelle est plus précise : le projet rend plusieurs causes de lacune représentables séparément.

Sources