As defined in RFC 768, a UDP is a connection-less protocol, which is great for transmitting real-time data between hosts and is often termed as an unreliable form of communication. The reason for this is that UDP doesn't care about the delivery of packets, and any lost packets are not recovered because the sender is never informed about the dropped or discarded packets during transmission. However, many protocols such as DHCP, DNS, TFTP, SIP, and so on rely only on this. The protocols that use a UDP as a transport mechanism have to rely upon other techniques to ensure data delivery and error-checking capabilities. And these protocols are inbuilt with such features, which can provide some level of reliability during the transmission. A point that we should not to forget is that a UDP provides faster transmission of packets as it is not concerned about the initiation of the connection or graceful termination as seen in the TCP. That's why a UDP is also referred to as a transaction-oriented protocol and not a message-oriented protocol like a TCP.
The size of a usual UDP header is 8 bytes; the data that is added with the header can be theoretically 65,535 (practically 65,507) bytes long. A UDP header is quite small when compared to a TCP header; it has just four common fields: Source Port, Destination Port, Packet Length, and Checksum. Refer to the UDP header shown here:
- Source port: This is the port number used by the sending side to receive any replies if needed. Most of the time, in a TCP and UDP, the port number chosen to be the part of the socket is ephemeral. On the other side of the communication, the port number comes in the category of well-known port numbers.
- Destination port: This field of the header identifies the port number used by the server or receiving side, and all data will be transmitted to this port. This port number is assigned to a particular service by IANA, and definitely, it is permanently assigned to the same service specifically. For example, port
53is for DNS and cannot be assigned to any other service (not advisable). - Packet length: This field specifies the length of the packet, starting from the header to the end of the data; the minimum length you will observe will be 8 bytes every time, that is, the length of the UDP header.
- Checksum: As discussed earlier, checksum is performed over data, that is, the packet of the packet to ensure data integrity that is what is sent from the sender side is the same what receiver got and to verify this there are couple of checksum algorithms which comes to the rescue. Sometimes, while working with a UDP, you will see that the checksum value is
0in the packet we received. This means that the checksum is not required to be validated.
To understand the way a UDP works, let's go ahead and analyze some of the protocols that use a UDP as a delivery protocol. First, I would like to discuss DHCP, and then we will see DNS traffic as well. We actually saw UDP traffic before as well while we were going through VOIP and SIP analysis.
For analysis purpose, I have a default gateway configured at 192.168.1.1 and a client at 192.168.1.106. Using the client, I will try to generate DHCP and DNS traffic, which will be captured in Wireshark, and then, I will try to dissect each protocol's communication process as well as the different components utilized during the whole session. Refer to the following network architecture that I have:
The most common and important protocol that assigns IP addresses to devices and makes them network compatible is Dynamic Host Configuration Protocol (DHCP). Now, from the client, I will try to release the IP address that the client already holds, which will generate a DHCP packet, and the same will be captured by our sniffer. Look at the following figure to understand this:
In the list pane, we can see a DHCP release packet that was generated implicitly by the client in order to release the current IP address (I used the dhclient –v –r command on the Linux terminal to release the IP address, but be careful while using this command as it may disconnect your machine from the network, hence making it incompatible for network communication). The client from the IP address 192.168.1.106 to the server at 192.168.1.1 initiates the request. The port numbers used by the client and server in case of DHCP are permanent, these won't be changed in your case either unless they are manually configured.
The DHCP server port number is 67 and the DHCP client port number is 68 by default; you can see the same in the preceding figure (highlighted as 3). There is a fourth field that I have highlighted, the packet length field, which specifies the length of the packet starting from the first byte until the end of data in the packet. However, out of 308 bytes, 8 bytes show the length of the UDP header and the remaining 300 bytes represent the application data that is appended. Interestingly, if a machine is power cycled, it will request the DHCP server to allocate an IP address. This, as a result, will generate a couple of packets related to the DHCP request, release, and offer and various others that will also use the UDP as a transport mechanism.
I filtered the packets listed to show only DHCP packets using the udp.port==67 filter; as a result, only DHCP packets will be listed in the list pane.
The Trivial File Transfer Protocol (TFTP) is a lightweight version of the FTP that is used to transfer between hosts. Unlike the FTP protocol, TFTP does not ask users for any credentials. A TFTP uses a UDP as a transport mechanism. Most commonly, a TFTP is used in LAN environments, and when dealing with manageable devices such as switches and routers, network administrators do use TFTP servers to take a back up of configuration files and to update the firmware running in those devices. A TFTP is also used by security professionals to transfer files from their system to yours in order to escalate the privileges (gaining more rights on a compromised system).
I have a TFTP server running at 192.168.1.106 and a client running at 192.168.1.104. There is a text file abc.txt that I've created on the server, and the client will try to download the same. And our sniffer in place will capture the traffic that is generated.
The traffic generated due to the transaction that takes place between two hosts is successfully captured and the packets corresponding to it are shown in the following figure:
Now, let's see what each pointer signifies:
- This shows that the transfer of the packet is initiated as soon as the client requests the
abc.txtfile. The request frame can be seen in the list pane. - As discussed, a TFTP uses a UDP for a transport mechanism. The related details for the request are shown in the details pane, which states that the request was initiated from a ephemeral port number from the client destined to port
69on the server (69is a well-known port to the TFTP protocol). - The request was specific to the
abc.txtfile that is also shown in the details pane in the TFTP protocol section.
You must be wondering about the acknowledgement packets that are shared between the two hosts. As we discussed, a UDP is an unreliable form of communication, so why are we seeing ACKs in a UDP? The reason is that the TFTP server I am using has some kind of inbuilt reliability feature. Even on the client side, over the standard console, after initiating the request, I received quite interactive messages from the server, such as the file of size 3 bytes has been transferred successfully, and various other details were listed along with the message. The interesting thing to know here is that port 69 was only involved in the first packet, and the rest of the packets were sent and received by the acknowledging feature that the server is embedded with. So, the statement that some protocols use a UDP as a transport protocol and have their own inbuilt feature to ensure delivery is true, as we have just witnessed.
Suppose that the resource we are looking for is not available on the server. How will traffic look like then? Refer to the following screenshot to understand this:
As seen in the preceding screenshot, the client requested an invalid resource that the server wasn't able to locate and hence returned with an error code and the summary message File not found. The same message was shown over the standard console to the client.
Sometimes, it is also possible that the server daemon may not run and the client may request a certain resource. In such cases, the client would receive the ICMP destination unreachable error with the error code 3. Refer to the following figure for the same:
Now, we will see what each pointer signifies:
- The server returned with an
ICMP destination unreachablemessage when the TFTP server daemon was not functional - The client received an error code of type
3 - The details regarding the request were mentioned in the reply under the UDP protocol section, which stated that the request was sent to port
69, which was currently nonfunctional - The requested resource was shown under the TFTP protocol section
Unusual DNS requests are also very often seen when a client initiates a request to look for name servers associated with an address. It would look similar to the one shown in the following figure:
Now, we will see what each pointer signifies:
- 1: As seen in the list pane, the client at
192.168.1.106initiated a request to look for the address8.0.0.0and received a response inFrame 2 - 2: The request was sent to the default gateway that holds the DNS cache
- 3: The gateway responded with a
No such nameerror
There can be multiple scenarios where you will see unusual traffic related to a UDP. The most important thing to look for is TFTP traffic, which might be generated because of a the TFTP client in your network. It may be malicious traffic that you would like to make a note of.