[5018] in North American Network Operators' Group
Re: TCP SYN attacks
daemon@ATHENA.MIT.EDU (Dima Volodin)
Fri Oct 4 12:22:22 1996
To: freedman@netaxs.com (Avi Freedman)
Date: Fri, 4 Oct 1996 12:16:41 -0400 (EDT)
Cc: dvv@sprint.net, freedman@netaxs.com, tep@sdsc.edu, richards@netrex.com,
rja@cisco.com, nanog@merit.edu, iepg@iepg.org
In-Reply-To: <199610041420.KAA01726@access.netaxs.com> from "Avi Freedman" at Oct 4, 96 10:20:03 am
From: dvv@sprint.net (Dima Volodin)
Avi Freedman writes:
>
> > Now what is 100,000 entries? With the timeout aggressively set at 10
> > secs (heck, with 10 secs I sometimes cannot even get all the images on
> > home.netscape.com) it's only 1000 SYNs/sec. How many hosts you want to
> > protect with such a firewall?
> >
> > Dima
>
> A timeout of 10 seconds is on two packets going back and forth.
> Many have said that the timeout must be much higher. I just don't
> see it. A SYN arrives. A SYN-ACK is sent out. A 10 second timer
> starts that is counted down to 0. An ACK of that SYN-ACK arrives
> back within the 10 seconds and we set up the connection. If the
> two packets can't each go one way in 10 seconds, the SYN will be
> retransmitted.
(quoting myself):
(heck, with 10 secs I sometimes cannot even get all the images
on home.netscape.com)
My kernel values:
tcp_ip_abort_cinterval 10000
tcp_ip_notify_cinterval 1000
In Solaris, these values work for both incoming and outgoing connections.
I could have lowered the notify_cinterval even more though.
And I'm not even on a dial-up line:
traceroute to www30.netscape.com (207.12.240.31), 30 hops max, 40 byte packets
1 206.229.244.1 (206.229.244.1) 159 ms 106 ms 10 ms
2 sl-dc-17-S1/0-T1.sprintlink.net (144.228.0.225) 11 ms 7 ms 15 ms
3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 19 ms 8 ms 8 ms
4 sl-stk-5-H1/0-T3.sprintlink.net (144.228.10.2) 80 ms 81 ms 79 ms
5 sl-stk-16-F0/0.sprintlink.net (144.228.40.16) 77 ms 79 ms 81 ms
6 sl-netscape-1-s-T3.sprintlink.net (144.228.146.26) 223 ms 101 ms 162 ms
7 207.12.240.31 (207.12.240.31) 147 ms 85 ms 92 ms
> 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, ...).
That's for sure. The only thing that bothers me with this approach -
why we need all those stinking options in TCP SYN packets then?
> Avi
Dima
