Welcome to the decomposition of TCP.
In this module, we'll be performing a dissection of a TCP datagram.
But don't worry,
as no actual TCP datagrams were harmed in the making of this video.
Welcome to the TCP datagram, also known as the header.
The datagram is composed of 20 bytes of data by default,
without extra data added.
But right now, actually, it's a bunch of blank boxes,
so let's work on filling in our information.
The first part of our datagram is the source port.
Let's take a moment to break the source port down further.
The source port is the source of the traffic,
where it's originating from, but it's also responsible for connection tracking.
For example,
let's say we have a computer communicating with the web server using the
source port of 12165 and the destination port of 443.
When traffic is ready to be returned, the sending server says,
okay, I need to get this back to the requester.
It then looks at the source port and IP and says,
oh yeah, that belongs to port 12165.
The traffic is then sent to that destination.
Please note, though,
it's not uncommon for the source and destination port
roles to switch between each other.
Also, the source port contains a bit value of 16.
The next portion of our datagram is the destination port.
Let's decompose our destination port further.
The destination port is exactly as it sounds.
It's the destination to where the traffic is heading.
And remember, the source port and the destination port can flop roles.
More often than not, though,
some part of your TCP communication will involve you
connecting to a common destination service.
The most common destination services you'll encounter is a web server,
generally over port 80 or 443,
but it could also be an FTP server over port 21 or even a
Ubiquiti network switch offering SSH over port 22.
The destination port also has a bit size of 16.
The next section of our datagram header is the sequence number.
Let's try and sequence the sequence number.
Try saying that five times fast.
Remember, TCP is the reliable protocol, yet without sequence numbers,
we would be unable to operate TCP effectively.
In fact, it would function more like UDP,
except it would be really bloated, and nobody wants that.
Sequence numbers are also used for tracking in‑flight data.
All data is assigned a numerical value used in tracking
the successful delivery of the data.
Now, this is a really over‑simplistic view,
but hang on because in a short while,
we're going to cover sequence numbers in depth through Wireshark.
The sequence number also has a numerical value of 32 bits.
The next block in our datagram is the acknowledgement number.
Let's gain some knowledge on acknowledgments.
The acknowledgment number works in combination with the sequence number.
Essentially, there should be parity between the two devices.
If PC 1 sends a sequence number of 16,
PC 2's acknowledgement number should be 16.
The acknowledgment number is also 32 bits in length.
As with sequence numbers, this was just another high‑level overview,
as we're going to cover this in much further detail shortly,
so just hang in there.
For the next portion of our datagram, we'll be covering three sections.
The first section is the header length, the second is the reserve section,
and the third portion is the flag portion.
For this section, I actually want to do things out of order.
I want to cover the reserve section first,
as header length and flags are tied together quite closely.
The purpose of the reserve section is nothing.
The reserve section has been reserved for future use,
and per the IETF RFC 4413, the current size is 4 bits.
So remember, as of now, the reserve section is reserved for nothing.
To quote the IETF RFC 791,
"The Internet Header Length is the length of the
internet header in 32 bit words,
and thus points to the beginning of the data." Due to
the varying sizes of TCP packets,
the destination computer needs to know where the actual data begins.
So in short,
the header length is a composition of all the bits in
the header minus the data section.
And by default, the header length field has a bit value of 4 bits,
but the entire composition of the header from within all fields has
a total composition of 20 bytes by default There are 6 primary
flags contained within the TCP datagram,
and none of them are checkered, and that's why our bit size is 6 bits.
To be perfectly honest, though, when digesting a TCP datagram,
you'll actually see 10 flags in total, but 4 of them are extra,
and so you'll not actually encounter all of them.
The first usable TCP datagram flag is the urgent flag.
The urgent flag is often seen as URG in a packet dissection tool,
and it's used to mark important data as urgent.
It should be noted, though,
that the Internet Engineering Task Force has
recommended that this flag not be used.
They're not recommending to have the flag removed due to
some applications having to have this flag,
but it definitely has the smell of deprecation to it.
Acknowledgements are also seen as ACK, ACK,
within a packet tracing application,
and it's responsible for acknowledging the receipt of data.
The next flag is the push flag, also seen as PSH.
Essentially, with TCP sessions, they're buffered.
The push flag instructs the receiver to get to the chopper and
process the data immediately; do not buffer it.
The next flag is the reset flag, also seen as RST,
and just like my Nintendo NES that came manufactured with a reset button,
so does TCP.
The main purpose of the reset flag is to do exactly as
it sounds; it resets a connection.
There are multiple reasons a connection could be reset,
but the most common one that I generally encounter is caused from firewalls.
Generally, firewalls protect the devices that we're accessing,
so it's more common than not to have something like an IPS reset the connection.
Our second‑to‑last flag is the synchronize flag, also seen as SYN.
When digesting traffic through an application like Wireshark,
the purpose of the synchronize flag is to initiate a connection.
This can be most commonly seen in a TCP 3‑way handshake.
Well, we've reached our final, sixth flag, the finish flag.
The finish flag can be seen as FIN, FIN.
The finish flag is used for graceful termination of a TCP session,
and it should be the last thing you see in a properly terminated session.
But chances are, if you're troubleshooting network‑related issues,
you'll most likely see your connections closing in a different manner.
We've arrived at our extra flags.
The reserve flag currently doesn't have a purpose,
so we'll just have to wait and see what the future holds.
The Internet Engineering Task Force has also stated that
this flag must have a bit value of 0.
Our next unused flag is nonce,
and this is an experimental protocol specified by the
Internet Engineering Task Force.
The goal of nonce is to help protect against accidental and malicious traffic.
The congestion window reduced flag, also known as CWR,
and that's a ton easier to say, by the way,
the goal of CWR is to announce traffic congestion,
which in turn will hopefully slow traffic between the two devices.
The final flag is the ECN‑Echo, which is ultimately tied to CWR.
Essentially,
when a CWR flag is sent from the sending machine to the receiving machine,
the receiving machine replies with an ECN‑Echo,
acknowledging the traffic congestion.
Our next section of our datagram is the window segment,
and hey, we're getting really close to having our board filled,
so somebody should probably yell Bingo.
TCP doesn't acknowledge every piece of data that's sent.
If that were the case, there would be so much overhead, it would be impalpable.
Instead,
a TCP session utilizes a window to determine how
much unacknowledged data to send.
The rate of the window size can also be adjusted on the fly,
which in turn creates a more efficient network.
Windowing also has a default bit size of 16.
There was once a time, I was in my first Cisco network class,
and the instructor was showing a pcap in Wireshark.
And he pointed out to the class and said, hey, you see this right here?
This is showing a windowing problem.
Being these super smart guy that I am, I piped up and said,
well, yeah, it's Microsoft.
The instructor turned and looked at me and said,
this isn't Microsoft, in a quite terse voice.
He then suggested that I read the course material before speaking out of turn.
From that day forward, I always understood what windowing was.
Our next portion of our ever‑shrinking datagram is the checksum.
Let's check in on the checksum.
Checksums are a mathematical calculation that is used to validate the data.
This is important, as it aids in data integrity.
The checksum also has a default bit size of 16.
Welcome to the options field.
Let's see what options we have available to us.
The option field has a couple of options that are available to us.
The most common one is MSS, which stands for maximum segment size.
Per the IETF RFC 879,
MSS is the value that is sent from the receiver to the sender,
to which the receiver says, hey,
this is the largest amount of data that I can accept.
The second most‑common option is NOP, which stands for no option.
NOP is used for padding a TCP header.
This in turn allows TCP to meet the various size requirements.
The third option you'll encounter is the option for window scaling.
The window scaling works hand in hand with windowing and allows the
window size to be increased past its mathematical limit.
The final common option is SACK, which stands for selective acknowledgement,
and per the IETF RFC 2018,
SACK is utilized by the receiver of the data to notify the sender that
it has received blocks of data that are not in order.
Awesome, we finally did it.
We've arrived at our last section, the data section.
The data section is where our data is finally added to
the TCP datagram and then transported.
The data could be anything really, pictures, videos, database queries.
The possibilities are endless because it's our data.
With our datagram now successfully filled in and Bingo achieved,
let's view how this information actually looks in a TCP
session dissected through Wireshark.
With the packet presented to us,
we can see the source port of 28881 and a destination port of 23,
indicating that this is a Telnet session.
We can also note the sequence number of 0,
indicating that this is the first part of the conversation.
We can also see an acknowledgment number of 0 as well,
meaning that no acknowledgments have occurred.
We can also see that the header is 32 bits in size,
so we've already grown past our default 20 bytes.
Next, we can see the reserved bit is 0, as it should be.
We can also verify that the only active flag in this
conversation is the synchronous flag.
Through our packet analysis,
we can also see that the window size has an initial value of 64240,
and our calculated checksum is using a hex value of 0x546e.
We're also reporting four options in our Options section.
The first is the MSS size of 1460 bytes.
Next, we have NOP, nothing to see here.
Then we have a window scale size of 8, and finally a SACK permitted option.
Now, you may be wondering hey, where's our data section? Well, there isn't any, as this is the first portion of our packet's conversation.