NFD

An additional problem in note-5 design is: a node in consumer region can erroneously insert SelectedDelegation.

In "choose and set SelectedDelegation" procedure, if the consumer host has a FIB entry ndn:/, any delegationName can match this FIB entry and be selected as SelectedDelegation.

Even if we change the procedure to ignore ndn:/, a generic FIB entry such as ndn:/ndn (covering all sites on NDN testbed) would cause a similar effect.

20150703 conference call discussed these problems but didn't reach a conclusion.

Lixia prefers to start with a simple solution, but disagrees with the assumption of having only one delegation per Link.

20150708 conference call discussed note-6 question.
The solution is:

• Hosts in consumer region should install default route in ndn:/. Operator shouldn't use ndn:/ndn as default route.
• Given an Interest with Link but without SelectedDelegation, forwarding should lookup FIB with the first delegation Name.
  • If lookup matches the FIB entry ndn:/ with at least one nexthop record, it's assumed that the Interest is still in consumer region. It's forwarded according to the matched FIB entry, but SelectedDelegation field is not inserted.
  • If lookup matches a FIB entry other than ndn:/, or the FIB entry ndn:/ with zero nexthop record, it's assumed that the Interest has reached the first default-free router. The choice for SelectedDelegation should be made at this router.

Design will be updated to reflect this solution.

20150713 conference call approves the design in note-8.

This issue will remain open. It's not to be closed until the final design, including all items in note-1, is complete.

For this reason, implementation tasks are "related to" but not "blocked by" this issue.

As shown in pptx, the detection of whether interest reached the producer region is based on "router's name".

Why router's name, not network(s) to which this router belongs. Besides the fact that router's name not necessary matches network it servers, the implication here is that we are allowing directing interests towards a specific router. This by itself is worrisome for me.

My thinking is that the logic should be based entirely on "network name" (with the same logic: delegation name should be a prefix of network name). In the long run, there could be multiple network names to which router belongs.

Reply to note-12:

It makes sense to allow a router to be configured with multiple "network name"s, or more precisely, region names.

However, I'm unsure whether this complication is necessary at this moment in the minimal feature set.

From http://gerrit.named-data.net/#/c/2279/4/daemon/fw/forwarder.cpp:

why "isInProducerRegion" is overloaded with two meanings: that the link is not present and that the link present and something is in producer region

This is a consequence of "determine whether in producer region" algorithm design (in note-8).

I agree with the comment that it's better to having a separate decision point to test whether a Link object exists.

I'll amend the design after note-12 is resolved.

Junxiao Shi wrote:

Reply to note-12:

It makes sense to allow a router to be configured with multiple "network name"s, or more precisely, region names.

However, I'm unsure whether this complication is necessary at this moment in the minimal feature set.

I didn't suggest allowing multiple network names right now, only in the future (=long term). The only change that I would like to have right now is to check against the configured "network name", not the "router name".

Reply to note-12:

This won't work.

"network name", in NLSR sense, is equivalent to an AS number.

Every NDN router on the testbed is in the same network /ndn.
A router may be configured as: network=ndn, site=edu/memphis, router=cs/pollux.

Using NLSR's "network name" as mobility's "region name" implies mobility is never useful on the testbed.

I see the point now. I guess I don't fully understand the meaning of "site". In my mind, "network" is something like "/ndn/edu/memphis", i.e., a combined NLSR "network" and "site".

I would like to question #3026 requirement: "contain enough information to be used by NLSR to initialize itself". Semantics of NLSR (e.g., concept of routing domain, site) doesn't necessarily apply to NFD...

Just want to mention the following:

• NLSR is designed for intra-domain routing.

• We consider the NDN testbed as one network, hence /ndn is the network name, not /ndn/edu/memphis.

• If you want to test the LINK design for mobility, it's best to set up multiple networks, each running its own instance of NLSR and inject some routes to other networks at the border routers (e.g., the border router at /att injects a route to /verizon with itself as the originator into the NLSR for /att) also set up some static routes at those border routers to get to other networks.

We want not just "test", we want to actually use it on the existing testbed. Our implementation shouldn't depend on how NLSR is configured...

Considering current "intra-domain" configuration. LINK should include prefix that is routed globally and within a specific network (and recursively within smaller networks, if necessary). As I see, this prefix is not NLSR's network, it looks like NLSR's network+site, but it is even not this prefix. I think what we really should use are prefixes for which NLSR announces reachability: set of advertising.prefix configuration setting from nlsr.conf.

During NDNcomm2015 "Revisiting name-content binding: In-network name space operations" session, Nacho Solis (PARC) raises an attack scenario after I introduce forwarding logic for Link:

P--\     /--C
    S---R
E--/     \--A

• /producer is an unroutable prefix, and its legit Link object is /P at node P.
• C is a legit user who wants to retrieve /producer from P.
• A is an attacker who wants to poison cache for contents under /producer.
• E is controlled by producer, and its routable prefix is /E.

Steps:

1. C expresses an Interest with Link /P, which is forwarded along C-R-S-P.
2. A expresses an Interest of same Name with Link /E, which is forwarded along A-R-S-E.
   Note that it's unfeasible to "keep Names secret". For realtime streaming traffic, it's easy for A to keep track of the current Interest Names (by running a legit consumer elsewhere), and to predict next Interest Names.
3. E returns Data faster than P.
4. At S, the Data satisfies A's Interest only, because PIT entry of C's Interest does not have an out-record toward E.
5. At R, the Data satisfies both A's Interest and C's Interest, because PIT entries of both Interests have out-records toward S.
6. R caches E's Data with both Link object /E and Link object /A.
   This is cache poisoning.
7. R returns E's Data to both A and C.
   This prevents C from receiving legit Data.

The root cause of this attack scenario is: after R forwards an Interest with multiple distinct Link objects toward the same upstream, when Data comes back from S, R cannot determine which Link object was used to retrieve this Data.

One solution is: the Link object used to retrieve a Data should be returned along with the Data itself, e.g. in NDNLP header.

note-27 attack scenario is to be discussed in #3333.

note-1 item-4 and item-9 cannot start until a solution for this attack is ready.

3/15/16: JeffB pointed out that the 2015/08/14 slide deck did not clearly describe LINK processing (slide 11 box, slide 13 explanation). Deserve a revision.

Junxiao, will you be able to implement stripping of the Link object when an Interest arrives at the network region (I created a separate issue #3893 for that)?