Summary

  • Le projet du groupe RADEXT entend normaliser le paquet RADIUS Protocol-Error, code 52, introduit à titre expérimental par la RFC 7930. Le registre IANA renvoie encore à cette RFC.
  • Error-Cause et Original-Packet-Code deviennent les deux attributs obligatoires. Le second rattache le diagnostic au type de demande réellement en attente lorsque plusieurs opérations portent le même identifiant.
  • L'erreur vaut pour un seul saut. Pour les causes 502 et 505, le proxy devrait chercher une autre connexion ou destination ; il lui est interdit de reprendre celle qui vient d'échouer.

Dans RADIUS, le silence a longtemps servi de réponse à trop de questions. Un serveur occupé, une requête impossible à traiter et un relais défaillant plus loin dans la chaîne peuvent tous laisser le même vide côté équipement d'accès. Celui-ci déclenche alors sa politique locale de temporisation et de nouvelle tentative. Plusieurs équipements peuvent interpréter ce vide différemment, tandis que le chemin défectueux reçoit encore davantage de trafic.

Le code 52 donne au serveur une phrase plus utile : la demande est arrivée, son traitement a échoué. Le texte en cours d'examen l'applique notamment aux demandes d'accès, de comptabilité, de changement d'autorisation et de déconnexion. Une comptabilité indisponible peut signaler un problème de traitement sans donner l'impression que l'événement est enregistré. Un incident technique dans l'authentification peut être décrit sans transformer artificiellement l'usager en refus d'accès.

La RFC 7930 avait déjà créé ce code dans un cadre expérimental ; la version de travail publiée début novembre cherche à en fixer le comportement plus largement.

Deux attributs empêchent le diagnostic de flotter sans dossier. Error-Cause décrit le défaut. Original-Packet-Code conserve le type de paquet à l'origine de la réponse. L'identifiant RADIUS peut se retrouver sur des opérations de types différents ; sa seule valeur numérique ne suffit donc pas à choisir la bonne demande en attente. La réponse reprend cet identifiant et le client doit écarter un code d'origine qui ne correspond à aucune demande pendante. Attribuer un incident comptable à une tentative de connexion serait une excellente façon d'automatiser la mauvaise décision.

La panne du relais reste chez le relais

Le paragraphe 4 traite Protocol-Error comme un message de saut en saut. Un proxy qui le reçoit doit examiner Error-Cause et ne peut simplement transmettre le paquet reçu. Il possède sa connexion vers l'aval ; l'équipement d'accès possède la demande remise au proxy. Faire passer le diagnostic brut de l'un à l'autre efface la frontière opérationnelle qui permet de réparer correctement.

Le projet réserve une lecture particulière aux causes 502, Request Not Routable (Proxy), et 505, Other Proxy Processing Error : elles indiquent un défaut du réseau de relais. Le proxy devrait alors réessayer sur une connexion différente vers le même destinataire, ou choisir une autre destination. Le texte interdit de renvoyer la demande sur la connexion qui a échoué. C'est la ligne qui sépare une reprise utile d'une machine à fabriquer des paquets. Le nombre de tentatives, la durée admise et la liste des routes de secours restent des choix de déploiement, que le projet ne règle pas entièrement.

Pour les autres causes, le proxy devrait traiter l'erreur comme provenant du serveur d'origine et adresser à son propre client un nouveau Protocol-Error qui conserve la cause. Cette nouvelle réponse a une provenance : elle vient du proxy, après lecture du résultat aval. Une trace exploitable relie donc la demande initiale, l'erreur du prochain saut, le choix de route du proxy et la réponse finale à l'équipement d'accès. Le paquet d'erreur constate un échec de traitement à un endroit précis ; l'issue d'une authentification ou d'une écriture comptable se constate au dernier état pertinent.

Les sections sur la migration, la négociation et le choix exact des réponses portent encore la mention TBD. Aucun parcours réel à travers deux relais ne figure dans le dossier officiel. Un essai contrôlé devrait enregistrer type et identifiant de la demande, cause retournée, connexion abandonnée, éventuel nouveau chemin et décision reçue par l'équipement d'accès. C'est le document qui permettrait de juger le comportement en exploitation.

Projet RADEXT · État Datatracker · RFC 7930 · Registre IANA