[Ndn-interest] NACK

[Cesar Ghali]

Both scenarios of content verification by routers that Alex mentioned are
valid and are explained in more detail in this paper:
http://dl.acm.org/citation.cfm?id=2677049

Cesar

On Wednesday, June 29, 2016, Alex Afanasyev <aa at cs.ucla.edu> wrote:

> 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 <javascript:;> 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
> <javascript:;>> 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 <javascript:;>> 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 <javascript:;>
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> >
> >
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu <javascript:;>
> > 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/20160629/e19bb939/attachment.html>