[Ndn-interest] Sending NACKs with ndn-cpp

[GTS]

Yep... I agree in the context of a forwarder talking a *collocated* app.
Cheers,
Gene

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

On 10/13/16 9:41 AM, Marc.Mosko at parc.com wrote:
> I agree things get more murky the further one gets away from where a 
> message was initiated.
>
> But I thought the premise of the previous messages is that adjacent 
> forwarders already trust each other for NACKs.  My point was that if 
> forwarders already trust each other for NACks, then why cannot a 
> forwarder apply a similar trust mechanism to a local app, as it should 
> know for which name spaces it trusts the app.
>
> Marc
>
>
>> On Oct 13, 2016, at 9:36 AM, GTS <gts at ics.uci.edu 
>> <mailto:gts at ics.uci.edu>> wrote:
>>
>>
>> Marc,
>>
>> yes, it's reasonable -- though not always practical -- to assume that 
>> there are pairwise secure
>> channels between local app, local forwarder, next forwarder, etc, 
>> etc, all the way to the last
>> hop.
>>
>> However, my apologies for this platitude, but trust is local.
>> The farther you get away (in trust hops) from the source, the less
>> trust there is, and more likely it becomes that someone on the path 
>> will be malicious.
>> It works the same way with humans :-)
>>
>> Cheers,
>> Gene
>>
>>
>> ======================
>> Gene Tsudik
>> Chancellor's Professor of Computer Science
>> University of California, Irvine
>>
>> On 10/13/16 9:05 AM, Marc.Mosko at parc.com wrote:
>>> Doesn’t an application have a trust channel with its local 
>>> forwarder, and the local forwarder with the next forwarder, etc.?
>>>
>>> Marc
>>>
>>>> On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu 
>>>> <mailto:cghali at uci.edu>> wrote:
>>>>
>>>> Hi Jeff, That's right, untrusted NACKs should not be accepted in 
>>>> the network. In fact a pre-arranged trusted channel is an approach 
>>>> proposed in the paper I shared before. Cesar
>>>>
>>>> On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu 
>>>> <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>
>>>>     Hi Cesar,
>>>>
>>>>     So in Junxiao’s example, the microcontroller would send an
>>>>     unsigned network Nack? Will forwarders be configured to respond
>>>>     to an unsigned Nack which comes from the (supposed) direction
>>>>     from any application? (I had though that these network
>>>>     signalling messages are send between forwarders on a
>>>>     pre-arranged trusted channel.)
>>>>
>>>>     - Jeff T
>>>>
>>>>     From: Cesar Ghali <cghali at uci.edu <mailto:cghali at uci.edu>>
>>>>     Date: Thursday, October 13, 2016 at 8:29:00
>>>>     To: Junxiao Shi <shijunxiao at email.arizona.edu
>>>>     <mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson
>>>>     <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>>
>>>>     Cc: "ndn-interest at lists.cs.ucla.edu
>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>"
>>>>     <ndn-interest at lists.cs.ucla.edu
>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>>
>>>>     Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>>>>
>>>>     That's right, mixing network and application NACKs is not a
>>>>     good idea. From a security perspective, this separation is
>>>>     discussed in details in:
>>>>     http://ieeexplore.ieee.org/document/7288477/ Cesar
>>>>
>>>>     On Wed, Oct 12, 2016 at 16:07 Junxiao Shi
>>>>     <shijunxiao at email.arizona.edu
>>>>     <mailto:shijunxiao at email.arizona.edu>> wrote:
>>>>
>>>>         Hi JeffT
>>>>
>>>>         I have a temperature sensor based on ESP8266
>>>>         microcontroller. It uses ndn-cpp-lite, connects to a remote
>>>>         forwarder over TCP, and acts as a producer.
>>>>         The ESP8266, clocked at 80MHz, has limited signing
>>>>         capability. It can sign or verify 8 ECDSA signatures per
>>>>         second.
>>>>         If Interests are arriving too fast, I want to be able to
>>>>         send a NetworkNack-Congestion so that the remote forwarder
>>>>         can forward less Interests to the sensor.
>>>>         An application Nack cannot fulfill this purpose because it
>>>>         still requires a signature. Allowing the Interests to time
>>>>         out increases overhead at the remote forwarder because PIT
>>>>         entries stay longer.
>>>>
>>>>         Yours, Junxiao
>>>>
>>>>
>>>>         On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff
>>>>         <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>
>>>>             Hi Matteo.
>>>>
>>>>             A NetworkNack is a ³network² nack because it is
>>>>             generated by a forwarder
>>>>             in the network, such as NFD. A client library like
>>>>             ndn-cpp is meant to be
>>>>             used by an application which does not generate
>>>>             network-level messages. It
>>>>             is called a ³network² nack to distinguish from an
>>>>             ³application² nack. Can
>>>>             you describe the situation where your application needs
>>>>             to generate a nack?
>>>>
>>>>             - Jeff T
>>>>
>>>>         _______________________________________________
>>>>         Ndn-interest mailing list
>>>>         Ndn-interest at lists.cs.ucla.edu
>>>>         <mailto: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 <mailto: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 --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/8122d54c/attachment.html>