Inside the TCP Handshake
Articles and Tips: article
01 Mar 2000
Editor's Note: For more information about network analysis techniques and uses, attend Laura Chappell's "Introduction to Network Analysis" (session 164) at BrainShare 2000 in Salt Lake City. You can also visit http://www.netanalysis.org.
Many applications rely on the connection-oriented services (such as HTTP, FTP, and pure IP) which are offered by TCP. When these applications are launched, the TCP stack on the local device must establish a connection with the TCP stack on the destination device.
The handshake process is based on three steps. (In this article, the device that initiates the handshake process is called Device 1 , and the destination device, or the target of the connection, is called Device 2.)
Device 1 sends its TCP sequence number and maximum segment size to Device 2.
Device 2 responds by sending its sequence number and maximum segment size to Device 1.
Device 1 acknowledges receipt of the sequence number and segment size information.
That's it. Pretty simple. By looking inside the handshake packets, you can see what a TCP header actually contains during the handshake process and understand how to troubleshoot this process.
Why is it so important to recognize a healthy TCP handshake? Unfortunately, hackers can alter this handshake to overload a destination device. Remember last month's denial of service attacks on popular Internet sites?
INSIDE PACKET 1
In the initial packet, Device 1 inserts a self-assigned initial sequence number in the TCP header. (See Figure 1.) This number is used to track the sequence of data sent to Device 2, ensuring that no packets are missing. The SYN flag, which is set on packets, is used to synchronize sequence numbers.
Figure 1: The initial TCP handshake packet
Note: This packet contains a hidden field--the Acknowledgment Number field. The Acknowledgment Number field contains the next-expected sequence number from the other side of the communication. Since this packet is the first in the handshake process, however, Device 1 does not know what sequence number Device 2 will use. As a result, the 4-byte field is left at 0x0000-0000, and this field is not displayed by the network analyzer.
The Data Offset field simply defines the length of the TCP header. The header is typically 24 bytes during the first two packets of the handshake and 20 bytes for regular data exchange.
In this packet, you will also notice that Device 1 has defined a Maximum Segment Size (MSS), which indicates the amount of data that can be contained in the packet after the TCP header. Here's why 1,460 bytes makes sense for this Ethernet packet:
1,460Data after TCP header (the payload)
20Typical TCP header size20Typical IP header size14Typical Ethernet header size4CRC size1,518Maximum Ethernet packet size
The TCP header also defines the desired process or application for this connection: port 524. NetWare 5 uses this port for pure IP (NetWare Core Protocol [NCP] over IP) communications.
INSIDE PACKET 2
Figure 2 shows the TCP header inside Device 2's response to the connection request. As you can see, Device 2 has selected the sequence number 2744080.
Figure 2: The second TCP handshake packet
Now the network analyzer--in this case, Network Associates's Sniffer--shows the value of the Acknowledgment Number field--12953. This field contains the next sequence number that Device 2 expects to receive from Device 1.
This packet has two flags set: SYN (which synchronizes sequence numbers) and ACK (which acknowledges receipt of Device 1's first packet).
This packet also indicates that Device 2 has an MSS of 1,460 bytes as well. Does this mean that the communications between the two devices would never be fragmented? No. If there is an intervening link that does not support this packet size, the packets would be fragmented.
INSIDE PACKET 3
To view packet 3, you can download the TCPSHAKE.CAP file from the trace file area at http://www.netanalysis.org. You can then use your network analyzer to view the contents of packet 3. You can probably guess what Device 1's sequence number is (12953). The final packet in the handshake process has the ACK flag set.
CONCLUSION
A basic knowledge of the typical communication processes will save you time and effort as you troubleshoot your company's network. This knowledge can also help you identify perpetrators of malicious attacks on your company's network.
Laura Chappell writes technical training books for podbooks.com (http://www.podbooks.com) and is a senior protocol analyst at NetAnalysis Institute. Ms. Chappell also makes a pretty mean margarita. (For more information about NetAnalysis Institute, visit http://www.netanalysis.org.)
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.