Résumé

  • Le texte du 28 septembre ajoute une responsabilité côté réception : sans connaître le périmètre de distinction d’un PSID, un collecteur peut produire une corrélation ambiguë ou fausse.
  • L’Internet-Draft reste au stade I-D Exists. Il ne décrit ni méthode obligatoire pour transmettre ce périmètre ni erreur constatée chez un opérateur.

Le piège apparaît au moment où plusieurs flux IPFIX arrivent dans un même entrepôt. Une requête rapproche deux enregistrements parce qu’ils portent le même identifiant de segment de chemin. Cette égalité ne suffit pourtant pas : chacun des deux émetteurs peut employer sa propre portée d’allocation. Le rapprochement transforme alors une convention locale en vérité globale.

La révision 07 de draft-ietf-opsawg-ipfix-path-segment déplace le regard vers ce traitement en aval. La révision 06 proposait déjà les éléments IPFIX psidMplsLabelStackSection pour MPLS et srhPsidIPv6 pour SRv6. Elle rappelait que l’entité établissant l’association avec le chemin devait maintenir des valeurs distinguables dans le périmètre voulu, et qu’une réutilisation au-delà de celui-ci ne définissait aucune corrélation. Les numéros des deux éléments sont toujours provisoires : TBD1 et TBD2.

La nouveauté substantielle est un paragraphe de la section 4.1.3. Un collecteur, ou un intermédiaire qui traite des enregistrements IPFIX, doit connaître le périmètre où le PSID demeure distinct. Ignorer ce cadre peut fausser le lien entre les données. Le projet ne précise pas comment l’information de périmètre sera acquise ni appliquée ; il laisse ce mécanisme aux déploiements. Il identifie donc une condition d’interprétation, pas une solution universelle déjà codifiée.

La portée du PSID n’est d’ailleurs pas nécessairement celle d’une seule liste de segments. Selon le cas, une valeur peut désigner plusieurs listes ou regrouper des chemins candidats dans une politique SR. Pour donner un sens à l’export, l’analyste doit disposer de l’association actuelle entre PSID et contexte de chemin. Le texte évoque la consultation d’un contrôleur et BGP-LS, mais ne normalise pas l’entretien de cette correspondance. Un ancien tableau peut rendre une jointure aussi trompeuse qu’un domaine erroné.

Autre limite : reconnaître un chemin ne prouve pas qu’il fonctionne bien. Une dégradation ne change pas automatiquement le PSID ; une protection locale peut agir sans changer l’identifiant. Les mesures de perte et de délai restent des observations distinctes. La condition du G-Flag pour lire l’entrée finale de l’en-tête SRv6 relève également de versions antérieures, pas de l’ajout de septembre.

Le projet signale enfin que l’export des PSID peut révéler topologie et répartition du trafic au-delà des champs habituels d’un flux. Une meilleure corrélation doit donc être assortie d’un contrôle d’accès adapté. Rien dans ce document de travail ne démontre une panne, une adoption ou une attaque précise.

Sources