Operations and Management Area Work Group S. Rich Internet-Draft Cisco Systems Intended status: Informational Expires: September 27, 2017 T. Dahm Google 27 March 2017 MUD Lifecyle: A Manufacturer's Perspective draft-srich-opsawg-mud-manu-lifecycle-01.txt Abstract Manufacturer Usage Descriptions, or MUDs, allow a manufacturer to cheaply and simply describe to the network the accesses required by an IoT device without adding any extra cost or software to the devices themselves. By doing so, the network infrastructure devices can apply access policies automatically which increase the overall security of the entire network, not just for the IoT devices themselves. This document describes the lifecycle of Manufacturer Usage Descriptions (MUDs) by describing detailed MUD scenarios from the perspective of device manufacturers. Status of This Memo 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 September 27, 2017. Rich & Dahm [Page 1] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 Copyright Notice Copyright (c) 2017 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. 1. Introduction The addition of IoT devices to a network expands the attack surface of that network. Even if a device does not have exploitable vulnerabilities (in the sense of an attacker injecting and running malware on it), it may be susceptible to denial-of- service (DoS) attacks and thus could have its functionality impaired by attackers. Recent events have shown just how real, and not just theoretical, such attacks can be. A detailed summary of the current state of understanding of the Mirai botnet's use of IoT devices can be found in [MIRAI]. It is estimated that around 100,000 IoT devices generated more than a terabit per second of DDoS traffic. Also consider the Sony Cameras IP Security article [SONYCAMS] which describes a vulnerability in many camera models which could be exploited to launch attacks like those seen in the massive DDoS attack on DynDNS in [DynDNS]. As both of these incidents show, more network-accessible devices which can connect to arbitrary external addresses can, if those devices permit too much access or if they have vulnerabilities which allow arbitrary code execution, be used by attackers to amplify attacks and to do so by using origin addresses spanning broad ranges of networks. Concerns about the negative possibilities of attacks related to IoT devices is also discussed in [MITTECH] that also discusses some of the regulatory and government angles in play. In a recent move described in [USGSUIT], the U.S. Federal Government has taken the step of suing D-Link, accusing it of ``poor security practices'' for some of its IoT devices. Rich & Dahm [Page 2] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 MUD provides a light-weight model of achieving very effective baseline security for IoT devices by simply allowing a network to automatically configure the required network access for IoT devices so that they can perform their intended functions without granting them gratuitous, unrestricted network privilege. 2. MUD High-level Introduction Manufacturer Usage Descriptions (MUDs) provide advice to end networks on how to treat specific classes of devices. The MUD architecture is explained in [LEAR2017], but we will describe it briefly here and also discuss details where necessary to understand this document. At its most basic, MUD is a system by which the IoT device itself tells the network exactly how to retrieve its network access requirements (in a ``MUD File'', which is the term used in the MUD specification to refer to the file which contains the description of an IoT device's network access requirements), and network infrastructure can fetch and act upon this information. The MUD File itself is a static text file which the network infrastructure element responsible for it can retrieve from the manufacturer or from whomever the manufacturer delegates the responsibility to. The MUD file may be cached, so when served, the MUD file should be returned with a ``max-age'' value which lets the requestor know how long it can cache it. To add MUD support to an IoT device is a very minimal change: add the URL for the MUD File as the ``MUD URI'' to whatever dynamic network registration protocol which is currently being used by the device (e.g. DHCP, etc.). It is so simple that the device manufacturer can statically compile the URI into the firmware of the device. The essential point is that MUD does not force a large behavioral change on the IoT device itself, and the serving up of the MUD file during the lifetime of the devices is similarly relatively low-impact. The bulk of the complexity of MUD is concentrated within the network elements which perform operations to retrieve the MUD files, possibly cache them, and then configure the network in response, but even there, the network elements effected mostly already perform all of these actions, albeit not automatically in most cases. For this description, one can consider three general classes of actors in the MUD ecosystem: o Device manufacturers o Networking equipment manufacturers Rich & Dahm [Page 3] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 o Network operators Note that end users are not mentioned here, as their involvement in MUD is minimal at best (and likely only present in the simplest of deployments). Note also that ``Device manufacturers'' are described with the assumption that they will both include MUD URIs within their devices as well as service MUD URL requests (via a cloud service or via their own web infrastructures). It is possible that a manufacturer will delegate the MUD URL retrieval function to a third party. The question of who actually services network requests for the MUD URL is an administrative one and does not affect the MUD architecture. It does give device manufactures more flexibility, though, in managing their investment into the MUD ecosystem. This document will describe the MUD ``lifecycle'' from the standpoint of manufacturers, but it is also intended to be informative to persons interested in standardization, installation, or other areas where MUD may be in play. Where appropriate, suggestions of best practices will be given if there are no specific hard requirements. 3. Terminology Before going into descriptions how MUD works, we will list terms used within the MUD ecosystem: MUD Manufacturer Usage Description MUD file a file containing YANG-based JSON that describes a recommended behavior MUD file server an HTTPS server that hosts a MUD file MUD controller the system that requests and receives the MUD file from the MUD server. After it has processed a MUD file it may direct changes to relevant network elements URL Universal Resource Locator Rich & Dahm [Page 4] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 URI Universal Resource Identifier. The difference between a ``URI'' and a ``URL'' is that a URI is intended to be used as an identifier in a general sense, whereas a URL is a specific use case of a URI that is used to access something at a particular network location MUD URI a URI that an IoT device carries and which will be issued during operations such as DHCP requests which can be used as a URL to retrieve a MUD file MUD URL the MUD URI being used as a URL IEEE 802.1AR A IEEE specification for a certification-based approach for communicating device characteristics YANG A data modeling language for the definition of data sent over the NETCONF network configuration protocol [RFC6020] NETCONF Network Configuration Protocol [RFC6241] JSON Javascript Object Notation, a human- as well as machine-readable file format containing textual representations of ``objects'' such as strings of characters, numbers, boolean values, and lists and dictionaries of such objects and collections of objects Many of these terms are in common usage with the IETF or other network standards bodies and are thus used for consistency. More information about terms like ``URL'', ``URI'', ``YANG'', and ``NETCONF'' can be found in the standards and references published by the IETF and others. The value in distinguishing ``URI'' and ``URL'' will hopefully become more apparent when MUD file caching is discussed (during which time, already-retrieved MUD files will be used if the URI lookup returns a match). The actual text of a ``MUD URI'' and a ``MUD URL'' will generally be identical; the distinction lies in the use of it by various elements (IoT devices, network devices, and web services). Rich & Dahm [Page 5] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 4. MUD Operation +--------------------------+ +------------------------------------------+ | [Manufacturer] | | [Customer] | | ------- | | | | +----->( ) 6 | | +------------+ 7 +----------------+ | | | |-------|<--------| MUD |---->| Network Policy | | | | 2:MUD| |-------->| Controller | | Management | | | | File ( ) | | +------------+ +----------------+ | | | ------- | | ^ | | | | | | 5:MUD | | 8 | | (1:Create Device) | | URI | v | | | | | +-------------+ | | | | | | (Switch) | | +---------|----------------+ | +-------------+ | v | | | | | | | +-------------------+ 3:Buy | 4:Deploy | | | | | | | Distribution ---------->| X X X X X ... | | Channels | | | +-------------------+ +------------------------------------------+ 6: MUD URI used as URL to request MUD File 7: MUD Controller informs network policy engine about ACLs 8: Network policy applied as close to IoT device as possible Figure 1: MUD-related network information flow A full description of MUD is given in [LEAR2017]. In short, when a device such as an IP-enabled lightbulb is connected to the network and given power, that device will perform some action to acquire a network identity, including an IP address, such as by making a DHCP request. If that request has a MUD URI in it, equipment in the network (not necessarily the DHCP server) can use that URI to retrieve the device's MUD file from the MUD file server. Some other networking component (the switch to which the bulb in connected, for example) can then act on the contents of the retrieved MUD file and apply the appropriate configurations to allow the device to function normally while restricting where it can connect. A MUD file's contents will mostly contain descriptions of which protocols are required by the device and over what port or ports. From the perspective of a manufacturer, the essential elements to note are the following: Rich & Dahm [Page 6] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 1. On the device itself, the only change required to add MUD compliance/functionality is to add a field populated with a URI to whatever network access protocol is already being used (i.e., DHCP, IPv6 AD, etc.). This will be a static text string which will probably remain constant throughout the life of the product and which is identical for every instance of a product run (i.e., there is no per-serial-number version of the MUD URI) 2. The MUD file which is to be returned via an HTTPS server can be a static file and can be reused for devices which have the same network access requirements. The service which returns the MUD file will not be responsible for any security policy enforcement, as that is the job of the network which contains the devices themselves 3. MUD files are fairly short (on the order of tens of lines of text) and are thus trivial to serve either directly and are amenable to caching 4. The act of retrieving the MUD file and of acting on it is entirely up to the network infrastructure and not a responsibility of the IoT devices themselves. MUD does not impose any behavioral requirements on the IoT devices themselves other than that they must send the MUD URI during network access configuration, as mentioned earlier How does MUD work in practice? Figure 1 shows a representation of the high-level MUD information flow. This document deals almost exclusively with elements in the upper left of that figure. Specifically, it describes what a manufacturer should do to put a MUD file into a device and what is required for a manufacturer (or a designee of the manufacturer) to answer requests for MUD files from network operators whose networks provide connectivity for such devices. 5. Device Manufacturer Considerations The device manufacturers have the most insight into what resources the devices will need once they are installed in a network. They are thus best-suited to author the network profiles which will be required by the devices that they make for correct operation. Conversely, each manufacturer cannot know what each network's other requirements happen to be. As a result, the manufactures should provide configuration requirements for their devices which network operators can apply in a way best suited for their networks. The network operator can optimize operations through Rich & Dahm [Page 7] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 caching, LAN segregation, etc., and can use the MUD information to further secure the network. If a manufacturer makes many devices which have similar network access requirements, that manufacturer may want to leverage common profiles. They should do so only when the profiles are truly close enough to be treated as the same. Device manufacturers have three responsibilities under MUD: o They must author a MUD profile which describes a device's requirements for network access o They must encode a MUD URI into the device such that when the device performs DHCP or similar o The MUD File must be hosted on a publicly-available web server Since the MUD profiles can be static files, there is very little overhead required to serve these profiles. Due to their static nature, they are inherently cacheable. Similarly, since the URI can be essentially static (the actual device configurations are easily updatable since they are contained in the MUD file, not the URI), the manufacturer can assign a name space and begin encoding the URIs into the devices relatively early in the manufacturing process, including before the MUD specification is finalized. An important point is that manufacturers should adopt and follow a nomenclature that insures that they can sufficiently distinguish classes or families of devices with different requirements and assign them different URIs. From a security standpoint, it is better to have several URIs with more granular security profiles than it is to have a very few URIs with "catch-all" (and thus more open) security profiles. This ensures that a customer using a single family of devices will have the most closed network configuration possible. If the device manufacturer decides to update the profile, then it may do so at any time, independently of updates to the firmware on the devices themselves. If it is expected that a profile may change frequently (say, for a new class of devices which aren't fully understood yet), then the MUD profile for said device should be served with a fairly short max-age (as compared to a device with a well-established network access profile). Rich & Dahm [Page 8] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 6. High-level MUD Lifecycle The following lifecycle description is described considering a single device. As additional devices are added to a portfolio, the same steps are taken for each one where necessary. Each step can be isolated or coordinated with other device instances where convenient. There is little coupling inherent in the way that the various phases of MUD deployment operates to impose strict requirements in this area. 1. Based on a device's function, a MUD profile is either: o Chosen from a library of existing profiles for similar devices o Written anew to describe this device's network requirements 2. If the profile is pre-existing, the a choice is made if this device will receive a new URI or if it should be classed as identical to existing devices and use the same URI 3. The chosen URI is assigned to the device so that when the device performs network initialization, the URI is included in the request (i.e., DHCP, ANIMA, etc.) 4. In parallel or in advance (but prior to first customer shipment), the device manufacturer should allocate in an appropriate namespace and place the MUD profiles for when the URI is used as a URL. 5. The MUD profile should be made available to customers until such a time that the device is unsupported. While it is outside the scope of this document, The manufacturer should support MUD profile retrieval for each device for at least as long as the manufacturer supports the devices themselves. 6. If the profile is found to contain an error, the manufacturer should update the profile. Devices which are already deployed will continue to use the original URI (unless a firmware updates changes it), so the original profile should be corrected 7. If a device manufacturer chooses to update a MUD-enabled device's firmware, the manufacturer may update the MUD URI to a new one. The manufacturer should change the URI if the network access requirements of the new firmware are sufficiently different from those of the original firmware version. Rich & Dahm [Page 9] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 7. MUD URI The MUD URI is a very visible and important part of MUD that is best done correctly from the start, for once it is embedded in an IoT device, changing it for the fielded devices will be, at best, inconvenient. Choosing a scheme for organizing the ``name space'' for the portion of the URI which is controlled by the device manufacturer may have knock-on effects such as the URL GET request routing behavior that must be supported during MUD file retrieval. The format of the URI is: https://authority/.well-known/mud/mud-rev/model where ``mud-rev'' is currently the literal string ``v1'', and may be suffixed with `` ?extras ''. Referencing [RFC3986], the authority element is described by the ``authority'' type, the model element by the ``segment'' type, and extras by the ``query'' type. This gives considerable flexibility to manufacturers to structure their various namespaces to handle a huge variety of device types. However, this document will restrict itself to describing a very simple URI encoding scheme. In the following, we will use ``example.com'' as the authority element. By far, the simplest method of assigning MUD URIs to devices is to assign each distinct model number a URI of the form https://example.com/.well-known/mud/v1/model where the ``model'' element is literally the model number of the device. If a manufacturer has a model number collision problem (possibly because of acquisitions of other companies, for example), a simple scheme of a prefix or a suffix, set off with a hyphen or similar, will suffice to disambiguate them. Since the MUD files are relatively small, there is likely little value in conjuring schemes to save disk space with complicated naming conventions or structure. 8. MUD File Serving: Operations, Lifetypes, and Transfer The previous section discussed how one might design the URI namespace for MUD files. Another very important consideration is the total lifecycle of the serving of MUD files via the internet for an appropriate length of time and what to do if one wants to transfer the responsibility of serving MUD files to some other Rich & Dahm [Page 10] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 entity. This section will describe several scenarios and suggest options for the transfer of responsibility of MUD files to other providers. There is no single set policy for these various activities, and organizations are free to decide how and when these transfers occur. There are technical considerations that must be dealt with, but this is not unlike outsourcing subsections of one's web site to payment partners or other specialists if so desired. The single largest factor in thinking about serving MUD files throughout their lifetimes is the relative ``permanence'' of the URI itself (since, for some types of devices, at least, the buried-in URI will be essentially indelible). Even if a device has a more fungible MUD URI (say, because it is easily and frequently updated), it is still wise to consider the case when a device's MUD URI cannot be easily updated since this represents the most problematic case. Networks containing the MUD-enabled devices will make network requests to retrieve the MUD files. The MUD URIs are, quite literally, the URLs of the MUD files. There, network infrastructure devices from potentially anywhere on the internet will try to retrieve these MUD files. The volume of requests will be simple to handle (given that MUD files are static and small and that MUD servers in the network will be able to cache them and avoid redundant retrievals). A very simple and direct way to manage MUD files and make the possible future delegation of MUD file serving to a $3^{rd}$-party is to assign a URI DNS ``namespace'' for your company's MUD files. For example, using the fictional company ``Acme Lightbulb and Sensor'' and its web presence at ``https://acmels.com'', the DNS namespace for MUD files could be mud.acmels.com which can serve as the authority section of the MUD URI. If Acme wants to serve the MUD files themselves, then they can provision an HTTPS service that serves that address and return the requested MUD files, or they can create a CNAME to point to the actual entity who will answer the requests. 9. Security Considerations The bulk of this document describes the use of MUD to increase the security of a network. However, it is possible to compromise the effectiveness of MUD by attacking its behavior directly. This section discusses the known attacks and describes possible mitigations (all from the manufacturer's perspective). This section also attempts to clarify the limits to which MUD is expected to perform in terms of increasing security. Rich & Dahm [Page 11] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 The first and most obvious attack scenario is that a malicious or compromised device can issue a MUD URI which allows that device to communicate too permissively, either by having the URI refer to an unintended file or by simply putting too permissive a set of rules in the otherwise-legitimate MUD File. A manufacturer SHOULD employ secure development best practices to take reasonable steps to insure that their devices behave correctly at least up to the point that they are shipped and that their web services follow all BCPs. Other attacks are not manufacturer-specific and will not be covered in this document. They will instead be discussed in TBD which focuses on the network operator's perspective of MUD. 10. IANA Considerations This document has no actions for IANA. 11. Normative References [LEAR2017] Lear, E., "Manufacturer Usage Description Specification", draft- ietf-opsawg-mud-03, January 05, 2017 [WEIS2017] Weis, B., "RADIUS Extensions for Manufacturer Usage Description", draft-weis-radext-mud-00, October 25, 2016 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", IETF RFC 6020, 2010 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and Bierman, A., "Network Configuration Protocol (NETCONF)", IETF RFC 6241, 2011 [RFC3986] Berners-Less, T., Fielding, R., Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", IETF RFC 3986, 2005 12. Informative References [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Rich & Dahm [Page 12] Draft MUD Lifecyle: A Manufacturer's Perspective 27 March 2017 Practices", RFC2882, July 2000 [MIRAI] https://www.flashpoint-intel.com/action-analysis-mirai-botnet- attacks-dyn/ [SONYCAMS] http://www.pcworld.com/article/3147311/security/backdoor-accounts- found-in-80-sony-ip-security-camera-models.html [DynDNS] http://www.pcworld.com/article/3134056/hacking/an-iot-botnet-is- partly-behind-fridays-massive-ddos-attack.html [MITTECH] https://www.technologyreview.com/s/603015/security-experts-warn- congress-that-the-internet-of-things-could-kill-people/ [USGSUIT] https://www.cnet.com/news/d-link-lawsuit-ftc-security-hackers/ Authors' Addresses Steven Rich Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 Email: srich@cisco.com Thorsten Dahm Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: thorstendlux@google.com Rich & Dahm [Page 13]