Understanding the TCP/IP Protocol (Part 1)

If you would like to read the next articles in this series please read:

Joined at the hip

Quite a few system administrators I am sure, are familiar with the TCP/IP protocol suite. By extension many of us are also used to looking at packets composed of both the TCP and IP protocols. A large amount of traffic, have both of them in it, so they could considered to be joined at the hip for lack of a better term. Thus the bulk of the Internet traffic that we see today, is largely composed of both TCP, and IP ferrying around whatever application layer protocol they may be carrying. That being said, as many of us remember, the computer world is not all just composed of application layer protocols, and the aforementioned TCP and IP protocols carrying them around. What this introductory three part article will do is convey to you exactly what is going on in both the TCP and IP header.

There exists quite a few other protocols though that don’t reside at the application, transport, or networking layer. While you may be asking yourself “why the devil is he talking about the OSI reference model, is this article not about protocols!?” Well, simply put, using the OSI reference model as our template, it will give us a great way to map protocols to specific layers. In essence it allows us to give some order to what can quickly become an unwieldy beast; the understanding of computer to computer communications. Think of it this way, using the skeletal outline of the OSI model we can add bits and pieces to it allowing us to flesh it out. It really simplifies our life as networking professionals if we use the OSI reference model in such a fashion.

Bring on the gory details!

For any of you system administrators reading this article you are probably familiar with the tool ethereal. What this tool does is break down the contents of a packet for you, and maps all of the hex values found in them. Not only that, but it will also tell the name of these values. What values you ask? Well good question! Values such as win size, ttl values, and mss amongst others. These terms may seem a little cryptic to you right now, but rest assured you will understand them shortly. I have always loved the details, and metrics such as. For they are very much the types of details that we must understand, in order to gain a deep understanding of TCP/IP.

Explaining such difficult concepts as the minutiae of TCP/IP can be a difficult task. Not to mention the reader trying to grasp all of the dry text. With that in mind I always strive to give some visual cues. This helps the reader to put some context to all of the new words, and terms they are encountering. I mentioned earlier the tool ethereal, and that it does a fine job of breaking out packets for us. Well to be honest you are best not using such a tool when first learning the contents of a packet. You are far better off trying to do so by hand. One of the best resources I have to found to date is the TCP/IP and tcpdump flyer provided by the SANS institute. Just look at the bottom of the page provided by the hyperlink and you will see the flyer. It is there under the “Additional Resources” category.

All of the information contained on the TCP/IP, and tcpdump flyer will be put to use during this two part series. This document is, simply put, the best of its kind out there today. All you need to do is simply follow the breakdown of the packet as it lays it out for you. Not only that, but the metrics themselves also get a quick explanation at the bottom of the page. You will also note at the bottom of the page that there are also many options that are associated for that protocol listed. Having the options listed there is very handy as many of them may seem very arcane to you. Lastly, please note as well that the size of the option in bytes is also listed before the option itself.

Will we ever see an actual packet!

‘Patience is a virtue that takes entirely too long to master’ is my motto! That being said let the much mentioned packet make an appearance. What you see below is two packets that were sniffed off of the wire, using a program such as windump, which required winpcap to work.

00:00:03.700720 > S [tcp sum ok] 365712315:365712315(0) win 32768 <mss 536> (ttl 63, id 59169, len 44)
0x0000   4500 002c e721 0000 3f06 4253 c0a8 0164        E..,.!..?.BS….
0x0010   c0a8 01c8 2eb3 0050 15cc 53bb 0000 0000        …1…P..S…..
0x0020   6002 8000 30e0 0000 0204 0218 0000             `…0………

00:00:03.715864 > S [tcp sum ok] 2093803204:2093803204(0) ack 365712316 win 5840 <mss 1460> (DF) (ttl 52, id 0, len 44)
0x0000   4500 002c 0000 4000 3406 f474 c0a8 01c8         E..,[email protected]…1
0x0010   c0a8 0164 0050 2eb3 7ccc e6c4 15cc 53bc           …..P..|…..S.
0x0020   6012 16d0 32d2 0000 0204 05b4 0000                  `…2………

What we see above us is two packets. Notably the SYN and the SYN/ACK. Those two packets actually represent two thirds of the TCP/IP handshake. You may note that the remaining part of the handshake ie; the ACK packet is missing. Well simply put, not every operating systems actually uses the last portion of the handshake to set up communications. So in an effort to keep things as realistic as possible I have only listed the portions of the handshake that you will usually see.

Yet more details

Seen as this is the start of a communications channel between two computers we have various metrics sent by each half of the soon to be completed socket. These metrics tell each computer what they can receive in terms of information, but more importantly also just how much information they can receive, at any one given time. There are values as well, which are only seen during the initial setup of communications. Values such as the mss will not appear in the actual PSH/ACK packets.

In case you have ever wondered how people are able to ascertain just what operating system it is that you are using, it is done by reading these very same packet metrics. For in case you did not know various operating systems all come with default values programmed into their TCP/IP stack. These values never really change unless changed manually. Therefore based on those hardcoded default values one can make a fairly good guess as to what operating system is in use.

Well with all that necessary background information out of the way we are ready to actually go through the contents of the packet. Covered will be absolutely everything that you see above in the two packets. From the timestamp of the packet all the way to the last piece of hex in it. On that note I will bid you a fond farewell and see you in part two of this article for some down and dirty TCP/IP info. Till then!

If you would like to read the next articles in this series please read:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top