From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 5 11:08:11 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 9284016A420 for ; Mon, 5 Mar 2007 11:08:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2F13413C4B2 for ; Mon, 5 Mar 2007 11:08:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l25B8BmB037491 for ; Mon, 5 Mar 2007 11:08:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l25B89Mt037487 for freebsd-ipfw@FreeBSD.org; Mon, 5 Mar 2007 11:08:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2007 11:08:09 GMT Message-Id: <200703051108.l25B89Mt037487@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 05 Mar 2007 11:08:11 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q 20 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 21:09:34 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 15AD816A400 for ; Wed, 7 Mar 2007 21:09:34 +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 EAE5B13C4B5 for ; Wed, 7 Mar 2007 21:09:33 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id B4FFA10BBE59; Wed, 7 Mar 2007 12:55:09 -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,HTML_50_60, HTML_MESSAGE,USER_IN_WHITELIST autolearn=disabled version=3.1.3 Received: from vroom (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 32C7510BBD3F for ; Wed, 7 Mar 2007 12:55:07 -0800 (PST) From: "Justin Robertson" To: Date: Wed, 7 Mar 2007 12:54:49 -0800 Message-ID: <000301c760fa$df57eb40$9e07c1c0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acdg+tY/lM/GRzDGQhKK/ZmEVN5Y2g== Content-Language: en-us x-cr-hashedpuzzle: Nr0= Ai5o BZt8 B2Qv CL7k ClCR Djls FvNB GIcf G8k2 Hyto IMaJ JAf1 JgZc KOjs L3nJ; 1; ZgByAGUAZQBiAHMAZAAtAGkAcABmAHcAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {CE19E6ED-C95F-40F2-93BE-86BA824ECAC0}; agB1AHMAdABpAG4AQABzAGsAMQBsAGwAegAuAG4AZQB0AA==; Wed, 07 Mar 2007 20:54:45 GMT; SQBQAEYAVwAgAFMAQQBDAEsAIABvAHAAdABpAG8AbgBzAA== x-cr-puzzleid: {CE19E6ED-C95F-40F2-93BE-86BA824ECAC0} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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 21:09:34 -0000 So I've done lots of 'worst case' benchmarks on 6.2 and 4.11 machines replicating DDoS traffic. Sadly it has become apparent that the 6 series simply cannot keep pace with the 4.11 branch. UDP floods of 28 or 29 byte packets in the 200mbps range will cause a 6.x machine to lose all internet connectivity (no in/outbound traffic, TCP, ICMP, UDP, etc). TCP floods (syn/ack/etc) net the same results at around 230mbps of traffic. TCP SYN floods with the selective ACK (SACK / sackOK) option set result in the 6.x series starting to drop packets aggressively in the 1mbps range, as you approach 100mbps point there is a total loss of all internet connectivity. 4.11 appears to deal with the UDP and TCP floods flawlessly up to full gigabit, however the TCP SYN floods with selective ACK (sackOK) cause it to lag quite badly at the 100mbps point. Adding an ipfw rule to drop these packets results in the box returning to full performance as though the flood was not in progress. Problem being you can't blanket rule these (real traffic), and there's no dynamic pps/destination measure, nor a scripted way to react quickly enough to prevent latency. (also, pipes do NOT stop the lag) Due to the nature of the current performance disparity between 6.x (I assume this is due to the work on making processes thread friendly?) and 4.11 (still kicking arse) I'm sticking with the 4.11 branch - and here comes my question. If someone is interested, could you work up an option to allow removal of the sackOK (sack permitted negotiation) on SYN packets, and then pass the SYN packet on with the tcpoption for sack stripped? If this was done for the 6/7 series I'd attempt to backport it myself to 4.11, but if someone were able to do a workup for the 4.11 branch that would truly make my day, and probably another donation to the FreeBSD fund. J (happy 4.11-RELEASE-p26 user). -Justin From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 21:47:24 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 383A716A400 for ; Wed, 7 Mar 2007 21:47:24 +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 20CF313C461 for ; Wed, 7 Mar 2007 21:47:24 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id E9A7B10BBE5B; Wed, 7 Mar 2007 13:47:23 -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.5 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 B039010BBD3F; Wed, 7 Mar 2007 13:47:21 -0800 (PST) Message-ID: <45EF32E2.8000807@sk1llz.net> Date: Wed, 07 Mar 2007 13:47:14 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chuck Swiger References: <000301c760fa$df57eb40$9e07c1c0$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 21:47:24 -0000 Chuck Swiger wrote: > On Mar 7, 2007, at 12:54 PM, Justin Robertson wrote: > [ ... ] >> Due to the nature of the current performance disparity between 6.x (I >> assume this is due to the work on making processes thread friendly?) and >> 4.11 (still kicking arse) I'm sticking with the 4.11 branch - and >> here comes >> my question. If someone is interested, could you work up an option to >> allow >> removal of the sackOK (sack permitted negotiation) on SYN packets, >> and then >> pass the SYN packet on with the tcpoption for sack stripped? > > Perhaps trying: > > sysctl net.inet.tcp.sack.enable=0 > > ...will do what you are looking for? > > ---Chuck > > 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. 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. -- Justin From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 22:04:41 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 30BE616A406 for ; Wed, 7 Mar 2007 22:04:41 +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 18AFA13C491 for ; Wed, 7 Mar 2007 22:04:41 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l27LRKmD007565; Wed, 7 Mar 2007 13:27:20 -0800 (PST) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 88D3C29C006; Wed, 7 Mar 2007 13:27:20 -0800 (PST) X-AuditID: 11807123-9e91ebb000004462-c7-45ef2e3802a0 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 relay5.apple.com (Apple SCV relay) with ESMTP id 724CC30400B; Wed, 7 Mar 2007 13:27:20 -0800 (PST) In-Reply-To: <000301c760fa$df57eb40$9e07c1c0$@net> References: <000301c760fa$df57eb40$9e07c1c0$@net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 7 Mar 2007 13:27:19 -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:04:41 -0000 On Mar 7, 2007, at 12:54 PM, Justin Robertson wrote: [ ... ] > Due to the nature of the current performance disparity between > 6.x (I > assume this is due to the work on making processes thread > friendly?) and > 4.11 (still kicking arse) I'm sticking with the 4.11 branch - and > here comes > my question. If someone is interested, could you work up an option > to allow > removal of the sackOK (sack permitted negotiation) on SYN packets, > and then > pass the SYN packet on with the tcpoption for sack stripped? Perhaps trying: sysctl net.inet.tcp.sack.enable=0 ...will do what you are looking for? -- -Chuck 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 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 From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 22:35:41 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 3746D16A402 for ; Wed, 7 Mar 2007 22:35:41 +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 14CC413C471 for ; Wed, 7 Mar 2007 22:35:41 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id E0BC310BBEBB; Wed, 7 Mar 2007 14:35:40 -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 A64A110BBEA9; Wed, 7 Mar 2007 14:35:38 -0800 (PST) Message-ID: <45EF3E33.2040507@sk1llz.net> Date: Wed, 07 Mar 2007 14:35:31 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, cswiger@mac.com References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net> In-Reply-To: <45EF3B1E.1080706@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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:35:41 -0000 Justin Robertson wrote: > 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. > > Example - windows PC trying to connect to POP mailserver, sacks blocked (being viewed from firewall) 14:31:54.632444 client.52985 > server.110: S [tcp sum ok] 3734795545:3734795545(0) win 8192 (DF) (ttl 115, id 12030, len 52) 14:31:57.629151 client.52985 > server.110: S [tcp sum ok] 3734795545:3734795545(0) win 8192 (DF) (ttl 115, id 12034, len 52) 14:32:03.635511 client.52985 > server.110: S [tcp sum ok] 3734795545:3734795545(0) win 8192 (DF) (ttl 115, id 12046, len 48) You get three sack attempted retransmissions, then failure. It's not sending selective acks, it's trying to establish that selective acks are allowed for the rest of the communication between client/server. I just want to strip the sack options from the packet and pass it on. The "issue" is that BSD can't cope with a flood of syn/sack permitted packets. All IP lags, and on 6.x stops all-together. -- Justin From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 23:00:40 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 BD18D16A400 for ; Wed, 7 Mar 2007 23:00:40 +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 A378B13C48E for ; Wed, 7 Mar 2007 23:00:40 +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 l27N0eic021808; Wed, 7 Mar 2007 15:00:40 -0800 (PST) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 83F9930076; Wed, 7 Mar 2007 15:00:40 -0800 (PST) X-AuditID: 11807125-a1479bb0000007df-e7-45ef4418e7e1 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 719C430012; Wed, 7 Mar 2007 15:00:40 -0800 (PST) In-Reply-To: <45EF3E33.2040507@sk1llz.net> References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net> <45EF3E33.2040507@sk1llz.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 7 Mar 2007 15:00:39 -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 23:00:40 -0000 On Mar 7, 2007, at 2:35 PM, Justin Robertson wrote: >> 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. >> > Example - windows PC trying to connect to POP mailserver, sacks > blocked (being viewed from firewall) > > 14:31:54.632444 client.52985 > server.110: S [tcp sum ok] > 3734795545:3734795545(0) win 8192 8,nop,nop,sackOK> (DF) (ttl 115, id 12030, len 52) > 14:31:57.629151 client.52985 > server.110: S [tcp sum ok] > 3734795545:3734795545(0) win 8192 8,nop,nop,sackOK> (DF) (ttl 115, id 12034, len 52) > 14:32:03.635511 client.52985 > server.110: S [tcp sum ok] > 3734795545:3734795545(0) win 8192 (DF) > (ttl 115, id 12046, len 48) > > You get three sack attempted retransmissions, then failure. It's > not sending selective acks, it's trying to establish that selective > acks are allowed for the rest of the communication between client/ > server. Which flavor of Windows was the sender? I seem to recall that Win2000/XP/2003 was willing to resend the SYN without enabling the SACK option after a few retries, but it's been a while since I've done that sort of testing... > I just want to strip the sack options from the packet and pass it > on. The "issue" is that BSD can't cope with a flood of syn/sack > permitted packets. All IP lags, and on 6.x stops all-together. Is the machine you're testing against the destination of this traffic, or are you wanting to change this on a firewall box which lies between the sender and destination? If the latter, I would agree that you'd need to hack the firewall code. But if the former, take a look into /usr/src/sys/netinet/ tcp_input.c for the tcp_dooptions() function, and try to #ifdef out the cases for TCPOPT_SACK_PERMITTED & TCPOPT_SACK? -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 23:11:12 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 5AC7E16A401 for ; Wed, 7 Mar 2007 23:11:12 +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 40D8813C491 for ; Wed, 7 Mar 2007 23:11:12 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id 04AC410BBE57; Wed, 7 Mar 2007 15:11:12 -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 66A0010BBD3F; Wed, 7 Mar 2007 15:11:09 -0800 (PST) Message-ID: <45EF4683.7060508@sk1llz.net> Date: Wed, 07 Mar 2007 15:10:59 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chuck Swiger , freebsd-ipfw@freebsd.org References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net> <45EF3E33.2040507@sk1llz.net> <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> In-Reply-To: <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 23:11:12 -0000 Chuck Swiger wrote: > On Mar 7, 2007, at 2:35 PM, Justin Robertson wrote: >>> 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. >>> >> Example - windows PC trying to connect to POP mailserver, sacks >> blocked (being viewed from firewall) >> >> 14:31:54.632444 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 > 8,nop,nop,sackOK> (DF) (ttl 115, id 12030, len 52) >> 14:31:57.629151 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 > 8,nop,nop,sackOK> (DF) (ttl 115, id 12034, len 52) >> 14:32:03.635511 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 (DF) (ttl >> 115, id 12046, len 48) >> >> You get three sack attempted retransmissions, then failure. It's not >> sending selective acks, it's trying to establish that selective acks >> are allowed for the rest of the communication between client/server. > > Which flavor of Windows was the sender? > > I seem to recall that Win2000/XP/2003 was willing to resend the SYN > without enabling the SACK option after a few retries, but it's been a > while since I've done that sort of testing... > >> I just want to strip the sack options from the packet and pass it on. >> The "issue" is that BSD can't cope with a flood of syn/sack permitted >> packets. All IP lags, and on 6.x stops all-together. > > Is the machine you're testing against the destination of this traffic, > or are you wanting to change this on a firewall box which lies between > the sender and destination? > > If the latter, I would agree that you'd need to hack the firewall > code. But if the former, take a look into > /usr/src/sys/netinet/tcp_input.c for the tcp_dooptions() function, and > try to #ifdef out the cases for TCPOPT_SACK_PERMITTED & TCPOPT_SACK? > > ---Chuck > > All latest windows updated XP machines, as well as all new Vista machines have this issue. And this is being done on a firewall box between sender/destination. The firewall machine itself (even in a transparent bridge) lags when passing SYN w/ SACK - hence the need to hack up ipfw to strip TCP options. -- Justin From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 8 23:23:26 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 C8D8116A400 for ; Thu, 8 Mar 2007 23:23:26 +0000 (UTC) (envelope-from justin@prismnet.com) Received: from smtp.prismnet.com (smtp.prismnet.com [209.198.128.91]) by mx1.freebsd.org (Postfix) with ESMTP id A066913C442 for ; Thu, 8 Mar 2007 23:23:26 +0000 (UTC) (envelope-from justin@prismnet.com) Received: from [192.168.246.21] (batman.prismnet.com [205.166.246.21]) (authenticated bits=0) by smtp.prismnet.com (8.13.4/8.13.4) with ESMTP id l28MvrQn080974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Mar 2007 16:57:53 -0600 (CST) (envelope-from justin@prismnet.com) Message-ID: <45F094F1.6050204@prismnet.com> Date: Thu, 08 Mar 2007 16:57:53 -0600 From: Justin Roush User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on smtp.prismnet.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=7.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on smtp.prismnet.com Subject: Slow Upload speeds 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: Thu, 08 Mar 2007 23:23:26 -0000 I'm having an issue with being able to use ipfw and dummynet as a bridge and getting slow and intermittent uploads. We have a setup where we are trying to control bandwidth on a wireless network. I have added rules like the following: 25018 41705 4680592 queue 25018 ip from 10.10.1.1 to any 25019 42092 52698217 queue 25019 ip from any to 10.10.1.1 With corresponding queues and pipes 25018: 512.000 Kbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail q25018: weight 1 pipe 25018 50 sl. 128 queues (128 buckets) droptail mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 25019: 512.000 Kbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail q25019: weight 1 pipe 25019 50 sl. 129 queues (128 buckets) droptail mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp The problem is it works great with downloads but when the end users attempt to upload its horrid. Why I would be getting this problem in only one direction on a bridge I don't know. I have even put the in and out on rules but that did not seem to really matter, not that I thought I would with a bridge. Really the biggest mystery is the stuff that goes into the sysctl.conf file. I understand a few of the command that I need to put in there, and why but some of the other like the hash table and the dynamic buckets etc etc, I'm at a loss as to why I would want to enter said values.. Is there a good definitive source for syscntl.conf variables that are well defined? I'm not really getting a good explanation from man pages. I am attempting to run this on BSD6.2 by the way. Any nudge in the right direction would be greatly appreciated. - Justin