Résumé

  • RFC 3318 autorisait * dans une combinaison de rôles de politique : une seule règle pouvait viser les interfaces possédant les rôles requis, quels que soient leurs rôles supplémentaires.
  • Le joker ne fixait aucun ordre de priorité. Le PDP devait résoudre les incompatibilités ; si elles arrivaient jusqu’au PEP, celui-ci devait refuser l’installation plutôt que fabriquer sa propre synthèse.

La répétition se mesure facilement : elle occupe des lignes, des messages et du temps d’exploitation. Le chevauchement se cache mieux. Plus une règle est générale, plus elle risque de rencontrer une autre règle générale sur la même interface. Le Framework PIB de 2003 associait ces deux phénomènes au même outil : le rôle et son astérisque.

Dans l’architecture COPS-PR, le Policy Decision Point décidait des informations à provisionner et le Policy Enforcement Point représentait l’équipement chargé de les accepter. SPPI définissait les classes et instances d’une Policy Information Base. RFC 3318 fournissait les éléments communs à plusieurs domaines : rôles, ensembles de capacités, incarnations d’état, limitations et erreurs.

Un rôle était une chaîne décrivant une fonction d’interface : finance, manager, interface de cœur ou pare-feu. Une interface pouvait en porter plusieurs. La politique comportait une RoleCombination, comparée à l’ensemble déclaré par l’interface. Cette indirection évitait au serveur central de connaître le nom local de chaque port et permettait de transmettre une seule politique à plusieurs interfaces fonctionnellement équivalentes.

La notation était canonique. La casse comptait et les rôles devaient être classés selon l’ordre ASCII. a+b était la forme valide ; b+a n’était pas une autre combinaison, mais une mauvaise écriture du même ensemble. La combinaison sans rôle s’appelait null. Ces contraintes donnaient aux deux extrémités une représentation stable à comparer.

L’astérisque étendait la réutilisation. Dans une classe install ou install-notify, *+a+b désignait toute interface contenant a et b, avec zéro, un ou plusieurs rôles supplémentaires. * ne pouvait pas devenir un rôle réel de l’interface et ne servait pas à compléter une partie de nom. RFC 3318 donnait une règle ensembliste : *+b+e+g correspondait à a+b+c+e+f+g.

Trois interfaces portant toutes A et B, mais aussi respectivement R1, R2 et R3, pouvaient ainsi partager une seule politique *+A+B. Le PDP économisait trois copies et l’intention devenait lisible : traiter tout ce qui possède les deux rôles essentiels.

Cette économie ne produisait toutefois aucune précédence. Plusieurs combinaisons génériques pouvaient correspondre à la même interface. Certaines politiques pouvaient coexister ; d’autres pouvaient attribuer des traitements incompatibles au même point de contrôle. La correspondance disait seulement « applicable », jamais « prioritaire ».

RFC 3318 plaçait l’arbitrage au PDP. Celui-ci devait tenter de résoudre les conflits avant l’envoi. Si des politiques incompatibles parvenaient malgré tout au PEP, à cause d’une erreur du PDP ou d’une contrainte propre à l’équipement, le PEP devait rejeter leur installation et retourner une erreur. Le refus conservait une frontière explicite entre décision et exécution.

L’exemple finance et manager rendait cette frontière concrète. Deux interfaces pouvaient d’abord être finance et une troisième manager. Après la promotion d’une personne, une interface signalait finance+manager. Le PDP pouvait donner la priorité à la politique des managers ou créer une troisième politique, par exemple un marquage DSCP 7. Même si le résultat reproduisait une politique existante, le PDP devait le déterminer et le télécharger.

Le PEP n’était ni obligé ni autorisé à composer la nouvelle politique à partir des deux anciennes. Une telle commodité aurait déplacé le pouvoir de décision vers chaque équipement. Deux constructeurs auraient pu fusionner les mêmes entrées différemment, tandis que le contrôleur aurait perdu la capacité d’expliquer l’autorisation du résultat. Une erreur visible était préférable à une réussite inventée localement.

La modification des rôles formait elle aussi une séquence. Le PEP déclarait ses associations dans un état complet. Le PDP pouvait ensuite les changer par décision non sollicitée. Après traitement réussi, le PEP envoyait d’abord son rapport de succès, puis de nouveaux états complets pour les contextes ouverts. En cas d’échec, il ne renvoyait qu’un rapport d’échec. Avant le succès, le PDP ne devait pas supposer le nouvel état.

Pendant l’intervalle de resynchronisation, une décision pouvait encore refléter les anciens rôles. L’étiquette modifiée ne prouvait donc pas que toutes les politiques dépendantes avaient été recalculées. RFC 3084 décrivait les messages de requête, décision et rapport ; RFC 3159 fournissait le modèle PIB. Ensemble, ils distinguaient l’intention de rôle, l’acceptation, le nouvel état et l’effet sur les paquets.

La sécurité du transport ne résolvait pas la sémantique. RFC 3318 avertissait qu’une information configurable pouvait être mal configurée avec des effets graves. Authentifier deux politiques prouvait leur origine ; les chiffrer protégeait leur contenu. Ni l’une ni l’autre opération ne décidait si finance ou manager devait l’emporter.

En 2016, l’IESG a reclassé RFC 3318, COPS-PR et SPPI comme Historic, en mentionnant leur déploiement limité et le déplacement des travaux vers NETCONF et YANG. Cette décision interdit d’en faire le récit d’une pratique universelle. Elle n’efface pas la leçon : mutualiser une règle ne mutualise pas la responsabilité de trancher.

L’astérisque réduisait la quantité de configuration. Il ne réduisait pas le nombre de décisions nécessaires lorsque les ensembles se recouvraient. RFC 3318 confiait cette décision au PDP et donnait au PEP un devoir de refus lorsque l’autorité centrale n’avait pas fourni de résultat cohérent.

Sources : RFC 3318, RFC 3084, RFC 3159 et le changement de statut de l’IESG en 2016.