Résumé

  • La RFC 9899 est une norme proposée de l’IETF qui complète le modèle ACL de la RFC 8519 ; elle ne le remplace pas.
  • Elle permet de référencer des ensembles nommés réutilisables de préfixes IPv4 et IPv6, ports, protocoles, types ICMP et alias, tout en élargissant les correspondances et en ajoutant des actions locales.
  • L’indirection réduit la répétition, mais concentre aussi l’impact d’une modification. La propriété, l’autorisation, la visibilité des dépendances, la validation progressive et le retour arrière deviennent donc essentiels.

Ce qui est réutilisé

Un ensemble à paramètre unique convient lorsqu’un objet ne contient qu’un seul type de valeur : préfixes, ports, protocoles ou types ICMP, par exemple. Un alias peut réunir des paramètres tels que préfixes, protocoles, ports ou VLAN. Les entrées ACL peuvent alors pointer vers ces objets nommés au lieu de répéter les littéraux. Le modèle prévoit également la réutilisation entre plusieurs éléments de réseau à l’échelle d’un domaine administratif. Il s’agit d’une possibilité du modèle, non d’une affirmation selon laquelle toutes les implémentations exposent toutes les fonctions.

La modification reste fondée sur la RFC 8519. Il faut donc distinguer les champs ACL de base des champs enrichis. Pour les indicateurs TCP, un client prenant en charge à la fois flags-bitmask enrichi et le champ flags de la RFC 8519 MUST NOT renseigner les deux dans une même requête. Une règle d’exclusion comparable s’applique lorsque la correspondance enrichie des fragments recouvre le champ flags de la RFC 8519. Un test qui envoie ces combinaisons doit vérifier le traitement de la contrainte ; il ne faut pas s’en servir pour exprimer implicitement une correspondance plus large.

Un vocabulaire de paquets plus large

Les ajouts permettent de faire correspondre les en-têtes d’extension IPv6, les indicateurs TCP via flags-bitmask, les types de fragments IPv4 et IPv6, des motifs de charge utile, les en-têtes MPLS, les VLAN et les I-SID. La correspondance de charge utile est conditionnée par une fonctionnalité et précise un type de décalage, un décalage, une longueur, un motif binaire et un opérateur. Elle ne déchiffre pas le trafic. Pour des paquets chiffrés, son efficacité dépend d’un motif observable qui reste invariant ; il faut donc vérifier ce qui est réellement visible, sans déduire le contenu applicatif.

Le module ajoute aussi des actions de limitation de débit, de journalisation et de compteurs, mais la version définie ne prend en charge que des actions locales. La RFC 9899 crée les premiers modules YANG maintenus par l’IANA pour les types ICMPv4, les types ICMPv6 et les types d’en-têtes d’extension IPv6. Cela ne garantit ni la prise en charge par tous les équipements, ni un gain de performance, ni une limite d’échelle universelle.

La surface de contrôle

Les ensembles définis sont des objets de sécurité lisibles et modifiables. Une écriture non autorisée peut permettre un trafic qui devrait être refusé ou refuser un trafic qui devrait être permis. Une lecture non autorisée peut révéler les ressources liées à un ensemble et affaiblir une stratégie de dissimulation de la topologie. La RFC vise des protocoles de gestion YANG utilisant un transport sécurisé et une authentification mutuelle, avec NACM pour restreindre les opérations et le contenu. La RFC 8341 est donc pertinente pour déterminer qui peut voir ou modifier ces objets ; la RFC 7950 fournit le langage de modélisation YANG 1.1.

Analyse de Theo March — pas une exigence des RFC : considérer chaque ensemble comme une dépendance possédant un responsable et une liste visible de consommateurs. Préparer la modification, valider les ACL parentes et un trafic représentatif, puis conserver une procédure de retour arrière testée. La RFC ne prescrit ni cycle de nommage, ni circuit d’approbation, ni intervalle de déploiement, ni seuil universel de retour arrière. La réutilisation ne rend pas automatiquement la politique plus sûre ou plus cohérente : elle réduit les répétitions tout en concentrant l’impact.

Jeux de vérification

  1. Créer un ensemble de préfixes référencé par deux entrées ACL, ajouter puis retirer un membre, et vérifier que les règles parentes n’ont pas à être redéfinies tandis que leurs dépendances effectives changent.
  2. Envoyer les indicateurs enrichis avec le champ flags de la RFC 8519, puis recommencer avec la correspondance enrichie des fragments et ce champ de base ; vérifier le traitement de l’exclusion mutuelle.
  3. Vérifier l’annonce de prise en charge avant de tester charge utile, MPLS, VLAN, I-SID, en-têtes d’extension, limitation de débit, journalisation ou compteurs. Employer un motif binaire connu avec décalage, longueur et opérateur explicites ; tester séparément le trafic chiffré sans parler de déchiffrement.
  4. Tenter une lecture et une écriture non autorisées d’un ensemble sous NACM, avec transport sécurisé et authentification mutuelle. Vérifier les décisions d’accès et la visibilité des journaux.

Parcours de décision opérateur

Commencer par recenser les consommateurs et le responsable. Choisir ensuite un ensemble à paramètre unique ou un alias, sans créer de couplage inutile. Confirmer la prise en charge des fonctions et les exclusions entre champs de base et champs enrichis. Examiner le diff, valider toutes les ACL concernées dans un périmètre progressif, observer les actions locales et les compteurs pertinents, puis approuver ou revenir à l’état préparé. Si les dépendances ne sont pas visibles ou si les droits de lecture et d’écriture ne peuvent pas être séparés, conserver les littéraux localement jusqu’à la résolution de ce défaut de contrôle.

Sources