Résumé

  • Un projet OPSAWG propose sept éléments d'information IPFIX pour les en-têtes QUIC, le numéro de paquet, le type de trame et l'identifiant de flux. Dans la version 00, les numéros restent à attribuer et les valeurs protégées supposent un déchiffrement réussi.
  • Le texte retient expressément la définition IPFIX du flux, et non celle d'une connexion QUIC. Les cinq-uplets changent, les identifiants de connexion tournent, et une migration volontaire échappe à l'association passive.
  • Daniel Kade propose une provenance au niveau du champ : point d'observation, méthode d'acquisition, autorité de déchiffrement, pertes, périmètre d'identité et décision autorisée. Cette proposition éditoriale n'est pas une exigence de l'IETF.

Dans un centre d'exploitation, la tentation la plus forte n'est pas de falsifier une donnée. Elle consiste à retirer les précisions qui l'accompagnent afin que toutes les données puissent entrer dans le même modèle.

La version QUIC devient un entier. Le Connection ID devient une chaîne d'octets. Le numéro de paquet, le type de trame et le Stream ID deviennent d'autres colonnes. Quand la ligne est pleine, le logiciel lui donne un identifiant de « connexion » et les graphiques commencent.

Or la ligne réunit peut-être trois pouvoirs distincts : ce qu'un routeur voit sans clé, ce qu'il peut découper grâce à une longueur configurée et ce qu'une extrémité révèle après avoir ouvert la protection QUIC. La normalisation est réelle. La reconstruction ne l'est pas encore.

Une adoption de groupe de travail, pas une allocation achevée

Le dossier de draft-ietf-opsawg-ipfix-quic-header-00 indique une mise à jour le 11 septembre 2026 et le statut WG Document. Aucun statut RFC visé, shepherd, Area Director responsable ou telechat n'est enregistré. Le texte vient de remplacer un projet individuel et demeure un Internet-Draft au stade I-D Exists.

Il demande sept nouveaux éléments : quicHeaderFlag, quicVersion, quicDestinationConnectionID, quicSourceConnectionID, quicPacketNumber, quicFrameType et quicStreamID. Les identifiants portent encore les marqueurs TBD1 à TBD7. L'IANA n'a donc pas transformé la proposition en vocabulaire permanent.

Le besoin est néanmoins solide. QUIC protège une grande partie des informations de transport que les équipements intermédiaires lisaient dans TCP. Des éléments communs permettraient à plusieurs exportateurs de nommer de la même manière ce qu'ils ont réellement mesuré. Le risque commence lorsque « même nom » est interprété comme « même accès » ou « même couverture ».

Le visible, le configuré et le déchiffré

Dans un en-tête long, la version ainsi que les Connection IDs source et destination sont exposés. Le premier octet mêle des bits visibles et des bits protégés. Dans un en-tête court, le Destination Connection ID est présent sans longueur explicite. Un équipement intermédiaire doit connaître cette longueur, par configuration ou par contexte antérieur, pour savoir où le champ s'arrête.

Une valeur quicDestinationConnectionID peut ainsi provenir d'une longueur portée dans le paquet ou d'une règle locale. La valeur brute ne conserve pas cette différence. Si la configuration change, l'ancien résultat peut devenir impossible à reproduire alors que la cellule n'a pas changé.

Le numéro de paquet, le type de trame et l'identifiant de flux sont protégés. RFC 9001 décrit la protection de l'en-tête et du paquet : une partie du premier octet et le numéro de paquet sont masqués, tandis que les trames se trouvent dans la charge chiffrée. La version 00 réserve donc ces observations aux extrémités ou à des appareils capables de déchiffrer QUIC.

Cette capacité doit être qualifiée. RFC 9312 explique qu'un observateur de transit peut dériver les secrets Initial à partir d'une constante de version et du premier Destination Connection ID du client. Les paquets Handshake et 1-RTT reposent sur des clés établies par les extrémités. Récupérer une trame Initial ne prouve ni l'accès aux secrets 1-RTT ni le droit institutionnel d'exporter toute structure de flux.

Une taxonomie d'acquisition est donc nécessaire : visible sur le fil, apparié par configuration, dérivé du secret Initial, déchiffré par l'extrémité, ou inféré. Une case remplie n'indique pas laquelle de ces opérations a eu lieu.

Le flux IPFIX a un lieu

RFC 7011 définit un flux comme un ensemble de paquets ou de trames qui passent par un Observation Point pendant un intervalle et partagent certaines propriétés. Le Flow Record rend compte de cet ensemble observé. Le projet QUIC insiste lui-même : son terme « flow » est celui d'IPFIX, pas celui de QUIC.

Cette réserve empêche de faire d'un outil de mesure un registre ontologique.

L'Observation Point peut être un port, une sonde, une interface logique ou un ensemble plus large. L'Observation Domain ID n'est unique que pour l'Exporting Process. Un Metering Process compose les enregistrements, un Exporting Process les transmet, et un Collecting Process les interprète. Deux domaines portant le même numéro chez deux exportateurs ne forment pas une identité mondiale.

Une connexion QUIC vit aux extrémités. Elle peut traverser plusieurs cinq-uplets, utiliser plusieurs espaces de numéros de paquet et contenir de nombreux flux. Un routeur situé sur l'ancien chemin n'observe pas nécessairement le nouveau. Une extrémité connaît les états cryptographiques, mais ne sait pas nécessairement où un paquet a été écarté dans le réseau. Leurs récits sont complémentaires, jamais automatiquement interchangeables.

Le Connection ID n'est pas un numéro de dossier

RFC 9000 prévoit plusieurs Connection IDs actifs pour une même connexion. Chaque extrémité fournit les identifiants que l'autre emploiera vers elle. Les identifiants peuvent être remplacés et retirés; certains déploiements choisissent une longueur nulle.

Cette souplesse autorise le rebinding et la migration sans assujettir la connexion à une adresse et un port. Elle limite aussi la corrélation. RFC 9312 avertit qu'un nouvel identifiant ne signifie pas nécessairement une nouvelle connexion, et qu'un même identifiant sur un autre cinq-uplet ne suffit pas toujours à prouver la continuité. Lors d'une migration intentionnelle, l'identifiant change précisément pour éviter une association passive.

Un regroupement par cinq-uplet peut donc couper une connexion en deux, ou fusionner plusieurs connexions qui partagent un couple adresse-port. Un regroupement strict par Connection ID peut couper la rotation. Un algorithme qui associe toute répétition inter-chemins peut inventer une continuité.

La conclusion raisonnable est proportionnée : un Connection ID est un excellent outil de routage dans le contexte prévu; il n'est pas, à lui seul, une identité d'audit permanente.

Exporter le protégé déplace la frontière

L'exportateur d'extrémité dispose d'informations que le protocole refuse au chemin. Il est souvent préférable qu'il fournisse une visibilité ciblée plutôt que de distribuer des clés aux équipements intermédiaires. Mais cette architecture déplace la frontière de divulgation vers le collecteur IPFIX.

Sécuriser le transport IPFIX ne clôt pas la décision. RFC 7011 prévoit confidentialité, intégrité et authentification, et souligne que les données de flux peuvent être identifiantes et sensibles pour la vie privée. Il reste à déterminer quels collecteurs et quels locataires reçoivent les numéros de paquet, les types de trame ou les Stream IDs, pendant combien de temps et pour quel usage.

Ces champs ne sont pas le contenu applicatif. Leur combinaison révèle toutefois une structure et un rythme que l'observateur passif ne possédait pas. « Télémétrie » n'est pas une exemption. Une donnée endpoint-décryptée doit conserver le rôle de l'extrémité et l'autorisation; une donnée Initial-dérivée doit garder sa classe; une donnée configurée doit nommer la version de configuration. Les clés secrètes, elles, ne quittent jamais leur périmètre.

La continuité d'export n'est pas la totalité du trafic

Le Sequence Number d'IPFIX compte les Data Records envoyés dans un flux d'export pour un domaine d'observation. Une discontinuité permet au collecteur de détecter des enregistrements manquants ou désordonnés. Elle ne révèle pas les paquets perdus avant l'Observation Point, exclus par échantillonnage, ignorés par la mesure ou impossibles à déchiffrer.

Les Templates comptent aussi. Un Data Record n'a de sens qu'avec le Template Record applicable. Un modèle perdu ou remplacé peut rendre les octets ininterprétables. L'heure d'export n'est pas l'heure de capture. Une transformation du collecteur n'est pas la mesure brute. Une séquence sans trou prouve une propriété de l'export, pas l'exhaustivité d'une connexion.

Il faut donc nommer le périmètre : aucun Data Record manquant pour l'exportateur E, le domaine D et l'intervalle S; tous les paquets vus au point P sous la politique M; tous les champs protégés ouverts parmi les paquets reçus par l'extrémité R. La formule est plus longue qu'« observation complète », mais elle ne promet pas l'inobservable.

Une provenance attachée au champ

Je propose un relevé de provenance d'observation au niveau du champ. Il ne modifie pas les sept éléments et ne prétend pas créer l'objet universel « connexion QUIC ».

Chaque valeur relie l'exportateur, le domaine et l'Observation Point exact; les heures de capture et d'export; la direction, le cinq-uplet, la forme d'en-tête et la version; l'élément, le Template et la valeur brute ou l'absence explicite; enfin la classe d'acquisition.

Pour un champ protégé, le relevé indique le rôle de l'extrémité et l'autorité de déchiffrement, jamais la clé. Pour un Connection ID, il note sa longueur et la source de cette longueur, l'émetteur de l'identifiant, le sens et les limites de visibilité sur sa rotation. Pour un numéro de paquet, il conserve l'espace concerné. Pour une trame ou un flux, il garde l'occurrence du paquet au lieu d'une simple liste dédupliquée.

Le relevé ajoute politique de mesure et d'échantillonnage, pertes de capture, suppressions d'export, ruptures de séquence, révision de Template et transformations du collecteur. Il finit par les consommateurs autorisés, la rétention, le droit d'agréger, la décision visée, l'incertitude, le responsable et l'expiration.

Ce dispositif est une proposition éditoriale de Daniel Kade. Ni la version 00, ni OPSAWG, ni IANA ne l'exigent. Il sert à empêcher qu'une valeur exacte obtienne, par simple voisinage, le pouvoir de certifier une connexion entière.

Employer des formulations graduées

« Version vue dans un en-tête long au point P » est une observation du fil. « Destination ID d'en-tête court découpé selon la configuration C » est un résultat configuré. « Type de trame Initial récupéré par secrets dérivables » décrit une acquisition cryptographique limitée. « Stream ID exporté par le serveur E » est une affirmation d'extrémité. « Ces flux appartiennent à une même connexion » reste une conclusion de corrélation.

Le vocabulaire commun d'IPFIX rend ces affirmations comparables. Il ne les fusionne pas. Le bon résultat n'est pas un écran qui semble tout savoir, mais une exploitation capable de dire exactement qui a pu voir chaque chose.

Sources