Résumé

  • La RFC 4014 permet au serveur d’accès réseau de conserver une sélection bornée d’attributs reçus dans un Access-Accept RADIUS, puis de les joindre à une demande DHCP relayée.
  • Le serveur DHCP se sert de ces attributs pour choisir des paramètres de configuration : l’autorisation RADIUS, le transport par le relais et l’attribution d’adresse restent trois fonctions distinctes.

L’accès était accordé. L’adresse restait à choisir.

Dans un réseau d’entreprise ou un campus, un équipement peut franchir une première porte sans avoir encore tout ce qu’il lui faut pour communiquer. L’authentification 802.1X aboutit. Le commutateur ou le point d’accès autorise la session. Ensuite seulement, le client sollicite DHCP pour obtenir sa configuration IP. À l’instant où l’accès est accepté, une question demeure donc ouverte : quelle configuration le serveur DHCP doit-il proposer à cette session ?

Cette séparation n’est pas une subtilité de vocabulaire. RADIUS sert à authentifier et à renvoyer des attributs d’autorisation. DHCP sélectionne et fournit des paramètres réseau. La RFC 3580 rappelle que 802.1X ne fournit pas lui-même de mécanisme d’attribution d’adresse. Même un attribut comme Framed-Pool n’est utile qu’avec un équipement d’accès qui sait participer à l’attribution IP.

La difficulté venait du partage des rôles. Le serveur RADIUS pouvait être centralisé. Le service DHCP pouvait fonctionner sur une autre machine. Entre les deux, le NAS connaissait la session admise et agissait aussi comme relais DHCP. Sans transmission de contexte, chacun aurait dû reconstituer l’information détenue par l’autre, ou les deux fonctions auraient été réunies de force dans le même appareil.

La RFC 4014 a documenté une troisième voie. Publiée en février 2005 par Ralph Droms et John Schnizlein, elle a permis au NAS de conserver localement les attributs d’un Access-Accept réussi, puis de transmettre une sélection de ces attributs dans un sous-option du relais lorsque la demande DHCP arrivait. La RFC ne transforme pas une décision RADIUS en bail DHCP ; elle aménage le passage entre deux échanges.

Le relais connaissait déjà l’endroit d’où venait la demande

Le cadre de ce passage existait depuis la RFC 3046. Celle-ci a créé l’option Relay Agent Information, souvent appelée Option 82, pour transporter des informations que le relais connaît mieux que le client : l’identifiant du circuit, par exemple, ou celui du modem distant. Le serveur DHCP pouvait s’appuyer sur ces indications pour appliquer une politique d’adresse ou d’autres paramètres.

Le retour était également encadré. Le serveur recopiait l’option de relais dans sa réponse ; le relais la retirait ensuite avant de transmettre la réponse au client. Le client n’avait pas besoin de connaître la topologie d’accès ni les étiquettes internes du réseau.

La RFC 4014 a ajouté le code de sous-option 7, « RADIUS Attributes », à l’intérieur de cette enveloppe. Le NAS pouvait y placer les octets encodés d’attributs issus de l’Access-Accept lorsqu’il relayait plus tard le message DHCP du client. Le serveur DHCP extrayait ces données et pouvait les utiliser pour choisir la configuration. Le relais apportait un contexte ; le serveur conservait la décision de configuration.

Le document n’enfermait pas le mécanisme dans le seul scénario 802.1X. Un relais pouvait transporter des attributs obtenus par d’autres moyens, à condition de respecter la sémantique RADIUS. Mais la portée d’interopérabilité garantie restait celle d’un domaine administratif localisé unique. La RFC ne promettait pas que des domaines indépendants partageraient une interprétation mondiale des attributs.

Une liste pour empêcher le raccourci

Le standard fixait une limite et une obligation minimale. Un message ne pouvait contenir qu’une seule sous-option RADIUS. Lorsque User-Name et Framed-Pool étaient disponibles, le relais devait les inclure ; il pouvait joindre d’autres attributs. Pour éviter que l’allocation DHCP dépende d’un état séparé que seul le serveur RADIUS connaîtrait, la RFC recommandait de s’en tenir à six valeurs : User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool et Framed-IPv6-Pool.

La présence d’un nom de pool ne contraignait pas le serveur DHCP à attribuer une adresse. Celui-ci utilisait le contexte dans le choix des paramètres et devait ignorer les attributs hors de la liste prévue. L’autorisation pouvait orienter une branche de politique ; elle ne remplaçait ni les pools que le serveur administrait ni son contrôle final.

La capacité du champ était finie. La RFC dit que le relais tronque les attributs pour les faire tenir dans la sous-option, sans définir de règle universelle de priorité en cas de troncature. Il serait donc imprudent de conclure qu’un attribut reçu par le NAS a nécessairement atteint le serveur DHCP. La sélection, la taille et l’observation du message comptent.

Le NAS devenait un point de jonction délicat. Il devait conserver la bonne information d’autorisation pour la demande DHCP qui suivait. La RFC définit le transport, mais ne décrit pas toutes les questions d’exploitation : comment associer cet état à une session, l’actualiser après une nouvelle authentification, ou réagir à une modification de politique. Ce sont des vérifications nécessaires en pratique, pas des exigences supplémentaires que le texte prétend imposer.

La confiance fait partie du trajet

Dès que le serveur DHCP choisit des paramètres à partir d’une option fournie par le relais, la confiance envers ce relais devient une pièce du contrôle. La RFC 4014 reprend la confiance relayeur-serveur de la RFC 3046. Elle recommande une protection plus profonde — authentification des options de relais ou IPsec — en complément du filtrage périmétrique qui n’accepte ces options que depuis les relais autorisés.

Le client ne voit normalement pas Option 82, mais cette invisibilité ne rend pas son contenu authentique à elle seule. Le serveur doit savoir qui lui a transmis l’information et quel mécanisme protège le trajet. Une valeur forgée ou périmée pourrait influencer une branche de politique si ces contrôles échouent ; c’est un risque déduit de l’architecture, pas la preuve qu’un réseau particulier a connu une telle panne.

L’histoire de cette RFC est donc aussi celle d’une frontière administrative. Le protocole définit des octets et une liste ; il ne peut pas vérifier que l’état du NAS est à jour, que le relais est digne de confiance ou que le pool choisi convient à la session. Seul le comportement effectif du relais et du serveur DHCP révèle le résultat opérationnel.

Une évolution, deux chemins de transport

En 2023, la RFC 9445 a repris le problème lorsque de nouveaux services ont eu besoin de paramètres DHCP qui ne figuraient pas dans l’ancienne liste figée. Elle met à jour la RFC 4014 en remplaçant cette liste par un registre IANA des attributs RADIUS autorisés dans la sous-option. L’extension demeure encadrée, avec examen expert.

La RFC 9445 définit aussi deux attributs différents qui transportent directement des options DHCP : DHCPv6-Options (245.3) et DHCPv4-Options (245.4). Son exemple de DNS chiffré illustre une configuration de service possible ; il ne mesure pas son adoption. Ces attributs ne sont pas la sous-option 7. Les confondre effacerait l’évolution même que les textes documentent.

Le registre IANA actuel montre ce qui est alloué ou permis. Il ne prouve pas ce que les opérateurs utilisent. L’évolution garde la même question au centre : comment transmettre un contexte d’autorisation vers un service de configuration sans attribuer à l’un le rôle de l’autre ?

Lue à travers la Note 64 de Lu Heng, la RFC 4014 ressemble à une enveloppe commune minimale, à l’intérieur de laquelle un domaine conserve ses choix locaux. La Note 65 rappelle qu’un texte publié ne démontre pas le comportement du code en production. Ces notes sont un regard analytique postérieur, pas la cause ni une source historique de la RFC. Le point de jonction ne devient réel que lorsque le relais et le serveur qui tournent effectivement transportent, vérifient puis appliquent le contexte attendu.

Sources