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

[Luca Muscariello]

Hi,

I think Christos brings up an important point that helps to formalise the
problem
in its most general form.

You can optimally use the available resources, or sub-optimally use them,
mis-use them, or create damage by exhausting resources on purpose or
because of mis-configuration.

Let's take a buffer and IP (but also NDN). You can use it optimally
according to some criteria, or poorly use it, or forget a non controlled
source hitting hard a buffer that will generate damage to other conformant
sources. Or just create damage on purpose.
There are several ways to optimally use a buffer like AQMs, shaping
sources, policers etc.

In the case of the PIT I don't see much difference. You need active PIT
management to optimise the network, or you may not and need similar
mechanisms to those I cited in the case of a forwarding queue.

Removing the PIT won't save the data plane from resource saturation.
Traffic engineering, to evaluate how much resources are needed, will always
be a necessary task as well as traffic management to allocate available
resources according to some criteria: latency, throughput, fairness.

So, if we buy the proposition of removing the PIT because of resource
saturation,
we can remove the buffers too and probably unplug the cables and shut down
all the radios...

Luca















On Wed, Sep 28, 2016 at 9:25 AM, Christos Papadopoulos <
christos at colostate.edu> wrote:

> Spyros,
>
> Your intuition is correct.
>
> A DDoS attack exploits resource exhaustion at some point in the
> communication chain. What we see currently with these IoT attacks is that
> the ratio of attackers to communication resources is approaching infinity,
> thus you will not win by simply throwing more resources. The alternative is
> to manage the resources you have and control failure when it happens. With
> NDN and the PIT you have important information about whether communication
> failed, where and potentially how it failed. That's a much better starting
> point than IP.
>
> Christos.
>
> On 09/27/2016 05:16 PM, Spyridon (Spyros) Mastorakis wrote:
>
> My 2 cents on the discussion:
>
> I agree that the network should take countermeasures to mitigate Interest
> flooding attacks and I believe that what you gain from the PIT state is
> more than the price that you have to pay.
>
> If the flooding concerns have to do with PIT, then the PIT size of each
> router should be limited. If the size reaches the maximum, the router
> should start dropping state in the sense of erasing PIT entries to mitigate
> a potential flooding attack. Which entries a router should erase? Probably,
> the ones closer to expiration.
>
> How exactly to do that is an open question, but this is my rough intuition.
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
> On Sep 27, 2016, at 3:59 PM, woodc1 at uci.edu wrote:
>
> On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu)
> wrote:
>
>
> On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
>
> The PIT may very well serve a useful purpose in NDN/CCN. However, it
> creates well-known
>
> security problems (interest flooding is trivial) and it’s highly doubtful
> that a deterministic
> solution is possible.
>
> the discussion below is on how to effectively mitigate Interest flooding.
> By removing PIT, one also removes a number of important functions enabled
> by PIT.
>
>
> To re-iterate Cesar’s point, as of now, there is no truly effective
> interest flooding mitigation. However, one concrete way to minimize
> the attack surface (for routers) is to get rid of the attack's root
> cause: the PIT. (Producers could still be hosed with bogus interests.)
> And since the PIT enables several important functions, other
> architecture changes will probably have to follow in its wake.
>
> Personally, I don’t think we should settle with an architectural
> element that has a known (and quite severe) weakness simply because it
> enables some nice features in practice. The more serious design
> problems must be dealt with first, not last.
>
> Chris
>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/dbaac0f1/attachment.html>