[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

ICN Research Group                                           A. Lindgren
Internet-Draft                                          F. Ben Abdesslem
Intended status: Experimental                                       SICS
Expires: January 5, 2015                                      O. Schelen
                                          Lulea University of Technology
                                                                A. Malik
                                                              B. Ahlgren
                                                            July 4, 2014

   Applicability and Tradeoffs of Information-Centric Networking for
                             Efficient IoT


   This document outlines the tradeoffs involved in utilizing
   Information Centric Networking (ICN) for the Internet of Things (IoT)
   scenarios.  It describes the contexts and applications where the IoT
   would benefit from ICN, and where a host-centric approach would be
   better.  The requirements imposed by the heterogeneous nature of IoT
   networks are discussed (e.g., in terms of connectivity, power
   availability, computational and storage capacity).  Design choices
   are then proposed for an IoT architecture to handle these
   requirements, while providing efficiency and scalability.  An
   objective is to not require any IoT specific changes of the ICN
   architecture per se, but we do indicate some potential modifications
   of ICN that would improve efficiency and scalability for IoT and
   other applications.

   This document mainly serves as a problem statement and will not
   present a conclusive architecture design.  It can be used as a basis
   for further discussion and to design architectures for the IoT.

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

Lindgren, et al.         Expires January 5, 2015                [Page 1]

Internet-Draft            ICN for Efficient IoT                July 2014

   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 5, 2015.

Copyright Notice

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

Lindgren, et al.         Expires January 5, 2015                [Page 2]

Internet-Draft            ICN for Efficient IoT                July 2014

Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Advantages of ICN Principles for IoT . . . . . . . . . . . . .  5
     2.1.  Naming of Devices, Data and Services . . . . . . . . . . .  5
     2.2.  Distributed Caching  . . . . . . . . . . . . . . . . . . .  5
     2.3.  Decoupling between Sender and Receiver . . . . . . . . . .  5
   3.  Design Challenges of IoT over ICN  . . . . . . . . . . . . . .  7
     3.1.  Naming of Devices, Data and Services . . . . . . . . . . .  7
     3.2.  Efficiency of Distributed Caching  . . . . . . . . . . . .  8
     3.3.  Decoupling between Sender and Receiver . . . . . . . . . .  9
   4.  Proposed Design Choices for IoT over ICN . . . . . . . . . . . 10
     4.1.  Existing Internet protocols  . . . . . . . . . . . . . . . 10
     4.2.  Data naming, format and composition  . . . . . . . . . . . 10
     4.3.  Immutable atomic data units  . . . . . . . . . . . . . . . 11
     4.4.  The importance of time . . . . . . . . . . . . . . . . . . 12
     4.5.  Decoupling and roles of senders and receivers  . . . . . . 12
     4.6.  Combination of PULL/PUSH model . . . . . . . . . . . . . . 13
     4.7.  Capability advertisements  . . . . . . . . . . . . . . . . 14
     4.8.  Name-based routing vs name resolution + 1-step vs
           2-step . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.9.  What's naming and what's searching . . . . . . . . . . . . 14
     4.10. Tagging/tracing of data, and partial data  . . . . . . . . 15
   5.  Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Security Considerations  . . . . . . . . . . . . . . . . . 16
       5.1.1.  Retrieving trusted content from several caches . . . . 16
       5.1.2.  Enabling application-layer processing in untrusted
               intermediaries . . . . . . . . . . . . . . . . . . . . 17
       5.1.3.  Energy efficiency of cryptographic mechanisms  . . . . 17
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Lindgren, et al.         Expires January 5, 2015                [Page 3]

Internet-Draft            ICN for Efficient IoT                July 2014

1.  Motivation

   Information Centric Networking (ICN) has been shown to efficiently
   meet current usage demands of computer networks, where users consume
   content from the network instead of communicating with specific
   hosts.  The applications and usage of the Internet of Things (IoT)
   often imply information centric usage patterns, where users or
   devices consume IoT generated content from the network instead of
   communicating with specific hosts or devices.

   However, while the IoT shares many characteristics with typical
   information centric applications, it differs because of the high
   heterogeneity of connected devices, including mainly sensors and
   actuators, leading to different applications and usage.  Because of
   these differences, applying an ICN approach to design the
   architecture of the IoT is often, but not always, beneficial.
   Depending on the context, the IoT architecture should follow an ICN
   approach, or a host-centric approach.  In practice, the right
   approach is a complex tradeoff that depends on the applications and
   usage of the IoT network.  This document describes some advantages
   and inconveniences of using an ICN architecture for the IoT, and
   helps finding the right tradeoff between an ICN and host-centric
   approach, depending on the context.

Lindgren, et al.         Expires January 5, 2015                [Page 4]

Internet-Draft            ICN for Efficient IoT                July 2014

2.  Advantages of ICN Principles for IoT

   A key concept of ICN is the ability to name data independently from
   the current location at which it is stored, which simplifies caching
   and enables decoupling of sender and receiver.  Using ICN concepts to
   design an architecture for IoT networks potentially provides these
   advantages compared to using traditional host-centric architecture.
   This section highlights general benefits an ICN architecture could
   provide to IoT networks in optimal contexts such as application's
   type, usage pattern, or network scale.  Benefiting from the
   advantages described hereafter can only happen when taking into
   account the right tradeoff depending on the context, which will be
   discussed in the following section.

2.1.  Naming of Devices, Data and Services

   The heterogeneity of both network equipment deployed and services
   offered by IoT networks leads to a large variety of data, services
   and devices.  While using a traditional host-centric architecture,
   only devices or their network interfaces are named at the network
   level, leaving to the application layer the task to name data and
   services.  In many common applications of IoT networks, data and
   services are the main goal, and specific communication between two
   devices is secondary.  The network distributes content and provides a
   service, instead of establishing a communication link between two
   devices.  In this context, data content and services can be provided
   by several devices, or group of devices, hence naming data and
   services is often more important than naming the devices.

2.2.  Distributed Caching

   While caching mechanisms are already used by other types of overlay
   networks, IoT networks can potentially benefit even more from caching
   systems, because of their resource constraints.  Wireless bandwidth
   and power supply can be limited for multiple devices sharing a
   communication channel, and for small mobile devices powered by
   batteries.  In this case, avoiding unnecessary transmissions with IoT
   devices to retrieve and distribute IoT data to multiple places is
   important, and storing such content in the network can save wireless
   bandwidth and battery power.  Moreover, as for other types of
   networks, applications for IoT networks requiring shorter delays can
   benefit from local caches to reduce delays between content request
   and delivery.

2.3.  Decoupling between Sender and Receiver

   IoT devices may be mobile and face intermittent network connectivity.
   When specific data is requested, such data can often be delivered by

Lindgren, et al.         Expires January 5, 2015                [Page 5]

Internet-Draft            ICN for Efficient IoT                July 2014

   ICN without any consistent direct connectivity between devices.
   Apart from using structured caching systems as described previously,
   information can also be spread by forwarding data opportunistically.

Lindgren, et al.         Expires January 5, 2015                [Page 6]

Internet-Draft            ICN for Efficient IoT                July 2014

3.  Design Challenges of IoT over ICN

   As outlined in Section 2, there are potential benefits from using ICN
   to implement IoT communication architectures.  However, in order to
   obtain a scalable and efficient architecture there are some aspects
   of ICN that must be specifically considered in making the right
   design choices for IoT.  In fact, using an ICN approach may not be
   beneficial in all desired sub-functions and scenarios.  This section
   outlines some of the ICN specific challenges that must be considered
   and describes some of the trade offs that will be involved.  We will
   address these challenges in our proposed design choices later in
   Section 4.

3.1.  Naming of Devices, Data and Services

   Naming devices is a common element of both ICN and host-centric
   approaches.  However, naming devices in the IoT raises different
   challenges that have to be addressed if an ICN approach is adopted.
   As for data and services, naming them in the network layer is proper
   to the ICN approach, and has to be designed carefully, depending on
   the context.

   o  Naming of devices: Naming devices is often important when using an
      ICN approach in an IoT network.  The presence of actuators
      requires clients to act specifically on a device, e.g. to switch
      it off.  Also, managing and monitoring the devices for
      administration purposes requires devices to have a specific name
      allowing to identify them uniquely.  There are multiple ways to
      achieve device naming, even in systems that are data centric by
      nature.  For example, in systems that are adressable or searchable
      based on metadata or sensor content, the device identifier can be
      included as a special kind of metadata or sensor reading.

   o  Size of data/service name: In information centric applications,
      the size of the data is often larger than its name.  For the IoT,
      sensors and actuators are very common, and they can generate data
      as small as a short integer containing a temperature value, or a
      one-byte instruction to switch off an actuator.  The name of the
      content for each of these pieces of data has to uniquely identify
      the content.  For this reason, many existing naming schemes have
      long names that are likely to be longer than the actual data
      content for many types of IoT applications.  Furthermore, naming
      schemes that have self certifying properties (e.g., by creating
      the name based on a hash of the content), suffer from the problem
      that the object can only be requested when the object has been
      created and the content is already known, thus requiring some form
      of indexing service.  While this is an acceptable overhead for
      larger data objects, it is infeasible for use when the object size

Lindgren, et al.         Expires January 5, 2015                [Page 7]

Internet-Draft            ICN for Efficient IoT                July 2014

      is on the order of a few bytes.

   o  Hash-based content name: Hash algorithms are commonly used to name
      content in order to verify that the content is the one requested.
      This is only possible in contexts where the requested object is
      already existing, and where there is a directory service to look
      up names.  This approach is suitable for systems with large data
      objects where it is important to verify the content.

   o  Metadata-based content name: Relying on metadata allows to
      generate a name for an object before it is created.  However this
      mechanism requires metadata matching semantics.

   o  Naming of services: Similarly to naming of devices or data,
      services can be referred to with a unique identifier, provided by
      a specific device or by someone assigned by a central authority as
      the service provider.  It can however also be a service provided
      by anyone meeting some certain metadata conditions.  Example of
      services include content retrieval, that takes a content name/
      description as input and returns the value of that content, and
      actuation, that takes an actuation command as input and possibly
      returns a status code afterwards.

3.2.  Efficiency of Distributed Caching

   Distributed caching is a key opportunity with ICN.  However, an IoT
   framework must be carefully designed to reap the maximum benefits of
   ICN caching.  When content popularity is heterogeneous, some content
   is often requested repeatedly.  In that case, the network can benefit
   from caching.  Another case where caching would be beneficial is when
   devices with low duty cycle are present in the network and when
   access to the cloud infrastructure is limited.

   However, using distributed caching mechanisms in the network is not
   useful when each object is only requested at most once, as a cache
   hit can only occur for the second request and later.  It may also be
   less useful and less scalable to have the caches distributed
   throughout the network in cases when all content is frequently
   requested.  A better strategy in that case is to proactively send all
   data to central or distributed repositories (i.e., a central cache),
   possibly a cloud, from which all clients can retrieve the data,
   assuming the clients have good connectivity.  Another example is when
   the name of the object has a different meaning depending on the
   context.  For example, when the last value for a sensor reading is
   requested, the returned object will change every time the sensor
   reading is updated.  In this case, caching cannot be used, and naming
   this as a service is more appropriate.

Lindgren, et al.         Expires January 5, 2015                [Page 8]

Internet-Draft            ICN for Efficient IoT                July 2014

3.3.  Decoupling between Sender and Receiver

   Decoupling the sender and receiver is useful mechanism offered by the
   ICN approach, especially for content retrieval with duty cycling
   devices or devices with intermittent connectivity.  However, in order
   to efficiently retrieve data it must be possible for requestors
   (receivers) to easily deduce the name of the data to request, without
   any direct contact with the responder (sender).

   Nevertheless, this mechanism cannot be used when authentication is
   needed for management and actuation, or, of course, when real-time
   interaction between devices is necessary.

Lindgren, et al.         Expires January 5, 2015                [Page 9]

Internet-Draft            ICN for Efficient IoT                July 2014

4.  Proposed Design Choices for IoT over ICN

   This section describes some fundamental design choices and trade-offs
   to allow for effective, efficient and scalable handling of IoT data
   in an ICN network.  An objective with these choices is to facilitate
   that an ICN network can be used without requiring additions of IoT
   application specific functionality in the ICN network.  However, in
   some cases we do invite for discussion on tentative additions of
   functionality to ICN in order to make the overall IoT solution more
   efficient and scalable.

4.1.  Existing Internet protocols

   IoT devices can have a role as content generators (e.g., sensors) in
   where an ICN paradigm should be effective for data retrieval and
   dissemination.  However, IoT devices may also have roles as actuators
   in which such devices shall be accessed for control purposes.  The
   use of an ICN network may be less natural when actuation and control
   of specific devices is the key objective.  To facilitate support of
   IoT for both data generation and control/actuation, we assume that
   there is a need for existing internet protocols, and the ICN routing
   should therefore work in concert with existing Internet protocols.

4.2.  Data naming, format and composition

   The data served by ICN may be aggregated from smaller components.
   Although IoT data components in many cases are small and simple, a
   general challenge in defining ICN applications is to decide how to
   compose (i.e. group) the data so that it can be effectively named and
   requested.  Requesting partial data inside a composition may become a
   challenge.  Indeed, if data is composed and sub components are
   requested, which are not directly namable by the requestor, finding
   such a subset will resemble a database query which may require
   processing to resolve.  The ICN network should not have to support
   such complexity.

   A design choice regarding IoT data is therefore to keep the ICN
   network free from supporting any advanced queries and instead only
   support directly addressable (i.e., named) data units.  Any advanced
   composition (hierarchical, graph-based, hyperlink, etc.) of IoT data,
   and related searching for sub-components, would be handled in
   servers/endpoints instead of inside the ICN network.  The issue of
   structure and searching is for further study.  For effective ICN
   interoperability, only the structure of the atomic addressable data
   units must be agreed.  There are several advantages of this design
   choice.  First, the size of the directly addressable units can be
   kept fairly small to avoid that unwanted bulk data is pulled over
   resource constrained networks or spread over various caches in the

Lindgren, et al.         Expires January 5, 2015               [Page 10]

Internet-Draft            ICN for Efficient IoT                July 2014

   ICN network.  This results in better resource utilization, better
   localization of desired data, and ultimately better scalability.
   There is however one tradeoff in that smaller data units results in a
   larger overhead.  Second, the computational requirement is kept low
   in the ICN network, essentially limiting it to deciding whether there
   is a cache hit or not.  Third, few new requirements are put on ICN
   data dissemination.  Existing methods will be sufficient.  Fourth,
   this simplification means that a flat address space would be
   sufficient, but for practical reasons a hierarchical address space
   may be preferred.  There is flexibility in the choice of exact
   addressing scheme and it may depend on which existing ICN framework
   that is used for IoT data.

4.3.  Immutable atomic data units

   The number of IoT devices as well as the amount of data produced by
   these devices may potentially be very large, and the data may be
   spread over very large ICN networks.  The potential problem of cache
   inconsistencies in an ICN network may therefore be large if we allow
   for data to be mutable objects.  To support scalability and
   horizontal distribution it is essential to define data properties
   that facilitate independency and consistency, while minimizing the
   need for dynamic global synchronization.

   A key design choice is therefore to mandate that IoT only uses
   immutable atomic data units.  This supports large scale distribution
   by ensuring that there is no stale data in the ICN domain.  A hit is
   always a clean hit.  A trade-off from this is that dynamic data must
   be modeled as a stream of immutable data units, potentially consuming
   more resources.  However, this challenge can be resolved by smart
   caching strategies where old data is dropped.  A client that wants
   the "latest" reading can according to our previously mentioned design
   choice, in Section 4.2, not ask the ICN network such a high level
   query, instead it must ask for the specific (version of) information.
   There are several methods for finding the latest version, for example
   through a high level request from a server/endpoint, or by using a
   naming scheme where the name can be directly inferred, e.g., if an
   IoT device has advertised that it produces data every whole second,
   the named data can include absolute time and therefore data from the
   current second can be requested (provided that clock synchronisation
   is accurate enough, which is out of scope of this document).  These
   methods are based on the request/pull method.  For real-time update
   (most accurate info), there is also an option to use dissemination
   based on the push model as described later in Section 4.6.

Lindgren, et al.         Expires January 5, 2015               [Page 11]

Internet-Draft            ICN for Efficient IoT                July 2014

4.4.  The importance of time

   In Section 4.3 we started to discuss the role of time in relation to
   immutable data.  We want to emphasize that time almost always is a
   very important property of IoT data, and especially so for data that
   change over time.  When modeling dynamic IoT data with a stream of
   immutable data, it is often the case that a certain IoT data object
   is a sensor reading at a particular point in time, and the next
   object in the stream is the next reading.  Thus, dynamic data is in
   this case dynamic over time, with well defined (immutable) values for
   particular points in time.

   We therefore argue that it is important to find a way to represent
   these time-related streams of immutable data.  It should be possible
   to request data from a certain time, and to infer/find the name of
   the latest, most current, data.  As mentioned in Section 4.3, an IoT
   device might advertise that it produces data at certain time
   intervals.  This information is also useful for the ICN network to be
   able to handle requests for the corresponding data in the most
   efficient manner.

   It is for further study whether any extensions are needed to the ICN
   paradigm, or if it can be supported with, e.g. clever use of
   metadata, namespace, and search functionality.  It may also depend on
   the particular flavor of ICN.  The naming scheme of CCN/NDN may here
   provide an advantage.

   We also note that time is also important for other applications, in
   particular for live streaming video.  Live video also produces a
   time-related stream of immutable objects, and would in the same way
   benefit from such support in the ICN service.

4.5.  Decoupling and roles of senders and receivers

   Since ICN networks essentially support a request/response model of
   interaction, we denote the receivers of information as requestors,
   and the senders of information as responders.  The ICN network in
   itself provides decoupling of requestors and responders, but it does
   not (and should not) provide any transformation or aggregation of
   data.  The IoT dissemination architecture should therefore allow for
   any number of intermediate processing nodes.  An intermediate node
   will be an endpoint in the ICN network that can act as both requestor
   and responder.  Such a node may perform aggregation, filtering,
   selection, etc.  The instantiation of such nodes may for example form
   a directed (acyclic) graph between ultimate responders (IoT devices)
   and ultimate requestors (the final applications).  It is for further
   study how to define such an architecture.

Lindgren, et al.         Expires January 5, 2015               [Page 12]

Internet-Draft            ICN for Efficient IoT                July 2014

   It is a design choice to keep the IoT dissemination and aggregation
   functionality outside of the ICN domain.  That architecture would be
   an overlay that may have intricate structure, and put the ICN usage
   in a new context, where content from ultimate requestors to ultimate
   responders may go through many IoT processing nodes that collect,
   process and re-publish data through an ICN for various purposes.

4.6.  Combination of PULL/PUSH model

   A critical decision regarding IoT data is whether to use a PULL
   model, a PUSH model, or both.  There are some intrinsic trade offs
   between these models.  The PULL model is for example resource
   efficient when there is an abundant amount of IoT information,
   potentially redundant from many devices, and the clients only
   occasionally or partially are interested in the information.  The
   PUSH model is for example efficient when there is real-time
   information and the clients are interested in all information from
   specific devices all the time.

   A design decision in the IoT domain is to support both PULL and PUSH.
   The base model should be PULL, meaning that requestors must always
   start by sending a request.  If the request is for some specific
   data, it can be resolved by returning the data (if it exists).  The
   pull model can be supported efficiently and scalably by an ICN
   network.  A request can however also include triggers, which means
   that data will be returned (pushed) when triggers are fulfilled,
   which may be immediately, or in the future at one or several
   occasions.  This can be used to select alarm conditions, to request
   continuous or periodic push, etc.  The trigger conditions can be set
   by the requestor, or be pre-defined by the responder.  The former is
   more flexible but may have performance/scalability issues.  The
   latter is more scalable since there will be a predefined and finite
   number of trigger conditions.  Our recommended choice, at least for
   the initial phase, is to go for a simple and scalable solution and
   therefore adopt the model where available trigger conditions are
   defined and advertised by the responder.  The ICN would be apt for
   supporting such capability advertisements, given that they are fairly

   We recommend to have a discussion on whether an ICN network can or
   should provide an option to effectively support a push model of data.
   Such support can make real-time IoT data dissemination more efficient
   and scalable as previously mentioned in Section 4.3.  However, since
   we assume that the ICN works with existing IP protocols, such
   functionality can be provided without ICN, by using traditional
   unicast or multicast communication.  We finally note that an ICN
   supported push service model would make the ICN network more like a
   publish/subscribe system.

Lindgren, et al.         Expires January 5, 2015               [Page 13]

Internet-Draft            ICN for Efficient IoT                July 2014

4.7.  Capability advertisements

   Capability advertisements and discovery can be used by requestors to
   discover which responders to connect to.  In a deployment with large
   numbers of responders, the functionality of automatic advertisement
   and discovery becomes a critical factor to support scaling.
   Responders should advertise their methods (inputs, outputs,
   parameters, triggers, etc) and provide relevant metadata.  Such
   capability advertisements should be conservative with resources,
   which suggests that new advertisements should be posted with
   reasonably low frequency.  This implies that an ICN network can be
   used for providing capability advertisements.  The advertisements
   should be provided as a stream of immutable objects, or alternatively
   the system should be tolerant to stale caches.  Should there be a
   need real-time awareness of dynamic changes, a push model of
   capability advertisements could be used as earlier described in
   Section 4.6.

4.8.  Name-based routing vs name resolution + 1-step vs 2-step

   As described in Section 4.2, the IoT framework should be defined so
   that new functionality in the ICN is not needed.  For data that is
   frequently generated and regenerated, it makes sense to keep simple
   structures and provide directly inferable naming/addressing of data
   objects, so that requestors can directly address the data.  For more
   complex data, such as pre-processed, aggregated and structured data a
   two-step resolution model is recommended.  The IoT devices can
   provide a higher level resolution based on for example queries and
   searching, resulting in a number of concrete directly addressable ICN
   objects.  This is similar to what web servers do when they return
   URLs that requestors can use, but in this case it is named content
   that is returned.

   Consequently, the IoT framework should have no requirement that the
   ICN network itself should support 2-step addressing (although such
   2-step methods may exist in some ICNs)

4.9.  What's naming and what's searching

   As described in Section 4.2, the IoT framework should be defined so
   that no new functionality is required in the ICN for searching data
   or subcomponents of data.  The ICN network supports just naming of
   atomic data objects, while any searching is provided by the IoT
   framework, which in itself may be constituted by a highly distributed
   set of nodes that provide processing, analysis and aggregation of IoT

Lindgren, et al.         Expires January 5, 2015               [Page 14]

Internet-Draft            ICN for Efficient IoT                July 2014

4.10.  Tagging/tracing of data, and partial data

   IoT data may be tagged with metadata to tell where it originates
   from.  Tagging is made at the level above the ICN network and may for
   example be a list of strings.  It can be added/changed by the
   originating node (or a node that assigns the originating ID), and
   added/changed/deleted by any node that processes the data.  The tag
   can in some cases be used to trace data back to origins.  For the ICN
   network, the metadata units are just black-box data that is to be
   conveyed, and therefore are not to modify the tags.  However, in some
   cases it makes no sense to transmit any metadata.  For efficiency
   reasons the ICN network should have support for optional delivery of
   metadata.  This is to be conservative with scarce resources, for
   example when a wireless node requests data which is cached in the ICN
   network, it would be beneficial if the requestor could tell that it
   is desirable to not receive any metadata.  There should be a
   discussion whether there should be just one, or more than one, piece
   of optional information in ICN content to be future proof.

Lindgren, et al.         Expires January 5, 2015               [Page 15]

Internet-Draft            ICN for Efficient IoT                July 2014

5.  Other Issues

5.1.  Security Considerations

   The ICN paradigm is content-centric as opposed to state-of-the-art
   host-centric internet.  Besides aspects like naming, content
   retrieval and caching this also has security implications.  ICN
   advocates the model of trust in content rather than trust in network
   hosts.  This brings in the concept of Object Security which is
   contrary to session-based security mechanisms such as TLS/DTLS
   prevalent in the current host-centric internet.

   Object Security is based on the idea of securing information objects
   unlike session-based security mechanisms which secure the
   communication channel between a pair of nodes.  This reinforces an
   inherent characteristic of ICN networks i.e. to decouple senders and
   receivers.  In the context of IoT, the Object Security model has
   several concrete advantages.  As discussed earlier in Section 2.1, in
   many IoT applications data and services are the main goal and
   specific communication between two devices is secondary.  Therefore
   it makes more sense to secure IoT objects instead of securing the
   session between communicating endpoints.

   It is important that while security mechanisms complement the ICN
   architecture in a coherent fashion, they do so without laying down
   any strict requirements or constraints.  Therefore, the decision of
   what security mechanisms are employed should be handled at a layer
   above ICN, in this case within the IoT framework.  This facilitates
   flexibility and allows IoT applications more freedom to decide what
   security mechanism suits them best (session-based security, object
   security or a hybrid).  Though the idea of Object Security is very
   much inline with the ICN concept, there can still be some use cases
   where Object Security does not add much e.g. a Pub/Sub interaction
   where a client is expected to interact more or less with the same
   server node (a session-based security protocol should suffice here)
   or use cases where application layer headers should also be secured
   (which can be achieved by TLS/DTLS).  We, therefore, effectively
   imply that there is no need to modify typical ICN standards to
   accommodate Object Security.

   The following sub-sections discuss some advantages of using Object
   Security in IoT applications.

5.1.1.  Retrieving trusted content from several caches

   When functioning in an ICN network, an IoT client is expected to rely
   on the network to deliver the requested content in an optimal fashion
   without concerning itself with where the content actually lies.  This

Lindgren, et al.         Expires January 5, 2015               [Page 16]

Internet-Draft            ICN for Efficient IoT                July 2014

   could potentially mean that each individual object within a stream of
   immutable objects is retrieved from a different source.  Having a
   trust relationship with each of these different sources is not
   realistic.  This gives rise to the need of retrieving trusted content
   from untrusted nodes/caches in an ICN network.  Object security is
   ideal in such use cases because it relieves an IoT client application
   from the hassle of having to establish trust with each node that can
   potentially cache an IoT object.  This also means that a requesting
   client can make use of more caches in the network, hence resulting in
   better throughput and latency.

5.1.2.  Enabling application-layer processing in untrusted

   Object Security ensures that objects in application-layer payload are
   secure e.g.  XML, JSON objects.  However, the application-layer
   header is unencrypted and available for processing.  Securing content
   at the object level means greater granularity.  This facilitates
   application-layer processing in untrusted intermediary nodes (e.g.
   proxies and caches) without compromising security.  An example use
   case is untrusted caching nodes that should have the ability to cache
   individual encrypted objects without being able to see what is there
   in those objects.  In this case there is a need for the caching nodes
   to identify the object URI which can be done by looking into the
   application-layer header.  But the object is still encrypted and
   unknown to the caching nodes.

5.1.3.  Energy efficiency of cryptographic mechanisms

   Session-based security protocols rely on the exchange of several
   messages before a secure session is established between a pair of
   nodes.  Use of such protocols in constrained IoT devices can have
   serious consequences in terms of power efficiency because in most
   cases transmission and reception of messages is more costly than the
   cryptographic operations.  This is especially true for wireless
   devices.  The problem is amplified even further when the constrained
   device is interacting with a number of caching nodes because the
   device will have to setup a secure session with each caching node.
   The Object Security model eliminates this problem because the content
   is readily available in a secure state in the network.  IoT devices
   producing data can secure it w.r.t. all the intended consumers and
   start transmitting it right away.

Lindgren, et al.         Expires January 5, 2015               [Page 17]

Internet-Draft            ICN for Efficient IoT                July 2014

6.  Informative References

              Vahdat, A. and D. Becker, "Epidemic Routing for Partially
              Connected Ad Hoc Networks", Duke University Technical
              Report CS-200006, April 2000.

Lindgren, et al.         Expires January 5, 2015               [Page 18]

Internet-Draft            ICN for Efficient IoT                July 2014

Authors' Addresses

   Anders F. Lindgren
   SICS Swedish ICT
   Box 1263
   Kista  SE-164 29

   Phone: +46707177269
   Email: andersl@sics.se
   URI:   http://www.sics.se/~andersl

   Fehmi Ben Abdesslem
   SICS Swedish ICT
   Box 1263
   Kista  SE-164 29

   Phone: +46705470642
   Email: fehmi@sics.se
   URI:   http://www.sics.se/~fehmi

   Olov Schelen
   Lulea University of Technology
   Lulea  SE-971 87

   Email: olov.schelen@ltu.se

   Adeel Mohammad Malik
   Kista  SE-164 80

   Phone: +46725074492
   Email: adeel.mohammad.malik@ericsson.com

Lindgren, et al.         Expires January 5, 2015               [Page 19]

Internet-Draft            ICN for Efficient IoT                July 2014

   Bengt Ahlgren
   SICS Swedish ICT
   Box 1263
   Kista  SE-164 29

   Phone: +46703141562
   Email: bengta@sics.se
   URI:   http://www.sics.se/people/bengt-ahlgren

Lindgren, et al.         Expires January 5, 2015               [Page 20]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/