Subject: Genart early review of draft-ietf-opsawg-mud-08

From: Robert Sparks <[email-masked]>
Date: Wed, 30 Aug 2017 10:21:04 -0700

Reviewer: Robert Sparks
Review result: Almost Ready

This is an exciting concept, and the draft overall is approachable. I
have identified a few areas I think need more detail, and have a 
longish list of nits (please don't take that to be negative).

==Issues==

I find the structure of the introduction unclear. Please consider
reworking it.  I would suggest even more succinctly listing goals and
constraints, and then intended applicability (these things are in the
current text, but I think you can render them much more efficiently). In
particular, the argument that implementers of things are incented only to
provide the minimal amount of behavior to get their thingyness could be
more strongly highlighted.

The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.

In the first paragraph of Section 2, it's not clear if you are trying
to restrict the models to only those in the two documents in the list
following the paragraph. 

I am not a YANG doctor, so this may be in the weeds, but it feels like
there's a discrepancy between the diagram at the end of section 2 and the
element definitions in section 3. In particular 3.7 doesn't seem to align
with what the diagram or the example in Appendix B uses. Should you be 
defining "from-device-policy" and "to-device-policy" instead of
"packet-direction"? (I'm wondering if 3.7 reflects an older design?)

At section 3.13, the description of my-controller is not quite right.
This bit signals to the mud controller to use a mapping that it knows
about or creates. Something else established that class (and maybe gave
it a name). I talked about this with Eliot and he has a better 
description to use.

It's not clear to me that this is a good use of .well-known. I suggest
getting an expert review on the proposed usage. (I had a quick 
conversation with Mark Nottingham and got some initial feedback that 
I'm passing along here. I'm sure there's more that an in-depth review
would identify.) Why wouldn't a URI template (RFC6570) do the job? 
Rather than use RFC3986's query, consider pointing to HTML5 (which
would bring the more familiar key=value format). 

The document needs to say more about how HTTP is used. I assume you only
intend to use GET, and that you expect redirects to be followed, and that
nothing special needs to be considered with caching? The document needs
to be explicit about it. Take a look at 
<https://mnot.github.io/I-D/bcp56bis/>. (There's been some conversation
about it on the art list, so Eliot, at least, is already aware of it - 
see <https://mailarchive.ietf.org/arch/search/?q=bcp56bis>)

I think there needs to be more discussion of the PKI used for signing MUD
files.

Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being 
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

You suggest the DHCP Client (which is a thing) SHOULD log or report 
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.

The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration
of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off. 

Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

The document currently suggests that a piece of software inspect the
WHOIS database to see if registration ownership of a domain has changed.
Do you really mean software, or should this be advice to the
administrator of the controller instead? 

==Nits==

I recommend an editorial pass focusing on simplifying sentences. Look
particularly where the word "therefore" is used and consider
restructuring the surrounds. (It is used non-sequitur in a couple of
places). Be careful to call out actors explicitly (I note the places 
that particularly caught my eye below).

Some specific nits:

The abstract speaks only about properties of MUD but does not describe
what MUD _is_, or is good for. A few more words here would help.

Next to last paragraph of section 1 (before 1.1): A means for _who_ to
retrieve the description? (Consider rendering the three list elements on
their own lines.)

The last sentence of section 1 treats "enterprise networks" more
specially than it intends, I think. Why couldn't _any_ network do this?
Could the sentence be reworded to make it clear that enterprise networks
are an example?

First sentence of 1.1: Perhaps you mean "general purpose computing
devices" instead of "general computing"? "their" has an unclear
antecedent.

Last paragraph of 1.3: It's unclear what "such an approach" is intended
to point to. Would "a general solution that required capabilities their
particular device would not use" make more sense?

First paragraph of 1.5: "might to allow" is probably meant to be "might
be to allow". What does it mean for a controller to "need to speak COAP".
Do you mean "controllers capable of speaking COAP"?

Fourth paragraph of 1.5 at the discussion of time and effort: Consider
rephrasing this to focus on the result of the time and effort (high
quality) rather than the time and effort itself.

In the list of abstractions at the end of 1.5, you have three things you
describe as devices and one thing you describe as a class. You later talk
about the abstractions you've described as devices as classes. At this
point in the document what you mean by "class" has not been made as
explicit as it could be.

Section 1.8, item 3: the MUD file doesn't have hosts in it (it has
identifiers of some kind). Consider being more explicit about what
you mean by testing that against a reputation service.

Section 3.1: You say "Which turn was taken". I think you meant
"Which, in turn, was taken". Consider deleting "for those keeping score".

Section 3.3 is missing a word at "the location any MASA service"?

I found the prose in the descriptions of the "manufacturer" and
"same-manufacturer" elements (3.8 and 3.9) very confusing. I think
additional prose introducing the concepts and maybe some examples would
be very useful.

What do you mean by "matches" at 3.10. Do you mean "is"?

The caution in the 2nd paragraph of 3.12 is not clear.

At section 4, consider pointing out that you are not allowing 
DHCP by default, and that devices that are expected to use DHCP
need to have an explicit allow in their MUD file. 

The description of the manufacturer leaf in the MUD YANG model
could be made more useful.

Provide a reference for "giaddr" when you use it in section 9.2.

Section 14, 2nd paragraph: additional segmentation of what?

Second paragraph of Section 15 - it would help to be more precise
with agency. _Who_ should review the class?

In the security considerations section, when you get to the "if for some
reason it is not possible to determine whether ownership has changed",
_who_ are you suggesting conduct further review?

==Micro-nits==

1,$s/enorcement/enforcement/g

s/autjors/authors/

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 30 Aug 2017 18:00:53 -0400

> let the MUD controller clean up on its own?

I would like to add a few words to the comprehensive review presented by
Robert Sparks (I hope it is proper etiquette on this list to do so).

With respect to the observation above:

There is also a cache timeout in the MUD profile. Does it make sense  that
the MUD controller should take the minimum of the DHCP lease time and the
cache timeout and use that to time out the installed ACLs (?) The DHCP
server should also  pass to the MUD controller, some way of identifying the
device to which the lease has been granted (for example the MAC address of
the device).

The draft also not specify how the DHCP server will communicate with the
MUD controller (presumably via a simple REST interface but what is the URL
to be used and how are the parameters passed?). I think this should be
specified for interoperability between DHCP clients and MUD servers. Maybe
words describing this interaction can be added here.

Thanks,

Ranga.

>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 30 Aug 2017 18:02:35 -0400

> words describing this interaction can be added here.

Sorry: I meant interoperability between DHCP servers and MUD controllers
above.

-- 
M. Ranganathan

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 30 Aug 2017 22:02:09 -0400

This draft raises some fascinating questions.  One is "How do we ensure
that the manufacturer cannot proscribe the uses of a device that it is
capable of and that its purchaser desires?"  Another is "How do we
ensure that the manufacturer cannot reduce the permitted uses of the
device after its purchase?"

Dale

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 31 Aug 2017 07:15:46 +0000

I think we need to bear in mind that the MUD files constitute recommendations for how a device should be treated and what policies/security should be applied to it by a network. This draft, in itself, cannot allow a manufacturer to actually proscribe anything. Today, the only way to achieve what you note below, AFAIK, is for the device to have a software update of some kind applied to it.

Also, we could also argue that a manufacturer-published MUD file actually has the potential to increase transparency as it should explicitly define the traffic flows required for "proper operations".

Cheers,

Einar

> On Aug 31, 2017, at 03:02, Dale R. Worley <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2017 10:41:28 +0200

Hi Ranga,

Robert wrote a great review, and I'll respond to him in due course with
suggested changes.  I wanted to take just a moment to comment to you on
your point:

On 8/31/17 12:00 AM, M. Ranganathan wrote:
>
>
> On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
> I would like to add a few words to the comprehensive review presented
> by Robert Sparks (I hope it is proper etiquette on this list to do so).
>
> There is also a cache timeout in the MUD profile. Does it make sense 
> that the MUD controller should take the minimum of the DHCP lease time
> and the cache timeout and use that to time out the installed ACLs (?)
> The DHCP server should also  pass to the MUD controller, some way of
> identifying the device to which the lease has been granted (for
> example the MAC address of the device).
>
> The draft also not specify how the DHCP server will communicate with
> the MUD controller (presumably via a simple REST interface but what is
> the URL to be used and how are the parameters passed?). I think this
> should be specified for interoperability between DHCP clients and MUD
> servers. Maybe words describing this interaction can be added here.

That's right.  At the moment, this is an "internalized" function.  That
is to say that the DHCP server is said to be tightly coupled to the MUD
controller without standardized interfaces.  In my first implementation,
I literally just tailed dhcpd syslog entries and triggered MUD based on
DHCPREQUEST messages.  Clean-up state had to do with RELEASE or periodic
SNMP queries.  Our implementation at Cisco does something different.

However... if the OPSAWG would like, and there is interest, we can
formalize that interface.  I don't want to do it in THIS draft (it's
already fairly involved), but there's nothing to say we couldn't do some
follow-on work.

Fair enough?

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 31 Aug 2017 10:38:24 -0400

Hi Eliot,

Reply in line below:

On Thu, Aug 31, 2017 at 4:41 AM, Eliot Lear <[email-masked]> wrote:

> That's right.  At the moment, this is an "internalized" function.  That is
> to say that the DHCP server is said to be tightly coupled to the MUD
> controller without standardized interfaces.  In my first implementation, I
> literally just tailed dhcpd syslog entries and triggered MUD based on

No problem with waiting to see if there's interest from OPSAWG and others
before considering this.

By way of explanation on why I think this makes sense to standardize in MUD:

I had envisioned an architecture where the MUD controller runs in the
Service Provider cloud. The DHCP server would run in the CPE router (e.g.
as part of the firmware on a home router + NAT ).

If the statement above makes sense, since the home router is typically not
made by the same party as the service provider software, I was thinking
there should be a standardized interface between the DHCP server and MUD
controller.

Thanks.

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2017 21:07:40 +0200

Robert,

As I wrote earlier, this was a great review.  Thanks for that.  Please
see below.

> more strongly highlighted.

I've received conflicting reviews here.  Most like what's there and
while I'm open to specific textual changes, a full reorganization would
likely be destabilizing.

This is discussed in security considerations:
> It may also be useful
> to limit retrieval of MUD URLs to only those sites that are known to
> have decent web reputations.
What I am specifically talking about are web or domain reputation
services.  These are pretty commonplace today.  Your browser uses one,
and numerous companies offer them, including our own.  But to be
clearer, I propose to use the term "web or domain reputation services",
so that people know what I'm talking about.

> to restrict the models to only those in the two documents in the list

Right.  This was caught earlier, and I'll correct.

> "packet-direction"? (I'm wondering if 3.7 reflects an older design?)

Yupper.  Fixed (I think).

Proposed text:

> This null-valued node signals to the MUD controller to use whatever
> mapping it has for this URL to a controller class".  This may require
> prompting the administrator for class members.  Future work should
> seek to automate membership management.

> would bring the more familiar key=value format). 

The key issue is that we want to externalize versioning AND hardcode it
in the URL so that it's independent of transport.  Remember, there is
very little information exchange between the Thing and the network, and
I will claim that's a good thing.

> see <https://mailarchive.ietf.org/arch/search/?q=bcp56bis>)

What we say today is the following;
> Processing of this
> URL occurs as specified in {{RFC2818}} and {{RFC3986}}.
There is one aspect of caching semantics we should probably capture,
which is that the cache-validity period should exceed the HTTP cache or
expiry period as specified by max-age or Expires.  Does that sound about
right to you?

> I think there needs to be more discussion of the PKI used for signing MUD

We do have some discussion in Section 12.2.  I'm happy to add an
additional sentence or two, but would seek guidance on where you think
we're missing.

I agree.  We allude to this in the draft.  We say, for instance:
> It is possible that there may be other means for a MUD URL to be
> learned by a network.  For instance, if a device has a serial number,
> it may be possible for the MUD controller to perform a lookup of the
> device, if it has some knowledge as to who the device manufacturer
> is, and what its MUD file server is.  Such mechanisms are not
> described in this memo, but are possible.

The case we have in mind is LoRaWAN.  Should we go further?

> or rewritten to acknowledge that things typically won't do that.
I think there's a philosophical thing hiding here, though: what
expectations should we have of device.  As a SHOULD we're saying, if you
have good cause not to, ok.  But otherwise, for the sake of the sanity
of the customer, please log.

> leave the devices effectively cut-off. 

It should not, and here's why:

  * Assuming the device has already been used, there is no reason to
    simply delete the MUD file from one's cache.  The cache-validity
    value is meant as a timer to keep implementations for harassing the
    MUD file server, but there's the information is still useful, even
    if it may not have been freshened.
  * In the case where the MUD file service is unavailable when the
    device is first turned up, it's as if it had not included a MUD-URL
    in the first place.  While this may be a downgrade attack, there is,
    as I understand it, really no way to get around it, other than for
    the MUD controller to log a problem.

> let the MUD controller clean up on its own?

See other response.

> administrator of the controller instead? 

The controller.  The idea is to catch bad behavior and anomalies.  And
the bigger idea is to reduce the number of decisions that the
administrator must make, while providing relevant information with which
to make the decisions.

> that particularly caught my eye below).

ok.
> what MUD _is_, or is good for. A few more words here would help.
Right.  See response to Henk.
> retrieve the description? (Consider rendering the three list elements on
Right.  Fixed.
> Could the sentence be reworded to make it clear that enterprise networks

s/enterprise networks/local deployments/

?

> devices" instead of "general computing"? "their" has an unclear

Indeed.  fixed.

> particular device would not use" make more sense?

Reworded.

> Do you mean "controllers capable of speaking COAP"?
Fixed.
> quality) rather than the time and effort itself.

Existence is good enough in this case ;-)

> point in the document what you mean by "class" has not been made as
I've tried to review all instances of class to be clear that it is used
consistently.  This is somewhat difficult given natural language, but I
hope I've gotten it right.

> you mean by testing that against a reputation service.

Actually, it can have hosts in it, but see above.

> "Which, in turn, was taken". Consider deleting "for those keeping score".

Awwww.  Just a bit of humor? ;-)

> Section 3.3 is missing a word at "the location any MASA service"?

Ok it's cleaned up.

> additional prose introducing the concepts and maybe some examples would

Added examples per your suggestion.

> What do you mean by "matches" at 3.10. Do you mean "is"?

All of this is applicable in the context of the matches statement in the
ACL model.  I've added some explanatory text at the beginning of the
chapeau.
> The caution in the 2nd paragraph of 3.12 is not clear.

Ok, I've cleaned that up and added an example.

> need to have an explicit allow in their MUD file. 

Hmm.  The issue here is that DHCP is an L2 protocol that isn't
forwarded.  Do you think it needs to be listed anyway?

> could be made more useful.

ALL the descriptions have been improved.
> Provide a reference for "giaddr" when you use it in section 9.2.

Cleaned up (that's defined in RFC 2131, already normatively referenced,
but I expanded).
> Section 14, 2nd paragraph: additional segmentation of what?

Make that "network segmentation".
> with agency. _Who_ should review the class?

Fixed.

> _who_ are you suggesting conduct further review?

It's always the network administrator.
> 1,$s/enorcement/enforcement/g

Doh!

> s/autjors/authors/

Fixed.

Thanks again,

Eliot