Résumé

  • RFC 9899 décrit une comparaison bornée : choisir une origine, ignorer length octets, appliquer un opérateur et comparer un motif binaire. La validité du modèle ne révèle pas les octets effectivement inspectés.
  • Une variation de compteur atteste une attribution locale à une ACE, dans un périmètre et un epoch connus. Elle ne prouve seule ni l’identité du paquet, ni l’exécution de l’action, ni le résultat du service.

Un rapport de changement peut présenter quatre voyants au vert : la feature existe dans le YANG Library, le commit a réussi, l’ACE apparaît à la relecture et son compteur augmente pendant le test. Ces constats peuvent tous être exacts sans que la phrase « la règle de payload fonctionne » soit démontrée.

RFC 9899, publié en décembre 2025 comme Proposed Standard, étend le modèle ACL de RFC 8519. Le Datatracker relie le texte à draft-ietf-netmod-acl-extensions. Une date de mise à jour ultérieure du Datatracker concerne la fiche, pas une nouvelle spécification. Pour figer l’état éditorial, il faut conserver la fiche RFC, le dossier Datatracker et la recherche d’errata du même moment.

La fenêtre de comparaison

La feature match-on-payload annonce une capacité de schéma au sens de YANG 1.1, pas un état du dataplane. Dans payload-match, offset choisit une origine sémantique, length indique le nombre d’octets à ignorer depuis cette origine, operator vaut match par défaut et pattern contient la valeur binaire. La comparaison commence à offset + length.

Le nom length prête à confusion : ce n’est pas la longueur du motif, mais la distance à sauter. Une preuve qui ne conserve que deux nombres, sans l’identity d’origine, l’opérateur et le motif exact, ne permet pas de rejouer la règle.

Les origines ne sont pas interchangeables. layer2 commence au header de liaison, layer3 au header IP, layer4 après le header IP et ses options ou headers d’extension, y compris AH. payload commence après le transport, donc après les options TCP éventuelles. Le registre IANA YANG Parameters établit l’identité des modules et révisions, pas le comportement d’une puce de transfert.

Quand l’origine se déplace

Deux segments TCP peuvent transporter les mêmes données avec des headers de tailles différentes. Le Data Offset de RFC 9293 situe le début des données TCP. Une implémentation fidèle à l’origine payload doit tenir compte des options ; un test utilisant un déplacement absolu fixe peut réussir par hasard sur un paquet minimal.

Avec IPv6, RFC 8200 place des headers d’extension avant la couche supérieure et traite les fragments comme des paquets séparés avant le réassemblage à destination. RFC 9899 définit l’origine layer4, mais ne fixe pas pour chaque équipement le point d’inspection avant ou après réassemblage, décapsulation ou normalisation. Ces choix locaux doivent être documentés et testés.

Le chiffrement fixe une autre limite. RFC 9000 protège le payload QUIC et applique une protection de header à des champs tels que le numéro de paquet. Certains éléments restent visibles, mais pas le contenu applicatif. RFC 9899 indique que le matching est déterministe sur les données non chiffrées et que son efficacité sur un paquet chiffré dépend d’un motif invariant ; il n’ajoute aucun déchiffrement. RFC 8329 situe le packet-content matching dans une taxonomie plus large, sans attester l’implémentation d’un constructeur.

Une chaîne à neuf maillons

La feature et le schéma ne sont que le premier maillon. Viennent ensuite l’identité du principal, l’autorisation et la transaction ; RFC 8341 sépare bien contrôle d’accès et validité du schéma. Puis il faut distinguer configuration intended et état operational selon RFC 8342, et prouver que l’ACE a été compilée et attachée au bon interface, dans le bon sens et au bon hook.

Quatre preuves restent encore nécessaires : les octets exacts d’un paquet capturé indépendamment ; leur visibilité après chiffrement, encapsulation, fragmentation et normalisation ; l’évolution du bon compteur pendant un stimulus contrôlé ; l’exécution séparément observée de l’action ; enfin le résultat du service.

Les compteurs matched-packets et matched-octets de RFC 8519 sont en lecture seule et peuvent être exposés par interface ou agrégés. Une hausse signifie donc qu’un compteur a attribué du trafic pendant un epoch déterminé. Sans périmètre, instant de remise à zéro, stimulus et capture, elle ne nomme même pas le paquet causal. Les actions complémentaires de journalisation et de compteur introduites par RFC 9899 restent elles aussi des intentions tant que leur exécution n’est pas observée.

Le reçu de fenêtre de paquet

Le bon livrable de test est un reçu rejouable. Il lie la révision du module, les features et deviations ; le build du système et du composant de transfert ; le principal, l’autorisation, l’identifiant de transaction et le datastore ; l’ACE, son ordre, son attachement, l’interface, la direction et le hook ; l’étape par rapport à la décapsulation, la normalisation et le réassemblage ; l’offset identity, la distance length, l’opérateur, le motif et la plage calculée ; les hashes du fixture et de la capture ; les longueurs de headers décodées ; la limite de chiffrement ; le nom, la largeur, le périmètre, l’agrégation, le reset et les valeurs du compteur ; puis des preuves distinctes pour l’action et le service.

Les tests négatifs révèlent la vraie portée : modifier les options TCP sans changer les données, ajouter un header d’extension IPv6, tester des fragments quand le comportement est documenté, changer un octet du motif, comparer chiffré et non chiffré, ingress et egress. Un succès limité au paquet le plus simple n’autorise qu’une conclusion limitée à ce fixture.

Du document à la puissance d’exécution

L’analyse mobilise ici, explicitement hors du RFC, les reality layers de Lu Heng. Daniel Kade applique cette distinction : le modèle appartient à la couche documentaire ; le dataplane programmé, le paquet observé, l’action et le résultat appartiennent à des couches de plus en plus exécutables. Ce n’est ni un propos de l’IETF ni une intention attribuée aux auteurs du RFC.

Le principe de Minimum Initial Specification et Localized Future Decision conduit à préserver un noyau minimal et déterministe : identité du schéma, fenêtre exacte, stimulus, epoch du compteur et observation indépendante. Les hooks, le réassemblage et la normalisation restent des décisions d’implémentation locales et visibles. L’essai sur l’autorité et la croyance rappelle enfin qu’un document coordonne, tandis que l’opérateur et l’implémentation qui contrôlent le chemin actif détiennent la puissance d’exécution. Il s’agit d’une lecture de l’auteur de cet article.

La formulation honnête reste bornée : dans ce contexte de schéma et d’autorisation, à ce hook programmé, ces octets visibles ont été comparés avec cette origine, ce saut, cet opérateur et ce motif ; ce compteur a varié pendant cet epoch ; d’autres preuves établissent l’action et le résultat. Chaque élargissement exige un nouveau reçu.

Sources