[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