I note that the LC ends right before IETF 100, which means that this document won't be on the IESG Telechat until (at least) Nov/30. If needed, the review period can be extended until (a few days before) then.

Reviewreview-ietf-opsawg-mud-13-rtgdir-lc-farrel-2017-11-01

Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-ietf-opsawg-mud-13.txt
Reviewer: Adrian Farrel
Review Date: 1 November 2017
IETF LC End Date: 7 November 2017
Intended Status: Standard Track
Overview
Manufacturer Usage Descriptions (MUD) provide a means for elements of
an IoT network to indicate what sorts of access and network
functionality they require in order to function properly. The
emphasis of this document is on access control although the authors
envision future extensions for "other aspects".
The document is a collection of bits and pieces to enable MUD: two
YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
specification, an X.509 certificate extension, and a means to sign and
verify the descriptions.
Some future work is listed, but I see no evidence that this work is
actually anything more than a possibility: there are no drafts that
appear to cover any additional MUD specifications.
Summary:
I have some minor concerns about this document that I think should be
resolved before publication. I have flagged one of these as a more
serious issue, although I think it may be possible to solve with some
2119 language that governs expectations on implementations.
The document was easy to read although the number of minor issues and
nits in the early section suggests that the late-stage reviews were more
focused on the YANG than the text.
Adrian
===
Major Issues:
I know I ranted about privacy before and the authors took some text I wrote as
the basis of the privacy considerations, but I'm still worried that the default
will be that devices are MUD-enabled (good) and that users will not be
protected. It would be sad if the user's only option is to reject MUD devices
(especially as they might not even know that the devices are MUD-enabled). More
burble below, but it seems to me that we should make privacy-supporting modes of
operation at least the default, but possibly the only approach.
Section 15 has...
The release of a MUD URL by a Thing reveals what the Thing is, and
provides an attacker with guidance on what vulnerabilities may be
present.
Pleased to see this text: it was a security concern I had. Good to have
it flagged. However, the mitigation suggested 2 paragraphs later is a
bit thin and sounds rather optional. I see how an implementer might
take action, but what can a user do to protect their device?
Similarly,
While the MUD URL itself is not intended to be unique to a specific
Thing, the release of the URL may aid an observer in identifying
individuals when combined with other information. This is a privacy
consideration.
This is not the only privacy issue since once a location or individual
has been identified, the release of MUD URLs announce things about the
location (such as what valuable Things are present and even what
security devices are in use). Furthermore, the picture of an individual
built up by knowing what Things they have is a substantial concern.
At least in the first case the implementer has an interest in applying
the protection, but the only person who cares about my privacy is me.
What options do I have to protect myself (except not purchasing MUD-
enabled devices which is presumably not the objective we want to
pursue)?
===
Minor Issues:
The last call indicated a Downref to draft-ietf-netmod-acl-model. All well and
good.
idnits reports RFC 2818 as a Downref as well, but didn't appear in the last
call.
---
Abstract
Referring to "Things" is cute, but actually doesn't help the reader.
Could you give a clue or two?
BTW, the definition in 1.6 is a little thin and circular. A Thing is
something to which you apply MUD, but what is it actually?
---
The Abstract says...
The initial focus is on access control.
But the Introduction says...
Although this memo may seem to stress
access requirements, usage intent also consists of quality of service
needs a device may have.
Please decide which you mean.
---
Introduction
OLD
The Internet has largely been constructed on general purpose
computers, those devices that may be used for a purpose that is
specified by those who buy the device.
NEW
The Internet is largely constructed from general purpose computers.
These are devices that may be used for a purpose that is specified by
those who buy the device.
Although this is ambiguous and probably wrong: I think routers and
switches probably form a part of the Internet, and I suspect they are
somewhat specific to their use.
---
Introduction
In the context of a smarter
device that has a built in Linux stack, it might be an integrator of
that device.
Is there something special about Linux?
---
1.5
This section introduces the "MUD controller." It's unexplained.
It could be helpful to pull section 1.6 up perhaps to 1.3.
---
There seems to be some overlap of terms and definitions in 1.5 and 1.6.
---
1.7 has a nice picture, thanks.
But I note that the text describes a "web site" while the picture shows
a "file server".
Similarly, the text has "network management system" while the picture
has "MUD controller".
---
3.3 makes reference to "is supported" and 3.4 gives clarity to what
that means. Shouldn't this section also describe the meaning of this
object when the Thang isn't supported?
---
3.5 has me confused. Looks like a fine idea, but how does it work? A
Thing reports the MUD URL, and the file that is pulled contains the
systeminfo URL, and the info that is pulled contains the localised info.
Have I got that right?
That means that the MUD URL has to include the correct systeminfo for
the locality. Presumably we're interested in the locality of the MUD
controller.
The MUD controller knows its locality. Is it supposed to tell the
web server? How else does the right systeminfo URL get provided, or
the URL get mapped to the right localised information?
---
16.2
Something messed up here.
We have
The IANA has allocated option 161 in the Dynamic Host Configuration
Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry
for the MUD DHCPv4 option.
IANA is requested to allocated the DHCPv4 and v6 options as specified
in Section 9.
But section 9 has 161 and 112 explicitly mentioned.
116 is already in the registry, but presumably you have an IANA action
to update the reference to this document when it becomes an RFC.
112 is also already in the DHCPv6 options registry.
So you probably want to point at that instead of the current 2nd para.
====
Nits:
Introduction
Please do NOT use random uppercase words in your text. There's NO
need: the readers are no more stupid than the average reader of an
RFC.
Ditto 3.4, 3.6
---
Introduction
The key points are that the device itself is expected
to serve a limited purpose,
I think you mean s/expected/intended/
---
Introduction
The intent of MUD is to solve for the following problems:
d/for/
Although the list that follows is not a list of problems. So, perhaps,
The intent of MUD is to provide the following function:
---
Introduction
o Provide for a means to scale network policies to the ever-
increasing number types of devices in the network.
d/for/
s/types/of types/
---
Introduction
Provide a means to address at least some vulnerabilities in a way
that is faster than it might take to update systems.
s/than/than the time/
---
Introduction
o A classifier that a device emits that can be used to locate a
description;
Classifier or classification?
---
OLD
1.1. What MUD doesn't do
NEW
1.1. What MUD Doesn't Do
---
Section 1.1
No matter how good a MUD-enabled network is, it will never replace
the need for manufacturers to patch vulnerabilities. It may,
however, provide network administrators with some additional
protection when those vulnerabilities exist.
Does this paragraph belong in this section? Seems to say what MUD does,
not what MUD doesn't do.
Maybe flip the order of presentation?...
MUD may provide network administrators with some protection when
vulnerabilities exist, however, no matter how good a MUD-enabled
network is, it will never replace the need for manufacturers to
patch vulnerabilities.
---
1.2
s/an app on smart phone/an application on a smart phone/
---
1.4 para 2
Might be worth splitting this into bullets
---
1.5
s/configuration of is/configuration is/
---
2.
s/only"accept"/only "accept"/
---
I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to
explain the notation used in this document.
---
3.
Note that in this section, when we use the term "match" we are
referring to the ACL model "matches" node, and thus returns positive
such that an action should be applied.
Is that English? I know what it means, but not what it says.
---
3.1
s/containers indicate/containers indicates/
---
3.1
[I-D.ietf-netmod-acl-model] describes access-lists but does not
attempt to indicate where they are applied as that is handled
elsewhere in a configuration
"a configuration file?" "operation"? "in configuration information"?
---
3.8
Say that this is a null-valued node
---
3.11
s/mud/MUD/