Resumen

  • RFC 5192 prohíbe usar la presencia o ausencia de sus opciones DHCP como negociación sobre el uso de PANA. Convertir “opción ausente” en “PANA no requerido” crea exactamente la oportunidad de degradación que advierte el documento.
  • Cuando la opción existe, contiene una lista ordenada de direcciones. Ese orden obliga a la secuencia de intentos, pero no demuestra salud, identidad, contacto ni éxito de autenticación; cada etapa necesita su propio recibo.

Los sistemas suelen tratar lo que falta como si fuese un valor. A veces es necesario: una política local puede definir un comportamiento predeterminado. El problema comienza cuando ese predeterminado se atribuye al protocolo que guardó silencio.

RFC 5192 es explícito. Las opciones PAA de DHCPv4 y DHCPv6 sirven para localizar agentes de autenticación PANA. No pueden negociar si PANA debe usarse. La presencia no es una orden de seguridad y la ausencia no es una dispensa.

Esta separación protege contra un ataque sencillo. Si borrar una opción bastara para rebajar la autenticación, quien pudiera modificar una respuesta DHCP podría llevar al cliente hacia un mecanismo menor o hacia ninguno. La ausencia observable sería real; la autorización inferida sería falsa.

La política vive fuera de la opción

La obligación de usar PANA debe proceder de una superficie distinta: configuración local, perfil administrado u otra fuente cuya autoridad y protección se puedan demostrar. RFC 5192 no designa la opción como esa superficie.

Por eso el estado operativo debe almacenar dos hechos: paa_option = absent y pana_policy = required, cada uno con su procedencia. Si el cliente dispone de otra forma de localizar PAAs, puede activarla. Si la política define un fallo cerrado, puede detenerse. Si existe una excepción, debe estar declarada allí.

Lo que no debe hacer es grabar pana_policy = optional porque no vio la opción. Ese campo tendría apariencia normativa sin haber sido emitido por ninguna autoridad.

El principio también funciona en sentido contrario. Recibir una lista no demuestra que el cliente haya pedido PANA ni que la red haya negociado su uso. El servidor puede enviar la opción aun cuando el cliente no la solicitó expresamente.

Solicitud, respuesta y resultado

En DHCPv4, el PaC debería pedir la opción en la Parameter Request List. En DHCPv6 debería incluirla en la Option Request Option. Un servidor configurado debería suministrarla incluso sin petición explícita.

Así aparecen cuatro estados legítimos: solicitada y recibida; solicitada y ausente; no solicitada y recibida; no solicitada y ausente. Una casilla “discovery enabled” no conserva esa matriz.

El recibo debe enlazar la solicitud y la respuesta por transacción, familia, interfaz, servidor y camino de relay. También debe registrar la protección observada. Sólo entonces puede decirse qué pidió el cliente y qué entregó el servidor.

Después vienen otras etapas: validación, lista decodificada, intentos y PANA. Ninguna debería actualizar retroactivamente el contenido de los paquetes.

El orden tiene alcance limitado

La opción 136 de DHCPv4 contiene direcciones IPv4 de 32 bits y exige una longitud múltiplo de cuatro. La opción 40 de DHCPv6 contiene direcciones IPv6 de 128 bits y exige una longitud múltiplo de dieciséis. Las direcciones se presentan por preferencia; el PaC debe probar los registros en el orden recibido.

Ese mandato no declara sano al primer PAA. Ordena una acción al cliente. El primer intento puede expirar y el segundo funcionar. También puede responder la dirección IP y fallar después el intercambio PANA.

Guardar sólo la dirección ganadora elimina la prueba de que el cliente respetó el orden. Guardar sólo la primera elimina el resultado real. La solución es una lista inmutable más un historial por intento: ordinal, inicio, observación, final y causa.

Una herramienta tampoco puede ordenar la lista alfabéticamente para mostrarla y usar luego esa representación para automatizar. Presentación y ejecución deben consumir el mismo orden recibido o declarar una política local que lo modifique con su propia autoridad.

Una longitud inválida no equivale a silencio

Los requisitos de múltiplos permiten dividir el payload exactamente en direcciones. Si sobran octetos, el dato no cumple el formato. RFC 5192 no describe una reparación creativa.

La plataforma debe retener código, longitud declarada, longitud capturada, bytes y resultado de validación. Truncar el resto y publicar direcciones plausibles es peligroso porque convierte una anomalía visible en una configuración aparentemente normal.

También es incorrecto registrar la opción malformada como ausente. La ausencia puede deberse a decisión o pérdida; la invalidez muestra que llegó información que no pudo interpretarse. En seguridad, esa diferencia cambia tanto la investigación como la respuesta.

IPv4 e IPv6 no forman una lista imaginaria

RFC 5192 define listas separadas para cada familia. No especifica cómo competirlas en un cliente dual-stack, cuánto esperar antes de pasar a la otra familia o si se permiten carreras paralelas.

Una implementación debe decidirlo, pero no ocultarlo. Conservar listas por familia, transacción e interfaz permite observar si los primeros candidatos divergen. Un único campo primary PAA destruye el origen de la selección.

Si una renovación entrega otro orden, debe generarse una nueva versión. Los intentos ya iniciados siguen enlazados a la versión antigua. De otro modo, la historia puede acusar al cliente de haber incumplido un orden recibido después de su decisión.

Los estándares DHCP aportan el contexto de transacción, servidor, relay, lease, Renew y Rebind. Ese contexto sitúa la lista en el tiempo; no certifica la disponibilidad de sus destinos.

La seguridad se demuestra intercambio por intercambio

RFC 5192 advierte que, en la mayoría de redes, el DHCP que entrega estas opciones antes de la autenticación de acceso carece de integridad y autenticación de origen. Una respuesta modificada o insertada puede dirigir al PaC hacia un PAA fraudulento que intercepte solicitudes de autenticación o niegue el acceso.

Hay especificaciones de autenticación DHCP. Citarlas no demuestra que una red concreta las aplicó. El registro debe nombrar el mecanismo verificado y su resultado. Si no existe esa evidencia, no debe ascender a authenticated por asociación bibliográfica.

Incluso una entrega protegida prueba la procedencia de la lista, no la salud de los candidatos. Contacto, identidad del peer y resultado PANA aparecen después.

Este límite distingue el presente artículo del ya conservado sobre RFC 5191: aquí se audita la cadena de descubrimiento e intentos. La autorización, el Enforcement Point y el plano de datos pertenecen a recibos posteriores.

El objeto operativo mínimo

Primero se guarda la política de seguridad, con su fuente. Luego la transacción DHCP: familia, interfaz, request set, respuesta, servidor, relay, protección y tiempos. La opción se archiva en bruto y se valida sin mutar.

La lista decodificada obtiene hash, versión y posiciones. Cada intento referencia una posición y guarda observación de red, mensaje PANA si lo hubo y razón terminal. Una nueva respuesta crea otra versión; no reescribe la anterior.

El tablero puede entonces decir algo exacto: “PANA sigue requerido; la opción 40 no llegó; se inició el método alternativo X.” O: “La lista [A,B] fue válida; A expiró; B inició PANA.”

La disciplina de Heng Lu sobre capas de realidad exige precisamente esto: el silencio de una capa no adquiere autoridad política sobre otra. Una ausencia puede activar una regla explícita. No puede inventarla.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 texto
  3. Registro RFC 5192
  4. Datatracker RFC 5192
  5. Historial RFC 5192
  6. Referencias RFC 5192
  7. Errata RFC 5192
  8. RFC 2131
  9. Registro RFC 2131
  10. RFC 2132
  11. RFC 8415
  12. Registro RFC 8415
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. Parámetros BOOTP/DHCP de IANA
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy