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

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.

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.

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

Thank you for addressing the Gen-ART review.

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.

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.