Subject: [secdir] Secdir early review of draft-ietf-opsawg-mud-08

From: Adam Montville <[email-masked]>
Date: Sun, 27 Aug 2017 06:29:39 -0700

Reviewer: Adam Montville
Review result: Has Issues

Hi. I am the assigned SECDIR reviewer for this document's early review reuqest.
What follows is what I would write if this were a last call review, more or
less.

The summary of the review is ready with (potential) issues and nits.

The draft is interesting in that it seeks to define a mechanism for devices to
self-identify in a trusted manner, so that the infrastructure in which the
devices operate may appropriately manage security-related configurations
pertaining to those devices. The examples provided are exclusively network flow
realted, but extension points are provided for future capabilities.

The mechanism is defined as a Manufacturer Usage Description, as expressed in a
file containing a YANG-based JSON serialization. This file is obtained from a
device-provided URL, which is trusted to varying degrees and communitacted to
the infrastructure in one of several different ways (i.e. via DHCP, 802.1AR,
802.1AB). Thus, the device emits a URL via one of the identified methods, and
the URL is used to obtain the MUD, which can then be interpreted and
appropriate action taken.

The security consideraitons appear well-thought and is worth a read.

This seems like a solution intended to take time to reach full potential, given
that there are devices deployed in the real world that know nothing about this,
and that there are different trust mechanisms at play. The intent seems less
about perfection and more about moving the needle, which seems to be the right
approach.

Finally, I found myself wondering if this type of appraoch - communicating
intended use - could be extended to software installed on general purpose
devices. For example, it would be interesting to consider how a given installed
software package could communicate not only its intended use, but it's
preferred configuration.

Some questions to consider (these are potential issues):

At the top of page 9, the draft describes controller behavior for mobile
devices - configurations should be removed when the device is removed. Does
this apply also to intermittent devices? When would a device be considered
"removed" instead of simply powered down? Also, when reading that paragraph I
began wondering about the load on Web servers serving MUD files - not that this
draft should say anything about it, but that it's something manufacturers are
going to have to consider and account for.

Is a stronger statement needed on the first bullet of section 4? Should it
read: Anything not explicitly permitted MUST be denied? Similarly for other
requirements in MUD file processing. At about this point, I began wondering if
additional security considerations may be required for the controller.

Section 9.2 describes DHCP server behavior, and is written in a manner
presuming the DHCP server knows what's happening with these building blocks. I
am not a DHCP expert, so there may be something in DHCP instructing a server to
ignore everything it doesn't understand, but if that is not the case, then what
is expected to happen when DHCP is not expecting these options and is not going
to ignore them?

Nits follow:

First paragraph of section 1.5: s/another example might to follow/another
example might be to follow/

Recommend the following for definition of Thing: the device emitting a MUD URL.

Suggest striking last two sentences of Manufacturer definition, as irrelevant.

Is there a way to make the ASCII art in section 1.7 a little cleaner? One
possibility is to move the right side of the bounding box to the left by two or
three places. Also, the arrows to the line text isn't necessary (e.g.
"----->get URL->" is cleaner as "---get URL--->").

Second bullet on page 11: s/other otherwise/otherwise/

Should there be a newline after "<CODE BEGINS>" at the start of section 6?

On page 17: s/end(ed)/end(s\/ed)/  Basically, the sentence without "ended"
should read, "Information about when support ends, and when to refresh."

Vertial spacing could be improved for the first bit in section 9, so that the
look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6

Section 11, first sentence: s/link layer protocols/link layer protocol/

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Aug 2017 20:31:46 +0200

Hi Adam,

Thanks very much for your review.  I'm pleased you like the general
approach.  You hit the nail on the head: this is NOT intended to be a
panacea, but a means by which the device (and its manufacturer) can
enlist the network's protection. Indeed as I mentioned the first time I
presented to SAAG, I will say now again (with feeling):

NOTHING in that draft nor anywhere ELSE should excuse a
manufacturer/developer from best coding practices and updating
software.  The best form of protection will ALWAYS ALWAYS be a well
secured device to begin with.

MUD is simply there to add an additional layer for when the hacker gets
there first...

Please now see below.

> software package could communicate not only its intended use, but it's

I'd very much like to pursue this concept, but it seems to me it has to
be rooted in some sort of hardware trust.

> this apply also to intermittent devices? 
Well indeed so.  I think the discussion around mobility is confusing. 
I've cleaned that up.

> When would a device be considered
> "removed" instead of simply powered down?

I think the best way to look at this is to view the configuration
information as ephemeral, and since the device provides the information
on connect, or otherwise periodically (eg LLDP), you can regenerate the
state.

>  Also, when reading that paragraph I
Right.
> additional security considerations may be required for the controller.

One of the principles we try to observe is that the administrator owns
the network.  As such we should be somewhat cautious about how we phrase
such things.  From a MUD perspective, what you end up with is an
access-list that an administrator might choose to augment.  For
instance, if he or she is running a special load on a Thing using
802.1AR certificates, he might want to augment the access to accommodate
a new feature.

In fact, it may be possible that a manufacturer writes such a complex
MUD file that the network administrator desires an optimization.  We do
not yet have enough experience to know what sort of normative statement
would cover that ;-)

> is expected to happen when DHCP is not expecting these options and is not going

This is not a worry.  DHCP servers are very capable of ignoring unknown
options, and they have to be well bullet proofed today or we have FAR
FAR bigger fish to fry ;-)
> example might be to follow/
Right!
> Recommend the following for definition of Thing: the device emitting a MUD URL.

Ok.
> Suggest striking last two sentences of Manufacturer definition, as irrelevant.

Ahhh but this actually is a big deal to system integrators ;-)  They
want to know what their role in the ecosystem is.

> three places.

Sure.  Done.
> Also, the arrows to the line text isn't necessary (e.g.

Done.
> Second bullet on page 11: s/other otherwise/otherwise/

right.
> Should there be a newline after "<CODE BEGINS>" at the start of section 6?

I'm going to leave that one to the YANG doctors...
> should read, "Information about when support ends, and when to refresh."

This will change with the updating of the model, based on YANG doctor
feedback.  That very container is likely to be consolidated away.
> look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6

Ok.  I think I addressed what you're talking about.
> Section 11, first sentence: s/link layer protocols/link layer protocol/

Good catch.

Best regards and thanks again for your review.

Eliot

---

From: Adam Montville <[email-masked]>
Date: Tue, 29 Aug 2017 18:50:15 +0000

Hi Eliot,

You're welcome. Thanks for taking the time to consider, and even implement
some of, my feedback.

I agree on the hardware rooted trust for software intended use. Seems
plausible, given work coming out of TCG. I'm sure there are others who may
find this train of thought interesting.

Kind regards,

Adam