Résumé

  • La version 15 du projet de manifeste des données collectées désigne désormais current-period, l’intervalle effectif entre deux mises à jour périodiques, comme une valeur lisible potentiellement sensible : elle peut révéler le rythme de collecte.
  • Le texte distingue les autorisations de lecture NETCONF/RESTCONF de celles d’une base de séries temporelles qui conserve les mêmes métadonnées. L’avis de sécurité favorable rendu le 24 septembre porte sur le projet, pas sur une norme adoptée ni sur une installation réelle.

Quand un équipement ralentit ses notifications parce qu’il est chargé, il faut pouvoir distinguer cette adaptation d’une perte de paquets. Le manifeste sert précisément à donner aux mesures reçues leur contexte : la période demandée par l’abonnement et la période réellement pratiquée peuvent diverger. Sans cette seconde valeur, un analyste risque de diagnostiquer une panne là où l’appareil a simplement changé de cadence. Mais fournir une meilleure explication au destinataire légitime peut aussi renseigner un lecteur indésirable sur la fréquence des observations.

Le champ n’apparaît pas pour la première fois dans la version 15. La version 14 décrivait déjà son fonctionnement. Elle affirmait pourtant dans sa partie sécurité que le module n’avait pas de nœud lisible particulièrement sensible. Le nouveau texte retire cette assurance. Il avertit que current-period expose la période réelle, donc potentiellement le calendrier de collecte, et qu’une personne connaissant les intervalles sans collecte pourrait tenter d’y placer une activité malveillante pour échapper plus facilement à la détection. Il s’agit d’un scénario de menace conditionnel, non du récit d’une attaque observée.

Il serait tout aussi abusif de transformer une période en carte complète des angles morts. Le chiffre ne fournit pas à lui seul l’instant exact de chaque prélèvement et ne prouve pas qu’aucun autre capteur ne fonctionne entre deux notifications. L’inférence dépend de l’architecture, des indices temporels disponibles et de l’accès au manifeste. Le risque formulé par l’IETF est plus précis : un attribut publié pour interpréter une mesure peut aussi révéler une propriété de l’observation elle-même.

Le parcours des avis explique le changement. Le 1er septembre, une revue de sécurité de la version 14 signalait la sensibilité de la période, s’interrogeait sur l’existence de filtres fins dans les systèmes concernés et demandait de ne pas transmettre toutes les métadonnées lorsque certaines seraient sensibles. La version 15 ajoute des précisions sur ces trois points. Une nouvelle revue, achevée le 24 septembre, estime que les questions relatives aux détails de la plateforme et aux horaires de collecte ont été traitées de manière adéquate.

Le statut « Ready » est une appréciation du texte par le relecteur ; le Datatracker affiche toujours un Internet-Draft actif, destiné à devenir une Proposed Standard, dans l’état IESG « Waiting for AD Go-Ahead ».

La nouvelle section de sécurité sépare aussi deux lieux où les droits doivent être vérifiés. Pour la consultation des nœuds YANG par NETCONF ou RESTCONF, le transport sécurisé, l’authentification mutuelle et NACM peuvent borner la lecture. Mais le manifeste et les données peuvent ensuite être conservés dans une base de séries temporelles. Les permissions de cette base peuvent être grossières, voire absentes pour les champs en question. Le projet conseille d’utiliser les protections disponibles dans ce stockage et de ne pas communiquer une métadonnée dont la divulgation serait sensible dans le déploiement concerné.

Une signature qui aide à établir l’intégrité ou la provenance ne rend pas la valeur confidentielle.

Une analyse antérieure de ce même projet portait sur les points de mesure jamais arrivés et sur la difficulté d’attester un manque depuis un flux qui a lui-même échoué. Le sujet présent est l’inverse : que peut apprendre un tiers d’une métadonnée bel et bien conservée ? Le premier problème relève de la continuité de la preuve ; le second, de sa diffusion.

Sources