Date: Mon, 3 Jan 2005 10:55:49 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: silby@silby.com Cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release Message-ID: <200501031855.j03Itnmh002076@gw.catspoiler.org> In-Reply-To: <20050103012325.A62262@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Jan, Mike Silbersack wrote:
>
> With re's permission, I'm going to commit FreeBSD's fix for the RST part
> of the slipping in the window attack to 4.11 in the next few days. That's
> not a big deal, we seem to have an acceptable solution there. (See
> tcp_input.c rev 1.235 for more info.)
>
> 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.
It can happen if one side of the connection crashes and tries to
reconnect using the same source port. The BGP case, which is the case
where attacks are of most concern, likes to connect from port 179 to
port 179.
> 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.
That'll hose things in the case I mentioned above. A client that
reboots and loses it's connection state won't be able to reconnect until
the server transmits something that provkes a RST response that causes
the server to drop the connection.
It's probably safer to just defang the code that handles the in-window
case, which would reduce the probability of a reconnection attempt
failing.
/*
* If a SYN is in the window, then this is an
* error and we send an RST and drop the connection.
*/
if (thflags & TH_SYN) {
if (tcp_insecure_syn == 0)
goto drop;
else {
tp = tcp_drop(tp, ECONNRESET);
rstreason = BANDLIM_UNLIMITED;
goto dropwithreset;
}
I'd also be hesitant to change the default behaviour.
> What are people's thoughts on this? I'm especially interested how
> stateful firewalls like IPF or PF would handle such a situation. How do
> they respond to unexpected SYN packets?
>
> Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501031855.j03Itnmh002076>