Hacker News new | past | comments | ask | show | jobs | submit login

Without net neutrality economics would likely fix this. "We'll limit our 60GBps traffic to this network block because our peering arrangement makes that expensive."

Couldn't an ISP just throttle traffic to a particular network block on receipt of an authorised request.

And that seemingly provides a general solution. Record output to particular network blocks and throttle traffic when it peaks beyond statistically normal bounds? Basically, applying damping.




The problem is a lot of traffic is spiky if you look at it from the view of any given network provider to a site that isn't always getting traffic.

So distribute the DOS traffic enough and it will be very risky for providers to throttle it without appearing to be overall slow for a lot of legitimate traffic.

The other problem is determining what an "authorised request" involves. As it stands it is already a problem that people can - and now and again do - manage to mess up routing tables by sending broken route announcement, re-routing large address ranges to the wrong location.

Too much of internet routing still relies on a large amount of trust. We unfortunately need less of that, not more.

Eventually that might lead us to a situation where we could properly authenticate and authorise requests like what you suggest, but today it is high risk.


One thing perhaps ISPs could do is share data on these attacks, and work to shut off the botnets after the fact- so they can't be used again. So for example if Akamai shared information with ISPs about which orgin IPs were involved in the DDOS attack, the ISPs could reactively reach out to the affected customers. Or the ISPs could even try to examine their own logs after hearing a report of a large scale DDOS attack to determine if any of their own nodes were part of it. There may be also measures ISPs cold take on their CPE routers to detect infected machines on the customer network and warn them more pro-actively.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: