[Nfd-dev] PIB service causes remote registration of every prefix

[Junxiao Shi]

Hi Dave

Yes, the laptop's certificate is issued by a CA who has authority over a
shorter prefix.
For example, CA=/ndn/edu/arizona, laptop has /ndn/edu/arizona/cs/shijunxiao
certificate issued by /ndn/edu/arizona. This laptop would be allowed to
register /ndn/edu/arizona/cs/shijunxiao, or a prefix under this namespace.

Remote prefix registration uses the same RIB Management protocol <
http://redmine.named-data.net/projects/nfd/wiki/RibMgmt>.


The laptop's top level certificate is published by the CA, and is already
accessible from the router before the registration.
The router will verify the trust chain before accepting the registration.

Yours, Junxiao

On Thu, May 7, 2015 at 7:42 AM, Dave Oran (oran) <oran at cisco.com> wrote:

>
> > On May 7, 2015, at 10:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> >
> > Hi Dave
> >
> > There's no risk of cache poisoning.
> > The gateway router registers a route to the laptop only if the laptop
> user owns the prefix, as proved by a certificate.
> What you are saying is that the route registration is signed by a
> certificate specifically issued for that prefix to the user holding the
> corresponding private key, and this was done by a CA with authority over a
> shorter prefix, right?
>
> What is the exact protocol machinery for registration? (sorry if this is
> obvious and written down somewhere and I haven’t seen it).
>
> >
> > There's no increased risk of DoS'ing the certificate store (PIB service).
> Agree
> > The DoS risk is the same when a laptop registers at least one prefix
> onto the gateway router.
> I’m not clear if there’s a hazard here. If the router checks that any
> prefix registered also has a path to the certificate registered and that
> the cert has been verified, I can see how this prevents
> DoS-by-fake-registrations. Is that in fact what’s done?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150511/e36b6093/attachment.html>