Draft: draft-ietf-suit-architecture

Commentary: Updates from genart review ( here : )
While the standardization work has been informed by and optimised for
firmware update use cases of Class 1 devices (according to the device
class definitions in RFC 7228 RFC7228), 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 devices (according to the device
class definitions in RFC 7228 RFC7228) devices, there is nothing in
the architecture that restricts its use to only these constrained IoT
devices.  Moreover, this architecture is not limited to managing
software updates, but can also be applied to managing the delivery of
arbitrary data, such as configuration information and keys.
For more information about TEEs see I-D.ietf-teep-architecture.
For more information about TEEs see I-D.ietf-teep-architecture.  TEEP
requires the use of SUIT for delivering TAs.
Status Tracker: The status tracker offers device management
functionality to retrieve information about the installed firmware
on a device and other device characteristics (including free
memory and hardware components), to obtain the state of the
firmware update cycle the device is currently in, and to trigger
the update process.  The deployment of status trackers is flexible
and they may be used as cloud-based servers, on-premise servers,
embedded in edge computing device (such as Internet access
gateways or protocol translation gateways), or even in smart
phones and tablets.  While the IoT device itself runs the client-
side of the status tracker it will most likely not run a status
tracker itself unless it acts as a proxy for other IoT devices in
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.
Status Tracker: The status tracker offers device management
functionality to retrieve information about the installed firmware
on a device and other device characteristics (including free
memory and hardware components), to obtain the state of the
firmware update cycle the device is currently in, and to trigger
the update process.  The deployment of status trackers is flexible
and they may be used as cloud-based servers, on-premise servers,
embedded in edge computing device (such as Internet access
gateways or protocol translation gateways), or even in smart
phones and tablets.  IoT devices that self-initiate updates may
run a status tracker.  Similarly, IoT devices that act as a proxy
for other IoT devices in a protocol translation or edge computing
device node may also run a status tracker.  However, if the device
contains multiple MCUs, the main MCU may 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.
Claim: A piece of information asserted about a recipient or
payload.
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.
Equally, adverse network conditions during an update must not cause
the 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.
Since parsers are known sources of bugs they must be minimal.
Additionally, it must be easy to parse only those fields that are
required to validate at least one signature or MAC with minimal
exposure.
Since parsers are known sources of bugs, any parsers used to process
the manifest must be minimal.  Additionally, it must be easy to parse
only those fields that are required to validate at least one
signature or MAC with minimal exposure.
While these broad classifications encompass the majority of operating
modes, some may not be covered in these classifications.  By
reinterpreting these modes as a set of operations performed by the
system as a whole, all operating modes can be represented.
This is a coarse-grained high level view of steps required to install
a new firmware.  By considering where in the system each of these
steps is performed, each operating mode can be represented.  Each of
these steps is broken down into smaller constituent parts.
architecture defines the steps taken from the perspective of the
communication between actors in the system. bootloader describes some
additional steps that a bootloader takes in addition to those
described here. example shows an example of the steps undertaken by
each party in the course of an update.
Claims in the manifest offer a way to convey instructions to a device
that impact the firmware update process.  To have any value the
manifest containing those claims must be authenticated and integrity
protected.  The credential used must be directly or indirectly
related to the trust anchor installed at the device by the Trust
Provisioning Authority.
Do not install firmware with earlier metadata than the current
metadata.
Only install firmware with a matching vendor, model, hardware
revision, software version, etc.
Only install firmware that is before its best-before timestamp.
Only allow a firmware installation if dependencies have been met.
Choose the mechanism to install the firmware, based on the type of
firmware it is.
The credential used to authenticate these Claims must be directly or
indirectly related to the trust anchor installed at the device by the
Trust Provisioning Authority.
The baseline claims for all manifests are described in I-D.ietf-suit-
information-model.
This configuration has two or more CPUs in a single SoC that share
memory (flash and RAM).  Generally, they will be a protection
mechanism to prevent one CPU from accessing the other's memory.
Upgrades in this case will typically be done by one of the CPUs, and
is similar to the single CPU with secure mode.
This configuration has two or more CPUs, each having their own
memory.  There will be a communication channel between them, but it
will be used as a peripheral, not via shared memory.  In this case,
each CPU will have to be responsible for its own firmware upgrade.
It is likely that one of the CPUs will be considered a master, and
will direct the other CPU to do the upgrade.  This configuration is
commonly used to offload specific work to other CPUs.  Firmware
dependencies are similar to the other solutions above, sometimes
allowing only one image to be upgraded, other times requiring several
to be upgraded atomically.  Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging.
In more complex SoCs with symmetric multi-processing support,
advanced operating systems, such as Linux, are often used.  These
SoCs frequently use an external storage medium such as raw NAND flash
or eMMC.  Due to the higher quantity of resources, these devices are
often capable of storing multiple copies of their firmware images and
selecting the most appropriate one to boot.  Many SoCs also support
bootloaders that are capable of updating the firmware image, however
this is typically a last resort because it requires the device to be
held in the bootloader while the new firmware is downloaded and
installed, which results in down-time for the device.  Firmware
updates in this class of device are typically not done in-place.
This configuration has two or more heterogeneous CPUs in a single SoC
that share memory (flash and RAM).  Generally, they will be a
protection mechanism to prevent one CPU from accessing the other's
memory.  Upgrades in this case will typically be done by one of the
CPUs, and is similar to the single CPU with secure mode.
This configuration has two or more heterogeneous CPUs, each having
their own memory.  There will be a communication channel between
them, but it will be used as a peripheral, not via shared memory.  In
this case, each CPU will have to be responsible for its own firmware
upgrade.  It is likely that one of the CPUs will be considered the
primary CPU, and will direct the other CPU to do the upgrade.  This
configuration is commonly used to offload specific work to other
CPUs.  Firmware dependencies are similar to the other solutions
above, sometimes allowing only one image to be upgraded, other times
requiring several to be upgraded atomically.  Because the updates are
happening on multiple CPUs, upgrading the two images atomically is
challenging.
If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a
working image is left on the device.  This allows the bootloader to
roll back to a working firmware image to execute a firmware download
if the bootloader itself does not have enough functionality to fetch
a firmware image plus manifest from a firmware server over the
Internet.  A multi-stage bootloader may soften this requirement at
the expense of a more sophisticated boot process.
In order to satisfy the reliability requirements defined in
reliability, devices must always be able to return to a working
firmware image.  This has implications for the design of the
bootloader: If the firmware image contains the firmware consumer
functionality, as described above, then the bootloader must be able
to roll back to a working firmware image.  Alternatively, the
bootloader may have enough functionality to fetch a firmware image
plus manifest from a firmware server over the Internet.  A multi-
stage bootloader may soften this requirement at the expense of a more
sophisticated boot process.