1. Introduction
In our daily lives, we have several signals to start and finish a conversation with people. For example, we can handshake a person with which we want to communicate. Moreover, we can friendly say goodbye to another person with waves of a hand, or simply turn our backs to someone and go away.
Similarly, computers have different signals to coordinate communication in a network. For instance, if computers communicate using the Transmission Control Protocol (TCP), SYN, ACK, FIN, and RST messages act as these communication signals.
In this tutorial, we’ll particularly study two communication signals from TCP: FIN and RST. First, we’ll briefly review the communication over TCP, pointing out the messages used to start and finish a communication. So, we’ll in-depth explore the FIN and RST messages, investigating scenarios where they are employed. Finally, we’ll compare FIN and RST in a systematic summary.
2. Communication Over TCP
TCP operates in the fourth layer (transport) of the OSI model. So, it provides host-to-host communication to several devices and their applications. Furthermore, TCP is a connection-oriented protocol. It means that devices communicating over TCP must establish a connection. Connections, in turn, are established through a handshaking process and enable the connected devices to exchange messages.
To establish, manage, and close a connection, TCP uses control messages that act as signals to the devices:
- SYN: a synchronization message typically used to request a connection between a client and a server
- ACK: an acknowledgment message employed to declare the receipt of a particular message
- FIN: a message that triggers a graceful connection termination between a client and a server
- RST: a message that aborts the connection (forceful termination) between a client and a server
In this way, a typical communication over TCP starts with a three-way handshake process. This process employs SYN and ACK messages to establish a connection between a client and a server. Thus, the connected entities can exchange messages.
Moreover, the entities acknowledge (ACK) each received message to each other. When the communication ends, a connected entity sends a FIN message to close the connection. So, a FIN handshake process begins. However, if some problem happens with the connection, an entity can abort it by sending an RST message.
3. FIN Message
A FIN message gracefully requests the termination of a TCP connection. If we compare the connection to a conversation, a FIN message represents an entity declaring: “I said everything I had to say to you. Now, I will listen to you until you say everything you have to say to me”. In technical terms, however, a FIN message triggers a process called FIN handshake.
Let’s consider that a client has connected and communicated with a server. At some point, the client signals to close the connection gracefully. Thus, the FIN handshaking begins:
- The client sends a FIN message to the server
- The server receives the client’s FIN message and ACKs it to the client
- The client receives the server’s ACK and waits
- If there are messages to be sent from the server to the client, the server sends it
- The server sends a FIN message to the client
- The client receives the server’s FIN message and ACKs it to the server
- The server receives the client’s ACK and closes the connection on the server-side
- The client waits a protocolar time
- The client closes the connection on the client-side
The following image depicts the previously described steps of a FIN handshake process:
At last, it’s relevant to highlight that the FIN handshake consists of a pair of two-way handshakes: the first one initiated by an entity that sends the first FIN message (step 1); and the second one beginning when the other entity sends a second Fin message (step 5).
4. RST Message
An RST message aborts a TCP connection. In our analogy to a conversation, an RST message is equivalent to a person declaring: “I don’t have anything to talk. I won’t say anything to you, and I won’t listen to anything from you”. In practice, an RST message enables the entity that sent it to close a TCP connection immediately, thus disregarding any subsequent message from the other entity communicating.
Let’s consider the generic scenario of a client communicating with a server. Eventually, an event occurs in the server, and it can’t respond to client messages. So, the server must inform the client through an RST message as follows:
- The server sends an RST message to the client
- The server closes the connection on the server-side
- The client receives the RST message from the server
- The client closes the connection on the client-side
The following image exemplifies the previously outlined steps of aborting a TCP connection:
Some particular scenarios in which RST messages can be employed are:
- An entity receives a message from another one through a connection previously established. However, the first entity had already closed its socket. Thus, the first entity sends an RST message to the second one
- An entity receives an SYN message for an already established connection. Thus, this entity responds to the SYN message with an RST message
- An entity receives a message from another one, but the first one is busy and can’t respond. So, an RST message is sent from the first entity to the second one
Finally, the spoofed TCP reset attack uses RST messages to abort a connection between two entities. In this case, a malicious agent forges an RST packet with the addressing information of connected entities. Thus, this malicious entity sends the forged packet to one of those connected entities.
The entity that receives the forged packet aborts the connection immediately. At some point, the other entity (that did not receive the forged packet) notes that the communications attempts aren’t responded to, aborting the connection.
5. FIN vs. RST
The FIN and RST messages, at a high level, have the same objective: close a TCP connection. However, the termination process and the typical scenarios where these messages are employed differ in multiple aspects.
First, the FIN message triggers a graceful termination, making the connected entities agree to close their connection. The RST message, in turn, closes a connection immediately, requiring no agreement from the other connected entity.
In this way, there are scenarios where closing a connection with FIN or RST is most suitable. In general, when a TCP connection is considered normal (successfully established and the message exchanging occurs with no anomalies), a FIN message is the better option to close it. The FIN process guarantee that the connected entities send and receive all the required messages.
Aborting a connection with RST, in turn, is the better option when, for instance, connection errors raise or an entity receives anomaly messages. In this way, the RST process avoids catastrophic errors and security compromising from occurring.
The following table summarizes the differences between FIN and RST:
FIN
RST
Connection Termination
Graceful
Abort
Termination Process
Two-way handshake (2x)
Unconditionally closes the connection
Typical Usage
Normal TCP connections
When errors or anomalies occur in the connections
6. Conclusion
In this article, we learned about FIN and RST messages of TCPabout FIN and RST messages of TCPabout FIN and RST messages of TCP. First, we had a brief review of TCP. Then, we in-depth analyzed the control messages of FIN and RST, outlining their characteristics. At last, we compared the control messages of FIN and RST, summarizing their main differences and application scenarios.
We can conclude that FIN and RST play a relevant role in TCP, enabling entities to close connections coordinately in common scenarios or aborting them when they represent some risk.