Resumen

  • RFC 3456 hizo circular DHCPv4 por una asociación IPsec temporal para conservar arrendamientos, opciones, reconfiguración y tolerancia a fallos en el sistema existente, sin duplicarlos dentro de IKE.
  • El DHCPACK y la dirección interna arrendada eran recibos de configuración, no credenciales de acceso: el host podía escoger otra dirección y el tramo entre relé y servidor no quedaba protegido por IPsec sin autenticación adicional.

Dos direcciones no eran una sola identidad

Publicado en enero de 2003, RFC 3456 planteó un host con una dirección externa para Internet y otra interna para una interfaz virtual. La primera terminaba el túnel IPsec en la pasarela; la segunda hacía visible al host dentro de la red corporativa. Eran espacios y pruebas diferentes.

El texto, la ficha del RFC Editor, el Datatracker, su historial, las referencias, las citas posteriores y los errata fijan el expediente normativo. No demuestran la autorización de un usuario ni la llegada a una aplicación.

Primero se creaba una asociación IKE. Después, una SA de modo túnel breve y exclusiva para DHCP transportaba DHCPDISCOVER o DHCPREQUEST. Tras recibir dirección y opciones, el host podía negociar una SA VPN más amplia usando la dirección nueva en la identidad de Quick Mode. Canal inicial, arrendamiento y túnel de datos eran estados separados.

Reutilizar DHCP mantuvo acotado a IKE

RFC 3457 recogía necesidades de acceso remoto. RFC 2131 y las opciones de RFC 2132 ya gestionaban pools, renovaciones y parámetros; RFC 3442 permitía entregar rutas sin clase. RFC 3456 evitó construir dentro de IKE otro sistema de configuración que, con el tiempo, tendría que duplicar arrendamientos, autenticación y conmutación por fallo.

La interfaz virtual usaba el tipo de hardware 31. El identificador de cliente debía ser único en la subred virtual y preferiblemente persistente. El registro IANA conserva la asignación. Esos valores enlazaban transacciones; no probaban una persona ni un derecho.

El relé abría una segunda jurisdicción

La pasarela solía actuar como relé DHCP. Podía escribir giaddr o la información de RFC 3046, incluido un identificador de circuito que señalara el puerto virtual del túnel. Al leer yiaddr en DHCPACK podía instalar una ruta de retorno.

Pero IPsec protegía los paquetes solo entre host y pasarela. El tramo desde la pasarela al servidor DHCP necesitaba su propia defensa, por ejemplo RFC 3118. La integridad de un segmento no se heredaba en el siguiente.

Además, un host remoto siempre podía fijar su propia dirección IP. Ni siquiera DHCP autenticado servía como control de acceso. Por eso RFC 3456 prohibía depender de la dirección asignada para la seguridad y pedía filtros por túnel o selectores de Quick Mode. RFC 2401 y RFC 2409 explican el marco contemporáneo de política y negociación, no prueban que una instalación concreta aplicara bien sus reglas.

Un ACK ocupaba un solo eslabón

DHCPACK demostraba una respuesta de configuración. El circuito del relé marcaba el regreso previsto. Una ruta instalada registraba una decisión local. Un selector vinculaba política y túnel. El tráfico observado respondía a una pregunta posterior. Sustituir toda la cadena por la dirección borraba la causa real del acceso.

La disciplina de capas de realidad de Heng Lu ayuda a separar esos recibos. La primacía del código en ejecución exige mirar rutas, selectores y paquetes efectivos. La especificación inicial mínima aclara el valor de reutilizar DHCP. Son lentes editoriales posteriores, no evidencia de la intención privada de los autores.

RFC 3456 no debilitó DHCP al negarse a llamar autorización al arrendamiento. Precisó su autoridad: configurar una presencia virtual. La pasarela todavía debía decidir qué podía hacer esa presencia.

Fuentes