Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: OPSAWG

RFC 8520

Manufacturer Usage Description Specification

Pages: 60
Proposed STD
Errata
Part 3 of 4 – Pages 30 to 46
First   Prev   Next

Top   ToC   Page 30   prevText
9.  MUD File Example

   This example contains two access lists that are intended to provide
   outbound access to a cloud service on TCP port 443.

   {
     "ietf-mud:mud": {
       "mud-version": 1,
       "mud-url": "https://lighting.example.com/lightbulb2000",
       "last-update": "2019-01-28T11:20:51+01:00",
       "cache-validity": 48,
       "is-supported": true,
       "systeminfo": "The BMS Example Light Bulb",
       "from-device-policy": {
         "access-lists": {
           "access-list": [
             {
               "name": "mud-76100-v6fr"
             }
           ]
         }
       },
       "to-device-policy": {
         "access-lists": {
           "access-list": [
             {
               "name": "mud-76100-v6to"
             }
           ]
         }
       }
     },
     "ietf-access-control-list:acls": {
       "acl": [
         {
           "name": "mud-76100-v6to",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "cl0-todev",
                 "matches": {
                   "ipv6": {
                     "ietf-acldns:src-dnsname": "test.example.com",
                     "protocol": 6
                   },
                   "tcp": {
                     "ietf-mud:direction-initiated": "from-device",
Top   ToC   Page 31
                     "source-port": {
                       "operator": "eq",
                       "port": 443
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "accept"
                 }
               }
             ]
           }
         },
         {
           "name": "mud-76100-v6fr",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "cl0-frdev",
                 "matches": {
                   "ipv6": {
                     "ietf-acldns:dst-dnsname": "test.example.com",
                     "protocol": 6
                   },
                   "tcp": {
                     "ietf-mud:direction-initiated": "from-device",
                     "destination-port": {
                       "operator": "eq",
                       "port": 443
                     }
                   }
                 },
                 "actions": {
                   "forwarding": "accept"
                 }
               }
             ]
           }
         }
       ]
     }
   }

   In this example, two policies are declared: one from the Thing and
   the other to the Thing.  Each policy names an access list that
   applies to the Thing and one that applies from the Thing.  Within
   each access list, access is permitted to packets flowing to or from
Top   ToC   Page 32
   the Thing that can be mapped to the domain name of
   "service.bms.example.com".  For each access list, the enforcement
   point should expect that the Thing initiated the connection.

10.  The MUD URL DHCP Option

   The IPv4 MUD URL client option has the following format:

     +------+-----+------------------------------
     | code | len |  MUDstring
     +------+-----+------------------------------

   Code OPTION_MUD_URL_V4 (161) has been assigned by IANA.  len is a
   single octet that indicates the length of the MUD string in octets.
   The MUDstring is defined as follows:

    MUDstring = mudurl [ " " reserved ]
    mudurl = URI; a URL [RFC3986] that uses the "https" scheme [RFC7230]
    reserved = 1*( OCTET ) ; from [RFC5234]

   The entire option MUST NOT exceed 255 octets.  If a space follows the
   MUD URL, a reserved string that will be defined in future
   specifications follows.  MUD managers that do not understand this
   field MUST ignore it.

   The IPv6 MUD URL client option has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         OPTION_MUD_URL_V6     |        option-length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            MUDstring                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OPTION_MUD_URL_V6 (112).

   option-length contains the length of the MUDstring, as defined above,
   in octets.

   The intent of this option is to provide both a new Thing classifier
   to the network as well as some recommended configuration to the
   routers that implement the policy.  However, it is entirely the
   purview of the network system as managed by the network administrator
   to decide what to do with this information.  The key function of this
Top   ToC   Page 33
   option is simply to identify the type of Thing to the network in a
   structured way such that the policy can be easily found with existing
   toolsets.

10.1.  Client Behavior

   A DHCPv4 client MAY emit a DHCPv4 option, and a DHCPv6 client MAY
   emit a DHCPv6 option.  These options are singletons, as specified in
   [RFC7227].  Because clients are intended to have at most one MUD URL
   associated with them, they may emit at most one MUD URL option via
   DHCPv4 and one MUD URL option via DHCPv6.  In the case where both v4
   and v6 DHCP options are emitted, the same URL MUST be used.

10.2.  Server Behavior

   A DHCP server may ignore these options or take action based on
   receipt of these options.  When a server consumes this option, it
   will either forward the URL and relevant client information (such as
   the gateway address or giaddr and requested IP address, and lease
   length) to a network management system or retrieve the usage
   description itself by resolving the URL.

   DHCP servers may implement MUD functionality themselves or they may
   pass along appropriate information to a network management system or
   MUD manager.  A DHCP server that does process the MUD URL MUST adhere
   to the process specified in [RFC2818] and [RFC5280] to validate the
   TLS certificate of the web server hosting the MUD file.  Those
   servers will retrieve the file, process it, and create and install
   the necessary configuration on the relevant network element.  Servers
   SHOULD monitor the gateway for state changes on a given interface.  A
   DHCP server that does not provide MUD functionality and has forwarded
   a MUD URL to a MUD manager MUST notify the MUD manager of any
   corresponding change to the DHCP state of the client (such as
   expiration or explicit release of a network address lease).

   Should the DHCP server fail, in the case when it implements the MUD
   manager functionality, any backup mechanisms SHOULD include the MUD
   state, and the server SHOULD resolve the status of clients upon its
   restart, similar to what it would do absent MUD manager
   functionality.  In the case where the DHCP server forwards
   information to the MUD manager, the MUD manager will either make use
   of redundant DHCP servers for information or clear state based on
   other network information, such as monitoring port status on a switch
   via SNMP, Radius accounting, or similar mechanisms.

10.3.  Relay Requirements

   There are no additional requirements for relays.
Top   ToC   Page 34
11.  The Manufacturer Usage Description (MUD) URL X.509 Extension

   This section defines an X.509 non-critical certificate extension that
   contains a single URL that points to an online Manufacturer Usage
   Description concerning the certificate subject.  The URI must be
   represented as described in Section 7.4 of [RFC5280].

   Any Internationalized Resource Identifiers (IRIs) MUST be mapped to
   URIs as specified in Section 3.1 of [RFC3987] before they are placed
   in the certificate extension.

   The semantics of the URL are defined Section 6 of this document.

   The choice of id-pe is based on guidance found in Section 4.2.2 of
   [RFC5280]:

         These extensions may be used to direct applications to on-line
         information about the issuer or the subject.

   The MUD URL is precisely that: online information about the
   particular subject.

   In addition, a separate new extension is defined as id-pe-mudsigner.
   This contains the subject field of the signing certificate of the MUD
   file.  Processing of this field is specified in Section 13.2.

   The purpose of this signature is to make a claim that the MUD file
   found on the server is valid for a given device, independent of any
   other factors.  There are several security considerations below in
   Section 16.

   A new content-type id-ct-mud is also defined.  While signatures are
   detached today, should a MUD file be transmitted as part of a
   Cryptographic Message Syntax (CMS) message, this content-type SHOULD
   be used.
Top   ToC   Page 35
   This module imports from [RFC5912] and [RFC6268].  The new extension
   is identified as follows:

   <CODE BEGINS>
      MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
                   internet(1) security(5) mechanisms(5) pkix(7)
                   id-mod(0) id-mod-mudURLExtn2016(88) }
       DEFINITIONS IMPLICIT TAGS ::= BEGIN

       -- EXPORTS ALL --

      IMPORTS

        -- RFC 5912
        EXTENSION
        FROM PKIX-CommonTypes-2009
             { iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) pkix(7) id-mod(0)
               id-mod-pkixCommon-02(57) }

        -- RFC 5912
        id-ct
        FROM PKIXCRMF-2009
             { iso(1) identified-organization(3) dod(6) internet(1)
               security(5)  mechanisms(5) pkix(7) id-mod(0)
               id-mod-crmf2005-02(55) }

        -- RFC 6268
        CONTENT-TYPE
        FROM CryptographicMessageSyntax-2010
          { iso(1) member-body(2) us(840) rsadsi(113549)
            pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

        -- RFC 5912
        id-pe, Name
        FROM PKIX1Explicit-2009
              { iso(1) identified-organization(3) dod(6) internet(1)
                security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-pkix1-explicit-02(51) } ;

       --
       -- Certificate Extensions
       --

       MUDCertExtensions EXTENSION ::=
          { ext-MUDURL | ext-MUDsigner, ... }

       ext-MUDURL EXTENSION ::=
Top   ToC   Page 36
          { SYNTAX MUDURLSyntax IDENTIFIED BY id-pe-mud-url }

       id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 }

       MUDURLSyntax ::= IA5String

       ext-MUDsigner EXTENSION ::=
          { SYNTAX MUDsignerSyntax IDENTIFIED BY id-pe-mudsigner }

       id-pe-mudsigner OBJECT IDENTIFIER ::= { id-pe 30 }

       MUDsignerSyntax ::= Name

       --
       -- CMS Content Types
       --

       MUDContentTypes CONTENT-TYPE ::=
          { ct-mud, ... }

        ct-mud CONTENT-TYPE ::=
          { -- directly include the content
            IDENTIFIED BY id-ct-mudtype }
          -- The binary data that is in the form
          -- "application/mud+json" is directly encoded as the
          -- signed data.  No additional ASN.1 encoding is added.

       id-ct-mudtype OBJECT IDENTIFIER ::= { id-ct 41 }

       END
   <CODE ENDS>

   While this extension can appear in either an 802.AR manufacturer
   certificate (IDevID) or a deployment certificate (LDevID), of course
   it is not guaranteed in either, nor is it guaranteed to be carried
   over.  It is RECOMMENDED that MUD manager implementations maintain a
   table that maps a Thing to its MUD URL based on IDevIDs.

12.  The Manufacturer Usage Description LLDP Extension

   The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop,
   vendor-neutral link-layer protocol used by end host network Things
   for advertising their identity, capabilities, and neighbors on an
   IEEE 802 local area network.  Its Type-Length-Value (TLV) design
   allows for "vendor-specific" extensions to be defined.  IANA has a
   registered IEEE 802 organizationally unique identifier (OUI) defined
   as documented in [RFC7042].  The MUD LLDP extension uses a subtype
   defined in this document to carry the MUD URL.
Top   ToC   Page 37
   The LLDP vendor-specific frame has the following format:

   +--------+--------+----------+---------+--------------
   |TLV Type|  len   |   OUI    |subtype  | MUDString
   |  =127  |        |= 00 00 5E|  = 1    |
   |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
   +--------+--------+----------+---------+--------------

   where:

   o  TLV Type = 127 indicates a vendor-specific TLV

   o  len = indicates the TLV string length

   o  OUI = 00 00 5E is the organizationally unique identifier of IANA

   o  subtype = 1 (as assigned by IANA for the MUDstring)

   o  MUDstring = the length MUST NOT exceed 255 octets

   The intent of this extension is to provide both a new Thing
   classifier to the network as well as some recommended configuration
   to the routers that implement the policy.  However, it is entirely
   the purview of the network system as managed by the network
   administrator to decide what to do with this information.  The key
   function of this extension is simply to identify the type of Thing to
   the network in a structured way such that the policy can be easily
   found with existing toolsets.

   Hosts, routers, or other network elements that implement this option
   are intended to have at most one MUD URL associated with them, so
   they may transmit at most one MUD URL value.

   Hosts, routers, or other network elements that implement this option
   may ignore these options or take action based on receipt of these
   options.  For example, they may fill in information in the respective
   extensions of the LLDP Management Information Base (MIB).  LLDP
   operates in a one-way direction.  Link Layer Discovery Protocol Data
   Units (LLDPDUs) are not exchanged as information requests by one
   Thing and responses sent by another Thing.  The other Things do not
   acknowledge LLDP information received from a Thing.  No specific
   network behavior is guaranteed.  When a Thing consumes this
   extension, it may either forward the URL and relevant remote Thing
   information to a MUD manager or retrieve the usage description by
   resolving the URL in accordance with normal HTTP semantics.
Top   ToC   Page 38
13.  The Creating and Processing of Signed MUD Files

   Because MUD files contain information that may be used to configure
   network access lists, they are sensitive.  To ensure that they have
   not been tampered with, it is important that they be signed.  We make
   use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
   this purpose.

13.1.  Creating a MUD File Signature

   A MUD file MUST be signed using CMS as an opaque binary object.  In
   order to make successful verification more likely, intermediate
   certificates SHOULD be included.  The signature is stored at the
   location specified in the MUD file.  Signatures are transferred using
   content-type "application/pkcs7-signature".

   For example:

   % openssl cms -sign -signer mancertfile -inkey mankey \
                 -in mudfile -binary -outform DER -binary \
                 -certfile intermediatecert -out mudfile.p7s

   Note: A MUD file may need to be re-signed if the signature expires.

13.2.  Verifying a MUD File Signature

   Prior to processing the rest of a MUD file, the MUD manager MUST
   retrieve the MUD signature file by retrieving the value of "mud-
   signature" and validating the signature across the MUD file.  The Key
   Usage Extension in the signing certificate MUST be present and have
   the bit digitalSignature(0) set.  When the id-pe-mudsigner extension
   is present in a device's X.509 certificate, the MUD signature file
   MUST have been generated by a certificate whose subject matches the
   contents of that id-pe-mudsigner extension.  If these conditions are
   not met, or if it cannot validate the chain of trust to a known trust
   anchor, the MUD manager MUST cease processing the MUD file until an
   administrator has given approval.

   The purpose of the signature on the file is to assign accountability
   to an entity, whose reputation can be used to guide administrators on
   whether or not to accept a given MUD file.  It is already common
   place to check web reputation on the location of a server on which a
   file resides.  While it is likely that the manufacturer will be the
   signer of the file, this is not strictly necessary, and it may not be
   desirable.  For one thing, in some environments, integrators may
   install their own certificates.  For another, what is more important
   is the accountability of the recommendation, and not just the
   relationship between the Thing and the file.
Top   ToC   Page 39
   An example:

   % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile

   Note the additional step of verifying the common trust root.

14.  Extensibility

   One of our design goals is to see that MUD files are able to be
   understood by as broad a cross-section of systems as is possible.
   Coupled with the fact that we have also chosen to leverage existing
   mechanisms, we are left with no ability to negotiate extensions and a
   limited desire for those extensions in any event.  As such, a two-
   tier extensibility framework is employed, as follows:

   1.  At a coarse grain, a protocol version is included in a MUD URL.
       This memo specifies MUD version 1.  Any and all changes are
       entertained when this version is bumped.  Transition approaches
       between versions would be a matter for discussion in future
       versions.

   2.  At a finer grain, only extensions that would not incur additional
       risk to the Thing are permitted.  Specifically, adding nodes to
       the mud container is permitted with the understanding that such
       additions will be ignored by unaware implementations.  Any such
       extensions SHALL be standardized through the IETF process and
       MUST be named in the "extensions" list.  MUD managers MUST ignore
       YANG nodes they do not understand and SHOULD create an exception
       to be resolved by an administrator, so as to avoid any policy
       inconsistencies.

15.  Deployment Considerations

   Because MUD consists of a number of architectural building blocks, it
   is possible to assemble different deployment scenarios.  One key
   aspect is where to place policy enforcement.  In order to protect the
   Thing from other Things within a local deployment, policy can be
   enforced on the nearest switch or access point.  In order to limit
   unwanted traffic within a network, it may also be advisable to
   enforce policy as close to the Internet as possible.  In some
   circumstances, policy enforcement may not be available at the closest
   hop.  At that point, the risk of lateral infection (infection of
   devices that reside near one another) is increased to the number of
   Things that are able to communicate without protection.

   A caution about some of the classes: admission of a Thing into the
   "manufacturer" and "same-manufacturer" class may have impact on the
   access of other Things.  Put another way, the admission may grow the
Top   ToC   Page 40
   access list on switches connected to other Things, depending on how
   access is managed.  Some care should be given on managing that access
   list growth.  Alternative methods such as additional network
   segmentation can be used to keep that growth within reason.

   Because as of this writing MUD is a new concept, one can expect a
   great many devices to not have implemented it.  It remains a local
   deployment decision as to whether a device that is first connected
   should be allowed broad or limited access.  Furthermore, as mentioned
   in the introduction, a deployment may choose to ignore a MUD policy
   in its entirety and simply take into account the MUD URL as a
   classifier to be used as part of a local policy decision.

   Finally, please see directly below information regarding device
   lifetimes and use of domain names.

16.  Security Considerations

   Based on how a MUD URL is emitted, a Thing may be able to lie about
   what it is, thus gaining additional network access.  This can happen
   in a number of ways when a device emits a MUD URL using DHCP or LLDP,
   such as being inappropriately admitted to a class such as
   "same-manufacturer", being given access to a device such as
   "my-controller", or being permitted access to an Internet resource,
   where such access would otherwise be disallowed.  Whether that is the
   case will depend on the deployment.  Implementations SHOULD be
   configurable to disallow additive access for devices using MUD URLs
   that are not emitted in a secure fashion such as in a certificate.
   Similarly, implementations SHOULD NOT grant elevated permissions
   (beyond those of devices presenting no MUD policy) to devices that do
   not strongly bind their identity to their L2/L3 transmissions.  When
   insecure methods are used by the MUD manager, the classes SHOULD NOT
   contain devices that use both insecure and secure methods, in order
   to prevent privilege escalation attacks, and MUST NOT contain devices
   with the same MUD URL that are derived from both strong and weak
   authentication methods.

   Devices may forge source (L2/L3) information.  Deployments should
   apply appropriate protections to bind communications to the
   authentication that has taken place.  For 802.1X authentication, IEEE
   802.1AE (MACsec) [IEEE8021AE] is one means by which this may happen.
   A similar approach can be used with 802.11i (Wi-Fi Protected Access 2
   (WPA2)) [IEEE80211i].  Other means are available with other lower-
   layer technologies.  Implementations using session-oriented access
   that is not cryptographically bound should take care to remove state
   when any form of break in the session is detected.
Top   ToC   Page 41
   A rogue certification authority (CA) may sign a certificate that
   contains the same subject name as is listed in the MUDsigner field in
   the manufacturer certificate, thus seemingly permitting a substitute
   MUD file for a device.  There are two mitigations available: First,
   if the signer changes, this may be flagged as an exception by the MUD
   manager.  Second, if the MUD file also changes, the MUD manager
   SHOULD seek administrator approval (it should do this in any case).
   In all circumstances, the MUD manager MUST maintain a cache of
   trusted CAs for this purpose.  When such a rogue is discovered, it
   SHOULD be removed.

   Additional mitigations are described below.

   When certificates are not present, Things claiming to be of a certain
   manufacturer SHOULD NOT be included in that manufacturer grouping
   without additional validation of some form.  This will be relevant
   when the MUD manager makes use of primitives such as "manufacturer"
   for the purpose of accessing Things of a particular type.  Similarly,
   network management systems may be able to fingerprint the Thing.  In
   such cases, the MUD URL can act as a classifier that can be proven or
   disproven.  Fingerprinting may have other advantages as well: when
   802.1AR certificates are used, because they themselves cannot change,
   fingerprinting offers the opportunity to add artifacts to the MUD
   string in the form of the reserved field discussed in Section 10.
   The meaning of such artifacts is left as future work.

   MUD managers SHOULD NOT accept a usage description for a Thing with
   the same Media Access Control (MAC) address that has indicated a
   change of the URL authority without some additional validation (such
   as review by a network administrator).  New Things that present some
   form of unauthenticated MUD URL SHOULD be validated by some external
   means when they would be given increased network access.

   It may be possible for a rogue manufacturer to inappropriately
   exercise the MUD file parser, in order to exploit a vulnerability.
   There are two recommended approaches to address this threat.  The
   first is to validate that the signer of the MUD file is known to and
   trusted by the MUD manager.  The second is to have a system do a
   primary scan of the file to ensure that it is both parseable and
   believable at some level.  MUD files will likely be relatively small,
   to start with.  The number of ACEs used by any given Thing should be
   relatively small as well.  It may also be useful to limit retrieval
   of MUD URLs to only those sites that are known to have decent web or
   domain reputations.

   Use of a URL necessitates the use of domain names.  If a domain name
   changes ownership, the new owner of that domain may be able to
   provide MUD files that MUD managers would consider valid.  MUD
Top   ToC   Page 42
   managers SHOULD cache certificates used by the MUD file server.  When
   a new certificate is retrieved for whatever reason, the MUD manager
   should check to see if ownership of the domain has changed.  A fair
   programmatic approximation of this is when the name servers for the
   domain have changed.  If the actual MUD file has changed, the MUD
   manager MAY check the WHOIS database to see if registration ownership
   of a domain has changed.  If a change has occurred, or if for some
   reason it is not possible to determine whether ownership has changed,
   further review may be warranted.  Note, this remediation does not
   take into account the case of a Thing that was produced long ago and
   only recently fielded, or the case where a new MUD manager has been
   installed.

   The release of a MUD URL by a Thing reveals what the Thing is and
   provides an attacker with guidance on what vulnerabilities may be
   present.

   While the MUD URL itself is not intended to be unique to a specific
   Thing, the release of the URL may aid an observer in identifying
   individuals when combined with other information.  This is a privacy
   consideration.

   In addressing both of these concerns, implementors should take into
   account what other information they are advertising through
   mechanisms such as Multicast DNS (mDNS) [RFC6872]; how a Thing might
   otherwise be identified, perhaps through how it behaves when it is
   connected to the network; and whether a Thing is intended to be used
   by individuals or carry personal identifying information, and then
   apply appropriate data minimization techniques.  One approach is to
   make use of TEAP [RFC7170] as the means to share information with
   authorized components in the network.  Network elements may also
   assist in limiting access to the MUD URL through the use of
   mechanisms such as DHCPv6-Shield [RFC7610].

   There is the risk of the MUD manager itself being spied on to
   determine what things are connected to the network.  To address this
   risk, MUD managers may choose to make use of TLS proxies that they
   trust that would aggregate other information.

   Please note that the security considerations mentioned in Section 3.7
   of [RFC8407] are not applicable in this case because the YANG
   serialization is not intended to be accessed via NETCONF.  However,
   for those who try to instantiate this model in a network element via
   the Network Configuration Protocol (NETCONF), all objects in each
   model in this document exhibit similar security characteristics as
   [RFC8519].  The basic purpose of MUD is to configure access, so by
   its very nature, it can be disruptive if used by unauthorized
   parties.
Top   ToC   Page 43
17.  IANA Considerations

17.1.  YANG Module Registrations

   The following YANG modules have been registered in the "YANG Module
   Names" registry:

      Name: ietf-mud
      URN: urn:ietf:params:xml:ns:yang:ietf-mud
      Prefix: ietf-mud
      Registrant contact: The IESG
      Reference: RFC 8520

      Name: ietf-acldns
      URI: urn:ietf:params:xml:ns:yang:ietf-acldns
      Prefix: ietf-acldns
      Registrant contact: The IESG
      Reference: RFC 8520

17.2.  URI Registrations

   IANA has added the following entries to the "IETF XML registry":

   URI: urn:ietf:params:xml:ns:yang:ietf-acldns
   Registrant Contact: The IESG.
   XML: N/A.  The requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-mud
   Registrant Contact: The IESG.
   XML: N/A.  The requested URI is an XML namespace.

17.3.  DHCPv4 and DHCPv6 Options

   The IANA has allocated OPTION_MUD_URL_V4 (161) in the "Dynamic Host
   Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP)
   Parameters" registry, and OPTION_MUD_URL_V6 (112) in the "Dynamic
   Host Configuration Protocol for IPv6 (DHCPv6)" registry, as described
   in Section 10.

17.4.  PKIX Extensions

   IANA has made the following assignments for:

   o  The MUDURLExtnModule-2016 ASN.1 module (88) in the "SMI Security
      for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

   o  id-pe-mud-url object identifier (25) from the "SMI Security for
      PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1).
Top   ToC   Page 44
   o  id-pe-mudsigner object identifier (30) from the "SMI Security for
      PKIX Certificate Extension" registry.

   o  id-ct-mudtype object identifier (41) from the "SMI Security for
      S/MIME CMS Content Type" registry.

   o  The use of these values is specified in Section 11.

17.5.  Media Type Registration for MUD Files

   The following media type is defined for the transfer of MUD files:

   o  Type name: application

   o  Subtype name: mud+json

   o  Required parameters: N/A

   o  Optional parameters: N/A

   o  Encoding considerations: 8bit; "application/mud+json" values are
      represented as JSON objects; UTF-8 encoding MUST be employed
      [RFC3629].

   o  Security considerations: See Security Considerations of RFC 8520
      and Section 12 of [RFC8259].

   o  Interoperability considerations: N/A

   o  Published specification: RFC 8520

   o  Applications that use this media type: MUD managers as specified
      by RFC 8520.

   o  Fragment identifier considerations: N/A

   o  Additional information:
      Magic number(s): N/A
      File extension(s): N/A
      Macintosh file type code(s): N/A

   o  Person & email address to contact for further information:
      Eliot Lear <lear@cisco.com>, Ralph Droms <rdroms@gmail.com>,
      Dan Romascanu <dromasca@gmail.com>

   o  Intended usage: COMMON

   o  Restrictions on usage: none
Top   ToC   Page 45
   o  Author:
      Eliot Lear <lear@cisco.com>
      Ralph Droms <rdroms@gmail.com>
      Dan Romascanu <dromasca@gmail.com>

   o  Change controller: IESG

   o  Provisional registration? (standards tree only): No.

17.6.  IANA LLDP TLV Subtype Registry

   IANA has created a new registry titled "IANA Link Layer Discovery
   Protocol (LLDP) TLV Subtypes" under "IEEE 802 Numbers".  The policy
   for this registry is Expert Review [RFC8126].  The maximum number of
   entries in the registry is 256.

   IANA has populated the initial registry as follows:

   LLDP subtype value: 1 (All the other 255 values are initially marked
   as "Unassigned".)

   Description: the Manufacturer Usage Description (MUD) Uniform
   Resource Locator (URL)

   Reference: RFC 8520

17.7.  The MUD Well-Known Universal Resource Name (URNs)

   The following parameter registry has been added in accordance with
   [RFC3553].

      Registry name: MUD Well-Known Universal Resource Name (URN)
      Specification: RFC 8520
      Repository: https://www.iana.org/assignments/mud
      Index value:  Encoded identically to a TCP/UDP port service
                    name, as specified in Section 5.1 of [RFC6335]

   The following entries have been added to the "MUD Well-Known
   Universal Resource Name (URN)" registry:

   "urn:ietf:params:mud:dns" refers to the service specified by
   [RFC1123].  "urn:ietf:params:mud:ntp" refers to the service specified
   by [RFC5905].
Top   ToC   Page 46
17.8.  Extensions Registry

   The IANA has established a registry of extensions as follows:

      Registry name: MUD Extensions
      Registry policy: Standards Action
      Reference: RFC 8520
      Extension name: UTF-8-encoded string, not to exceed 40 characters.

   Each extension MUST follow the rules specified in this specification.
   As is usual, the IANA issues early allocations in accordance with
   [RFC7120].



(page 46 continued on part 4)

Next Section