Warum können bei IPv6 und einem DHCP-Server keine MAC-Adressen als Filterkriterium verwendet werden.
Oder: Wie DHCP-Relay-Funktion in IPv6 die IT-Sicherheit beeinflusst.
Für ein weltweites Unternehmen arbeiteten wir an der Auswahl einer IPAM (IP Address Management)- und DHCP (Dynamic Host Configuration Protocol)- Lösung. Unsere selbst gesteckte Anforderung war unter anderem - natürlich - die Gleichheit von IPv4 und IPv6.
Während des „Proof of concepts” kamen wir dann zu folgender Frage:
Warum können bei IPv6 und einem DHCPv6-Server keine MAC-Hardware-Adressen als Filterkriterium verwendet werden?
Wir stellten fest, dass eine Filterung der Clients anhand Ihrer MAC-Adresse (Media-Access-Control-Adresse) nur bei IPv4, nicht aber bei IPv6 möglich ist.
Damit war die minimale Sicherheitsanforderung, nämlich die Adressvergabe per DHCP-Server nur für bekannte Hosts (MAC-Adresse) zu ermöglichen, für IPv6 nicht realisierbar.
(Die MAC-Adresse ist als Sicherheitsmerkmal komplett unzureichend, jedoch kann das versehentliche Verbinden von betriebsfremden Endgeräten mit der MAC-Adressabfrage zumindest etwas unterbunden werden. Das letztendliche Sicherheitsziel sollte immer die Einführung von 802.1X (NAC) und IEEE 802.1AE (MACsec) sein.)
Warum kann nun die MAC-Adresse bei DHCPv6-Anfragen nicht ausgelesen werden? Ein Blick in die RFCs (Request for Comments) verrät den Grund:
IPv4:
Beim BOOTP (Bootstrap-Protokoll) IPv4 (RFC 951) erfolgt die optionale Clientidentifizierung anhand der MAC-Adresse, die MAC-Adresse befindet sich dazu im eigenen „chaddr“-Feld (Client Hardware Address).
Danach führte die RFC 1531 für IPv4 DHCP zusätzlich das optionale Feld „client identifier" ein, um die Abhängigkeit zur Hardware MAC-Adresse und zu dem Feld „chaddr" als Identifizierungsmerkmale aufzulösen. Fortan waren beide Felder „chaddr" (MAC-Adresse) und „client identifier” bei DHCPv4-Anfragen enthalten.
Dabei kann das neue „client identifier“-Feld auch die MAC-Adresse enthalten.
Interessant ist nun dieses neue „client identifier“-Feld: Der Client hat die Möglichkeit, seine MAC-Adresse auch in diesem Feld hineinzuschreiben. Jedoch sieht die RFC für das „client identifier“-Feld mehrere Möglichkeiten vor.
Damit ist dieses Feld leider momentan noch keine verlässliche Quelle.
Zwar gibt zum jetzigen Zeitpunkt ein testweise installiertes Windows 10 Endgerät seine MAC-Adresse über dieses Feld bekannt.
Stand ist heute: es fehlt jedoch die breite Erfahrung „im Feld.”
Für gewöhnlich befinden sich in größeren Unternehmensnetzwerken die DHCP-Server nicht im gleichen IP-Netz wie die anfragenden Clients.
Die DHCP-Relay Funktion („ip helper") stellt in diesen Fällen sicher, dass die DHCP-Anfragen zum DHCP-Server weitergeleitet werden. Bei IPv4-Anfragen wird die MAC-Adresse als „chaddr“-Feld mit übertragen.
(Ein Sonderfall zum Verständnis: Befinden sich der DHCP-Server und die anfragenden Clients im gleichen Layer 3 (IP)-Netz, so erhält der DHCP-Server den Layer 2 Frame, inklusive MAC-Adresse, direkt vom Clients. In dieser geswitchen LAN-Umgebung braucht der „client identifier" gar nicht ausgewertet werden, um die MAC-Adress zu ermitteln, da die MAC-Adresse im Layer 2 Frame frei Haus mitgeliefert wird. Dies gilt für IPv4 und IPv6 gleichermaßen.)
IPv6, jetzt kommt der entscheidende Punkt:
Bei IPv6 fehlt in der DHCP-Relay-Funktion die „chaddr“-Option. Die MAC-Adresse des Clients wird bei IPv6-DHCP-Request also gar nicht zum Server hin übertragen.
Anstelle dessen wird ausschliesslich die DUID (DHCP Unique Identifier) übertragen.
Somit ist erst mal keine Filterung anhand von MAC-Adressen möglich, lediglich die DUID-Informationen sind für Filterregeln verfügbar.
Dass der DUID-Inhalt wiederum aus der MAC-Adresse (RFC 8415) gebildet werden kann, ist gut, aber in der Praxis ist die „Kann"-Bestimmung allerdings noch nicht belastend genug. Auch wenn Windows 10 diese Praxis momentan so umsetzt, lässt sie trotzdem noch zu wenig Rückschlüsse auf die zukünftige Praxis zu.
(Die RFC sieht für die Bildung der IPv6 DHCP DUID vier Möglichkeiten vor:
Link-layer address plus time, vendor-assigned unique ID based on Enterprise Number, Link-layer address oder Universally Unique Identifier (UUID)
[RFC6355].)
Der Vorteil der DUID bei den heutigen Geräten ist, dass auch bei mehreren Netzwerk-Interfaces, wie LAN und WLAN, nur eine ID (DUID) am DHCP-Server hinterlegt werden muss. Zudem ist die DUID ein manuell beschreibbares Feld und eignet sich daher zur administrativen Steuerung.
Für die Filterung anhand der MAC-Adresse gibt es nun eine RFC 6939, welche endlich die MAC-Adresse in die DHCPv6-Relaypakete mit einfügt.
Es bleibt nur noch abzuwarten, ob die Hersteller das zukünftig unterstützen.
Ich hoffe, ja.
Informationen rund um die IT-Sicherheit gibt es hier.