[Nfd-dev] NFD call 20151013

[christian.tschudin at unibas.ch]

> Link: cache poisoning after forwarded Interest with multiple distinct Link
> objects

Unfortunately, I will not be able to attend this phone call. A few 
thoughts through this channel on the above topic:

I hope that we agree that LINK is useful. Adding the LINK object to the 
returned data (as proposed on Redmine) might by a possible patch, but 
the issue merits a larger discussion.

First, note that this "poisoning" is not a poisoning if E is a legit 
node also serving the requested content.

Returnig also the LINK object just postpones the decision whether 
one should trust the returned data (or use excludes, probably to be 
extended to LINKs, in a second attempt).

The bigger picture is that this is "in-network name rewritting", and 
somehow the routing (e.g. knowing about E's status) has to be involved.

Even more general, this falls into the class of critique that I often 
hear for named functions: how do you trust the result? (Name rewritting 
is also a computation - the LINK names that function, so to speak. 
Moreover, structurally this is identical on how we tunnel named-function 
expressions through NDN).

One perhaps more broader plan would be to create a subset of trustworthy 
routers, only those being allowed to do the rewriting and having to sign 
(with a cheap hmac) their result. They also would be obliged to keep a 
log of their rewrittings. If there is suspicion on a cheating rewriter, 
one can ask proof of correct behavior. This would attempt to rescue the 
goal that rewriting/redirection is a network internal business (starting 
with the magical insertion of the LINK) and which does not have to 
involve the clients.

best, christian


On Tue, 13 Oct 2015, NFD call notification wrote:

> Dear folks
> 
> This is a reminder of the upcoming NFD call using Bluejeans
> https://bluejeans.com/760263096. The current call time is every
> Tuesday/Thursday 14:00-15:00 Pacific Time. The current agenda includes the
> following issues:
> 
> ____________________________________________________________________________
> 
> http://gerrit.named-data.net/2445
> 
> NLSR BroadcastStrategy => MulticastStrategy, what's blocking this?
> 
> need: Vince
> 
> http://redmine.named-data.net/issues/3232#note-1
> 
> FaceMgmt: separate faces/create and faces/update commands
> 
> http://redmine.named-data.net/issues/3229
> 
> `nfdc register -P` implicitly creates permanent face
> 
> need: Junxiao, Alex, Jeff or representative
> 
> http://redmine.named-data.net/issues/2200#note-92
> 
> InMemoryStorage in mgmt Dispatcher, design review
> 
> need: Junxiao, Alex, Yanbiao
> 
> http://redmine.named-data.net/issues/3000#note-27
> 
> Link: cache poisoning after forwarded Interest with multiple distinct Link
> objects
> 
> need: Junxiao, Alex or Spyros, Beichuan
> 
> http://redmine.named-data.net/issues/3251
> 
> Arbitrary signature types in Data packets
> 
> need: Beichuan, Lixia, Lan, Alex
> 
> http://redmine.named-data.net/issues/3210
> 
> Doxygen documentation checking on Jenkins
> 
> need: Junxiao, Alex
> 
> http://redmine.named-data.net/issues/3259#note-2
> 
> FacePersistency::NONE
> 
> need: Junxiao, Alex
> 
> 
>