One document matched: draft-zhang-icnrg-icniot-architecture-00.txt
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-icniot-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]
| PAFTECH AB 2003-2026 | 2026-04-24 10:52:44 |