Network Working Group X. Zhang
Internet-Draft R. Ravindran
Intended status: Informational H. Xie
Expires: August 22, 2013 G. Wang
Huawei Technologies
February 18, 2013
PID: A Generic Naming Schema for Information-centric Network
draft-zhang-icnrg-pid-naming-scheme-01
Abstract
In Information-centric network (ICN), everything is an identifiable
object with a name such as named data chunks, services and mobile
devices. Different from host-centric connectivity, ICN connects
these named entities using name-based routing and forwarding. At the
same time, network entities, end devices, and applications have
variant demands to verify the integrity, authenticity, and validation
of these entities through names. This document proposes a generic
naming schema, called PID (Principal, Identifier, and Domain), which
supports security provenance, content lookup, routing and inter-
domain resolution for ICN. With P:I:D (or simply PID) schema, a name
consists of three components: Principal, Identifier, and Domain. In
this specification, we only illustrate the principles and concepts of
PID schema and the functional role of each component, and leave the
encoding approaches as implementation options.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Zhang, et al. Expires August 22, 2013 [Page 1]
Internet-Draft PID Naming Schema February 2013
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Naming in ICN . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Principles for Naming in ICN . . . . . . . . . . . 4
2. PID Naming Scheme . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Naming Format . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Routing Names . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Content Store and PIT . . . . . . . . . . . . . . . . . . 8
2.4. Dynamic Content Routing . . . . . . . . . . . . . . . . . 8
2.5. Towards Generic Naming Scheme . . . . . . . . . . . . . . 9
3. Trust Management . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhang, et al. Expires August 22, 2013 [Page 2]
Internet-Draft PID Naming Schema February 2013
1. Introduction
1.1. Naming in ICN
In ICN design, a name has been required to serve for many purposes:
ICN requires unique names to identify mutable or immutable content or
information objects; in data caching, a name is used to look up and
access the data; in routing and forwarding, a name is used for
reaching the information object; for security, a provenance between
name and data is established and verified via cryptographic
credentials associated with a name. We summarize the following roles
that a name may be desired from different users or stakeholder in
ICN:
o R1 (unique): A name identifies an object or entity with uniqueness
in some scope (e.g., within a domain or Internet).
o R2 (locatable): A name enables interested entities to locate the
identified object in a network. For this purpose, the name is
either routable to reach the object, or includes information to
derive the routable location(s) of the object.
o R3 (readable): A name enables a user or application to easily
identify and indicate the content of an object, even without
knowing the content itself beforehand or before the content is
generated. For this, the name may be required to be human-
readable.
o R4 (authenticable): A name has strong binding with the content
itself (either the publisher or owner of the content, or the
content itself), in order to provide content access
authentication, to let receiver verify the provenance, and to
prevent denial-of-service attacks in an ICN [ICN-name].
o R5 (trustable): A name includes information on how to derive the
trust of a content object, e.g., by an end user who retrieves the
content from ICN. The trust can be built on mechanisms out of ICN
primitives.
There may be many different naming schemes towards all or subset of
the above roles. For example, flat names are used in [DONA] for
global uniqueness and authentication, but does not provide
readability, routing, and trust information. Hierarchical flat name
is proposed in [ICN-Name] to use nested flat names for routing
purposes. Hierarchical human-readable names are proposed in CCN and
NDN, but they do not provide authentication and trust information. A
generalized form of name is proposed in [SCN] to bind authentication
with content names via a signature.
Zhang, et al. Expires August 22, 2013 [Page 3]
Internet-Draft PID Naming Schema February 2013
1.2. Design Principles for Naming in ICN
We follow several principles for naming scheme in ICN.
o Naming scheme satisfies necessary but not more than necessary
aforementioned roles: in our view, a single-component name cannot
satisfy all roles at the same time.
o A content name identifies a content object in persistent way, such
that this name does not change with the mobility and multi-home of
corresponding content, device, or host. A client can always use
this name to retrieve the content from network and verify the
binding of the content and the name.
o A naming scheme should give certain level of flexibility to
support different networks, considering variant network
architectures have been proposed and multiple ICNs and current
Internet may co-exist. Ideally, a name can include any form of
identifier, including flat, hierarchical, human readable or non-
readable. The identifier can be chosen by content owner or
publisher with the uniqueness within certain domain or within an
application-specific scope.
o The network does not use persistent content name for routing
directly; instead, a "routing name" (or routable address/location/
label/tag) is network architecture dependent, which is usually
routable within the network, such that a network node or client
can reach the content with it. Usually, a routing name is the
real location (or locator) of the content in the network.
o Per-domain-based (globally or locally) naming resolution services
(NRS) should be available, to map a persistent content name to
routing name or location. While per-domain NRS updates the
routing labels for a content name, it creates a late-binding
routing behavior. We note that a single content name can be
mapped to multiple routing names. How to implement name
resolution service is out of the scope of this document.
2. PID Naming Scheme
2.1. Naming Format
Based on these principles, we propose a PID naming schema for ICN.
Each name is specified by three components of PID, where:
o P is the principal to bind the object with complete name for
security purpose, for different relationships, e.g., ownership,
Zhang, et al. Expires August 22, 2013 [Page 4]
Internet-Draft PID Naming Schema February 2013
administration, and social relations. P is usually constructed by
hashing the public key of the principal, or the hashing the
content object itself if it is static. We call the relationship
between P and the object as "security binding".
o I is the identifier of the object in variant forms and is referred
by end user, applications, or other entities. It can be something
chosen by publisher or a network service, or other administrative
authorities. It can be hierarchical or flat, user-readable or
non-readable, and usually location-independent. We call the
relationship between I and the object as "application-binding".
o D is the domain that provides resolution from identifier to the
real location of the object by routers. For persistence purpose,
D can be in any of the following forms:
* The locator of the target object if the locator is persistent;
* A resolution service name or location which maps the content
identifier (I) to its real location, if the resolution service
name is persistent;
* A resolution service name that maps the content identifier (I)
to another resolution service name or location, that is, a
meta-domain;
* Any combinations of above.
We call the relationship between D and the content object as
"network-binding".
For example, D can be the domain name of the publisher's domain
gateway, service, host that can resolve P:I, or a redirection
gateway, service or host to preserve name persistence or to deal with
mobility or hosted services. D is the "fall back" used for name-
resolution if P:I is not resolvable in the local cache of the
requesting domain. D is usually routable (globally or locally), such
that, when an application or network node first receives an interest
with the content name, it can query a resolution service by routing
with D and obtain the real location or locator of the named object.
In case the resolution service is not static, a recursive name
resolution may be performed, i.e., the D points to a static
resolution service, which in turn points to a dynamic resolution
service, which points to the location of the object. D is optional,
if I is routable within a given domain.
D can be in the same namespace of I, but in general it can be
different. For example, in one case, D is the container of a set of
Zhang, et al. Expires August 22, 2013 [Page 5]
Internet-Draft PID Naming Schema February 2013
objects which can locate and resolve objects [1].
We note that the domain concept in our naming scheme is more general
than the administration domain in current Internet architecture. In
PID, the relationship between a named object and its domain D is for
location resolution and routing purpose. It can be the same as the
administration domain of the content object, or a 3rd party
resolution service provider, where the designated domain provides
resolution service. In more generally way, the domain of a name can
have social-, admin-, owner-, host- relationships with the named
object, which implies that the domain provides resolution service to
locate a content object with its name. A domain can provide a DNS-
like service that maps a content identifier to the location of the
object or the resolution service. Different from current Internet's
centralized DNS, a domain-based resolution can be more general with a
distributed implementation. Furthermore, the meta-domain of a
content object can be personal profile, e.g., as in social network
service, an enterprise directory service, a cloud service provider,
or a web hosting service. For example, to support the Example 2 of
[2], the domain part of the content name is simply the service name
or location of the lookup database, which is more persistent than the
mapping of a content identifier to location. Note that in [2], the
lookup database is assumed to be static and pre-known by the network,
which we believe is not realistic and flexible enough.
2.2. Routing Names
As aforementioned, our naming scheme differentiates content names and
routing names, where the former is persistent to specify a content
object, while the later is location-based for routing purpose.
Instead of a very specific format of routing names, our scheme
supports variant routable names (or routing labels), e.g., a network
address or a locator. For a content name P:I:D, the D resolves P:I
to one or many routing labels, and application or network router can
choose one to reach the content or more for multicast. A routing
label for a content object can be dynamic, and can be changed from
domain to domain. For example, a single domain may by default set a
gateway routing label to all the clients it is serving. The gateway
may then replace it with some other label. Through this way, the
routing label can allow policy-based intra/inter-domain routing, late
binding for mobility, and delay-tolerant content routing.
With a content name provided by a content requester, the network
first returns the real location of the named object via resolution
services specified by the domain information (D) in the name. This
location information is then augmented in the head field of a PDU
(e.g., an interest in CCN). The network then uses location to reach
the object, retrieve the named content, and forward back to the
Zhang, et al. Expires August 22, 2013 [Page 6]
Internet-Draft PID Naming Schema February 2013
requester. Resolving the location from name and augmenting the PDU
can be transparent to applications.
In general with P:I:D the resolution process works as follows: with a
content name P:I:D, a client forwards request to a network node
(e.g., an access router), if not resolvable in the local cache, the
router first routes to a naming resolution service (NRS) with D. With
the input of P:I, the NRS returns the routing name or routing label
of the content object, e.g., a location or a locator. Upon receiving
this, the network node inserts this label in the head of the interest
packet. The network then uses this routing label to reach the next
hop, to retrieve the named content by using P:I at each hop, and to
forward data back to the requester. In case the routing name
resolved from the NRS is another name resolution service named with
D', the network node sends the request to this revolved NRS with D'
in interest head, obtains the location of the target object, and then
inserts the location into interest head to obtain the content object.
This process happens recursively until the location of the named
object can be reached. In another case, where a separate locator
address space is not managed, a per-hop forwarding can be adopted,
where a content router tries to resolve the content name identifier
(I or P:I) locally in its cache, if it is unresolvable, use I:D or
just D to route to domain D, in the latter case once the interest
reaches D, the request I:D can be used to route to location(s) of the
content object.
Therefore, logically, a data PDU could be of form <P:I:D, <Routing
Label>, C, Sign_P(I:D,C), Metadata >, where C is the content payload,
Sign_P is a signature generated from the private key corresponding to
P on C and persistent content name, and the metadata includes other
meta attribute information. With this hybrid naming approach, our
scheme achieves the benefits of both pure self-certified names and
hierarchical names. Specifically, similar to hierarchical human-
readable name, the P:I part of our name scheme can achieve global
unique and readability (if needed). With D, our name scheme achieves
persistent locatability without real location of the content in name.
With the P part, our name scheme can achieve strong binding between
content and its name for security and data integrity. Note that
trust management is built on some external mechanism out of the
naming scheme.
In a special case, the D of a content name P:I:D could also serve as
a routing label, i.e., D can serve dual purposes: a resolution/
redirection point, and a routing label as well, e.g., D could
directly resolve to a container (server). This avoids one RTT to
obtain the Routing Labels of the content name. While D can serve the
same purpose of routing label that is proposed in [2], our PID schema
has two improvements:
Zhang, et al. Expires August 22, 2013 [Page 7]
Internet-Draft PID Naming Schema February 2013
P:I:D has better persistence property since it separates routing
labels from content names, while in [2], a content ID includes
both routing labels and identifier. When the routing label of a
content is changed, e.g., the host service is changed, or a new
host service is added, the content ID has to be changed, which
destroys the name persistency.
P:I:D has stronger security binding of name and content via
principal field.
Note: We focus on the logical semantics of fields in a naming in this
document. In implementation, variant formats of P:I:D can be
options. For example, I:D can be in a single component, which acts
as a resolvable identifier.
2.3. Content Store and PIT
With a content name of P:I:D, a router can use the full name to index
and look up cached content chunks and pending interests in content
sore (CS) and pending interest table (PIT) (e.g., in [3]).
Optionally, a router can only use P and I for the same purposes.
This achieves location independency in data storage and forwarding,
e.g., when a content chunk with P and I can satisfy any request of
P:I:D with any D. That is, two content objects with same P and I are
considered as the same and thus only one is cached at anytime, even
though they may have different Ds.
2.4. Dynamic Content Routing
The P:I:D naming lends itself to allow consuming and producing
applications to choose naming semantic that meets requirements in
terms of reliability, security or performance metrics. The naming
format follows a P:I:D format, where I identifies the named entity
with a local or global scope, and D is the authority which could
resolve the entity's location(s), and P securely binds the content
object to I. For content routing I:D is the relevant portion. As I
could be a hierarchical or flat name, several options for content
routing are possible. In one case separate ICN domains can be built
that is optimized to deal with either flat or hierarchical, here
name-resolution service allows the request to be directed to the
appropriate domain criterion determined by the publisher, consumer or
based on certain routing policies. In another case, a content
routing domain can be built where the name-resolution infrastructure
is enabled to deal with both flat and hierarchical names, here
irrespective of the type of naming, a separate locator space exists
to resolve the content name to its location(s).
If the combination of I:D is hierarchical, the content routing can
Zhang, et al. Expires August 22, 2013 [Page 8]
Internet-Draft PID Naming Schema February 2013
follow the resolution mechanism similar to CCN. To resolve an
interest, either I itself could be routable if it is globally unique,
or the combination of I:D should be routable, which shall be
interpretable by the name resolution service handling hierarchical
names. Such ICN domains can leverage longest prefix match to take
advantage of name-prefix aggregation mitigating routing scalability
issue.
If I is flat, then the resolution through D should return a routing
label(s), which can be appended to the interest packet for intra- and
inter-domain name based routing on a fast path, or the name
resolution can be handled by the global name resolution
infrastructure through inter-domain cooperation on a slow path.
There are several considerations for dynamic name based routing.
Based on the particular naming construct, hierarchical vs flat vs
hybrid each of these considerations achieves the same objectives
respectively with different mechanisms.
2.5. Towards Generic Naming Scheme
As mentioned before, one object may have several names. Different
names are assigned from different domains and served for different
purposes. Logically, for a single object (e.g., a content, a device,
an application, a service, a network nodes, or a user), it can have
multiple identifiers, For example, a mobile device may have
identifier of IMEI, a phone number, an IP address, a human readable
name (e.g., Alice's iPhone), and an organizational device id (e.g.,
if the device belongs to a company). A user generated content can
have a user chosen ID, a URL, and a tinyURL. All these identifiers
can have a single principal. Therefore the name of the object can be
P:(I1:...:In):D, where Ix is an identifier, D is a domain that
provides name resolution service, and P is the principal.
In very general case, each identifier can be associated with
different principals, and multiple locators can be used for a single
content object, e.g., for load balance and duplication. For example,
the Abel's iPhone have different public keys for different names it
may use for different network services, one for Abel's personal use,
and another from the enterprise. Therefore, the relationships
between the object, identifier, and principals can be illustrated as
follows.
As one object may have many persistent domains (e.g., a content is
stored at different host services or CDNs), and one object may also
have many IDs, in this generic schema, both domain and identifier may
be a multi-element set, and content routers and consumers can select
variant elements for content routing and forwarding (based on locally
Zhang, et al. Expires August 22, 2013 [Page 9]
Internet-Draft PID Naming Schema February 2013
defined policy).
Note that there can be mapping relationships between multiple names
of a single object. For example, an object may have a hierarchical
identifier within its local domain owned by an enterprise, but has a
flat identifier (hash of its content) with a DHT service. There can
be a mapping service to link these two names towards the same object.
In general, mapping function between different names of a single
object can be used to build flexible relationships between names,
such as:
o An identifier can be derived from another identifier, which forms
nested or tunneled names.
o A principal can be signed by another principal, to build trust
between different principals, such as for ownership,
administration, and social relationships.
o A domain name can point to another domain name for the same
object.
The P:I:D scheme can support these levels of flexibility. However,
we consider these are extensions of core naming scheme.
3. Trust Management
Naming scheme design and implementation is independent from the trust
management infrastructure. The trust of a content object is derived
from the trust of the principal, i.e., the public key of the
principal. Either network nodes or end users can verify the trust of
a content object, according to different security requirements. The
trust management infrastructure is out of the scope of PID naming
scheme.
Similar to [CCN], the public key of a principal can be regular ICN
data, also with the name of P:I:D. For the name of a certified public
key, its I can be some domain- or realm-based name, D can be the name
(if static) of the certificate directory service of a CA, or a domain
that resolves the location of a public key certificate, and the P is
the hash the CA's public key.
4. Security Considerations
Security issues are not discussed in this memo.
Zhang, et al. Expires August 22, 2013 [Page 10]
Internet-Draft PID Naming Schema February 2013
5. IANA Considerations
This document makes no specific request of IANA.
6. Conclusions
In this draft, we propose a naming schema for ICN, named PID scheme.
With this, an object name includes a prinicapl P, an identifier I,
and a domain D. The princial P acts for security binding to verify if
the object is bounded with its name, and can further derive the trust
of the object with possible trust managemnet mechanisms. The
identifier I identifies the object within certain scope, and can be
used for application binding such as caching. The D referes to a
name resolution service that can drive the realtime location of the
object, directly or recrusively. While this draft lays out the basic
design pinciples and scheme of PID, we leave its encoding and
implementation details to other documentations, such as [Huawei-
container-name].
7. Informative References
[1] "Container Assisted Naming and Routing for ICN.", http://
www.ietf.org/internet-drafts/
draft-yao-icnrg-naming-routing-00.txt. 2013.
[2] "NDN and IP Routing, Can it Scale?", http://trac.tools.ietf.org/
group/irtf/trac/raw-attachment/wiki/icnrg/
IRTF%20-%20CCN%20And%20IP%20Routing%20-%202.pdf 2011.
[3] Jacobson, V., "Networking named content.", Proc. of ACM
CoNEXT 2009, 2009.
[4] Koponen, I., "A Data-Oriented (and Beyond) Network
Architecture.", Proc. of ACM SIGCOMM 2007, 2007.
[5] Ghodsi, A., "Naming in Content-Oriented Architectures.", Proc.
of ACM ICN Workshop 2011, 2011.
[6] "Securing Network Content.", PARC Technical Report 2009, 2009.
Zhang, et al. Expires August 22, 2013 [Page 11]
Internet-Draft PID Naming Schema February 2013
Authors' Addresses
Xinwen Zhang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: xinwenzhang@gmail.com
Ravi Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: ravi.ravindran@huawei.com
Haiyong Xie
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: haiyong.xie@huawei.com
Guoqiang Wang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: gq.wang@huawei.com
Zhang, et al. Expires August 22, 2013 [Page 12]