Subject: [OPSAWG] Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 16 Apr 2018 12:09:15 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2018 08:43:36 +0200

Responding to Spencer, Ben, and Alexy (in order).

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

I proposed a clarification: direction initiated is a TCP element.
> ever mean anything except "is-updated"? 

Mostly that what it means, but the implication is that there's no
support, and enterprise administrators in particular might want to know
that (usually they do- because those devices represent a particular risk).

> "Supported" covers a lot of ground …
>

The intent is that the entity providing the MUD file (probably the
manufacturer) will not be issuing software/firmware updates or MUD file
updates.  But your point is more about device lifecycle, and that's a
more interesting question than just "is-supported".  Steve Rich and
Thorsten Dahm have begun to delve in that direction.  There are at least
a few possibilities, such as the use of redirects, or even domain names
that are used for particular classes of devices, or even common repos. 
More work needed.

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

Thanks, Spencer.  We're just getting going.

Now to Ben:

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

Because at this stage there is only one encoding and no source of
confusion as to what is returned, and the people implementing this stuff
are getting their feet wet.  If they're using a service that simply
doesn't include the right Accept: header, and the right thing can still
happen, let's let that happen.

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

Indeed.  It's captured in Security Considerations, but we can place a
forward pointer there.

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

EKR beat you to it.  Change proposed.
>
> §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.

I think EKR beat you to this one as well ;-).  Change proposed.

> §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")

This one's harder to change, and authority has its own ambiguities.

>
> §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"?

How about:
> In seeking a general
> solution, however, we assume that a device will    implement
> functionality necessary to fulfill its limited purpose.

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

That is a mouthful.  Propose:
>    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.  For
>    legacy cases where Things cannot emit a URL, if the switch is able to
>    determine the appropriate URL, it may proxy it.  In the trivial case
>    it may hardcode MUD-URL on a switch port or a map from some
>    available identifier such as an L2 address or certificate hash to a
>    MUD-URL.

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

Could be either.  The only difference between the two is that at some
point someone has to CRUD the thing out of a database somewhere.
>
> §2: "A MUD file consists of a YANG model ..."
> A model instance, right? That is, not the model itself?

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

I think that's fair, and propose to change it to the following:

> Note that MUD extensions MUST NOT be used in a MUD file without
> the extensions being declared.  Implementations MUST ignore any node
> in this file that they do not understand.

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

Maybe so, but the intent here is that a great many devices are going to
be making use of DNS and NTP, and that not listing them in a MUD file is
more likely to lead to mistakes, rather than accidentally listing them.

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

Propose "lateral infection" with a parenthetical definition.

On to Alexey:
> 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".

In this day and age I think that sounds correct.  I personally have no
objections.

>
>     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.
Ok
>
>     o Applications that use this media type: MUD controllers as
>       specified by this document.
>
> As above.
Ok
>
>     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 <[email-masked]>, Ralph Droms <[email-masked]>
>
> I think Ralph's address is wrong in 2 places.

Corrected.
>
>     o Intended usage: COMMON
>     o Restrictions on usage: none
>     o Author:
>          Eliot Lear <[email-masked]>
>          Ralph Droms <[email-masked]>
>     o Change controller: IESG
>     o Provisional registration? (standards tree only): No.
>
> UTF-8 needs to be a Normative reference (RFC 3629).
>
Ok.

Thanks, all.

Eliot

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 17 Apr 2018 07:44:55 -0500

Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear <[email-masked]> wrote:

> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>

That is a clarification.

I guess what I'm thinking, on reflection, is that direction is likely to be
helpful for TCP-based communication, is not likely to be helpful for
UDP-based communication without stateful inspection (so, my camera probably
does need to act as a DNS client, but probably doesn't need to act as a DNS
server), and is likely to be increasingly unhelpful if we really do see
things using encrypted, UDP-based transports like QUIC.

This does poke the "how are network managers going to manage networks
running encrypted, UDP-based transport" bear, but that's way bigger than
this document. Say as much as you think is helpful, and then move on, I
think.

> Mostly that what it means, but the implication is that there's no support,
> and enterprise administrators in particular might want to know that
> (usually they do- because those devices represent a particular risk).
>

 Here, I must apologize, because I've been thinking of MUD as the other
side of a coin that also has SUIT, TEEP, and similar tools - If your Thing
is just being installed and forgotten until it's an attack platform, you
need MUD descriptions, but if your Thing is going to be updated, you should
be looking at SUIT, TEEP, and whatever else seems helpful.

I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
that's a lack of imagination on my part, but the most relevant side effect
of that, is that if you know what your printer needs to do, to be a network
printer, and you get a MUD description for it, and the printer isn't going
to be updated, that MUD description should be fine, forever.

I'm still connecting dots.

> updates.  But your point is more about device lifecycle, and that's a more
> interesting question than just "is-supported".  Steve Rich and Thorsten
> Dahm have begun to delve in that direction.  There are at least a few
> possibilities, such as the use of redirects, or even domain names that are
> used for particular classes of devices, or even common repos.  More work
> needed.
>

Yeah, and I didn't mean to slow MUD down waiting for that work. Just to be
clear (hence, Yes).

> Thanks, Spencer.  We're just getting going.

And I'm darned glad to see that happening.

Thanks for the quick responses.

Spencer

> are getting their feet wet.  If they're using a service that simply doesn't
> include the right Accept: header, and the right thing can still happen,
> let's let that happen.
>
> Maybe so, but the intent here is that a great many devices are going to be
> making use of DNS and NTP, and that not listing them in a MUD file is more
> likely to lead to mistakes, rather than accidentally listing them.
>
>       Eliot Lear <[email-masked]> <[email-masked]>, Ralph Droms <[email-masked]> <[email-masked]>
>
>          Eliot Lear <[email-masked]> <[email-masked]>
>          Ralph Droms <[email-masked]> <[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2018 14:56:47 +0200

On 17.04.18 14:44, Spencer Dawkins at IETF wrote:
> Hi, Eliot,
>
> On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>>     <https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/>
>>
>>
>>
> I guess what I'm thinking, on reflection, is that direction is likely
> to be helpful for TCP-based communication, is not likely to be helpful
> for UDP-based communication without stateful inspection (so, my camera
> probably does need to act as a DNS client, but probably doesn't need
> to act as a DNS server), and is likely to be increasingly unhelpful if
> we really do see things using encrypted, UDP-based transports like QUIC. 
>
> running encrypted, UDP-based transport" bear, but that's way bigger
> than this document. Say as much as you think is helpful, and then move
> on, I think.

Well indeed.  I think the key here is to recognize that all MUD can do
is invoke network management capabilities already present in the
infrastructure.  "Picture if you will", however, a MUD extension that
modifies the meaning of "direction-initiated" to say, please do stateful
to allow stuff outbound, and re-adds the element in the UDP context. 
Absolutely possible.  I think it's a matter of whether the underlying
infrastructure broadly supports such a capability.

>     support, and enterprise administrators in particular might want to
>     know that (usually they do- because those devices represent a
>     particular risk).
>
>
>  Here, I must apologize, because I've been thinking of MUD as the
> other side of a coin that also has SUIT, TEEP, and similar tools - If
> your Thing is just being installed and forgotten until it's an attack
> platform, you need MUD descriptions, but if your Thing is going to be
> updated, you should be looking at SUIT, TEEP, and whatever else seems
> helpful. 
>
> that's a lack of imagination on my part, but the most relevant side
> effect of that, is that if you know what your printer needs to do, to
> be a network printer, and you get a MUD description for it, and the
> printer isn't going to be updated, that MUD description should be
> fine, forever.
>

I've been thinking about this as well.  Had MUD been completed later, I
would have wanted to leave a reference to the work, along the lines of
"MUD is part of a nutritious breakfast, along with SUIT, TEEP, etc".  By
the time we do v2, I expect us to do just that.

Regards,

Eliot

>>     If a manufacturer sells off one product line (so, flobbidy.example.com <http://flobbidy.example.com> covered
>>     multiple product lines, but now flobbidy.example.com/mark1/lightbulb
>>     <http://flobbidy.example.com/mark1/lightbulb> will be
>>     maintained by a manufacturer that isn't flobbidy.example.com <http://flobbidy.example.com>), is there a good
>     manufacturer) will not be issuing software/firmware updates or MUD
>     file updates.  But your point is more about device lifecycle, and
>     that's a more interesting question than just "is-supported". 
>     Steve Rich and Thorsten Dahm have begun to delve in that
>     direction.  There are at least a few possibilities, such as the
>     use of redirects, or even domain names that are used for
>     particular classes of devices, or even common repos.  More work
>     needed.
>
>
> Yeah, and I didn't mean to slow MUD down waiting for that work. Just
> to be clear (hence, Yes).
>  
>
>
>     confusion as to what is returned, and the people implementing this
>     stuff are getting their feet wet.  If they're using a service that
>     simply doesn't include the right Accept: header, and the right
>     thing can still happen, let's let that happen.
>
>     Indeed.  It's captured in Security Considerations, but we can
>     place a forward pointer there.
>
>>     Editorial/Nits:
>>
>     Could be either.  The only difference between the two is that at
>     some point someone has to CRUD the thing out of a database somewhere.
>     Maybe so, but the intent here is that a great many devices are
>     going to be making use of DNS and NTP, and that not listing them
>     in a MUD file is more likely to lead to mistakes, rather than
>     accidentally listing them.
>
>     In this day and age I think that sounds correct.  I personally
>     have no objections.
>
>>           Eliot Lear <[email-masked]> <mailto:[email-masked]>, Ralph Droms <[email-masked]> <mailto:[email-masked]>
>>
>>              Eliot Lear <[email-masked]> <mailto:[email-masked]>
>>              Ralph Droms <[email-masked]> <mailto:[email-masked]>