[Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices

[Cedric Westphal]

Hi,

regarding 3), it's probably too late once your under attack. Note that in this case, it's Akamai that was attacked, and even though they have more capacity to spread out the attack, the server still went down.

regarding 2), many people have made this content that NDN requires flow balance and that measuring flow imbalance tells you about attack. There is information in the unsatisfied interests. That is true, but that information is noisy and more importantly, relying on it means it becomes a new vector of attacks.

Consider a few nodes spraying interests for non existing objects. The router will see a flow imbalance, and will shut down traffic, but it can't discriminate between valid traffic and attack. Attack succeeds. This is different from flooding the PIT, since it only attacks the monitoring of the flow imbalance and the router stops forwarding not under PIT exhaustion but from its observation of unsatisfied interests.

New features enabled by PIT are also new risks.

C.

Sent from HUAWEI AnyOffice
From:Paul Bellamy
To:ndn-interest at lists.cs.ucla.edu,
Date:2016-09-28 01:57:52
Subject:Re: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices

One the invariants of a DoS is that there are a lot of packets depleting the resources of a single target physical machine. Which means we can prevent it in two ways. Given that, there are several potential solutions which jump to my mind:

1) Reject bad-actors sending lots of packets. Would work against a DoS, but not a DDos, as each individual actor is sending a reasonable amount of packets.

2) Stop too many packets reaching the single target. During resource-exhaustion we could purge PIT entries with similar prefixes. The nature of the flooded interests means they should all have a similar prefix. We could limit the number of outstanding interests for a given prefix.

3) Scale up the target. IMO, one of the big advantages of NDN for service-operators is that (unlike IP) interests don't have to be answered by any specific physical machine. If you've designed your application well, you can easily add more capacity. This is "good enough", until you run into cost-constraints.

Of those, a combination of 2 and 3 seem the most practical.

Regards,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/d2caeadc/attachment.html>