I agree completely, but neither one is a panacea. - paul At 08:40 AM 10/3/96 -0400, Dima Volodin wrote:
And if everyone doesn't make any attacks we won't have any problems either. To rephrase - relying on ingress filtering is putting your security in someone other's hands, doing host-based stuff is protecting yourself with your own hands. To rephrase once again - doing ingress filtering is "being conservative with what you produce", being able to cope with SYN floods on the host level is "being liberal on what you accept." We need both, and overemphasising one side of the solution will do a lot of harm.
Dima
But of course. The problem is that SYN_RCVD is a transient state in the TCP automaton, and it requires some resources allocation. The life might have been a little bit different if servers weren't forced to track this state. Something like a signed ticket accompanying the second SYN and the following ACK. Dima Paul Ferguson writes:
I agree completely, but neither one is a panacea.
- paul
At 08:40 AM 10/3/96 -0400, Dima Volodin wrote:
And if everyone doesn't make any attacks we won't have any problems either. To rephrase - relying on ingress filtering is putting your security in someone other's hands, doing host-based stuff is protecting yourself with your own hands. To rephrase once again - doing ingress filtering is "being conservative with what you produce", being able to cope with SYN floods on the host level is "being liberal on what you accept." We need both, and overemphasising one side of the solution will do a lot of harm.
Dima
But of course. The problem is that SYN_RCVD is a transient state in the TCP automaton, and it requires some resources allocation. The life might have been a little bit different if servers weren't forced to track this state. Something like a signed ticket accompanying the second SYN and the following ACK.
Dima
That's the idea of making the iss a ticket that includes mss info and a hash of the other info plus a security ticket. I had hoped to work on that but it looks like someone else local is almost done and claims that ignoring window size and any data with the SYN(s) is harmless... Avi
I agree completely, but neither one is a panacea.
Actually, after the details of Random Drop is worked out including the proper queue size and the drop algorithm we have gone a long way to protecting servers from TCP SYN attacks. I have the beginnings of Random Drop working now based on Alan->Vernnon->Morris; and have been working on 'how to fire hose' the interface and make it work, with kernel print statements in every junction and reboot after reboot after kernel build, etc. ad you-know-what. The TCP fix and possibly and ICMP fix (and more work on kernel hackers part) will, I can safely predict, the faster short term solution than trying to coordinate the world into doing filters. Random Drop, is not a panacea, as you say Paul, but it is a very big, big step in the right direction and I predict that within 30 days and at the latest 60 days (because people are busy) that the SYN attack much less 'troublesome'. Tim
participants (4)
-
Avi Freedman -
dvv＠sprint.net -
Paul Ferguson -
Tim Bass