Résumé

  • La révision 18 du projet RadSec borne la santé à une connexion et au prochain saut ; un proxy RADIUS masque l’état des domaines et des services d’identifiants situés derrière lui.
  • TLS/DTLS, Status-Server et les keepalives restent indispensables, mais ils ne remplacent ni la preuve de routage du domaine, ni la réponse du serveur d’origine, ni l’effet produit sur l’accès.

Imaginons un établissement qui confie l’itinérance de ses accès à un proxy de fédération. Les requêtes pour plusieurs dizaines de domaines empruntent le même pool RadSec. Le certificat du proxy est accepté, les connexions sont stables et le watchdog applicatif répond. Seul le domaine exemple.net ne renvoie plus ni acceptation ni refus.

Une supervision construite autour du serveur peut déclarer : « RADIUS est disponible ». Une supervision construite autour de l’utilisateur dira : « cette route d’authentification ne produit plus de décision ». Les deux phrases ne décrivent pas le même objet.

RADIUS fonctionne saut par saut. Pour l’équipement d’accès, le proxy joue le rôle du serveur. Pour le serveur d’origine, il devient client. Entre les deux, il peut choisir une route selon le realm, appliquer une politique, changer de transport, attendre une base d’identités ou solliciter un autre proxy. Le premier équipement n’observe pas cette topologie. Il ne reçoit que la réponse du voisin qui lui fait face.

La section 3.8 de draft-ietf-radext-radiusdtls-bis-18 transforme cette distinction en règle d’exploitation. L’état TCP, TLS ou DTLS doit être combiné au watchdog applicatif de RFC 3539. Une connexion ne passe à l’état indisponible que si la pile réseau la juge non viable, si D(TLS) ne fournit plus de canal utilisable ou si l’algorithme applicatif la classe ainsi. Le verdict porte sur une connexion précise. La défaillance d’un membre du pool ne doit pas condamner tous les autres.

Cette finesse évite qu’une association DTLS oubliée, une terminaison déséquilibrée ou un backend particulier fasse tomber un service entier. Elle interdit aussi de conclure dans l’autre sens : une connexion saine n’absout pas toutes les dépendances qu’un proxy dissimule.

RFC 5997 explique pourquoi Status-Server ne peut pas trancher le cas du domaine. Un serveur ou proxy ne doit jamais transférer ce paquet. La réponse concerne uniquement l’adresse et le port interrogés. Comme le serveur ne route pas la requête de surveillance à partir du User-Name, celle-ci ne donne aucune information sur l’accessibilité d’un realm donné. La non-transmission rend le signal clair pour le premier saut ; elle le rend volontairement muet sur le reste.

Le projet impose aux clients RadSec ce mécanisme et aux serveurs la capacité d’y répondre. Il suggère de réserver l’Identifier zéro sur chaque connexion, l’espace RADIUS ne contenant que 256 valeurs simultanées. Les keepalives TCP ou les battements DTLS peuvent accélérer la détection d’une rupture de transport. Ils restent des contrôles du canal, pas des consultations de la base d’identités.

Deux erreurs de conduite deviennent alors possibles.

La première consiste à basculer trop tôt. Une requête vers un serveur d’origine lent reste sans réponse ; le NAS condamne le proxy entier et envoie tous les domaines vers un secours. Le changement déplace du trafic qui fonctionnait, recrée des connexions et charge un deuxième site. La panne locale devient un événement partagé. RFC 3539 avait déjà identifié cette limite : en présence d’un agent, le client ne dispose pas des paramètres de transport de bout en bout nécessaires pour régler seul un délai de bascule.

La seconde consiste à ne rien déplacer parce que le proxy répond. Chaque nouvelle requête du domaine défaillant revient vers la même route. Le témoin vert est exact ; la décision qu’on lui fait porter ne l’est pas. La preuve manquante doit être liée au domaine : choix de route, remise au prochain saut, réponse du serveur d’origine, résultat du magasin d’identités, décision d’autorisation puis exécution par le NAS.

Protocol-Error conserve la même juridiction. La révision 18 l’emploie pour signaler un paquet indésirable sur le tronçon courant, arrêter sa retransmission et éventuellement permettre un autre acheminement. Cette réponse ne doit pas être propagée. Elle ne raconte pas ce qu’un serveur plus lointain aurait décidé.

Le chiffrement n’étend pas davantage la portée du constat. TLS ou DTLS identifie le pair adjacent et protège le segment. Le projet souligne qu’un intermédiaire peut ensuite relayer le paquet en RADIUS/UDP. Le client initial ne possède pas de mécanisme lui garantissant un transport protégé sur toute la chaîne. La sécurité complète nécessite donc une organisation des intermédiaires, et non une interprétation élargie du premier cadenas.

Les changements de transport rendent visible un autre partage de responsabilités. RADIUS/TCP et RADIUS/TLS s’appuient sur un transport fiable et ne retransmettent pas le paquet RADIUS sur la même connexion. UDP et DTLS doivent le faire au niveau applicatif. Si un proxy reçoit sur un lien non fiable puis émet sur un lien fiable, il absorbe les doublons entrants. Dans le sens inverse, il devient propriétaire des retransmissions vers le lien non fiable. Lorsque la connexion amont ferme ou que le client réutilise un Identifier, le proxy doit interrompre la tentative devenue orpheline.

Il est donc impossible de diagnostiquer proprement avec un simple compteur de délais. Le client peut avoir abandonné tandis que le proxy continue. Le serveur d’origine peut avoir traité une requête dont la réponse tarde. Un seul realm peut bloquer alors que la connexion transporte correctement les autres.

Le cas de la comptabilité montre le risque d’emballement. Le projet préfère un Event-Timestamp immuable, date de l’événement, à la modification répétée de Acct-Delay-Time. Chaque valeur de délai mise à jour fabrique un nouveau paquet décrivant presque le même fait, parfois avec un nouvel Identifier. À la frontière TLS/UDP, chaque paquet peut lancer sa propre série de retransmissions. L’annexe A.2 suit ainsi un événement transformé en trois identités aval, 101, 102 et 103, pendant qu’un serveur surchargé traite déjà la première.

La date d’événement stabilise la déduplication ; elle n’est ni un identifiant universel ni une promesse d’exécution unique. Il faut conserver le lien entre événement, paquet, tronçon, propriétaire de la relance et décision du serveur.

Même un échec d’authentificateur demande une lecture bornée. L’annexe A.1 décrit une réponse tardive à une ancienne requête après réutilisation de l’Identifier. Vérifiée contre la nouvelle requête, elle échoue. Le client doit l’écarter sans fermer la connexion. Une erreur de paquet ne prouve ni la mort de la connexion ni la compromission du pair.

La révision 18 a été déposée le 30 septembre 2026. Elle vise le niveau Proposed Standard, expire le 3 avril 2027 et ne possède pas de numéro RFC. Son remplacement annoncé des RFC expérimentales 6614 et 7360 dépend encore de l’approbation et de la publication. Ces textes n’attestent aucun déploiement, taux de panne ou comportement d’un fournisseur nommé.

La phrase exploitable reste donc courte : tel pair RadSec a répondu, sur telle connexion, à tel instant. Pour parler du service, il faut ajouter le domaine demandé, la route aval, la réponse du serveur ou de son backend, la décision, son application par le NAS et l’effet observé. Un signal commun coordonne les acteurs ; il ne leur cède pas les responsabilités situées au saut suivant.

Sources