A secure democratic Net is a fundamental right

source

It would be like this

"In 2002, I wrote a companion utility named Ndos (“Network Denial of Service&rdquo), which creates DoS situations against listening TCP services. It does this by exhausting resources of the listening applications or the OS kernel they are running on. There are numerous resources you can exhaust this way, but my main focuses were open socket limits in the listening application and TCP stack, TCP send buffers in the OS kernel, and concurrent process limits of the OS kernel (or configured by the application).

1. Attacker sends a TCP SYN packet to the target port from your own IP address (or one you control) to request a connection.
2. The target port is open, so it will respond with a SYN/ACK packet—the 2nd step of the TCP 3-way handshake. Remember that attacker sent the SYN as a raw packet from userland rather than using his operating system's connect() API to establish the connections. So when attacker's operating system's TCP stack sees the unexpected SYN/ACK come back, it would normally destroy the nascent connection by sending a reset (RST) packet. This is why the special firewall rule was mentioned—to prevent such interference by attacker's OS. Instead attacker's DoS application handle all these packets by sniffing them from userland (generally using libpcap) and building/sending the raw reply packets.
3. Using the initial sequence number and other information from the SYN/ACK, attacker sends an acknowledgment packet (the final step of the 3-way handshake) to complete the connection. "

He used a not released internal tool for that which he described in the book "how to own a continent" (see our bookclub :) ) in the following free chapter (which is one of the best by the way.

But is it exactly this ?

" I wouldn't be surprised if they have identified some ways to enhance the bug and make it more effective (at least in certain situations)... You have many variables to control, including the number of connections, payload data (a ton of flexibility here), source IP addresses to use, window size, attack timing, etc. Those can be optimized to design the most effective attack for a given target. But in many cases the services are down well before you get to the attack optimizing stage"

I don't agree with the following

"Once an attack has started, it is relatively easy to identify and block the culprit IP addresses" Such low level attacks (4 to 10 connections before the machine goes down) are just not filterable. There are too many other things going on at the same time to see it coming. Even for automated filters it would be difficult because you would have too many other factors giving a faulty response or indication. I have always hundreds of syn-ack cookie alerts, would I now have to refuse all those connections a second time when I know that 99,99% are just wrong packets but not malicious.

But I do agree with this

"While I don't consider it a serious threat to the Internet as a whole, I do consider it an important issue which should be fixed"

Personally I think it is about time, if you see that the discussions and problems and research for solutions is going back to even 1996.... that is nearly 12 years ago.

Finally

What we are even more curious about is a debate/confrontation between those two.