[Iotops] Manufacturer Usage Description for quarantined access to firmware - draft-richardson-shg-mud-quarantined-access-02

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 17 December 2020 19:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CD7413A0E8C; Thu, 17 Dec 2020 11:23:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9Ans20yp5L7m; Thu, 17 Dec 2020 11:23:34 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338403A0E60; Thu, 17 Dec 2020 11:23:32 -0800 (PST)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id CB1AE389AC; Thu, 17 Dec 2020 14:26:16 -0500 (EST)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id m9SbiclX722K; Thu, 17 Dec 2020 14:26:16 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id 17199389A8; Thu, 17 Dec 2020 14:26:16 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5217E11B4; Thu, 17 Dec 2020 14:23:30 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org, suit@ietf.org
In-Reply-To: <27659.1608229409@localhost>
References: <27659.1608229409@localhost>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Thu, 17 Dec 2020 14:23:30 -0500
Message-ID: <10446.1608233010@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/UKaOaG8mIw1lv1UAse5me6C7O1Q>
Subject: [Iotops] Manufacturer Usage Description for quarantined access to firmware - draft-richardson-shg-mud-quarantined-access-02
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 19:23:36 -0000

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > 5) Manufacturer Usage Description for quarantined access to firmware
    > draft-richardson-shg-mud-quarantined-access-02

[perhaps I should rename it with opsawg in the filename]

    > Abstract
    > The Manufacturer Usage Description is a tool to describe the limited
    > access that a single function device such as an Internet of Things
    > device might need.

This is a small extension to RFC8520 which provides a new attribute to each
ACL.  It marks the ACL as being essential for firmware/software updates.
In the parlance of draft-kuehlewind-update-tag-03  this document is an Extends.

The need for this extension became obvious during the PoC phase of the
CIRA SecureHomeGateway back in 2018.  We put a sample device into the deny
list, kicking the device off the Internet, and and then wondered... so now
what?  How does it get updated?   Is it landfill?  There must be a better

I believe that this work needs to be adopted by OPSAWG to be able to make progress.
I presented it at the spring IETF107 meeting in OPSAWG, but it is quite
likely that are some Software Update people who haven't seen it.
The slides are at:
or: https://github.com/CIRALabs/shg-mud-quarantine/tree/master/presentations

At present, the document isn't much more than a YANG modules with a lot of
words in it!  (Much like a third of the documents coming from the RTG area)
The security considerations will need some work beyond "TBD": there are two obvious
  1) did a third party lie about what they essential connections are?
     This boils down to: how did the MUD controller establish trust in the
     MUD file in the first place.  I have another document about that.

  2) was did the manufacturer lazy and just marked everything as essential?
     Or, how can we be sure what's essential anyway?
     What kind of local policy might need to override this anyway, and
     does that render this all moot?

In the two years since I started this document SUIT has made significant progress.
One thing that the CIRA SHG team really wanted was to actually collect the
firmware ourselves.  That is, rather than allowing the device out to the
network to get it's own firmware, we would have rather been able to discovery
the URL of the new firmware using a standard protocol, cached it locally, and
then pointed the device at that copy.
This would essentially have rendered the two concerns above irrelevant.

SUIT has intentionally not standardized such a mechanism as being too much of
a bikeshed/rathole (I think), but I am interested if there is some interest
in doing that.  Perhaps in addition to this document, or maybe, instead of.

Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide