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

Request Review of draft-ietf-opsawg-mud-08
Requested rev. 08 (document currently at 20)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2017-08-29
Requested 2017-08-15
Requested by Joe Clarke
Other Reviews 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 Bjorklund (diff)
Rtgdir Last Call review of -13 by Adrian Farrel (diff)
Secdir Last Call review of -13 by Adam Montville (diff)
Genart Telechat review of -20 by Robert Sparks
Opsdir Telechat review of -20 by Scott Bradner
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.
Review State Completed
Reviewer Adam Montville
Review review-ietf-opsawg-mud-08-secdir-early-montville-2017-08-27
Posted at https://mailarchive.ietf.org/arch/msg/secdir/y8klKPQLA8CNRHUIr9KRZ1tmwvw
Reviewed rev. 08 (document currently at 20)
Review result Has Issues
Draft last updated 2017-08-27
Review completed: 2017-08-27


Hi. I am the assigned SECDIR reviewer for this document's early review reuqest. What follows is what I would write if this were a last call review, more or less.

The summary of the review is ready with (potential) issues and nits.

The draft is interesting in that it seeks to define a mechanism for devices to self-identify in a trusted manner, so that the infrastructure in which the devices operate may appropriately manage security-related configurations pertaining to those devices. The examples provided are exclusively network flow realted, but extension points are provided for future capabilities. 

The mechanism is defined as a Manufacturer Usage Description, as expressed in a file containing a YANG-based JSON serialization. This file is obtained from a device-provided URL, which is trusted to varying degrees and communitacted to the infrastructure in one of several different ways (i.e. via DHCP, 802.1AR, 802.1AB). Thus, the device emits a URL via one of the identified methods, and the URL is used to obtain the MUD, which can then be interpreted and appropriate action taken.

The security consideraitons appear well-thought and is worth a read.

This seems like a solution intended to take time to reach full potential, given that there are devices deployed in the real world that know nothing about this, and that there are different trust mechanisms at play. The intent seems less about perfection and more about moving the needle, which seems to be the right approach.

Finally, I found myself wondering if this type of appraoch - communicating intended use - could be extended to software installed on general purpose devices. For example, it would be interesting to consider how a given installed software package could communicate not only its intended use, but it's preferred configuration.

Some questions to consider (these are potential issues):

At the top of page 9, the draft describes controller behavior for mobile devices - configurations should be removed when the device is removed. Does this apply also to intermittent devices? When would a device be considered "removed" instead of simply powered down? Also, when reading that paragraph I began wondering about the load on Web servers serving MUD files - not that this draft should say anything about it, but that it's something manufacturers are going to have to consider and account for.

Is a stronger statement needed on the first bullet of section 4? Should it read: Anything not explicitly permitted MUST be denied? Similarly for other requirements in MUD file processing. At about this point, I began wondering if additional security considerations may be required for the controller.

Section 9.2 describes DHCP server behavior, and is written in a manner presuming the DHCP server knows what's happening with these building blocks. I am not a DHCP expert, so there may be something in DHCP instructing a server to ignore everything it doesn't understand, but if that is not the case, then what is expected to happen when DHCP is not expecting these options and is not going to ignore them?

Nits follow:

First paragraph of section 1.5: s/another example might to follow/another example might be to follow/

Recommend the following for definition of Thing: the device emitting a MUD URL.

Suggest striking last two sentences of Manufacturer definition, as irrelevant.

Is there a way to make the ASCII art in section 1.7 a little cleaner? One possibility is to move the right side of the bounding box to the left by two or three places. Also, the arrows to the line text isn't necessary (e.g. "----->get URL->" is cleaner as "---get URL--->").

Second bullet on page 11: s/other otherwise/otherwise/

Should there be a newline after "<CODE BEGINS>" at the start of section 6?

On page 17: s/end(ed)/end(s\/ed)/  Basically, the sentence without "ended" should read, "Information about when support ends, and when to refresh."

Vertial spacing could be improved for the first bit in section 9, so that the look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6

Section 11, first sentence: s/link layer protocols/link layer protocol/