cghali at uci.edu
Wed Jun 29 16:36:46 PDT 2016
Both scenarios of content verification by routers that Alex mentioned are
valid and are explained in more detail in this paper:
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.
> > 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
> >> 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 <
> >>> 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
> >>> -- Regards,
> >>> Tanusree Chatterjee
> >> _______________________________________________
> >> Ndn-interest mailing list
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> > _______________________________________________
> > Ndn-interest mailing list
> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest