[Ndn-interest] NACK

[Alex Afanasyev]

There are cases when router can do some verification, including when router and client share the trust model or the interest carried the verification key and the router is willing to do crypto checks, or the interest carried full name, including the implicit digest of data.

What to do when the previously sent interest retrieved a data packet that cannot satisfy the interest depends on the forwarding strategy.  The strategy can try retrieve again, either using different interface and/or specifying the exclude filter.  The strategy can also give up retrieving data and send network NACK (interest return) back downstream.  The downstream router, receiving the NACK, can invoke its forwarding strategy actions and/or give up, sending its own NACK back.

Note that this, potentially cascading, hop-by-hop network NACK mechanism does not create new security problems when links between routers are point-to-point.   In multi-access cases, network NACKs indeed pose a problem and I'm not sure about a good way to handle this except timeout.

---
Alex

> On Jun 28, 2016, at 10:57 AM, Marc.Mosko at parc.com wrote:
> 
> I disagree about the “lower layer” statement.  A fair number of errors do make their way past layer 2.  While Ethernet with reasonable MTUs will have an “age of the universe” error rate, bad cables, for example, can cause a higher error rate that will get past the CRC (due to 4 or more bit errors).  Very large MTUs also have a non-linear effect on error rate, especially on very fast links because the scrambler can propagate single bit errors to multi-bit errors.  There’s a ton of material on the IEEE web site on these effects (see the sections on MTU size for 1 Gbps + macs). Other PHYs will have different behavior too.   Some compression schemes have a higher than normal error rate.  There’s also a broad category of intermediate systems causing errors (bugs, hardware errors, etc.) [see “When the CRC and TCP checksums Disagree”].
> 
> An intermediate system in NDN could verify validations, even though NFD does not.  I think the OP was asking this sort of what if question, not asking about the implemented behavior.  I agree with Gene’s position that one should not generate a NACK in this case.  If the router has some strategy that allows it to re-transmit the Interest, I think that’s ok as it would either be a CS hit upstream if it was an honest error or be aggregated/retransmitted if not.  But that needs to be rate limited, otherwise there is an amplification attack possible.  Otherwise, I’d just increment a “corrupted data packet” counter and drop it.
> 
> Also, note that some Interests carry a signature.  If the intermediate system is checking those too, then that might be a case where a NACK is warranted.  If you’re spending all the cycles to check a signature, sending a NACK is a small incremental cost and that’s a 1:1 message transaction.
> 
> Marc
> 
>> On Jun 28, 2016, at 8:49 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
>> 
>> Hi Tanusree
>> 
>> What’s the reason for “data packet is modified”?
>> For a transmission error due to line noise, the lower layer is responsible for detecting such error and drop the packet. NDNLPv2 will attempt to repair the packet loss by retransmitting the packet.
>> If there’s a malicious node on the path deliberately modifying the Data packet, NFD will not detect that because NFD neither has knowledge about the trust model, nor has the computation power to verify signatures. Consumer can re-express the Interest with an Exclude selector to exclude the bad Data, and hope the network can find a path to locate the good Data.
>> 
>> Yours, Junxiao
>> 
>>> On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com> 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
> 
> 
> _______________________________________________
> 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/20160629/c504fd1c/attachment.bin>