Résumé

  • La révision 16 de draft-ietf-rtgwg-qos-model modélise classificateurs, compteurs de débit, files, ordonnanceurs, rattachement d’une politique et statistiques opérationnelles. La référence valide d’une politique sur une interface décrit un traitement voulu ; elle ne prouve ni l’instanciation matérielle ni le service reçu par les paquets.
  • Le module opérationnel offre aussi une action de remise à zéro. Elle porte nacm:default-deny-all, car son usage peut perturber la surveillance et cacher des indices d’anomalie. Sans fenêtre temporelle et historique d’effacement, zéro ne prouve l’absence de trafic, de congestion, de perte ou d’attaque.

Zéro était exact, mais incomplet

Une enquête commence devant un écran apparemment rassurant. La bonne politique est encore liée à l’interface de sortie. Le classificateur n’a rien compté ; le meter ne signale aucun paquet exceed ou violate ; profondeur, tail drop et marquage ECN sont à zéro. Cela peut signifier que la rafale soupçonnée n’est jamais arrivée. Le même écran apparaît pourtant après un redémarrage, la création d’un nouveau compteur, un remplacement de politique, une panne de collecte ou un effacement antérieur à l’enquête.

La valeur ne choisit pas son histoire.

La révision 16 du projet RTGWG place ce problème dans une même famille de modèles. Les modules de configuration assemblent filtres et actions en politiques, puis rattachent une politique à une interface en entrée ou en sortie. Le module opérationnel publie les observations des classificateurs, meters et files. Enfin, une action clear peut effacer toutes les statistiques, ou une catégorie, immédiatement ou à une heure programmée.

Le texte qualifie clairement le risque : l’action est refusée par défaut, parce qu’elle peut rompre la surveillance et masquer la trace d’une anomalie ou d’une attaque. Le contrôle concerne la conservation de la preuve, pas seulement la sécurité d’une commande.

La référence de politique est un mandat, pas un reçu de paquet

Le parcours du modèle est lisible. Un classificateur sélectionne des paquets. Les actions peuvent marquer, mesurer, compter, jeter, placer en file, ordonnancer ou appeler une politique enfant. L’ordre des classificateurs et de leurs actions forme la politique. qos-target-policy relie ensuite une politique d’un type donné à une interface et à une direction.

Cette structure donne à l’automatisation un objet stable. Elle ne regarde toutefois pas directement le silicium. Une référence dans la configuration ne certifie pas qu’une carte a réservé une file, que la granularité matérielle a conservé le débit demandé, ni que le paquet suivant empruntera la branche attendue.

RFC 8342 fournit la distinction nécessaire entre intention, configuration appliquée et état opérationnel. Une édition NETCONF ou RESTCONF réussie atteste qu’une transaction autorisée a été acceptée selon les règles du datastore. Elle ne démontre pas que les ressources étaient disponibles ou que l’implémentation a produit le comportement voulu.

Les types de politique, identités et augmentations peuvent être propres au constructeur. Cette extensibilité correspond à la diversité des équipements. Elle interdit de confondre une syntaxe commune avec une équivalence comportementale entre fournisseurs.

Les politiques hiérarchiques donnent le même avertissement. Le module exclut l’autoréférence directe et exige le rejet des cycles. L’acyclicité élimine un défaut structurel ; elle ne prouve ni la faisabilité de la chaîne ni sa qualité de service.

Les compteurs témoignent seulement à leur point d’observation

Le module opérationnel expose des reçus détaillés : paquets, octets et débit moyen d’un classificateur ; trafic conforme, dépassant, violant ou jeté par un meter ; tailles courante, moyenne et maximale d’une file ; sorties, tail drops, RED, WRED et marquages ECN.

Ces données répondent à des questions bornées. Le paquet a-t-il atteint ce classificateur ? Le profil engagé a-t-il été dépassé ? Cette file, sur cette interface et dans cette direction, a-t-elle gonflé ou débordé ?

Elles ne répondent pas à la suite. Une correspondance ne prouve pas l’entrée dans la file matérielle attendue. Une sortie de file ne prouve pas le transport par le prochain saut. Un marquage ECN ne prouve pas la réaction du terminal. L’absence de perte locale ne certifie ni latence applicative ni SLA.

Les statistiques nommées peuvent agréger plusieurs classificateurs, meters ou files, ou les conserver séparément. Le total facilite un tableau de bord ; il efface l’identité des contributeurs. Toute décision de responsabilité fondée sur ce total exige le détail non agrégé ou une correspondance reproductible.

La chaîne de preuve reste donc séquencée :

  1. un responsable approuve l’objectif de service et le trafic visé ;
  2. une révision relue décrit classificateurs et actions ;
  3. les écritures autorisées et le datastore attestent l’acceptation ;
  4. l’état du dispositif prouve l’instanciation des ressources ;
  5. un trafic connu fait évoluer les bons compteurs pendant une fenêtre bornée ;
  6. files, pertes, ECN et débits décrivent le traitement local ;
  7. une mesure aval établit chemin et résultat applicatif ;
  8. chaque effacement laisse un reçu avant/après, conservé hors de l’équipement.

Aucun reçu ne doit hériter silencieusement de l’autorité du suivant.

Être autorisé à effacer ne justifie pas l’effacement

Le refus NACM par défaut est un bon premier verrou. Il faut une règle explicite pour invoquer l’action. L’authentification mutuelle et le transport protégé de NETCONF ou RESTCONF peuvent attribuer la requête et garantir son intégrité.

Ces contrôles répondent à « qui pouvait demander ? », pas à « fallait-il détruire cette fenêtre maintenant ? ». L’autorisation n’est pas une justification.

Un reçu défendable indique demandeur, approbateur, motif, interface, direction, politique, catégorie, heure demandée, heure exécutée, instantané antérieur, nouvelle base et dépôt d’audit externe. Une opération programmée a aussi besoin d’une trace d’annulation et d’horloge. Si l’équipement qui efface garde l’unique journal, une même panne peut supprimer le fait et son explication.

Il faut donc dissocier écriture, observation et effacement. La personne capable de changer un débit n’a pas besoin de pouvoir supprimer l’historique. L’analyste qui lit la congestion n’a pas besoin de modifier la politique. L’équipe d’incident ne devrait pas découvrir qu’une maintenance routinière a effacé sa période décisive.

Une remise à zéro peut être légitime : créer une base d’essai, borner une maintenance ou gérer une télémétrie finie. L’erreur est de faire du nouveau zéro une affirmation sur le temps antérieur.

Observer révèle aussi la politique

La conservation n’implique pas une lecture sans limite. Les filtres révèlent préfixes, ports, protocoles et DSCP jugés importants. Les actions montrent où le trafic est marqué, façonné ou jeté. Les paramètres de meter et de file révèlent des limites et des choix de capacité.

Un attaquant capable d’injecter une sonde et de lire les compteurs peut inférer la règle qui a correspondu. Les couleurs du meter dévoilent des seuils. Profondeur, RED et ECN exposent le rythme de congestion. Un nom de politique libre peut contenir un client ou un élément de topologie.

Lecture, écriture et effacement demandent donc trois décisions de moindre privilège. Interdire toute observation empêcherait la vérification ; l’ouvrir largement ferait du plan de gestion un oracle. Il faut des accès circonscrits, un audit indépendant et une durée de conservation proportionnée.

DiffServ conserve sa propre frontière. Un remarking illégitime peut voler un niveau de service ; un discard ou un meter malveillant peut provoquer un déni de service. Même légitime, le marquage reste un fait par saut : l’aval peut le modifier et l’application peut échouer.

La validation du schéma n’est pas le déploiement

La révision exacte est datée du 25 septembre 2026 et expire le 29 mars 2027. Datatracker la classe comme document actif du groupe RTGWG, à l’état I-D Exists. Son en-tête propose Standards Track, tandis que le champ intended status de Datatracker est vide. Ce n’est pas un RFC.

Datatracker rapporte zéro erreur et six avertissements pour la validation YANG. Cela concerne la vérification automatique de cette version, non l’implémentation fournisseur, l’allocation des ressources, l’interopérabilité, le déploiement ou le résultat d’un SLA. Des références RFC restent des espaces réservés.

L’affirmation robuste est plus étroite : le projet fournit un vocabulaire commun de l’intention QoS et de ses témoins locaux ; son action d’effacement révèle la gouvernance nécessaire pour lire ces témoins honnêtement.

Sources