[Ndn-interest] NACK

GTS gts at ics.uci.edu
Tue Jun 28 02:20:03 PDT 2016

One can choose to require a router to generate a NACK in this case. 
However, if this is a
communication/transmission error, it's best for the consumer to timeout 
and resend the interest.
Otherwise, it could be due to:
(1) an implementation bug at either router or consumer -- probably best 
left alone,
(2) an attack -- adversary feeds incorrect content to router. If this is 
an on-path adversary
(e.g., a subverted/malicious upstream router), sending a NACK is 
useless. A router that
detects the error is better off trying another route.

Another issue is how to secure the NACK itself. If not secured, this 
kind of NACK can be
used as a DoS attack (anyone can generate it). If secured (e.g., 
signed), the originating
router would incur some non-negligible computational burden.


p.s. FYI, for a discussion of some NACK-related issues in ICN, take a 
look at:
or http://arxiv.org/pdf/1503.02123.pdf

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

On 6/28/16 1:47 AM, Tanusree Chatterjee wrote:
> If a data packet is modified and detected during verification, can 
> forwarder send a NACK. How the data can be resend in this case? If 
> consumer is not satisfied it has to send the same interest again, is 
> there any other way out to get the data which may not been correctly 
> received due to some modification.Â
> -- Regards,
> Tanusree Chatterjee
> _______________________________________________
> 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/20160628/1f23c949/attachment.html>

More information about the Ndn-interest mailing list