Networking

TCP Flags : What they mean and how they help!

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 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).
  • 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.

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

 

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.

 

That’s all for today! I hope you enjoyed reading this post as much as I enjoyed writing it. If you did, go ahead a share it with the world.
To get more details and insight into how things work in the world of IT, keep a watch out for this space. You might even want to subscribe, over on the right.

I recommend that you get yourself a copy of Windows Server 2008 TCP/IP Protocols and Services from Joseph Davies. The book comes with a disc containing a lot of sample network captures that you can reference during you studies.

Additional References:

Tweet
Pin
Share
0 Shares