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, operates at layer 4 of the OSI model. It handles data sequencing and error
recovery, and ultimately ensures that data gets where it is supposed to go. A lot of commonly used application-layer protocols rely on TCP and IP to deliver packets to their final destination.
The TCP Header
TCP provides a great deal of functionality, as reflected in the complexity ofits header. As shown in Figure 6-16, 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 6-16: 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 her destination 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.
In order 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 is not incredibly important and can be selected randomly. The remote server will simply determine the port to communicate with from the original packet it is sent (see Figure 6-17).
Figure 6-17: 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:
1. The standard port group is from 1 through 1023 (ignoring 0 because it is reserved). Particular services use standard ports, which generally lie within the standard port grouping.
2. 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 different TCP packets and identify the port numbers they are using by opening the file tcp_ports.pcap. In this file, we have the HTTP communication of a client browsing to two websites. As mentioned previously, HTTP uses TCP for communication, which makes it a great example of standard TCP traffic.
In the first packet in this file (see Figure 6-18), 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 standard port, port 80 , the standard port used for web servers using HTTP.
Figure 6-18: The source and destination ports can be found in the TCP header.
The second packet is being sent back from 212.58.226.142 to 172.16.16.128 (see Figure 6-19). As with the IP addresses, the source and destination ports are now also switched.
Figure 6-19: The source and destination port numbers are switched for reverse communication
All 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.
There is one more communication stream included in this sample capture file. See if you can locate the port numbers it uses for communication.
TIPS As we progress through this book, you will learn more about the ports associated with common protocols and services. Eventually, you will be able to profile services and devices by the ports they use. For a thorough list of common ports, see http://www.iana.org/assignments/port-numbers/.
The TCP Three-Way Handshake
All TCP-based communication must begin with a handshake between two hosts. This handshake process serves a few different purposes:
1. It allows the transmitting host to ensure that the destination host is up and able to communicate.
2. It lets the transmitting host check that it is listening on the port on which the source is attempting to communicate.
3. 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 separate steps, as shown in Figure 6-20. 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.
Figure 6-20: The TCP three-way handshake
TIPS TCP packets are often referred to by the flags they have set. For example, rather than refer to a packet as a TCP packet with the SYN flag set, we call that packet a SYN packet. As such, the packets used in the TCP handshake process are referred to as SYN, SYN/ACK, and ACK.
To see this process in action, open tcp_handshake.pcap. The first packet in this capture represents our initial SYN packet (see Figure 6-21). 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 .
Figure 6-21: The initial SYN packet
The second packet in the handshake is the SYN/ACK response from 212.58.226.142 (see Figure 6-22). This packet also contains this host’s initial sequence number (233779340) and an acknowledgment number (3691127925) . The acknowledgment number shown here is one 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.
Figure 6-22: The SYN/ACK response
The final packet is the ACK packet sent from 172.16.16.128 (see Figure 6-23). This packet, as expected, contains the sequence number 3691127925 as defined in the previous packet’s Acknowledgment Number field.
Figure 6-23: The final ACK
A handshake occurs before every TCP communication sequence. When sorting through a busy capture file in search of the beginning of a communication sequence, the sequence of SYN-SYN/ACK-ACK is a great marker.
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 process. This process is illustrated in Figure 6-24.
Figure 6-24: The TCP teardown process
To view this process in Unicorn, open the file tcp_teardown.pcap. Beginning with the first packet in the sequence, (see Figure 6-25), you can see that the device at 67.228.110.120 initiates the teardown sequence by sending a packet with the FIN and ACK flags set .
Figure 6-25: The FIN/ACK 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, and they must complete a new TCP handshake in order to begin communicating again.
TCP Resets
In an ideal world, every connection would end gracefully with a TCP teardown. In reality, connections often end abruptly. For example, this may occur due to a potential attacker performing a port scan or simply a misconfigured host. In these cases, a TCP packet with the RST flag set is used. The RST flag is used to indicate a connection was closed abruptly or to refuse a connection attempt.
The file tcp_refuseconnection.pcap displays an example of network traffic that includes a 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 is a Cisco router, with no web interface configured, meaning that no service is listening for connections on port 80. 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 6-26 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.
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.
Figure 6-26: The RST and ACK flags signify the end of communication.