<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="+1"><font face="Times New Roman, Times, serif"><br>
Yep... I agree in the context of a forwarder talking a
*collocated* app.<br>
Cheers,<br>
Gene<br>
<br>
</font></font>
<pre class="moz-signature" cols="72">======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine
</pre>
<div class="moz-cite-prefix">On 10/13/16 9:41 AM,
<a class="moz-txt-link-abbreviated" href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a> wrote:<br>
</div>
<blockquote cite="mid:9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
I agree things get more murky the further one gets away from where
a message was initiated.
<div class=""><br class="">
</div>
<div class="">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.
<div class=""><br class="">
</div>
<div class="">Marc<br class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 13, 2016, at 9:36 AM, GTS <<a
moz-do-not-send="true" href="mailto:gts@ics.uci.edu"
class="">gts@ics.uci.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><br
class="">
<font class="" size="+1"><font class="" face="Times
New Roman, Times, serif">Marc,<br class="">
<br class="">
yes, it's reasonable -- though not always
practical -- to assume that there are pairwise
secure<br class="">
channels between local app, local forwarder,
next forwarder, etc, etc, all the way to the
last<br class="">
hop.<br class="">
<br class="">
However, my apologies for this platitude, but
trust is local. <br class="">
The farther you get away (in trust hops) from
the source, the less<br class="">
trust there is, and more likely it becomes that
someone on the path will be malicious.<br
class="">
It works the same way with humans :-)<br
class="">
<br class="">
Cheers,<br class="">
Gene<br class="">
<br class="">
<br class="">
</font></font>
<pre class="moz-signature" cols="72">======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine
</pre>
<div class="moz-cite-prefix">On 10/13/16 9:05 AM, <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Marc.Mosko@parc.com">
Marc.Mosko@parc.com</a> wrote:<br class="">
</div>
<blockquote
cite="mid:032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com"
type="cite" class="">
Doesn’t an application have a trust channel with
its local forwarder, and the local forwarder with
the next forwarder, etc.?
<div class=""><br class="">
</div>
<div class="">Marc<br class="">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Oct 13, 2016, at 8:50 AM,
Cesar Ghali <<a
moz-do-not-send="true"
href="mailto:cghali@uci.edu" class="">cghali@uci.edu</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="white-space:pre-wrap" class="">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</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Oct
13, 2016 at 08:45 Thompson, Jeff
<<a moz-do-not-send="true"
href="mailto:jefft0@remap.ucla.edu"
class="">jefft0@remap.ucla.edu</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap: break-word;
font-size: 14px; font-family:
Calibri, sans-serif;" class="">
<div class="">Hi Cesar,</div>
<div class=""><br class="">
</div>
<div class="">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.)</div>
<div class=""><br class="">
</div>
<div class="">- Jeff T</div>
<div class=""><br class="">
</div>
<span class="">
<div style="font-family:
Calibri; font-size: 11pt;
text-align: left;
border-width: 1pt medium
medium; border-style: solid
none none; padding: 3pt 0in
0in; border-top-color:
rgb(181, 196, 223);" class="">
<span style="font-weight:bold"
class="">From: </span>Cesar
Ghali <<a
moz-do-not-send="true"
href="mailto:cghali@uci.edu"
target="_blank" class="">cghali@uci.edu</a>><br
class="">
<span style="font-weight:bold"
class="">Date: </span>Thursday,
October 13, 2016 at 8:29:00<br
class="">
<span style="font-weight:bold"
class="">To: </span>Junxiao
Shi <<a
moz-do-not-send="true"
href="mailto:shijunxiao@email.arizona.edu"
target="_blank" class="">shijunxiao@email.arizona.edu</a>>,
Jeff Thompson <<a
moz-do-not-send="true"
href="mailto:jefft0@remap.ucla.edu"
target="_blank" class="">jefft0@remap.ucla.edu</a>><br
class="">
<span style="font-weight:bold"
class="">Cc: </span>"<a
moz-do-not-send="true"
href="mailto:ndn-interest@lists.cs.ucla.edu"
target="_blank" class="">ndn-interest@lists.cs.ucla.edu</a>"
<<a moz-do-not-send="true"
href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank" class="">ndn-interest@lists.cs.ucla.edu</a>><br
class="">
<span style="font-weight:bold"
class="">Subject: </span>Re:
[Ndn-interest] Sending NACKs
with ndn-cpp<br class="">
</div>
</span></div>
<div style="word-wrap: break-word;
font-size: 14px; font-family:
Calibri, sans-serif;" class="">
<span class="">
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div style="white-space:pre-wrap" class="">That's right, mixing network and application NACKs is not a good idea. From a security perspective, this separation is discussed in details in:
<a moz-do-not-send="true" href="http://ieeexplore.ieee.org/document/7288477/" target="_blank" class="">
http://ieeexplore.ieee.org/document/7288477/</a> Cesar</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On
Wed, Oct 12, 2016 at
16:07 Junxiao Shi <<a
moz-do-not-send="true"
href="mailto:shijunxiao@email.arizona.edu" target="_blank" class="">shijunxiao@email.arizona.edu</a>>
wrote:<br class="">
</div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr" class="">Hi
JeffT
<div class=""><br
class="">
</div>
<div class="">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.</div>
<div class="">The
ESP8266, clocked at
80MHz, has limited
signing capability.
It can sign or
verify 8 ECDSA
signatures per
second.</div>
<div class="">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.</div>
<div class="">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.</div>
<div class=""><br
class="">
</div>
<div class="">Yours,
Junxiao</div>
</div>
<div dir="ltr" class="">
<div class=""><br
class="">
<div
class="gmail_extra"><br
class="">
<div
class="gmail_quote">On
Wed, Oct 12,
2016 at 10:08
AM, Thompson,
Jeff <span
dir="ltr"
class="">
<<a
moz-do-not-send="true"
href="mailto:jefft0@remap.ucla.edu" target="_blank" class="">jefft0@remap.ucla.edu</a>></span>
wrote:<br
class="">
<blockquote
class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matteo.<br
class="">
<br class="">
A NetworkNack
is a łnetwork˛
nack because
it is
generated by a
forwarder<br
class="">
in the
network, such
as NFD. A
client library
like ndn-cpp
is meant to be<br
class="">
used by an
application
which does not
generate
network-level
messages. It<br
class="">
is called a
łnetwork˛ nack
to distinguish
from an
łapplication˛
nack. Can<br
class="">
you describe
the situation
where your
application
needs to
generate a
nack?<br
class="">
<br class="">
- Jeff T<br
class="">
</blockquote>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
Ndn-interest mailing
list<br class="">
<a
moz-do-not-send="true"
href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank" class="">Ndn-interest@lists.cs.ucla.edu</a><br
class="">
<a
moz-do-not-send="true"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest"
rel="noreferrer"
target="_blank"
class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br
class="">
</blockquote>
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:Ndn-interest@lists.cs.ucla.edu"
class="">Ndn-interest@lists.cs.ucla.edu</a><br
class="">
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
Ndn-interest mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>