Il protocollo DHCP stesso non è stato progettato per avere la crittografia ed è un protocollo molto basilare di short DISCOVER - > OFFER & REQUEST - > % pacchettiACKNOWLEDGE. In particolare, SSL / TLS non funzionerebbe, poiché anche la negoziazione di tale connessione richiederebbe l'utilizzo anticipato del DHCP. Inoltre, non è possibile aggiungere semplicemente un po 'di crittografia, poiché nessuno avrebbe un'implementazione che supporti questo, e sarebbe difficile modificarli separatamente su ogni dispositivo.
Ci sono stati alcuni tentativi per proteggere ARP, per autenticare richieste DHCP usando 802.1x, e persino per implementare EAP in DHCP (EAPoDHCP), ma quelli erano tutti solo bozze e non c'è stato alcun lavoro relativo a questo ultimamente. È interessante leggere, tuttavia, ad esempio:
-
Proteggi il protocollo di risoluzione degli indirizzi unicast (S-UARP) estendendo il DHCP
di B. Issac; L.A. Mohammed; DOI: 10.1109 / ICON.2005.1635503
-
Proteggi i protocolli ARP e Secure DHCP per attenuare gli attacchi di sicurezza [ PDF ]
di Biju Issac; International Journal of Network Security, Vol.8, No.2, pp.107-118, marzo 2009
Inoltre, tutte queste proposte erano principalmente per autenticare le richieste DHCP, non per codificarle . Questo perché nessuno ha mai considerato le coppie di lease MAC e DHCP come informazioni che dovrebbero essere nascoste da chiunque possa catturare quei pacchetti.
Il motivo per cui tali proposte non sono mai state ampiamente accettate è stata la mancanza di domanda: la moderna sicurezza di rete si basa sulla creazione di riservatezza e integrità a un livello superiore. Anche in presenza di un server DHCP canaglia o di client non autorizzati, tecnologie come DNSSEC e HTTPS impediscono loro di causare una vera minaccia fornendo catene di fiducia indipendenti di livello inferiore.