UDP port 80 DDoS attack

Tue Feb 7 01:43:00 UTC 2012

>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.

there is a fix for it, it's called "putting a fuckton of ram in -most- 
routers on the internet" and keeping statistics for each destination 
ip:destination port:outgoing interface so that none of them individually 
can (entirely/procentually compared to other traffic) flood the outgoing 
interface on that router... end result, if enough routers are structured
like that, is that ddos attacks will be come completely useless.

keyword here, is terabytes of ram.

statistic tables on very basic ipv4 stuff alone would already take 
multiple 100's of gigabytes...

(keep in mind, this won't be "cpu work", its just using the table entry 
size * dest ip as an offset and reading it out ;)

the good news is, ram doesn't cost a flying fuck anymore...

it just requires a complete re-think of router design, but then again, 
with the prices that cisco and juniper charge we expect a bit more than a 
1960's telephone exchange look and feel device, or we might as well use 1 
linux box/blade per 20gbit/s throughput and consider that whole thing a 
"hotpluggable interface". cisco and juniper, at the moment, sell faster 
versions of their crap from the 1990s, but not much effort went into 
completely re-designing the stuff to be suitable for the internet as it is 
today, they still forward all packets they can get their hands on, and 
besides rather simple stuff like QoS, not much effort went into 
inteligently spreading the capacity available on the outgoing interface 
(at least for that individual router) over all the possible targets.

now, if an outgoing interface is 10ge, and 10mbit traffic should go to 
1.2.3.4 and 20ge (ddos) traffic should go to 4.3.2.1, i'd say, a router 
should give 1.2.3.4 the full 10ge, as it is available, and lower volume 
should basically just get a higher priority.

we have not quite worked out the formula yet... but it should be something 
along those lines (simply to say, any destination ip can never fill more 
than half of the outgoing interface, doesn't quite cover it, it needs some 
"intelligent adjustment of the percentage")..

basically...
table:

destip
destport
packetcounter

every so and so many packets/timeslices,whatever that packetcounter is 
decreased by 1

every packet, the packet counter is incremented

after inactivity for that ip for timeperiod x, the packet counter is 
cleared.

with ipv4, this "destip" entry is such a small (32 bit) integer that its 
better to just not store the ip itself but rather just throw more ram at 
it and use the ip address number as the offset in the array

(for faster lookups, preferably in hardware logic).

the same thing could be applied to pretty much every other concept still 
done with slow lookups nowadays (arp, routes, etc)... throw more ram at it 
and use the destination as the offset, who cares if 99.9% of the ram is 
not actually used. for the price of a juniper, you can buy a truck full of 
ram chips ;).. it's faster that way, and it allows us to do a lot of 
things, like not passing potential ddos floods in the first place, and 
intelligently allowing everyone, not an equal share of the traffic 
capacity, but the part they need.

if you don't mind wasting 50% of the available capacity the formula to 
determine wether to forward a packet or not is 
quite simple, if you also want to give a destip 100% of the traffic in 
situations where there is no other traffic, it becomes a bit more 
complicated..

as stated before, we haven't quite worked it out in full yet, but in any 
case... this would require for at least 30% of the routers that currently 
are on the internet and are 110 kg heavy "1960s telephone exchange models" 
to be replaced with 2012 style hardware, not "just faster cisco 7200 like 
things".