From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 06:35:58 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 04DE916A4CE for ; Tue, 4 Jan 2005 06:35:57 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 55CB843D2F for ; Tue, 4 Jan 2005 06:35:57 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 34222 invoked from network); 4 Jan 2005 06:35:56 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Jan 2005 06:35:56 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 4 Jan 2005 00:35:55 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <200501040603.j0463Kx4003063@gw.catspoiler.org> Message-ID: <20050104002732.D68869@odysseus.silby.com> References: <200501040603.j0463Kx4003063@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 06:35:58 -0000 On Mon, 3 Jan 2005, Don Lewis wrote: > That's pretty much what previous versions of the draft suggested. The > earlier versions made some suggestions about how to deal with the corner > case by adjusting the sequence number in ACK, but these schemes added a > bunch of complexity and had some fatal flaws. > > I believe that sending the ACK challenge is the Cisco IPR claim. The goofy special cases in the previous draft could have potentially been unique. In the current draft, however, their description of the ACK challenge to an incoming SYN follows RFC 793 Figure 10 (page 34) exactly. I think we're safe here. >> Sounds like that's the way to go, with the addition of rate limiting those >> ACKs. > > 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. > I was going to suggest just doing a > goto dropafterack; > but there's a lot of code in tcp_output() that might unnecessarily > perturb things. I think you can get away without creating a template > for this. Take a look at the code under the dropwithreset label. Hm, tcp_respond does look like a good candidate... BTW, that tcp template code should probably have been removed years ago, it's only used by keepalives now. I just haven't gotten around to replacing it. Mike "Silby" Silbersack