Résumé

  • draft-ietf-opsawg-ipfix-quic-header-00 propose sept éléments d’information IPFIX pour décrire des observations QUIC ; trois d’entre eux portent sur des champs protégés qui exigent un déchiffrement réussi.
  • La présence d’une valeur atteste au mieux ce qu’un exportateur identifié a récupéré avec une configuration donnée. Elle n’atteste ni l’exhaustivité d’une connexion, ni l’autorisation d’utiliser les clés, ni le traitement par l’application.

Dans un collecteur, une ligne associe un quintuple, un Connection ID QUIC, un Packet Number et un Stream ID. La présentation est nette. Les colonnes auront peut-être demain des numéros normalisés par l’IANA. Toute l’esthétique invite à croire que la connexion a été mise en fiche.

Ce que la ligne met réellement en fiche, c’est un acte d’observation.

Le projet de groupe OPSAWG publié le 10 septembre propose quicHeaderFlag, quicVersion, quicDestinationConnectionID, quicSourceConnectionID, quicPacketNumber, quicFrameType et quicStreamID. Les drapeaux, la version et les Connection IDs des en-têtes longs comprennent des informations visibles sur le réseau. Packet Number, Frame Type et Stream ID sont protégés ; ils ne deviennent disponibles qu’à un terminal ou à un appareil intermédiaire capable de déchiffrer QUIC.

La visibilité elle-même ne suffit pas à garantir l’interprétation. Dans un en-tête court, la longueur du Destination Connection ID n’est pas transportée. Un appareil intermédiaire doit connaître à l’avance l’identifiant ou sa longueur. Cette configuration peut être juste, périmée ou appliquée au mauvais trafic. Or la valeur exportée ne contient pas à elle seule la preuve de l’hypothèse qui a permis de la découper.

Le sens du mot « flow » empêche une autre confusion. Le projet précise qu’il emploie la définition IPFIX, et non une notion propre à QUIC. Selon le RFC 7011, un Flow réunit des paquets ou des trames observés à un point déterminé, pendant un intervalle, avec des propriétés communes. Le Metering Process peut sélectionner, échantillonner, horodater et dériver des données avant la création du Flow Record. Un enregistrement fidèle à cette définition n’est donc pas, par construction, le journal complet d’une connexion QUIC.

QUIC rend cette différence particulièrement visible. Une connexion peut continuer après un changement d’adresse ou de port. Les terminaux émettent plusieurs Connection IDs, les remplacent et les retirent. Un même dialogue peut traverser plusieurs quintuplets. Et le Connection ID, loin d’être un identifiant mondial du client ou de l’appareil, n’a de sens que dans le contexte de l’émetteur qui l’a choisi. Relier deux observations séparées exige une méthode et une trace de corrélation.

Le Packet Number est lui aussi relatif. QUIC possède des espaces distincts pour Initial, Handshake et Application Data, auxquels s’ajoute le sens du trafic. Un trou dans une suite observée peut signaler une perte sur le réseau. Il peut également venir d’un échantillon, d’un autre chemin, d’un démarrage tardif, de clés absentes ou d’un Flow Record perdu pendant l’export. Le RFC 7011 autorise la sélection et décrit la perte de Data Records quand les tampons sont sous pression. Deux numéros voisins ne certifient donc pas tout ce qui s’est produit entre eux.

Frame Type ne signifie pas « action exécutée ». Il choisit la grammaire à appliquer après retrait de la protection, sans prouver que tous les champs ont été conservés, que le pair a traité la trame ou que l’application en a accepté l’effet. Stream ID n’est unique qu’au sein d’une connexion. Sans contexte de connexion validé et rapprochement avec le terminal, il ne désigne pas durablement une requête, un utilisateur ou une transaction.

Le déchiffrement impose enfin de séparer capacité et mandat. Enlever correctement les protections authentifie un paquet dans un contexte de clés. Cela n’accorde pas automatiquement le droit de posséder ces clés, d’exporter les champs obtenus, de les conserver chez tel collecteur ou de déclencher une décision. L’autorisation doit voyager dans une chaîne de garde distincte.

La section Security Considerations de la révision 00 affirme ne rien ajouter au RFC 7012. Cette brièveté ne fait pas disparaître les risques déjà décrits par IPFIX. Le RFC 7011 traite l’authentification des exportateurs et collecteurs, l’intégrité, la confidentialité du trafic, la vie privée et l’injection de faux messages ou modèles. Ces garanties entourent l’élément d’information ; elles ne sont pas déductibles de sa seule valeur.

Un dossier vérifiable conserve le point et le domaine d’observation, l’identité de l’exportateur, la version du parseur, l’hypothèse de longueur des en-têtes courts, les filtres et l’échantillonnage, le contexte et l’autorité de déchiffrement, le modèle IPFIX, l’espace de numéros, les compteurs de perte, le collecteur et la durée de conservation. Chaque rapprochement entre quintuplets, Connection IDs et streams doit ensuite être confronté aux journaux du terminal puis de l’application.

Cette discipline laisse intacte l’utilité du projet : un vocabulaire commun réduit les schémas privés et permet à plusieurs outils d’échanger la même observation bornée. Mais la révision 00 reste un Internet-Draft, dont l’état Datatracker est I-D Exists. Elle ne constitue ni un RFC, ni une preuve de déploiement, ni une mesure de bénéfice opérationnel.

La règle de direction tient en une phrase : l’exportateur répond de ce qu’il a vu, pas de l’ensemble qu’il n’a pas pu voir. La continuité de la connexion, la réception d’un stream, le traitement d’une commande et le résultat commercial réclament chacun leur propre reçu.

Sources