Architectural Considerations with Smart Objects and Software Updates
slides-iotsuws-architectural-considerations-with-smart-objects-and-software-updates-00

Internet Engineering Task Force                                 J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                              May 31, 2016
Expires: December 2, 2016


  Architectural Considerations with Smart Objects and Software Updates
                      draft-arkko-iotsu-arch-cons

Abstract

   There are many security concerns around embedding communications and
   computing technology to various real-world objects.  Such objects are
   commonly referred to as the "Internet of Things".

   One specific remedy for some of the security concerns lies in the
   ability to update software in the computers embedded in other
   objects.  This seemingly simple function is surprisingly complicated,
   when one takes into account the many technical, cryptographic,
   business and even legal factors that will be discussed in the IAB IOT
   Software Update Workshop (IOTSU).

   This paper does not address those factors directly, but discusses a
   number of architectural concerns and tradeoffs that have been
   inspired by thinking about the factors and designs for software
   updates.

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 December 2, 2016.








Arkko                   Expires December 2, 2016                [Page 1]

Internet-Draft      Software Updates and Architecture           May 2016


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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  On the Nature of Things . . . . . . . . . . . . . . . . . . .   3
   3.  Designs Patterns for Smart Object Systems . . . . . . . . . .   4
   4.  Design Tradeoffs for Software Updates . . . . . . . . . . . .   4
   5.  Data and Protocols  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Building for Change . . . . . . . . . . . . . . . . . . . . .   6
   7.  Non-Technical Factors . . . . . . . . . . . . . . . . . . . .   6
   8.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   There are many security concerns around embedding communications and
   computing technology to various real-world objects.  Such objects are
   commonly referred to as the "Internet of Things", although this a
   term does little justice to a very broad trend of increasingly
   computer-driven processes.  Also, with the exception of
   virtualisation technologies, traditional Internet hosts are tangible
   objects and could equally be called "Things".  But we digress.

   One specific remedy for some of the security concerns lies in the
   ability to update software in the computers embedded in other
   objects.  This seemingly simple function is surprisingly complicated,
   when one takes into account the many technical, cryptographic,
   business and even legal factors that will be discussed in the IAB IOT
   Software Update Workshop (IOTSU) [IOTSU].

   The most obvious complications to us engineers relate to small
   devices.  The devices have limited available bandwidth, and may also



Arkko                   Expires December 2, 2016                [Page 2]

Internet-Draft      Software Updates and Architecture           May 2016


   be otherwise constrained [RFC7228].  There are also obvious
   difficulties in designing sound cryptographic software update
   solutions in the face of many different potential attacks (such as
   those involving attackers gaining physical access to a device and
   using it to attack the software update process in others).

   But there are other complications related to, for instance, to who
   controls software updates, such as the ability of manufacturers to
   "brick" devices or users to supply their own software long after
   support for a device has stopped [IAB-FCC].

   This paper does not address the complicating factors directly, but
   discusses a number of architectural concerns and tradeoffs that have
   been inspired by the author thinking about the factors and designs
   for software updates.

2.  On the Nature of Things

   Many smart object technology discussions focus on the devices as the
   most visible aspect of the technology.  But the devices are not
   everything.  The concept of a communicating, smart object itself
   implies that it communicates with others.

   There are cases such as lightbulbs and switches, where such
   communication can and perhaps should happen directly within user-
   observable objects.  Lighting systems often have additional
   components such as controllers, though.  But more generally, a large
   fraction of smart devices communicate even more broadly, and big
   parts of the functionality reside in the cloud, web user-interfaces,
   smartphone applications, and so on.

   For the purposes of the software updates, this is a key observation:

      The Internet of Things is not in the things

   Rather, smart applications relating to physical objects are
   distributed systems spanning multiple widely different platforms.
   These systems also often cross ownership and administrative
   boundaries, such as objects owned by the end-user and servers run by
   manufacturer.

   With this picture in mind, it may become easier to talk about some of
   the challenges involved in controlling, evolving, and updating these
   systems.







Arkko                   Expires December 2, 2016                [Page 3]

Internet-Draft      Software Updates and Architecture           May 2016


3.  Designs Patterns for Smart Object Systems

   [RFC7452]discusses a number typical architectures for building smart
   object systems.  These include the Device-to-Device, Device-to-Cloud,
   Device-to-Gateway, and the Back-End-Data-Sharing design patterns.
   These patterns have different characteristics and can also be
   combined in various ways.

   A key issue discussed in RFC 7452 was to ensure interoperability,
   enable different components to evolve in different ways, allow users
   to choose what cloud services they employ, and to enable
   interconnection of different systems.

   [I-D.garcia-core-security] discusses security of IP-based smart
   object systems.  It explains the lifecycle that the objects typically
   go through, including software update processes and security
   bootstrapping processes.

4.  Design Tradeoffs for Software Updates

   The architecture has also an impact on what software updates do.  An
   obvious architectural choice is between the following:

   1.  Thick Devices

      Placing as much functionality as possible within the devices.

   2.  Thin Devices

      Placing as much functionality outside the devices as possible.
      For instance, functionality can be placed in gateways,
      controllers, or cloud systems.

   Cloud systems are much easier to evolve and are in direct control of
   a manufacturer or operator.  Gateways are likely to have capabilities
   similar to general-purpose computers, in that access and management
   of software updates can be done easily.

   As a result, traditional, well-understood update mechanisms and
   system performance tracking can easily be applied in both cloud and
   gateway systems.  This would seem to speak in favour of keeping
   functionality largely outside the devices, perhaps following the
   "Device-to-Cloud Communication" design pattern from RFC 7452.

   However, this is a tradeoff with regards to other effects of such a
   design -- such as the need for the devices to be connected to the
   gateway or cloud component, possibly over the Internet.  This is
   quite reasonable for many applications, but not all.  An example of



Arkko                   Expires December 2, 2016                [Page 4]

Internet-Draft      Software Updates and Architecture           May 2016


   an application where an Internet connection requirement would likely
   be inappropriate is light control within a building.

   There is another issue in binding devices to specific backend or
   cloud systems.  RFC 7452 recommends the following:

      Similarly, in many situations it is desirable to change which
      cloud service a device connects to, such as when an application
      service provider changes its hosting provider.

   RFC 7452 stated this mainly for the purpose of allowing users to
   control how their information is used, and the ability to
   competitively bid for services.  But there's a software update angle
   as well: the ability to change the cloud service component allows
   users to update and continue to use a system that is no longer being
   updated or supported by its original creators.

   In any case, a device with relatively little functionality -- a
   sensor with just the basic ability to send readings, for instance --
   would be less likely to need software updates to begin with, than a
   fully-featured device that runs actual application logic.

   Nevertheless, even simple devices do need some software updates.  An
   implementation of most layer 2 radio systems is complicated, and
   building a full internetworking stack with transport protocols,
   security toolkits, and application frameworks is also complicated.
   Implementations of these are likely to contain bugs that need updates
   as they are discovered.

5.  Data and Protocols

   A distributed system only loosely controlled from any point will have
   obvious challenges with respect to evolving its functionality.

   An obvious key issue whether the communication protocols between
   devices are stable, or perhaps standardised.  Similarly, changes to
   data that is either communicated or at rest on a server are
   potentially very disruptive unless properly managed.

   An ability to version protocols and data, and the ability make
   statements (perhaps as part of various meta-level descriptions) about
   them is important.  Such statements help the building of applications
   from complex and evolving parts.








Arkko                   Expires December 2, 2016                [Page 5]

Internet-Draft      Software Updates and Architecture           May 2016


6.  Building for Change

   Another benefit of providing relatively little functionality in the
   devices themselves is that small, simple components are easier used
   by multiple different applications.  As RFC 7452 notes:

      Tight Coupling

         Many applications are built around a specific set of servers,
         devices, and users.  However, often the same data and devices
         could be useful for many purposes, some of which may not be
         easily identifiable at the time the devices are deployed.

   As noted by Clark et al [TUSSLES] it is useful to break complex
   systems into modular parts, so that one tussle does not spill over
   and distort unrelated issues.

   The software update angle is that clearly defined roles and reusable
   components allow majority of components to stay unchanged when, for
   instance, the web user interface towards user changes.

7.  Non-Technical Factors

   Another set of factors is non-technical, such as business models.
   The role of device sales within a business model may affect decisions
   around placement of functionality within the system, as well as the
   availability of newer functionality for older devices.

   Similarly, warranties, warranty legislation, and the need to avoid
   obsolete devices from being hijacked may have implications for update
   processes.  While these issues do not specifically affect
   architectural decisions directly, it is clear that there needs to be
   an explicit design for the "long lifetime" aspects of smart object
   systems.  One possible architectural impact is the need for high
   amount of control over devices, to implement features such as making
   obsolete devices safe, or to hand off the control of updates to users
   or groups of users.

8.  Conclusions

   The key observations in this paper are:

   o  There is a tradeoff between device-focused and system-focused or
      cloud-focused architectures.  The former can be more easily free-
      standing and within the user's control, whereas the latter are
      easier to update and evolve.





Arkko                   Expires December 2, 2016                [Page 6]

Internet-Draft      Software Updates and Architecture           May 2016


   o  Building devices as simple components increases the ability to
      evolve systems.

   o  Various meta-level descriptions of software, protocol, and data
      schema versions are useful for ensuring interoperability in a
      changing system.

   o  The ability of the users to choose what cloud or other systems
      their devices communicates with is important not only from the
      point of user choice, but also the ability to deal with long-term
      support and system evolution issues.

9.  Informative References

   [I-D.garcia-core-security]
              Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
              R. Struik, "Security Considerations in the IP-based
              Internet of Things", draft-garcia-core-security-06 (work
              in progress), September 2013.

   [IAB-FCC]  Internet Architecture Board, , "IAB Comments on Proposed
              FCC Rules regarding Authorization of Radiofrequency
              Equipment", https://www.iab.org/2015/10/07/iab-comments-
              on-proposed-fcc-rules-regarding-authorization-of-
              radiofrequency-equipment/, IAB, October 2015.

   [IOTSU]    Farrell, S., Birgisson, A., Smith, N., Arkko, J., Bormann,
              C., Tschofenig, H., Sparks, R., and R. Housley, "Internet
              of Things Software Update Workshop (IoTSU)",
              https://down.dsg.cs.tcd.ie/iotsu/, June 2016.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,
              <http://www.rfc-editor.org/info/rfc7452>.

   [TUSSLES]  Clark, D., Wroclawski, J., Sollins, K., and R. Braden,
              "Tussle in Cyberspace: Defining Tomorrow's Internet", In
              Proceedings of ACM SIGCOMM
              http://conferences.sigcomm.org/sigcomm/2002/papers/
              tussle.html 2002.





Arkko                   Expires December 2, 2016                [Page 7]

Internet-Draft      Software Updates and Architecture           May 2016


Appendix A.  Acknowledgments

   The author would like to thank Jaime Jimenez, Stephen Farrell, Hannes
   Tschofenig, Robert Sparks, Ines Robles, Andrew Sullivan, Ted Hardie,
   Daniel Migault, Mohit Sethi, and many others for interesting
   discussions in this problem space.

Author's Address

   Jari Arkko
   Ericsson
   Kauniainen  02700
   Finland

   Email: jari.arkko@piuha.net




































Arkko                   Expires December 2, 2016                [Page 8]