Résumé

  • Les feuilles en lecture seule de la révision 01 indiquent jusqu'où une règle SCHC peut changer ; elles ne désignent ni l'utilisateur, ni le groupe, ni la session autorisée à exercer ce changement.
  • Une mutation défendable exige deux autorisations conjointes, puis une preuve de version, de validation, d'activation chez les pairs et de retour arrière.

Dans une console d'administration, deux voyants passent au vert. La session est authentifiée et son groupe peut écrire dans la configuration. Plus bas, la règle SCHC expose change-tv pour le champ visé. Le moteur d'automatisation additionne les deux réponses et exécute la demande.

Cette addition masque une différence essentielle. Le premier voyant répond à « cette session peut-elle demander une opération ? ». Le second répond à « quelle transformation ce Field Descriptor peut-il supporter ? ». Il reste à démontrer que cet acteur peut transformer ce champ précis, dans le Context de cet équipement, à cet instant, à partir de la version qu'il croit encore active.

La scène est une reconstruction analytique, non un incident rapporté. Elle éclaire la question laissée au centre de draft-ietf-schc-access-control-01, mis à jour le 29 septembre 2026 : une propriété de mutabilité peut-elle faire office de mandat ? La réponse opérationnelle doit être non.

Un identifiant court repose sur un accord long

SCHC réduit les échanges parce que les extrémités possèdent déjà le Context. Selon le RFC 8724, le RuleID sélectionne la règle qui permet de comprimer ou de reconstruire un en-tête. Chaque Field Descriptor associe notamment un identifiant de champ, une valeur cible, un opérateur de correspondance et une action de compression/décompression.

Le paquet économise donc les informations que le Context rend communes. Cette économie devient une dépendance : si deux extrémités donnent un sens différent au même RuleID, les bits transmis ne suffisent pas à arbitrer. Le RFC 9363 avertit qu'une modification de l'adresse IPv6 applicative peut bloquer le trafic ou faciliter l'écoute. Il demande de valider l'identité du requérant et de limiter un appareil à ses propres règles.

Le nouveau projet affine l'autre dimension. Une autorisation générique d'écrire un sous-arbre YANG ne distingue pas une Target Value de Uri-Path, qui pourrait évoluer, d'un préfixe applicatif qui devrait rester immuable dans la même règle. Il faut décrire la mutation admissible au niveau de l'objet lui-même.

Trois étages qui se ferment de haut en bas

ac-modify-set-of-rules fixe la limite au niveau de l'ensemble : aucune modification, modification d'un élément existant, ou ajout et suppression. ac-modify-compression-rule affine cette limite pour les Field Descriptions d'une règle de compression. ac-modify-field distingue enfin l'interdiction, le seul changement de Target Value, ou le changement de TV avec MO et CDA.

L'ordre est une partie de la sécurité. Le deuxième étage n'est actif que si le premier autorise la modification ; le troisième suppose l'accord des deux parents. Un enfant permissif ne perce pas un parent restrictif. En l'absence de la feuille, le texte dit que l'information ne peut pas être modifiée.

Ces feuilles sont config false. Elles sont exposées par le système et non écrites par le client qui réclame la modification. C'est une propriété saine : l'acteur ne fabrique pas son permis au cours du même geste.

Mais un permis sans titulaire n'est pas encore une autorisation. Aucune de ces valeurs ne contient l'identité authentifiée, les groupes, la session, la délégation, le propriétaire de l'équipement ou la version de la politique. Elles fixent un plafond sémantique. Elles ne nomment pas celui qui peut l'atteindre.

NACM décide de l'acteur, pas de toute la sémantique SCHC

Le projet reconnaît explicitement NACM. Le RFC 8341 associe une session authentifiée à un nom d'utilisateur et à des groupes, puis évalue les opérations de protocole et les nœuds de données. Un refus produit access-denied. Les règles en vigueur au début du traitement restent les mêmes jusqu'à la fin du message.

NACM constitue donc un bon emplacement pour la question de l'acteur. Il ne rend pas les feuilles SCHC inutiles. Son modèle CRUDX sait qu'un groupe peut mettre à jour une donnée ; il ne traduit pas naturellement la différence entre la Target Value modifiable d'une entrée et le préfixe protégé de l'entrée voisine. Inversement, change-tv ne prouve aucune appartenance à un groupe.

La règle de composition doit rester visible :

le principal peut exécuter cette requête et cet élément SCHC peut subir cette classe de mutation.

NETCONF, RESTCONF et CORECONF apportent des transports et des transactions différents autour de cette conjonction. NETCONF impose l'authentification des connexions et peut proposer validation, datastore candidat, verrou et rollback-on-error. RESTCONF confie la transaction au serveur et permet de protéger une édition avec un ETag et If-Match. CORECONF réduit la taille des messages grâce à CoAP et CBOR, tout en imposant d'empêcher les lectures et écritures non autorisées.

Ces mécanismes complètent le modèle ; aucun ne transforme un change-tv en identité. Une architecture qui utilise seulement NACM risque d'accorder trop largement la modification d'une règle. Une architecture qui utilise seulement les feuilles SCHC laisse ouverte la question de celui qui agit.

La concurrence et l'activation ne sont pas des détails

Supposons que les deux autorisations soient correctes. Entre la lecture et l'écriture, un autre contrôleur peut avoir changé la règle. Un ETag RESTCONF peut empêcher l'écrasement si le client utilise If-Match. Un verrou NETCONF peut isoler une opération. Une configuration candidate peut être validée avant le commit. Ces garanties dépendent toutefois des capacités et du protocole déployés.

Surtout, l'acceptation par le datastore ne signifie pas que le pair SCHC utilise déjà le nouveau Context. Le succès d'une transaction de gestion et le succès d'une transition de protocole sont deux événements. Il faut définir qui active la nouvelle révision, comment les pairs démontrent leur compatibilité, quel trafic sert de contrôle et quelle version demeure disponible pour le retour arrière.

La révision 01 ne décrit pas encore l'origine des feuilles en lecture seule, leur révocation, l'association d'un principal à un Context ou à un appareil, la résolution de deux écritures simultanées, l'atomicité de plusieurs champs, le journal d'audit ou la procédure de restauration. On peut construire ces fonctions avec les protocoles existants ; on ne peut pas prétendre qu'elles sont déjà dans les trois feuilles.

Cette retenue correspond à une discipline plus générale : l'autorité d'un composant doit rester proportionnée à ce qu'il peut prouver. Le gestionnaire d'identités prouve le principal. Le modèle SCHC prouve la limite de l'objet. Le gestionnaire de transaction prouve la cohérence de l'édition. L'opérateur du service accepte la conséquence d'une activation.

Les traces de brouillon changent le niveau de confiance

La révision 01 est un Internet-Draft de groupe de travail avec un en-tête Standards Track, pas un RFC. Le chapitre Terminology porte encore ToDo. Les sections Security Considerations et IANA Considerations sont TBD. Le module YANG garde une révision de 2023 et une description étrangère au sujet, consacrée au compound-ack et à RFC YYYY. Les descriptions de trois valeurs field-access indiquent encore Reserved slot number.

Ces traces ne réfutent pas l'idée. Elles interdisent de traiter le texte comme une interface figée. L'architecture SCHC de juillet 2026 recommande déjà l'authentification des gestionnaires, l'audit des changements et la restauration d'un Context sain, tout en reconnaissant que le cycle de vie et la gestion restent à développer.

Aucune source figée ne démontre une adoption large, un incident réel, des résultats d'interopérabilité ou des performances. Une expérience doit enregistrer la révision exacte du module et prévoir que sa composition de sécurité change.

La preuve minimale d'une mutation

Pour que la décision soit réexaminable, conserver :

  1. le principal, ses groupes, la session et la protection du transport ;
  2. l'opération, le Context, le Set of Rules et le RuleID visés ;
  3. la révision ou l'ETag antérieur et les valeurs avant/après ;
  4. toutes les feuilles SCHC, parents compris ;
  5. la version de la politique NACM ou équivalente ;
  6. la validation, le contrôle de concurrence et le résultat transactionnel ;
  7. le moment d'activation et la preuve pour chaque pair ;
  8. l'effet observé, le responsable et le point de restauration testé.

Une interface peut afficher « autorisé ». Un responsable doit pouvoir dire qui a autorisé quoi, sur quelle version, dans quelle limite et avec quelle voie de retour. C'est cette chaîne, et non un seul bit permissif, qui transforme la mutabilité en pouvoir légitime.

Sources