Hacker News Reader

There "is" such a way, see RFC 5575, but it seems to be little known/implemented/deployed/enabled/something.

5575 is a BGP extension that says "for packets from x to y, do z". Assuming a router knows on which if its input ports such packets arrive (and during a DDoS it doesn't have to wait long for the next packet), it can disseminate the flow specification towards the actual source(s) quickly, so the packets can be dropped quite far from the DDoS target, in the ideal case as soon as it reaches an honest ISP.

Egress filtering should kill much of the spoofed-origin traffic and this much of the rest — if deployed.

I'd love to know why 5575 isn't deployed. Memory concerns maybe?

It is possible to mitigate, but it takes time.

> Is there no way to capture a list of all IPs involved in the traffic and quickly distribute a "shut off this device" request to the origin network?

Now hackers have a new attack vector.

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.

And governments can easliy silence "nuisances" like human rights lobbysts.

Governments can already block traffic on their border and can organize attacks again foreign targets (remember China vs Github case).

Oppressive governments can do even worse things to human rights activists, like banning a person from international travel (like Mr. Snowden or Wikileaks founder) and getting them extradicted from other countries.

The Internet is supposed to be a dump series of pipes. However, in practice you can of course try a traceroute and then complain to the ISP, which will or will not cooperate. If the ISP does not cooperate, then you can call their upstream provider and kindly ask them to call their customer and yell at them, but note that money is flowing in the wrong direction for that to work.

Plus you get the problem that you are usually seeing DDOS traffic from innocent bystanders, if the ISP is shutting of a compromised home router, then their customer will not have internet for some length of time.

Shutting off Internet for people housing compromised devices does not seem like a bad thing, and it is probably the best solution that exists.

It probably seems like a bad thing to the customer paying for internet, and since they're the one paying for service they do get some say in the matter.

Which do you think costs Comcast more? Temporarily disabling 20,000 customers' internet connections, or forcing Akamai to drop Brian Krebs as a customer?

I think someone who has equipment engaged in DDoS attacks might be a bigger cost to the telecom than they are paying anyway. Those 20,000 customers are either using disproportionately more bandwidth and resources or they are at least unwittingly involved in illegal activity, so Comcast would have either a financial incentive or social obligation to temporarily suspend their service. The company should be complaining to the customer, and they should be worried about losing their service. If every competitive provider had these very narrow standards, customers should be more worried about not having Internet because of their security illiteracy.

Why not simply block traffic from the specific unknowing customer to the target? I.e. Allow all normal traffic from the customer to go through, except for the traffic that was identified as being part of a DDoS? Is it expensive for an ISP to do that type of intelligent/rule-based routing?

It would probably take too long to get the ISP to comply, and I suppose the targets keep changing with botnets

http://packetlife.net/blog/2009/jul/6/remotely-triggered-bla...

You cannot stop attack because web is decentralized. You cannot tell other Autonomous System to stop sending traffic to you.

> Why do backbones allow it to be carried?

Because they get paid for any traffic passing through. The more traffic they have the more profit they earn.

You can capture the IPs, but they aren't going to be the true originating IPs. Usually they are just random IPs generated on the fly. Or sometimes the attacker will pick a company or ISP and spoof the packets with those IPs.