Communication Networks/DHCP Protocol
Dynamic Host Configuration Protocol
[edit | edit source]Dynamic Host Configuration Protocol (DHCP) allows for manual and automatic assignment of IP addresses (see IETF rfc 2131 & 2132). DHCP is enacted when a new machine joins a network or an existing machine attempts to renew its IP address. DHCP is an extension of an older protocol known as the "bootstrap protocol" (BOOTP) and is backwards compatible with BOOTP. There are three methods of IP address allocation:
Manual: An administrator manually assigns the IP address; tedious but most secure method.
Automatic: DHCP server assigns permanent IP address to requesting client.
Dynamic: DHCP server "leases" IP address to requesting client. The IP address is only valid for a limited period of time;
after which the client must request a renewal or ask for a new IP address.
By far the most common (and most detailed) method is the dynamic method, which we'll focus our attention on. A typical sequence for a new client requesting an IP address is shown in the diagrams.below. Please note that this depiction shows the DHCP server located on a different network segment than the new client. But it's not required to be that way.
Example
[edit | edit source]Figure 1
In figure 1, a new client that just joined the network, needs an IP address. Since it does not know the DHCP server's location, the client broadcasts (step 1) a DHCPDISCOVER message on the local network. The message packet contains a hardware identifier (usually the MAC address), the source port (68), the destination IP (255.255.255.255), destination port (67), and a randomly generated transaction id. Optionally the client can specify the IP address it wants and the lease duration in the message. Once the DHCP relay receives the broadcasted message, it fills in the "giaddr" field of the packet with the gateway IP address of 10.1.2.9 . This piece of information is critical because the DHCP Server needs it to determine which subnet the client is on and thus which IP address to allocate to the client. Afterwards the DHCPDISCOVER message is relayed to the DHCP Server via unicast (step 2). A unicast, instead of a broadcast, is sufficient because the DHCP relay knows the exact location of the DHCP server. For this same reason, the DHCP relay does not allow the other network segment, 10.1.1.X, to receive the message.
Once the DHCP server receives the DHCPDISCOVER request, it allocates an IP address, marks it as taken, and then broadcasts a DHCPOFFER message back to the requesting client. This message packet contains the DHCP server's IP address, the client's hardware identifier, the same transaction id, and the IP address allocated for the client. Optionally, the message may also contain the lease time, subnet mask, default TTL, default router(s), and numerous other parameters.
Figure 2
In figure 2, the DHCP server allocates new IP address 10.1.2.3 for the client and broadcasts a DHCPOFFER message to its network (step 3). When the DHCP relay sees the DHCPOFFER broadcast, it relays the broadcast to the 10.1.2.X network and only that network (step 4). Once the new client sees the DHCPOFFER message, it accepts the IP address (step 5) and prepares a confirmation message to the DHCP server with a DHCPREQUEST packet. Please note that the client does not have to accept this IP address, in which case it will not send a DHCPREQUEST message. If multiple DHCP servers sends out a DHCPOFFER, the client can choose which one to accept. If for some reason, the DHCPOFFER message fails to ever arrive, the client will rebroadcast the DHCPDISCOVER message.
Figure 3
If the client included optional information in the initial DHCPDISCOVER message, it must include that same information in the subsequent DHCPREQUEST message. In step 6 of figure 3, the new client confirms it wants the IP address 10.1.2.3 by broadcasting a DHCPREQUEST to the DHCP server. Once the DHCP Server receives this message (with help again from the DHCP Relay), it first ensures that it is the intended target - because the client could be responding to another DHCP Server. If this DHCP server is not the intended target, then it knows some other DHCP server is handling this client. So this DHCP server can discard any previously allocated IP address for that client. If this DHCP Server is the intended recipient, then it has to verify the optional parameters that it specified in the previous DHCPOFFER message to this client, are still valid. Assuming everything is fine up to this point, the DHCP Server sends a DHCPACK broadcast (step 8) to tell the client that its new IP address can now officially be used. However, if something is wrong, then a DHCPNACK is broadcasted instead. Either way, a DHCPACK or DHCPNACK will be the final message sent by the DHCP server in the dynamic IP address allocation sequence..
Assuming it receives the DHCPACK relayed by the router (step 9), the client is encouraged to verify no other hosts has the same IP address. This is usually accomplished through a simple ARP probe. Any response to the probe means that another client is already using the IP address. In such a situation, the client must send a DHCPDECLINE message to the DHCP server. Afterwards the client will then need to restart this whole process beginning with DHCPDISCOVER phase. In most cases, there's no response to the client's ARP probe. This means the client can go ahead and use the allocated IP address along with any other optional information stored in the message packet.
If the client got a DHCPNAK instead of DHCPACK, then it has no choice but to restart everything from the very beginning i.e. the DHCPDISCOVER stage. Finally, if the client doesn't receive any DHCPACK or DHCPNAK message after a certain period of time, then it rebroadcasts the DHCPREQUEST message.
Other DHCP Messages
[edit | edit source] IP Renewal: If the client wishes to renew its existing IP address (usually because of expiring lease), it unicasts a special
DHCPREQUEST message that indicates it's renewing (and not asking for new) IP address. The DHCP server can choose
to extend the lease or reject it. Either way, it must inform the client via a DHCPACK message.
Release IP: The client can request its current IP address be relinquished by issuing a DHCPRELEASE message (via unicast) to
the DHCP server. The message packet must contain the IP address and the hardware identifier of the client. Upon
receipt, the DHCP server marks the client's IP address as unallocated.
Inform: The client already has an IP address but needs additional configuration parameters, such as default TTL, subnet
mask, etc. So it sends a DHCPINFORM message to the DHCP server. In response, the DHCP server unicasts a DHCPACK
Security Concerns
[edit | edit source]DHCP is inherently insecure because there's no authentication mechanism built in. Here are a few examples of security weaknesses.
Problem: The DHCP server does not know if requests are from a legitimate new client or a rogue host pretending to be one.
Impact: This could lead to IP addresses allocated to spoofed MAC addresses that don't exist, and eventually exhaust the pool
of legitimate IP addresses. Thus new hosts cannot added to the network.
Solution: Manually assign IP addresses or manually verify every new client requesting IP address. Can also audit the DHCP
database. But these are all fairly time-consuming. No simple way to address this issue.
Problem: A new client doesn't know if responses are coming from real DHCP server or rogue host pretending to be a DHCP server.
Impact: If the client accepts all the information given to it by the rogue DHCP server, then false information (e.g. bad
subnet mask) could render the client useless.
Solution: Can identify fake DHCP servers by using security tools that send out DHCPDISCOVER & DHCPREQUEST messages and flag any
suspicious information returned.
Summary
[edit | edit source]Dynamic Host Configuration Protocol (DHCP) is a convenient, though insecure, technique to assign an IP address to a host newly added to a network. It can also be used to extend the lease period of an existing IP address, drop the IP address of a host, or provide initial configuration parameters to a requesting host.
Exercises
[edit | edit source]Question:
- Using the example illustrated in the DHCP section, explain how the interaction between the new client and the DHCP Server would change if the DHCP Server is located on the same network segment as the new client.
- (T/F) Once a new client receives the IP address after the DHCPOFFER, the client should verify no other hosts are using that IP address.
Answer:
- The only difference would be the DHCP Relay not getting involved. Thus the DHCP Server receives broadcasts instead of unicasts, and the "igaddr" field of the message packet wil be empty.
- False - the client must wait until DHCPACK (not DHCPOFFER) because the IP address is not officially assigned to the new client until DHCPACK is received.
References
[edit | edit source]http://tools.ietf.org/html/rfc2131
http://www.windowsecurity.com/articles/DHCP-Security-Part1.html
http://www.eventhelix.com/RealtimeMantra/Networking/DHCP.pdf