[Nfd-dev] Adventures and questions in setting up a ndnping server on the ndn testbed

[Burke, Jeff]

Hi Junxiao,

Thanks.  I understand the mechanism now, based on your explanation, but not the motivation.

Why shouldn’t the device publishing /A/B/C be able to provide its cert (claimed proof of being able to publish in /A/B/C) to the upstream forwarder directly at the time of registration of /A/B/C (if necessary), rather than relying that some other node be up and available to provide its own certificate?

Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu>
Date: Sunday, September 11, 2016 at 8:05 PM
To: Jeff Burke <jburke at remap.ucla.edu>
Cc: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] Adventures and questions in setting up a ndnping server on the ndn testbed

Hi Jeff

You published /A/B/C certificate, which has a name starting with /A/B/KEY/C, on the "ping server".
The "ping server" only has private key for /A/B/C identity, so it cannot register /A/B/KEY or /A/B.
As a result, the router is unable to retrieve /A/B/C certificate because there's no FIB entry match /A/B/KEY/C.

If you add /A/B private key onto the "ping server", it registers /A/B back-route, and /A/B/C certificate would be reachable.
If you want to avoid adding /A/B private key onto the "ping server", move the repo-ng instance to the machine that has /A/B private key, and keep that machine running 24x7. This also ensures /A/B/C certificate is reachable.

Yours, Junxiao

On Sun, Sep 11, 2016 at 7:58 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Hi Junxiao,

I do publish the cert for /A/B/C.  But, the certificate in question (for /A/B) corresponds to /ndn/edu/ucla/jburke, which should be published by the testbed node for /ndn/edu/ucla, right?  In this particular case, do I need to publish it? I thought this was taken care of by the repos on each corresponding testbed node.    (e.g., ndnpeek /ndn/edu/ucla/KEY/cs/lixia returns a key, and I am not sure Lixia is running a repo for it?)

So I think the problem is a different one. As you’ll see in the extended explanation that was below the signature of my email, the difference between what works and what doesn’t is whether I provide a publisher for /A/B or not, but whether that private key (for /A/B) is installed and available for signing on the host that is running the ping-server for /A/B/C.   There seems to be a dependence on this in the auto prefix registration step.

--

Regarding your comment on documentation:
> If a technology (in this case, the NDN testbed) is widely used, there will be blog posts, StackOverflow answers, and other information scattered across the Internet, and user can use search engines to find them. For example, my article Let the World Reach Your NFD can be found by Google search "how to configure nfd auto prefix propagation".

This seems like a longer discussion. I agree in concept (I think), but in practice with NDN’s current state, there’s not enough crowdsourced information to make this the only viable way to figure out how to use things right now.   There are not many people besides you writing blog entries in such detail! :)

Thanks,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160912/05e993d6/attachment.html>