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, . [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, . [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]