[Fud] (quick) review of draft-moran-fud-architecture-00

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Wed, 19 July 2017 18:33 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDA94131B3E for <fud@ietfa.amsl.com>; Wed, 19 Jul 2017 11:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gCafLjb5MPv7 for <fud@ietfa.amsl.com>; Wed, 19 Jul 2017 11:33:48 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1C9131A62 for <fud@ietf.org>; Wed, 19 Jul 2017 11:33:48 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 80so6206291uas.0 for <fud@ietf.org>; Wed, 19 Jul 2017 11:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=orHqRaw2mLGb6Ut46RuXeuxwFEtnhjwezrp1m6wCz8Y=; b=uVnkLxqOHAgaKQzqC3lZBhySUIpp+OZVZcCpA1QgzINir7VTajSp1X3sQuEVHuJyoc hXRXxRpkmQ//ZPUL9tnVF0oFJIQ9eCUPNaQYw6QgidJVt2bmv+o5dMHafTX2JnGNRC/3 KJ6CYTUqtY1rrOKuUqBFE3rDqHbaUOCAXwSQgMgBoHc9bU/jtDFv7Lc+v9M/4GLv9Nci I8qTDN3ncBeq4+n4Sv+EjsCjovhddOvcIY6BKSDQ4q2gY7qXDhGybOHyXs28RRWvd5Zk jd8FXPc1tjPMZF7QoAM4F3amJ/BsFSSQ64tq4dYnactEpR+gvKwkawZRJxyi6vTe4J5D 29uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=orHqRaw2mLGb6Ut46RuXeuxwFEtnhjwezrp1m6wCz8Y=; b=Zosuor7DiVyLJXYKoZG/hweIg55fGr1ZXXl8Ax27jIbsUMJ0KL2Yr8hsuUVQOtHBUY d7e4z4yd4r67FGJiljsDmn6jeRf57ITPzoGAt12KmoOWy1ryoeGTwmw4fL1a7CFNffa+ bxeoWrBH2+22ITdMmFSdx4G0JSZCihfT69g4ZsIdnfrIpZdAoe1IHcMbCVi0RTlk6A8/ rGAtHVKyG3dvDv2WQAYqSiXkOQOQNNjCoaTLIidpHNS/rAFbU9ey94ab8HngN3JOtgJQ POQkMW4Khys8inYOBxnJNcm0LHvEt4q2UTCHmqcjIJK8HhlGa9JKJ1ge36g++znoItIa Cz0w==
X-Gm-Message-State: AIVw112FSXhftNi8Aykh/RgwfXtuLcM836NjPK93x2XZL81lZt3YBOc2 +BF5O+lusl64NeQQnuUA8Gc/Ub5CLbnB
X-Received: by with SMTP id w47mr592148uah.207.1500489227060; Wed, 19 Jul 2017 11:33:47 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by with HTTP; Wed, 19 Jul 2017 11:33:26 -0700 (PDT)
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Wed, 19 Jul 2017 20:33:26 +0200
X-Google-Sender-Auth: RybPJC8cefF2SdotSGeGGA50-Xo
Message-ID: <CANK0pbYAHH79nRWkD5LkpJApJvYH4Ds563jg-uh0ir0F1QcN3w@mail.gmail.com>
To: fud@ietf.org
Content-Type: multipart/alternative; boundary="f403043649d45e4caa0554afdfdf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/WbC9-HK8sH9ftYlCgYai867BiE4>
Subject: [Fud] (quick) review of draft-moran-fud-architecture-00
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 18:33:50 -0000

Hi everyone,

thanks for the draft.

to prepare tomorrow's meeting, I read the drafts as fast as I could ( I
hope note too fast ;)

It reads well already, and it is actually pretty close to what
we are doing in RIOT.

See below some comments, questions and suggestions.

General comments:

1. In the proposed architecture some trust is required in the storage
element, which is assumed to correctly:
- serve the latest manifest/firmware (if the device pulls)
- pushe/signal newer manifests to the device (if the author pushes)

2. What is specific to firmware in the document so far?
It seems to me that this could apply to any software module on an IoT
device, not necessarily a firmware.
For instance it could be "application" logic (We have use cases where we
are updating some software, but not the firmware).
Why not generalize somehow the terminology to something more generic like
"software update" or something similar?

Some more detailed comments:

# in Section 3:
why/how/what small bootloader?

why/how friendly to broadcast => no TLS, Object security
but: are we really going to broadcast a (relatively large) firmware?

# in Section 3.4:

"the device is required to provide a minimum of two storage locations for
firmware and one bootable location for firmware."

Is reliability possible only with this approach?
This seems out of scope of the generic architecture.

# in Section 3.5:
How about rephrasing like:
"The approach must not require a large bootloader"

# in Section 3.6
Here I think the draft should reference examples of what "existing firmware
formats" are alluded to.
In my opinion, this section could be removed for two reasons:
1. because the metadata is anyways separate from the actual firmware,
2. the software might not be firmware, but just a software module (as per
my comment above)

# in Section 3.7
I would suggest to have this document focus primarily on single MCU devices.
Ideally: extensions to cover multi-firmware devices would either be in a
later part of the document or in a separate document.

At this point in the document it is obscure what the distinctions are
Author, Store, Apply, Approve, Qualify

# in Section 4:
How about being more assertive here, such as:

The firmware image MAY be encrypted and MUST be integrity protected AS WELL
The meta-data MUST integrity protected and AUTHENTICATED.

# in Section 5:

   -  When should the device apply the update?
   out of scope?

   -  How should the device apply the update?
   out of scope?

   -  What kind of firmware binary is it?
   is this different from the question "should it apply the firmware"?

   -  Where should the update be obtained?
   if we are not making the assumption that metadata and firmware are
stored in difference places, is this redundant?

   -  Where should the firmware be stored?
   out of scope?

# in Section 6:
"information about when the firmware update has to be applied".
I guess the default should be "as soon as possible".
However, in cases when the time is no synchronized, I'm wondering how the
could interpret this "when" indication.

# in Section 7:

Typically the author will produce/transfer a new firmware and its
(manifest) metadata in one go.
In practice, firmware and manifest might even be bundled in a single file
Hence I would suggest to invert the order of the steps "Upload Firmware"
 and "Create Manifest".