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

Christos Papadopoulos christos at colostate.edu
Thu Sep 29 07:11:09 PDT 2016

Brief interruption to bring the latest news. Apparently we exceeded the 
1Tbps mark with these IoT attacks:



On 09/28/2016 08:19 PM, Luca Muscariello wrote:
> That's my understanding too.
> 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.
> We wrote  a paper last year that quantifies that.
> 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.
> So before throwing away the PIT I need to understand how compelling is 
> what I get in return.
> 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.
> 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.
> Then I still refrain about the routing to locators.
> That is where I loose a whole set of compelling features.
> But before going there it would be useful to understand what the PIT 
> is and what  the size of this beast really is.
> Luca
> On Thursday, 29 September 2016, <Marc.Mosko at parc.com 
> <mailto:Marc.Mosko at parc.com>> wrote:
>     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.
>     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.
>     Marc
>>     On Sep 29, 2016, at 9:47 AM, Luca Muscariello
>>     <luca.muscariello at gmail.com
>>     <javascript:_e(%7B%7D,'cvml','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
>>     <javascript:_e(%7B%7D,'cvml','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
>>>         <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
>>>>             <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
>>>>             <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
>>>>         <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/5e6134f2/attachment.html>

More information about the Ndn-interest mailing list