This document describes architectural considerations and implications
related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN).
It explains how the ICN architecture can change when an NRS is utilized
and how its use influences the ICN routing system. This document is a product
of the Information-Centric Networking Research Group (ICNRG).¶
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 https://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."¶
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.¶
Information-Centric Networking (ICN) is an approach to evolving the
Internet infrastructure to provide direct access to Named Data Objects (NDOs)
by names. In two common ICN architectures, NDN [NDN] and
CCNx [CCNx], the name of an NDO is used directly
to route a request to retrieve the data object. Such direct name-based
routing has inherent challenges in enabling a globally scalable routing system,
accommodating producer mobility, and supporting off-path caching.
These specific issues are discussed in detail in Section 3. In order
to address these challenges, a Name Resolution Service (NRS) has been
utilized in the literature as well as the proposals of several ICN projects
[Afanasyev][Zhang2][Ravindran][SAIL][MF][Bayhan].¶
This document describes the potential changes in the ICN architecture
caused by the introduction of NRS and the corresponding implication to
the ICN routing system. It also describes ICN architectural considerations
for the integration of an NRS. The scope of this document includes
considerations from the perspective of ICN architecture and routing
system when using an NRS in ICN. A description of the NRS itself is
provided in the companion NRS design considerations document
[RFC9138], which provides the NRS approaches,
functions and design considerations.¶
This document represents the consensus of the Information-Centric
Networking Research Group (ICNRG). It has been reviewed extensively
by the Research Group (RG) members who are actively involved in the
research and development of the technology covered by this document.
It is not an IETF product and is not a standard.¶
Name Resolution Service (NRS): An NRS in ICN is defined as
a service that provides the function of translating a content
name or a data object name into some other information such as
a routable prefix, a locator, an off-path-cache pointer, or an alias name that is
more amenable than the input name to forwarding the object request
toward the target destination storing the NDO [RFC9138].
An NRS is most likely implemented through the use of a distributed
mapping database system. Domain Name System (DNS) may be used as an NRS.
However, in this case, the requirements of frequent updates of NRS records
due to the creations of a lot of new NDOs and changes in their
locations in the network need to be considered.¶
NRS server: An NRS comprises the distributed NRS servers
storing the mapping records in their databases. NRS servers
store and maintain the mapping records that keep the mappings
of content or object name to some other information that is
used for forwarding the content request or the content itself.¶
NRS resolver: The client side function of an NRS is called an NRS resolver.
The NRS resolver is responsible for initiating name resolution
request queries that ultimately lead to a name resolution of
the target data objects. NRS resolvers can be located in the
consumer (or client) nodes and/or ICN routers. An NRS resolver
may also cache the mapping records obtained through the name
resolution for later usage.¶
Name registration: In order to populate the NRS, the content
names and their mapping records must be registered in the NRS
system by a publisher who has access right to at least one
authoritative NRS server or by a producer who generates named
data objects. The records contain the mapping of an object
name to some information such as other alias names, routable prefixes and locators,
which are used for forwarding the content request. Thus, a
publisher or producer of contents creates an NRS registration request and
sends it to an NRS server. On registration, the NRS server
stores (or updates) the name mapping record in the database
and sends an acknowledgement back to the producer or publisher
that made the registration request.¶
Name resolution: Name resolution is the main function of the
NRS system. It is performed by an NRS resolver which can be
deployed on a consumer node or an ICN router. Resolvers are
responsible for either returning a cached mapping record
(whose lifetime has not expired or alternatively sending a
name resolution request toward an NRS server. The NRS server
searches for the content name in its mapping record database,
and if found, retrieves the mapping record and returns it in a
name resolution response message to the NRS resolver.¶
NRS node: NRS servers are also referred to as NRS nodes that
maintain the name records. The terms are used interchangeably.¶
NRS client: A node that uses the NRS is called an NRS client.
Any node that initiates a name registration, resolution,
or update procedure is an NRS client. That is, NRS resolvers,
ICN client nodes, ICN routers, or producers can be NRS clients.¶
A pure name-based routing approach in ICN has inherent challenges in enabling
a globally scalable routing system, accommodating producer mobility, and
supporting off-path caching. In order to address these challenges, an NRS
has been utilized in proposals and literature of several ICN projects as follows:¶
Routing scalability: In ICN, application names identifying contents
are intended to be used directly for packet delivery, so ICN routers
run a name-based routing protocol to build name-based routing and
forwarding tables. Similar to the scalability challenge of IP
routing, if non-aggregatable name prefixes are injected into the
Default Route Free Zone (DFZ) of ICN routers, they would be driving
the uncontrolled growth of the DFZ routing table size. Thus, providing
the level of indirection enabled by an NRS in ICN can be an approach
to keeping the routing table size under control. The NRS system
resolves name prefixes which do not exist in the DFZ forwarding
table into globally routable prefixes such as one proposed in
NDN [Afanasyev]. Another approach dealing
with routing scalability is the Multi-level Distributed Hash Table
(MDHT) used in NetInf [Dannewitz]. It provides
name-based anycast routing that can support a non-hierarchical
namespace and can be adopted on a global scale [Dannewitz2].¶
Producer mobility: In ICN, if a producer moves into a different
name domain that uses a different name prefix, the request for a
content produced by the moving producer with the origin content
name must be forwarded to the moving producer's new location.
Especially in a hierarchical naming scheme, producer mobility
support is much harder than in a flat naming scheme since the routing
tables in a broader area need to be updated to track the producer
movement. Therefore, various ICN architectures such as NetInf [Dannewitz]
and MobilityFirst [MF] have adopted NRS systems
to tackle the issues of producers whose location changes.¶
Off-path caching: In-network caching is a common feature of an
ICN architecture. Caching approaches can be categorized into
on-path caching and off-path caching, according to the location
of caches in relation to the forwarding path from the original
content store to a consumer. Off-path caching, sometimes also
referred to as content replication or content storing, aims to
replicate a Named Data Object in various locations within a network
in order to increase the availability of contents, reduce access latency,
or both. These caching locations may not be lying along the
content forwarding path. Thus, finding off-path cached contents
requires more complex forwarding procedures if a pure name-based
routing is employed. In order to support access to off-path caches,
the locations of replicas are usually advertised into a name-based
routing system or into an NRS as described in [Bayhan].¶
This document discusses architectural considerations and implications
of ICN when an NRS is utilized to solve such challenges facing a name-based
routing in ICN.¶
An NRS is not a mandatory part of an ICN architecture, as the majority
of ICN architectures uses name-based routing that avoids the need for
a name resolution procedure. Therefore, the utilization of an NRS in
an ICN architecture changes some architectural aspects at least with
respect to forwarding procedures, latency, and security, as discussed below:¶
Forwarding procedure: When an NRS is included in an ICN architecture,
the name resolution procedure has to be included in the ICN
overall routing and forwarding architectural procedures.
To integrate an NRS into an ICN architecture, there are certain
things that have to be decided and specified such as where, when and how
the name resolution task is performed.¶
Latency: When an NRS is included in an ICN architecture,
additional latency introduced by the name resolution process
is incurred by the routing and forwarding system. Although the
latency due to the name resolution is added, the total latency
of individual requests being served could be lower if the nearest copies or
off-path caches can be located by the NRS lookup procedure.
Additionally, there might be a favorable trade-off between
the name resolution latency and inter-domain traffic reduction
by finding the nearest off-path cached copy of the content.
Finding the nearest cache holding the content might significantly
reduce the content discovery as well as delivery latency.¶
Security: When any new component such as an NRS is introduced
in the ICN architecture, the attack surface may increase. Protection of the NRS system
itself against attacks such as Distributed Denial of Service
(DDoS) and spoofing or alteration of name mapping records and
related signaling messages may be challenging.¶
This section discusses the various items that can be considered from
the perspective of ICN architecture when employing an NRS system.
These items are related to the registration, resolution, and update of
name mapping records, protocols and messages, and integration with the
routing system.¶
When an NRS is integrated in ICN architecture, the functions related to
the registration, resolution and update of name mapping records have to
be considered. The NRS nodes maintain the name mapping records and may
exist as an overlay network over the ICN routers, that is, they communicate
to each other through ICN routers. Figure 1 shows the NRS nodes and NRS
clients connected through an underlying network. The NRS nodes should be
deployed in such a manner that an NRS node is always available at a short distance from
an NRS client so that communication latency for the name registration and
resolution requested by the NRS client remains very low. The name registration,
name resolution and name record update procedures are briefly discussed below.¶
Name registration: Name registration is performed by the producer
(as an NRS client) when it creates a new content. When a producer
creates content and assigns a name from its name prefix space
to the content, the producer performs the name registration in
an NRS node. Name registration may be performed by an ICN router
when the ICN architecture supports off-path caching or cooperative caching since involving
an NRS may be a good idea for off-path caching. The ICN routers
with forwarder caches do not require name registration for their
cached content because they lie on the path toward an upstream
content store or producer. They will be hit when a future request
is forwarded to the content producer by an ICN router lying
downstream toward the ICN client node. However, ICN routers
performing off-path caching of content must invoke the name
registration procedure so that other ICN routers can depend on
name resolutions to know about the off-path cache locations.
If a content gets cached in many off-path ICN routers, all of them
may register the same content names in the same NRS node,
resulting in multiple registration actions. In this case, the NRS
node adds the new location of the content to the name record
together with the previous locations. In this way, each of the
name records stored in the NRS node may contain multiple locations
of the content. Assigning validity time or a lifetime of each
mapping record may be considered especially for the off-path
caching contents and managing mobility.¶
Name resolution: Name resolution is performed by an NRS client
to obtain the name record from an NRS node by sending a name
resolution request message and getting a response containing
the record. In the name-based ICN routing context, the name
resolution is needed by any ICN router whose forwarding
information base (FIB) does not contain
the requested name prefix. Name resolution may also be performed
by the consumer (especially in the case where the consumer is
multihomed) to forward the content request in a better direction
so that it obtains the content from the nearest cache. If the
consumer is single homed, it may not bother to perform name
resolution, instead depending on either straightforward name-based
routing or name resolution by an upstream ICN router. On this case,
the consumer creates the content request packet containing the
content name and forwards to the nearest ICN router. The ICN
router checks its FIB table to see where to forward the content
request. If the ICN router fails to know the requested content
reachable, it performs name resolution to obtain the name mapping
record and adds this information to its FIB. The ICN router
may also perform name resolution even before the arrival of a
content request to use the name mapping record to configure
its FIB.¶
Name record update: Name record update is carried out when a
content name mapping record changes, e.g. the content is not
available in one or more of previous locations. The name record
update includes the substitution and deletion of the name mapping
records. The name record update may take place explicitly by the exchange of name
record update messages or implicitly when a timeout occurs and
a name record is deemed to be invalid. The implicit update is
possible when each record is accompanied by a lifetime value.
The lifetime can be renewed only by the authoritative producer
or node. The cached mapping records get erased after the lifetime
expires unless a lifetime extension indication is obtained from
the authoritative producer.¶
In order to develop an NRS system within a local ICN network domain or
global ICN network domain, new protocols and semantics must be designed
and implemented to manage and resolve names among different name spaces.¶
One way of implementing an NRS for CCNx is by extending the basic TLV
format and semantics [RFC8569][RFC8609].
For instance, name resolution and response messages can be implemented
by defining new type fields in the Interest and Content Object
messages [CCNxNRS]. By leveraging the existing CCNx
Interest and Content Object packets for name resolution and registration,
the NRS system can be deployed with a few ICN protocol changes. However,
because of confining the changes to the basic ICN protocol and semantics,
the NRS system may not be able to exploit more flexible and scalable designs.¶
On the other hand, an NRS system can be designed independently with its
own protocol and semantics like the NRS system described in [Hong].
For instance, the NRS protocol and messages can be implemented by using
a RESTful API and the NRS can be operated as an application protocol
independent of the rest of the ICN protocol.¶
An NRS reduces the routing complexity of ICN architecture compared to pure
name-based routing. It does so by permitting the routing system to update
the routing table on demand through the help of name records obtained
from NRS. The routing system therefore needs to make name resolution
requests and process the information returned, such as a prefix, a locator, an
off-path-cache pointer, or an alias name, obtained from the name resolution.¶
No matter what kind of information is obtained from the name resolution,
as long as it is in the form of a name, the content request message in
the routing system may be reformatted with the obtained information.
In this case, the content name requested originally by a consumer needs
to be involved in the reformatted content request to check the integrity
of the binding between the name and the requested content. In other words,
the information obtained from the name resolution is used to forward
the content request and the original content name requested by a consumer
is used to identify the content. Alternatively, the resolved information
may be used to build the routing table.¶
The information obtained from name resolution may not be in the form of
a name. For example, it may identify tunnel endpoints by IP address
and instead be used to construct an IP protocol tunnel through which
to forward the content request.¶
A Name Resolution Service (NRS) is not a mandatory part in an ICN architecture,
as the majority of ICN architectures use name-based routing which does not
employ a name resolution procedure. However, such name-based routing in ICN
has inherent challenges in enabling a globally scalable routing system,
accommodating producer mobility, and supporting off-path caching.
In order to address these challenges, an NRS system has been introduced in
several ICN projects. Therefore, this document describes how the ICN architecture
changes when an NRS is utilized and how this affects the ICN routing system.¶
The document defines a few terminologies related to an NRS and explains
some inherent challenges of pure name-based routing in ICN such as routing
scalability, producer mobility, and off-path caching. This document describes
how the ICN architecture would change with respect to procedures, latency,
and security when an NRS is utilized. According to the ICN architectural
changes, this document describes ICN architectural considerations for NRS
such as the functions related to the registration, resolution and update
of name mapping records, protocols and semantics to implement an NRS system,
and the routing system involving the name resolution.¶
When any new component such as an NRS is introduced in the ICN architecture,
the attack surface increases. The related security vulnerability issues
are discussed below:¶
Name space security: In order to deploy an NRS system in ICN
architecture, ICN name spaces, which may be assigned by
authoritative entities, must be securely mapped to the content
publishers and securely managed by them. According to the ICN
research challenges [RFC7927], a new name space can also provide
an integrity verification function to authenticate its publisher.
The issues of namespace authentication and the mapping among different
name spaces require further investigation.¶
NRS system security: An NRS requires the deployment of new entities
(e.g. NRS servers) to build distributed and scalable NRS systems.
Thus, the entities, e.g., NRS server maintaining a mapping database,
could be the focus of attacks by receiving malicious requests
from innumerable adversaries comprising a Denial of Service or
Distributed Denial of service attacks. In addition, NRS clients
in general must trust the NRS nodes in other network domains to
some degree and communication among them must also be protected
securely to prevent malicious entities from participating in this
communication. The history of name resolution data requires to be
stored and analyzed as in passive DNS to uncover potential security
incidents or discover malicious infrastructures.¶
NRS protocol and message security: In an NRS system, the protocols
to generate, transmit and receive NRS messages related to the name
registration, resolution, and record update should be protected
by proper security mechanisms. Proper security measures must be
provided so that only legitimate nodes can initiate and read NRS
messages. These messages must have secured by integrity protection
and authentication mechanism so that unauthorized parties cannot
manipulate them when being forwarded through the network. Security
measures to encrypt these messages should also be developed to
thwart all threats to both security and privacy. Numerous problems
similar to the security issues of an IP network and DNS can affect the
overall ICN architecture. The DNS QNAME minimization type of approach
would be suitable for preserving privacy in the name resolution process.
Therefore, security mechanisms such as accessibility, authentication,
etc., for the NRS system [RFC9138] should be
considered to protect not only the NRS system, but also the ICN architecture overall.¶
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7927]
Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, , <https://www.rfc-editor.org/info/rfc7927>.
[RFC8569]
Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", https://www.rfc-editor.org/info/rfc8569 , .
[RFC8609]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Format", https://www.rfc-editor.org/info/rfc8609 , .
[RFC9138]
Hong, J. et al., "Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)", https://www.rfc-editor.org/info/rfc9138 , .
"NSF Mobility First project.", http://mobilityfirst.winlab.rutgers.edu/ .
[Bayhan]
Bayhan, S. et al., "On Content Indexing for Off-Path Caching in Information-Centric Networks", ACM ICN , .
[CCNxNRS]
Hong, J. et al., "CCNx Extension for Name Resolution Service", draft-hong-icnrg-ccnx-nrs-02 , .
[Hong]
Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable Name Resolution System for Information-Centric Networking", ACM ICN , .
[Dannewitz]
Dannewitz, C. et al., "Network of Information (NetInf)-An information centric networking architecture", Computer Communications vol. 36, no. 7, .
[Dannewitz2]
Dannewitz, C., DAmbrosio, M., and V. Vercellone, "Hierarchical DHT-based name resolution for Information-Centric Networks", Computer Communications vol. 36, no. 7, .
The authors would like to thank Dave Oran (ICNRG Co-chair)
for very useful reviews and comments on the document and they helped to
immeasurably improve the document.¶