Practical TCP Series - Connection Teardown - Expected and Unexpected

This is the fifth TCP article in the 5-part “Practical TCP Series”. In this series we have learned the fundamentals of TCP. We've looked into how TCP connections are established, we described the TCP Flags, explored the operation of the TCP Window, and we’ve seen how sequence and acknowledgment numbers work. Now we will look at how a TCP connection is closed. Why do we care? The TCP connection was established, data was transferred, and ACKs were sent. Isn’t that all we care about? No. It is important that the TCP connection eventually be torn down. Why? Because open connections take up host and server resource, and a server can only support so many connections. One way that attackers can compromise servers is by starting multiple connections using the a three way handshake on hundreds or thousands of ports, without going back and tearing down the connection. The server will hold the socket open for awhile, and it will eventually run out of connections to support new users. The server may become unavailable or very slow in response. This is called a SYN Attack. This is not as common as it used to be with modern security measures, but the threat is still there in some environments.

How is a TCP connection closed? There are two ways. I like to refer to these as the “kind and friendly” way and the “buzz off” way. The kind and friendly way a TCP connection is torn down is by using the FIN bit in the TCP Flags. One side of the connection sends a packet with the TCP Finished bit set. The other side of the connection responds with two packets, an ACK , and a FIN of it’s own. This last FIN is acknowledged by the original station, indicating that the connection has been closed on both sides.

A FIN can originate from the client or the server. If there has been no activity on the connection for a set amount of time, the connection can be shut down to free up resource for another user. There are a few exceptions to this four-way tear-down with FINs, but for now let’s keep it simple. The other way a connection can be closed is by using the reset bit in the TCP Flags field. A reset indicates that this connection is considered closed, and there is no need to send additional packets. We commonly see these when TCP data packets are sent to a server where no connection has been established, or when SYNs are sent to a port that the server is not listening on. The server should reply with a reset, showing the connection is closed or unavailable.

We can also see resets sent in some applications when a user is suddenly kicked out of an application. Something unexpected happened in the server and the TCP connection was reset from the server. Especially when we are looking for causes of application drops, we will look for TCP Resets.

A reset is an abrupt way to tear down the connection, and should not be overlooked in a trace file. That is not to say that they are all bad, but when looking for application problems, make sure to fully understand why a reset was sent.

That wraps up the 5 part Practical TCP Series. Hopefully these articles helped to get the basics of TCP and get started with interpreting the headers. The best thing to do now is to start capturing and interpreting what TCP is doing.

Thank you as for all of the positive response to the Practical TCP Series!

Make sure to go back and check out the other articles in this series.

1. The Connection Setup

2. TCP Flags

3. The TCP Window

4. Sequence and Acknowledgement Numbers

Author Profile - Chris Greer is a Network Analyst for Packet Pioneer. Chris has many years of experience in analyzing and troubleshooting networks. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. When he isn’t hunting down problems at the packet level, he can be found teaching various analysis workshops at Interop and other industry trade shows. Chris also delivers training and develops technical content for several analysis vendors.