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

[Burke, Jeff]

Hi Junxiao,

Thanks. Both of these options seem appealing, probably #2237 most of all.

Jeff


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

Currently, the validator is responsible for collecting all certificates by sending Interests. This requires the certificates to be reachable, before prefix registration command can be fulfilled.

#2766<https://redmine.named-data.net/issues/2766> designs key-bundle, which shifts the responsibility of collecting certificates from the validator to the signer. The "ping server" should collect all certificates, and send them along with the prefix registration command (which would carry three certificates, /A /A/B /A/B/C).
This does not depend on you running a 24x7 server to publish your sub-certificates. This also has lower latency because there aren't multiple round-trips for certificates retrievals. The drawback is that every command carrying a key-bundle would be larger.

#2237<https://redmine.named-data.net/issues/2237> has a different proposal specifically for /localhop prefix registrations: NFD-RIB can direct Interest for certificate retrievals to the end host who sends the commands.
However, there's security concern in #2237-3<https://redmine.named-data.net/issues/2237#note-3>, and operational difficulty in #2237-8<https://redmine.named-data.net/issues/2237#note-8>.

Yours, Junxiao

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

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

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