Hi,
On 9/26/17 8:54 PM, Kent Watsen wrote:
> 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.
Perhaps I've misunderstood your initial question, so let me try again.
While not specifically discussed, it is possible for a device to request
a change of state if it starts to emit a different MUD-URL. This is
possible for DHCP and LLDP but may be problematic for 802.1AR
certificates. I do think there are some security considerations when
devices change state like this, and those are discussed in Security
Considerations. I'm NOT recommending that devices do this.
> 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"...
See above. I would worry about the complexity of the solution, which is
one of the reasons why I'm tending to agree with you to remove the
masa-server entry, but I'm still thinking about that one. Also, keep
this in mind: my absolute preference is that this be done with 802.1AR
certificates so that the device itself doesn't really assert ANYTHING.
Rather the manufacturer should do the asserting.
>
>
>>> 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,
There is no conformance claim here at all. These are called
"descriptions" not "directives". Deployments can do what with this
information they will. That is stated several times in the draft.
> 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.
It is intentionally unclear on that. See below.
>
>
>>> 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?
How a pizza parlor deals with is will likely differ from a bank. And a
bank will likely differ from how Juniper deals with it, which will
likely differ from how a healthcare provider deals with it. I'm happy,
if you like to insert the following into Section 1.7 to make this
abundantly clear:
Network administrators have the ultimate say over how their networks
are configured. MUD files are recommendations. The access to
network services assigned to a particular device either before a MUD
file is read or after will depend on the deployment. In some cases,
deployments may allow open access or limit access prior to receiving
a MUD-URL. In some cases, deployments may completely ignore MUD
URLs, or substitute some other behavior.
>
>
>
>
>
>>> 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.
Emm... it is clearly (I hope, again based on reviewer comments) defined
in the definitions section (there is a single forward reference).
From your other message:
> Separately, who generates the MUD files? Is it the Manufacturer or someone
> else? Section 12.1 doesn't say.
But Section 1 does ;-) See bottom of page 3 top of page 4.
Finally,
> As an aside, why are these fields called "[my-]controller"?
Because controllers are a pretty well understood IoT concept. To answer
the other question, I think it might help to state clearly that all the
abstractions are translated into appropriate IP addresses that would be
suitable for use in the ACL model.
I'll comment on BRSKI in a separate post, probably tomorrow.
Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
