Date: Mon, 10 Jan 2005 02:46:44 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: silby@silby.com Cc: net@FreeBSD.org Subject: Re: Slipping in the window update Message-ID: <200501101046.j0AAkilD019867@gw.catspoiler.org> In-Reply-To: <20050110034422.C9716@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Jan, Mike Silbersack wrote:
>
> On Mon, 10 Jan 2005, Don Lewis wrote:
>
>> Now that I've looked at the above case, it looks to me like your
>> suggested patch might affect the response to a legitimate duplicate SYN.
>> It will definitely follow a different code path.
>
> You're right, I neglected to handle the duplicate SYN case.
>
> Couldn't we centralize all SYN handling right after trimthenstep6:?
>
> We could do something there like
>
> if (th->th_seq != tp->irs) {
> goto dropafterack; /* Or however we handle these bad syns */
> } else {
> thflags &= ~TH_SYN;
> th->th_seq++;
> if (th->th_urp > 1)
> th->th_urp--;
> else
> thflags &= ~TH_URG;
> todrop--;
> }
My thinking is that the security problem is confined to the following
block of code:
/*
* 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) {
tp = tcp_drop(tp, ECONNRESET);
rstreason = BANDLIM_UNLIMITED;
goto drop;
}
and that to implement the recommendation in the Internet Draft, it is
only necessary to change the actions taken inside this "if" block.
If response rate limiting is implemented, I'd actually prefer a more
general solution that is at least somewhat independent of the SYN flag,
since if the goal of an attacker is to cause an flood of ACK responses,
he can just as easily trigger it by sending spoofed packets that don't
have the SYN flag set. The SYN flag could be used as a hint, but the
solution should be more general.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501101046.j0AAkilD019867>