[Nfd-dev] Using Forwarding Hints

[Junxiao Shi]

Hi Philipp

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?

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
> http://named-data.net/doc/NDN-packet-spec/current/interest.html , but no
> separated document.
>

NFD devguide <https://named-data.gitlab.io/TR-NDN-0021-NFD-dev-guide/>
"incoming Interest pipeline" section has some description on how NFD
processes forwarding hint.
However, there isn't any protocol document on how a forwarder *should*
process forwarding hint.

NDN-LAN dissertation <http://hdl.handle.net/10150/625652> Chapter 3 has a
description on how a forwarder should process Interest, Data, Nack packets.
However, the dissertation left out forwarding hint, because there are
several unresolved issues in forwarding hint design.

A major problem with forwarding hints is the increased risk of cache
poisoning attacks.
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:

   1. Express an Interest /N with forwarding hint /A. The Interest would go
   toward the producer of /A.
   2. The producer, also controlled by the attacker, replies the Interest
   with a malicious Data.

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 NFD
Feature 3161 <https://redmine.named-data.net/issues/3161>, NFD Feature 3162
<https://redmine.named-data.net/issues/3162>, and others.
However, it's been pointed out
<https://redmine.named-data.net/issues/3000#note-27>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.
This attack scenario, later named as forwarding hint crafting attack
<https://redmine.named-data.net/issues/3333#note-9>, prompted Interest
digest <https://redmine.named-data.net/issues/3333> proposal.
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.

The NDN-DPDK forwarder <https://github.com/usnistgov/ndn-dpdk> 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.
Then it uses a PIT token field <https://redmine.named-data.net/issues/4432> 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.
This effectively eliminates the vulnerability of forwarding hint crafting
attack.

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.
PIT token is not implementable in NFD, because it only works on
point-to-point links, while NFD needs to support broadcast links.
There was a hackathon project
<https://github.com/4th-ndn-hackathon/Initial-Implementation-of-Interest-Digest-in-NFD>
implementing
Interest digest in NFD, which weakly confirms its performance benefit.

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)
>
> 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 :-)


Thanks Lixia for taking the lead on this.
https://redmine.named-data.net/issues/5000 is now assigned to Lixia.


> 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?


ProducerRegion is an implementation choice. In NFD, it cannot be changed
via management command because there isn't a use case for that.

>> 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.
> > correct (according to my understanding)
>
> 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.".
>
> 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.
>

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.
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.

NFD and NDN-DPDK take forwarding hint as a mobility solution.
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.
The procedure in SNAMP paper would deliver the Interest to /ndn/edu/arizona
router, which does not satisfy mobility use case.


>
> 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.
>

Yes. Equally important is a deployment of NDNS.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191018/cd292922/attachment.html>