<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Yes, your point is well taken. One would expect that a signed interest with a timestamp and nonce in the name would elicit only one response from an on-line producer. If a selector were
modified or corrupted, it would likely result in either no effect or making the Interest un-satisfiable (e.g. MinSuffixComponents is changed from “0” to “3” and the producer does not generate a name like that).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Marc<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Tai-Lin Chu <tailinchu@gmail.com><br>
<b>Date: </b>Friday, July 8, 2016 at 3:55 PM<br>
<b>To: </b>Marc <Marc.Mosko@parc.com><br>
<b>Cc: </b>"klaus@email.arizona.edu" <klaus@email.arizona.edu>, "ndn-interest@lists.cs.ucla.edu" <ndn-interest@lists.cs.ucla.edu><br>
<b>Subject: </b>Re: [Ndn-interest] NACK<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">> As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered.
For example, someone could change MinSuffixComponents from “0” to “1” and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field
to omit certain data packets or cause the same one to keep being returned. <o:p>
</o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The example is unlikely to happen. Because signed interest name is unique, there should be only one expected valid data. However, it is possible to deny signed interest response by modifying selectors. Am I missing something?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jul 7, 2016 at 9:02 AM, <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered.
For example, someone could change MinSuffixComponents from “0” to “1” and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field
to omit certain data packets or cause the same one to keep being returned.<br>
<br>
I do not think intermediate nodes should try to parse NDN SignedInterest. There is no deterministic way to figure out if a name is signed apart from knowledge of the application-layer framing and application security protocol. One could try to guess by inspecting
the last four name components of the Interest to see if they look like a signature, but that is no guarantee they are a signature.<br>
<br>
My understanding from looking at the specs is that the last 4 name components would look like this, where “__” is a length of the bytes to the right.<br>
<br>
%08%08<posix_time>/%08%08<nonce>/%08__%16__<signature_info>/%08__%17__<signature_value><br>
<br>
The issue is that generic name component (%08) is an opaque octet string, so it could be anything that just happens to have %16 or %17 as the 1st byte of name component, based on the application’s use. I grant that if the %16__ evaluates to the correct length
and %17__ evaluates to the correct length, then its more likely you have a signed interest, but you are still guessing. You could keep on trying to parse further and further down in the data structures to see if it syntactically looks like a signature info
(not the signature value, it has no TLV structure), but that is a lot of work to do on every Interest and makes an easy attack vector against forwarders.<br>
<br>
The Naming Conventions tech report (<a href="https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf" target="_blank">https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf</a>) reserves
some special values as the 1st byte of a name component, but the values %16 and %17 are not in those reserved values, so these fall squarely in the opaque octet string realm.<br>
<br>
Marc<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
> On Jul 6, 2016, at 7:12 PM, Klaus Schneider <<a href="mailto:klaus@email.arizona.edu">klaus@email.arizona.edu</a>> wrote:<br>
><br>
> I'm not an expert in NDN security, but it looks like it can:<br>
><br>
> <a href="http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests" target="_blank">
http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests</a><br>
><br>
> <a href="http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html" target="_blank">
http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html</a><br>
><br>
> Best regards.<br>
><br>
><br>
> On 06.07.2016 18:49, Tanusree Chatterjee wrote:<br>
>> Can any special Interest be signed to check its authenticity on other side?<br>
>> On Jul 7, 2016 5:37 AM, "Klaus Schneider" <<a href="mailto:klaus@email.arizona.edu">klaus@email.arizona.edu</a><br>
>> <mailto:<a href="mailto:klaus@email.arizona.edu">klaus@email.arizona.edu</a>>> wrote:<br>
>> ><br>
>> > I think there are at least two cases in which the verification fails:<br>
>> 1) random errors which couldn't be corrected by a lower layer and 2)<br>
>> purposeful manipulation of the packet by a malicious attacker.<br>
>> ><br>
>> > I don't know how easy these are to distinguish, but in both cases<br>
>> it's likely that the in-network routers have to solve the problem by<br>
>> forwarding interests on a different path.<br>
>> ><br>
>> > There is a trade-off in how persistently routers should retransmit<br>
>> before notifying the consumer: In one extreme all routers on the path<br>
>> try all of their paths before sending a NACK back (potentially<br>
>> increasing the delay to the point where the consumer no longer needs the<br>
>> data). In the other extreme, the NACK goes directly to the consumer and<br>
>> then the consumer sends a retransmission to tell the routers to try a<br>
>> different path (increasing delay and packet overhead compared to routers<br>
>> retransmitting on their own).<br>
>> ><br>
>> > It is also useful to identify how fine-granular the problem is: Did<br>
>> the data corruption affect 1) just a single packet, 2) many/most packets<br>
>> under that FIB-prefix-face combination, or 3) all packets send over that<br>
>> face?<br>
>> ><br>
>> > This information can then be used to make better decisions at the<br>
>> forwarding layer, like moving traffic of the affected "flow"/FIB<br>
>> prefix/face. I think the problem is quite similar to the one of congestion.<br>
>> ><br>
>> > Best regards,<br>
>> > Klaus<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On 30.06.2016 14:29, Cesar Ghali wrote:<br>
>> >><br>
>> >> I just want to highlight that interest NACKs that Lixia mentioned are<br>
>> >> studied as two types of NACK messages in the paper that Gene shared<br>
>> earlier:<br>
>> >> <a href="http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477" target="_blank">
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477</a><br>
>> >><br>
>> >> Cesar<br>
>> >><br>
>> >><br>
>> >> On Wednesday, June 29, 2016, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a><br>
>> <mailto:<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>><br>
>> >> <mailto:<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a> <mailto:<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>>>> wrote:<br>
>> >><br>
>> >> one detail that I have not seen mentioned so far: interest NACK<br>
>> >> versus data packet NACK.<br>
>> >><br>
>> >> It seems to me that interest NACK is relatively well understood: a<br>
>> >> forwarding node failed to forward a received interest hence<br>
>> >> generates a NACK to its previous hop.<br>
>> >> data NACK seems to me not understood as fully:<br>
>> >> a) if a consumer gets a data packet that's not what it wants, it'd<br>
>> >> retry the interest in some way;<br>
>> >> b) any other forwarding node could drop an incorrect data packet, it<br>
>> >> can; whether it should generate a NACK on behalf of the consumer<br>
>> >> seems a separable question.<br>
>> >><br>
>> >><br>
>> >> > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee<br>
>> >> <<a href="mailto:tnsr.chatterjee@gmail.com">tnsr.chatterjee@gmail.com</a> <mailto:<a href="mailto:tnsr.chatterjee@gmail.com">tnsr.chatterjee@gmail.com</a>>><br>
>> wrote:<br>
>> >> ><br>
>> >> > If a data packet is modified and detected during verification,<br>
>> >> can forwarder send a NACK. How the data can be resend in this case?<br>
>> >> If consumer is not satisfied it has to send the same interest again,<br>
>> >> is there any other way out to get the data which may not been<br>
>> >> correctly received due to some modification.<br>
>> >> ><br>
>> >> > -- Regards,<br>
>> >> > Tanusree Chatterjee<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > Ndn-interest mailing list<br>
>> >> > <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
>> <mailto:<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
>> >> > <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Ndn-interest mailing list<br>
>> >> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a> <mailto:<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
>> >> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Ndn-interest mailing list<br>
>> >> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a> <mailto:<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
>> >> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>> >><br>
>> > _______________________________________________<br>
>> > Ndn-interest mailing list<br>
>> > <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a> <mailto:<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
>> > <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
>><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br>
<br>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>