From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 22:14:59 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 A040A16A400 for ; Wed, 7 Mar 2007 22:14:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 86ECD13C494 for ; Wed, 7 Mar 2007 22:14:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l27MEuuD014930; Wed, 7 Mar 2007 14:14:56 -0800 (PST) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id B474A3004A; Wed, 7 Mar 2007 14:14:56 -0800 (PST) X-AuditID: 11807125-a0477bb0000007df-49-45ef3960e0e3 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id 9B08530041; Wed, 7 Mar 2007 14:14:56 -0800 (PST) In-Reply-To: <45EF32E2.8000807@sk1llz.net> References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 7 Mar 2007 14:14:55 -0800 To: Justin Robertson X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-ipfw@freebsd.org 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:14:59 -0000 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