Two programs use a TCP connection (3-way handshake) to open, communicate, terminate the connection and open a new connection. If a FIN message sent to shut down the first connection is duplicated and delayed until the second connection has been established, then delivered, will the new connection be terminated?
2 Answers
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
-
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.– Ron Maupin ♦May 5, 2019 at 3:04
-
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.– AlexisMay 5, 2019 at 3:15
-
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.– Ron Maupin ♦May 5, 2019 at 3:21
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each Host. However, it proves useful to attach frequently used processes (e.g., a "logger" or timesharing service) to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides.
When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.
If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.
If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.