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

Junxiao Shi shijunxiao at email.arizona.edu
Sun Sep 11 20:48:18 PDT 2016


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> 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/20160911/b2524f79/attachment.html>


More information about the Nfd-dev mailing list