Subject: RTG-DIR review of draft-ietf-opsawg-mud-13

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Nov 2017 18:53:35 -0000

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/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 1 Nov 2017 23:38:44 +0100

Hello Adrian,

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

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

> idnits reports RFC 2818 as a Downref as well, but didn't appear in the last

It's on the right list.

> something to which you apply MUD, but what is it actually?

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

> Please decide which you mean.

Right.  Mark caught this as well.
> somewhat specific to their use.

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

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

> Similarly, the text has "network management system" while the picture

What I propose is to make the terms consistent, but added parentheticals
to remind people what those terms mean.
> object when the Thang isn't supported?

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

> systeminfo URL, and the info that is pulled contains the localised info.
Yes.
> the locality.  Presumably we're interested in the locality of the MUD

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.

> So you probably want to point at that instead of the current 2nd para.

Yes.  Bad edit.  Thanks.

>    need: the readers are no more stupid than the average reader of an

Sorry- I didn't parse this.
> I think you mean s/expected/intended/

How about "assumed"?

>    The intent of MUD is to provide the following function:

s/following function/following/ ?
>       increasing number types of devices in the network.

ok

> s/types/of types/

right.

> Classifier or classification?

Classifier.
> 1.1.  What MUD Doesn't Do

ok
>    network is, it will never replace the need for manufacturers to 

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.
> s/an app on smart phone/an application on a smart phone/

ok
> Might be worth splitting this into bullets

ok
> s/configuration of is/configuration is/

ok
> s/only"accept"/only "accept"/

ok
> explain the notation used in this document.

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

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

> s/containers indicate/containers indicates/

Good catch.

> "a configuration file?" "operation"? "in configuration information"?

This text requires a small change, anyway.

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

Ok.

And thanks again!

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Nov 2017 00:01:55 -0000

This looks really good, Eliot. Thanks for being so responsive and positive to my peculiar brand of paranoia and pedantry.

Just a few bits of discussion remain...

>> 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
>> (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...
>>
> 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
> while others will have quite a few.  In addition, whatever capabilities the
> device has must intersect the capabilities found in deployments.
>
> • Add text that RECOMMENDs that devices make use of TEAP when there
> • 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.

This is getting gooder. Thanks.
Even when the MUD controller is on the premises (the not mobile case), it contacts
an offsite file server, and that act is visible.
Suppose my Hi-Fi uses MUD - now you know that my house is worth robbing.
Suppose my intruder alarm uses MUD - now you know what security system I have.

Of course, when the MUD controller is remote (the mobile case), it's all even more worrying.

I know you are trying to trade between perfect and getting something that will be implemented and so make the world a somewhat better place. But just recall that someone implemented those devices that "leak like sieves" and those folk are unlikely to see a Recommendation as anything like a strong hint.

Well, I'm not in a position to block the whole effort, and I'm not enough of an expert to suggest a solution to my concern that works for all types of device.

> Can you be more specific?

1.5 and 1.6 both have "manufacturer".
1.5 has "controller" and 1.6 has "MUD controller".
The definitions don't match.

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

I'm missing something, but that's OK, I don't have to understand something for it to be right :-)

So long as it is possible for the MUD Controller to be in one locale and the MUD Server in another and all the bits to work right, I'm happy.

> Sorry- I didn't parse this.

Sorry I'm being sassy.

I mean, please don't capitalise for emphasis. Just limit yourself to 2119 capitalisation.

>> I think you mean s/expected/intended/

We're both being overly passive. Who has the expectation/intention/assumption?

By "intended" I meant "intended by the manufacturer".
So, actually, any one of the three words is fine, if you can attribute the verb to someone.

>> Classifier or classification?

Oh.

A "classifier" is a person or thing that classifies.
I don't think the device emits a thing or a person :-)
I think it emits a piece of information that allows the device to be classified. 

Cheers,
Adrian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Nov 2017 09:46:07 +0100

Hi Adrian,

> This looks really good, Eliot. Thanks for being so responsive and positive to my peculiar brand of paranoia and pedantry.

Not at all, and thanks for improving the work.
> Suppose my intruder alarm uses MUD - now you know what security system I have.

Here, I think you have some cause for hope, because on the whole, in the
home, wireless encryption is generally used.  It's not perfect but would
address the point you make above.

> Of course, when the MUD controller is remote (the mobile case), it's all even more worrying.

Yes, and to that end I propose to highlight a particular warning for
open networks (this would be one amongst many that developers should
heed with regard to open networks).

> I know you are trying to trade between perfect and getting something that will be implemented and so make the world a somewhat better place. But just recall that someone implemented those devices t…

My hope is that this problem will abate over time, but I really cannot
say.  My guess is that the same who are unlikely to heed such a
recommendation are also highly unlikely to implement MUD in the first place.

> The definitions don't match.

Ah- that is because they are being used in different contexts.  One is
intended as a YANG node and the other really means those people who
build the thing.
> I mean, please don't capitalise for emphasis. Just limit yourself to 2119 capitalisation.

Got it.

> We're both being overly passive. Who has the expectation/intention/assumption.
>

Ok, I think we might have to disagree.  The use of passive in this case
is appropriate because the assumption is general and not attached to a
single party.  Also, the following phrase – and the rest of the document
– make clear who is doing what.

> I think it emits a piece of information that allows the device to be classified.

Means of classification?

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Nov 2017 11:14:09 -0000

Getting close.

> > Even when the MUD controller is on the premises (the not mobile case), it
> > contacts an offsite file server, and that act is visible.

Yes. This addresses communications between device and router, and between router and MUD controller.
Of course, there are some issues with the use of wireless encryption in the home (like security concerns) added to the fact that far fewer people use wireless security than you might think given that you hang out with technology-aware folk. But that's OK because (nominally) we have a protection mechanism.

But when the home-based MUD controller uses a URL to access a MUD server, isn't that pretty visible and associated with the home (via the IP address)?

> heed with regard to open networks).

OK. That works.

> > I know you are trying to trade between perfect and getting something that will
> > be implemented and so make the world a somewhat better place. But just recall
> > that someone implemented those devices that "leak like sieves" and those folk
> > are unlikely to see a Recommendation as anything like a strong hint.
> 

Yeah, you're right.

I assume you have already written the paper titled "As Clear As MUD".

> intended as a YANG node and the other really means those people who

Yeah, got that. But isn't the YANG node supposed to encode the information about the real things?

Well, if everyone else thinks this is clear.

> – make clear who is doing what.

Sigh. You'll not convince me that passive voice is ever a good thing in a spec. 
A general assumption is pretty risky. It's a second order assumption: you're assuming that I assume. I'm reminded that the US has actually written laws about "intended use" because those assumptions were not necessarily shared.

Maybe it's just writing style.

Thanks,
Adrian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 2 Nov 2017 16:00:57 +0100

Hi Adrian,

Trimming now.

On 11/2/17 12:14 PM, Adrian Farrel wrote:
> But when the home-based MUD controller uses a URL to access a MUD
> server, isn't that pretty visible and associated with the home (via
> the IP address)?

The communication occurs via TLS.  I just don't know how to do better. 
Also, I perceive two additional mitigations, one something of a happy
accident: I expect that there will be providers that do MUD file
management and so many of these URLs will all likely be served from the
same places, and not necessarily give away what they are.  The second is
that much of this data will be served from commercial clouds for
reliability purposes.

Regarding passive tense let us take that as editorial and I will work
with you to find a form that fits.

AD and WG permitting of course.

Eliot