Hiya again, >> In my previous review, I had asked about how MUD intersects with my >> zerotouch draft, which has the device reaching out to either a well-known >> Internet-based or deployment-specific HTTPS resource. But the need to reach >> out to these HTTPS resources should only be during the device's initial >> bootstrap process. You said before something about an initial policy >> followed by an on-going policy, but I don't see that here. Did I miss it?
> I think so. There is the notion of “cache-validity” with the idea being > that one can change the policy from time to time. The policy does not itself > expire, but the idea with “cache-validity” is that mud controllers shouldn't > pester the mud file server any sooner than that period. IIUYC, you're thinking that the switch would receive updated configuration over time; an initial configuration would allow the Thing (to use the word in the draft, not my preference) to allow the bootstrapping flows and, then later, a second configuration that would reflect normal operation. This is not (IMO) a MUD-file thing, so much as a controller-thing, as the Manufacturer would have no awareness of the operational state of the devices or be able to sequence the release of MUD files accordingly. For this to work, I think the MUD file would need to have both states built into it, so then the controller can initially select the first state and then later, perhaps based on criteria other than a timeout, selects the second state. Note, by "select" I mean "select and push updated config to switch based on"... >> What is the default behavior of the switch, when no MUD file is available. >> Section 4 says "Anything not explicitly permitted is denied", but that >> section discusses the processing of a MUD file, not when there is no MUD >> file. I'm assuming the goal is for the switch to deny traffic (fail close) >> when no MUD file can be found, but I worry that this may lead to unhappy >> operators as new product deployments (not having MUD support) are constantly >> blocked by the switches... > Fair question. If no MUD file is available, it's a deployment decision as to > how to proceed (much as it is today). The intent of Section 4 is that one > should assume that the end of an ACL is the JSON equivalent of "deny any". > Should I clarify this? Right, the ACL is default deny all, but that is the ACL within the MUD file that the controller (not the switch) processes. Looking to section 1.8, it starts off with "Thing emits URL". In this case, it doesn't happen, the Thing doesn't implement the RFC. In order for solutions to claim conformance, I think the switch would have to have a "mud-mode" whereby it refused pass traffic on a port unless a mud-controller gave it the config to do so. If this is indeed the intent, I think the draft should be clear about it. >> Building upon the above two comments, I'm assuming that the switch could be >> configured to *always* allow access to some resources, even when no MUD file >> is found. Is this what you had in mind? > Yes. I can clarify this as well. Okay, but then this seems to be at odds with the previous conclusion, which I may have gotten wrong. To me, it seems that either the switch fails-closed (mud mode) or not (normal mode), is there room for anything else? >> Nits: >I'll check each of these, but the term "Thing" is intended to be used consistently, and changes made were in response to Robert Sparks' review. I'll make sure that each is as intended. Okay, but I think it puts off the wrong signals and marginalizes the solution as a whole. But, if you insist, at least be sure to define "Thing" before first use in the document (this is not the case currently) and give it a definition that clearly indicates that it applies to all network elements, not just lightbulbs, etc. >> s1.3: "Thing" here is distracting. Can you change to "device"? >> s1.4: replace "Our work" with something like "The solution"? >> s1.5: inconsistent capitalization in manufacturer class names >> s1.6: I see Thing here too. Is this necessary? Isn't the solution for >> non-IoT devices too? >> s1.6: you might want to include a ref to RFC 8174, per RFC 8174. >> s1.7: the text talks about NMSs and websites, but I think you mean >> controller and mud server, right? >> s1.8: #7, how is "disconnect" defined? >> >> <skimmed a bunch here> >> >> regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an >> extension? Also, note that the brski-07 draft says nothing about this >> draft, so the relationship between the two is unclear. I'd like to see >> references to brski removed from this draft if possible, with a preference >> for the brski draft to define its own "extension" if desired. > I am tempted to agree. This is the one that may need just a day or two to > consider, perhaps with a conversation with Max and the ANIMA folk. Ack. >> <skimmed a bunch more here> >> >> s17: s/Watson/Watsen/ - an all too common typo in my life! ;) >> > Deepest apologies. I know how you feel. > > Eliot Thanks, Kent _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
