<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
To get back to the issue of having or not having the PIT:<br>
<br>
Recall that this thread started with discussion of massive DoS
attacks on <br>
the current Internet, initiated from IoT devices. It progressed to a
discussion<br>
of DoS attacks in CCN. It was then suggested that a PIT-less<br>
design might address the only glaring major type of DoS attack in CCN
--<br>
interest flooding. I specifically say "address", not "solve" or
"obviate". <br>
(That's because even a PIT-less design allows the producers to be
interest-flooded).<br>
Now, the particular PIT-less design that Cesar mentioned is this:<br>
<br>
<a class="moz-txt-link-freetext" href="https://arxiv.org/abs/1512.07755">https://arxiv.org/abs/1512.07755</a><br>
<br>
It is NOT motivated solely by interest flooding mitigation. It just
happens<br>
to be one of its features. The authors (of whom I'm one) would love
to<br>
hear some reasoned criticism of this PIT-less design. It should be
based<br>
on actually reading the paper. <br>
<br>
More generally, the PIT is currently a fundamental feature of both
NDN and CCNx.<br>
Should it even be questioned? To some true believers, this is
clearly an anathema.<br>
IMHO, all architecture features should be up for debate and all
dogmas ought to be questioned.<br>
For example, I believe that the PIT and the CACHE (for example) are
not what <br>
make an architecture Content-Centric. Either or both can be removed
and what <br>
remains would still be a Content-Centric Network (though perhaps not
a good one). <br>
<br>
Finally, the PIT-less design mentioned above could well be
ill-advised,<br>
or even totally senseless. We simply don't know yet. <br>
Indeed, as the paper admits, it has some problems of its own.<br>
Or, it might make sense in some settings, e.g., where the <br>
network infrastructure is mobile. Or, it might be an alternative/optional
implementation.<br>
(BTW, it can in fact co-exist with a PIT-ful CCN).<br>
<br>
Cheers,<br>
Gene<br>
<br>
<pre class="moz-signature" cols="72">======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine
</pre>
<div class="moz-cite-prefix">On 9/27/16 10:12 PM, Luca Muscariello
wrote:<br>
</div>
<blockquote
cite="mid:CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com"
type="cite">
<div dir="ltr">The work JJ has presented this morning is probably
another interesting thread.
<div>And I agree that the signal mentioned here is not a
prerogative of the PIT.</div>
<div><br>
</div>
<div>So, to stay in topic to this thread, from my point of you
what JJ has proposed</div>
<div>has more compelling properties to remove the PIT than the
DDoS example</div>
<div>considered here.</div>
<div><span></span>
<div><br>
</div>
<div>In JJ's proposition, you trade something for something
else. It's not an equivalent</div>
<div>architecture to NDN though. So we need to be careful
before laying away pieces of the architecture. There is a
price for that.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
On Wednesday, 28 September 2016, <<a
moz-do-not-send="true" href="mailto:Marc.Mosko@parc.com"
target="_blank">Marc.Mosko@parc.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Removing
the PIT and using, for example, a label swapping approach
such as J.J. Garcia-Luna-Aceves has suggested, does not
remove the “signal” you talk about. One could keep
upstream and downstream counters for each label swap
identifier and see which labels are not getting downstream
data.<br>
<br>
I do not think the strategy of purging PIT entries based
on the shortness of their remaining lifetime gives you any
correlation to purging attack packets. First of all, an
attacker could easily use a very large Interest Lifetime.
Well-behaved clients that are using RTT estimates in their
Interest Lifetime would, by definition, likely have very
small margins in the Interest Lifetime remaining before
the Data comes back (personally, I think it is a problem
to make InterestLifetime based on RTT, but that’s a
different thread).<br>
<br>
<br>
Marc<br>
<br>
> On Sep 28, 2016, at 10:47 AM, <a
moz-do-not-send="true">christopherwood07@gmail.com</a>
wrote:<br>
><br>
> On September 27, 2016 at 5:14:14 PM, Christos
Papadopoulos<br>
> (<a moz-do-not-send="true">christos@colostate.edu</a>)
wrote:<br>
>><br>
>><br>
>> On 09/27/2016 04:59 PM, <a
moz-do-not-send="true">woodc1@uci.edu</a> wrote:<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>
>> You start with what I believe to be the wrong
premise: protecting the<br>
>> router. In NDN we care about communication, not a
single router.<br>
>> Protecting a router is winning the battle but
losing the war.<br>
><br>
> I respectfully disagree. If the adversary takes out
the producer,<br>
> there is no communication. If the adversary takes out
the routers<br>
> adjacent or otherwise on the path to the producer,
there is no<br>
> communication. Protecting the router(s) is equally
important,<br>
> especially since it may impact more than just a
single producer.<br>
><br>
>><br>
>> I don't understand your statement that the root
cause of DDoS attacks is<br>
>> the PIT. The root cause of DDoS is resource
exhaustion.<br>
><br>
> In these attack scenarios, the PIT *is* the resource
being exhausted.<br>
><br>
>><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>
>> You are underestimating the importance of the
signal the PIT provides.<br>
>> It is an important insight into the status of
communication. The PIT<br>
>> does not simply enable some "nice features".
Think a bit harder about<br>
>> the things you can do with this signal.<br>
><br>
> In most attack scenarios, yes, it tells you when
bogus interests are<br>
> flooding a particular prefix and otherwise when
communication is<br>
> failing. But consider this scenario. Suppose you have
a malicious<br>
> producer cooperating with one or more malicious
consumers. The<br>
> consumers are quickly sending interests to this
legitimate producer,<br>
> who responds with legitimate data. The communication
is not failing.<br>
> Their goal is to do nothing other than saturate the
PIT of some<br>
> intermediate router. Per Spyros’ follow-up
suggestion, that router<br>
> might kick out old, legitimate interests in favor of
these malicious<br>
> ones. Of course, this is fundamentally how we would
expect one to deal<br>
> with and manage a limited resource. So preventing
this attack seems<br>
> difficult for any approach. But the point is that
this resource, the<br>
> PIT, is easily abused in CCN/NDN.<br>
><br>
> Chris<br>
><br>
> ______________________________<wbr>_________________<br>
> Ndn-interest mailing list<br>
> <a moz-do-not-send="true">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a moz-do-not-send="true"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest"
target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a moz-do-not-send="true">Ndn-interest@lists.cs.ucla.edu</a><br>
<a moz-do-not-send="true"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest"
target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<br>
</body>
</html>