Draft: draft-ietf-suit-architecture

Commentary: Signed - off - by :   
 cc
When developing Internet of Things (IoT) devices, one of the most
difficult problems to solve is how to update firmware on the device.
Once the device is deployed, firmware updates play a critical part in
its lifetime, particularly when devices have a long lifetime, are
deployed in remote or inaccessible areas where manual intervention is
cost prohibitive or otherwise difficult.  Updates to the firmware of
an IoT device are done to fix bugs in software, to add new
functionality, and to re-configure the device to work in new
environments or to behave differently in an already deployed context.
When developing Internet of Things (IoT) devices, one of the most
difficult problems to solve is how to update firmware on the device.
Once the device is deployed, firmware updates play a critical part in
its lifetime, particularly when devices have a long lifetime, or are
deployed in remote or inaccessible areas where manual intervention is
cost prohibitive or otherwise difficult.  Updates to the firmware of
an IoT device are done to fix bugs in software, to add new
functionality, and to re-configure the device to work in new
environments or to behave differently in an already deployed context.
The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be
prevented.  Obtaining the firmware is often one of the first steps
to mount an attack since it gives the adversary valuable insights
into used software libraries, configuration settings and generic
functionality (even though reverse engineering the binary can be a
tedious process).
The firmware image can be kept confidential from adversaries.
Obtaining the firmware is often one of the first steps to mount an
attack since it gives the adversary valuable insights into used
software libraries, configuration settings and generic
functionality (even though reverse engineering the binary can be a
tedious process).
While the standardization work has been informed by and optimised for
firmware update use cases of Class 1 (as defined in RFC 7228 RFC7228)
devices, there is nothing in the architecture that restricts its use
to only these constrained IoT devices.  Software update and delivery
of arbitrary data, such as configuration information and keys, can
equally be managed by manifests.
While the standardization work has been informed by and optimised for
firmware update use cases of Class 1 (as defined in RFC 7228 RFC7228)
devices, there is nothing in the architecture that restricts its use
to only these constrained IoT devices.  Delivery of arbitrary data,
such as configuration information and keys, can equally be managed by
manifests.
a protocol translation or edge computing device node.  How much
functionality a status tracker includes depends on the selected
configuration of the device management functionality and the
communication environment it is used in.  In a generic networking
environment the protocol used between the client and the server-
side of the status tracker need to deal with Internet
communication challenges involving firewall and NAT traversal.  In
other cases, the communication interaction may be rather simple.
This architecture document does not impose requirements on the
status tracker.
a protocol translation or edge computing device node.  However, if
the device contains multiple MCUs, the main MCU must likely act as
a limited status tracker towards the other MCUs if updates are to
be synchronized across MCUs.  How much functionality a status
tracker includes depends on the selected configuration of the
device management functionality and the communication environment
it is used in.  In a generic networking environment the protocol
used between the client and the server-side of the status tracker
need to deal with Internet communication challenges involving
firewall and NAT traversal.  In other cases, the communication
interaction may be rather simple.  This architecture document does
not impose requirements on the status tracker.
A power failure at any time must not cause a failure of the device.
A failure to validate any part of an update must not cause a failure
of the device.  One way to achieve this functionality is to provide a
minimum of two storage locations for firmware and one bootable
location for firmware.  An alternative approach is to use a 2nd stage
bootloader with build-in full featured firmware update functionality
such that it is possible to return to the update process after power
down.
A power failure at any time must not cause a failure of the device.
A failure to validate any part of an update must not cause a failure
of the device.  One way to achieve this functionality is to provide a
minimum of two storage locations for firmware one or both of which
are bootable.  An alternative approach is to use a 2nd stage
bootloader with build-in full featured firmware update functionality
such that it is possible to return to the update process after power
down.
Second, an IoT device needs a recovery strategy in case the
firmware update / boot process fails.  The recovery strategy may
include storing two or more firmware images on the device or
offering the ability to have a second stage bootloader perform the
firmware update process again using firmware updates over serial,
USB or even wireless connectivity like a limited version of
Bluetooth Smart.  In the latter case the firmware consumer
functionality is contained in the second stage bootloader and
requires the necessary functionality for executing the firmware
update process, including manifest parsing.
Second, an IoT device needs a recovery strategy in case the
firmware update / boot process fails.  The recovery strategy may
include storing two or more firmware images on the device or
offering the ability to have a second stage bootloader perform the
firmware update process again using firmware updates over serial,
USB or even wireless connectivity like a limited version of
Bluetooth Low Energy.  In the latter case the firmware consumer
functionality is contained in the second stage bootloader and
requires the necessary functionality for executing the firmware
update process, including manifest parsing.
There is an option for embedding a firmware image into a manifest.
This is a useful approach for deployments where devices are not
connected to the Internet and cannot contact a dedicated firmware
server for the firmware download.  It is also applicable when the
firmware update happens via a USB stick or via Bluetooth Smart.
attached-firmware-figure shows this delivery mode graphically.
There is an option for embedding a firmware image into a manifest.
This is a useful approach for deployments where devices are not
connected to the Internet and cannot contact a dedicated firmware
server for the firmware download.  It is also applicable when the
firmware update happens via a USB stick or via Bluetooth Low Energy.
attached-firmware-figure shows this delivery mode graphically.