Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear <[e-mail]>]

On 17.04.18 14:44, Spencer Dawkins at IETF wrote:
> Hi, Eliot,
>
> On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Responding to Spencer, Ben, and Alexy (in order).
>
>
>     On 16.04.18 21:09, Spencer Dawkins wrote:
>>     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
>>     <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/
>>     <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.
>
>     I proposed a clarification: direction initiated is a TCP element.
>
>
> 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.

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.



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

> I'm still connecting dots.
>
>>     "Supported" covers a lot of ground …
>>
>>     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
>>     plan for what comes next? I'm not sure what happens to is-supported, for
>>     instance.
>
>     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.
>
>
> Yeah, and I didn't mean to slow MUD down waiting for that work. Just
> to be clear (hence, Yes).
>  
>
>
>>     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.
>>
>
>     Thanks, Spencer.  We're just getting going.
>
>
> And I'm darned glad to see that happening.
>
> Thanks for the quick responses.
>
> Spencer
>  
>
>     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 <[e-mail]> <mailto:[e-mail]>, Ralph Droms <[e-mail]> <mailto:[e-mail]>
>>
>>     I think Ralph's address is wrong in 2 places.
>
>     Corrected.
>>         o Intended usage: COMMON
>>         o Restrictions on usage: none
>>         o Author:
>>              Eliot Lear <[e-mail]> <mailto:[e-mail]>
>>              Ralph Droms <[e-mail]> <mailto:[e-mail]>
>>         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
>
>