Re: Unacceptable ACK in SYN_RCVD state handling

Bob Braden <braden@ISI.EDU> Mon, 08 April 2002 21:45 UTC

From: Bob Braden <braden@ISI.EDU>
Date: Mon, 8 Apr 2002 21:45:31 GMT
Message-Id: <200204082145.VAA04951@gra.isi.edu>
To: tcp-impl@grc.nasa.gov, mbashyam@cisco.com
Subject: Re: Unacceptable ACK in SYN_RCVD state handling
X-Sun-Charset: US-ASCII
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1526
Lines: 43

  *> From owner-tcp-impl@grc.nasa.gov  Fri Apr  5 11:22:21 2002
  *> Date: Fri, 05 Apr 2002 11:14:22 -0800
  *> From: Murali Bashyam <mbashyam@cisco.com>
  *> X-Accept-Language: en
  *> MIME-Version: 1.0
  *> To: tcp-impl@grc.nasa.gov
  *> Subject: Unacceptable ACK in SYN_RCVD state handling
  *> Content-Transfer-Encoding: 7bit
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> Hi
  *> 
  *> In SYN_RECEIVED state after sending a SYN-ACK to the peer, when TCP
  *> receives a unacceptable ACK
  *> i.e the ACK lies outside the receive window, it is supposed to drop the
  *> incoming ACK and respond with a pure ACK as it should for any packet
  *> that is completely outside the receive window. This is reqd as per RFC
  *> 793.
  *> 
  *> In BSD TCP code (FREEBSD/NETBSD) i notice that in SYN-RECEIVED state any
  *> 
  *> outgoing segment generated would carry the SYN bit as well as the ACK
  *> bit set. So BSD code, when it responds with a ACK in the above scenario
  *> also has the SYN bit set. Is this acceptable behaviour? Linux responds
  *> with a pure ACK in this scenario.
  *> 
  *> Murali
  *> 
  *> 
  *> 

Hmmm.  I was about to say that:

	The TCP has sent a SYN,ACK and its SYN has not been acknowledged.  It
	is still in SYN RECEIVED state, so retransmitting the SYN seems to me
	to be acceptable behavior in this situation.

But glancing at RFC 793, it appears that it says to send a RST segment
at that point (ACK bit on and unacceptable ACK in SYN RECEIVED state,
page 72 of RFC 793.)

Bob Braden