Skip to main content

Filter by topic and date

Filter by topic and date

Help managing the growing number of Things on our networks has arrived

13 Mar 2019

This week the IETF again turns its attention to Internet of Things (IoT) security with the release of RFC 8520 on Manufacturer Usage Descriptions (MUD).


Things are generally lightweight single-purpose network devices. There are a great many number of Things connected to enterprise, consumer, and industrial networks. Many can be found on the Internet through search engines such as Already, deployment of connected things such as printers, thermostats, heaters, dryers, coffee makers, toasters, light bulbs, curtains, door bells, and sprinkler systems are outpacing deployment of laptops and cell phones on our networks. And there are a lot of types of Things, so many that we do not even know how to properly count them, or even how to group them into common categories. Put in other terms, we probably already do not have enough network administrators on the planet to understand what these Things are doing on our networks. In enterprise terms, that means that these devices are likely either not receiving the access they need, or they have too much access. The problem is made even worse by The Department Gap, where the IT department isn't even told what Things are being connected to the network by other teams in order to meet a critical business need.

Manufacturer Usage Descriptions

MUD attempts to address this problem by capitalizing on the assumptions that, unlike the general-purpose computers we use to surf the Web, IoT devices have a single or small number of uses, and that these uses may be tied to a predictable set of communications patterns. For example, it is unlikely that your Internet-enabled toothbrush–a real world device that uses a built-in camera to capture and report on dental hygiene–is going to need access to Netflix. If that toothbrush attempts to access Netflix, something fishy is happening. Since manufacturers are the ones that designed these Things, they are in a very good position to document what sort of access they need.

Put in terms that network administrators might find useful, device manufacturers are in a very good position to provide us most of what we need in IP-based access lists for their devices. MUD provides the basic framework to enable manufacturers to provide policy that can be used to generate IP-based access lists. The astute will notice that manufacturers cannot know what IP addresses should be listed in an access list. To address that issue, MUD establishes some abstractions, such as “my-controller”, “controller {URI}”, “same-manufacturer”, “manufacturer”, and the use of domain names, with the idea being that each will map to one or more devices that the device should be allowed to access, or not. These abstractions build upon and augment the IETF’s brand new access control list (ACL) model (RFC 8519). A simple example of how to construct a “MUD file” can be found at MUD File Maker.

The MUD file itself is served up via HTTPS, just like any other file. It thus has a URL associated with it. What is left is for devices to output that URL such that deployments can retrieve it. This can be done in any number of ways, including via DHCP (RFC 2131 and RFC 8415), Link Layer Discovery Protocol (LLDP), or, my favorite, via a device certificate in an EAP-TLS or Tunnel Extensible Authentication Protocol (TEAP) transaction (RFC 7170) .

So what’s the result of all of this? At the very least, it’s knowledge the network administrator can use to establish security policies that are appropriate for each device. And that means a smaller threat surface. Even better, that process can be automated for the administrator. A number of implementations have taken that step:

  • offers an open source version of the MUD manager that can be used in consumer deployments.
  • Google has developed a device automated qualification framework (DAQ) that makes use of MUD to establish profiles for corporate building infrastructure (among other things).
  • The Canadian Internet Registration Authority (CIRA) has also developed a consumer-oriented MUD manager.
  • Cisco released support for manual configuration of devices with MUD support in their Identity Services Engine product, and has developed a proof of concept implementation that can be used to test manufacturer intent.
  • Yikes!, provides automated device classification and network security for small business and consumer networks, incorporated a MUD manager into their product. 
  • A number of lighting and building companies will be delivering MUD-enabled products over the next few months.

A key point to observe is that each of these MUD managers consumes a MUD file and then produces policy in a slightly different way. One has the MUD manager reside directly on the consumer router, one is more service provide focused and delivers policy down to the consumer router, and one makes use of a FreeRadius infrastructure to deliver updated per-session ACLs. There will be other approaches over time as the technology continues to mature.

Next steps

First, check out RFC 8520. It’s a page turner.

For manufacturers

Produce a MUD file for your device and maybe even test it against an implementation or two. To create a MUD file, go to MUD File Maker. If nothing else you will have documented what access your devices need. That’s a huge win, even for deployments that don’t automate access: at least you can point administrators to what access your devices need. And then have your device output a MUD URL. Guidance for this can be found at the Cisco DevNet site.

For enterprises and consumers

Ask for products that implement MUD. Ask manufacturers for their MUD files, so that you know what sort of access devices need. Consider implementing one of the MUD manager implementations mentioned above.

A final word of caution

We think MUD is pretty cool stuff, but it’s not a panacea. It’s part of a healthy breakfast, not the whole breakfast. For that, manufacturers need to do what they can to keep their devices secure, including providing security updates to customers, as well as using secure coding practices and taking advantage of hardware trust anchors available in some of the newest IoT platforms.


  • [1]RFC 8519

    YANG Data Model for Network Access Control Lists (ACLs)

    This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.

  • [2]RFC 2131

    Dynamic Host Configuration Protocol

    The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. …

  • [3]RFC 8415

    Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

    This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 …

  • [4]RFC 7170

    Tunnel Extensible Authentication Protocol (TEAP) Version 1

    This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunne…

  • [5]RFC 8520

    Manufacturer Usage Description Specification

    This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Late…

Share this page