Editing MUD

Manufacturer Usage Description (MUD) IETF Specification (MUDS) is a
framework under RFC development that aims to automate Internet access control rules for IoT devices . The intention is to specify normal and abnormal usage of a device outside the device and allow an installation to derive security controls (Access list ) and apply it. For example the posrts and servers which should be allowed to do remote service or change configuration or initiate firmware update of the device
==IETF [https://tools.ietf.org/html/draft-lear-mud-framework-00 Abstract]==

   A key presumption of the Internet architecture has been that devices
   are general purpose computers.  By constraining the set of devices
   that connect to the Internet to non-general purpose devices, we can
   introduce a set of network capabilities that provides an additional
   layer of protection to those devices.  One such capability is the
   Manufacturer Usage Description (MUD).  This work builds on many
   existing network capabilities so as to be easily deployable by all
   involved.  The focus of this work is primarily, but not exclusively,
   in the realm of security; and again primarily, but not exclusively,
   relating to smart objects.


==[http://ieeexplore.ieee.org/document/7496625/?part=1 IEEE]==
Through the simplifying assumption that a Thing has a single use or a small number of intended uses, it is possible to reduce the threat surface of the device by constraining the communication paths needed for those uses. This is accomplished using a small number of extensions to IEEE 802.1AR, a YANG model, DHCP, and IEEE 802.1AB, where a manufacturer maintains an online presence that is used inter alia to retrieve recommended configuration for a given device. This recommended configuration is used to create an access control list on a network device
==CISCO Proposal==
MUD allows a Universal Resource Identifier (URI) for getting  ad device configuration. That URI points to a  web site, either the manufacturer or the system integrator deploying devices  from which the network security controller pulls the XML file<ref>YANG models [RFC6020] </ref> or JSON  declaring the device’s appropriate usage. That usage file can then be merged with the existing network security policy and enforced. 

==MUD overview==
A schematic form an implementation at Indiana University illustrates.
[[File:IoTSecurity MUD Arvind.png| link=https://figshare.com/articles/Manufacturer_Usage_Description_Specification_Implementation/5552923]]
@@ Line 1: / Line 1: @@
-Manufacturer Usage Description (MUD) is a draft IETF Specification. MUDS is a
+Manufacturer Usage Description (MUD) IETF Specification (MUDS) is a
-framework under RFC development that aims to automate Internet access control rules for IoT devices . The intention is to specify normal and abnormal usage of a device outside the device and allow an installation to derive security controls (Access list ) and apply it. For example the ports and servers which should be allowed to do remote service or change configuration or initiate firmware update of the device. It is also intended to provide methods for devices no longer supported by the manufacturer.
+framework under RFC development that aims to automate Internet access control rules for IoT devices . The intention is to specify normal and abnormal usage of a device outside the device and allow an installation to derive security controls (Access list ) and apply it. For example the posrts and servers which should be allowed to do remote service or change configuration or initiate firmware update of the device
 ==IETF [https://tools.ietf.org/html/draft-lear-mud-framework-00 Abstract]==
@@ Line 23: / Line 23: @@
 A schematic form an implementation at Indiana University illustrates.
 [[File:IoTSecurity MUD Arvind.png| link=https://figshare.com/articles/Manufacturer_Usage_Description_Specification_Implementation/5552923]]
-ASCII art from [https://tools.ietf.org/html/draft-lear-mud-framework-00 IETF]
-    .........................................
-    .                      ____________     .           __________
-    .                     |  Network   |    .          |          |
-    .                     | Management |----->get URI->|   MFG    |
-    .                     |  System    |    .          | Web Site |
-    .  End system network |____________|<--MUD file<--<|__________|
-    .                             .         .
-    .                             .         .
-    . _______                 _________     .
-    .|       |               | router  |    .
-    .| Thing |---->MUD URI-->|   or    |    .
-    .|_______|               | switch  |    .
-    .                        |_________|    .
-    .........................................
-                        Figure 1: MUD Architecture
-== Use cases from Standard proposals==
-===Light Bulb===
-   A light bulb is intended to light a room.  It may be remotely
-   controlled through the network; and it may make use of a rendezvous
-   service of some form that an app on smart phone accesses.  What we
-   can say about that light bulb, then, is that all other network access
-   is unwanted.  It will not contact a news service, nor speak to the
-   refrigerator, and it has no need of a printer or other devices.  It
-   has no Facebook friends.  Therefore, an access list applied to it
-   that states that it will only connect to the single rendezvous
-   service will not impede the light bulb in performing its function,
-   while at the same time allowing the network to provide both it and
-   other devices an additional layer of protection.
-===Advanced Policies===
-The manufacturer may specify either specific hosts or certain classes.  An example of a class might be
-   "devices of a specified manufacturer type", where the manufacturer
-   type itself is indicated simply by the authority of the MUD-URI.
-   Another example might to allow or disallow local access.  Just like
-   other policies, these may be combined.  For example:
-      Allow access to host controller.example.com with QoS AF11
-      Allow access to devices of the same manufacturer
-      Allow access to and from controllers who need to speak COAP
-      Allow access to local DNS/DHCP
-      Deny all other access
-==Also See==
-*[https://tools.ietf.org/html/draft-ietf-opsawg-mud-05 IETF]
-*[http://www.ieee802.org/1/files/public/docs2017/new-lear-iot-mud-0217-v01.pdf IEEE]
-[[Category:IoTStack]][[Category:Security]]