TCP Header Anaylsis - Section 2: TCP Sequence & Acknowledgement Numbers

This page will closely examine the Sequence and Acknowledgement numbers. The very purpose of their existence is related directly to the fact that the Internet, and generally most networks, are packet switched (we will explain shortly) and because we nearly always send and receive data that is larger than the maximum transmission unit (a.k.a MTU - analysed on sections 5 and 6 ) which is 1500 on most networks.

Let's take a look at the fields we are about to analyse:

As you can see, the Sequence number proceeds the Acknowledgement number.

We are going to explain how these numbers increment and what they mean, how various operating systems handle them in a different manner and lastly, what way these numbers can become a security hazard for those who require a solid secure network.

 

TCP - The Connection Oriented Protocol

The Sequence and Acknowledgement fields are two of the many features that help us classify TCP as a connection oriented protocol. As such, when data is sent through a TCP connection, they help the remote hosts keep track of the connection and ensure that no packet has been lost on the way to its destination.

TCP utilizes positive acknowledgments, timeouts and retransmissions to ensure error-free, sequenced delivery of user data. If the retransmission timer expires before an acknowledgment is received, data is retransmitted starting at the byte after the last acknowledged byte in the stream.

A further point worth mentioning is the fact that Sequence numbers are generated differently on each operating system. Using special algorithims (and sometimes weak ones), an operating system will generate these numbers, which are used to track the packets sent or received, and since both Sequence and Acknowledgement fields are 32bit, there are 2^32= 4,294,967,296 possibilities of generating a different number!

TCP - Initial Sequence Number (ISN)

When two hosts need to transfer data using the TCP transport protocol, a new connection is created. This involves the first host that wishes to initiate the connection, to generate what is called an Initial Sequence Number (ISN), which is basically the first sequence number that's contained in the Sequence field we are looking at. The ISN has always been the subject of security issues, as it seems to be a favourite way for hackers to 'hijack' TCP connections.

Believe it or not, hijacking a new TCP connection is something an experienced hacker can alarmingly achieve with very few attempts. The root of this security problem starts with the way the ISN is generated.

Every operating system uses its own algorithm to generate an ISN for every new connection, so all a hacker needs to do is figure out, or rather predict, which algorithm is used by the specific operating system, generate the next predicted sequence number and place it inside a packet that is sent to the other end. If the attacker is successful, the receiving end is fooled and thinks the packet is a valid one coming from the host that initiated the connection.

At the same time, the attacker will launch a flood attack to the host that initiated the TCP connection, keeping it busy so it won't send any packets to the remote host with which it tried to initiate the connection.

Here is a brief illustration of the above-mentioned attack:

As described, the hacker must find the ISN algorithm by sampling the Initial Sequence Numbers used in all new connections by Host A. Once this is complete and the hacker knows the algorithm and they are ready to initiate their attack:

Timing is critical for the hacker, so he sends his first fake packet to the Internet Banking Server while at the same time starts flooding Host A with garbage data in order to consume the host's bandwidth and resources. By doing so, Host A is unable to cope with the data it's receiving and will not send any packets to the Internet Banking Server.

The fake packet sent to the Internet Banking Server will contain valid headers, meaning it will seem like it originated from Host A's IP Address and will be sent to the correct port the Internet Banking Server is listening to.

There have been numerous reports published online that talk about the method each operating system uses to generate its ISN and how easy or difficult it is to predict. Do not be alarmed to discover that the Windows operating system's ISN algorithm is by far the easiest to predict!

Programs such as 'nmap' will actually test to see how difficult it can be to discover the ISN algorithm used in any operating system. In most cases, hackers will first sample TCP ISN's from the host victim, looking for patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. Once a pattern is found it's only a matter of minutes for connections initiated by the host to be hijacked.

Example of Sequence and Acknowledgment Numbers

To help us understand how these newly introduced fields are used to track a connection's packets, an example is given below.

Before we proceed, we should note that you will come across the terms "ACK flag" or "SYN flag"; these terms should not be confused with the Sequence and Acknowledgment numbers as they are different fields within the TCP header. The screen shot below is to help you understand:

You can see the Sequence number and Acknowledgement number fields, followed by the TCP Flags to which we're referring.

The TCP Flags (light purple section) will be covered on the pages to come in much greater depth, but because we need to work with them now to help us examine how the Sequence and Acknowledgement numbers work, we are forced to analyse a small portion of them.

To keep things simple, remember that when talking about Sequence and Acknowledgement numbers we are referring to the blue section, while SYN and ACK flags refer to the light purple section.

The next diagram shows the establishment of a new connection to a web server - the Gateway Server. The first three packets are part of the 3-way handshake performed by TCP before any data is transferred between the two hosts, while the small screen shot under the diagram is captured by our packet sniffer:

To make sure we understand what is happening here, we will analyse the example step by step.

Step 1

Host A wishes to download a webpage from the Gateway Server. This requires a new connection between the two to be established so Host A sends a packet to the Gateway Server. This packet has the SYN flag set and also contains the ISN generated by Host A's operating system, that is 1293906975. Since Host A is initiating the connection and hasn't received a reply from the Gateway Server, the Acknowledgment number is set to zero (0).

In short, Host A is telling the Gateway Server the following: "I'd like to initiate a new connection with you. My Sequence number is 1293906975".

Step 2

The Gateway Server receives Host A's request and generates a reply containing its own generated ISN, that is 3455719727, and the next Sequence number it is expecting from Host A which is 1293906976. The Server also has the SYN & ACK flags set, acknowledging the previous packet it received and informing Host A of its own Sequence number.

In short, the Gateway Server is telling Host A the following: "I acknowledge your sequence number and expecting your next packet with sequence number 1293906976. My sequence number is 3455719727".

Step 3

Host A receives the reply and now knows Gateway's sequence number. It generates another packet to complete the connection. This packet has the ACK flag set and also contains the sequence number that it expects the Gateway Server to use next, that is 3455719728.

In short, Host A is telling the Gateway Server the following: "I acknowledge your last packet. This packet's sequence number is 1293906976, which is what you're expecting. I'll also be expecting the next packet you send me to have a sequence number of 3455719728".

Now, someone might be expecting the next packet to be sent from the Gateway Server, but this is not the case. You might recall that Host A initiated the connection because it wanted to download a web page from the Gateway Server. Since the 3-way TCP handshake has been completed, a virtual connection between the two now exists and the Gateway Server is ready to listen to Host A's request.

With this in mind, it's now time for Host A to ask for the webpage it wanted, which brings us to step number 4.

Step 4

In this step, Host A generates a packet with some data and sends it to the Gateway Server. The data tells the Gateway Server which webpage it would like sent.

Note that the sequence number of the segment in line 4 is the same as in line 3 because the ACK does not occupy sequence number space.

So keep in mind that any packets generated, which are simply acknowledgments (in other words, have only the ACK flag set and contain no data) to previously received packets, never increment the sequence number.

Final Notes

There are other important roles that the Sequence and Acknowledgement numbers have during the communication of two hosts. Because segments (or packets) travel in IP datagrams, they can be lost or delivered out of order, so the receiver uses the sequence numbers to reorder the segments. The receiver collects the data from arriving segments and reconstructs an exact copy of the stream being sent.

If we have a closer look at the diagram above, we notice that the TCP Acknowledgement number specifies the sequence number of the next segment expected by the receiver. Simply scroll back to Step 2 and you will see what I mean.

Summary

This page has introduced the Sequence and Acknowledgement fields within the TCP header. We have seen how hackers hijack connections by discovering the algorithms used to produce the ISNs and we examined step by step the way Sequence and Acknowledgement numbers increase.

The next page examines the TCP header length field, so take a quick break if it's required and let's continue!

Next: TCP Header Anaylsis - Section 3: Header Length