IPFW SACK options

Justin Robertson justin at sk1llz.net
Wed Mar 7 22:22:32 UTC 2007


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





More information about the freebsd-ipfw mailing list