Subject: Re: [icnrg] Locator hint

From: Andrea Detti <[email-masked]>
Date: Fri, 16 Oct 2015 09:22:42 +0200

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] 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]
>>
>>
>>
>>
>>
>> On 1/9/15, 10:26 AM, "Andrea Detti" <[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]>
>>>>> wrote:
>>>>>
>>>>> On 01/08/2015 06:00 PM, [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]>
>>>>>>    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]
>>>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>>>> _______________________________________________
>>>>>> icnrg mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> icnrg mailing list
>>>>> [email-masked]
>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>> _______________________________________________
>>> icnrg mailing list
>>> [email-masked]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 16 Oct 2015 16:34:45 +0000

We had also presented this draft in an earlier ICN-RG meeting, we will have a revision of this draft for the next meeting.

https://tools.ietf.org/html/draft-ravi-ccn-forwarding-label-00

regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Andrea Detti
Sent: Friday, October 16, 2015 12:23 AM
To: [email-masked]
Subject: Re: [icnrg] Locator hint

Dear All,

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:

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.

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.

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 do not know :-)

Andrea

While we may be forced into doing something like this ultimately, every

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.

single-destination delivery - one example of a full-worked scheme is the

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.

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²

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

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:

Dear Mark,

"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?"

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.

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.

Thanks,
Mark

[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: <[email-masked]>
Date: Fri, 16 Oct 2015 16:36:50 +0000

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.

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

Dear All,

References:

Regards,

Andrea

Andrea

Nacho

I do not know :-)

Andrea

DaveO.

      Regards,

Andrea

Marc

Dear Mark,

especially when

Thanks,
Mark

---

From: Dirk Kutscher <[email-masked]>
Date: Fri, 16 Oct 2015 17:35:28 +0000

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]
Sent: Freitag, 16. Oktober 2015 18:37
To: [email-masked]; [email-masked]
Subject: Re: [icnrg] Locator hint

Nacho

Dear All,

References:

Regards,

Andrea

Andrea

Nacho

I do not know :-)

Andrea

DaveO.

      Regards,

Andrea

Marc

Dear Mark,

especially when

Thanks,
Mark

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 16 Oct 2015 19:22:14 +0000

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]; [email-masked]; [email-masked]
Subject: Re: [icnrg] Locator hint

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: Andrea Detti <[email-masked]>
Date: Sun, 18 Oct 2015 17:09:43 +0200

Dear Nacho,

I like manifest approach, but I do not understand how using hash you can 
"solve" routing scalability problem that, conversely, link object seems 
to alleviate, expecially in case of mobility.

Please, can you give me a link to a document explaining the manifest in 
mobility use-cases? By Googling "CCNx manifest", I just found a 
presentation and draft-wood-icnrg-ccnxmanifests-00 which explain 
manifest, but I was not able to figure out how to use manifest in 
presence of source mobility...without resigning content object, obviously.

Kind Regards,

Andrea

On 16/10/2015 18:36, [email-masked] wrote:
> 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.
>
> 1- We allow anybody to publish any name anywhere and have the network 
> look for it (in other words, no routing, just discovery)
> 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
> On 10/16/15, 12:22 AM, "Andrea Detti" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear All,
>     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:
>

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 Oct 2015 11:43:29 -0400

I had a couple of questions:

On 10/16/15 1:35 PM, Dirk Kutscher wrote:
[...]
> 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.

so ... I was curious about exactly what you intended there. do you think 
that a) you should be able to send messages to a light-switch in Japan 
from anywhere on the internet? or b) do you think you're sending 
messages to a controller application or server that is responsible for 
that particular building or site?

if (a), does that really seem like a good idea? how do you intend to 
handle things like authentication, access control, dos, logging, replay?

if (b), and assuming that the server application is capable of 
authentication and access control, can you say why you think you need to 
communicate in the clear? do you think that that would be considered 
acceptable in 2015 for an IP version of the application? if there's an 
application, then there's probably some kind of application protocol. in 
the context of the application protocol, there may be lots of ways to 
refer to devices or groups of devices (or historical log info, or groups 
of users, etc) why do you think that the names in the messages you send 
need to be in-the-clear, and need to reflect all of the semantics of the 
application? I'd prefer to be able to have private, encrypted 
communication with the application server, and I'd prefer to have an 
application protocol that can do ... whatever the application needs to do.

I'm also wondering what the phrase "global-scale communication" means in 
this context. if (a), do you think that every application on my laptop 
has to push something into ... the internet so that it can be globally 
reachable? if (b), then do you mean something like skype or facetime, 
where the application's servers act to make my presence known? there are 
many good reasons to use servers - rendezvous, authentication, logging, 
help with mobility and reachability.

there seems to be a bit of confusion here: do you think there are going 
to be applications and servers? or do you think that all applications 
and servers will "go away", to be replaced with ... something else? that 
second path seems to me to introduce a bunch of problems.

Thanks,
Mark

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Tue, 20 Oct 2015 10:02:14 +0200

Nacho,

If I understand correctly these new features,
i.e. (signed) manifests,  and name-less objects, then

the signature of the manifest of a nameless object seems
similar to the new HTTP header "Integrity" that makes
use of the Netinf ni: hash based naming scheme.

see http://www.w3.org/TR/SRI/

the manifest can provide to the client the set of locators
that store a permanent copy of the object.
Afterwards the client issues Interests that may be load balanced
towards the different locations (or not).

It seems (at first look)
very similar to Bittorrent or some CDNs (if they make use of the
Integrity HTTP header). And actually the NetInf naming
worked in a very similar way (I fail to see any difference for the moment).

However I fail to see how an intermediate node between the client
and the servers, can change adaptively the forwarding decision.

As far as I understand ccnx1.0, forwarding in the network is made
by using the name in the interest and the manifest makes an early
binding between  the locations and the names used to make
the replicas reachable. Just like HTTP +TCP/IP today.

You can still do load balancing towards multiple paths to reach
the same replica, but you cannot do load balancing among different
replicas as they have different locators (=the names in the manifest).

Is there anything other than LPM in the FIB  in ccnx1.0 that allows
the intermediate node to understand that, e.g., two name prefixes in the 
FIB
(used as addresses as a matter of fact) being  not necessarily LPMs,
  are routable to satisfy that interest?

Thanks
Luca

On 01/09/2015 08:06 PM, [email-masked] wrote:
> .

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 20 Oct 2015 21:49:00 +0000

Here is our updated forwarding-label draft for discussion at Yokohama. Mistook the draft submission deadline to today.

http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/icnrg/draft-ravi-ccn-forwarding-label-01.txt

Abstract

   The objective of this proposal is to enable ID/Locator split in CCN
   protocol.  We enable this through the notion of forwarding-label (FL)
   object, which is an optional hop-by-hop payload in the Interest
   message with locator name which identifies a network domain, router,
   or a host.  Depending on the application and trust context FL object
   is subjected to policy based actions by the forwarders such as
   invoking security verification or enabling other service-centric
   actions such as FL object replacement.  FL can be inserted by the
   applications or by the network.  To enable dynamic name resolution FL
   can be modified in the network by designated points such as the edge
   routers.  Enabling ID/Locator split in CCN has several applications
   such as towards routing optimization, mobility, handling indirections
   in manifests, and routing scalability.

Discussions are welcome.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Ravi Ravindran
Sent: Friday, October 16, 2015 9:35 AM
To: Andrea Detti; [email-masked]
Subject: Re: [icnrg] Locator hint

regards,
Ravi

Dear All,

References:

Regards,

Andrea

Andrea

Nacho

I do not know :-)

Andrea

DaveO.

      Regards,

Andrea

Marc

Dear Mark,

especially when

Thanks,
Mark