On Mon, 24 Oct 2005 13:50:08 +0900
Yohanes Santoso <ysantoso-rubytalk / dessyku.is-a-geek.org> wrote:

> "Zed A. Shaw" <zedshaw / zedshaw.com> writes:
> 
> 5)  Require that the header MUST have the
> > content-length settings.  This is again to make sure that requests
> > which are too large are always booted.  Making this optional just
> > leaves open an attack where you again slam the server with never
> > ending data until it dies.  This also makes it very clear how the
> > content is always sent and leaves nothing open for debate.
> 
> To add to what Zed's said:
> 
> Servers can always prevent trickle attack by specifying a
> timeout. Without any timeout from server, a client would always be
> able to tie up unnecessary resources (IP port, for example).
> 
> Most HTTP/1.1 servers close idle persistent connection after 2 minutes
> of inactivity.
> 
> Again, server implementations should employ some sort of timeout
> mechanism. That's just the right thing to do.
> 
> YS.
> 

That misses the point of the trickle attack.  I just trickle enough to
never be idle but slowly eat up memory.  Since the server can't boot me
as I might be legit, it's got to keep everything I send around.
Eventually I'll fill up the process' memory.  Most servers just set a
max size for the read buffer, but then they have to always read that
amount before detecting the attack.  By simply predefining the size bad
clients can be booted immediately for going over size and booted before
the data has been read.

Predefined size protocols also have the advantage that any data can be
sent without needing to encode the data.  If the server knows how much
it must read then it just reads that much.  With line ended protocols
you're constantly negotiating some encoding so that you avoid binary
data tripping up the parsing.

Zed A. Shaw
http://www.zedshaw.com/