New information has been added to this article since publication.
Refer to the Editor's Update below.
How IT Works
Decoding TCP/IP
Don Parker
TCP/IP is comprised of a set of protocols including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), and Internet Control Message Protocol (ICMP). Most IT professionals understand how these protocols work together to make network communication possible. They also know that IP is used for routing and that TCP is a transport protocol. However, it's not as well known what the various fields mean in a standard TCP/IP packet. Let's dive into the details.
A TCP/IP connection begins with a three-way handshake, used to initiate communications between computers, and is composed of three packets. This handshake usually begins with a synchronize (SYN) packet sent from a client to a server, followed by a synchronize/acknowledgement (SYN/ACK) packet from the server back to the client, and finally an acknowledgement (ACK) packet from the client back to the server. The final ACK packet is optional depending on the operating system you are using.
Let's look at and decipher an example TCP/IP packet, shown in the figure. This is the first step in the three-way TCP/IP handshake. A SYN packet like this is used to initiate communication and synchronize sequence numbers.
[Editor's Update - 5/5/2005:This was captured using the tool WinDump. Other utilities will most likely format and augment the results differently. For example, the timestamp discussed in the following section is inserted by WinDump and is not actually included in the data sent across the wire.]
09:09:52.283919
This is the time that my computer actually received the packet (not the time that it was sent). This time is accurate to the microsecond as represented by the six numbers after the last decimal point.
xxx.xxx.xxx.xxx.10459
Following the IP address 192.168.1.100 is the number 10459. This is the source port on the source computer that sent this packet.
>
The greater-than symbol shows the flow of communications, namely that the IP address to the left of the symbol is talking to the one on the right of the symbol.
192.168.1.200.80
This is the destination computer's IP address (192.168.1.200) as well as the destination port (80). You can infer that the client computer is trying to initiate communications with a Web server, since port 80 is the default used by HTTP servers such as IIS to listen for client connections.
S
The "S" that follows the IP address confirms this is a SYN packet.
[tcp sum ok]
This is also known as "TCP Checksum OK," and conveys that the checksum—as calculated by the source computer—is valid. When the source computer sends a packet, it adds to the packet the result of running a mathematical formula called a checksum over the contents of the packet, and it embeds the results into the packet's header. When the packet is received by the destination computer, the destination computer performs the same calculation on the received data. If the destination finds that its calculated checksum is the same as that embedded in the received packet's header, the packet will be processed.
3153110659:3153110659
This long string of numbers is the TCP sequence number. The number in parentheses that follows the sequence number represents the amount of data bytes sent. In this case, the value is zero as a SYN packet contains only a header and no data. In other words, no data has been sent as the two computers have not yet completed the three-way handshake.
win 32768
Window size is represented by win 32768, meaning the client computer has a window size of 32768 bytes. Also commonly known as the receive buffer, this metric is normally controlled by the application in use and indicates to the receiving computer the number of bytes that the client is willing to receive unacknowledged (once the source computer sends an acknowledgement to the destination computer, the destination can then send more data). In this case, we've surmised that the client is starting up communications with a Web server, so it is likely that this window size is that of Microsoft® Internet Explorer. If the server sends more information than the maximum allowed by the window size, the client may simply drop the extra packets due to a full buffer.
<mss 536>
Maximum segment size is represented by the number within the angle brackets. This value, as sent by the source computer, tells the destination to send no more than 536 bytes of data in any one packet. The Maximum Transmission Unit (MTU) for Ethernet is 1540.
(ttl 63, id 60989, len 44)
The value ttl 63 represents the packet's time-to-live, which defines the number of router hops that can be made before this packet will be dropped. In this example, 63 more router hops can be made before the packet will be dropped by the next router in line. When a router receives a packet with a ttl of 1, it will drop this packet and send an ICMP error message back to the originator. This prevents packets from flying around endlessly if they cannot reach their destination. I know that the source computer is running Windows® 2000 Professional, which has a default ttl of 128. That means that this packet went through quite a few hops before this capture was taken.
The TTL on the source computer had been changed from the default to a much lower number, meaning that the number of hops was significantly less than is implied.
Next is id 60989, the number assigned to the IP header. This number is used for packet fragmentation purposes. Should a packet need to be split into multiple pieces by a router, each fragment that is generated will have the same IP ID number assigned to it. The destination computer needs this to be able to reassemble them. Were this packet actually fragmented, there would also be a value called the fragmentation offset included (there's no use having fragments if you don't also know in what order they need to be reassembled).
Most current operating systems have the DF (don't fragment) bit set by default. If a router receives a packet with the DF bit set, and that packet is too big for the router to route, then the router will simply discard the packet, since the router would need to fragment it to pass it along. This will, in turn, cause the router to generate an ICMP error message, which it will send back to the originator of the packet to let it know.
Lastly, there is len 44, which represents the overall length of the packet. This includes not only the byte count of TCP and IP headers, but also the data sent, if any. Everything is measured in bytes.
At the end of the packet is a mass of hexadecimal values as well as some ASCII content. While this may seem cryptic, it actually isn't—all you are seeing is the TCP and IP header information of the packet that was just examined, but this time in a hexadecimal representation. You can, if you choose, decode these hexadecimal values yourself instead of letting the computer do it for you, but doing so is not for the faint of heart.
Don Parker works in a high-assurance environment where he is employed as a network security analyst. He has been a guest speaker at various computer security conferences, and holds the GCIA and GCIH certifications. His Web site is www.bridonsecurity.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.