What is MUD?

Manufacturer Usage Description (MUD) is an embedded software standard defined by the IETF that allows IoT Device makers to advertise device specifications, including the intended communication patterns for their device when it connects to the network. The network can then use this intent to author a context-specific access policy, so the device functions only within those parameters. In this manner, MUD becomes the authoritative identifier and enforcer of policy for devices on the network.

The following diagram shows the basic architecture of MUD:

MUD network

As can be seen from above, the MUD solution consists of three components at its very core:

  • A URL that an IoT Device emits when it connects to the network.
  • An Internet hosted file that this URL points to. This file contains an abstracted policy that describes the level of communication access which the IoT Device needs to perform its normal function.
  • A core process that receives the URL from the IoT Device, retrieves the file from the MUD File Server, and establishes appropriate access controls in the network for that IoT Device.

The blocks in the above diagram represent the broad components for MUD to function. Cisco has put together the following architecture to support this capability:

MUD architecture

The process depicted above consists of the following chronological steps:

  1. When an IoT Device first connects to a Network Access Point, it sends a MUD URL embedded in either the LLDP, DHCP, or 802.1X request.
  2. The Network Access Device, which for Cisco deployments is restricted to Catalyst switches for now, extracts the URL, encapsulates it in a Radius packet, and sends it to the AAA Server. (When the MUD URL is embedded in a DHCP packet, some networks may instead forward the entire DHCP packet to the AAA Server.)
  3. The AAA Server, which is the Identity Services Engine (ISE) for Cisco deployments, then passes this URL onto the MUD Controller, which is also hosted on the ISE for now.
  4. The MUD Controller then contacts the internet hosted MUD File Server of the manufacturer that this URL points to over HTTPS.
  5. After verifying that the MUD file was produced by the device manufacturer, the MUD file corresponding to that device is sent to the MUD Controller. This file, which is a YANG Data Model represented as a JSON object, contains abstracted communication intent for the IoT Device in question.
  6. The MUD Controller translates this abstract intent to a context-specific policy, which is passed onto the AAA Server/ISE.
  7. The ISE then enforces the policy onto the network in the form of port-based Access Control Lists (ACLs) for the point of that IoT Device's connection.
  8. Based on the manufacturer stated intent, access to the device is then provided.