Résumé

  • La RFC 3539 limite volontairement le chien de garde AAA au pair immédiat. Une absence de réponse métier ne prouve pas que ce pair est mort, et son échec ne prouve pas que la requête confiée à l’ancienne connexion a disparu.
  • Lors du basculement, la file des requêtes en attente part vers un agent de remplacement. Pour une authentification dépendante de l’état, le premier serveur peut répondre Accept et le second Reject. Identifier le doublon, choisir une réponse, l’appliquer sur le NAS et constater l’accès sont quatre preuves différentes.

Un basculement est souvent raconté comme une substitution : le primaire tombe, le secondaire prend sa place. La RFC 3539 décrit une réalité moins propre. La nouvelle route commence avant que l’ancienne ne soit certaine d’avoir fini. Pendant cet intervalle, une seule intention existe dans deux chemins, peut atteindre deux processeurs et peut produire deux réponses.

Publiée en juin 2003 comme Proposed Standard, la RFC Authentication, Authorization and Accounting (AAA) Transport Profile étudie précisément les transports utilisés par l’authentification, l’autorisation et la comptabilité. Elle ne rapporte ni panne réelle ni pratique d’un opérateur nommé. Elle fournit le modèle qui permet de ne pas appeler « succès » une récupération dont les effets n’ont pas été réconciliés.

Le chien de garde ne voit pas au-delà de son voisin

Le mécanisme de surveillance applicative doit distinguer l’indisponibilité d’un pair des délais ordinaires d’une transaction. Toute réponse AAA provenant du pair constitue un signe de vie. L’absence de réponse à une demande d’accès ne suffit pas à déclarer ce pair hors service : un proxy ou un serveur situé plus loin peut être la cause du silence.

La RFC attend donc l’échec d’une requête de chien de garde avant la transition vers l’état de panne décrit. Le périmètre est intentionnel. Le test vise le pair immédiat et ne doit pas être perturbé par les défaillances des composants en aval. Il ne s’agit pas non plus d’un heartbeat de cluster. Un DWA ou son équivalent n’atteste ni la disponibilité du domaine d’origine, ni la fraîcheur de sa base d’état, ni une décision d’autorisation.

Ce confinement évite qu’un problème profond fasse osciller tous les clients amont. Mais il oblige l’exploitation à écrire une phrase précise : « ce pair a répondu » ou « ce pair n’a pas répondu au contrôle », jamais « le service d’identité complet est sain ».

La temporisation porte le même compromis. La valeur initiale par défaut décrite est de trente secondes avant jitter ; elle peut descendre à six secondes, hors jitter, mais pas davantage. La RFC prévient qu’une valeur courte augmente les doublons et les basculements ou retours prématurés. Réduire l’attente face à une vraie panne diminue donc la tolérance accordée à un pair simplement retardé.

Le réglage n’abolit pas l’incertitude : il choisit qui la supporte.

Le basculement copie une file locale

Pour savoir quoi renvoyer, le client ou l’agent conserve une file de messages en attente pour chaque pair. La réception d’une réponse retire la demande correspondante. Lorsque le basculement commence, tous les messages encore présents sont transmis à un agent de remplacement, s’il existe.

Cette règle travaille sur un fait local : aucune réponse corrélée n’a encore fermé l’entrée. Elle ne sait pas qu’une requête originale vient d’être validée à distance, qu’un Accept est bloqué derrière un proxy ou que l’ancien chemin a atteint un autre serveur. Elle ne peut pas attendre une preuve d’extinction parfaite sans perdre l’objectif même de disponibilité.

La RFC impose donc aux agents et serveurs de se préparer aux doublons et de supposer qu’ils peuvent arriver par n’importe quelle connexion. Le changement de socket ne crée pas une nouvelle intention. L’échec du socket ne détruit pas l’ancienne.

Le reçu de basculement doit garder l’identité du pair initial, celle du remplaçant, le déclencheur, l’instantané de la file, le condensat de la demande et les deux heures d’envoi. Sans cela, le mot « retry » mélange une copie fidèle, une nouvelle demande, un changement de cible et une éventuelle transformation de contenu.

Deux identifiants décrivent deux frontières

Le profil évoque l’identifiant Hop-by-Hop pour rapprocher une réponse de la requête locale encore en file. Pour reconnaître le même travail au-delà des agents, il exige la combinaison d’un identifiant de bout en bout et de l’hôte d’origine.

La RFC 6733 a repris ce modèle dans le protocole Diameter. Elle conserve l’algorithme de détection de panne de la RFC 3539, retransmet les demandes en attente vers un autre agent avec l’indicateur approprié et rappelle que plusieurs demandes ou réponses identiques peuvent être reçues. L’End-to-End Identifier avec Origin-Host sert à repérer les doublons ; le Hop-by-Hop Identifier reste lié à l’échange adjacent.

Cette séparation empêche deux erreurs. La première consiste à traiter une réponse locale comme une preuve de décision unique de bout en bout. La seconde consiste à transformer un identifiant global en verrou magique. La clé permet de dire « ces messages parlent du même travail ». Elle ne prouve pas qu’un seul serveur a écrit l’état, que les caches sont cohérents ou qu’un seul effet est arrivé jusqu’au NAS.

Reconnaître un doublon ouvre donc une étape de disposition. Faut-il renvoyer la réponse déjà durable, attendre son propriétaire, refuser une réévaluation ou compenser un effet antérieur ? La RFC 6733 demande normalement qu’une demande dupliquée reçoive la même réponse, hors détail de hop. Cette stabilité suppose que le système puisse retrouver la décision, et pas seulement retrouver la clé.

Accept et Reject peuvent être tous deux explicables

La RFC 3539 propose une frontière nette entre les dossiers comptables et certaines authentifications. Pour la comptabilité, elle cite l’identifiant de session, l’horodatage d’événement et l’identité du NAS afin d’éliminer les enregistrements répétés. Ce triplet rappelle déjà qu’une ressemblance de paquet ne suffit pas à définir un événement.

Une authentification peut dépendre d’un état établi précédemment. Prenons la restriction d’usage simultané donnée par le texte. La première copie atteint un serveur lorsque l’utilisateur n’est pas encore considéré comme connecté et obtient Accept. L’état évolue. La seconde copie atteint un autre serveur et obtient Reject parce qu’une seule session est permise.

Les deux moteurs peuvent avoir appliqué correctement leur vue locale. La contradiction naît du décalage des vues et de la non-idempotence de la décision. Le client peut recevoir les deux réponses ; la RFC constate que l’issue dépend alors de celle qui arrive en premier.

Cette phrase révèle un mécanisme de gouvernement caché. Si aucune règle plus forte n’existe, la latence sélectionne l’autorisation. Déplacer le serveur secondaire, modifier un proxy ou raccourcir une file peut changer le résultat sans toucher à la politique déclarée.

Ce n’est pas la preuve d’un incident actuel. C’est la raison pour laquelle une organisation doit décider avant l’incident si elle conserve une réponse unique par identité de bout en bout, si elle réévalue, comment elle traite une contradiction et qui possède le droit de choisir.

Le client doit conserver la réponse qu’il n’a pas choisie

Un journal qui ne garde que le résultat appliqué fait disparaître le problème. Il faut enregistrer chaque réponse avec le serveur émetteur, son état ou epoch, la contrainte utilisée, l’heure de décision et la classification du doublon. Le client doit ensuite produire une preuve de sélection : réponses reçues, ordre observé, règle applicable, réponse choisie et raison.

« La première a gagné » doit être une politique assumée ou un constat critiquable, pas une conséquence invisible du code. « Les réponses étaient identiques » doit être vérifié sur le contenu et l’identité, pas déduit du fait qu’elles portent le même Result-Code.

Le NAS ouvre une frontière supplémentaire. Un Accept qui revient ne prouve pas que le profil a été installé ni que l’accès a fonctionné. Un Reject tardif ne prouve pas que l’accès a été bloqué si un Accept antérieur avait déjà été appliqué. Les enregistrements d’application, d’ouverture de session et de comptabilité doivent suivre la réponse retenue.

Ainsi, le propriétaire du transport peut attester une connexion secondaire saine. Il ne peut pas attester la cohérence des serveurs. Le propriétaire de la politique peut attester une décision. Il ne peut pas attester ce que le NAS a exécuté. Le propriétaire du NAS peut attester une configuration. Il ne peut pas attester seul le résultat utilisateur.

Le précédent RADIUS doit rester à sa place

RADIUS possède une autre grammaire de transaction. Son Identifier d’un octet, son Request Authenticator, le contexte de transport et le secret partagé participent au rapprochement des réponses et aux règles de retransmission. Les RFC 2865, 2866 et 5080 délimitent ce modèle.

Ces champs ne doivent pas être renommés en identifiants Diameter. L’article présent ne répète pas le sujet historique de l’identité RADIUS. Il examine la copie interconnexion décrite par la RFC 3539 et la façon dont un état changeant peut transformer une copie en seconde décision.

Le principe commun reste utile : une retransmission doit garder assez d’identité pour rester le même travail. Mais la preuve d’identité ne remplace jamais la preuve de disposition.

Un dossier de preuve en sept pièces

La première pièce décrit la demande logique : origine, identité de bout en bout, condensat immuable, utilisateur ou session, application et date de création. La deuxième décrit le pair : connexion, dernière réponse qualifiante, cycle du chien de garde, temporisation et cause du soupçon.

La troisième fixe le basculement : ancien pair, nouvel agent, copie exacte de la file, indicateur de retransmission et heures. La quatrième conserve chaque décision serveur, son état observé, sa règle, la recherche de doublon et son point de commit.

La cinquième appartient au client : toutes les réponses, leur ordre et le choix. La sixième appartient au NAS : validation et profil réellement appliqué. La septième relie la session et ses événements comptables au résultat visible.

Une synthèse honnête peut alors dire : « ce pair immédiat a échoué au contrôle ; ces identités encore en attente ont été renvoyées ; les décisions concurrentes ont été rapprochées selon cette règle ; le NAS a appliqué cette réponse ; l’accès et la comptabilité observés étaient ceux-ci ». Chaque clause manquante doit rester une incertitude, pas devenir un adjectif rassurant.

Limite des preuves

Cet Article ne nomme aucun opérateur, fournisseur, domaine AAA, déploiement RADIUS ou Diameter, compte, connexion, NAS, incident, panne, événement de sécurité, double facturation ou utilisateur. Il ne mesure ni adoption, ni latence, ni fréquence de réponse contradictoire.

La RFC 3539 est traitée comme un Proposed Standard de juin 2003. La RFC 3588 fournit un contexte historique et a été remplacée par la RFC 6733. Cette dernière conserve le mécanisme de panne et d’identification des doublons ; elle ne prouve pas sa bonne mise en œuvre dans un système réel. Les RFC 8174 et 6298 bornent respectivement le langage normatif et le contexte de temporisation.

Les notes de Lu Heng sur la primauté du code en fonctionnement et la spécification initiale minimale sont une grille éditoriale déclarée. Elles aident à séparer document publié, décision locale, mise en œuvre et résultat. Elles ne prouvent ni l’intention des auteurs de la RFC ni un fait de terrain.

La conclusion limitée est la suivante : le basculement peut copier une seule demande AAA avant l’extinction de l’originale. L’identité commune permet de la reconnaître. Seules une disposition idempotente, une sélection explicite, une exécution vérifiée et une observation finale permettent de parler d’un effet unique.

Sources