Résumé

  • RFC 3456 faisait passer DHCPv4 dans une association IPsec temporaire afin de conserver baux, options, renouvellement et bascule dans le système de configuration existant plutôt que de les reconstruire dans IKE.
  • Le DHCPACK et l’adresse interne louée étaient des preuves de configuration, non des titres d’accès : l’hôte pouvait choisir sa propre adresse et le segment relais-serveur restait hors de la protection IPsec sans authentification distincte.

Deux adresses, deux réalités

Publié en janvier 2003, RFC 3456 décrit un hôte possédant une adresse externe pour Internet et une adresse virtuelle interne pour l’intranet. La première termine le tunnel IPsec au niveau de la passerelle de sécurité ; la seconde fait apparaître l’hôte derrière cette passerelle. Ce dédoublement organise le routage, il ne fusionne ni identité ni autorité.

Le texte, la notice RFC Editor, le Datatracker, son historique, ses références, ses citations ultérieures et la recherche d’errata établissent le dossier normatif. Ils ne prouvent ni l’autorisation d’un utilisateur ni la réussite d’une application.

L’hôte crée d’abord une association IKE, puis une SA en mode tunnel, brève et réservée à DHCP. Une fois l’adresse et les options reçues, il peut négocier une SA VPN plus générale en reprenant l’adresse attribuée dans l’identité Quick Mode. Canal provisoire, bail et tunnel de données sont donc trois états distincts.

Réutiliser DHCP bornait IKE

RFC 3457 formulait les exigences d’accès distant. RFC 2131 et les options de RFC 2132 offraient déjà baux, pools, renouvellements et paramètres ; RFC 3442 ajoutait des routes sans classe. RFC 3456 refusait donc de transformer IKE en second gestionnaire d’adresses. Dupliquer peu à peu options, authentification et bascule aurait agrandi le périmètre sensible de l’échange de clés.

L’interface virtuelle recevait le type matériel 31. Son identifiant client devait être unique dans le sous-réseau virtuel et, si possible, persistant. Le registre IANA conserve cette attribution. Ces valeurs servent à corréler un bail ; elles n’attestent ni personne ni droit.

Le relais marquait une couture de sécurité

La passerelle agissait généralement comme relais DHCP. Elle inscrivait giaddr ou l’information de relais définie par RFC 3046, éventuellement avec le port virtuel du tunnel dans l’identifiant de circuit. Elle pouvait lire yiaddr dans le DHCPACK et installer la route correspondante.

IPsec ne protégeait pourtant que le trajet hôte-passerelle. Le trajet passerelle-serveur DHCP exigeait une protection propre, par exemple l’authentification de RFC 3118. Une enveloppe sûre sur un tronçon ne se propage pas par transitivité.

Surtout, un hôte peut fixer lui-même son adresse IP. Même un DHCP authentifié ne suffit donc pas à contrôler l’accès. RFC 3456 impose de ne pas faire dépendre la sécurité de l’adresse attribuée et renvoie vers des filtres par tunnel ou des sélecteurs Quick Mode. L’architecture IPsec de RFC 2401 et IKE dans RFC 2409 donnent le contexte de politique et de négociation, sans prouver l’installation correcte d’une règle donnée.

Un ACK n’était qu’un reçu

Un DHCPACK prouve une réponse de configuration. L’identifiant de circuit indique le chemin de retour visé. Une route installée documente une décision locale. Un sélecteur documente une liaison de politique. Seul le trafic observé renseigne sur l’étape suivante. Les confondre efface précisément la frontière que le RFC rendait visible.

La discipline des couches de réalité de Heng Lu aide à nommer ces reçus. La primauté du code exécuté demande d’examiner routes, sélecteurs et paquets réellement présents. La spécification initiale minimale éclaire le choix de réutiliser DHCP. Ce sont des lectures éditoriales ultérieures, non une preuve des intentions privées des auteurs.

RFC 3456 ne diminuait pas DHCP en refusant de faire du bail une autorisation. Il lui rendait son autorité exacte : configurer une présence virtuelle. La passerelle devait encore décider ce que cette présence pouvait faire.

Sources