The tcp protocol actions on arriving segment vary. The set of choices includes:

  • silently drop segment
  • kill connection (i.e. enter CLOSED)
  • send reset (and maybe kill connection)
  • send dup/null ack
  • (etc)

Some decisions are obvious, some aren't. The ones embarrassing me now are actions for SYN-RECEIVED state if arriving segment has

  1. invalid ACK (page 72 of rfc793, step 5) or
  2. invalid security (page 71 of rfc793, step 3)

In both cases the action is merely `send reset'.

Do we really expect that our party will correct it's mistake and send new, valid segment? No. Then, we merely send a reset to achieve what? Why not

  • kill connection or
  • retransmit syn-ack

like synchronized states do for such segments?

  • You are asking why a RST is sent, so why not kill the connection. Sending a RST kills the connection.
    – Ron Maupin
    Nov 24 '17 at 21:45
  • ... at remote side, @Ron. But local connection state SYN-RECEIVED is kept carefully. What for?
    – jabba
    Nov 27 '17 at 8:05

why not kill the connection

The question about ACKs has the following textbook answer:

IP is an unreliable network layer. Among others packets can be delayed by a large amount (at least in theory, AFAIK that also happened in practice when TCP was designed). Thus TCP should be able to handle receiving wrong packets, in particular packets from previous connections that are arbitrary delayed.

Thus, when TCP receives a segment for the same socket, which however has wrong sequence number, it cannot distinguish between the client making a mistake and a network delivering outdated packet. Thus it would be a mistake to kill the new connection on possibly outdated packet. TCP also has random sequence numbers precisely for this situation. New connection should choose initial sequence numbers so that outdated packets will not fit in receiver window with "very high probability". This could happen though...

So, no, TCP does not expect the other peer to recover. Instead, if this was indeed a mistake of the other peer, the other peer receives a RST, which kills the connection on that peer's side. It just cannot know if the other peer indeed did a mistake or something wrong happened in the network.

I am not sure about security, since I never new about it but I think the same logic applies

Why not Re-transmitting SYNACK

It kinda looks like, retransmitting SYNACK actually happens. However it happens on a timer, not on a wrong segment, i believe, for reasons described above.

There is a trace with retransmitted synacks here and here.

A note about killing SYN-RECEIVED

Killing a TCP connection involves mostly deallocating memory for connection state (the TCP control block or TCB in the rfc). If you read through the specification, you may notice that it specifies allocation and de-allocation of connection state mostly as result of user action, not result of incoming packets (deleting TCB on transition to close is specified as well, but it is more to ensure that the opposite does not happen). This should tell you, that it is implementation detail on how to handle deallocating connection state for sockets in SYN-RECEIVED state.

In practice, it is advisable to only allocate small number of strictly necessary state for SYN-RECEIVED, and only allocate whole TCP control block when the ACK from the peer (third handshake message) is received. This is done to protect against so called Syn-Flood Attack. You can read about it here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.