Resumen

  • FORCERENEW, definido en 2001, permite que el servidor haga volver al cliente al procedimiento normal de renovación. El aviso no es una nueva dirección, una revocación directa ni la confirmación de un cambio terminado.
  • La extensión de 2012 introdujo un nonce entregado durante la configuración para autenticar avisos posteriores, evitando la distribución previa de ese secreto por otra vía.
  • La protección se diseñó frente a un atacante externo que no observa los intercambios habituales. No autentica desde una raíz independiente la primera entrega del secreto, ni elimina los riesgos del enlace local o de una reconfiguración inoportuna.

Dos decisiones que no vencen a la vez

El cliente conserva una configuración que aún puede utilizar. El administrador, en cambio, quiere modificar un parámetro. No hay contradicción: la vigencia de una concesión y la conveniencia de una modificación responden a preguntas distintas. El problema aparece cuando el segundo necesita que el primero vuelva a consultar antes de que lo haga por iniciativa propia.

DHCP ya disponía de procedimientos para renovar. El RFC 2131, de marzo de 1997, incluso permitía que un cliente lo intentara antes de T1. Por tanto, la historia de FORCERENEW no comienza con la invención de la renovación anticipada. Comienza con un cambio en quién puede promoverla.

El RFC 3203, publicado en diciembre de 2001, concedió esa iniciativa al servidor. Su mensaje unicast hace que el cliente entre en renovación y envíe un DHCPREQUEST normal. La dirección del siguiente paquete importa: tras la llamada del servidor, la petición vuelve a salir del cliente.

Así se añadía una ocasión para conversar, no un procedimiento paralelo que sustituyera toda la configuración. Los autores destacaban que no era necesario introducir nuevos estados en el cliente. El coste de la extensión se contenía reutilizando lo que ya existía, aunque reconocer el nuevo mensaje seguía exigiendo soporte.

La notificación no lleva el resultado incorporado

Cuando el servidor quiere cambiar la dirección, el recorrido descrito por el RFC 3203 incluye pasos posteriores. Responde a la solicitud con DHCPNAK; el cliente regresa al estado inicial y emite DHCPDISCOVER; el servidor puede ofrecer entonces otra dirección mediante DHCPOFFER. No ocurre todo dentro de FORCERENEW.

Esta secuencia impide tratar el aviso como una revocación consumada. También impide suponer que cada renovación cambia de dirección. Una nueva consulta puede terminar manteniendo la anterior o actualizando otros parámetros. Solo las respuestas y el estado resultante permiten saberlo.

Hay un caso todavía más claro. Un equipo puede tener una dirección configurada manualmente y utilizar DHCPINFORM para obtener otra información. Ante el aviso, debe enviar otro INFORM. La extensión se limita a los parámetros configurables mediante DHCP y no debe sobrescribir los ajustes manuales. La capacidad de llamar al cliente no absorbe todas las decisiones que antes quedaban fuera del servidor.

El nuevo nombre cabe en una estructura antigua. El RFC 2132 define la opción 53, que identifica el tipo de mensaje DHCP; FORCERENEW añadió el valor 9 en ese espacio. No se trata de un puerto ni de la opción de autenticación. Un número permite reconocer una petición de interacción, pero no demuestra que la interacción haya concluido.

El precio de no esperar

El documento de 2001 proponía usos como cambios de servicio en pasarelas domésticas, selección de servicios en redes de hoteles y renumeración de subredes bajo condiciones estrictamente controladas. Son ejemplos de diseño, no una lista de despliegues comprobados ni una medida de adopción.

La advertencia operativa acompañaba a la ventaja: cambiar la dirección o los parámetros locales podía interrumpir sesiones activas. El protocolo no ofrecía continuidad automática a las aplicaciones. El administrador obtenía una manera de reducir la espera, pero debía decidir si el beneficio justificaba interrumpir a clientes que todavía estaban funcionando.

Tampoco podía garantizar que todos respondieran. Si no llegaba el DHCPREQUEST esperado, el servidor debía reintentar con espera exponencial y limitar el número de retransmisiones. El intervalo inicial se elegía según las condiciones de la red, sin una cifra universal en la especificación. El camino previsto era unicast; un FORCERENEW recibido por multicast debía descartarse silenciosamente.

La ausencia de respuesta es un dato incompleto. Puede requerir investigar entrega, estado del cliente, capacidad o rechazo de la notificación. Reenviar permite intentar recuperar la interacción, no distinguir por sí solo entre esas causas. Un contador de avisos emitidos no sirve como contador de equipos reconfigurados.

Controlar el momento también abre una superficie de ataque

Un tercero no necesita haber cambiado todavía un parámetro para influir en el cliente. Si puede escoger cuándo este inicia otra consulta, controla un momento que normalmente no podía predecir o provocar del mismo modo. El RFC 3203 exigió por ello autenticar FORCERENEW y descartar los mensajes que fallaran la comprobación.

La referencia era el RFC 3118, de junio de 2001. Sus mecanismos no deben confundirse. Un token opaco enviado en claro ofrece una comprobación débil y no autentica el mensaje completo. La autenticación diferida utiliza un secreto compartido, pero presupone que se ha distribuido fuera del intercambio DHCP.

Para distinguir clientes de forma individual también hay que gestionar sus relaciones de claves. El trabajo no consiste únicamente en añadir un campo a un paquete: incluye preparar, guardar y mantener secretos en los participantes. Esa carga condiciona la facilidad con que puede desplegarse una función aparentemente pequeña.

En agosto de 2012, el RFC 6704 sostuvo que el requisito anterior resultaba más estricto de lo necesario para ese uso y había limitado la adopción de FORCERENEW. Es una valoración de sus autores en aquel momento, no un censo actual de productos o redes. Su propuesta redujo el coste protegiendo una amenaza más concreta.

Un secreto recibido antes del próximo aviso

El antecedente era Reconfigure Key, incluido en el DHCPv6 histórico del RFC 3315, publicado en julio de 2003. La relación entre los textos se refiere a ese mecanismo de autenticación. No equivale a trasladar todo DHCPv6 a DHCPv4, ni convierte un documento posteriormente sustituido en una guía vigente completa.

El mecanismo de 2012 solo se utiliza cuando las partes no están empleando la autenticación anterior y han negociado la opción del nonce. El cliente anuncia capacidad en DISCOVER y REQUEST; el servidor indica su preferencia en OFFER. Anunciar que se entiende una función no es lo mismo que autenticar el mensaje que la utilizará. El cliente no debe enviar la opción de autenticación con este protocolo de nonce en sus propios mensajes.

Cuando corresponde establecer el secreto, el servidor genera un valor aleatorio o seudoaleatorio fuerte de 128 bits y lo entrega en un ACK durante el intercambio REQUEST–ACK. El cliente lo guarda. Más tarde, el servidor calcula con ese valor como clave un código de autenticación para FORCERENEW. El aviso posterior transporta el código, no una nueva exposición del secreto.

La mejora de despliegue es concreta: no hace falta aprovisionar previamente ese secreto por una vía independiente. La primera conversación de configuración proporciona el material con el que se reconocerán llamadas futuras. Precisamente por eso, la seguridad de esa primera entrega no puede desaparecer del análisis.

La negociación impone límites. El servidor no debe insertar el nonce en el ACK de un cliente que no declaró la capacidad. Si el OFFER inicial sí anunció el mecanismo y el ACK posterior no lleva la opción válida correspondiente, el cliente debe descartarlo y volver al inicio. Esa regla impide aceptar una negociación incoherente; no acredita de forma independiente la identidad del servidor que inició la relación.

No todo valor aleatorio es desechable

El nonce queda almacenado y puede autenticar más de una notificación. Su nombre no significa que se consuma en un único uso. El texto normativo del RFC 6704 indica que un ACK de renovación no debe repetirlo salvo que se haya generado uno nuevo. El dibujo de un ejemplo que muestra un valor nuevo no obliga a rotarlo en cada renovación ordinaria.

La situación cambia cuando el cliente pasa a otro servidor durante la revinculación: el nuevo servidor debe generar un nonce. El estado conservado a ambos lados forma parte de la relación, no es un adorno del formato. Al investigar un fallo después de una sustitución de servidor, importa saber qué secreto se entregó y cuándo, no solo si el paquete contiene una opción de autenticación.

También hay que separar autenticidad de frescura. El mecanismo histórico utiliza HMAC-MD5; describirlo no supone recomendar hoy ese algoritmo ni afirmar que cifra la conversación. La detección de repeticiones utiliza información adicional. La errata verificada 3474 precisó en 2013 que el contador debía aumentar estrictamente. Repetir el mismo valor no satisface ese requisito aunque el código de un mensaje antiguo siga siendo correcto.

De ahí que una clave válida no funcione como una credencial reutilizable sin contexto. El cliente necesita el secreto, las comprobaciones del mensaje y un estado que permita distinguir una nueva llamada de una ya recibida.

La confianza empieza antes de que llegue el aviso

La amenaza delimitada por el RFC 6704 es la de un atacante externo que no puede observar las conversaciones normales entre servidor y cliente. Si no conoce el nonce, no puede producir la notificación autenticada que haría consultar al cliente en el instante elegido por él.

No es una promesa equivalente frente a quien ve la entrega inicial. Interceptar ese nonce compromete la protección. Un observador situado en el enlace local también puede ver las solicitudes ordinarias. El diseño no crea una raíz de confianza separada para el arranque, ni demuestra que cualquier servidor accesible tenga autoridad administrativa para configurar el equipo.

La validación de mensajes falsos, además, consume recursos. Descartarlos después de comprobarlos no elimina toda posibilidad de denegación de servicio. Las especificaciones describen un mecanismo y su alcance, no pruebas de un incidente concreto ni estadísticas de ataques.

El registro de parámetros BOOTP y DHCP de IANA mantiene por separado el tipo de mensaje 9, la opción de autenticación 90 y la opción de capacidad 145. Permite que dos implementaciones atribuyan el mismo significado a esos valores. No demuestra que todas las implementaciones los usen, que hayan negociado su uso o que una actualización sea conveniente.

La historia deja una cadena de condiciones, no un mando absoluto. El servidor puede adelantar la consulta; el cliente debe procesar la interacción que sigue; el nonce limita quién puede provocar el aviso dentro del modelo de amenaza previsto. Ninguna de esas capacidades convierte la primera llamada en la respuesta final.