Re: [tcpm] SYN in SYN_RCVD state

Ted Faber <faber@ISI.EDU> Mon, 22 October 2007 18:03 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1cf-0006of-NV; Mon, 22 Oct 2007 14:03:29 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ik1cd-0006ir-F3 for tcpm-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 14:03:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1cc-0006i7-25 for tcpm@ietf.org; Mon, 22 Oct 2007 14:03:26 -0400
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik1bY-00006S-2G for tcpm@ietf.org; Mon, 22 Oct 2007 14:03:26 -0400
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l9MI1HNc027836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Oct 2007 11:01:18 -0700 (PDT)
Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l9MI1HJR008021; Mon, 22 Oct 2007 11:01:17 -0700 (PDT) (envelope-from faber)
Date: Mon, 22 Oct 2007 11:01:16 -0700
From: Ted Faber <faber@ISI.EDU>
To: Vishal Study <vishal.study@gmail.com>
Subject: Re: [tcpm] SYN in SYN_RCVD state
Message-ID: <20071022180116.GE24089@hut.isi.edu>
References: <a517c2ff0710191935i5c84bf87qf6d634e71a6c3471@mail.gmail.com> <4719EB76.6040605@tlc.polito.it> <a517c2ff0710210425t5540ab3ex16e00d391f9c8619@mail.gmail.com>
Mime-Version: 1.0
In-Reply-To: <a517c2ff0710210425t5540ab3ex16e00d391f9c8619@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: tcpm@ietf.org, Marco Mellia <mellia@tlc.polito.it>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2074520409=="
Errors-To: tcpm-bounces@ietf.org

On Sun, Oct 21, 2007 at 04:25:25AM -0700, Vishal Study wrote:
> > Vishal Study ha scritto:
> > > 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?
> > >
> 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?

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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm