Architectural Considerations of ICN using Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-05

Versions: (draft-hong-icnrg-nrs-requirements) 00           Informational
          01 02 03 04 05                                                
ICN Research Group                                               J. Hong
Internet-Draft                                                    T. You
Intended status: Informational                                      ETRI
Expires: March 13, 2021                                         V. Kafle
                                                                    NICT
                                                       September 9, 2020


   Architectural Considerations of ICN using Name Resolution Service
               draft-irtf-icnrg-nrsarch-considerations-05

Abstract

   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).

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

   This Internet-Draft will expire on March 13, 2021.

Copyright Notice

   Copyright (c) 2020 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



Hong, et al.             Expires March 13, 2021                 [Page 1]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Implications of NRS in ICN  . . . . . . . . . . . . . . . . .   5
   5.  ICN Architectural Considerations for NRS  . . . . . . . . . .   6
     5.1.  Name mapping records registration, resolution, and update   6
     5.2.  Protocols and Semantics . . . . . . . . . . . . . . . . .   8
     5.3.  Routing System  . . . . . . . . . . . . . . . . . . . . .   8
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Information-Centric Networking (ICN) is an approach to evolving the
   Internet infrastructure to provide direct access to Named Data
   Objects (NDOs) by name.  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 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 [NRSconsiderations], which provides the
   analysis of NRS approaches, functions of NRS and design
   considerations of NRS.




Hong, et al.             Expires March 13, 2021                 [Page 2]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   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.

2.  Terminology

   o  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
      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 [NRSconsiderations].
      An NRS is most likely implemented through the use of a distributed
      mapping database system.

   o  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.

   o  NRS resolver: The client side 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.

   o  Name registration: In order to populate the NRS, the content names
      and their mapping records must be registered in NRS system by a
      publisher who has an access 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 names and locators, which are used for forwarding
      the content request.  Thus, a publisher or producer 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.

   o  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



Hong, et al.             Expires March 13, 2021                 [Page 3]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


      toward an NRS server.  The NRS server searches for the content
      name in its mapping record database, and if found retrieves and
      returns the mapping record in a name resolution response message
      to the NRS resolver.

   o  NRS node: NRS servers are also referred to as NRS nodes that
      maintain the name records.  The terms are used interchangeably.

   o  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.

3.  Background

   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:

   o  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 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].

   o  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.



Hong, et al.             Expires March 13, 2021                 [Page 4]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   o  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.

4.  Implications of NRS 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:

   o  Forwarding procedure: When an NRS is included in an ICN
      architecture, the name resolution procedure has to be included in
      the ICN overall 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.

   o  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 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.





Hong, et al.             Expires March 13, 2021                 [Page 5]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   o  Security: When an NRS is included in an ICN architecture, security
      threats 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.  These challenges must be overcome by
      taking appropriate security measures into consideration.

5.  ICN Architectural Considerations for NRS

   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.

5.1.  Name mapping records registration, resolution, and update

   When an NRS is utilized 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 so 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.


                   +------------+             +------------+
                   |  NRS Node  |             |  NRS Node  |
                   +------------+             +------------+
                         |                          |
                         |                          |
      +------------+     |                          |     +------------+
      | NRS Client |--------------------------------------| NRS Client |
      +------------+         underlying network           +------------+


    Figure 1: NRS nodes and NRS clients connected through an underlying
                                  network

   o  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



Hong, et al.             Expires March 13, 2021                 [Page 6]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


      node.  Name registration may be performed by an ICN router when it
      does 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.

   o  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 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.

   o  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 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 explicit update is possible
      when each record is accompanied by a lifetime value.




Hong, et al.             Expires March 13, 2021                 [Page 7]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


5.2.  Protocols and Semantics

   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.

5.3.  Routing System

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




Hong, et al.             Expires March 13, 2021                 [Page 8]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   address and instead be used to construct an IP protocol tunnel
   through which to forward the content request.

6.  Conclusion

   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.

7.  IANA Considerations

   There are no IANA actions required by this document.

8.  Security Considerations

   When an NRS is utilized in an ICN architecture, security threats may
   increase in various aspects as discussed below:

   o  Name Space Management: 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.
      Secure verification for the mappings among different name spaces
      is required.

   o  NRS System: 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,



Hong, et al.             Expires March 13, 2021                 [Page 9]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


      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.

   o  NRS Protocols and Messages: In an NRS system, additional messages
      related to the name registration, name resolution, and name record
      update can spill over to unauthorized parties, increasing the
      threats to both security and privacy.  An adversary can attempt to
      manipulate these messages by hijacking them to create false
      messages.  Numerous problems similar to the security issues of an
      IP network can affect the overall ICN architecture.  Therefore,
      security mechanisms such as accessibility, authentication, etc.,
      [NRSconsiderations] for the NRS system should be considered to
      protect not only the NRS system, but also the ICN architecture
      overall.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, July 2016,
              <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 , July 2019.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", https://www.rfc-editor.org/info/rfc8609 , July
              2019.

9.2.  Informative References

   [NDN]      "NSF Named Data Networking project.",
              http://www.named-data.net .




Hong, et al.             Expires March 13, 2021                [Page 10]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


   [CCNx]     "Content Centric Networking project.",
              https://wiki.fd.io/view/Cicn .

   [Afanasyev]
              Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to
              Scale NDN Forwarding", IEEE Global Internet Symposium ,
              April 2015.

   [Zhang2]   Zhang, Y., "A Survey of Mobility Support in Named Data
              Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES,
              ALGORITHMS, AND APPLICATIONS(NOM) , 2016.

   [Ravindran]
              Ravindran, R. et al., "Forwarding-Label support in CCN
              Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July
              2017.

   [SAIL]     "FP7 SAIL project.", http://www.sail-project.eu/ .

   [MF]       "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 ,
              September 2016.

   [CCNxNRS]  Hong, J. et al., "CCNx Extension for Name Resolution
              Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018.

   [Hong]     Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable
              Name Resolution System for Information-Centric
              Networking", ACM ICN , September 2015.

   [NRSconsiderations]
              Hong, J. et al., "Design Guidelines for Name Resolution
              Service in ICN", draft-irtf-icnrg-nrs-requirements-03 ,
              November 2019.

   [Dannewitz]
              Dannewitz, C. et al., "Network of Information (NetInf)-An
              information centric networking architecture", Computer
              Communications vol. 36, no. 7, April 2013.

   [Dannewitz2]
              Dannewitz, C., DAmbrosio, M., and V. Vercellone,
              "Hierarchical DHT-based name resolution for Information-
              Centric Networks", Computer Communications vol. 36, no. 7,
              April 2013.



Hong, et al.             Expires March 13, 2021                [Page 11]


Internet-Draft    Arch Considerations of ICN using NRS    September 2020


Acknowledgements

   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.

Authors' Addresses

   Jungha Hong
   ETRI
   218 Gajeong-ro, Yuseung-Gu
   Daejeon  34129
   Korea

   Email: jhong@etri.re.kr


   Tae-Wan You
   ETRI
   218 Gajeong-ro, Yuseung-Gu
   Daejeon  34129
   Korea

   Email: twyou@etri.re.kr


   Ved Kafle
   NICT
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: kafle@nict.go.jp


















Hong, et al.             Expires March 13, 2021                [Page 12]