From owner-freebsd-net@FreeBSD.ORG  Mon Jan 10 10:46:52 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7578816A4CE
	for <net@FreeBSD.org>; Mon, 10 Jan 2005 10:46:52 +0000 (GMT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3830743D39
	for <net@FreeBSD.org>; Mon, 10 Jan 2005 10:46:52 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0AAkilD019867;
	Mon, 10 Jan 2005 02:46:48 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200501101046.j0AAkilD019867@gw.catspoiler.org>
Date: Mon, 10 Jan 2005 02:46:44 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: silby@silby.com
In-Reply-To: <20050110034422.C9716@odysseus.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: net@FreeBSD.org
Subject: Re: Slipping in the window update
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2005 10:46:52 -0000

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.