Résumé

  • RFC 3993 permet à un relais DHCP d’ajouter un Subscriber-ID attribué par le fournisseur et conçu pour rester stable lorsque le client emprunte une autre voie d’accès physique.
  • La norme transporte la valeur, mais laisse son attribution et son interprétation à la configuration du fournisseur ; utile à la continuité des politiques, le même identifiant peut aussi faciliter des corrélations dans le temps.

Changer de circuit sans changer de dossier

Un serveur DHCP doit parfois décider pour un client qu’il ne voit pas directement. Dans un réseau d’accès étendu, le relais reçoit la diffusion locale du client et la transmet à un serveur central. Il peut y ajouter des informations sur le point d’entrée dans le réseau du fournisseur. Le serveur peut alors choisir une adresse et des paramètres sans installer un serveur local sur chaque segment.

Le relais devient ainsi témoin autant que messager. Publiée en 2001, la RFC 3046 lui a fourni un conteneur d’informations. Ses premières sous-options comprennent Circuit-ID et Remote-ID : l’une peut décrire le circuit entrant, l’autre un modem distant. Ces valeurs aident à distinguer lignes et équipements, mais elles suivent la topologie. Si le client change de voie, l’identifiant lié au circuit peut changer alors que le fournisseur souhaite garder le même traitement administratif.

La RFC 3993, publiée en 2005, ajoute Subscriber-ID au conteneur existant. La valeur peut être indépendante de la structure physique de l’accès et rester stable lors d’un changement de voie ou d’une évolution du réseau. Le fournisseur peut l’utiliser avec les identifiants du circuit et de l’équipement, au lieu de demander à un seul champ de remplir ces deux fonctions.

Un format de transport, pas une définition

La retenue de la spécification est centrale. Subscriber-ID est une chaîne NVT ASCII portée par la sous-option 6 et précédée d’un champ de longueur d’un octet. Elle comporte au moins un octet et ne se termine pas par NUL. Ces règles indiquent où trouver la valeur dans le message. Elles ne disent pas ce que signifient ses caractères.

La RFC précise que ce sens dépend du fournisseur. Celui-ci attribue l’identifiant ; les mécanismes d’attribution et de configuration sont hors du périmètre du mémo. Le relais peut être configuré pour l’inclure. Un serveur qui prend en charge cette sous-option peut l’utiliser avec les autres données du relais et du client pour choisir une adresse ou d’autres paramètres. Ni sa présence ni son emploi ne sont obligatoires.

Cette séparation rend l’étiquette transportable sans la rendre universelle. Un fournisseur peut relier une valeur à un compte de facturation ; un autre, à un profil de service. La RFC n’impose aucun de ces modèles, et une même chaîne n’a pas à désigner la même chose dans un autre domaine administratif. Le paquet DHCP ne prouve donc pas, à lui seul, l’identité d’une personne, d’un appareil, d’un contrat ou d’un droit d’accès. Ces liens résident dans les dossiers et les choix opérationnels du fournisseur.

L’ajout modifie modestement le protocole, mais déplace une frontière de contrôle importante. Le client ne déclare pas lui-même son identité stable au moyen de ce champ. C’est un relais exploité par le fournisseur qui l’insère ; le service central peut ensuite en déduire une adresse ou une configuration. L’autorité de la valeur vient de la relation de confiance et du rapprochement tenu par le fournisseur, pas de la forme de la chaîne.

La confiance rend le raccourci décisif

L’option d’information du relais suppose une relation de confiance entre celui-ci et le serveur. RFC 3993 avertit que des données frauduleuses peuvent contribuer à un vol de service, à l’épuisement d’adresses rares, à un déni de service ou à une configuration inadaptée. Selon RFC 3046, le serveur qui reconnaît l’option la renvoie au relais, lequel la retire avant de répondre au client. Ce circuit de contrôle du fournisseur reste distinct d’un certificat d’identité présenté au client.

Cette frontière peut être mieux protégée. RFC 3993 cite les défenses de périmètre et recommande une protection plus profonde au moyen du sous-option d’authentification du relais ou d’IPsec. RFC 4030 décrit cette authentification et ses procédures de détection des rejeux. Elle peut aider à établir que les informations proviennent d’un chemin accepté ; elle ne définit toujours pas le sens propre au fournisseur que RFC 3993 laisse ailleurs.

La stabilité comporte aussi un coût de confidentialité. Un identifiant de circuit peut révéler le point d’entrée d’un message ; un identifiant d’abonné peut suivre le même sujet d’un circuit à l’autre. RFC 3993 prévient que la valeur peut permettre d’identifier un hôte ou un utilisateur si elle est exposée. RFC 7819 traite Subscriber-ID comme un identifiant potentiellement durable, capable de relier des activités au fil du temps. Le gain qui réduit les reconfigurations peut prolonger la période pendant laquelle des dossiers sont rapprochables.

RFC 4580 transpose une idée similaire à DHCPv6. Elle laisse également l’attribution et le sens hors du texte et réserve l’échange prévu à un seul domaine administratif. Cette parenté confirme un motif de conception, pas l’équivalence automatique entre un identifiant DHCPv4 et un identifiant DHCPv6.

Les RFC établissent le mécanisme et les risques qu’elles décrivent. Elles ne mesurent ni son adoption, ni un déménagement de client réussi, ni les contrôles de confidentialité d’un fournisseur particulier. L’histoire tient donc à cette frontière : DHCP pouvait transporter l’étiquette durable d’un fournisseur au-delà d’une topologie changeante, tandis que ce fournisseur restait responsable de son sens et des décisions qui en découlaient.

Sources