Although the DHCP specification has remained in time a relatively stable framework for clients and servers, the environment described by RFC 3046, targeting primarily the behavior of intermediate network transport elements, has been subject to several vendor-specific enhancements and, consequently, to an evolutionary standardization process, with the definition of additional recommendations. Significant developments in this field include:

– Support of fine grained option 82 manipulation on OSI layer 2 devices (DHCP Snooping)
– DHCP Snooping as baseline for enforcing a network security boundary in the DHCP domain (MAC, ARP, IP and DHCP related)
– Enhancements to DHCP relay agent behavior in order to achieve a DHCP state-full behavior
– High Availability for statefull DHCP relay agent platforms
– Address Resolution Protocol (ARP) table secured by coupling DHCP and ARP state on IPv4 Relay Agents / Default Gateways
– Ability to perform integrated control plane and forwarding plane decisions on a per subscriber basis based on option82 usage
– Integrated methods for enforcing and consolidating user identity with AAA and DHCP frameworks

Most of these enhancements, due to their popularity, have also reached (at least some level of) standardization from the IETF. The following sections will explore them one by one, describing their essential characteristics (purpose, mode of operation, real applications) as well as their relation to the IETF standardization course.

DHCP Snooping: option 82 tagging and security boundary on layer 2 devices As DHCP deals with the very foundation of network access (host addressing and initial configuration) it operation must be made secure, as much as possible protected from attacks. In fact, as pointed out by RFC 2131 itself: “… DHCP is built directly on UDP and IP which are as yet inherently insecure… Therefore, DHCP in its current form is quite insecure. … Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients…. Clearly, once this seed information is in place, an attacker can further compromise affected systems.”

The need for security and control in a DHCP environment, due to the vulnerabilities present in the DHCP, IP and ARP mechanisms, has made DHCP snooping critical to modern deployments. DHCP snooping is a feature available today on many brands and types of Ethernet switches and equivalent OSI layer access devices (including DSLAMs, DOCSIS stations, Wi-Fi access points and similar). The feature is essentially the capability of processing n the fly upper layer (UDP payload) DHCP communication by the OSI layer 2 device, for the dual purpose of providing option 82 tagging (at the edge of the network) as well as to enforce a security boundary between network and potentially untrusted users (DHCP clients).

Across all implementations, the possibility of tagging the option 82 (without, of course, setting the giaddr parameter) is generally well supported, with capabilities ranging from setting one or both sub-options, Circuit-ID and/or Remote-ID, and typically offering per port and/or per VLAN customization. In this way topological information (and in some case user-to-port identity) can be enforced at the network boundary.

What switches (or equivalent Ethernet based OSI layer 2 devices) seems to excel into is the enforcement of a tight level of security for the DHCP environment. In most of the cases a DHCP snooping device builds and maintains a DHCP snooping binding table by observing the DHCP conversations going on. Many implementations require the administrator only to define, on the device, untrusted downstream ports (ports from which clients will generate DHCP requests) and œtrusted upstream ports (ports from which DHCP servers are expected to speak, which, in a good design, should not be carrying any client-generated DHCP inbound message). Such devices typically offer granularity in terms of which VLAN and port the security feature should be applied to.

As such OSI layer 2 devices are able to keep track of the DHCP bindings (including information such MAC and IP addresses, lease time, VLAN number, and interface) they can also act as a firewall preventing ill-behaving IP hosts or rogue devices able to access the network at the MAC layer and to perform malicious actions such IP Spoofing and ARP Poisoning: the layer 2 device can discern ill-behaving from normal traffic by simply relying on the DHCP binding table (i.e. an unsolicited ARP reply announcing an IP to MAC entry inconsistent with the binding table, traffic sent by a MAC or IP source not present in the binding table, etc.) and consequently selectively drop malicious traffic, eventually generating an alarm.

Many implementations provide additional security tools to protect the network also from attacks performed against the DHCP environment itself, for instance by preventing DHCP server-based messages generation from untrusted downstream ports (allowing only client-generated messages to enter and therefore avoiding Denial of Service attempts from rogue DHCP servers), by enforcing RFC 2131 compliant behaviors (i.e. checking the ciaddr and MAC address in MAC header match, giaddr is 0.0.0.0, etc.) and by providing means for mitigating DHCP flooding attacks (i.e. by limiting the number of open DHCP conversations on a given port to a maximum number).

Although a powerful framework, DHCP snooping must be still considered as an anomaly for the OSI layered approach. Discussions within the IETF on how (and if) to define recommendations concerning bridges and DHCP snooping have actually taken place and some are currently still open (see draft Layer 2 Relay Agent Information currently under discussion within the DHC working group), but no recommendation on this topic has ever (yet) reached the standardization level. On the other side the role of layer 2 devices in the DHCP environment remains critical and DHCP snooping will surely remain popular and widely supported in real environments.

RFC 5107 (Server Identifier override)

The standard behavior of RFC 3046 requires the relay agent to only intercept and relay client-generated broadcast messages. Any further communication between client and server (i.e. DHCP Release or renew actions) should be based on IP unicast, as performed directly between the client and the server. The effect of such mode of operation is that the state of an earlier established lease is in general unpredictable for the relay agent.

In many cases, it would be useful to be able modify the behavior of RFC 3046 and have the relay agent explicitly addressed by all DHCP communication, making it statefull to the clients state. To have the relay agent statefully aware of the clients state opens ground for several other enhancements, which we will address shortly in the rest of this article.

As a secondary benefit the approach allows the DHCP server to receive all messages properly tagged with the option 82 values, instead of potentially missing it in unicast messages. By always having the option 82 set on the DHCP messages within the domain, the trust relationship between the devices in the network, as opposed to clients, can be tightly enforced (i.e. allowing consistent network device authentication, as proposed by RFC 4030, with the introduction of an authentication sub-option carrient in the option 82).

In the years many vendors have introduced proprietary approaches (sometimes referring to them as DHCP Proxy Relay Agent mode of operation), which have seen successful application in particular in the broadband market. Recently the Internet community has partially embraced such approaches and released an additional standard recommendation, RFC 5107, which proposes an integrated Server “ Relay Agent method for supporting this mode of operation. In all cases, solutions have in common the manipulation of the Server Identifier option (option 54, defined in RFC 2132).

RFC 5107 operates by using option 82 on the relay agent as a channel to inform the server that the Server Identifier (option 54) will need to be mutated (to point the relay agent). It is then the server which mutates the Server Identifier, making the client believe the relay agent is actually the answering DHCP server.

Proprietary (pre-standard) implementations are somehow similar, but set the entire responsibility on the relay agent (without requiring any server awareness). The relay agent, in fact, upon relaying messages from server to client mutates the Server Identifier received by the Server to point to its own IP address, and in the opposite direction translates back this field in the messages to let the message appear normal to the Server. Although the effect is virtually identical to the one of RFC 5107 (clients see the relay agent as the answering DHCP server), in this case neither client nor server is aware of the trick. The mechanism specified by RFC 5107, though, satisfies the additional purpose of having every message being tagged with option 82 explicitly.

In both cases unicast messages will be sent by the client directly to the relay agent, with the latter required regenerating the messages towards the server.

The behavior of the vendor proprietary variant, which is currently the most popular, is depicted in the next picture.

The possibility of handling all DHCP communication by the relay agent, and therefore making it state-full to the lease state, opens opportunities for efficient and secure user traffic processing. The next sections will describe such approaches.

DHCP securing the ARP protocol in IPv4 over Ethernet networks

In an IPv4 network based on dynamic addressing, the DHCP relay agent functionality is typically performed by the same host which acts as users default gateway. Both functionalities therefore reside what is an IP “default router”: the router first acts as relay agent for DHCP based clients (when they issue DHCP messages) and then, once the clients receive proper IP assignment and configuration (including a default gateway address, as coded in DHCP option 3) acts as their default gateway.

In most cases users reside on a MAC based multi-access broadcast-enabled environment (i.e. Campus Ethernet, IPoE Broadband, 802.11 Wireless), to which the router is also attached to. In this sort of environments the ARP protocol is used for IP to MAC address resolution. The ARP protocol, though, is also an inherently insecure mechanism. Denial-of-Service, Man-in-the-middle, ARP poisoning and other forms of attacks are possible in a MAC based multi-access broadcast-enabled network.

As already explained when describing the uses of DHCP snooping, in many cases the network administrator may be able to control the DHCP protocol on layer 2 access devices, this way enabling forms of ARP protection (several implementations allow the switch, acting as a DHCP snooping device, to use the DHCP snooping binding table to enforce ARP forwarding). In some cases though this may not be possible (i.e. as part of the network is not under direct administrator control or in case DHCP snooping is neither available nor feasible).

To answer such need, many vendors offer the possibility to couple the DHCP binding state to the ARP table on the default gateway, if this router also acts as DHCP relay agent and, usually, if it performs some form of statefull behavior (RFC 5107 or similar proprietary implementation).

By using the information in the DHCP messages, the router can populate a local DHCP binding table and, by doing this, its ARP table. Only changes to the DHCP binding state allow changes to the ARP table. In this setup the router will still respond to ARP requests, but disable any ARP learning from ARP communication. This approach protects the ARP table of the router, making attempts to poison it harmless, and it also prevents IP spoofing for traffic forwarded through the router (only subscribers granted a DHCP lease will be able to send and receive traffic through the default gateway).

High availability for DHCP Relay Agent implementations

In cases the Relay Agent operates as a statefull device (i.e. for security purposes) potential operational issues may arise, in particular regarding how the binding table state should be handled across platform reloads or in case of failover between a pair of gateway routers.

In fact, for a relay agent operating statefully, it would be impossible to accept a lease renew message if the binding state related to such user (MAC and IP address) is not known or had been somehow lost due to a crash or a planned reload action. This behavior is particularly critical to very large environments (with thousands of clients): not only a platform reload could cause massive user downtimes (as the relay agent refuses the renew, it is likely it will also refuse any other IP forwarding for the users, unless a new clean lease is established again) but it also endangers the control plane of the router, due to possible storms of DHCP client messages caused by users willing to regain as soon as possible their service.

Therefore vendor implementations of statefull DHCP relay agents are often associated with the capability to periodically save the binding table on a local non volatile memory storage media or to a remote host. By being capable of loading such tables upon a restart, the node can ensure state-full (and quick) recovery.

Note: This behavior is currently vendor specific and is not part of any IETF recommendation. It is also interesting to notice that failover mechanisms for recovering statefull DHCP relay agent platforms are currently only offered for single node implementations (possibly multi processor). The authors are not aware of any implementation which supports active-standby state-full (“hot”) fail-over across multiple distinct nodes.