Date: Wed, 05 Jan 2005 10:13:52 -0500 From: Mark Allman <mallman@icir.org> To: Mike Silbersack <silby@silby.com>, net@freebsd.org Cc: rrs@cisco.com Subject: Re: Fixing "Slipping in the window" before 4.11-release Message-ID: <20050105151352.87D2A77B0CC@guns.icir.org> In-Reply-To: <20050103184048.471E477B0CC@guns.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-=
Content-Type: text/plain
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...
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFB3AQwWyrrWs4yIs4RAg/3AJ4ojLLq2QYm2mngWU+WU6IxsxMrCgCfae78
u020LMCUM5Ds/t0eb7IMDS4=
=6LfN
-----END PGP SIGNATURE-----
--=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050105151352.87D2A77B0CC>