Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13

[Eliot Lear <[e-mail]>]

Hello Adrian,

Thanks again for your highly detailed review.  Please see below:


On 11/1/17 7:53 PM, Adrian Farrel wrote:
> 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? [...]


While this may not be a *perfect* solve for all of your concerns, I hope
you will find  the proposal below Good Enough.  Keep in mind that we are
attempting to address a very broad set of devices with a large variety
of capabilities, from energy-harvesting devices that may never encrypt
(think a wall switch) to devices that have heaps of power and memory
(think robots).  Many of the devices have very limited privacy concerns,
while others will have quite a few.  In addition, whatever capabilities
the device has must intersect the capabilities found in deployments.

With all that in mind, what I propose is the following:

  * Add text that RECOMMENDs that devices make use of TEAP when there
    may be privacy concerns and when it is available; and
  * In other cases where privacy may be a concern, we should RECOMMEND
    that a configuration option be provided, particularly when devices
    are designed to be mobile, which is where I think most of your
    concerns stem from.

At the moment, you should also consider that devices leak like sieves. 
Bad guys can do a very good job of mapping devices they are looking for,
and aggregating that information.  So before you go reaching for that
button, get hold of WireShark :-(

And as you consider this as an issue, also consider the threat that you
face at home.  Every single one of those devices, if hacked, will
absolutely violate your privacy, to say the least.  The goal here is to
stop that.


>
>
> ===
>
> 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.

It's on the right list.

>
> ---
>
> 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?

This is addressed, I think, in response to mnot's review.

>
> ---
>
> 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.

Right.  Mark caught this as well.
> ---
>
> 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.

I think the participle we are looking for is "for".  Propose to change
to that.

>
> ---
>
> 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?

That's meant as an example, nothing more.  To clarify, I propose to add
"For example" in the previous sentence.
>
> ---
>
> 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.

Ok.

> ---
>
> There seems to be some overlap of terms and definitions in 1.5 and 1.6.

Can you be more specific?

>
> ---
>
> 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".

What I propose is to make the terms consistent, but added parentheticals
to remind people what those terms mean.
>
> ---
>
> 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?

That is actually discussed in Section 3.4 (these are short sections).

>
> ---
>
> 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?
Yes.
>
> 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 intent here is basically to allow for language tags to do their
thing through one level of indirection.  That doesn't require any
specific change to the URL itself.  I've included some text in response
to Mark, but that text may further shift based on other suggestions Mark
may have.


>
> ---
>
> 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.

Yes.  Bad edit.  Thanks.

>
> ====     
>
> 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

Sorry- I didn't parse this.
>
> ---
>
> Introduction
>
>    The key points are that the device itself is expected
>    to serve a limited purpose,
>
> I think you mean s/expected/intended/

How about "assumed"?

> ---
>
> 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:

s/following function/following/ ?
>
> ---
>
> Introduction
>
>    o  Provide for a means to scale network policies to the ever-
>       increasing number types of devices in the network.
>
> d/for/

ok

> s/types/of types/

right.

>
> ---
>
> 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?

Classifier.
>
> ---
>
> OLD
> 1.1.  What MUD doesn't do
> NEW
> 1.1.  What MUD Doesn't Do

ok
>
> ---
>
> 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. 

How about:

Although MUD can provide network administrators with some additional
protection when    device vulnerabilities exist, 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/

ok
> ---
>
> 1.4 para 2
> Might be worth splitting this into bullets

ok
>
> ---
>
> 1.5
> s/configuration of is/configuration is/

ok
>
> ---
>
> 2.
>
> s/only"accept"/only "accept"/

ok
>
> ---
>
> I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to
> explain the notation used in this document.

I think this is broken off to another draft
(draft-ietf-netmod-yang-tree-diagrams).

>
> ---
>
> 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.

New text in response to review.  I don't think it's English either.  I
think a line was clipped accidentally.  I propose to delete everything
after the comma.

>
> ---
>
> 3.1
>
> s/containers indicate/containers indicates/

Good catch.

> ---
>
> 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"?

This text requires a small change, anyway.

>
> ---
>
> 3.8
>
> Say that this is a null-valued node
ok
> ---
>
> 3.11
> s/mud/MUD/
>
>

Ok.


And thanks again!

Eliot