Résumé

  • La RFC 3182 plaçait un ou plusieurs éléments AUTH_DATA dans les données de politique RSVP. Le localisateur désignait une politique; le nom, le ticket ou le certificat fournissait un matériau d’authentification. Aucun de ces éléments n’accordait seul la ressource.
  • L’identité n’était pas immuable de bout en bout. En unicast, le localisateur utilisateur pouvait venir du saut précédent tandis que le justificatif représentait le nœud courant. En multicast, le PDP pouvait choisir l’identité d’application qui survivait.
  • Une authentification réussie restait distincte de l’autorisation, de l’exécution locale, de la réservation sur tout le chemin, du traitement des paquets et du résultat applicatif.

L’adresse du règlement n’était pas le règlement

RSVP devait résoudre deux questions. La capacité demandée était-elle disponible? Le demandeur était-il autorisé à la recevoir? La RFC 2205 séparait admission control et policy control; les deux devaient être favorables. Le protocole transportait la donnée de politique sans en faire lui-même l’interprétation complète.

Publiée en octobre 2001 comme Proposed Standard, la RFC 3182 donna une structure à l’identité utilisée par la seconde décision. AUTH_USER désignait l’utilisateur, AUTH_APP l’application. Dans chaque élément, POLICY_LOCATOR pointait vers une politique d’admission, CREDENTIAL portait un nom, un ticket Kerberos ou un certificat, une signature pouvait protéger les attributs précédents, et un objet d’erreur expliquait un échec.

La RFC 3182 remplaça la RFC 2752 pour corriger une attribution de code et la taille d’un champ d’erreur. Il ne faut pas raconter cette substitution comme deux générations déployées. La date de mise à jour 2026 du Datatracker n’est pas davantage une révision récente: elle reflète notamment la présence d’un erratum vérifié.

Cet erratum, le numéro 2958, corrige l’exemple Kerberos de la section 6.3. Le serveur n’envoie pas le ticket au KDC pour obtenir la clé de session; il extrait la clé du ticket puis l’utilise pour authentifier l’utilisateur. Une histoire rigoureuse suit la correction, sans reproduire l’erreur parce qu’elle demeure dans le texte immuable du RFC.

Le localisateur répondait donc à une question étroite: où chercher la règle associée au sujet ou à l’application? Il ne disait pas qui avait mandat pour accorder de la bande passante, quelle version de la règle s’appliquait, ni si la capacité existait encore.

Une décision passait par plusieurs autorités

La RFC 2753 séparait le Policy Decision Point du Policy Enforcement Point. Le PDP pouvait consulter annuaire, authentification, comptabilité, facturation, groupe, heure et configuration locale. Le PEP appliquait la réponse au nœud. Même une politique favorable ne créait pas de ressources; l’admission de capacité pouvait encore échouer.

Cette architecture empêche de transformer une signature en mandat. Un certificat valide atteste une relation entre une clé, un nom et une chaîne de confiance dans un contexte précis. Il ne prouve pas que ce sujet peut réserver cette ressource dans ce domaine. Le mandat naît seulement lorsque l’autorité locale relie la preuve validée à une politique qu’elle est habilitée à faire exécuter.

Le chemin complet comprend ainsi la prétention d’identité, le type de justificatif, la validation, le principal authentifié, le localisateur, la version de politique, la décision du PDP, l’exécution du PEP, l’état de ressource, puis l’observation des paquets et de l’application. Un voyant vert qui fusionne ces étapes ne résume pas le système; il en détruit la preuve.

Texte, Kerberos et clé publique ne promettaient pas la même chose

La forme simple transportait un identifiant ASCII ou Unicode. Pour une application, un nom de fichier exécutable comme vic.exe pouvait servir d’exemple. La RFC reconnaissait que cette forme ne contenait aucun justificatif authentifiable de façon sûre et qu’elle était intrinsèquement moins sécurisée. Un nom de fichier ne mesure ni le binaire, ni son éditeur, ni le propriétaire du processus.

Kerberos supposait un KDC, un ticket destiné au prochain nœud RSVP ou à son PDP et un contexte de confiance compatible. La validation pouvait authentifier un principal dans ce contexte; elle n’importait pas avec elle le droit universel d’obtenir des ressources dans chaque domaine suivant.

La forme à clé publique ajoutait certificat et signature. Elle supposait une clé privée protégée, une autorité de certification reconnue et un vérificateur capable de contrôler certificat et signature. La possession de la clé ne réglait pas l’état de révocation, l’autorité organisationnelle, la politique de ressources ou l’identité réelle du processus émetteur.

La RFC 4230 montra ensuite les limites pratiques: le contrôle de révocation demandait d’autres mécanismes, la cryptographie à clé publique coûtait cher par flux, Kerberos ne masquait pas entièrement l’identité et l’authentification demeurait souvent insuffisante pour l’autorisation. Renforcer une preuve ne remplace pas les décisions qui suivent.

Le locuteur pouvait changer à chaque saut

Pour la politique utilisateur en unicast, la RFC 3182 copiait le localisateur du saut précédent, mais faisait porter les justificatifs sur l’identité du nœud réseau courant. Le sujet recherché et le locuteur authentifié pouvaient donc venir de moments différents.

En multicast, le localisateur utilisateur et le justificatif représentaient le nœud courant. L’identité d’application suivait une autre règle: copiée du saut précédent en unicast, elle pouvait être, en multicast, la première du message ou celle choisie par le PDP.

Cette sélection est une réduction. L’identité survivante ne représente pas automatiquement tous les émetteurs, récepteurs ou applications réunis. «Première» décrit un ordre; «choisie par le PDP» décrit une décision. Aucune formule ne crée à elle seule une représentation collective.

Plusieurs éléments AUTH_DATA pouvaient coexister, et des nœuds conscients des politiques pouvaient modifier les données. Il fallait donc conserver l’entrée, la sortie, l’acteur, le domaine de confiance, l’association de sécurité et la raison de chaque transformation. Garder seulement la dernière identité ferait disparaître la chaîne de garde.

Un saut pouvait laisser passer sans juger

Le déploiement ne supposait pas que chaque routeur comprenne la politique. La RFC 2753 autorisait une application aux frontières d’un domaine, avec des nœuds ignorants faisant confiance à ceux qui étaient capables de décider. La RFC 3182 prévoyait qu’un routeur ignorant les politiques puisse ignorer les objets et poursuivre le traitement RSVP.

Le passage n’attestait donc pas une autorisation à ce saut. Un PEP capable de politique pouvait consulter un PDP et refuser après une réponse négative. Une réponse positive permettait simplement au traitement RSVP de continuer; un autre nœud pouvait manquer de capacité, appliquer une autre règle ou ne jamais installer l’état attendu.

Cette distinction protège aussi les mesures. «Objet reçu», «justificatif validé», «politique approuvée», «ressource installée» et «service observé» sont cinq états. Une absence d’erreur n’est pas une preuve commune à ces cinq états.

L’erreur décrivait la politique, pas toute la conséquence

Les valeurs prévues incluaient type de justificatif non pris en charge, privilèges insuffisants, justificatif expiré et identité changée. Si le PDP ne vérifiait pas AUTH_DATA, il devait renvoyer un échec de contrôle de politique et devait, si possible, en préciser la cause.

Ces distinctions évitaient de confondre signature, privilège et capacité. Mais un code d’expiration ne prouvait pas que tous les états RSVP avaient été retirés, qu’un flux s’était arrêté, que chaque branche multicast avait reçu l’erreur ou que l’application avait réagi.

Le registre IANA actuel des paramètres RSVP conserve la classe POLICY_DATA et les erreurs de contrôle de politique. Cette coordination prouve l’existence d’un espace de numérotation. Elle ne mesure ni implémentation, ni déploiement, ni décision effective d’un routeur.

L’intégrité protégeait un périmètre, pas la légitimité

Quand le message RSVP entier n’était pas protégé, la RFC 3182 recommandait une intégrité propre à POLICY_DATA. Cette enveloppe pouvait résister à la modification et au rejeu dans une association de sécurité donnée.

La RFC 4230 distingua plus tard l’intégrité du message RSVP de celle du conteneur de politique. Elle rappela que des nœuds pouvaient modifier les éléments par conception, que l’information utilisateur pouvait fuir au-delà du premier saut et que la confidentialité générale n’était pas fournie entre routeurs.

Il faut donc vérifier successivement les octets, l’acteur authentifié et son mandat. Un condensat valide répond au premier problème. Un ticket ou une signature peut répondre au deuxième. Aucun calcul cryptographique ne décide si la politique est légitime, à jour ou correctement exécutée.

Le franchissement des domaines rendait ce point visible. La RFC 2753 envisageait la réécriture des objets selon des accords bilatéraux. La RFC 4230 constatait l’absence de format d’autorisation normalisé et de mécanisme convenu pour les réservations QoS en itinérance. L’identité pouvait voyager; le pouvoir d’autoriser restait local.

L’archive défendable gardait chaque reçu

Il faut d’abord conserver l’identité déclarée et l’élément brut, puis le type de justificatif, son vérificateur, le principal obtenu, le realm ou la chaîne de confiance, la protection contre rejeu et l’étendue de l’intégrité.

Viennent ensuite le localisateur, la version de politique, le domaine compétent, les autres entrées et la décision du PDP. Puis seulement l’accusé du PEP, la capacité, l’installation locale, les transformations ultérieures et les erreurs. Le plan de données et l’application produisent encore leurs propres observations.

Le multicast exige le registre de toutes les identités entrantes, de leur ordre, de la règle de sélection et des contributeurs perdus. Sans lui, une identité compacte peut se présenter abusivement comme celle du groupe.

La séparation entre symbole, pouvoir et exécution proposée dans les notes de Lu Heng sert ici de méthode éditoriale, non d’attribution aux auteurs du RFC. La RFC 3182 a donné au nom une place dans RSVP. Seul le système en fonctionnement pouvait montrer qui décidait, dans quel périmètre et avec quel effet.

Sources et limites

Le dossier repose sur le texte de la RFC 3182, sa fiche RFC Editor, le Datatracker, son API, l’erratum 2958 et la RFC 2752 remplacée. Le contexte vient des RFC 2205, 2750, 2753, 2747, 4230, 4094 et de la plus tardive RFC 4923. Les justificatifs historiques sont documentés par les RFC 1510 et 2459; la vue actuelle vient du registre IANA.

L’analyse s’inspire des textes de Lu Heng sur les couches de réalité et la primauté du code en fonctionnement. Les 18 sources ont été figées le 2 octobre 2026 en Asia/Shanghai. Elles n’identifient aucune implémentation, aucun opérateur, utilisateur, flux, incident, déploiement, test d’interopérabilité ou résultat de service nommé. Chaque état—standard, numéro, justificatif, approbation ou réservation locale—ne prouve que son propre périmètre.