On 17.04.18 14:44, Spencer Dawkins at IETF wrote: > Hi, Eliot, > > On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear <l...@cisco.com > <mailto:l...@cisco.com>> 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 <l...@cisco.com> <mailto:l...@cisco.com>, Ralph Droms >> <rdr...@cisco.com> <mailto:rdr...@cisco.com> >> >> I think Ralph's address is wrong in 2 places. > > Corrected. >> o Intended usage: COMMON >> o Restrictions on usage: none >> o Author: >> Eliot Lear <l...@cisco.com> <mailto:l...@cisco.com> >> Ralph Droms <rdr...@cisco.com> <mailto:rdr...@cisco.com> >> 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
