By: Eliot Lear
Date: June 26, 2018
In the early days of the Internet its primary responsibility was connecting general purpose computers to one another. These computers ranged in form from mainframes with serially attached terminals to workstations to PCs and laptops to phones and tablets. But even in those early days, a few “things” found their way onto the network. A few people can remember using the finger protocol to query the host “CMU-CS-A” for coke, to learn the status of the vending machine. Others may recall the first connected toaster for which John Romkey built an IP stack.[i] From recognition of the possibility to its realization: thanks to the marvels of Moore’s Law and many other technical innovations, nearly every type of Thing can now be connected to the Internet.
All of these devices represent numerous challenges to network administrators. Through all of our innovations we have not been able to perfect the human being. Our flaws are reflected in the vulnerabilities that these devices have. Meanwhile our competence securing computers has been bound by the way that we have used them and enhanced through the painful impact of numerous mistakes. We learn through practical experience.
Now, however, the learning curve of security is running up against the practical needs of those who these Things are supposed to help, and a scaling problem like no other. While estimates of the number of connected things range from 25 billion today to as much as 100 billion by 2025, we do not even have a methodology to count the number of types of things. For instance, is version 1 of a particular brand of toaster expected to behave exactly like version 2? And which one of those versions of toaster is likely to attack the refrigerator or the home security system or the climate control system? And why would the toaster talk to the refrigerator in the first place?
It is possible with today’s technology to block the toaster from doing so, but until now it simply has not been practicable to implement those blocks. IP address and port-based access lists have existed since the first days of the Internet. By limiting access to devices to just that access they need, we are able to reduce attacks, both laterally within a network and more broadly across the Internet.
To do so requires that network owners know how the toaster is designed, and which communication patterns are nominal. In some cases, developers haven’t even made available the authorized hosts and ports a toaster needs to speak to. The best that can happen in those cases is observation and hoping that all designed behaviors have been understood, a task that could take qualified network administrators and researchers anywhere from days to months to complete – per device. Now multiply that task by the myriad of devices that can be found on a network, and the problem becomes intractable. Worse, in the home, the administrator is… my mom, the retired teacher (she was an award-winning teacher, but doesn’t know much about network administration).
“Everyone complains about the weather, but nobody does anything about it.”
–Charles Dudley Warner
Let us make a simplifying assumption: each device we are attempting to protect has a single or small number of purposes, and that it has a correspondingly small number of communication patterns. Let us also assume that the one who built the Thing is in the best position to describe what sort of access it needs. Thus, the architecture we describe is inappropriate for the laptop or tablet you are using to read this article, but hopefully more applicable to a thermostat or light bulb. However, once we make these assumptions, one can enumerate what access a device needs, and we know who is in the best position to provide that information.
A broad group of people have worked at the IETF to develop a means to automate learning what access a device needs. The architecture known as Manufacturer Usage Descriptions (MUD) is an evolution on much of the technology we have already developed. The just-approved draft contains 29 normative references, and contributions from leaders in the Internet, Operations, and Applications & Real Time areas of the IETF, as well as many others, an excellent example of collaboration.
Rather than an application of guesswork, MUD is a declarative approach. The following components are in the architecture:
- The thing connecting to the network;
- A network access device of some form, like a wireless access point that will limit access to the Thing;
- The MUD manager, that will retrieve and translate abstract policy recommendations from the manufacturer;
- The MUD file server, that is operated on behalf on the Thing manufacturer; and finally
- The MUD file that contains the policy recommendation.
Figure 1 – Components of the MUD architecture
This process begins when the device connects to a network. It will announce what type it is by emitting a URL that the manufacturer or developer configured. It can do this via DHCP[ii] or LLDP[iii] or via an IEEE 802.1X[iv] transaction with an X.509[v] certificate. Depending on how the device communicates the URL, the MUD manager receives this URL along with some relevant specifics about the device via a DHCP server, a AAA server or directly from the switch, access point or router. It then resolves the URL to retrieve a YANG-based JSON file that contains not much more than an access list or two that have abstracted local deployment information into classes that manufacturers can use. Indeed MUD augments the nascent access-control-list YANG model[vi], also developed at the IETF. The MUD manager then replaces those classes with specific IP addresses of endpoints with which a particular Thing should communicate.
MUD defines a handful of classes such as my-controller, controller, my-manufacturer, manufacturer, and local, the intent being that over time network management systems will automate their population.
Figure 2 – MUD files are translated into specific access-control lists
Figure 2 shows one possible translation of abstract policy into local ACLs. Other means are possible. One could even envision MAC-based ACLs, VLANs, and other approaches to impose access controls.
There are differing levels of trust associated with MUD. At its simplest level, when the MUD URL is conveyed without encryption, MUD is best used when it restricts access to a device, rather than adds access. This matches most deployments today. Over time, the stronger model where certificates and an associated trust model are used is more appropriate. When this method is used, the manufacturer certificate links the MUD URL and the name of the signer of the MUD file, thus binding the two. This requires that the MUD manager and the administrator make decisions about which signers are trustworthy, work that is ongoing in the industry.
Figure 3 – Securing the MUD File
One design goal behind MUD is to make it easy for manufacturers to implement. Adding a DHCP option or an LLDP TLV requires almost no additional space on the Thing, a device that may be quite cost sensitive. If a more advanced device has implemented certificate-based authentication, MUD specifies two extensions to be included. On the other side of this process, the manufacturer need only host a file and a signature for a device. The result is that the manufacturer’s role in the process of connecting a device is limited to the device emitting the URL and a web server transmitting a file.
The result of all of this that Things receive just the access they were designed to have in the first place, but no more. The toaster manufacturer might state a policy permits only HTTP local access on its port 80. The thermostat might only communicate with devices of particular manufacturers or with a locally defined controller. The more the access is circumscribed, the less likely a device will be able to be infected or be able to transmit malware.
Figure 4 – Things and their controllers
In the example in Figure 4, the air conditioner would want the thermostat listed as my-controller whereas luminaires would need the lighting switch as my-controller. Communications between the two subsystems are restricted, based on recommendations from both manufacturers.
This brings us to a few things MUD does not do. MUD does not repair end point vulnerabilities. Only the manufacturer can do that. If a device does get authorized to communicate with another device, it can be attacked and it can attack that other device. MUD is also not an authentication technology, although it works best in conjunction with those other mechanisms. For instance, IP-based access lists rely on the authenticity of the IP address.
Because MUD is a component architecture, the building blocks may be used in ways that are useful beyond the description in this article or the purposes of the standard. MUD doesn’t mandate use of specific protocols, but rather provides guidance on how to use a few of them to protect devices. For example, if devices are already registered in some form with a service provider, it may make more sense for them to not communicate a MUD URL, but instead have that information provided as part of that service provider registration.
Administrators can take advantage of MUD in three ways:
- Simply having devices output a MUD URL states what they are, and just knowing that gives some idea as to how to protect them.
- Have a look at the policies that manufacturers lay out. These give some idea as to what communications the devices are designed to have.
- Enable MUD protection in your infrastructure as the tools become available.
There are four actions manufacturers can take so that their customers can take advantage of MUD:
- Read the standard;
- Choose the right approach for your devices to output the MUD URL;
- Understand what network access each device needs (the standard gives you NTP and DNS access by default);
- Create and sign a MUD file and host it somewhere.
[i] Romkey, J. “Toast of the IoT: The 1990 Interop Internet Toaster”, IEEE Consumer Electronics Magazine,Volume 1, Issue 6, January 2017.
[ii] Droms., R., “Dynamic Host Configuration Protocol”, RFC 2131 et al., March 1997.
[iii] “IEEE Standard for Local and Metropolitan Area Networks: Station and Media Access Control Connectivity Discovery” IEEE 802.1AB, April 2005.
[iv] “IEEE Standard for Local and metropolitan area networks–Port-Based Network Access Control”, IEEE 802.1X-2010, 2010.
[v] Cooper, D., et al,” Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, May 2008.
[vi] Jethanandani, M., et al, “Network Access Control List (ACL) YANG Data Model”, draft-ietf-netmod-acl-model-19.txt, April, 2018.
[vii] Lear, E., Droms, R., Romascanu D., “Manufacturer Usage Description Specification”, draft-ietf-opsawg-mud-25.txt, June 2018.