Exploring DHCP Requests

-
In this article I would like to explore DHCP requests so that we can understand what happens when a device sends a request to a DHCP server.
Lets start by listing some important information about DHCP…..
  1. DHCP is the abbreviation for Dynamic Host Configuration Protocol
  2. DHCP uses UDP 67 & 68 – 67 – In a client-server environment port 67 is the BOOTP for the DHCP server and 68 is the BOOTP for the client
  3. The purpose of DHCP is to assign IP addresses automatically to the device that has requested an IP address
How does the client interact with the DHCP server?
In short…
  1. The client sends a DISCOVER frame asking for an IP address
  2. The DHCP server responds with an OFFER which contains an IP address and additional information
  3. The client sends a REQUEST to use the IP address contained in the OFFER
  4. The DHCP server ACKNOWLEDGES the request to use the IP address
The above process is what happens on the surface however there is a lot more going on if we take a look at the frames using Wireshark.
Behind the scenes of a DHCP request…
Below is the topology we are going to work from to explain the DHCP process in depth.
Image .1
The client on the left doesn’t have an IP address yet and would like to request one from the DHCP server located at 10.0.4.4. The switches are configured with ip helper-addresses to relay DHCP information. ESW1 has a VLAN 10 static IP address of 10.0.0.2. The ip helper-address and ESW1 IP address are only relevant so I can explain the Wireshark capture pictured below.
Image.2
 
We have a lot of detail to cover so I will break each frame down using the numbers (No.) in the above image and then within those numbers we will examine the information further.
Frame Number 383.
This is the first frame sent by the client when requesting an IP address automatically. On the surface of image .2 we can see that the source IP address is 0.0.0.0, the destination IP address is 255.255.255.255, the protocol is DHCP and in the info we can see that it is a DHCP Discover message.
The reason the client has a source IP address of 0.0.0.0 is because it doesn’t currently have a layer 3 address. The client doesn’t know the IP address of the DHCP server so it sends the frame with a destination IP address of 255.255.255.255 which is a broadcast address.
If we look at image .3 below, we start by examining the Layer 2 information. As with the client not knowing the destination IP address, it also doesn’t know the destination MAC address so it too sets the destination MAC address to a broadcast of ff:ff:ff:ff:ff:ff.
Image .3
 
If we now take a look at the Layer 3 information in Image .4 we can see that the source IP address is set to 0.0.0.0 and this is because the client doesn’t currently have an I P address. The destination address is set to 255.255.255.255 and this is because the client doesn’t know the destination address of the DHCP server so it sends it to the broadcast L3 address.
Image .4
 
If we take a look at the protocol and port information in Image.5 we can see the source port that the DHCP Request has originated, Port 68. The destination port is that of a DHCP server and the protocol is UDP which is connection-less.
Image .5
The last field in the Discover frame is the Bootstrap protocol. The BOOTP protocol is defined in RFC 951 as a protocol that assigns IP addresses and other information to networking devices.
If we look at the BOOTP fields in Image .6 we can see much of the information we have already identified along with option fields. In option (12) we can see that the client has been identified as SALES1. Much of this information will change in the frames we examine later on.
Image .6
 
This concludes Frame number 383 which was the DHCP Discover frame, we will now move onto the DHCP Offer packet number 385.
 For Packet number 385 I have missed out the Layer 1 and Layer 2 information as there isn’t anything particular interesting to explore. In Image 7. we start with the Layer 3 information and we can see the original source IP address of the ESW1 switch. If we look at the Destination IP address, you will see 10.0.0.51, this IP address is the one being offered to the client by the DHCP server.
Image .7
 
Moving onto the Layer 4 information in Image .8 we can see some UDP information that is worth explaining. As the DHCP Offer is flowing back to the client PC from the server we can see that the Source port is 67 and the Destination port is 68. All we need to know about these two port numbers is that 67 is the bootstrap protocol (BOOTP) from the server and 68 is the bootstrap protocol (BOOTP) for the client.
Image .8
 
Image .9 shows some very interesting information about the DHCP offer packet. If we look at the ‘Client IP address’ field we can see that the client still doesn’t have an IP address until this packet reaches the client and requests to have the IP address of 10.0.0.51 shown in ‘Your (client) IP Address’ field.
The ‘Relay agent IP address’ field shows the IP address for the ESW1 switch as this is acting as the DHCP relay device.
Skipping over some of the details we can see the subnet mask of the host in ‘Option (1)’ , we also see further down some more options that include the renewal information, lease time and DHCP server identifier.
This concludes the inspection of the DHCP Offer packet 383, we will now have a look at what happens when the client receives the offer and chooses to accept the IP address.
Image .9
 
So the client has now received the DHCP Offer and would like to accept the IP address 10.0.0.51 that the server offered. To do this the client first needs to respond to the server via the DHCP Request packet shown in Image.10.
If we look at the Layer 3 information we can see that the client still hasn’t been assigned the 10.0.0.51 IP Address, this is because it doesn’t happen until the server acknowledges the Request packet. So the request message is still sent in this case as a Broadcast message on the network with a destination IP address of 255.255.255.255.
Image .10
 
Looking at the Layer 4 information in Image .11 we can see that the Source port is 68 and the Destination port is 67. As mentioned earlier in this post, these port numbers represent the BOOTP Client and BOOTP Server.
Image .11
 
Now this is where the inspection gets slightly more interesting with the DHCP Request packet. In Image .12 we can see that although the field ‘Next server IP Address’ shows the IP address of 0.0.0.0, further down in the options we see that the ‘DHCP Server Identifier’ shows the server address of 10.0.4.4. In ‘Option 50’ we see the requested IP address information that the client would like and further down we see the hostname of the client machine.
‘Option 55’ displays some additional information that the client would like to request, in this case we can see that the client would like the following:
  1. Subnet Mask
  2. Router (I believe this is the gateway information)
  3. DNS settings
  4. Domain name
All this information makes up the DHCP Request packet so now we will take a look at what happens when the server receives the request and what it does next.
Image .12
 
So now that the server has received the DHCP Request we just talked about the server sends an Acknowledgement to the client as shown in Image .13. If we take a look at the Layer 3 information we can see that the server sends the Acknowledgment packet to ESW1 switch at 10.0.0.2 who will then forward onto the client.
Image .13
 
The Layer 4 information in Image .14 shows that the source port and destination port is the same for the Acknowledgement packet and I believe this is because the server is just sending and ACK only.
Image .14
 
If we look at the last section of the Acknowledgement packet we can see that the server has sent all the additional information the client requested in the last packet. Then the last image named Image .16 shows ESW1 forward the ACK packet onto the client. This then completes the DORA process and the assignment of the dynamic IP Address to the client is complete.
Image .15
Image .16
 
I hope you have found this post useful, if you have any questions please drop us a comment.
Kelvin Charles - Network and Cyber Security Professional.

Popular Posts

Capturing EAPOL and RADIUS Using Wireshark

-
Image
In this article we are going to take a look at how to capture Extensible Authentication Protocol Over LAN (EAPOL) and Remote Authentication Dial-In User Service (RADIUS) packets using Wireshark. This article can be useful for troubleshooting 802.1x within your environment and can also be used for learning purposes. The following topology has been used to gather the required output for this article. Note: This article will only cover the switch configurations that are required to gather EAPOL and RADIUS configuration. Overview of the Topology The supplicant is configured to perform 802.1x using EAP-TLS as the authentication method The user certificate on the supplicant will be used for authentication The supplicant has Wireshark installed Cisco ISE is used for authentication and authorisation The supplicant is assigned to VLAN 10 upon authentication and all other endpoint ports are assigned to VLAN 99 Sniffer device is running Wireshark in order to capture RADIUS flows via SPAN 802.1x
Read more

Configuring Cisco Smart License Software

-
In this article, I would like to demonstrate how to configure Cisco Smart Licensing on the virtual Cisco Adaptive Security Appliance (ASAv). This post assumes that readers already have access to there own Smart Account and would like to know the process of applying licenses. Step 1: Generate ID Token Sign into your Cisco Software Portal: software.cisco.com and navigate to “Smart Software Licensing” You will now need to create an ID token for your device, this is required for communication between the device and the licensing authority. Follow the steps below to create a new token. Click Inventory >>> General >>> New Token and select your preferred options and enter a description for your token. Once you are happy with your token settings click Create Token . You should now have a token created which can be copied over to the device you wish to license. All commands and output from this point will be related to the ASA so please seek out further advice if you wish
Read more

Cisco :: FXOS Authentication Using TACACS

-
In this article, I will describe how to enable authentication and authorization for Firepower eXtensible Operating System (FXOS) devices. The use case presented in this document illustrates how Cisco Identity Services Engine (ISE) can be utilised with attribute-value pairs (AV-Pairs) to authenticate and authorize users accessing the Firepower Chassis Manager (FCM) or FXOS platforms via TACACS+. At the time of writing this post, I found that limited documentation existed and of that documentation that did exist, the examples given weren’t as straightforward. In an effort to make this process easier for my colleagues and customers to understand I have put together the following instructions based on a previous use case given to me. Extracts of this document have been taken from a wider document I am currently creating. I will update this article with the complete document when it has been finalized. Requirements A ‘Device Administration’ license is required in order to use TACACS+ with
Read more

Configuring Remote Access VPN on Firepower

-
Image
In this article we are going to take a look at how to configure remote access VPN's on Firepower devices. This demonstration is based on the following lab environment: Cisco Virtual Firepower Management Center Cisco Virtual Firepower Threat Defense Cisco ISE 2.6 Windows host with AnyConnect VPN Windows Server 2019 (CA Server) All Firepower devices are running version 6.5 Note: ISE is used for authentication and authorization in the following lab however the configuration elements of ISE are out of scope for this demonstration. Generate a CSR for Remote Access VPN's Those accessing your network remotely need to trust the service you're running. Without the correct trust users could face issues connecting via VPN. With access to the FMC navigate to Objects > Object Management > PKI > Cert Enrollment Assuming you are opting for manual enrollment, select 'Manual' in Enrollment Type and copy the CA Certificate BASE-64 into the field. Now select the 'Certifi
Read more

Kali Linux :: CAM Table Overflow Attack Demonstration

-
Image
As part of my on-going studying for the CCNA Security 210 – 260 certification I have been exploring different types of network attacks, one of which is CAM table overflow attacks. In this article I would like to share what I have learnt and provide a demonstration of the attack carried out in a lab environment. To understand my demonstration, you first need to understand how a CAM table overflow attack works and what happens as a result of the attack.   Switches build Content Addressable Memory (CAM) tables based on mac-addresses and port numbers. When a switch receives a frame it checks the table to see if the source mac-address is already known, if the source mac-address is unknown the switch will add the mac-address to the table along with the port number. The switch then checks the destination layer two frame and if no entry exists the switch broadcasts the frame out of all ports except the port in which the frame was received. Presuming the destination mac-address wants to respond
Read more