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