In TCP, flags indicate a particular connection state, provide some additional helpful information for troubleshooting purposes, or handle control of a specific connection.
Flags are also called control bits. Each flag corresponds to 1-bit information. The most commonly used flags are SYN, URG, ACK, PSH, FIN, and RST.
SYN bit is used in the initial three-way handshake where both parties generate the initial sequence numbers.
URG says that the data should be treated with priority over other data.
ACK is used to confirm that the data packets have been received.
PSH tells an application that the data should be transmitted immediately, and we do not want to wait to fill the entire TCP segment.
FIN bit is used to end the TCP connection. TCP is a full-duplex, so both the sender and receiver must use the FIN bit to end the connection. This is the standard method of how both parties end the connection.
RST resets the connection. When the host receives this, it must terminate the connection right away. This is only used when there are unrecoverable errors, and it is not a normal way to finish the TCP connection.
The CWR, ECE, and NS are the additional flags that are not commonly used. TCP ECE and CWR are related to bandwidth congestion.
The ECE (ECN echo) bit indicates that the TCP peer is ECN capable. ECN allows routers to inform the TCP endpoints that their transmit buffers are filling due to congestion. This allows the TCP endpoints to slow their data transmission to prevent packet loss.
CWR (Congestion Window Reduced) bit is used by the sending host to indicate that it received a packet with the ECE flag set.
NS (Nonce sum) is the experimental flag used to help protect against accidental or malicious concealment of marked packets from the sender.
To export TCP flags in IPFIX or NetFlow v9 flow records for Cisco IOS devices, the command collect transport tcp flags must be configured under the flow record section.
flow record v4_r1 match ipv4 protocol match ipv4 source address match ipv4 destination address match transport source-port match transport destination-port match application name collect counter packets long collect interface input collect interface output collect counter bytes collect flow direction collect transport tcp flags
Take a look at the IPFIX flow shown in Figure 1. The flow record is exported by a Cisco CSR1000v router with IP address 10.0.0.2. The host 192.168.88.102 with the source port 23293 is attempting to establish a connection to a Telnet server with IP address 188.188.188.188.
Figure 1 – IPFIX Flow Record
The hexadecimal number 0x02 tells us that the TCP SYN flag is present in the TCP header (Figure 2). The binary value is 0b0000010, meaning that only the SYN bit is set. As with all flags, a value of “1” indicates that a particular flag is set.
| Reserved | Reserved | URG | ACK | PSH | RST | SYN | FIN |
| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
Figure 2 – TCP Flags in IPFIX Flow
In our example, only the “SYN” flag is set, indicating that this is the first segment of a new TCP connection. This is the first stage of the 3-way handshake process, during which both parties generate their initial sequence numbers. The purpose of the sequence number is to assist the recipient in putting the packets of the data in order.
Note that the ACK flag is missing in the IPFIX flow, meaning that the TCP three-way handshake is not complete, so the connection is not established. The firewall likely blocks telnet protocol, or there is a routing problem on the path between hosts.
Figure 3 helps us to illustrate how TCP flag aggregation is working. The firewall is no longer blocking a connection to telnet server 188.188.188.188. There are now two TCP flags in the TCP header of the IPFIX flow, and the flow contains two packets. The SYN bit is set in the first phase and the ACK bit is set in the third phase of the three-way handshake. Both phases are included in the same flow record, but the second phase is included in a separate flow that contains a single packet with the SYN and ACK flags set.
Figure 3 – IPFIX Flow Record with 3-way TCP Handshake
During the second phase of the three-way TCP handshake, the source IP address is 188.188.188.188 (telnet server), so the exporter creates a new IPFIX flow.
A single flow consists of many individual packets. The observed aggregated TCP flags in a given flow are reported by the tcpControlBits information element. The collected control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, FIN.
The exact number of specific TCP flags in a given flow, e.g. SYN and FIN, can be reported with the IPFIX Information Elements tcpSynTotalCount, tcpFinTotalCount, etc. defined in RFC5102.
Monitoring TCP flags is useful because it give us a better understanding of what is really going on in our networks. For example, an excessive number of of TCP SYN flags may indicate a denial-of-service attack, where an attacker initiates numerous connections to a server from a spoofed IP address without finalizing the connection. Servers must spend resources waiting for half-opened connections, which can consume enough resources to make the system unresponsive to legitimate traffic.
Likewise, many network scans can be detected by the presence or absence of certain TCP flags in flows. For example, an excessive number of ACK flags sent to a monitored network may indicate TCP ACK scan. An attacker sets ACK flags and determines whether a firewall is blocking ports based on RST flags in received TCP segments. On the other hand, numerous received RST+ACK flags may indicate a TCP SYN scan. An excessive number of flow records with no TCP flags set, in turn, may indicate a Null scan.
TCP flag review is an easy process with the Noction Flow Analyzer. NFA allows you to spot and solve potential and existing network security/performance issues with a prompt high-level approach as opposed to cumbersome Wireshark packet analysis techniques. Take NFA for a spin with the free 30 day trial and see how the products fits your network traffic monitoring needs.