<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Brief interruption to bring the latest news. Apparently we
exceeded the 1Tbps mark with these IoT attacks:</p>
<p><a
href="http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/">http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/</a></p>
<p>Christos.</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 09/28/2016 08:19 PM, Luca
Muscariello wrote:<br>
</div>
<blockquote
cite="mid:CAHx=1M60u79q-xitAB__vvA+CJFEnBMJBdMYwDoQDF9DB54k7w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
That's my understanding too.
<div><br>
</div>
<div>When I talk about token I mean a local label that is used to
perform data forwarding. Even in CCN you could do that instead
of using the name of the data. You loose aggregation and the
scaling of the state is just flow state. </div>
<div>We wrote a paper last year that quantifies that.</div>
<div>The result is not always good news. Depending on the use
cases the state is huge. In some other cases it's ok with today
technology. But the numbers and use cases are compelling at the
edge.</div>
<div>So before throwing away the PIT I need to understand how
compelling is what I get in return.</div>
<div><br>
</div>
<div><br>
</div>
<div>So even if the label state space is smaller no matter if
interests are routed using names or locators the PIT size is
measured independently of the name state space.</div>
<div><br>
</div>
<div>Now the first comparison I need to make is between the state
used by a label switching forwarder and a regular CCN
forwarder. No matter if the interests are routed using locators
or names.</div>
<div><br>
</div>
<div>Then I still refrain about the routing to locators.</div>
<div>That is where I loose a whole set of compelling features.</div>
<div>But before going there it would be useful to understand what
the PIT is and what the size of this beast really is.</div>
<div><br>
</div>
<br>
<div>Luca<span></span></div>
<div><br>
</div>
<div><br>
On Thursday, 29 September 2016, <<a moz-do-not-send="true"
href="mailto:Marc.Mosko@parc.com">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">
<div style="word-wrap:break-word">
<div>In the earlier label-swapping proposals, some of which
are JJ’s, it is true that the Interest is routed per-hop
via the name and the labels are established only to label
swap back the Data. The state space scales in the number
of flows through a node.</div>
<div><br>
</div>
<div>In some of the later proposals, such as the paper JJ
just presented at ICN 2016, because the routing is done on
anchors one no longer needs to do a lookup on names at
every hop, but on anchor identifiers. I think it also
went further in that once a forward path label is picked
for an Interest, it could be label swapped in the forward
direction too (assuming an SVC was already setup for that
destination). In this respect, the switching of interests
and data inside the network is no different and only the
edge devices need to do different computations on them.</div>
<div><br>
</div>
<div>Marc</div>
<div><br>
</div>
<br>
<div>
<blockquote type="cite">
<div>On Sep 29, 2016, at 9:47 AM, Luca Muscariello <<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','luca.muscariello@gmail.com');"
target="_blank">luca.muscariello@gmail.com</a>>
wrote:</div>
<br>
<div>I think the PIT is not just a question of
interests aggregation. It is more than that.
<div>We need to be careful in comparing forwarding and
the way routing is/can be built on top of a given
forwarding plane.</div>
<div><br>
</div>
<div>I read JJ's paper but not yet Gene's and Ravi's.</div>
<div>If Ravi's can send a preprint that would help the
discussion.</div>
<div><br>
</div>
<div>Of course I would expect the authors of such
papers to make the comparison we look for in the
papers.</div>
<div><br>
</div>
<div>Why is the PIT more than just aggregation?</div>
<div><br>
</div>
<div>In CCN only Interests are routed. Data is in a
way label switched by using local state. The name in
the data is used to implement label switching and
to follow the bread crumbs. But in principle you
could use a token to implement data forwarding. </div>
<div>Still this token state space would scale with the
interest names state space. </div>
<div><br>
</div>
<div>So the label switching proposed by JJ scales
better because the system has changed state space of
the labels. JJ is using an address space and not a
name space. The assumption is that the address state
space is way smaller. And it is true.</div>
<div><br>
</div>
So the big change in JJ design is this one and not
label swapping per se.
<div><br>
</div>
<div>I read other papers proposing that like
Carzaniga's work (ICN 2014) but I would like to read
Gene's work and also Ravi's work to see how the
solved the issue.</div>
<div><br>
</div>
<div>Now routing on locators is a whole new thread I
guess. But PIT-less design that route on names is
different. Again I need to check the new papers.</div>
<div><br>
</div>
<div>Luca<br>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div><br>
</div>
<div><br>
<div><br>
On Thursday, 29 September 2016, <<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','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">
<div style="word-wrap:break-word">
<div>This message got a bit off topic from
the OP, so I label swapped the subject ;)</div>
<div><br>
</div>
<div>I think preserving the possibility of
symmetric paths is a significant feature.
It is the main property that new
congestion control protocols use and I
think an attribute that deserves serious
thought.</div>
<div><br>
</div>
I agree with Luca that going label swapping
instead of PIT trades one set of features
for another set of features. I think it
would be useful to systematically list the
features offered by the PIT and the features
offered by label swapping. One could then
make a principled comparison between them.
<div><br>
</div>
<div>I believe that the main feature lost is
Interest aggregation. If one has caching,
then I think this is a minor loss. The
window for Interest aggregation to work is
a RTT. The window for caching to work
could be much longer. All the memory one
was spending on the per-packet PIT state
can now be used for more caching. It
would be useful to look at flash crowd
dynamics to see if even in those cases
aggregation saves much compared to
caching.</div>
<div><br>
</div>
<div>In the NDN architecture, one would also
lose the PIT nonce state, but NFD already
has a second nonce table to keep them
around after a PIT entry is erased, so
that could stay as it is. It wouldn’t be
exactly like now, but one could probably
make nonces still work if one thinks
keeping them is worth the memory usage.</div>
<div><br>
</div>
<div>A significant feature gained is a large
reduction in memory bandwidth by not
having to update a large data structure at
wire speed. As we saw today from JJ’s
presentation, if one uses label swapping
and routing on anchor identifiers, then
one can make the case of running on
today’s forwarding hardware at or near
full speed. Thus the time to deployment
on high speed routers could really shrink
down.</div>
<div><br>
</div>
<div>Anyway, I think this is worth more
formal study rather than this piecewise
analysis.</div>
<div><br>
</div>
<div>Marc</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div>On Sep 29, 2016, at 5:26 AM, GTS
<<a moz-do-not-send="true">gts@ics.uci.edu</a>>
wrote:</div>
<br>
<div>
<div 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 moz-do-not-send="true"
href="https://arxiv.org/abs/1512.07755"
target="_blank">https://arxiv.org/abs/1512.077<wbr>55</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 cols="72">======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine
</pre>
<div>On 9/27/16 10:12 PM, Luca
Muscariello wrote:<br>
</div>
<blockquote 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">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></fieldset>
<br>
<pre>______________________________<wbr>_________________
Ndn-interest mailing list
<a moz-do-not-send="true">Ndn-interest@lists.cs.ucla.edu</a>
<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>
</pre>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote></div>
</blockquote>
</body></html>