Résumé

  • Introduit en 2001, FORCERENEW invite un client déjà configuré à reprendre la procédure DHCP normale. Le serveur avance le moment de la demande ; la notification ne contient pas à elle seule une nouvelle attribution accomplie.
  • L'authentification était obligatoire, mais la distribution préalable des secrets compliquait l'adoption selon les auteurs de l'extension de 2012. Leur mécanisme de nonce a réduit ce coût en confiant un secret au client pendant un échange de configuration.
  • Cette économie repose sur une limite : le secret protège les rappels ultérieurs contre un adversaire extérieur qui n'a pas vu l'échange initial. Elle ne transforme ni cet échange ni le réseau local en source indépendante de confiance.

La ligne qui manque au compte rendu

Dans le suivi d'une opération réseau, « notification envoyée » est une information utile. Elle devient trompeuse lorsqu'elle est lue comme « configuration changée ». Entre les deux, un terminal doit recevoir, vérifier, répondre, puis traiter les paramètres effectivement proposés. Chacune de ces étapes peut manquer alors que la première est parfaitement documentée.

Cette distinction est inscrite dans FORCERENEW, l'extension de DHCP publiée en décembre 2001 dans la RFC 3203. Le serveur envoie un message unicast à un client déjà configuré. Celui-ci passe dans l'état de renouvellement et transmet une demande DHCPREQUEST. Le serveur a donc obtenu une nouvelle question, pas encore une nouvelle configuration.

La nuance n'est pas seulement sémantique. Un serveur peut savoir qu'un paramètre devrait changer alors que le client utilise encore sans difficulté les valeurs reçues auparavant. Attendre sa prochaine démarche peut être gênant pour l'exploitation. FORCERENEW permet de réduire cette attente, tout en conservant le chemin ordinaire par lequel le client reçoit une réponse.

Le nom du message suggère une force immédiate. Sa procédure décrit au contraire une action indirecte : faire revenir le client dans un échange dont le résultat reste à établir.

Une initiative nouvelle dans des états anciens

La RFC 2131, publiée en mars 1997, organisait déjà le renouvellement des baux. Elle autorisait aussi le client à tenter un renouvellement avant T1. L'innovation de 2001 n'est donc pas la possibilité abstraite d'agir plus tôt. Elle consiste à laisser le serveur prendre l'initiative de ce retour.

Les auteurs de FORCERENEW soulignaient qu'aucun nouvel état client n'était nécessaire. L'extension ajoutait une entrée dans un mécanisme connu, plutôt qu'une seconde manière de configurer la machine. Cela réduisait la surface de changement, sans dispenser les implémentations de reconnaître le nouveau message.

Pour remplacer l'adresse, le parcours décrit dans la RFC 3203 va plus loin. Le serveur répond à la demande de renouvellement par DHCPNAK ; le client revient à l'initialisation et diffuse DHCPDISCOVER ; une offre peut alors lui proposer une autre adresse. FORCERENEW n'est ni ce refus, ni cette offre, ni la confirmation finale. Un renouvellement peut également conserver l'adresse existante.

Le cas d'une adresse manuelle rend la séparation particulièrement nette. Un hôte peut ne demander à DHCP que d'autres paramètres, au moyen de DHCPINFORM. Après un rappel, il doit envoyer un nouvel INFORM. L'extension ne doit pas écraser les réglages manuels. Le pouvoir d'obtenir une réponse n'élargit donc pas automatiquement le périmètre confié au serveur.

La grammaire du paquet reste elle aussi familière. La RFC 2132 définit l'option 53 pour le type de message DHCP ; FORCERENEW y reçoit la valeur 9. Il ne s'agit pas d'un nouveau port, ni du numéro de l'option d'authentification. Un petit ajout au vocabulaire commun peut avoir une conséquence importante sur le calendrier des interactions.

Le silence ne désigne pas son auteur

Si aucune demande ne suit la notification, le serveur peut réessayer. La RFC 3203 prévoit un recul exponentiel entre les envois et un nombre limité de tentatives. Le délai initial dépend des conditions du réseau ; le document ne prescrit pas un chiffre universel.

Ces tentatives ne produisent pas, à elles seules, un diagnostic. Un message perdu, un client qui ne le traite pas ou un échec de vérification peuvent tous laisser le serveur sans la réponse attendue. Compter les répétitions permet de voir une difficulté, non d'affirmer quelle étape a échoué. Le chemin normal repose sur l'unicast ; la RFC demande de rejeter silencieusement un FORCERENEW reçu en multicast.

Les usages proposés étaient concrets : évolution des services d'une passerelle domestique, choix de services dans un réseau hôtelier, changement de numérotation sous contrôle étroit. Ces exemples décrivent l'ambition de la spécification, pas une enquête sur les déploiements. La même RFC avertit que modifier l'adresse ou les paramètres locaux peut interrompre les sessions actives.

Le serveur gagne ainsi de la réactivité, mais pas un certificat d'innocuité. Le fait qu'une notification soit admissible ne dit pas que le changement demandé arrive à un moment acceptable pour les applications.

Choisir l'heure d'une demande est déjà un pouvoir

Le danger ne commence pas nécessairement avec une fausse adresse. Pouvoir amener un client à solliciter sa configuration à un instant choisi constitue déjà une prise sur son comportement. C'est pourquoi la RFC 3203 exige l'authentification de FORCERENEW et le rejet des notifications qui échouent à ce contrôle.

Elle s'appuie sur la RFC 3118, publiée en juin 2001. Ce document distingue notamment un jeton de configuration transmis en clair, dont la protection est faible, d'une authentification différée fondée sur un secret partagé. Le premier ne fournit pas l'authentification du message entier. Les appeler indistinctement « authentification DHCP » ferait disparaître une différence essentielle.

Le mécanisme différé suppose que le secret a été distribué hors de l'échange DHCP. Pour authentifier individuellement les clients, il faut gérer les relations de clés correspondantes. Avant de pouvoir rappeler simplement un parc de machines, l'exploitant doit donc résoudre un problème d'approvisionnement en secrets.

En août 2012, la RFC 6704 décrit cette exigence comme plus contraignante que nécessaire pour le cas considéré et comme un frein à l'adoption de FORCERENEW. Il s'agit du constat formulé par ses auteurs à cette date, non d'une mesure de l'usage actuel. Leur réponse consiste à protéger un déclencheur précis sans exiger cette distribution préalable.

Un secret confié par la conversation qu'il prolongera

L'idée reprend le mécanisme historique Reconfigure Key de DHCPv6, décrit dans la RFC 3315 de juillet 2003. Cette filiation porte sur une méthode de protection du rappel. Elle ne signifie pas que DHCPv4 adopte l'ensemble du protocole IPv6, ni que cette ancienne RFC constitue la référence actuelle complète pour DHCPv6.

Le nouveau mode n'est utilisé que si les parties n'emploient pas déjà l'authentification précédente et ont négocié l'usage du nonce. Le client annonce sa capacité dans DISCOVER et REQUEST ; le serveur indique son choix dans OFFER. Cette annonce ne constitue pas une signature du client. Celui-ci ne doit pas envoyer lui-même l'option d'authentification portant ce protocole de nonce.

Le serveur crée, lorsque la procédure le demande, une valeur aléatoire ou pseudo-aléatoire forte de 128 bits. Il la remet au client dans un ACK au cours de l'échange REQUEST–ACK. Chacun conserve cette valeur. Lors d'un FORCERENEW ultérieur, le serveur envoie un code d'authentification calculé avec elle comme clé, et non le secret une seconde fois.

L'économie est facile à identifier : la relation DHCP fournit elle-même le matériau nécessaire à ses futurs rappels. Il n'est plus nécessaire de préparer ce secret par un canal distinct. Mais l'origine de la confiance n'a pas disparu ; elle s'est concentrée dans l'échange qui remet la première valeur.

Le protocole conserve des conditions d'entrée. Un client qui n'a pas annoncé la capacité ne doit pas recevoir de force l'option correspondante dans son ACK. Si l'OFFER initial a annoncé le mécanisme mais que l'ACK qui suit ne comporte pas l'information valide attendue, le client doit rejeter cet ACK et revenir à l'initialisation. Ce contrôle vérifie la cohérence de la négociation, pas l'identité du premier serveur au moyen d'une autorité extérieure.

Le nonce n'est pas un ticket à usage unique

La valeur peut servir à plusieurs rappels. Il ne faut pas déduire du mot nonce qu'elle disparaît après chaque emploi. La prose normative de la RFC 6704 demande de ne pas répéter le nonce dans un ACK de renouvellement, sauf si une nouvelle valeur a été créée. Le schéma qui en dessine une nouvelle après un renouvellement n'impose pas une rotation à chaque échange.

Lorsqu'un autre serveur prend le relais pendant le rebinding, il doit en revanche créer son propre nonce. La continuité dépend donc de l'état détenu par les deux participants et de la manière dont cet état a été acquis. Une option d'authentification visible dans un paquet ne suffit pas à prouver que cette continuité a été maintenue.

Le mécanisme décrit historiquement utilise HMAC-MD5. C'est un code d'authentification, pas un chiffrement de la conversation ni une recommandation cryptographique contemporaine. Il faut aussi contrôler la fraîcheur. L'erratum vérifié 3474 a précisé en 2013 que le compteur de détection des rejeux devait augmenter strictement : une valeur égale à la précédente ne devient pas nouvelle parce que son authentification reste correcte.

Cette distinction explique pourquoi le secret et l'historique de réception jouent des rôles complémentaires. Reconnaître un message produit avec la bonne clé n'autorise pas à exécuter indéfiniment une ancienne demande.

Une frontière de menace, pas une confiance universelle

La RFC 6704 vise l'adversaire extérieur qui ne peut pas observer les échanges normaux du client et du serveur. Sans accès au nonce, il ne peut pas fabriquer le rappel authentifié qui ferait renouveler le client à l'instant de son choix. Le mécanisme répond à cette asymétrie précise.

Un observateur capable d'intercepter la remise initiale du nonce change la situation. La protection ne lui oppose pas une racine de confiance indépendante. Un acteur présent sur le lien local peut déjà observer les demandes normales. Il serait donc abusif de conclure que tous les messages DHCP sont désormais authentifiés, que tout serveur local est légitime ou que tout paramètre proposé est sûr.

Même un message rejeté coûte du calcul. L'authentification n'efface pas le risque de saturation par de nombreuses notifications invalides. Les textes décrivent des propriétés et des limites de conception ; ils ne constituent pas un relevé d'attaques constatées ou une mesure de leur fréquence.

Le registre IANA des paramètres BOOTP et DHCP distingue le type de message 9, l'option d'authentification 90 et l'option de capacité 145. Ces attributions rendent les messages interprétables. Elles ne prouvent ni l'implémentation, ni la négociation, ni l'acceptation d'une modification particulière.

L'intérêt historique de FORCERENEW tient finalement à la modestie de son effet immédiat. Le serveur peut demander au client de revenir. Il doit encore attendre sa question, produire une réponse appropriée et constater ce qui en résulte. Le nonce protège cette invitation dans un périmètre choisi ; il ne remplit pas les lignes manquantes du compte rendu de maintenance.