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

[Alex Afanasyev]

> On Mar 15, 2016, at 10:43 AM, <Ignacio.Solis at parc.com> <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 on behalf of 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
>>> service.
>> 
>> 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.

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.

---
Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160315/ad242939/attachment.bin>