From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 22:22:32 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6054316A402 for ; Wed, 7 Mar 2007 22:22:32 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id 47F2F13C441 for ; Wed, 7 Mar 2007 22:22:32 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id 345C610BBE58; Wed, 7 Mar 2007 14:22:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=-99.4 required=5.0 tests=AWL,BAYES_50, USER_IN_WHITELIST autolearn=disabled version=3.1.3 Received: from [192.168.1.102] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 0FC5610BBD3F for ; Wed, 7 Mar 2007 14:22:30 -0800 (PST) Message-ID: <45EF3B1E.1080706@sk1llz.net> Date: Wed, 07 Mar 2007 14:22:22 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> In-Reply-To: <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPFW SACK options X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2007 22:22:32 -0000 Chuck Swiger wrote: > On Mar 7, 2007, at 1:47 PM, Justin Robertson wrote: >>> Perhaps trying: >>> >>> sysctl net.inet.tcp.sack.enable=0 >>> >>> ...will do what you are looking for? >> >> No (this only works in 6.x, btw) - setting sack.enable=0 simply >> tells the system not to send selective acks itself, this doesn't stop >> a host from sending selective acks inbound, and processing them still >> causes the system to bog and die. > > That sysctl is present in 5.x, at least somewhere around 5.4/5.5. > > Nothing (short of a firewall) is going to prevent the other side from > sending SACKs inbound, however, if you don't enable SACKs on your > side, you won't reply with that option, and the remote host should not > continue to generate them for the rest of the TCP session. > > If you're looking at a deliberate DoS attack using SACKs, well, you'd > want to block the initial SYNs entirely rather than worry about > processing the option after receiving the packets. I would not expect > that the system would bog down processing SACKs if the sysctl disables > them, but I'll take your word for it that turning off the sysctl does > not prevent the extra work from being done. > >> What I'm looking for here, is a patch to ipfw to allow one to set a >> flag to strip the tcpoption sack from syn packets. > > Is there something wrong with: > > ipfw add deny tcp from any tcpoptions sack to any > > ...? Sure, you're going to force hosts which default to SACK being > enabled to retransmit their SYNs without that option, but > RFC-793-compliant stacks will do so without much extra delay. I'm not > sure this is a good solution, but it's not exactly clear to me which > problem you are trying to solve.... > > ---Chuck > > The issue here is that no windows PC is compliant, and continues to try and send SYN SACK packets until giving up entirely on the connection - I've already tried this. I can't tell you why the bsd stack doesn't have an issue with bare SYNs, but does on SYNs with SACK set in the tcpoptions, but it apparently does. -- Justin