[Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy?

Marc.Mosko at parc.com Marc.Mosko at parc.com
Tue Mar 15 12:20:05 PDT 2016

On Mar 15, 2016, at 10:58 AM, Alex Afanasyev <aa at CS.UCLA.EDU<mailto:aa at cs.ucla.edu>> wrote:

On Mar 15, 2016, at 10:43 AM, <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>> <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>> wrote:

On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" <ndn-interest-bounces at lists.cs.ucla.edu<mailto:ndn-interest-bounces at lists.cs.ucla.edu> on behalf of jburke at remap.UCLA.edu<mailto:jburke at remap.ucla.edu>> wrote:

sure - I don't want to expose names that identify me, or expose my
communication activities. given that, the "network" doesn't have the job
of finding things for me by partial names - I only want to expose the
details of my communication to a service that I have authenticated, and
only when those details are encrypted. the "names" visible to the
network in that sort of world just get the packets moving - and the only
LPM needed is LPM in the FIB to get me to one or more instances of a

So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys?   What about cert or key names that may reflect your identity being requested by the service during authentication?    If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here.

You don’t have to expose names of keys or certs to intermediary nodes. You only need to expose that information to the parties you choose.

Let me talk about "In-network discovery” for a second.

[5] **In-Network Name Discovery**:
  Interests should be able use incomplete names to retrieve data packets.

The first thing to say, is that in this phrasing, you mean the network layer, the forwarders, not the network as a whole.

Today we do discovery in many ways. Whether it’s mDNS, DNS, a SQL query, a google/bing query or a piece of ajax code. Sometimes we do ping or trace route or god forbid snmp. (Did I mention routing protocols?) There are many ways to do “discovery”.

Because of the nature of NDN/CCN in naming everything, we have to do one extra step that other protocols don’t; the discovery of the name of a network packet.  Many times this is not really discovery, it’s mostly like bootstrapping.  We need to figure out where to start, and once we have that we can continue. These are all fine goals and problems to have.

The way old CCN and NDN try to solve these is by having prefix matching on interests.  The argument is that if the network-layer helps with this, then things will be better.  I have yet to see a good argument of why this is the case.

We’ve had this discussion a number of times.  You can do everything the current LPM system can do if you create a simple service that lets you do LPM queries.  Let’s call this service the Selector Service.  Any node running a Selector Service can then process interests with selectors and generate replies. Any node running a Selector Service can also verify these replies if it wishes (under the same constraints as the current system).  Any node NOT wishing to reveal what they have in their caches, or not wanting to waste the extra compute cycles may decide not to run that service.

I would like to know what makes the built in LPM mode advantageous than the Selector Service method.

I’m not saying that this Selector Service is what I would implement for discovery, but, there it is in case somebody wants it.

LPM matching on interests throws a few wrenches in the system. Here are a few:

- You never know what you’re going to get. You don’t know if the data you got is what you wanted. (how could you?, if you had known, you would have asked for it directly).  Almost by definition, the only way for you to know if what you got is what you wanted is to ask again to get more information.  Apparently in some solutions that use this system, you actually have calls that to succeed need to time out.

- “What’s in the network?” is fragile.  People claim that you can do this in-network-layer discovery to find if one packet/piece of data (that I only partially know how to prefix-name) is in the connected network. For example, if the producer disconnected or if there is a network partition. This doesn’t really work without some very big participation from routing or by flooding the network.  I’m not sure if it’s obvious to people how bad flooding the network is.  The situations where this is considered advisable are very special. Why subject the world to this very special case that can lead to disaster?

- LPM interests can be abused by malicious nodes.  A malicious cache can reply with valid content in a way that creates extra traffic.

I think sometimes there is a misunderstanding that exact matching means you must know everything in advance. This is not the case. It just means that I get to ask a specific question and somebody needs to stand up and answer it.

Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit?

In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery.  There is simply no way it is possible to have an "oracle" that can tell you what is there.

I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery.  The communication will not work otherwise without having an out-of-band channel to tell you what to fetch.  What is the best way to achieve this is a completely different question.

So it is impossible to run a discovery agent on each content store that runs a different discovery protocol than NDN’s in-network discovery?

consumer interest:
payload = “query = select * from CS where name like ‘%superman.mov/h264/%/manifest’ and keyid=0x1234 and expired=false”

From content store:
payload = LINK /acme/5/_content_store_/ver=12/chunk=0

payload = rowset {
{ /WarnerBros/1978/superman.mov/h264/rate1/manifest, hash 0x12777, keyid 0x884844 },
{ /WarnerBros/1978/superman.mov/h264/rate3/manifest, hash 0xaaaaa, keyid 0xbbbbb },

consumer interest:

Acme #5:
more rowset

consumer interest:
payload = “exclude /acme/5, query = select * from CS where name like ‘%superman.mov/h264/%/manifest’ and keyid=0x1234 and expired=false”

and so on….

And a note note.  It is not LPM!  It is fetching data with interests that don't have a full name (if needed with hash digest.


Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160315/02f64a90/attachment.html>

More information about the Ndn-interest mailing list