Network Working Group H. Tschofenig
Internet-Draft ARM Limited
Intended status: Informational S. Farrell
Expires: May 4, 2017 Trinity College Dublin
October 31, 2016

Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016


This document provides a summary of the ‘Workshop on Internet of Things (IoT) Software Update (IOTSU)’ which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.

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

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 May 4, 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 ( 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

This document provides a summary of the ‘Workshop on Internet of Things (IoT) Software Update (IOTSU)’ [IoTSU], which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges and solutions for bringing software and firmware updates to IoT devices.

The views and positions in this report are those of the workshop participants and do not necessarily reflect those of their employers/sponsors, the authors of this memo nor the Internet Architecture Board (IAB), under whose auspices the workshop was held.

The IAB holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The topics investigated often require coordinated efforts of different organizations and industry bodies to improve an identified problem. One of the goals of such workshops is to assist with communication between relevant organisations, companies and universities, specially when the topics are partly out of the scope for the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.

In his essay ‘The Internet of Things Is Wildly Insecure And Often Unpatchable’ [BS14] Bruce Schneier expressed concerns about the status of software/firmware updates for Internet of Things (IoT) devices. IoT devices, which have a reputation for being insecure already at the time when they are manufactured, are often expected to stay active in the field for 10+ years and operate unattended with Internet connectivity.

Incorporating a software update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts but there are challenges when using software updates, as the United States Federal Trade Commission (FTC) staff in their "Internet of Things – Privacy & Security in a Connected World" [FTC] and the Article 29 Working Party Opinion 8/2014 on the on Recent Developments on the Internet of Things [WP29] reported.

Amongst the challenges in designing a basic software/firmware update function are:

There are various (often proprietary) software update mechanisms in use today and the functionality of those varies significantly with the envisioned use of the IoT devices. More powerful IoT devices, such as those running general purpose operating systems (like Linux), can make use of sophisticated software update mechanisms known from the desktop and the mobile world. This workshop focused on more constrained IoT devices that often run dedicated real-time operating systems or potentially no operating system at all.

There is a real risk that many IoT devices will continue to be shipped without a solid software/firmware update mechanism in place. Ideally, IoT software developers and product designers should be able to integrate standardized mechanisms that have experienced substantial review and where the documentation is available to the public.

Hence, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state-of-the-art and to identify requirements and gaps. In particular, the call for position papers asked for

The rest of the document is organized as follows: Basic terminology is provided in Section 2 followed by a longer section discussing requirements. Subsequent sections explore selected topics, such as incentives, and measurements, in more detail. Most of the writeup does raise more questions than it answers. Nevertheless, we tried to synthesise possible conclusions and offer a few next steps.

2. Terminology

As is typical with people from different backgrounds, workshop participants started the workshop with a discussions of terminology. This section is more intended to reflect those discussions than to present canonical definitions of terms.

Device Classes:
IoT devices come in various "sizes" (such as size of RAM, or size of flash memory). With these configurations devices are limited in what they can support in terms of operating system features, cryptographic algorithms, and protocol stacks. For this reason, the group differentiated two types of classes, namely ARM Cortex A-class / Intel Atom and Cortex M-class / Intel Quark types of devices. A-class devices are equipped with powerful processors typically found in set-top boxes and home routers. The Raspberry Pi is an example of a A-class device, which is capable of running a regular desktop operating system, such as Linux. There are differences between the Intel and the ARM-based CPUs in terms of architecture, micro-code and who is allowed to update a BIOS (if available) and the micro-code. A detailed discussion of these hardware architectural differences were, however, outside the scope of the workshop. The implication is that lower-end microcontrollers have constraints that put restrictions on the amount of software that can be put on them. While it is easy require support of a wide range of features those may not necessarily fit on these devices.
Software Update and Firmware Update:
Based on the device classes it was observed that regular operating systems come with sophisticated software update mechanisms (such as RPM [rpm] or Pacman [pacman]) that make use of the operating system to install and run each application in a compartmentalized fashion. Firmware updates typically do not provide such a fine-grained granularity for software updates and instead distribute the entire binary image, which consists of the (often minimalistic) operating system and all applications. While the distinction between the mechanisms A-class and M-class devices will typically use may get more fuzzy over time, most M-class devices use firmware updates and A-class devices use a combination of firmware and software updates (with firmware updates being less frequent operations).
Hitless Update:
A hitless update implies that the user experience is not “hit”, i.e., it is not impacted. It is possible to impact the user experience when applying an update even when the device does not reboot (to obtain or apply said update). If the update is applied when a user is not using a product and their service is not impacted, the update is “hitless".

3. Requirements

Workshop participants discussed requirements and several of these raised further questions. As with the previous section we aim to present the discussion as it was.

Which of the features discussed in the list above are nice to have? Which are required? Not all of these are required to achieve improvement. What are most important?

Among the participants there was consensus that supporting signatures (for integrity and authentication) of the firmware image itself and the need for partial updates was seen as important.

There were, however, also concerns regarding the performance implications since certain device categories may not utilize public key cryptography at all and hence only a symmetric key approach seems viable. This aspect raised concerns and trigger a discussions around the use of device management infrastructure, similar to Kerberos, that manages keys and distributes them to the appropriate parties. As such, in this set-up there could be a unique key shared with the key distribution center but for use with specific services (such as a software update service) a fresh and unique secret would be distributed.

In addition to the requirements for the end devices there are also infrastructure-related requirements. The infrastructure may consist of servers in the local network and/or various servers deployed on the Internet. It may also consist of some application layer gateways. The potential benefits of having such a local server might include:

Another point related to local infrastructure is that since many IoT devices will not be (directly) connected to the Internet, but only through a gateway, there may in any case be a need to develop a software / firmware update mechanism that works in environments where no end-to-end Internet connectivity exists.

Some current firmware update schemes need to identify devices. Different design approaches are possible.

Hence, in some deployed software update mechanisms there is no desire for the device to be identified beyond the need to exchange information about most recent software versions. For other devices, it is seen as important to identify the device itself in order to provide the appropriate firmware image/software packages.

Related to device identification various privacy concerns arise, such as the need to determine what information is provided to whom and the uses to which this information is put. For IoT devices where there is a close relationship to an individual (see [RFC6973]) privacy concerns are likely higher than for devices where such a relationship does not exist (e.g., a sensor measuring concrete). The software / firmware update mechanism should, however, not make the privacy situation of IoT devices worse. The proposal from the group was to introduce a minimal requirement of not sending any new identifiers over an unencrypted channel as part of an update protocol.

Software update will however provide yet another venue in which the tension between those advocating better privacy and those seeking to monetize information will play out. It is in the nature of software update that it requires devices to sometimes "call home" and such interactions provide fertile ground for monetization.

4. Authorizing a Software / Firmware Update

There were quite a few points revolving around authorization.

5. End-of-Support

There was quite a bit of discussion about end-of-support for products/devices and how to handle that.

The recommendation that can be provided to device-makers and users is to think about the end-of-support, end-of-support scenarios ahead of time and plan for those. While device-makers rarely want to consider what happens if their business fails it is definitely legitimate to consider scenarios where they are hugely successful and want to evolve a product line instead of supporting previously sold products forever. Maybe there is also a value in subscription-based models where product and device support is only provided as long as the subscription is paid. Without a subscription the product is deactivated and cannot pose a threat to the Internet at large.

6. Incentives

Workshop participants also discussed how to create incentives for companies to ship software updates, which is particularly important for products that will be deployed in the market for a long time. It is also further complicated by complex value chains.

7. Measurements and Analysis

From a security point of view it is important to know what devices are out there and what version of software they run. One workshop paper [plonka] reported measurements with initial done on buggy devices first distributed in 2003 that were still detectable in significant numbers just before the workshop 13 years later. As such, in addition to the firmware update mechanism companies have been offering device management solutions that allow OEMs to keep track of their devices. Tracking these devices and their status is still challenging since some devices are only connect irregularly or are only turned on when needed (such as a hockey alarm that is only turned on before a match).

Various stakeholders have a justified interest in knowing something about deployed devices. For example,

There can easily be some invasiveness in approaches to acquiring such measurements. The challenge was put forward to find ways to create measurement infrastructures that are privacy preserving. Arnar Birgisson noted that there are privacy-preserving statistical techniques, such as RAPPOR [RAPPOR], and Ned Smith added that techniques like Intel's Enhanced Privacy ID (EPID) may play a role in maintaining some level anonymity for the IoT device (owners) while also enabling measurement. It seemed clear that naive approaches to measurement (e.g., where devices are willing to expose a unique identifier to anyone on request) are unlikely to prove sufficient.

8. Firmware Distribution in Mesh Networks

There was some discussion of the requirements for mesh-based networks, mainly relating to industrial lighting. In these networks, software update can impose unacceptable performance burdens, especially if there are many devices, some of which may be are sleepy.

The workshop discussed whether some forms of multicast (perhaps not IP multicast) would be needed to provide acceptable solutions for software update in such cases. It was not clear at which layer a multi-cast solution might be effective in such cases, though there did seem to be no clearly applicable standards-based approach that was available at the time of the workshop.

9. Compromised Devices

There was a recognition that there are, and perhaps always will be, large numbers of devices that can be, or have been compromised. While updating these can mitigate problems, there will always be new devices added to networks that cannot be updated (for various reasons) so the question of what, if anything, to do about compromised devices was discussed.

The conclusion of the discussion at the workshop itself was that there is some interest to identify and stop misbehaving devices but the actual solution mechanisms are unclear.

10. Miscellaneous Points

There were a number of points discussed at the workshop that don't neatly fit under the above headings but that are worth recording. Those included:

11. Tentative Conclusions and Next Steps

The workshop participants discussed some tentative conclusions and possible next steps:

12. Security Considerations

This document summarizes an IAB workshop on software/firmware updates and the entire content is therefore security related. Standardizing and deploying a software/firmware update mechanism for use with IoT devices could help to fix security vulnerabilities faster and in some cases the only via to get vulnerability patched at all.

13. IANA Considerations

This document does not contain any requests to IANA.

14. Acknowledgements

We would like to thank all paper authors and participants for their contributions. The IoTSU workshop is co-sponsored by the Internet Architecture Board and the Science Foundation Ireland funded CONNECT Centre for future networks and communications. The programme committee would like to express their thanks to Comcast for sponsoring the social event.

15. Appendix A: Program Committee

The following individuals helped to organize the workshop: Jari Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig.

16. Appendix B: Accepted Position Papers

The list of accepted position papers is below. Links to these, and to the workshop agenda and raw minutes are accessible at: <>.

17. Appendix C: List of Participants

18. Informative References

[BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart Homes Could Be", April 2014.
[BS14] Schneier, B., "The Internet of Things Is Wildly Insecure And Often Unpatchable", January 2014.
[bsdiff] Percival, C., "Binary diff/patch utility", September 2016.
[courgette] Google, "Software Updates - Courgette", September 2016.
[DDOS-KREBS] Goodin, D., "Record-breaking DDoS reportedly delivered by >145k hacked cameras", September 2016.
[FTC] Federal Trade Commission, "FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks", January 2015.
[hashsig] Langley, A., "Hash based signatures", July 2013.
[housley-cms-mts-hash-sig] Housley, R., "Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)", March 2016.
[HP-Firmware] BoingBoing, "HP detonates its timebomb - printers stop accepting third party ink en masse", September 2016.
[IoTSU] IAB, "Internet of Things Software Update Workshop (IoTSU)", June 2016.
[LittlePrinter] Berg, "The future of Little Printer", September 2014.
[NEA] IETF, "Network Endpoint Assessment (nea) (Concluded Working Group)", 2016.
[OS-Support] Dong, W., Chen, C., Liu, X. and J. Bu, "Providing OS Support for Wireless Sensor Networks - Challenges and Approaches", May 2010.
[OS14] Oppenheim, L. and S. Tal, "Too Many Cooks – Exploiting the Internet-of-TR-069-Things", December 2014.
[pacman] -, "Pacman", 2016.
[plonka] Plonka, D. and E. Boschi, "The Internet of Things Old and Unmanage", June 2016.
[RAPPOR] Erlingsson, U., Pihur, V. and A. Korolova, "RAPPOR", July 2014.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005.
[RFC6561] Livingood, J., Mody, N. and M. O'Reirdan, "Recommendations for the Remediation of Bots in ISP Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H. and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, December 2014.
[rpm] -, "Red Hat Package Manager (RPM)", 2016.
[RT] Google, "Roughtime", September 2016.
[SNMP-DDOS] BITAG, "SNMP Reflected Amplification DDoS Attack Mitigation", August 2012.
[WP29] Article 29 Data Protection Working Party, "Opinion 8/2014 on the on Recent Developments on the Internet of Things", September 2014.

Authors' Addresses

Hannes Tschofenig ARM Limited EMail:
Stephen Farrell Trinity College Dublin Dublin, 2 Ireland Phone: +353-1-896-2354 EMail: