ICN Research Group J. Hong
Internet-Draft T. You
Intended status: Informational Y-G. Hong
Expires: September 12, 2019 ETRI
March 11, 2019

Architectural Considerations of ICN using Name Resolution Service


This document discusses architectural considerations and implications of Information-Centric Networking (ICN) related to the usage of the Name Resolution Service (NRS). It describes how ICN architectures may change and what implications are introduced within the ICN routing system when NRS is integrated into ICN.

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 September 12, 2019.

Copyright Notice

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

Information-Centric Networking (ICN) is an approach to evolve the Internet infrastructure to directly access Named Data Objects (NDOs) by its name, i.e., the name of NDO is directly used to route the request to the data object. Such name based routing in ICN poses a number of issues, which are not solved yet in ICN. These issues includes global scalability of routing, producer mobility, off-path cache, etc. In order to address these issues, the Name Resolution Service (NRS) has been integrated into several ICN projects and literature [Afanasyev][Zhang2][Ravindran][SAIL][MF][Bayhan].

This document describes how ICN architectures may change and what implications are introduces within the ICN routing system when NRS is integrated into ICN. It also discusses ICN architectural considerations for an NRS. In other words, the scope of this document includes considerations in the veiw of the ICN architecture and routing system when integrating NRS into ICN. However, it does not include the NRS discussion, itself, which is presented in [NRSrequirements].

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Background

The name based routing in ICN can be helpful to address a number of challenges, such as global scalability of routing, producer mobility, and off-path caching in ICN. In order to address these challenges, an NRS has been integrated into several ICN projects and literature:

This document discusses architectural considerations and implications of ICN when NRS is integrated into ICN to solve such challenges due to the name-based routing in ICN.

4. Implications of NRS in ICN

In general, NRS would not be mandatory in an ICN architecture if the name-based routing system can be scalable enough to timely reflect the optimal location of requested content in the routing table. However, due to the unlimited size of content namespace, it is not easy to achieve such a scalable routing system in near future. Therefore, the adoption of an NRS is a design choice for making ICN routing and forwarding scalable. Integration of NRS would change the ICN architecture at least with respect to procedures, latency, and security, which are described below.

5. ICN Architectural Considerations for NRS

This section discusses the various items that have to be considered from the point of view of ICN architecture when it utilizes an NRS. These items are related with the name mapping records registration, resolution, and update, protocols and messages, and integration with the routing system.

5.1. Name resolution

When an NRS is integrated into an ICN architecture, the followings related with the registration and resolution of name mapping records have to be considered.

The name resolution in ICN can be performed by consumer, routers, or both. Once it is decided where the name resolution will take place, it has to be considered how the name resolution will be performed. The name provided by a consumer might be always resolved to identifiers in a differnet namespace just like a DNS lookup. Conversely, an NRS is always needed to map names to a different namespace.

5.2. Protocols and Semantics

In order to develop a NRS system within a local ICN network domain or global ICN network domain, new protocols and semantics should be designed to manage and resolve names between different name spaces.

One way of implementing an NRS is by extending the basic ICN TLV format and semantics [CCNxMessages] [CCNxSemantics]. For instance, name resolution and response messages can be implemented by defining new type fields in the Interest and Content Object messages [CCNxNRS]. Then it allows the ICN architecture to minimize implication of ICN architectural changes. But NRS system cannot support more flexible and scalable designs cause to restrict basic ICN protocol and semantics.

On the other hand, a NRS system can be implemented by using its own protocol and semantics like existing NRS systems, such as [Hong]. For instance, the NRS protocol and messages can be implemented by using a RESTful API. Then a NRS as application protocol can be operated independently from a basic ICN architecture, but an ICN architecture cannot be assisted with the routing protocol itself effectively.

5.3. Routing System

It has to be considered how to process the information resolved by an NRS lookup. The results of an NRS operation can be intended to be used just to construct tunnels resulting in NRS identifying tunnel endpoints.

Another way to process the information resolved by an NRS lookup is to use it as routing hints in request messages. In this case, request message needs to be re-written with the resolved information including the original name that was requested by a consumer to check the data integrity.

6. Security Considerations

When NRS is integrated into an ICN architecture, security threats shall be increased in various aspects such as followings.

6.1. Name Space Separation

In order to deploy an NRS on ICN architecture, ICN name spaces are separated into more than two name spaces. Thus these name spaces should be mapped and managed securely. According to the ICN research challenge [RFC7927], new name space can also provide an integrity verification function to authenticate its publishers. In addition to the verification, binding two different name spaces should be securely required.

6.2. NRS System

NRS enables deployment of new entities to build distributed and scalable NRS systems. Thus, the entities, e.g., mapping server that can be a mapping database, could be a single point of failure receiving malicious requests from innumerable adversaries like Denial of Service or Distributed Denial of service attacks. Additionally, in order to communicate with the entities to build a NRS system, an initiator should rely on other NRS entities that are designed to be distributed deployed mapping servers in each network domain. Because malicious entities should be involved in this communication to impersonate control functions. Thus, NRS entities should trust each other and communications with them should be protected securely.

6.3. NRS Protocols and Messages

Regarding NRS messages, such as lookup, update, etc., if these messages are transported unauthenticated, an adversary can manipulate them and hijack the important communication to response or to store fake data. Thus, the adversary can generate malicious traffic to be redirected to victim hosts. Therefore, security requirements for NRS should be considered to protect the ICN architecture as well as the NRS.

7. Acknowledgements


8. References

8.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.
[RFC7927] Kutscher, D., 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.

8.2. Informative References

[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.
[CCNxSemantics] Mosko, M., Solis, I. and C. Wood, "CCNx Semantics", draft-irtf-icnrg-ccnxsemantics-06 , October 2017.
[CCNxMessages] Mosko, M., Solis, I. and C. Wood, "CCNx Messages in TLV Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017.
[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.
[NRSrequirements] Hong, J. et al., "Requirements for Name Resolution Service in ICN", draft-irtf-icnrg-nrs-requirements-01 , March 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.

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
Yong-Geun Hong ETRI 218 Gajeong-ro, Yuseung-Gu Daejeon, 34129 Korea EMail: yghong@etri.re.kr