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

[Burke, Jeff]

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

From: Junxiao Shi <shijunxiao at email.arizona.edu>
Date: Sunday, September 11, 2016 at 7:44 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

Yours, Junxiao

On Sun, Sep 11, 2016 at 2:51 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi,

I am trying to get a handle on automatic prefix propagation in the wild, and have three questions:

#1 –

I have a testbed cert assigned for /A/B, where A=/ndn/edu/ucla and B=jburke.   I am bringing up a node that I only want to publishe content, starting with a ping server, in the namespace /A/B/C.

So first, I make a new cert for /A/B/C and sign it with my cert for /A/B.  I put the cert for /A/B/C into a repo running on my node. Then, I add a route from /A/B/C to the testbed node for /A.

Given that the trust chain is set up properly, auto-prefix propagation should take care of the rest, right?

Unfortunately, this does not work in practice unless the cert for /A/B is also installed on the node publishing /A/B/C.

As described in Issue Your Own NDN Certificates<https://yoursunny.com/t/2016/ndncert/>, /A/B certificate does not need to be installed on the node publishing /A/B/C, but the certificate must be reachable from the router.


Is this a feature or a bug? I do not want that node to have access to my private key for /A/B, merely to be authorized by it for publishing /A/B/C.  And I do not want to have to stand up a node to publish /A/B just to get /A/B/C on the testbed.

Until #2766 protocol is defined and related features are implemented, /A/B certificate must be reachable from the router. To make /A/B certificate reachable, you need to keep a node running 24x7 to publish /A/B/C certificate which is under /A/B/KEY prefix. This is the only node that needs to have /A/B private key, so that it can register /A/B back-route with auto prefix propagation to make /A/B/KEY prefix reachable from the router.


See a long log of how I figured out this requirement at the end of the email.  (Pointers to what docs I could have read to have understood this from the start would be great.)

Issue Your Own NDN Certificates<https://yoursunny.com/t/2016/ndncert/> has the procedure.


#2 –

Why must I manually register localhop/nfd, which Junxiao mentions in his article and recent emails, upon connecting to a hub for automatic prefix propagation to work?

$ nfdc register /localhop/nfd udp4://spurs.cs.ucla.edu<http://spurs.cs.ucla.edu>

Or more specifically, why is this new step explicit rather than automatic?  (When would I not want it to happen? And if that’s an unlikely scenario, perhaps the more likely scenario should be default behavior?)

Requiring /localhop/nfd to trigger auto prefix propagation because this prefix tells NFD-RIB which face is the testbed router. The resulting FIB entry is also used to forward prefix registration commands.

Registering /localhop/nfd is automatic if you use ndn-autoconfig program. ndn-autoconfig is designed specifically for the testbed.
nfdc works at a lower level. It has no means to know whether a registration is a testbed router.



#3 –

Regarding both questions above, as a user of the testbed and NFD, where would I go to learn about these specifics, or to contribute corrections or examples as below?  Right now, I think the detailed information is distributed across some documentation, redmine issues and Junxiao’s articles, but it seems like we need a community-authored cookbook for working with the testbed, a FAQ, and/or some type of tutorial that is kept up to date as new features (like automatic prefix propagation, cert requirements, etc. are put in place.)  Would it make sense to start something like this?

No. 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<https://yoursunny.com/t/2016/nfd-prefix/> can be found by Google search "how to configure nfd auto prefix propagation".

It makes sense to index good articles in a wiki site (similar to CHIP Community<http://www.chip-community.org/index.php/Main_Page>) or forum (sticky posts). However, you cannot force users to contribute directly to the wiki/forum. Users can post them anywhere, and good articles are linked from the wiki/forum.
I'm already doing so on NFD wiki and nfd-dev mailing list (which I treat as a forum), but for coders (in "HOWTOs for n00b" section).


Thanks,
Jeff

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