El protocolo DHCP en sí no fue diseñado para tener cifrado y es un protocolo muy básico de short DISCOVER - > OFFER & REQUEST - > ACKNOWLEDGE paquetes. SSL / TLS especialmente no funcionaría aquí, ya que incluso la negociación de dicha conexión necesitaría el uso del DHCP de antemano. Además, no es posible simplemente agregar un poco de cifrado, ya que nadie tendría una implementación que lo admita, y sería difícil modificarlos por separado en cada dispositivo.
Ha habido algunos intentos para asegurar ARP, autenticar las solicitudes DHCP utilizando 802.1x, e incluso implementar EAP en DHCP (EAPoDHCP), pero todos fueron Borradores y no ha habido ningún trabajo relacionado con eso últimamente. Interesante de leer, sin embargo, por ejemplo:
Protocolo de resolución de direcciones de unicast seguro (S-UARP) mediante la extensión de DHCP
por B. Issac; L.A. Mohammed; DOI: 10.1109 / ICON.2005.1635503
Proteger los protocolos ARP y DHCP para mitigar los ataques de seguridad [ PDF ]
por Biju Issac; Revista Internacional de Seguridad de Redes, Vol.8, No.2, PP.107-118, marzo de 2009
Además, todas estas propuestas fueron principalmente para autenticar las solicitudes DHCP, no para cifrarlas . Esto se debe a que nadie realmente ha considerado los pares de arrendamiento de MAC y DHCP como información que debería ocultarse a cualquiera que pueda capturar esos paquetes.
La razón por la que esas propuestas nunca fueron ampliamente aceptadas fue la falta de demanda: la seguridad moderna de la red se basa en crear confidencialidad e integridad en un nivel superior. Incluso cuando existía un servidor DHCP no autorizado o un cliente no autorizado, tecnologías como DNSSEC y HTTPS evitan que causen una amenaza real al proporcionar cadenas de confianza independientes de capa inferior .