Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-25

Note: This ballot was opened for revision 18 and is now closed.

Alissa Cooper Yes

Comment (2018-04-18 for -20)
No email
send info
Thank you for addressing the Gen-ART review.

Spencer Dawkins Yes

Comment (2018-04-16 for -20)
No email
send info
I'm a Yes who's watching Discussions with other ADs, but that's still a Yes. Thanks for doing this work.

I do have some questions and comments.

I don't think this requires any changes to the current document, but I note that

3.15.  direction-initiated

   When applied this matches packets when the flow was initiated in the
   corresponding direction.  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.  When this flag is set, and
   the system has no reason to believe a flow has been initiated it MUST
   drop the packet.  This node may be implemented in its simplest form
   by looking at naked SYN bits, but may also be implemented through
   more stateful mechanisms.

it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2 over QUIC, and I'm a bit suspicious of "may also be implemented through more stateful mechanisms" in 2018. Do the right thing, of course. 

Does 

3.5.  is-supported

   This boolean is an indication from the manufacturer to the network
   administrator as to whether or not the Thing is supported.  In this
   context a Thing is said to not be supported if the manufacturer
   intends never to issue an update to the Thing or never update the MUD
   file.  A MUD controller MAY still periodically check for updates.

ever mean anything except "is-updated"? "Supported" covers a lot of ground …

If a manufacturer sells off one product line (so, flobbidy.example.com covered multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be maintained by a manufacturer that isn't flobbidy.example.com), is there a good plan for what comes next? I'm not sure what happens to is-supported, for instance. 

I'm sensitive to Eliot's "walk before trying to run" comment on another ballot thread, but I'm thinking that 

3.11.  model

   This string matches the entire MUD URL, thus covering the model that
   is unique within the context of the authority.  It may contain not
   only model information, but versioning information as well, and any
   other information that the manufacturer wishes to add.  The intended
   use is for devices of this precise class to match, to permit or deny
   communication between one another.

might usefully result in a BCP about naming models, after the community has some experience with MUD. So, that's not intended to affect the current draft text, only the working group that produced it ;-)

And, double ;-) ;-) but I wrote that before I saw this text in Section 14:

  A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may have impact on
   access of other Things.  Put another way, the admission may grow the
   access-list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that
   access-list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

So, when people know enough to describe best practices, I hope they do.

Warren Kumari Yes

Comment (2018-04-09 for -20)
No email
send info
I was the RAD until Benoit stepped down and OpsAWG transferred to Ignas, did the AD review, etc.; any issues / blame should be directed at me.

Mirja Kühlewind Yes

Comment (2018-04-18 for -20)
No email
send info
Minor comments:

1) "is-supported" confused me a bit at the beginning. Maybe "is-maintained" could be a better name?

2) Why does the MUD file contain the MUD URL? Is this meant to be used as an identifier?

3) Given this document talks quite often about possible future extensions, I'm also wondering if this should be Experimental. However, I assume the framework/architecture that is defined in this doc is not suppoed to change and as such PS might be good as well.

4) I understand that the use of YANG is quite convinent for ACLs, however, I'm wondering if it is still the right choice if the MUD File would be used to describe more detailed behavior/traffic patterns. However, that should probably not be changed now, but might be another reason to go for experimental. Annother solution would be to further separate the architecture from the MUD file format (maybe into different doc?) and include a versioning mechanism in the MUD URL.

Alexey Melnikov Yes

Comment (2018-04-17 for -20)
No email
send info
3.6.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a localized name
   associated with the Thing.

systeminfo is provided by the manufacturer (or whoever generated the MUD file), right?
Why would it be *localized* for the administrator? Think of a manufacturer from China and a sysadmin in Russia.

3.13.  controller

   This URI specifies a value that a controller will register with the
   MUD controller.  The node then is expanded to the set of hosts that
   are so registered.  This node may also be a URN.  In this case, the
   URN describes a well known service, such as DNS or NTP.

You don't list the DNS/NTP URNs until much later in the document. Please either add a forward reference or list them here.



As per response from Eliot, my earlier comments should have been addressed in editor's copy:

16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

    o Type name: application
    o Subtype name: mud+json
    o Required parameters: n/a
    o Optional parameters: n/a
    o Encoding considerations: 8bit; application/mud+json values
      are represented as a JSON object; UTF-8 encoding SHOULD be
      employed.

I am tempted to say "MUST be UTF-8 encoded".

    o Security considerations: See Security Considerations
      of this document.
    o Interoperability considerations: n/a
    o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified references. Use "[RFCXXXX]" instead of "this document" here, so that when the RFC is published, the registration template can be posted to IANA website and will have correct reference.

    o Applications that use this media type: MUD controllers as
      specified by this document.

As above.

    o Fragment identifier considerations: n/a
    o Additional information:

        Magic number(s): n/a
        File extension(s): n/a
        Macintosh file type code(s): n/a

    o Person & email address to contact for further information:
      Eliot Lear <lear@cisco.com>, Ralph Droms <rdroms@cisco.com>

I think Ralph's address is wrong in 2 places.

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
         Eliot Lear <lear@cisco.com>
         Ralph Droms <rdroms@cisco.com>
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.


UTF-8 needs to be a Normative reference (RFC 3629).

Adam Roach Yes

Comment (2018-04-18 for -20)
No email
send info
I would like to thank everyone who worked on this document, and the authors in
particular for clear, easy-to-read prose. The described mechanism seems quite useful.

---------------------------------------------------------------------------

§1.3:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

This document also uses lowercase forms of these words. Consider using the
boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.6:

>  Section 5.3.2) containing "application/mud+json", an "Accept-
>  Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
>  header ([RFC7231], Section 5.5.3).

s/header/header field/ (three times)

---------------------------------------------------------------------------

§1.7:

>  JSON is used as a serialization for compactness and readability,

Perhaps cite RFC 7159 here?

---------------------------------------------------------------------------

§3.5:

>  A MUD controller MAY still periodically check for updates.

I'm surprised to see this as a "MAY" rather than a "SHOULD." For example, even
an unsupported device may be the subject of a CERT security advisory, and the
manufacturer would presumably (if possible) take whatever mitigating steps would
make sense.

---------------------------------------------------------------------------

§8:

>                    "ietf-acldns:src-dnsname": "test.com",

The domain "test.com" is registered by an entity known as TESTCOM Inc. It's
probably best to avoid its use in an example. I would propose "test.example.org"
or something else reserved by RFC 6761.

(This applies to three other locations in the document as well)

---------------------------------------------------------------------------

§9:

>   reserved = 1*( CHAR ) ; from [RFC5234]

Is there a reason to restrict this to be only 7 bits?

---------------------------------------------------------------------------

§11:

>  The LLDP vendor specific frame has the following format:
>
>  +--------+--------+----------+---------+--------------
>  |TLV Type|  len   |   OUI    |subtype  | MUD URL
>  |  =127  |        |= 00 00 5E|  = 1    |
>  |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
>  +--------+--------+----------+---------+--------------

Should this final field be a MUD URL? Or should it be the (extensible)
MUDstring defined in §9?

---------------------------------------------------------------------------

§12.2:

>  Prior to retrieving a MUD file the MUD controller SHOULD retrieve the
>  MUD signature file by retrieving the value of "mud-signature" and
>  validating the signature across the MUD file.

I'm really confused about how this works. My understanding so far is that the
Thing will provide a URL that points to the MUD file. Inside this MUD file is a
"mud-signature" that points to the signature discussed in this section. So, to
get to the MUD signature, the MUD controller has to first retrieve the MUD file.
But the text above says that it SHOULD retrieve the signature before it
retrieves the MUD file.

How?

---------------------------------------------------------------------------

§12.2:

I'm surprised to see no discussion in here of duration of signature validity. I
presume these will typically be cached by the MUD controller.

---------------------------------------------------------------------------

§16.4:

>   o Security considerations: See Security Considerations
>     of this document.

Ideally, this would also cite RFC 7159, section 12.

Ignas Bagdonas No Objection

Comment (2018-04-17 for -20)
No email
send info
S2.1: Valid MUD file will contain "mud" and "acls" containers - what if it does not, especially if it does not contain an ACL container - how will the connectivity requirement be interpreted then? 

A few nits: 

s/MUR-URL/MUD-URL

s/yang/YANG in the document and module description fields. 

s/dns/DNS in the modules. 

S1, MUD building blocks section: "A URL that is can be used"

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-04-15 for -20)
No email
send info
Substantive:

§1.6, 2nd paragraph: Why is the SHOULD not a MUST?

§1.8, 4th paragraph: "The web server is typically run by or on behalf of the manufacturer.
   Its domain name is that of the authority found in the MUD URL. "

These URLS are likely to be hardcoded, correct? This seems to point to operational considerations, especially around Thing lifecycle and ownership.

Editorial/Nits:

Abstract: I'm not sure the use of the term "Things" will be obvious to a reader of the abstract in isolation from the rest of the document. (Abstracts should be able to stand alone.)

§1.1 : first paragraph: The idea that a Thing might have highly restricted communication patterns seems core to the document. It would be helpful to mention that earlier in §1.

§1.3, definition of "Manufacturer": The definition says that "Manufacturer" may not necessarily be the entity that constructed the Thing. But that's the plain English meaning of the word "manufacturer". If you don't want it to mean that, please consider choosing a different term. ( for example, "authority")

§1.4: "... we assume that a device has so few
   capabilities that it will implement the least necessary capabilities
   to function properly."

That's a bit circular. Perhaps one of the two instances of "capabilities" should have been "requirements"?

§1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and otherwise difficult to parse.

§1.9, list item 7:  are we talking about transient disconnect or permanent removal?

§2: "A MUD file consists of a YANG model ..."
A model instance, right? That is, not the model itself?

§3.8, 2nd sentence: Consider reformulating this as a construction of MUST.

§4: The idea of a "default" in bullet 2 seems in tension with the idea of "Anything not explicitly permitted is forbidden" in bullet 1.

§14: Please define the concept of "east-west infection".

Benjamin Kaduk (was Discuss) No Objection

Comment (2018-06-05 for -24)
No email
send info
Thank you for your efforts to resolve the DISCUSSes on this document.

Suresh Krishnan No Objection

Comment (2018-04-18 for -20)
No email
send info
* Section 1.6

I looked at RFC2618 and there is nothing even remotely resembling certificate validation. I think this reference is wrong. Please fix.

* Section 9.1

Who enforces this given that the DHCPv4 and DHCPv6 servers are separate?

"In the case where both v4 and v6 DHCP options are emitted, the same URL MUST be used."

Terry Manderson No Objection

Eric Rescorla (was Discuss) No Objection

Comment (2018-06-05 for -24)
No email
send info
Thanks for addressing my DISCUSS.

"  signature" and validating the signature across the MUD file.  The Key
   Usage Extension in the signing certificate MUST be present and have
   the bit digitalSignature(0) set.  When the id-pe-mudsigner extension
   is present in a device's X.509 certificate, the MUD signature file
   MUST have been generated by a certificate whose subject matches the
   contents of that id-pe-mudsigner extension. "

Isn't the extension required to be present.

Alvaro Retana No Objection

Martin Vigoureux No Objection