Re: Unacceptable ACK in SYN_RCVD state handling

Murali Bashyam <mbashyam@cisco.com> Mon, 08 April 2002 22:51 UTC

Message-ID: <3CB21F06.1DA07E61@cisco.com>
Date: Mon, 08 Apr 2002 15:51:51 -0700
From: Murali Bashyam <mbashyam@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Cc: tcp-impl@grc.nasa.gov
Subject: Re: Unacceptable ACK in SYN_RCVD state handling
References: <200204082213.WAA05024@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1144
Lines: 42

Bob Braden wrote:

>   *>
>   *> No, the scenario that applies is described on page 68 (sequence number check),
>
> Yes, sorry, I misinterpreted what you were asking (ACK field as opposed
> to sequence field of ACK segment (But the man DID say "receive window"...
> mumble).
>
>   *>
>   *> The point u mentioned above is the conflict i am having as well, it seems to me
>   *> that retransmitting
>   *> a SYN-ACK seems the right thing to do. But the BSD stack doesn't seem to be
>   *> doing that.
>
> I thought you said earlier that the BSD DOES retransmit the SYN.  In

Sorry, the BSD stack does retransmit the SYN. Linux sends a pure ACK in response.

Murali

>
> any case, I would agree that the text of RFC 793 seems to say
> otherwise.  This particular test is one that has caused a great deal of
> confusion over the years.  From the underlying logic of TCP,  I believe
> that retransmitting the SYN is OK.  So it seems you can choose either
> interpretation you want (unless there is some  subtle security
> implication.)

>
> Bob Braden
>
>   *>
>   *> Murali
>   *>
>   *>
>   *>
>   *>
>   *> >
>   *> >
>   *> > Bob Braden
>   *>