Re: [icnrg] Locator hint

[Andrea Detti <[e-mail]>]

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