<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 5:06 PM <<a href="mailto:Ignacio.Solis@parc.com">Ignacio.Solis@parc.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<div>I'm going to guess that caching data rules will be the same as forwarding rules. If the interface is not allowed to produce that content (due to routing / fib entries, local naming policy) data should not be forwarded OR cached. </div></div></div></blockquote><div><br></div><div>Caching rules could be simpler because the data is considered cachable only after it passes PIT matching. During PIT matching you can do all sorts of checking, including the check that the data indeed comes from one of the faces where the Interest was forwarded to. After that, the data can be inserted into cache table if cache management policy allows.</div><div><br></div><div>If there is no PIT for the data, it really should be dropped in the first place.</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<div><br>
</div>
<div>NDN has a slightly more complicated problem with caching than CCN given then LPM matching rules. </div>
<div><br>
</div>
<div>If you have a repo that has permission to serve this content then you changed the problem. Now you need the repo protocol to give you trust. </div>
<div><br>
</div>
<div>For regular forwarding you are relying on trusting routing. For local apps you will rely (I assume) on local permissions. For repo you will need both of those plus now a repo permission protocol. </div>
<div><br>
</div>
<div>Dropping unsolicited data may end up being your only recourse. </div>
<div><br>
</div>
<div>There are obviously other approaches for pre-populating caches that involve higher level protocols, but I assume that's not what you're talking about. </div></div></div><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<div><br>
</div>
<div>Nacho (Ignacio) Solis
<div>Principal Scientist</div>
<div>Palo Alto Research Center </div>
</div>
</div></div><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"></div>
<div style="clear:both"><br>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<span style="font-size:11.0pt;font-family:'Calibri','sans-serif'"><b>From:</b> Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><br>
<b>Sent:</b> Mar 30, 2015 4:50 PM<br>
<b>To:</b> "Solis, Ignacio <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a>>" <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a>>;Mosko, Marc <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span></div></div></div><div><div style="clear:both"><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><span style="font-size:11.0pt;font-family:'Calibri','sans-serif'"><br>
<b>Cc:</b> <a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a><br>
<b>Subject:</b> Re: [Nfd-dev] Handling new content in app for pending interest in NFD<br>
</span></div></div></div><div>
<br type="attribution">
<div>
<div dir="ltr">Hi Nacho,
<div><br>
</div>
<div>I don't have any argument against this rule right now. But it seems more relevant to "forwarding" data packets, while the problem we were discussing is about "caching" unsolicited data packets, which cannot be forwarded anyway because there is no PIT.
The simplest solution I would suggest to the problem is to drop any unsolicited data in the forwarder.</div>
<div><br>
</div>
<div>Wentao<br>
<br>
<div class="gmail_quote">On Mon, Mar 30, 2015 at 3:42 PM <<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<div>This rule is important, router or not. You can't have "non-priviledged" applications generating replies at servers. Specially important at systems with multiple users, tenants, virtual systems. </div>
<div><br>
</div>
<div>At the local router there are even more restrictions. We haven't even gotten to talking about privileged names and restrictions and end-h out behavior. We have a design for this for CCN that we'll be talking about at CCNxCon. </div>
<div><br>
</div>
<div>Nacho (Ignacio) Solis
<div>Principal Scientist</div>
<div>Palo Alto Research Center </div>
</div>
</div>
<div style="clear:both"><br>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<span style="font-size:11.0pt;font-family:'Calibri','sans-serif'"><b>From:</b> Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>><br>
<b>Sent:</b> Mar 30, 2015 1:07 PM<br>
<b>To:</b> Mosko, Marc <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span></div>
</div>
</div>
<div>
<div style="clear:both">
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<span style="font-size:11.0pt;font-family:'Calibri','sans-serif'"><br>
<b>Cc:</b> <a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a><br>
<b>Subject:</b> Re: [Nfd-dev] Handling new content in app for pending interest in NFD<br>
</span></div>
</div>
</div>
<div>
<div>
<div dir="ltr"><br>
<div class="gmail_quote">On Mon, Mar 30, 2015 at 12:52 PM <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">I’ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested. Otherwise, there’s a potential for off-path
attacks sending content objects that match popular well-known names. A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there’s a corresponding FIB entry for the name.</div>
</blockquote>
<div><br>
</div>
<div>This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless
there is a PIT entry specifying a path pointing to some other router.</div>
<div><br>
</div>
<div>Wentao</div>
<div> </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">
<div><br>
</div>
<div>Marc</div>
</div>
<div style="word-wrap:break-word">
<div><br>
<div>
<div>On Mar 30, 2015, at 12:08 PM, Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">I agree with Dave.
<div><br>
</div>
<div>In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache
(or repo) for future fetching.</div>
<div><br>
</div>
<div>Wentao</div>
<div><br>
<div class="gmail_quote">On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Isn’t this what the repo was invented for?<br>
<br>
Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks.<br>
<br>
> On Mar 30, 2015, at 2:24 PM, Haowei Yuan <<a href="mailto:hyuan@wustl.edu" target="_blank">hyuan@wustl.edu</a>> wrote:<br>
><br>
> I think as long as the data has actually been requested by an Interest<br>
> packet, it is safe to send the Data packet to NFD. The NFD will either<br>
> forward or drop the Data packet by checking if the Interest has<br>
> expired.<br>
><br>
> If the Interest has expired, Data packet is dropped, and the consumer<br>
> is still interested in the data, the consumer could resend the<br>
> Interest. Hopefully this time, the Data packet can be generated and<br>
> sent faster by the application so that NFD will forward it.<br>
><br>
> Haowei<br>
><br>
><br>
> On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <<a href="mailto:anilj.mailing@gmail.com" target="_blank">anilj.mailing@gmail.com</a>> wrote:<br>
>><br>
>> On Mar 30, 2015 11:08 AM, "Dehart, John" <<a href="mailto:jdd@wustl.edu" target="_blank">jdd@wustl.edu</a>> wrote:<br>
>>><br>
>>><br>
>>> Is there any harm in it pushing the data out without knowing for sure if<br>
>>> the<br>
>>> Interest is still active?<br>
>>><br>
>> If data is so critical, can the Interest be refreshed proactively before it<br>
>> expires?<br>
>><br>
>> /anil<br>
>><br>
>>> John<br>
>>><br>
>>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Hi folks,<br>
>>>>>><br>
>>>>>> We are facing this scenario in a few applications:<br>
>>>>>><br>
>>>>>> 1) Interest received by NFD, passed to an application<br>
>>>>>> 2) Application not able to respond to interest, so interest stays in<br>
>>>>>> NFD PIT<br>
>>>>>> 3) Some time passes, but not enough for the Interest to expire<br>
>>>>>> 4) Application generates data (e.g., from a sensor reading) that would<br>
>>>>>> answer the Interest in the NFD PIT<br>
>>>>>><br>
>>>>>> Question: How does app know to inform NFD it has the data after step 4,<br>
>>>>>> and how should it do that?<br>
>>>>>><br>
>>>>>> - In this type of app, should it push the data unsolicited to the NFD<br>
>>>>>> and let it decide if there is something to do?<br>
>>>>><br>
>>>>><br>
>>>>> In my opinion, as long as the application is certain that the Interest<br>
>>>>> has arrived and is stored in NFD's PIT, it can just push the data out to<br>
>>>>> NFD.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> How certain does it have to be? There is a chance it could have<br>
>>>> expired...<br>
>>>> jeff<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>>><br>
>>>>> Wentao<br>
>>>>><br>
>>>>>><br>
>>>>>> - Is it recommended to implement an application-level PIT so the app is<br>
>>>>>> sure this data is solicited? (Why add another PIT?)<br>
>>>>>><br>
>>>>>> Thank you,<br>
>>>>>> Jeff<br>
>>>>>><br>
>>>>>> ______________________________<u></u>_________________<br>
>>>>>> Nfd-dev mailing list<br>
>>>>>> <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>>>>> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">
http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
>>>><br>
>>>> ______________________________<u></u>_________________<br>
>>>> Nfd-dev mailing list<br>
>>>> <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>>> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">
http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<u></u>_________________<br>
>>> Nfd-dev mailing list<br>
>>> <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
>>> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">
http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
>>><br>
> ______________________________<u></u>_________________<br>
> Nfd-dev mailing list<br>
> <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">
http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div></blockquote></div></div>