MUD
Manufacturer Usage Description (MUD) IETF Specification (MUDS) is a framework under RFC development that aims to automate Internet access control rules for IoT devices . The intention is to specify normal and abnormal usage of a device outside the device and allow an installation to derive security controls (Access list ) and apply it. For example the posrts and servers which should be allowed to do remote service or change configuration or initiate firmware update of the device
Contents
IETF Abstract
A key presumption of the Internet architecture has been that devices are general purpose computers. By constraining the set of devices that connect to the Internet to non-general purpose devices, we can introduce a set of network capabilities that provides an additional layer of protection to those devices. One such capability is the Manufacturer Usage Description (MUD). This work builds on many existing network capabilities so as to be easily deployable by all involved. The focus of this work is primarily, but not exclusively, in the realm of security; and again primarily, but not exclusively, relating to smart objects.
IEEE
Through the simplifying assumption that a Thing has a single use or a small number of intended uses, it is possible to reduce the threat surface of the device by constraining the communication paths needed for those uses. This is accomplished using a small number of extensions to IEEE 802.1AR, a YANG model, DHCP, and IEEE 802.1AB, where a manufacturer maintains an online presence that is used inter alia to retrieve recommended configuration for a given device. This recommended configuration is used to create an access control list on a network device
CISCO Proposal
MUD allows a Universal Resource Identifier (URI) for getting ad device configuration. That URI points to a web site, either the manufacturer or the system integrator deploying devices from which the network security controller pulls the XML file<ref>YANG models [RFC6020] </ref> or JSON declaring the device’s appropriate usage. That usage file can then be merged with the existing network security policy and enforced.
MUD overview
A schematic form an implementation at Indiana University illustrates.
ASCII art from IETF
......................................... . ____________ . __________ . | Network | . | | . | Management |----->get URI->| MFG | . | System | . | Web Site | . End system network |____________|<--MUD file<--<|__________| . . . . . . . _______ _________ . .| | | router | . .| Thing |---->MUD URI-->| or | . .|_______| | switch | . . |_________| . .........................................
Figure 1: MUD Architecture
Use cases from Standard proposals
Light Bulb
A light bulb is intended to light a room. It may be remotely controlled through the network; and it may make use of a rendezvous service of some form that an app on smart phone accesses. What we can say about that light bulb, then, is that all other network access is unwanted. It will not contact a news service, nor speak to the refrigerator, and it has no need of a printer or other devices. It has no Facebook friends. Therefore, an access list applied to it that states that it will only connect to the single rendezvous service will not impede the light bulb in performing its function, while at the same time allowing the network to provide both it and other devices an additional layer of protection.
Advanced Policies
The manufacturer may specify either specific hosts or certain classes. An example of a class might be
"devices of a specified manufacturer type", where the manufacturer type itself is indicated simply by the authority of the MUD-URI. Another example might to allow or disallow local access. Just like other policies, these may be combined. For example:
Allow access to host controller.example.com with QoS AF11
Allow access to devices of the same manufacturer
Allow access to and from controllers who need to speak COAP
Allow access to local DNS/DHCP
Deny all other access
