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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
