Date: Wed, 07 Mar 2007 14:35:31 -0800 From: Justin Robertson <justin@sk1llz.net> To: freebsd-ipfw@freebsd.org, cswiger@mac.com Subject: Re: IPFW SACK options Message-ID: <45EF3E33.2040507@sk1llz.net> In-Reply-To: <45EF3B1E.1080706@sk1llz.net> References: <000301c760fa$df57eb40$9e07c1c0$@net> <CDAD9871-3C36-4225-AABC-749BC703058D@mac.com> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mss 1460,nop,wscale 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 <mss 1460,nop,wscale 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 <mss 1460,nop,nop,sackOK> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45EF3E33.2040507>