<div dir="ltr"><div dir="ltr"><div>Hi Philipp</div><div dir="ltr"><br></div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I wonder if there there is any documentation about using ForwardingHints available? I think I got an idea how everything works by checking out the NFD implementation, but some details are still unclear. Is there additional documentation besides the code?  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If there is any additional documentation, or examples available, I would appreciate to get some pointers. So far, I only found the hint that "Specifics of the forwarding logic for Interests with ForwardingHint will be defined in a separated document." on <a href="http://named-data.net/doc/NDN-packet-spec/current/interest.html" rel="noreferrer" target="_blank">http://named-data.net/doc/NDN-packet-spec/current/interest.html</a> , but no separated document.<br></blockquote></div><div dir="ltr"><br></div><div><a href="https://named-data.gitlab.io/TR-NDN-0021-NFD-dev-guide/" target="_blank">NFD devguide</a> "incoming Interest pipeline" section has some description on how NFD processes forwarding hint.<br></div><div>However, there isn't any protocol document on how a forwarder <b>should</b> process forwarding hint.</div><div dir="ltr"><div><br></div><div><a href="http://hdl.handle.net/10150/625652" target="_blank">NDN-LAN dissertation</a> Chapter 3 has a description on how a forwarder should process Interest, Data, Nack packets.</div><div>However, the dissertation left out forwarding hint, because there are several unresolved issues in forwarding hint design.</div><div><br></div><div>A major problem with forwarding hints is the increased risk of cache poisoning attacks.</div><div>Suppose an attacker wants to insert a malicious Data /N to the cache, but does not own /N namespace. She could use a namespace she owns, such as /A, and perform the following steps:</div><div><ol><li>Express an Interest /N with forwarding hint /A. The Interest would go toward the producer of /A.</li><li>The producer, also controlled by the attacker, replies the Interest with a malicious Data.</li></ol></div><div>A countermeasure is to partition the PIT and CS, so that the cached Data /N retrieved with forwarding hint /A can only satisfy an Interest carrying forwarding hint /A, but cannot satisfy an Interest carrying any other forwarding hint. This countermeasure prompted the creation of <a href="https://redmine.named-data.net/issues/3161">NFD Feature 3161</a>, <a href="https://redmine.named-data.net/issues/3162">NFD Feature 3162</a>, and others.</div><div>However, <a href="https://redmine.named-data.net/issues/3000#note-27">it's been pointed out </a>that it's impossible for a forwarder to determine which forwarding hint was used to retrieve a Data, if an incoming Data could satisfy several pending Interests with distinct forwarding hints. </div><div>This attack scenario, later named as <a href="https://redmine.named-data.net/issues/3333#note-9" target="_blank">forwarding hint crafting attack</a>, prompted <a href="https://redmine.named-data.net/issues/3333" target="_blank">Interest digest</a> proposal.</div><div>However, this proposal is blocked on the question of whether a universal agreement of the digest algorithm is necessary, and how to rotate the digest algorithm should the chosen digest algorithm becomes insecure in the future.</div><div><br></div><div><div>The <a href="https://github.com/usnistgov/ndn-dpdk" target="_blank">NDN-DPDK forwarder</a> partitions its PIT and CS with forwarding hint name. (1) Two Interests having the same name but different forwarding hints are considered completely different and cannot aggregate with one another. (2) Every Data stored in the CS is tagged with the forwarding hint used during its retrieval, and it can only satisfy an Interest that carries the same forwarding hint.</div><div>Then it uses a <a href="https://redmine.named-data.net/issues/4432" target="_blank">PIT token field</a> to match Data to pending Interest. It's a similar approach to Interest digest, but sidesteps the concern about universal digest algorithm choice because PIT token is a hop-by-hop field.</div></div><div>This effectively eliminates the vulnerability of forwarding hint crafting attack.</div><div><br></div><div>In NFD, it's possible to partition the tables and allow cached Data to only satisfy Interest carrying the same forwarding hint. This is never implemented due to unresolved issue of forwarding hint crafting attack.</div><div>PIT token is not implementable in NFD, because it only works on point-to-point links, while NFD needs to support broadcast links.</div><div>There was a <a href="https://github.com/4th-ndn-hackathon/Initial-Implementation-of-Interest-Digest-in-NFD">hackathon project</a> implementing Interest digest in NFD, which weakly confirms its performance benefit.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
not sure but I might be the guilty party for the missing of this doc (I vaguely recall I agreed to write something about forwarding hints a few years back, after I had some discussion with Haitao to clarify a couple confusing points, but unfortunately that item is still pretty far down my TODO list)<br>
<br>
Unless such a doc existed somewhere else already, otherwise I could take this msg of yours as a starting point, and you could help as well :-)</blockquote><div><br></div><div>Thanks Lixia for taking the lead on this. <a href="https://redmine.named-data.net/issues/5000" target="_blank">https://redmine.named-data.net/issues/5000</a> is now assigned to Lixia.</div></div><div dir="ltr"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In the NFD code, I saw that the forwarding hint is used by forwarding strategies and stripped by the forwarder when the Interest has reached the ProducerRegion. I also found that the NetworkRegionTable stores the ProducerRegions of the node. It seems that ProducerRegions can be configured statically in the ndf.conf file. Is the nfd.conf file the only possibility to configure ProducerRegions, or is it possible to change it via nfdc as well? </blockquote><div><br></div><div>ProducerRegion is an implementation choice. In NFD, it cannot be changed via management command because there isn't a use case for that.</div><div><br></div></div></div><div class="gmail_quote"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> In the NFD code, I saw that the forwarding hint is used by forwarding strategies and stripped by the forwarder when the Interest has reached the ProducerRegion.<br>
> correct (according to my understanding)<br>
<br>
OK, until looking at the code I thought that the implementation of the forwarding hint follows the SNAMP paper [1]. However, the paper states that "When this modified interest reaches the first router that cannot find a matching FIB entry for the interest name, the router will extract the prefix delegations from the attached link object (see Section II-E), select the best candidate (e.g., by using routing cost or based on previous traffic measurements), and forward the interest based on this selection.".<br>
<br>
This would mean that the forwarding hint is only used if no FIB entry for the Interest name is found. In the actual implementation, it looks to me (maybe I am wrong) that the forwarding hint is used as soon as a forwarding hint exists, which is different from the behavior described in the paper. No need to justify, I just wonder if there is a reason why the implementation differs from the behavior of the paper.<br></blockquote><div><br></div><div>The SNAMP paper positions forwarding hint as a routing scalability solution. If a forwarder finds a FIB entry via LPM lookup of the Interest, it means the producer's name prefix is announced to the forwarder, and thus it does not need to use the forwarding hint.</div><div>Furthermore, the SNAMP paper does not address forwarding hint crafting attack. It assumes globally unique name assignments in the default-free zone. Forwarding hints (then called "link objects") are signed, and forwarders are supposed to validate the signature when necessary. However, the trust schema is unclear.</div><div><br></div><div>NFD and NDN-DPDK take forwarding hint as a mobility solution.</div><div>Suppose you own a routable name /ndn/edu/arizona/cs/shijunxiao, but you are traveling and connected to /ndn/edu/ucla router, others would be able to reach your content with Interest name /ndn/edu/arizona/cs/shijunxiao and forwarding hint /ndn/edu/ucla.</div><div>The procedure in SNAMP paper would deliver the Interest to /ndn/edu/arizona router, which does not satisfy mobility use case.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I think additional info that might be useful in this doc is how one may get a forwarding hint; there can be a few options, and this doc should show examples.<br></blockquote></div><div><br></div><div>Yes. Equally important is a deployment of NDNS.</div><div><br></div><div>Yours, Junxiao</div></div></div></div>