Résumé

  • La RFC 1104 présentait trois modèles : agir sur la diffusion de l’information de routage, filtrer ou acheminer chaque paquet, puis allouer dynamiquement bande passante et tampons. La comptabilité constituait une fonction voisine, fondée sur l’historique.
  • La présence d’une route n’attestait pas l’admission d’un paquet. Une admission locale n’attestait ni trajet complet ni livraison. Aucune des deux ne prouvait une réservation de capacité, encore moins l’exactitude d’une imputation.
  • Chaque surface devait produire sa propre trace : état de joignabilité, décision locale sur le paquet, attribution d’une ressource rare, unité mesurée et acte ultérieur de facturation ou de sanction.

Quatre postes se cachaient derrière un seul mot

Datée de juin 1989 et signée H-W. Braun, de Merit/NSFNET, la RFC 1104 ne prétendait pas livrer l’architecture définitive du routage par politiques. Elle inventoriait des modèles afin d’ouvrir la discussion sur leur passage à l’échelle. Aujourd’hui, la notice du RFC Editor porte le statut Unknown, tandis que l’IETF Datatracker classe le document dans le flux Legacy, sans rang formel dans le processus de normalisation de l’IETF.

Son classement technique demeure fécond. Un premier mécanisme choisissait les informations de route diffusées. Un deuxième décidait du sort de chaque paquet. Un troisième distribuait des ressources dynamiques. La comptabilité conservait ensuite une histoire susceptible d’influencer de nouvelles politiques.

Ces postes pouvaient tous annoncer que « la politique a été appliquée ». Or ils ne recevaient pas le même objet et ne produisaient pas le même fait. La carte de joignabilité, le portique de filtrage, le répartiteur de capacité et le registre d’usage avaient chacun un contrôleur et une limite d’observation.

La carte de routes définissait des possibilités

La politique de diffusion du routage agissait à l’échelle des réseaux et des Administrative Domains. Elle décidait quelles annonces seraient acceptées, employées ou transmises. Son résultat pouvait rendre tout un réseau visible ou absent dans une vue de routage.

La RFC 1104 illustrait ce modèle avec l’interface NSFNET : contrôle de l’adresse source du pair, vérification du domaine ou de l’AS, vérification des numéros de réseau annoncés et maîtrise des métriques au moyen d’une base de politiques. Ces quatre contrôles ont déjà servi de preuve secondaire dans l’article Sofia Ren consacré à la RFC 1074. Ils ne constituent ni l’ouverture ni la thèse de la présente enquête.

La limite formulée juste après est plus importante. La distribution de routes ne remplace pas le filtrage des paquets et ne suffit pas à empêcher un trafic malveillant introduit par source routing. Elle manipule une possibilité macroscopique. L’absence de route explique une impossibilité dans une vue donnée, mais pas automatiquement la disparition observée d’un datagramme. La présence d’une route offre un choix ; elle ne prouve ni le choix effectué, ni le passage du paquet, ni sa réception.

Une preuve de routage doit donc nommer la portée, le voisin, l’objet annoncé, la version de politique et l’état obtenu. Elle ne peut pas devenir un reçu de livraison.

Le portique voyait un paquet, pas tout son voyage

Le second modèle portait sur le paquet individuel. Un équipement comparait les informations disponibles avec une règle, puis autorisait, transmettait ou rejetait localement. L’échelle devenait assez fine pour évoquer des hôtes ou des utilisateurs, là où le premier modèle restait au niveau des réseaux.

Cette finesse avait un prix. RFC 1104 signalait la charge imposée au routeur et la taille potentielle de bases de politiques qui devaient rester cohérentes. Une règle précise ne valait que si le dispositif pouvait la retrouver au moment de la décision et si les autres dispositifs utilisaient une version compatible.

Même parfaite, la trace n’établissait qu’un événement local. La RFC 1102 examinait un autre problème : la construction progressive d’une route de politique à travers une suite de régions administratives. Un filtrage réussi à un point ne construisait pas cette suite. Il ne démontrait pas le prochain saut, le chemin retour, l’arrivée ou la lecture par une application.

Le journal légitime devait rester étroit : représentation observée du paquet, point de contrôle, règle et version, résultat local. Dire ensuite « le routage de politique a fonctionné » lui ferait attester un trajet qu’il n’avait jamais vu.

Le répartiteur accordait une ressource rivale

Le troisième modèle concernait bande passante, tampons, circuits et priorité des files. La RFC le disait fondamentalement orthogonal à la diffusion du routage, tout en reconnaissant leurs interactions. Une route pouvait exister sans réservation ; un paquet pouvait être admis puis attendre faute de capacité. Une ressource pouvait aussi être préparée alors que la joignabilité échouait plus loin.

Surtout, l’allocation faisait apparaître un perdant possible. Donner davantage à un trafic réduisait parfois ce qui restait aux autres. Le partage entre domaines soulevait ainsi des questions politiques aussi bien que techniques : qui pouvait engager une ressource tenue par un autre opérateur ? Le texte posait la question sans transformer ses exemples en déploiements constatés.

Il introduisait également un arbitrage économique. Faire respecter la rareté exigeait calcul, mémoire, bases et gouvernance. Augmenter la ressource pouvait être moins coûteux que multiplier les contrôles. Le simple fait qu’une politique soit exprimable ne démontrait pas l’intérêt de son exécution.

Le registre racontait une histoire, il n’accordait rien

La comptabilité venait à part. RFC 1104 la décrivait comme la combinaison d’un historique et d’une politique. Des volumes, routes ou usages pouvaient être mesurés au niveau du domaine, du réseau, de l’hôte ou de l’utilisateur, puis orienter une décision ultérieure.

Mesurer ne revenait toutefois pas à autoriser. Le compteur ne diffusait pas une route, ne laissait pas passer le paquet et ne réservait pas un tampon. Il faisait une affirmation limitée à une unité, un point et une méthode. Dans un service traversant plusieurs domaines, le compte de l’un ne décrivait pas nécessairement le service de bout en bout.

La RFC 1125 décomposa ensuite la politique de tarification en unité, base de calcul, montant, payeur, compteur de référence et bornes. Ses exemples n’étaient pas des politiques officielles, mais cette structure montrait pourquoi le nombre ne suffisait pas. Il fallait encore une règle pour attribuer le nombre et une autorité pour agir.

L’accord entre les traces n’était pas garanti

La carte pouvait indiquer « joignable » tandis que le portique rejetait. Le portique pouvait admettre tandis que la file refusait la capacité. La capacité pouvait être réservée sans usage mesuré. Le compteur pouvait avoir une valeur sans désigner un débiteur. Ces désaccords décrivaient les frontières du système ; ils n’étaient pas nécessairement des erreurs à effacer.

Un champ unique « politique appliquée » détruirait l’enquête. Il confondrait absence de route et rejet, autorisation et qualité de service, réservation et consommation, mesure et responsabilité. L’objet durable devait conserver version, contrôleur, heure, portée, état de route, disposition du paquet, attribution de ressource, unité comptable et décision institutionnelle.

Sources