draft-iab-iotsu-workshop-01.txt   rfc8240.txt 
Network Working Group H. Tschofenig Internet Architecture Board (IAB) H. Tschofenig
Internet-Draft ARM Limited Request for Comments: 8240 S. Farrell
Intended status: Informational S. Farrell Category: Informational September 2017
Expires: August 7, 2017 Trinity College Dublin ISSN: 2070-1721
February 3, 2017
Report from the Internet of Things (IoT) Software Update (IoTSU) Report from the Internet of Things Software Update (IoTSU) Workshop 2016
Workshop 2016
draft-iab-iotsu-workshop-01.txt
Abstract Abstract
This document provides a summary of the 'Workshop on Internet of This document provides a summary of the Internet of Things Software
Things (IoT) Software Update (IOTSU)' which took place at Trinity Update (IoTSU) Workshop that took place at Trinity College Dublin,
College Dublin, Ireland on the 13th and 14th of June, 2016. The main Ireland on the 13th and 14th of June, 2016. The main goal of the
goal of the workshop was to foster a discussion on requirements, workshop was to foster a discussion on requirements, challenges, and
challenges and solutions for bringing software and firmware updates solutions for bringing software and firmware updates to IoT devices.
to IoT devices. This report summarizes the discussions and lists This report summarizes the discussions and lists recommendations to
recommendations to the standards community. the standards community.
Status of This Memo Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on August 7, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8240.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Questions Arising . . . . . . . . . . . . . 5 3. Requirements and Questions Raised . . . . . . . . . . . . . . 6
4. Authorizing a Software / Firmware Update . . . . . . . . . . 12 4. Authorizing a Software/Firmware Update . . . . . . . . . . . 12
5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 12 5. End-of-Support . . . . . . . . . . . . . . . . . . . . . . . 13
6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Incentives . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15 7. Measurements and Analysis . . . . . . . . . . . . . . . . . . 15
8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16 8. Firmware Distribution in Mesh Networks . . . . . . . . . . . 16
9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 16 9. Compromised Devices . . . . . . . . . . . . . . . . . . . . . 17
10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17 10. Miscellaneous Points . . . . . . . . . . . . . . . . . . . . 17
11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 18 11. Tentative Conclusions and Next Steps . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 14. Informative References . . . . . . . . . . . . . . . . . . . 20
15. Appendix A: Program Committee . . . . . . . . . . . . . . . . 19 Appendix A. Program Committee . . . . . . . . . . . . . . . . . 24
16. Appendix B: Accepted Position Papers . . . . . . . . . . . . 19 Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 24
17. Appendix C: List of Participants . . . . . . . . . . . . . . 21 Appendix C. List of Participants . . . . . . . . . . . . . . . . 26
18. Informative References . . . . . . . . . . . . . . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document provides a summary of the 'Workshop on Internet of This document provides a summary of the Internet of Things Software
Things (IoT) Software Update (IOTSU)' [IoTSU], which took place at Update (IoTSU) Workshop [IoTSU] that took place at Trinity College
Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of
The main goal of the workshop was to foster a discussion on the workshop was to foster a discussion on requirements, challenges,
requirements, challenges and solutions for bringing software and and solutions for bringing software and firmware updates to IoT
firmware updates to IoT devices. devices.
The views and positions in this report are those of the workshop The views and positions in this report are those of the workshop
participants and do not necessarily reflect those of their employers/ participants and do not necessarily reflect those of their employers/
sponsors, the authors of this memo nor the Internet Architecture sponsors, the authors of this memo, nor the Internet Architecture
Board (IAB), under whose auspices the workshop was held. Board (IAB), under whose auspices the workshop was held.
The IAB holds occasional workshops designed to consider long-term The IAB holds occasional workshops designed to consider long-term
issues and strategies for the Internet, and to suggest future issues and strategies for the Internet, and to suggest future
directions for the Internet architecture. The topics investigated directions for the Internet architecture. The topics investigated
often require coordinated efforts of different organizations and often require coordinated efforts of different organizations and
industry bodies to improve an identified problem. One of the goals industry bodies to improve an identified problem. One of the goals
of such workshops is to assist with communication between relevant of such workshops is to assist with communication between relevant
organisations, companies and universities, specially when the topics organizations, companies, and universities, especially when the
are partly out of the scope for the Internet Engineering Task Force topics are partly out of the scope for the Internet Engineering Task
(IETF). This long-term planning function of the IAB is complementary Force (IETF). This long-term planning function of the IAB is
to the ongoing engineering efforts performed by working groups of the complementary to the ongoing engineering efforts performed by working
IETF. groups of the IETF.
In his essay 'The Internet of Things Is Wildly Insecure And Often In his essay "The Internet of Things Is Wildly Insecure -- And Often
Unpatchable' [BS14] Bruce Schneier expressed concerns about the Unpatchable" [BS14], Bruce Schneier expressed concerns about the
status of software/firmware updates for Internet of Things (IoT) status of software/firmware updates for IoT devices. IoT devices,
devices. IoT devices, which have a reputation for being insecure which have a reputation for being insecure from the time they are
already at the time when they are manufactured, are often expected to manufactured, are often expected to stay active in the field for 10
stay active in the field for 10+ years and operate unattended with or more years and to operate unattended with Internet connectivity.
Internet connectivity.
Incorporating a software update mechanism to fix vulnerabilities, to Incorporating a software update mechanism to fix vulnerabilities, to
update configuration settings as well as adding new functionality is update configuration settings and, to add new functionality as well,
recommended by security experts but there are challenges when using is recommended by security experts. However, there are challenges
software updates, as the United States Federal Trade Commission (FTC) when using software updates, as documented in the United States
staff in their "Internet of Things - Privacy & Security in a Federal Trade Commission (FTC) report titled "internet of things:
Connected World" [FTC] and the Article 29 Working Party Opinion Privacy & Security in a Connected World" [FTC] and in the Article 29
8/2014 on the on Recent Developments on the Internet of Things [WP29] Data Protection Working Party document "Opinion 8/2014 on the on
reported. [sic] Recent Developments on the Internet of Things"[WP29].
Amongst the challenges in designing a basic software/firmware update Among the challenges in designing a basic software/firmware update
function are: function are:
- Implementations of software update mechanisms may incorporate - Implementations of software update mechanisms may incorporate
vulnerabilities becoming an attractive attack target, see for vulnerabilities, becoming an attractive attack target. See, for
example [OS14], example, [OS14].
- Operational challenges such as the case of an expired certificate - Operational challenges, such as the case of an expired certificate
in a hub device [BB14], in a hub device [BB14].
- Privacy issues if devices "call home" often to check for updates - Privacy issues if devices "call home" often to check for updates.
- A lack of incentives to distribute software updates along the - A lack of incentives to distribute software updates along the
value chain value chain.
- Who should be able to update device software after normal support - Questions such as the following. Who should be able to update
stops? When should an alternate source of software updates take device software after normal support stops? When should an
over? alternate source of software updates take over?
There are various (often proprietary) software update mechanisms in There are various (often proprietary) software update mechanisms in
use today and the functionality of those varies significantly with use today, and the functionality of those varies significantly with
the envisioned use of the IoT devices. More powerful IoT devices, the envisioned use of the IoT devices. More powerful IoT devices,
such as those running general purpose operating systems (like Linux), such as those running general purpose operating systems (like Linux),
can make use of sophisticated software update mechanisms known from can make use of sophisticated software update mechanisms known from
the desktop and the mobile world. This workshop focused on more the desktop and the mobile world. This workshop focused on more
constrained IoT devices that often run dedicated real-time operating constrained IoT devices that often run dedicated real-time operating
systems or potentially no operating system at all. systems or potentially no operating system at all.
There is a real risk that many IoT devices will continue to be There is a real risk that many IoT devices will continue to be
shipped without a solid software/firmware update mechanism in place. shipped without a solid software/firmware update mechanism in place.
Ideally, IoT software developers and product designers should be able Ideally, IoT software developers and product designers should be able
to integrate standardized mechanisms that have experienced to integrate standardized mechanisms that have experienced
substantial review and where the documentation is available to the substantial review and where the documentation is available to the
public. public.
Hence, the IAB decided to organize a workshop to reach out to Hence, the IAB decided to organize a workshop to reach out to
relevant stakeholders to explore the state-of-the-art and to identify relevant stakeholders to explore the state of the art and to identify
requirements and gaps. In particular, the call for position papers requirements and gaps. In particular, the call for position papers
asked for asked for:
- Protocol mechanisms for distributing software updates. - Protocol mechanisms for distributing software updates.
- Mechanisms for securing software updates. - Mechanisms for securing software updates.
- Meta-data about software / firmware packages. - Metadata about software/firmware packages.
- Implications of operating system and hardware design on the - Implications of operating system and hardware design on the
software update mechanisms. software update mechanisms.
- Installation of software updates (in context of software and - Installation of software updates (in context of software and
hardware security of IoT devices). hardware security of IoT devices).
- Privacy implications of software update mechanisms. - Privacy implications of software update mechanisms.
- Implications of device ownership and control for software update. - Implications of device ownership and control for software update.
The rest of the document is organized as follows: Basic terminology The rest of the document is organized as follows: basic terminology
is provided in Section 2 followed by a longer section discussing is provided in Section 2, followed by a longer section discussing
requirements. Subsequent sections explore selected topics, such as requirements. Subsequent sections explore selected topics, such as
incentives, and measurements, in more detail. Most of the writeup incentives and measurements in more detail. Most of the write-up
does raise more questions than it answers. Nevertheless, we tried to does raise more questions than it answers. Nevertheless, we tried to
synthesise possible conclusions and offer a few next steps. synthesize possible conclusions and offer a few next steps.
2. Terminology 2. Terminology
As is typical with people from different backgrounds, workshop As is typical with people from different backgrounds, workshop
participants started the workshop with a discussions of terminology. participants started the workshop with a discussions of terminology.
This section is more intended to reflect those discussions than to This section is more intended to reflect those discussions than to
present canonical definitions of terms. present canonical definitions of terms.
Device Classes: IoT devices come in various "sizes" (such as size of Device Classes: IoT devices come in various "sizes" (such as size of
RAM, or size of flash memory). With these configurations devices RAM or size of flash memory). With these configurations, devices
are limited in what they can support in terms of operating system are limited in what they can support in terms of operating-system
features, cryptographic algorithms, and protocol stacks. For this features, cryptographic algorithms, and protocol stacks. For this
reason, the group differentiated two types of classes, namely ARM reason, the group differentiated two types of classes, namely ARM
Cortex A-class / Intel Atom and Cortex M-class / Intel Quark types Cortex A-class/Intel Atom and Cortex M-class/Intel Quark types of
of devices. A-class devices are equipped with powerful processors devices. A-class devices are equipped with powerful processors
typically found in set-top boxes and home routers. The Raspberry 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 Pi is an example of an A-class device that is capable of running a
a regular desktop operating system, such as Linux. There are regular desktop operating system, such as Linux. There are
differences between the Intel and the ARM-based CPUs in terms of differences between the Intel and the ARM-based CPUs in terms of
architecture, micro-code and who is allowed to update a BIOS (if architecture, microcode, and who is allowed to update a Basic
available) and the micro-code. A detailed discussion of these Input/Output System (BIOS) (if available). A detailed discussion
hardware architectural differences were, however, outside the of these hardware architectural differences were, however, outside
scope of the workshop. The implication is that lower-end the scope of the workshop. The implication is that lower-end
microcontrollers have constraints that put restrictions on the microcontrollers have constraints that put restrictions on the
amount of software that can be put on them. While it is easy amount of software that can be put on them. While it is easy to
require support of a wide range of features those may not require support of a wide range of features, those may not
necessarily fit on these devices. necessarily fit on these devices.
Software Update and Firmware Update: Based on the device classes it Software Update and Firmware Update: Based on the device classes, it
was observed that regular operating systems come with was observed that regular operating systems come with
sophisticated software update mechanisms (such as RPM [rpm] or sophisticated software update mechanisms (such as Red Hat Package
Pacman [pacman]) that make use of the operating system to install Manager (RPM) [RPM] or pacman [PACMAN]) that make use of the
and run each application in a compartmentalized fashion. Firmware operating system to install and run each application in a
updates typically do not provide such a fine-grained granularity compartmentalized fashion. Firmware updates typically do not
for software updates and instead distribute the entire binary provide such a fine-grained granularity for software updates and
image, which consists of the (often minimalistic) operating system instead distribute the entire binary image, which consists of the
and all applications. While the distinction between the (often minimalistic) operating system and all applications. While
mechanisms A-class and M-class devices will typically use may get the distinction between the mechanisms that A-class and M-class
more fuzzy over time, most M-class devices use firmware updates devices will typically use may get more fuzzy over time, most
and A-class devices use a combination of firmware and software M-class devices use firmware updates while A-class devices use a
updates (with firmware updates being less frequent operations). combination of firmware and software updates (with firmware
updates being less frequent operations).
Hitless Update: A hitless update implies that the user experience is 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 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 user experience when applying an update even when the device does
not reboot (to obtain or apply said update). If the update is 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 applied when a user is not using a product and their service is
not impacted, the update is "hitless". not impacted, the update is "hitless".
3. Requirements and Questions Arising 3. Requirements and Questions Raised
Workshop participants discussed requirements and several of these Workshop participants discussed requirements and several of these
raised further questions. As with the previous section we aim to raised further questions. As with the previous section, we aim to
present the discussion as it was. present the discussion as it was.
- There may be a need to be support partial (differential) updates, - There may be a need to be support partial (differential) updates
that do not require the entire firmware image to be sent. This that do not require the entire firmware image to be sent. This
may mean that techniques like bsdiff [bsdiff] and courgette may mean that techniques like bsdiff [BSDIFF] and courgette
[courgette] are used but might also mean devices supporting [COURGETTE] are used but might also mean devices supporting the
download of applications and libraries alone. The latter feature download of applications and libraries alone. The latter feature
may require dynamic linking and position independent code. It was may require dynamic linking and position independent code. It was
unclear whether position independent code should be recommended unclear whether position independent code should be recommended
for low-end IoT devices. for low-end IoT devices.
- The relative importance of dynamic linkers for low-end IoT devices - The relative importance of dynamic linkers for low-end IoT devices
is unclear. Some operating systems used with M-class devices, is unclear. Some operating systems used with M-class devices,
such as Contiki, provide support for a dynamic linker according to such as Contiki, provide support for a dynamic linker according to
[OS-Support]. This could help to minimize the amount of data [OS-Support]. This could help to minimize the amount of data
transmitted during updates since only the modified application or transmitted during updates since only the modified application or
library needs to be transmitted. library needs to be transmitted.
- How should dependencies among various software updates be handled? - How should dependencies among various software updates be handled?
These dependencies may include information about the hardware These dependencies may include information about the hardware
platform and configuration as well as other software components platform and configuration as well as other software components
running on a system. For firmware updates the problem of running on a system. For firmware updates, the problem of
dependencies are often solved by the manufacturer or OEM rather dependencies are often solved by the manufacturer or Original
than on the device itself. Equipment Manufacturer (OEM) rather than on the device itself.
- Support for devices with multiple micro-controllers may required - Support for devices with multiple microcontrollers may require an
an architecture where one micro-controller is responsible for architecture where one microcontroller is responsible for
interacting with the update service and then dispatching software interacting with the update service and then dispatching software
images to the attached micro-controllers within its local realm. images to the attached microcontrollers within its local realm.
The alternative of letting each microcontroller interact with an The alternative of letting each microcontroller interact with an
update service appeared less practical. update service appeared less practical.
- Support may be required for devices with multiple owners/ - Support may be required for devices with multiple owners/
stakeholders where the question arises about who is authorized to stakeholders where the question arises about who is authorized to
push a firmware/software update. push a firmware/software update.
- Data origin authentication (DAO) was agreed to be required for - Data origin authentication (DAO) was agreed to be required for
software updates. Without DAO, updates simply become a perfect software updates. Without DAO, updates simply become a perfect
vulnerability. It is however non-trivial to ensure the actual vulnerability. It is, however, nontrivial to ensure that the
trust relationships that exist are modelled by the DAO mechanism. actual trust relationships that exist are modeled by the DAO
For some devices and deployment scenarios, any DAO mechanism is mechanism. For some devices and deployment scenarios, any DAO
onerous, possibly to the point where it may be hard to convince a mechanism is onerous, possibly to the point where it may be hard
device-maker to include the functionality. to convince a device maker to include the functionality.
- Should digital signatures and encryption for software updates be - Should digital signatures and encryption for software updates be
recommended as a best current practice? This question recommended as a best current practice? This question
particualrly raises the question about the use of symmetric key particularly raises the question about the use of symmetric key
cryptography since not all low end IoT devices are currently using cryptography since not all low-end IoT devices are currently using
asymmetric crypto. asymmetric crypto.
- DAO is most commonly provided via digital signature mechanisms, - DAO is most commonly provided via digital signature mechanisms,
but symmetric schemes could also be developed, though IETF but symmetric schemes could also be developed, though IETF
discussion of such mechanisms (for purposes less sensitive than discussion of such mechanisms (for purposes less sensitive than
software update) has proved significantly controversial. The main software update) has proved significantly controversial. The main
problem seems to be that simple symmetric schemes only ensure that problem seems to be that simple symmetric schemes only ensure that
the sender is a member of a group and do not fully authenticate a the sender is a member of a group, and they do not fully
specific sender. And with software update, we do not want any authenticate a specific sender. And with a software update, we do
(possibly compromised) device to be able to be authenticate new not want any (possibly compromised) device to be able to
software for all other similar devices. authenticate new software for all other similar devices.
- What are the firmware update signing key requirements? Since - What are the firmware update signing key requirements? Since
devices have a rather long lifetime there has to be a way to devices have a rather long lifetime, there has to be a way to
change the signing key during the lifetime of the device. change the signing key during the lifetime of the device.
- Should a firmware update mechanism support multiple signatures of - Should a firmware update mechanism support multiple signatures of
firmware images? Multiple signatures can come in two different firmware images? Multiple signatures can come in two different
flavours, namely flavors, namely:
a single firmware image may be signed by multiple different A single firmware image may be signed by multiple different
parties. In this case one could imagine an environment where parties. In this case, one could imagine an environment where
an Original Equipment Manufacturer (OEM) signs the software it an OEM signs the software it creates, but then the software is
creates but then the software is again signed by the enterprise again signed by the enterprise that approves the distribution
that approves the distribution within the company. Other within the company. Other examples include regulatory
examples include regulatory signatures where a the software for signatures where the software for a medical device may be
a medical device may be signed as approved by a certification signed as approved by a certification body.
body.
a software image may contain libraries that are each signed by A software image may contain libraries that are each signed by
their developers. their developers.
Is a device expected to verify the different types of signatures Is a device expected to verify the different types of signatures
or is this rather a service provided by some non-constrained or is this a service provided by some unconstrained device? This
device? This raises the question about who the IoT device should raises questions about who the IoT device should trust for what
trust for what and whether transitive trust is acceptable for some and whether transitive trust is acceptable for some types of
types of devices? devices.
- Are applications from a range of sources allowed to run on a - Are applications from a range of sources allowed to run on a
device or only those from the OEM? If the device is a "closed" device or only those from the OEM? If the device is a "closed"
device that only supports/runs software from the OEM then a single device that only supports/runs software from the OEM, then a
signature may be sufficient. In any more "open" system, 3rd party single signature may be sufficient. In a system that is more
applications may require support of multiple signatures. "open", third-party applications may require support of multiple
signatures.
- There is a need for some form of secure storage, at least for - There is a need for some form of secure storage, at least for
those IoT devices that are exposed to physical attacks. This those IoT devices that are exposed to physical attacks. This
includes at least the need to protect the integrity of the public includes at least the need to protect the integrity of the public
key of the update service on the device (if signature based DAO is key of the update service on the device (if signature-based DAO is
in use). The use of symmetric key cryptography requires improved in use). The use of symmetric key cryptography requires improved
confidentiality protection (in addition to integrity protection). confidentiality protection (in addition to integrity protection).
- Is there a need to allow the update infrastructure-side to - Is there a need to allow the update infrastructure side to
authenticate the IoT device before distributing an update? authenticate the IoT device before distributing an update?
Questions about the identifier used for such an authentication Questions about the identifier used for such an authentication
action were raised. The idea of re-use MAC addresses lead to action were raised. The idea of reusing Media Access Control
concerns about the significant privacy implications of such (MAC) addresses lead to concerns about the significant privacy
identifier re-use. implications of such identifier reuse.
- It is important to minimize device/service downtime due to update - It is important to minimize device/service downtime due to update
processing, minimize user interaction (e.g., car should not processing and to minimize user interaction (e.g., car should not
distract the driver) (see hitless updates). While it may not be distract the driver) (see "Hitless Update" in Section 2). While
possible to avoid all downtime, there was agreement that one ought it may not be possible to avoid all downtime, there was agreement
strive for "no inappropriate" device downtime. This means minimal that one ought to strive for "no inappropriate" device downtime.
downtime impacting the user/operation of the device. The This means minimal downtime impacting the user/operation of the
definition of "downtime" also depends on the use case, with a device. The definition of "downtime" also depends on the use
smart light bulb, the device could be "up" if the light is still case, with a smart light bulb, the device could be "up" if the
on, even if some advanced services are unavailable for a short light is still on, even if some advanced services are unavailable
time. Whether an update can be done without rebooting the device for a short time. Whether an update can be done without rebooting
depends on the software being installed, on the OS architecture, the device depends on the software being installed, on the OS
and potentially even on the hardware architecture. The cost/ architecture, and potentially even on the hardware architecture.
benefit ratio also plays a role. The cost/benefit ratio also plays a role.
- It is desirable to minimise the time taken from the start of the - It is desirable to minimize the time taken from the start of the
update to when it is finished. In some systems with many devices update to when it is finished. In some systems with many devices
(e.g., industrial lighting) this can be a challenge if updates (e.g., industrial lighting), this can be a challenge if updates
need to be unicasted. need to be unicasted.
- In some systems with multiple devices, it can be a challenge to - In some systems with multiple devices, it can be a challenge to
ensure that all devices are at the same release level, especially ensure that all devices are at the same release level, especially
if some devices are sleepy. There are some systems where ensuring if some devices are sleepy. There are some systems where ensuring
all relevant devices are at the same release level is a hard- all relevant devices are at the same release level is a hard
requirement. In other cases, it is acceptable if devices converge requirement. In other cases, it is acceptable if devices converge
much more slowly to the current release level. much more slowly to the current release level.
- It ought not be possible for a factory worker to compromise the - It ought not be possible for a factory worker to compromise the
update process (e.g., copy signing keys, install unauthorized update process (e.g., copy signing keys and install unauthorized
public keys/trust anchors) during the manufacturing process. public keys/trust anchors) during the manufacturing process.
There are typically two factories involved, first the factory that There are typically two factories involved: the first factory
produces microcontrollers and other components. The second produces microcontrollers and other components and the second
factory produces the complete product, such as a fridge. This factory produces the complete product, such as a fridge. This
fridge contains many of the components previously manufactured. fridge contains many of the components previously manufactured.
Hence, the firmware of components produced in the first stage may Hence, the firmware of components produced in the first stage may
be 6 month old when the fridge leaves the factory. One does not be six months old when the fridge leaves the factory. One does
want to install a firmware update when the fridge boots the first not want to install a firmware update when the fridge boots the
time. For that time the firmware update happens already at the first time. For that time, the firmware update happens already at
end of the manufacturing process. the end of the manufacturing process.
- Should devices have a recovery procedure when the device gets - Should devices have a recovery procedure when the device gets
compromised? How is the compromise detected? compromised? How is the compromise detected?
- There was a bit of discussion about the importance for IoT devices - There was a bit of discussion about the importance for IoT devices
to know the current time for the purpose of checking certificate to know the current time for the purpose of checking certificate
validity. For example, what does "real-time clock" (RTC) actually validity. For example, what does "real-time clock" (RTC) actually
mean? And what constitute 'good enough' time? There are, mean? And what constitutes "good enough" time? There are,
however, cost, power, size, and environmental constraints that can however, cost, power, size, and environmental constraints that can
make the addition of a real-time clock to an IoT device complex: make the addition of a real-time clock to an IoT device complex:
o Cost: battery- or supercap-backed RTC modules might be several o Cost: Battery- or supercap-backed RTC modules might be several
times the cost of the rest of the bill of materials. times the cost of the rest of the bill of materials.
o Size: the battery and other components are often several times o Size: The battery and other components are often several times
larger than the rest of the material. larger than the rest of the material.
o Manufacturing: some modules require an extra assembly step, o Manufacturing: Some modules require an extra assembly step,
because the battery could be damaged/explodes at high because the battery could be damaged or explode at high
temperature during the reflow process. temperatures during the reflow process.
o Supply chain: devices containing fitted batteries need o Supply chain: Devices containing fitted batteries need
additional supply chain management to account for storage additional supply-chain management to account for storage
temperature and to avoid shipping aged devices. temperature and to avoid shipping aged devices.
o Environmental: Real-time-clock modules are typically not rated o Environmental: Real-time-clock modules are typically not rated
at industrial temperature ranges. Those that are have at industrial temperature ranges. Those that are have
extremely reduced lifetime at high temperatures. extremely reduced lifetime at high temperatures.
o Lifetime: some of these modules last only a few years at the o Lifetime: Some of these modules last only a few years at the
top of their environmental range. top of their environmental range.
While a good solution is needed, it is not clear whether there is While a good solution is needed, it is not clear whether there is
one true solution. A recent proposal from Google called Roughtime one true solution. A recent proposal from Google called
[RT] may be worthwhile to explore. "Roughtime" [RT] may be worthwhile to explore.
- How do devices learn about a firmware update? Push or Pull? What - How do devices learn about a firmware update? Push or Pull? What
should be required functionality for a firmware update protocol? should be required functionality for a firmware update protocol?
- There is a need to find out whether a software update was - There is a need to find out whether a software update was
successful. In one discussed solution the bootloader analyses the successful. In one discussed solution, the bootloader analyzes
performance of the running image to determine which image to run the performance of the running image to determine which image to
(rather than just verifying the integrity of the received image). run (rather than just verifying the integrity of the received
One of the key criteria is that the updated system is able to make image). One of the key criteria is that the updated system is
a connection to the device management/software update able to make a connection to the device management/software update
infrastructure. As long as it is able to talk to the update infrastructure. As long as it is able to talk to the update
infrastructure it can receive another update. As alternative infrastructure, it can receive another update. As an alternative
perspective the argument was made that one needs to have a way to perspective, the argument was made that one needs to have a way to
update the system without have the full system running. update the system without having the full system running.
- Gateway requirements. In some deployments gateways terminate the - Gateway requirements. In some deployments, gateways terminate the
IP-based protocol communication and use non-IP mechanisms to IP-based protocol communication and use non-IP mechanisms to
communicate with other micro-controllers, for example, within a communicate with other microcontrollers, for example, within a
car. The gateway in such a system is the end point of the IP car. The gateway in such a system is the endpoint of the IP
communication. The group had mixed feelings about the use of communication. The group had mixed feelings about the use of
gateways vs the use of IP communication to every micro-controller. gateways versus the use of IP communication to every
Participants argued that there is a lack of awareness of IPv6 microcontroller. Participants argued that there is a lack of
header compression (with the 6lowpan standards) and of the awareness of IPv6 header compression (with the IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) standards) and of the
possible benefits of IPv6 in those environments in terms of possible benefits of IPv6 in those environments in terms of
lowering the complexity of the overall system. lowering the complexity of the overall system.
- The amount of energy consumed due to software update needs to be - The amount of energy consumed due to software update needs to be
minimized. For example, awakening a sleepy device regularly only minimized. For example, awakening a sleepy device regularly only
to check for new software would seem wasteful if the device cannot to check for new software would seem wasteful if the device cannot
feasibly be exploited whilst asleep. However, the trade-off is feasibly be exploited while asleep. However, the trade-off is
that once the device awakens with old software, there may be a that once the device awakens with old software, there may be a
window of vulnerability, if some relevant exploit has been window of vulnerability if some relevant exploit has been
discovered. discovered.
- The amount of storage required for update ought be minimized and - The amount of storage required for update ought to be minimized
can sometimes be significant. However, there are also benefits to and can sometimes be significant. However, there are also
schemes that store two or three different software images for benefits to schemes that store two or three different software
robustness, e.g., if one has space for separate current, last- images for robustness, e.g., if one has space for separate current
known-good and being-updated images then devices can better last-known-good and being-updated images, then devices can better
survive the buggy occasional updates that are also inevitable. survive the buggy occasional updates that are also inevitable.
Which of the features discussed in the list above are nice to have? Which of the features discussed in the list above are nice to have?
Which are required? Not all of these are required to achieve Which are required? Not all of these are required to achieve
improvement. What are most important? improvement. Which are most important?
Among the participants there was consensus that supporting signatures Among the participants, there was consensus that supporting
(for integrity and authentication) of the firmware image itself and signatures (for integrity and authentication) of the firmware image
the need for partial updates was seen as important. itself and the need for partial updates were seen as important.
There were, however, also concerns regarding the performance However, there were also concerns regarding the performance
implications since certain device categories may not utilize public implications, since certain device categories may not utilize public
key cryptography at all and hence only a symmetric key approach seems key cryptography at all; hence, only a symmetric key approach seems
viable, unless some other scheme such as hash-based signature become viable, unless some other scheme such as a hash-based signature
practical (they currently aren't due to signature size). This aspect became practical (they currently aren't, due to signature size).
raised concerns and trigger a discussions around the use of device This aspect raised concerns and triggered a discussion around the use
management infrastructure, similar to Kerberos, that manages keys and of device management infrastructure, similar to Kerberos, that
distributes them to the appropriate parties. As such, in this set-up manages keys and distributes them to the appropriate parties. As
there could be a unique key shared with the key distribution center such, in this setup, there could be a unique key shared with the key
but for use with specific services (such as a software update distribution center; but for use with specific services (such as a
service) a fresh and unique secret would be distributed. software update service), a fresh and unique secret would be
distributed.
In addition to the requirements for the end devices there are also In addition to the requirements for the end devices, there are also
infrastructure-related requirements. The infrastructure may consist infrastructure-related requirements. The infrastructure may consist
of servers in the local network and/or various servers deployed on of servers in the local network and/or various servers deployed on
the Internet. It may also consist of some application layer the Internet. It may also consist of some application-layer
gateways. The potential benefits of having such a local server might gateways. The potential benefits of having such a local server might
include: include:
- The local server acting for neighbouring nodes. For example, in a - The local server acting for neighboring nodes. For example, in a
vehicle one micro-controller can process all firmware updates and vehicle one microcontroller can process all firmware updates and
redistribute the relevant parts of those to interconnected micro- redistribute the relevant parts of those to interconnected
controllers. microcontrollers.
- Local infrastructure could perform some digital signature checks - Local infrastructure could perform some digital signature checks
on behalf of the devices, e.g., certificate revocation checking. on behalf of the devices, e.g., certificate-revocation checking.
- Local multicast can enable transmission of the same update to many - Local multicast can enable transmission of the same update to many
devices devices.
- Local servers can hide complexity associated with NAT and - Local servers can hide complexity associated with Network Address
Firewalls from the device Translation (NAT) and firewalls from the device.
Another point related to local infrastructure is that since many IoT Another point related to local infrastructure is that since many IoT
devices will not be (directly) connected to the Internet, but only 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 through a gateway, there may in any case be a need to develop a
software / firmware update mechanism that works in environments where software/firmware update mechanism that works in environments where
no end-to-end Internet connectivity exists. no end-to-end Internet connectivity exists.
Some current firmware update schemes need to identify devices. Some current firmware update schemes need to identify devices.
Different design approaches are possible. Different design approaches are possible.
- In an extreme form in one case the decision about updating a - In an extreme form in one case, the decision about updating a
device is made by the infrastructure based on the unique device device is made by the infrastructure based on the unique device
identification. The operator of the firmware update identification. The operator of the firmware update
infrastructure knows about the hardware and software requirements infrastructure knows about the hardware and software requirements
for the IoT devices, knows about the policy for updating the for the IoT devices, knows about the policy for updating the
device, etc. The device itself is provisioned with credentials so device, etc. The device itself is provisioned with credentials so
that it can verify a firmware update coming from an authorized that it can verify a firmware update coming from an authorized
device. device.
- In another extreme the device has knowledge about the software and - In another extreme, the device has knowledge about the software
hardware configuration and possible dependencies. It consults and hardware configuration and possible dependencies. It consults
software repositories to obtain those software packages that are software repositories to obtain those software packages that are
most appropriate. Verifying the authenticity of the software most appropriate. Verifying the authenticity of the software
packages/firmware images will still be required. packages/firmware images will still be required.
Hence, in some deployed software update mechanisms there is no desire Hence, in some deployed software update mechanisms there is no desire
for the device to be identified beyond the need to exchange for the device to be identified beyond the need to exchange
information about most recent software versions. For other devices, information about the most recent software versions. For other
it is seen as important to identify the device itself in order to devices, it is seen as important to identify the device itself in
provide the appropriate firmware image/software packages. order to provide the appropriate firmware image/software packages.
Related to device identification various privacy concerns arise, such Related to device identification, various privacy concerns arise,
as the need to determine what information is provided to whom and the such as the need to determine what information is provided to whom
uses to which this information is put. For IoT devices where there and the uses to which this information is put. For IoT devices where
is a close relationship to an individual (see [RFC6973]) privacy there is a close relationship to an individual (see [RFC6973]),
concerns are likely higher than for devices where such a relationship privacy concerns are likely higher than for devices where such a
does not exist (e.g., a sensor measuring concrete). The software / relationship does not exist (e.g., a sensor measuring concrete). The
firmware update mechanism should, however, not make the privacy software/firmware update mechanism should, however, not make the
situation of IoT devices worse. The proposal from the group was to privacy situation of IoT devices worse. The proposal from the group
introduce a minimal requirement of not sending any new identifiers was to introduce a minimal requirement of not sending any new
over an unencrypted channel as part of an update protocol. identifiers over an unencrypted channel as part of an update
protocol.
Software update will however provide yet another venue in which the However, software updates will provide yet another venue in which the
tension between those advocating better privacy and those seeking to tension between those advocating better privacy and those seeking to
monetize information will play out. It is in the nature of software monetize information will play out. It is in the nature of software
update that it requires devices to sometimes "call home" and such update that it requires devices to sometimes "call home" and such
interactions provide fertile ground for monetization. interactions provide fertile ground for monetization.
4. Authorizing a Software / Firmware Update 4. Authorizing a Software/Firmware Update
There were quite a few points revolving around authorization. There were quite a few points revolving around authorization:
- Who can accept or reject an update? Is it the owner of the - Who can accept or reject an update? Is it the owner of the
device, or the user or both? The user may not necessarily be the device, the user, or both? The user may not necessarily be the
owner. owner.
- With products that fall under a regulatory structure, such as - With products that fall under a regulatory structure, such as
healthcare, you don't want firmware other than what has been healthcare, you don't want firmware other than what has been
accredited. accredited.
- In some cases it will be very difficult for a firmware update - In some cases, it will be very difficult for a firmware update
system to communicate to users that an update is available. Doing system to communicate to users that an update is available. Doing
so may requires tracking the device and it's status with regards so may require tracking the device and its status with regard to
to the installed firmware/software, with all the privacy downsides the installed firmware/software, with all the privacy downsides if
if such tracking is badly done. such tracking is badly done.
- Not all updates are the same. Security updates are often treated - Not all updates are the same. Security updates are often treated
differently compared to feature updates and the authorization for differently compared to feature updates, and the authorization for
these may differ. these may differ.
- Some people may choose to decline updates, often on the basis that - Some people may choose to decline updates, often on the basis that
their system is currently stable, but also possibly due to their system is currently stable, but also possibly due to
concerns about unwanted changes, such as the HP printer firmware concerns about unwanted changes, such as the HP printer firmware
update pushed in March 2016 [HP-Firmware] that turned off features update pushed in March 2016 [HP-Firmware] that turned off features
that end-users liked. that end users liked.
5. End-of-Support 5. End-of-Support
There was quite a bit of discussion about end-of-support for There was quite a bit of discussion about end-of-support for
products/devices and how to handle that. products/devices and how to handle that.
- How should end-of-support, or end-of-features be treated? Devices - How should end-of-support or end-of-features be treated? Devices
are often deployed for 10+ years (or even longer in some are often deployed for 10+ years (or even longer in some
verticals). Device-makers may not want or be able to support verticals). Device makers may not want or be able to support
software and services for such an extended period of time. Will software and services for such an extended period of time. Will
these devices stop working after a certain, previously unannounced these devices stop working after a certain, previously unannounced
period of time, such as Eye-Fi cards [eyefi]. period of time, such as Eye-Fi cards [EYEFI]?
- There will be a broad range of device-makers involved in IoT, who - There will be a broad range of device makers involved in IoT, who
may differ substantially in terms of how well they can handle the may differ substantially in terms of how well they can handle the
full device life-cycle. Some will be large commercial enterprises full device life cycle. Some will be large commercial enterprises
who are used to dealing with long device life times, whilst others that are used to dealing with long device lifetimes, whereas
may be very small commercial entities where the device lifetime others may be very small commercial entities where the device
may be longer than the company life-time. Yet other devices may lifetime may be longer than the company lifetime. Yet other
be the result of open-source activities that prosper or flounder. devices may be the result of open-source activities that prosper
The problem of end-of-support arises in all these cases, though or flounder. The problem of end-of-support arises in all these
feasible solutions for software update may substantially differ. cases, though feasible solutions for software update may
In some cases device-makers may not be willing to continue to substantially differ. In some cases, device makers may not be
update devices, for example due to a change in business strategies willing to continue to update devices, for example, due to a
caused by a merger. In yet other cases a company may have gone change in business strategies caused by a merger. In yet other
bankrupt. cases, a company may have gone bankrupt.
- While there are many legal, ethical, and business related - While there are many legal, ethical, and business-related
questions can we technically enable transfer of device service to questions, can we technically enable transfer of device service to
another provider? Could there even be business models for another provider? Could there even be business models for
entities that take over device updates for original device-makers entities that take over device updates for original device makers
who no longer wish to handle software update? that no longer wish to handle software update?
- The release of code, as it was done with the Little Printer - The release of code, as it was done with the Little Printer
manufactured and developed by a company called Berg manufactured and developed by a company called "Berg"
[LittlePrinter], could provide a useful example. While the [LittlePrinter], could provide a useful example. While the
community took over the support in that case, this can hardly be community took over the support in that case, this can hardly be
assumed in all cases. Just releasing the source code for a device assumed in all cases. Just releasing the source code for a device
will not necessarily motivate others to work on the code, to fix will not necessarily motivate others to work on the code, to fix
bugs or to maintain a service. Nevertheless, escrowing code so bugs, or to maintain a service. Nevertheless, escrowing code so
that the community can take it over if a company fails is one that the community can take it over if a company fails is one
possible option. possible option.
- The situation gets more complex when the device has security - The situation gets more complex when the device has security
mechanisms to ensure that only selected parties are allowed to mechanisms to ensure that only selected parties are allowed to
update the device (which is really a basic requirement for any update the device (which is really a basic requirement for any
secure software update). In this case, private signing keys (or secure software update). In this case, private signing keys (or
similar) may need to be made available as well, which could similar) may need to be made available as well, which could
introduce security problems for already deployed software. In the introduce security problems for already-deployed software. In the
best case it changes assumptions made about the trust model and best case, it changes assumptions made about the trust model and
about who can submit updates. about who can submit updates.
- How should deployed devices behave when they are end-of-support - How should deployed devices behave when they are end-of-support
and support ends? Many of them may still function normally, but and support ends? Many of them may still function normally, but
others may fail due to the absence of cloud infrastructure others may fail due to the absence of cloud infrastructure
services. Some products are probably expected to fail safely, services. Some products are probably expected to fail safely,
similarly to a smoke alarm that makes a loud noise when the similarly to a smoke alarm that makes a loud noise when the
battery becomes empty. Cell phones without a contract can, in battery becomes empty. Cell phones without a contract can, in
some countries, still be used for emergency services (although at some countries, still be used for emergency services (although at
the expense of the society due to untraceable hoax calls), as the expense of society due to untraceable hoax calls), as
discussed in RFC 7406 [RFC7406]. discussed in RFC 7406 [RFC7406].
The recommendation that can be provided to device-makers and users is 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 to think about the end-of-support and end-of-support scenarios ahead
time and plan for those. While device-makers rarely want to consider of time and plan for those. While device makers rarely want to
what happens if their business fails it is definitely legitimate to consider what happens if their business fails, it is definitely
consider scenarios where they are hugely successful and want to legitimate to consider scenarios where they are hugely successful and
evolve a product line instead of supporting previously sold products want to evolve a product line instead of supporting previously sold
forever. Maybe there is also a value in subscription-based models products forever. Maybe there is also value in subscription-based
where product and device support is only provided as long as the models where product and device support is only provided as long as
subscription is paid. Without a subscription the product is the subscription is paid. Without a subscription, the product is
deactivated and cannot pose a threat to the Internet at large. deactivated and cannot pose a threat to the Internet at large.
6. Incentives 6. Incentives
Workshop participants also discussed how to create incentives for Workshop participants also discussed how to create incentives for
companies to ship software updates, which is particularly important companies to ship software updates, which is particularly important
for products that will be deployed in the market for a long time. It for products that will be deployed in the market for a long time. It
is also further complicated by complex value chains. is also further complicated by complex value chains.
- Companies shipping software updates benefit from improved - Companies shipping software updates benefit from improved
security. Their devices are less likely to be abused as a vector security. Their devices are less likely to be abused as a vector
to launch other attacks, whether on their own networks, or (as to launch other attacks, whether on their own networks or (as part
part of a botnet) on other Internet hosts. This clearly creates of a botnet) on other Internet hosts. This clearly creates an
an incentive to support and use software updates. incentive to support and use software updates.
- On the other hand updates can also break things. The negative - On the other hand, updates can also break things. The negative
customer experience can be due to service interruptions during or customer experience can be due to service interruptions during or
after the update process but can also result from bad experience after the update process but can also result from bad experience
from deliberate changes introduced as part of an update - such as from deliberate changes introduced as part of an update -- such as
a feature that is not available anymore, or that a "bug" that a feature that is not available anymore, or a "bug" that another
another service has relied upon being fixed. service has relied upon being fixed.
- For most classes of device, there does not seem to be a regulatory - For most classes of device, there does not seem to be a regulatory
requirement to report or fix, vulnerabilities, similar to data requirement to report or fix vulnerabilities, similar to data-
breach notification laws. breach-notification laws.
- Subscription models for device management were suggested so that - Subscription models for device management were suggested so that
companies providing the service have an economic interest in companies providing the service have an economic interest in
keeping devices online (and updated for that). keeping devices online (and updated for that).
7. Measurements and Analysis 7. Measurements and Analysis
From a security point of view it is important to know what devices 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 are out there and what version of software they run. One workshop
paper [plonka] reported measurements with initial done on buggy paper [PLONKA] reported measurements that were initially done on
devices first distributed in 2003 that were still detectable in buggy devices first distributed in 2003, and that were still
significant numbers just before the workshop 13 years later. As detectable in significant numbers just before the workshop 13 years
such, in addition to the firmware update mechanism companies have later. As such, in addition to the firmware update mechanism,
been offering device management solutions that allow OEMs to keep companies have been offering device management solutions that allow
track of their devices. Tracking these devices and their status is OEMs to keep track of their devices. Tracking these devices and
still challenging since some devices are only connect irregularly or their status is still challenging since some devices are only
are only turned on when needed (such as a hockey alarm that is only connected irregularly or are only turned on when needed (such as a
turned on before a match). hockey alarm that is only turned on before a match).
Various stakeholders have a justified interest in knowing something Various stakeholders have a justified interest in knowing something
about deployed devices. For example, about deployed devices. For example:
- Manufacturers and other players in the supply chain are interested - Manufacturers and other players in the supply chain are interested
to know what devices are out there, how many have been sold, what to know what devices are out there, how many have been sold, and
devices are out there but have not been sold. This could help to what devices are out there but have not been sold. This could
understand which firmware versions to support for how long. help to understand which firmware versions to support and for how
long.
- Device users, owners, and customers these may want to know what - Device users, owners, and customers like these may want to know
devices are installed over a longer period of time, what software/ what devices are installed over a longer period of time, what
firmware version is the device running, what is uptime of each of software/firmware version is the device running, what is the
these devices, what types of faults have occurred, etc. Forgotten uptime of each of these devices, what types of faults have
devices may pose problems, particularly if they (have the occurred, etc. Forgotten devices may pose problems, particularly
potential to) behave badly. if they (have the potential to) behave badly.
- To an extent, network operators offering services to device owners - To an extent, network operators offering services to device owners
and other actors may also need similar information, for example to and other actors may also need similar information, for example,
control botnets. to control botnets.
- Researchers doing analysis on the state of the Internet ecosystem - Researchers doing analysis on the state of the Internet ecosystem
(such as what protocols are being used, how much data IoT devices (such as what protocols are being used, how much data IoT devices
generate, etc. need measurements for their work. generate, etc.,) need measurements for their work.
There can easily be some invasiveness in approaches to acquiring such There can easily be some invasiveness in approaches to acquiring such
measurements. The challenge was put forward to find ways to create measurements. The challenge was put forward to find ways to create
measurement infrastructures that are privacy preserving. Arnar measurement infrastructures that are privacy preserving. Arnar
Birgisson noted that there are privacy-preserving statistical Birgisson noted that there are privacy-preserving statistical
techniques, such as RAPPOR [RAPPOR], and Ned Smith added that techniques, such as RAPPOR [RAPPOR], and Ned Smith added that
techniques like Intel's Enhanced Privacy ID (EPID) may play a role in techniques like Intel's Enhanced Privacy ID (EPID) may play a role in
maintaining some level anonymity for the IoT device (owners) while maintaining some level of anonymity for the IoT device (owners) while
also enabling measurement. It seemed clear that naive approaches to also enabling measurement. It seemed clear that naive approaches to
measurement (e.g., where devices are willing to expose a unique measurement (e.g., where devices are willing to expose a unique
identifier to anyone on request) are unlikely to prove sufficient. identifier to anyone on request) are unlikely to prove sufficient.
8. Firmware Distribution in Mesh Networks 8. Firmware Distribution in Mesh Networks
There was some discussion of the requirements for mesh-based There was some discussion of the requirements for mesh-based
networks, mainly relating to industrial lighting. In these networks, networks, mainly relating to industrial lighting. In these networks,
software update can impose unacceptable performance burdens, software update can impose unacceptable performance burdens,
especially if there are many devices, some of which may be are especially if there are many devices, some of which may be sleepy.
sleepy.
The workshop discussed whether some forms of multicast (perhaps not The workshop discussed whether some forms of multicast (perhaps not
IP multicast) would be needed to provide acceptable solutions for IP multicast) would be needed to provide acceptable solutions for
software update in such cases. It was not clear at which layer a software update in such cases. It was not clear at which layer a
multi-cast solution might be effective in such cases, though there multicast solution might be effective in such cases, though there did
did seem to be no clearly applicable standards-based approach that not seem to be any clearly applicable standards-based approach that
was available at the time of the workshop. was available at the time of the workshop.
9. Compromised Devices 9. Compromised Devices
There was a recognition that there are, and perhaps always will be, There was recognition that there are, and perhaps always will be,
large numbers of devices that can be, or have been compromised. large numbers of devices that can be, or have been, compromised.
While updating these can mitigate problems, there will always be new While updating these can mitigate problems, there will always be new
devices added to networks that cannot be updated (for various devices added to networks that cannot be updated (for various
reasons) so the question of what, if anything, to do about reasons); so the question of what, if anything, to do about
compromised devices was discussed. compromised devices was discussed.
- There may be value if it were possible to single out a device, - There may be value if it were possible to single out a device that
which shows faulty behavior or has been compromised, and to shut shows faulty behavior or has been compromised, and to shut it down
that down in some sense. in some sense.
- Prior work in the IETF on Network Endpoint Assessment (NEA) [NEA] - Prior work in the IETF on Network Endpoint Assessment (NEA) [NEA]
allowed assessing the "posture" of devices. Posture refers to the allowed assessing the "posture" of devices. Posture refers to the
hardware or software configuration of a device and may include hardware or software configuration of a device and may include
knowledge that software installed is up-to-date. The obtained knowledge that the software installed is up to date. The obtained
information can then be used by some network infrastructure to information can then be used by some network infrastructure to
create a quarantined region network around the device. create a quarantined region network around the device.
- RFC 6561 [RFC6561] describes one scheme for an ISP to send - RFC 6561 [RFC6561] describes one scheme for an ISP to send
"signals" to customers about hosts (usually those that are part of "signals" to customers about hosts (usually those that are part of
a botnets or generating spam) in their home network. a botnet or generating spam) in their home network.
- Neither RFC 6561 nor NEA has found widespread deployment. Whether - Neither RFC 6561 nor NEA has found widespread deployment. Whether
such mechanisms can be more successful in the IoT environment has such mechanisms can be more successful in the IoT environment has
yet to be studied. yet to be studied.
The conclusion of the discussion at the workshop itself was that The conclusion of the discussion at the workshop itself was that
there is some interest to identify and stop misbehaving devices but there is some interest in identifying and stopping misbehaving
the actual solution mechanisms are unclear. devices, but the actual solution mechanisms are unclear.
10. Miscellaneous Points 10. Miscellaneous Points
There were a number of points discussed at the workshop that don't There were a number of points discussed at the workshop that don't
neatly fit under the above headings but that are worth recording. neatly fit under the above headings but that are worth recording.
Those included: Those include:
- Complex questions can arise when considering the impact of the - Complex questions can arise when considering the impact of the
lack of updates on other devices, other persons, or the public in lack of updates on other devices, other persons, or the public in
general. If I don't update my device and that is used to attack a general. If I don't update my device, and it is used to attack a
random host on the Internet, then what incentive do I have to do random host on the Internet, but at no apparent cost to me, then
updates? What incentive has my device's vendor to have done that what incentive do I have to do updates that would have protected
in advance? An example of such a case can be found in DDoS that random host? What incentive has my device's vendor to have
attacks from IoT devices, such as printers [SNMP-DDOS] and cameras provided those updates in advance? An example of such a case can
[DDOS-KREBS]. be found in DDoS attacks from IoT devices, such as printers
[SNMP-DDOS] and cameras [DDOS-KREBS].
- With some IoT devices there are many stakeholders contributing to - With some IoT devices, there are many stakeholders contributing to
the end product (e.g., contributing different subsystems) and the end product (e.g., contributing different subsystems).
ensuring that vulnerabilities are fixed and software/firmware Ensuring that vulnerabilities are fixed and software/firmware
updates are communicated through the value chain is known to be updates are communicated through the value chain is known to be
difficult, as demonstrated in [OS14]. difficult, as demonstrated in [OS14].
- What about forgotten devices? There are many such, and will be - What about forgotten devices? There are many such, and there will
more. Even though they are forgotten, such devices may be useless be more. Even though they are forgotten, such devices may be
consumers of electricity, or may be part of some critical system. useless consumers of electricity, or they may be part of some
critical system.
- Can we determine whether an update impacts other devices in the - Can we determine whether an update impacts other devices in the
Internet? Updates to one device can have unintended impact on Internet? Updates to one device can have unintended impact on
other devices that depend on it. This can have cascading effects other devices that depend on it. This can have cascading effects
if we are not careful. Changing the format of the output of a if we are not careful. Changing the format of the output of a
sensor could have cascading impacts, e.g., if some actuator reacts sensor could have cascading impacts, e.g., if some actuator reacts
to the presence/absence of that sensor's data. to the presence/absence of that sensor's data.
- How should a device behave when it is running out-of-date - How should a device behave when it is running out-of-date
software. The example of a smoke alarm was mentioned. We don't software? The example of a smoke alarm was mentioned. We don't
want 100 devices in a living room to start beeping when their want 100 devices in a living room to start beeping when their
batteries run low or when they cannot communicate with the cloud. batteries run low or when they cannot communicate with the cloud.
But are devices supposed to simply stop working? But are devices supposed to simply stop working?
- The IETF has published a specification that uses the Cryptographic - The IETF has published a specification that uses the Cryptographic
Message Syntax (CMS) to protect firmware packages, as described in Message Syntax (CMS) to protect firmware packages, as described in
RFC 4108 [RFC4108], which also contains meta-data to describe the RFC 4108 [RFC4108], which also contains metadata to describe the
firmware image itself. During the workshop the question was firmware image itself. During the workshop, the question was
raised whether a solution will in future be needed that is post- raised whether a solution will, in the future, be needed that is
quantum secure. A post-quantum cryptosystem is a system that is post-quantum secure. A post-quantum cryptosystem is a system that
secure against quantum computers that have more than a trivial is secure against quantum computers that have more than a trivial
number of quantum bits. It is open to conjecture whether it is number of quantum bits. It is open to conjecture whether it is
feasible to build such a machine but current signature algorithms feasible to build such a machine, but current signature algorithms
are known to not be post-quantum secure. This would require are known not to be post-quantum secure. This would require
introducing technologies like the Hash-based Merkle Tree Signature introducing technologies like the Hash-based Merkle Tree Signature
(MTS) [housley-cms-mts-hash-sig], which was presented and (MTS) [HOUSLEY], which was presented and discussed at the
discussed at the workshop. The downside of such solutions are, workshop. The downsides of such solutions are their novelty and,
their novelty, and for these use-cases, the fairly large signature for these use cases, the fairly large signature or key sizes
or key sizes involved, e.g., depending on the parameters a involved; e.g., depending on the parameters, a signature could
signature could easily have a size of 5-10KiB [hashsig]. While it easily have a size of 5-10 KiB [HASHSIG] [XMSS]. While it is
is likely that post-quantum secure signature algorithms will be likely that post-quantum secure signature algorithms will be
needed for software update at some point in time, it may be the needed for software updates at some point in time, it may be the
case that such algorithms will be needed sooner for services case that such algorithms will be needed sooner for services
requiring long term confidentiality, (e.g., using TLS) so it was requiring long-term confidentiality, (e.g., using Transport Layer
not clear that this application would be a first-mover in terms of Security (TLS)), so it was not clear that this application would
post-quantum security. be a first-mover in terms of post-quantum security.
- Many devices that use certificates do not check the revocation - Many devices that use certificates do not check the revocation
status of certificates, even though extensions like OSCP stapling status of certificates, even though extensions like Online
exists [RFC6961] and is increasingly deployed with Web browsers. Certificate Status Protocol (OCSP) stapling exists [RFC6961] and
The workshop participants were inconclusive regarding the is increasingly deployed with Web browsers. The workshop
recommendations of certificate revocation checking although the participants did not reach a conclusion regarding the
importance has been recognized. The reluctance of deploying recommendations of certificate revocation checking, although the
certificate revocation deserves further investigations. importance has been recognized. The reluctance regarding
deploying certificate revocation deserves further investigation.
11. Tentative Conclusions and Next Steps 11. Tentative Conclusions and Next Steps
The workshop participants discussed some tentative conclusions and The workshop participants discussed some tentative conclusions and
possible next steps: possible next steps:
- There was good agreement that having some standardized secure - There was strong agreement that having some standardized secure
(authorized and authenticated) software update would be an (authorized and authenticated) software update would be an
improvement over having none. improvement over having none.
- It would be valuable to find agreement on the right scope for a - It would be valuable to find agreement on the right scope for a
standardized software/firmware update mechanism. It is not clear standardized software/firmware update mechanism. It is not clear
that an entire update system can or should be standardised but that an entire update system can or should be standardized, but
there may be some aspects of such solutions where standards would there may be some aspects of such solutions where standards would
be beneficial, e.g., (meta-)data formats and/or protocols for be beneficial, e.g., (meta-)data formats and/or protocols for
distributing firmware updates. More discussion is needed to distributing firmware updates. More discussion is needed to
identify which parts of the problem space could benefit from identify which parts of the problem space could benefit from
standardisation. standardization.
- It will be useful to investigate solutions to install updates with - It will be useful to investigate solutions to install updates with
no operation interruption as well as ways to distribute software no operational interruption as well as ways to distribute software
updates without disrupting network operations (specifically in updates without disrupting network operations (specifically, in
low-power wireless networks), including the development of a low-power wireless networks), including the development of a
multicast transfer mechanism (with appropriate security). multicast transfer mechanism (with appropriate security).
- There will almost certainly be a need for a way to transfer - There will almost certainly be a need for a way to transfer
authority/responsibility for updates, particularly considering authority/responsibility for updates, particularly considering
end-of-support cases. This is very close to calling for a end-of-support cases. This is very close to calling for a
standard way to "root" devices as a feature of all devices. standard way to "root" devices as a feature of all devices.
- We would benefit from documentation of proofs-of-concept of - We would benefit from documentation of proofs-of-concept of
software/firmware updates for constrained devices on different software/firmware updates for constrained devices on different
operating system architectures. The IETF Light-Weight operating system architectures. The IETF Light-Weight
Implementation Guidance (lwig) working group may be a good venue Implementation Guidance (lwig) Working Group may be a good venue
for such documents. for such documents.
12. Security Considerations 12. Security Considerations
This document summarizes an IAB workshop on software/firmware updates This document summarizes an IAB workshop on software/firmware updates
and the entire content is therefore security related. Standardizing and the entire content is, therefore, security related.
and deploying a software/firmware update mechanism for use with IoT Standardizing and deploying a software/firmware update mechanism for
devices could help to fix security vulnerabilities faster and in some use with IoT devices could help fix security vulnerabilities faster
cases the only via to get vulnerability patched at all. and, in some cases, be the only via to get vulnerability patched at
all.
13. IANA Considerations 13. IANA Considerations
This document does not contain any requests to IANA. This document does not require any IANA actions.
14. Acknowledgements 14. Informative References
We would like to thank all paper authors and participants for their [BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart
contributions. The IoTSU workshop is co-sponsored by the Internet Homes Could Be", April 2014,
Architecture Board and the Science Foundation Ireland funded CONNECT <http://www.wired.com/2015/04/smart-home-headaches/>.
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 [BS14] Schneier, B., "The Internet of Things Is Wildly Insecure
-- And Often Unpatchable", January 2014,
<https://www.schneier.com/essays/archives/2014/01/
the_internet_of_thin.html>.
[BSDIFF] Percival, C., "Matching with Mismatches and Assorted
Applications", September 2016,
<https://ora.ox.ac.uk/objects/
uuid:4f0d53cc-fb9f-4246-a835-3c8734eba735/datastreams/
THESIS01>.
[COURGETTE]
Google, "Software Updates: Courgette", September 2016,
<https://www.chromium.org/developers/design-documents/
software-updates-courgette>.
[DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[EYEFI] Aldred, J., "Eye-Fi to Drop Suport for Some Cards. They
Will 'Magically' Stop Working on September 16, 2016", June
2016, <http://www.diyphotography.net/eyefi-drop-support-
cards-will-magically-stop-working-september-16-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,
<https://www.ftc.gov/system/files/documents/reports/
federal-trade-commission-staff-report-november-2013-
workshop-entitled-internet-things-
privacy/150127iotrpt.pdf>.
[HASHSIG] Langley, A., "Hash based signatures", July 2013,
<https://www.imperialviolet.org/2013/07/18/hashsig.html>.
[HOUSLEY] Housley, R., "Use of the Hash-based Merkle Tree Signature
(MTS) Algorithm in the Cryptographic Message Syntax
(CMS)", Work in Progress, draft-housley-cms-mts-hash-
sig-07, June 2017.
[HP-Firmware]
BoingBoing, "HP detonates its timebomb: printers stop
accepting third party ink en masse", September 2016,
<http://boingboing.net/2016/09/19/
hp-detonates-its-timebomb-pri.html>.
[IoTSU] IAB, "Internet of Things Software Update Workshop (IoTSU)
2016", June 2016,
<https://www.iab.org/activities/workshops/iotsu/>.
[LittlePrinter]
Berg, "The future of Little Printer", September 2014,
<http://littleprinterblog.tumblr.com/post/97047976103/
the-future-of-little-printer>.
[NEA] IETF, "Network Endpoint Assessment (nea) Concluded WG",
October 2016,
<https://datatracker.ietf.org/wg/nea/charter/>.
[OS-Support]
Dong, W., Chen, C., Liu, X., and J. Bu, "Providing OS
Support for Wireless Sensor Networks: Challenges and
Approaches", DOI 10.1109/SURV.2010.032610.00045, May 2010,
<http://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=5462978>.
[OS14] Oppenheim, L. and S. Tal, "Too Many Cooks: Exploiting the
Internet of TR-069 Things", December 2014,
<http://mis.fortunecook.ie/
too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf>.
[PACMAN] "pacman", 2016, <https://www.archlinux.org/pacman/>.
[PLONKA] Plonka, D. and E. Boschi, "The Internet of Things Old and
Unmanaged", June 2016,
<https://down.dsg.cs.tcd.ie/iotsu/subs/
IoTSU_2016_paper_25.pdf>.
[RAPPOR] Erlingsson, U., Pihur, V., and A. Korolova, "RAPPOR",
DOI 10.1145/2660267.2660348, July 2014,
<http://dl.acm.org/citation.cfm?doid=2660267.2660348>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005,
<https://www.rfc-editor.org/info/rfc4108>.
[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,
<https://www.rfc-editor.org/info/rfc6561>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[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,
<https://www.rfc-editor.org/info/rfc6973>.
[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, <https://www.rfc-editor.org/info/rfc7406>.
[RPM] "Red Hat Package Manager (RPM)", 2016, <http://rpm.org/>.
[RT] Google, "Roughtime", September 2016,
<https://roughtime.googlesource.com/roughtime>.
[SNMP-DDOS]
BITAG, "SNMP Reflected Amplification DDoS Attack
Mitigation", August 2012,
<https://www.bitag.org/documents/
SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf>.
[WP29] Article 29 Data Protection Working Party, "Opinion 8/2014
on the on Recent Developments on the Internet of Things",
14/EN, WP 223, September 2014,
<http://ec.europa.eu/justice/data-protection/article-
29/documentation/opinion-recommendation/files/2014/
wp223_en.pdf>.
[XMSS] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: Extended Hash-Based Signatures", Work in
Progress, draft-irtf-cfrg-xmss-hash-based-signatures-10,
July 2017.
Appendix A. Program Committee
The following individuals helped to organize the workshop: Jari The following individuals helped to organize the workshop: Jari
Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ Arkko, Arnar Birgisson, Carsten Bormann, Stephen Farrell, Russ
Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig. Housley, Ned Smith, Robert Sparks, and Hannes Tschofenig.
16. Appendix B: Accepted Position Papers Appendix B. Accepted Position Papers
The list of accepted position papers is below. Links to these, and The list of accepted position papers is below. Links to these, and
to the workshop agenda and raw minutes are accessible at: to the workshop agenda and raw minutes are accessible at:
<https://down.dsg.cs.tcd.ie/iotsu/>. <https://down.dsg.cs.tcd.ie/iotsu/>.
- R. Housley, 'Position Paper for Internet of Things Software - R. Housley, "Position Paper for Internet of Things Software Update
Update Workshop (IoTSU)' Workshop (IoTSU)"
- D. Thomas and A. Beresford, 'Incentivising software updates' - D. Thomas and A. Beresford, "Incentivising software updates"
- L. Zappaterra and E. Dijk, Software Updates for Wireless
- L. Zappaterra and E. Dijk, "Software Updates for Wireless
Connected Lighting Systems: requirements, challenges and Connected Lighting Systems: requirements, challenges and
recommendations' recommendations"
- M. Orehek and A. Zugenmaier, 'Updates in IoT are more than just - M. Orehek and A. Zugenmaier, "Updates in IoT are more than just
one iota' one iota"
- D. Plonka and E. Boschi, 'The Internet of Things Old and - D. Plonka and E. Boschi, "The Internet of Things Old and
Unmanaged' Unmanaged"
- D. Bosschaert, 'Using OSGi for an extensible, updatable and - D. Bosschaert, "Using OSGi for an extensible, updatable and future
future proof IoT' proof IoT"
- A. Padilla, E. Baccelli, T. Eichinger and K. Schleiser, 'The - A. Padilla, E. Baccelli, T. Eichinger, and K. Schleiser, "The
Future of IoT Software Must be Updated' Future of IoT Software Must be Updated"
- T. Hardie, 'Software Update in a multi-system Internet of Things' - T. Hardie, "Software Update in a multi-system Internet of Things"
- R. Sparks and B. Campbell, 'Avoiding the Obsolete-Thing Event - R. Sparks and B. Campbell, "Avoiding the Obsolete-Thing Event
Horizon' Horizon"
- J. Karkov, 'SW update for Long lived products' - J. Karkov, "SW update for Long lived products"
- S. Farrell, 'Some Software Update Requirements' - S. Farrell, "Some Software Update Requirements"
- S. Chakrabarti, 'Internet Of Things Software Update Challenges: - S. Chakrabarti, "Internet Of Things Software Update Challenges:
Ownership, Software Security & Services' Ownership, Software Security & Services"
- M. Kovatsch, A. Scholz, and J. Hund, 'Why Software Updates Are - M. Kovatsch, A. Scholz, and J. Hund, "Why Software Updates Are
More Than a Security Issue' More Than a Security Issue: Challenges for IETF CoRE and the W3C
Web of Things"
- A. Grau, 'Secure Software Updates for IoT Devices' - A. Grau, "Secure Software Updates for IoT Devices"
- Birr-Pixton, Electric Imp's experiences of upgrading half a - Birr-Pixton, "Electric Imp's experiences of upgrading half a
million embedded devices' million embedded devices"
- Y. Zhang, J. Yin, C. Groves, and M. Patel, 'oneM2M device - Y. Zhang, J. Yin, C. Groves, and M. Patel, "oneM2M device
management and software/firmware update' management and software/firmware update"
- E. Smith, M. Stitt, R. Ensink, and K. Jager, 'User Experience - E. Smith, M. Stitt, R. Ensink, and K. Jager, "User Experience (UX)
(UX) Centric IoT Software Update' Centric IoT Software Update"
- J.-P. Fassino, E.A. Moktad, J.-M. Brun, 'Secure Firmware Update - J.-P. Fassino, E.A. Moktad, and J.-M. Brun, "Secure Firmware
in Schneider Electric IOT-enabled offers' Update in Schneider Electric IOT-enabled offers"
- M. Orehek, 'Summary of existing firmware update strategies for - M. Orehek, "Summary of existing firmware update strategies for
deeply embedded systems' deeply embedded systems"
- N. Smith, 'Toward A Common Modeling Standard for Software Update - N. Smith, "Toward A Common Modeling Standard for Software Update
and IoT Objects' and IoT Objects"
- S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, 'Secure - S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, "Secure
Firmware Update Over the Air in the Internet of Things Focusing on Firmware Update Over the Air in the Internet of Things Focusing on
Flexibility and Feasibility' Flexibility and Feasibility"
- A. Adomnicai, J. Fournier, L. Masson, and A. Tria, 'How - A. Adomnicai, J. Fournier, L. Masson, and A. Tria, "How careful
careful should we be when implementing cryptography for software should we be when implementing cryptography for software update
update mechanisms in the IoT?' mechanisms in the IoT?"
- V. Prevelakis and H. Hamad, 'Controlling Change via Policy - V. Prevelakis and H. Hamad, "Controlling Change via Policy
Contracts' Contracts"
- H. Birkholz, N. Cam-Winget and C. Bormann, 'IoT Software - H. Birkholz, N. Cam-Winget, and C. Bormann, "IoT Software Updates
Updates need Security Automation' need Security Automation"
- R. Bisewski, 'Comparative Analysis of Distributed Repository - R. Bisewski, "Comparative Analysis of Distributed Repository
Update Methodology and How CoAP-like Update Methods Could Update Methodology and How CoAP-like Update Methods Could
Alleviate Internet Strain for Devices that Constitute the Internet Alleviate Internet Strain for Devices that Constitute the Internet
of Things' of Things"
- J. Arrko, 'Architectural Considerations with Smart Objects and - J. Arrko, "Architectural Considerations with Smart Objects and
Software Updates' Software Updates"
- J. Jimenez and M. Ocak, 'Software Update Experiences for IoT' - J. Jimenez and M. Ocak, "Software Update Experiences for IoT"
- H. Tschofenig, 'Software and Firmware Updates with the OMA LWM2M - H. Tschofenig, "Software and Firmware Updates with the OMA LWM2M
Protocol' Protocol"
17. Appendix C: List of Participants Appendix C. List of Participants
- Arnar Birgisson, Google - Arnar Birgisson, Google
- Alan Grau, IconLabs - Alan Grau, IconLabs
- Alexandre Adomnicai, Trusted Objects - Alexandre Adomnicai, Trusted Objects
- Alf Zugenmaier, Munich University of Applied Science - Alf Zugenmaier, Munich University of Applied Science
- Ben Campbell, Oracle - Ben Campbell, Oracle
skipping to change at page 23, line 5 skipping to change at page 27, line 20
- Russ Housley, Vigil Security - Russ Housley, Vigil Security
- Samita Chakrabarti, Ericsson - Samita Chakrabarti, Ericsson
- Stephen Farrell, Trinity College Dublin - Stephen Farrell, Trinity College Dublin
- Vassilis Prevelakis, TU Braunschweig - Vassilis Prevelakis, TU Braunschweig
- Hannes Tschofenig, ARM Ltd. - Hannes Tschofenig, ARM Ltd.
18. Informative References Acknowledgements
[BB14] Barrett, B., "Winks Outage Shows Us How Frustrating Smart
Homes Could Be", April 2014,
<http://www.wired.com/2015/04/smart-home-headaches/>.
[BS14] Schneier, B., "The Internet of Things Is Wildly Insecure
And Often Unpatchable", January 2014,
<https://www.schneier.com/essays/archives/2014/01/
the_internet_of_thin.html>.
[bsdiff] Percival, C., "Binary diff/patch utility", September 2016,
<http://www.daemonology.net/bsdiff/>.
[courgette]
Google, "Software Updates - Courgette", September 2016,
<https://www.chromium.org/developers/design-documents/
software-updates-courgette>.
[DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[eyefi] Aldred, J., "EYEFI TO DROP SUPPORT FOR SOME CARDS. THEY
WILL 'MAGICALLY' STOP WORKING ON SEPTEMBER 16, 2016", June
2016, <http://www.diyphotography.net/eyefi-drop-support-
cards-will-magically-stop-working-september-16-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,
<https://www.ftc.gov/news-events/press-releases/2015/01/
ftc-report-internet-things-urges-companies-adopt-best-
practices>.
[hashsig] Langley, A., "Hash based signatures", July 2013,
<https://www.imperialviolet.org/2013/07/18/hashsig.html>.
[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, <https://tools.ietf.org/html/draft-
housley-cms-mts-hash-sig-04>.
[HP-Firmware]
BoingBoing, "HP detonates its timebomb - printers stop
accepting third party ink en masse", September 2016,
<http://boingboing.net/2016/09/19/
hp-detonates-its-timebomb-pri.html>.
[IoTSU] IAB, "Internet of Things Software Update Workshop
(IoTSU)", June 2016,
<https://www.iab.org/activities/workshops/iotsu/>.
[LittlePrinter]
Berg, "The future of Little Printer", September 2014,
<http://littleprinterblog.tumblr.com/post/97047976103/
the-future-of-little-printer>.
[NEA] IETF, "Network Endpoint Assessment (nea) (Concluded
Working Group)", 2016,
<https://datatracker.ietf.org/wg/nea/charter/>.
[OS-Support]
Dong, W., Chen, C., Liu, X., and J. Bu, "Providing OS
Support for Wireless Sensor Networks - Challenges and
Approaches", May 2010, <http://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=5462978>.
[OS14] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the
Internet-of-TR-069-Things", December 2014,
<http://mis.fortunecook.ie/
too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf>.
[pacman] -, "Pacman", 2016, <https://www.archlinux.org/pacman/>.
[plonka] Plonka, D. and E. Boschi, "The Internet of Things Old and
Unmanage", June 2016,
<https://down.dsg.cs.tcd.ie/iotsu/subs/
IoTSU_2016_paper_25.pdf>.
[RAPPOR] Erlingsson, U., Pihur, V., and A. Korolova, "RAPPOR", July
2014, <https://github.com/google/rappor>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005,
<http://www.rfc-editor.org/info/rfc4108>.
[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,
<http://www.rfc-editor.org/info/rfc6561>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[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,
<http://www.rfc-editor.org/info/rfc6973>.
[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, <http://www.rfc-editor.org/info/rfc7406>.
[rpm] -, "Red Hat Package Manager (RPM)", 2016,
<http://rpm.org/>.
[RT] Google, "Roughtime", September 2016,
<https://roughtime.googlesource.com/roughtime>.
[SNMP-DDOS]
BITAG, "SNMP Reflected Amplification DDoS Attack
Mitigation", August 2012,
<https://www.bitag.org/documents/SNMP-Reflected-
Amplification-DDoS-Attack-Mitigation.pdf>.
[WP29] Article 29 Data Protection Working Party, "Opinion 8/2014 We would like to thank all paper authors and participants for their
on the on Recent Developments on the Internet of Things", contributions. The IoTSU workshop is co-sponsored by the Internet
September 2014, <http://ec.europa.eu/justice/data- Architecture Board and the Science Foundation Ireland funded CONNECT
protection/article-29/documentation/opinion- Centre for future networks and communications. The program committee
recommendation/files/2014/wp223_en.pdf>. would like to express their thanks to Comcast for sponsoring the
social event.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
ARM Limited ARM Limited
EMail: hannes.tschofenig@gmx.net Email: hannes.tschofenig@gmx.net
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 189 change blocks. 
586 lines changed or deleted 604 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/