TCP SYN attacks

Fri Oct 4 14:58:06 UTC 1996

> 
> My preferred approach is to not even have to store state on any
> of the embryonic connections.  And to implement the fix on all
> of my hosts.  And customers can implement it in a firewall, if
> they choose (and have boxes which can't be fixed: Win95, NT, Macs, ...).
> 
> Avi
> 

Agreed.  Certainly this should be an option in the host kernel configuration;
performing this service in firewalls is a valid option as well; and I might
add, this is what will 'more than likely' happen.  I think we would
all like to see TCP continue to rein as an end2end protocol.  To
concede that TCP in not an end2end protocol is 'a stake in the
heart of TCP' (ouch!).

Ihe issue is how best to do this in tcp_input.c, IMO.  The algorithm
is non-trivial. Random packet drop is not perfect and when I try
to hash the connections looking for SYN_RECV states and timeout
values; it is difficult to build an algorithm (if not, for memory
constraints, practically impossible) that will stop the attack
over high speed networks.     

I have not been constraining my lab tests to WANS and T1 connections,
BTW.  When/If SYN attack code becomes common place (i.e. available
on MS Windows, etc.), the office place can become a battlefield.
as everyone can well imagine, further adding 'mud to the face'
of TCP and the future of the protocol for high speed networks.

This is why I have been testing all ideas on the over Ethernet.
In the 'office or internal organizational attack' scenerio,
an outside firewall is ineffective, of course, unless ones
thinks it is a good idea to put up a firewall in front
of every server???

The firewall, stated another way, should be in the TCP/IP
implementation to strengthen TCP/IP.  

Best Regards,

Tim