[Ndn-interest] Sending NACKs with ndn-cpp

GTS gts at ics.uci.edu
Thu Oct 13 11:13:37 PDT 2016


Precisely! (Adversary here being something like a rogue app, or a set 
thereof, on the same platform)

Cheers,
Gene

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

On 10/13/16 11:03 AM, Thompson, Jeff wrote:
> Hi Gene,
> By “collocated”, you mean talking over something like a Unix socket on 
> the same computer with the idea that there is little chance of an 
> adversary getting in the middle?
> - Jeff T
>
> From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu 
> <mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of GTS 
> <gts at ics.uci.edu <mailto:gts at ics.uci.edu>>
> Date: Thursday, October 13, 2016 at 10:10:00
> To: "Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>" 
> <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
> 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
>
>
> 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.eduhttp://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/2fbe1416/attachment.html>


More information about the Ndn-interest mailing list