RFC 8520
Manufacturer Usage Description Specification
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",
"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
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
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.
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.
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 ::=
{ 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.
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.
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.
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
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.
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
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.
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 852017.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).
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
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].
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)
