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

Sun Sep 11 14:51:59 PDT 2016

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.

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.

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.)

#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

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?)

#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?

Thanks,
Jeff

---

Figuring out #1 above –

Node 1 (golem, Ubuntu 14.04)
Intended to be the ping server, set up as follows:

$ ndnsec list
* /ndn/edu/ucla/jburke/golem
  /ndn/edu/ucla/remap/jburke

$ nfd-start
...
$ ndn-repo-ng     # for keys, route should propagate later
...
$ nfdc register /localhop/nfd udp4://spurs.cs.ucla.edu
...
$ nfdc register / udp4://spurs.cs.ucla.edu
...

# The following step works with or without registering /localhop/nfd, as I expect
#
$ ndnping /ndn/edu/arizona
PING /ndn/edu/arizona
content from /ndn/edu/arizona: seq=4967821016123099668 time=28.7008 ms
content from /ndn/edu/arizona: seq=4967821016123099669 time=26.6555 ms
^C

$ ndnping /ndn/edu/ucla
PING /ndn/edu/ucla
content from /ndn/edu/ucla: seq=2517646711465375070 time=14.1014 ms
content from /ndn/edu/ucla: seq=2517646711465375071 time=12.1235 ms
^C

$ ndnpingserver -t /ndn/edu/ucla/jburke/golem
PING SERVER /ndn/edu/ucla/jburke/golem

NFD on same host says -
1473622278.460591 INFO: [RibManager] Adding route /ndn/edu/ucla/jburke/golem/ping nexthop=264 origin=0 cost=0
1473622278.460591 INFO: [RibManager] Adding route /ndn/edu/ucla/jburke/golem/ping nexthop=264 origin=0 cost=0
1473622278.468520 INFO: [AutoPrefixPropagator] advertise /ndn/edu/ucla/jburke/golem
1473622278.468520 INFO: [AutoPrefixPropagator] advertise /ndn/edu/ucla/jburke/golem

And from the same host this works -
$ ndnping /ndn/edu/ucla/jburke/golem
PING /ndn/edu/ucla/jburke/golem
content from /ndn/edu/ucla/jburke/golem: seq=12577619585809314370 time=2.4881 ms
content from /ndn/edu/ucla/jburke/golem: seq=12577619585809314372 time=0.370532 ms
^C

Now, leaving the above ping server running, on Node 2 (cavimorph, Mac OS 10.11):

$ ndnsec list
* /ndn/edu/ucla/jburke
  /jburke
  /ndn/edu/jburke

$ nfd-start

$ nfdc register / udp4://spurs.cs.ucla.edu

$ ndnping /ndn/edu/ucla
PING /ndn/edu/ucla
content from /ndn/edu/ucla: seq=5912483167798969453 time=72.02 ms
content from /ndn/edu/ucla: seq=5912483167798969454 time=29.133 ms
^C

$ ndnping /ndn/edu/ucla/jburke/golem
PING /ndn/edu/ucla/jburke/golem
timeout from /ndn/edu/ucla/jburke/golem: seq=8690330602053050878
timeout from /ndn/edu/ucla/jburke/golem: seq=8690330602053050879
^C

What am I doing wrong here?

If I run the ping server on the second node (cavimorph) for /ndn/edu/ucla/jburke, I can ndnping it from the other machine just fine.
So the issue seems to be related to registering the longer name.

I don’t want this node to have the signing key for /ndn/edu/ucla/jburke, just for .../jburke/golem.  Does testbed policy prevent it from publishing data to the testbed even though it has a key signed by the parent that is signed by the appropriate testbed node?

Quickly try a ping server for the parent,   which fails because I don’t have the signing key (I guess) -

$ ndnpingserver /ndn/edu/ucla/jburke
PING SERVER /ndn/edu/ucla/jburke
...
from NFD,
1473624713.894229 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/edu/ucla/jburke/ping
1473624713.894229 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/edu/ucla/jburke/ping
...
[Btw, this error does not seem to propagate back to the application, so it has no idea the prefix hasn’t been propagated?  Pls respond to Issue #3733<https://redmine.named-data.net/issues/3773>.]

Ok, so as an exercise. I also install the /ndn/edu/ucla/jburke signing key on to this Node 1 (golem) and make it available, but not the default.

$ ndnsec list
* /ndn/edu/ucla/jburke/golem
  /ndn/edu/ucla/remap/jburke
  /ndn/edu/ucla/jburke                   <= new cert installed

Repeating the original steps above, I do everything and then try to ping.

$ nfd-start
$ ndn-repo-ng  # attempts to propagate ... see #3774<https://redmine.named-data.net/issues/3774> regarding incorrect error messages.
$ nfdc register /localhop/nfd udp4://spurs.cs.ucla.edu
now, here we see that autoprefix propagation takes place -
1473626687.921452 INFO: [AutoPrefixPropagator] advertise /ndn/edu/ucla/jburke
1473626687.921452 INFO: [AutoPrefixPropagator] advertise /ndn/edu/ucla/jburke
$ nfdc register / udp4://spurs.cs.ucla.edu
$ ndnping /ndn/edu/ucla
PING /ndn/edu/ucla
content from /ndn/edu/ucla: seq=5607246297517915673 time=16.5428 ms
content from /ndn/edu/ucla: seq=5607246297517915674 time=12.0276 ms
^C
$ ndnpingserver -t /ndn/edu/ucla/jburke/golem
$ ndnping /ndn/edu/ucla/jburke/golem
PING /ndn/edu/ucla/jburke/golem
content from /ndn/edu/ucla/jburke/golem: seq=3169930236227802087 time=2.59708 ms
content from /ndn/edu/ucla/jburke/golem: seq=3169930236227802088 time=0.404028 ms
^C

On the remote,
$  nfd-start
$  nfdc register / udp4://spurs.cs.ucla.edu
$  ndnping /ndn/edu/ucla/jburke/golem
content from /ndn/edu/ucla/jburke/golem: seq=6791844684297860820 time=65.478 ms
content from /ndn/edu/ucla/jburke/golem: seq=6791844684297860821 time=34.843 ms
^C

Success!

So, wait, I need the parent key installed, even though I am not attempting to register a prefix with it... why?

Let’s doublecheck that it’s because of having the parent key:

$ ndnsec delete /ndn/edu/ucla/jburke
OK: Delete identity: /ndn/edu/ucla/jburke
$ nfd-start
$  nfdc register /localhop/nfd udp4://spurs.cs.ucla.edu
$  nfdc register / udp4://spurs.cs.ucla.edu
$  ndnpingserver -t /ndn/edu/ucla/jburke/golem

Now it works... Because the prefix has persistent for awhile?

Ok, so this is what’s on spurs via ndn-status:

ndn/edu/ucla/jburke

FaceId

9875

Cost

15

Wonder how long automatically propagated prefixes last? Where would one look to figure this out?
Redmine!  https://redmine.named-data.net/issues/3211
Hm, can’t decipher what the terms in the state machine/transition table mean exactly, and no information on timing.
But the config file has a refresh interval of 300 seconds, so probably the lifetime is less than 300 seconds.

<... go have coffee for five minutes to see if the route goes away so we can doublecheck>

Indeed, seems less than that, route gone from spurs on ndn-status.

So, try ping again with identity deleted. Doesn’t work.

Ok, so indeed, I must have the /ndn/edu/ucla/jburke key installed on the host that wishes to register content for /ndn/edu/ucla/jburke/golem.

<WHY?>  [And, more to the process oriented nature of this email... what documentation should tell me this? ]

Reinstall key.  Reset default.   (Btw, you can make arbitrary names the default identity!  Try ndnsec set-default /chicken/wings. Issue #3776<https://redmine.named-data.net/issues/3776>.)

$ ndnsec list
* /ndn/edu/ucla/jburke/golem
  /ndn/edu/ucla/remap/jburke
  /ndn/edu/ucla/jburke
  /hello/chicken/wings
$  nfd-start
$  nfdc register /localhop/nfd udp4://spurs.cs.ucla.edu
$ nfdc register / udp4://spurs.cs.ucla.edu
$ ndn-repo-ng
$ ndnpingserver -t /ndn/edu/ucla/jburke/golem

Ok, that works for remote hosts.

Tried this a few times and it seems to work from different hubs.

<end>

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