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".
