Subject: Re: [icnrg] The myth of meaningful names (was: Locator hint)

From: "Thompson, Jeff" <[email-masked]>
Date: Mon, 19 Oct 2015 15:20:59 +0000

Hi Ravi,

> the whole name is a persistent ID

Do you expect to be able to grab a random content object from the network (not participating in the application which produced it), look at its ID and do something with that ID? What? I think to burden is on you to justify why anyone should be able to look at a content object's ID and do something with it.

Cheers,
- Jeff T

From: icnrg <[email-masked]<mailto:[email-masked]>> on behalf of Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 14:08:00
To: Jeff Thompson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] The myth of meaningful names (was: Locator hint)

Hi Jeff,

So it depends on who suggested the routing prefix part of the name to the producer, does that come from the network ?, I don’t think that is the case. What I understand is that the whole name is a persistent ID, it only happens that applications share that authority prefix hence is able to make use of name aggregation,  and no matter where you publish this content object should always carry the same name. In this sense, I disagree with the separation you describe, also a reason for the LINK object proposal in NDN.

Regards,
Ravi

From: Thompson, Jeff [mailto:[email-masked]]
Sent: Friday, October 16, 2015 1:09 PM
To: Ravi Ravindran; [email-masked]<mailto:[email-masked]>
Subject: Re: The myth of meaningful names (was: Locator hint)

Ravi writes:
> Also the notion of nameless objects seems to contradict, when the basic primitive of ICN  is named data.

No contradiction from current practice. Here is an interest name that I just grabbed from the NDN test bed: "/ndn/edu/ucla/remap/ndnrtc/chat/remap/F6PCWlqWrV/1444850865/1". The prefix "/ndn/edu/ucla/remap/ndnrtc/chat/remap" is only useful to route the interest to the application. All the thousands of interests flying towards this application have the same prefix. The last part "F6PCWlqWrV/1444850865/1" only means something because the producer application told the consumer application to ask for it. This name in no way "self-describes" the object, so it is in effect "nameless" already from an outside observer. There is little difference if the producer application told the consumer application to ask for an object by hash. This is similar to how I understand the problematically-termed "nameless object": An object is requested in an interest with a routable prefix and another part (the hash) which the producer application told the consumer application to ask for.

- Jeff T

From: icnrg <[email-masked]<mailto:[email-masked]>> on behalf of Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 12:22:00
To: Dirk Kutscher <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] Locator hint

Agree that we shouldn’t mix the two semantics that of a ID and a Locator, they operate and are managed in two different domains, one at the application and the other at the network level. Also the notion of nameless  objects seems to contradict, when the basic primitive of ICN  is named data. All this comes by mixing the ID/locator definitions, resulting in Interest message carry locators which are supposed to be meant for persistent IDs; a clear separation of the two in the protocol will serve many purposes, manifests, mobility, routing scalability. Agree there are security implications like cache poisoning or exploitation use of these name separation and should be addressed considering the different trust context.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Friday, October 16, 2015 10:35 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Locator hint

Not disagreeing, but: another way of seeing this is that entangling object identification, representation of organizational structure and location information in an aggregatable fashion in a single naming framework is likely to cause some headaches – and we are currently figuring out how to disentangle this again – with names hashes and nameless objects.

We want to be able to connect a bunch of ICN nodes locally, e.g., in a building automation scenario, and address Interests to semantically meaningful names like “/jp/yokohama/pacifico/room123/light-switch42” and want the same concept and names to be useful for global-scale communication. This can only work with a few very strong assumptions: We can get inter-domain routing to work based on such names – and there is no  mobility.

Obviously, flat naming schemes are facing similar problems. One pattern here is to use some organizationally structured part of the name to look up: locators (or location hints) – indirection…

Dirk

From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Freitag, 16. Oktober 2015 18:37
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Locator hint

The Locator Hint or Link Object are proposed solutions to a big ICN/CCN/NDN problem, namely the misguided belief the name is independent of location.  This is a somewhat incorrect assumption if we also believe, at the same time, that the name is used for routing.  By definition, routing is location.

There are numerous ways to get around this contradiction.

1- We allow anybody to publish any name anywhere and have the network look for it (in other words, no routing, just discovery)
2- Have routing update on the fly (allow any node to advertise, via routing, the presence of name/namespace)
3- Do some form of indirection

In this email we’ll rule out options 1 and 2, which have some serious scalability issues for a real network.  That leaves us with option 3.

Locator Hints and Link Objects are in effect a version of option 3.  CCNx uses manifests to indirect to hash based names, also a version of 3.

The Link Object proposed in this paper gets rid of cache poisoning with a number of techniques that boil down to one big sacrifice:

- "The cache can then impose the restriction that only interests carrying the same link object can be satisfied with the specific instance of the data item."

Basically, what it’s saying is that if you retrieve something with the name /a/b with a link to /foo/bar  it can only be answered by an interest with the name /a/b and a link to /foo/bar.   Effectively, we are routing and matching /foo/bar/a/b when talking about object /a/b.  Disadvantage: A request for /a/b will not match the object (this would lead to cache poisoning)[1].  Advantage: The signature for /a/b (the object) can be done at a different level than the signature of /foo/bar/a/b (the link).

Note that this is a form of encapsulation.  I could achieve similar results by just encapsulating /a/b into /foo/bar/a/b and not require any link object.

The paper suggests verifying link objects. This is not sufficient to prevent poisoning.  I can have a valid link object (from an attacker) that brings me  an invalid content object.  If that content object is matched on name then poisoning will occur. The only way around this would be to have a reverse crypto mapping from the object name to the link object. (Like a signed content object + link object together from the content object’s key).

The paper also mentions that caches can check signatures and consumers can use excludes to help with poisoning. This is unscalable for a number of reasons and probably deserves another thread.

The current CCNx approach is to use hash based naming and objects with no names (only implied hashes). This allows us to get around many of these problems.  NDN could potentially use similar techniques (with or without the link object).

Nacho

[1] Some people believe that we’re not going to be in a world where this type of caching matters, so this may not be a disadvantage.

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>

On 10/16/15, 12:22 AM, "Andrea Detti" <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,
do you remember this old discussion?

Citing DaveO "While we may be forced into doing something like this ultimately....".

Well, this email is just to point out that NDN team embraced the Locator Hint, aka Link Object, principles in their NFD software, with a clever technique to avoid cache poisoning .

References:

http://redmine.named-data.net/attachments/download/427/forwarding-hint_20150814.pptx
http://named-data.net/wp-content/uploads/2015/03/SNAMP-NDN-Scalability.pdf
see also "network_region" configuration section in nfd.conf

Regards,

Andrea

On 09/01/2015 23:38, Andrea Detti wrote:
Great news.
Is there already a document presenting these interesting features or it will be released shortly ?

Andrea

On 01/09/2015 08:06 PM, [email-masked]<mailto:[email-masked]> wrote:
CCN 1.0 has gone major revisions since the old CCN.  In the current system
there are a number of features that make these issues less of a problem.

Specifically, we have Manifests and Name-less objects.  These basically
allow you to have name indirection and objects hosted independently of
location.

The name, which for us is a network name, is what the network uses to find
stuff. It¹s easy to thing of this as the same as the user defined name.
In some cases it is, but in some cases it might not be.

In CCN we can currently use manifests to do a form of secure translation
of one name to another. There are some limitations in terms of publisher
but the primitives are currently holding up for what we want to achieve.

So, to answer your initial question, I think that the primitives we have
right now can give you a lot of what you¹re looking for.  Will we need to
have some extra locator or some other scalability mechanism?  Maybe, but I
think we can get far with the primitives we currently have.

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
[email-masked]<mailto:[email-masked]>

On 1/9/15, 10:26 AM, "Andrea Detti" <[email-masked]><mailto:[email-masked]> wrote:

I agree on all your points.

Consequently, I see two choices in front of us before to think to use
ICN in the global scale:

1) either we found a reasonable way to scale the routing by object name
(including mobility and multi-destinations/multi-sources cases);
2) or we found a reliable and secure translation mechanism.

Which of two will require less effort?

I do not know :-)

Andrea

On 01/09/2015 06:21 PM, David Oran wrote:
While we may be forced into doing something like this ultimately, every
time you introduce a level of indirection via some kind of translation
function, you dramatically increase the attack surface against the
system. Not only do you have to secure the input and the output values
in the packets, you also have secure the translations against spoofing
and the service that performs the translation against the full panoply
of vulnerabilities.

Routing hints are particularly tricky. I recall a proposal for NDN
routing hints that was presented at a recent NDN retreat that looked
superficially clever, but collapsed in a heap of security problems after
a few hours of scrutiny.

Invalidation of mappings is also quite delicate for routing systems
where the expectations of routing disruption durations are much shorter
than say, name mapping disruptions in systems like DNS due to
translation cache TTLs.

One thing that makes routing hints (as opposed to name->name
translations) particularly tricky for NDN/CCN-like architectures is
doing them in a way that does not break or substantially constrain
multi-destination delivery. It¹s much easier to do this with
single-destination delivery - one example of a full-worked scheme is the
LISP mapping service for IP.

DaveO.

On Jan 9, 2015, at 2:30 AM, Andrea Detti <[email-masked]><mailto:[email-masked]>
wrote:

On 01/08/2015 06:00 PM, [email-masked]<mailto:[email-masked]> wrote:
PARC will be releasing the next version of our working documents
shortly, before the icnrg meeting.  We have for a while supported an
Interest carrying a Payload field that can carry extended information
that is not part of the name.  Intermediate nodes do not process the
payload.

If the payload can make a difference to a dynamic content publisher,
then the requester must put a marker of the payload in the name ‹ i.e.
put the hash of the payload a a name component, or use a nonce.  This
will allow proper multiplexing of different payloads in the name.
I see that this is a way to indicate to the router which is the part
of the name that is relevant for the PIT/FIB purposes. And it sounds
good to me, since it speeds up the lookup processes.

However, let me pose a more general question: is it really "ICN
mandatory" to use a component of the object name to forward?

What we would lose, if we used the object name only for PIT and
caching operations and (optionally) another "routing info" field
completely decoupled from the name for FIB forwarding purposes?

If we do not lose so much, why do not open an ICN 1.01 phase (2.0 was
too ambitious ;-))  in which we recognize that routing by object name
creates scalability problem in the large area, and so in these cases
ICN can be helped by a plain old by routing by locator (aka routing
info, routing hint, label, forwarding alias, etc.)?

If this was obvious, probably it is now the right time to define such
a TLV. Simirarily to KeyLocator we could define a ContentLocator that
specifies a (or more) routable Name where it it is possible to found
the object.

I know that I am rediscovering the wheel since many other excellent
projects/researchers before have predicted that, e.g.

SAIL project 2010  ³Routing hints²

S. Shenker, 2011 - Naming in content-oriented Architectures: ³Šthe
fetch-terms enable the routing system to more easily find the object²

http://www.icsi.berkeley.edu/pubs/networking/ICSI_namingincontentoriente
d11.pdf

Presentation of D. Oran, 2011 - NDN and IP Routing: Can it scale? 
³ŠUse a translation lookup to convert from content name to routing
label(s)²

http://tools.ietf.org/group/irtf/trac/raw-attachment/wiki/icnrg/IRTF%20-
%20CCN%20And%20IP%20Routing%20-%202.pdf

Hermans et. al,  2012 - Global source mobility in the content-centric
networking architecture- ³Separate namespaces for identifier and
locators².
http://user.it.uu.se/~frehe489/publications/hermans12global.pdf

L. Zhang, 2013 - Scaling NDN Routing: Old Tale, New Design,
³Application names are used for caching and signature verification,
while the forwarding alias, which reflects the service provider of the
content producer, serves as a hint to routers about where the packet
may be forwarded²

http://named-data.net/wp-content/uploads/2014/08/ndn-tr-4-scaling-ndn-ro
uting.pdf

N. Solis (PARC developer of CCNx 1.0), presentation at CCNxCon 2013 
Ordered-Element Naming (OEN), ³I presented a matching system with order
of preference based on labels (which included hashes of content)²
http://www.ccnx.org/events/ccnxcon-2013/

      Regards,

Andrea
It is not mandatory that applications do this ‹ some data might
rightly belong in the name.

Using this method relieves the forwarding plane from having to
process and store in the PIT large names that make no difference in
routing.  It also means that the potentially large payload does not
need to be echoed back to the client in the response name.

The previous PARC spec is at
http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-02.html
.  It will be updated in the next day or so and we will send an email
to the list.

Marc

On Jan 8, 2015, at 8:19 AM, Mark Stapp
<[email-masked]><mailto:[email-masked]>
   wrote:

On 1/8/15 4:24 AM, Andrea Detti wrote:

Dear Mark,

I found rather interesting this question

"Is it really necessary to continue to force all of the information
in
Interests into the Name?  Wouldn't it be clearer to use the Name
only
for publisher/routing info, object name info, and segment/sequence
number?"

and wonder ICN community think about that. Especially with respect
to
the routing info.
That specific question has been open for quite a long time - not
really in the routing context however. One position has been that
Interests carry "only" a name, and therefore all application-specific
data must be in the name. Now in fact Interests have been permitted
to carry several additional "meta" items - such as filters/selectors
(another open topic) and timeout values. Another position asks
whether there are types of application-specific data that could also
be carried outside the Interest name. We've asked whether REST-ful
application state transfer might be one example.

I see a scalability problem with the ICN routing plane,
yes, of course - that's a very long-standing problem.

especially when

objects are multi-sourced (same object on my PC and on my phone) and
objects are provided by mobile devices.  This framework could be the
norm in the future.
that's ... certainly an assertion I've heard before, but "could be"
is about as strong as it gets. there are a lot of questions about
whether encapsulation mechanisms, or "name resolution" mechanisms, or
some other mechanisms will be needed to deal with the expected name
scale, whether or not there will be any significant of peer-to-peer
communication. personally, I think it's highly unlikely that my phone
will "publish" anything directly, but that's just another speculation
really.

at the moment, I'd be happy if there could be progress on even the
most basic aspects of messaging - such as what names look like,
something that seems truly fundamental.

Thanks,
Mark

_______________________________________________
icnrg mailing list

[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list

[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ravi Ravindran <[email-masked]>
Date: Mon, 19 Oct 2015 17:17:59 +0000

Hi Jeff,

Not sure if I understand the question, what I was getting at is the semantic of the Name of the produced content is only scoped in the context of the application or the service, and not bound by any networking requirements. So the producer should be able work with any number of content distributor for replicating its content and consumers get it from the vantage points, with network having a say depending on a given application’s context. Similar holds good for a mobile entity too, the producer should be publish the names which require mobility to its current point-of-attachment with network actively taking part in resolving it in an efficient manner.

Regards,
Ravi

From: Thompson, Jeff [mailto:[email-masked]]
Sent: Monday, October 19, 2015 8:21 AM
To: Ravi Ravindran; [email-masked]
Subject: Re: [icnrg] The myth of meaningful names (was: Locator hint)

Hi Ravi,

Cheers,
- Jeff T

Hi Jeff,

Regards,
Ravi

- Jeff T

Regards,
Ravi

Dirk

Nacho

Dear All,

References:

Regards,

Andrea

Andrea

Nacho

I do not know :-)

Andrea

DaveO.

      Regards,

Andrea

Marc

Dear Mark,

especially when

Thanks,
Mark

---

From: Anders Nilsson Plymoth <[email-masked]>
Date: Mon, 19 Oct 2015 22:46:33 +0200

Hi,

I think I agree with Ravi here, but many people seem to be talking
around each other due a lack of definitions. I think we should declare
the definition of these concepts, and what the options are, and then
work from there.

As to the namespaces, it seems to me that layering is not properly
considered in this discussion. I think a naming scheme similar to
current URL's makes sense, like what TelHoc is currently doing. Consider
a named object named as /icn/node1/app1/1asx313 . /icn/ would then be the
network prefix for the domain, /icn/node1/ would be a node within that
domain, /icn/node1/app1/ would be an application on that node, and
/icn/node1/app1/1asx313 would identify the specific object. The object
id, which could be any name assigned by the application, is
an application layer identifier. /icn/node1/ is a network layer identifier.
Inter domain routers would typically care about /icn/ prefix, while intra domain
routers would care about /icn/node1/.
/icn/node1/app1/ would have then have the role of
something like a port. The application itself would only really care
about 1asx313, but could use the full /icn/node1/app1/1asx313 to
retrieve the data. When storing data the application may specify only
1asx313, but the full named URL after the store operation would be
/icn/node1/app1/1asx313 created through the domain, node and
application identifiers. In IP world, this would be something like
http://node1.icn:app1/1asx313.
The possibility is also for routers to choose to treat this name as
flat, as mentioned. Nameless objects using hashes may also work here,
if the application uses the hash URL, or if its encrypted.

I think this concept should to a large degree be close to what most
people here are
talking about, and should cover the scenario Dirk
mentioned. Again, what are the common definitions?

Ravi, what would be the role of the content distributor when routers
cache data. Pre caching?

Considering producer mobility in this scheme would be much like
current Mobile IP considerations, which many of us have worked with.
If a node roams into a new domain, can it publish data within that
domain context, or should it use its home domain.

Thanks,
Anders Plymoth
TelHoc

On Mon, Oct 19, 2015 at 7:17 PM, Ravi Ravindran
<[email-masked]> wrote:
> Hi Jeff,
>
>
>
> Not sure if I understand the question, what I was getting at is the semantic
> of the Name of the produced content is only scoped in the context of the
> application or the service, and not bound by any networking requirements. So
> the producer should be able work with any number of content distributor for
> replicating its content and consumers get it from the vantage points, with
> network having a say depending on a given application’s context. Similar
> holds good for a mobile entity too, the producer should be publish the names
> which require mobility to its current point-of-attachment with network
> actively taking part in resolving it in an efficient manner.
>
>
>
> Regards,
>
> Ravi
>
>
>

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 19 Oct 2015 20:58:21 +0000

Naming and addressing.  A really hard problem and one, IMHO, not well
understood and more often than not, done wrong.

I'm hoping ICN can get it right (and perhaps the DTN folks can learn
something).

The best source I've ever seen regarding a detailed analysis of naming and
addressing is Jon Day's book "Patterns in Network Architecture: A Return
to Fundamentals"

There is a really good analogy in the book describing how a phone number
went from a physical point of attachment to a name referencing an
application.

Hope that helps.

Will

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 20 Oct 2015 12:47:38 +0000

Hi Anders,

Please see for my comments inline..

Regards,
Ravi

-----Original Message-----
From: Anders Nilsson Plymoth [mailto:[email-masked]] 
Sent: Monday, October 19, 2015 1:47 PM
To: Ravi Ravindran
Cc: Thompson, Jeff; [email-masked]
Subject: Re: [icnrg] The myth of meaningful names (was: Locator hint)

Hi,

Ravi > In the above example, my point was that the applications chooses /icn/node1 as a prefix because of a service reasons such as naming authority, trust context etc. independent of the any topology constructs. 

Ravi> Content distributors could be edge cloud providers who could be operating ICN platforms as a service for third parties, not only for pre-caching, but also to realize service overlays for edge computing.

Ravi> ICN because of in-network name resolution will enable distributed mobility, different from Mobile IP. However control plane mechanisms like name re-registration is required to help network with efficient name resolution whenever mobile entities moves into a foreign domains. Also CCN/NDN provides good opportunity for de-centralized name resolution, as home contexts can be derived from names, where the mapping of the mobile namespaces to the locator mapping can be managed for global resolution. Again such name resolution service is useful where dynamicity (migration, mobility, replication etc.) or routing scalability (inter-domain scenario) is required to be handled.

Thanks,
Anders Plymoth
TelHoc