Fixing "Slipping in the window" before 4.11-release

[Mark Allman]

Folks-

> > The SYN side of the equation, however, is a bit more tricky.  The
> > proposed RFC recommends ACKing SYN packets in the window, just like
> > we do to SYN packets to the left of the window right now.
> > 
> > For the life of me, I can't figure out why SYN packets (other than
> > delayed retransmissions of the original SYN) would ever show up once
> > a connection is in the ESTABLISHED state.  So, I'm proposing the
> > attached patch, which simply ignores any packet with the SYN flag on
> > it while a connection is in the ESTABLISHED state.  This means that
> > SYN packets left of the window will no longer receive an ACK, and
> > SYN packets in the window will no longer reset the connection.  In
> > all states other than ESTABLISHED, SYN packets are handled as they
> > were before, in case there's some edge case where that could happen.
> 
> This sounds OK to me.  FWIW.

I ran this idea by Randall Stewart who has done a bunch of thinking on
this topic (and, helped produce one of the current internet-drafts on
the topic).  He swayed me that my initial hit (above) might not be quite
right.  Below is Randall's response to my forward of Mike's note
(forwarded with permission).  This is a case that had not occurred to me
and leaves me thinking maybe ignoring SYNs is not quite the right
approach.  However, I think there could be times when ignoring SYNs
might be fine.  E.g., if the connection is moving right along and there
are other packets being transmitted and ACKed and we see a SYN that it
should be ignored.

FWIW.

allman


--- Begin Randall's note ---

Anyway.. we discussed this very option in GORY detail last year about
this time.. and we discarded the idea for a number of important
reasons..

a) It is NOT uncommon for a machine to be rebooted (there are a
    lot of windoz boxes out there.. not everyone uses FreeBSD)

b) When a machine reboots that was a client, it is likely to pick
    the same starting port... so say if not many connections have been
    made.. I make some connection out of my windoz box to my
    favorite server "telnet my.favorite.server" .. and start working..
    Of course my windoz box crashes.. chances are that if I do
    the same telnet again.. I get the same starting port (if port
    randomization is not in place.. which most O/S's dont' do). Guess
    what happens to my SYN ->>... dumpper. Now this means I must
    depend on the TCP endpoint that still has the hanging TCB to
    cleanup before I can connect on that port set.

c) This is a nasty inconvience for a lot of apps.. for our internal
    ones that use the same ports often on each side.. (don't ask why
    since i don't understand all the reasoning.. but its the way
    it is) and guess what I get things that can't connect since all
    my SYN's upon reboot are ignored (not that a router ever crashes :-D)

So... this is when we came up with the SYN idea... yes its possible you
would never notice the SYN being dropped.. but, there will be SOME
apps that do.. especially the more long term things such as
banking ... routing... ip telephoney... etc. It might work
ok most of the time.. but when it does not work and a crash as
occured it will fail at the MOST miserable time.

It would be far better to send back the ACK .. thus cleaning up
the TCB and then allowing the connection to progress...  at least
IMO...






-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050105/8adde01e/attachment.bin