engineering --> ddos and flooding

Mon Jun 4 19:24:26 UTC 2001

> -----Original Message-----
> From: Richard A. Steenbergen [mailto:ras at e-gerbil.net]
> Sent: Monday, June 04, 2001 3:09 PM
> To: Matt Zito
> Cc: Paul Johnson; nanog at merit.edu
> Subject: RE: engineering --> ddos and flooding
> > Rate-limiting ICMP is not so difficult - rate-limiting SYNs is
> > basically useless.  Syn floods work not because the amount 
> of traffic
> > they do, but because they fill up state tables or make them so
> > horribly inefficient as to make the box cease responding on 
> that port.
> > Given that, say, a linux box has a default queue depth of 128, I can
> > send 128 spoofed SYNs at a rate of one a second, and in two minutes
> > that box will stop responding.  The larger you make the queue, the
> > longer it will stand up to a slow SYN attack, but the more 
> costly each
> > incoming SYN and SYN+ACK becomes, as the data structures become more
> > and more unwieldy.
> 
> Wrong, and very much out of date.
> 
> I didn't write all this down to waste my breath...
> 
> http://www.e-gerbil.net/ras/projects/dos/dos.txt
> 

Well, what I said is inaccurate for SOME operating systems.  A default linux
box today still has a 128-syn queue.  Unless you enable syn cookies, you're
screwed - I haven't checked BSD or Solaris for slow-syn behavior recently.
Syn cookies also aren't a magic bullet - you lose TCP options that some
people really want/need.  And rate-limiting SYN is still a bad idea - if you
rate-limit to a certain bandwidth, either your server will not be able to
handle the incoming syns and will stop responding, or legitimate incoming
traffic will hit the floor because the queue on the router is full (or
approaching full and RED is invoked) and legitimate incoming requests will
be dropped.  This might be okay for places where one server performs many
functions - i.e. the box is still available on other ports, but in larger
infrastructures, a box generally has one purpose, and if its purposed port
is down, the box might as well be turned off.  

So, I prefer solutions that negotiate the connection before passing it back
to the host - like (insert basically any firewall product here).  Some do it
better than others, of course - the netscreen 100, 500, and 1000  seem much
better than anything else the field has to offer.

Thanks,
Matt