TCP/IP: TCP Connection Management

TCP supports a half-close operation. Few applications require this capability, so it is not common.

To use this feature, the API must provide a way for the application to say, essentially, "I am done sending data, so send a FIN to the other end, but I still want to receive data from the other end, until it sends me a FIN".

The Berkeley sockets API supports half-close, if the application calls the shutdown() function instead of calling the more typical close() function. Most applications, however, terminate both directions of the connection by calling close.

It is possible, although highly improbable unless specifically arranged, for two applications to perform an active open to each other at the same time. If this happens, it is called a simultaneous open.

With a simultaneous close the same number of segments are exchanged as in the normal close. The only real difference is that the segment sequence is interleaved instead of sequential.

When a connection is open, any segment with the appropriate two IP addresses and port numbers is accepted as valid provided the sequence number is valid (i.e., within the window) and the checksum is OK.

Before each end sends its SYN to establish the connection, it chooses an ISN for that connection.

If a connection had one of its segments delayed for a long period of time and closed, but then opened again with the same 4-tuple, it is conceivable that the delayed segment could reenter the new connection’s data stream as valid data.

The connection 4-tuple as well as the currently active window of sequence numbers is all that is required to form a TCP segment that is considered valid to a communicating TCP endpoint, which represents a form of vulnerability for TCP:

There are several circumstances in which a connection cannot be established. One obvious case is when the server host is down.

To simulate this scenario, we issue our telnet command to a nonexistent host in the same subnet.

The number of times to retry an initial SYN can be configured on some systems. In Linux,

The maximum segment size (MSS) is the largest segment that a TCP is willing to receive from its peer and, consequently, the largest size its peer should ever use when sending.

Because it uses cumulative ACKs, TCP with a sliding window is never able to acknowledge data it has received correctly but that is not contiguous, in terms of sequence numbers, with data it has received previously.

If a TCP sender were able to learn of the existence of holes (and out-of-sequence data blocks beyond holes in the sequence space) at the receiver, it could better select which particular TCP segments to retransmit when segments are lost or otherwise missing at the receiver.

SACK information contained in a SACK option consists of a range of sequence numbers representing data blocks the receiver has successfully received.

The Window Scale option (denoted WSCALE or WSOPT) [RFC1323] effectively increases the capacity of the TCP Window Advertisement field from 16 to about 30 bits.

Instead of changing the field size, however, the header still holds a 16-bit value, and an option is defined that applies a scaling factor to the 16-bit value.

This option can appear only in a SYN segment, so the scale factor is fixed in each direction when the connection is established.

Assume we are using the Window Scale option, with a shift count of S for sending and a shift count of R for receiving.

The shift count is automatically chosen by TCP, based on the size of the receive buffer. The size of this buffer is set by the system, but the capability is normally provided for the application to change it.

The Window Scale option is most relevant when TCP is used to provide bulk data transfer over networks with large-bandwidth-delay products (i.e., those with a product of round-trip time and bandwidth being relatively large).

The Timestamps option (sometimes called the Timestamp option and written as TSOPT or TSopt) lets the sender place two 4-byte timestamp values in every segment.

The receiver reflects these values in the acknowledgment, allowing the sender to calculate an estimate of the connection’s RTT for each ACK received.

The main reason for wishing to calculate a good estimate of the connection’s RTT is to set the retransmission timeout, which tells TCP when it should try resending a segment that is likely lost.

The Timestamps option allows for more frequent RTT samples, but it also provides a way for the receiver to avoid receiving old segments and considering them as valid, which is called Protection Against Wrapped Sequence Numbers (PAWS), and it is described in [RFC1323] along with the Timestamps option.

The User Timeout (UTO) option is a relatively new TCP capability described in [RFC5482]. The UTO value (also called USER_TIMEOUT) specifies the amount of time a TCP sender is willing to wait for an ACK of outstanding data before concluding that the remote end has failed.

USER_TIMEOUT has traditionally been a local configuration parameter for TCP [RFC0793]. The UTO option allows one TCP to signal its USER_TIMEOUT value to its connection peer. This allows the receiving TCP to adjust its behavior (e.g., to tolerate a longer period of disrupted connectivity prior to aborting a connection). NAT devices could also interpret such information to help set their connection activity timers.

UTO option values are advisory; just because one end of a connection might wish to use a large or small UTO value does not mean that the other end needs to comply.

UTO options are included on SYN segments when a connection is established, on the first non-SYN segments, and whenever the USER_TIMEOUT value is changed. The option value is expressed as a 15-bit value in units of seconds or minutes following a bit field (granularity) that indicates that the value is in minutes (1) or seconds (0). As a relatively new option, it is not yet widely deployed.

There is an option used to enhance the security of TCP connections. It is designed to enhance and replace an earlier mechanism called TCP-MD5 [RFC2385]. Called the TCP Authentication Option (TCP-AO) [RFC5925], it uses a cryptographic hash algorithm, in combination with a secret value known to each end of a TCP connection, to authenticate each segment.

TCP-AO improves upon TCP-MD5 by supporting a variety of cryptographic algorithms and identifying changing of keys using in-band signaling. It does not provide a comprehensive key management solution, however. That is, each end still has to have a way to establish a shared set of keys prior to operation.

However, because it requires creation and distribution of a shared key (and is a relatively new option), it is not yet widely deployed.

The TIME_WAIT state is also called the 2MSL wait state, which is a state in which TCP waits for a time equal to twice the Maximum Segment Lifetime (MSL), sometimes called timed wait. It is the maximum amount of time any segment can exist in the network before being discarded.

[RFC0793] specifies the MSL as 2 minutes. Common implementation values, however, are 30s, 1 minute, or 2 minutes.

Given the MSL value for an implementation, the rule is: When TCP performs an active close and sends the final ACK, that connection must stay in the TIME_WAIT state for twice the MSL. This lets TCP resend the final ACK in case it is lost.

Another effect of this 2MSL wait state is that while the TCP implementation waits, the endpoints defining that connection cannot be reused. That connection defined by the address/port 4-tuple can be reused

Unfortunately, some implementations impose a more stringent constraint. In these systems, a local port number cannot be reused while that port number is the local port number of any endpoint that is in the 2MSL wait state on the system.

Most implementations and APIs provide a way to bypass this restriction.

With the Berkeley sockets API, the SO_REUSEADDR socket option enables the bypass operation.

For interactive applications, it is normally the client that does the active close and enters the TIME_WAIT state. The server usually does the passive close and does not go through the TIME_WAIT state.

The 2MSL wait provides protection against delayed segments from an earlier instantiation of a connection being interpreted as part of a new connection that uses the same local and foreign IP addresses and port numbers. But this works only if a host with connections in the 2MSL wait does not crash.

What if a host with connections in the TIME_WAIT state crashes, reboots within the MSL, and immediately establishes new connections using the same local and foreign IP addresses and port numbers corresponding to the local connections that were in the TIME_WAIT state before the crash? In this scenario, delayed segments from the connections that existed before the crash can be misinterpreted as belonging to the new connections created after the reboot. This can happen regardless of how the initial sequence number is chosen after the reboot.

To protect against this scenario, [RFC0793] states that TCP should wait an amount of time equal to the MSL before creating any new connections after a reboot or crash. This is called the quiet time. Few implementations abide by this because most hosts take longer than the MSL to reboot after a crash. Also, if applications use their own checksums or encryption, errors such as these are easily detected.

In the FIN_WAIT_2 state, TCP has sent a FIN and the other end has acknowledged it.

Many implementations prevent this infinite wait in the FIN_WAIT_2 state as follows:

In Linux, the variable net.ipv4.tcp_fin_timeout can be adjusted to control the number of seconds to which the timer is set. Its default value is 60s.

We have seen the normal uses for the SYN_SENT and SYN_RCVD states that correspond to sending and receiving SYN segments, respectively. As illustrated in Figure 13-3, TCP was purposely designed to handle simultaneous opens that result in a single connection.

When a simultaneous open occurs, both ends send a SYN at about the same time, entering the SYN_SENT state.

For a simultaneous close, both ends go from ESTABLISHED to FIN_WAIT_1 when the application issues the close. This causes both FINs to be sent, and they probably pass each other somewhere in the network.

A common case for generating a reset segment is when a connection request arrives and no process is listening on the destination port.

Because the ACK bit field was not on in the arriving SYN segment, the sequence number of the reset is set to 0 and the ACK number is set to the incoming ISN plus the number of data bytes in the segment.

The normal way to terminate a connection is for one side to send a FIN, which is sometimes called an orderly release because the FIN is sent after all previously queued data has been sent, and there is normally no loss of data. But it is also possible to abort a connection by sending a reset instead of a FIN at any time which is sometimes called an abortive release.

Aborting a connection provides two features to the application:

The sockets API provides this capability by using the linger on close socket option (SO_LINGER) with a 0 linger value, which essentially this means Linger for no time in making sure data gets to the other side, then abort.

In the following example, we show what happens when a remote command that generates a large amount of output is canceled by the user:

TCP reset attack, also known as a "forged TCP reset" or "spoofed TCP reset", is a way to terminate a TCP connection by sending a forged TCP reset packet. This tampering technique can be used by a firewall or abused by a malicious attacker to interrupt Internet connections. [RSTATTACK]

The Great Firewall of China, and Iranian Internet censors are known to use TCP reset attacks to interfere with and block connections, as a major method to carry out Internet censorship.

By encrypting connections using a VPN, the attacker has to do a TCP reset attack on all encrypted connections, causing collateral damage.

A TCP connection is said to be half-open if one end has closed or aborted the connection without the knowledge of the other end.

Another common cause of a half-open connection is when one host is powered off instead of shut down properly. This happens, for example,

We can easily create a half-open connection. In this case, we do so on the client rather than the server.

During TIME-WAIT state period, the waiting TCP usually has little to do; it merely holds the state until the 2MSL timer expires.

If, however, it receives certain segments from the connection during this period, or more specifically an RST segment, it can become desynchronized. This is called TIME-WAIT Assassination (TWA) [RFC1337].

We shall watch the secure shell server (called sshd) using the netstat command on a dual-stack IPv4/IPv6-capable host. The following output is on a system with no active secure shell connections.

We now start a secure shell client on the host through a NAT 192.168.91.1 that connects to this server.

We now initiate another client request from the same system (192.168.91.1) to this server. Here is the relevant netstat output:

We can see what happens when the server does not wildcard the local IP address but instead sets it to one particular local address. If we run our nc program as a server and provide it with a particuclar IP address, that address becomes the local address of the listening endpoint. For example:

If we instead try to connect to this server from a host using a destination address other than 192.168.91.128 (even including the local address 127.0.0.1), the connection request is not accepted by the TCP module, meanwhile the server application never sees the connection request.

If we watch with tcpdump, the SYN elicits an RST segment.

The abstract interface functions for TCP given in [RFC0793] allow a server doing a passive open to have either a fully specified foreign endpoint (to wait for a particular client to issue an active open) or an unspecified foreign endpoint (to wait for any client).

Unfortunately, the ordinary Berkeley sockets API does not provide a way to do this. The server must leave the client’s endpoint unspecified, wait for the connection to arrive, and then examine the IP address and port number of the client.

A concurrent server invokes a new process or thread to handle each client, so the listening server should always be ready to handle the next incoming connection request. That is the underlying reason for using concurrent servers.

But there is still a chance that multiple connection requests will arrive

How does TCP handle these scenarios?

To fully explore this question, we must first understand that new connections may be in one of two distinct states before they are made available to an application.

An application has limited control over the sizing of these queues.

In Linux, then, the following rules apply: