Résumé

  • Une Disconnect-Request ou une CoA-Request authentifiée peut correspondre à zéro, une ou plusieurs sessions. Les attributs de recherche définissent donc directement le périmètre de l’action.
  • L’ACK affirme que le NAS a réussi la transition demandée pour toutes les sessions retenues. Il ne certifie pas, à la place d’autres systèmes, la convergence comptable, la politique répliquée ni le trafic réellement vécu par l’abonné.

Le danger n’est pas toujours une commande falsifiée. Il peut être une commande parfaitement authentifiée, adressée au bon NAS, qui exprime un ensemble plus large que celui imaginé par l’opérateur. RFC 5176 oblige à regarder cet ensemble avant de parler de réussite.

Les attributs tels que User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id ou Chargeable-User-Identity peuvent contribuer à retrouver le contexte. Aucun principe général du protocole ne transforme automatiquement cette combinaison en identifiant unique. S’il n’existe aucune correspondance, le NAS répond par un NAK. S’il en existe plusieurs, la requête vise toutes les sessions correspondantes.

L’atomicité commence après la sélection

Pour une modification d’autorisation, tous les changements demandés doivent réussir sur toutes les sessions sélectionnées. Alors seulement le NAS émet un CoA-ACK. Si un attribut n’est pas pris en charge, si une valeur est invalide ou si une seule session ne peut accepter la transition, il renvoie un CoA-NAK et ne modifie rien. Une déconnexion suit la même règle de tout ou rien.

Cette discipline évite un état fractionné dans lequel deux sessions seraient coupées et une troisième laissée active. Mais elle ne réduit pas le groupe. Si un nom partagé retrouve trois connexions alors que l’opérateur n’en visait qu’une, une exécution atomique peut réaliser exactement la mauvaise portée, avec une cohérence irréprochable.

Le NAS qui ne sait pas traiter une sélection multiple doit répondre avec Error-Cause 508. Cette réponse n’est pas un détail d’implémentation : elle signale que le cardinal de l’ensemble a dépassé la capacité de contrôle. Une plateforme de supervision devrait donc enregistrer le nombre de correspondances avant le code final, et non découvrir la multiplicité à travers un échec agrégé.

L’ACK dit quelque chose de précis

Réduire l’ACK à « paquet reçu » serait une autre erreur. Un Disconnect-ACK affirme que le contexte associé a été supprimé et que les sessions retenues ne sont plus connectées. Un CoA-ACK affirme que les changements d’autorisation ont réussi. Le NAS engage ainsi son observation locale sur une transition définie.

Il ne peut cependant pas parler pour tous les plans qui l’entourent. Le flux comptable peut être différé. Une passerelle en aval peut conserver un état. Un cache de politique peut converger plus tard. Le trafic mesuré depuis un autre point peut raconter une histoire différente. Il faut préserver la force de l’ACK à son niveau sans lui prêter une vue qu’il ne possède pas.

Le dossier probant relie donc la demande exacte, le canal protégé, la règle d’autorisation, la liste des sessions trouvées, la réponse complète, l’état du NAS, les enregistrements comptables et la mesure du service. Il ne choisit pas entre le protocole et la réalité opérationnelle ; il exige que les deux restent comparables.

Un NAK peut ouvrir la suite

Le cas Authorize Only révèle la pauvreté d’un tableau rouge-vert. Si le NAS accepte de lancer une nouvelle décision d’autorisation, il ne doit jamais envoyer CoA-ACK. Il répond CoA-NAK avec Error-Cause 507, Request Initiated, puis émet un Access-Request. L’Access-Accept ou l’Access-Reject ultérieur fournit la décision finale.

Le NAK signifie ici que la demande CoA ne constitue pas elle-même la nouvelle autorisation, tout en attestant que le mécanisme suivant a commencé. Le classer comme échec pur est faux. Le classer comme succès final l’est aussi. Il faut suivre la transition vers le second échange.

Les autres causes gardent la même nécessité de précision : contexte introuvable, action administrativement interdite, requête non routable par le proxy, ressources indisponibles, attribut non pris en charge. La valeur explique où la chaîne s’est arrêtée. Les errata vérifiés rappellent en outre que des causes de succès peuvent apparaître dans d’autres réponses et que l’ACK peut lui aussi porter Error-Cause.

Le transport ne décide pas le mandat

Dans le modèle UDP historique, l’adresse source choisit le secret partagé et la construction RADIUS fondée sur MD5 protège la requête. Event-Timestamp, l’identité des retransmissions et la détection des doublons traitent séparément la fraîcheur. RFC 5176 insiste pourtant sur une autre frontière : un client authentifié n’est pas nécessairement autorisé à modifier tous les abonnés d’un NAS partagé.

RFC 9765 modernise ce plan pour RADIUS/1.1 sur TLS ou DTLS négocié. Le canal remplace alors l’authentification historique du paquet et Message-Authenticator n’est pas envoyé. La cryptographie change ; la question de mandat demeure. Quel client peut agir sur quel domaine et quelle session ?

Le proxy ajoute une étape. RFC 8559 définit Operator-Name et Operator-NAS-Identifier afin de reconstruire le chemin vers le NAS d’origine. Cet identifiant opaque aide à trouver l’équipement. Il ne prouve pas l’unicité de la session à l’intérieur de cet équipement.

Le protocole devient fiable lorsque chaque acteur limite son témoignage. Le client atteste son intention. Le proxy atteste son routage. Le NAS atteste la transition qu’il a exécutée. La comptabilité et le trafic attestent leurs propres résultats. La gouvernance échoue lorsqu’une interface transforme ces quatre réalités en un seul voyant.

Sources