IETF Logo Mail Archive

Re: [Suit] Fwd: Firmware Update Paper

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 05 December 2019 14:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708C11200C7 for <suit@ietfa.amsl.com>; Thu, 5 Dec 2019 06:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FjmLhYC4j27 for <suit@ietfa.amsl.com>; Thu, 5 Dec 2019 06:33:48 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740FF12002E for <suit@ietf.org>; Thu, 5 Dec 2019 06:33:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D65AF3818F; Thu, 5 Dec 2019 09:30:08 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 72B16AAB; Thu, 5 Dec 2019 09:33:47 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?UTF-8?Q?Szymon_S=C5=82upik?= <simon@silvair.com>
cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, "suit@ietf.org" <suit@ietf.org>
In-Reply-To: <CABNHR1zPxMcgSg0cpci8zs-zR5v38bYZjE8Hyu2OOw67-vuXMQ@mail.gmail.com>
References: <VI1PR08MB53600B1D1A194F49B67B90DFFAC60@VI1PR08MB5360.eurprd08.prod.outlook.com> <20191127203651.GA117656@davidb.org> <CANK0pbaWkn7w2swRgkOqsTubE1os=rDo2BLjrTZ5eW6ePv3WnA@mail.gmail.com> <20191129183627.GA16289@davidb.org> <DB6PR0801MB1879D9742622EA0AE08A8B72EA430@DB6PR0801MB1879.eurprd08.prod.outlook.com> <CABNHR1yEFvgEzHjBhpqTW-FX+LQTVYuSJE_9SP9OMwzjWsdORQ@mail.gmail.com> <CANK0pbaf8TTtMOSKHD0D-73+MCzSdjk7p+6hVO0WzpSxhF2fVg@mail.gmail.com> <CABNHR1z4N=uH9d5DvyYi17DCULqu3T6Ve9k-_EJr-37zUjF-uw@mail.gmail.com> <CANK0pbYGbzu8VAr7ZuzUOY1yQ75qkMKQ6PAncZCfkH2=RZWNUQ@mail.gmail.com> <CABNHR1wOXx6QRYMMFgnNs12qtc5Ofs8MdR-Oe=d4KRCzXtaiQA@mail.gmail.com> <CANK0pbagZtjzE4vsW6ez76aT2sFeNj_vMr=fKP8Xo6kvCcSF9A@mail.gmail.com> <VI1PR08MB5360CF7EFDF7C550D0D7E755FA5D0@VI1PR08MB5360.eurprd08.prod.outlook.com> <5719.1575486149@localhost> <CABNHR1zPxMcgSg0cpci8zs-zR5v38bYZjE8Hyu2OOw67-vuXMQ@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 05 Dec 2019 09:33:47 -0500
Message-ID: <24548.1575556427@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/5It8ky7vMisKar05g-RCupwffzY>
Subject: Re: [Suit] Fwd: Firmware Update Paper
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2019 14:33:50 -0000

    mcr> It occurs to me now that the development of an update protocol over
    mcr> 802.15.4
    mcr> (which I mentioned in another email in this thread) might be
    mcr> appropriately
    mcr> done in the 6tisch WG, since I actually think that the bandwidth and
    mcr> scheduling of the update is probably the critical part.
    mcr> SUIT has the security done... so we have the HOW. We just have the WHEN.

Szymon Słupik <simon@silvair.com> wrote:
    > One other approach to explore, very applicable to FW updates, is multi-hop
    > multicast, as in many scenarios you are updating more than one device, and
    > many of them are identical (like lights on a big parking lot).

I agree that this is an important aspect to explore.
It requires that each hop is able to buffer the entire firmware update in a
way that does not break the hash of it.  If the firmware is execute in place
and/or if the device is designed such that the bootstrap code validates the
firmware on each boot, then keeping the firmware image in that form may not
be a big imposition.

We also did MPL ("mipple", RFC7733) in the ROLL WG, which would allow for
the "download" of the firmware to be multicast.  There are bandwidth, CPU and
network scheduling tradeoffs of each, which I think 6tisch is most capable to
consider.   That's why I think that it's not a HOW anymore, but a WHEN.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email