TCP Connection Management

TCP Connection Management

In this section well examine how a TCP connection is established and torn down. Though this topic may not seem particularly exciting, it is important because TCP connection establishment can considerably add to perceived delays (for instance, when surfing the Web). Moreover, many of the most common network attacks - including the incredibly popular SYN flood attack - exploit vulnerabilities in TCP connection management. Let's first consider how a TCP connection is established. Assume a process running in one host (client) wants to initiate a connection with another process in another host (server). The client application process first informs the client TCP that it wants to establish a connection to a process in the server. The TCP in the client then proceeds to establish a TCP connection with the TCP in the server in the following manner:

●  Step 1. The client-side TCP first sends a special TCP segment to the server-side TCP. This special segment includes no application-layer data. But one of the flag bits in the segment's header (see "TCP Segment Structure" Figure 1), the SYN bit, is set to 1. That's why, this special segment is referred to as a SYN segment. Moreover, the client randomly chooses an initial sequence number (client_isn) and puts this number in the sequence number field of the initial TCP SYN segment. This segment is encapsulated within an IP datagram and sent to the server. There has been a lot of interest in properly randomizing the choice of the client_isn in order to avoid certain security attacks.

●  Step 2. Once the IP datagram including the TCP SYN segment arrives at the server host (assuming it does arrive), the server extracts the TCP SYN segment from the datagram, assigns the TCP buffers and variables to the connection, and sends a connection-granted segment to the client TCP. (We'll see in "Security in Computer Networks" that the allocation of these buffers and variables before completing the third step of the three-way handshake makes TCP vulnerable to a denial-of-service attack known as SYN flooding.) This connection-granted segment also includes no application-layer data. On the other hand, it does include three important pieces of information in the segment header. First, the SYN bit is set to 1. Second, the acknowledgment field of the TCP segment header is set to client_isn+1. Lastly, the server selects its own initial sequence number (server_isn) and puts this value in the sequence number field of the TCP segment header. This connection-granted segment is saying, in effect, "I received your SYN packet to start a connection with your initial sequence number, client_isn. I agree to establish this connection. My own initial sequence number is server_isn". The connection-granted segment is referred to as a SYNACK segment.

●  Step 3. Upon receiving the SYNACK segment, the client also assigns buffers and variables to the connection. The client host then sends the server yet another segment; this last segment acknowledges the server's connection-granted segment (the client does so by putting the value server_isn+1 in the acknowledgment field of the TCP segment header). The SYN bit is set to zero, since the connection is established. This third stage of the three-way handshake may carry client-to-server data in the segment payload.

Once these three steps have been completed, the client and server hosts can send segments containing data to each other. In each of these future segments, the SYN bit will be set to zero. Note that in order to establish the connection, three packets are sent between the two hosts, as shown in Figure 1. That's why, this connection-establishment procedure is frequently referred to as a three-way handshake. It's interesting to note that a rock climber and a  belayer (who is stationed below the rock climber and whose job is to handle the climber's safety rope) use a three-way-handshake  communication protocol that is identical to TCP's to ensure that both sides are ready before the climber begins ascent.

All good things must come to an end, and the same is true with a TCP connection. Either of the two processes participating in a TCP connection can end the connection. When a connection ends, the "resources" (that is, the buffers and variables) in the hosts are deallocated. As an instance, assume the client decides to close the connection, as illustrated in Figure 2. The client application process issues a close command,

TCP three-way handshake - segment exchange

This causes the client TCP to send a special TCP segment to the server process. This special segment has a flag bit in the segment's header, the FIN bit (see "TCP Segment Structure" Figure 1), set to 1. When the server receives this segment, it sends the client an acknowledgment segment in return. The server then sends its own shutdown segment, which has the FIN bit set to 1. At last, the client acknowledges the server's shutdown segment. At this point, all the resources in the two hosts are now deallocated.

During the life of a TCP connection, the TCP protocol running in each host makes transitions through several TCP states. Figure 3 shows a typical sequence of TCP states that are visited by the client TCP. The client TCP begins in the CLOSED state. The application on the client side initiates a new TCP connection (by creating a Socket object in our Java examples from "Application Layer"). This causes TCP in the client to send a SYN segment to TCP in the server. Alter having sent the SYN segment, the client TCP enters the SYN_SENT state. While in the SYN_SENT state, the client TCP waits for a segment from the server TCP that includes an acknowledgment for the client's previous segment and has the SYN bit set to 1. Having received such a segment, the client TCP enters the ESTABLISHED state. While in the ESTABLISHED state, the TCP client can send and receive TCP segments including payload (that is, application-generated) data.

Closing a TCP connection

Assume that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection.)  This causes the client TCP to send a TCP segment with the FIN bit set to 1 and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client TCP waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client TCP enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1; after receiving this segment, the client TCP acknowledges the server's segment and enters the TIME_WAIT state. The TIME_WAIT state lets the TCP client resend the final acknowledgment in case the ACK is lost. The time spent in the TIME_WAIT state is implementation-dependent, but typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers) are released.

Figure 4 shows the series of states usually visited by the server-side TCP, assuming the client begins connection teardown. The transitions are self-explanatory. In these two state-transition diagrams, we have only shown how a TCP connection is normally established and shut down.

A typical sequence of TCP states visited by a client TCP


A typical sequence of TCP states visited by a server-side TCP

THE SYN FLOOD ATTACK

We have not explained what happens in certain pathological scenarios, for instance, when both sides of a connection want to initiate or shut down at the same time. If you are interested in learning about this and other advanced issues concerning TCP, you are encouraged to see Stevens comprehensive book [Stevens 1994].

Our discussion above has assumed that both the client and server are prepared to communicate, i.e., that the server is listening on the port to which the client sends its SYN segment. Lets examine what happens when a host receives a TCP segment whose port numbers or source IP address do not match with any of the ongoing sockets in the host. For instance, suppose a host receives a TCP SYN packet with destination port 80, but the host is not accepting connections on port 80 (that is, it is not running a Web server on port 80). Then the host will send a special reset segment to the source. This TCP segment has the RST flag bit (see "TCP Segment Structure") set to 1. Therefore, when a host sends a reset segment, it is telling the source "I don't have a socket for that segment. Please do not resend the segment". When a host receives a UDP packet whose destination port number doesn't match with an ongoing UDP socket, the host sends a special ICMP datagram, as explained in "The Network Layer".

Now that we have a good understanding of TCP connection management, lets revisit the nmap port-scanning tool and look at more closely how it works. To explore a specific TCP port, say port 6789, on a target host, nmap will send a TCP SYN segment with destination port 6789 to that host. There are three possible outcomes:

●  The source host receives a TCP SYNACK segment from the target host. Since this means that an application is running with TCP port 6789 on the target post, nmap returns "open".

●  The source host receives a TCP RST segment from the target host. This means that the SYN segment reached the target host, but the target host is not running an application with TCP port 6789. But the attacker at least knows that the segments destined to the host at port 6789 are not blocked by any firewall on the path between source and target hosts. (Firewalls are explained in "Security in Computer Networks")

●  The source receives nothing. This likely means that the SYN segment was blocked by an intervening firewall and never reached the target host.

Nmap is a powerful tool, which can "case the joint" not only for open TCP ports, but also for open UDP ports, for firewalls and their configurations, and even for the versions of applications and operating systems. Most of this done by manipulating TCP connection-management segments [Skoudis 2006]. If you happen to be sitting near a Linux machine, you may want to give nmap a whirl right now by  simply typing "nmap" at the command line. You can download nmap for other operating systems from http://insecure.org/nmap.

This ends our discussion to error control and flow control in TCP. In "TCP Congestion Control" well return to TCP and examine TCP congestion control in some depth. Before doing so, however, we first step back and look at congestion-control issues in a wider context.

Tags

tcp connection, tcp segment, ip datagram, payload, router, synack segment

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.