8
TRANSPORT LAYER PROTOCOLS

In this chapter, we’ll continue to examine individual protocols and how they appear at the packet level. Moving up the OSI model, we’ll look at the transport layer and the two most common transport protocols, TCP and UDP.

Transmission Control Protocol (TCP)

The ultimate goal of the Transmission Control Protocol (TCP) is to provide endto-end reliability for the delivery of data. TCP, which is defined in RFC 793, handles data sequencing and error recovery, and ultimately ensures that data gets where it’s supposed to go. TCP is considered a connection-oriented protocol because it establishes a formal connection before transmitting data, tracks packet delivery, and usually attempts to formally close communication channels when transmission is complete. Many commonly used application-layer protocols rely on TCP and IP to deliver packets to their final destination.

TCP Packet Structure

TCP provides a great deal of functionality, as reflected in the complexity of its header. As shown in Figure 8-1, the following are the TCP header fields:

Source Port   The port used to transmit the packet.

Destination Port   The port to which the packet will be transmitted.

Sequence Number   The number used to identify a TCP segment. This field is used to ensure that parts of a data stream are not missing.

Acknowledgment Number   The sequence number that is to be expected in the next packet from the other device taking part in the communication.

Flags   The URG, ACK, PSH, RST, SYN, and FIN flags for identifying the type of TCP packet being transmitted.

Window Size   The size of the TCP receiver buffer in bytes.

Checksum   Used to ensure the contents of the TCP header and data are intact upon arrival.

Urgent Pointer   If the URG flag is set, this field is examined for additional instructions for where the CPU should begin reading the data within the packet.

Options   Various optional fields that can be specified in a TCP packet.

Figure 8-1: The TCP header

TCP Ports

All TCP communication takes place using source and destination ports, which can be found in every TCP header. A port is like the jack on an old telephone switchboard. A switchboard operator would monitor a board of lights and plugs. When a light lit up, he would connect with the caller, ask who she wanted to talk to, and then connect her to the other party by plugging in a cable. Every call needed to have a source port (the caller) and a destination port (the recipient). TCP ports work in much the same fashion.

To transmit data to a particular application on a remote server or device, a TCP packet must know the port the remote service is listening on. If you try to access an application on a port other than the one configured for use, the communication will fail.

The source port in this sequence isn’t incredibly important and can be selected randomly. The remote server will simply determine the port to communicate with from the original packet it’s sent (see Figure 8-2).

Figure 8-2: TCP uses ports to transmit data.

There are 65,535 ports available for use when communicating with TCP. We typically divide these into two groups:

•     The system port group (also known as the standard port or well-known port group) is from 1 through 1023 (ignoring 0 because it’s reserved). Well-known, established services generally use ports that lie within the system port grouping.

•     The ephemeral port group is from 1024 through 65535 (although some operating systems have different definitions for this). Only one service can communicate on a port at any given time, so modern operating systems select source ports randomly in an effort to make communications unique. These source ports are typically located in the ephemeral range.

Let’s examine a couple of TCP packets and identify the port numbers they are using by opening the file tcp_ports.pcapng. In this file, we have the HTTP communication of a client browsing to two websites. As mentioned previously, HTTP uses TCP for communication, making it a great example of standard TCP traffic.

In the first packet in this file (see Figure 8-3), the first two values represent the packet’s source port and destination port. This packet is being sent from 172.16.16.128 to 212.58.226.142. The source port is 2826 ➊, an ephemeral port. (Remember that source ports are chosen at random by the operating system, although they can increment from that random selection.) The destination port is a system port, port 80 ➋, the standard port used for web servers using HTTP.

Figure 8-3: The source and destination ports can be found in the TCP header.

Notice that Wireshark labels these ports as slc-systemlog (2826) and http (80). Wireshark maintains a list of ports and their most common uses. Although system ports are primarily the ones with labeled common uses, many ephemeral ports have commonly used services associated with them. The labeling of these ports can be confusing, so it’s typically best to disable it by turning off transport name resolution. To do this, go to Edit ▶ Preferences ▶ Name Resolution and uncheck Enable Transport Name Resolution. If you wish to leave this option enabled but want to change how Wireshark identifies a certain port, you can do so by modifying the services file located in the Wireshark system directory. The contents of this file are based on the IANA common ports listing (see “Using a Custom hosts File” on page 86 for an example of how to edit a name resolution file).

The second packet is sent back from 212.58.226.142 to 172.16.16.128 (see Figure 8-4). As with the IP addresses, the source and destination ports are now also switched ➊.

In most cases, TCP-based communication works the same way: a random source port is chosen to communicate to a known destination port. Once this initial packet is sent, the remote device communicates with the source device using the established ports.

This sample capture file includes one more communication stream. See if you can locate the port numbers it uses for communication.

Figure 8-4: Switching the source and destination port numbers for reverse communication

The TCP Three-Way Handshake

All TCP-based communication must begin with a handshake between two hosts. This handshake process serves several purposes:

•     It allows the transmitting host to ensure that the recipient host is up and able to communicate.

•     It lets the transmitting host check that the recipient is listening on the port the transmitting host is attempting to communicate on.

•     It allows the transmitting host to send its starting sequence number to the recipient so that both hosts can keep the stream of packets in proper sequence.

The TCP handshake occurs in three steps, as shown in Figure 8-5. In the first step, the device that wants to communicate (host A) sends a TCP packet to its target (host B). This initial packet contains no data other than the lower-layer protocol headers. The TCP header in this packet has the SYN flag set and includes the initial sequence number and maximum segment size (MSS) that will be used for the communication process. Host B responds to this packet by sending a similar packet with the SYN and ACK flags set, along with its initial sequence number. Finally, host A sends one last packet to host B with only the ACK flag set. Once this process is completed, both devices should have all of the information they need to begin communicating properly.

To see this process in action, open tcp_handshake.pcapng. Wireshark includes a feature that replaces the sequence numbers of TCP packets with relative numbers for easier analysis. For our purposes, we’ll disable this feature in order to see the actual sequence numbers. To disable this, choose Edit ▶ Preferences, expand the Protocols heading, and choose TCP. In the window, uncheck the box next to Relative Sequence Numbers and click OK.

Figure 8-5: The TCP three-way handshake

The first packet in this capture represents our initial SYN packet ➋ (see Figure 8-6). The packet is transmitted from 172.16.16.128 on port 2826 to 212.58.226.142 on port 80. We can see here that the sequence number transmitted is 3691127924 ➊.

The second packet in the handshake is the SYN/ACK response ➌ from 212.58.226.142 (see Figure 8-7). This packet also contains this host’s initial sequence number (233779340) ➊ and an acknowledgment number (3691127925) ➋. The acknowledgment number shown here is 1 more than the sequence number included in the previous packet, because this field is used to specify the next sequence number the host expects to receive.

The final packet is the ACK ➋ packet sent from 172.16.16.128 (see Figure 8-8). This packet, as expected, contains the sequence number 3691127925 ➊ as defined in the previous packet’s Acknowledgment number field.

A handshake occurs before every TCP communication sequence. When you are sorting through a busy capture file in search of the beginning of a communication sequence, the sequence SYN-SYN/ACK-ACK is a great marker.

Figure 8-6: The initial SYN packet

Figure 8-7: The SYN/ACK response

Figure 8-8: The final ACK

TCP Teardown

Most greetings eventually have a good-bye and, in the case of TCP, every handshake has a teardown. The TCP teardown is used to gracefully end a connection between two devices after they have finished communicating. This process involves four packets, and it utilizes the FIN flag to signify the end of a connection.

In a teardown sequence, host A tells host B that it is finished communicating by sending a TCP packet with the FIN and ACK flags set. Host B responds with an ACK packet and transmits its own FIN/ACK packet. Host A responds with an ACK packet, ending the communication. This process is illustrated in Figure 8-9.

Figure 8-9: The TCP teardown process

To view this process in Wireshark, open the file tcp_teardown.pcapng. Beginning with the first packet in the sequence (see Figure 8-10), you can see that the device at 67.228.110.120 initiates teardown by sending a packet with the FIN and ACK flags set ➊.

Figure 8-10: The FIN/ACK packet initiates the teardown process.

Once this packet is sent, 172.16.16.128 responds with an ACK packet to acknowledge receipt of the first packet, and it sends a FIN/ACK packet. The process is complete when 67.228.110.120 sends a final ACK. At this point, the communication between the two devices ends. If they need to begin communicating again, they will have to complete a new TCP handshake.

TCP Resets

In an ideal world, every connection would end gracefully with a TCP tear-down. In reality, connections often end abruptly. For example, a host may be misconfigured, or a potential attacker may perform a port scan. In these cases, when a packet is sent to a device that is not willing to accept it, a TCP packet with the RST flag set may be sent. The RST flag is used to indicate that a connection was closed abruptly or to refuse a connection attempt.

The file tcp_refuseconnection.pcapng displays an example of network traffic that includes an RST packet. The first packet in this file is from the host at 192.168.100.138, which is attempting to communicate with 192.168.100.1 on port 80. What this host doesn’t know is that 192.168.100.1 isn’t listening on port 80 because it’s a Cisco router with no web interface configured. There is no service configured to accept connections on that port. In response to this attempted communication, 192.168.100.1 sends a packet to 192.168.100.138 telling it that communication won’t be possible over port 80. Figure 8-11 shows the abrupt end to this attempted communication in the TCP header of the second packet. The RST packet contains nothing other than RST and ACK flags ➊, and no further communication follows.

Figure 8-11: The RST and ACK flags signify the end of communication.

An RST packet ends communication whether it arrives at the beginning of an attempted communication sequence, as in this example, or is sent in the middle of the communication between hosts.

User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is the other layer 4 protocol commonly used on modern networks. While TCP is designed for reliable data delivery with built-in error checking, UDP aims to provide speedy transmission. For this reason, UDP is a best-effort service, commonly referred to as a connectionless protocol. A connectionless protocol doesn’t formally establish and terminate a connection between hosts, unlike TCP with its handshake and teardown processes.

With a connectionless protocol, which doesn’t provide reliable services, it would seem that UDP traffic would be flaky at best. That would be true, except that the protocols that rely on UDP typically have their own built-in reliability services or use certain features of ICMP to make the connection somewhat more reliable. For example, the application-layer protocols DNS and DHCP, which are highly dependent on the speed of packet transmission across a network, use UDP as their transport layer protocol, but they handle error checking and retransmission timers themselves.

UDP Packet Structure

The UDP header is much smaller and simpler than the TCP header. As shown in Figure 8-12, the following are the UDP header fields:

Source Port   The port used to transmit the packet

Destination Port   The port to which the packet will be transmitted

Packet Length   The length of the packet in bytes

Checksum   Used to ensure that the contents of the UDP header and data are intact upon arrival

Figure 8-12: The UDP header

The file udp_dnsrequest.pcapng contains one packet. This packet represents a DNS request, which uses UDP. When you expand the packet’s UDP header, you’ll see four fields (see Figure 8-13).

Figure 8-13: The contents of a UDP packet are very simple.

The key point to remember is that UDP does not care about reliable delivery. Therefore, any application that uses UDP must take special steps to ensure reliable delivery, if it is necessary. This is in contrast to TCP, which utilizes a formal connection setup and teardown, and has features in place to validate that packets were transmitted successfully.

This chapter has introduced you to the transport layer protocols TCP and UDP. Not unlike network protocols, TCP and UDP are at the core of most of your daily communication, and the ability to analyze them effectively is critical to becoming an effective packet analyst. In Chapter 9, we will look at common application-layer protocols.