]> Cisco Systems, Inc.

lear@cisco.com

Operations and Management IOT Operations MUD IOT Manufacturer Usage Descriptions (MUD) provide a means to describe device network behavior. This memo clarifies some aspects that may improve both usability and interoperability. Some examples include how to handle IP-based access-lists, broadcasts and multicasts of various forms, and QoS. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IOT Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Manufacturer Usage Descriptions (MUD) provide a means to describe device network behavior. Since its initial standardization, there have been a number of questions and clarifications that have arisen. The goal of a MUD file is to accurately describe the network behavior of a device in a way that is independent of the network topology. Primarily the topological concern is local; that is, within an enterprise or home network. Certain cases make that challenging:

• Some devices make use of directed broadcasts, which are not supported in all networks. When they are, there is a need to understand each and every network segment to which such a device may be attached.
• Some devices hardcode certain IP addresses. MUD itself augments , which specifies an access control list (ACL) schema in YANG. Within that context, therefore, it should be possible to employ ACLs that match that schema.

While one could argue whether or not either of these approaches should be used by device manufacturers, the reality is that they are used. Therefore, MUD should provide a means to describe them.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Clarifications

ACLs in MUD As mentioned above, RFC 8519 specifies a YANG schema for ACLs. Nothing in the specification prevents the use of ACLs to describe the network behavior of devices in a MUD file. For example, the following is a valid MUD file that describes a device that is allowed to connect to a cloud service.

Example ACL in MUD file

A few cautions about using native IP addresses in MUD files:

• They should only ever refer to globally unique addresses that are coordinated by the device manufacturer.
• Address changes will necessitate a new MUD file, which must be signed retrieved by mud managers.

Discussion Some device manufacturers will use hardcoded IP addresses to bootstrap functions like the domain name system (DNS). The use of anycast servers is not uncommon. Others simply do not want to introduce a dependency on DNS.

Directed Broadcasts Some devices make use of directed broadcasts to communicate with devices either on the same subnet or on remote networks. Directed broadcasts require local toplogical knowledge, specifically the subnet mask of the network to which the device is attached. That information cannot be used across deployments, and so is inappropriate for MUD files. To address this, we specify a MUD extension here that indicates that the device uses directed broadcasts. Extension name: directed-broadcasts A new object is added to the MUD file, called directed-broadcasts. It contains two boolean elements:

• inbound: indicates whether the device must receive directed broadcasts.
• outbound: indicates whether the device must send directed broadcasts.

The directed-broadcast extension The YANG tree for this extension is as follows:

YANG tree for directed-broadcasts extension

The YANG model for this extension is as follows:

YANG model for directed-broadcasts extension WG List: Author: Eliot Lear "; description " Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. This module defines a MUD extension for directed broadcasts."; revision 2024-06-01 { description "Initial revision."; reference "RFC XXXX: Some MUD Extensions and Clarifications"; } grouping directed-broadcasts-group { description "Indicates whether the device uses directed broadcasts."; container directed-broadcasts { description "Indicates whether the device uses directed broadcasts."; leaf inbound { type boolean; description "Indicates whether the device must receive directed broadcasts."; } leaf outbound { type boolean; description "Indicates whether the device must send directed broadcasts."; } } } augment "/mud:mud" { description "Augments the MUD model with directed-broadcasts."; uses directed-broadcasts-group; } } ]]>

Example The following is an example of a MUD file that indicates that the device uses directed broadcasts in both directions.

Example MUD file with directed-broadcasts extension

Note that in all likelihood there would also be ACLs in the MUD file, but they are omitted here for brevity.

Discussion Directed broadcasts have well known security issues (see ). However, they are used in circumstances where a limited amount of configuration is considered acceptable, and where other mechanisms such as multicast cannot be expected to be available in all deployments. The purpose of this extension is not to encourage the use of directed broadcasts, but rather to provide a means to describe them in MUD files when they are used.

Handling of Multicast does not specify how multicast should be handled. The reason was that MUD primarily specified abstractions, and multicast is anything but. Use of multicast for discovery is relatively common. However, support for multicast beyond the local link is by no means guaranteed. Unlike directed broadcasts, however, multicast addresses are not typically tied to a local network topology. For this reason, MUD files MAY contain multicast addresses in ACLs. To facilitate a better understanding of how a device behaves, an extension is provided to indicate whether a device requires multicast routing. Extension name: multicast-routing Note that no new YANG model is specified for this extension, as it is simply a signal that the device requires multicast routing.

Handling of Broadcasts does not specify how broadcast should be handled. Devices may make use of broadcast for many reasons, including discovery, fast failover, expedited processing, and so on. There are a sufficient number of reasons to use broadcasts, that simply identifying that a device uses broadcasts seems as useful as saying that a device uses IP. Broadcasts can still be filtered in several ways:

• For outbound use, they MAY be listed in ACLs.
• For inbound use, the existing abstractions in may be used to authorize the source of the broadcast traffic.

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. MUD files are intended to be retrieved from a web server, and so the security considerations of apply. In addition, see for a discussion of the security implications of directed broadcasts.

IANA Considerations

Directed Broadcasts MUD Extension IANA is requested to make the following additions to the "Manufacturer Usage Description (MUD) Extensions" registry: The following YANG namespace is registered for the directed-broadcasts MUD extension:

• Namespace: urn:ietf:params:xml:ns:yang:ietf-mud-directed-broadcasts
• Prefix: mud-directed-broadcasts

References Normative References This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536.

Acknowledgments TODO acknowledge.

Changes

• Initial revision.