RFC 8520 - Manufacturer Usage Description Specification

Abstract

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.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8520.

Copyright Notice

Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Contents

• 1. Introduction
  • 1.1. What MUD Doesn't Do
  • 1.2. A Simple Example
  • 1.3. Terminology
  • 1.4. Determining Intended Use
  • 1.5. Finding a Policy: The MUD URL
  • 1.6. Processing of the MUD URL
  • 1.7. Types of Policies
  • 1.8. The Manufacturer Usage Description Architecture
  • 1.9. Order of Operations
• 2. The MUD Model and Semantic Meaning
  • 2.1. The IETF-MUD YANG Module
• 3. MUD Model Definitions for the Root "mud" Container
  • 3.1. mud-version
  • 3.2. MUD URL
  • 3.3. to-device-policy and from-device-policy Containers
  • 3.4. last-update
  • 3.5. cache-validity
  • 3.6. is-supported
  • 3.7. systeminfo
  • 3.8. mfg-name, software-rev, model-name, and firmware-rev
  • 3.9. extensions
• 4. Augmentation to the ACL Model
  • 4.1. manufacturer
  • 4.2. same-manufacturer
  • 4.3. documentation
  • 4.4. model
  • 4.5. local-networks
  • 4.6. controller
  • 4.7. my-controller
  • 4.8. direction-initiated
• 5. Processing of the MUD File
• 6. What Does a MUD URL Look Like?
• 7. The MUD YANG Model
• 8. The Domain Name Extension to the ACL Model
  • 8.1. src-dnsname
  • 8.2. dst-dnsname
  • 8.3. The ietf-acldns Model
• 9. MUD File Example
• 10. The MUD URL DHCP Option
  • 10.1. Client Behavior
  • 10.2. Server Behavior
  • 10.3. Relay Requirements
• 11. The Manufacturer Usage Description (MUD) URL X.509 Extension
• 12. The Manufacturer Usage Description LLDP Extension
• 13. The Creating and Processing of Signed MUD Files
  • 13.1. Creating a MUD File Signature
  • 13.2. Verifying a MUD File Signature
• 14. Extensibility
• 15. Deployment Considerations
• 16. Security Considerations
• 17. IANA Considerations
  • 17.1. YANG Module Registrations
  • 17.2. URI Registrations
  • 17.3. DHCPv4 and DHCPv6 Options
  • 17.4. PKIX Extensions
  • 17.5. Media Type Registration for MUD Files
  • 17.6. IANA LLDP TLV Subtype Registry
  • 17.7. The MUD Well-Known Universal Resource Name (URNs)
  • 17.8. Extensions Registry
• 18. References
  • 18.1. Normative References
  • 18.2. Informative References
• Appendix A. Default MUD Nodes
• Appendix B. A Sample Extension: DETNET-indicator
• Acknowledgments
• Authors' Addresses