Résumé

  • Un projet individuel déposé à l’IETF le 27 octobre impose à l’objet de politique des champs area, owner et author, mais laisse au point d’administration la faculté, avec MAY, de vérifier si l’émetteur a le droit de modifier les règles du domaine destinataire.
  • La signature répond à la question « qui a envoyé cet objet intact ? ». L’autorisation répond à « qui lui a donné le pouvoir de gouverner cette zone ? ». Le destinataire doit conserver la réponse liée à la version réellement installée.

Le paquet impeccable et le bureau vide

Un paquet franchit la frontière entre deux administrations réseau. Son sceau est lisible, son format passe le contrôle, son étiquette annonce un propriétaire. À l’arrivée, un autre bureau devrait trancher : ce propriétaire a-t-il compétence ici ? Si ce bureau est vide, la qualité de l’emballage ne ralentira pas l’installation de la mauvaise règle.

Le projet Model for distributed policy sharing, daté du 27 octobre 2026, propose un conteneur YANG pour une politique individuelle. Les feuilles area, language, policy-content, owner et author sont obligatoires. origin et policy-provenance apparaissent comme facultatives dans le modèle. La logique de la politique reste opaque pour le conteneur : une syntaxe Rego et une règle de sécurité réseau peuvent voyager sous la même structure sans recevoir la même interprétation.

La distinction est utile. Elle crée aussi une petite monarchie de champs déclaratifs si le destinataire ne complète pas le contrôle. owner est renseigné par l’objet entrant. author désigne la personne ou le système qui l’a écrit. area affirme le territoire visé. Ces trois mentions n’accordent aucun mandat sur le domaine récepteur. Même une signature conforme au projet sur la provenance YANG établirait l’origine et l’intégrité du contenu signé ; elle ne fournirait pas la délégation locale.

Le verbe qui change la frontière

Le texte confie au Policy Administration Point, ou PAP, validation du schéma, gestion du cycle de vie et, le cas échéant, vérification de provenance. Avant d’accepter ou de distribuer l’objet, il MAY interroger un Policy Decision Point pour savoir si le propriétaire déclaré ou l’émetteur est autorisé à définir ou modifier une politique dans la zone pertinente. Le schéma de la section 6.2 dessine un bloc « Governance Authorization Check » au cœur du PAP. Le dessin est ferme ; la phrase laisse le poste de contrôle à la discrétion du déploiement.

Cette marge peut servir plusieurs architectures de confiance. Elle empêche toutefois de présenter le schéma comme une preuve que l’autorisation sera toujours vérifiée. Un récepteur sérieux doit établir sa propre table : quelle institution détient le pouvoir sur chaque area, à qui l’a-t-elle délégué, jusqu’à quand, et quelle preuve fait cesser ce pouvoir ? Le PAP doit confronter les réponses à la version reçue avant qu’un moteur d’exécution ne la lise.

Dans son message à la liste NMOP, une auteure décrit une démonstration prévue dans deux domaines : une politique Rego évaluée par OPA d’un côté, une politique fondée sur RFC 9061 conduisant à un tunnel IPsec de l’autre. Montrer que deux moteurs reçoivent leurs instructions vérifierait l’échange hétérogène. Montrer qui a autorisé chaque instruction dans chaque domaine vérifierait la frontière politique. Le message annonce l’expérience, il n’en fournit pas les résultats.

Le Datatracker de l’IETF classe le texte parmi les projets individuels actifs, à l’état I-D Exists. Il ne décrit ni norme adoptée ni déploiement mesuré. Le besoin de contrôle est déjà explicite dans le projet lui-même : les systèmes multi-domaines peuvent ignorer si une source est habilitée à imposer une politique dans la zone visée.

Une archive qui relie les décisions

Le projet autorise, sans l’imposer, la conservation des anciennes versions dans un système externe et l’inscription des événements dans un registre comptable append-only. Pour enquêter sur une règle contestée, ces traces doivent rejoindre le verdict d’autorisation, l’identité du signataire, la délégation locale, la révision exacte, la cible d’installation et l’ordre de retour arrière. Un registre de paquets reçus qui omet le droit de les accepter documente le transport, pas la responsabilité.

RFC 2904 fournit le cadre historique des fonctions d’autorisation. Le projet actuel laisse le transport concret à chaque déploiement. C’est au gestionnaire du domaine récepteur de produire la pièce manquante : un acte de délégation vérifiable au moment où la règle est admise.

Sources