Résumé

  • Le code de commande 314, l’identifiant d’application 16777243 et l’AVP Policy-Data décrivent une enveloppe Diameter. Ils identifient l’échange ; ils n’établissent ni la qualité des données ni le mandat de celui qui décide.
  • L’architecture OMA distingue explicitement l’évaluation de l’exécution. Elle prévoit qu’une décision soit rendue à la ressource appelante, laquelle choisit ensuite ce qu’elle en fait, ou que PEEM exécute lui-même l’action.
  • Une piste d’audit sérieuse doit relier la requête, la version de politique, les entrées, la décision, la réception par l’exécuteur, l’installation, l’activation, les décisions ultérieures et l’effet constaté.

Le reçu n’est pas l’acte

Un ordre de paiement et le débit d’un compte ne sont pas le même événement. Un jugement et son exécution non plus. Pourtant, dans l’automatisation des réseaux, une réponse de politique acquiert souvent la grammaire du fait accompli dès qu’elle atteint le tableau de bord.

Prenons une séquence construite pour l’analyse. Une ressource envoie un Policy-Data-Request. La réponse arrive une seconde plus tard, correctement corrélée, avec le bon identifiant d’application et un résultat de succès. L’interface d’exploitation affiche aussitôt « politique appliquée ». L’adaptateur d’exécution est pourtant hors ligne ; une règle locale plus récente l’emportera à son retour. La réponse est authentique, mais le verbe affiché dépasse ce qu’elle prouve.

RFC 5224 est un document Informationnel. Il enregistre un code de commande, un AVP dans l’espace fournisseur OMA et un identifiant d’application. Il précise que les entrées passent par Policy-Data et que les résultats utilisent Policy-Data avec Experimental-Result. Pour le comportement détaillé, il renvoie à la spécification OMA PEM-1.

Cette modestie est une vertu. Le RFC coordonne la syntaxe et les registres. Il ne prétend pas observer l’installation d’une règle dans un équipement, la modification d’un état de service ou l’issue vécue par un utilisateur.

L’espace de noms ne confère pas le mandat

Le code 314 désigne PDR/PDA. L’AVP Policy-Data porte le code 1 dans l’espace OMA. L’application utilise 16777243, et le registre actuel des paramètres AAA de l’IANA conserve ces valeurs. Dans le binding OMA, le Vendor-Id est 30079 et le support est annoncé pendant l’échange de capacités Diameter.

Ces nombres permettent aux logiciels de s’accorder. Ils ne répondent pas à la question institutionnelle : ce nœud est-il habilité à prendre cette décision pour ce sujet, cette ressource et cet instant ?

Une application déclarée n’est pas une délégation. Un Vendor-Id n’est pas un titre de compétence. Une route vers un realm ou un host ne prouve pas que la destination est l’autorité attendue. La sécurité de pair protège encore une autre frontière. RFC 5224 reprend les considérations de RFC 3588, remplacé ensuite par RFC 6733. Un canal protégé peut authentifier le pair et préserver le message. Il ne certifie ni l’exhaustivité du contexte ni la fraîcheur d’une donnée externe.

Il faut donc enregistrer séparément le pair cryptographique, la relation autorisant l’application et le principal qui possède le mandat politique. Une exploitation peut les faire coïncider ; elle doit alors être capable de montrer comment.

L’extensibilité rend la provenance indispensable

La spécification PEM-1 organise des entrées et sorties très variables au moyen de BLOB et de templates standard ou personnalisés. C’est un choix pragmatique : une politique de localisation ne demande pas les mêmes faits qu’une politique de compte, d’accès ou de risque.

Mais un identifiant de template ne garantit pas la vérité de son contenu. La version indique une structure ; elle ne démontre pas que les champs obligatoires sont complets, que la valeur est encore actuelle ou que deux opérateurs donnent le même sens métier à une extension.

Le texte OMA trace lui-même la limite. La publication des options supportées sort du périmètre. La manière dont l’implémentation PEEM traite les entrées, et celle dont la ressource requérante traite les sorties, sortent également du périmètre de l’interface.

Une preuve exploitable doit donc joindre aux octets Policy-Data le template et sa version, le sujet, la ressource, la politique et sa version, ainsi que la source et l’heure d’observation de chaque donnée externe. Pour un solde, une position ou un score de risque, « présent » ne signifie pas « actuel ». Si l’évaluation délègue une partie du travail, chaque appel subordonné doit conserver son propre lien causal.

Une même expression couvre deux chemins

Dans PEM-1, le traitement de politique signifie évaluation seule, ou évaluation avec exécution. Un journal qui ne conserve que processed efface précisément cette bifurcation.

L’architecture PEEM décrit plusieurs fins possibles. PEEM peut rendre une décision à la ressource requérante ; cette ressource garde alors le contrôle de son interprétation et de l’action. PEEM peut aussi exécuter lui-même et, dans certains cas, ne rien retourner. Le document illustre même un chemin d’évaluation pure, sans action de politique ni exécution par PEEM.

La décomposition en composants confirme la séparation. PV évalue et renvoie un résultat. PF accomplit l’action qui découle du résultat et peut encore déléguer. Les réunir dans un binaire n’abolit pas le passage de contrôle ; cela le rend seulement moins visible.

Le vocabulaire IETF est cohérent. RFC 2753 place la décision au PDP et l’exécution effective au PEP. RFC 3198 définit l’exécution comme la mise en œuvre d’une décision. Dire que le PEP doit exécuter est une exigence normative. Dire qu’il l’a fait lors de cette transaction exige un reçu.

Le mot résultat masque plusieurs étages

Diameter possède son résultat de protocole, via Result-Code ou Experimental-Result. « Experimental » désigne ici un conteneur de code fournisseur ; ce n’est pas le constat empirique d’un effet dans le réseau.

PEM-1 ajoute un template Output Status dont le code obligatoire décrit l’état final du traitement ou une erreur détectée. Enfin, la politique peut produire une décision ou des données que le demandeur doit interpréter.

Les trois peuvent être valides sans que l’action soit active. Le message a été accepté, le traitement s’est terminé, la décision est revenue ; ensuite l’exécuteur peut refuser, installer partiellement, rencontrer un conflit ou recevoir une décision plus récente. Inversement, PEEM peut exécuter en interne avec un retour très limité.

Le modèle d’état devrait dire exactement ce que l’on sait : transporté, accepté par le protocole, évalué, décision rendue, reçu par l’exécuteur, installé, actif, effet observé, remplacé, annulé. Une organisation peut simplifier l’affichage, pas la preuve sous-jacente.

Le protocole ne conserve pas la vie de la décision

Le binding OMA utilise NO_STATE_MAINTAINED pour Auth-Session-State. Le serveur ne maintient pas d’état de session Diameter et le client n’a pas à envoyer de terminaison. Cette économie convient à un appel ponctuel. Elle interdit cependant de prêter au dialogue un historique qu’il ne promet pas.

Une réponse corrélée prouve qu’une requête a reçu une réponse. Elle ne crée pas un bail de politique durable et n’indique pas quand l’état a été remplacé localement. Ces preuves appartiennent aux couches applicative et d’exécution.

La distinction préserve aussi l’originalité de ce travail. RFC 3539 traite les watchdogs, la reprise, les requêtes en attente et les doublons AAA. RFC 2989 porte sur les capacités d’une architecture AAA. Ni la fiabilité du transport ni une case de capacité cochée ne prouve l’action d’une transaction. RFC 7683 et RFC 4006 rappellent, chacun dans son domaine, que charge, état applicatif et résultat de service ont des sémantiques distinctes.

Écrire le reçu au changement de contrôle

La chaîne minimale conserve : la requête brute et sa route ; le pair sécurisé ; le sujet, la ressource et la version de politique ; les sources et dates des entrées ; les dépendances de l’évaluation ; le résultat Diameter, le statut PEEM et la sortie métier dans des champs distincts ; l’identité de l’exécuteur ; son accusé de réception ; la cible et l’état antérieur ; l’installation et son readback ; l’heure d’activation ; les échecs partiels ; les décisions ultérieures ; enfin l’effet mesuré par un composant capable de le voir.

Cette piste doit accumuler les faits, non réécrire le passé. Une décision remplacée a bien été rendue. Une installation échouée n’efface pas la réponse initiale ; elle ajoute un échec au maillon suivant. Ce modèle maintient la causalité et permet une compensation exacte.

La doctrine des couches de réalité de Lu Heng éclaire ce point : un identifiant classe, une réponse consigne, une décision instruit. La réalité opérationnelle apparaît lorsque des systèmes en fonctionnement acceptent, installent, exécutent et exposent un état observable. La rigueur consiste à laisser chaque preuve porter le nom étroit qu’elle a réellement gagné.

Sources

  1. RFC 5224
  2. RFC 5224, texte brut
  3. RFC 5224 sur l’IETF Datatracker
  4. Statut de RFC 5224
  5. Historique de RFC 5224
  6. Errata de RFC 5224
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. Paramètres AAA de l’IANA
  21. Spécification technique OMA PEM-1
  22. Architecture OMA PEEM
  23. Exigences OMA PEEM
  24. Registre OMA des AVP privés
  25. Lu Heng — Couches de réalité et pouvoir symbolique
  26. Lu Heng — Primauté du code exécuté
  27. Lu Heng — Le problème d’agence