<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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.<br>
</p>
<p>Christos.<br>
</p>
<br>
<div class="moz-cite-prefix">On 09/27/2016 05:16 PM, Spyridon
(Spyros) Mastorakis wrote:<br>
</div>
<blockquote
cite="mid:FFE7E552-51EE-4862-A37F-CC3B5CDFF4D3@cs.ucla.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
My 2 cents on the discussion:
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">How exactly to do that is an open question, but this
is my rough intuition.</div>
<div class=""><br class="">
<div class="">
<div class="">
<div class="">
<div class=""><span class="" style="float: none; display:
inline !important;">Spyridon (Spyros) Mastorakis</span><br
class="">
<span class="" style="float: none; display: inline
!important;">Personal Website: </span><a
moz-do-not-send="true"
href="http://cs.ucla.edu/%7Emastorakis/" class="">http://cs.ucla.edu/~mastorakis/</a><br
class="">
<span class="" style="float: none; display: inline
!important;">Internet Research Laboratory</span><br
class="">
<span class="" style="float: none; display: inline
!important;">Computer Science Department</span><br
class="">
<span class="" style="float: none; display: inline
!important;">UCLA</span></div>
<div class=""><br class="">
</div>
</div>
</div>
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Sep 27, 2016, at 3:59 PM, <a
moz-do-not-send="true" href="mailto:woodc1@uci.edu"
class="">woodc1@uci.edu</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On September 27, 2016 at 3:23:14 PM, Lixia
Zhang (<a moz-do-not-send="true"
href="mailto:lixia@cs.ucla.edu" class="">lixia@cs.ucla.edu</a>)
wrote:<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">On Sep 27, 2016, at
1:49 PM, Cesar Ghali wrote:<br class="">
<br class="">
The PIT may very well serve a useful purpose in
NDN/CCN. However, it creates well-known<br class="">
</blockquote>
security problems (interest flooding is trivial) and
it’s highly doubtful that a deterministic<br class="">
solution is possible.<br class="">
<br class="">
the discussion below is on how to effectively mitigate
Interest flooding.<br class="">
By removing PIT, one also removes a number of
important functions enabled by PIT.<br class="">
</blockquote>
<br class="">
To re-iterate Cesar’s point, as of now, there is no
truly effective<br class="">
interest flooding mitigation. However, one concrete way
to minimize<br class="">
the attack surface (for routers) is to get rid of the
attack's root<br class="">
cause: the PIT. (Producers could still be hosed with
bogus interests.)<br class="">
And since the PIT enables several important functions,
other<br class="">
architecture changes will probably have to follow in its
wake.<br class="">
<br class="">
Personally, I don’t think we should settle with an
architectural<br class="">
element that has a known (and quite severe) weakness
simply because it<br class="">
enables some nice features in practice. The more serious
design<br class="">
problems must be dealt with first, not last.<br class="">
<br class="">
Chris<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>