The people you're really worried about --- the people who are set up to carry out extortion operations against your site, who know how to safely deliver their demands and safely collect your money --- already have the ability to take you down with the push of a button. Some of them herd massive botnets, some of them have relays set up in various countries and on various networks. Some of them are even set up to inject prefixes into BGP4.
From 2001-2005, I worked in various roles at Arbor Networks, now basically the dominant DDoS defense company, deployed at every major ISP in the world. I was, among other things, the lead developer on Peakflow DoS, their DDoS tracking and remediation product. The thing I learned there that sticks most: ISPs deal with tens or hundreds of DDoS attacks (real, honest to god attacks) per day.
I can't see how any new DDoS research is going to change the game at this point.
Last time we were under serious ddos, the attack vector shifted several times in response to our countermeasures. One of those shifts was looking quite similar to what fyodor describes. An attacking machine opened 1000+ connections, sent the request, then shrank the receive window to 1 byte. The botnet segment doing that was maybe ~500 zombies or so.
Of course, it's trivially mitigated on linux with iptables connlimit match (fyodor mentioned that, too).
The punchline: our colo provider insisted on having a PIX firewall in front of our box, with stateful packet inspection and all that. And, of course, that was way too much state for it to keep. So the PIX has gone down and we've got our 24 hours of downtime.
TCP is a stateful protocol. Per-connection state uses memory, so creating more connections will exhaust memory OR it will cause no more connections to be created - both cases are a form of DoS.
A naive approach is to initiate a lot of connections, but never complete the setup. That's a SYN flood. Another approach is to actually complete the handshake, then initiate a tear down and never complete it. The OS at the server end gets stuck with a lot of half-closed connections that may take many minutes to timeout and there's no application control over this. There's no control over this 'stuck' connections at the OS level either, the only option is to wait for them to die off as per TCP spec.
There are other variations, but you get the idea. I do agree though that these two guys are simply whoring for attention.
Don't forget to stuff the kernel buffers with a few (or many) megabytes of data before getting those connections 'stuck'.
The amount of time it will take for them to die off (as per the TCP spec) is 'infinity' since there is no provision in the protocol itself for detecting unresponsive peers. If your operating system implements a hack called 'tcp keepalive' then those connections will die in a couple of hours in a typical configuration.
Put up? Fyodor described exactly how the attacks work (attacks which have been widely known for a very long time). The only thing he didn't mention here is that you can abuse selective acknowledgement to make one variation of the attack especially destructive.
Oh, and you can attack clients. That's a new entertaining possibility that nobody thought of before.
Until the patch is ready? I hate to break it to you, but there is never going to be a patch for this.
"My opinion on disclosure is simple: put up or shut up! If you go the full-disclosure route and announce the bug and full details immediately, that is great. Or if you want to coordinate disclosure with vendors and keep the bug secret until a patch is released, that is great too. But if you go with the coordinated approach (which vendors refer to as “responsible disclosure”), there is no point announcing and hyping the bug before a patch is released and you're ready to disclose details. I don't tell people how to report vulnerabilities—disclosure has long been one of the most personal and political issues in the security community. So I let them decide for themselves. But when people decide on the partial disclosure fear-mongering approach, I reserve the right to speculate on the issue as I do here. I recognize their vague description of the attack and results because I've written and used a similar DoS tool. I was not the first to do so, either."
And I was around at the time of synflooding to teardrop. The botnets already have the power to DoS the whole Internet for a while by attacking key infrastructure elements. The question is why they don't do it or perhaps why would they do it. Ransom won't work. And zombies are valued assets to use for more profitable tricks like spamming, installing spyware, or 419-style scams.
From 2001-2005, I worked in various roles at Arbor Networks, now basically the dominant DDoS defense company, deployed at every major ISP in the world. I was, among other things, the lead developer on Peakflow DoS, their DDoS tracking and remediation product. The thing I learned there that sticks most: ISPs deal with tens or hundreds of DDoS attacks (real, honest to god attacks) per day.
I can't see how any new DDoS research is going to change the game at this point.