| Network Working Group | E. Lear |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | January 21, 2016 |
| Expires: July 24, 2016 |
Manufacturer Usage Description Framework
draft-lear-mud-framework-00
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Internet has largely been constructed on general purpose computers; those devices that may be used for a purpose that is specified by those who buy the device. [RFC1984] presumed that an end device would be most capable of protecting itself. This made sense when the typical device was a workstation or a mainframe, and it continues to make sense for general purpose computing devices today, including laptops, smart phones, and tablets.
[RFC7452] discusses design patterns for, and poses questions about, smart objects. Let us then posit a group of objects that are specifically not general purpose computers. These devices therefore have a purpose to their use. By definition, therefore, all other purposes are NOT intended. The combination of these two statements can be restated as a manufacturer usage description (MUD) that can be applied at various points within a network. Although this memo may seem to stress access requirements, usage intent also consists of quality of service needs a device may have.
We use the notion of “manufacturer” loosely in this context, to simply mean the entity or organization that will state how a device is intended to be used. In the context of a lightbulb, this might indeed be the lightbulb manufacturer. In the context of a smarter device that has a built in Linux stack, it might be integrator of that device. The key points are that the device itself is expected to serve a limited purpose, and that there may exist an organization in the supply chain of that device that will take responsibility for informing the network about that purpose.
The converse statement holds that general computing systems will benefit very little from MUD, as their manufacturers cannot envision a specific communication pattern to describe.
The intent of MUD is to therefore solve for the following problems:
No matter how good a MUD-enabled network is, it will never replace the need for manufacturers to patch vulnerabilities. It may, however, provide network administrators with some additional protection when those vulnerabilities exist.
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.
The notion of intended use is in itself not new. Network administrators apply access lists every day to allow for only such use. This notion of white listing was well described by Chapman and Zwicky in [FW95]. Programmatically profiling systems have existed for years as well. These systems make use of heuristics that take at least some time to assert what a system is.
A system could just as easily tell the network what sort of protection it requires without going into what sort of system it is. This would, in effect, be the converse of [RFC7488]. In seeking a general purpose solution, however, we assume that a device has so few capabilities that it will implement the least necessary capabilities to function properly. This is a basic economic constraint. Unless the network would refuse access to such a device, its developers would have no reason to implement such an approach. To date, such an assertion has held true.
If the network does not apply heuristics and a device is not capable of articulating what it needs from the network, perhaps there is a third approach that builds on capabilities already in both. There are four such potential capabilities for the network to determine what sort of client it has:
With these capabilities, a device may impart some piece of information to the network. In the immortal words of David John Wheeler, “All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.” Our means of providing this level of indirection is a Universal Resource Identifier (URI) [RFC3986] that references a file put in place by someone who knows something about the device – the manufacturer. As we will later discuss, we can later relax whether it is indeed the manufacturer who is specifying the URI.
With a simple resolution of a URI, a file is retrieved. We are now to the point in the discussion where we have to decide how the manufacturer expresses intent. We have already stated that Things themselves have limited capabilities. Let us also assume that we in the networking business wish to stand on the shoulders of giants and also not reinvent the wheel. While such a wheel is not perfectly rounded for our purposes, YANG models [RFC6020] and their derivative XML provide sufficient richness for the manufacturer to clearly state at least simple intent. They are thus our starting point.
Once we know how to determine intended use and who can determine it, there is still the question of what that sort of policies can in fact be intended. At least initially, we envision that as a beginning host-level access 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
To add a bit more depth that should not be a stretch of anyone’s imagination, one could also make use of port-based access lists. Thus a printer might have a description that states:
Allow access for port IPP or port LPD Allow local access for port HTTP Deny all other access
In this way anyone can print to the printer, but local access would be required for the management interface.
Other non-access policies may be possible as well. For instance, suppose a manufacturer is able to make use of an authentication infrastructure. That could be specified in the usage description such that the details could be filled in by the controller. In addition, QoS policies are sufficiently mature and ubiquitous as to be valuable in this context as well. And so for instance, for voice/video services:
Set QoS AF13 to SIP-GW.EXAMPLE.COM
The converse highlights a design consideration: policies that are articulated by the manufacturer must be ubiquitously understood, or they may not be applied. That is- applying half a policy is not safe.
With these components laid out we now have the basis for an archicture. This leads us to ASCII art.
......................................... . ____________ . __________ . | Network | . | | . | Management |----->get URI->| MFG | . | System | . | Web Site | . End system network |____________|<--MUD file<--<|__________| . . . . . . . _______ _________ . .| | | router | . .| Thing |---->MUD URI-->| or | . .|_______| | switch | . . |_________| . .........................................
Figure 1: MUD Architecture
In the above diagram, the switch or router collects MUD URIs and forwards them to the network management system for processing. This happens in different ways, depending on how the URI is communicated. For instance, in the case of DHCP, the DHCP server might receive the URI and then process it. In the case of IEEE 802.1X, the switch would tunnel the URI to the authentication server, who would then process it.
The information returned by the web site is valid for the duration of the device’s connection, or as specified in the description. Thus if the device is mobile, when it moves on, any configuration in the switch is removed. Similarly, from time to time the description may be refreshed, based on new capabilities or communication patterns or vulnerabilities.
The web site is run by or on behalf of the manufacturer. Its domain name is that of the authority found in the MUD URI. For legacy cases where Things cannot emit a URI, if the switch is able to determine the appropriate URI, it may proxy it, the trivial cases being a map between some registered device or port and a URI.
To begin with, MUD takes full advantage of both the https: scheme and the use of .well-known. HTTPS is important in this case because men in the middle could otherwise harm the operation of a class of devices. .well-known is used because we wish to add additional structure to the URI. And so the URI is specified in draft-lear-netmod-mud-pre0. It looks like this:
https://manufacturer.example.com/.well-known/mud/v1/model/version#extra
“model” represents a device model as the manufacturer wishes to represent it. It could be a brand name or something more specific. “version” provides a means to indicate what version the product is. Specifically if it has been updated in the field, this is the place where evidence of that update would appear. Once again, the field is opaque. From a controller standpoint, therefore, only comparison and matching operations are safe.
We assume that the the manufacturer has at its disposal a web service running atop port 443 with standard HTTPS semantics, and that its capabilities are at par with today’s web servers. We further assume that this web server has no semantic understanding itself of MUD. This poses us a particular challenge: either we are to cast in stone the model that is put in place, or we must find a mechanism by which the switch or its controller can choose an appropriate set of capabilities.
Because NETCONF is well distributed within network infrastructure and YANG has become the accepted way to generate schema for NETCONF, these we attempt to adapt the protocol and the modeling language, respectively. At some point in the near future, it will likely be the case that XML gives way to JSON[RFC7159]. YANG can be used for either, and so it seems even more appropriate to make good use of it. This work makes use of XML because of the breadth of toolsets available, and not for any love of angle brackets. That is subject to change.
The descriptions specified in MUD files should be based on relatively ubiquitous network capabilities. Access lists are such an example, and QoS policies follow closely behind. For security purposes, these policies must only apply to the device that is connecting, and should not modify other parts of a network element’s configuration. The key scaling properties here are as follows:
The network management system receiving the MUD file must convert it into an access list that a network element understands, and apply it to an appropriate interface, limiting its applicability only to the device in question. In some cases, the policies will be abstract. For example, “local” would be translated to the set of networks that are within the same administrative domain. It is the network management system’s responsibility to see that the configuration is removed when the device detaches, and that the configuration is consistent with other policies that might apply to that device. Importantly, network management systems should always defer to the network administrator’s wishes. As such, a conflicting policy should not be deployed, but rather logged.
Human interaction may be required in some cases. In the home, one could imagine description simply being instantiated, whereas in the enterprise, someone may need to review the description before it is applied.
It is distinctly possible that a highly advanced enterprise would ignore any manufacturer recommendations altogether but still use the URI received from devices as a classifier.
In some environments it may not be possible for policy reasons to make changes to network elements to instantiate usage descriptions as a means of enforcement. These very same descriptions may be used as a means to audit activity of a device to determine whether or not it is acting in accordance with the the manufacturer’s intent.
[I-D.ietf-anima-bootstrapping-keyinfra] specifies a means by which a device is configured with appropriate credentials for a given network. This work specifies a means to configure the network rather than the device. In fact, one key assumption of MUD is that it will be extremely painful to make any end system changes.
The three mentioned means for a device to emit a MUD URI each have their own security properties, and will be discussed in separate drafts. A risk they share in common, however, is that the URI could point to to a site that contains malware. To avoid such problems, several countermeasures are suggested:
By emitting a URI the device may identify itself to an interloper. As it happens, most devices can be relatively easily fingerprinted based on their communications patterns. However, if this is of concern, devices should emit the URI to network controllers over secure channels.
Use of certain operations, such as SameManufacturer scale less well than others. Frequent connects and disconnects could cause configuration storms. To address this risk, as the number of changes increase, modifications to devices other than the one connecting should decrease or simply be scheduled. In as much as this is an attack, it can also be mitigated through device authorization mechanisms such as 802.1X.
The IANA is requested to enjoy a coffee or tea, as there is nothing in this document that otherwise requires their attention.
The author thanks Bernie Volz, Eric Vyncke, and Cullen Jennings for their helpful suggestions.