This isn't really new as others have said. Maybe someone publicly released a tool to do this finally.
but basically how this works:
You have a malicious client figure out a transaction(s) that are easy for the client to request, but difficult for the server to fulfill (ideally).
The client initiates the TCP connection.
Three way handshake happens.
Client sends in the whole request.
Client immediately sends in a tcp window update with a very small or zero window size.
The server processes the entire request and goes to send it.
The server's TCP stack says "Oops, I need to send to that client but he has a small or zero window size. I can only send packets of X size, or I can't send at all. This data is going to sit in my TCP Send Buffer until I can send it".
Two things happen here. The TCP send buffer is full (taking up memory) and 2, if the amount of data needed to be sent > TCP Send Buffer size, you now have a Server thread blocked trying to send the data.
The client delays for some amount of time and then sends another TCP window update "Hey, I can take X bytes of data now".
The server sends X bytes of data.
The client can now play a game of sending random small window sizes and or zero windows to essentially slow the connection to a crawl and consume resources on the server side.
This sounds coceptually identical to any number of tarpits, like "labrea", for example. That was produced by Tom Piston et. al in 2001. This isn't really new.
Precisely. If you get too aggressive with combating this, you're locking out everyone whose machine or connection isn't up to some arbitrary technical standard. You might decide that dial-up no longer matters to you, but what about mobile?
You can combat this a little with good architecture, by making sure the attacks won't stack.
One part of the attack is finding a difficult-to-serve request. The other part is being very slow at receiving the response, keeping the request alive. The impact is multiplied if you keep dozens exceptionally high-memory processess alive while the clients slowly the response that those processors generated.
If you have the right architecture, it won't matter if the difficult-to-serve request takes a long time to send - you backend processes it, sends the response to your web server, and frees the resources (not holding resources until the client is happy).
This remembers me of the really cool spamd application from OpenBSD just the other way around:
"When a sending host talks to spamd, the reply will be stuttered. That is, the response will be sent back a character at a time, slowly."
Combined with a per ip connection limit, async-IO style server like Node.js would alleviate the problem somehow by using smaller amount of memory per connection.
but basically how this works:
You have a malicious client figure out a transaction(s) that are easy for the client to request, but difficult for the server to fulfill (ideally).
The client initiates the TCP connection.
Three way handshake happens.
Client sends in the whole request.
Client immediately sends in a tcp window update with a very small or zero window size.
The server processes the entire request and goes to send it.
The server's TCP stack says "Oops, I need to send to that client but he has a small or zero window size. I can only send packets of X size, or I can't send at all. This data is going to sit in my TCP Send Buffer until I can send it".
Two things happen here. The TCP send buffer is full (taking up memory) and 2, if the amount of data needed to be sent > TCP Send Buffer size, you now have a Server thread blocked trying to send the data.
The client delays for some amount of time and then sends another TCP window update "Hey, I can take X bytes of data now".
The server sends X bytes of data.
The client can now play a game of sending random small window sizes and or zero windows to essentially slow the connection to a crawl and consume resources on the server side.
Edit: Formatting