<p dir="ltr">Can any special Interest be signed to check its authenticity on other side?<br>
On Jul 7, 2016 5:37 AM, "Klaus Schneider" <<a href="mailto:klaus@email.arizona.edu">klaus@email.arizona.edu</a>> wrote:<br>
><br>
> I think there are at least two cases in which the verification fails: 1) random errors which couldn't be corrected by a lower layer and 2) purposeful manipulation of the packet by a malicious attacker.<br>
><br>
> I don't know how easy these are to distinguish, but in both cases it's likely that the in-network routers have to solve the problem by forwarding interests on a different path.<br>
><br>
> There is a trade-off in how persistently routers should retransmit before notifying the consumer: In one extreme all routers on the path try all of their paths before sending a NACK back (potentially increasing the delay to the point where the consumer no longer needs the data). In the other extreme, the NACK goes directly to the consumer and then the consumer sends a retransmission to tell the routers to try a different path (increasing delay and packet overhead compared to routers retransmitting on their own).<br>
><br>
> It is also useful to identify how fine-granular the problem is: Did the data corruption affect 1) just a single packet, 2) many/most packets under that FIB-prefix-face combination, or 3) all packets send over that face?<br>
><br>
> This information can then be used to make better decisions at the forwarding layer, like moving traffic of the affected "flow"/FIB prefix/face. I think the problem is quite similar to the one of congestion.<br>
><br>
> Best regards,<br>
> Klaus<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On 30.06.2016 14:29, Cesar Ghali wrote:<br>
>><br>
>> I just want to highlight that interest NACKs that Lixia mentioned are<br>
>> studied as two types of NACK messages in the paper that Gene shared earlier:<br>
>> <a href="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477">http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477</a><br>
>><br>
>> Cesar<br>
>><br>
>><br>
>> On Wednesday, June 29, 2016, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a><br>
>> <mailto:<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>>> wrote:<br>
>><br>
>>     one detail that I have not seen mentioned so far: interest NACK<br>
>>     versus data packet NACK.<br>
>><br>
>>     It seems to me that interest NACK is relatively well understood: a<br>
>>     forwarding node failed to forward a received interest hence<br>
>>     generates a NACK to its previous hop.<br>
>>     data NACK seems to me not understood as fully:<br>
>>     a) if a consumer gets a data packet that's not what it wants, it'd<br>
>>     retry the interest in some way;<br>
>>     b) any other forwarding node could drop an incorrect data packet, it<br>
>>     can; whether it should generate a NACK on behalf of the consumer<br>
>>     seems a separable question.<br>
>><br>
>><br>
>>      > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee<br>
>>     <<a href="mailto:tnsr.chatterjee@gmail.com">tnsr.chatterjee@gmail.com</a>> wrote:<br>
>>      ><br>
>>      > If a data packet is modified and detected during verification,<br>
>>     can forwarder send a NACK. How the data can be resend in this case?<br>
>>     If consumer is not satisfied it has to send the same interest again,<br>
>>     is there any other way out to get the data which may not been<br>
>>     correctly received due to some modification.<br>
>>      ><br>
>>      > -- Regards,<br>
>>      > Tanusree Chatterjee<br>
>>      ><br>
>>      > _______________________________________________<br>
>>      > Ndn-interest mailing list<br>
>>      > <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
>>      > <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>><br>
>><br>
>>     _______________________________________________<br>
>>     Ndn-interest mailing list<br>
>>     <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
>>     <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Ndn-interest mailing list<br>
>> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
>> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</p>