Subject: [Mud] my list of MUD related documents

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 13:23:29 -0500

1) SBOM Extension for MUD
   draft-lear-opsawg-mud-sbom-00
Abstract
   Software bills of materials (SBOMs) are formal descriptions of what
   pieces of software are included in a product.  This memo specifies a
   means for manufacturers to state how SBOMs may be retrieved through
   an extension to manufacturer usage descriptions (MUD).

2) Authorized update to MUD URLs
   draft-richardson-opsawg-mud-acceptable-urls-03
Abstract
   This document provides a way for an RFC8520 Manufacturer Usage
   Description (MUD) definitions to declare what are acceptable
   replacement MUD URLs for a device.

3) Operational Considerations for use of DNS in IoT devices
   draft-richardson-opsawg-mud-iot-dns-considerations-03
Abstract
   This document details concerns about how Internet of Things devices
   use IP addresses and DNS names.  The issue becomes acute as network
   operators begin deploying RFC8520 Manufacturer Usage Description
   (MUD) definitions to control device access.

   This document explains the problem through a series of examples of
   what can go wrong, and then provides some advice on how a device
   manufacturer can best make deal with these issues.  The
   recommendations have an impact upon device and network protocol
   design.

4) On loading MUD URLs from QR codes
   draft-richardson-opsawg-securehomegateway-mud-05
Abstract
   This informational document details the mechanism used by the CIRA
   Secure Home Gateway (SHG) to load MUD definitions for devices which
   have no integrated MUD (RFC8520) support.

5) Manufacturer Usage Description for quarantined access to firmware
draft-richardson-shg-mud-quarantined-access-02
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.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 13:31:22 -0500

> replacement MUD URLs for a device.

This document is intended to be an Update to RFC8520.
In the parlance of draft-kuehlewind-update-tag-03  this document is an Amends.
It normatively changes how the MUD-URL attribute is to be interpreted.
The first five pages are justification, section 5 is just over a page for the
core.

I believe that we presented this document at IETF107 in the Spring.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 13:35:14 -0500

> recommendations have an impact upon device and network protocol

This document is a BCP, and it creates no new protocol or on-the-wire-bits.

It may be an appropriate document for IOTOPS if OPSAWG does not wish to work
on it.  Actually, I'm more and more convinced that this is an important
aspect for an IETF architectural view on IoT.

The ADD WG chairs examined it, as it has policy about when (not) to use
DoT/DoH/QuadX-Do53, but determined that it was not in the rather narrow ADD
charter.

I would like to get early review from DNSOP, and I will endeavour to get that
early in the new year.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 13:40:01 -0500

> have no integrated MUD (RFC8520) support.

This document is essentially complete.
It does not create any on-the-wire protocol, at least no IP-wire.
It described how to transmit MUD URLs over the optical-band ether[1], that is
via QR code.

The Return Logistics Alliance (rla.org) has a QR code format used today on many things,
and a protocol for encoding and extending things.   I have obtained a code
point from them.  While their document is open and available without
marketing paywall, I have included just enough detail so that this document
is probably stand-alone.

Unless I hear otherwise, I intend to go to the ISE with this document.

[1] - https://en.wikipedia.org/wiki/Aether_(classical_element)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 14:23:30 -0500

> draft-richardson-shg-mud-quarantined-access-02

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

    > access that a single function device such as an Internet of Things

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.