Are these "new" TCP DoS attacks the dreaded "naptha" attacks of 2000?

Just saw the SecurityFocus article and it is hard to tell from Fyodor's article or Robert Lee's post but these smell a lot like a variation of CA-2000-21 also known as as Naptha attacks where a relatively low number/rate of sessions could kill apps and devices or at least spike their CPU pretty nicely.

I was always surprised these didn't get more play, because they were pretty nasty. I even built a Trinux package for the tools that were released. I also thought there was more potential in terms of spoofing application layer messages and the link layer (meaning not relying on connect()) to send an HTTP GET Request or some other first message, especially if it was a crypto protocol.

I remember a certain crappy implementation of SSH where you could peg the CPU with stale sessions because it did whatever RSA foo way too early.

But anyway, it is almost 2009 and who still gives a shit about TCP DoS vulns? I know I don't, but I'm probably just burned out on the whole vuln scene. After all it is all about getting your name in lights, right? Be a king for a day?

Oh that's right Fernando Gont and CPNI still do.

UPDATE:

Damn! Jose Nazario beat me by a day. What else is new.

And from Robert Graham

The problem, in a nutshell, is that they can open a TCP connection that will never be closed. The only way to get rid of them is to reboot the server. This means that I can connect to the Internet with a dialup connection, then quickly take down www.google.com (or any other server) by maxing out the number of connections.

If this statement is true, "that the connection will never be closed" (which to me, means the same thing as never timing out this was not the case with many of the implementations that I did testing of with the Naptha toolset (the srvr responder in particular) released in 2000. Some stacks did time out with a reboot. And depending on the state you were trying to exhaust different states had different thresholds, as well. Exhausting the ESTABLISHED state would respond differently to the LAST_ACK state.

Of course some stacks (and applications) just died, as well.