ICN Research Group                                              Y. Zhang
Internet-Draft                                            D. Raychadhuri
Intended status: Informational                WINLAB, Rutgers University
Expires: January 8, 2017                                       L. Grieco
                                               Politecnico di Bari (DEI)
                                                              S. Sabrina
                                    Universita degli studi dell Insubria
                                                                  H. Liu
                                      The Catholic University of America
                                                                S. Misra
                                             New Mexico State University
                                                            R. Ravindran
                                                                 G. Wang
                                                     Huawei Technologies
                                                            July 7, 2016


                     ICN based Architecture for IoT
                 draft-zhang-icnrg-iot-architecture-00

Abstract

   Internet of Things (IoT) promises to connect billions of objects to
   Internet.  Nowadays, the IoT landscape is very fragmented from both
   technological and service perspectives.  As a consequence, it is
   difficult to cross correlate data coming from heterogeneous contexts
   and build added value services on top of them.  For this reason, the
   current trend is to develop a unified de-fragmented IoT platform so
   that objects can be made accessible to applications across
   organizations and domains.  Towards this goal, quite a few proposals
   have been made to build a unified IoT platform as an overlay on top
   of today's Internet.  Such overlay solutions, however, inherit the
   same limitations of the IP protocol, in terms of mobility, security,
   scalability and communication reliability.  To address this problem,
   we propose a unified IoT platform based on the Information Centric
   Networking (ICN) architecture, which we call ICN-IoT [2].  ICN-IoT
   leverages the salient features of ICN, and thus provides seamless
   device-to-device (D2D) communication, mobility support, scalability,
   and efficient content and service delivery.  Furthermore, in order to
   guarantee the real diffusion of ICN-IoT architecture it is
   fundamental to deal with security and privacy requirements, since the
   system may handle sensitive information (e.g., user habits, devices
   location).  Note that ICN-IoT needs to manage the security
   requirements at the early stage of the design, representing all the
   involved entities and their relationships, in order to better
   understand their interactions and, consequently, apply the proper
   countermeasures to the possible security attacks (e.g., data
   violation, privacy violation, access attacks).



Zhang, et al.            Expires January 8, 2017                [Page 1]


Internet-Draft       ICN based Architecture for IoT            July 2016


   This draft begins by motivating the need for an unified ICN-IoT
   platform to connect heterogenous IoT systems.  We then propose an
   ICN-IoT system architecture and middleware components which includes
   device/network-service discovery, naming service, IoT service
   discovery, data discovery, user registration, and content delivery.
   For all of these components, a secure solution is defined too.  We
   also provide discussions on inter-connecting heterogeneous ICN-IoT
   domains.

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 January 8, 2017.

Copyright Notice

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











Zhang, et al.            Expires January 8, 2017                [Page 2]


Internet-Draft       ICN based Architecture for IoT            July 2016


Table of Contents

   1.  ICN-Centric Unified IoT Platform  . . . . . . . . . . . . . .   3
     1.1.  Strengths of ICN-IoT  . . . . . . . . . . . . . . . . . .   4
   2.  ICN-IoT System Architecture . . . . . . . . . . . . . . . . .   6
   3.  ICN-IoT Middleware Architecture . . . . . . . . . . . . . . .   7
   4.  ICN-IoT Middleware Functions  . . . . . . . . . . . . . . . .   8
     4.1.  Device Discovery  . . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  Detailed Discovery Process  . . . . . . . . . . . . .  10
     4.2.  Naming Service  . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Service Discovery . . . . . . . . . . . . . . . . . . . .  13
     4.4.  Context Processing and Storage  . . . . . . . . . . . . .  15
     4.5.  Publish-Subscribe Management  . . . . . . . . . . . . . .  16
     4.6.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  19
   5.  Support to heterogeneous core networks  . . . . . . . . . . .  19
     5.1.  Interoperability with IP legacy network . . . . . . . . .  19
     5.2.  Named protocol bridge . . . . . . . . . . . . . . . . . .  19
     5.3.  Inter-domain Management . . . . . . . . . . . . . . . . .  20
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  ICN-Centric Unified IoT Platform

   In recent years, the current Internet has become inefficient in
   supporting rapidly emerging Internet use cases, e.g., mobility,
   content retrieval, IoT, contextual communication, etc.  As a result,
   Information Centric Networking has been proposed as a future Internet
   design to address these inefficiencies.  ICN has the following main
   features: (1) it identifies a network object (including a mobile
   device, a content, a service, or a context) by its name instead of
   its IP address, (2) a hybrid name/address routing, and (3) a delay-
   tolerant transport.  These features make it easy to realize many in-
   network functions, such as mobility support, multicasting, content
   caching, cloud/edge computing and security.

   Considering these salient features of ICN, we propose to build a
   unified IoT platform using ICN, in which the overlay IoT services are
   only needed for administrative purposes, while the publishing,
   discovery, and delivery of the IoT data/services is directly
   implemented within the ICN network.  Figure 1 shows the proposed ICN-
   centric IoT approach, which is centered around the ICN network
   instead of today's Internet.









Zhang, et al.            Expires January 8, 2017                [Page 3]


Internet-Draft       ICN based Architecture for IoT            July 2016


               ______________   __________   __________
              |IoT Smart Home| |IoT Smart | |IoT Smart |
              |Management    | |Transport | |Healthcare|
              |______________| |Management| |Management|
                   \           |__________| |__________|
                    \               |             /
                     \ _____________|___________ /
                      {                         }
                      {                         }
                      {           ICN           }
                      {                         }
                      {_________________________}
                        /           |         \
                       /            |          \
             _________/     ________|______   __\_____________
            {          }   {               } {                }
            {Smart home}   {Smart Transport} {Smart Healthcare}
            {__________}   {_______________} {________________}
              |      |          |      |         |          |
           ___|__  __|___     __|__  __|__   ____|____  ____|____
          |Home-1||Home-2|   |Car-1||Car-2| |Medical  ||Medcical |
          |______||______|   |_____||_____| |Devices-1||Devices-2|
                                            |_________||_________|


             Figure 1: The proposed ICN-centric IoT unified platform.


1.1.  Strengths of ICN-IoT

   Our proposed ICN-IoT architecture delivers IoT services over the ICN
   network, which aims to satisfy the requirements of the open IoT
   platform (discussed in "draft-zhang-icnrg-icniot-requirements-
   01"[2]):

   o  Naming.  In ICN-IoT, we assign a unique name to an IoT object, an
      IoT service, or even a context.  These names are persistent
      throughout their scopes.

   o  Scalability.  In ICN-IoT, the name resolution is performed at the
      network layer, distributed within the entire network.  Thus, it
      can achieve high degree of scalability exploiting features like
      content locality, local computing, and multicasting.

   o  Resource efficiency.  In ICN-IoT, in both the constrained and non-
      constrained parts of the network, only those data that are
      subscribed by applications in the specified context will be
      delivered.  Thus, it offers a resource-efficient solution.



Zhang, et al.            Expires January 8, 2017                [Page 4]


Internet-Draft       ICN based Architecture for IoT            July 2016


   o  Local traffic Pattern.  In ICN-IoT, we can easily cache data or
      deploy services in the network, hence making communications more
      localized and reducing the overall traffic volume.

   o  Context-aware communications.  ICN-IoT supports contexts at
      different layers, including device layer, networking layer and
      application layer.  Contexts at the device layer include
      information such as battery level or location; contexts at the
      network layer include information such as network status and
      statistics; contexts at the application layer are usually defined
      by individual applications.  In ICN-IoT, device and network layer
      contexts are stored in the network layer, while network elements
      (i.e., routers) are able to resolve application-layer contexts to
      lower-layer contexts.  As a result of adopting contexts and
      context-aware communications, communications only occur under
      certain contexts that are specified by applications, which can
      significantly reduce the entire network traffic volume.

   o  Seamless mobility handling.  In ICN-IoT, ICN's name resolution
      layer allows multiple levels of mobility relying on receiver-
      oriented nature for self-recovery for consumers, and using
      multicasting and late-binding techniques to realize seamless
      mobility support of producing nodes.

   o  Self-Organization: Name based networking allows service level self
      configuration and bootstrapping of devices with minimal
      manufacturer or administrator provisioned configuration.  This
      configuration involves naming, key distribution and trust
      association to enable data exchange between applications and
      services.

   o  Data storage.  In ICN-IoT, data are stored locally, either by the
      mobile device or by the gateway nodes or at service points.  In-
      network storage/caching [3] also speeds up data delivery.

   o  Security and privacy.  In ICN-IoT, secure binding between names
      and objects instead of IP addresses to identify devices/data/
      services, is inherently more secure than the traditional IP
      paradigm [10].

   o  Communication reliability.  ICN-IoT supports delay tolerant
      communications [17], which in turn provides reliable
      communications over unreliable links.

   o  Ad hoc and infrastructure mode.  ICN-IoT supports both
      applications operating in ad-hoc [1] and infrastructure modes.





Zhang, et al.            Expires January 8, 2017                [Page 5]


Internet-Draft       ICN based Architecture for IoT            July 2016


   o  In-network processing.  ICN offers in-network processing that
      supports various network services, such as context resolution,
      data aggregation and compression.

2.  ICN-IoT System Architecture

   The ICN-IoT system architecture, which is also a general abstraction
   of an IoT system, is shown in Figure 2, has the following five main
   system components:



     +----------------+      +-----------------+       +-----------------+       +------------------+
     |Embedded System | <--> | Aggregator      | <-->  | Local Service   | <-->  |    IoT Server    |
     +----------------+      +-----------------+       |     Gateway     |       |                  |
            |                            |             +-----------------+       +------------------+
            |                            |                   ^                           ^
     +----------------+      +----------------+              |                           |
     | Embedded System|      |Aggregator      | <------------                            V
     +----------------+      +----------------+                                 +-------------------+
                                                                                | Services/Consumers|
                                                                                +-------------------+


                                                          Figure 2: ICN-IoT System Architecture


   o  Embedded Systems: The embedded sensor has sensing and actuating
      functions and may also be able to relay data for other sensors to
      the Aggregator, through wireless or wired links.

   o  Aggregator: It interconnects various entities in a local IoT
      network.  Aggregators serve the following functionalities: device
      discovery, service discovery, and name assignment.

   o  Local Service Gateway (LSG): A LSG serves the following
      functionalities: (1) it is at the administrative boundary, such
      as, the home or an enterprise, connecting the local IoT system to
      the rest of the global IoT system, (2) it serves to assign ICN
      names to local sensors, (3) it enforces data access policies for
      local IoT devices, and (4) it runs context processing services to
      generate information specified by application-specific contexts
      (instead of raw data) to the IoT server.

   o  IoT Server: Within a given IoT service context, the IoT server is
      a centralized server that maintains subscription memberships and
      provides the lookup service for subscribers.  Unlike legacy IoT
      servers that are involved in the data path from publishers to



Zhang, et al.            Expires January 8, 2017                [Page 6]


Internet-Draft       ICN based Architecture for IoT            July 2016


      subscribers -- raising the concern of its interfaces being a
      bottleneck -- the IoT server in our architecture is only involved
      in the control path where publishers and subscribers exchange
      their names, certificates, and impose other security functions
      such as access control.

   o  Services/Consumer: These are other application instances
      interacting with the IoT server to fetch or be notified of
      anything of interest within the scope of the IoT service.

   The logical topology of the IoT system can be mesh-like, with every
   sensor attached to one or more aggregators, while every aggregator is
   attached to one or more LSG and all the LSGs connected to the IoT
   server.  Thus, each sensor has its aggregators, and each of which in
   turn has its LSG.  All sensors belonging to the same IoT service
   share the same IoT server.  All the aggregators that are attached to
   the same LSG management are logical neighbors to each other.  While
   such richer connectivity improves reliability, it also requires
   control plane sophistication to manage the inter-connection.  Though
   our discussion can be generalized to such mesh topologies, in the
   rest of the draft, we will focus on the tree topology for the sake of
   simplicity.

3.  ICN-IoT Middleware Architecture

   The proposed ICN-IoT middleware aims to bridge the gap between
   underlying ICN functions, IoT applications and devices to achieve
   self-organizing capability.

   The middleware functions are shown in Fig. 3 and it includes six core
   functions: device discovery, naming service, service discovery,
   context processing and storage, pub/sub management, and security
   which spans all these functions.

   In contrast to centralized or overlay-based implementation in the
   legacy IP-based IoT platform, ICN-IoT architecture pushes a large
   portion of the functionalities to the network layer, such as naming
   resolution, mobility management, in-network processing/caching,
   context processing, which greatly simplifies the middleware design.












Zhang, et al.            Expires January 8, 2017                [Page 7]


Internet-Draft       ICN based Architecture for IoT            July 2016


                                +------------------------------------+
                                |         (IoT Middleware)           |
                                |                                    |
                                |   +----------------------+  +--+   |
                                |   |  Pub/Sub Management  |  |  |   |       +---------------------+
                                |   +----------------------+  |  |   |       |      Consumer       |
           +-------------+      |   |Context Processing and|  |S |   |       |  +-------------+    |
           |             |      |   |  Storage             |  |E |   |       |  |             |    |
           | Sensor      |      |   +----------------------+  |C |   |       |  |    App      |    |
           + ----------- +      |   |IoT Service Discovery |  |U |   |       |  +-------------+    |
           |Gateway      |<-->  |   |                      |  |R |   | <-->  |  |  Service    |    |
           +-------------+      |   +----------------------+  |I |   |       |  +-------------+    |
           |Actuator     |      |   |  Naming Service      |  |T |   |       +---------------------+
           +-------------+      |   +----------------------+  |Y |   |
           |Smart thing  |      |   | Device Discovery     |  |  |   |
           +-------------+      |   +----------------------+  +--+   |
                                +------------------------------------+
                                          ^          ^
                                          |          |
                                          V          V
                            +---------------------------------------------+
                            |                  ICN Network                |
                            |   +-------------------------------------+   |
                            |   |       In-network Computing          |   |
                            |   |    (Data Aggregation/Fusion)        |   |
                            |   +-------------------------------------+   |
                            |   |         Network Service             |   |
                            |   |      (Multicast/Push/Pull)          |   |
                            |   +-------------------------------------+   |
                            |   |       Name Based Routing            |   |
                            |   +-------------------------------------+   |
                            |   |       Mobility and Security         |   |
                            |   +-------------------------------------+   |
                            +---------------------------------------------+

                    Figure 3: The ICN-IoT Middleware Functions


4.  ICN-IoT Middleware Functions

   The ICN-IoT middleware mainly consists of the following functions:
   device discovery, service discovery, naming service, publish/
   subscribe management, context processing, and security.  For each of
   these functions we highlight what these function achieves, advantages
   an ICN architecture enables in realizing this function, and provide
   discussion of how the function can be realized considering two ICN
   protocols i.e. NDN [5] and MobilityFirst (MF) [4].




Zhang, et al.            Expires January 8, 2017                [Page 8]


Internet-Draft       ICN based Architecture for IoT            July 2016


   Please note while most these middleware functions are implemented on
   unconstrained aggregators, LSGs and the IoT servers, only very
   limited functions (mainly for device discovery and naming service)
   are implemented on resource-constrained sensors, while unconstrained
   devices within an aggregator can execute more functions such as
   service discovery.

4.1.  Device Discovery

   Device discovery is a key component of any IoT system.  The objective
   of device discovery is to expose new devices to the rest of the IoT
   system - every entity should be exposed to its direct upstream device
   and possibly other devices.  Specifically, it includes the following
   three aspects: (1) a newly added sensor should be exposed to its
   aggregator, and possibly to its LSG and the IoT server; (2) a newly
   added aggregator is exposed to its LSG, and possibly to its neighbor
   aggregators; and (3) a newly added LSG should be exposed to the IoT
   server.  We note that device discovery could be used in other
   contexts, such as neighboring sensors discovering each other to form
   routing paths, but in this draft, we use the term to specifically
   mean discovering new devices for IoT middleware purpose.

   During device discovery for newly-added sensors, the sensor passes
   its device-level information (such as manufacturer-ID and model
   number) and application-level information (such as service type and
   data type) to the upstream devices.  If the device is required to
   have a globally unique ICN ID, but does not have one yet, it is given
   one by the naming service (described in Section 4.2), and recorded by
   the LSG (and possibly the aggregator and the IoT server).  As part of
   the device discovery process, each sensor will also be assigned a
   local network ID (LID) that is unique in its local domain.  Then the
   device will use its LID for routing within the local domain (i.e.
   between sensors and the aggregator) because the globally unique ICN
   ID associated with a device is usually quite long and not energy
   efficient for constrained IoT devices.  One approach to generate a
   short LID is to hash its persistent ID.

   ICN enables flexible and context-centric device discovery which is
   important in IoT ecosystem where heterogeneous IoT systems belonging
   to different IoT services may co-exist.  Contextualization is a
   result of name-based networking where different IoT services can
   agree on unique multicast names that can be pre-provisioned in end
   devices and the network infrastructure using the routing control
   plane.  This also has an advantage of localizing device discovery to
   regions of network relevant to an ICN service, also enabling certain
   level of IoT asset security.  In contrast IP offers no such natural
   IoT service mapping; any forced mapping of this manner will entail




Zhang, et al.            Expires January 8, 2017                [Page 9]


Internet-Draft       ICN based Architecture for IoT            July 2016


   high configuration cost both in terms of device configuration, and
   network control and forwarding overhead.

4.1.1.  Detailed Discovery Process

   A device can be an embedded device, a virtual device, a process, or a
   service instance such as a sensing service.  We assume that the
   device has pre-loaded secure keys.  Specifically, we consider both
   resource-constrained devices and resource-rich devices, and assume
   that the pre-loaded secure keys are symmetric keys or passwords for
   the former, while the asymmetric key pair (public key certificate and
   the corresponding private key) for the latter.

   Below we discuss the detailed device discovery process.  We consider
   both resource-constrained devices and resource-rich devices.  We
   assume that for the former there is a mechanism for either securely
   pre-loading symmetric keys or passwords, while for the latter
   asymmetric key-pair using the public key infrastructure and
   certificate are used to exchange/generate the symmetric key (denoted
   as SMK_{device}).  We note that the use of asymmetric keys follows
   the standard PKI procedures with the the use of either self-
   certificates, certificates generated by a local (or domain specific)
   or global authority.  The bootstrapping of the constrained devices
   with symmetric keys can be performed in several ways.  As mentioned,
   pre-loading the device with keys before shipping is one approach, or
   the symmetric keys can be loaded by the administrator (or home owner
   or site-manager) at the time of bootstrapping of the device on-site.
   The approach is based on the level of trust and the threat model in
   which the system operates.  We also note that with ongoing research
   constrained devices are becoming increasingly powerful and new low-
   cost and computation based PKI approaches are being proposed.  In the
   future, constrained devices may be able to also use PKI mechanisms
   for creating symmetric keys.  In addition, we assume that there is a
   local authentication service (AS) that performs authentication,
   authorization and transient action key distribution.  The local
   authentication service is a logical entity that can be co-hosted at
   the LSG or IoT server.  The location of the AS may be informed by
   efficiency, security, and trust considerations.  The design offloads
   the complexity to the local AS and simplifies the operations at the
   devices.

   The device discovery process has the following steps:

   New device polling: The configuration service periodically sends out
   messages pulling information from new devices.  In NDN, this process
   is initiated by the configuration service running on the LSG, which
   periodically broadcasts discovery Interests (using the name /iot/
   model).  In MF, we can set a group-GUID as the destination address,



Zhang, et al.            Expires January 8, 2017               [Page 10]


Internet-Draft       ICN based Architecture for IoT            July 2016


   and the configuration service issues a polling via multicasting.
   Once the new device enters the IoT domain and receives the polling
   message, it sends a association request (AssoReq) message, including
   its manufacture ID, or ICN ID (if it has been assigned one before),
   its network and security capabilities, and a message ID which is used
   for the further message exchange between the new device and
   aggregator.  If the device is already assigned a symmetric key, it
   can use the symmetric key to communicate with the LSG (the ID can be
   transmitted in clear or by using a pseudonym [11]) to facilitate
   quick identification by the LSG.  If the device can use the PKI, a
   symmetric key can also be generated.  After the aggregator receives
   the AssoReq from the new device, it will request the LSG naming
   service to issue a local LID for this new device.  The aggregator
   shall send an Association Reply (AssoRep) message to the new device,
   which includes the message ID copied from the previous AssoReq
   message from the new device to indicate this association reply is for
   this new device, the selected authentication method according to the
   new device security capabilities, the assigned LID.  The AssoRep is
   sent to the new device via a specific multicast group (as the new
   device does not have a routable ID yet at this moment).  The LID is a
   short ID unique in the local IoT domain, and is used for the routing
   purpose in the local domain.  This specification will not limit the
   format of the LID and the method to generate a LID.  If
   authentication is not required, the device discovery is completed and
   the device can communicate with the aggregator using the LID.  If the
   Authentication is required, this LID is blocked by the aggregator
   from passing general data traffic between two devices until the
   authentication transaction completes successfully with the local
   authentication service.  The unauthenticated LID can only send
   traffic to the authentication service.  The aggregator forwards the
   traffic between the device and the local AS.  The aggregator may also
   implement the policy to regulate the amount of traffic to be sent by
   an unauthenticated LID to mitigate the DoS attack.  If the
   authentication is required, the following steps shall be performed.

   Mutual Authentication: The mutual authentication allows only
   authorized device to register and use the network, and to provide the
   device with assurance that it is communicating with a legitimate
   network.  If the authentication is required in the AssoRep, the
   device shall send a Authentication Request (AuReq) message to the
   aggregator using the selected authentication method.  The AuReq is
   signed with the pre-loaded SMK{device} for authentication.  The
   aggregator forwards the AuReq to the local AS.  The local AS performs
   authentication locally or contact the third-party AS according to the
   authentication method.  If the authentication is successful, the
   local AS generates a master symmetric key SMK{device, aggregator} for
   the communications between the device and the aggregator.  It sends
   Authentication Reply (AuRep) with master SMK{device, aggregator} to



Zhang, et al.            Expires January 8, 2017               [Page 11]


Internet-Draft       ICN based Architecture for IoT            July 2016


   the device via the aggregator.  The master SMK{device, aggregator} is
   protected with the pre-loaded SMK{device}. The local AS also sends a
   copy of master SMK{device, aggregator} to the aggregator through the
   secure connection between the local AS and the aggregator.

   Key generation and distribution: Once the master SMK{device,
   aggregator} is placed on the device and aggregator, the session keys
   (AKs) and group keys (GTKs) are generated and placed on the device
   and the aggregator for unicast and multicast communications,
   respectively, using the master SMK{device, aggregator}.

   Protected Data Transfer: The session keys (AKa and AKe) are used for
   message integrity and data confidentiality, respectively, which can
   be renewed periodically.

   In the second case, we consider devices that have sufficient
   resources to run asymmetric keys.  That is, the device is pre-loaded
   with a manufacture ID, a pair of public/private keys (PK_{device},
   SK_{device}) and a certificate which binds the device identity and
   public key.  In this case, we also go through the above three steps,
   with the only difference being in the second step which is Mutual
   Authentication.  In this case, the AuReq message shall include the
   device certificate and a message authentication code signed by the
   device private key SK_{device}. The local AS will authenticate the
   device once receiving the AuReq.  If the authentication succeeds,
   then the local AS will send the master SMK{device, aggregator} along
   with its certificate in AuRep.  AuRep contains a MAC signed by the
   local AS private key.  The mater SMK{device, aggregator} is encrypted
   using the device public key PK_{device}.  SMK{device, aggregator}
   will be used for generation of AKs to ensure the integrity and
   confidentiality of future data exchange between the device and the
   aggregator.

4.2.  Naming Service

   The objective of the naming service is to assure that either device
   or service itself is authenticated, attempting to prevent sybil (or
   spoofing) attack [12] and that the assigned name closely binds to the
   device (or service).  Naming service assigns and authenticates sensor
   and device names.  An effective naming service should be secure,
   persistent, and able to support a large number of application
   agnostic names.

   Traditional IoT systems use IP addresses as names, which are insecure
   and non-persistent.  IP addresses also have relatively poor
   scalability, due to its fixed structure.  Instead, ICN separates
   names from locators, and assigns unique and persistent names to each
   sensor/device, which satisfies the above requirements.



Zhang, et al.            Expires January 8, 2017               [Page 12]


Internet-Draft       ICN based Architecture for IoT            July 2016


   If a device needs a global unique name/ID, but does not have one, it
   may request the naming service to obtain one after it is
   authenticated.  Alternatively, the IoT domain (LSG or aggregator) may
   determine ID for an authenticated device is required based on the
   policy.  The proposed naming process works as follows.  After a
   device has been authenticated, it may request an ID from the naming
   service.  It sends a ID request (IDReq) to the naming service.  The
   aggregator serves as the devices' proxy and sends the IDReq to the
   naming service at the LSG.  The naming service assigns a ID to the
   device, which can be self-certified or a URI.  .  The naming service
   also generates a certificate, binding the ID/public key with the
   devices' manufacture ID or human-readable name.  The LSG sends a ID
   reply (IDRep) message to the aggregator that sends the IDRep to the
   device.  The IDRep includes the ID certificate and the corresponding
   private key.  The private key is encrypted and the entire message is
   integrity-protected with AK_{device} when the message is delivered to
   the device.  Alternatively, if the LSG determines that an
   authenticated device requires an ID when the aggregator registers
   this device, it will contact the naming service to generate the ID,
   certificate, and corresponding private key for the device.  It sends
   the ID information to the device.  If the device already has a pre-
   loaded public key, the naming service may use this pre-loaded public
   key as the device's ID.

   The LSG maintains the mapping between every devices' LID and the ID.
   When the LSG receives a message from the external network that is
   intended for a device within the domain, the LSG will translate the
   destination devices' ID (which is included in the message) to its LID
   and then route the message to the device using its LID.  Similarly,
   when the LSG receives a message from within the domain, it will
   replace the source devices' LID with its ID and then forward the
   message to the next-hop router.  Such a mechanism can ensure global
   reachability of any IoT device as well as energy efficiency for
   resource-constrained devices.

   Finally, we note that the same naming mechanism can be used to name
   higher-level IoT devices such as aggregators and LSGs.

4.3.  Service Discovery

   Service discovery intends to learn IoT services that are hosted by
   one aggregator by its neighbor aggregators.  The aggregators
   themselves learn service capability of the devices during the device
   discovery process or separately after authenticating (or even after
   naming) them.  The requirements for any discovery mechanism includes
   low protocol overhead (including low latency and low control message
   count), and discovery accuracy.




Zhang, et al.            Expires January 8, 2017               [Page 13]


Internet-Draft       ICN based Architecture for IoT            July 2016


   In today's IoT platforms, sensors, aggregators and LSGs are connected
   via IP multicast, which involves complicated group management and
   multicast name to IP translation service.  Multicast, however, is
   greatly simplified in ICN as most ICN architectures have natural
   support for multicast.

   Service discovery is widely accepted as an essential element in
   pervasive computing environments.  Many research activities on
   service discovery has been conducted, but privacy has often been
   ignored; while it is essential that legitimate users were able to
   discover the services for which they have the proper credentials.
   Furthermore, it is also necessary that services were hidden from
   illegitimate users.  Since service information, service provider's
   information, service requests, and credentials to access services via
   service discovery protocols could be sensitive, it is important to
   keep them private.  In [7], the authors present a user-centric model,
   called Prudent Exposure, as an approach designed for exposing minimal
   information privately, securely, and automatically for both service
   providers and users of service discovery protocols.

   Below, we explain how service discovery is implemented.  The key to
   service discovery is to expose aggregator's services to its neighbor
   aggregators.  How this is implemented differs in NDN and MF.

   In NDN, the following procedures are performed: 1) The source
   aggregator broadcasts an interest using the well-known name
   /area/servicename/certificate, which will eventually reach the
   destination aggregator.  NDN's Interest/Data mechanisms allows only
   one response for each Interest sent while discovery may require to
   learn multiple entities, hence efficient discovery is realized using
   exclusion via Selectors in the protocol or as an overlay protocol
   [6]; 2) After establishing the multicast group, the source aggregator
   sends a request containing the service name and certificate to the
   multicast group.  The destination aggregator that hosts the service
   checks the certificate and registers the source Aggregator if there
   is a matched service.  It replies with an acknowledgment containing
   certificate to the source aggregator.

   As an example of NDN smart home, a thermostat expresses a request to
   discover a AC service using well-known name /home/ac/certificate via
   broadcast channel.  In MF case, a multicast group GUID 1234 can be
   assigned to all home appliance IoT service.  The thermostat sends
   request containing the service name and certificate to 1234.  In both
   cases, the AC hosting this services replies with acknowledgment if
   all conditions match.

   As regards to secure multicast service request, it is possible to use
   the following solution adopted by MF.  In fact, especially in MF IoT,



Zhang, et al.            Expires January 8, 2017               [Page 14]


Internet-Draft       ICN based Architecture for IoT            July 2016


   secured group GUID is utilized, which may be owned by multiple hosts,
   hence conventional public/private key scheme may not be suitable for
   this case.  For secure service discovery, a secured name needs to
   assigned to the service host.  As an alternative, group key
   management protocol (GKMP) [31] can be adopted to resolved the issue
   above -- A naming service residing at LSG or IoT server (depending on
   application scope) generates a group public key that is used as group
   GUID for a service, then this group public/private keys pair is
   assigned to each Aggregator that host this service.  The service host
   Aggregator in the group then listen on this group GUID, and use the
   group private key to decrypt the incoming discovery message.
   Finally, we note that this form of secure service discovery is
   difficult for NDN.

4.4.  Context Processing and Storage

   In order to facilitate context-aware communication and data
   retrieval, we need to support context processing in the IoT system.
   The objective of context processing is to expose the sensor's low-
   level context information to upstream aggregators and LSGs, as well
   as to resolve the application's high-level context requirements using
   lower-level sensor contexts.  The context processing service usually
   runs on both aggregators and LSGs.

   Context processing requires the underlying network to be able to
   support in-network computing at both application and network levels.
   ICN inherently supports in-networking computing and caching, which
   thus offers unique advantages compared to traditional IP network
   where the support for in-network computing and caching is poor.

   Application level contexts differ from application to application,
   and therefore, we need to provide a set of basic mechanisms to
   support efficient context processing.  Firstly, the network needs to
   define a basic set of contextual attributes for devices (including
   sensors, aggregators, and LSGs), including device-level attributes
   (such as location, data type, battery level, etc), network-level
   attributes (such as ICN names), and service-level attributes (such as
   max, min, average, etc).

   Secondly, we need to have means to expose sensor/aggregator/LSG
   contextual attributes to the rest of the system, through centralized
   naming resolution service or distributed routing protocols.

   Thirdly, the IoT server needs to allow applications (either producers
   or consumers) to specify their contextual requirements.  Fourthly,
   the unconstrained part of ICN-IoT needs to be able to map the higher-
   level application-specific contextual requirements to lower-level
   device-level and network-level contextual information.



Zhang, et al.            Expires January 8, 2017               [Page 15]


Internet-Draft       ICN based Architecture for IoT            July 2016


4.5.  Publish-Subscribe Management

   Data Publish/Subscribe (Pub/Sub) is an important function for ICN-
   IoT, and is responsible for IoT information resource sharing and
   management.  The objective of pub/sub system is to provide
   centralized membership management service.  Efficient pub/sub
   management poses two main requirements to the underlying system: high
   data availability and low network bandwidth consumption.

   In conventional IP network, most of the IoT platforms provide a
   centralized server to aggregate all IoT service and data.  While this
   centralized architecture ensures high availability, it scales poorly
   and has high bandwidth consumption due to high volume of control/data
   exchange, and poor support of multicast.

   Next we consider two decentralized pub/sub models.  The first one is
   the Rendezvous mode that is commonly used for today's pub/sub
   servers, and the second one involves Data-Control separation that is
   unique to ICN networks where the control messages are handled by the
   centralized IoT server and the data messages are handled by the
   underlying ICN network.  Compared to the popular Rendezvous mode
   where both control and data messages both meet at the centralized
   server, separating data and control messages can greatly improve the
   scalability of the entire system, which is enabled by the ICN
   network.

   In today's IP network, Rendezvous mode is the classic pub/sub scheme
   in which data and requests meet at an intermediate node.  In this
   case the role of the IoT server is only required to authenticate the
   consumers and providing it Rendezvous service ID.

   While NDN is a Pull-based architecture without supporting the Pub/Sub
   mode naturally, COPSS [13] proposes a solution to fix this problem.
   It integrates a push based multicast feature with the pull based NDN
   architecture at the network layer by introducing Rendezvous Node(RN).
   RN is a network layer logical entity that resides in a subset of NDN
   nodes.  The publisher first forwards a Content Descriptor (CD) as a
   snapshot to the RN.  RN maintains a subscription table, and receives
   the subscription message from subscriber.  The data publisher just
   sends the content using Publish packet by looking up FIB instead of
   PIT.  If the same content prefix is requested by multiple
   subscribers, RN will deliver one copy of content downstream, which
   reduces the bandwidth consumption substantially.

   Compared with the Rendezvous mode in which data plane and control
   plane both reside on the same ICN network layer, we consider an
   architecture where the control message is handled by the centralized
   server while data is handled by ICN network layer.  Following the



Zhang, et al.            Expires January 8, 2017               [Page 16]


Internet-Draft       ICN based Architecture for IoT            July 2016


   naming process mentioned above, the LSG has the ICN name for the
   local resource which is available for publishing on IoT server.  IoT
   server maintains the subscription membership, and receives
   subscription requests from subscribers.  Since the subscribers has no
   knowledge about the number of resource providers and their identities
   in a dynamic scenario, IoT server has to take responsibility of
   grouping and assigning group name for the resource.

   MF takes advantage of Group-GUID to identify a service provided by
   multiple resources.  This Group-GUID will be distributed to the
   subscriber as well as the publisher.  In an example of NDN, it uses
   the common prefix/home/monitoring/ to identify a group of resource
   that provides multiple monitoring services such as /home/monitoring/
   temperature and /home/monitoring/light.  The subscriber retrieves the
   prefix from the IoT server, and sends Interest toward the resource.
   In a MF example, GUID-x identifies the "home monitoring" service that
   combines with "light status" and "temperature".  The resource
   producers, i.e. the host of "temperature" and the host of "light
   status" are notified that their services belong to GUID-x, then
   listen on GUID-x.  The subscriber sends the request containing GUID-x
   through multicasting which ultimately reach the producers at the last
   common node.  Once receiving the request, the resource producer
   unicasts the data to the subscriber.  In addition, if multiple
   resource consumers subscribe to the same resource, the idea of Group-
   GUID can be reused to group the consumers to further save bandwidth
   using multicast.

   With a pub/sub framework, important considerations should be given
   towards user registration and content distribution.

   User Registration: A user, who wants to access/subscribe to a
   service, has to perform the registration operation by sending
   information that depends on the specific application domain to the
   IoT server.  The information can be secured with the help of the PKI
   infrastructure.  Upon successful registration the IoT server securely
   transmits an identifier, a user signature key SK_{user} (to be used
   to sign messages), a user encryption key EK_{user} (to communicate
   data confidentially), and an access password to the user in an
   encrypted message.  Upon reception of the message, the user accesses
   the system to modify his/her password (function changePassword).
   With respect to existing secure application-layer solutions, a
   further benefit of the presented approach is the introduction of a
   second level of security, represented by the use of a temporary
   password (immediately replaced) and a couple of keys (signature
   SK_{user} and encryption EK_{user}), which is well suited for the
   heterogeneous and distributed IoT environment.

   Content Distribution: In literature, there are some solutions able to



Zhang, et al.            Expires January 8, 2017               [Page 17]


Internet-Draft       ICN based Architecture for IoT            July 2016


   guarantee content security [8] [9].  In fact, the work presented in
   [8] aims to ensure a high availability of the cached data only to
   legitimate users.  The authors design a security framework for ICN
   able to deliver trusted content securely and efficiently to
   legitimate users/subscribers.  They assume that the content is
   encrypted by the content provider, either at the servers layer or in
   the content distribution network (if it is trusted), by means of a
   popular symmetric key encryption algorithm.  A group of contents may
   be encrypted using the same secret key.  The goal is to ensure that
   the encrypted content cannot be used by an entity that is not a
   legitimate user/customer.  The authors achieve this goal by
   guaranteeing that only a legitimate user can obtain the symmetric key
   to decrypt the content, whereas a fake or a revoked user cannot.  In
   this way, the framework does not require any user authentication, for
   example by an online server, each time a content is requested.
   Instead, Zhang et al. in [9] consider trust and security as built-in
   properties for future Internet architecture.  Leveraging the concept
   of named content in recently proposed information centric network,
   the authors propose a name-based trust and security protection
   mechanism.  Their scheme is built with identity-based cryptography
   (IBC), where the identity of a user or device can act as a public key
   string.  Uniquely, in named content network such as content-centric
   network (CCN), a content name or its prefixes can be used as a public
   identity, with which content integrity and authenticity can be
   achieved by means of IBC algorithms.  The trust of a content is
   seamlessly integrated with the verification of the content's
   integrity and authenticity with its name or prefix, instead of the
   public key certificate of its publisher.  In addition, flexible
   confidentiality protection is enabled between content publishers and
   consumers.  For scalable deployment purpose, they further propose to
   use a hybrid scheme combined with traditional public-key
   infrastructure (PKI) and IBC.  Taking in mind the available
   solutions, in our proposed method, the device sends to the aggregator
   its ICN name, its ID encrypted with its signature key SK_{device} and
   the data encrypted with its own action key AK_{device}, in order to
   guarantee confidentiality and integrity.  The action key AK_{device}
   has been distributed during the device discovery (see Section Device
   discovery).  The aggregator is able to decrypt the data using the
   corresponding action key AK_{device}, stored with the device ID, the
   signature key SK_{device} and the device ICN name obtained during the
   name service (see Section Name service), in particular the aggregator
   uses the device name for identifying the related action key
   AK_{device} (function contentDecryption).  Note that the data are
   encrypted only if it is required by the application domain (i.e.,
   some contexts may not have any security requirements - in this case
   the function contentDecryption is not applied).  As regards the
   content delivery towards a user who subscribes to a service, the ICN
   IoT server transmits to the user the data encrypted with the user



Zhang, et al.            Expires January 8, 2017               [Page 18]


Internet-Draft       ICN based Architecture for IoT            July 2016


   action key AK_{user} in order to guarantee security and privacy, if
   it is a requirement of the application domain.  The user decrypts the
   received data using his/her action key AK_{user}(function
   contentDecryption).  In such a situation, the services are treated as
   multiple-unicast ones, since the aggregator has to use different keys
   for different devices.  In order to address a multicast approach, a
   group signature key system may be adopted, as in MF approach.

4.6.  Security

   This spans across all the middleware functions.  Generally speaking,
   the security objective is to assure that the device that connects to
   the network should be authenticated, the provided services are
   authenticated and the data generated (through sensing or actuating)
   by both devices and services can be authenticated and kept privacy
   (if needed).  To be specific, we consider the approach to secure
   device discovery, naming service and service discovery, because other
   services, such as pub/sub management and context processing and
   storage, can be properly secured according to application-specific
   demands.

5.  Support to heterogeneous core networks

5.1.  Interoperability with IP legacy network

   Interoperability between the IP legacy network and ICN networks is an
   important property that the middleware must meet in order to ensure
   the co-existence and gradual migration from the today IP-based
   technologies and protocols.  This could provide a market strength to
   the deployment of the ICN technologies.  To this end, the Internames
   architecture [15][16] provides an embedded capability to manage
   different network domains (or realms), and to support legacy web
   applications and services.  In this sense, a crucial role is played
   by the Name Resolution Service (NRS), whose functionalities can
   decouple names from network locators as function of
   time/location/context/service, and provide ICN functionalities in IP
   networks.  By integrating these functionalities on appropriated nodes
   a distributed database is created to ease internet-working among
   heterogeneous protocol stacks in the core network.

5.2.  Named protocol bridge

   In an heterogeneous network, composed of different ICN networks and
   legacy IP-based networks, interoperability can be pursued, thanks to
   the name-to-name primitives.  To this end, a name-based protocol
   bridge could be deployed at different points of the heterogeneous
   core network so as to provide bridging functionalities at the border
   of different administered network domains.  In order to correctly



Zhang, et al.            Expires January 8, 2017               [Page 19]


Internet-Draft       ICN based Architecture for IoT            July 2016


   forward the message through the network, the NRS node could aid the
   name-based protocol bridge providing inter-domain routing
   functionalities.

5.3.  Inter-domain Management

   In heterogeneous networks the IoT server has to strictly cooperate
   with the NRS nodes in the core network in order to build a virtual
   network topology to efficiently support Req/Res and Pub/Sub
   functionalities.  The IoT Server could provide the names of the
   internal resources to the NRS, so that when the internal network
   changes, hence the connectivity to the resources.  This ensures that
   the NRS database is always synchronized and updated with every IoT
   subsystems.  In order to support Req/Res and Pub/Sub services
   management efficiently in an heterogeneous core network, the IoT
   Servers of the different administered domains have to strictly
   cooperate with the NRS nodes in the core network.  This is to provide
   internal information of their own administered domain, such as the
   names and or the locators of the internal resources.  When the
   internal network changes, the status of the resources are synced in
   order to maintain an accurate database of the virtual network
   topology view comprising of various IoT subsystems.

6.  Informative References

   [1]        Grassi, G., Pesavento, D., and Giovanni. Pau, "VANET via
              Named Data Networking.", IEEE Conference on Computer
              Communications Workshops (INFOCOM WKSHPS) , 2014.

   [2]        ICN based Architecture for IoT - Requirements and
              Challenges, ICN-IoT., "https://tools.ietf.org/html/draft-
              zhang-icnrg-icniot-requirements-01", IETF/ICNRG 2015.

   [3]        Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content
              Broadcast Efficiency in Routers with Integrated Caching.",
              Proceedings of the IEEE Symposium on Computers and
              Communications (ISCC) , 2011.

   [4]        NSF FIA project, MobilityFirst.,
              "http://www.nets-fia.net/", 2010.

   [5]        NSF FIA project, NDN., "http://named-data.net/", 2010.

   [6]        Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and
              G. Wang, "Information-centric Networking based Homenet",
              ACM, Sigcomm, 2013.





Zhang, et al.            Expires January 8, 2017               [Page 20]


Internet-Draft       ICN based Architecture for IoT            July 2016


   [7]        Feng, Z., Mutka, M., and L. Ni, "Prudent Exposure: A
              private and user-centric service discovery protocol",
              Pervasive Computing and Communications, 2004, Proceedings
              of the Second IEEE Annual Conference on. IEEE, 2004.

   [8]        Misra, S., Tourani, R., and N. Majd, "Secure content
              delivery in information-centric networks: design,
              implementation, and analyses", Proceedings of the 3rd ACM
              SIGCOMM workshop on Information-centric networking. ACM,
              2013.

   [9]        Zhang, X., "Towards name-based trust and security for
              content-centric network", Network Protocols (ICNP), 2011
              19th IEEE International Conference on. IEEE, 2011.

   [10]       Nikander, P., Gurtov, A., and T. Henderson, "Host identity
              protocol (HIP): Connectivity, mobility, multi-homing,
              security, and privacy over IPv4 and IPv6 networks", IEEE
              Communications Surveys and Tutorials, pp: 186-204, 2010.

   [11]       Misra, S. and G. Xue, "Efficient anonymity schemes for
              clustered wireless sensor networks", International Journal
              of Sensor Networks, volume 1, number 1/2, pp: 50-63, 2006.

   [12]       Newsome, J., Shi, E., Song, DX., and A. Perrig, "The sybil
              attack in sensor networks: analysis and defenses", IEEE,
              IPSN, 2004.

   [13]       Jiachen, C., Mayutan, A., Lei, J., Xiaoming, Fu., and KK.
              Ramakrishnan, "COPSS: An efficient content oriented
              publish/subscribe system", ACM/IEEE ANCS, 2011.

   [14]       Marica, A., Campolo, C., and A. Molinaro, "Multi-source
              data retrieval in IoT via named data networking", ACM ICN
              Siggcomm, 2014.

   [15]       Blefari-Melazzi, A., Mayutan, A., Detti, A., and KK.
              Ramakrishnan, "Internames: a name-toname principle for the
              future Internet", Proc. of International Workshop on
              Quality, Reliability, and Security in Information-Centric
              Networking (Q-ICN), 2014.

   [16]       Piro, G., Signorello, S., Palatella, M., Grieco, L.,
              Boggia, G., and T. Engel, "Understanding the Social impact
              of ICN: between myth and reality", AI Society: Journal of
              Knowledge, Culture and Communication, Springer, pp. 1-9,
              2016.




Zhang, et al.            Expires January 8, 2017               [Page 21]


Internet-Draft       ICN based Architecture for IoT            July 2016


   [17]       Nelson, S., Bhanage, G., and D. Raychaudhuri, ""GSTAR:
              generalized storage-aware routing for mobilityfirst in the
              future mobile internet", Proceedings of the sixth
              international workshop on MobiArch, pp. 19--24, 2011.

Authors' Addresses

   Prof.Yanyong Zhang
   WINLAB, Rutgers University
   671, U.S 1
   North Brunswick, NJ  08902
   USA

   Email: yyzhang@winlab.rutgers.edu


   Prof. Dipankar Raychadhuri
   WINLAB, Rutgers University
   671, U.S 1
   North Brunswick, NJ  08902
   USA

   Email: ray@winlab.rutgers.edu


   Prof. Luigi Alfredo Grieco
   Politecnico di Bari (DEI)
   671, U.S 1
   Via Orabona 4, Bari  70125
   Italy

   Email: alfredo.grieco@poliba.it


   Sicari Sabrina
   Universita degli studi dell Insubria
   Via Mazzini 5
   Varese, VA  21100
   Italy

   Email: sabrina.sicari@uninsubria.it










Zhang, et al.            Expires January 8, 2017               [Page 22]


Internet-Draft       ICN based Architecture for IoT            July 2016


   Hang Liu
   The Catholic University of America
   620 Michigan Ave., N.E.
   Washington, DC  20064
   USA

   Email: liuh@cua.edu


   Satyajayant Misra
   New Mexico State University
   1780 E University Ave
   Las Cruces, NM  88003
   USA

   Email: misra@cs.nmsu.edu


   Ravi Ravindran
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: ravi.ravindran@huawei.com


   G.Q.Wang
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: gq.wang@huawei.com

















Zhang, et al.            Expires January 8, 2017               [Page 23]