[Ndn-interest] Sending NACKs with ndn-cpp

[GTS]

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/29bdff2c/attachment.html>