From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 07:49:32 2005 Return-Path: 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 B4EB016A4CE for ; Tue, 4 Jan 2005 07:49:32 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D1A543D31 for ; Tue, 4 Jan 2005 07:49:32 +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 j047nOKC003234; Mon, 3 Jan 2005 23:49:29 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501040749.j047nOKC003234@gw.catspoiler.org> Date: Mon, 3 Jan 2005 23:49:24 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050104002732.D68869@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 07:49:32 -0000 On 4 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: >> I'm not sure that it makes sense to rate limit the ACKs in this special >> case. If an attacker has enough information to trigger an ACK response >> flood from the hardened stack, he could still produce a flood by turning >> off the SYN bit. A general way of rate limiting ACKs triggered by the >> reception of out of window data could be a good idea, but this would >> have to be done very carefully to avoid breaking the algorithms that >> look at ACKs to sense network congestion. > > I probably agree here... but I want to just fix this one problem for 4.11, > and I don't want to touch the rest of the TCP stack whatsoever. If > integrating this case with others in rate limiting makes sense, we could > do that in 6.x and 5.x, but I don't want to risk breaking 4.x by rewriting > dropafterack at this point in time. Agreed. Tweaking the dropafterack stuff would need to be thoroughly discussed, and it would need to soak for quite a while in 6.x to make sure that it didn't cause an interoperability problems.