Re: New Denial of Service Attack ...

[vjs () mica denver sgi com (Vernon Schryver)]

> From: Barney Wolff <barney () databus com>
> To: vjs () sgi com (Vernon Schryver), nanog () merit edu


> > At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which
> > is not so bad.  Drop-oldest is better with those three numbers, since
> > it works 100% (modulo ordinary problems), but its performance falls off
> > the cliff to 0% at R=L/RTT.  If you have a short queue and care about
> > long RTT's, random drop is better than drop-oldest.
>
> Agreed.  Note that 93% is not bad for a human-initiated telnet, but is
> disastrous for a Web browser which initiates a dozen tcp sessions to
> retrieve one page, because the browser will probably not retry at all if
> it gets a reset, but instead report failure to retrieve the page to the
> user, who can only ask it to start over from the beginning.

Caching should keep them from having to retransfer everthing.
Of course, if the problem is getting through the listen queue, that
might not help much.

>                                                              So I think
> that it's better to accept the limited-radius-under-attack property of
> drop-oldest, gaining the immunity from interference within the safe
> radius.

If you have a useful safe radius.  At only 130 SYNs/sec, a 260 entry
queue seems useful today, giving a 2 second radius.

What is the limit on the queue in the typical router or Ethernet hub?

>          If it were possible to set the syn-rcvd timeout with sub-second
> granularity, this "fix" would not even take any kernel code mods - but
> of course it does not adjust the safe radius dynamically as the attack
> rate changes.

Again, I think it is practical to switch automagically from drop-oldest
when the attack rate is modest to random-drop when the bad guys
get something better than a v.34 modem, such as ISDN or just a
corrupted machine somewhere on an Ethernet connected with a T1.


> What's absolutely clear is that any method of queue pruning is better
> than none, and a big queue is required for survival.

A queue limit 50 to 500 times larger than the 7 from the classic BSD
SO_MAXCONN=5 seems useful for handling the 100's of valid TCP
connections/sec that you get on a busy WWW server.


Vernon Schryver,  vjs () sgi com
- - - - - - - - - - - - - - - - -