[Suit] Fwd: ITU-T Liaison statement

[Brendan Moran <[e-mail]>]

Dear suit wg,

I’ve gone through the Draft Recommendation ITU-T X.secup-iot. Here are my comments.

Best Regards,
Brendan

Status Tracker
---
I find the use of “Status Tracker" difficult to reconcile. The term “Status tracker” implies a reporting channel, however the status tracker is far more than this.

In section 3.2.5 (label is 1.1.5, but this looks wrong), the status tracker definition includes:

… and initiates the FW updates as needed

This feature gives the status tracker substantial power to choose when devices are updated and which updates they receive. It appears to me that some status trackers should have this power and some should not.

It might be helpful to define a separate component that can initiate a FW update in response to a status tracker’s report.

Status tracker has numerous uses:

  *   3.2.5 (label is 1.1.5, but this looks wrong) says that it monitors device version/state, then initiates FW updates as needed.
  *   7 shows the status tracker receiving firmware update requests, checking the need for updates, and initiating firmware updates.
  *   8.1 says that the status tracker receives and validates the trigger to initiate the FW update procedure.
  *   8.2 says that a status tracker may reside inside a status tracker.

The model presented does not have any way to handle blindly broadcast updates. This may not be a use case that we care about, but it may be useful to consider. This sort of use case may be especially relevant for situations where firmware is loaded onto devices with a USB flash drive, for example.

The definition of "status tracker" is so broad that it could mean either:

  1.  A serial console that reports the current version, and accepts a command to place the device into booloader mode
  2.  A cloud-hosted system for orchestrating firmware updates across fleets of millions of devices that:
     *   Aggregates status reports from both direct-connected IoT devices and IoT gateways that, in turn aggregate status reports from the devices they manage
     *   Applies a broad set of rules to ensure that compatibility is maintained across networks, that the most recent compatible firmware is applied to all devices in a given network, and that security patches are applied in a timely manner.

It could also mean anything in between.

While I appreciate that there are some common elements here, I’m not certain that a definition this broad is helpful to the discussion. It could lead to confusion where implementers believe that all features are mandatory at all levels, creating needless complexity on constrained nodes.

The status tracker could be a very useful abstraction that allows a common behaviour at all levels, but for that to work, it needs a rigorous definition.

I have some concerns with regards to how each status tracker’s trust relationship with the end node is established. While having a tree of status trackers to aggregate data is helpful, having many entities with the ability to initiate a firmware update causes some trouble with regards to correctly assigned privileges.

I don’t believe that SUIT should adopt the “status tracker” terminology without a more rigorous definition and more modelling around the rights for initiating a fw update.


Here’s my attempt at a rigorous definition of the status tracker.

The Status Tracker contains four interfaces:

  1.  Status Reporter
  2.  Update Request Receiver
  3.  Status Requester
  4.  Update Initiator

The Status Reporter and the Update Request Receiver can communicate with either

  1.  An upstream Status Tracker
  2.  An update management application

The Status Requester and the Update Initiator can communicate with

  1.  One or more downstream Status Tracker(s)
  2.  One or more Firmware Consumer(s)

Or a combination, determined by the application

The Status Reporter receives a request for status information, the either

  1.  Responds with one or more cached status reports
  2.  Initiates a status request on the Status Requester interface, waits for the status report, then caches the status report and responds to the original status request

The Update Request Receiver

  1.  Receives an authenticated request to update
  2.  Verifies the request
  3.  Obtains current status by either
     *   Checking cached status
     *   Initiating a status request on the Status Requester interface
  4.  Performs application-specific logic to decide whether or not to initiate an update
  5.  (Optionally) Initiates an update on the Update Initiator interface



Other observations by section
---
Section 6:
I don’t understand why a “webcam device” (typically a USB-connected camera) would contain multiple firmware consumers.

Section 7:
It would be helpful to have a sequence diagram with federated status trackers. I may misunderstand the diagram, but I believe there is an ordering problem that will cause many status checks.

Suppose that we have Status Tracker A->Status Tracker B->Firmware Consumer.


  1.  Status Tracker A receives a request to update firmware
  2.  Status Tracker A initiates a status check (deferred to Status Tracker B)
  3.  Status Tracker B initiates a status check of Firmware Consumer
  4.  Status Tracker B receives the status info from Firmware Consumer and forwards to Status Tracker A
  5.  Status Tracker A receives the status info from Status Tracker B
  6.  Status Tracker A determines that there is a need for firmware update.
  7.  Status Tracker A initiates a firmware update (forwards the request to update firmware to Status Tracker B)
  8.  Status Tracker B receives a request to update firmware
  9.  Status Tracker B initiates a status check of Firmware Consumer
  10. Status Tracker B receives the status info from Firmware Consumer
  11. Status Tracker B determines that there is a need for firmware update
  12. Status Tracker B initiates a firmware update (forwards the request to update firmware to Firmware Consumer)


This problem can be overcome by adding a caching layer to Status Tracker B. However, I think that this is a sufficiently fundamental requirement that it should be documented.

The semantics of "the FW-consumer installs the FW” are unclear. In constrained nodes, it is common to require a firmware to be written to storage (“installed”) prior to verification because the firmware may be too large to hold in RAM for verification. In this situation, the post-verification “install” has to do with activation, or marking an image as bootable, rather than writing the image to long-term storage.

Section 8:

An IoT device must contain at least one FW-consumer because it is natural that an IoT device contains multiple FW images.
In section 8.1, it is not clear why single-image IoT devices are excluded. It is also not clear why single-image IoT devices do not require a firmware consumer.

8.2:
a status tracker may reside inside a status tracker
I don’t understand the purpose of including one status tracker inside another.

Cases where (1) a status tracker inside an IoT device directly communicates with an FW-server, (2) a status tracker inside an IoT device communicates with an FW-server via another status tracker residing inside the Intranet, and (3) a status tracker inside an IoT device communicates with an FW-server via multiple status trackers are illustrated in clause 8.2.1 to 8.2.3.
Status tracker-firmware server interactions are not defined in Section 7. I don’t understand why the status tracker is interacting with the FW server.

8.2.1: Based on the Figure 3 and the text explaining Figure 3, the title of 8.2.1 is wrong:
A status tracker inside an IoT device directly communicates with an FW-server
The diagram and text show the firmware consumer interacting with the FW-server, the status tracker does not.

9: Status trackers do not report firmware update requests upstream. This could be necessary for auditing purposes and it could cause network incompatibility where part of an interoperable network is updated to a new firmware version but another part is not updated. Status trackers should conspire to ensure that all interoperating devices retain compatible firmwares. This likely requires upstream reporting of update requests for evaluation. Section 7 may need to add this process.

10: IETF SUIT has its own version of these security requirements. See draft-ietf-suit-information-model.

Note that confidentiality, integrity and availability of the four functional entities must be preserved
It is not possible to guarantee the availability of any networked entity. Any assumption to the contrary may result in an unreliable or vulnerable system. All functional entities must be designed with tolerance for the unavailability of any other functional entity.

Section 11:

11.1.a.iv: Most of the document says that the status tracker notifies the FW consumer of an update. This is the reverse. This is the only place in the document where the FW consumer notifies the status tracker of anything.

11.2.d: Upstream status trackers must also be able to verify the authenticity of downstream status trackers. If these status trackers are operated by different entities, then a rights management framework is needed.

11.2: seems to be missing common security requirements: Replay attack prevention, Proof/verification of reported firmware version (attestation).

11.3.c: This requirement conflicts with 11.4.b/c. If the author is maintaining confidentiality, then the FW server cannot see the contents of the FW image. This means that the FW server cannot identity malicious SW/FW images.

11.3.f: Isn’t this exactly the role of the status tracker? Especially when combined with 11.3.g?

11.3.g: The status tracker is responsible for notifying FW consumers of new versions. Why is the FW server now doing so as well?

11.3.h: Seems very prescriptive with regards to region-locking firmware. Couldn’t an IoT device lie about its location to the FW server? Since it’s only responsible for distribution, and trust is primarily between the FW-Consumer and the Author, there is a very limited trust relationship between the FW consumer and the FW-Server. This requirement might fit better in the status tracker, where the IoT device might not even be notified of an update if it’s in a prohibited location. The status tracker and the IoT device have a much more significant trust relationship. If an IoT device lies about its location to the status tracker, other location-dependent management features of the device might not work as expected (e.g. maintenance).


Appendix 1: It may be useful to include the information model.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.