[Ndn-interest] NACKs in ICN

[Cesar Ghali]

Hi Marc,

The experiments that we did in Section IV.E were to measure the
performance of serving existing content by a producer under cnacks DoS
attack. Benign consumers always request existing content, and at the
same time, malicious consumers are requesting non-existing content
forcing the producer to generate and sign cnacks. We only measure the
time required by the producer to reply to interests by benign consumers.
The more non-sensical interests processed by the producer the more time
it needs to process interests requesting existing content. Specifically
the increased time of processing benign consumers interests is because
the producer is busy with signing a lot of cnacks.

Also in this case, the producer is serving per-generated static content
objects, i.e. no run-time signing of existing content.

Thanks,
Cesar


On 03/10/2015 09:09 AM, Marc.Mosko at parc.com wrote:
> I’ll second Mark’s opinion that it’s great to get a lot of these issues with cnacks and fnacks written up and public.  
> 
> I agree that cnaks pose potential computational DoS attacks and when cached content DoS.  As to a solution to safely use cnacks, I think it will depend a lot on how the interests are being used.  For example, using Interests for content discovery where you issue a long-standing interest waiting for the next item would probably use a different cnack approach than someone trying to do something else.  
> 
> I think in the case of fnacks, having a secure neighbor protocol and local key exchange in ccnx/ndn would go a long way towards making fnacks practical.  This seems like a much lower barrier than cnacks.
> 
> In section IV.E (experimenting with cnacks), did this include an signing time too or was it from cache pollution?  It wasn’t clear what specifically contributed to the increased time.
> 
> Also, if a producer will issue a cnack for plausible content and not random names, isn’t that a big information leak for someone name scanning?  That’s like a firewall sending an ICMP packets to let a hacker know when they’re on the right track (well, I guess its the opposite, as a bad firewall sending prohibited is for bad ports and a cnack for a plausible name is for a good name).
> 
> Marc
> 
> On Mar 10, 2015, at 7:15 AM, Mark Stapp <mjs at cisco.com> wrote:
> 
>> Thanks for sending this around, Cesar. It's certainly good to see some details confirming the intuition that it would be costly for producers to try to use public-key operations on adversary-selected inputs as a means of denial-of-existence. but ... the paper doesn't explore many alternative schemes - we presented five, I think, at the last icnrg meeting. the conclusion of the paper - that NACKs have security problems - seems a little strong, based on the small number of approaches considered.
>>
>> It would be very interesting to see whether your analytical tools might be able to be applied to some of the other approaches.
>>
>> Thanks,
>> Mark
>>
>> On 3/9/15 9:14 PM, Cesar Ghali wrote:
>>> Hi all,
>>>
>>> Some of you might be interested in the following report:
>>>
>>> A. Compagno, M. Conti, C. Ghali, G. Tsudik,
>>> To NACK or not to NACK? Negative Acknowledgments in Information-Centric
>>> Networking,
>>> arXiv: 1503.02123, March 7, 2015.
>>> URL: http://arxiv.org/pdf/1503.02123v1.pdf
>>>
>>> Of course, comments are appreciated.
>>>
>>> Thanks,
>>> Cesar
>>>
>>> --
>>> PGP Key: http://www.cesarghali.info/contact.html
>>> PGP Key ID: 0x455D8052
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 


-- 
cesarghali.info