ndnrtc

Changing the user prefix does not eliminate NdnCon's dependency on nfd-autoreg.
nfd-autoreg is still used to create back-route for ndn:/ndn/broadcast which is used for conference discovery and chatroom services.
However, the bulk of Interests are no longer flooded, so it's still beneficial.

Also, automatic prefix propagation itself depends on nfd-autoreg to fetch certificates, but the traffic volume is much smaller.

More information about automatic prefix propagation can be found in NDN Memo: Automatic Prefix Propagation, to be published as a technical report.
Contact @Yanbiao for a draft.

A dependency of using automatic prefix propagation is for every participant to have an NDN testbed certificate.
Currently, ndncert is broken that operators cannot issue certificates and site certificates are expiring.
These must be fixed before users can request certificates.

The issue description is not correct. The change must not be done blindly to ndn:/ndn/guest/someone%40example.com/ndnrtc form. The prefix name should be inferred from the NDN certificate that is currently installed on the system, which can correspond to guest or testbed-site specific prefix. This namespace is equivalent to "identity" of the certificate.

For example, my cert is

• /ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

The corresponding identity and namespace under which I can publish (and automatically propagate)

• /ndn/edu/ucla/cs/aa

Peter, can you comment on the impact on the application, and whether we can roll this into the next release and text on Wednesday?

is automatic prefix propagation deployed?

Yes.

Automatic prefix propagation is a feature in end hosts. It's implemented since NFD 0.4.0.

It relies on prefix registration commands under /localhop/nfd prefix, which is enabled on NDN testbed since 2015.

Need to clarify implementation details for myself first.

Alex Afanasyev wrote:

The issue description is not correct. The change must not be done blindly to ndn:/ndn/guest/someone%40example.com/ndnrtc form. The prefix name should be inferred from the NDN certificate that is currently installed on the system, which can correspond to guest or testbed-site specific prefix. This namespace is equivalent to "identity" of the certificate.

For example, my cert is

• /ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

The corresponding identity and namespace under which I can publish (and automatically propagate)

• /ndn/edu/ucla/cs/aa

User can have multiple NDN certificates installed, can't she? Thus she must explicitly select which certificate to use, right?
Right now, registering routes is simply: $ nfdc regsiter / udp://<hub>. How different it will become with this approach?

User can have multiple NDN certificates installed, can't she? Thus she must explicitly select which certificate to use, right?

I suggest providing a dropdown menu for the user to select an identity; a user cannot publish any stream before a valid identity is selected.

An identity (and thus the user prefix) is globally reachable only if the connected gateway router announces a prefix of it, thus the end host must connect to the correct gateway router.
Application may verify the prefix is announced by the connected gateway router by local prefix discovery procedure.

Right now, registering routes is simply: $ nfdc register / udp://<hub>. How different it will become with this approach?

It's best to connect with ndn-autoconfig tool.

Otherwise, the end host must also manually register ndn:/localhop/nfd toward the gateway router to trigger automatic prefix propagation.

@Junxiao is there a defined structure for certificate name which I can use to infer a prefix? I.e. in this example:

/ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

Should prefix be composed of anything before KEY and between KEY and ksk-.*?

The libraries organize certificates under concept of identity. You just need to take the identity (enumerate available identities).

At 20160324 NFD call, Alex points out that changing the user prefix is not a prerequisite of using automatic prefix propagation.
One can enter /ndn/edu/ucla/aa to NDN publishing prefix box, which would generate a user prefix that falls under this identity name which is compatible with automatic prefix propagation.
Therefore, this issue does not block #3568.

However, Alex still suggests proceeding with this issue as a UI improvement.

@Junxiao, ndncon has test producers (and there will be arbitrary number of producers for large scale tests in the nearest future). I assume all of these need to have a testbed certificate to be discoverable, right? How should we generate these certs?

Answer to note-20:

Suppose /ndn/edu/ucla/remap/mrfoo wants to run two test producers demo1 and demo2, he can creates two keys and sign them with his main testbed certificate.
The two keys would have identities /ndn/edu/ucla/remap/mrfoo/demo1 and /ndn/edu/ucla/remap/mrfoo/demo2.

These two keys should be published by mrfoo in his own repository.
This repository listens on prefix /ndn/edu/ucla/remap/mrfoo/KEY, and can run on either or both hosts, or on another machine.
Consumers who want to verify the packets from test producers will be retrieving certificates from this repository.
mrfoo's main testbed certificate is already available on the repository on REMAP gateway router, and is not served from this repository.

As an implication of #3568 before #2766, only certificates directly requested from ndncert can be used with automatic prefix propagation.
Thus, mrfoo must install his main testbed certificate into the NFD KeyChain on both test producers, and the machine with his key repository if it's separate.
Since automatic prefix propagation prefers the shortest identity, the main testbed certificate will be used to register the back routes.

An unfortunate consequence is that both test producer will have the same back route prefix /ndn/edu/ucla/remap/mrfoo instead of the more accurate /ndn/edu/ucla/remap/mrfoo/demo1 and /ndn/edu/ucla/remap/mrfoo/demo2.
This can lead to inefficiency in #3219, but it would only affect mrfoo's test producers and does not impact other users.
This limitation can be lifted only after #2766 and related changes, after which mrfoo can delete his main testbed certificate from the test producers so that a more accurate prefix will be registered by automatic prefix propagation.

Large scale tests are more complicated.
In those tests, an experimenter may need to connect a producer to a gateway router other than his own institution.
To have automatic prefix propagation register a prefix under another institution's routable prefix, a certificate under that institution is needed.

I've proposed ndncert Issue 4 that would allow an experimenter to request a certificate at another institution, and ndncert Issue 5 that automates the certificate issuance procedure so the experimenter can write a script to request certificates from all institutions (the script can also access the email inbox and click the link automatically).