TCP Header Length Analysis - Section 3

Introduction

The third field under close examination is the TCP Header length. There really isn't that much to say about the Header length other than to explain what it represents and how to interpret its values, but this alone is very important as you will soon see.

Let's take a quick look at the TCP Header length field, noting its position within the TCP structure:

You might also have seen the Header length represented as "Data offset" in other packet sniffers or applications, this is virtually the same as the Header length, only with a 'fancier' name.

Analysing the Header length

If you open any networking book that covers the TCP header, you will almost certainly find the following description for this particular field:

"An interger that specifies the length of the segment header measured in 32-bit multiples" (Internetworking with TCP/IP, Douglas E. Comer, p. 204, 1995). This description sounds impressive, but when you look at the packet, you're most likely to scratch your head thinking: what exactly did that mean?

Well, you can cease being confused because we are going to cover it step by step, giving answers to all possible questions you might have. If we don't cover your questions completely, well... there are always our forums to turn to!

Step 1 - What portion is the "Header length"?

Before we dive into analysing the meaning of the values used in this field, which by the way changes with every packet, we need to understand which portion on the packet is the "Header length".

Looking at the screen shot on the left, the light blue highlighted section shows us the section that's counted towards the Header length value. With this in mind, you can see that the total length of the light blue section (header length) is 28 bytes.

The Header length field is required because of the TCP Options field, which contains various options that might or might not be used. Logically, if no options are used then the header length will be much smaller.

If you take a look at our example, you will notice the 'TCP Options' is equal to 'yes', meaning there are options in this field that are used in this particular connection. We've expanded the section to show the TCP options used and these are 'Max Segment' and 'SACK OK'. These will be analysed in the pages which follow, at the present time though we are interested in whether the TCP options are used or not.

As the packet in our screenshot reaches the receiving end, the receiver will read the header length field and know exactly where the data portion starts.

This data will be carried to the layers above, while the TCP header will be stripped and disregarded. In this example, we have no data, which is normal since the packet is initiating a 3-way handshake (Flags, SYN=1), but we will cover that in more depth on the next page.

The main issue requiring our attention deals with the values used for the header length field and learning how to interpret them correctly.

Step 2 - Header Value Analysis

From the screen shot above, we can see our packet sniffer indicating that the field has a value of 7(hex) and this is interpreted as 28 bytes. To calculate this, you take the value of 7, multiply it by 32 and divide the result by 8: 7x32=224/8=28 bytes.

Do you recall the definition given at the beginning of this page? "An interger that specifies the length of the segment header measured in 32-bit multiples". This was the formal way of describing these calculations :)

The calculation given is automatically performed by our packet sniffer, which is quite thoughtful, wouldn't you agree? This can be considered, if you like, as an additional 'feature' found on most serious packet sniffers.

Below you will find another screen shot from our packet sniffer that shows a portion of the TCP header (left frame) containing the header length field. On the right frame, the packet sniffer shows the packet's contents in hex:

By selecting the Header length field on the left, the program automatically highlights the corresponding section and hex value on the right frame. According to the packet sniffer, the hex value '70' is the value for the header length field.

If you recall at the beginning of the page, we mentioned the header length field being 4 bits long. This means that when viewing the value in hex, we should only have one digit or character highlighted, but this isn't the case here because the packet sniffer has incorrectly highlighted the '7' and '0' together, giving us the impression that the field is 8 bits long!

Note: In hex, each character e.g '7' represents 4 bits. This means that on the right frame, only '7' should be highlighted, and not "70". Furthermore, if we were to convert '7' hex to binary, the result would be '0111' (notice the total amount of bits is equal to 4).

Summary

The 'Header length' field is very simple as it contains only a number that allows the receiving end to calculate the number of bytes in the TCP Header. At the same time, it is mandatory because without it there is no way the receiver will know where the data portion begins!

Logically, wherever the TCP header ends, the data begins - this is clear in the screen shots provided on this page. So, if you find yourself analysing packets and trying to figure out where the data starts, all you need to do is find the TCP Header, read the "Header length" value and you can find exactly where the data portion starts!

Next up are the TCP flags that most of us have come across when talking about the famous 3-way handshake and virtual connections TCP creates before exchanging data.