Today many service providers operate their broadband environments (DSL, Cable, Fiber-to-the-Home, etc.) utilizing IP over Ethernet (IPoE) access, in association with DHCP, instead of more traditional Point-to-Point Protocol (PPP) and PPP over Ethernet (PPPoE) approaches. The comparably lower costs of operation of the first compared to the second model make such architectures very attractive and (sometimes) even a critical factor for targeting certain competitive markets. Anyway traditional PPP and Remote Authentication Dial In User Service (RADIUS) AAA environments, although more complex and expensive, offer additional granularity in terms of subscriber control (i.e. supporting session based hierarchical Quality of Service, H-QoS or selective security restrictions). In some cases operators running an IPoE broadband network may wish to add such level of control to (at least some part of) their proposition.

Recently, many implementations in the market have shown that the use of DHCP with option 82 can be extended and support session management and granular per-subscriber traffic handling. Such solutions have in common a similar approach: discover an IPoE “session” by following the DHCP communication, identify the subscriber using the option 82 populated value and consequently act by selecting a specific policy. Upon a DHCP lease establishment the router (operating as a statefull relay agent) dynamically retrieves a specific subscriber-policy from a policy server (using the option 82 as the key for query and retrieval, typically based on RADIUS or other AAA-like mechanism). The downloaded policy, which may include user specific QoS settings, access lists or similar, is then associated to the IP or MAC address identified by the discovered DHCP lease session, making the router capable to apply the policy at the forwarding plane: IP packets from/to such IP or MAC address are handled according to the specific subscriber profile. At the control plane DHCP communication will remain the mean for retrieving any new session event (i.e. a session stop).

DHCP Authentication and Integrity Management

In order to solve protocol vulnerabilities in terms of identity and authenticity of the DHCP speaker, the IETF has introduced in time recommendations for DHCP-level authentication capabilities: RFC 3118 (Authentication for DHCP Messages?) and RFC 4030 (œAuthentication Suboption for the DHCP Relay Agent Option?). RFC 3118 covers authentication for client and server communication, and is meant as a user-to-network authentication method (DHCP option 90 is defined for such use). RFC 4030, instead, defines a method for network-based authentication, in terms of DHCP processing trusted elements, and it is targeted for use between DHCP relay agents and DHCP servers. The authentication field is carried as an additional sub-option of the option 82, providing integrity and replay protection (the specification recommends the HMAC-SHA1 algorithm, but additional mechanisms can be defined).

Please note that the mechanism provided by RFC 4030 requires careful handling: in fact the standard RFC 3046 behavior imposes option 82 to be echoed back? by the server to the relay agent, and the relay agent to strip the entire option off the message when passing the communication on to the clients. In case of RFC 4030 the authentication sub-option, if utilized, needs to be properly “regenerated” by the server in the option 82 before being sent back to the relay agent. Moreover, in order to protect servers from user-level attacks, it is recommendable to have all DHCP messages been relayed by the relay agent (i.e. implementing the behavior proposed by RFC 5107), avoiding any direct unicast communication between clients and servers.

Use of DHCP option 82 to convey AAA Identity (RFC 4014)

Recommendation RFC 4014 (RADIUS Attributes Suboption for the DHCP Relay Agent Information Option) has introduced a standard approach for conveying AAA RADIUS identity attributes (i.e. the username used upon user authentication exchanges) to a DHCP Server using a sub-option of DHCP option 82. A DHCP server, receiving a DHCP message containing such RADIUS attribute sub-option, should be able to extract the content (i.e. the username) and use it in selecting configuration parameters for the specific user.

A useful application of RFC 4014 is the possibility of achieving convergence between AAA and DHCP network access and identity control processes, in particular on Ethernet networks using the IEEE 802.1X specification. In such case the role of 802.1X Authenticator is often performed by an access device and the same device is normally also capable of DHCP snooping and option 82 tagging. Upon completion of the 802.1X authentication process (through RADIUS and AAA exchanges) the switch would be aware of the user identity in the form of a RADIUS attribute (i.e. a username). Once the user issues a DHCP discover, the switch can convey such username (or similar RADIUS attribute) as part of the option 82. The DHCP server, by parsing the option 82, could be able to identify the user and select a proper action. As a both DHCP server and AAA server point to the same identity, the solution allows all subscriber information to be consolidated in a single subscriber database.

Other DHCP Relay Agent related enhancements

In order to complete the overview of the latest developments regarding the DHCP Relay Agent Information option manipulation, the following additional IETF recommendations are briefly mentioned:

RFC 3527 (Link Selection sub-option): according to RFC 3046 the relay agent is required to set the “giaddr” to itself when relaying the message towards the server. The giaddr is used by the server for both actual IP unicast communication with the realy agent, as well as for identifying the pool to be used for offer selection. This behavior may be reason for problems in case the relay agent IP address giaddr address is not an address reachable by the server (i.e. due to an intermediate firewall). The specification introduces a modification to the “giaddr” functionality, in order it to be only the relay agent IP contact point, separate from the concept of pool selection. By creating an additional sub-option in the option 82 (called Link Selection sub-option) the relay agent can specify to the server which is the pool to use for actual allocation.

RFC 3993 (Subscriber-ID Suboption for the DHCP Relay Agent Option?) and RFC 4243 (Vendor-Specific Information Suboption for the DHCP Relay Agent Option?): these are extensions of the option 82 in terms of supporting administrator customized information. The first, as we mentioned, may be use by the administrator to insert user identity information (i.e. if the Remote-ID cannot be customized), while the second may be used to identify a specific vendor-type and model for the equipment performing the tagging of the option. In both cases no modification to the mechanisms specified in RFC3046 is applied.

RFC 5010 (DHCP Relay Agent Flags Suboption?): in cases a relay agent performs the behavior specified by RFC 5107 (or similar proprietary implementation) the server may loose visibility of some of the message original characteristics. In particular the unicast or broadcast “nature” of the original message would be lost once the message is relayed. For instance, according to RFC 2131, a DHCPREQUEST must be sent as a unicast before timer T1 expiration (for renewing a lease) and as a broadcast upon timer T2 expiration (for rebinding a lease). In cases all messages are relayed by the relay agent, such information would be lost, causing potential ambiguities in the server behavior. The purpose of the sub-option described in RFC 5010 is to allow the DHCP relay agent to specify flags? into the relayed message. These flags (as a sub-option of the option 82) can be used to describe attributes of the original message that are useful to the DHCP server, but which can only be detected by the relay agent. The DHCP server, if supporting RFC 5010, can use the information to improve its processing algorithm (for instance consider trusted a DHCPREQUEST for renewing purposes as flagged as unicast, but not trust a similar one for rebinding purposes because flagged as broadcast, symptom of user re-location in the access network).

Design guidelines: DHCP in Broadband IPoE architectures

In the last ten years broadband architectures based on plain IP over Ethernet (IPoE) access have gained momentum, especially when compared to more traditional PPPoE models. Such network deployments, using DHCP as addressing and identity management paradigm, offer scalability and contain costs. Traditionally the IPoE broadband environment is set up using the so called “Service VLAN” model: all users requiring the same sort of service (i.e. Internet access) attach to a common Ethernet access network and are consolidated into the same VLAN. In general users requiring multiple services (i.e. Internet, TV and VoIP) will be required to attach to multiple Service VLANs and therefore to use multiple IP clients within their home environment. Users utilize DHCP as automatic configuration method for their devices, with very few or no initial setup required.

Broadband IPoE architectures are, beyond doubt, a very interesting environment for seeing DHCP design best practices in action. In such environments subscriber identity management takes full advantage of the capabilities introduced by RFC 3046. In residential environments (DSL, DOCSIS or Fiber-to-the-Home – FTTH), in fact, the service provider usually manages the access node (DSLAM, DOCSIS station or FTTH switch). Under these circumstances the location of a port (on a given DSLAM, DOCSIS station or switch) becomes already a very precise indication of the user identity. Typically the access nodes in question operate at the OSI layer 2 and offer full DHCP snooping functionalities. Therefore, by setting on the entrance point of the network either the Circuit-ID or the Remote-ID sub-options in the option 82 value, the operator can identify with precision “who” the user willing to get access is. The information encoded into the option 82 value is usually provisioned on a subscriber database which can be accessed by the DHCP server in order to select the proper action. Due to the critical importance of the DHCP infrastructure, large broadband IPoE deployments pay particular attention to the scalability of the DHCP server and to its integration with Operations Support Systems (OSS) and Provisioning tools. To address such need, today’s DHCP server implementations, targeted to large broadband deployments, offer platform carrier grade reliability and capabilities for querying a separate subscriber database, using standard database methods like the Lightweight Directory Access Protocol (LDAP). Such DHCP server platforms are designed and dimensioned carefully, aiming to achieve carrier grade reliability and scalability.

Beside subscriber identity management, DHCP processing is also used as an effective security baseline. By properly defining trust boundaries, DHCP snooping capable nodes (DSLAMs, DOCSIS stations, switches) can protect both operator’s network and legitimate, well-behaving users from being attacked. Security prevention mechanisms include the methods previously introduced when discussing DHCP snooping and are used for protection against ARP, MAC, IP spoofing and DHCP abuse. Moreover the role and position of the Default Gateway (which in this setup operates always as the Relay Agent) require specific protection. For such purpose statefull DHCP-to-ARP table mapping, including failover mechanisms (in particular for recovery of the binding tables across platform restarts), is frequently used. Additionally, as both DHCP and ARP typically require central processor handling, control plane protection mechanisms are deployed on the Default Gateway node.

Note: many additional requirements and design practices are typical of IPoE broadband environments, such a topic requiring more than a few sentences to be properly described. Anyway it is opportune to expose the reader at least to one additional constraint, typical of such environments: the necessity of forcing all IP traffic (including user-to-user traffic, internal to the VLAN segment) to flow through the Default Gateway, the reasons including security, billing and control purposes. Such requirements are typically satisfied by using a combination of so called local proxy ARP? and of layer 2 “user isolation” methods. The local proxy ARP behavior causes the router to answer with its MAC address not only in response to ARP requests for its own IP addresses or for routed IP subnets (the latter the so called proxy ARP behavior, a default on many routing platforms) but also for any other ARP request, including requests targeting IP hosts in the local subnet. By coupling this behavior with strict OSI layer 2 user isolation constraints (users have the possibility to exchange traffic only with the default gateway, any user-to-user direct communication at the OSI layer 2 been prevented), all IP traffic is forced to flow through the default gateway.

In more recent years complex multi-play propositions, as well as the introduction of mobile access broadband services (such as WiMAX), have required broadband networks to extend the flexibility for subscriber control to reach an additional level of granularity: be able to dynamically identify user sessions and apply “on the fly” subscriber specific polices (i.e. requiring hierarchical QoS, H-QoS) for handling traffic.

The need for such level of control, answered by the introduction of the functionalities described in the section “Subscriber selective profile management in IPoE environments”, has lead to more sophisticated Default Gateway node implementations. Such “advanced router” statefully follows DHCP session establishment and, by this, dynamically discovers user sessions. Using the option 82 in the DHCP message as the key for querying a policy server, the router can download the proper policy (i.e. using Radius as query and download mechanism) and apply it locally to the MAC and/or IP entry defined by the DHCP lease. According to the installed policy, the router performs proper forwarding plane traffic handling (i.e. H-QoS). Such approaches can be combined to more traditional Service VLAN based approaches: users requiring “specially customized services” can be consolidated into a specific VLAN, while traditional flat services can still be provided using the flat Service VLAN approach on other VLANs, as previously explained.

Design guidelines: DHCP in Enterprise Campus environments

Large DHCP deployments are also common to the modern Enterprise network. Targets in this case are often very demanding, in terms of security and user identity management, and in many situations also in terms of automatic configuration management of devices and upper layer applications (i.e. Voice over IP). Traditionally separated solutions and technologies, one by one, have been introduced to the Enterprise infrastructure, each one satisfying only a specific individual demand. Consequently Enterprise architects are left today with the additional challenge of chasing component harmonization.

These considerations are also applicable to DHCP processing as applied to the Enterprise. Typically DHCP has been deployed in the Enterprise as a standard method for automatic host configuration and, in many cases (i.e. VoIP solutions), as a primary channel for device and application (stateless) configuration. In these cases DHCP Vendor Extensions options (as specified by RFC 2132) have seen extensive deployment, as a standardized framework for exchanging configuration parameters, directly between clients (devices) and servers. Anyway, as the DHCP messages and Vendor Extensions options used concern only user and device level characterization (such as option 43 and 60, often used to specify user-device model and type and option 150 and 66 offered by the server for signaling the location of the system offering device configuration scripts), the role of the network in terms of DHCP manipulation has traditionally been transparent.

As we have seen through this paper, DHCP has much more to offer to the Enterprise world. If a relationship between user identity and option 82 is properly set, DHCP network-centric processing (read, option 82 manipulation) can offer scalable user characterization at the IP layer and, as often critical to the Enterprise, a very effective security approach for access control.

According to the approach already used to the broadband case, in a network using DHCP for user and device configuration, it is recommendable to use option 82 processing and let the access node operate as a DHCP snooping element, supported by Relay Agent functionalities performed by a the first IP router node faced by the users (their default gateway). The security measures offered by DHCP snooping (as we described, targeting MAC, ARP, IP and DHCP abuse) are consequently to be recommended also for the Enterprise. An infrastructure-level approach for security based on DHCP can be further completed by including ARP table protection (i.e. ARP being coupled to the DHCP lease state, if possible, on both switches and routers facing users and having a role in the DHCP RFC 3046 process), control plane protection against protocol misuse and forms of network protocol node authentications (such as recommended in RFC 4030, which avoids rogue devices to have any role in the DHCP domain).

Concerning harmonization, as a general good practice, integration of network and domain access control (i.e. Windows) should be chased. As the AAA framework offers a standardized and widespread approach for coordinating authentication, authorization and accounting from many systems, the overall solution should seek harmonization through integration with AAA. In this direction, a key role for access control should again be assigned to the network access devices facing the users (wired switch or wireless access point). The access node should, in fact, act as primary trust boundary between the untrusted client domain and the trusted network infrastructure domain. In order to maximize manageability, user identity should be managed under a single user identity database for the entire Enterprise, trying to harmonize, if possible, user authentication and device management processes.

In many cases 802.1X may be already in use as end-user authentication paradigm, and therefore consolidation between the AAA infrastructure and the DHCP user identification methods could be performed using an approach complaint to RFC 4014. In fact, as the same access node (wired switch or wireless access point) running DHCP snooping and setting the option 82 commonly acts also as AAA (802.1X) authenticator, the recommendation would be to follow the following logics: users, once authenticated using 802.1X and selectively assigned to a certain VLAN upon successful authentication, should issue a DHCP discover for obtaining automatic configuration; such DHCP message should be “marked” by the same access node (acting as both 802.1X Authenticator and DHCP snooping device), using the same “username” exchanged by 802.1X authentication (as RADIUS attribute) as part (sub-option) of the network-imposed option 82 value; finally the DHCP server should be able to parse the option 82, retrieve the username and, based on it, define the action to be taken.

A common user database used by both AAA and DHCP servers to query the user identity for permission and configuration parameters would then be the keyword for achieving full harmonization. As many DHCP and AAA server implementations today offer interfacing to many standard and proprietary database and domain controller technologies, the administrator and solution architect should properly consider the choice for which language and/or Application Programming Interface (API) should be deployed.

Conclusion

The flexibility provided by its vocabulary of options, together with the simplicity of the original concept and its widespread support base (operative systems, user devices, commercial and GNU-licenced servers implementations, network intermediate components), have made of DHCP the protocol of choice for automatic end-user host addressing and configuration. The evolution of the DHCP framework in terms of network-centric control mechanism, in particular as feeded by RFC 3046 and subsequent recommendations, has further extended the protocol recognition by the community. DHCP option 82 manipulation techniques provide operators with sophisticated tools for enforcing indentity and access control in multi-access environments, such as Ethernet networks. As Ethernet and IP still gain popularity, DHCP will likely remain a key component of modern and future IPoE deployments, both in public broadband and private enterprises environments.

DHCP related links:

IETF DHC workgroup http://www.ietf.org/dyn/wg/charter/dhc-charter.html
IETF RFC 2131 http://www.ietf.org/rfc/rfc2131.txt
IETF RFC 2132 http://www.ietf.org/rfc/rfc2132.txt
IETF RFC 3046 http://www.ietf.org/rfc/rfc3046.txt