IPFW SACK options

[Justin Robertson]

   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