[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: March 27, 2017                                          T. Dahm
                                                                  Google
                                                       27 September 2017


             MUD Lifecyle: A Network Operator's Perspective
              draft-srich-opsawg-mud-net-lifecycle-01.txt


Abstract


   This memo describes the lifecycle of MUD as seen from the
   perspective of a network operator.  It is informational and
   intended to help provide perspective around the operation of a
   network which connects MUD-supporting devices and uses MUD-
   supporting network infrastructure.  All phases of network
   operation that involves or affects MUD will be described.
   Considerations specific to device manufacturers will be described
   elsewhere.  Considerations relevant to network equipment
   manufacturers and networking software authors will be described
   where appropriate where MUD behavior is affected.


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 March 27, 2017.







Rich & Dahm                                                     [Page 1]


Draft                MUD Lifecyle: Network Operator    27 September 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.  MUD Introduction

   Network architects and operators have the goal of designing and
   operating networks so that they are reliable, secure, and operate
   correctly.  Making them do so requires that the network permit
   traffic which is intended to be allowed on the network while
   rejecting or blocking traffic which is not.  Both goals are met
   with a combination of policies and configurations which promote
   efficient routing of packets for certain classes of traffic and
   which rate limit or even block (possibly by black-holing) other
   classes of unwanted or lower-priority traffic.

   A common assumption is that devices on the inside of the network
   can have relatively unrestricted access to other parts of the
   network and to the local network segment.  This is reasonable for
   devices which themselves have certain configurations which will
   naturally govern which network access they require.  For example,
   a printer will usually be configured to accept connections from
   hosts which wish to print to it.  The printer itself may not tend
   to initiate outbound connections and thus does not require a
   complex set of custom ACLs.  If the printer needs external
   connectivity, the usual scenario is to allow the printer to make
   outbound connections while still preventing inbound connections
   using a stateful firewall rule or similar.  However, there are
   often no rules preventing the printer from making arbitrary
   connections within network delineated by the firewall.

   Other devices such as general-purpose end-user hosts (PCs, Mac,
   etc.)  might need unrestricted access, at least in the outbound
   direction, because, contrary to the printer example, end-user
   hosts are generally expected to make outbound connections to an
   unpredictable number of hosts.  Even if outbound restrictions to



Rich & Dahm                                                     [Page 2]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   certain ports (such as 80, 443, 22, 25, etc.) are enforced, the
   destination address may be unrestricted.  As stated above,
   restrictions from internal hosts to internal addresses may be even
   more lax.

   Enter into this situation IoT devices which may be introduced to
   the network in the thousands and which may have unspecified or
   unclear requirements for network access.  For example, IoT light
   bulbs may need to talk to DNS, NTP, LLDP, DHCP, and a controller
   on the local network and nothing else.  An IoT thermostat may need
   to talk to DNS, NTP, LLDP, DHCP, and its cloud-based controller,
   but nothing else.  For both of these cases, while their specific
   requirements vary, knowing each one's requirements would allow a
   tight set of ACLs to be imposed, all the way to the port level, to
   limit what connectivity is afforded to each individual instance.

   Recent examples of IoT-based malware campaigns will not be
   repeated here and the benefits of providing such security will no
   doubt be obvious to network operators.  What has not been
   available before MUD is an ability to automatically retrieve
   configuration policy and then automatically apply it for each
   device.  This document will describe the ``lifecycle'' of MUD from
   the perspective of a network operator.  The details of the
   protocol and contents of the MUD file itself are described in
   [LEAR2017], and familiarity with it is assumed for this document.


2.  Terminology

   This document will use some terms and abbreviations which will be
   listed and described in this section.

   MPD
      "MUD-Protected Device" - While this is a possibly tedious use of a
      three-letter acronym, repeated use of "MUD-protected device" or
      similar is equally tedious

   AAA Server
      "Authentication, Authorization, and Accounting Server" - A network
      service which processes AAA requests

   ACL
      "Access Control List" - In the context of this document, an ACL
      will refer specifically to those which are specified in a MUD file
      and which get applied at some point in the network to enforce the
      security policy needed by a device.  These ACLs may be configured
      down the port into which the device the is plugged, and they may
      be applied "dynamically" in the sense that they appear in response



Rich & Dahm                                                     [Page 3]


Draft                MUD Lifecyle: Network Operator    27 September 2017


      to the MUD request as opposed to a static configuration.  They
      will not be dynamic in the sense that they change frequently.  The
      actual implementation by any particular vendor is left up to that
      vendor and thus may differ from the examples given in this
      document.


3.  MUD Lifecycle Description for Network Operators

   The totality of what network operators must do to build, operate,
   and maintain networks will not be described in exhaustive detail
   in this document.  Instead, we will describe what additional or
   different things are necessary or recommended when establishing
   MUD support within the network.  Some of the steps discussed will
   presuppose that networking equipment vendors will have added MUD
   support to their products.

   The following high-level tasks are required to support the
   automatic network configuration aspects of MUD devices on the
   network:

   1. Network Segmentation Considerations and Design

   2. Install and/or enable a MUD Policy Server

   3. Configure network devices so that they will receive and enforce
      ACLs generated by the MUD Policy Server

   4. Test and verify functionality by confirming that MUD files are
      retrieved and ACLs are applied to the appropriate ports and that
      those ACLs are removed when the port goes down

   The MUD Policy Server may support caching retrieved MUD files.  If
   it does, then the operator may choose to enable, tune, test, and
   monitor this functionality as well.  Details about caching MUD
   files as well as each task above will be covered later in this
   document.

   The network equipment to which MPDs connect must be capable of
   accepting and enabling dynamic ACLs which can preferrably be
   scoped to a port.  While it is conceivable that the ACLs be
   combined and applied at a point in network that is multiple hops
   away from the switch to which the MPD connects, the tightest
   security controls are possible when enforcement can happen
   directly on the port.  This eliminates the possibility that a MPD
   can talk to other devices on the same switch unless explicitly
   permitted.  The remainder of this document will only discuss the
   case of using ACLs.



Rich & Dahm                                                     [Page 4]


Draft                MUD Lifecyle: Network Operator    27 September 2017


3.1.  Network Segmentation Considerations and Design

   A well-designed network is one which includes the use of
   segmentation which keeps different parts of the network isolated
   from each other to the optimimum degree.  For example, groups of
   machines which need to communicate frequently and at high speed
   most likely should be on the same LAN.  Different groups of
   machines which rarely communicate together can be separated into
   different routed networks, and depending upon security
   requirements, may even be guarded by ACLs or other mechanisms.

   Different network segments may be designed with different
   expectations of security.  Inner-bastion networks may contain
   sensitive systems which are isolated from all but the most trusted
   systems.  Segments which allow guest users or devices which are
   less trusted may be relegated to segments which have also been
   protected with ACLs, but the focus can be on limiting what the
   devices in the segment can access rather than worrying about what
   external devices can access inside the segment itself.

   The goal of MUD is to enable the near-automatic management of
   device segmentation for the class of devices which have MUD
   support.  To be maximally effective, though, the network designer
   should take advantage of pre-defining segments into which MUD-
   capable devices can be grouped by function and by required access.
   An optimal middle ground (for a large network with many types of
   MUD-enabled devices) would comprise some device-class-specific
   segments, some vendor-specific segments, the essential set of
   network segments (required regardless of MUD for the normal
   operation), and perhaps a ``default network'' into which untrusted
   devices are placed which get no internal network access and
   severely limited internet access.

   Ideally, with full MUD support in devices deployed in a network,
   there would be no need for the so-called ``default network''
   segment (except perhaps as a ``guest'' network) since MUD profiles
   would result in a properly-segmented and protected devices.  Until
   MUD is ubiquitously supported, though, it is wise to consider the
   option.

   To make these ideas more clear, an example network will be
   described (at a high level) with various segments defined.  The
   use of each segment by MUD will then be described.  These are
   segments within a larger network which will not be described to
   avoid cluttering the diagram.






Rich & Dahm                                                     [Page 5]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   +-------------+---------------------+-----+
   |Segment Name | Segment Description | MUD |
   +-------------+---------------------+-----+
   |SecDB        | Recorders, IDs      |  N  |
   +-------------+---------------------+-----+
   |Readers      | Badge Scanners      |  Y  |
   +-------------+---------------------+-----+
   |Cameras      | Security Cameras    |  Y  |
   +-------------+---------------------+-----+
   |Other        | Other IoT devices   |  Y  |
   +-------------+---------------------+-----+
   |NetMgmt      | Network Management  |  N  |
   +-------------+---------------------+-----+

   There are five segments.  Two of them will have no MUD-enabled
   devices in them, whereas the other three will.  Of those three,
   one is a non-classed MUD network (i.e., one in which MUD-enabled
   devices which do not belong to specifically-configured classes
   will be placed).  The connectivity of the network looks like:

      +--------------------+
      | Network Management |-----------|
      +--------------------+           |
        |                              v
        |                            +--------------+
        |                            | SecDB        |
        |  +---------+               | +----------+ |
        +->| Readers |---------------->|Controller| |
        |  +---------+               | +----^-----+ |
        |                            +------|-------+
        |     +---------+                   |
        +---->| Cameras |-------------------+
        |     +---------+
        |
        |       +-------+
        +------>| Other |
                +-------+

   The SecDB segment will contain senstive systems as well as a
   controller to which some of the other devices will need to
   communicate.  The Readers will be a segment in which all
   badge/card readers will be grouped.  The Cameras segment will
   contain all of the security cameras.  Finally, all other MUD-
   enabled devices will be placed in the Other segment.  Devices
   placed into any of these segments as a result of MUD will still
   have applicable ACLs applied.  In addition, any static access
   control restrictions given to each segment will be enforced per
   the network designers' intentions.



Rich & Dahm                                                     [Page 6]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   How do the cameras get into the Cameras segment, and how do the
   card readers get into the Readers segment?  The specifics will
   depend on the MUD Controller implemenation and the network devices
   used, but the gist is that the network administrator defines
   policies which map a MUD file's ``manufacturer'' and ``model'' to
   the appropriate network segment assignment policy.  If no specific
   mapping is available for a device, then the MUD-enabled device
   will be placed into a default segment per the operation of the MUD
   Controller in use.

   Another consideration is what to do with devices which have no MUD
   profile at all.  This was the case for all device before MUD was
   defined and may continue to be the case for certain classes of
   devices.  The solution again lies with the definition of network
   policies.  It is up to the network designer to choose which
   segment or segments devices which have no MUD support are placed
   by default.  Theoretically, the placement could be influenced by
   the MAC address, the port into which the device is plugged, etc.

   The bottom line is that MUD is not responsible for fully
   describing the network configuration policy.  It is very helpful
   to automatically limit the access that MUD-enabled devices are
   afforded to only what they need, but the network operator must
   insure that the network design is complete.


3.2.  Installing and/or Enabling a MUD Controller

   MUD Policy Servers can conceivably take on many forms, including
   stand-alone appliances, software modules installed on a switch or
   a router, a software package installed and integrated with a DHCP
   server, etc.  The key requirements for MUD Policy Servers are:

   1. Able to "see" a MUD URI

   2. Able to retrieve a MUD file

   For a MUD Policy Server to ``see a MUD URI'', it must either be
   able to see the DHCP or equivalent requests from MPDs directly or
   it must be otherwise connected to the service which does get to
   see these types of requests.  For example the MUD Policy Server
   could be implemented as a plugin to a RADIUS server which is
   receiving requests from a switch which is handling DHCP requests
   by generating corresponding RADIUS AAA requests.

   For a MUD Policy Server to be able to retrieve a MUD file, it must
   have network access permissive enough to retrieve files which are
   served from arbitrary locations on the internet.



Rich & Dahm                                                     [Page 7]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   Finally, to have any useful effect, the MUD Policy Server must be
   able to, having parsed a MUD file, generate ACLs which are to be
   applied to the appropriate port of the appropriate network device
   (i.e., a dynamic configuration must be generated and applied which
   reflects the MUD policy).  The specifics of how the generated ACLs
   get back to the NAS and get applied to the proper port will depend
   on the design of the network.

   At the time of this document's preparation, MUD is still a new
   protocol and is under development.  Therefore, descriptions of how
   it is integrated will be subject to adjustment according to the
   progression of actual implementations.


3.3.  Network Device Configuration

   There are two distinct "network configuration" concepts involved
   in the deployment of MUD:

   1. Configuration of the network infrastructure such that the MUD
      controller is "in the loop" and able to issue configurations for
      devices as they appear on the network

   2. The per-device dynamic configuration that is generated through the
      behavior of MUD itself

   This document discusses both concepts where applicable.  To avoid
   confusion, when a reference is made to "configuring a device" or
   similar, we will be referring to setting up the network
   infrastructure to include the MUD Policy Server into operations.
   The actions of the MUD infrastructure and network infrastructure
   to effect changes to network configurations persuant to MUD-
   advised policies will be referred to as "applying device policy"
   or (when it is more clear to do so) "applying the dynamic device
   configuration".  The key word in the latter is dynamic and may be
   used when describing the specific steps being taken by the devices
   to apply the policies.

   As previously mentioned, the ideal point for the application of
   MUD-based access restrictions is the port into which a device is
   directly plugged since this results in the most finely-grained
   application of access control and insures that devices are not
   able to talk even to neighbors on the same shared media without
   MUD authorization.  For this to happen, the switches which connect
   to MUD-enabled devices must be configured to allow ACLs to be
   applied to each port.  If the switch is stand-alone, then it will
   have to be configured to allow something like RADIUS or similar so
   that a controller device can send ACLs to the switch via an



Rich & Dahm                                                     [Page 8]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   authorization transaction once the MUD profile has been processed.

   For MUD to work properly, the switches MUST remove any dynamic
   configuration applied to a port when the connection on that port
   is dropped (such as when the cable to the port is disconnected).
   Once reconnected, a device will again issue a DHCP or similar
   request and the MUD behavior will begin again.

   As an example, if a Layer-2 switch is used which can process DHCP
   requests by issuing RADIUS AAA requests to complete the port-level
   authorization, MUD process can occur by:

   1. The switch adds the MUD URI to the RADIUS request (see [WEIS2017])

   2. The RADIUS server passes the MUD URI to a MUD Controller

   3. The returned MUD file is processed and the appropriate ACLs
      generated

   4. The ACLs are encoded into the RADIUS Authorization response and
      returned to the switch

   5. The switch receives the RADIUS Authorization, matches it to the
      port being provisioned, and applies the ACLs


3.4.  Testing and Verification

   In addition to the normal activities of validating through
   monitoring commands that ACLs have been applied as expected, the
   following items are suggested:

   o  If one wants to understand what ACLs will be applied during a test
      of a particular device, one can read the MUD file to understand
      what access requirements it has and thus compare that with what
      ACLs get applied during the operation of the MUD protocol

   o  The devices with MPDs attached to them should be checked to
      confirm the application of the expected ACLs and they are scoped
      to the appropriate ports

   o  An ideal test would be to connect a MUD-enabled test client which
      will issue an appropriate network access negotiation via DHCP or
      whatever is appropriate for the NAS in use so that a full MUD File
      retrieval is triggered.  The test client should then be used to
      try to both confirm connectivity to its explicity provisioned
      destination(s) while also verifying that it is not possible to
      reach sites outside the stipulated ACLs.



Rich & Dahm                                                     [Page 9]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   o  The MPD should be disconnected from the switch and the switch
      checked to verify that the ACLs are removed (which may not occur
      until another device is plugged into the same port)


3.5.  Caching MUD Files

   MUD Files may be cached by the MUD Controller.  The MUD File
   itself indicates the minimum time between re-retrievals of a MUD
   File via the ``cache-validity'' attribute.  When the MUD
   Controller is asked for a MUD File, if the URIs match a cached MUD
   File which is recent enough to be used, then that cached MUD File
   should be used.  If not, then a valid MUD File MUST be retrieved
   by using the URI as a URL.

   Note, however, that MUD files are very small.  Additionally, MPDs
   will likely be installed into networks and then left running for
   long periods of time such that the number of MUD file requests
   will likely be small.  Given those considerations, the value in
   caching MUD files, at least in the near term, is expected to be
   low.


4.  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 network operator's perspective).  This
   section also attempts to clarify the limits to which MUD is
   expected to perform in terms of increasing security.

   The use of MUD is intended to increase the level of security in
   the network relative to its current state.  If the network has no
   security protections in place, then MUD may improve the situation
   by limiting access to MUD-enabled devices, but the network may
   already be too permissively accessible to be secure.  A common
   comment about MUD is that a compromised MUD File can allow a MUD-
   enabled device to access arbitrary parts of the network or to
   allow arbitrary access to the device.  If the network had had no
   security to begin with, then the compromised MUD File will not
   have reduce the security in any meaningful way.

   To put this another way, any network SHOULD be properly designed
   such that the minimum required access is granted to all parties
   involved.  If this is done, then a bad MUD File can only result in
   too permissive access to and from a single device in the network.



Rich & Dahm                                                    [Page 10]


Draft                MUD Lifecyle: Network Operator    27 September 2017


   Although MUD is still a new protocol, it is conceivable that an
   "ecosystem" around it will grow that will enable a level of
   security validation that is much more difficult without it.  In
   particular, the published MUD Files could be analyzed by third
   parties to assess their contents and to make users aware of
   anomalies.  Additionally, deviations in successive versions of MUD
   Files can be audited to detect surprising changes.

   Another commonly-mentioned attack scenario is tampering with the
   MUD URI during device bring-up to cause a different MUD File to be
   fetched and applied in place of the correct, manufacturer-supplied
   file.  The ramifications of such an attack are no different than
   that of a compromised MUD File.  The mitigation against the attack
   is insure the use of secure means of receiving and processing the
   device's advertisement of the MUD URI.

   One other intriguing attack scenario is the spurious introduction
   of something akin to a "phantom" DHCP request with a MUD URI
   intended to coax the network infrastructure into fetching and
   acting on a MUD File, possibly without an actual device being
   present (or the "device" actually being a rogue software element
   running on a real device).  In addition to mitigations already
   mentioned, port-level security should be used whenever possible
   with strict security policies to enable the detection of these
   rogue DHCP or other advertisements.


5.  IANA Considerations

   This document has no actions for IANA.


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

7.  Informative References


   [RFC2882]
      Mitton, D., "Network Access Servers Requirements: Extended RADIUS



Rich & Dahm                                                    [Page 11]


Draft                MUD Lifecyle: Network Operator    27 September 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 12]


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