<div dir="ltr">Hi,<div><br></div><div>I think Christos brings up an important point that helps to formalise the problem</div><div>in its most general form.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>There are several ways to optimally use a buffer like AQMs, shaping sources, policers etc.</div><div><br></div><div>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.</div><div><br></div><div>Removing the PIT won't save the data plane from resource saturation. </div><div>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. <br></div><div><br></div><div>So, if we buy the proposition of removing the PIT because of resource saturation,</div><div>we can remove the buffers too and probably unplug the cables and shut down </div><div>all the radios...</div><div><br></div><div>Luca</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 9:25 AM, Christos Papadopoulos <span dir="ltr"><<a href="mailto:christos@colostate.edu" target="_blank">christos@colostate.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Spyros,</p>
<p>Your intuition is correct.</p>
<p>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.<span class="HOEnZb"><font color="#888888"><br>
</font></span></p><span class="HOEnZb"><font color="#888888">
<p>Christos.<br>
</p></font></span><div><div class="h5">
<br>
<div>On 09/27/2016 05:16 PM, Spyridon
(Spyros) Mastorakis wrote:<br>
</div>
<blockquote type="cite">
My 2 cents on the discussion:
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>How exactly to do that is an open question, but this
is my rough intuition.</div>
<div><br>
<div>
<div>
<div>
<div><span style="float:none;display:inline!important">Spyridon (Spyros) Mastorakis</span><br>
<span style="float:none;display:inline!important">Personal Website: </span><a href="http://cs.ucla.edu/%7Emastorakis/" target="_blank">http://cs.ucla.edu/~<wbr>mastorakis/</a><br>
<span style="float:none;display:inline!important">Internet Research Laboratory</span><br>
<span style="float:none;display:inline!important">Computer Science Department</span><br>
<span style="float:none;display:inline!important">UCLA</span></div>
<div><br>
</div>
</div>
</div>
</div>
<div>
<blockquote type="cite">
<div>On Sep 27, 2016, at 3:59 PM, <a href="mailto:woodc1@uci.edu" target="_blank">woodc1@uci.edu</a> wrote:</div>
<br>
<div>
<div>On September 27, 2016 at 3:23:14 PM, Lixia
Zhang (<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a>)
wrote:<br>
<blockquote type="cite"><br>
<blockquote type="cite">On Sep 27, 2016, at
1:49 PM, Cesar Ghali wrote:<br>
<br>
The PIT may very well serve a useful purpose in
NDN/CCN. However, it creates well-known<br>
</blockquote>
security problems (interest flooding is trivial) and
it’s highly doubtful that a deterministic<br>
solution is possible.<br>
<br>
the discussion below is on how to effectively mitigate
Interest flooding.<br>
By removing PIT, one also removes a number of
important functions enabled by PIT.<br>
</blockquote>
<br>
To re-iterate Cesar’s point, as of now, there is no
truly effective<br>
interest flooding mitigation. However, one concrete way
to minimize<br>
the attack surface (for routers) is to get rid of the
attack's root<br>
cause: the PIT. (Producers could still be hosed with
bogus interests.)<br>
And since the PIT enables several important functions,
other<br>
architecture changes will probably have to follow in its
wake.<br>
<br>
Personally, I don’t think we should settle with an
architectural<br>
element that has a known (and quite severe) weakness
simply because it<br>
enables some nice features in practice. The more serious
design<br>
problems must be dealt with first, not last.<br>
<br>
Chris<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/<wbr>mailman/listinfo/ndn-interest</a><br>
<br></blockquote></div><br></div>