Skip to main content

Early Review of draft-ietf-opsawg-mud-08

Request Review of draft-ietf-opsawg-mud-08
Requested revision 08 (document currently at 25)
Type Early Review
Team Internet of Things Directorate (iotdir)
Deadline 2017-08-29
Requested 2017-08-15
Requested by Joe Clarke
Authors Eliot Lear , Ralph Droms , Dan Romascanu
I-D last updated 2017-08-29
Completed reviews Secdir Early review of -08 by Adam W. Montville (diff)
Genart Early review of -08 by Robert Sparks (diff)
Iotdir Early review of -08 by Henk Birkholz (diff)
Yangdoctors Early review of -08 by Martin Björklund (diff)
Rtgdir Last Call review of -13 by Adrian Farrel (diff)
Secdir Last Call review of -13 by Adam W. Montville (diff)
Genart Telechat review of -20 by Robert Sparks (diff)
Opsdir Telechat review of -20 by Scott O. Bradner (diff)
The opsawg working group feels this document is generally in good shape, and the work has been progressing nicely.  The document is very readable, and it would benefit from an early review especially around areas of security and IoT.  By MUD's very nature, it relies on trust and needs to be friendly to constrained, purpose-built devices.

The YANG modules defined within have been previously reviewed, but could use a new set of YANG Doctor eyes.  In particular, comments have been raised about what leafs should be mandatory (if any).

Thank you.
Assignment Reviewer Henk Birkholz
State Completed
Review review-ietf-opsawg-mud-08-iotdir-early-birkholz-2017-08-29
Reviewed revision 08 (document currently at 25)
Result On the Right Track
Completed 2017-08-29
Reviewer: Henk Birkholz
Review result: Has Issues


I am the assigned IoT-DIR reviewer for this document's early review.

Please find my comments in kramdown below.

Viele Grüße,


# IoT-DIR Early Review of I-D.ietf-opsawg-mud-08

## Draft Summary

This draft defines a canonical way to compose an URI that points to a specific
resource called a MUD file. A MUD file is a text resource that contains
imperative guidance in the form of YANG-based ACL policies represented in JSON.
The imperative guidance is intended to be applied to things that can be
identified by the segments of the MUD URI via a specific controller. The
version of MUD is a component (segment) of the MUD URI and there are three
examples in what to embed a MUD URI in (DHCP option, X.509 extension, and LLDP

## Comments on General Topics

This draft could be a significant step towards to self-descriptiveness of
things. Constrained things might require imperative guidance or declarative
guidance in order to be managed appropriately - which in includes aspects, such
as isolation, clustering, service/capability discovery/exposure, and therefore
security automation in general. In a lot of usage scenarios, it might not be
feasible to store that guidance on the thing itself and MUD URI could be a
solution to support a lot of vendor supplied information, such as reference
integrity measurements, intended composition of composite devices, etc.

### Scope of Application

On one hand, this drafts limits the potential usage of the MUD architecture to
the use of one specific branch of YANG modules regarding ACL policies. There is
no way to express other manufacture usage description "information-types" or
"content-types" on a fundamental level and section 13 specifically states that
"coupled with the fact that we have also chosen to leverage existing
mechanisms, we are left with no ability to negotiate extensions and a limited
desire for those extensions in any event."

Creating augments for the metainfo container as it is also described in Section
13, on the other hand, allows for virtually any kind of information to be
expressed and conveyed via a MUD file, but on a semantic level that seems to be
a bit perplexing.

This comment is not intended to question the feasibility of the technical
approach - which is okay - but more taking into account the principle of least
surprise. Hence, a strong proposal - in respect to the already included
universal extension mechanism - to consider:

* aligning ACL content and "other" content on the same semantic level in the
YANG module, and * maybe indicating the corresponding semantics of the MUD file
in the MUD URI itself.

### Intended & Allowed Representations/Formats

The assumption is that neither the MUD controller nor the server serving the
MUD files are constrained devices. The things that the imperative guidance is
intended to address can be constrained devices. YANG modules are used to create
the MUD files and the representation in the MUD files is JSON.

In the scope of the extensibility feature highlighted, is it intended that
every MUD file must contain content that relates to the structure of a YANG
module (or are there other data models for data at rest planned for)?

Is JSON intended to be the only allowed representation used for the
representation of content in MUD files (a question in respect to the CBOR-based
CoMI draft in the CORE WG)?

### Segment "mud-rev"

There seems to be conflicting definitions about the semantic of the segment

Section "5. What does a MUD URL look like?" states that a "mud-rev signifies
the version of the manufacturer usage description file" and "this memo
specifies "v1" of that file". The passages quoted here seem to imply that
mud-rev is about the instance of JSON that is the content of the MUD file.

Section "13. Extensibility" though states "at a coarse grain, a protocol
version is included in a MUD URL. This memo specifies MUD version 1. Any and
all changes are entertained when this version is bumped.", which implies that
mud-rev is intended to state the version of the MUD protocol and probably the
respective YANG module(s).

Probably, you want both? Most certainly, this has to be clarified.

### Segment "model"

Every device typically is a composite. Similarly, the hardware device-model
identifier is a potential composite of device-type, device-model &
device-version (and probably even more). The text is very vague on this part,
maybe deliberatively so because the authors do not want to prescribe how to
compose the string that constitutes the model segment - but a bit more guidance
on what this typically means and what could be caveats if you concatenate this
potentially very complex identifier into a single string is strongly

Also, model is supposed to include in a not further specified way an identifier
of the "version" of the software next to the "version" of the hardware. Even in
very small things, software components can be composites, too. Furthermore, a
software version may run on more than one device-model or even device-type.
While it might introduce complexity in respect to URI composition (one/two
extra segments), separating the hardware composite-identifier from the
software/firmware composite-identifier will be helpful and provide more clear
semantics to both humans and machines.

### Query "extra"

While this option is included in the composition guidance of a MUD URI, it is
not included in the text anywhere. One guess of its purpose could be to provide
subsets of the modules via xpath or subtree expressions. Is that the case?
Additionally, including a variable in an immutable container, e.g. DevID, seems
to negate the intend of it being a variable? Maybe this should be highlighted
in the upcoming section that illustrates what the "extra" query option is for?

### Signing MUD files

The given openssl example basically allows for every kind of certificate- or
key-type. Is that intentional? While most individuals will be able to inflate
"mancertfile" or "mankey" to manufacturer certificate and manufacturer key,
respectively, I strongly recommend to provide more guidance here - especially
in regard to command parameters and appropriate hash and cipher algorithms with
a low footprint. Providing examples here will be beneficial (maybe ECDSA &

## Nits

What does the expression "relative to XML"  intends to convey in "JSON is used
as a serialization for compactness and readability, relative to XML."?


IoT-DIR mailing list