Subject: [OPSAWG] Review and comments: mud-05

From: Tim Polk <[email-masked]>
Date: Wed, 29 Mar 2017 22:09:45 +0000

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?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Mar 2017 17:12:34 -0500

Hi Tim,

Thanks very much for raising these questions.  Although they are not on
my slides for tomorrow (already submitted) I propose to address them
first in person then if you can make it, or otherwise on list.

Regards,

Eliot

On 3/29/17 5:09 PM, Tim Polk wrote:
> 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.
>
> (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.
>
> 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.
>
> 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:
>
> 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:
> 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.
>
> operator has decided to override certain settings, does this preclude
> use of future updates?
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg