MUD Lifecyle: A Network Operator's Perspective

Document Type Active Internet-Draft (individual)
Last updated 2017-09-27
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Operations and Management Area Work Group                        S. Rich
Internet-Draft                                             Cisco Systems
Intended status: Informational
Expires: March 27, 2017                                          T. Dahm
                                                       27 September 2017

             MUD Lifecyle: A Network Operator's Perspective


   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

   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 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
   ( 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
Show full document text