[Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack ever delivered by botnet of hijacked IoT devices)
ravi.ravindran at gmail.com
Thu Sep 29 15:57:14 PDT 2016
Here is the link where you can download our paper:
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
> 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.
> 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
>> 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.
>> 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
>> 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
>> (That's because even a PIT-less design allows the producers to be
>> Now, the particular PIT-less design that Cesar mentioned is this:
>> It is NOT motivated solely by interest flooding mitigation. It just
>> 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
>> 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
>> make an architecture Content-Centric. Either or both can be removed and
>> 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
>> (BTW, it can in fact co-exist with a PIT-ful CCN).
>> 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
>> And I agree that the signal mentioned here is not a prerogative of the
>> So, to stay in topic to this thread, from my point of you what JJ has
>> 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
>> 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).
>>> > 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
>>> >>> 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
>>> >> 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
>>> >>> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest