Manufacturer Usage Description Specification
RFC 8520

Received changes through RFC Editor sync (created alias RFC 8520, changed abstract to 'This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.', changed pages to 60, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-03-12, changed IESG state to RFC Published)

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
* 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."

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
Hopefully this will be an easy DISCUSS to clear.

Partially guided by some of the discussion that has already happened, it seems like there are three places where
authentication/identity validation occurs in the MUD flow: the (CMS) signature alongside the MUD file, the TLS
connection used to retrieve the MUD file, and the binding between the MUD URL and the device itself.  The last
one seems pretty important, especially given some of the points in Ekr's DISCUSS about limiting damage in case
of compromised/malicious device.  The security considerations already give some coverage in the first paragraph,
but basically limited to the "manufacturer" groupings, and only covers the usage of the certificate extension for
binding a MUD URL to a specific device.  There's also some related text when considering what to do if the MUD
URL for a given MAC address changes, but I didn't see any coverage for the general case.  The entity using the MUD
contents needs to be aware of the provenance of the URL and the risks of using a "spoofed" MUD from an attacker.

[Ballot comment]
It's pretty exciting to have the prospect of getting this kind of information out there in a standard, machine-readable
format.  That said ... there's been a decent amount of talk of "still getting feet wet", "need to get experience how this unfolds", etc.,
so I have to ask: are we confident that this is better as Proposed Standard than Experimental?

Adding the ability to use DNS names in ACL 'match' patterns should probably be accompanied by some note about
the (lack of) veracity of DNS information.  This is not a DISCUSS since the DNS name is expected to be what the
Thing actually attempts to use, and the DNS resolver used by the Thing is likely to be the same one as used by the
network, so in that sense the ACL will still "work as intended" even in the face of spoofed DNS.  But we can probably
mention that it's still a risk.

I echo Ekr's question about CMS vs. JWS.

Please consider using the BCP 14/RFC8174 boilerplate.

Other comments (in document order, sorry about the interspersed nits).

Section 1

  o  Substantially reduce the threat surface on a device entering a
      network to those communications intended by the manufacturer.

Comma after 'network'?


Section 1.5

      [...] The DHCP server may take further actions,
      such as retrieve the URL or otherwise pass it along to network
      management system or controller.

Retrieve the resource from the URL?


Section 1.7

  my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits.

I'm probably just being dumb, but I am failing to parse what this
means.


Section 1.8

  The information returned by the MUD file server (a web server) is
  valid for the duration of the Thing's connection, or as specified in
  the description.  Thus if the Thing is disconnected, any associated
  configuration in the switch can be removed.  Similarly, from time to
  time the description may be refreshed, based on new capabilities or
  communication patterns or vulnerabilities.

This feels slightly internally inconsistent about valid/refreshed.


Section 12.2

"Prior to retrieving a MUD file [...] validating the signature
across the MUD file" is internally inconsistent.  Perhaps the first
pargaraph is stale, since the second paragraph basically duplicates
it?

Also,
  [...] For another, what is more important
  is the accountability of the recommendation, and not the
  cryptographic relationship between the device and the file.
seems not really true.

  An example:

  % openssl cms -verify -in mudfile.p7s -inform DER -content
  % mudfile

  Note the additional step of verifying the common trust root.

The additional step that's not included in the example?  Maybe it
could be included?


Section 15

Lots of tiny comments, so I'll quote and put inline.

% Based on how a MUD URL is emitted, a Thing may be able to lie about

s/emitted/conveyed to the network/?

% what it is, thus gaining additional network access.  There are

s/thus/potentially/
And maybe clarify ", based on the (false) MUD that is claimed"?

% several means to limit risk in this case.  The most obvious is to
% only believe Things that make use of certificate-based authentication
% such as IEEE 802.1AR certificates.  When those certificates are not
% present, Things claiming to be of a certain manufacturer SHOULD NOT
% be included in that manufacturer grouping without additional
% validation of some form.  This will occur when it makes use of

"occur" sounds more like it refers to the validation than the
"claiming to be of a certain manufacturer"; maybe "be relevant"?

% primitives such as "manufacturer" for the purpose of accessing Things
% of a particular type.  Similarly, network management systems may be
% able to fingerprint the Thing.  In such cases, the MUD URL can act as
% a classifier that can be proven or disproven.  Fingerprinting may
% have other advantages as well: when 802.1AR certificates are used,
% because they themselves cannot change, fingerprinting offers the
% opportunity to add artificats to the MUD URL.  The meaning of such

typo                ^^^^^^^^^^
This is the "reserved" field in the MUD URL?  Maybe best to say so
explicitly.

% artifacts is left as future work.
%
% Network management systems SHOULD NOT accept a usage description for
% a Thing with the same MAC address that has indicated a change of
% authority without some additional validation (such as review by a
% network administrator).  New Things that present some form of

This sentence could probably be tightened up.

% unauthenticated MUD URL SHOULD be validated by some external means
% when they would be otherwise be given increased network access.

I'd suggest replacing "otherwise" with a more concrete condition.

% It may be possible for a rogue manufacturer to inappropriately
% exercise the MUD file parser, in order to exploit a vulnerability.
% There are three recommended approaches to address this threat.  The
% first is to validate the signature of the MUD file.  The second is to

How does this help -- can't a rogue manufacturer sign whatever
malformed blob it wants?

% have a system do a primary scan of the file to ensure that it is both
% parseable and believable at some level.  MUD files will likely be
% relatively small, to start with.  The number of ACEs used by any
% given Thing should be relatively small as well.  It may also be
% useful to limit retrieval of MUD URLs to only those sites that are
% known to have decent web or domain reputations.
%
[...]
%
% 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.

It also seems to be permitted for the manufacturer to give Things
unique MUD URLs and perform (e.g., location) tracking based on
accesses to that URL...

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

...even though you disclaim that intent.  I suspect that any
normative guidance on making MUD URLs non-identifying would not
really be enforcable, but it may be worth mentioning this
consideration earlier in the document (e.g., in Sections 5 and 10).
Also, it's not necessarily just the "release" of the MUD URL, but
the actual accesses by the MUD controller, that give the MUD URL's
origin server real data about where the device being tracked is
located/used.

% In addressing both of these concerns, implementors should take into
% account what other information they are advertising through
% mechanisms such as mDNS[RFC6872], how a Thing might otherwise be
% identified, perhaps through how it behaves when it is connected to
% the network, whether a Thing is intended to be used by individuals or
% carry personal identifying information, and then apply appropriate
% data minimization techniques.  One approach is to make use of TEAP
% [RFC7170] as the means to share information with authorized
% components in the network.  Network elements may also assist in
% limiting access to the MUD URL through the use of mechanisms such as
% DHCPv6-Shield [RFC7610].
[...]


Appendix C

  In this sample extension we augment the core MUD model to indicate
  whether the device implements DETNET.  If a device later attempts to
  make use of DETNET, an notification or exception might be generated.

Presumably this should say that if a device *claims to not use
DETNET* but then later does?

[Ballot comment]
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"

[Ballot comment]
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 , Ralph Droms

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

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
        Eliot Lear
        Ralph Droms
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.


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

[Ballot comment]
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.

[Ballot comment]
I've only reviewed a part of the document, so sending you my current comments:

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 , Ralph Droms

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

    o Intended usage: COMMON
    o Restrictions on usage: none
    o Author:
        Eliot Lear
        Ralph Droms
    o Change controller: IESG
    o Provisional registration? (standards tree only): No.


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

[Ballot comment]
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".

[Ballot discuss]
Re-posted due to pilot error.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>      The certificate extension is described below.
> 
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as a post-compromise mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>        https://example.com/lightbulbs/colour/v1
> 
>      The MUD URL identifies a Thing with a specificity according to the
>      manufacturer's wishes.  It could include a brand name, model number,
>      or something more specific.  It also could provide a means to
>      indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>                    -in mudfile -binary -outform DER - \
>                    -certfile intermediatecert -out mudfile.p7s
> 
>      Note: A MUD file may need to be re-signed if the signature expires.
> 
>  12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.

[Ballot comment]

> 
>  Abstract
> 
>      This memo specifies a component-based architecture for manufacturer
>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>      Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>      it continues to make sense for general purpose computing devices
>      today, including laptops, smart phones, and tablets.
> 
>      [RFC7452] discusses design patterns for, and poses questions about,
>      smart objects.  Let us then posit a group of objects that are
>      specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>      specifically not general purpose computers.  These devices, which
>      this memo refers to as Things, have a specific purpose.  By
>      definition, therefore, all other uses are not intended.  The
>      combination of these two statements can be restated as a manufacturer
>      usage description (MUD) that can be applied at various points within
>      a network.

I would make the point here that the purpose of the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.


>      can say about that light bulb, then, is that all other network access
>      is unwanted.  It will not contact a news service, nor speak to the
>      refrigerator, and it has no need of a printer or other devices.  It
>      has no social networking friends.  Therefore, an access list applied
>      to it that states that it will only connect to the single rendezvous
>      service will not impede the light bulb in performing its function,

This *might* be true, but imagine that I wanted to control my light
bulbs over Tor and then I would want it to act as a Tor hidden
service.


>      a public key.  In these cases, manufacturers may be able to map those
>      identifiers to particular MUD URLs (or even the files themselves).
>      Similarly, there may be alternative resolution mechanisms available
>      for situations where Internet connectivity is limited or does not
>      exist.  Such mechanisms are not described in this memo, but are
>      possible.  Implementors should allow for this sort of flexibility of

Do you mean SHOULD?


>  1.6.  Processing of the MUD URL
> 
>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>      signature files as per [RFC7230], using the GET method [RFC7231].
>      They MUST validate the certificate using the rules in [RFC2618],
>      Section 3.1.

ITYM 2818.


> 
>      The files that are retrieved are intended to be closely aligned to
>      existing network architectures so that they are easy to deploy.  We
>      make use of YANG [RFC7950] because of the time and effort spent to
>      develop accurate and adequate models for use by network devices.
>      JSON is used as a serialization for compactness and readability,

Nit: "serialization format"


>          domain reputation service, and it may test any hosts within the
>          file against those reputation services, as it deems fit.
> 
>      4.  The MUD controller may query the administrator for permission to
>          add the Thing and associated policy.  If the Thing is known or
>          the Thing type is known, it may skip this step.

What is a "Thing type"?


> 
>  2.1.  The IETF-MUD YANG Module
> 
>      This module is structured into three parts:
> 
>      o  The first container "mud" holds information that is relevant to

This appears to be the only container.


> 
>      o  The third component augments the tcp-acl container of the ACL
>        model to add the ability to match on the direction of initiation
>        of a TCP connection.
> 
>      A valid MUD file will contain two root objects, a "mud" container and

MUST contain?


>      extension example can be found in Appendix C.
> 
>  3.9.  manufacturer
> 
>      This node consists of a hostname that would be matched against the
>      authority component of another Thing's MUD URL.  In its simplest form

In what encoding?


>      the expression as is appropriate in their deployments.
> 
>  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

The use of "controller" and "MUD controller" is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agent"?


>      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

SYN seems over-specific here, as it doesn't apply to UDP-based
protocols.


>      reserved = 1*( CHAR ) ; from [RFC5234]
> 
>      The entire option MUST NOT exceed 255 octets.  If a space follows the
>      MUD URL, a reserved string that will be defined in future
>      specifications follows.  MUD controllers that do not understand this
>      field MUST ignore it.

This is a matter of taste I suppose, but why not just have two chunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.


>  9.2.  Server Behavior
> 
>      A DHCP server may ignore these options or take action based on
>      receipt of these options.  If a server successfully parses the option
>      and the URL, it MUST return the option with length field set to zero
>      and a corresponding null URL field as an acknowledgment.  Even in

What this means here is "no URL field"? Generally, the use of "null"
is confusing in the context of string processing because of C
semantics.


> 
>      Because MUD files contain information that may be used to configure
>      network access lists, they are sensitive.  To insure that they have
>      not been tampered with, it is important that they be signed.  We make
>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>      this purpose.

It's very odd to be using CMS here when you are serializing in JSON.
This is a decision for the WG, but why aren't you using JWS?

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3106


The threat model for MUD doesn't seem clear, at least to me. It seems
like there are at least two potential threat models:  - Telling the
network how to configure access control to prevent the device from
being compromised - Telling the network how to configure access
control the limit the damage in case a device is compromised (e.g.,
avoiding its use in a botnet).  Are both of these in scope? If so, the
latter seems to need substantially more analysis -- and perhaps
mechanism -- because it seems relatively easy for the attacker to
evade access control limits once it has replaced the firmware on the
device (as noted below). In either case, the document needs to be
clear about this, whether in the security considerations or elsewhere.





IMPORTANT
>      The certificate extension is described below.
> 
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

IMPORTANT: What does "disconnected" mean in this context? Does a
reboot count? What if I am wireless? This is a critical question if
MUD is intended as an access control mechanism. Say that an attacker
compromises the firmware for a device and then forces a reboot
followed by a 2 hour pause before the wireless NIC is activated. Will
this result in configuration removal? If so, MUD seems of limited use,
because it can then make itself appear to be a new device with a new
MUD configuration. (This is of course true in general in a wireless
context if the firmware can change the client's L2 address).


>        https://example.com/lightbulbs/colour/v1
> 
>      The MUD URL identifies a Thing with a specificity according to the
>      manufacturer's wishes.  It could include a brand name, model number,
>      or something more specific.  It also could provide a means to
>      indicate what version the product is.

IMPORTANT: Are you just using "identify" loosely here? I see how it
can be *based* on those characteristics, but absent a schema it
doesn't seem like the MUD controller can infer any of those
characteristics from the URL.


>                    -in mudfile -binary -outform DER - \
>                    -certfile intermediatecert -out mudfile.p7s
> 
>      Note: A MUD file may need to be re-signed if the signature expires.
> 
>  12.2.  Verifying a MUD file signature

IMPORTANT: This seem underspecified. Is the intention that these
certificates will be rooted in the WebPKI? Something else? I realize
that IETF tends to be kind of vague about where trust anchors come
from, but at the end of the day its hard to see how to implement this
interoperably without some more guidance.

[Ballot comment]

> 
>  Abstract
> 
>      This memo specifies a component-based architecture for manufacturer
>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>      Things to signal to the network what sort of access and network

I realize that "Things" has become a marketing term, but it's opaque
and unnecessary here. "elements" would be the conventional term.


>      it continues to make sense for general purpose computing devices
>      today, including laptops, smart phones, and tablets.
> 
>      [RFC7452] discusses design patterns for, and poses questions about,
>      smart objects.  Let us then posit a group of objects that are
>      specifically not general purpose computers.  These devices, which

I don't think this makes sense. These devices usually *are* general
purpose computers (turing complete, etc.) and not infrequently run the
same operating systems (Android, for instance), but they're intended
for specific purposes. In fact the core of the problem is that they
are general purpose computers but embedded in a limited purpose
device.


>      specifically not general purpose computers.  These devices, which
>      this memo refers to as Things, have a specific purpose.  By
>      definition, therefore, all other uses are not intended.  The
>      combination of these two statements can be restated as a manufacturer
>      usage description (MUD) that can be applied at various points within
>      a network.

I would make the point here that the purpose of the MUD is to describe
the communications pattern. You only really get that by the statement
in S 1.1 that the communication pattern of other devices is too
complicated to profile.


>      can say about that light bulb, then, is that all other network access
>      is unwanted.  It will not contact a news service, nor speak to the
>      refrigerator, and it has no need of a printer or other devices.  It
>      has no social networking friends.  Therefore, an access list applied
>      to it that states that it will only connect to the single rendezvous
>      service will not impede the light bulb in performing its function,

This *might* be true, but imagine that I wanted to control my light
bulbs over Tor and then I would want it to act as a Tor hidden
service.


>      a public key.  In these cases, manufacturers may be able to map those
>      identifiers to particular MUD URLs (or even the files themselves).
>      Similarly, there may be alternative resolution mechanisms available
>      for situations where Internet connectivity is limited or does not
>      exist.  Such mechanisms are not described in this memo, but are
>      possible.  Implementors should allow for this sort of flexibility of

Do you mean SHOULD?


>  1.6.  Processing of the MUD URL
> 
>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>      signature files as per [RFC7230], using the GET method [RFC7231].
>      They MUST validate the certificate using the rules in [RFC2618],
>      Section 3.1.

ITYM 2818.


> 
>      The files that are retrieved are intended to be closely aligned to
>      existing network architectures so that they are easy to deploy.  We
>      make use of YANG [RFC7950] because of the time and effort spent to
>      develop accurate and adequate models for use by network devices.
>      JSON is used as a serialization for compactness and readability,

Nit: "serialization format"


>      The certificate extension is described below.
> 
>      The information returned by the MUD file server (a web server) is
>      valid for the duration of the Thing's connection, or as specified in
>      the description.  Thus if the Thing is disconnected, any associated
>      configuration in the switch can be removed.  Similarly, from time to

Updated: s/intended as an access control mechanism/intended as a post-
compromise mechanism/


>          domain reputation service, and it may test any hosts within the
>          file against those reputation services, as it deems fit.
> 
>      4.  The MUD controller may query the administrator for permission to
>          add the Thing and associated policy.  If the Thing is known or
>          the Thing type is known, it may skip this step.

What is a "Thing type"?


> 
>  2.1.  The IETF-MUD YANG Module
> 
>      This module is structured into three parts:
> 
>      o  The first container "mud" holds information that is relevant to

This appears to be the only container.


> 
>      o  The third component augments the tcp-acl container of the ACL
>        model to add the ability to match on the direction of initiation
>        of a TCP connection.
> 
>      A valid MUD file will contain two root objects, a "mud" container and

MUST contain?


>      extension example can be found in Appendix C.
> 
>  3.9.  manufacturer
> 
>      This node consists of a hostname that would be matched against the
>      authority component of another Thing's MUD URL.  In its simplest form

In what encoding?


>      the expression as is appropriate in their deployments.
> 
>  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

The use of "controller" and "MUD controller" is very unfortunate
terminology. Could you perhaps rename one of these? Given that
"controller" is encoded in the YANG model, perhaps "MUD agent"?


>      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

SYN seems over-specific here, as it doesn't apply to UDP-based
protocols.


>      reserved = 1*( CHAR ) ; from [RFC5234]
> 
>      The entire option MUST NOT exceed 255 octets.  If a space follows the
>      MUD URL, a reserved string that will be defined in future
>      specifications follows.  MUD controllers that do not understand this
>      field MUST ignore it.

This is a matter of taste I suppose, but why not just have two chunks
in the option. The cost would be one byte in the non-extension case
but then you would be able to handle extensions that brought the total
length above 255.


>  9.2.  Server Behavior
> 
>      A DHCP server may ignore these options or take action based on
>      receipt of these options.  If a server successfully parses the option
>      and the URL, it MUST return the option with length field set to zero
>      and a corresponding null URL field as an acknowledgment.  Even in

What this means here is "no URL field"? Generally, the use of "null"
is confusing in the context of string processing because of C
semantics.


> 
>      Because MUD files contain information that may be used to configure
>      network access lists, they are sensitive.  To insure that they have
>      not been tampered with, it is important that they be signed.  We make
>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>      this purpose.

It's very odd to be using CMS here when you are serializing in JSON.
This is a decision for the WG, but why aren't you using JWS?

[Ballot comment]
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.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type required in Proposed Standard.  This is the right track as it requires coordination between vendors and consumers in order to achieve interoperability, and there will be continuing work as more implements are produced.

The type of RFC is called out in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This memo specifies a component-based architecture for manufacturer
  usage descriptions (MUD).  The goal of MUD is to provide a means for
  Things to signal to the network what sort of access and network
  functionality they require to properly function.  The initial focus
  is on access control.  Later work can delve into other aspects.

  This memo specifies 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.

Working Group Summary

  There was excellent discussion and comments throughout.  The authors were quick to respond, and incorporate feedback as well as push back on items thought to be out of scope.  The discussions led to talks of subsequent work for future drafts.

Document Quality

  There are implementations in the works.  Eliot Lear has stood up a tool at https://mudmaker.org/ that builds MUD files as a way to help vendors.  There were numerous expert reviews including multiple areas and YANG Doctors.  Those reviews led to some tighter security considerations, as well as more explicit mention that MUD files are to be taken under operational advisement as it is not wise to blindly apply others' configurations to your network.  The YANG Doctors review, in particular, led to a better structure to the MUD YANG module that will allow it to provide a data definition, as well as be implemented on controllers if need be.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Joe Clarke is the document shepherd.
 
  Warren Kumari is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd reviewed this draft multiple times across multiple revisions and provided feedback to the authors on the opsawg list each time.  All feedback was incorporated.  The Document Shepherd believes this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  Many reviews were performed both in opsawg, as well as in other areas.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was reviewed by the Security Directorate, IoT Directorate, YANG Doctors, and GEN ART.  Feedback was reported by all reviewers and the responses were incorporated into the text as needed.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.  All IPR has been reported.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, a disclosure has been made.  There was no discussion on the IPR only to say IPR exists and it was disclosed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Consensus was very solid with many expressing support for the work.  There were no dissenters, and there were a large number of reviews outside of the authors' organization that indicate broad support. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No NITS beyond some spacing weirdness caused by pyang's tree output.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by YANG Doctors as described above.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The only non-ratified normative reference is to draft-ietf-netmod-acl-model.  This is a WG document proceeding towards standardization  I do not have a firm timeline on when that is expected.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations follow with the text of the document by requiring registration for the module namespaces, DHCP options to facilitate the transmission of MUD URLs, PKIX extensions for MUD, LLDP extensions for MUD advertisement, a MUD file media type, a URN for MUD resources, and a new registry for MUD extensions.

Each of these requirements are described within the text of the document to justify the ask of IANA.

The newly created registry has details on how new extensions are to be defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

A new URN namespace for urn:ietf:params:mud has been requested with two initial resources of urn:ietf:params:mud:dns and urn:ietf:params:mud:ntp.

A new registry to hold MUD extensions has been requested.

Any expert reviews will require people with MUD expertise.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Various YANG validators (e.g., pyang, yanglint) have been run on the YANG models.  The models within this document validate properly.

Authors (Elliot) notes that this depends on draft-ietf-netmod-acl-model (and will likely need edits as this changes).

Putting in AD watching state while netmod-acl-model is worked on (MISREF didn't seem appropriate as this document may need to change, it isn't just a reference)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-opsawg-mud-13. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are ten actions which we must complete.

First, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG Modules are to be registered as follows:

Name: ietf-mud
File: [ TBD-at-registration ]
Namespace: urn:ietf:params:xml:ns:yang:ietf-mud
Prefix: ief-mud
Module:
Reference: [ RFC-to-be ]

Name: ietf-acldns
File: [ TBD-at-registration ]
Namespace: urn:ietf:params:xml:ns:yang:ietf-acldns
Prefix: ietf-acldns
Module:
Reference: [ RFC-to-be ]

IANA Question --> is the prefix supplied in section 16.1 of the current document ("ief-mud") possibly a typo for ietf-mud?

Second, in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

The existing temporary registration for tag 161 (OPTION_MUD_URL_V4) will be made permanent and its reference changed to [ RFC-to-be ].

Third, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

The existing temporary registration for value 112 (OPTION_MUD_URL_V6) will be made permanent and its reference changed to [ RFC-to-be ].

Fourth, in the SMI Security for PKIX Module Identifier registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

The existing temporary registration for Decimal 88 (id-mod-mudURLExtn2016) will be made permanent and its reference changed to [ RFC-to-be ].

Fifth, in the SMI Security for PKIX Certificate Extension registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page also located at:

https://www.iana.org/assignments/smi-numbers/

The existing temporary registration for Decimal 25 (id-pe-mud-url) will be made permanent and its reference changed to [ RFC-to-be ].

Sixth, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

The existing registration for URI Suffix "mud" will be changed to [ RFC-to-be ].

Seventh, in the application section of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

The existing temporary registration for Name: mud+json will be made permanent and its reference changed to [ RFC-to-be ].

Eighth, a new registry is to be created called the IANA Link Layer Discovery Protocol (LLDP) TLV subtype values registry.

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Expert Review.

IANA QUESTION -> Do the values in this new registry range from 0-255 or 1-256?

There is a single initial value in the new registry as follows:

LLDP subtype value: 1
Description: the Manufacturer Usage Description (MUD) Uniform Resource Locator (URL)
Reference: [ RFC-to-be ]

The remainder of the values in the new registry are to be marked "Unassigned."

Ninth, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

The existing temporary registration for Registered Parameter Identifier mud will be made permanent and its reference changed to [ RFC-to-be ].

IANA Question -> In section 16.7 the authors indicate that:

The following parameter registry is requested to be added in
accordance with [RFC3553]

Registry name: "urn:ietf:params:mud" is requested.
Specification: this document
Repository: this document
Index value: Encoded identically to a TCP/UDP port service
name, as specified in Section 5.1 of [RFC6335]

The following entries should be added to the "urn:ietf:params:mud"
name space:

"urn:ietf:params:mud:dns" refers to the service specified by
[RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified
by [RFC5905].

Where should this namespace be located?

Tenth, a new registry will be created called the MUD Extensions Registry. The registry is to be maintained via Standards Action.

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

Are there initial values for the new MUD Extensions Registry?

The IANA Services Operator understands that these ten actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-11-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-mud@ietf.org, jclarke@cisco.com, opsawg-chairs@ietf.org, Joe Clarke , opsawg@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Manufacturer Usage Description Specification) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Manufacturer
Usage Description Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-11-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo specifies a component-based architecture for manufacturer
  usage descriptions (MUD).  The goal of MUD is to provide a means for
  Things to signal to the network what sort of access and network
  functionality they require to properly function.  The initial focus
  is on access control.  Later work can delve into other aspects.

  This memo specifies 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2740/
  https://datatracker.ietf.org/ipr/2757/
  https://datatracker.ietf.org/ipr/2758/
  https://datatracker.ietf.org/ipr/2759/



The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-netmod-acl-model: Network Access Control List (ACL) YANG Data Model (None - IETF stream)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type required in Proposed Standard.  This is the right track as it requires coordination between vendors and consumers in order to achieve interoperability, and there will be continuing work as more implements are produced.

The type of RFC is called out in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This memo specifies a component-based architecture for manufacturer
  usage descriptions (MUD).  The goal of MUD is to provide a means for
  Things to signal to the network what sort of access and network
  functionality they require to properly function.  The initial focus
  is on access control.  Later work can delve into other aspects.

  This memo specifies 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.

Working Group Summary

  There was excellent discussion and comments throughout.  The authors were quick to respond, and incorporate feedback as well as push back on items thought to be out of scope.  The discussions led to talks of subsequent work for future drafts.

Document Quality

  There are implementations in the works.  Eliot Lear has stood up a tool at https://mudmaker.org/ that builds MUD files as a way to help vendors.  There were numerous expert reviews including multiple areas and YANG Doctors.  Those reviews led to some tighter security considerations, as well as more explicit mention that MUD files are to be taken under operational advisement as it is not wise to blindly apply others' configurations to your network.  The YANG Doctors review, in particular, led to a better structure to the MUD YANG module that will allow it to provide a data definition, as well as be implemented on controllers if need be.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Joe Clarke is the document shepherd.
 
  Warren Kumari is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd reviewed this draft multiple times across multiple revisions and provided feedback to the authors on the opsawg list each time.  All feedback was incorporated.  The Document Shepherd believes this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  Many reviews were performed both in opsawg, as well as in other areas.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was reviewed by the Security Directorate, IoT Directorate, YANG Doctors, and GEN ART.  Feedback was reported by all reviewers and the responses were incorporated into the text as needed.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.  All IPR has been reported.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, a disclosure has been made.  There was no discussion on the IPR only to say IPR exists and it was disclosed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Consensus was very solid with many expressing support for the work.  There were no dissenters, and there were a large number of reviews outside of the authors' organization that indicate broad support. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No NITS beyond some spacing weirdness caused by pyang's tree output.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed by YANG Doctors as described above.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The only non-ratified normative reference is to draft-ietf-netmod-acl-model.  This is a WG document proceeding towards standardization  I do not have a firm timeline on when that is expected.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations follow with the text of the document by requiring registration for the module namespaces, DHCP options to facilitate the transmission of MUD URLs, PKIX extensions for MUD, LLDP extensions for MUD advertisement, a MUD file media type, a URN for MUD resources, and a new registry for MUD extensions.

Each of these requirements are described within the text of the document to justify the ask of IANA.

The newly created registry has details on how new extensions are to be defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

A new URN namespace for urn:ietf:params:mud has been requested with two initial resources of urn:ietf:params:mud:dns and urn:ietf:params:mud:ntp.

A new registry to hold MUD extensions has been requested.

Any expert reviews will require people with MUD expertise.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Various YANG validators (e.g., pyang, yanglint) have been run on the YANG models.  The models within this document validate properly.

The authors are going to produce another draft based on LC comments.  Once that is done, consensus will be called and this will move to a shepherd state.