DHCPv6 Client MAC Address Validation to Prevent Session Hijacking
Starting in Junos OS Release 18.2R1, a nonconfigurable mechanism exists for DHCPv6 local servers and relay agents to drop packets from a client with an unknown MAC address to prevent a malicious client from hijacking a session. When a DHCPv6 local server or relay agent receives a solicit message from a client to establish a session, it extracts the client MAC address (link-layer address) from the message and adds it to a local table that maps MAC addresses to client IPv6 addresses or prefixes. The server or relay agent uses this table to compare MAC addresses received in subsequent messages from the client to validate whether the client is known; if not, it is assumed to be malicious and the control packet is dropped. Because the packet has failed MAC validation, the Client MAC validation counter is incremented.
The assumption here is that the client sending the initial solicit message is benign. In this case, client MAC address validation protects against a malicious client trying to hijack a client session that is already established or in the process of being established. The client MAC address validation does not protect against a malicious client that sends the initial solicit message.
When no relay agent is present; the local server shares a link or access node with the client. In this case, the local server extracts the client MAC address directly from the Layer 2 header of the DHCPv6 control packet and validates the address against the table.
When a relay agent is present, validation is performed by the relay agent. RFC 6939, Client Link-Layer Address Option in DHCPv6, enables DHCPv6 relay agents that are connected to the same link as a DHCPv6 client to extract the client MAC address from the Ethernet (Layer 2) header in the received DHCPv6 control packet. The packet includes the client link-layer address as the source MAC address in its Ethernet header. The relay agent validates the MAC address against the value for this client that is stored in its local table. If the address does not match it drops the packet.
If the address is validated by the relay agent and the packet is not dropped, then the relay agent also includes that MAC address in option 79 (Client Link-Layer Address) in the header of the DHCPv6 relay-forward message that the relay agent sends to the local server. When the DHCPv6 local server receives a relay-forward message from a relay agent, the server automatically examines the message for the presence of option 79. When the option is present, the local server extracts the MAC address and validates it against the value stored in the table for this client. If option 79 is not present, the local server cannot perform the validation.
However, because the relay agent has already validated the address, the local server should not discover any address mismatches.
The following scenarios describe possible relay agent configurations and their implications for server validation:
A single Lightweight DHCPv6 Relay Agent (LDRA; Layer 2) is connected between the client and the server. If the LDRA did not add option 79 to the header, then the local server extracts the client MAC address directly from the Layer 2 header of the DHCPv6 control packet and validates the address against the table.
One or more Layer 3 DHCPv6 relay agents are connected between the client and the server. In this case, the server checks for option 79 in the header of the innermost relay-forward message sent by the relay agent. The innermost header is viewed because it is the header modified by the first relay agent reached by the client. Other headers are added by subsequent relay agents in the path. These agents do not add option 79 and they cannot extract the MAC address from the first relay agent’s Layer 2 header, because that agent changes the address to its own address, as does each subsequent relay agent.
A combination of a client-facing Layer 2 (LDRA) relay agent followed by one or more Layer 3 DHCPv6 relay agents is connected between the client and the server. The server checks for option 79 in the innermost header of the relay-forward message sent by the relay agent. If the LDRA did not add option 79 to the header, it is probably not capable of changing the MAC address in the header to its own. Consequently, the server next checks the second innermost header for the option, because the first Layer 3 relay agent may have extracted the MAC address and added option 79 to convey the address.
No configuration is required to enable validation of client
MAC addresses. You can view how many control packets have been dropped
because of a validation failure by issuing the show dhcpv6 server
statistics command.
Benefits of Client MAC address Validation
Client MAC address validation enables you to prevent a DHCPv6 client with an unknown MAC address from hijacking a session established by a known client. Usage of DHCPv6 client MAC addresses is likely to increase as it is convenient for correlating DHCPv4 and DHCPv6 clients in a dual-stack environment.