Date: Fri, 7 Jan 2005 00:58:06 +0100 (CET) From: Lars Erik Gullerud <lerik@nolink.net> To: Mike Silbersack <silby@silby.com> Cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release Message-ID: <20050107004734.O97889@electra.nolink.net> In-Reply-To: <20050106143727.S18425@odysseus.silby.com> References: <20050105151352.87D2A77B0CC@guns.icir.org> <20050106143727.S18425@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Jan 2005, Mike Silbersack wrote: > Don convinced me of the same thing, using similar reasoning. > > I think that you're right that "there could be times when ignoring SYNs might > be fine." I think that we track how long a connection has been idle; my plan > is to only respond to SYNs if the connection has been idle for more than 30 > seconds or more. That should ensure that we handle the client crashing case > properly (even if the client reboots instantly, it'll keep retransmitting > SYNs for more than 30 sceonds), but also ensure that we do not let a forged > SYN flood prod us into sending unnecessary ACKs. I'll try to get this coded > up this weekend. OK, time to chime in here - if you read Don's comments, the particular example he chose to use was BGP, where one end crashes and tries to bring up a new session. BGP stability in particular was also one of the main reasons this particular draft received so much attention recently. Now, I'm a network engineer, not a developer. And if there is one thing I would hate if a BGP process were to crash, it is for the reestablishment of this connection to be delayed for up to 30 seconds because the other end thinks it is a good idea to ignore these SYNs. So please - don't. Why not stick to the procedures outlined in the draft as they are? The acronym "KISS" also comes to mind here, I don't really see that sending a few extra ACKs in this situation is a particularly relevant problem, I have problems seeing how this would realistically be used as a vector for a DoS or other nastiness. /leg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050107004734.O97889>