Résumé

  • Le relais de RFC 6345 n’a pas besoin de conserver un état par client. L’agent d’authentification conserve néanmoins les coordonnées du relais dans la session.
  • La protection de l’authentification ne garantit pas que les échanges arriveront à leur terme. Le transport garde ses risques propres, même sans usurpation réussie.
  • Une économie de mémoire locale ne permet pas, à elle seule, de réduire le budget de configuration, de capacité et de rétablissement du service.

La ligne qui manque dans le devis

La promesse « sans état » décrit souvent un avantage réel, mais elle ne dit pas encore qui devra intervenir un dimanche si un appareil légitime ne parvient plus à rejoindre le réseau. Le composant peut avoir exécuté exactement son rôle. Le service, lui, peut rester indisponible.

Il ne s’agit pas ici d’un devis ni d’un incident observé. C’est un problème de comparaison : comment valoriser la simplicité d’un équipement sans faire disparaître, dans le même calcul, les tâches que cette simplicité laisse ailleurs ? Le relais PANA permet de poser la question avec une précision inhabituelle.

Le relais n’est pas l’agent qui décide de toute l’admission. Il transporte les messages nécessaires à une authentification que les extrémités ne peuvent pas encore échanger par routage IP ordinaire. Le registre officiel de RFC 6345 classe ce texte d’août 2011 comme Proposed Standard. Son cas introductif est celui d’un nouveau nœud IPv6 disposant d’une adresse de portée locale au lien, capable de joindre son parent mais pas directement l’agent plus éloigné.

L’utilité du dispositif est donc très concrète. Il faut permettre la conversation avant que l’accès complet soit disponible. Ajouter un intermédiaire ne constitue pas nécessairement une complication gratuite ; cela peut être précisément ce qui rend l’admission possible. La question économique vient après : le rôle limité du relais a-t-il été confondu avec une responsabilité limitée du système entier ?

Un état évité ici, un contexte conservé là

Dans RFC 6345, le PANA Relay Element, ou PRE, n’a pas à mémoriser un état pour chaque client. Le PANA Authentication Agent, ou PAA, ajoute en revanche à la session l’adresse IP et le port UDP du relais. Il sait ainsi vers quel intermédiaire renvoyer les messages.

Cette information complète les coordonnées du client. Des clients situés derrière des relais différents peuvent présenter la même combinaison d’adresse et de port. Leur contexte de relais aide l’agent à distinguer les échanges initiaux. Une coordonnée isolée ne résume donc pas l’identité opérationnelle de la conversation.

Le dispositif ne crée pas pour autant un annuaire de personnes. Il organise une communication. Compter des coordonnées, des sessions ou des relais comme autant de clients commerciaux serait une autre opération, qui demanderait ses propres règles. La précision technique protège aussi contre une comptabilité trop imaginative.

L’enveloppe PRY transporte deux choses distinctes : le message PANA intérieur, dans Relayed-Message, et les coordonnées du client, dans PaC-Information. Le premier ne contient pas les en-têtes IP et UDP d’origine. Le second fournit les renseignements nécessaires au retour vers le client.

Une correction officielle tranche un détail que la prose initiale avait mal attribué. L’erratum technique 2996, signalé en octobre 2011 puis vérifié en septembre 2012, précise que le port UDP de destination du retour provient de PaC-Information. La référence initiale à Relayed-Message était erronée. La correction ne renforce pas l’authentification ; elle rétablit le bon emplacement de l’information.

Pour l’exploitant, l’intérêt dépasse la coquille. Préserver le message et choisir son destinataire sont deux responsabilités. La réussite de la première ne suffit pas à démontrer la seconde. Une chaîne de traitement peut conserver des octets impeccables tout en utilisant le mauvais contexte de livraison.

L’économie du relais a ainsi une définition limitée. Elle porte sur l’absence nécessaire d’un certain état local, pas sur la suppression de tout travail. Le relais traite toujours des paquets et peut avoir des relations de pairs à configurer. L’agent garde les sessions et les coordonnées supplémentaires. Parler de transfert de toutes les dépenses vers le centre serait aussi inexact que de parler de disparition de toutes les dépenses.

Le transport n’a pas hérité de l’authentification

La séparation entre les couches apparaît également dans la fiabilité. Les champs de session et de séquence de PRY valent zéro, et l’enveloppe elle-même n’est pas retransmise. Si une extrémité retransmet le message PANA intérieur, une nouvelle enveloppe peut le transporter. Le relais ne reproduit pas une seconde fois tout le mécanisme de session.

Le protocole de base, RFC 5191, laisse aux extrémités les vérifications de messages, les sessions et les retransmissions. Il distingue le client, l’agent, une éventuelle infrastructure d’authentification en arrière-plan et le point qui applique les règles d’accès. Une association de sécurité PANA dépend d’une authentification EAP réussie produisant une clé de session maîtresse ; elle n’existe pas simplement parce qu’un message a traversé le relais.

Cela évite deux lectures commodes et fausses. Voir des zéros dans l’enveloppe ne prouve pas l’absence de séquencement intérieur. Voir des vérifications cryptographiques à l’intérieur ne prouve pas que chaque condition du transport est satisfaite. Chaque conclusion a son objet.

La sécurité décrite pour le relais suit cette logique. Un relais malveillant peut perturber l’échange et, dans les circonstances examinées par le texte, modifier les coordonnées de relais enregistrées pour le retour. Il ne peut pas achever l’authentification initiale à la place du client sans posséder ses justificatifs. Après une authentification par une méthode EAP génératrice de clés, les messages intérieurs falsifiés échouent aux contrôles d’intégrité.

Ce résultat est borné. Il reprend le modèle de menace de la spécification, pas une campagne de tests sur des produits actuels. Il ne permet ni de déclarer toutes les implémentations sûres, ni de transformer une perturbation du chemin en preuve de vol d’identité.

Il explique néanmoins une situation opérationnelle importante : la barrière d’admission peut continuer à repousser les usurpations alors que des appareils autorisés ne réussissent plus à entrer. La sécurité et la disponibilité ne sont pas deux versions concurrentes d’un même voyant. Elles décrivent des résultats différents.

Une équipe qui ne traite que les compromissions de justificatifs risque de laisser un défaut de livraison sans propriétaire. À l’inverse, une équipe qui veut rétablir la circulation à tout prix ne devrait pas prendre le silence d’un agent pour une autorisation de contourner l’authentification. Ces situations sont des hypothèses de gestion, non des accusations.

Ce que le mot « facultatif » oblige à décider

Le texte de 2011 rend facultative la protection cryptographique entre PRE et PAA. Il ne rend pas facultative toute réflexion sur les risques résiduels. Il prévoit des mesures physiques ou cryptographiques et le contrôle des pairs légitimes pour réduire les risques que les mécanismes de bout en bout ne suffisent pas à éliminer.

Ce point devrait empêcher un raccourci fréquent dans les projets : déduire d’une option du protocole qu’aucune justification de déploiement n’est nécessaire. Une règle commune peut laisser plusieurs solutions ouvertes. L’organisation qui en choisit une doit encore expliquer les conditions sur lesquelles elle repose.

La discussion historique d’IPsec contient elle-même une distinction utile. La gestion des clés configurée manuellement présente la limite de protection contre le rejeu indiquée par le document ; IKE avec secrets prépartagés constitue une autre possibilité recommandée à prendre en charge. Toutes les utilisations d’un secret prépartagé ne se confondent donc pas. Ce passage n’est pas non plus une prescription de configuration cryptographique pour 2026.

La responsabilité pratique porte sur le maintien des hypothèses. Si la confiance dépend d’une enceinte physique, d’une liste de pairs ou d’un mode de protection, qui remarque qu’un changement rend cette hypothèse caduque ? La réponse ne figure pas automatiquement dans le mot « compatible » imprimé sur un produit.

Il faut aussi respecter les limites fonctionnelles de la spécification. Elle suppose au plus un PRE entre client et agent. La découverte dynamique des PAA par le relais et le relais de messages déjà relayés sortent de son périmètre. Un acheteur ne peut y lire une promesse implicite de chaînes arbitraires, de découverte automatique ou de basculement sans interruption.

Le guide d’orientation ne fait pas la règle d’entrée

RFC 5192 fournit aux clients, par DHCP, une liste ordonnée d’adresses d’agents. Les adresses doivent être essayées dans l’ordre indiqué. Ce mécanisme facilite la recherche du correspondant ; il ne décide pas si l’authentification PANA est requise.

Le texte interdit précisément d’employer ces options pour négocier cette obligation. Leur présence ou leur absence ne doit pas conduire à choisir un mécanisme plus faible, voire aucune sécurité. Celui qui influence l’information de découverte ne doit pas recevoir, par cette seule influence, le pouvoir de définir la politique d’admission.

La même discipline vaut pour les noms et les adresses observés. Lorsqu’une solution de liaison de canal utilise l’adresse du PAA, elle doit tenir compte du fait que le client voit l’adresse du PRE tandis que le serveur d’authentification voit celle du PAA. RFC 6345 signale qu’un agent non relayé, doté de plusieurs interfaces, peut déjà présenter une différence comparable. La divergence demande une interprétation explicite ; elle n’est pas un verdict automatique de compromission.

Le relais possède aussi une descendance documentaire précise. Le profil RPL pour les bâtiments et l’habitat de RFC 7733, publié en février 2016, inscrit PANA et EAP-TLS dans sa pile d’authentification et confie le rôle PRE au parent, sauf lorsque celui-ci est le serveur d’authentification. Cette prescription historique ne mesure ni l’adoption actuelle ni la fiabilité d’un déploiement particulier.

La simplicité a besoin d’une comptabilité complète

Dans son texte sur une spécification initiale minimale, Lu Heng défend des règles communes étroites et vérifiables. Il reconnaît aussi que le modèle est moins directement applicable à certains cas, notamment au domaine administratif unique. Il serait donc abusif d’en tirer un argument contre toute fonction légitime d’admission.

L’application utile est plus modeste : définir ce que fait l’intermédiaire, puis identifier ce que sa limitation laisse aux autres. Son analyse du découplage entre pouvoir et responsabilité éclaire une autre question, celle du propriétaire des conséquences. Ces essais ne portent pas sur PANA. Le rapprochement relève ici de l’analyse de Daniel Kade.

La centralisation d’une partie du travail peut être économiquement justifiée. Des relais légers peuvent être un bon choix. Pour le démontrer, il faudrait toutefois comparer les capacités, les configurations, les moyens de diagnostic et les contraintes de rétablissement de solutions complètes. Les sources utilisées ici n’apportent ni devis, ni mesures de charge, ni historique d’incidents permettant de déclarer un vainqueur.

Elles permettent de refuser une fausse économie : retrancher du projet une obligation au motif qu’elle n’apparaît pas dans la mémoire d’un composant. Un relais sans état par client n’est pas un système sans mémoire. C’est une manière de répartir la mémoire et le travail, qui mérite d’être évaluée comme telle.