Internet DRAFT - draft-srich-opsawg-mud-manu-lifecycle
draft-srich-opsawg-mud-manu-lifecycle
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]
