TCP Flags : What they mean and how they help!

webcache.googleusercontent.com/search

December 17, 2018

Hey there, Hello and Welcome back.

Today we are going to talk about the Flags and Options used by TCP. We will discuss the
significances and uses of each parameter. The information in this post is a addition to my
previous post “The TCP 3-Way Handshake“. If you have not read it yet, take 10 mins to go
through it before reading ahead.

Let’s start with the WHY.

To understand anything, be it in IT or daily life, you need to understand the reasoning behind
it. Don’t be like a horse with blinds on its eyes, they are magnificent creatures, but the blinds
give them tunnel vision and they can only see what is right in front of them.

Think of TCP Flags like road signs. These signs are very helpful in making sure we are safe
on the road and are fully aware of the surroundings. They help us be vigilant on the road.
TCP Flags are exactly this, they are used to indicate different kinds of details, options,
conditions and/or situations to its TCP peers and the devices in between them.

There are 8 flags in TCP. Together they are 1 word (8bits) in size. The flags are ordered in
the following manner and can be either set to 1 (on) or 0 (off)

TCP Flags

CWR : Congestion Windows Reduced

ECE : Explicit Congestion Notification [ECN]-Echo
URG : Urgent
ACK : Acknowledgement
PSH : Push
RST : Reset
SYN : Synchronize
FIN : Finish

Now lets detail each flag. I have reordered the flags so help you better understand them.

SYN : Synchronize
I talked about this flag in my previous post that covered “The TCP 3-Way handshake“. The
SYN flag is ONLY set at the beginning of a TCP connection. It is used to indicate to a peer
the First Sequence number in the data stream. This Sequence number is also called the

1/5
Initial Sequence Number (ISN).

ACK : Acknowledgement
The ACK flag is sent on almost every TCP segment after the First SYN. It is used to indicate
to the sender, until where data was received and what is the next sequence in the stream
that the receiver expects.

Example: If the sender sent 5 segments ranging from 5001-10000 (i.e. 5000 bytes), the
receiver will set the ACK flag and the ACK number to 10001. this tells the sender, that I got
everything from the initial sequence number (set in SYN) up to 10000 and I want you to send
me data from byte 10001 onwards.

RST : Reset
The RST flag, it one of the most misunderstood flags out there. To the untrained eye, a RST
is like a RED FLAG that screams “ERROR! ERROR! ERROR!”. This is so not true. Let’s
clear the air, shall we.

A RST for a SYN segment

On its own simply indicates that the TCP Socket (i.e. IP Address : Port combination)
you are trying to reach does not exist on the destination machine. Simply put, it means
that your TCP packet reached the destination machine, was sent up the stack from the
NIC to the TCP stack, but TCP did not have a application bound/attached to the TCP
port the traffic was destined for.
Example: If you try to send HTTP traffic to a server that is not a Web Server, you will
see a RST sent back. (assuming no firewalls).
Exercise: Open Microsoft Edge and try to access the IP of a test machine, that is not a
web server, using http://IpAddress (make sure the destination machine’s Windows
Firewall profiles are turned off). When you look at a packet sniff for this, you will see a
SYN being sent and a RST received.

A RST at the end of a conversation.

This means that the segment that was received was for a TCP Flow that is no longer
active, most likely because it was closed out.
This is generally seen in higher latency networks that have multiple paths from source
to destination and packets thought to have been lost were not really lost, but rather
took a longer pathway.
Think of it as a response to a segment that arrived late to the party

A RST and an ACK (this is called piggybacking, see TCP and its efficiency, don’t you just love it).

2/5
 If the RST + ACK is seen for a SYN packet it means that the receiving machine
received the TCP Segment and has an Application attached to the TCP port. However,
for whatever reason, the application cannot process the request at the time. This is
your que to say, “Psst! App team, what’s up you your app man?”
If the RST + ACK is seen at the end of a conversation it means that the sender of the
RST + ACK, it just doing a fast close. You will see this quite often with high density
services, (like IIS, SMB etc.) after a ACK + FIN was received from the client.
If the RST + ACK is seen at the end of a conversation, without receipt of a ACK + FIN.
This indicates an application issue or a application timeout. You might need to look at
performance metrics, event logs, application logs, etc. to determine what happened.

Words for the Wise. The next time you see a RESET, take a step back and think about the
above scenarios.

FIN : Finish
The finish flag does exactly what is says on the tin. It is used to indicate to the receiver that
the sender has finished sending data and is closing it’s outbound flow. Pay close attention to
this, I said “the sender finished sending data and is closing its outbound flow“. TCP is a
full duplex connection, this means that it has both a inbound and outbound flow.

For a connection to truly close, both flows will need to be closed with an ACK + FIN in a
graceful manner. This means ACK + FIN (ack here is for previous segment and has nothing
to do with the FIN), followed by an ACK, with the same coming from the other side.

After a ACK + FIN, ACK is received, the other side could also do a fast close (i.e. ACK +
RST)

PSH : Push

The Push flag is an odd flag. Let me try and explain why I’d say this.

TCP as a protocol is inherently a very Efficient Protocol. What this means is that TCP will
always try to fill up a TCP segment with the Maximum Payload permitted (MSS).

This behavior is defined in the Nagle Algorithm.

It does this by pausing outbound traffic for up to 200ms in order to gather more data coming
in from higher up the stack (i.e. the application) and clubbing them together in to a single
TCP segment.

In nearly all scenarios this is a great feature and should be applauded. However, there are
some applications (especially Real-Time Apps), like Telnet and SSH that require immediate
data transmission and response.

3/5
Imagine that you are in remote console session typing out some commands. If TCP had it’s
way, you will have had to type at least 20-30 characters, depending on how fast you can
type, before you’d see any feedback on the screen.

In order to facilitate immediate feedback to the user, applications such as Telnet or SSH,
disable this efficiency, i.e. the Nagle Algorithm, by setting the TCP_NODELAY parameter
when data is sent down the stack to the TCP Layer.

URG : Urgent

During a normal TCP communication there are times when the process must be interrupted
to accepts control data for Asynchronous events. This type of data, control data, is known as
out-of-band data.

There are 2 ways to do OOB data.

Using a separate TCP socket for this data, such as the control channel in FTP (i.e.
TCP 20)
Making the use of the TCP Urgent Flag and Urgent Pointer

The urgent flag is used to indicate to a receiving node that there is data in the packet that
needs to be prioritized.
When this flag is set the receiving node will read the Urgent Pointer in the TCP header to
distinguish the urgent data from non-urgent data.

In today’s modern networks, you will almost never see this flag being sent. However, it is
important to know that there are 2 definitions of the Urgent Pointer.

RFC 793 defines the value of the Urgent Pointer as the positive offset from the
beginning of the TCP Segment to the First byte of non-urgent data.
RFC 1122 defines the value of the Urgent Pointer as the positive offset from the
beginning of the TCP Segment to the Last byte of urgent data.

The 2 definitions differ by just 1-byte but if both nodes in the communication use different
definition it could lead to data corruption.
The definition being used will be negotiated in the 3-Way Handshake.

By default, Windows adheres to RFC 793. This behavior can be controlled using the below
registry key.

TcpUseRFC1122UrgentPointer
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Type: REG_DWORD
Valid Range: 0-1
Default: 0

4/5
ECE : Explicit Congestion Notification [ECN]-Echo

During the 3-way handshake, this flag indicates that the sending node is ECN ( Explicit
Congestion Notification ) capable.

This flag is usually set by intermediate devices such as routers, when the intermediate
device is facing high volumes of data that could cause congestion and lead to dropped
packets.

When the sending node sees this flag, it reduces the amount of data it pushes to the wire to
help the intermediate device recover, reduce the risk of dropped packets and prevent
unnecessary retransmissions.

CWR : Congestion Window Reduced

The CWR flag is set when the sending node receives a TCP segment that has the ECE bit
turned on.
It is used to indicate to a peer that the congestion window was reduced to facilitate recovery
of an intermediate device.
When this flag is set the sending node will half it’s send window and will begin sending data
in accordance to the slow-start algorithm once again.

5/5