Résumé

  • Dans RFC 3084, un message de décision COPS-PR constituait une transaction indivisible : toutes ses suppressions et installations réussissaient, ou le PEP revenait à la dernière transaction réussie.
  • Le rapport de succès ne garantissait pas une vérité durable. Pendant une rupture, le PEP continuait avec sa politique en cache ; au retour du lien, il fallait réconcilier les Request-States ou accepter l’hypothèse que les deux côtés étaient restés d’accord.

L’ordre envoyé devenait un état local

Un PDP envoie au routeur un message qui retire un ancien filtre et installe son remplaçant. TCP livre les octets. Le PEP répond par un rapport Success. Le serveur dispose alors de mieux qu’un journal d’émission : l’équipement affirme avoir appliqué la transaction.

Ce reçu ne traverse cependant pas toutes les couches. Le PEP doit encore traduire les instances de politique en files, classificateurs ou mécanismes propres à sa plateforme. Un rapport COPS n’est ni une capture de paquets, ni une mesure de file, ni la preuve que l’application a obtenu la qualité attendue. Il clôt une opération de provisioning à une frontière précise.

Publiée en mars 2001, RFC 3084 définissait COPS-PR, l’usage du Common Open Policy Service consacré au provisioning. Le Policy Decision Point fournissait des informations au Policy Enforcement Point. Une Policy Information Base décrivait les classes ; une PRI était une instance, et un PRID l’identifiait. Le protocole restait indépendant du domaine — qualité de service, sécurité ou autre — et ne prétendait pas fournir un modèle universel de politique.

Cette frontière distingue l’article de celui consacré à RFC 3060. PCIM avait normalisé une structure d’information sans imposer l’algorithme local qui l’évalue. Ici, la question est différente : même lorsque les données sont comprises, comment deux machines prouvent-elles que l’état installé, reconnu, conservé puis resynchronisé est bien le même ?

L’atomicité protégeait le remplacement

Un DEC pouvait contenir plusieurs décisions. Les suppressions devaient précéder les installations, non pour promettre une chronologie observable, mais pour résoudre la priorité au sein d’une même transaction. Tout le message devait réussir ou échouer. Si une nouvelle règle ne pouvait être installée, le PEP envoyait Failure et revenait au dernier état considéré comme bon.

Cette propriété empêchait une demi-migration : l’ancienne politique supprimée alors que sa remplaçante échoue. Chaque DEC, même nul, exigeait un RPT sollicité. Le PDP pouvait donc distinguer la décision envoyée de la décision acceptée.

RFC 3084 séparait aussi deux formes d’échec. Un échec sollicité, immédiatement associé au DEC, possédait un point de retour clair. Une configuration précédemment installée pouvait en revanche tomber en panne plus tard et provoquer un rapport non sollicité. Dans ce cas, le texte reconnaissait que revenir à un « bon » état antérieur pouvait être impossible : après des changements asynchrones, l’état correct devenait ambigu. La même étiquette d’échec ne signifiait donc pas la même capacité de réparation.

Les versions ne se rencontraient pas symétriquement

Les PIB étaient appelées à évoluer. Si un PDP récent envoyait une nouvelle classe à un PEP ancien, celui-ci devait signaler l’erreur et restaurer son état précédent. Dans le sens inverse, un PEP récent relié à un PDP ancien ne recevait simplement aucune instance de cette classe. Les classes dépréciées suivaient encore une autre règle.

Ces conventions limitaient la casse, mais ne rendaient pas les versions équivalentes. Le succès d’un échange attestait les objets effectivement traités. Il ne prouvait pas que les deux côtés connaissaient les mêmes classes inutilisées, disposaient des mêmes capacités, ou traduisaient une instance dans le même mécanisme de transfert.

L’architecture choisissait en outre un seul écrivain pour une zone de politique identifiée par un Client-Type. Tant que le PEP restait connecté à son PDP, la configuration était décrite comme verrouillée, y compris face à la console locale. Éliminer les écrivains concurrents clarifiait l’autorité ; cela rendait aussi l’identité du serveur, la connexion et le magasin d’état indispensables à la continuité du contrôle.

La coupure donnait une autorité provisoire au cache

Après une perte de communication, le PEP tentait d’abord le dernier PDP, puis un serveur secondaire configuré. Il continuait entre-temps à utiliser le Request-State actif. Lors de la reconnexion, LastPDPAddr pouvait indiquer de quel PDP provenaient les décisions encore en cache. Le nouveau serveur décidait alors s’il fallait demander une synchronisation.

Une requête SSQ obligeait le PEP à réémettre les REQ de tous les Request-States connus. Le PDP envoyait ensuite les suppressions de PRID ou de préfixes nécessaires pour revenir à un état connu et cohérent. Si le serveur ne demandait pas cette procédure, le client pouvait supposer qu’il était reconnu et que son état était correct. Cette règle évitait un transfert complet systématique ; elle ne constituait pas une vérification indépendante.

Les changements locaux survenus pendant la coupure devaient tout de même être rapportés. Et si la reconnexion n’arrivait pas avant un délai administratif, PEP et PDP supprimaient leurs états associés. Les deux extrémités avaient donc une politique d’expiration, mais l’existence de deux temporisateurs ne garantissait pas leur déclenchement au même instant.

Les documents ultérieurs étendirent l’ensemble : SPPI fournit un langage pour les PIB, puis des RFC décrivirent des PIB de QoS, de cadre et de retour d’usage. En 2016, l’IETF reclassa RFC 3084 et ces textes en Historic, mentionnant un déploiement limité et le déplacement des travaux de configuration vers NETCONF et YANG. Le constat éclaire une trajectoire ; il ne démontre ni l’absence totale d’implémentations ni l’état d’un équipement précis.

L’héritage utile de RFC 3084 est une discipline de preuve. L’intention du PDP, la transaction DEC, le RPT du PEP, le cache, la resynchronisation, la configuration locale et l’effet sur le trafic sont des faits reliés mais distincts. Un protocole fiable peut transporter la règle ; seul un rapprochement explicite, suivi d’une observation du réseau, montre ce que l’équipement a réellement conservé.

Sources

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/