After a hallway conversation with one of the authors, I have reviewed
mud-05 in some depth and skimmed mud-net-lifecycle-00 and
mud-manu-lifecycle-01 for context.
I think that the MUD protocol fills a very important gap in the supply
chain, in a reasonably elegant manner. Emitting a stable URI for the MUD
file provides a very low overhead mechanism to integrate a new component
into your network along with appropriate access controls. The goals laid
out in the introduction are largely satisfied, and security controls seem
appropriate. I am especially excited about the application to IoT devices
for the home consumer, but believe this has distinct advantages for the
enterprise as well.
In short, I support advancing the document.
That said, I have some issues with the draft I would like to raise.
(1) Why are we excluding legacy devices from the benefits of MUD? If the
device does not emit the MUD URI, which is every legacy device, then it is
excluded from the system. If I obtain a MUD controller, I would definitely
want to apply this functionality to my previously purchased legacy
devices. Yes there are risks in obtaining this information out-of-band,
and the management overhead is much lower if my devices convey the URI, but
once I provision the controller with a URI and identify the devices I will
obtain many of the same benefits to security.
Supporting MUD files for legacy devices also allows me to maximize my
near-term ROI, which promote adoption...
I would suggest adding a brief section 1.7 on legacy devices, simply
stating that manufacturers MAY make MUD files available for legacy devices
to support appropriate network configuration, and MUD controllers MAY
accept URIs for devices through out-of-band means.
(2a) [Section 3.3] This draft uses a cache-validity period rather than a
next-update time to indicate when to check back. Given that cache-validity
prohibits checking back during the specified period, are we comfortable
with a recommended maximum value of 1440 hours (60 days!)?
Okay, that was a rhetorical question - I'm not comfortable with that at
all. Assume a revised MUD file is posted to address a new vulnerability,
and the controller always retrieves a fresh copy at the first permissible
moment, the average network supporting the corresponding device will
experience a post-discovery window of vulnerability of 30 days on average.
Given the expected size of the file, why prohibit checking for so long? I
understand that there are concerns about MUD controllers hammering servers
at high frequency, but 7 days (168 hours) seems like a reasonable maximum
to me.
In more brevity, I suggest:
OLD
It is RECOMMENDED that this value be no less than 24 and no
more than 1440 for any device that is supported.
NEW
It is RECOMMENDED that this value be no less than 24 and no
more than 168 for any device that is supported.
(2b) Better yet, should there be a MAXIMUM amount of time before the
checking for a new MUD file? As written, the MUD controller could choose
to never look for updates and be "conformant". We could add a field to MUD
file specifying the MAXIMUM amount of time, but a lighter weight solution
might be a recommendation that the MUD controller refresh all MUD files
whose cache-validity period has been exhausted:
Append to the end of Section 3.3:
The MUD controller SHOULD refresh any MUD file whose cache-validity period
has been exhausted.
(3) The introduction (section 1, top of pg 4, bullet 3) states that MUD is
intended to:
o Provide a means to address at least some vulnerabilities in away
that is faster than it might take to update systems. This will be
particularly true for systems that are no longer supported by
their manufacturer.
In practice, this is probably true since so many devices are never updated
or are used beyond the supported lifetime. For this statement to be more
broadly correct, we would need a way to push a new MUD file since
cache-validity prohibits early checking. That is, once the vulnerability
is known and we post the new MUD file, the average time to download and
implementation of access rules is 50% of the cache-validity period.
Is this a reason to support subscription of a MUD-controller to a MUD file
distributor for emergency changes? I do not advocate changing the MUD
draft to incorporate this level of complexity, but if this is our goals
perhaps this should be addressed in a future draft...
(4) I request a bit of indulgence here; I admit that this one is a bit of a
rant.
The MUD protocol may have the unexpected consequence of perpetuating bad
developer behavior. There is no reason a baby monitor should include a web
browser, but the lazy developer just leaves the code in their
distribution. Removing the unnecessary code (so messages sent to the
offending port would be rejected) should provide stronger security than
constraints implicitly specified in the MUD file, and both in concert would
be ideal.
Does this incentivize developers to make weak security choices and "fix"
them in the MUD file? I think that some text in the security
considerations stating that MUD is intended to complement and strengthen
well designed systems and does not relieve vendors of the obligation to
produce decent code is in order.
(5) This may be a bridge too far for initial deployment, but (based on my
limited understanding of YANG) the architecture assumes that the access
controls are independent of device configuration. (That is, I don't see
any conditionals.) Is that really the case? For example, if the devices
still use the default administrator password I might want to be more
restrictive than after the passwords have been updated. If I am a large
enterprise, I might also want to substitute infrastructure I own for the
vendor supplied cloud that supports operations.
How do people envision dealing with this situation? If the network
operator has decided to override certain settings, does this preclude use
of future updates?
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
