[T2TRG] Fwd: [OPSAWG] Here's MUD in your eye!

[Carsten Bormann <[e-mail]>]

Interesting use case for a "thing description".

Grüße, Carsten


-------- Original Message --------
Subject: 	[OPSAWG] Here's MUD in your eye!
Date: 	Fri, 5 Feb 2016 08:24:42 +0100
From: 	Eliot Lear <[e-mail]>
To: 	[e-mail]



Hi everyone,

For the last few months I've been working on a little effort which I
call MUD.  It stands for Manufacturer Usage Descriptions, and it focuses
on the security of Things.  There are already quite a lot things and
more on the way (Cisco estimates 50 billion by 2020, and others say
more).  And there will be many developers/manufacturers of these
things.  It will be impossible for anyone to really keep track of all of
these Things on their own.  Developers/manufacturers will be in a good
position to tell network administrators what sort of network access
these Things require, and as importantly, what sort of network access
these things are not intended to have.  Consider this simple example : a
networked rheostat is unlikely to want to browse CNN.  That same
rheostat may have a bug.  It's also possible for the network to limit
who can attack it, so long as the rheostat manufacturer has a means to
tell the network what access is needed and what is not.

So... what's necessary for all of this to work?

 1. A standard way to indicate where a description is stored;
 2. A way for the thing to tell the network what it is in such a way
    that the network can retrieve a description;
 3. A schema for the description itself; and optionally
 4. Some abstractions that can permit/deny access to certain classes of
    devices.

As an entrée, I've specified a URI as a means to indicate where the
desription is (1),  IEEE 802.1AR certificates with 802.1X as well as
DHCP for getting it from the device (2), and YANG-based XML for (3) and
(4).  In IETFeze that translates to the following drafts:

  * draft-lear-mud-framework (a few more lines of text describing the above)
  * draft-lear-ietf-netmod-mud (the YANG model and the URI specification)
  * draft-lear-ietf-pkix-mud-extension (a non-critical constraint for
    the MUD URI); and
  * draft-lear-ietf-dhc-mud-option (a way to communicate the URI via DHCP)

I think you'll find one or two open issues with these drafts (to say the
very least), but hopefully you might like the concept. I'm seeking
feedback, discussion, collaborators, and perhaps some co-authors on this
work.  At the very least, I'm sure some people can contribute a humorous
pun or two.

And please!  No mud slinging!

;-)

Eliot