[Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack ever delivered by botnet of hijacked IoT devices)

[Ravi Ravindran]

hi Luca,

Here is the link where you can download our paper:

https://www.researchgate.net/publication/306671766_pitLESS_Stateless_Forwarding_in_Content_Centric_Networks

Regards,
Ravi

On Wed, Sep 28, 2016 at 5:47 PM, Luca Muscariello <
luca.muscariello at gmail.com> wrote:

> I think the PIT is not just a question of interests aggregation. It is
> more than that.
> We need to be careful in comparing forwarding and the way routing is/can
> be built  on top of a given forwarding plane.
>
> I read JJ's paper but not yet Gene's and Ravi's.
> If Ravi's can send a preprint that would help the discussion.
>
> Of course I would expect the authors of such papers to make the comparison
> we look for in the papers.
>
> Why is the PIT more than just aggregation?
>
> 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.
> Still this token state space would scale with the interest names state
> space.
>
> 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.
>
> So the big change in JJ design is this one and not label swapping per se.
>
> 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.
>
> 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.
>
> Luca
>
>
>
>
>
>
>
>
>
>
> On Thursday, 29 September 2016, <Marc.Mosko at parc.com> wrote:
>
>> This message got a bit off topic from the OP, so I label swapped the
>> subject ;)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Anyway, I think this is worth more formal study rather than this
>> piecewise analysis.
>>
>> Marc
>>
>> On Sep 29, 2016, at 5:26 AM, GTS <gts at ics.uci.edu> wrote:
>>
>> To get back to the issue of having or not having the PIT:
>>
>> Recall that this thread started with discussion of massive DoS attacks on
>> the current Internet, initiated from IoT devices. It progressed to a
>> discussion
>> of DoS attacks in CCN. It was then suggested that a PIT-less
>> design might address the only glaring major type of DoS attack in CCN --
>> interest flooding. I specifically say "address", not "solve" or
>> "obviate".
>> (That's because even a PIT-less design allows the producers to be
>> interest-flooded).
>> Now, the particular PIT-less design that Cesar mentioned is this:
>>
>> https://arxiv.org/abs/1512.07755
>>
>> It is NOT motivated solely by interest flooding mitigation. It just
>> happens
>> to be one of its features. The authors (of whom I'm one) would love to
>> hear some reasoned criticism of this PIT-less design. It should be based
>> on actually reading the paper.
>>
>> More generally, the PIT is currently a fundamental feature of both NDN
>> and CCNx.
>> Should it even be questioned? To some true believers, this is clearly an
>> anathema.
>> IMHO, all architecture features should be up for debate and all dogmas
>> ought to be questioned.
>> For example, I believe that the PIT and the CACHE (for example) are not
>> what
>> make an architecture Content-Centric. Either or both can be removed and
>> what
>> remains would still be a Content-Centric Network (though perhaps not a
>> good one).
>>
>> Finally, the PIT-less design mentioned above could well be ill-advised,
>> or even totally senseless. We simply don't know yet.
>> Indeed, as the paper admits, it has some problems of its own.
>> Or, it might make sense in some settings, e.g., where the
>> network infrastructure is mobile. Or, it might be an alternative/optional
>> implementation.
>> (BTW, it can in fact co-exist with a PIT-ful CCN).
>>
>> Cheers,
>> Gene
>>
>> ======================
>> Gene Tsudik
>> Chancellor's Professor of Computer Science
>> University of California, Irvine
>>
>>
>> On 9/27/16 10:12 PM, Luca Muscariello wrote:
>>
>> The work JJ has presented this morning is probably another interesting
>> thread.
>> And I agree that the signal mentioned here is not a prerogative of the
>> PIT.
>>
>> So, to stay in topic to this thread, from my point of you what JJ has
>> proposed
>> has more compelling properties to remove the PIT than the DDoS example
>> considered here.
>>
>> In JJ's proposition, you trade something for something else. It's not an
>> equivalent
>> architecture to NDN though. So we need to be careful before laying away
>> pieces of the architecture. There is a  price for that.
>>
>>
>>
>> On Wednesday, 28 September 2016, <Marc.Mosko at parc.com> wrote:
>>
>>> 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.
>>>
>>> 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).
>>>
>>>
>>> Marc
>>>
>>> > On Sep 28, 2016, at 10:47 AM, christopherwood07 at gmail.com wrote:
>>> >
>>> > On September 27, 2016 at 5:14:14 PM, Christos Papadopoulos
>>> > (christos at colostate.edu) wrote:
>>> >>
>>> >>
>>> >> On 09/27/2016 04:59 PM, woodc1 at uci.edu wrote:
>>> >>> 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.
>>> >>
>>> >> You start with what I believe to be the wrong premise: protecting the
>>> >> router. In NDN we care about communication, not a single router.
>>> >> Protecting a router is winning the battle but losing the war.
>>> >
>>> > I respectfully disagree. If the adversary takes out the producer,
>>> > there is no communication. If the adversary takes out the routers
>>> > adjacent or otherwise on the path to the producer, there is no
>>> > communication. Protecting the router(s) is equally important,
>>> > especially since it may impact more than just a single producer.
>>> >
>>> >>
>>> >> I don't understand your statement that the root cause of DDoS attacks
>>> is
>>> >> the PIT. The root cause of DDoS is resource exhaustion.
>>> >
>>> > In these attack scenarios, the PIT *is* the resource being exhausted.
>>> >
>>> >>
>>> >>>
>>> >>> 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.
>>> >>
>>> >> You are underestimating the importance of the signal the PIT provides.
>>> >> It is an important insight into the status of communication. The PIT
>>> >> does not simply enable some "nice features". Think a bit harder about
>>> >> the things you can do with this signal.
>>> >
>>> > In most attack scenarios, yes, it tells you when bogus interests are
>>> > flooding a particular prefix and otherwise when communication is
>>> > failing. But consider this scenario. Suppose you have a malicious
>>> > producer cooperating with one or more malicious consumers. The
>>> > consumers are quickly sending interests to this legitimate producer,
>>> > who responds with legitimate data. The communication is not failing.
>>> > Their goal is to do nothing other than saturate the PIT of some
>>> > intermediate router. Per Spyros’ follow-up suggestion, that router
>>> > might kick out old, legitimate interests in favor of these malicious
>>> > ones. Of course, this is fundamentally how we would expect one to deal
>>> > with and manage a limited resource. So preventing this attack seems
>>> > difficult for any approach. But the point is that this resource, the
>>> > PIT, is easily abused in CCN/NDN.
>>> >
>>> > Chris
>>> >
>>> > _______________________________________________
>>> > Ndn-interest mailing list
>>> > Ndn-interest at lists.cs.ucla.edu
>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>
>>
>> _______________________________________________
>> Ndn-interest mailing listNdn-interest at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>>
>>
>>
> _______________________________________________
> 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/20160929/8790707e/attachment.html>