NFD

20160112 conference call schedules a discussion about this issue on 20160119.
Alex is expected to prepare slides for this discussion, but everyone should be prepared.

Beichuan talked about one implication of one Data satisfying only one Interest: "I only get one Data and upstream is down. I have three pending Interests, but only one can be satisfied. When downstream retransmits, I can satisfy them from the cache."

20160128 conference call decides that during v0.5 timeline we should proceed with the design of this idea, but the implementation, if any, cannot be merged into master branch.

20160816 conference call identifies three major issues:

• How to make sure everyone use the same hash function, and be able to replace the hash function in the future?
• Is the Interest digest required or optional with return Data?
• How is CS organized? still partition by Link, or require exactly same Interest?

For the third question:

• Requiring exactly same Interest to match a CS entry has the potential of improving CS performance, but it effectively disables name discovery in the CS.
• Partitioning the CS by Link keeps CS semantics unchanged, but every Interest (including retransmission after Data loss) would still require a full CS lookup.

Below is my opinion.

the hash function can be a hop-by-hop decision

An implication is that, a forwarder whose downstream and upstream links use different hash function would have to perform a potentially expensive hash computation.

It's believed that a cryptographic hash function is not needed.

Using a non-cryptographic hash function leads to Link crafting attack:

Alice--\    /----Bob
        R--S
Chuck--/    \-Mallet

1. Alice expresses an Interest /Bob/1 with Link object delegating to Bob's network.
2. Chuck expresses an Interest /Bob/1 with Link object delegating to Mallet's network. The Link object is crafted such that Chuck's Interest has the same digest as Alice's Interest.
3. Mallet returns bogus Data /Bob/1. Router R is unable to distinguish whether this Data is in reply to Chuck's or Alice's Interest.

Crafting a Link object to cause a hash collision is possible, because the Link object name contains a version component which can be chosen by Chuck. This attack is cheap as long as the hash function lacks "it is infeasible to generate a message from its hash value except by trying all possible messages" property: Chuck can compute a suitable value to put into the version component from the desired Interest digest.

Link crafting attack would become difficult or impossible if every hop uses a different hash function or a different "salt". However, that would require a negotiation protocol to bootstrap.

20170208 call confirms Link crafting attack is indeed possible and trivial with non-cryptographic hash function. The choice of hash function needs additional studies.

Crafting a Link object to cause a hash collision is possible, because the Link object name contains a version component which can be chosen by Chuck. This attack is cheap as long as the hash function lacks "it is infeasible to generate a message from its hash value except by trying all possible messages" property: Chuck can compute a suitable value to put into the version component from the desired Interest digest.

#4055 replaces Link object in the Interest with a forwarding hint. However, forwarding hint crafting attack is still possible with an insecure hash function.
Chuck can make a forwarding hint like [{<preference>,/Mallet/<extra-components>}], and choose <preference> and <extra-components> to cause a hash collision. No matter what <extra-components> is, the Interest still goes to Mallet because the delegation name starts with /Mallet.