IOT Operations E. Lear Internet-Draft Cisco Systems, Inc. Updates: 8520 (if approved) 11 August 2026 Intended status: Standards Track Expires: 12 February 2027 Some MUD Extensions and Clarifications draft-lear-iotops-mudextras-latest Abstract 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. This memo updates RFC 8520. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://elear.github.io/draft-lear-mudextras/draft-lear-iotops- mudextras.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lear-iotops-mudextras/. Discussion of this document takes place on the IOT Operations Working Group mailing list (mailto:iotops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/iotops/. Subscribe at https://www.ietf.org/mailman/listinfo/iotops/. Source for this draft and an issue tracker can be found at https://github.com/elear/draft-lear-mudextras. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Conventions and Definitions 2. Clarifications 2.1. ACLs in MUD 2.1.1. Discussion 2.2. Handling of Multicast 2.3. Handling of Broadcasts 3. Extensions 3.1. Multicast Across Segments Extension 3.1.1. Discussion 3.2. Directed Broadcasts 3.2.1. The directed-broadcasts extension 3.2.2. Example 3.2.3. Discussion 3.3. Inclusion of icons 3.3.1. The icons extension 3.3.2. Example 4. Security Considerations 5. IANA Considerations 5.1. MUD Extension and YANG Namespace Registrations 6. References 6.1. Normative References 6.2. Informative References Appendix A. Acknowledgments Appendix B. Changes Author's Address 1. Introduction Manufacturer Usage Descriptions (MUD) [RFC8520] provide a means to describe device network behavior. Operational experience has introduced a new use of MUD: to more clearly describe device network behavior and network access requirements in order for it to properly function. The MUD file itself can serve as a contract that is written by the device manufacturer and enacted and observed by both OT and IT services and organizations. This means that the descriptions should be as complete and accurate as possible. Experience has shown that certain cases require clarification, and in some cases new extensions. For example: * 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 [RFC8519], 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. * Some devices make use of multicast, and in some of those cases, multicast packets may need to be sent or received across network segments. 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. This memo updates [RFC8520] by clarifying that IP-based ACLs MAY be used in MUD files, and by providing a MUD extension to describe directed broadcasts. It also clarifies that all devices are assumed to both send and receive broadcasts, and provides an example of how to use ACLs to describe multicast behavior. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Clarifications 2.1. ACLs in MUD As mentioned above, RFC 8519 specifies a YANG schema for ACLs. [RFC8520] discourages the use of IP addresses in MUD files. However, that advice was too broad. As we will discuss below, IP addresses are permitted in MUD files since they are based on [RFC8519]. However, they should only be used when the IP addresses are globally unique and are coordinated by the publisher of the MUD file. For example, the following is a valid MUD file that describes a device that is allowed to connect to a cloud service. { "ietf-mud:mud": { "mud-version": 1, "mud-url": "https://iot.example.com/modelX.json", "mud-signature": "https://iot.example.com/modelX.p7s", "last-update": "2022-01-05T13:30:31+00:00", "cache-validity": 48, "is-supported": true, "systeminfo": "Sample IoT device", "mfg-name": "Example, Inc.", "documentation": "https://iot.example.com/doc/modelX", "model-name": "modelX", "from-device-policy": { "access-lists": { "access-list": [ { "name": "sample-ipv4-acl" } ] } }, "to-device-policy": { "access-lists": { "access-list": [ { "name": "sample-ipv4-acl" } ] } } }, "ietf-access-control-list:acls": { "acl": [ { "name": "sample-ipv4-acl", "type": "ipv4-acl-type", "aces": { "ace": [ { "name": "permit-https-to-my-cloud-service", "matches": { "ipv4": { "protocol": 6, "destination-ipv4-network": "10.1.2.3/32" }, "tcp": { "destination-port": { "operator": "eq", "port": 443 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 1: Example ACL in MUD file 2.1.1. Discussion Some device manufacturers will use hardcoded IP addresses to bootstrap functions like the domain name system (DNS). In other cases, DNS isn't used at all. These addresses may refer directly to an anycast function such as a public DNS resolver, or to specific servers operated by the device manufacturer. This memo does not pass judgment on these uses, but rather describes the use so that it can be properly documented. 2.2. Handling of Multicast [RFC8520] does not specify how multicast should be handled. Use of multicast for discovery is relatively common. However, support for multicast beyond the local link is by no means guaranteed. Because multicast addresses are not typically tied to a local network topology, MUD files MAY contain multicast addresses in ACLs. When used, specific multicast addresses SHOULD be used. The following ACL fragment can be used by either the to-device or from-device ACL to permit packets to or from a specific multicast address: { "ace": [ { "name": "permit-multicast", "matches": { "ipv4": { "protocol": 17, "destination-ipv4-network": "224.8.5.1/32" } }, "actions": { "forwarding": "accept" } } ] } Figure 2: Example multicast ACE that can be used in a MUD file While this example demonstrates how to describe how a device sends or receives multicast traffic, it doesn't specify whether those packets may need to be transmitted across network segments. That will be discussed in the next section. 2.3. Handling of Broadcasts [RFC8520] does not specify how broadcast should be handled. Devices make use of broadcast for many reasons, including discovery, fast failover, expedited processing, and so on. We distinguish transmission and receipt of broadcasts: it is RECOMMENDED that MUD managers enable the ability of devices to transmit broadcasts. It is also possible to specify a broadcast address in an ACL. Receipt of broadcasts SHOULD be governed by who is sending them; device should receive broadcasts only from authorized sources, as specified in the MUD file. This is particularly important for constrained devices that may be overwhelmed by unneeded and unwanted broadcast (or any other) traffic. 3. Extensions 3.1. Multicast Across Segments Extension Whether a manufacturer intends for multicast packets to go beyond a local segment is something that can be expressed in the MUD file with the following extension: Extension name: multicast-across-segments This extension does not extend the MUD YANG model; its presence in a MUD file simply signals to the network operator that multicast may be required to traverse network segments. This will be useful when multicast is intended for purposes *other* than local discovery. On its own it doesn't specify which multicast groups the device may need to join. An ACL that permits multicast traffic is still required. 3.1.1. Discussion Examples might include the following: * A controller that requires consistent behavior across a set of devices in a timely fashion. It may use multicast to communicate with all of them. * A smoke detector that is part of a building-wide alarm system. If one smoke detector detects smoke, it may multicast a message to audible and visual alarms throughout the building to sound the alarm. * On-hold music is a historical example, where music is distributed via multicast. * Local gaming, where participants may span multiple network segments. Note that operational issues associated with multicast, such as the scope of a multicast group, are outside the scope of this document. Here we are merely documenting the device's behavior and network requirements. 3.2. 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 topological 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. 3.2.1. The directed-broadcasts extension The YANG tree for this extension is as follows: module: ietf-mud-directed-broadcasts augment /mud:mud: +--rw directed-broadcasts +--rw inbound? boolean +--rw outbound? boolean Figure 3: YANG tree for directed-broadcasts extension The YANG model for this extension is as follows: module ietf-mud-directed-broadcasts { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-directed-broadcasts"; prefix mud-directed-broadcasts; import ietf-mud { prefix mud; reference "RFC 8520: Manufacturer Usage Description (MUD)"; } organization "IETF IOTOPS Working Group"; contact "WG Web: 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 2026-07-05 { 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; } } Figure 4: YANG model for directed-broadcasts extension 3.2.2. Example The following is an example of a MUD file that indicates that the device uses directed broadcasts in both directions. { "ietf-mud:mud": { "mud-version": 1, "mud-url": "https://iot.example.com/modelX.json", "mud-signature": "https://iot.example.com/modelX.p7s", "last-update": "2022-01-05T13:30:31+00:00", "extensions": [ "directed-broadcasts" ], "cache-validity": 48, "is-supported": true, "systeminfo": "Sample IoT device", "mfg-name": "Example, Inc.", "documentation": "https://iot.example.com/doc/modelX", "model-name": "modelX", "mud-directed-broadcasts:directed-broadcasts": { "inbound": true, "outbound": true } } } Figure 5: 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. 3.2.3. Discussion Directed broadcasts have well known security issues (see [RFC2644]). 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. 3.3. Inclusion of icons Sometimes it is useful to visualize a network of devices. Having an icon associated with a device can improve readability. Icons SHOULD follow the guidance given in [PWG5100.13], with the exception that the HTTP schema MUST NOT be used. Extension name: icons The icons extension adds an array of icon URLs to the MUD file. Each entry MAY use any URI scheme accepted by inet:uri, including the data URI scheme defined by [RFC2397]. A publisher that uses this extension MUST include icons in the MUD extensions leaf-list. 3.3.1. The icons extension The YANG tree for this extension is as follows: module: ietf-mud-icons augment /mud:mud: +--rw icons* inet:uri Figure 6: YANG tree for icons extension The YANG model for this extension is as follows: module ietf-mud-icons { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-icons"; prefix mud-icons; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-mud { prefix mud; reference "RFC 8520: Manufacturer Usage Description (MUD)"; } organization "IETF IOTOPS Working Group"; contact "WG Web: WG List: Author: Eliot Lear "; description "This module defines a MUD extension for device icons. 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."; revision 2026-08-11 { description "Initial revision."; reference "RFC XXXX: Some MUD Extensions and Clarifications"; } augment "/mud:mud" { description "Augments the MUD model with icon URLs."; leaf-list icons { type inet:uri; description "URLs for icons representing the device. The data URI scheme is permitted."; } } } Figure 7: YANG model for icons extension 3.3.2. Example { "ietf-mud:mud": { "mud-version": 1, "mud-url": "https://iot.example.com/modelX.json", "mud-signature": "https://iot.example.com/modelX.p7s", "last-update": "2026-08-11T13:30:31+00:00", "extensions": [ "icons" ], "cache-validity": 48, "is-supported": true, "systeminfo": "Sample IoT device", "mfg-name": "Example, Inc.", "model-name": "modelX", "ietf-mud-icons:icons": [ "https://example.com/icons/modelX-48x48.png", "https://example.com/icons/modelX-128x128.png", "https://example.com/icons/modelX-512x512.png" ] } } Figure 8: Example MUD file with icons extension Here we have three icons, each with a different size. For brevity purposes, this example uses the https URI scheme, but the data URI scheme defined by [RFC2397] could also have been used. 4. Security Considerations The YANG modules specified in this document define schemas for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] 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 [RFC8520] apply. In addition, see Section 3.2.3 for a discussion of the security implications of directed broadcasts. 5. IANA Considerations 5.1. MUD Extension and YANG Namespace Registrations IANA is requested to make the following additions to the "Manufacturer Usage Description (MUD) Extensions" registry: Name: directed-broadcasts Reference: [RFCXXXX] (this document) Name: multicast-across-segments Reference: [RFCXXXX] (this document) Name: icons Reference: [RFCXXXX] (this document) The following YANG namespaces are registered: * Namespace: urn:ietf:params:xml:ns:yang:ietf-mud-directed- broadcasts * Prefix: mud-directed-broadcasts * Namespace: urn:ietf:params:xml:ns:yang:ietf-mud-icons * Prefix: mud-icons 6. References 6.1. Normative References [PWG5100.13] Sweet, M., McDonald, I., and P. Zehler, "IPP: Job and Printer Extensions -- Set 3 (JPS3)", PWG 5100.13, July 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, . 6.2. Informative References [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, August 1999, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Appendix A. Acknowledgments Thanks to Michael Richardson for the reorganized text, and to Michael Sweet for his input on how to include icons. Appendix B. Changes * 02: - Reorganization based on MCR PR. - Repair ACL name. - Separate out sending and receiving of broadcasts. - Add the icons extension and an example with three icon sizes. * 01: Cleaned up text, added updates header, revisited multicast. * 00: Initial revision. Author's Address Eliot Lear Cisco Systems, Inc. Email: lear@cisco.com