Subject: Re: [icnrg] Name resolution and name based routing in ICN -Adiscussion (final try)

From: "David Oran" <[email-masked]>
Date: Thu, 02 Nov 2017 10:59:00 -0400

Continuing the discussion in advance of the session at the interim…

On 31 Oct 2017, at 21:25, Z.W. Yan wrote:

> Hi, David, I agree with this "route" to design the NRS in ICN/NDN.
> From the point of routing support, this issue can be split into two 
> sub-issues:
> In order to make sure the name-based routing can be deployment in 
> practice,
> the following principles should be followed (at least):
> 1) Uniqueness: the name appeared in the public network should be 
> unique.
I’m not sure the “public network” terminology is useful here, 
because ICN architectures have a “self defining” naming property:  
if the namespace is global, then the names are unambiguous globally no 
matter how or where they are expressed. If the namespace is non-global 
and names leak outside the expected context, then applications can get 
confused. This is not a big problem if there is a single global 
namespace and leakage from non-global namespaces can be at least 
detected and possibly blocked.

I also have to invoke a small pedantic point. People often use the term 
“unique” when actually they mean “unambiguous”. Unambiguous 
means that no two or more different objects can share the same name. 
Uniqueness means that the same object cannot have more than one name. 
Uniqueness is actually a stronger property and one we may not actually 
need in an ICN naming design (it’s in practice quite hard to enforce 
anyway).

> [Just like in IP/DNS, a management scheme is needed to guarantee the 
> uniqueness of the name in ICN/NDN.]
I think I disagree here, but we need to peel this down to what exactly 
is meant by a “management scheme”. All namespaces need some form of 
administration and whether that administration is automated (and to what 
extent) is an interesting discussion. I doubt we want to recapitulate 
the administration model of DNS, which is overly complex and poorly 
coupled to the authenticaiton and authorization functions. One thing we 
do need to think carefully about is whether name ownership follows the 
certification hierarchy (e.g. as would be the case with the proposed 
DANE design for DNS), or is independent with indirection through 
separate CA certificates (as is the case with DNSSEC and web PKI). There 
are very delicate tradeoffs here (which have ben discussed ad nauseum in 
the Internet comunity for as long as I can remember.)

> 2) Scalability: the name appeared in the ICN/NDN routing should be 
> restricted.
> [Not all the names can be flooded into the FIB. This is also for the 
> routing security consideration.]
Well, clearly not all names can be in the FIB under any reasonable 
projection of Moore’s Law (see the work by me and Ashok Narayanan from 
2012). Given the hierarchical token structure of NDN and CCN, the 
requirement is that name prefixes exposed to routing either not require 
global reachability, or be topologically aggregatable to scale with the 
connectivity of the underlying network graph.

> 3) Mobility: publisher mobility should not be supported directly by 
> routing flooding.
> [Tunneling or other redirection schemes can be used to support 
> publisher mobility to guarantee the stability of the routing.]
So, I’m not sure I’d put it quite so strongly. Some IGPs have 
efficient storage and rapid convergence for quite large domains, in 
which case tunneling or redirection is not needed. Also, schemes tht 
undertand mobility patterns (like MapMe) can handle quite significant 
degrees of producer mobility without resorting to an NRS to maintain the 
mobility mappings. At some point, mobility devolves to “roaming” or 
even multihoming at which point routing is no longer expected to track 
mobility in near realtime and an NRS may be the best way to maintain the 
mappings.

> ......
>
> Then, the following name-based routing architecture may be needed as 
> an example:
> 1) Hierarchical routing: in the top level, the information of 
> top-level prefixes are exchanged, just like the TLD (Top-level domain 
> in DNS) related routing information. In the lower levels, the 
> information of lower-level prefixes are exchanged. The default 
> out-face of the lower-level routing is its upper-level routing.
That’s certainly one of the simple ways to do it, if you don’t care 
about policy or network partitions. Also, if you are willing to live 
with slow convergence, a hyperbolic routing system can do better than a 
fixed hierarchy and is much friendlier to multi-homing. In my view 
it’s premature to pick.

> 2) With the above logic, a name registration scheme is needed to 
> guarantee the uniqueness and validity of the routing names (this 
> scheme may be decentralized in the top-level). And then the 
> upper-level delegates the lower-level.
Hmmm… it isn’t clear to me that the name registrations have to be 
unique to have valid routing handles, nor that the secure delegations 
have to be hierarchical. It would in my view be a mistake to 
recapitulate the RPKI/BGP experience. Given that with either NDN or CCN 
we have the opportunity to employ flexible trust schemas (e.g. Yingdi 
Yu’s work) we might be able to control propagation of routing-friendly 
names using the trust schema rather than the hierarchy. (This is a 
specultion on my part at this point but I think we should not start from 
the restrictions imposed by a strict tree-like hierarchy without looking 
at alternatives.)

> 3) Security in the routing must be considered from the beginning. For 
> example, a route only with a legal certificate can be broadcasted into 
> the network and with border restriction.
I’d make a stronger statement than that. Not sure exactly what it 
should be but routing needs to be protected locally as well as globally, 
and what the “borders” are is not entirely clear (unless we adopt 
the BGP AS model unquestioningly).

> [This cannot guarantee the optimized routing, but the fist motivation 
> is to support the routing
> to be scalable with numerous names. In other words, routing should 
> rely on the content delegation/management
> relationship because network topology is more dynamic. In addition, 
> because ICN/NDN supports the content caching,
> reachability is more important than efficiency for the name-based 
> routing.]
>
I think I follow you here, but there’s a lot to digest and elaborating 
on these points would be helpful. One point I’d make is that a touted 
advantage of ICN is that, unlike HTTP/IP-style content systems, NDN/CCN 
do not require content delegation/management in the same sense. It would 
be a shame to force us into delegation or worse custodial transfer of 
content in order to make ICN routing work.

Wild speculation: I might be willing to put down a bet that the data 
structure we use to express routes (whether injected directly in routing 
or stored in an NRS) will need to have at least two signatures.

> As you siad, we may need something to start.This is just my rough idea 
> to start the discussion, if it mainly makes sense, we can discuss the 
> related details.
>
Thanks!

> BR,
> Zhiwei Yan
> CNNIC
>
>
>
> 发件人： David Oran
> 发送时间： 2017-10-31  00:22:58
> 收件人： Z.W. Yan
> 抄送： Börje Ohlman; icnrg
> 主题： Re: [icnrg] Name resolution and name based routing in ICN 
> -Adiscussion (final try)
>
> On 29 Oct 2017, at 21:33, Z.W. Yan wrote:
> It’s necessary to have wide discussion about the naming service in 
> ICN/NDN,
> but we also need to narrow the requirements because it’s impossible 
> to have
> a perfect naming service which satisfies too many requirements
> (scalable, readable, secure, mobility-supporting, routing…).
>
> In general this is a good list and the point that trying to be 
> everything to everybody is a path unlikely to succeed is certainly 
> valid. This is why we (the chairs) tried to explain the nature of the 
> whole design space and then suggest we concentrate on the role of an 
> NRS in ICN routing without worrying about some of the other uses 
> identified.
> That said, at least some of the attributes/requirements you list above 
> are in fact important, if not critical, to solving the problem of an 
> NRS applied to ICN routing, so I’m not sure how to pare that list 
> down in a useful way.
> If you have ideas on how to scope these things for routing more 
> narrowly than for a general naming service, those would be great to 
> write down and discuss on the mailing list and at the meeting. As a 
> start to that, I can suggest a few areas that may yield 
> simplifications:
> the dynamic nature of the forwarding plane may allow an NRS to have 
> slower update convergence than one designed for data plane that has to 
> protect against transient loops or undetected misrouting. This helps 
> with mobility.
> the kinds of mapping stored in an NRS for routing may not need a fully 
> general trust schema and hence simpler route validation and key 
> management may suffice.
> privacy may be such an intractible problem generally that trying to 
> enforce routing privacy through the NRS a waste of time.
> some architectures like CCNx1.0 can avoid certain NRS complexity by 
> punting multiple (topological) name assignment to the applications 
> rather than trying to solve it in the NRS
> discovery may be better done with a separate custom service rather 
> than leveraging an NRS.
> etc.
> As in ICN/NDN, the most important point is “name-based routing”,
> then the naming service should be scalable and efficient enough
> to support this point. I think that should be our main motivation to 
> design the naming service in ICN/NDN.
>
> I agree that this should be our focus, at least for now.
> 2017-10-30
>
>
>
> Zhiwei Yan
> CNNIC
>
>
>
> 发件人： Börje Ohlman
> 发送时间： 2017-10-27 23:32:02
> 收件人： icnrg
> 抄送：
> 主题： [icnrg] Name resolution and name based routing in ICN - 
> Adiscussion (final try)
>
> Name Resolution has been a longstanding topic in ICN, so the chairs 
> would like to encourage a discussion about name resolution and its 
> potential utility to ICN and its specific instantiations, without 
> presuming any particular name resolution architecture and protocol 
> properties. We would like to have a longer discussion on this at the 
> interim meeting in Singapore. Please let us know if you would be 
> willing to make a short discussion starter presentation of your view 
> of this.
>
> Some background:
>
> In ICN, names can represent different things, including Named Data 
> Objects (NDOs), nodes, functions (or their results). Names can also be 
> related to other names in a variety of ways, including collections, 
> alternative names for the same data, various forms of indirection, and 
> discovery. While each of these “name computation” or “name 
> lookup” functions could be provided in a number of ways, for 
> example, by an application-specific function on a per-application 
> basis, by a function-specific lookup service (e.g. “link objects”, 
> or discovery services) there are also a set of functions that 
> manipulate names in order to enable scalable routing in an ICN. These 
> are the functions we have been discussing under the rubric of a 
> “Name Resolution Service/System”, or “NRS”.
>
> When consumers issue Interests for these named things, we expect the 
> network to forward those interests to a suitable place in the network 
> that generates a corresponding Data message. Forwarding Information 
> can be built leveraging different information sources: name-based 
> routing, name resolution, SDN control, static configuration etc. 
> Sometimes, none of this is needed (for example in broadcast or local 
> rendezvous-based systems). In other cases, a combination of different 
> inputs and mechanisms could be useful.
>
> Whereas the different techniques have their individual merits and 
> potentials issues (scalability, lookup latency, communication overhead 
> etc.), there are also architectural considerations and implications:
> Does relying on a name resolution system imply that we always have to 
> resolve names to identifiers in a different namespace? Conversely, is 
> a name resolution system ever needed to map names to a different 
> namespace (specifically the namespace of lower-layer services such as 
> IP or Ethernet).
> Are there specific privacy and security implications with particular 
> approaches? Whenever a level of indirection is added to a system, 
> there is potential to expand the attack surface dramatically, as now 
> there are opportunities to attack the provenance of the input 
> namespace, the output namespace, andthe translation mechanisms and 
> protocols themselves.
> Who does the resolution?
> Is NRS a new architectural entity that requires new protocols and 
> semantics in current ICN systems?
> Does NRS imply some mutability of Interest messages (name rewriting?) 
> and what would be the implications?
> What is the level of integration with the routing system? Are the 
> results of an NRS operation intended to be used just to construct 
> tunnels (e.g. the routing system is oblivious other than possibly 
> calling the NRS to identify tunnel endpoints) or is the routing system 
> intimately entwined, as it would be with routing hints in Interest 
> messages.
> Relying solely on Name Based Routing (NBR) poses a number of yet not 
> resolved issues. Some of these are general in the sense of fundamental 
> to the scaling of routing state*rate; others are specific to the 
> structure of namespaces in an ICN architecture. These issues include, 
> but are not limited to:
> Global scalability of routing
> Producer mobility
> Finding off-path cached objects
> Security (specifically authorization) of routing information injected 
> from outside the routing system.
> Existing material on this topic includes:
>
> Requirements for Name Resolution Service in ICN - 
> https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/
>
> Looking forward to your input and comments,
> Börje, Dave & Dirk
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
> DaveO

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

DaveO

---

From: "Z.W. Yan" <[email-masked]>
Date: Fri, 3 Nov 2017 10:25:45 +0800

Yepp. It's good to try to design an automated or decentralized content name 
“management” architecture (also fulfilling some main security considerations) in ICN/NDN.

And it’s the chance to do it here without recapitulating the centralization model of DNSSEC/RPKI, 
although it will certainly face more challenges for the real deployment.

But the key point here is the routing architecture, based on this,
the name “management” can be discussed and designed more smooth and well-founded.

About the delegation, what I want to clarity is in some cases (even not under hierarchical delegation)
it may be needed in ICN/NDN. For example, if another publisher publishes one content but this content
originated from another publisher, does this publisher need an authorization to do the publishing? 
Besides, in order to validate the content, which publisher will be the trust source or anchor?   

2017-11-03 

Z.W. Yan 

发件人： David Oran 
发送时间： 2017-11-02  22:59:37 
收件人： Z.W. Yan 
抄送： Börje Ohlman; icnrg 
主题： Re: [icnrg] Name resolution and name based routing in ICN-Adiscussion (final try) 
 
Thanks!
DaveO