TCP Connection Management(4)

Reset Segments 

A segment hav- ing this bit set to “on” is called a “reset segment” or simply a “reset.”

In general, a reset is sent by TCP whenever a segment arrives that does not appear to be correct for the referenced connection.  

(We use the term referenced connection to mean the connection specified by the 4-tuple in the TCP and IP headers of the reset.) 

Resets ordinarily result in a fast teardown of a TCP connection. 

 

Connection Request to Nonexistent Port 

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

We saw this previously when we encountered the “connection refused” error messages. These are com- mon with TCP.

In the case of UDP, we saw in Chapter 10 that an ICMP Destination Unreachable (Port Unreachable) message is generated when a datagram arrives for a destination port that is not in use.

TCP uses a reset segment instead. 

An example of this is trivial to generate—we use the Telnet client and specify a port number that is not in use on the destination.

This destination can just as well be the local computer.

The values we need to examine in Listing 13-5 are the Sequence Number field and ACK Number field in the reset (second) segment. 

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.  

Although there is no data in the arriving segment, the SYN bit logically occupies 1 byte of sequence number space;

therefore, in this example the ACK number in the reset segment is set to the ISN, plus the data length (0), plus 1 for the SYN bit. 

For a reset segment to be accepted by a TCP, the ACK bit field must be set and the ACK Number field must be within the valid window (see Chapter 12).

This helps to prevent a simple attack in which anyone able to generate a reset matching the appropriate connection (4-tuple) could disrupt a connection [RFC5961]. 

 

Aborting a Connection 

But it is also possible to abort a connection by sending a reset instead of a FIN at any time.

This is sometimes called an abortive release(instead of orderly release of FIN).

Aborting a connection provides two features to the application:

(1) any queued data(the receiver side) is thrown away and a reset segment is sent immediately, and

(2) the receiver of the reset can tell that the other end did an abort instead of a normal close. 

The sockets API provides this capability by using the “linger on close” socket option (SO_LINGER) with a 0 linger value.

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: 

Linux% ssh linux cat /usr/share/dict/words 

When the interrupt character is hit, the connection is aborted.

The reset segment contains a sequence number and acknowledgment number. 

Also notice that the reset segment elicits no response from the other end—it is not acknowledged at all. 

The receiver of the reset aborts the connection and advises the application that the connection was reset. 

This often results in the error indication “Connection reset by peer” or a similar message. 

 

Half-Open Connections 

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

This can happen anytime one of the peers crashes.

As long as there is no attempt to transfer data across a half-open connection, the end that is still up does not detect that the other end has crashed. 

Another common cause of a half-open connection is when one host is pow- ered off instead of shut down properly.

This happens, for example, when PCs are being used to run remote login clients and are switched off at the end of the day.

If there was no data transfer going on when the power was cut, the server will never know that the client disappeared

(it would still think the connection is in the ESTABLISHED state).

When the user comes in the next morning, powers on the PC, and starts a new session, a new occurrence of the server is started on the server host.

This can lead to many half-open TCP connections on the server host.

(In Chapter 17 we will see a way for one end of a TCP connection to discover that the other end has disappeared using

TCP’s keepalive option.) 

TODO

 

TIME-WAIT Assassination (TWA) 

If, however, (when in TIME_WAIT state)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]. 

In the example shown in Figure 13-10, the server has completed its role in the connection and cleared any state.

The client remains in the TIME_WAIT state. When the FIN exchange completes, the client’s next sequence number is K and the server’s is L.

The late-arriving segment is sent from the server to the client using sequence number L - 100 and containing ACK number K - 200.

When the cli- ent receives this segment, it determines that both the sequence number and ACK values are “old.”

When receiving such old segments, TCP responds by sending an ACK with the most current sequence number and ACK values

(K and L, respec- tively).(PLEASE CONSIDER THIS IS WHY?)

However, when the server receives this segment, it has no information whatsoever about the connection and therefore replies with an RST segment. 

This is no problem for the server, but it causes the client to prematurely transition from TIME_WAIT to CLOSED.

Most systems avoid this problem by simply not reacting to reset segments while in the TIME_WAIT state.