[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Operations and Management Area Work Group                        S. Rich
Internet-Draft                                             Cisco Systems
Intended status: Informational
Expires: September 27, 2017                                      T. Dahm
                                                           27 March 2017

               MUD Lifecyle: A Manufacturer's Perspective


   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

   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:

      Manufacturer Usage Description

   MUD file
      a file containing YANG-based JSON that describes a recommended

   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

      Universal Resource Locator

Rich & Dahm                                                     [Page 4]

Draft          MUD Lifecyle: A Manufacturer's Perspective  27 March 2017

      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

      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

      the MUD URI being used as a URL

   IEEE 802.1AR
      A IEEE specification for a certification-based approach for
      communicating device characteristics

      A data modeling language for the definition of data sent over the
      NETCONF network configuration protocol [RFC6020]

      Network Configuration Protocol [RFC6241]

      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

   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

   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

   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


   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:


   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


   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

   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
   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

   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

      Lear, E., "Manufacturer Usage Description Specification", draft-
      ietf-opsawg-mud-03, January 05, 2017

      Weis, B., "RADIUS Extensions for Manufacturer Usage Description",
      draft-weis-radext-mud-00, October 25, 2016

      Bjorklund, M., "YANG - A Data Modeling Language for the Network
      Configuration Protocol (NETCONF)", IETF RFC 6020, 2010

      Enns, R., Bjorklund, M., Schoenwaelder, J. and Bierman, A.,
      "Network Configuration Protocol (NETCONF)", IETF RFC 6241, 2011

      Berners-Less, T., Fielding, R., Masinter, L., "Uniform Resource
      Identifier (URI): Generic Syntax", IETF RFC 3986, 2005

12.  Informative References

      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






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]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/