Summary

  • TIME-WAIT protects a future connection incarnation from delayed segments left by an earlier one; it is not a retransmission timer or a user-delivery deadline.
  • RFC 1337 demonstrated a three-segment failure chain in which an old unacceptable segment elicited an ACK, the peer reflected that ACK as RST, and the reset prematurely deleted TIME-WAIT.
  • The document proposed ignoring resets in TIME-WAIT, but it was Informational and asked for production testing; the current TCP base specification still describes close-on-RST behavior after validation.
  • RFC 6191 took a different route for high connection rates: admit certain new SYNs early only when sequence-number and timestamp evidence support a newer incarnation.

A safety state, not idle debris

TCP connections are identified by a pair of endpoint addresses and ports. Those four values can be reused. Packets, however, do not disappear merely because an application has closed its socket. A delayed duplicate from an earlier connection can remain in the network long enough to meet a later connection with the same identifying tuple.

TIME-WAIT is one of TCP's defenses against that ambiguity. The active closer retains a transmission control block after the closing handshake, ordinarily for twice the maximum segment lifetime. The interval gives old duplicates time to die before the same connection identity is treated as entirely free. RFC 9293 expresses that purpose directly: TIME-WAIT helps ensure the peer received the final acknowledgment and prevents delayed segments from one incarnation from affecting the next.

That retained state can resemble waste on a busy server. RFC 1337's insight was that it was also fragile. The state machine itself could be induced to remove it before the interval expired.

Three ordinary responses form one hazardous chain

The assassination example begins after a normal close. Endpoint A has entered TIME-WAIT. Endpoint B has already discarded its corresponding connection state.

An old data or ACK segment then reaches A. Its sequence number may be outside A's acceptable window, or its timestamp may fail a protection-against-wrapped-sequences check. A follows the ordinary rule for an unacceptable non-reset segment and sends an acknowledgment carrying its current sequence expectations.

B receives that acknowledgment but has no connection matching the tuple. In CLOSED state, an incoming non-reset segment causes TCP to send a reset. The reset returns to A. Under the reset-processing rule analyzed by RFC 1337, A accepts it, deletes the control block and leaves TIME-WAIT early.

Nothing in the chain requires a malicious sender. A delayed duplicate, an ACK generated by a still-existing safety state, and a reset generated by a peer with no state are each intelligible local actions. Their composition defeats the purpose of the interval. RFC 1337 named the result “TIME-WAIT assassination.”

What the assassination exposes

Deleting TIME-WAIT does not prove that the network is free of old packets. It proves only that a reset arrived and was accepted. Once the tuple is reused, an old data segment might fall inside the new connection's receive space; an old acknowledgment might incorrectly advance the new sender; or a duplicate acknowledgment might disturb congestion behavior. RFC 1337 separated these into several hazards because the corrupting packet need not be the same packet that killed TIME-WAIT.

This distinction matters. The assassin is the reset that removes the state. The later hazard may be caused by a different duplicate that survived in the network. Treating early deletion as evidence of safety reverses cause and proof.

The simple fix, and its boundary

RFC 1337's preferred short-term remedy, F1, was plain: ignore RST segments while in TIME-WAIT. If the assumed maximum segment lifetime is actually enforced, preserving the state for the full interval avoids the three hazards described in the document. The argument is structural. If one purpose of TIME-WAIT is to let old duplicates expire, an arriving reset should not truncate that protection.

The historical qualification is just as important. RFC 1337 is Informational. It called F1 the simplest and best short-term answer, but it also said extended production testing would be desirable to discover unexpected effects. It did not turn the proposal into a universal statement about every stack.

The current consolidated TCP specification, RFC 9293, retains a different base rule. In its processing for synchronized states, after sequence validation, a reset in TIME-WAIT leads to CLOSED and deletion of the control block. A history of the mechanism therefore cannot say that the ignore-reset proposal simply became the modern base state machine. The record preserves a tension between the hazard analysis and the standardized processing text.

Early reuse needs evidence, not disappearance

RFC 6191 addressed a related operational pressure: high rates of new connections can encounter a matching tuple still in TIME-WAIT. Its algorithm does not merely kill the old state. It changes the handling of incoming SYN segments and asks whether the SYN carries evidence of a newer incarnation.

When timestamps were used previously, a greater timestamp can support accepting the request. Equal timestamps require a greater initial sequence number. When timestamps are absent in the relevant combination, sequence-number comparisons provide the remaining test. If the evidence does not pass, TCP silently drops the incoming SYN and leaves the prior incarnation in TIME-WAIT.

RFC 9293 incorporates this distinction. It requires an active closer to linger for 2xMSL, permits direct reopening only with sequence safeguards, and recommends the timestamp-based RFC 6191 algorithm for busy endpoints. Guarded reuse and reset-driven deletion may both shorten the practical obstacle presented by TIME-WAIT, but they are not equivalent. One tests the new request against retained history; the other throws that history away.

Sources