From lanwang at memphis.edu  Fri Sep  2 05:04:19 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 2 Sep 2016 12:04:19 +0000
Subject: [Ndn-interest] Fwd: ACM Information Centric Networking (ICN) 2016 @
 Kyoto: Call For Participation (Sept. 26-28, 2016)
References: <CAADkTf1ccGRs57D=EJvowV0ckH+snSzr_0vd84T4vDt9bPLyyQ@mail.gmail.com>
Message-ID: <061A7407-8A98-4691-8A1E-33B262194D5D@memphis.edu>



Begin forwarded message:

From: Mayutan A. <mayutan.arumaithurai at GMAIL.COM<mailto:mayutan.arumaithurai at gmail.com>>
Subject: [InternetTC] ACM Information Centric Networking (ICN) 2016 @ Kyoto: Call For Participation (Sept. 26-28, 2016)
Date: September 2, 2016 at 12:27:12 AM CDT
To: <itc at COMSOC.ORG<mailto:itc at comsoc.org>>

ACM Information Centric Networking (ICN) 2016
CALL FOR PARTICIPATION
http://conferences2.sigcomm.org/acm-icn/2016

The organizing committee is delighted to invite you to the 2016 edition of the
ACM ICN conference, to be held in Kyoto Japan, Sep 26-30th 2016

ACM ICN is an annual conference of the ACM Special Interest Group on Data
Communication (SIGCOMM) on information-centric networking.

In a nutshell, this year's conference includes:
- 15 full papers presented in single track format
- 8 short papers presented in single track format
- 8 posters
- 10 demos
- 2 panels
- 1 full-day and 1 half-day tutorials
- 1 associated workshop (ICN for 5G)


Conference website:
http://conferences2.sigcomm.org/acm-icn/2016/

Program details:
http://conferences2.sigcomm.org/acm-icn/2016/program.php

Registration details:
http://conferences2.sigcomm.org/acm-icn/2016/registration.php

Panels:
- New Opportunities and Challenges for Internet Privacy using ICN
- Five Years Later: Critical research challenges in ICN five years after the first ACM ICN workshop.

Tutorials:
- Exploring NDN Research through Real World Problem Solving
- Throughput and Delay Optimality in ICN Design

Topics of papers, posters, and demos include:
- Architecture design and evaluation
- Comparison of ICN architecture proposals
- Limits and limitations of ICN architectures
- ICN evaluation methodology and metrics
- Evaluation of ICN benefits
- Analysis of scalability issues in ICN
- ICN enabled applications
- Routing in ICN networks
- Mobility support
- Trust management
- Access control mechanisms
- ICN economics and business models
- Tools and experimentation facilities
- Measurement methodologies
- Experience from implementations and experiments
- Specific scenarios and implementation approaches
- Feasibility studies for high speed networking
- Privacy
- ICN Deployment
- ICN APIs


On behalf of the organizing committee

Tohru Asami and Xiaoming Fu
(Conference General Chair)

Jeff Burke and Dario Rossi
(Technical Program Committee Chairs)

----------------------------------------------------------------------------------- Internet Technical Committee http://committees.comsoc.org/itc/ To subscribe or unsubscribe: https://comsoc-listserv.ieee.org/cgi-bin/wa?SUBED1=itc&A=1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160902/7ef8ee04/attachment.html>

From Matteo.Bertolino at eurecom.fr  Fri Sep  2 07:28:07 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 02 Sep 2016 16:28:07 +0200
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"
Message-ID: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>

Good morning, thank you for the acceptance in the mailing list. I am a
student and I am writing this mail in order to clarify some doubts
about "how start".
The documentation is a lot and I am a little lost.

1) First of all, I noticed that there are two simulators: one Mininet
based and then ndnSIM. I started some simulations with this last one,
but I did not understand why there are two simulators: do they have
different purposes?

2) Always about ndnSIM, I am a bit in difficult. I successfully
launched a simulation, the simple simulation scenario, but I have
totally not clear how to:
- Modifying the existing scenario
- Make my own scenario. Should I utilize the Helper classes?
- During a simulation in visual mode, I manage to look at FIB, PID and
CS. But I am not able to do the same launching the program in console
with gdb.

3) Finally, the cpp library. I saw it, but I do not understand, again,
how to start. I saw the example about Consumer and Producer, but if I
would like to build a network with some producers, some consumers, and
some gateways! Should I utilize the NFD daemon or is it totally a part?

Excuse-me for the noob questions,
Thanks a lot
Matteo


-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From agawande at memphis.edu  Fri Sep  2 07:51:15 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Fri, 2 Sep 2016 14:51:15 +0000
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"
In-Reply-To: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
References: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
Message-ID: <BN3PR04MB21969809FA61EA751453D2E7D9E50@BN3PR04MB2196.namprd04.prod.outlook.com>

I can answer the first question:


The Mininet based "simulator", Mini-NDN, is actually an emulator in the sense that it runs actual instances of NFD and NLSR on each node provided by Mininet. As a result it does not scale very well due to CPU requirements. ndnSIM is a simulator based on NS-3 and scales much better.


But Mini-NDN emulations might be more closer to real scenario. Running an NFD based application requires no modification in Mini-NDN, it might require some in ndnSIM.


In Mini-NDN the user can interact with the running topology. Example query nfd-status of a node.


Ashlesh

________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Matteo Bertolino <Matteo.Bertolino at eurecom.fr>
Sent: Friday, September 2, 2016 9:28:07 AM
To: ndn-interest at lists.cs.ucla.edu
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"

Good morning, thank you for the acceptance in the mailing list. I am a
student and I am writing this mail in order to clarify some doubts
about "how start".
The documentation is a lot and I am a little lost.

1) First of all, I noticed that there are two simulators: one Mininet
based and then ndnSIM. I started some simulations with this last one,
but I did not understand why there are two simulators: do they have
different purposes?

2) Always about ndnSIM, I am a bit in difficult. I successfully
launched a simulation, the simple simulation scenario, but I have
totally not clear how to:
- Modifying the existing scenario
- Make my own scenario. Should I utilize the Helper classes?
- During a simulation in visual mode, I manage to look at FIB, PID and
CS. But I am not able to do the same launching the program in console
with gdb.

3) Finally, the cpp library. I saw it, but I do not understand, again,
how to start. I saw the example about Consumer and Producer, but if I
would like to build a network with some producers, some consumers, and
some gateways! Should I utilize the NFD daemon or is it totally a part?

Excuse-me for the noob questions,
Thanks a lot
Matteo


-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


_______________________________________________
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/20160902/33fa7867/attachment.html>

From lanwang at memphis.edu  Fri Sep  2 08:11:20 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 2 Sep 2016 15:11:20 +0000
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"
In-Reply-To: <BN3PR04MB21969809FA61EA751453D2E7D9E50@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
	<BN3PR04MB21969809FA61EA751453D2E7D9E50@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <1B37EEC1-B1D3-4C49-9C18-684846D75613@memphis.edu>



On Sep 2, 2016, at 9:51 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:


I can answer the first question:

The Mininet based "simulator", Mini-NDN, is actually an emulator in the sense that it runs actual instances of NFD and NLSR on each node provided by Mininet. As a result it does not scale very well due to CPU requirements. ndnSIM is a simulator based on NS-3 and scales much better.

Just want to clarify: perhaps it?s better to say that the above statement about scalability is at best speculation because we haven?t done a comparison between the two under the same conditions yet. We have run Mini-NDN with 99 nodes (all running NLSR, NFD, and every node ndn-ping?ing every other node) on one machine with a 2.7Ghz Intel Xeon E5-2680 CPU and 160GB memory.  Currently we are exploring the MiniNet cluster edition to further scale up the Mini-NDN experiments.

Lan

But Mini-NDN emulations might be more closer to real scenario. Running an NFD based application requires no modification in Mini-NDN, it might require some in ndnSIM.

In Mini-NDN the user can interact with the running topology. Example query nfd-status of a node.

Ashlesh

________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu<mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of Matteo Bertolino <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>>
Sent: Friday, September 2, 2016 9:28:07 AM
To: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"

Good morning, thank you for the acceptance in the mailing list. I am a
student and I am writing this mail in order to clarify some doubts
about "how start".
The documentation is a lot and I am a little lost.

1) First of all, I noticed that there are two simulators: one Mininet
based and then ndnSIM. I started some simulations with this last one,
but I did not understand why there are two simulators: do they have
different purposes?

2) Always about ndnSIM, I am a bit in difficult. I successfully
launched a simulation, the simple simulation scenario, but I have
totally not clear how to:
- Modifying the existing scenario
- Make my own scenario. Should I utilize the Helper classes?
- During a simulation in visual mode, I manage to look at FIB, PID and
CS. But I am not able to do the same launching the program in console
with gdb.

3) Finally, the cpp library. I saw it, but I do not understand, again,
how to start. I saw the example about Consumer and Producer, but if I
would like to build a network with some producers, some consumers, and
some gateways! Should I utilize the NFD daemon or is it totally a part?

Excuse-me for the noob questions,
Thanks a lot
Matteo


-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr<http://webmail.eurecom.fr/>


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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<mailto: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/20160902/3c33d9b7/attachment.html>

From mhasabet at gmail.com  Fri Sep  2 10:48:13 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Fri, 2 Sep 2016 22:18:13 +0430
Subject: [Ndn-interest] Miscellanous: some problems about "how to start"
In-Reply-To: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
References: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
Message-ID: <CADQ0MFb-Q9_37K=wSCFkBM4eRdJO+JSoPsuuky-gdTfJeLeA0Q@mail.gmail.com>

Hi Matteo

For the 2nd, I suggest you to take a look at the below first:

https://www.nsnam.org/docs/release/3.18/tutorial/ns-3-tutorial.pdf

It's pretty simple and I believe will get you more clear.
Modifying a scenario is not difficult if you feel comfortable with it by
knowing it bit by bit. I believe the above link will lead you to it.
About helpers, well, you'd better use them. They will make your job much
simpler most of the times for usual scenarios.

And for the 3rd one. ndnSIM utilizes a version of NFD(currently 0.3.4)
which is different with current NFD 0.4.1. So, yes. Generally NFD is a part
of ndnSIM!

Actually, your email is a way of going through "how to start". You've just
did it!!

Sabet

On Fri, Sep 2, 2016 at 6:58 PM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

> Good morning, thank you for the acceptance in the mailing list. I am a
> student and I am writing this mail in order to clarify some doubts
> about "how start".
> The documentation is a lot and I am a little lost.
>
> 1) First of all, I noticed that there are two simulators: one Mininet
> based and then ndnSIM. I started some simulations with this last one,
> but I did not understand why there are two simulators: do they have
> different purposes?
>
> 2) Always about ndnSIM, I am a bit in difficult. I successfully
> launched a simulation, the simple simulation scenario, but I have
> totally not clear how to:
> - Modifying the existing scenario
> - Make my own scenario. Should I utilize the Helper classes?
> - During a simulation in visual mode, I manage to look at FIB, PID and
> CS. But I am not able to do the same launching the program in console
> with gdb.
>
> 3) Finally, the cpp library. I saw it, but I do not understand, again,
> how to start. I saw the example about Consumer and Producer, but if I
> would like to build a network with some producers, some consumers, and
> some gateways! Should I utilize the NFD daemon or is it totally a part?
>
> Excuse-me for the noob questions,
> Thanks a lot
> Matteo
>
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> 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/20160902/d5dddf9d/attachment.html>

From tnsr.chatterjee at gmail.com  Sun Sep  4 07:29:49 2016
From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee)
Date: Sun, 4 Sep 2016 19:59:49 +0530
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <D5DB7E1D-6BFF-40C4-8FC7-8B637E6300A7@memphis.edu>
References: <CAOeyPyQSmNjmR-KQxjerS0G_AUpJ0tBcPvSV_LRiSuhBV=FisA@mail.gmail.com>
	<D5DB7E1D-6BFF-40C4-8FC7-8B637E6300A7@memphis.edu>
Message-ID: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>

Hello,
Can you tell me whenever there is a change in LSA of a node A, it is
updated in the neighbors of that node easily as there is periodic sync
interest exchanged among the neighbors. Then how this change will be
propagated to the neighbors of neighbors of A? In the same way i.e. the
neighbors of A replies to the sync interest from its neighbors with the
change?

Thank you for your attention.

Regards,
Tanusree Chatterjee
On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:

>
> On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <
> tnsr.chatterjee at gmail.com> wrote:
>
> Hello,
>
> Can anyone please tell me whether each router sends the periodic sync
> interests to all other routers in the network or only its direct neighbors?
> Is it a hop by hop notification when there is any updates? Or the node
> where the update occurred, floods the update to all other nodes in a data
> packet?
>
>
> The sync interests are sent using a multicast strategy, but they should be
> aggregated when every node has the same sync digest (thus same interest).
> So when the network is stable, only one sync interest is sent per link per
> direction.
>
> Lan
>
> _______________________________________________
> 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/20160904/ba7eb00a/attachment.html>

From Matteo.Bertolino at eurecom.fr  Tue Sep  6 02:02:01 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 06 Sep 2016 11:02:01 +0200
Subject: [Ndn-interest] Miscellanous: some problems about "how to	start"
In-Reply-To: <CADQ0MFb-Q9_37K=wSCFkBM4eRdJO+JSoPsuuky-gdTfJeLeA0Q@mail.gmail.com>
References: <20160902162807.gmwflca2o0s0o8ko@webmail.eurecom.fr>
	<CADQ0MFb-Q9_37K=wSCFkBM4eRdJO+JSoPsuuky-gdTfJeLeA0Q@mail.gmail.com>
Message-ID: <20160906110201.f5gztwghbc48ksk0@webmail.eurecom.fr>

Thank you to all, I've surely the idea clearer!
Matteo

Quoting Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com>:

> Hi Matteo
>
> For the 2nd, I suggest you to take a look at the below first:
>
> https://www.nsnam.org/docs/release/3.18/tutorial/ns-3-tutorial.pdf
>
> It's pretty simple and I believe will get you more clear.
> Modifying a scenario is not difficult if you feel comfortable with it by
> knowing it bit by bit. I believe the above link will lead you to it.
> About helpers, well, you'd better use them. They will make your job much
> simpler most of the times for usual scenarios.
>
> And for the 3rd one. ndnSIM utilizes a version of NFD(currently 0.3.4)
> which is different with current NFD 0.4.1. So, yes. Generally NFD is a part
> of ndnSIM!
>
> Actually, your email is a way of going through "how to start". You've just
> did it!!
>
> Sabet
>
> On Fri, Sep 2, 2016 at 6:58 PM, Matteo Bertolino <
> Matteo.Bertolino at eurecom.fr> wrote:
>
>> Good morning, thank you for the acceptance in the mailing list. I am a
>> student and I am writing this mail in order to clarify some doubts
>> about "how start".
>> The documentation is a lot and I am a little lost.
>>
>> 1) First of all, I noticed that there are two simulators: one Mininet
>> based and then ndnSIM. I started some simulations with this last one,
>> but I did not understand why there are two simulators: do they have
>> different purposes?
>>
>> 2) Always about ndnSIM, I am a bit in difficult. I successfully
>> launched a simulation, the simple simulation scenario, but I have
>> totally not clear how to:
>> - Modifying the existing scenario
>> - Make my own scenario. Should I utilize the Helper classes?
>> - During a simulation in visual mode, I manage to look at FIB, PID and
>> CS. But I am not able to do the same launching the program in console
>> with gdb.
>>
>> 3) Finally, the cpp library. I saw it, but I do not understand, again,
>> how to start. I saw the example about Consumer and Producer, but if I
>> would like to build a network with some producers, some consumers, and
>> some gateways! Should I utilize the NFD daemon or is it totally a part?
>>
>> Excuse-me for the noob questions,
>> Thanks a lot
>> Matteo
>>
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From Matteo.Bertolino at eurecom.fr  Tue Sep  6 04:48:40 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 06 Sep 2016 13:48:40 +0200
Subject: [Ndn-interest] miniNDN: nack, no route
Message-ID: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>

Good morning NDN community,
I choose miniNDN to begin my experience, but surely for my poor use of  
the tool, I am obtaining unexpected results.
I launched the program already written pingAll in a my personal  
topology composed by two nodes connected by a link.

It is a simple scenario, but I have the same following problem with  
the default topology: all the requests are nacked. For example:
PING /ndn/edu/b
20160906T113355.728806 - nack from /ndn/edu/b: seq=7022016325669868656  
time=25.3841 ms reason=NoRoute
[...]
10 packets transmitted, 0 received, 10 nacked, 0% packet loss, 100%  
nacked, time 0 ms

NLSR converged successfully, and the FIB table of A and B seems ok.  
However I wrote them below.

mininet> a nfd-status -b
FIB:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /ndn/edu/b nexthops={faceid=260 (cost=10)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}


mininet> b nfd-status -b
FIB:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
   /ndn/edu/a nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}

Any ideas? Thank you very much

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From shijunxiao at email.arizona.edu  Tue Sep  6 04:56:16 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 6 Sep 2016 04:56:16 -0700
Subject: [Ndn-interest] miniNDN: nack, no route
In-Reply-To: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>
References: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>
Message-ID: <57ceaee1.d345620a.22573.bd6c@mx.google.com>

Hi Matteo

ndnpingserver needs to be running on node B. Otherwise, NFD on node B will return Nack-NoRoute because /ndn/edu/b/ping doesn't match any FIB entry.

Start ndnpingserver with this command:
b ndnpingserver /ndn/edu/b &

Yours, Junxiao

-----Original Message-----
From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
Sent: ?9/?6/?2016 4:49
To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] miniNDN: nack, no route

Good morning NDN community,
I choose miniNDN to begin my experience, but surely for my poor use of  
the tool, I am obtaining unexpected results.
I launched the program already written pingAll in a my personal  
topology composed by two nodes connected by a link.

It is a simple scenario, but I have the same following problem with  
the default topology: all the requests are nacked. For example:
PING /ndn/edu/b
20160906T113355.728806 - nack from /ndn/edu/b: seq=7022016325669868656  
time=25.3841 ms reason=NoRoute
[...]
10 packets transmitted, 0 received, 10 nacked, 0% packet loss, 100%  
nacked, time 0 ms

NLSR converged successfully, and the FIB table of A and B seems ok.  
However I wrote them below.

mininet> a nfd-status -b
FIB:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /ndn/edu/b nexthops={faceid=260 (cost=10)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}


mininet> b nfd-status -b
FIB:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
   /ndn/edu/a nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}

Any ideas? Thank you very much

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


_______________________________________________
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/20160906/6a9e93b9/attachment.html>

From Matteo.Bertolino at eurecom.fr  Tue Sep  6 05:12:35 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 06 Sep 2016 14:12:35 +0200
Subject: [Ndn-interest] miniNDN: nack, no route
In-Reply-To: <57ceaee1.d345620a.22573.bd6c@mx.google.com>
References: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>
	<57ceaee1.d345620a.22573.bd6c@mx.google.com>
Message-ID: <20160906141235.sbp0lh1rcowc8wks@webmail.eurecom.fr>

First of all, thank you very much Junxiao.
I'm shaming about my future question but I have to do it, sorry.

I launch the program from my console in this way:
sudo minindn --experiment=pingall --nPings=10 ./ndn_utils/topologies/try1.conf
I understand that the pingserver is necessary on B, but in which way I  
can execute this command? If I start the console and I execute your  
command, I have not more the possibility of executing the experiment  
pingall.

Moreover, I am following the following tutorial, in the Installation section:

You can use these steps to verify your installation:

Issue the command: sudo minindn --experiment=pingall --nPings=50
When the mininet> CLI prompt appears, the experiment has finished. On  
the Mini-NDN CLI, issue the command exit to exit the experiment.
Issue the command: grep -c content /tmp/*/ping-data/*.txt. Each file  
should report a count of 50.
Issue the command: grep -c timeout /tmp/*/ping-data/*.txt. Each file  
should report a count of 0.

I understood why my scenario does not work, but I do not understand  
how to run the pingserver on node B and launch the pre-built  
experiment in the meantime. Thank you .
Yours Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> ndnpingserver needs to be running on node B. Otherwise, NFD on node   
> B will return Nack-NoRoute because /ndn/edu/b/ping doesn't match any  
>  FIB entry.
>
> Start ndnpingserver with this command:
> b ndnpingserver /ndn/edu/b &
>
> Yours, Junxiao
>
> -----Original Message-----
> From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> Sent: ?9/?6/?2016 4:49
> To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
> Subject: [Ndn-interest] miniNDN: nack, no route
>
> Good morning NDN community,
> I choose miniNDN to begin my experience, but surely for my poor use of
> the tool, I am obtaining unexpected results.
> I launched the program already written pingAll in a my personal
> topology composed by two nodes connected by a link.
>
> It is a simple scenario, but I have the same following problem with
> the default topology: all the requests are nacked. For example:
> PING /ndn/edu/b
> 20160906T113355.728806 - nack from /ndn/edu/b: seq=7022016325669868656
> time=25.3841 ms reason=NoRoute
> [...]
> 10 packets transmitted, 0 received, 10 nacked, 0% packet loss, 100%
> nacked, time 0 ms
>
> NLSR converged successfully, and the FIB table of A and B seems ok.
> However I wrote them below.
>
> mininet> a nfd-status -b
> FIB:
>    /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>    /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>    /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
>    /localhost/nfd nexthops={faceid=1 (cost=0)}
>    /ndn/edu/b nexthops={faceid=260 (cost=10)}
>    /localhost/nlsr nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>
>
> mininet> b nfd-status -b
> FIB:
>    /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>    /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>    /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>    /ndn/edu/a nexthops={faceid=260 (cost=10)}
>    /localhost/nfd nexthops={faceid=1 (cost=0)}
>    /localhost/nlsr nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
>    /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>
> Any ideas? Thank you very much
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From agawande at memphis.edu  Tue Sep  6 07:51:05 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 6 Sep 2016 14:51:05 +0000
Subject: [Ndn-interest] miniNDN: nack, no route
In-Reply-To: <20160906141235.sbp0lh1rcowc8wks@webmail.eurecom.fr>
References: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>
	<57ceaee1.d345620a.22573.bd6c@mx.google.com>,
	<20160906141235.sbp0lh1rcowc8wks@webmail.eurecom.fr>
Message-ID: <BN3PR04MB2196D6FA5D85593AA376E4C5D9F90@BN3PR04MB2196.namprd04.prod.outlook.com>

Can you check if the pingserver is running by issuing the following command in a separate terminal:

ps aux | grep ndnpingserver ?


When you are getting the NACKs did you run the experiment or did you just simply ran "sudo minindn"?

In the latter case, as Junxiao mentioned, an ndnpingserver is required on b:


# Run ndnpingserver on b in background and save output to /tmp/b/ping-server.

mininet>b ndnpingserver /ndn/edu/b > ping-server &


Then from any other node:

mininet>a ndnping -c3 /ndn/edu/b


Ashlesh

________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Matteo Bertolino <Matteo.Bertolino at eurecom.fr>
Sent: Tuesday, September 6, 2016 7:12:35 AM
To: Junxiao Shi
Cc: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] miniNDN: nack, no route

First of all, thank you very much Junxiao.
I'm shaming about my future question but I have to do it, sorry.

I launch the program from my console in this way:
sudo minindn --experiment=pingall --nPings=10 ./ndn_utils/topologies/try1.conf
I understand that the pingserver is necessary on B, but in which way I
can execute this command? If I start the console and I execute your
command, I have not more the possibility of executing the experiment
pingall.

Moreover, I am following the following tutorial, in the Installation section:

You can use these steps to verify your installation:

Issue the command: sudo minindn --experiment=pingall --nPings=50
When the mininet> CLI prompt appears, the experiment has finished. On
the Mini-NDN CLI, issue the command exit to exit the experiment.
Issue the command: grep -c content /tmp/*/ping-data/*.txt. Each file
should report a count of 50.
Issue the command: grep -c timeout /tmp/*/ping-data/*.txt. Each file
should report a count of 0.

I understood why my scenario does not work, but I do not understand
how to run the pingserver on node B and launch the pre-built
experiment in the meantime. Thank you .
Yours Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> ndnpingserver needs to be running on node B. Otherwise, NFD on node
> B will return Nack-NoRoute because /ndn/edu/b/ping doesn't match any
>  FIB entry.
>
> Start ndnpingserver with this command:
> b ndnpingserver /ndn/edu/b &
>
> Yours, Junxiao
>
> -----Original Message-----
> From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> Sent: ?9/?6/?2016 4:49
> To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
> Subject: [Ndn-interest] miniNDN: nack, no route
>
> Good morning NDN community,
> I choose miniNDN to begin my experience, but surely for my poor use of
> the tool, I am obtaining unexpected results.
> I launched the program already written pingAll in a my personal
> topology composed by two nodes connected by a link.
>
> It is a simple scenario, but I have the same following problem with
> the default topology: all the requests are nacked. For example:
> PING /ndn/edu/b
> 20160906T113355.728806 - nack from /ndn/edu/b: seq=7022016325669868656
> time=25.3841 ms reason=NoRoute
> [...]
> 10 packets transmitted, 0 received, 10 nacked, 0% packet loss, 100%
> nacked, time 0 ms
>
> NLSR converged successfully, and the FIB table of A and B seems ok.
> However I wrote them below.
>
> mininet> a nfd-status -b
> FIB:
>    /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>    /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>    /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
>    /localhost/nfd nexthops={faceid=1 (cost=0)}
>    /ndn/edu/b nexthops={faceid=260 (cost=10)}
>    /localhost/nlsr nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>
>
> mininet> b nfd-status -b
> FIB:
>    /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>    /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>    /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>    /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>    /ndn/edu/a nexthops={faceid=260 (cost=10)}
>    /localhost/nfd nexthops={faceid=1 (cost=0)}
>    /localhost/nlsr nexthops={faceid=257 (cost=0)}
>    /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
>    /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>
> Any ideas? Thank you very much
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


_______________________________________________
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/20160906/3c6257ec/attachment.html>

From bertolin at eurecom.fr  Tue Sep  6 06:43:11 2016
From: bertolin at eurecom.fr (bertolin at eurecom.fr)
Date: Tue, 06 Sep 2016 15:43:11 +0200
Subject: [Ndn-interest] miniNDN: nack, no route [solved]
In-Reply-To: <20160906141235.sbp0lh1rcowc8wks@webmail.eurecom.fr>
References: <20160906134840.nwolouws7scwwo80@webmail.eurecom.fr>
	<57ceaee1.d345620a.22573.bd6c@mx.google.com>
	<20160906141235.sbp0lh1rcowc8wks@webmail.eurecom.fr>
Message-ID: <20160906154311.vgqpa1tqrwosocw0@webmail.eurecom.fr>

I solved, thank you for your help!
For other noob like me, just launching minindn with the custom topology, ex.
sudo minindn ./ndn_utils my_topology.conf,
then starting the ndnpingserver with the command suggested by Junxiao
>> b ndnpingserver /ndn/edu/b &, then after some time make the ping from a.
a ndnping -c 4 /ndn/edu/p

I know that my question was not so smart but I am understanding a bit more,
thank you to all.
Matteo

Quoting Matteo Bertolino <Matteo.Bertolino at eurecom.fr>:

> First of all, thank you very much Junxiao.
> I'm shaming about my future question but I have to do it, sorry.
>
> I launch the program from my console in this way:
> sudo minindn --experiment=pingall --nPings=10   
> ./ndn_utils/topologies/try1.conf
> I understand that the pingserver is necessary on B, but in which way I
> can execute this command? If I start the console and I execute your
> command, I have not more the possibility of executing the experiment
> pingall.
>
> Moreover, I am following the following tutorial, in the Installation section:
>
> You can use these steps to verify your installation:
>
> Issue the command: sudo minindn --experiment=pingall --nPings=50
> When the mininet> CLI prompt appears, the experiment has finished. On
> the Mini-NDN CLI, issue the command exit to exit the experiment.
> Issue the command: grep -c content /tmp/*/ping-data/*.txt. Each file
> should report a count of 50.
> Issue the command: grep -c timeout /tmp/*/ping-data/*.txt. Each file
> should report a count of 0.
>
> I understood why my scenario does not work, but I do not understand how
> to run the pingserver on node B and launch the pre-built experiment in
> the meantime. Thank you .
> Yours Matteo
>
> Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:
>
>> Hi Matteo
>>
>> ndnpingserver needs to be running on node B. Otherwise, NFD on node  
>>   B will return Nack-NoRoute because /ndn/edu/b/ping doesn't match   
>> any  FIB entry.
>>
>> Start ndnpingserver with this command:
>> b ndnpingserver /ndn/edu/b &
>>
>> Yours, Junxiao
>>
>> -----Original Message-----
>> From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
>> Sent: ?9/?6/?2016 4:49
>> To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: [Ndn-interest] miniNDN: nack, no route
>>
>> Good morning NDN community,
>> I choose miniNDN to begin my experience, but surely for my poor use of
>> the tool, I am obtaining unexpected results.
>> I launched the program already written pingAll in a my personal
>> topology composed by two nodes connected by a link.
>>
>> It is a simple scenario, but I have the same following problem with
>> the default topology: all the requests are nacked. For example:
>> PING /ndn/edu/b
>> 20160906T113355.728806 - nack from /ndn/edu/b: seq=7022016325669868656
>> time=25.3841 ms reason=NoRoute
>> [...]
>> 10 packets transmitted, 0 received, 10 nacked, 0% packet loss, 100%
>> nacked, time 0 ms
>>
>> NLSR converged successfully, and the FIB table of A and B seems ok.
>> However I wrote them below.
>>
>> mininet> a nfd-status -b
>> FIB:
>>   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>>   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>>   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>>   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>>   /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>>   /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
>>   /localhost/nfd nexthops={faceid=1 (cost=0)}
>>   /ndn/edu/b nexthops={faceid=260 (cost=10)}
>>   /localhost/nlsr nexthops={faceid=257 (cost=0)}
>>   /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
>>
>>
>> mininet> b nfd-status -b
>> FIB:
>>   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>>   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
>>   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
>>   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
>>   /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>>   /ndn/edu/a nexthops={faceid=260 (cost=10)}
>>   /localhost/nfd nexthops={faceid=1 (cost=0)}
>>   /localhost/nlsr nexthops={faceid=257 (cost=0)}
>>   /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
>>   /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
>>
>> Any ideas? Thank you very much
>>
>> -------------------------------------------------------------------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From mrchwdhr at memphis.edu  Tue Sep  6 11:46:00 2016
From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr))
Date: Tue, 6 Sep 2016 18:46:00 +0000
Subject: [Ndn-interest] Fw:  Periodic sync interest
In-Reply-To: <A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>,
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
Message-ID: <BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>

Yes It will be propagated the same way.

After A's neighbors update their LSA's as per A's, they will update their sync digest and respond to their neighbors' sync interest with the updated digest. Now A's neighbor's neighbors know there is a change in the LSDB and they will express interest to fetch the update. This way the change will be propagated throughout the network.


Alvy


Begin forwarded message:

From: Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>>
Subject: Re: [Ndn-interest] Periodic sync interest
Date: September 4, 2016 at 9:29:49 AM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>


Hello,
Can you tell me whenever there is a change in LSA of a node A, it is updated in the neighbors of that node easily as there is periodic sync interest exchanged among the neighbors. Then how this change will be propagated to the neighbors of neighbors of A? In the same way i.e. the neighbors of A replies to the sync interest from its neighbors with the change?

Thank you for your attention.

Regards,
Tanusree Chatterjee

On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Hello,

Can anyone please tell me whether each router sends the periodic sync interests to all other routers in the network or only its direct neighbors? Is it a hop by hop notification when there is any updates? Or the node where the update occurred, floods the update to all other nodes in a data packet?

The sync interests are sent using a multicast strategy, but they should be aggregated when every node has the same sync digest (thus same interest).  So when the network is stable, only one sync interest is sent per link per direction.

Lan
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


__._,_.___
________________________________
Posted by: "Lan Wang (lanwang)" <lanwang at memphis.edu>
________________________________
Reply via web post<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/messages/5222;_ylc=X3oDMTJxNXR1dm90BF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQ3MzE4NjQ5Ng--?act=reply&messageNum=5222>   *       Reply to sender <mailto:lanwang at memphis.edu?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>   *       Reply to group <mailto:NetlabMemphis at yahoogroups.com?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>  *       Start a New Topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/newtopic;_ylc=X3oDMTJmNnYwbWxvBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NzMxODY0OTY->   *       Messages in this topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/topics/5222;_ylc=X3oDMTM1NTk5M3FwBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ3MzE4NjQ5NgR0cGNJZAM1MjIy> (1)
________________________________
[https://s.yimg.com/ru/static/images/yg/img/megaphone/1464031581_phpFA8bON]
Have you tried the highest rated email app?<https://yho.com/1wwmgg>
With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.
________________________________
Visit Your Group<https://groups.yahoo.com/neo/groups/NetlabMemphis/info;_ylc=X3oDMTJmb3M2NjdqBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NzMxODY0OTY->

[Yahoo! Groups]<https://groups.yahoo.com/neo;_ylc=X3oDMTJlY2ZoajIxBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ3MzE4NjQ5Ng-->
* Privacy<https://info.yahoo.com/privacy/us/yahoo/groups/details.html> * Unsubscribe<mailto:NetlabMemphis-unsubscribe at yahoogroups.com?subject=Unsubscribe> * Terms of Use<https://info.yahoo.com/legal/us/yahoo/utos/terms/>

.


__,_._,___
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160906/29ecabd1/attachment.html>

From tnsr.chatterjee at gmail.com  Tue Sep  6 13:29:10 2016
From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee)
Date: Wed, 7 Sep 2016 01:59:10 +0530
Subject: [Ndn-interest] Fw:  Periodic sync interest
In-Reply-To: <BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
Message-ID: <CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>

Thank you for the response.
Whether the forwarding is exactly in the following way?
If say node A finds from LSDB that a data is found at say node F then it
detects the next hop to reach F from routing table and forwards the
interest to that next hop say B. Now, if the data is not found in the CS of
B then again B finds from LSDB where the data can be found and again
detects the next hop from routing table to reach to the data.

Thank you for your attention.

Regards,
Tanusree Chatterjee
On Sep 7, 2016 12:16 AM, "Muktadir R Chowdhury (mrchwdhr)" <
mrchwdhr at memphis.edu> wrote:

> Yes It will be propagated the same way.
>
> After A's neighbors update their LSA's as per A's, they will update their
> sync digest and respond to their neighbors' sync interest with the updated
> digest. Now A's neighbor's neighbors know there is a change in the LSDB and
> they will express interest to fetch the update. This way the change will be
> propagated throughout the network.
>
>
> Alvy
>
>
> Begin forwarded message:
>
> *From: *Tanusree Chatterjee <tnsr.chatterjee at gmail.com>
> *Subject: **Re: [Ndn-interest] Periodic sync interest*
> *Date: *September 4, 2016 at 9:29:49 AM CDT
> *To: *"Lan Wang (lanwang)" <lanwang at memphis.edu>
> *Cc: *ndn-interest at lists.cs.ucla.edu
>
> Hello,
> Can you tell me whenever there is a change in LSA of a node A, it is
> updated in the neighbors of that node easily as there is periodic sync
> interest exchanged among the neighbors. Then how this change will be
> propagated to the neighbors of neighbors of A? In the same way i.e. the
> neighbors of A replies to the sync interest from its neighbors with the
> change?
>
> Thank you for your attention.
>
> Regards,
> Tanusree Chatterjee
> On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
>
>>
>> On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <
>> tnsr.chatterjee at gmail.com> wrote:
>>
>> Hello,
>>
>> Can anyone please tell me whether each router sends the periodic sync
>> interests to all other routers in the network or only its direct neighbors?
>> Is it a hop by hop notification when there is any updates? Or the node
>> where the update occurred, floods the update to all other nodes in a data
>> packet?
>>
>>
>> The sync interests are sent using a multicast strategy, but they should
>> be aggregated when every node has the same sync digest (thus same
>> interest).  So when the network is stable, only one sync interest is sent
>> per link per direction.
>>
>> Lan
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>>
> __._,_.___
> ------------------------------
> Posted by: "Lan Wang (lanwang)" <lanwang at memphis.edu>
> ------------------------------
> Reply via web post
> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/messages/5222;_ylc=X3oDMTJxNXR1dm90BF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQ3MzE4NjQ5Ng--?act=reply&messageNum=5222>
> ? Reply to sender
> <lanwang at memphis.edu?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>
> ? Reply to group
> <NetlabMemphis at yahoogroups.com?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>
> ? Start a New Topic
> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/newtopic;_ylc=X3oDMTJmNnYwbWxvBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NzMxODY0OTY->
> ? Messages in this topic
> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/topics/5222;_ylc=X3oDMTM1NTk5M3FwBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ3MzE4NjQ5NgR0cGNJZAM1MjIy>
> (1)
> ------------------------------
> Have you tried the highest rated email app? <https://yho.com/1wwmgg>
> With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email
> app on the market. What are you waiting for? Now you can access all your
> inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email
> again with 1000GB of free cloud storage.
> ------------------------------
> Visit Your Group
> <https://groups.yahoo.com/neo/groups/NetlabMemphis/info;_ylc=X3oDMTJmb3M2NjdqBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NzMxODY0OTY->
>
>
> [image: Yahoo! Groups]
> <https://groups.yahoo.com/neo;_ylc=X3oDMTJlY2ZoajIxBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ3MzE4NjQ5Ng-->
> ? Privacy <https://info.yahoo.com/privacy/us/yahoo/groups/details.html> ?
> Unsubscribe
> <NetlabMemphis-unsubscribe at yahoogroups.com?subject=Unsubscribe> ? Terms
> of Use <https://info.yahoo.com/legal/us/yahoo/utos/terms/>
>
> .
>
> __,_._,___
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160907/dd81755c/attachment.html>

From bertolin at eurecom.fr  Wed Sep  7 08:11:55 2016
From: bertolin at eurecom.fr (bertolin at eurecom.fr)
Date: Wed, 07 Sep 2016 17:11:55 +0200
Subject: [Ndn-interest] Run an arbitrary program on miniNDN
Message-ID: <20160907171155.mhiffauc08ww88wc@webmail.eurecom.fr>

Good morning to all,
Waiting for my request in miniNDN list, I need to ask an advice to the  
community, using this mailing list.

I successfully installed and tried the ndnPing / ndnPingserver  
commands with miniNDN, and all works. Now, next step. I would like to  
run my personal program in the environment, byt I am having some  
troubles and my poor knowledge does not help me.

I wrote a simple topology composed by two nodes, a and b, connected by  
a link. I've already used this topology for the ping experiment so I  
assume that it is correct.
Now I would like to put in a node the program "producer" already  
written in the section "examples" of ndn-cxx package availaible on the  
git, and the "consumer" on b node.
Both programs are here:  
https://github.com/named-data/ndn-cxx/tree/master/examples

I generated the executable and I was trying to run them into a and b.
The consumer start, it express its interest for the prefix  
/example/testApp/randomData , but after few time the timeout expires.

Making some little changing in the producer, I noticed that it  
successfully enter into Run() function, but it does not enter neither  
in onInterest callback and onRegisterFailed callback.

My suspicious is that the prefix /example/testApp is not registered  
anywhere, because I do not see it into the tables. Indeed:
The FIB table of a is:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=257 (cost=0)}

The FIB table of b is:
   /ndn/NLSR/sync nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /localhost/nfd/rib nexthops={faceid=256 (cost=0)}
   /ndn/NLSR/LSA nexthops={faceid=260 (cost=10)}
   /ndn/broadcast/KEYS nexthops={faceid=257 (cost=0), faceid=260 (cost=10)}
   /ndn/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}
   /ndn/edu/a nexthops={faceid=260 (cost=10)}
   /localhost/nfd nexthops={faceid=1 (cost=0)}
   /localhost/nlsr nexthops={faceid=257 (cost=0)}
   /ndn/edu/%C1.Router/cs/a nexthops={faceid=260 (cost=10)}
   /ndn/NLSR/LSA/edu/%C1.Router/cs/b nexthops={faceid=257 (cost=0)}

So I am getting wrong something I think... any advice ?
Thanks to all,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From lanwang at memphis.edu  Wed Sep  7 14:05:29 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 7 Sep 2016 21:05:29 +0000
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
	<CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
Message-ID: <5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>

Tanusree,

Yes, the forwarding works more or less as you described, except that the nodes use their LSDB to construct their FIB which is used for finding the next hop.  LSDB contains the raw connectivity (topology) information.  Nodes run a shortest path algorithm on the network topology to compute the FIB.

A correction on Alvy?s answer to your previous question: because the Sync name prefix uses a multicast forwarding strategy, there should be a pending Sync interest on every link in each direction, so whenever one node sends a Sync reply, it should be delivered to all the other nodes in the network following the PIT entries (unless a PIT entry doesn?t exist on a particular link for some reason).

Lan

On Sep 6, 2016, at 3:29 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Thank you for the response.
Whether the forwarding is exactly in the following way?
If say node A finds from LSDB that a data is found at say node F then it detects the next hop to reach F from routing table and forwards the interest to that next hop say B. Now, if the data is not found in the CS of B then again B finds from LSDB where the data can be found and again detects the next hop from routing table to reach to the data.

Thank you for your attention.

Regards,
Tanusree Chatterjee

On Sep 7, 2016 12:16 AM, "Muktadir R Chowdhury (mrchwdhr)" <mrchwdhr at memphis.edu<mailto:mrchwdhr at memphis.edu>> wrote:

Yes It will be propagated the same way.

After A's neighbors update their LSA's as per A's, they will update their sync digest and respond to their neighbors' sync interest with the updated digest. Now A's neighbor's neighbors know there is a change in the LSDB and they will express interest to fetch the update. This way the change will be propagated throughout the network.


Alvy


Begin forwarded message:

From: Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>>
Subject: Re: [Ndn-interest] Periodic sync interest
Date: September 4, 2016 at 9:29:49 AM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>


Hello,
Can you tell me whenever there is a change in LSA of a node A, it is updated in the neighbors of that node easily as there is periodic sync interest exchanged among the neighbors. Then how this change will be propagated to the neighbors of neighbors of A? In the same way i.e. the neighbors of A replies to the sync interest from its neighbors with the change?

Thank you for your attention.

Regards,
Tanusree Chatterjee

On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Hello,

Can anyone please tell me whether each router sends the periodic sync interests to all other routers in the network or only its direct neighbors? Is it a hop by hop notification when there is any updates? Or the node where the update occurred, floods the update to all other nodes in a data packet?

The sync interests are sent using a multicast strategy, but they should be aggregated when every node has the same sync digest (thus same interest).  So when the network is stable, only one sync interest is sent per link per direction.

Lan
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


__._,_.___
________________________________
Posted by: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
________________________________
Reply via web post<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/messages/5222;_ylc=X3oDMTJxNXR1dm90BF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQ3MzE4NjQ5Ng--?act=reply&messageNum=5222>   ?       Reply to sender <mailto:lanwang at memphis.edu?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>   ?       Reply to group <mailto:NetlabMemphis at yahoogroups.com?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>  ?       Start a New Topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/newtopic;_ylc=X3oDMTJmNnYwbWxvBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NzMxODY0OTY->   ?       Messages in this topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/topics/5222;_ylc=X3oDMTM1NTk5M3FwBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ3MzE4NjQ5NgR0cGNJZAM1MjIy> (1)
________________________________
[https://s.yimg.com/ru/static/images/yg/img/megaphone/1464031581_phpFA8bON]
Have you tried the highest rated email app?<https://yho.com/1wwmgg>
With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.
________________________________
Visit Your Group<https://groups.yahoo.com/neo/groups/NetlabMemphis/info;_ylc=X3oDMTJmb3M2NjdqBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NzMxODY0OTY->

[Yahoo! Groups]<https://groups.yahoo.com/neo;_ylc=X3oDMTJlY2ZoajIxBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ3MzE4NjQ5Ng-->
? Privacy<https://info.yahoo.com/privacy/us/yahoo/groups/details.html> ? Unsubscribe<mailto:NetlabMemphis-unsubscribe at yahoogroups.com?subject=Unsubscribe> ? Terms of Use<https://info.yahoo.com/legal/us/yahoo/utos/terms/>

.


__,_._,___
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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/20160907/811ee196/attachment.html>

From tnsr.chatterjee at gmail.com  Thu Sep  8 04:47:14 2016
From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee)
Date: Thu, 8 Sep 2016 17:17:14 +0530
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
	<CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
	<5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>
Message-ID: <CAOeyPyTwG_SLfnipCYhc+wEcM9AgvK-uc8ar23nJheJhH9g5fQ@mail.gmail.com>

Lan,

Thanks. The idea is more clear now.
But, whenever one node sends a Sync reply, it should be delivered to all
the other nodes in the network following the PIT entries  But the Sync
interest will be pending from the adjacency nodes only, right? So, whenever
there is any change, the sync reply is sent to all neighbor/adjacency nodes
from where the interest is pending.

Regards,

On Thu, Sep 8, 2016 at 2:35 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> Tanusree,
>
> Yes, the forwarding works more or less as you described, except that the
> nodes use their LSDB to construct their FIB which is used for finding the
> next hop.  LSDB contains the raw connectivity (topology) information.
> Nodes run a shortest path algorithm on the network topology to compute the
> FIB.
>
> A correction on Alvy?s answer to your previous question: because the Sync
> name prefix uses a multicast forwarding strategy, there should be a pending
> Sync interest on every link in each direction, so whenever one node sends a
> Sync reply, it should be delivered to all the other nodes in the network
> following the PIT entries (unless a PIT entry doesn?t exist on a particular
> link for some reason).
>
> Lan
>
> On Sep 6, 2016, at 3:29 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com>
> wrote:
>
> Thank you for the response.
> Whether the forwarding is exactly in the following way?
> If say node A finds from LSDB that a data is found at say node F then it
> detects the next hop to reach F from routing table and forwards the
> interest to that next hop say B. Now, if the data is not found in the CS of
> B then again B finds from LSDB where the data can be found and again
> detects the next hop from routing table to reach to the data.
>
> Thank you for your attention.
>
> Regards,
> Tanusree Chatterjee
> On Sep 7, 2016 12:16 AM, "Muktadir R Chowdhury (mrchwdhr)" <
> mrchwdhr at memphis.edu> wrote:
>
>> Yes It will be propagated the same way.
>>
>> After A's neighbors update their LSA's as per A's, they will update their
>> sync digest and respond to their neighbors' sync interest with the updated
>> digest. Now A's neighbor's neighbors know there is a change in the LSDB and
>> they will express interest to fetch the update. This way the change will be
>> propagated throughout the network.
>>
>>
>> Alvy
>>
>>
>> Begin forwarded message:
>>
>> *From: *Tanusree Chatterjee <tnsr.chatterjee at gmail.com>
>> *Subject: **Re: [Ndn-interest] Periodic sync interest*
>> *Date: *September 4, 2016 at 9:29:49 AM CDT
>> *To: *"Lan Wang (lanwang)" <lanwang at memphis.edu>
>> *Cc: *ndn-interest at lists.cs.ucla.edu
>>
>> Hello,
>> Can you tell me whenever there is a change in LSA of a node A, it is
>> updated in the neighbors of that node easily as there is periodic sync
>> interest exchanged among the neighbors. Then how this change will be
>> propagated to the neighbors of neighbors of A? In the same way i.e. the
>> neighbors of A replies to the sync interest from its neighbors with the
>> change?
>>
>> Thank you for your attention.
>>
>> Regards,
>> Tanusree Chatterjee
>> On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
>> wrote:
>>
>>>
>>> On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <
>>> tnsr.chatterjee at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Can anyone please tell me whether each router sends the periodic sync
>>> interests to all other routers in the network or only its direct neighbors?
>>> Is it a hop by hop notification when there is any updates? Or the node
>>> where the update occurred, floods the update to all other nodes in a data
>>> packet?
>>>
>>>
>>> The sync interests are sent using a multicast strategy, but they should
>>> be aggregated when every node has the same sync digest (thus same
>>> interest).  So when the network is stable, only one sync interest is sent
>>> per link per direction.
>>>
>>> Lan
>>>
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>
>>
>> __._,_.___
>> ------------------------------
>> Posted by: "Lan Wang (lanwang)" <lanwang at memphis.edu>
>> ------------------------------
>> Reply via web post
>> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/messages/5222;_ylc=X3oDMTJxNXR1dm90BF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQ3MzE4NjQ5Ng--?act=reply&messageNum=5222>
>> ? Reply to sender
>> <lanwang at memphis.edu?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>
>> ? Reply to group
>> <NetlabMemphis at yahoogroups.com?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>
>> ? Start a New Topic
>> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/newtopic;_ylc=X3oDMTJmNnYwbWxvBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NzMxODY0OTY->
>> ? Messages in this topic
>> <https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/topics/5222;_ylc=X3oDMTM1NTk5M3FwBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ3MzE4NjQ5NgR0cGNJZAM1MjIy>
>> (1)
>> ------------------------------
>> Have you tried the highest rated email app? <https://yho.com/1wwmgg>
>> With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email
>> app on the market. What are you waiting for? Now you can access all your
>> inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email
>> again with 1000GB of free cloud storage.
>> ------------------------------
>> Visit Your Group
>> <https://groups.yahoo.com/neo/groups/NetlabMemphis/info;_ylc=X3oDMTJmb3M2NjdqBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NzMxODY0OTY->
>>
>>
>> [image: Yahoo! Groups]
>> <https://groups.yahoo.com/neo;_ylc=X3oDMTJlY2ZoajIxBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ3MzE4NjQ5Ng-->
>> ? Privacy <https://info.yahoo.com/privacy/us/yahoo/groups/details.html>
>> ? Unsubscribe
>> <NetlabMemphis-unsubscribe at yahoogroups.com?subject=Unsubscribe> ? Terms
>> of Use <https://info.yahoo.com/legal/us/yahoo/utos/terms/>
>>
>> .
>>
>> __,_._,___
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>


-- 
Tanusree Chatterjee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160908/83912911/attachment.html>

From lanwang at memphis.edu  Thu Sep  8 06:59:08 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 8 Sep 2016 13:59:08 +0000
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <CAOeyPyTwG_SLfnipCYhc+wEcM9AgvK-uc8ar23nJheJhH9g5fQ@mail.gmail.com>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
	<CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
	<5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>
	<CAOeyPyTwG_SLfnipCYhc+wEcM9AgvK-uc8ar23nJheJhH9g5fQ@mail.gmail.com>
Message-ID: <C35F93EF-DEBC-4C92-8AEE-0BF76039575F@memphis.edu>

Tanusree,

The adjacent nodes also have the same interest pending from their neighbors (because the digests are the same when all the LSDBs synchronized before the new change).  So they will also forward the Sync reply based on their PIT entries.  For more information, you can read the ChronoSync paper at http://named-data.net/publications/chronosync/

Lan

On Sep 8, 2016, at 6:47 AM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:

Lan,

Thanks. The idea is more clear now.
But, whenever one node sends a Sync reply, it should be delivered to all the other nodes in the network following the PIT entries  But the Sync interest will be pending from the adjacency nodes only, right? So, whenever there is any change, the sync reply is sent to all neighbor/adjacency nodes from where the interest is pending.

Regards,

On Thu, Sep 8, 2016 at 2:35 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Tanusree,

Yes, the forwarding works more or less as you described, except that the nodes use their LSDB to construct their FIB which is used for finding the next hop.  LSDB contains the raw connectivity (topology) information.  Nodes run a shortest path algorithm on the network topology to compute the FIB.

A correction on Alvy?s answer to your previous question: because the Sync name prefix uses a multicast forwarding strategy, there should be a pending Sync interest on every link in each direction, so whenever one node sends a Sync reply, it should be delivered to all the other nodes in the network following the PIT entries (unless a PIT entry doesn?t exist on a particular link for some reason).

Lan

On Sep 6, 2016, at 3:29 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Thank you for the response.
Whether the forwarding is exactly in the following way?
If say node A finds from LSDB that a data is found at say node F then it detects the next hop to reach F from routing table and forwards the interest to that next hop say B. Now, if the data is not found in the CS of B then again B finds from LSDB where the data can be found and again detects the next hop from routing table to reach to the data.

Thank you for your attention.

Regards,
Tanusree Chatterjee

On Sep 7, 2016 12:16 AM, "Muktadir R Chowdhury (mrchwdhr)" <mrchwdhr at memphis.edu<mailto:mrchwdhr at memphis.edu>> wrote:

Yes It will be propagated the same way.

After A's neighbors update their LSA's as per A's, they will update their sync digest and respond to their neighbors' sync interest with the updated digest. Now A's neighbor's neighbors know there is a change in the LSDB and they will express interest to fetch the update. This way the change will be propagated throughout the network.


Alvy


Begin forwarded message:

From: Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>>
Subject: Re: [Ndn-interest] Periodic sync interest
Date: September 4, 2016 at 9:29:49 AM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>


Hello,
Can you tell me whenever there is a change in LSA of a node A, it is updated in the neighbors of that node easily as there is periodic sync interest exchanged among the neighbors. Then how this change will be propagated to the neighbors of neighbors of A? In the same way i.e. the neighbors of A replies to the sync interest from its neighbors with the change?

Thank you for your attention.

Regards,
Tanusree Chatterjee

On Aug 11, 2016 6:25 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Hello,

Can anyone please tell me whether each router sends the periodic sync interests to all other routers in the network or only its direct neighbors? Is it a hop by hop notification when there is any updates? Or the node where the update occurred, floods the update to all other nodes in a data packet?

The sync interests are sent using a multicast strategy, but they should be aggregated when every node has the same sync digest (thus same interest).  So when the network is stable, only one sync interest is sent per link per direction.

Lan
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


__._,_.___
________________________________
Posted by: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
________________________________
Reply via web post<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/messages/5222;_ylc=X3oDMTJxNXR1dm90BF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQ3MzE4NjQ5Ng--?act=reply&messageNum=5222>   ?       Reply to sender <mailto:lanwang at memphis.edu?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>   ?       Reply to group <mailto:NetlabMemphis at yahoogroups.com?subject=Re%3A%20Fwd%3A%20%5BNdn-interest%5D%20Periodic%20sync%20interest>  ?       Start a New Topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/newtopic;_ylc=X3oDMTJmNnYwbWxvBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0NzMxODY0OTY->   ?       Messages in this topic<https://groups.yahoo.com/neo/groups/NetlabMemphis/conversations/topics/5222;_ylc=X3oDMTM1NTk5M3FwBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRtc2dJZAM1MjIyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ3MzE4NjQ5NgR0cGNJZAM1MjIy> (1)
________________________________
[https://s.yimg.com/ru/static/images/yg/img/megaphone/1464031581_phpFA8bON]
Have you tried the highest rated email app?<https://yho.com/1wwmgg>
With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated email app on the market. What are you waiting for? Now you can access all your inboxes (Gmail, Outlook, AOL and more) in one place. Never delete an email again with 1000GB of free cloud storage.
________________________________
Visit Your Group<https://groups.yahoo.com/neo/groups/NetlabMemphis/info;_ylc=X3oDMTJmb3M2NjdqBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NzMxODY0OTY->

[Yahoo! Groups]<https://groups.yahoo.com/neo;_ylc=X3oDMTJlY2ZoajIxBF9TAzk3MzU5NzE0BGdycElkAzIxMjY3MDI0BGdycHNwSWQDMTcwNTAwNDcyNgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ3MzE4NjQ5Ng-->
? Privacy<https://info.yahoo.com/privacy/us/yahoo/groups/details.html> ? Unsubscribe<mailto:NetlabMemphis-unsubscribe at yahoogroups.com?subject=Unsubscribe> ? Terms of Use<https://info.yahoo.com/legal/us/yahoo/utos/terms/>

.


__,_._,___
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




--
Tanusree Chatterjee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160908/d63ab800/attachment.html>

From tnsr.chatterjee at gmail.com  Thu Sep  8 07:20:49 2016
From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee)
Date: Thu, 8 Sep 2016 19:50:49 +0530
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <C35F93EF-DEBC-4C92-8AEE-0BF76039575F@memphis.edu>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
	<CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
	<5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>
	<CAOeyPyTwG_SLfnipCYhc+wEcM9AgvK-uc8ar23nJheJhH9g5fQ@mail.gmail.com>
	<C35F93EF-DEBC-4C92-8AEE-0BF76039575F@memphis.edu>
Message-ID: <CAOeyPyRQ_Df_CaK=V2g4LzjakWnqt6mkq1AVU6J1HQX9VbXttg@mail.gmail.com>

Whenever forwarding a content/data, Can I specify a particular node next to
whom the packet has to be forwarded, that need not be the destination. Say
from node A a packet has been forwarded to node B with the specification
that B has to forward it to C.

Regards,
Tanusree Chatterjee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160908/0317b4d1/attachment.html>

From lanwang at memphis.edu  Thu Sep  8 07:24:05 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 8 Sep 2016 14:24:05 +0000
Subject: [Ndn-interest] Periodic sync interest
In-Reply-To: <CAOeyPyRQ_Df_CaK=V2g4LzjakWnqt6mkq1AVU6J1HQX9VbXttg@mail.gmail.com>
References: <CAOeyPyQfiNwRBFGJOt3X8kB6xKF+F5NkbxvyP6Wq__PHcsgd4w@mail.gmail.com>
	<A695C208-ABE2-4DA5-8602-87364ECB3AE1@memphis.edu>
	<BY1PR0401MB1628741CE213C20C3BB601FEDAF90@BY1PR0401MB1628.namprd04.prod.outlook.com>
	<CAOeyPyQYosHkAxhh1ySwix1QJX+xur9PnUpaA+xVwL7tjsBHxw@mail.gmail.com>
	<5DE01FD5-D41C-4E7D-84A8-D554F8BE5625@memphis.edu>
	<CAOeyPyTwG_SLfnipCYhc+wEcM9AgvK-uc8ar23nJheJhH9g5fQ@mail.gmail.com>
	<C35F93EF-DEBC-4C92-8AEE-0BF76039575F@memphis.edu>
	<CAOeyPyRQ_Df_CaK=V2g4LzjakWnqt6mkq1AVU6J1HQX9VbXttg@mail.gmail.com>
Message-ID: <EEAFF4B9-8B24-48F2-B753-392235CB4516@memphis.edu>

A cannot tell B how B should forward a packet.  But A can specify a particular local interface for forwarding the packet.

Lan

On Sep 8, 2016, at 9:20 AM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:


Whenever forwarding a content/data, Can I specify a particular node next to whom the packet has to be forwarded, that need not be the destination. Say from node A a packet has been forwarded to node B with the specification that B has to forward it to C.

Regards,
Tanusree Chatterjee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160908/ff20ee75/attachment.html>

From bertolin at eurecom.fr  Mon Sep 12 07:13:37 2016
From: bertolin at eurecom.fr (bertolin at eurecom.fr)
Date: Mon, 12 Sep 2016 16:13:37 +0200
Subject: [Ndn-interest] [ndn-cxx][mini-NDN][General] Printing some
 information
Message-ID: <20160912161337.acd1wlyf7oc80cco@webmail.eurecom.fr>

Good morning at all and thank you again for the help that I am  
receiving by your community.
I spent some time, without success, in trying to print the following  
information (I am working in miniNDN:

1) The Content of the Data.
If I print the packet, I obtain:
Name: /mat/try/normandie/%FC%00%05%3CO%E0%D0%FC%D7
MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds
Content: (size: 6)
Signature: (type: 1, value_length: 256)

So I manage to play with the blocks and the buffers, but the  
documentation is not really verbose. However, I though to write:

	void onData(const Interest& interest, const Data& data) {
		log << "Data received correctly" << std::endl;
		log << data << endl;

		//take block
		ndn::Block x = data.getContent();

		//take buffer
		shared_ptr<const Buffer> buffer = x.getBuffer();

		//take string
		std::string content((char*)buffer.get(), 6);
		log << content << endl;
  	}

But on my log file I obtained just not-printable random characters!  
Where did I wrong?

2) the PIT table of a node. I did not find any with nfd-status and  
other commands. Is it possible in principle ?

3) Finallyh, I would like to concentrate here another question a bit  
different. Working with miniNDN, I would like to build the following  
topology:
Consume <-------> gateway <-------> Producer.
I already wrote my version of consumer and producer, with the callback  
onInterest, onData etc.. But with the gateway, conceptually how should  
I structure the program that works on this node?

Thank you for you help, I say it again it so I will not fill up the  
mailing list with just "thank you" answers :)
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From jburke at remap.UCLA.EDU  Mon Sep 12 09:45:41 2016
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Mon, 12 Sep 2016 16:45:41 +0000
Subject: [Ndn-interest] NDNcomm 2017 - Revised Date and Location
Message-ID: <8A12BAC2-9E5F-4507-913E-11087ACC1470@remap.ucla.edu>


Hi everyone,

We wanted to let you know that we?re going to try something new this year, and have revised our plans to host the next NDNcomm at the University of Memphis NDN project site on March 22-24, 2017, immediately preceding IETF 97 in Chicago.

This alignment with the IETF meeting is more convenient for many abroad who plan to attend, avoids any potential conflict with the US elections (Nov 8), and diversifies the geography of our meetings a bit.

We appreciate your flexibility and look forward to seeing you in Memphis in March!

Best,
Jeff


From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Jeff Burke <jburke at remap.ucla.edu>
Date: Sunday, August 21, 2016 at 12:11 PM
To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] NDNcomm 2016 - Save the Date - November 9-10 @ UCLA

Hi everyone,
NDNcomm 2016 will be held at UCLA from November 9-10, 2016.  (There may be events, like a hackathon, leading up to it on November 8.)  We look forward to seeing you there and will share more details soon!

Best,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160912/c99681c6/attachment.html>

From josh at caida.org  Wed Sep 14 17:06:49 2016
From: josh at caida.org (Josh Polterock)
Date: Wed, 14 Sep 2016 17:06:49 -0700
Subject: [Ndn-interest] Named Data Networking (NDN) Project Newsletter for
 Summer 2016
Message-ID: <20160915000649.GB96444@caida.org>

Named Data Networking (NDN) Project Newsletter for Summer 2016

The NDN project team compiles and publishes this newsletter periodically
to inform the community about recent activities, technical news,
meetings, publications, presentations, code releases, and upcoming
events. You can find these newsletters posted on the Named Data
Networking Project blog.

COMMUNITY OUTREACH

* In August the NDN team released an updated statement regarding
  the team's perspective on IPR and licensing of NDN and related
  ICN technologies. The post includes a discussion of the history
  of IPR and licensing in NDN, as well as the relationship to CCN,
  in response to community questions and in relation to the
  "harmonization" activity in ICNRG.  Please see the updated statement
  on the NDN web site.  https://named-data.net/ipr-aug-2016/

* NDN lead PI Lixia Zhang presented the keynote address at the 11th
  International Conference on Future Internet Technologies: "Looking
  Back, Looking Forward: Why We Need a New Internet Architecture",
  June 2016.
  https://named-data.net/wp-content/uploads/2016/07/looking_back_looking_forward_cfi.pdf

* Coming up later this month, the NDN Team will present a full-day
  tutorial on "Exploring NDN Research through Real World Problem
  Solving" at the 3rd ACM Conference on Information Centric Networking (ICN 2016). 
  http://conferences2.sigcomm.org/acm-icn/2016/tutorial-ndn.php
  See below for additional NDN team papers, posters, and panels at 
  ACM Information Centric Networking (ICN), Sept. 26-28, 2016
  http://conferences2.sigcomm.org/acm-icn/2016/

* Coming up in December 2016, adjacent to IEEE Globecom 2016 at the
  Workshop on Information Centric Networking Solutions for Real
  World Applications (ICNSRA 2016) in Washington D.C., the NDN team
  will present two publications (listed below) as well as participate
  on a panel discussing "Application of ICN in Infrastructure-Free
  Environments: Rural Areas, Disaster Recovery, and Military Tactical
  Environments.  http://icnsra.nz.comm.waseda.ac.jp/?page_id=61

* Save the date: We have revised our plans to host the next NDNComm
  at the University of Memphis March 22-24, 2017 immediately preceding
  IETF 97 in Chicago.  We look forward to seeing you there and will
  share more details as they become available.

TECHNICAL NEWS

* We are pleased to announce the release of version 0.3.0 of
  Named-data Link State Routing Protocol (NLSR). You can find more
  information about NLSR, tutorials, installation and configuration
  guides the official webpage of NLSR: http://named-data.net/doc/NLSR/0.3.0/

NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS

* "NDN-NIC: Name-based Filtering on Network Interface Card",
  by Junxiao Shi, Teng Liang, Hao Wu, Bin Liu, Beichuan Zhang, 
  ACM Information Centric Networking Conference (ICN 2016), September 2016.  
  https://named-data.net/publications/ndn-nic/

* "A Practical Congestion Control Scheme for Named Data Networking",
  by Klaus Schneider, Cheng Yi, Beichuan Zhang, Lixia Zhang, ACM
  Information Centric Networking Conference (ICN 2016), September 2016.
  https://named-data.net/publications/practical_congestion_control_scheme/

* "Sharing mHealth Data via Named Data Networking", 
  by Haitao Zhang, Zhehao Wang, Jeff Burk, Lixia Zhang, 
  ACM Information Centric Networking Conference (ICN 2016), September 2016.
  https://named-data.net/publications/sharing_mhealth_data_ndn/

* ICN 2016 Poster: MicroForwarder.js: an NDN Forwarder Extension for Web Browsers
  by Wentao Shang (UCLA), Jeff Thompson (UCLA).

* ICN 2016 Poster: In-Network Retransmissions in Named Data Networking
  Hila Ben Abraham (Washington University in St. Louis), Patrick
  Crowley (Washington University in St. Louis).

* ICN 2016 Panel: Five Years Later: Critical research challenges
  in ICN five years after the first ACM ICN workshop.  Bengt Ahlgren
  (SICS), Giovanna Carofiglio (Cisco), Toru Hasegawa (Osaka
  University), Marc Mosko (PARC), Christian Tschudin +(University
  of Basel), Lixia Zhang (UCLA)

* "Real-time streaming data delivery over Named Data Networking", 
  by Peter Gusev, Zhehao Wang, Jeff Burke, Lixia Zhang, 
  Eiichi Muramoto, Ryota Ohnishi, and Takahiro Yoneda.  
  Institute of Electronics, Information and Communication Engeineers (IEICE) 
  Transactions on Communication, May 2016.
  http://named-data.net/publications/realtime_streaming_data_delivery_ndn/

* "The Design and Implementation of the NDN Protocol Stack for RIOT-OS", 
  by Wentao Shang, Alexander Afanasyev, and Lixia Zhang, 
  IEEE GLOBECOM 2016 Information Centric Networking Solutions for Real
  World Applications (ICNSRA 2016), to appear December 2016.
  https://named-data.net/publications/design_implementation_ndn_protocol/

* "Supporting Multi-dimensional Naming for NDN Applications",
  by Shuai Gao and Hongke Zhang, Beichuan Zhang, GLOBECOM Workshop
  on Information Centric Networking Solutions for Real World
  Applications (ICNSRA 2016), to appear December 2016.

* "Content-Based Security for the Web",
  by Yingdi Yu, Daniel Zappala, Lixia Zhang, Alexander Afanasyev,
  J. Alex Halderman, Scott Ruoti, and Kent Seamons, ACM New Security
  Paradigms Workshop (NSPW), to appear September 2016.

* "An Experimental Investigation of Hyperbolic Routing with a Smart
  Forwarding Plane in NDN", by Vince Lehman, Ashlesh Gawande, Rodrigo
  Aldecoa, Dmitri Krioukov, Beichuan Zhang, Lixia Zhang, and Lan
  Wang, IEEE/ACM International Workshop on Quality of Service
  (IWQoS), June 2016.
  http://named-data.net/publications/experimental_investigation_hyperbolic_routing/
  Extended by TR NDN-0042 (below)

* "Improving the Freshness of NDN Forwarding States",
  by Jianxun Cao, Dan Pei, Zhelun Wu, Xiaoping Zhang, Beichuan
  Zhang, Lan Wang, and Youjian Zhao, IFIP Networking Conference and
  Workshops, May 2016.
  https://named-data.net/publications/improving_freshness_ndn/

*  NDN TR-40 Revision 1: "NDN DeLorean: An Authentication System
   for Data Archives in Named Data Networking", by Yingdi Yu,
   Alexander Afanasyev, Lixia Zhang, Named Data Networking Technical
   Report, May 24, 2016
   http://named-data.net/publications/techreports/ndn-0040-1-delorean/

*  NDN TR-41 Revision 1: "Hop-By-Hop Best Effort Link Layer Reliability
   in Named Data Networking", by Satyanarayana Vusirikala, Spyridon
   Mastorakis, Alexander Afanasyev, Lixia Zhang Named Data Networking
   Technical Report, August 26, 2016
   https://named-data.net/publications/techreports/ndn-0041-1-hop-by-hop-link-reliability/

*  NDN TR-42 Revision 1:"An Experimental Investigation of Hyperbolic
   Routing with a Smart Forwarding Plane in NDN", by Vince Lehman,
   Ashlesh Gawande, Rodrigo Aldecoa, Dmitri Krioukov, Beichuan
   Zhang, Lixia Zhang, and Lan Wang, Named Data Networking Technical
   Report, July 6, 2016
   https://named-data.net/publications/techreports/ndn-0042-1-asf/

SEMINARS

* The NDN seminars are internally focused. If you would like to
  participate in the NDN Seminars, please contact the PoC, UCLA
  PhD. candidate Spyridon Mastorakis <Spiros.mastorakis at gmail.com>
  for the most up-to-date information regarding upcoming seminars.

   - 2 June 2016 Klaus Schneider (University of Arizona), "Practical Congestion Control for NDN"

For more information about the Named Data Networking (NDN) Project
please visit http://www.named-data.net/.




From Matteo.Bertolino at eurecom.fr  Tue Sep 20 06:41:09 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 20 Sep 2016 15:41:09 +0200
Subject: [Ndn-interest] Problem with Interest and Data structure in c++
Message-ID: <20160920154109.fmvn45dfj4kwwogo@webmail.eurecom.fr>

Good morning to all,
I write in order to ask your help with a problem.
I would like to do a Map <Interest, int>.

So I wrote:
std::map<Interest, int> myMap;
but each operation on it fails, like:
int numbEntries = mappa.count(nack.getInterest());
or
std::map<Interest,int>::iterator it = mappa.find (nack.getInterest());
or
Interest x: mappa[x] = 5;

The error is always the same:
/usr/include/c++/4.9/bits/stl_function.h:371:20: error: no match for  
?operator<? (operand types are ?const ndn::Interest? and ?const  
ndn::Interest?)
        { return __x < __y; }

Then I think to redefine operator "<" into interest.cpp, writing:
bool
   operator<(const ndn::Interest ones, const ndn::Interest other)
   {
     return ones.getName().compare(other.getName())<0;
   }

But, also here, no effect.
Any idea?
Thank you,
Matteo


-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From aa at CS.UCLA.EDU  Tue Sep 20 07:16:51 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 20 Sep 2016 10:16:51 -0400
Subject: [Ndn-interest] Problem with Interest and Data structure in c++
In-Reply-To: <20160920154109.fmvn45dfj4kwwogo@webmail.eurecom.fr>
References: <20160920154109.fmvn45dfj4kwwogo@webmail.eurecom.fr>
Message-ID: <E8B784CB-3B46-408D-8A3B-E9ECE48285EB@cs.ucla.edu>


> On Sep 20, 2016, at 9:41 AM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr> wrote:
> 
> Good morning to all,
> I write in order to ask your help with a problem.
> I would like to do a Map <Interest, int>.
> 
> So I wrote:
> std::map<Interest, int> myMap;
> but each operation on it fails, like:
> int numbEntries = mappa.count(nack.getInterest());
> or
> std::map<Interest,int>::iterator it = mappa.find (nack.getInterest());
> or
> Interest x: mappa[x] = 5;
> 
> The error is always the same:
> /usr/include/c++/4.9/bits/stl_function.h:371:20: error: no match for ?operator<? (operand types are ?const ndn::Interest? and ?const ndn::Interest?)
>       { return __x < __y; }
> 
> Then I think to redefine operator "<" into interest.cpp, writing:
> bool
>  operator<(const ndn::Interest ones, const ndn::Interest other)
>  {
>    return ones.getName().compare(other.getName())<0;
>  }

For C++ to find the method, you need to define this operator in the same namespace as Interest, e.g.,

namespace ndn {

bool
operator<(const Interest& i1, const Interest& i2)
{
    ... // you may need to include additional comparisons in addition to checking names
}

}

---
Alex

> But, also here, no effect.
> Any idea?
> Thank you,
> Matteo
> 
> 
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
> 
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160920/6f223534/attachment.bin>

From Matteo.Bertolino at eurecom.fr  Tue Sep 20 07:25:41 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 20 Sep 2016 16:25:41 +0200
Subject: [Ndn-interest] Problem with Interest and Data structure in c++
In-Reply-To: <E8B784CB-3B46-408D-8A3B-E9ECE48285EB@cs.ucla.edu>
References: <20160920154109.fmvn45dfj4kwwogo@webmail.eurecom.fr>
	<E8B784CB-3B46-408D-8A3B-E9ECE48285EB@cs.ucla.edu>
Message-ID: <20160920162541.9plpws7w0sow8kwk@webmail.eurecom.fr>

Thank you for the advice!
If somebody had a similar problem, here there is my solution:

struct cmpInterests {
     bool operator()(const Interest& a, const Interest& b) const {
         return a.getName().compare(b.getName());
     }
};
std::map<Interest, int, cmpInterests> mappa;

I do not know if it is suitable for my purposes, but at least the  
compilation errors are solved.

Sincerely,
Matteo


Quoting Alex Afanasyev <aa at cs.ucla.edu>:

>
>> On Sep 20, 2016, at 9:41 AM, Matteo Bertolino   
>> <Matteo.Bertolino at eurecom.fr> wrote:
>>
>> Good morning to all,
>> I write in order to ask your help with a problem.
>> I would like to do a Map <Interest, int>.
>>
>> So I wrote:
>> std::map<Interest, int> mappa;
>> but each operation on it fails, like:
>> int numbEntries = mappa.count(nack.getInterest());
>> or
>> std::map<Interest,int>::iterator it = mappa.find (nack.getInterest());
>> or
>> Interest x: mappa[x] = 5;
>>
>> The error is always the same:
>> /usr/include/c++/4.9/bits/stl_function.h:371:20: error: no match  
>> for ?operator<? (operand types are ?const ndn::Interest? and ?const  
>> ndn::Interest?)
>>       { return __x < __y; }
>>
>> Then I think to redefine operator "<" into interest.cpp, writing:
>> bool
>>  operator<(const ndn::Interest ones, const ndn::Interest other)
>>  {
>>    return ones.getName().compare(other.getName())<0;
>>  }
>
> For C++ to find the method, you need to define this operator in the   
> same namespace as Interest, e.g.,
>
> namespace ndn {
>
> bool
> operator<(const Interest& i1, const Interest& i2)
> {
>     ... // you may need to include additional comparisons in   
> addition to checking names
> }
>
> }
>
> ---
> Alex
>
>> But, also here, no effect.
>> Any idea?
>> Thank you,
>> Matteo
>>
>>
>> -------------------------------------------------------------------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From wentaoshang at ucla.edu  Tue Sep 20 08:48:55 2016
From: wentaoshang at ucla.edu (Wentao Shang)
Date: Tue, 20 Sep 2016 08:48:55 -0700
Subject: [Ndn-interest] Fwd: ACM TCPS Special Issue on Dependability in
 Cyber Physical Systems and Applications
References: <5873-275804671.1474378207958.JavaMail.ORANGE$@ORANGE>
Message-ID: <500700C6-6F31-4727-BEEE-AE1DD54050EE@ucla.edu>



> Begin forwarded message:
> 
> From: "Tei-Wei Kuo" <pubs at acm.org>
> Subject: ACM TCPS Special Issue on Dependability in Cyber Physical Systems and Applications
> Date: September 20, 2016 at 6:30:04 AM PDT
> To: wentao at CS.UCLA.EDU
> 
>  <http://orange.hosting.lsoft.com/trk/click?ref=znwrbbrs9_6-112e9x3bda9x09488&>CALL FOR PAPERS
> 
> ACM Transactions on
> Cyber-Physical Systems (TCPS)
> Special Issue on Dependability in Cyber Physical Systems and Applications
> 
> Guest Editors
> Md Zakirul Alam Bhuiyan, Fordham University, USA
> Sy-Yen Kuo, National Taiwan University, Taiwan
> Damian Lyons, Fordham University, USA
> Zili Shao, The Hong Kong Polytechnic University, Hong Kong
> 
> Introduction
> 
> Cyber-Physical Systems (CPS) is a speedily emerging area that will cover every aspect of life in the near future. Semiconductors and the Internet have revolutionized and transformed our lives and how we interact with information, which has in turn led to the growth of information technology. Today we are in a CPS paradigm that will transform the way we interact with, and manipulate, physical systems. CPS represents a bold new generation of systems that integrates computing and communication capabilities with the dynamics of physical and engineered systems. Vast major investments are being made worldwide in developing this technology and its impact on the economy and social structure has yet to be realized. No matter how integrated cyber-physical worlds are to develop, there is no doubt that they must be "dependable".
> 
> Increasingly, individuals, practitioners, and organizations have begun to develop or procure sophisticated CPS in whose dependability of services they must have great confidence. Future CPS systems need to close the dependability gap in the face of challenges in different circumstances and services, e.g., continuity, effective performance, real-time responsiveness, ability to overcome data fault/corruption/anomaly, ability to avoid catastrophic failures, prevention of deliberate privacy intrusions, reliability/availability/sustainability/adaptability/heterogeneity/security/safety, and so on. Therefore, we have a wide open area of research to explore and exploit the challenges and immense opportunities in this dependable CPS arena.
> 
> Scope
> 
> This special issue focuses on bringing together current research ideas and techniques from researchers and practitioners belonging to a myriad of research areas, with the final goal of sharing their specific challenges and solutions for CPS dependability. More specifically, contributions related to dependability aspects of CPS applications/systems in practice are of interest. The scope for this special issue includes but is not limited to the following list:
> Theoretical foundations of dependability in controlling/managing/monitoring in CPS
> Architectural framework and design methodologies for dependable CPS
> Dependable software platforms for managing CPS
> Dependability issues in Big Data analytics for CPS
> Dependability issues in Cloud-assisted CPS
> Dependability issues in sensor network protocols for CPS
> Fault models and fault tolerances in both cyber and physical subsystems
> HCI models and HCI system failure and recovery
> Cyber security, privacy, safety, availability/reliability issues in distributed CPS and applications
> Dependability issues in CPS applications (including robotics, autonomous vehicles, manufacturing, transportation, smart energy, smart civil infrastructure, and healthcare)
> Dependability measurement, modeling, evaluation, and tools for CPS
> 
> Evaluation Criteria
> 
> All papers submitted to this special issue will be evaluated according to relevance, novelty, and new contributions. Particularly, the paper must show enough evidence of contributions to CPS applications/systems in practice.
> 
> Schedule
> Manuscript submission due:	March 15, 2017
> First-round pass notification:	April 15, 2017
> First round of reviews complete:	August 15, 2017
> Second round of reviews complete:	October 15, 2017
> Final notification:	November 15, 2017
> Target publication:	2017/2018
> For further information, please contact SI.Dependable.CPS at gmail.com <mailto:SI.Dependable.CPS at gmail.com>.
> 
> If you do not want to receive future emails about publishing in ACM journals,
> send an email to mktg2 at hq.acm.org <mailto:mktg2 at hq.acm.org> with "UNSUBSCRIBE" in the subject.
> 
> Association for Computing Machinery, Two Penn Plaza, Suite 701, New York, NY 10121-0701, USA
> Copyright 2016, ACM, Inc.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160920/814979d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160920/814979d6/attachment.bin>

From mhasabet at gmail.com  Tue Sep 20 14:57:11 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Wed, 21 Sep 2016 02:27:11 +0430
Subject: [Ndn-interest] Forwarding states impact on FIB
Message-ID: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>

Hi everyone,

Regarding face colors(GREEN, YELLOW and RED) and their impact on *routing, *I
wonder if there is any relation between those two. I know colors are taken
into account by forwarding plane while FIB entries are taken care of by
routing plane. My question is: If a face remains RED for a period, is it
going to be an update in FIB with regard to delete that face from its
associated entry? Since updating FIB typically comes from RIB, then I guess
for such an update routing protocol should decide.

Thanks,
Sabet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160921/70fd5d46/attachment.html>

From lanwang at memphis.edu  Tue Sep 20 18:38:44 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 21 Sep 2016 01:38:44 +0000
Subject: [Ndn-interest] Forwarding states impact on FIB
In-Reply-To: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
References: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
Message-ID: <8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>

Sabet,

The answer depends on the routing protocol.  I assume RED means the link corresponding to the face is physically down.  A typical dynamic routing protocol is likely to remove that face from the associated entry after the face remains RED for a period.  But a static routing protocol that doesn?t react to link failures will not.

Lan

On Sep 20, 2016, at 5:57 PM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:

Hi everyone,

Regarding face colors(GREEN, YELLOW and RED) and their impact on routing, I wonder if there is any relation between those two. I know colors are taken into account by forwarding plane while FIB entries are taken care of by routing plane. My question is: If a face remains RED for a period, is it going to be an update in FIB with regard to delete that face from its associated entry? Since updating FIB typically comes from RIB, then I guess for such an update routing protocol should decide.

Thanks,
Sabet

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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/20160921/01529892/attachment.html>

From mhasabet at gmail.com  Tue Sep 20 21:17:37 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Wed, 21 Sep 2016 08:47:37 +0430
Subject: [Ndn-interest] Forwarding states impact on FIB
In-Reply-To: <8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>
References: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
	<8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>
Message-ID: <CADQ0MFaJ_omHARDpUwEoOT4hvEnSj12S1woUzNrngeJMh4bfTg@mail.gmail.com>

Lan,

Thanks. Taking NLSR as an example, how does it react to link failure
technically? I'm not much of familiar with nlsr api and don't know what to
look for.

Regards,
Sabet

On 21 Sep 2016 5:08 am, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:

> Sabet,
>
> The answer depends on the routing protocol.  I assume RED means the link
> corresponding to the face is physically down.  A typical dynamic routing
> protocol is likely to remove that face from the associated entry after the
> face remains RED for a period.  But a static routing protocol that doesn?t
> react to link failures will not.
>
> Lan
>
> On Sep 20, 2016, at 5:57 PM, Muhammad Hosain Abdollahi Sabet <
> mhasabet at gmail.com> wrote:
>
> Hi everyone,
>
> Regarding face colors(GREEN, YELLOW and RED) and their impact on *routing,
> *I wonder if there is any relation between those two. I know colors are
> taken into account by forwarding plane while FIB entries are taken care of
> by routing plane. My question is: If a face remains RED for a period, is it
> going to be an update in FIB with regard to delete that face from its
> associated entry? Since updating FIB typically comes from RIB, then I guess
> for such an update routing protocol should decide.
>
> Thanks,
> Sabet
>
> _______________________________________________
> 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/20160921/22bbf4da/attachment.html>

From lanwang at memphis.edu  Wed Sep 21 10:18:06 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 21 Sep 2016 17:18:06 +0000
Subject: [Ndn-interest] Forwarding states impact on FIB
In-Reply-To: <CADQ0MFaJ_omHARDpUwEoOT4hvEnSj12S1woUzNrngeJMh4bfTg@mail.gmail.com>
References: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
	<8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>
	<CADQ0MFaJ_omHARDpUwEoOT4hvEnSj12S1woUzNrngeJMh4bfTg@mail.gmail.com>
Message-ID: <D4268B05-8054-4EF0-B64E-FF6FABE5300F@memphis.edu>

Sabet,

NLSR subscribes to face change events.  If a face goes down, the node with this face will generate a new adjacency LSA and every node recomputes their routes using this information.

Lan

On Sep 21, 2016, at 12:17 AM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:


Lan,

Thanks. Taking NLSR as an example, how does it react to link failure technically? I'm not much of familiar with nlsr api and don't know what to look for.

Regards,
Sabet

On 21 Sep 2016 5:08 am, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Sabet,

The answer depends on the routing protocol.  I assume RED means the link corresponding to the face is physically down.  A typical dynamic routing protocol is likely to remove that face from the associated entry after the face remains RED for a period.  But a static routing protocol that doesn?t react to link failures will not.

Lan

On Sep 20, 2016, at 5:57 PM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:

Hi everyone,

Regarding face colors(GREEN, YELLOW and RED) and their impact on routing, I wonder if there is any relation between those two. I know colors are taken into account by forwarding plane while FIB entries are taken care of by routing plane. My question is: If a face remains RED for a period, is it going to be an update in FIB with regard to delete that face from its associated entry? Since updating FIB typically comes from RIB, then I guess for such an update routing protocol should decide.

Thanks,
Sabet

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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/20160921/d24595cf/attachment.html>

From mhasabet at gmail.com  Wed Sep 21 11:32:40 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Wed, 21 Sep 2016 23:02:40 +0430
Subject: [Ndn-interest] Forwarding states impact on FIB
In-Reply-To: <D4268B05-8054-4EF0-B64E-FF6FABE5300F@memphis.edu>
References: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
	<8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>
	<CADQ0MFaJ_omHARDpUwEoOT4hvEnSj12S1woUzNrngeJMh4bfTg@mail.gmail.com>
	<D4268B05-8054-4EF0-B64E-FF6FABE5300F@memphis.edu>
Message-ID: <CADQ0MFZN3nJcpF7cFFM6MKmQMkgJG_VfcN5g+-wR3sNKAxX4pg@mail.gmail.com>

Lan,

Thanks! So if a face goes down, nlsr first updates local FIB, then it will
advertise new LSA, right? Is there api documentation (e.g. doxygen) for
nlsr? Or some document similar to nfd developer guide? I'm want to see how
nlsr cooperates with nfd.

Bests,
On Sep 21, 2016 8:48 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:

> Sabet,
>
> NLSR subscribes to face change events.  If a face goes down, the node with
> this face will generate a new adjacency LSA and every node recomputes their
> routes using this information.
>
> Lan
>
> On Sep 21, 2016, at 12:17 AM, Muhammad Hosain Abdollahi Sabet <
> mhasabet at gmail.com> wrote:
>
> Lan,
>
> Thanks. Taking NLSR as an example, how does it react to link failure
> technically? I'm not much of familiar with nlsr api and don't know what to
> look for.
>
> Regards,
> Sabet
>
> On 21 Sep 2016 5:08 am, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
>
>> Sabet,
>>
>> The answer depends on the routing protocol.  I assume RED means the link
>> corresponding to the face is physically down.  A typical dynamic routing
>> protocol is likely to remove that face from the associated entry after the
>> face remains RED for a period.  But a static routing protocol that doesn?t
>> react to link failures will not.
>>
>> Lan
>>
>> On Sep 20, 2016, at 5:57 PM, Muhammad Hosain Abdollahi Sabet <
>> mhasabet at gmail.com> wrote:
>>
>> Hi everyone,
>>
>> Regarding face colors(GREEN, YELLOW and RED) and their impact on *routing,
>> *I wonder if there is any relation between those two. I know colors are
>> taken into account by forwarding plane while FIB entries are taken care of
>> by routing plane. My question is: If a face remains RED for a period, is it
>> going to be an update in FIB with regard to delete that face from its
>> associated entry? Since updating FIB typically comes from RIB, then I guess
>> for such an update routing protocol should decide.
>>
>> Thanks,
>> Sabet
>>
>> _______________________________________________
>> 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/20160921/cc3306fd/attachment.html>

From lanwang at memphis.edu  Wed Sep 21 13:23:10 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 21 Sep 2016 20:23:10 +0000
Subject: [Ndn-interest] Forwarding states impact on FIB
In-Reply-To: <CADQ0MFZN3nJcpF7cFFM6MKmQMkgJG_VfcN5g+-wR3sNKAxX4pg@mail.gmail.com>
References: <CADQ0MFZZJ6-GHsoGfyp7=JOpv9W73R5_GBYYP2uc_j7+Yvr8_w@mail.gmail.com>
	<8B5EA804-6847-41DE-93B7-7D0688C1D578@memphis.edu>
	<CADQ0MFaJ_omHARDpUwEoOT4hvEnSj12S1woUzNrngeJMh4bfTg@mail.gmail.com>
	<D4268B05-8054-4EF0-B64E-FF6FABE5300F@memphis.edu>
	<CADQ0MFZN3nJcpF7cFFM6MKmQMkgJG_VfcN5g+-wR3sNKAxX4pg@mail.gmail.com>
Message-ID: <D103BF0B-9654-4C1D-88DC-DCA62225B846@memphis.edu>



On Sep 21, 2016, at 2:32 PM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:


Lan,

Thanks! So if a face goes down, nlsr first updates local FIB, then it will advertise new LSA, right?

Yes.

Is there api documentation (e.g. doxygen) for nlsr? Or some document similar to nfd developer guide? I'm want to see how nlsr cooperates with nfd.

The NLSR developers? guide is at https://netwisdom.cs.memphis.edu/gitlab/vslehman/nlsr-docs/blob/master/nlsr-docs.pdf

We have an NLSR mailing list.  If you are interested, you can subscribe to the list (see the last one on https://named-data.net/codebase/platform/support/mailing-lists/).

Lan

Bests,

On Sep 21, 2016 8:48 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Sabet,

NLSR subscribes to face change events.  If a face goes down, the node with this face will generate a new adjacency LSA and every node recomputes their routes using this information.

Lan

On Sep 21, 2016, at 12:17 AM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:


Lan,

Thanks. Taking NLSR as an example, how does it react to link failure technically? I'm not much of familiar with nlsr api and don't know what to look for.

Regards,
Sabet

On 21 Sep 2016 5:08 am, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Sabet,

The answer depends on the routing protocol.  I assume RED means the link corresponding to the face is physically down.  A typical dynamic routing protocol is likely to remove that face from the associated entry after the face remains RED for a period.  But a static routing protocol that doesn?t react to link failures will not.

Lan

On Sep 20, 2016, at 5:57 PM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:

Hi everyone,

Regarding face colors(GREEN, YELLOW and RED) and their impact on routing, I wonder if there is any relation between those two. I know colors are taken into account by forwarding plane while FIB entries are taken care of by routing plane. My question is: If a face remains RED for a period, is it going to be an update in FIB with regard to delete that face from its associated entry? Since updating FIB typically comes from RIB, then I guess for such an update routing protocol should decide.

Thanks,
Sabet

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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/20160921/2f280189/attachment.html>

From malhowaidi at gmail.com  Wed Sep 21 20:09:39 2016
From: malhowaidi at gmail.com (Mohammad Alhowaidi)
Date: Wed, 21 Sep 2016 22:09:39 -0500
Subject: [Ndn-interest] Compiling ndncatchunk without waf
Message-ID: <CAOYiq11Yb4BL2W5vZwVwQ+s0V3XDzYhjLCaDPbDPgjwFej==Dw@mail.gmail.com>

Hello,

I am using the ndncatchunk/ndnputchunk from the ndn-tools. I am wondering
how to compile this code alone without using ./waf. For example by using
g++/gcc .. etc.
Could you please help in that as I am not familiar with using waf and I
need to include this code in my work?!

Thanks,
Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160921/f07d1219/attachment.html>

From agawande at memphis.edu  Thu Sep 22 08:02:59 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Thu, 22 Sep 2016 15:02:59 +0000
Subject: [Ndn-interest] Compiling ndncatchunk without waf
In-Reply-To: <CAOYiq11Yb4BL2W5vZwVwQ+s0V3XDzYhjLCaDPbDPgjwFej==Dw@mail.gmail.com>
References: <CAOYiq11Yb4BL2W5vZwVwQ+s0V3XDzYhjLCaDPbDPgjwFej==Dw@mail.gmail.com>
Message-ID: <SN2PR04MB2205165EBD085A68D0E20195D9C90@SN2PR04MB2205.namprd04.prod.outlook.com>

Use ./waf -v to print the g++ commands being used.


Ashlesh

________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Mohammad Alhowaidi <malhowaidi at gmail.com>
Sent: Wednesday, September 21, 2016 10:09:39 PM
To: ndn-interest at lists.cs.ucla.edu
Subject: [Ndn-interest] Compiling ndncatchunk without waf

Hello,

I am using the ndncatchunk/ndnputchunk from the ndn-tools. I am wondering how to compile this code alone without using ./waf. For example by using g++/gcc .. etc.
Could you please help in that as I am not familiar with using waf and I need to include this code in my work?!

Thanks,
Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160922/d873af34/attachment.html>

From malhowaidi at gmail.com  Thu Sep 22 09:26:48 2016
From: malhowaidi at gmail.com (Mohammad Alhowaidi)
Date: Thu, 22 Sep 2016 11:26:48 -0500
Subject: [Ndn-interest] Compiling ndncatchunk without waf
In-Reply-To: <SN2PR04MB2205165EBD085A68D0E20195D9C90@SN2PR04MB2205.namprd04.prod.outlook.com>
References: <CAOYiq11Yb4BL2W5vZwVwQ+s0V3XDzYhjLCaDPbDPgjwFej==Dw@mail.gmail.com>
	<SN2PR04MB2205165EBD085A68D0E20195D9C90@SN2PR04MB2205.namprd04.prod.outlook.com>
Message-ID: <CAOYiq116Mex4fCm9S_sWHK5HC=gLuNZK5Spx940FXd1MDgHPvg@mail.gmail.com>

Thank you!

Also, I was wondering if there is a *cmake* version of the waf!

Thanks,
Mohammad


On Thu, Sep 22, 2016 at 10:02 AM, Ashlesh Gawande (agawande) <
agawande at memphis.edu> wrote:

> Use ./waf -v to print the g++ commands being used.
>
>
> Ashlesh
> ------------------------------
> *From:* Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf
> of Mohammad Alhowaidi <malhowaidi at gmail.com>
> *Sent:* Wednesday, September 21, 2016 10:09:39 PM
> *To:* ndn-interest at lists.cs.ucla.edu
> *Subject:* [Ndn-interest] Compiling ndncatchunk without waf
>
> Hello,
>
> I am using the ndncatchunk/ndnputchunk from the ndn-tools. I am wondering
> how to compile this code alone without using ./waf. For example by using
> g++/gcc .. etc.
> Could you please help in that as I am not familiar with using waf and I
> need to include this code in my work?!
>
> Thanks,
> Mohammad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160922/efdb974d/attachment.html>

From aa at CS.UCLA.EDU  Thu Sep 22 12:24:07 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 22 Sep 2016 12:24:07 -0700
Subject: [Ndn-interest] Compiling ndncatchunk without waf
In-Reply-To: <CAOYiq116Mex4fCm9S_sWHK5HC=gLuNZK5Spx940FXd1MDgHPvg@mail.gmail.com>
References: <CAOYiq11Yb4BL2W5vZwVwQ+s0V3XDzYhjLCaDPbDPgjwFej==Dw@mail.gmail.com>
	<SN2PR04MB2205165EBD085A68D0E20195D9C90@SN2PR04MB2205.namprd04.prod.outlook.com>
	<CAOYiq116Mex4fCm9S_sWHK5HC=gLuNZK5Spx940FXd1MDgHPvg@mail.gmail.com>
Message-ID: <5DA4E184-BF45-41F1-B651-D71E07EF083A@cs.ucla.edu>

You can take a look at https://github.com/cawka/ndn-skeleton-apps <https://github.com/cawka/ndn-skeleton-apps> skeleton code.

> On Sep 22, 2016, at 9:26 AM, Mohammad Alhowaidi <malhowaidi at gmail.com> wrote:
> 
> Thank you!
> 
> Also, I was wondering if there is a cmake version of the waf!
> 
> Thanks,
> Mohammad
> 
> 
> On Thu, Sep 22, 2016 at 10:02 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu <mailto:agawande at memphis.edu>> wrote:
> Use ./waf -v to print the g++ commands being used.
> 
> 
> Ashlesh
> 
> From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu <mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of Mohammad Alhowaidi <malhowaidi at gmail.com <mailto:malhowaidi at gmail.com>>
> Sent: Wednesday, September 21, 2016 10:09:39 PM
> To: ndn-interest at lists.cs.ucla.edu <mailto:ndn-interest at lists.cs.ucla.edu>
> Subject: [Ndn-interest] Compiling ndncatchunk without waf
> 
> Hello,
> 
> I am using the ndncatchunk/ndnputchunk from the ndn-tools. I am wondering how to compile this code alone without using ./waf. For example by using g++/gcc .. etc.
> Could you please help in that as I am not familiar with using waf and I need to include this code in my work?!
> 
> Thanks,
> Mohammad
> 
> _______________________________________________
> 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/20160922/0b7f33c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160922/0b7f33c0/attachment.bin>

From Matteo.Bertolino at eurecom.fr  Fri Sep 23 06:08:13 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 23 Sep 2016 15:08:13 +0200
Subject: [Ndn-interest] Mobility support on technical report + Signature
	infrastructure	NDN
Message-ID: <20160923150813.7akgdin9wo4s88ko@webmail.eurecom.fr>

Good morning, I would like to ask you a thing about mobility support  
and one about the signature mechanism.

1) I am reading the paragraph about the mobility support during the  
forwarding of an interest in the NFD Developer guide:  
https://named-data.net/wp-content/uploads/2016/03/ndn-0021-6-nfd-developer-guide.pdf
Paragraph 4.2.3. I need to clarify some aspects because I do not  
understand well the process described in this paragraph:

"If the Interest carries a Link object, it is processed for mobility support.
First, the pipeline determines whether the Interest has reached the  
producer region, by checking if any delegation name
in the Link object is a prefix of any region name from the network  
region table (Section 3.2). If so, FIB lookup is
performed using Interest Name, as if the Link object does not exist.
Second, the pipeline inspects whether the Interest contains the  
SelectedDelegation field, which indicates that a down-
stream forwarder has chosen which delegation to use. If so, it implies  
that the Interest is already in default-free zone,
FIB lookup is performed using the selected delegation name.
Third, the pipeline determines whether the Interest is in the consumer  
region or has reached the default-free zone, by
looking up the first delegation Name in FIB. If this lookup turns out  
the default route (i.e., the root FIB entry ndn:/
with a non-empty nexthop list), it means the Interest is still in  
consumer region, and this lookup result is passed down
to next step. Otherwise, the Interest has reached the default-free zone.
Last, the pipeline selects a delegation for an Interest that has  
reached the default free zone, by looking up every
delegation name in the FIB, and choose the lowest-cost delegation that  
matches a non-empty FIB entry. The chosen
delegation is written into the SelectedDelegation field in the  
Interest packet, so that upstream forwarders can follow
this selection without doing multiple FIB lookups."

In particular, the purposes of mobility support, what are the  
delegations, what their utility and so on.


2) Meanwhile, I would like to use this mail in order to ask another  
thing about the Signature infrastructure using the ndn-cxx. I would  
like to test the mechanism, but I need some advices. For example, does  
it exists already something that can help me? Or should I create a  
node "Certificate authority" that answer to the request in the  
recursive verification process, should I generate and store the  
certificate myself, should I implement all "by hand" ?

Have a nice weekend. Thanks a lot,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From mhasabet at gmail.com  Fri Sep 23 06:55:20 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Fri, 23 Sep 2016 17:25:20 +0330
Subject: [Ndn-interest] Mobility support on technical report + Signature
 infrastructure NDN
In-Reply-To: <20160923150813.7akgdin9wo4s88ko@webmail.eurecom.fr>
References: <20160923150813.7akgdin9wo4s88ko@webmail.eurecom.fr>
Message-ID: <CADQ0MFatrx3+t9GPK37FU7n_Ays8=_S6s_z2hDpSt=Tu19EPNQ@mail.gmail.com>

Hi Matteo,

Delegation names are names/prefixes which the carrying interest will be
forwarded
?towards them at first
.
? When the interest reaches a delegation name, from there it will be
forwarded by it's name, not the Link anymore.

As an example take an application responsible for me(/sabet) which is
mobile and at the moment is located, or some how can be reached in /eurecom
network.? For Interersts looking for a data under /sabet prefix (e.g
/sabet/calander/sep23), they should carry a Link object which has /eurecom
as a delegation name. So we will an interest packet(or a set of interests)
which has /sabet/calander/sep23 for its name, and a Link object which has
/eurecom as a delegation is attached
to it(the interest). Routers outside /eurecom network when receive that
interest, will forward it towards /eurecom. When the interest reaches a
router in /eurecom network, then it will be forwarded towards /sabet which
existence of the Link object indicates that /sabet exist in FIB table of
?routers in /eurecom. If application responsible for /sabet moves into
another network (e.g. /ucla) and cannot be accessed in /eurecom, then
Interest should have updated version of Link, which has /ucla as delegation
name, in order to reach /sabet.
Sorry. It seems my example got a bit complicated.
I suggest you to take a look at
http://named-data.net/publications/snamp-ndn-scalability/ for understanding
how Link object is supposed to work and what is its impact on forwarding
process.

Bests,
Sabet

On Sep 23, 2016 4:40 PM, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
wrote:

> Good morning, I would like to ask you a thing about mobility support and
> one about the signature mechanism.
>
> 1) I am reading the paragraph about the mobility support during the
> forwarding of an interest in the NFD Developer guide:
> https://named-data.net/wp-content/uploads/2016/03/ndn-0021-6
> -nfd-developer-guide.pdf
> Paragraph 4.2.3. I need to clarify some aspects because I do not
> understand well the process described in this paragraph:
>
> "If the Interest carries a Link object, it is processed for mobility
> support.
> First, the pipeline determines whether the Interest has reached the
> producer region, by checking if any delegation name
> in the Link object is a prefix of any region name from the network region
> table (Section 3.2). If so, FIB lookup is
> performed using Interest Name, as if the Link object does not exist.
> Second, the pipeline inspects whether the Interest contains the
> SelectedDelegation field, which indicates that a down-
> stream forwarder has chosen which delegation to use. If so, it implies
> that the Interest is already in default-free zone,
> FIB lookup is performed using the selected delegation name.
> Third, the pipeline determines whether the Interest is in the consumer
> region or has reached the default-free zone, by
> looking up the first delegation Name in FIB. If this lookup turns out the
> default route (i.e., the root FIB entry ndn:/
> with a non-empty nexthop list), it means the Interest is still in consumer
> region, and this lookup result is passed down
> to next step. Otherwise, the Interest has reached the default-free zone.
> Last, the pipeline selects a delegation for an Interest that has reached
> the default free zone, by looking up every
> delegation name in the FIB, and choose the lowest-cost delegation that
> matches a non-empty FIB entry. The chosen
> delegation is written into the SelectedDelegation field in the Interest
> packet, so that upstream forwarders can follow
> this selection without doing multiple FIB lookups."
>
> In particular, the purposes of mobility support, what are the delegations,
> what their utility and so on.
>
>
> 2) Meanwhile, I would like to use this mail in order to ask another thing
> about the Signature infrastructure using the ndn-cxx. I would like to test
> the mechanism, but I need some advices. For example, does it exists already
> something that can help me? Or should I create a node "Certificate
> authority" that answer to the request in the recursive verification
> process, should I generate and store the certificate myself, should I
> implement all "by hand" ?
>
> Have a nice weekend. Thanks a lot,
> Matteo
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> 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/20160923/90add58f/attachment.html>

From malhowaidi at gmail.com  Fri Sep 23 14:01:42 2016
From: malhowaidi at gmail.com (Mohammad Alhowaidi)
Date: Fri, 23 Sep 2016 16:01:42 -0500
Subject: [Ndn-interest] NFD problem
Message-ID: <CAOYiq10vVYX7u8nMKd8TuM8PkMwpN4dHS4g8U1SssR7=ta6xsA@mail.gmail.com>

Hello all,

I installed NFD and when I try to start it, I am getting the following
error:

mohammad at NDN:~$ nfd-start
mohammad at NDN:~$ 1474664239.547175 INFO: [StrategyChoice] setDefaultStrategy
/localhost/nfd/strategy/best-route/%FD%04
1474664239.548490 INFO: [InternalForwarderTransport]
[id=0,local=internal://,remote=internal://] Creating transport
1474664239.548774 INFO: [FaceTable] Added face id=1 remote=internal://
local=internal://
1474664239.550677 WARNING: [CommandValidator] Wildcard identity is intended
for demo purpose only and SHOULD NOT be used in production environment
1474664239.550830 INFO: [CommandValidator] Giving privilege "faces" to
identity wildcard
1474664239.551006 INFO: [CommandValidator] Giving privilege "fib" to
identity wildcard
1474664239.551152 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity wildcard
1474664239.551630 INFO: [StrategyChoice] changeStrategy(/ndn/broadcast)
from /localhost/nfd/strategy/best-route/%FD%04 to
/localhost/nfd/strategy/multicast/%FD%01
1474664239.553247 INFO: [StrategyChoice] changeStrategy(/localhost) from
/localhost/nfd/strategy/best-route/%FD%04 to
/localhost/nfd/strategy/multicast/%FD%01
1474664239.554930 INFO: [StrategyChoice] changeStrategy(/localhost/nfd)
from /localhost/nfd/strategy/multicast/%FD%01 to
/localhost/nfd/strategy/best-route/%FD%04
1474664239.556493 INFO: [TablesConfigSection] Setting CS max packets to
65536
1474664239.558125 INFO: [MulticastUdpTransport] [id=0,local=udp4://
10.0.2.15:56363,remote=udp4://224.0.23.170:56363] Creating transport
1474664239.558462 INFO: [FaceTable] Added face id=256 remote=udp4://
224.0.23.170:56363 local=udp4://10.0.2.15:56363
1474664239.558790 INFO: [EthernetTransport]
[id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating
transport
1474664239.589669 INFO: [FaceTable] Added face id=257
remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1474664239.590122 WARNING: [CommandValidator] Wildcard identity is intended
for demo purpose only and SHOULD NOT be used in production environment
1474664239.590256 INFO: [CommandValidator] Giving privilege "faces" to
identity wildcard
1474664239.590508 INFO: [CommandValidator] Giving privilege "fib" to
identity wildcard
1474664239.590691 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity wildcard
1474664239.591119 INFO: [InternalForwarderTransport]
[id=0,local=null://,remote=null://] Creating transport
1474664239.591355 INFO: [FaceTable] Added face id=255 remote=null://
local=null://
1474664239.596502 INFO: [InternalForwarderTransport]
[id=0,local=contentstore://,remote=contentstore://] Creating transport
1474664239.596838 INFO: [FaceTable] Added face id=254
remote=contentstore:// local=contentstore://
1474664239.600444 INFO: [PrivilegeHelper] dropped to effective uid=0 gid=0
1474664239.603018 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate
section in rib section
1474664239.603371 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate
section in rib section
1474664239.603484 INFO: [RibManager] Listening on: /localhost/nfd/rib
1474664239.608388 INFO: [RibManager] Start monitoring face create/destroy
events
1474664239.612554 INFO: [UnixStreamTransport]
[id=0,local=unix:///run/nfd.sock,remote=fd://25] Creating transport
1474664239.612874 INFO: [FaceTable] Added face id=258 remote=fd://25
local=unix:///run/nfd.sock
1474664239.626273 INFO: [AutoPrefixPropagator] local registration only for
/localhost/nfd/rib




Thanks,
Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160923/c6f69633/attachment.html>

From mastorakis at CS.UCLA.EDU  Fri Sep 23 14:11:47 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Fri, 23 Sep 2016 14:11:47 -0700
Subject: [Ndn-interest] NFD problem
In-Reply-To: <CAOYiq10vVYX7u8nMKd8TuM8PkMwpN4dHS4g8U1SssR7=ta6xsA@mail.gmail.com>
References: <CAOYiq10vVYX7u8nMKd8TuM8PkMwpN4dHS4g8U1SssR7=ta6xsA@mail.gmail.com>
Message-ID: <1A39AC06-5602-4214-8634-6C9C505125A6@cs.ucla.edu>

Hi,

could you please point us to the error?

Personally, I do not see anything wrong with those logs.

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA


> On Sep 23, 2016, at 2:01 PM, Mohammad Alhowaidi <malhowaidi at gmail.com> wrote:
> 
> Hello all,
> 
> I installed NFD and when I try to start it, I am getting the following error:
> 
> mohammad at NDN:~$ nfd-start
> mohammad at NDN:~$ 1474664239.547175 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%04
> 1474664239.548490 INFO: [InternalForwarderTransport] [id=0,local=internal://,remote=internal://] Creating transport
> 1474664239.548774 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
> 1474664239.550677 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
> 1474664239.550830 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
> 1474664239.551006 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
> 1474664239.551152 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
> 1474664239.551630 INFO: [StrategyChoice] changeStrategy(/ndn/broadcast) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
> 1474664239.553247 INFO: [StrategyChoice] changeStrategy(/localhost) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
> 1474664239.554930 INFO: [StrategyChoice] changeStrategy(/localhost/nfd) from /localhost/nfd/strategy/multicast/%FD%01 to /localhost/nfd/strategy/best-route/%FD%04
> 1474664239.556493 INFO: [TablesConfigSection] Setting CS max packets to 65536
> 1474664239.558125 INFO: [MulticastUdpTransport] [id=0,local=udp4://10.0.2.15:56363 <http://10.0.2.15:56363/>,remote=udp4://224.0.23.170:56363 <http://224.0.23.170:56363/>] Creating transport
> 1474664239.558462 INFO: [FaceTable] Added face id=256 remote=udp4://224.0.23.170:56363 <http://224.0.23.170:56363/> local=udp4://10.0.2.15:56363 <http://10.0.2.15:56363/>
> 1474664239.558790 INFO: [EthernetTransport] [id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating transport
> 1474664239.589669 INFO: [FaceTable] Added face id=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
> 1474664239.590122 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
> 1474664239.590256 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
> 1474664239.590508 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
> 1474664239.590691 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
> 1474664239.591119 INFO: [InternalForwarderTransport] [id=0,local=null://,remote=null://] Creating transport
> 1474664239.591355 INFO: [FaceTable] Added face id=255 remote=null:// local=null://
> 1474664239.596502 INFO: [InternalForwarderTransport] [id=0,local=contentstore://,remote=contentstore://] Creating transport
> 1474664239.596838 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://
> 1474664239.600444 INFO: [PrivilegeHelper] dropped to effective uid=0 gid=0
> 1474664239.603018 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
> 1474664239.603371 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
> 1474664239.603484 INFO: [RibManager] Listening on: /localhost/nfd/rib
> 1474664239.608388 INFO: [RibManager] Start monitoring face create/destroy events
> 1474664239.612554 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://25] Creating transport
> 1474664239.612874 INFO: [FaceTable] Added face id=258 remote=fd://25 local=unix:///run/nfd.sock
> 1474664239.626273 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
> 
> 
> 
> 
> Thanks,
> Mohammad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160923/718801fa/attachment.html>

From divyasaxena.iiitm at gmail.com  Sat Sep 24 04:50:06 2016
From: divyasaxena.iiitm at gmail.com (Divya Saxena)
Date: Sat, 24 Sep 2016 17:20:06 +0530
Subject: [Ndn-interest] Regarding the NDN Survey
Message-ID: <CAO6FiKJampmQMbwHGfs+TovBmPsw79NMtdar+xbX2PNLHuOUwQ@mail.gmail.com>

Hello everyone


We are working on the Named Data Networking since last 2 years and have
published an extensive survey ?Named Data Networking: A Survey?. In this
paper, we proposed a novel taxonomy to study the NDN features in depth.


Please have a look and provide your valuable feedback. Please also cite our
paper as

?Saxena D, Raychoudhury V, Suri N, Becker C, Cao J. *Named data networking:
a survey*. Computer Science Review. 19 (2016): 15-55?.


> --
>
Thanks & Regards
Divya Saxena
Research Scholar
Department of Computer Science & Engineering
Indian Institute of Technology Roorkee
Roorkee 247667, Uttarakhand, INDIA
?You have to dream before your dreams can come true."--APJ Abdul Kalam

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160924/845bd4b8/attachment.html>

From malhowaidi at gmail.com  Sat Sep 24 17:23:12 2016
From: malhowaidi at gmail.com (Mohammad Alhowaidi)
Date: Sat, 24 Sep 2016 19:23:12 -0500
Subject: [Ndn-interest] NFD problem
In-Reply-To: <1A39AC06-5602-4214-8634-6C9C505125A6@cs.ucla.edu>
References: <CAOYiq10vVYX7u8nMKd8TuM8PkMwpN4dHS4g8U1SssR7=ta6xsA@mail.gmail.com>
	<1A39AC06-5602-4214-8634-6C9C505125A6@cs.ucla.edu>
Message-ID: <CAOYiq10rzVMkMt9L79_zEYNjJVvEVcJJfPiTzYiuOEv04rG7+Q@mail.gmail.com>

I felt its misbehaving by showing the log, and when I run the ndncatchunk
from ndn-tools, it give the following log ( how to stop showing these
logs?!)

1474762701.186640 INFO: [UnixStreamTransport]
[id=0,local=unix:///run/nfd.sock,remote=fd://26] Creating transport
1474762701.186893 INFO: [FaceTable] Added face id=260 remote=fd://26
local=unix:///run/nfd.sock
1474762701.195898 INFO: [RibManager] Adding route /ndn/test nexthop=260
origin=0 cost=0
1474762701.206572 INFO: [AutoPrefixPropagator] no signing identity
available for: /ndn/test
1474762747.728925 INFO: [UnixStreamTransport]
[id=0,local=unix:///run/nfd.sock,remote=fd://27] Creating transport
1474762747.729293 INFO: [FaceTable] Added face id=261 remote=fd://27
local=unix:///run/nfd.sock
1474762755.735341 INFO: [Transport]
[id=261,local=unix:///run/nfd.sock,remote=fd://27] setState UP -> FAILED
1474762755.735861 INFO: [Transport]
[id=261,local=unix:///run/nfd.sock,remote=fd://27] setState FAILED -> CLOSED
1474762755.739910 INFO: [FaceTable] Removed face id=261 remote=fd://27
local=unix:///run/nfd.sock


Thanks,
Mohammad


On Fri, Sep 23, 2016 at 4:11 PM, Spyridon (Spyros) Mastorakis <
mastorakis at cs.ucla.edu> wrote:

> Hi,
>
> could you please point us to the error?
>
> Personally, I do not see anything wrong with those logs.
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
>
> On Sep 23, 2016, at 2:01 PM, Mohammad Alhowaidi <malhowaidi at gmail.com>
> wrote:
>
> Hello all,
>
> I installed NFD and when I try to start it, I am getting the following
> error:
>
> mohammad at NDN:~$ nfd-start
> mohammad at NDN:~$ 1474664239.547175 INFO: [StrategyChoice]
> setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%04
> 1474664239.548490 INFO: [InternalForwarderTransport] [id=0,local=
> internal://,remote=internal://] Creating transport
> 1474664239.548774 INFO: [FaceTable] Added face id=1 remote=internal://
> local=internal://
> 1474664239.550677 WARNING: [CommandValidator] Wildcard identity is
> intended for demo purpose only and SHOULD NOT be used in production
> environment
> 1474664239.550830 INFO: [CommandValidator] Giving privilege "faces" to
> identity wildcard
> 1474664239.551006 INFO: [CommandValidator] Giving privilege "fib" to
> identity wildcard
> 1474664239.551152 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity wildcard
> 1474664239.551630 INFO: [StrategyChoice] changeStrategy(/ndn/broadcast)
> from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/
> multicast/%FD%01
> 1474664239.553247 INFO: [StrategyChoice] changeStrategy(/localhost) from
> /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/
> multicast/%FD%01
> 1474664239.554930 INFO: [StrategyChoice] changeStrategy(/localhost/nfd)
> from /localhost/nfd/strategy/multicast/%FD%01 to
> /localhost/nfd/strategy/best-route/%FD%04
> 1474664239.556493 INFO: [TablesConfigSection] Setting CS max packets to
> 65536
> 1474664239.558125 INFO: [MulticastUdpTransport] [id=0,local=udp4://
> 10.0.2.15:56363,remote=udp4://224.0.23.170:56363] Creating transport
> 1474664239.558462 INFO: [FaceTable] Added face id=256 remote=udp4://
> 224.0.23.170:56363 local=udp4://10.0.2.15:56363
> 1474664239.558790 INFO: [EthernetTransport] [id=0,local=dev://eth0,remote=
> ether://[01:00:5e:00:17:aa]] Creating transport
> 1474664239.589669 INFO: [FaceTable] Added face id=257 remote=
> ether://[01:00:5e:00:17:aa] local=dev://eth0
> 1474664239.590122 WARNING: [CommandValidator] Wildcard identity is
> intended for demo purpose only and SHOULD NOT be used in production
> environment
> 1474664239.590256 INFO: [CommandValidator] Giving privilege "faces" to
> identity wildcard
> 1474664239.590508 INFO: [CommandValidator] Giving privilege "fib" to
> identity wildcard
> 1474664239.590691 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity wildcard
> 1474664239.591119 INFO: [InternalForwarderTransport] [id=0,local=
> null://,remote=null://] Creating transport
> 1474664239.591355 INFO: [FaceTable] Added face id=255 remote=null://
> local=null://
> 1474664239.596502 INFO: [InternalForwarderTransport] [id=0,local=
> contentstore://,remote=contentstore://] Creating transport
> 1474664239.596838 INFO: [FaceTable] Added face id=254
> remote=contentstore:// local=contentstore://
> 1474664239.600444 INFO: [PrivilegeHelper] dropped to effective uid=0 gid=0
> 1474664239.603018 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate
> section in rib section
> 1474664239.603371 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate
> section in rib section
> 1474664239.603484 INFO: [RibManager] Listening on: /localhost/nfd/rib
> 1474664239.608388 INFO: [RibManager] Start monitoring face create/destroy
> events
> 1474664239.612554 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.
> sock,remote=fd://25] Creating transport
> 1474664239.612874 INFO: [FaceTable] Added face id=258 remote=fd://25
> local=unix:///run/nfd.sock
> 1474664239.626273 INFO: [AutoPrefixPropagator] local registration only for
> /localhost/nfd/rib
>
>
>
>
> Thanks,
> Mohammad
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160924/902de5c3/attachment.html>

From jburke at remap.ucla.edu  Sun Sep 25 01:49:58 2016
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sun, 25 Sep 2016 08:49:58 +0000
Subject: [Ndn-interest] New video faq posting - security
Message-ID: <D48FD299-A984-4B15-BD12-BEC89748439C@remap.ucla.edu>

Hi everyone,

There is a new video faq posting by J. Alex Halderman on security here ?
https://vimeo.com/channels/ndnvfaq

Please let us know questions you?d like answered on video using the ?shout box? or message to the channel owner on vimeo.

best,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160925/36aac1d3/attachment.html>

From christos at colostate.edu  Sun Sep 25 18:04:26 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Sun, 25 Sep 2016 19:04:26 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
Message-ID: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>

http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html

Apologies if you have seen this already, but 600+Gbps DDoS attack from 
IoT devices is truly remarkable. Moreover, it was *not* and reflection 
attack! The target was protected by Akamai, who had to drop them (it was 
hosted pro-bono) after a few days of sustained attack because it was 
costing too much.

There are a few elements that might make this event a game changer. (a) 
from now on, people may want to always talk about security in IoT, (b) 
it raises questions about protecting the little guy from DDoS, the 
customer here found a home at Google's Project Shield, but obviously 
this is not scalable, and (c) cloud protection from DDoS is not a 
general solution despite what cloud providers will have you believe.

To me such events bring to focus the weaknesses and fragility of the IP 
architecture. With billions of IoT devices projected in the future, even 
one packet/second (or even per minute) from a fraction of these devices 
would be enough to cause real damage. We all know about the code quality 
and ease of patching of IoT devices, this will not change.

Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.

https://www.schneier.com/crypto-gram/archives/2016/0915.html#2

Christos.




From mesarpe at gmail.com  Sun Sep 25 23:45:51 2016
From: mesarpe at gmail.com (=?UTF-8?Q?C=C3=A9sar_A=2E_Bernardini?=)
Date: Mon, 26 Sep 2016 08:45:51 +0200
Subject: [Ndn-interest] New video faq posting - security
In-Reply-To: <D48FD299-A984-4B15-BD12-BEC89748439C@remap.ucla.edu>
References: <D48FD299-A984-4B15-BD12-BEC89748439C@remap.ucla.edu>
Message-ID: <CAO9+PG_ou0FHa1K5A=kqDFLu_9RTnJCNq6tVcuxHNH4xvfyW5Q@mail.gmail.com>

Dear Jeff,

We have already published a paper that solves the problems highlighted in
the video:

PROTECTOR: Privacy-preserving information lookup in content-centric networks
MR Asghar, C Bernardini, B Crispo

Bests,

2016-09-25 10:49 GMT+02:00 Burke, Jeff <jburke at remap.ucla.edu>:

> Hi everyone,
>
>
>
> There is a new video faq posting by J. Alex Halderman on security here ?
>
> https://vimeo.com/channels/ndnvfaq
>
>
>
> Please let us know questions you?d like answered on video using the ?shout
> box? or message to the channel owner on vimeo.
>
>
>
> best,
>
> Jeff
>
>
>
> _______________________________________________
> 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/20160926/a786fd1c/attachment.html>

From s.h.ahmed at ieee.org  Sun Sep 25 22:01:22 2016
From: s.h.ahmed at ieee.org (Syed Hassan Ahmed)
Date: Mon, 26 Sep 2016 14:01:22 +0900
Subject: [Ndn-interest] IEEE Access Special Session on Future Networks
Message-ID: <CAJeX4qfT9RTsijd-N2s4ZiQPVT9hu=Qu3x6f4BK=C6Pp8wOU0w@mail.gmail.com>

Hello NDN Community,

We are accepting submissions to our Special Section on ?Future Networks:
Architectures, Protocols, and Applications"
URL:
http://ieeeaccess.ieee.org/special-sections/future-networks-architectures-protocols-applications/

---------------------
IEEE Access Journal (Indexed by SCI-E, IF: 1.270)
---------------------

Scope: This special section aims to bring together researchers, academics,
and individuals working on the selected areas of Future Networks and share
their new ideas, latest findings, and results on the following topics, but
are not limited to:

- Future Networks and Wireless Ad hoc Networks
- Future Networks in Vehicular Ad Hoc Networks
- 5G and Internet of Things (IoT)
- Future Internet applications in IoT
- Steps towards Future of Smart Grid Communications
- Routing in Machine to Machine (M2M) and Future Networks
- Fusion of Future Networking Technologies and Big Data / Fog Computing
- Future Internet and 5G architectural designs
- 5G advancements in VANETs
- Information Centric/Content Centric/Named Data Networking (ICN/CCN/NDN)
- Mobile edge computing
- Security and Privacy in future Networks
- Networking Protocols for Future Networks
- Data Forwarding in Future Networks
- New Applications for Future Networks
- Transport Layer advancements in Future Networks
- Cloud-based IoT architectures and use cases

Editorial Team:
Safdar Hussain Bouk, Kyungpook National University, Korea
Houbing Song, West Virginia University, USA
Waleed Ejaz, Ryerson University, Ontario, Canada
Syed Hassan Ahmed, Kyungpook National University, Korea
Danda B. Rawat, Georgia Southern University, USA

Paper submission:
http://mc.manuscriptcentral.com/ieee-access

Important Dates:
Paper Submission: January 31, 2017

Best Regards,
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
*Syed Hassan Ahmed *(??)
Kyungpook National University,
Daegu City, Republic of Korea.
Cell: +82-10-9883-0786
https://sites.google.com/site/shahmedknu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160926/aaba0511/attachment.html>

From Matteo.Bertolino at eurecom.fr  Mon Sep 26 02:43:38 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Mon, 26 Sep 2016 11:43:38 +0200
Subject: [Ndn-interest] Signature verification
Message-ID: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>

Good morning,
I am searching an example about how to realize secure communication,  
because the security library tutorial on the web site did not solved  
lots of doubts.
Specifically, I would like to realize something like:

Consumer --- NDN network with some gateways --- GW_edge --- Producer
, where:

- The Consumer requests a data;
- Producer has a certificate given by an Authority A well know.  
Consumer has the certificate of A in its store.
- Producer has two keys: KSK long term , DSK for short term. Now let's  
focus on the data origin authentication.
- Producer sign the data packet with its certificate.
- Consumer check the certificate of Producer and it notices that it  
was signed by A.
- Consumer sends an Interest to A in order to obtain its certificate.
- Consumer see that A's certificate it is the same that it cached, and  
it does not drop the data packet.

These steps are not "mandatory", I mean  that if you know a better  
method to perform authentication or something else that I can study in  
order to understand better is good the same.

I am working in C++. I had a look to the ndn-cxx api, but I do not  
understand the elementary steps about how to realize the communication  
above mentioned.

Best regards,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From Cedric.Westphal at huawei.com  Mon Sep 26 11:43:37 2016
From: Cedric.Westphal at huawei.com (Cedric Westphal)
Date: Mon, 26 Sep 2016 18:43:37 +0000
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
Message-ID: <369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>

That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off. 

C.

-----Original Message-----
From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
Sent: Sunday, September 25, 2016 6:04 PM
To: ndn-interest at lists.cs.ucla.edu
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices

http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html

Apologies if you have seen this already, but 600+Gbps DDoS attack from 
IoT devices is truly remarkable. Moreover, it was *not* and reflection 
attack! The target was protected by Akamai, who had to drop them (it was 
hosted pro-bono) after a few days of sustained attack because it was 
costing too much.

There are a few elements that might make this event a game changer. (a) 
from now on, people may want to always talk about security in IoT, (b) 
it raises questions about protecting the little guy from DDoS, the 
customer here found a home at Google's Project Shield, but obviously 
this is not scalable, and (c) cloud protection from DDoS is not a 
general solution despite what cloud providers will have you believe.

To me such events bring to focus the weaknesses and fragility of the IP 
architecture. With billions of IoT devices projected in the future, even 
one packet/second (or even per minute) from a fraction of these devices 
would be enough to cause real damage. We all know about the code quality 
and ease of patching of IoT devices, this will not change.

Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.

https://www.schneier.com/crypto-gram/archives/2016/0915.html#2

Christos.


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



From christos at colostate.edu  Mon Sep 26 12:39:55 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Mon, 26 Sep 2016 13:39:55 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
Message-ID: <170059c7-75ef-e846-fb58-964cf8922077@colostate.edu>

Cedric,

There are more expanded published versions of my answer below, but let 
me try to hit the highlights.

NDN has a few advantages over IP when it comes to DDoS. More 
specifically, even if attackers request unique objects, path symmetry 
allows a router to estimate the rate if un-answered interests coming 
from a particular face and impose rate limits or even cutoff traffic 
from that face completely. In IP you cannot do that because of 
asymmetric routing.

As you said, a DDoS attack of this type would have to use unique names. 
I have not done the analysis, but if those unique names are generated by 
an algorithm (or are random), then they are subject to lexicographic 
analysis. A similar scenario is bots that use DGA (domain generated 
algorithms) to rendezvous with C&C servers. I suspect that a similar 
analysis is possible.

I am not sure I understand the scenario of a congested caching 
infrastructure. In NDN data can be cached in all routers, meaning that 
many DDoS Interests may not even leave the local network. In terms of 
blocking DDoS attacks this is probably as good as you can get. I would 
even say that in NDN a DDoS attack that requests the same content is 
unlikely to be successful, it will do more harm the local network.

Christos.



On 09/26/2016 12:43 PM, Cedric Westphal wrote:
> That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off.
>
> C.
>
> -----Original Message-----
> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
> Sent: Sunday, September 25, 2016 6:04 PM
> To: ndn-interest at lists.cs.ucla.edu
> Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices
>
> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
>
> Apologies if you have seen this already, but 600+Gbps DDoS attack from
> IoT devices is truly remarkable. Moreover, it was *not* and reflection
> attack! The target was protected by Akamai, who had to drop them (it was
> hosted pro-bono) after a few days of sustained attack because it was
> costing too much.
>
> There are a few elements that might make this event a game changer. (a)
> from now on, people may want to always talk about security in IoT, (b)
> it raises questions about protecting the little guy from DDoS, the
> customer here found a home at Google's Project Shield, but obviously
> this is not scalable, and (c) cloud protection from DDoS is not a
> general solution despite what cloud providers will have you believe.
>
> To me such events bring to focus the weaknesses and fragility of the IP
> architecture. With billions of IoT devices projected in the future, even
> one packet/second (or even per minute) from a fraction of these devices
> would be enough to cause real damage. We all know about the code quality
> and ease of patching of IoT devices, this will not change.
>
> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
>
> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
>
> Christos.
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



From mesarpe at gmail.com  Mon Sep 26 12:47:12 2016
From: mesarpe at gmail.com (=?UTF-8?Q?C=C3=A9sar_A=2E_Bernardini?=)
Date: Mon, 26 Sep 2016 21:47:12 +0200
Subject: [Ndn-interest] Signature verification
In-Reply-To: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>
References: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>
Message-ID: <CAO9+PG88iOJwgX6bun-r2hH0KaKNiJiKx2Jm9=cju2h1dvQPFw@mail.gmail.com>

Mateo,

I have implemented a security protocol for NDN/CCN (PROTECTOR, icc2016).
The implementation is way complicated in NDN.

It is several orders of magnitude easier with the Athena CCNx. They have a
receiver and a sender that you can overwrite to implement your protocol.

However, be careful, that both implementations Are not really flexible
neither prepared for extensions.

Bests,

On Sep 26, 2016 20:04, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
wrote:

> Good morning,
> I am searching an example about how to realize secure communication,
> because the security library tutorial on the web site did not solved lots
> of doubts.
> Specifically, I would like to realize something like:
>
> Consumer --- NDN network with some gateways --- GW_edge --- Producer
> , where:
>
> - The Consumer requests a data;
> - Producer has a certificate given by an Authority A well know. Consumer
> has the certificate of A in its store.
> - Producer has two keys: KSK long term , DSK for short term. Now let's
> focus on the data origin authentication.
> - Producer sign the data packet with its certificate.
> - Consumer check the certificate of Producer and it notices that it was
> signed by A.
> - Consumer sends an Interest to A in order to obtain its certificate.
> - Consumer see that A's certificate it is the same that it cached, and it
> does not drop the data packet.
>
> These steps are not "mandatory", I mean  that if you know a better method
> to perform authentication or something else that I can study in order to
> understand better is good the same.
>
> I am working in C++. I had a look to the ndn-cxx api, but I do not
> understand the elementary steps about how to realize the communication
> above mentioned.
>
> Best regards,
> Matteo
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> 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/20160926/9710dabd/attachment.html>

From gts at ics.uci.edu  Mon Sep 26 13:34:14 2016
From: gts at ics.uci.edu (GTS)
Date: Mon, 26 Sep 2016 13:34:14 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
Message-ID: <d7d975c3-6aa2-4eee-3037-d5d5aee75967@ics.uci.edu>

I generally agree with Cedric. In CCN (i.e., NDN & CCNx), the so-called 
"attack surface"
will change shape but it's area will remain almost the same. In 
particular, attacks
such as the one Christos mentions, where IoT devices act as mini-zombies 
(DoS attack sources),
are unfortunately still possible. Just not in the same way...

One notable item in the shifting attack surface is this: in CCN, an 
end-entity (e.g., an IoT
device) that only acts as a consumer (never produces anything), can not 
be DoS-attacked
in the usual manner, since the only way it can be "reached" is by 
content that *it*
has actually requested. In IP, that's certainly not the case.

But, if an end-entity can request content, it can in principle be 
infected by malware.^$
Thus, it can still be turned into a mini-zombie. :-)

Cheers,
Gene

$ Or, it can be infected prior to being put in service.

======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

On 9/26/16 11:43 AM, Cedric Westphal wrote:
> That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off.
>
> C.
>
> -----Original Message-----
> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
> Sent: Sunday, September 25, 2016 6:04 PM
> To: ndn-interest at lists.cs.ucla.edu
> Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices
>
> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
>
> Apologies if you have seen this already, but 600+Gbps DDoS attack from
> IoT devices is truly remarkable. Moreover, it was *not* and reflection
> attack! The target was protected by Akamai, who had to drop them (it was
> hosted pro-bono) after a few days of sustained attack because it was
> costing too much.
>
> There are a few elements that might make this event a game changer. (a)
> from now on, people may want to always talk about security in IoT, (b)
> it raises questions about protecting the little guy from DDoS, the
> customer here found a home at Google's Project Shield, but obviously
> this is not scalable, and (c) cloud protection from DDoS is not a
> general solution despite what cloud providers will have you believe.
>
> To me such events bring to focus the weaknesses and fragility of the IP
> architecture. With billions of IoT devices projected in the future, even
> one packet/second (or even per minute) from a fraction of these devices
> would be enough to cause real damage. We all know about the code quality
> and ease of patching of IoT devices, this will not change.
>
> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
>
> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
>
> Christos.
>
>
> _______________________________________________
> 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
> .
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160926/28f1ebe3/attachment.html>

From christos at colostate.edu  Mon Sep 26 20:36:14 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Mon, 26 Sep 2016 21:36:14 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <d7d975c3-6aa2-4eee-3037-d5d5aee75967@ics.uci.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
	<d7d975c3-6aa2-4eee-3037-d5d5aee75967@ics.uci.edu>
Message-ID: <52f157a9-7448-cdf9-9349-43b969236b1e@colostate.edu>

Hi Gene,

In NDN, with symmetric traffic and the PIT state, there is an 
equilibrium imposed (an Interest must be followed by a response) and 
more importantly, can be verified (expired or overflowed PIT state means 
failure of the equilibrium).

The point is there is a signal available in NDN (failure in the 
equilibrium) that is not available in IP. There are very interesting 
research questions about how to use this signal.

IP tried to do something similar with pushback. One problem with it was 
the coordination required between the routers to make pushback 
effective. Imagine for example, how hard it would be to coordinate at 
the interdomain level. In NDN a disturbance in the equilibrium can be 
detected locally.

Christos.



On 09/26/2016 02:34 PM, GTS wrote:
> I generally agree with Cedric. In CCN (i.e., NDN & CCNx), the 
> so-called "attack surface"
> will change shape but it's area will remain almost the same. In 
> particular, attacks
> such as the one Christos mentions, where IoT devices act as 
> mini-zombies (DoS attack sources),
> are unfortunately still possible. Just not in the same way...
>
> One notable item in the shifting attack surface is this: in CCN, an 
> end-entity (e.g., an IoT
> device) that only acts as a consumer (never produces anything), can 
> not be DoS-attacked
> in the usual manner, since the only way it can be "reached" is by 
> content that *it*
> has actually requested. In IP, that's certainly not the case.
>
> But, if an end-entity can request content, it can in principle be 
> infected by malware.^$
> Thus, it can still be turned into a mini-zombie. :-)
>
> Cheers,
> Gene
>
> $ Or, it can be infected prior to being put in service.
>
> ======================
> Gene Tsudik
> Chancellor's Professor of Computer Science
> University of California, Irvine
>
> On 9/26/16 11:43 AM, Cedric Westphal wrote:
>> That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off.
>>
>> C.
>>
>> -----Original Message-----
>> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
>> Sent: Sunday, September 25, 2016 6:04 PM
>> To:ndn-interest at lists.cs.ucla.edu
>> Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices
>>
>> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
>>
>> Apologies if you have seen this already, but 600+Gbps DDoS attack from
>> IoT devices is truly remarkable. Moreover, it was *not* and reflection
>> attack! The target was protected by Akamai, who had to drop them (it was
>> hosted pro-bono) after a few days of sustained attack because it was
>> costing too much.
>>
>> There are a few elements that might make this event a game changer. (a)
>> from now on, people may want to always talk about security in IoT, (b)
>> it raises questions about protecting the little guy from DDoS, the
>> customer here found a home at Google's Project Shield, but obviously
>> this is not scalable, and (c) cloud protection from DDoS is not a
>> general solution despite what cloud providers will have you believe.
>>
>> To me such events bring to focus the weaknesses and fragility of the IP
>> architecture. With billions of IoT devices projected in the future, even
>> one packet/second (or even per minute) from a fraction of these devices
>> would be enough to cause real damage. We all know about the code quality
>> and ease of patching of IoT devices, this will not change.
>>
>> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
>>
>> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
>>
>> Christos.
>>
>>
>> _______________________________________________
>> 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
>> .
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160926/8b689bdf/attachment.html>

From gts at ics.uci.edu  Mon Sep 26 22:31:59 2016
From: gts at ics.uci.edu (GTS)
Date: Mon, 26 Sep 2016 22:31:59 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <52f157a9-7448-cdf9-9349-43b969236b1e@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
	<d7d975c3-6aa2-4eee-3037-d5d5aee75967@ics.uci.edu>
	<52f157a9-7448-cdf9-9349-43b969236b1e@colostate.edu>
Message-ID: <de499102-49f9-ba73-ad21-ae841a0df0f3@ics.uci.edu>

Hi Christos,

indeed, there's (expected) equilibrium in CCN.
A PIT overflow implies failure of this equilibrium. However, an attack 
is not the
only potential cause for a PIT overflow, right? Telling the difference 
seems very hard.

Coming back to the specific large-scale DoS issue, you originally cited 
the recent attack where
IP-enabled IoT devices acted as attack sources (zombies). I claim this 
is possible in CCN
if malware gets in before deployment; in that case, a CCN-enabled IoT 
device can become a
DoS *source*.

The real difference I see is this:  a CCN-enabled IoT device that never 
publishes anything (e.g., a pure actuator)
can not be a DoS *target*.

Cheers,
Gene

======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

On 9/26/16 8:36 PM, Christos Papadopoulos wrote:
>
> Hi Gene,
>
> In NDN, with symmetric traffic and the PIT state, there is an 
> equilibrium imposed (an Interest must be followed by a response) and 
> more importantly, can be verified (expired or overflowed PIT state 
> means failure of the equilibrium).
>
> The point is there is a signal available in NDN (failure in the 
> equilibrium) that is not available in IP. There are very interesting 
> research questions about how to use this signal.
>
> IP tried to do something similar with pushback. One problem with it 
> was the coordination required between the routers to make pushback 
> effective. Imagine for example, how hard it would be to coordinate at 
> the interdomain level. In NDN a disturbance in the equilibrium can be 
> detected locally.
>
> Christos.
>
>
>
> On 09/26/2016 02:34 PM, GTS wrote:
>> I generally agree with Cedric. In CCN (i.e., NDN & CCNx), the 
>> so-called "attack surface"
>> will change shape but it's area will remain almost the same. In 
>> particular, attacks
>> such as the one Christos mentions, where IoT devices act as 
>> mini-zombies (DoS attack sources),
>> are unfortunately still possible. Just not in the same way...
>>
>> One notable item in the shifting attack surface is this: in CCN, an 
>> end-entity (e.g., an IoT
>> device) that only acts as a consumer (never produces anything), can 
>> not be DoS-attacked
>> in the usual manner, since the only way it can be "reached" is by 
>> content that *it*
>> has actually requested. In IP, that's certainly not the case.
>>
>> But, if an end-entity can request content, it can in principle be 
>> infected by malware.^$
>> Thus, it can still be turned into a mini-zombie. :-)
>>
>> Cheers,
>> Gene
>>
>> $ Or, it can be infected prior to being put in service.
>>
>> ======================
>> Gene Tsudik
>> Chancellor's Professor of Computer Science
>> University of California, Irvine
>>
>> On 9/26/16 11:43 AM, Cedric Westphal wrote:
>>> That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off.
>>>
>>> C.
>>>
>>> -----Original Message-----
>>> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
>>> Sent: Sunday, September 25, 2016 6:04 PM
>>> To:ndn-interest at lists.cs.ucla.edu
>>> Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices
>>>
>>> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
>>>
>>> Apologies if you have seen this already, but 600+Gbps DDoS attack from
>>> IoT devices is truly remarkable. Moreover, it was *not* and reflection
>>> attack! The target was protected by Akamai, who had to drop them (it was
>>> hosted pro-bono) after a few days of sustained attack because it was
>>> costing too much.
>>>
>>> There are a few elements that might make this event a game changer. (a)
>>> from now on, people may want to always talk about security in IoT, (b)
>>> it raises questions about protecting the little guy from DDoS, the
>>> customer here found a home at Google's Project Shield, but obviously
>>> this is not scalable, and (c) cloud protection from DDoS is not a
>>> general solution despite what cloud providers will have you believe.
>>>
>>> To me such events bring to focus the weaknesses and fragility of the IP
>>> architecture. With billions of IoT devices projected in the future, even
>>> one packet/second (or even per minute) from a fraction of these devices
>>> would be enough to cause real damage. We all know about the code quality
>>> and ease of patching of IoT devices, this will not change.
>>>
>>> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
>>>
>>> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
>>>
>>> Christos.
>>>
>>>
>>> _______________________________________________
>>> 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
>>> .
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160926/dc68ad77/attachment.html>

From Matteo.Bertolino at eurecom.fr  Mon Sep 26 23:22:19 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 27 Sep 2016 08:22:19 +0200
Subject: [Ndn-interest] Signature verification
In-Reply-To: <CAO9+PG88iOJwgX6bun-r2hH0KaKNiJiKx2Jm9=cju2h1dvQPFw@mail.gmail.com>
References: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>
	<CAO9+PG88iOJwgX6bun-r2hH0KaKNiJiKx2Jm9=cju2h1dvQPFw@mail.gmail.com>
Message-ID: <20160927082219.0atqlqx8g4gk88sk@webmail.eurecom.fr>

Thank you for the answer.
Actually it is a little advanced for me, I searched something in order  
to understand the basis. Something like  
https://github.com/chengyu/ndn-examples
But I am having lots of problem on running these examples. Someone was  
successfully able to run it?
Yours, Matteo

Quoting "C?sar A. Bernardini" <mesarpe at gmail.com>:

> Mateo,
>
> I have implemented a security protocol for NDN/CCN (PROTECTOR, icc2016).
> The implementation is way complicated in NDN.
>
> It is several orders of magnitude easier with the Athena CCNx. They have a
> receiver and a sender that you can overwrite to implement your protocol.
>
> However, be careful, that both implementations Are not really flexible
> neither prepared for extensions.
>
> Bests,
>
> On Sep 26, 2016 20:04, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> wrote:
>
>> Good morning,
>> I am searching an example about how to realize secure communication,
>> because the security library tutorial on the web site did not solved lots
>> of doubts.
>> Specifically, I would like to realize something like:
>>
>> Consumer --- NDN network with some gateways --- GW_edge --- Producer
>> , where:
>>
>> - The Consumer requests a data;
>> - Producer has a certificate given by an Authority A well know. Consumer
>> has the certificate of A in its store.
>> - Producer has two keys: KSK long term , DSK for short term. Now let's
>> focus on the data origin authentication.
>> - Producer sign the data packet with its certificate.
>> - Consumer check the certificate of Producer and it notices that it was
>> signed by A.
>> - Consumer sends an Interest to A in order to obtain its certificate.
>> - Consumer see that A's certificate it is the same that it cached, and it
>> does not drop the data packet.
>>
>> These steps are not "mandatory", I mean  that if you know a better method
>> to perform authentication or something else that I can study in order to
>> understand better is good the same.
>>
>> I am working in C++. I had a look to the ndn-cxx api, but I do not
>> understand the elementary steps about how to realize the communication
>> above mentioned.
>>
>> Best regards,
>> Matteo
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From shijunxiao at email.arizona.edu  Tue Sep 27 02:07:31 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 27 Sep 2016 02:07:31 -0700
Subject: [Ndn-interest] Signature verification
In-Reply-To: <20160927082219.0atqlqx8g4gk88sk@webmail.eurecom.fr>
References: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>
	<CAO9+PG88iOJwgX6bun-r2hH0KaKNiJiKx2Jm9=cju2h1dvQPFw@mail.gmail.com>
	<20160927082219.0atqlqx8g4gk88sk@webmail.eurecom.fr>
Message-ID: <CAOFH+Oac0VjqqyQvfuUZ3jydO1Oxkgji4o=ZrMKUFQ0t8Vbkdw@mail.gmail.com>

Hi Matteo

Based on the update date of this repository, these programs are designed
for an older version of ndn-cxx and NFD.
You can try to find a version released around that time, and compile the
programs.

Yours, Junxiao

On Mon, Sep 26, 2016 at 11:22 PM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

> Thank you for the answer.
> Actually it is a little advanced for me, I searched something in order to
> understand the basis. Something like https://github.com/chengyu/ndn
> -examples
> But I am having lots of problem on running these examples. Someone was
> successfully able to run it?
> Yours, Matteo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/1393aa89/attachment.html>

From Matteo.Bertolino at eurecom.fr  Tue Sep 27 02:13:17 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 27 Sep 2016 11:13:17 +0200
Subject: [Ndn-interest] Signature verification
In-Reply-To: <CAOFH+Oac0VjqqyQvfuUZ3jydO1Oxkgji4o=ZrMKUFQ0t8Vbkdw@mail.gmail.com>
References: <20160926114338.hfv9h7fzfo04w488@webmail.eurecom.fr>
	<CAO9+PG88iOJwgX6bun-r2hH0KaKNiJiKx2Jm9=cju2h1dvQPFw@mail.gmail.com>
	<20160927082219.0atqlqx8g4gk88sk@webmail.eurecom.fr>
	<CAOFH+Oac0VjqqyQvfuUZ3jydO1Oxkgji4o=ZrMKUFQ0t8Vbkdw@mail.gmail.com>
Message-ID: <20160927111317.ar4yhivz7k00owks@webmail.eurecom.fr>

Aaah I did not get care about the date, you are right! Thank you.
Can I kindly ask if someone has a trivial program which shows how to  
realize the signature verification?
Thank you,
Sincerely Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> Based on the update date of this repository, these programs are designed
> for an older version of ndn-cxx and NFD.
> You can try to find a version released around that time, and compile the
> programs.
>
> Yours, Junxiao
>
> On Mon, Sep 26, 2016 at 11:22 PM, Matteo Bertolino <
> Matteo.Bertolino at eurecom.fr> wrote:
>
>> Thank you for the answer.
>> Actually it is a little advanced for me, I searched something in order to
>> understand the basis. Something like https://github.com/chengyu/ndn
>> -examples
>> But I am having lots of problem on running these examples. Someone was
>> successfully able to run it?
>> Yours, Matteo
>>
>>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From shijunxiao at email.arizona.edu  Tue Sep 27 02:26:45 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 27 Sep 2016 02:26:45 -0700
Subject: [Ndn-interest] NFD problem
In-Reply-To: <CAOYiq10rzVMkMt9L79_zEYNjJVvEVcJJfPiTzYiuOEv04rG7+Q@mail.gmail.com>
References: <CAOYiq10vVYX7u8nMKd8TuM8PkMwpN4dHS4g8U1SssR7=ta6xsA@mail.gmail.com>
	<1A39AC06-5602-4214-8634-6C9C505125A6@cs.ucla.edu>
	<CAOYiq10rzVMkMt9L79_zEYNjJVvEVcJJfPiTzYiuOEv04rG7+Q@mail.gmail.com>
Message-ID: <CAOFH+Ob8hDMKRhDAYvnBrfwCfE8yAqmGkevApd7V9Uxn9B9_9w@mail.gmail.com>

Hi Mohammad

To disable NFD logging: modify /etc/ndn/nfd.conf (or
/usr/local/etc/ndn/nfd.conf if installed from source), change
log.default_level to NONE.

Yours, Junxiao

On Sat, Sep 24, 2016 at 5:23 PM, Mohammad Alhowaidi <malhowaidi at gmail.com>
wrote:

>
> I felt its misbehaving by showing the log, and when I run the ndncatchunk
> from ndn-tools, it give the following log ( how to stop showing these
> logs?!)
>
> 1474762701.186640 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://26]
> Creating transport
> 1474762701.186893 INFO: [FaceTable] Added face id=260 remote=fd://26
> local=unix:///run/nfd.sock
> 1474762701.195898 INFO: [RibManager] Adding route /ndn/test nexthop=260
> origin=0 cost=0
> 1474762701.206572 INFO: [AutoPrefixPropagator] no signing identity
> available for: /ndn/test
> 1474762747.728925 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://27]
> Creating transport
> 1474762747.729293 INFO: [FaceTable] Added face id=261 remote=fd://27
> local=unix:///run/nfd.sock
> 1474762755.735341 INFO: [Transport] [id=261,local=unix:///run/nfd.sock,remote=fd://27]
> setState UP -> FAILED
> 1474762755.735861 INFO: [Transport] [id=261,local=unix:///run/nfd.sock,remote=fd://27]
> setState FAILED -> CLOSED
> 1474762755.739910 INFO: [FaceTable] Removed face id=261 remote=fd://27
> local=unix:///run/nfd.sock
>
>
> Thanks,
> Mohammad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/584434b8/attachment.html>

From christos at colostate.edu  Tue Sep 27 07:30:38 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Tue, 27 Sep 2016 08:30:38 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <de499102-49f9-ba73-ad21-ae841a0df0f3@ics.uci.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<369480A01F73974DAC423D05A977B4F21D4A6F7C@SJCEML701-CHM.china.huawei.com>
	<d7d975c3-6aa2-4eee-3037-d5d5aee75967@ics.uci.edu>
	<52f157a9-7448-cdf9-9349-43b969236b1e@colostate.edu>
	<de499102-49f9-ba73-ad21-ae841a0df0f3@ics.uci.edu>
Message-ID: <820f83a3-b7e6-fbd3-9087-9e57b44bcf48@colostate.edu>

Hi Gene,


On 09/26/2016 11:31 PM, GTS wrote:
> Hi Christos,
>
> indeed, there's (expected) equilibrium in CCN.
> A PIT overflow implies failure of this equilibrium. However, an attack 
> is not the
> only potential cause for a PIT overflow, right? Telling the difference 
> seems very hard.

I agree that it is very hard to determine intent  - is it a malicious 
act or a flash crowd? But is making that distinction important? The 
network should defend itself either way.

But we are diverging. The point is that NDN is a communication process 
that does not make a distinction between network infrastructure and 
applications as IP does. When communication fails it is visible to the 
entire communication chain (because the equilibrium fails).

>
> Coming back to the specific large-scale DoS issue, you originally 
> cited the recent attack where
> IP-enabled IoT devices acted as attack sources (zombies). I claim this 
> is possible in CCN
> if malware gets in before deployment; in that case, a CCN-enabled IoT 
> device can become a
> DoS *source*.
>
> The real difference I see is this:  a CCN-enabled IoT device that 
> never publishes anything (e.g., a pure actuator)
> can not be a DoS *target*.

Yup, if you do not attract any Interests (you are purely a consumer) 
then you cannot be attacked.

Christos.

>
> Cheers,
> Gene
> ======================
> Gene Tsudik
> Chancellor's Professor of Computer Science
> University of California, Irvine
>
> On 9/26/16 8:36 PM, Christos Papadopoulos wrote:
>>
>> Hi Gene,
>>
>> In NDN, with symmetric traffic and the PIT state, there is an 
>> equilibrium imposed (an Interest must be followed by a response) and 
>> more importantly, can be verified (expired or overflowed PIT state 
>> means failure of the equilibrium).
>>
>> The point is there is a signal available in NDN (failure in the 
>> equilibrium) that is not available in IP. There are very interesting 
>> research questions about how to use this signal.
>>
>> IP tried to do something similar with pushback. One problem with it 
>> was the coordination required between the routers to make pushback 
>> effective. Imagine for example, how hard it would be to coordinate at 
>> the interdomain level. In NDN a disturbance in the equilibrium can be 
>> detected locally.
>>
>> Christos.
>>
>>
>>
>> On 09/26/2016 02:34 PM, GTS wrote:
>>> I generally agree with Cedric. In CCN (i.e., NDN & CCNx), the 
>>> so-called "attack surface"
>>> will change shape but it's area will remain almost the same. In 
>>> particular, attacks
>>> such as the one Christos mentions, where IoT devices act as 
>>> mini-zombies (DoS attack sources),
>>> are unfortunately still possible. Just not in the same way...
>>>
>>> One notable item in the shifting attack surface is this: in CCN, an 
>>> end-entity (e.g., an IoT
>>> device) that only acts as a consumer (never produces anything), can 
>>> not be DoS-attacked
>>> in the usual manner, since the only way it can be "reached" is by 
>>> content that *it*
>>> has actually requested. In IP, that's certainly not the case.
>>>
>>> But, if an end-entity can request content, it can in principle be 
>>> infected by malware.^$
>>> Thus, it can still be turned into a mini-zombie. :-)
>>>
>>> Cheers,
>>> Gene
>>>
>>> $ Or, it can be infected prior to being put in service.
>>>
>>> ======================
>>> Gene Tsudik
>>> Chancellor's Professor of Computer Science
>>> University of California, Irvine
>>>
>>> On 9/26/16 11:43 AM, Cedric Westphal wrote:
>>>> That's very interesting. But since it's sent on this mailing list: would NDN be an answer to this? If the millions of IoT devices involved in the attack request a distinct object under the attacked page's prefix, it would happen exactly the same way, wouldn't it? And if all requests are for the same name, then it's the caching infrastructure of the high degree nodes that becomes attacked and shifting the attack target from akamai to a highly connected router is not a good trade-off.
>>>>
>>>> C.
>>>>
>>>> -----Original Message-----
>>>> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Christos Papadopoulos
>>>> Sent: Sunday, September 25, 2016 6:04 PM
>>>> To:ndn-interest at lists.cs.ucla.edu
>>>> Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices
>>>>
>>>> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
>>>>
>>>> Apologies if you have seen this already, but 600+Gbps DDoS attack from
>>>> IoT devices is truly remarkable. Moreover, it was *not* and reflection
>>>> attack! The target was protected by Akamai, who had to drop them (it was
>>>> hosted pro-bono) after a few days of sustained attack because it was
>>>> costing too much.
>>>>
>>>> There are a few elements that might make this event a game changer. (a)
>>>> from now on, people may want to always talk about security in IoT, (b)
>>>> it raises questions about protecting the little guy from DDoS, the
>>>> customer here found a home at Google's Project Shield, but obviously
>>>> this is not scalable, and (c) cloud protection from DDoS is not a
>>>> general solution despite what cloud providers will have you believe.
>>>>
>>>> To me such events bring to focus the weaknesses and fragility of the IP
>>>> architecture. With billions of IoT devices projected in the future, even
>>>> one packet/second (or even per minute) from a fraction of these devices
>>>> would be enough to cause real damage. We all know about the code quality
>>>> and ease of patching of IoT devices, this will not change.
>>>>
>>>> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
>>>>
>>>> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
>>>>
>>>> Christos.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>> .
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/499c1c0e/attachment.html>

From lixia at CS.UCLA.EDU  Tue Sep 27 10:13:39 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Tue, 27 Sep 2016 10:13:39 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
Message-ID: <74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>

thanks Christos for sharing this interesting news, that triggered interesting discussion. I'm trying to summarize up the exchanges in my 2 cents (not in original order), so if I missed/misinterpreted anything:

- non data producer devices dont attract attacks
- there is no reflect attack in NDN network since interest/data myst take symmetric path
- brute force interest flood need to generate random names to get sent forward, because caching dumps those attack interest with known names of existing data 
- the above suggests (anyone see a whole here?) that DDoD by interesting flooding has a unique mark of leaving in each router PIT unsatisfied PIT entries after normally expected RTT time, so this seems leaving a few things to investigate towards DDoD mitigation

a) one should constantly watch out unsatisfied PIT entries (not wait till PIT overflows)
b) one can observe the arriving patterns of these PIT entries (speed, from where)
c) one can slow down the downstream that seem only/mostly supply bad PIT, to protect other interest going through the same forwarder...

I woke up mid of night to catch up email, although the brain is cloudy, one thing still seems clear: IP router has hard time because its stateless data plate.
NDN routers, thanks to PIT, knows everything going on -- this seems "the real difference" from IP case, a great enabler for us to develop smart detection and mitigations...

and BTW the PIT was set up to serve many purposes, just "happen" to be useful for DDoS mitigation as well
this is in contrast to all other proposed IP DDoD imitation solutions that need to install *new* state into routers (and that state is only useful for DDoS but nothing else)


> On Sep 25, 2016, at 6:04 PM, Christos Papadopoulos <christos at colostate.edu> wrote:
> 
> http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
> 
> Apologies if you have seen this already, but 600+Gbps DDoS attack from IoT devices is truly remarkable. Moreover, it was *not* and reflection attack! The target was protected by Akamai, who had to drop them (it was hosted pro-bono) after a few days of sustained attack because it was costing too much.
> 
> There are a few elements that might make this event a game changer. (a) from now on, people may want to always talk about security in IoT, (b) it raises questions about protecting the little guy from DDoS, the customer here found a home at Google's Project Shield, but obviously this is not scalable, and (c) cloud protection from DDoS is not a general solution despite what cloud providers will have you believe.
> 
> To me such events bring to focus the weaknesses and fragility of the IP architecture. With billions of IoT devices projected in the future, even one packet/second (or even per minute) from a fraction of these devices would be enough to cause real damage. We all know about the code quality and ease of patching of IoT devices, this will not change.
> 
> Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
> 
> https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
> 
> Christos.
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From cghali at uci.edu  Tue Sep 27 13:49:20 2016
From: cghali at uci.edu (Cesar Ghali)
Date: Tue, 27 Sep 2016 13:49:20 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
Message-ID: <CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>

The PIT may very well serve a useful purpose in NDN/CCN. However, it creates
well-known security problems (interest flooding is trivial) and it?s highly
doubtful that a deterministic solution is possible. However, the CCN model
of communication is possible without PITs. See, e.g., [1] and [2].

[1] Content-Centric Networking Using Anonymous Datagrams: http://arxiv.org/
abs/1603.08491.
[2] Living in a PIT-less World: A Case Against Stateful Forwarding in
Content-Centric Networking: https://arxiv.org/abs/1512.07755.

Cesar

On Tue, Sep 27, 2016 at 10:13 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> thanks Christos for sharing this interesting news, that triggered
> interesting discussion. I'm trying to summarize up the exchanges in my 2
> cents (not in original order), so if I missed/misinterpreted anything:
>
> - non data producer devices dont attract attacks
> - there is no reflect attack in NDN network since interest/data myst take
> symmetric path
> - brute force interest flood need to generate random names to get sent
> forward, because caching dumps those attack interest with known names of
> existing data
> - the above suggests (anyone see a whole here?) that DDoD by interesting
> flooding has a unique mark of leaving in each router PIT unsatisfied PIT
> entries after normally expected RTT time, so this seems leaving a few
> things to investigate towards DDoD mitigation
>
> a) one should constantly watch out unsatisfied PIT entries (not wait till
> PIT overflows)
> b) one can observe the arriving patterns of these PIT entries (speed, from
> where)
> c) one can slow down the downstream that seem only/mostly supply bad PIT,
> to protect other interest going through the same forwarder...
>
> I woke up mid of night to catch up email, although the brain is cloudy,
> one thing still seems clear: IP router has hard time because its stateless
> data plate.
> NDN routers, thanks to PIT, knows everything going on -- this seems "the
> real difference" from IP case, a great enabler for us to develop smart
> detection and mitigations...
>
> and BTW the PIT was set up to serve many purposes, just "happen" to be
> useful for DDoS mitigation as well
> this is in contrast to all other proposed IP DDoD imitation solutions that
> need to install *new* state into routers (and that state is only useful for
> DDoS but nothing else)
>
>
> > On Sep 25, 2016, at 6:04 PM, Christos Papadopoulos <
> christos at colostate.edu> wrote:
> >
> > http://www.networkworld.com/article/3123672/security/
> largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html
> >
> > Apologies if you have seen this already, but 600+Gbps DDoS attack from
> IoT devices is truly remarkable. Moreover, it was *not* and reflection
> attack! The target was protected by Akamai, who had to drop them (it was
> hosted pro-bono) after a few days of sustained attack because it was
> costing too much.
> >
> > There are a few elements that might make this event a game changer. (a)
> from now on, people may want to always talk about security in IoT, (b) it
> raises questions about protecting the little guy from DDoS, the customer
> here found a home at Google's Project Shield, but obviously this is not
> scalable, and (c) cloud protection from DDoS is not a general solution
> despite what cloud providers will have you believe.
> >
> > To me such events bring to focus the weaknesses and fragility of the IP
> architecture. With billions of IoT devices projected in the future, even
> one packet/second (or even per minute) from a fraction of these devices
> would be enough to cause real damage. We all know about the code quality
> and ease of patching of IoT devices, this will not change.
> >
> > Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
> >
> > https://www.schneier.com/crypto-gram/archives/2016/0915.html#2
> >
> > Christos.
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/ddd30e29/attachment.html>

From lixia at CS.UCLA.EDU  Tue Sep 27 15:15:37 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Tue, 27 Sep 2016 15:15:37 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
Message-ID: <FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>


> On Sep 27, 2016, at 1:49 PM, Cesar Ghali <cghali at uci.edu> wrote:
> 
> The PIT may very well serve a useful purpose in NDN/CCN. However, it creates well-known security problems (interest flooding is trivial) and it?s highly doubtful that a deterministic solution is possible.

the discussion below is on how to effectively mitigate Interest flooding.
By removing PIT, one also removes a number of important functions enabled by PIT.

>  However, the CCN model of communication is possible without PITs. See, e.g., [1] and [2].
> 
> [1] Content-Centric Networking Using Anonymous Datagrams: http://arxiv.org/abs/1603.08491 <http://arxiv.org/abs/1603.08491>.
> [2] Living in a PIT-less World: A Case Against Stateful Forwarding in Content-Centric Networking: https://arxiv.org/abs/1512.07755 <https://arxiv.org/abs/1512.07755>.
> 
> Cesar
> 
> On Tue, Sep 27, 2016 at 10:13 AM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
> thanks Christos for sharing this interesting news, that triggered interesting discussion. I'm trying to summarize up the exchanges in my 2 cents (not in original order), so if I missed/misinterpreted anything:
> 
> - non data producer devices dont attract attacks
> - there is no reflect attack in NDN network since interest/data myst take symmetric path
> - brute force interest flood need to generate random names to get sent forward, because caching dumps those attack interest with known names of existing data
> - the above suggests (anyone see a whole here?) that DDoD by interesting flooding has a unique mark of leaving in each router PIT unsatisfied PIT entries after normally expected RTT time, so this seems leaving a few things to investigate towards DDoD mitigation
> 
> a) one should constantly watch out unsatisfied PIT entries (not wait till PIT overflows)
> b) one can observe the arriving patterns of these PIT entries (speed, from where)
> c) one can slow down the downstream that seem only/mostly supply bad PIT, to protect other interest going through the same forwarder...
> 
> I woke up mid of night to catch up email, although the brain is cloudy, one thing still seems clear: IP router has hard time because its stateless data plate.
> NDN routers, thanks to PIT, knows everything going on -- this seems "the real difference" from IP case, a great enabler for us to develop smart detection and mitigations...
> 
> and BTW the PIT was set up to serve many purposes, just "happen" to be useful for DDoS mitigation as well
> this is in contrast to all other proposed IP DDoD imitation solutions that need to install *new* state into routers (and that state is only useful for DDoS but nothing else)
> 
> 
> > On Sep 25, 2016, at 6:04 PM, Christos Papadopoulos <christos at colostate.edu <mailto:christos at colostate.edu>> wrote:
> >
> > http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html <http://www.networkworld.com/article/3123672/security/largest-ddos-attack-ever-delivered-by-botnet-of-hijacked-iot-devices.html>
> >
> > Apologies if you have seen this already, but 600+Gbps DDoS attack from IoT devices is truly remarkable. Moreover, it was *not* and reflection attack! The target was protected by Akamai, who had to drop them (it was hosted pro-bono) after a few days of sustained attack because it was costing too much.
> >
> > There are a few elements that might make this event a game changer. (a) from now on, people may want to always talk about security in IoT, (b) it raises questions about protecting the little guy from DDoS, the customer here found a home at Google's Project Shield, but obviously this is not scalable, and (c) cloud protection from DDoS is not a general solution despite what cloud providers will have you believe.
> >
> > To me such events bring to focus the weaknesses and fragility of the IP architecture. With billions of IoT devices projected in the future, even one packet/second (or even per minute) from a fraction of these devices would be enough to cause real damage. We all know about the code quality and ease of patching of IoT devices, this will not change.
> >
> > Maybe Bruce Schneier 's near-apocalyptic thoughts are not too far off.
> >
> > https://www.schneier.com/crypto-gram/archives/2016/0915.html#2 <https://www.schneier.com/crypto-gram/archives/2016/0915.html#2>
> >
> > Christos.
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu <mailto: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 <mailto: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/20160927/08ecb6ec/attachment.html>

From woodc1 at uci.edu  Tue Sep 27 15:59:56 2016
From: woodc1 at uci.edu (woodc1 at uci.edu)
Date: Tue, 27 Sep 2016 15:59:56 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
Message-ID: <CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>

On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu) wrote:
>
> > On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
> >
> > The PIT may very well serve a useful purpose in NDN/CCN. However, it creates well-known
> security problems (interest flooding is trivial) and it?s highly doubtful that a deterministic
> solution is possible.
>
> the discussion below is on how to effectively mitigate Interest flooding.
> By removing PIT, one also removes a number of important functions enabled by PIT.

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.

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.

Chris



From mastorakis at CS.UCLA.EDU  Tue Sep 27 16:16:33 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Tue, 27 Sep 2016 16:16:33 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
Message-ID: <FFE7E552-51EE-4862-A37F-CC3B5CDFF4D3@cs.ucla.edu>

My 2 cents on the discussion:

I agree that the network should take countermeasures to mitigate Interest flooding attacks and I believe that what you gain from the PIT state is more than the price that you have to pay.

If the flooding concerns have to do with PIT, then the PIT size of each router should be limited. If the size reaches the maximum, the router should start dropping state in the sense of erasing PIT entries to mitigate a potential flooding attack. Which entries a router should erase? Probably, the ones closer to expiration.

How exactly to do that is an open question, but this is my rough intuition.

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA

> On Sep 27, 2016, at 3:59 PM, woodc1 at uci.edu wrote:
> 
> On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu) wrote:
>> 
>>> On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
>>> 
>>> The PIT may very well serve a useful purpose in NDN/CCN. However, it creates well-known
>> security problems (interest flooding is trivial) and it?s highly doubtful that a deterministic
>> solution is possible.
>> 
>> the discussion below is on how to effectively mitigate Interest flooding.
>> By removing PIT, one also removes a number of important functions enabled by PIT.
> 
> 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.
> 
> 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.
> 
> Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/efa41aa0/attachment.html>

From christos at colostate.edu  Tue Sep 27 17:12:43 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Tue, 27 Sep 2016 18:12:43 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
Message-ID: <72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>



On 09/27/2016 04:59 PM, woodc1 at uci.edu wrote:
> On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu) wrote:
>>> On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
>>>
>>> The PIT may very well serve a useful purpose in NDN/CCN. However, it creates well-known
>> security problems (interest flooding is trivial) and it?s highly doubtful that a deterministic
>> solution is possible.
>>
>> the discussion below is on how to effectively mitigate Interest flooding.
>> By removing PIT, one also removes a number of important functions enabled by PIT.
> 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 don't understand your statement that the root cause of DDoS attacks is 
the PIT. The root cause of DDoS is resource exhaustion.

>
> 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.

Christos.

>
> Chris



From christos at colostate.edu  Tue Sep 27 17:25:01 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Tue, 27 Sep 2016 18:25:01 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <FFE7E552-51EE-4862-A37F-CC3B5CDFF4D3@cs.ucla.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<FFE7E552-51EE-4862-A37F-CC3B5CDFF4D3@cs.ucla.edu>
Message-ID: <c7f6a333-13bb-daae-de51-fc54c2947217@colostate.edu>

Spyros,

Your intuition is correct.

A DDoS attack exploits resource exhaustion at some point in the 
communication chain. What we see currently with these IoT attacks is 
that the ratio of attackers to communication resources is approaching 
infinity, thus you will not win by simply throwing more resources. The 
alternative is to manage the resources you have and control failure when 
it happens. With NDN and the PIT you have important information about 
whether communication failed, where and potentially how it failed. 
That's a much better starting point than IP.

Christos.


On 09/27/2016 05:16 PM, Spyridon (Spyros) Mastorakis wrote:
> My 2 cents on the discussion:
>
> I agree that the network should take countermeasures to mitigate 
> Interest flooding attacks and I believe that what you gain from the 
> PIT state is more than the price that you have to pay.
>
> If the flooding concerns have to do with PIT, then the PIT size of 
> each router should be limited. If the size reaches the maximum, the 
> router should start dropping state in the sense of erasing PIT entries 
> to mitigate a potential flooding attack. Which entries a router should 
> erase? Probably, the ones closer to expiration.
>
> How exactly to do that is an open question, but this is my rough 
> intuition.
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/ 
> <http://cs.ucla.edu/%7Emastorakis/>
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
>> On Sep 27, 2016, at 3:59 PM, woodc1 at uci.edu <mailto:woodc1 at uci.edu> 
>> wrote:
>>
>> On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu 
>> <mailto:lixia at cs.ucla.edu>) wrote:
>>>
>>>> On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
>>>>
>>>> The PIT may very well serve a useful purpose in NDN/CCN. However, 
>>>> it creates well-known
>>> security problems (interest flooding is trivial) and it?s highly 
>>> doubtful that a deterministic
>>> solution is possible.
>>>
>>> the discussion below is on how to effectively mitigate Interest 
>>> flooding.
>>> By removing PIT, one also removes a number of important functions 
>>> enabled by PIT.
>>
>> 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.
>>
>> 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.
>>
>> Chris
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160927/61e75d94/attachment.html>

From luca.muscariello at gmail.com  Tue Sep 27 17:54:13 2016
From: luca.muscariello at gmail.com (Luca Muscariello)
Date: Wed, 28 Sep 2016 09:54:13 +0900
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <c7f6a333-13bb-daae-de51-fc54c2947217@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<FFE7E552-51EE-4862-A37F-CC3B5CDFF4D3@cs.ucla.edu>
	<c7f6a333-13bb-daae-de51-fc54c2947217@colostate.edu>
Message-ID: <CAHx=1M6rzJ-cghpg-fasqnYBSM=fmJsLb-Db6Mt_RA_dnUQ77g@mail.gmail.com>

Hi,

I think Christos brings up an important point that helps to formalise the
problem
in its most general form.

You can optimally use the available resources, or sub-optimally use them,
mis-use them, or create damage by exhausting resources on purpose or
because of mis-configuration.

Let's take a buffer and IP (but also NDN). You can use it optimally
according to some criteria, or poorly use it, or forget a non controlled
source hitting hard a buffer that will generate damage to other conformant
sources. Or just create damage on purpose.
There are several ways to optimally use a buffer like AQMs, shaping
sources, policers etc.

In the case of the PIT I don't see much difference. You need active PIT
management to optimise the network, or you may not and need similar
mechanisms to those I cited in the case of a forwarding queue.

Removing the PIT won't save the data plane from resource saturation.
Traffic engineering, to evaluate how much resources are needed, will always
be a necessary task as well as traffic management to allocate available
resources according to some criteria: latency, throughput, fairness.

So, if we buy the proposition of removing the PIT because of resource
saturation,
we can remove the buffers too and probably unplug the cables and shut down
all the radios...

Luca















On Wed, Sep 28, 2016 at 9:25 AM, Christos Papadopoulos <
christos at colostate.edu> wrote:

> Spyros,
>
> Your intuition is correct.
>
> A DDoS attack exploits resource exhaustion at some point in the
> communication chain. What we see currently with these IoT attacks is that
> the ratio of attackers to communication resources is approaching infinity,
> thus you will not win by simply throwing more resources. The alternative is
> to manage the resources you have and control failure when it happens. With
> NDN and the PIT you have important information about whether communication
> failed, where and potentially how it failed. That's a much better starting
> point than IP.
>
> Christos.
>
> On 09/27/2016 05:16 PM, Spyridon (Spyros) Mastorakis wrote:
>
> My 2 cents on the discussion:
>
> I agree that the network should take countermeasures to mitigate Interest
> flooding attacks and I believe that what you gain from the PIT state is
> more than the price that you have to pay.
>
> If the flooding concerns have to do with PIT, then the PIT size of each
> router should be limited. If the size reaches the maximum, the router
> should start dropping state in the sense of erasing PIT entries to mitigate
> a potential flooding attack. Which entries a router should erase? Probably,
> the ones closer to expiration.
>
> How exactly to do that is an open question, but this is my rough intuition.
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
> On Sep 27, 2016, at 3:59 PM, woodc1 at uci.edu wrote:
>
> On September 27, 2016 at 3:23:14 PM, Lixia Zhang (lixia at cs.ucla.edu)
> wrote:
>
>
> On Sep 27, 2016, at 1:49 PM, Cesar Ghali wrote:
>
> The PIT may very well serve a useful purpose in NDN/CCN. However, it
> creates well-known
>
> security problems (interest flooding is trivial) and it?s highly doubtful
> that a deterministic
> solution is possible.
>
> the discussion below is on how to effectively mitigate Interest flooding.
> By removing PIT, one also removes a number of important functions enabled
> by PIT.
>
>
> 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.
>
> 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.
>
> Chris
>
>
>
>
> _______________________________________________
> 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/20160928/dbaac0f1/attachment.html>

From christopherwood07 at gmail.com  Tue Sep 27 18:47:29 2016
From: christopherwood07 at gmail.com (christopherwood07 at gmail.com)
Date: Tue, 27 Sep 2016 18:47:29 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
Message-ID: <CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>

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



From Marc.Mosko at parc.com  Tue Sep 27 19:18:53 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 28 Sep 2016 02:18:53 +0000
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
Message-ID: <6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>

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




From christos at colostate.edu  Tue Sep 27 19:49:59 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Tue, 27 Sep 2016 20:49:59 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
Message-ID: <b0eade32-0704-b39f-cee5-79c8e5a6c7cc@colostate.edu>



On 09/27/2016 07:47 PM, 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.

You are still thinking in IP terms. In NDN data follows demand; data 
diffuses in the network pulled by Interests over all available faces. If 
an attacker manages to attack all available paths to your content 
without attacking the entire infrastructure, then I claim you deployed a 
bad defense system.

>
>> 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.

Then you are looking at a subset of DDoS attacks. There are others that 
exhaust link bandwidth or compute resources. Why is the PIT the only bad 
guy here?

>
>>> 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.

I am not sure where you are going here. All public resources can be 
abused. The question is how do you build a good resource management 
system to detect and mitigate resource abuse. Luca put it nicely, i 
suggest you read his message.

Christos.

>
> Chris



From susmit at cs.colostate.edu  Tue Sep 27 19:51:15 2016
From: susmit at cs.colostate.edu (Susmit)
Date: Tue, 27 Sep 2016 20:51:15 -0600
Subject: [Ndn-interest] 3rd NDN Hackathon: Call for Participation
Message-ID: <CAM4XVko_otbwJTb7uq63W65B+QTY43QQFz2zUaFU9hc9qKqbLA@mail.gmail.com>

======================================
CALL FOR PROPOSALS
The 3rd Named Data Networking (NDN) Hackathon
November 4-5th, Colorado State University, Fort Collins, CO
======================================

------------------------------------------
IMPORTANT DATES
------------------------------------------
Submission deadline: October 26, 2016
Acceptance notification: October 31, 2016

------------------------------------------
WEBSITE
------------------------------------------
http://3rd-ndn-hackathon.named-data.net

------------------------------------------
Call for Hacks
------------------------------------------

The NDN team is organizing our 3rd NDN hackathon that is going to be held on
November 4-5th, 2016 at Colorado State University, Fort Collins, CO.
We solicit hackathon proposals that will advance the state of NDN.
Participants will have approximately **12 hours** to work on their projects.

We encourage projects that:

 - directly address NDN research needs,
 - create new NDN tools or modify existing tools,
 - create or improve documentation and how-to guides.

------------------------------------------
SUBMISSION GUIDELINES
------------------------------------------

Proposals should be submitted via email to <3rd-ndn-hackathon at named-data.net>.
Submission templates are available on the hackathon website.

The submissions should include:

- 1 page description PDF, including contact information of submitter
  and project leader(s), problem statement, approach, contribution to
  NDN, planned tasks to accomplish, knowledge requirements, and what is
  the expected outcome by the end of the hackathon.

- 1 or 2 PPTx slides, listing the project leader(s) and summarizing the
  problem, contribution, tasks, required knowledge, and expected outcome.

All submitted proposals will be reviewed by the hacking Committee.
If accepted, the project leader is expected to give a 5 minute ?pitch?
presentation at the beginning of the Hackathon, soliciting participation
from attendees.

Projects will be judged by a panel for the "Best of Hackathon" prize. We
hope that this hackathon will be a fun event for everyone and that projects
will lead to collaborations extending beyond the hackathon.

We look forward to your participation in the hackathon.



From cghali at uci.edu  Tue Sep 27 20:31:41 2016
From: cghali at uci.edu (Cesar Ghali)
Date: Tue, 27 Sep 2016 20:31:41 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <b0eade32-0704-b39f-cee5-79c8e5a6c7cc@colostate.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<b0eade32-0704-b39f-cee5-79c8e5a6c7cc@colostate.edu>
Message-ID: <CAAj99Km7nvumbRwMOhqgZFLjCMbCFtqJ=f5PhGhjFQq5CdY_KA@mail.gmail.com>

This is an interesting topic and I'm sure Chris read Luca's message before
he responded. Exhausting link bandwidth or computing resource is a problem
in today's network, and, as far as I know, all proposed future Internet
architectures. Since the PIT is a new player here (this doesn't mean it is
the bad guy or the only bad guy) and it introduces a new problem that
didn't exist before, it might be helpful to take a step back and reassess
design decisions. Especially that proposed countermeasures do not solve the
problem and can be bypassed by smart adversaries.

On Tue, Sep 27, 2016 at 7:49 PM, Christos Papadopoulos <
christos at colostate.edu> wrote:

>
>
> On 09/27/2016 07:47 PM, 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.
>>
>
> You are still thinking in IP terms. In NDN data follows demand; data
> diffuses in the network pulled by Interests over all available faces. If an
> attacker manages to attack all available paths to your content without
> attacking the entire infrastructure, then I claim you deployed a bad
> defense system.
>
>
>> 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.
>>
>
> Then you are looking at a subset of DDoS attacks. There are others that
> exhaust link bandwidth or compute resources. Why is the PIT the only bad
> guy here?


>
>
>> 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.
>>
>
> I am not sure where you are going here. All public resources can be
> abused. The question is how do you build a good resource management system
> to detect and mitigate resource abuse. Luca put it nicely, i suggest you
> read his message.
>
> Christos.
>
>
>
>> Chris
>>
>
> _______________________________________________
> 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/20160927/23c17d16/attachment.html>

From christos at colostate.edu  Tue Sep 27 20:59:10 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Tue, 27 Sep 2016 21:59:10 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAAj99Km7nvumbRwMOhqgZFLjCMbCFtqJ=f5PhGhjFQq5CdY_KA@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<b0eade32-0704-b39f-cee5-79c8e5a6c7cc@colostate.edu>
	<CAAj99Km7nvumbRwMOhqgZFLjCMbCFtqJ=f5PhGhjFQq5CdY_KA@mail.gmail.com>
Message-ID: <c1ba100f-7773-8bcd-2bfe-d775e2b55780@colostate.edu>

Hi Cesar,

If the PIT were to be added to IP then I would agree with what you say 
below. But this is NDN. You cannot just pick on the PIT ignoring the 
rest of the architecture.

Christos.



On 09/27/2016 09:31 PM, Cesar Ghali wrote:
> This is an interesting topic and I'm sure Chris read Luca's message 
> before he responded. Exhausting link bandwidth or computing resource 
> is a problem in today's network, and, as far as I know, all proposed 
> future Internet architectures. Since the PIT is a new player here 
> (this doesn't mean it is the bad guy or the only bad guy) and it 
> introduces a new problem that didn't exist before, it might be helpful 
> to take a step back and reassess design decisions. Especially that 
> proposed countermeasures do not solve the problem and can be bypassed 
> by smart adversaries.
>
> On Tue, Sep 27, 2016 at 7:49 PM, Christos Papadopoulos 
> <christos at colostate.edu <mailto:christos at colostate.edu>> wrote:
>
>
>
>     On 09/27/2016 07:47 PM, christopherwood07 at gmail.com
>     <mailto:christopherwood07 at gmail.com> wrote:
>
>         On September 27, 2016 at 5:14:14 PM, Christos Papadopoulos
>         (christos at colostate.edu <mailto:christos at colostate.edu>) wrote:
>
>
>             On 09/27/2016 04:59 PM, woodc1 at uci.edu
>             <mailto: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.
>
>
>     You are still thinking in IP terms. In NDN data follows demand;
>     data diffuses in the network pulled by Interests over all
>     available faces. If an attacker manages to attack all available
>     paths to your content without attacking the entire infrastructure,
>     then I claim you deployed a bad defense system.
>
>
>             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.
>
>
>     Then you are looking at a subset of DDoS attacks. There are others
>     that exhaust link bandwidth or compute resources. Why is the PIT
>     the only bad guy here? 
>
>
>
>
>                 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.
>
>
>     I am not sure where you are going here. All public resources can
>     be abused. The question is how do you build a good resource
>     management system to detect and mitigate resource abuse. Luca put
>     it nicely, i suggest you read his message.
>
>     Christos.
>
>
>
>         Chris
>
>
>     _______________________________________________
>     Ndn-interest mailing list
>     Ndn-interest at lists.cs.ucla.edu <mailto: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/20160927/da083bdc/attachment.html>

From luca.muscariello at gmail.com  Tue Sep 27 22:12:41 2016
From: luca.muscariello at gmail.com (Luca Muscariello)
Date: Wed, 28 Sep 2016 14:12:41 +0900
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
Message-ID: <CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/aa2cc235/attachment.html>

From s.h.ahmed at ieee.org  Tue Sep 27 22:58:21 2016
From: s.h.ahmed at ieee.org (Syed Hassan Ahmed)
Date: Wed, 28 Sep 2016 14:58:21 +0900
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
Message-ID: <4277EC06-5DE3-4821-A085-2AD5BAEFD9DB@ieee.org>

Hi, 

I'm wondering if we could use PIT with dynamic entry lifetime? To be precise, it would be better to have some criteria to let application decide that how long an interest should live inside the PIT and upon time expiration, retransmission techniques can be moderately designed.

Through this way, somehow the "design" will be maintained regarding "PIT" existence. 

Best Regards,
Syed Hassan Ahmed. (??)
Kyungpook National University,
Daegu, Republic of Korea. 
https://sites.google.com/site/shahmedknu/

> On Sep 28, 2016, at 2:12 PM, Luca Muscariello <luca.muscariello at gmail.com> 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 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/20160928/7bbef6a6/attachment.html>

From paul.a.bellamy at gmail.com  Wed Sep 28 01:55:00 2016
From: paul.a.bellamy at gmail.com (Paul Bellamy)
Date: Wed, 28 Sep 2016 08:55:00 +0000
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <mailman.66.1475039570.418.ndn-interest@lists.cs.ucla.edu>
References: <mailman.66.1475039570.418.ndn-interest@lists.cs.ucla.edu>
Message-ID: <CAD6L7P+owAPo5OvDoMrxEDM1xKTAbk9jAb2mNdD32Q9pG36Adg@mail.gmail.com>

One the invariants of a DoS is that there are a lot of packets depleting
the resources of a single target physical machine. Which means we can
prevent it in two ways. Given that, there are several potential solutions
which jump to my mind:

1) Reject bad-actors sending lots of packets. Would work against a DoS, but
not a DDos, as each individual actor is sending a reasonable amount of
packets.

2) Stop too many packets reaching the single target. During
resource-exhaustion we could purge PIT entries with similar prefixes. The
nature of the flooded interests means they should all have a similar
prefix. We could limit the number of outstanding interests for a given
prefix.

3) Scale up the target. IMO, one of the big advantages of NDN for
service-operators is that (unlike IP) interests don't have to be answered
by any specific physical machine. If you've designed your application well,
you can easily add more capacity. This is "good enough", until you run into
cost-constraints.

Of those, a combination of 2 and 3 seem the most practical.

Regards,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/2b84bbe0/attachment.html>

From Cedric.Westphal at huawei.com  Wed Sep 28 12:43:07 2016
From: Cedric.Westphal at huawei.com (Cedric Westphal)
Date: Wed, 28 Sep 2016 19:43:07 +0000
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAD6L7P+owAPo5OvDoMrxEDM1xKTAbk9jAb2mNdD32Q9pG36Adg@mail.gmail.com>
References: <mailman.66.1475039570.418.ndn-interest@lists.cs.ucla.edu>,
	<CAD6L7P+owAPo5OvDoMrxEDM1xKTAbk9jAb2mNdD32Q9pG36Adg@mail.gmail.com>
Message-ID: <etPan.57ec1d49.7a74db3e.171c@localhost>

Hi,

regarding 3), it's probably too late once your under attack. Note that in this case, it's Akamai that was attacked, and even though they have more capacity to spread out the attack, the server still went down.

regarding 2), many people have made this content that NDN requires flow balance and that measuring flow imbalance tells you about attack. There is information in the unsatisfied interests. That is true, but that information is noisy and more importantly, relying on it means it becomes a new vector of attacks.

Consider a few nodes spraying interests for non existing objects. The router will see a flow imbalance, and will shut down traffic, but it can't discriminate between valid traffic and attack. Attack succeeds. This is different from flooding the PIT, since it only attacks the monitoring of the flow imbalance and the router stops forwarding not under PIT exhaustion but from its observation of unsatisfied interests.

New features enabled by PIT are also new risks.

C.

Sent from HUAWEI AnyOffice
From:Paul Bellamy
To:ndn-interest at lists.cs.ucla.edu,
Date:2016-09-28 01:57:52
Subject:Re: [Ndn-interest] Largest DDoS attack ever delivered by botnet of hijacked IoT devices

One the invariants of a DoS is that there are a lot of packets depleting the resources of a single target physical machine. Which means we can prevent it in two ways. Given that, there are several potential solutions which jump to my mind:

1) Reject bad-actors sending lots of packets. Would work against a DoS, but not a DDos, as each individual actor is sending a reasonable amount of packets.

2) Stop too many packets reaching the single target. During resource-exhaustion we could purge PIT entries with similar prefixes. The nature of the flooded interests means they should all have a similar prefix. We could limit the number of outstanding interests for a given prefix.

3) Scale up the target. IMO, one of the big advantages of NDN for service-operators is that (unlike IP) interests don't have to be answered by any specific physical machine. If you've designed your application well, you can easily add more capacity. This is "good enough", until you run into cost-constraints.

Of those, a combination of 2 and 3 seem the most practical.

Regards,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/d2caeadc/attachment.html>

From gts at ics.uci.edu  Wed Sep 28 13:26:21 2016
From: gts at ics.uci.edu (GTS)
Date: Wed, 28 Sep 2016 13:26:21 -0700
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
Message-ID: <55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>

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 
> <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160928/fe0679e8/attachment.html>

From christos at colostate.edu  Wed Sep 28 13:30:38 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Wed, 28 Sep 2016 14:30:38 -0600
Subject: [Ndn-interest] Largest DDoS attack ever delivered by botnet of
 hijacked IoT devices
In-Reply-To: <etPan.57ec1d49.7a74db3e.171c@localhost>
References: <mailman.66.1475039570.418.ndn-interest@lists.cs.ucla.edu>
	<CAD6L7P+owAPo5OvDoMrxEDM1xKTAbk9jAb2mNdD32Q9pG36Adg@mail.gmail.com>
	<etPan.57ec1d49.7a74db3e.171c@localhost>
Message-ID: <072ee071-b69b-cf8e-60d3-07654aedb00d@colostate.edu>

Hi Cedric,


On 09/28/2016 01:43 PM, Cedric Westphal wrote:
> Hi,
>
> regarding 3), it's probably too late once your under attack. Note that 
> in this case, it's Akamai that was attacked, and even though they have 
> more capacity to spread out the attack, the server still went down.
>
> regarding 2), many people have made this content that NDN requires 
> flow balance and that measuring flow imbalance tells you about attack. 
> There is information in the unsatisfied interests. That is true, but 
> that information is noisy and more importantly, relying on it means it 
> becomes a new vector of attacks.
>
> Consider a few nodes spraying interests for non existing objects. The 
> router will see a flow imbalance, and will shut down traffic, but it 
> can't discriminate between valid traffic and attack. Attack succeeds. 
> This is different from flooding the PIT, since it only attacks the 
> monitoring of the flow imbalance and the router stops forwarding not 
> under PIT exhaustion but from its observation of unsatisfied interests.

I am not sure why the single router failure scenario keeps coming up, 
but I will try this one last time. The attack *will* succeed (at least 
the type of attacks we have been discussing here) to bring down one or 
more routers. NDN, however, enables you to manage communication failure. 
In one example, we may allow routers in networks with many attackers to 
overload and fail by controlling the PIT size. That would have the 
policy effect of higher collateral damage in networks with high 
infection rate. No single policy will work for all cases, so other 
policies are also possible.

There is noting magical about NDN that will thwart all DDoS attacks (as 
much as I like unicorns). You can have crappy designs in NDN, just like 
any other architecture. As with any other system there are tradeoffs and 
compromises. The fundamental question, IMHO, is which architecture 
allows you to make the best tradeoffs. I put my money on the one that 
provides better feedback.

Christos.

>
> New features enabled by PIT are also new risks.
>
> C.
>
> Sent from HUAWEI AnyOffice
> *From:*Paul Bellamy
> *To:*ndn-interest at lists.cs.ucla.edu,
> *Date:*2016-09-28 01:57:52
> *Subject:*Re: [Ndn-interest] Largest DDoS attack ever delivered by 
> botnet of hijacked IoT devices
>
> One the invariants of a DoS is that there are a lot of packets 
> depleting the resources of a single target physical machine. Which 
> means we can prevent it in two ways. Given that, there are several 
> potential solutions which jump to my mind:
>
> 1) Reject bad-actors sending lots of packets. Would work against a 
> DoS, but not a DDos, as each individual actor is sending a reasonable 
> amount of packets.
>
> 2) Stop too many packets reaching the single target. During 
> resource-exhaustion we could purge PIT entries with similar prefixes. 
> The nature of the flooded interests means they should all have a 
> similar prefix. We could limit the number of outstanding interests for 
> a given prefix.
>
> 3) Scale up the target. IMO, one of the big advantages of NDN for 
> service-operators is that (unlike IP) interests don't have to be 
> answered by any specific physical machine. If you've designed your 
> application well, you can easily add more capacity. This is "good 
> enough", until you run into cost-constraints.
>
> Of those, a combination of 2 and 3 seem the most practical.
>
> Regards,
> Paul
>
>
> _______________________________________________
> 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/20160928/cce1c012/attachment.html>

From Marc.Mosko at parc.com  Wed Sep 28 14:56:23 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 28 Sep 2016 21:56:23 +0000
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack ever
 delivered by botnet of hijacked IoT devices)
In-Reply-To: <55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
Message-ID: <77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>

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<mailto: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<mailto: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 list
Ndn-interest at lists.cs.ucla.edu<mailto: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/20160928/558b4e92/attachment.html>

From ravi.ravindran at gmail.com  Wed Sep 28 16:57:59 2016
From: ravi.ravindran at gmail.com (Ravi Ravindran)
Date: Wed, 28 Sep 2016 16:57:59 -0700
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
Message-ID: <CAGhfKze=gWnoZ+6DHxcVbueYUQxhpDYszP9DtM4t5ZhL0FZmFA@mail.gmail.com>

Interesting discussion on various aspects of PIT. Just wanted to add that,
usefulness of PIT should also seen in the light of real-time communication
where latency is very critical. In such systems one would pre-fetch content
even before it is produced (to achieve a PUSH effect). In the Audio/Video
conferencing system we build (
http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p217-chakraborti.pdf),
and also NDN-Conf uses this feature. In such situations multicasting is
more at play here than caching, caching is more useful in case of packet
loss during the transit.
On the topic of PITless design, we have a paper coming up in this year's
Globecomm on this topic ("pit/LESS: Stateless Forwarding in Content Centric
Networks"). IMO, these solutions are more useful to realize CCN/NDN
protocol on programmable data planes like P4/PoF where the current
forwarder/control plane abstractions are not efficient to support
per-packet statefull forwarding. From a deployment perspective, we can
envision such a data plane supporting high speed name-based forwarding with
statefull forwarding restricted only to the network edge.

Regards,
Ravi

On Wed, Sep 28, 2016 at 2:56 PM, <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/20160928/1a5ad32a/attachment.html>

From Marc.Mosko at parc.com  Wed Sep 28 17:05:11 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Thu, 29 Sep 2016 00:05:11 +0000
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <CAGhfKze=gWnoZ+6DHxcVbueYUQxhpDYszP9DtM4t5ZhL0FZmFA@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAGhfKze=gWnoZ+6DHxcVbueYUQxhpDYszP9DtM4t5ZhL0FZmFA@mail.gmail.com>
Message-ID: <83EC8197-70F9-4595-B734-CF579CE6EAAA@parc.com>

That is another interesting aspect that I think works better without a PIT than with a PIT.  If one wants to use ?interests as subscriptions?, i.e. ask for something with an unknown delay to service possibly because it is not created yet, then putting some large number in the PIT reserves resources on every hop for that time.  In a PIT-less architecture, only the producer needs to track the consumers that are asking for it.

On the other hand, this is a situation where interest aggregation would work well (and I think is the situation it was originally designed for), assuming one was ok with reserving those resources at every hop for the potentially very long Interest Lifetime.

The other approach that has been proposed by several people is to treat the Interest for a long delay thing more like a TCP segment and send back a data ?ack? that says ?wait for X seconds? and then have the consumer retry.

Marc

On Sep 29, 2016, at 8:57 AM, Ravi Ravindran <ravi.ravindran at gmail.com<mailto:ravi.ravindran at gmail.com>> wrote:

Interesting discussion on various aspects of PIT. Just wanted to add that, usefulness of PIT should also seen in the light of real-time communication where latency is very critical. In such systems one would pre-fetch content even before it is produced (to achieve a PUSH effect). In the Audio/Video conferencing system we build (http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p217-chakraborti.pdf), and also NDN-Conf uses this feature. In such situations multicasting is more at play here than caching, caching is more useful in case of packet loss during the transit.
On the topic of PITless design, we have a paper coming up in this year's Globecomm on this topic ("pit/LESS: Stateless Forwarding in Content Centric Networks"). IMO, these solutions are more useful to realize CCN/NDN protocol on programmable data planes like P4/PoF where the current forwarder/control plane abstractions are not efficient to support per-packet statefull forwarding. From a deployment perspective, we can envision such a data plane supporting high speed name-based forwarding with statefull forwarding restricted only to the network edge.

Regards,
Ravi

On Wed, Sep 28, 2016 at 2:56 PM, <Marc.Mosko at parc.com<mailto: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<mailto: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<mailto: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 list
Ndn-interest at lists.cs.ucla.edu<mailto: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<mailto: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/3c225ec3/attachment.html>

From luca.muscariello at gmail.com  Wed Sep 28 17:47:01 2016
From: luca.muscariello at gmail.com (Luca Muscariello)
Date: Thu, 29 Sep 2016 09:47:01 +0900
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
Message-ID: <CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>

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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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.edu <javascript:_e(%7B%7D,'cvml','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/15e1f412/attachment.html>

From Marc.Mosko at parc.com  Wed Sep 28 18:10:18 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Thu, 29 Sep 2016 01:10:18 +0000
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
Message-ID: <7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>

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<mailto: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<mailto: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<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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 list
Ndn-interest at lists.cs.ucla.edu<javascript:_e(%7B%7D,'cvml','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/935cd0f5/attachment.html>

From luca.muscariello at gmail.com  Wed Sep 28 19:19:26 2016
From: luca.muscariello at gmail.com (Luca Muscariello)
Date: Thu, 29 Sep 2016 11:19:26 +0900
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
	<7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
Message-ID: <CAHx=1M60u79q-xitAB__vvA+CJFEnBMJBdMYwDoQDF9DB54k7w@mail.gmail.com>

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> 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
>>
>> 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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160929/f5933aec/attachment.html>

From NourElHouda.BenYoussef at wevioo.com  Thu Sep 29 02:40:26 2016
From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef)
Date: Thu, 29 Sep 2016 09:40:26 +0000
Subject: [Ndn-interest] ndn replication strategy
Message-ID: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>

Dear ndn users,

I was wondering which replication strategy does ndn use?

Since a copy of content is stored along the path, can it be considered as LCE (leave copy everywhere) strategy ?

Best regards





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160929/070ef1ba/attachment.html>

From Matteo.Bertolino at eurecom.fr  Thu Sep 29 03:33:10 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Thu, 29 Sep 2016 12:33:10 +0200
Subject: [Ndn-interest] ndn replication strategy
In-Reply-To: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
References: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
Message-ID: <20160929123310.f9ahyfch6sk0s88c@webmail.eurecom.fr>

I think that you can decide the placement strategy.
By default, it is LCE, that's true.
I advice you to read the NDN survey that analyse this issue (page 8):
http://www1.deeds.informatik.tu-darmstadt.de/External/PublicationData/0/NDN-Survey-Final.pdf

matteo

Quoting Nour El Houda Ben Youssef <NourElHouda.BenYoussef at wevioo.com>:

> Dear ndn users,
>
> I was wondering which replication strategy does ndn use?
>
> Since a copy of content is stored along the path, can it be   
> considered as LCE (leave copy everywhere) strategy ?
>
> Best regards
>
>
>
>
>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From ibrojay01 at gmail.com  Thu Sep 29 04:05:45 2016
From: ibrojay01 at gmail.com (Ibrahim ABDULLAHI)
Date: Thu, 29 Sep 2016 19:05:45 +0800
Subject: [Ndn-interest] ndn replication strategy
In-Reply-To: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
References: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
Message-ID: <CAOV5UZ38ngVEPaVKwdVRRa-STFpY6+9FYN6E4fCdpPSA_JnCKQ@mail.gmail.com>

Dear Nour,
Yes LCE could be one of the strategies for the cache nature of NDN.
However, it all depends on the deployment particularly the network setting.
MCD, ProbCache are all good options.

On Sep 29, 2016 5:40 PM, "Nour El Houda Ben Youssef" <
NourElHouda.BenYoussef at wevioo.com> wrote:

> Dear ndn users,
>
>
>
> I was wondering which replication strategy does ndn use?
>
>
>
> Since a copy of content is stored along the path, can it be considered as
> LCE (leave copy everywhere) strategy ?
>
>
>
> Best regards
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/ef6d9df8/attachment.html>

From NourElHouda.BenYoussef at wevioo.com  Thu Sep 29 04:32:37 2016
From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef)
Date: Thu, 29 Sep 2016 11:32:37 +0000
Subject: [Ndn-interest] ndn replication strategy
In-Reply-To: <CAOV5UZ38ngVEPaVKwdVRRa-STFpY6+9FYN6E4fCdpPSA_JnCKQ@mail.gmail.com>
References: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
	<CAOV5UZ38ngVEPaVKwdVRRa-STFpY6+9FYN6E4fCdpPSA_JnCKQ@mail.gmail.com>
Message-ID: <712FE4E7257849499414892DD92704BC7A9B6A73@INFRAEX02.oxia.corp>

Thank you for your reply
what do you exactly mean by MCD?

Best regards

De : Ibrahim ABDULLAHI [mailto:ibrojay01 at gmail.com]
Envoy? : jeudi 29 septembre 2016 12:06
? : Nour El Houda Ben Youssef
Cc : ndn-interest at lists.cs.ucla.edu
Objet : Re: [Ndn-interest] ndn replication strategy


Dear Nour,
Yes LCE could be one of the strategies for the cache nature of NDN. However, it all depends on the deployment particularly the network setting. MCD, ProbCache are all good options.

On Sep 29, 2016 5:40 PM, "Nour El Houda Ben Youssef" <NourElHouda.BenYoussef at wevioo.com<mailto:NourElHouda.BenYoussef at wevioo.com>> wrote:
Dear ndn users,

I was wondering which replication strategy does ndn use?

Since a copy of content is stored along the path, can it be considered as LCE (leave copy everywhere) strategy ?

Best regards






_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto: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/335505da/attachment.html>

From christos at colostate.edu  Thu Sep 29 07:11:09 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Thu, 29 Sep 2016 08:11:09 -0600
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <CAHx=1M60u79q-xitAB__vvA+CJFEnBMJBdMYwDoQDF9DB54k7w@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
	<7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
	<CAHx=1M60u79q-xitAB__vvA+CJFEnBMJBdMYwDoQDF9DB54k7w@mail.gmail.com>
Message-ID: <36a6cfe3-4af6-c9b2-bdbf-e14db22fef66@colostate.edu>

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

http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/

Christos.



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>

From ibrojay01 at gmail.com  Thu Sep 29 04:59:24 2016
From: ibrojay01 at gmail.com (Ibrahim ABDULLAHI)
Date: Thu, 29 Sep 2016 19:59:24 +0800
Subject: [Ndn-interest] ndn replication strategy
In-Reply-To: <CAOV5UZ3FQfOfHB-kYzsJzC7D8wtpSHbuWk1H9ZuUyFKt+yDOcg@mail.gmail.com>
References: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
	<CAOV5UZ38ngVEPaVKwdVRRa-STFpY6+9FYN6E4fCdpPSA_JnCKQ@mail.gmail.com>
	<712FE4E7257849499414892DD92704BC7A9B6A73@INFRAEX02.oxia.corp>
	<CAOV5UZ3FQfOfHB-kYzsJzC7D8wtpSHbuWk1H9ZuUyFKt+yDOcg@mail.gmail.com>
Message-ID: <CAOV5UZ1p4LAueomGxvpD3ScAj4av=KNkr56sgF+pfPdh7j9MEQ@mail.gmail.com>

As replied

On Sep 29, 2016 7:57 PM, "Ibrahim ABDULLAHI" <ibrojay01 at gmail.com> wrote:

> Move Copy Down. Even thou it can be thought of in another perspective due
> to its plus in carefully reducing the amount of redundant or replica
> content cache.
>
> All the best
>
> On Sep 29, 2016 7:32 PM, "Nour El Houda Ben Youssef" <
> NourElHouda.BenYoussef at wevioo.com> wrote:
>
>> Thank you for your reply
>>
>> what do you exactly mean by MCD?
>>
>>
>>
>> Best regards
>>
>>
>>
>> *De :* Ibrahim ABDULLAHI [mailto:ibrojay01 at gmail.com]
>> *Envoy? :* jeudi 29 septembre 2016 12:06
>> *? :* Nour El Houda Ben Youssef
>> *Cc :* ndn-interest at lists.cs.ucla.edu
>> *Objet :* Re: [Ndn-interest] ndn replication strategy
>>
>>
>>
>> Dear Nour,
>> Yes LCE could be one of the strategies for the cache nature of NDN.
>> However, it all depends on the deployment particularly the network setting.
>> MCD, ProbCache are all good options.
>>
>>
>>
>> On Sep 29, 2016 5:40 PM, "Nour El Houda Ben Youssef" <
>> NourElHouda.BenYoussef at wevioo.com> wrote:
>>
>> Dear ndn users,
>>
>>
>>
>> I was wondering which replication strategy does ndn use?
>>
>>
>>
>> Since a copy of content is stored along the path, can it be considered as
>> LCE (leave copy everywhere) strategy ?
>>
>>
>>
>> Best regards
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/21a458a8/attachment.html>

From ravi.ravindran at gmail.com  Thu Sep 29 15:57:14 2016
From: ravi.ravindran at gmail.com (Ravi Ravindran)
Date: Thu, 29 Sep 2016 15:57:14 -0700
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
Message-ID: <CAGhfKzdG+UrMDKebipgV8R6BbXGZf3S=cbtaahayc7mmeCZSYw@mail.gmail.com>

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>

From mhasabet at gmail.com  Thu Sep 29 17:19:49 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Fri, 30 Sep 2016 09:19:49 +0900
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
	<7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
Message-ID: <CADQ0MFYeRSyR4pkonqFCR0M6UpxpE50ypsdCW5kB0fW1yON_7Q@mail.gmail.com>

Marc,

There is nothing in JJ's latter proposal in ICN 2016 indicating anchors'
identifiers are not anchors' names. Actually the namespaces could be the
same. So name lookup can still hold.

Thanks,
Sabet

On 29 Sep 2016 10:11 am, <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>
> 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/20160930/cf118c56/attachment.html>