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

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