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

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> 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
way.

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:
    https://datatracker.ietf.org/meeting/interim-2020-opsawg-01/materials/slides-interim-2020-opsawg-01-sessa-device-quarantine-definition-for-manufacturer-usage-descriptions-rfc8520-00
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
concerns:
  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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide