draft-iab-iotsu-workshop-latest.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-iab-iotsu-workshop-01.txt" category="info">

  <front>
    <title abbrev="IoTSU Report">Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016</title>

    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>ARM Limited</organization>
      <address>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>

<author fullname="Stephen Farrell" initials="S." surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>

    <date/>

    
    
    <keyword>Internet-Draft, Security, Firmware Updates, Software Updates, Internet of Things</keyword>

    <abstract>


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



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">


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

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

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

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

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

<t>Amongst the challenges in designing a basic software/firmware update function
are: 
<list style="symbols">

<t>Implementations of
software update mechanisms may incorporate
vulnerabilities becoming an attractive attack target, see for example <xref target="OS14"/>, 
</t>

<t>Operational
challenges such as the case of an expired certificate in a hub device <xref
target="BB14"/>,
</t>

<t>Privacy issues if devices "call home" often to check for updates</t>

<t>A lack of incentives to distribute software updates along the value
chain</t>

<t>Who should be able to update device software after normal support
stops? When should an alternate source of software updates take over?</t>

</list>
</t>

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

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

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

<t><list style="symbols">
  <t>Protocol mechanisms for distributing software updates.</t>
  <t>Mechanisms for securing software updates.</t>
  <t>Meta-data about software / firmware packages.</t>
  <t>Implications of operating system and hardware design on the software update mechanisms.</t>
  <t>Installation of software updates (in context of software and hardware security of IoT devices).</t>
  <t>Privacy implications of software update mechanisms.</t>
  <t>Implications of device ownership and control for software update.</t>
</list></t>

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

</section>
<section anchor="terminology" title="Terminology">

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

<t><list style="hanging">

  <t hangText='Device Classes:'> IoT devices come in various "sizes"
(such as size of RAM, or size of flash memory). With these configurations
devices are limited in what they can support in terms of operating system
features, cryptographic algorithms, and protocol stacks. For this reason, the
group differentiated two types of classes, namely ARM Cortex A-class / Intel
Atom and Cortex M-class / Intel Quark types of devices. A-class devices are
equipped with powerful processors typically found in set-top boxes and home
routers. The Raspberry Pi is an example of a A-class device, which is capable of
running a regular desktop operating system, such as Linux. There are differences
between the Intel and the ARM-based CPUs in terms of architecture, micro-code and who is allowed to
update a BIOS (if available) and the micro-code. A detailed discussion of these
hardware architectural differences were, however, outside the scope of the
workshop. The implication is that lower-end microcontrollers have 
constraints that put restrictions on the amount of software that can be put on them.
While it is easy require support of a wide range of features those may not necessarily fit on these devices.</t>

  <t hangText='Software Update and Firmware Update:'> Based on the device
classes it was observed that regular operating systems come with
sophisticated software update mechanisms (such as RPM <xref target="rpm"/> or 
Pacman <xref target="pacman"/>) that make use
of the operating system to install and run each application in a
compartmentalized fashion. Firmware updates typically do not provide such a
fine-grained granularity for software updates and instead distribute the entire
binary image, which consists of the (often minimalistic) operating system and
all applications. While the distinction between the mechanisms A-class and M-class
devices will typically use may get more fuzzy over time, most M-class devices use
firmware updates and A-class devices use a combination of firmware and software
updates (with firmware updates being less frequent operations).</t>

  <t hangText='Hitless Update:'> 

A hitless update implies that the user experience is not “hit”, i.e., it is not impacted.  
It is possible to impact the user experience when applying an update even when the 
device does not reboot (to obtain or apply said update). If the update is applied when
a user is not using a product and their service is not impacted, the update is “hitless".</t> 

<!-- 
<t hangText="Device Reboot:"> 

After a new software or firmware image has been distributed, the question arises 
whether the device has to be restarted or not. For many desktop, smart phones and tablets new software
updates do not require a restart when new applications are installed while
changes to the underlying operating system often require a restart. For
embedded devices a firmware update often requires a device reboot since it is
also the easiest way to get the device into a clean state. </t>
--> 
</list></t>

</section>

<section anchor="requirements" title="Requirements and Questions Arising">

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

<t><list style="symbols">

  <t>There may be a need to be support partial (differential) updates, that
do not require the entire firmware image to be sent. This may mean that techniques like bsdiff 
<xref target="bsdiff"/> and courgette <xref target="courgette"/> are used but might
also mean devices supporting download of applications and libraries alone. The
latter feature may require dynamic linking and position independent code. 
It was unclear whether position independent code should be recommended for low-end IoT
devices.</t>

  <t>The relative importance of dynamic linkers for low-end IoT devices is unclear. Some operating
systems used with M-class devices, such as Contiki, provide support for a
dynamic linker according to <xref target="OS-Support"/>. This could help to
minimize the amount of data transmitted during updates since only the
modified application or library needs to be transmitted.</t>

  <t>How should dependencies among various software updates be handled? 
These dependencies may include information about the hardware platform
and configuration as well as other software components
running on a system. For firmware updates the problem of dependencies are often solved by the manufacturer or OEM 
rather than on the device itself.</t>

  <t>Support for devices with multiple micro-controllers may required an architecture where one
micro-controller is responsible for interacting with the update service and then
dispatching software images to the attached micro-controllers within its local
realm. The alternative of letting each microcontroller interact with an update service 
appeared less practical.</t>

  <t>Support may be required for devices with multiple owners/stakeholders where the question
arises about who is authorized to push a firmware/software update.</t>

  <t>Data origin authentication (DAO) was agreed to be required for software
updates. Without DAO, updates simply become a perfect vulnerability. 
It is however non-trivial to ensure the actual trust relationships that exist
are modelled by the DAO mechanism. For some devices and deployment
scenarios, any DAO mechanism is onerous, possibly to the point where
it may be hard to convince a device-maker to include the functionality.</t>

  <t>Should digital signatures and encryption for software updates be
recommended as a best current practice? This question particualrly raises the question
about the use of symmetric key cryptography since not all low end IoT devices
are currently using asymmetric crypto.</t>

<t>
DAO
is most commonly provided via digital signature mechanisms, but
symmetric schemes could also be developed, though IETF discussion of
such mechanisms (for purposes less sensitive than software update) has
proved significantly controversial. The main 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 specific sender.
And with software update, we do not want any (possibly compromised)
device to be able to be authenticate new software for all other
similar devices.
</t>

  <t>What are the firmware update signing key requirements? Since devices have a rather long
lifetime there has to be a way to change the signing key during the lifetime of
the device.</t>

  <t>Should a firmware update mechanism support multiple signatures of firmware
images? Multiple signatures can come in two different flavours, namely <list style="number"> 
<t>a
single firmware image may be signed by multiple different parties. In this case one could imagine an environment where an 
Original Equipment Manufacturer (OEM) 
signs the software it creates but then the software is again signed by the
enterprise that approves the distribution within the company. 
Other examples include regulatory
signatures where a the software for a medical device may be signed as approved by a certification body.</t>
<t>a
software image may contain libraries that are each signed by their
developers.</t> 
</list>  

Is a device expected to verify the different types of signatures
or is this rather a service provided by some
non-constrained device? This raises the question about who the IoT device
should trust for what and whether transitive trust is acceptable for some types of
devices? </t>

<t>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 that only supports/runs
software from the OEM then a single signature may be sufficient.  In any more
“open” system, 3rd party applications may require support of multiple
signatures.</t> 

  <t>There is a need for some form of secure storage, at least for those IoT devices that are exposed 
to physical attacks. This 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 in use). The use of symmetric key cryptography requires improved confidentiality protection (in addition to integrity protection).
</t>

  <t>Is there a need to
allow the update infrastructure-side to authenticate the IoT device before
distributing an update? Questions about the identifier used for such an
authentication action were raised. The idea of re-use MAC addresses lead 
to concerns about the significant privacy implications of such
identifier re-use.</t>

  <t>It is important to minimize device/service downtime due to update processing, minimize user interaction 
(e.g., car should not distract the driver) (see hitless updates). 
While it may not be possible to avoid all downtime,
there was agreement that one ought strive for “no inappropriate” device downtime. This means
minimal downtime impacting the user/operation of the device.  
The definition of “downtime” also depends on the use case,
with a smart light bulb, the device could be "up" if the light is still on, even
if some advanced services are unavailable for a short time.  
Whether an update can be done
without rebooting the device depends on the software being
installed, on the OS architecture, and potentially even on the hardware
architecture. The cost/benefit ratio also plays a role. 
</t>

<t>
It is desirable to minimise the time taken from the 
start of the update to when  it is finished.
In some systems with many devices (e.g., industrial lighting) this
can be a challenge if updates need to be unicasted. 
</t>

<t>In some systems
with multiple devices, it can be a challenge to ensure that all
devices are at the same release level, especially if some devices
are sleepy. There are some systems where ensuring all relevant
devices are at the same release level is a hard-requirement. In
other cases, it is acceptable if devices converge much more slowly to the
current release level.
</t>



<!-- 
SF: I don't recall this being presented? And I'm not even sure
what'd be needed from the net that could interfere with the
production line?

  <t>During the manufacturing process it is preferable to 
not depend on Internet connectivity that could stall the factory in failure
cases. In one
presented solution HTTP with the caching capabilities was used in the factory
to avoid creating such a dependency. </t>
-->

<t>It ought not be possible
for a factory worker to compromise the update process (e.g., copy signing keys,
install unauthorized public keys/trust anchors) during the 
manufacturing process. There
are typically two factories involved, first the factory that produces
microcontrollers and other components. The second factory produces the complete
product, such as a fridge. This fridge contains many of the components
previously manufactured. Hence, the firmware of components produced in the
first stage may be 6 month old when the fridge leaves the factory. One does not
want to install a firmware update when the fridge boots the first time. For
that time the firmware update happens already at the end of the manufacturing
process.</t>

  <t>Should devices have a recovery procedure when the device gets compromised?
How is the compromise detected?</t>

  <t>There was a bit of discussion about the importance for IoT devices to know the current time for the purpose of checking certificate validity. For example, what does “real-time clock” (RTC) actually mean? And what constitute ‘good enough’ time? There are, however, cost, power, size, and environmental constraints that 
can make the addition of a real-time clock to an IoT device complex: 

<list style="symbols"> 
<t>Cost: battery- or supercap-backed RTC modules might be several times the cost of the rest of the bill of materials.</t>
<t>Size: the battery and other components are often several times larger than the rest of the material. </t>
<t>Manufacturing: some modules require an extra assembly step, because the battery could be damaged/explodes at high temperature during the reflow process.</t>
<t>Supply chain: devices containing fitted batteries need additional supply chain management to account for storage temperature and to avoid shipping aged devices.</t>
<t>Environmental: Real-time-clock modules are typically not rated at industrial temperature ranges. Those that are have extremely reduced lifetime at high temperatures.</t>
<t>Lifetime: some of these modules last only a few years at the top of their environmental range.</t> 
</list> 

While a good solution is needed, it is not clear whether there is one true solution. A recent proposal from Google called Roughtime <xref target="RT"/> may be worthwhile to explore.</t>

  <t>How do devices learn about a firmware update? Push or Pull? What should be
required functionality for a firmware update protocol?</t>

  <t>There is a need to find out whether a software update was successful.  In
one discussed solution the bootloader analyses the performance of the running
image to determine which image to run (rather than just verifying the integrity
of the received image).  One of the key criteria is that the  updated system is
able to make a connection to the device management/software update
infrastructure. As long as it is able to talk to the update infrastructure it
can receive another update. As alternative perspective the argument was made
that one needs to have a way to update the system without have the full system
running.</t>

  <t>Gateway requirements. In some deployments gateways terminate the IP-based
protocol communication and use non-IP mechanisms to communicate with other
micro-controllers, for example, within a car. The gateway
in such a system is the end point of the IP communication. The group had mixed feelings
about the use of gateways vs the use of IP communication to every
micro-controller. Participants argued that there is a lack of awareness of IPv6
header compression (with the 6lowpan standards) and of the possible benefits of
IPv6 in those environments in terms of lowering the complexity of the overall
system. </t>

  <t>The amount of energy consumed due to software update needs to be
minimized. For example, awakening a sleepy device regularly only to 
check for new software would seem wasteful if the device cannot feasibly
be exploited whilst asleep. However, the trade-off is that once the
device awakens with old software, there may be a window  
of vulnerability, if some relevant exploit has been discovered.</t>

<t>The amount of storage required for update ought be minimized and can 
sometimes be significant. However, there are also benefits to schemes
that store two or three different software images for robustness, e.g.,
if one has space for separate current, last-known-good and being-updated 
images then devices can better survive the buggy occasional updates that are
also inevitable.</t>

</list></t>

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

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

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

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

<t><list style="symbols">

  <t>The local server acting for neighbouring nodes. For example, in a vehicle one
micro-controller can process all firmware updates and redistribute the
relevant parts of those to
interconnected micro-controllers.</t>

  <t>Local infrastructure could perform some digital signature checks on behalf of the
devices, e.g., certificate revocation checking.</t>

  <t>Local multicast can enable transmission of the same update to many devices</t>

  <t>Local servers can hide complexity associated with NAT and Firewalls from the device</t>

</list></t>

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

<t>Some current firmware update schemes need to identify devices.
Different design approaches are possible.</t>

<t><list style="symbols">

  <t>In an extreme form in one case the decision about updating a device is
made by the infrastructure based on the unique device identification. The
operator of the firmware update infrastructure knows about the hardware and
software requirements for the IoT devices, knows about the policy for updating
the device, etc. The device itself is provisioned with credentials so that it
can verify a firmware update coming from an authorized device.</t>

  <t>In another extreme the device has knowledge about the software and
hardware configuration and possible dependencies. It consults software
repositories to obtain those software packages that are most appropriate.
Verifying the authenticity of the software packages/firmware images will still
be required.</t>

</list></t>

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

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

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

</section>

<!-- 
SF: Not clear to me what this section adds. I think it's all 
repetetive other than the energy and storage points (which I've now 
added above.

<section anchor="performance" title="Performance">

<t><list style="symbols">

  <t>Not just sending updates to each device individually</t>

  <t>Differential updates, examples are bsdiff <xref target="bsdiff"/> and
courgette <xref target="courgette"/></t>

  <t>firmware update consumes a lot of energy</t>

  <t>requires sufficient amount of flash for storing a backup image</t>

</list></t>


</section>
-->
<section anchor="authz" title="Authorizing a Software / Firmware Update">

<t>There were quite a few points revolving around authorization.</t>

<t><list style="symbols">

  <t>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 owner.</t>

  <t>With products that fall under a regulatory structure, such as healthcare,
you don’t want firmware other than what has been accredited.</t>

  <t>In some cases it will be very difficult for a firmware update system to
communicate to users that an update is available. Doing so may requires tracking the
device and it's status with regards to the installed firmware/software, 
with all the privacy downsides if such
tracking is badly done.</t>

  <t>Not all updates are the same. Security updates are often 
treated differently compared to feature updates and the
authorization for these may differ. </t>

  <t>Some people may choose to decline updates, often on the basis 
that their system is currently stable, but also possibly due
to concerns about unwanted changes, such as the 
HP printer firmware update pushed in March 2016 <xref
target="HP-Firmware"/> that turned off features that
end-users liked.</t>

</list>
</t>

</section>

<section anchor="eol" title="End-of-Support">

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

<t><list style="symbols">

  <t>How should end-of-support, or end-of-features be treated? Devices are often
deployed for 10+ years (or even longer in some verticals). Device-makers 
may not
want or be able to support software and services for such an extended period of time.
Will these devices stop working after a certain, previously unannounced period of time, such as Eye-Fi cards <xref target="eyefi"/>.</t> 

<t>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 
full device life-cycle. Some will be large commercial enterprises
who are used to dealing with long device life times, whilst others may
be very small commercial entities where the device lifetime may
be longer than the company life-time. Yet other devices may be 
the result of open-source activities that prosper or flounder.
The problem of end-of-support arises in all these cases, though
feasible solutions for software update may substantially differ.
In
some cases device-makers may not be willing to continue to update devices, 
for example due to a change in
business strategies caused by a merger. In yet other cases a company may have
gone bankrupt. </t>

<t>While there are many legal, ethical, and business related
questions can we technically enable transfer of device service to another
provider? Could there even be business models for entities that
take over device updates for original device-makers who no
longer wish to handle software update?</t>

<t>The release of code, as it was done with the Little Printer
manufactured and developed by a company called Berg <xref
target="LittlePrinter"/>, could provide a useful example.
While the community took over the support in that case, this can
hardly be assumed in all cases. Just releasing the source code for a device
will not necessarily motivate others to work on the code, to fix bugs or to
maintain a service. Nevertheless, escrowing code so that the
community can take it over if a company fails is one possible option.</t>

<t>The
situation gets more complex when the device has security mechanisms to ensure
that only selected parties are allowed to update the device (which is
really a basic requirement for any secure software update). In this case, 
private signing keys (or similar) may need to be made available as well, which could introduce
security problems for already deployed software. In the best case it changes
assumptions made about the trust model and about who can submit updates.</t>

  <t>How should deployed devices behave when they are end-of-support and 
support ends? Many of them may still function normally, but others may fail
due to the absence of 
cloud infrastructure services. Some products are probably expected
to fail safely, similarly to a smoke alarm that makes a loud noise when the
battery becomes empty. Cell phones without a contract can, in some countries,
still be used for emergency services (although at the expense of the society
due to untraceable hoax calls), as discussed in RFC 7406 <xref
target="RFC7406"/>.</t>

</list></t>

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

</section>

<section anchor="incentives" title="Incentives">

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

<t><list style="symbols">

  <t>Companies shipping software updates benefit from improved security.
Their devices are less likely to be abused as a vector to launch other
attacks, whether on their own networks, or (as part of a botnet) on other
Internet hosts. This clearly creates an incentive to support and use
software updates.</t>

<t>On the other hand updates can also break things. The negative customer
experience can be due to service interruptions during or after the update
process but can also result from bad experience from deliberate changes
introduced as part of an update - such as a feature that is not available
anymore, or that a “bug” that another service has relied upon being fixed.</t>

<!--
SF: I don't get this point
  <t>In the open source community public shaming works since the community is
open to feedback. The problem is when changes are available, just not applied,
since there is not necessarily an entity that pushes patches out.</t>
-->

  <t>For most classes of device, there does not seem to be a regulatory 
requirement to report or fix,
vulnerabilities, similar to data breach notification laws.</t>

  <t>Subscription models for device management were suggested so that companies
providing the service have an economic interest in keeping devices online (and
updated for that).</t>

</list></t>


</section>

<section anchor="measurements-and-analysis" title="Measurements and Analysis">

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

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

<t><list style="symbols">

  <t>Manufacturers and other players in the supply chain are interested to know
what devices are out there, how many have been sold, what devices are out there
but have not been sold. This could help to understand which firmware versions
to support for how long.  </t>

  <t> Device users, owners, and customers these may want to know what devices
are installed over a longer period of time, what software/firmware version is
the device running, what is uptime of each of these devices, what types of
faults have occurred, etc. Forgotten devices may pose problems, particularly if
they (have the potential to) behave badly.</t>

  <t>To an extent, network operators offering services to device owners
and other actors may also need similar information, for example to
control botnets.</t>

<!--
SF: I don't see how this relates to measurement?
  <t>Regulators and law makers need information to evaluate the effectiveness of cyber
security laws.</t>
-->

  <t>Researchers doing analysis on the state of the Internet ecosystem
(such as what protocols are being used, how much data IoT devices generate,
etc. need measurements for their work.</t>

</list></t>

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

</section>

<section anchor="firmware-distribution-in-mesh-networks" title="Firmware Distribution in Mesh Networks">

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

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

</section>

<section anchor="compromised-devices" title="Compromised Devices">

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

<t><list style="symbols">

<t>There may be value if it were possible to single out a device, which shows
faulty behavior or has been compromised, and to shut that down in some
sense.</t>

<t>Prior work in the IETF on Network Endpoint Assessment (NEA) <xref
target="NEA"/> allowed assessing the “posture” of devices. Posture refers to
the hardware or software configuration of a device and may include knowledge
that software installed is up-to-date.
The obtained information can then be used by some network infrastructure to
create a quarantined region network around the device. 
</t>

<t>RFC 6561 <xref target="RFC6561"/> describes one scheme for an ISP to send “signals” to 
customers about hosts (usually those that are part of a botnets or
generating spam) in their home network.
</t>

<t>Neither RFC 6561 nor NEA has found widespread deployment. Whether such
mechanisms can be more successful in the IoT environment has yet to be
studied.</t>

<!--
SF: What's foo?
<t>There is also a desire to explore mechanisms on the device that shuts down
the device itself. An example of such an approach has been studied in <xref
target="foo"/>.</t>
-->

</list></t>

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

</section>

<section anchor="misc" title="Miscellaneous Points">

<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. Those
included:</t>

<t><list style="symbols">

<t>Complex questions can arise when considering the impact of the 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 random host on the Internet, then what incentive do I have 
to do updates? What incentive has my device's vendor to have
done that in advance? An example of such a case can be found in DDoS 
attacks from IoT devices, such as printers <xref target="SNMP-DDOS"/> and cameras <xref target="DDOS-KREBS"/>.</t>

<!--
SF: repetitive I think?
<t>Lack of updates due to end of life /
end of support for a given product may again be treated differently.</t>
-->

  <t>With some IoT devices there are many stakeholders contributing to
the end product (e.g., contributing different subsystems) and ensuring that vulnerabilities 
are fixed and
software/firmware updates are communicated through the value chain is known to
be difficult, as demonstrated in <xref target="OS14"/>.</t>

  <t>What about forgotten devices? There are many such, and will be more.  Even
though they are forgotten, such devices may be useless consumers of electricity, 
or may be part of some critical system.</t>

  <t>Can we determine whether an update impacts other devices in the Internet?
Updates to one device can have unintended impact on other devices that depend
on it. This can have cascading effects if we are not careful.  Changing the
format of the output of a sensor could have cascading impacts, e.g., if some 
actuator reacts to the presence/absence of that sensor's data.</t>

<t>How should a device behave when it is running out-of-date software. The
example of a smoke alarm was mentioned. We don't want 100 devices in a
living room to start beeping when
their batteries run low or when they cannot communicate with the cloud. But 
are devices supposed to simply stop
working?</t>

<t>The IETF has published a specification that uses the Cryptographic Message
Syntax (CMS) to protect firmware packages, as described in RFC 4108 <xref
target="RFC4108"/>, which also contains meta-data to describe the firmware
image itself. During the workshop the question was raised whether a solution
will in future be needed that is post-quantum secure. A post-quantum
cryptosystem is a system that is secure against quantum computers that have
more than a trivial number of quantum bits. It is open to conjecture whether it
is feasible to build such a machine but current signature algorithms are known
to not be post-quantum secure.  This would require introducing technologies
like the Hash-based Merkle Tree Signature (MTS) <xref
target="housley-cms-mts-hash-sig"/>, which was presented and discussed at the
workshop. The downside of such solutions are, their novelty, and for these
use-cases, the fairly large signature or key sizes involved, e.g., depending on
the parameters a signature could easily have a size of 5-10KiB <xref
target="hashsig"/>. While it is likely that post-quantum secure signature
algorithms will be needed for software update at some point in time, it may be
the case that such algorithms will be needed sooner for services requiring long
term confidentiality, (e.g., using TLS) so it was not clear that this
application would be a first-mover in terms of post-quantum security.</t>

<t>Many devices that use certificates do not check the revocation status of certificates, even though extensions like OSCP stapling exists <xref target="RFC6961"/> and is increasingly deployed with Web browsers. The workshop participants were inconclusive regarding the recommendations of certificate revocation checking although the importance has been recognized. The reluctance of deploying certificate revocation deserves further investigations.</t>
</list></t>

</section>

<section anchor="next-steps" title="Tentative Conclusions and Next Steps">

<t>The workshop participants discussed some tentative conclusions and
possible next steps:</t>

<t><list style="symbols">

  <t>There was good agreement that having some standardized secure (authorized and
authenticated) software update would be an improvement over having none.</t>

  <t>It would be valuable to find agreement on the right scope for a
standardized software/firmware update mechanism. It is not clear that an entire
update system can or should be standardised but there may be some aspects of
such solutions where standards would be beneficial, e.g., (meta-)data formats
and/or protocols for distributing firmware updates. More discussion is needed to identify which parts of the problem
space could benefit from standardisation.</t>

  <t>It will be useful to investigate solutions to install updates with no
operation interruption as well as ways to distribute software updates without
disrupting network operations (specifically in low-power wireless networks),
including the development of a multicast transfer mechanism (with appropriate
security).</t>

  <t>There will almost certainly be a need for a way to transfer
authority/responsibility for updates, particularly considering end-of-support cases.
This is very close to calling for a standard way to "root" devices as a
feature of all devices.<!-- While this would be a dangerous implement, it
is hard to see how to address end-of-support without some such functionality.--></t>

  <t>We would benefit from documentation of proofs-of-concept of
software/firmware updates for constrained devices on different operating system
architectures.  The IETF Light-Weight Implementation Guidance (lwig) working group may be a good venue for such
documents.</t>

</list></t>

</section>

<section anchor="security-considerations" title="Security Considerations">
<t>This document summarizes an IAB workshop on software/firmware updates and
the entire content is therefore security related. Standardizing and deploying a
software/firmware update mechanism for use with IoT devices could help to fix
security vulnerabilities faster and in some cases the only via to get vulnerability patched at all.</t>
</section>

<section anchor="iana-considerations" title="IANA Considerations">

<t>This document does not contain any requests to IANA.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

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

</section>
<section anchor="appendix-a-program-committee" title="Appendix A: Program Committee">

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

</section>
<section anchor="appendix-b-accepted-position-papers" title="Appendix B: Accepted Position Papers">

<t>The list of accepted position papers is below. Links to these,
and to the workshop agenda and raw minutes are accessible at:
<eref target="https://down.dsg.cs.tcd.ie/iotsu/"/>.</t>

<t><list style="symbols">
  <t>R. Housley, ‘Position Paper for Internet of Things Software Update Workshop (IoTSU)’</t>
  <t>D. Thomas and A. Beresford, ‘Incentivising software updates’</t>
  <t>L. Zappaterra and E. Dijk, Software Updates for Wireless Connected Lighting Systems: requirements, challenges and recommendations’</t>
  <t>M. Orehek and A. Zugenmaier, ‘Updates in IoT are more than just one iota’</t>
  <t>D. Plonka and E. Boschi, ‘The Internet of Things Old and Unmanaged’</t>
  <t>D. Bosschaert, ‘Using OSGi for an extensible, updatable and future proof IoT’</t>
  <t>A. Padilla, E. Baccelli, T. Eichinger and K. Schleiser, ‘The Future of IoT Software Must be Updated’</t>
  <t>T. Hardie, ‘Software Update in a multi-system Internet of Things’</t>
  <t>R. Sparks and B. Campbell, ‘Avoiding the Obsolete-Thing Event Horizon’</t>
  <t>J. Karkov, ‘SW update for Long lived products’</t>
  <t>S. Farrell, ‘Some Software Update Requirements’</t>
  <t>S. Chakrabarti, ‘Internet Of Things Software Update Challenges: Ownership, Software Security &amp; Services’</t>
  <t>M. Kovatsch, A. Scholz, and J. Hund, ‘Why Software Updates Are More Than a Security Issue’</t>
  <t>A. Grau, ‘Secure Software Updates for IoT Devices’</t>
  <t>Birr-Pixton, Electric Imp’s experiences of upgrading half a million embedded devices’</t>
  <t>Y. Zhang, J. Yin, C. Groves, and M. Patel, ‘oneM2M device management and software/firmware update’</t>
  <t>E. Smith, M. Stitt, R. Ensink, and K. Jager, ‘User Experience (UX) Centric IoT Software Update’</t>
  <t>J.-P. Fassino, E.A. Moktad, J.-M. Brun, ‘Secure Firmware Update in Schneider Electric IOT-enabled offers’</t>
  <t>M. Orehek, ‘Summary of existing firmware update strategies for deeply embedded systems’</t>
  <t>N. Smith, ‘Toward A Common Modeling Standard for Software Update and IoT Objects’</t>
  <t>S. Schmidt, M. Tausig, M. Hudler, and G. Simhandl, ‘Secure Firmware Update Over the Air in the Internet of Things Focusing on Flexibility and Feasibility’</t>
  <t>A. Adomnicai, J. Fournier, L. Masson, and A. Tria, ‘How careful should we be when implementing cryptography for software update mechanisms in the IoT?’</t>
  <t>V. Prevelakis and H. Hamad, ‘Controlling Change via Policy Contracts’</t>
  <t>H. Birkholz, N. Cam-Winget and C. Bormann, ‘IoT Software Updates need Security Automation’</t>
  <t>R. Bisewski, ‘Comparative Analysis of Distributed Repository Update Methodology and How CoAP-like Update Methods Could Alleviate Internet Strain for Devices that
Constitute the Internet of Things’</t>
  <t>J. Arrko, ‘Architectural Considerations with Smart Objects and Software Updates’</t>
  <t>J. Jimenez and M. Ocak, ‘Software Update Experiences for IoT’</t>
  <t>H. Tschofenig, ‘Software and Firmware Updates with the OMA LWM2M Protocol’</t>
</list></t>

</section>
<section anchor="appendix-c-list-of-participants" title="Appendix C: List of Participants">

<t><list style="symbols">
  <t>Arnar Birgisson, Google</t>
  <t>Alan Grau, IconLabs</t>
  <t>Alexandre Adomnicai, Trusted Objects</t>
  <t>Alf Zugenmaier, Munich University of Applied Science</t>
  <t>Ben Campbell, Oracle</t>
  <t>Carsten Bormann, TZI University Bremen</t>
  <t>Daniel Thomas, University of Cambridge</t>
  <t>David Bosschaert, Adobe</t>
  <t>David Malone, Maynooth University</t>
  <t>David Plonka, Akamai</t>
  <t>Doug Leith, Trinity College Dublin</t>
  <t>Emmanuel Baccelli, Inria</t>
  <t>Eric Smith, SpinDance</t>
  <t>Jean-Philippe Fassino, Schneider Electric</t>
  <t>Jørgen Karkov, Grundfos</t>
  <t>Jonathon Dukes, Trinity College Dublin</t>
  <t>Joseph Birr-Pixton, Electric Imp</t>
  <t>Kaspar Schleiser, Freie Universität Berlin</t>
  <t>Luca Zappaterra, Philips Lighting Research</t>
  <t>Martin Orehek, Munich University of Applied Science</t>
  <t>Mathias Tausig, FH Campus Wien</t>
  <t>Matthias Kovatsch, Siemens</t>
  <t>Milan Patel, Huawei</t>
  <t>Ned Smith, Intel</t>
  <t>Robert Ensink, SpinDance</t>
  <t>Robert Sparks, Oracle</t>
  <t>Russ Housley, Vigil Security</t>
  <t>Samita Chakrabarti, Ericsson</t>
  <t>Stephen Farrell, Trinity College Dublin</t>
  <t>Vassilis Prevelakis, TU Braunschweig</t>
  <t>Hannes Tschofenig, ARM Ltd.</t>
</list></t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC6561' target='http://www.rfc-editor.org/info/rfc6561'>
<front>
<title>Recommendations for the Remediation of Bots in ISP Networks</title>
<author initials='J.' surname='Livingood' fullname='J. Livingood'><organization /></author>
<author initials='N.' surname='Mody' fullname='N. Mody'><organization /></author>
<author initials='M.' surname='O&apos;Reirdan' fullname='M. O&apos;Reirdan'><organization /></author>
<date year='2012' month='March' />
<abstract><t>This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers.  Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud.  Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack.  Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6561'/>
<seriesInfo name='DOI' value='10.17487/RFC6561'/>
</reference>


<reference  anchor='RFC6973' target='http://www.rfc-editor.org/info/rfc6973'>
<front>
<title>Privacy Considerations for Internet Protocols</title>
<author initials='A.' surname='Cooper' fullname='A. Cooper'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='B.' surname='Aboba' fullname='B. Aboba'><organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='J.' surname='Morris' fullname='J. Morris'><organization /></author>
<author initials='M.' surname='Hansen' fullname='M. Hansen'><organization /></author>
<author initials='R.' surname='Smith' fullname='R. Smith'><organization /></author>
<date year='2013' month='July' />
<abstract><t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t></abstract>
</front>
<seriesInfo name='RFC' value='6973'/>
<seriesInfo name='DOI' value='10.17487/RFC6973'/>
</reference>

<reference  anchor='RFC4108' target='http://www.rfc-editor.org/info/rfc4108'>
<front>
<title>Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date year='2005' month='August' />
<abstract><t>This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components.  CMS is specified in RFC 3852.  A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package.  A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package.  Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4108'/>
<seriesInfo name='DOI' value='10.17487/RFC4108'/>
</reference>



<reference  anchor='RFC7406' target='http://www.rfc-editor.org/info/rfc7406'>
<front>
<title>Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='McCann' fullname='S. McCann'><organization /></author>
<author initials='G.' surname='Bajko' fullname='G. Bajko'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='D.' surname='Kroeselberg' fullname='D. Kroeselberg'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.</t></abstract>
</front>
<seriesInfo name='RFC' value='7406'/>
<seriesInfo name='DOI' value='10.17487/RFC7406'/>
</reference>


<reference  anchor='RFC6961' target='http://www.rfc-editor.org/info/rfc6961'>
<front>
<title>The Transport Layer Security (TLS) Multiple Certificate Status Request Extension</title>
<author initials='Y.' surname='Pettersen' fullname='Y. Pettersen'><organization /></author>
<date year='2013' month='June' />
<abstract><t>This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods.  (The use of the Certificate Status extension is commonly referred to as &quot;OCSP stapling&quot;.)  Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.</t></abstract>
</front>
<seriesInfo name='RFC' value='6961'/>
<seriesInfo name='DOI' value='10.17487/RFC6961'/>
</reference>

<reference anchor="BS14" target="https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html">
  <front>
    <title>The Internet of Things Is Wildly Insecure And Often Unpatchable</title>
    <author initials="B." surname="Schneier">
      <organization></organization>
    </author>
    <date year="2014" month="January"/>
  </front>
</reference>
<reference anchor="FTC" target="https://www.ftc.gov/news-events/press-releases/2015/01/ftc-report-internet-things-urges-companies-adopt-best-practices">
  <front>
    <title>FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks</title>
    <author >
      <organization>Federal Trade Commission</organization>
    </author>
    <date year="2015" month="January"/>
  </front>
</reference>
<reference anchor="WP29" target="http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp223_en.pdf">
  <front>
    <title>Opinion 8/2014 on the on Recent Developments on the Internet of Things</title>
    <author >
      <organization>Article 29 Data Protection Working Party</organization>
    </author>
    <date year="2014" month="September"/>
  </front>
</reference>
<reference anchor="OS14" target="http://mis.fortunecook.ie/too-many-cooks-exploiting-tr069_tal-oppenheim_31c3.pdf">
  <front>
    <title>Too Many Cooks – Exploiting the Internet-of-TR-069-Things</title>
    <author initials="L." surname="Oppenheim">
      <organization></organization>
    </author>
    <author initials="S." surname="Tal">
      <organization></organization>
    </author>
    <date year="2014" month="December"/>
  </front>
</reference>
<!--
<reference anchor="foo" target="https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html">
  <front>
    <title>Paper about on-device malware analysis</title>
    <author initials="J." surname="Doe">
      <organization></organization>
    </author>
    <date year="2014" month="December"/>
  </front>
</reference>
-->
<reference anchor="BB14" target="http://www.wired.com/2015/04/smart-home-headaches/">
  <front>
    <title>Winks Outage Shows Us How Frustrating Smart Homes Could Be</title>
    <author initials="B." surname="Barrett">
      <organization></organization>
    </author>
    <date year="2014" month="April"/>
  </front>
</reference>
<reference anchor="IoTSU" target="https://www.iab.org/activities/workshops/iotsu/">
  <front>
    <title>Internet of Things Software Update Workshop (IoTSU)</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="2016" month="June"/>
  </front>
</reference>
<reference anchor="LittlePrinter" target="http://littleprinterblog.tumblr.com/post/97047976103/the-future-of-little-printer">
  <front>
    <title>The future of Little Printer</title>
    <author >
      <organization>Berg</organization>
    </author>
    <date year="2014" month="September"/>
  </front>
</reference>
<reference anchor="NEA" target="https://datatracker.ietf.org/wg/nea/charter/">
  <front>
    <title>Network Endpoint Assessment (nea) (Concluded Working Group)</title>
    <author >
      <organization>IETF</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<reference anchor="rpm" target="http://rpm.org/">
  <front>
    <title>Red Hat Package Manager (RPM)</title>
    <author >
      <organization>-</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<reference anchor="pacman" target="https://www.archlinux.org/pacman/">
  <front>
    <title>Pacman</title>
    <author >
      <organization>-</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<reference anchor="HP-Firmware" target="http://boingboing.net/2016/09/19/hp-detonates-its-timebomb-pri.html">
  <front>
    <title>HP detonates its timebomb - printers stop accepting third party ink en masse</title>
    <author >
      <organization>BoingBoing</organization>
    </author>
    <date year="2016" month="September"/>
  </front>
</reference>
<reference anchor="courgette" target="https://www.chromium.org/developers/design-documents/software-updates-courgette">
  <front>
    <title>Software Updates - Courgette</title>
    <author >
      <organization>Google</organization>
    </author>
    <date year="2016" month="September"/>
  </front>
</reference>
<reference anchor="RAPPOR" target="https://github.com/google/rappor">
  <front>
    <title>RAPPOR</title>
    <author initials="U." surname="Erlingsson">
      <organization></organization>
    </author>
    <author initials="V." surname="Pihur">
      <organization></organization>
    </author>
    <author initials="A." surname="Korolova">
      <organization></organization>
    </author>
    <date year="2014" month="July"/>
  </front>
</reference>
<reference anchor="bsdiff" target="http://www.daemonology.net/bsdiff/">
  <front>
    <title>Binary diff/patch utility</title>
    <author initials="C." surname="Percival">
      <organization></organization>
    </author>
    <date year="2016" month="September"/>
  </front>
</reference>
<reference anchor="hashsig" target="https://www.imperialviolet.org/2013/07/18/hashsig.html">
  <front>
    <title>Hash based signatures</title>
    <author initials="A." surname="Langley">
      <organization></organization>
    </author>
    <date year="2013" month="July"/>
  </front>
</reference>

<reference anchor="housley-cms-mts-hash-sig" target="https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-04">
  <front>
    <title>Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)</title>
    <author initials="R." surname="Housley">
      <organization></organization>
    </author>
    <date year="2016" month="March"/>
  </front>
</reference>

<reference anchor="OS-Support" target="http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=5462978">
  <front>
    <title>Providing OS Support for Wireless Sensor Networks - Challenges and Approaches</title>
    <author initials="W." surname="Dong">
      <organization></organization>
    </author>
    <author initials="C." surname="Chen">
      <organization></organization>
    </author>
    <author initials="X." surname="Liu">
      <organization></organization>
    </author>
    <author initials="J." surname="Bu">
      <organization></organization>
    </author>
    <date year="2010" month="May"/>
  </front>
</reference>

<reference anchor="plonka" target="https://down.dsg.cs.tcd.ie/iotsu/subs/IoTSU_2016_paper_25.pdf">
  <front>
	<title>The Internet of Things Old and Unmanage</title>
	<author initials="D." surname="Plonka"> <organization></organization> </author>
	<author initials="E." surname="Boschi"> <organization></organization> </author>
	<date year="2016" month="June"/>
  </front>
</reference>

<reference anchor="eyefi" target="http://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/">
  <front>
	<title>EYEFI TO DROP SUPPORT FOR SOME CARDS. THEY WILL ‘MAGICALLY’ STOP WORKING ON SEPTEMBER 16, 2016
</title>
	<author initials="J." surname="Aldred"> <organization></organization> </author>

	<date year="2016" month="June"/>
  </front>
</reference>

<reference anchor="RT" target="https://roughtime.googlesource.com/roughtime">
  <front>
	<title>Roughtime</title>

<author> <organization>Google</organization> </author>

	<date year="2016" month="September"/>
  </front>
</reference>

<reference anchor="SNMP-DDOS" target="https://www.bitag.org/documents/SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf">
  <front>
	<title>SNMP Reflected Amplification DDoS Attack Mitigation</title>

<author> <organization>BITAG</organization> </author>

	<date year="2012" month="August"/>
  </front>
</reference>



<reference anchor="DDOS-KREBS" target="http://arstechnica.com/security/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/">
  <front>
	<title>Record-breaking DDoS reportedly delivered by >145k hacked cameras</title>

<author initials="D." surname="Goodin"> <organization></organization> </author>

	<date year="2016" month="September"/>
  </front>
</reference>


    </references>

  </back>
</rfc>