Summary

  • RFC 5221 demande qu’une politique de sélection d’adresses mise à jour dynamiquement puisse être administrée au centre sans effacer les différences entre nœuds, applications et interfaces, et qu’elle soit coordonnée avec le choix du prochain saut.
  • Il faut donc un reçu d’état qui distingue l’autorité du contrôleur, l’intégrité, la livraison, la portée applicable, l’installation, la synchronisation du routage, la paire d’adresses choisie, la réponse du pair et le résultat applicatif.

Le reçu de livraison n’est que le début

Une équipe de contrôle peut produire un chiffre impeccable : cent pour cent des machines ont téléchargé la version attendue, vérifié sa signature et confirmé son installation. Ce chiffre répond à une question utile. Il ne répond pas à la question décisive : la règle installée était-elle la bonne règle pour cette décision précise ?

RFC 5221, publié en 2008, ne choisit pas un protocole universel de distribution. Le texte formule les exigences auxquelles un mécanisme de mise à jour des règles de sélection d’adresses devrait répondre. Il exige une mise à jour dynamique et un contrôle central, mais aussi des comportements propres au nœud, à l’application et à l’interface. Il demande en outre une coordination avec la sélection du prochain saut.

Ces exigences mettent en tension deux objectifs. Le centre cherche une politique cohérente. Le poste agit dans un contexte local qui change. Une organisation ne peut pas résoudre cette tension en supprimant le contexte de ses preuves.

Une politique traverse plusieurs états

Le vocabulaire « déployé » ou « non déployé » est trop court. Il faut d’abord prouver que le contrôleur est autorisé pour la population visée. Il faut prouver ensuite que l’objet n’a pas été altéré, qu’il est arrivé au bon nœud, que la bonne version a été installée et que sa portée inclut l’application et l’interface concernées.

Puis commence la partie que le tableau de configuration ne voit pas. Les préférences doivent correspondre à l’état actuel du routage. La pile doit sélectionner la paire source-destination attendue. Le prochain saut doit mener à un pair joignable. Enfin, l’application doit obtenir le résultat recherché.

La réussite d’une étape ne se transmet pas automatiquement à la suivante. Une signature valide ne prouve pas l’autorisation fonctionnelle de l’émetteur. Une installation valide ne prouve pas la portée. Une règle applicable ne prouve pas la cohérence avec le routage. Un paquet envoyé ne prouve pas la réponse du pair. Une session ouverte ne prouve pas la valeur livrée à l’utilisateur.

Cette chaîne doit apparaître dans le dossier de décision, avec une date et un responsable pour chaque passage.

Le centre ne voit pas toujours la différence locale

L’exigence de comportements distincts par nœud, application et interface n’est pas un détail de mise en œuvre. Deux machines du même parc peuvent avoir des rôles, des capacités et des contraintes différentes. Deux applications sur une même machine peuvent utiliser des interfaces de programmation ou des modèles de continuité différents. Deux interfaces peuvent conduire vers des domaines administratifs et des prochains sauts différents.

Une table unique distribuée à tout le monde peut donc être parfaitement valide sur le plan syntaxique et trop large sur le plan opérationnel. Si son enregistrement ne dit pas à quelle classe de nœuds, d’applications et d’interfaces elle s’applique, il manque le sujet de la règle.

Le décalage temporel aggrave le problème. Une interface disparaît. Un ordinateur change de réseau. Un routeur annonce une préférence nouvelle. Une application maintient une session pendant que la politique bascule de version. Le contrôleur peut conserver un modèle global cohérent mais déjà ancien, tandis que le nœud décide avec un état local plus récent.

Le contrôle central n’est pas en cause. Ce qui est en cause, c’est la prétention qu’une même réception établit une même pertinence. Une erreur répétée partout reste une erreur.

La préférence d’adresse et le prochain saut produisent ensemble le résultat

RFC 5221 demande que le mécanisme soit coordonné avec le choix du prochain saut. RFC 4191 décrit séparément des informations de préférence de routeur et de routes plus spécifiques que l’hôte peut utiliser. Ces documents ne démontrent pas qu’un produit donné synchronise les deux plans. Ils montrent pourquoi un audit séparé est insuffisant.

La politique d’adresses peut privilégier une source ou une destination selon une représentation de la topologie. Le routage décide où le trafic part réellement. Si la politique et l’instantané de routage ne couvrent pas la même interface ou la même heure, chaque composant peut paraître sain alors que leur composition produit une décision inadéquate.

L’objet auditable doit être la décision. Pour un flux échantillonné, le dossier doit contenir le nœud, l’application, l’interface, la version de politique, la règle correspondante, les candidats, la paire retenue, la route, le prochain saut, l’heure, la réponse du pair et le résultat applicatif. Cette trace permet de tester une affirmation au lieu de célébrer un fichier installé.

L’authenticité ne suffit pas à établir l’applicabilité

RFC 5221 attire l’attention sur la fuite d’informations, l’injection ou la modification malveillante d’une politique susceptible de détourner le trafic, ainsi que sur le déni de service contre le contrôleur. Une chaîne de distribution protégée est donc nécessaire. Elle n’épuise pourtant pas le problème.

Il faut aussi autoriser précisément la portée, empêcher la répétition d’une ancienne version, définir l’expiration et le retour arrière, conserver la provenance, prévoir un mode sûr quand le contrôleur est indisponible et vérifier que les exceptions locales n’ont pas disparu lors d’une normalisation centrale.

Une politique ancienne mais correctement signée doit avoir un état distinct. Une politique authentique émise par un contrôleur non habilité pour une classe d’applications aussi. « Authentique » décrit l’origine et l’intégrité ; « applicable » décrit la décision que l’organisation autorise dans un contexte déterminé.

Ce que les sources ne prouvent pas

RFC 5221 est un document d’exigences, pas un rapport de déploiement. Il ne prouve ni qu’un mécanisme donné satisfait ces exigences, ni qu’un fournisseur diffuse des politiques dangereuses, ni qu’un réseau actuel a subi une injection. RFC 3484 fournit le contexte historique des règles par défaut et RFC 6724 l’a remplacé ; cette analyse ne propose pas de rétablir l’ancienne table.

Elle ne reprend pas non plus le mécanisme distinct de RFC 5220 sur les réseaux à demi fermés et le chemin retour. Elle ne prescrit aucun classement de familles d’adresses ni aucune course de connexions. Son propos est strict : la livraison centrale n’établit ni la portée correcte, ni la synchronisation avec le prochain saut, ni le succès de la communication.

Constituer un reçu d’état de la politique

Pour chaque version importante, il faut conserver l’identité et l’autorisation du contrôleur, l’approbation, le hash et la version exacts, les classes de nœuds, d’applications et d’interfaces visées, les heures d’émission et d’expiration, les chiffres de livraison et d’installation, les exceptions locales, les hypothèses de routage, les traces de décisions échantillonnées, le comportement sans contrôleur et les conditions de retour arrière.

Les anomalies appartiennent au reçu. Rejets, versions périmées, interfaces sans règle, chemins d’API inattendus, décisions fondées sur un routage plus récent, absence de réponse du pair et recours à un repli décrivent la frontière réelle du contrôle.

Le cadre de Lu Heng, centré sur la réalité observable et l’attribution, interdit d’emprunter la preuve d’un autre acteur. L’équipe du contrôleur prouve l’émission. L’équipe du poste prouve l’installation. L’équipe réseau prouve l’état des routes. Le propriétaire de l’application prouve le résultat. La gouvernance commence quand ces preuves sont reliées sans être confondues.

Sources

Dossier normatif complémentaire

  1. RFC 5221 en texte brut
  2. Fiche RFC 5221
  3. Dossier Datatracker de RFC 5221
  4. Errata de RFC 5221
  5. Fiche RFC 3484
  6. Fiche RFC 6724
  7. Fiche RFC 4191