|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Avi Freedman <freedman@netaxs.com> To: bass@linux.silkroad.com (Tim Bass) Date: Fri, 4 Oct 1996 16:17:29 -0400 (EDT) Cc: dvv@sprint.net, michael@memra.com, nanog@merit.edu, iepg@iepg.org In-Reply-To: <199610041959.PAA02386@linux.silkroad.com> from "Tim Bass" at Oct 4, 96 03:59:23 pm See Jeff Weisberg's post to nanog yesterday. It can be solved in tcp_input.c, even for tens of thousands of syn packets/second. Just keep no state until the syn/ack comes back (and with a valid hash matching one you would have supplied as an initial seq number). Avi > Dimo laments: > Yep. Life sucks and we all die. > > Victor Hugo, _The Hunchback of Notre Dame_ and _Les Miserables_ > both inspired by the author seeing the word FATALITY graphically > painted on a wall in Paris. (I highly recommend _Les Miserables_) > Jean Valjean, the man who, for stealing a loaf of bread to > feed a starving family, lives out his entire life in misery... > ... hence, FATALITY (set in Paris in the early 1800s) > > Anyway ..... > > I'll drop off unless someone can provide a technical suggestion > on an algorithm that will stop high speed TCP SYN attacks > in tcp_input.c (otherwise, I'm not moving toward my aim/target) > > What is the IPV6 approach to solving this problem? Is there one? > > Regards, > > Tim
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |