[Ndn-interest] NDN protocol principles: no privacy?

Marc.Mosko at parc.com Marc.Mosko at parc.com
Sun Apr 3 17:47:55 PDT 2016


So that I am clear on this, to use the in-network discovery approach and find the latest version of data, one would need to:

1) Issue an interest for /foo, right most child
2) Get back some /foo/ver=5/segment=0/hash=123
3) Issue an interest for /foo, excluding up to and including ver=5, right most child
4) Get back some /foo/ver=6/segment=0/hash=444
5) issue an interest for /foo excluding up to and including ver = 6
6) get back a NACK (or timeout)
7) issue an interest for /foo/ver=6/segment=0 excluding last seen hash (e.g. 444)
8) get back either a duplicate name with different hash (go to 7 and add another exclusion) or get back a NACK (or timeout)

one would then need to make some sort of decision (e.g. keyid or something intrinsic in the data) to determine which version 6 to use (or maybe all).

I’m not clear who issues the NACK in steps 6 and 8. I assume it would be an authoritative source (which might not exist in my connected component of the network, in which case they would be timeouts).

Is that correct or did I miss something?

Marc

On Apr 3, 2016, at 9:00 PM, Lixia Zhang <lixia at CS.UCLA.EDU<mailto:lixia at cs.ucla.edu>> wrote:


On Apr 3, 2016, at 12:56 PM, Dave Oran (oran) <oran at cisco.com<mailto:oran at cisco.com>> wrote:


On Apr 3, 2016, at 3:06 PM, Lixia Zhang <lixia at CS.UCLA.EDU<mailto:lixia at cs.ucla.edu>> wrote:


On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <rdroms at cisco.com<mailto:rdroms at cisco.com>> wrote:

In the icnrg meeting, we didn't have time to discuss this sub-bullet of principle 2:

Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.

I need help understanding how the phrase "new versions of immutable data packets" makes sense.  "new version" and "immutable" seem contradictory. Jeff promised get me some help, here, if I moved the discussion to the mailing list.

- Ralph

I can see how the wording could lead to confusion.
my understanding of what it is meant to say is this:
• /foo/bar/ICNslides/v1 is immutable data
•  (for simplicity lets assume it's just one data packet here)
• When I make changes to the slides, I produce /foo/bar/ICNslides/v2
Lixia

What if I have a stateless producer that does not remember enough to maintain a monotonic (or worse, a sequential) counter, or if I have a distributed producer and it’s inconvenient/infeasible to run an agreement protocol to maintain the version number? Is it in fact considered an “epic fail” for a producer to create two different bags of bits (and hence different hashes) that have identical names?

I just used a simple example to mean
- data is immutable
- updated name should have a different name.

yes name collision may occur in distributed production scenario. The ultimate way to distinguish different data packets is by their full name (i.e. name with implicit digest).

In the same vein, is the following legal:

At time T0, I create object with name a/b/c and bits “dsfasdfasdfadsfadfa”, and expiration time T0+deltaT.
Then, At time T1=T0+deltaT+epsilon, I create object a/b/c with bits “fgsdfgsfgsdfgsfgfg” and expiration time T1+deltaT.

If not, why not?

Personal view:
- as far as application development is concerned: one should use different names for different data to the extend possible.
- the last resort to distinguish different data is by name with digest.

Lixia

On Mar 15, 2016, at 1:01 AM 3/15/16, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:


On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <tailinchu at gmail.com<mailto:tailinchu at gmail.com>> 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.

Immutability is related to in-network discovery with LPM.  If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as “discovery”). This devalues ndn as an “universal" protocol.

Could you please define immutable?  Do you mean that a single publisher will never use the same name for different contents?  Is that mandatory or enforceable?  Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet?

I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery.  One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration.




On Mar 14, 2016, at 12:10 PM, Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:

interesting -

On 3/14/16 11:27 AM, Burke, Jeff wrote:

[...]
RFC 6973 takes a nice approach, for example, by offering
definitions of some technical properties and mechanisms, but not trying
to formulate an overall definition of "privacy".

So I can try to understand your point here - do you agree with the
authors that the primary privacy concerns are those of individuals? (Or,
more generally, are corporations people here for this discussion - a
more generic "data owner"?)


hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B?

The editors there say
that the body of the document, the discussion of the tradeoffs and
alternatives, is the best way they could come up with to approach that
abstraction. in practical terms, as you know well I think there's been
an over-reliance on opportunistic caching in ICN generally, and as a
result observability and correlation are defined to be positive
properties of ICN communication rather than harmful ones.


Would I be correct to parse your concerns into two pieces that may
have different implications:

- Confidentiality of request (e.g., the consumer side)
- Confidentiality of publication (e.g., the publisher side)


I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"?

[...]


most of these six "principles" sounded like "mechanisms" to me - the
list felt like the end of a discussion about alternatives and the best
ways to implement an architecture, rather than the start of one. it
sounded like "we're tired of questions about LPM in the PIT, so we're
going to stop calling that a possible mechanism and start calling it an
inevitable, immutable, unquestionable 'principle'".

Well, to take LPM for an example - it's actually not mentioned in
the
principle doc that Alex sent. The principle I suspect that you are
referring to is:

[5] In-Network Name Discovery: Interests should be able use
incomplete
names to retrieve data packets.
A consumer may not know the complete network-level name for data, as
some parts of the name cannot be guessed, computed, or inferred
beforehand. Once initial data is received, naming conventions can help
determine complete names of other related data:


* majority of interests will carry complete names

* in-network name discovery expected to be used to bootstrap
communication)



Can you explain your objection in these terms?


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.

Thanks,
Mark
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

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


More information about the Ndn-interest mailing list