Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Mar 2007 14:14:55 -0800
From:      Chuck Swiger <cswiger@mac.com>
To:        Justin Robertson <justin@sk1llz.net>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: IPFW SACK options
Message-ID:  <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com>
In-Reply-To: <45EF32E2.8000807@sk1llz.net>
References:  <000301c760fa$df57eb40$9e07c1c0$@net> <CDAD9871-3C36-4225-AABC-749BC703058D@mac.com> <45EF32E2.8000807@sk1llz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C17F7D1-6763-41EC-970E-E88FF3782D22>