Manufacturer Usage Description Specification
Extracted elements (32)
A two-tier extensibility framework is used: coarse-grained versioning via the mud-version integer in the MUD URL (this memo specifies version 1), and fine-grained extensions that add nodes to the mud container, which must be IETF-standardized, declared in the 'extensions' list, and ignored by unaware implementations. This avoids negotiation complexity while enabling evolution.
MUD file contents are recommendations, not directives: 'no matter what the manufacturer specifies in a MUD file, these are not directives, but suggestions.' Local network administrators ultimately decide how and whether to instantiate them, preserving operational autonomy.
YANG (RFC 7950) is used as the data modeling language and JSON (RFC 8259/7951) as the serialization format because YANG provides accurate models for network devices and JSON provides compactness and readability relative to XML; other formats may be adopted in later versions.
A MUD file is limited to the serialization of only ietf-access-control-list (RFC 8519), ietf-mud, and ietf-acldns schemas; only match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-on-icmp ACL features are assumed, and only 'accept' or 'drop' forwarding actions SHOULD be included. MUD managers MAY interpret 'reject' as 'drop' and SHOULD ignore other actions.
A MUD file MUST be signed using DER-encoded CMS as an opaque binary object; intermediate certificates SHOULD be included to make successful verification more likely.
firmware-rev and software-rev MUST NOT be populated in a MUD file if the device can be upgraded but the MUD URL cannot be updated, such as when MUD URLs are embedded in 802.1AR certificates.
In the case where both DHCPv4 and DHCPv6 MUD URL options are emitted by a client, the same URL MUST be used in both.
MUD extensions MUST NOT be used in a MUD file without being declared in the 'extensions' leaf-list; implementations MUST ignore any node they do not understand.
MUD files MUST NOT contain a src-dnsname in an ACL associated with from-device-policy, nor a dst-dnsname associated with to-device-policy, since access is scoped to the specific Thing.
MUD managers MUST validate the TLS certificate of the MUD file server using the rules in RFC 2818, Section 3.1, when fetching MUD URLs.
MUD URLs MUST use the 'https' scheme in order to establish the MUD file server's identity and assure integrity of the MUD file.
Prior to processing a MUD file, the MUD manager MUST retrieve and validate the CMS signature; the signing certificate MUST have the digitalSignature(0) bit set in the Key Usage Extension; if validation fails or the chain of trust to a known anchor cannot be established, the MUD manager MUST cease processing until an administrator approves.
Publishers of MUD files SHOULD avoid use of IP addresses and MUST NOT include ACL model nodes outside those described in this specification or its extensions; a MUD manager SHOULD NOT automatically implement a MUD file that contains IP addresses with local significance.
The cache-validity field MUST NOT be more than 168 hours for any supported Thing; it is RECOMMENDED to be no less than 24 hours, and SHOULD be no shorter than any HTTP caching directive period.
The direction-initiated match node MUST only be applied to TCP; when 'from-device' is set, packets transmitted toward the Thing MUST be dropped unless the Thing first initiated the TCP connection.
Release of a MUD URL by a Thing reveals the device type and may aid in identifying individuals when combined with other information; implementors should apply data minimization techniques and consider using TEAP to share MUD URLs only with authorized network components.
The ietf-acldns YANG module augments the ACL model match nodes for both IPv4 and IPv6 to add src-dnsname and dst-dnsname leaves (type inet:host), allowing domain names to be used directly as match criteria in access control entries.
The ietf-mud YANG module augments the ACL model with MUD-specific match abstractions: manufacturer (host matching authority of another Thing's MUD URL), same-manufacturer (null-valued, matches same authority), model (matches entire MUD URL), local-networks (null-valued, expands to local addresses), controller (URI naming a registered class), and my-controller (null-valued, matches configured controllers for this MUD URL).
The MUD architecture consists of three components: the Thing emitting a MUD URL, the MUD manager that fetches and processes the MUD file, and the MUD file server (a web server run by or on behalf of the manufacturer). The MUD manager translates policy abstractions to device-specific network configuration and updates network elements.
The MUD file is a YANG-based JSON document (RFC 7951 serialization) containing two root objects: a 'mud' container with file metadata and access policy references, and an 'acls' container from RFC 8519. The mud container includes mud-version, mud-url, last-update, cache-validity, is-supported, systeminfo, and optional mfg-name, model-name, firmware-rev, software-rev, documentation, extensions, from-device-policy, and to-device-policy.
RFC 8520 assigns LLDP subtype 1 under IANA OUI 00 00 5E in the IANA LLDP TLV Subtype Registry for the MUDstring field.
RFC 8520 registers DHCPv4 option code 161 (OPTION_MUD_URL_V4) and DHCPv6 option code 112 (OPTION_MUD_URL_V6) in the respective IANA option registries.
RFC 8520 registers MUD well-known URNs for standard controller classes, including URNs for DNS and NTP services, in a new IANA registry, allowing manufacturers to reference standardized services without specifying IP addresses.
RFC 8520 registers the media type 'application/mud+json' for MUD files and defines the MUD Extensions Registry, where each extension name (1–40 characters) must be registered with IANA and described in an RFC.
RFC 8520 registers two YANG modules in the IANA 'YANG Module Names' registry: ietf-mud (URN: urn:ietf:params:xml:ns:yang:ietf-mud) and ietf-acldns (URN: urn:ietf:params:xml:ns:yang:ietf-acldns).
A rogue CA may sign a certificate with the same subject name as the MUDsigner field, enabling a substitute MUD file; mitigations include flagging signer changes as exceptions and requiring administrator approval when the MUD file changes, with MUD managers MUST maintaining a cache of trusted CAs.
A Thing may lie about its identity by emitting a forged MUD URL via DHCP or LLDP, gaining unauthorized network access; implementations SHOULD be configurable to disallow additive access for devices presenting MUD URLs not emitted in a secure (certificate-bound) fashion, and MUST NOT mix devices with the same MUD URL derived from both strong and weak authentication.
If domain name ownership changes, a new domain owner may serve MUD files that MUD managers consider valid; MUD managers SHOULD cache server certificates and check for domain ownership changes (e.g., via name server or WHOIS changes) when a new certificate is retrieved.
The DHCPv4 MUD URL option uses code OPTION_MUD_URL_V4 (161), a one-octet length field, and a MUDstring (an https URL optionally followed by a space and reserved future bytes); the entire option MUST NOT exceed 255 octets.
The DHCPv6 MUD URL option uses code OPTION_MUD_URL_V6 (112), a two-octet option-length, and the MUDstring payload; format follows the standard DHCPv6 option structure with 2-octet code and 2-octet length fields.
The LLDP MUD extension uses a vendor-specific TLV (type 127) with OUI 00 00 5E (IANA), subtype 1 (IANA-assigned for MUD), and a MUDstring of 1–255 octets; the 7-bit TLV Type, 9-bit length, 3-octet OUI, 1-octet subtype, and variable MUDstring are encoded in sequence.
The X.509 MUD URL extension (id-pe-mud-url, OID id-pe 25) is a non-critical certificate extension containing an IA5String MUD URL; a companion id-pe-mudsigner extension (id-pe 30) carries the subject Name of the MUD file signing certificate, enabling binding of the file to a specific signer.