Subject: [tcpm] SYN in SYN_RCVD state

From: "Vishal Study" <[email-masked]>
Date: Fri, 19 Oct 2007 19:35:34 -0700

Consider the following scenario:

1. TCP client sends SYN to server; server goes to SYN_SENT state

2. server responds with SYN+ACK;  server goes to SYN_RCVD state
but SYN+ACK sent to client is lost somewhere in the network.

3. client re-sends SYN on its timeout (couple of seconds later) to server

What should be the server behavior? Should it retransmit SYN+ACK or
should it send a RST?

thanks!

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Vishal Study" <[email-masked]>
Date: Sun, 21 Oct 2007 04:25:25 -0700

But RFC 793, pg 71 seem to say that the server should send out a RST
if SYN is rx in SYN-RCVD state (assuming SYN seq number is within the
window, which is true in the example I had mentioned).

Any thoughts on this?

Thanks!

On 10/20/07, Marco Mellia <[email-masked]> wrote:
> Vishal Study ha scritto:
> Clearly the first case!
> Marco

---

From: "Agarwal, Anil" <[email-masked]>
Date: Sun, 21 Oct 2007 15:17:32 -0400

On October 21, 2007, Vishal wrote -

> window, which is true in the example I had mentioned).

Your example is covered by the rules on page 68 of RFC 793. The
retransmitted SYN segment is a duplicate segment and is outside
the receive window (SEG.SEQ is < RCV.NXT). 
Hence, the receiver sends an Acknowledgement and discards the segment.

Anil

Anil Agarwal
ViaSat Inc.
Germantown, MD 20876
USA

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 Oct 2007 11:01:16 -0700

> window, which is true in the example I had mentioned).

I think that because RCV.NEXT was set to SEG.SEQ+1 when the "server"
entered SYN-RECEIVED state (as documented on page 66 of 793) the resent
SYN is outside the window and will be acked.  The "server's" SYN+ACK
will be resent if it times out.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Vishal Study" <[email-masked]>
Date: Mon, 22 Oct 2007 12:37:23 -0700

Hi Ted:

The server would retransmit SYN+ACK when server times out in SYN-RECEIVED state.
I agree and have seen this.

But, when the server hasn't timed out in SYN-RECEIVED state and it
receives retransmitted SYN from client (due to client's timeout), what
is the expected behavior on server side? Is server supposed to send
SYN+ACK?

Thanks!

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 Oct 2007 13:32:08 -0700

> is the expected behavior on server side? Is server supposed to send

The spec says no.   RFC793 p 69 gives the sequence number test and the
ACK requirement:

----
   first check sequence number

      SYN-RECEIVED STATE
      ESTABLISHED STATE
      FIN-WAIT-1 STATE
      FIN-WAIT-2 STATE
      CLOSE-WAIT STATE
      CLOSING STATE
      LAST-ACK STATE
      TIME-WAIT STATE

        Segments are processed in sequence.  Initial tests on arrival
        are used to discard old duplicates, but further processing is
        done in SEG.SEQ order.  If a segment's contents straddle the
        boundary between old and new, only the new parts should be
        processed.

[table and some text snipped.  None of it applies; the segment is
outside the window and unacceptable. ]

        If an incoming segment is not acceptable, an acknowledgment
        should be sent in reply (unless the RST bit is set, if so drop
        the segment and return):

          <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

        After sending the acknowledgment, drop the unacceptable segment
        and return.
----

I can imagine an implementor sending a SYN+ACK here, but it would be
outside the spec.  I assume you have no basis for sending one.

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Oct 2007 15:00:44 -0700

Ted Faber wrote:
> The spec says no. 

Agreed. FWIW, Ted already said there are two separate events:

1) the arriving retransmitted SYN causes the server to send an ACK

2) a timeout on the server associated with sending the SYN-ACK goes off,
and the server resends the SYN-ACK then

(1) doesn't cause (2); timeout does.

Joe