Résumé

  • draft-ietf-ippm-ioam-data-integrity-20 permet à un Validateur de recalculer une chaîne AES-GMAC et de détecter la modification des champs immuables inclus dans l’option protégée.
  • Un ICV valide ne prouve pas la présence de toutes les options attendues, la sincérité des mesures locales, l’intégrité après export, l’absence de retard ni la couverture de tout le trafic.
  • Toute automatisation doit conserver l’ensemble attendu et observé, l’état anti-rejeu, la provenance du Validateur, la chaîne de garde de l’export et une mesure indépendante du service.

Le résultat tient en une comparaison : l’ICV recalculé par le Validateur est identique à celui du paquet. Dans une console, cette égalité devient vite une phrase plus ambitieuse : « le chemin est fiable ».

Le projet IETF ne fait pas ce saut. Sa révision 20, datée du 19 juillet 2026, se trouve dans la file du RFC Editor, mais demeure un Internet-Draft du groupe IPPM. Elle attend son premier éditeur et la fiche IANA indique qu’une nouvelle revue de version est nécessaire. La maturité administrative du texte ne certifie aucune installation réelle.

Le mécanisme construit des variantes protégées des traces préallouées et incrémentales, de la preuve de transit et de l’option bout à bout. Chaque nœud qui participe possède sa clé symétrique. Le nonce de douze octets réunit un identifiant de clé, un identifiant du nœud d’encapsulation et un compteur de 64 bits. Le premier nœud calcule l’ICV sur des champs d’en-tête immuables et sa contribution; chaque participant ajoute sa propre contribution immuable au calcul précédent.

Le paquet ne transporte que le dernier ICV. Pour le vérifier, il faut reconstruire l’ordre, identifier les nœuds et retrouver leurs clés. L’association entre identifiant et clé reste hors du périmètre du projet. Le verdict dépend donc déjà d’un registre local d’identités que l’algorithme ne crée pas.

Une signature authentique peut protéger une déclaration fausse

Un nœud compromis ne peut pas se faire passer pour un autre participant sans être détecté, sous réserve que les clés et associations soient correctes. Il peut pourtant fabriquer ou supprimer des paquets et mentir dans les champs qu’il produit sous sa propre identité.

Une profondeur de file inventée, mais inscrite par le détenteur légitime de la clé, donne une chaîne cryptographiquement cohérente. L’intégrité préserve l’auteur et les octets; elle ne calibre pas le capteur et ne juge pas l’intention de l’auteur.

Il faut donc distinguer deux colonnes : contribution authentique et mesure crédible. La seconde demande version logicielle, configuration, attestation, comparaison avec d’autres compteurs et parfois un observateur extérieur. Les fusionner revient à confondre provenance et vérité.

Le Validateur est un gardien, pas une abstraction neutre

Le texte appelle le Validateur une entité de confiance. Il possède les clés et décide finalement si l’ICV est valable. Il précise aussi qu’un Validateur compromis peut modifier les champs ou produire un résultat erroné, sans que la méthode puisse l’en empêcher.

Cette limite organise la gouvernance. Si le même système définit les participants attendus, entretient le registre de clés, calcule le verdict et ordonne la remédiation, il concentre observation, jugement et action. La présence de GMAC ne rend pas ce jugement indépendant.

Un reçu vérifiable doit nommer le Validateur, son binaire, sa configuration, la version du registre identifiant-clé, l’époque de clé et la règle de décision. Pour une action risquée, un second plan d’observation ou une approbation extérieure doit pouvoir contester le gardien.

L’absence n’entre pas dans le calcul

Un attaquant sur le chemin peut supprimer l’en-tête complet d’une option IOAM. Le projet dit que sa méthode ne traite pas cette attaque; la protection doit venir du protocole qui encapsule IOAM. Un nœud compromis peut également remplacer une option protégée par son équivalent non protégé.

Le Validateur doit donc connaître les Namespace-ID, nœuds d’encapsulation et types d’option qui doivent être protégés. Il faut comparer l’ensemble attendu à l’ensemble reçu avant de vérifier l’ICV. Sinon, le calcul peut être parfait sur un dossier amputé.

Cette règle change les états possibles. Une option manquante n’est ni valide ni invalide. Elle peut avoir été retirée, ne pas avoir été insérée, ne pas appartenir à l’échantillon, avoir disparu à l’export ou relever d’une politique différente. Le tableau de bord doit conserver cette incertitude.

Une zone protégée peut côtoyer une zone ordinaire

Les options protégées et classiques peuvent coexister dans le même domaine. Un espace de noms peut porter une trace protégée et un autre une trace ordinaire. Pour contenir le coût de calcul, l’opérateur peut n’insérer le mécanisme que dans une fraction du trafic.

Le nombre de validations réussies ne donne donc pas le dénominateur. Mille paquets valides ne disent rien sur le flux critique qui n’a jamais été sélectionné. La couverture doit être mesurée par politique, espace de noms, type d’option et classe de trafic.

Les champs mutables constituent une autre frontière. Ils ne profitent pas de la protection, précisément parce qu’ils changent. Un résultat doit publier les masques et champs couverts; « l’enregistrement IOAM est protégé » est trop large.

Après la décapsulation, une nouvelle chaîne de garde commence

Les attaques du plan de gestion et l’intégrité des données exportées sont hors périmètre. Le protocole de gestion et le format d’export sont censés fournir leur propre sécurité. Direct Export ne transporte pas de champs IOAM et ne doit pas employer cette méthode.

Un ICV peut donc être valable dans le paquet, puis la donnée être altérée pendant l’extraction, la normalisation, le transport, l’agrégation ou le stockage. Conserver uniquement la table analytique finale détruit la possibilité de relier le résultat aux octets protégés.

Le bon dossier garde l’option brute, le reçu de validation et les empreintes de chaque transformation. Si cette chaîne se rompt, l’état doit devenir « intégrité d’export non prouvée ».

Fraîcheur et anti-rejeu sont des preuves distinctes

La réutilisation d’un nonce avec la même clé permet la falsification. Les nœuds et le Validateur doivent détecter cette réutilisation; la fenêtre anti-rejeu fixe la tolérance au réordonnancement. Après un redémarrage sans état persistant, une clé ne peut pas être reprise : il faut la renouveler avant de recommencer.

Mais un paquet unique peut encore arriver trop tard. Le projet ne protège pas contre une attaque de délai. Des octets authentiques mais retardés peuvent déclencher une décision sur un état qui n’existe plus.

Le reçu doit donc séparer rejeu détecté de donnée trop ancienne. Il enregistre le compteur, l’époque de clé, la fenêtre appliquée, l’heure de capture, l’heure de validation et le budget d’âge de la décision.

Le reçu qui manque au voyant vert

Avant l’ICV, consigner domaine, Namespace-ID, type d’option, méthode, masque, identité du paquet, règle d’échantillonnage, participants et options attendus. Pendant la validation, consigner nonce, identifiants non secrets, époque de clé, version d’association, décision anti-rejeu et provenance du Validateur.

Après la validation, relier l’export et le stockage aux octets originaux. Puis mesurer délai, perte, chemin corroboré et qualité du service. Enregistrer l’action prise, l’autorité qui l’a permise, la condition de retour arrière et le résultat.

Le vocabulaire doit rester typé : valide pour l’ensemble déclaré, option attendue absente, association inconnue, provenance du Validateur non vérifiée, couverture partielle, intégrité d’export non prouvée, résultat de service en attente.