Internet Engineering Task Force (IETF) E. Lear
Request for Comments: 8520 Cisco Systems
Category: Standards Track R. Droms
ISSN: 2070-1721 Google
D. Romascanu
March 2019
Internet Engineering Task Force (IETF) E. Lear
Request for Comments: 8520 Cisco Systems
Category: Standards Track R. Droms
ISSN: 2070-1721 Google
D. Romascanu
March 2019
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.
本备忘录为制造商使用说明（MUD）指定了基于组件的体系结构。MUD的目标是为终端设备提供一种方法，向网络发出信号，说明它们需要何种接入和网络功能才能正常工作。最初的重点是访问控制。以后的工作可以深入研究其他方面。
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.
此备忘录指定了两个模块：IPv4和IPv6 DHCP选项、链路层发现协议（LLDP）TLV、URL、X.509证书扩展以及签名和验证说明的方法。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What MUD Doesn't Do . . . . . . . . . . . . . . . . . . . 5
1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Determining Intended Use . . . . . . . . . . . . . . . . 6
1.5. Finding a Policy: The MUD URL . . . . . . . . . . . . . . 7
1.6. Processing of the MUD URL . . . . . . . . . . . . . . . . 8
1.7. Types of Policies . . . . . . . . . . . . . . . . . . . . 8
1.8. The Manufacturer Usage Description Architecture . . . . . 10
1.9. Order of Operations . . . . . . . . . . . . . . . . . . . 12
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 12
2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 14
3. MUD Model Definitions for the Root "mud" Container . . . . . 15
3.1. mud-version . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. MUD URL . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3. to-device-policy and from-device-policy Containers . . . 16
3.4. last-update . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. cache-validity . . . . . . . . . . . . . . . . . . . . . 16
3.6. is-supported . . . . . . . . . . . . . . . . . . . . . . 16
3.7. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 16
3.8. mfg-name, software-rev, model-name, and firmware-rev . . 17
3.9. extensions . . . . . . . . . . . . . . . . . . . . . . . 17
4. Augmentation to the ACL Model . . . . . . . . . . . . . . . . 17
4.1. manufacturer . . . . . . . . . . . . . . . . . . . . . . 17
4.2. same-manufacturer . . . . . . . . . . . . . . . . . . . . 17
4.3. documentation . . . . . . . . . . . . . . . . . . . . . . 18
4.4. model . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. local-networks . . . . . . . . . . . . . . . . . . . . . 18
4.6. controller . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. my-controller . . . . . . . . . . . . . . . . . . . . . . 19
4.8. direction-initiated . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What MUD Doesn't Do . . . . . . . . . . . . . . . . . . . 5
1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Determining Intended Use . . . . . . . . . . . . . . . . 6
1.5. Finding a Policy: The MUD URL . . . . . . . . . . . . . . 7
1.6. Processing of the MUD URL . . . . . . . . . . . . . . . . 8
1.7. Types of Policies . . . . . . . . . . . . . . . . . . . . 8
1.8. The Manufacturer Usage Description Architecture . . . . . 10
1.9. Order of Operations . . . . . . . . . . . . . . . . . . . 12
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 12
2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 14
3. MUD Model Definitions for the Root "mud" Container . . . . . 15
3.1. mud-version . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. MUD URL . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3. to-device-policy and from-device-policy Containers . . . 16
3.4. last-update . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. cache-validity . . . . . . . . . . . . . . . . . . . . . 16
3.6. is-supported . . . . . . . . . . . . . . . . . . . . . . 16
3.7. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 16
3.8. mfg-name, software-rev, model-name, and firmware-rev . . 17
3.9. extensions . . . . . . . . . . . . . . . . . . . . . . . 17
4. Augmentation to the ACL Model . . . . . . . . . . . . . . . . 17
4.1. manufacturer . . . . . . . . . . . . . . . . . . . . . . 17
4.2. same-manufacturer . . . . . . . . . . . . . . . . . . . . 17
4.3. documentation . . . . . . . . . . . . . . . . . . . . . . 18
4.4. model . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. local-networks . . . . . . . . . . . . . . . . . . . . . 18
4.6. controller . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. my-controller . . . . . . . . . . . . . . . . . . . . . . 19
4.8. direction-initiated . . . . . . . . . . . . . . . . . . . 19
5. Processing of the MUD File . . . . . . . . . . . . . . . . . 19
6. What Does a MUD URL Look Like? . . . . . . . . . . . . . . . 19
7. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 20
8. The Domain Name Extension to the ACL Model . . . . . . . . . 26
8.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. dst-dnsname . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 28
9. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 30
10. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 32
10.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 33
10.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 33
10.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 33
11. The Manufacturer Usage Description (MUD) URL X.509 Extension 34
12. The Manufacturer Usage Description LLDP Extension . . . . . . 36
13. The Creating and Processing of Signed MUD Files . . . . . . . 38
13.1. Creating a MUD File Signature . . . . . . . . . . . . . 38
13.2. Verifying a MUD File Signature . . . . . . . . . . . . . 38
14. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 39
15. Deployment Considerations . . . . . . . . . . . . . . . . . . 39
16. Security Considerations . . . . . . . . . . . . . . . . . . . 40
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
17.1. YANG Module Registrations . . . . . . . . . . . . . . . 43
17.2. URI Registrations . . . . . . . . . . . . . . . . . . . 43
17.3. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 43
17.4. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 43
17.5. Media Type Registration for MUD Files . . . . . . . . . 44
17.6. IANA LLDP TLV Subtype Registry . . . . . . . . . . . . . 45
17.7. The MUD Well-Known Universal Resource Name (URNs) . . . 45
17.8. Extensions Registry . . . . . . . . . . . . . . . . . . 46
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
18.1. Normative References . . . . . . . . . . . . . . . . . . 46
18.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Default MUD Nodes . . . . . . . . . . . . . . . . . 52
Appendix B. A Sample Extension: DETNET-indicator . . . . . . . . 56
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
5. Processing of the MUD File . . . . . . . . . . . . . . . . . 19
6. What Does a MUD URL Look Like? . . . . . . . . . . . . . . . 19
7. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 20
8. The Domain Name Extension to the ACL Model . . . . . . . . . 26
8.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. dst-dnsname . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 28
9. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 30
10. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 32
10.1. Client Behavior . . . . . . . . . . . . . . . . . . . . 33
10.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 33
10.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 33
11. The Manufacturer Usage Description (MUD) URL X.509 Extension 34
12. The Manufacturer Usage Description LLDP Extension . . . . . . 36
13. The Creating and Processing of Signed MUD Files . . . . . . . 38
13.1. Creating a MUD File Signature . . . . . . . . . . . . . 38
13.2. Verifying a MUD File Signature . . . . . . . . . . . . . 38
14. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 39
15. Deployment Considerations . . . . . . . . . . . . . . . . . . 39
16. Security Considerations . . . . . . . . . . . . . . . . . . . 40
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
17.1. YANG Module Registrations . . . . . . . . . . . . . . . 43
17.2. URI Registrations . . . . . . . . . . . . . . . . . . . 43
17.3. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 43
17.4. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 43
17.5. Media Type Registration for MUD Files . . . . . . . . . 44
17.6. IANA LLDP TLV Subtype Registry . . . . . . . . . . . . . 45
17.7. The MUD Well-Known Universal Resource Name (URNs) . . . 45
17.8. Extensions Registry . . . . . . . . . . . . . . . . . . 46
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
18.1. Normative References . . . . . . . . . . . . . . . . . . 46
18.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Default MUD Nodes . . . . . . . . . . . . . . . . . 52
Appendix B. A Sample Extension: DETNET-indicator . . . . . . . . 56
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
The Internet has largely been constructed for general purpose computers, those devices that may be used for a purpose that is specified by those who own the device. In [RFC1984], it was presumed that an end device would be most capable of protecting itself. This made sense when the typical device was a workstation or a mainframe, and it continues to make sense for general purpose computing devices today, including laptops, smart phones, and tablets.
互联网在很大程度上是为通用计算机而构建的，这些设备可以用于拥有该设备的人指定的目的。在[RFC1984]中，假定终端设备最能保护自身。当典型的设备是工作站或大型机时，这一点是有意义的，对于今天的通用计算设备，包括笔记本电脑、智能手机和平板电脑，这一点仍然是有意义的。
[RFC7452] discusses design patterns for, and poses questions about, smart objects. Let us then posit a group of objects that are specifically not intended to be used for general purpose computing tasks. These devices, which this memo refers to as Things, have a specific purpose. By definition, therefore, all other uses are not intended. If a small number of communication patterns follows from those small number of uses, the combination of these two statements can be restated as a Manufacturer Usage Description (MUD) that can be applied at various points within a network. MUD primarily addresses threats to the device rather than the device as a threat. In some circumstances, however, MUD may offer some protection in the latter case, depending on how the MUD URL is communicated and how devices and their communications are authenticated.
[RFC7452]讨论智能对象的设计模式，并提出有关智能对象的问题。然后，让我们假设一组对象，这些对象不是专门用于通用计算任务的。这些设备，本备忘录称之为物品，有特定的用途。因此，根据定义，并非所有其他用途。如果这些少量的使用导致了少量的通信模式，那么这两个语句的组合可以重新表述为制造商使用说明（MUD），可以应用于网络中的各个点。MUD主要解决对设备的威胁，而不是将设备视为威胁。然而，在某些情况下，在后一种情况下，MUD可能提供一些保护，这取决于MUD URL的通信方式以及设备及其通信的身份验证方式。
We use the notion of "manufacturer" loosely in this context to refer to the entity or organization that will state how a device is intended to be used. For example, in the context of a light bulb, this might indeed be the light bulb manufacturer. In the context of a smarter device that has a built in Linux stack, it might be an integrator of that device. The key points are that the device itself is assumed to serve a limited purpose, and that there exists an organization in the supply chain of that device that will take responsibility for informing the network about that purpose.
在本文中，我们松散地使用“制造商”的概念来指代将说明如何使用设备的实体或组织。例如，在灯泡的上下文中，这可能确实是灯泡制造商。在具有内置Linux堆栈的更智能设备的上下文中，它可能是该设备的集成器。关键点在于，假设设备本身的用途有限，并且该设备的供应链中存在一个组织，负责将该用途告知网络。
The intent of MUD is to provide the following:
泥浆的目的是提供以下各项：
o Substantially reduce the threat surface on a device to those communications intended by the manufacturer.
o 将设备上的威胁面大幅降低至制造商预期的通信。
o Provide a means to scale network policies to the ever-increasing number of types of devices in the network.
o 提供一种方法，根据网络中不断增加的设备类型扩展网络策略。
o Provide a means to address at least some vulnerabilities in a way that is faster than the time it might take to update systems. This will be particularly true for systems that are no longer supported.
o 提供一种方法，以比更新系统所需时间更快的方式解决至少一些漏洞。对于不再受支持的系统来说，这一点尤其重要。
o Keep the cost of implementation of such a system to the bare minimum.
o 将实施此类系统的成本降至最低。
o Provide a means of extensibility for manufacturers to express other device capabilities or requirements.
o 为制造商提供一种可扩展性手段，以表达其他设备功能或需求。
MUD consists of three architectural building blocks:
MUD由三个建筑构件组成：
o A URL that can be used to locate a description;
o 可用于定位描述的URL；
o The description itself, including how it is interpreted; and
o 描述本身，包括如何解释；和
o A means for local network management systems to retrieve the description.
o 本地网络管理系统检索描述的一种方法。
MUD is most effective when the network is able to identify in some way the remote endpoints that Things will talk to.
当网络能够以某种方式识别事物将与之通信的远程端点时，MUD最为有效。
In this specification, we describe each of these building blocks and how they are intended to be used together. However, they may also be used separately, independent of this specification, by local deployments for their own purposes.
在本规范中，我们描述了这些构建块中的每一个，以及它们打算如何一起使用。但是，本地部署也可以独立于本规范单独使用它们。
MUD is not intended to address network authorization of general purpose computers, as their manufacturers cannot envision a specific communication pattern to describe. In addition, even those devices that have a single or small number of uses might have very broad communication patterns. MUD on its own is not for them either.
MUD并不是为了解决通用计算机的网络授权问题，因为它们的制造商无法设想一种特定的通信模式来描述。此外，即使那些具有单一或少量用途的设备也可能具有非常广泛的通信模式。泥浆本身也不适合他们。
Although MUD can provide network administrators with some additional protection when device vulnerabilities exist, it will never replace the need for manufacturers to patch vulnerabilities.
尽管当存在设备漏洞时，MUD可以为网络管理员提供一些额外的保护，但它永远无法取代制造商修补漏洞的需要。
Finally, no matter what the manufacturer specifies in a MUD file, these are not directives, but suggestions. How they are instantiated locally will depend on many factors and will be ultimately up to the local network administrator, who must decide what is appropriate in a given circumstances.
最后，无论制造商在MUD文件中指定了什么，这些都不是指令，而是建议。如何在本地实例化它们将取决于许多因素，并最终取决于本地网络管理员，他们必须决定在给定情况下什么是合适的。
A light bulb is intended to light a room. It may be remotely controlled through the network, and it may make use of a rendezvous service (which could be accessed by an application on a smart phone). What we can say about that light bulb, then, is that all other network access is unwanted. It will not contact a news service, nor
灯泡是用来照亮房间的。它可以通过网络远程控制，还可以利用会合服务（可以通过智能手机上的应用程序访问）。那么，我们能说的是，所有其他网络接入都是不需要的。它不会联系新闻服务机构，也不会
speak to the refrigerator, and it has no need of a printer or other devices. It has no social networking friends. Therefore, applying an access list to it that states it will only connect to the single rendezvous service will not impede performing its function; at the same time, this will allow the network to provide the light bulb and other devices an additional layer of protection.
与冰箱交谈，冰箱不需要打印机或其他设备。它没有社交网络朋友。因此，对其应用一个访问列表，声明其将仅连接到单一会合服务，不会妨碍其功能的执行；同时，这将允许网络为灯泡和其他设备提供额外的保护层。
MUD: Manufacturer Usage Description.
泥浆：制造商使用说明。
MUD file: a file containing YANG-based JSON that describes a Thing and associated suggested specific network behavior.
MUD文件：一个包含基于YANG的JSON的文件，它描述了一个事物和相关的特定网络行为。
MUD file server: a web server that hosts a MUD file.
MUD文件服务器：承载MUD文件的web服务器。
MUD manager: the system that requests and receives the MUD file from the MUD server. After it has processed a MUD file, it may direct changes to relevant network elements.
MUD管理器：从MUD服务器请求和接收MUD文件的系统。在处理MUD文件后，它可能会指示对相关网络元素进行更改。
MUD controller: a synonym that has been used in the past for MUD manager.
泥浆控制器：过去用于泥浆管理器的同义词。
MUD URL: a URL that can be used by the MUD manager to receive the MUD file.
MUD URL：MUD管理器可用于接收MUD文件的URL。
Thing: the device emitting a MUD URL.
事情：设备发出一个泥浆URL。
Manufacturer: the entity that configures the Thing to emit the MUD URL and the one who asserts a recommendation in a MUD file. The manufacturer might not always be the entity that constructs a Thing. It could, for instance, be a systems integrator, or even a component provider.
制造商：将对象配置为发出MUD URL的实体，以及在MUD文件中声明建议的实体。制造商可能并不总是构造一件东西的实体。例如，它可以是一个系统集成商，甚至是一个组件提供商。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The notion of intended use is in itself not new. Network administrators apply access lists every day to allow for only such use. This notion of white listing was well described by Chapman and Zwicky in [FW95]. Profiling systems that make use of heuristics to identify types of systems have existed for years as well.
预期用途的概念本身并不新鲜。网络管理员每天应用访问列表，以便仅允许此类使用。Chapman和Zwicky在[FW95]中很好地描述了白名单的概念。利用启发式识别系统类型的评测系统也已经存在多年了。
A Thing could just as easily tell the network what sort of access it requires without going into what sort of system it is. This would, in effect, be the converse of [RFC7488]. In seeking a general solution, however, we assume that a device will implement functionality necessary to fulfill its limited purpose. This is basic economic constraint. Unless the network would refuse access to such a device, its developers would have no reason to provide the network any information. To date, such an assertion has held true.
一个东西可以很容易地告诉网络它需要什么样的访问，而不需要进入什么样的系统。实际上，这与[RFC7488]相反。然而，在寻求通用解决方案时，我们假设设备将实现实现其有限用途所需的功能。这是基本的经济约束。除非网络拒绝访问此类设备，否则其开发者将没有理由向网络提供任何信息。到目前为止，这种说法是正确的。
Our work begins with the device emitting a Universal Resource Locator (URL) [RFC3986]. This URL serves both to classify the device type and to provide a means to locate a policy file.
我们的工作从设备发出通用资源定位器（URL）[RFC3986]开始。此URL用于对设备类型进行分类，并提供查找策略文件的方法。
MUD URLs MUST use the "https" scheme [RFC7230].
MUD URL必须使用“https”方案[RFC7230]。
In this memo, three means are defined to emit the MUD URL, as follows:
在本备忘录中，定义了三种方式来发出MUD URL，如下所示：
o A DHCP option [RFC2131] [RFC8415] that the DHCP client uses to inform the DHCP server. The DHCP server may take further actions, such as acting as the MUD manager or passing the MUD URL along to the MUD manager.
o DHCP客户端用于通知DHCP服务器的DHCP选项[RFC2131][RFC8415]。DHCP服务器可以采取进一步的操作，例如充当MUD管理器或将MUD URL传递给MUD管理器。
o An X.509 constraint. The IEEE has developed IEEE 802.1AR [IEEE8021AR] to provide a certificate-based approach to communicate device characteristics, which itself relies on [RFC5280]. The MUD URL extension is non-critical, as required by IEEE 802.1AR. Various means may be used to communicate that certificate, including the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170].
o X.509约束。IEEE已经开发了IEEE 802.1AR[IEEE8021AR]，以提供一种基于证书的方法来通信设备特性，该方法本身依赖于[RFC5280]。根据IEEE 802.1AR的要求，MUD URL扩展是非关键的。可以使用各种方式来传送该证书，包括隧道可扩展认证协议（TEAP）[RFC7170]。
o Finally, a Link Layer Discovery Protocol (LLDP) frame is defined [IEEE8021AB].
o 最后，定义了链路层发现协议（LLDP）帧[IEEE8021AB]。
It is possible that there may be other means for a MUD URL to be learned by a network. For instance, some devices may already be fielded or have very limited ability to communicate a MUD URL, and yet they can be identified through some means, such as a serial number or a public key. In these cases, manufacturers may be able to map those identifiers to particular MUD URLs (or even the files themselves). Similarly, there may be alternative resolution mechanisms available for situations where Internet connectivity is limited or does not exist. Such mechanisms are not described in this memo, but they are possible. Implementors are encouraged to allow for the flexibility of how MUD URLs may be learned.
有可能存在网络学习MUD URL的其他方法。例如，一些设备可能已经部署或通信MUD URL的能力非常有限，但它们可以通过一些方式识别，例如序列号或公钥。在这些情况下，制造商可以将这些标识符映射到特定的MUD URL（甚至文件本身）。类似地，在互联网连接受限或不存在的情况下，可能会有替代的解决机制。本备忘录中未描述此类机制，但它们是可能的。鼓励实现者考虑如何灵活地学习MUD URL。
MUD managers that are able to do so SHOULD retrieve MUD URLs and signature files as per [RFC7230], using the GET method [RFC7231]. They MUST validate the certificate using the rules in [RFC2818], Section 3.1.
能够这样做的MUD管理器应该使用GET方法[RFC7231]按照[RFC7230]检索MUD URL和签名文件。他们必须使用[RFC2818]第3.1节中的规则验证证书。
Requests for MUD URLs SHOULD include an "Accept" header field ([RFC7231], Section 5.3.2) containing "application/mud+json", an "Accept-Language" header field ([RFC7231], Section 5.3.5), and a "User-Agent" header field ([RFC7231], Section 5.5.3).
MUD URL请求应包括包含“应用程序/MUD+json”的“接受”标题字段（[RFC7231]，第5.3.2节）、“接受语言”标题字段（[RFC7231]，第5.3.5节）和“用户代理”标题字段（[RFC7231]，第5.5.3节）。
MUD managers SHOULD automatically process 3xx response status codes.
泥浆管理器应自动处理3xx响应状态代码。
If a MUD manager is not able to fetch a MUD URL, other means MAY be used to import MUD files and associated signature files. So long as the signature of the file can be validated, the file can be used. In such environments, controllers SHOULD warn administrators when cache-validity expiry is approaching so that they may check for new files.
如果MUD管理器无法获取MUD URL，则可以使用其他方法导入MUD文件和相关签名文件。只要文件的签名可以验证，文件就可以使用。在这样的环境中，当缓存有效期即将到期时，控制器应该警告管理员，以便他们可以检查新文件。
It may not be possible for a MUD manager to retrieve a MUD file at any given time. Should a MUD manager fail to retrieve a MUD file, it SHOULD consider the existing one safe to use, at least for a time. After some period, it SHOULD log that it has been unable to retrieve the file. There may be very good reasons for such failures, including the possibility that the MUD manager is in an offline environment, the local Internet connection has failed, or the remote Internet connection has failed. It is also possible that an attacker is attempting to interfere with the deployment of a device. How to handle such circumstances is a local decision.
泥浆管理器可能无法在任何给定时间检索泥浆文件。如果MUD管理器无法检索MUD文件，它应该考虑现有的安全文件，至少要使用一段时间。经过一段时间后，它应该记录它无法检索文件。此类故障可能有很好的原因，包括MUD管理器处于脱机环境、本地Internet连接故障或远程Internet连接故障的可能性。攻击者还可能试图干扰设备的部署。如何处理这种情况是当地的决定。
When the MUD URL is resolved, the MUD manager retrieves a file that describes what sort of communications a device is designed to have. The manufacturer may specify either specific hosts for cloud-based services or certain classes for access within an operational network. An example of a class might be "devices of a specified manufacturer type", where the manufacturer type itself is indicated simply by the authority component (e.g., the domain name) of the MUD URL. Another example might be to allow or disallow local access. Just like other policies, these may be combined. For example:
解析MUD URL后，MUD管理器将检索一个文件，该文件描述设备的设计通信类型。制造商可以为基于云的服务指定特定主机，也可以为在运营网络中访问指定特定类别。一个类的示例可能是“指定制造商类型的设备”，其中制造商类型本身仅由MUD URL的授权组件（例如域名）表示。另一个例子可能是允许或不允许本地访问。与其他政策一样，这些政策也可以结合使用。例如：
o Allow access to devices of the same manufacturer
o 允许访问同一制造商的设备
o Allow access to and from controllers via the Constrained Application Protocol (COAP) [RFC7252]
o 允许通过受限应用程序协议（COAP）访问控制器和从控制器访问[RFC7252]
o Allow access to local DNS/NTP
o 允许访问本地DNS/NTP
o Deny all other access
o 拒绝所有其他访问
A printer might have a description that states:
打印机可能有一个说明，说明：
o Allow access for port IPP or port LPD
o 允许访问端口IPP或端口LPD
o Allow local access for port HTTP
o 允许对HTTP端口进行本地访问
o Deny all other access
o 拒绝所有其他访问
In this way, anyone can print to the printer, but local access would be required for the management interface.
这样，任何人都可以打印到打印机，但管理界面需要本地访问。
The files that are retrieved are intended to be closely aligned to existing network architectures so that they are easy to deploy. We make use of YANG [RFC7950] because it provides accurate and adequate models for use by network devices. JSON [RFC8259] is used as a serialization format for compactness and readability, relative to XML. Other formats may be chosen with later versions of MUD.
检索到的文件旨在与现有网络体系结构紧密一致，以便易于部署。我们之所以使用YANG[RFC7950]，是因为它为网络设备提供了准确而充分的模型。JSON[RFC8259]被用作相对于XML的紧凑性和可读性的序列化格式。其他格式可与更高版本的MUD一起选择。
While the policy examples given here focus on access control, this is not intended to be the sole focus. By structuring the model described in this document with clear extension points, other descriptions could be included. One that often comes to mind is quality of service.
虽然这里给出的策略示例侧重于访问控制，但这并不是唯一的重点。通过使用清晰的扩展点构建本文档中描述的模型，可以包括其他描述。人们经常想到的是服务质量。
The YANG modules specified here are extensions of [RFC8519]. The extensions to this model allow for a manufacturer to express classes of systems that a manufacturer would find necessary for the proper function of the device. Two modules are specified. The first module specifies a means for domain names to be used in Access Control Lists (ACLs) so that devices that have their controllers in the cloud may be appropriately authorized with domain names, where the mapping of those names to addresses may rapidly change.
此处指定的模块是[RFC8519]的扩展。此模型的扩展允许制造商表示制造商认为设备正常运行所需的系统类别。指定了两个模块。第一个模块为访问控制列表（ACL）中使用的域名指定了一种方式，以便在云中拥有控制器的设备可以使用域名进行适当授权，而这些名称到地址的映射可能会快速变化。
The other module abstracts away IP addresses into certain classes that are instantiated into actual IP addresses through local processing. Through these classes, manufacturers can specify how the device is designed to communicate, so that network elements can be configured by local systems that have local topological knowledge. That is, the deployment populates the classes that the manufacturer specifies. The abstractions below map to zero or more hosts, as follows:
另一个模块将IP地址抽象为某些类，这些类通过本地处理实例化为实际IP地址。通过这些类，制造商可以指定设备通信的设计方式，从而可以由具有本地拓扑知识的本地系统配置网络元素。也就是说，部署填充制造商指定的类。下面的抽象映射到零台或多台主机，如下所示：
Manufacturer: A device made by a particular manufacturer, as identified by the authority component of its MUD URL.
制造商：由特定制造商制造的设备，由其MUD URL的授权组件标识。
same-manufacturer: Devices that have the same authority component of their MUD URL.
同一制造商：在其MUD URL中具有相同权限组件的设备。
controller: Devices that the local network administrator admits to the particular class.
控制器：本地网络管理员允许特定类别的设备。
my-controller: Devices intended to serve as controllers for the MUD URL that the Thing emitted.
my controller（我的控制器）：用于作为对象发出的MUD URL的控制器的设备。
local: The class of IP addresses that are scoped within some administrative boundary. By default, it is suggested that this be the local subnet.
本地：在某个管理边界范围内的IP地址类。默认情况下，建议这是本地子网。
The "manufacturer" classes can be easily specified by the manufacturer, whereas controller classes are initially envisioned to be specified by the administrator.
“制造商”类可以很容易地由制造商指定，而控制器类最初设想由管理员指定。
Because manufacturers do not know who will be using their devices, it is important for functionality referenced in usage descriptions to be relatively ubiquitous and mature. For these reasons, the YANG-based configuration in a MUD file is limited to the modules either specified or referenced in this document, or specified in documented extensions.
因为制造商不知道谁将使用他们的设备，所以使用说明中引用的功能相对普遍和成熟是很重要的。由于这些原因，MUD文件中基于YANG的配置仅限于本文档中指定或引用的模块，或文档扩展中指定的模块。
With these components laid out, we now have the basis for an architecture. This leads us to ASCII art.
有了这些组件，我们现在就有了架构的基础。这就引出了ASCII艺术。
.......................................
. ____________ . _____________
. | | . | |
. | MUD |-->get URL-->| MUD |
. | Manager | .(https) | File Server |
. End system network |____________|<-MUD file<-<|_____________|
. . .
. . .
. _______ _________ .
.| | (DHCP et al.) | router | .
.| Thing |---->MUD URL-->| or | .
.|_______| | switch | .
. |_________| .
.......................................
.......................................
. ____________ . _____________
. | | . | |
. | MUD |-->get URL-->| MUD |
. | Manager | .(https) | File Server |
. End system network |____________|<-MUD file<-<|_____________|
. . .
. . .
. _______ _________ .
.| | (DHCP et al.) | router | .
.| Thing |---->MUD URL-->| or | .
.|_______| | switch | .
. |_________| .
.......................................
Figure 1: MUD Architecture
图1：泥浆体系结构
In the above diagram, the switch or router collects MUD URLs and forwards them to the MUD manager (a network management system) for processing. This happens in different ways, depending on how the URL is communicated. For instance, in the case of DHCP, the DHCP server might receive the URL and then process it. In the case of IEEE 802.1X [IEEE8021X], the switch would carry the URL via a certificate to the authentication server via the Extensible Authentication Protocol (EAP) over Radius [RFC3748], which would then process it. One method to do this is TEAP, as described in [RFC7170]. The certificate extension is described below.
在上图中，交换机或路由器收集MUD URL并将其转发给MUD管理器（网络管理系统）进行处理。这以不同的方式发生，具体取决于URL的通信方式。例如，在DHCP的情况下，DHCP服务器可能会接收URL，然后对其进行处理。在IEEE 802.1X[IEEE8021X]的情况下，交换机将通过Radius[RFC3748]上的可扩展身份验证协议（EAP）通过证书将URL传送到身份验证服务器，然后该服务器将对其进行处理。一种方法是TEAP，如[RFC7170]所述。证书扩展如下所述。
The information returned by the MUD file server is valid for as long as the Thing is connected. There is no expiry. However, if the MUD manager has detected that the MUD file for a Thing has changed, it SHOULD update the policy expeditiously, taking into account whatever approval flow is required in a deployment. In this way, new recommendations from the manufacturer can be processed in a timely fashion.
MUD文件服务器返回的信息在连接的情况下有效。没有有效期。但是，如果MUD经理检测到某事物的MUD文件已更改，则应迅速更新策略，同时考虑部署中所需的任何审批流。这样，制造商的新建议可以及时处理。
The information returned by the MUD file server (a web server) is valid for the duration of the Thing's connection, or as specified in the description. Thus, if the Thing is disconnected, any associated configuration in the switch can be removed. Similarly, from time to time the description may be refreshed, based on new capabilities or communication patterns or vulnerabilities.
MUD文件服务器（web服务器）返回的信息在连接期间有效，或者在描述中指定。因此，如果设备断开连接，则可以删除交换机中的任何相关配置。类似地，可根据新的能力或通信模式或漏洞不时刷新描述。
The web server is typically run by or on behalf of the manufacturer. Its domain name is that of the authority found in the MUD URL. For legacy cases where Things cannot emit a URL, if the switch is able to determine the appropriate URL, it may proxy it. In a trivial case, it may hardcode a MUD URL on a switch port or a map from some available identifier such as an L2 address or certificate hash to a MUD URL.
web服务器通常由制造商或其代表运行。其域名为MUD URL中的权威机构的域名。对于无法发出URL的传统情况，如果交换机能够确定适当的URL，则可以代理它。在一般情况下，它可能会硬编码交换机端口上的MUD URL，或者将一些可用标识符（如L2地址或证书哈希）映射到MUD URL。
The role of the MUD manager in this environment is to do the following:
泥浆管理器在此环境中的作用是执行以下操作：
o receive MUD URLs,
o 接收MUD URL，
o fetch MUD files,
o 获取MUD文件，
o translate abstractions in the MUD files to specific network element configuration,
o 将MUD文件中的抽象翻译为特定的网元配置，
o maintain and update any required mappings of the abstractions, and
o 维护和更新任何必要的抽象映射，以及
o update network elements with appropriate configuration.
o 使用适当的配置更新网络元素。
A MUD manager may be a component of an Authentication, Authorization, and Accounting (AAA) system or a network management system. Communication within those systems and from those systems to network elements is beyond the scope of this memo.
MUD管理器可以是身份验证、授权和计费（AAA）系统或网络管理系统的组件。这些系统内以及从这些系统到网络元件的通信超出了本备忘录的范围。
As mentioned above, MUD contains architectural building blocks, so the order of operation may vary. However, here is one clear intended example:
如上所述，MUD包含建筑构件，因此操作顺序可能会有所不同。然而，这里有一个明确的预期示例：
1. Thing emits a URL.
1. 东西发出一个URL。
2. That URL is forwarded to a MUD manager by the nearest switch (how this happens depends on the way in which the MUD URL is emitted).
2. 该URL由最近的开关转发给MUD管理器（这取决于MUD URL的发送方式）。
3. The MUD manager retrieves the MUD file and signature from the MUD file server, assuming it doesn't already have copies. After validating the signature, it may test the URL against a web or domain reputation service, and it may test any hosts within the file against those reputation services, as it deems fit.
3. MUD管理器从MUD文件服务器检索MUD文件和签名，假设它还没有副本。在验证签名后，它可以根据web或域信誉服务测试URL，并且可以根据这些信誉服务测试文件中的任何主机（如果它认为合适）。
4. The MUD manager may query the administrator for permission to add the Thing and associated policy. If the Thing is known or the Thing type is known, it may skip this step.
4. MUD管理员可以向管理员查询添加内容和相关策略的权限。如果已知对象或对象类型，则可能跳过此步骤。
5. The MUD manager instantiates local configuration based on the abstractions defined in this document.
5. MUD管理器根据本文档中定义的抽象实例化本地配置。
6. The MUD manager configures the switch nearest the Thing. Other systems may be configured as well.
6. 泥浆管理器配置离物体最近的开关。也可以配置其他系统。
7. When the Thing disconnects, policy is removed.
7. 当事物断开连接时，策略被删除。
A MUD file consists of a YANG model instance that has been serialized in JSON [RFC7951]. For purposes of MUD, the nodes that can be modified are access lists as augmented by this model. The MUD file is limited to the serialization of only the following YANG schema:
MUD文件由一个已在JSON[RFC7951]中序列化的YANG模型实例组成。出于MUD的目的，可以修改的节点是由该模型扩展的访问列表。MUD文件仅限于以下模式的序列化：
o ietf-access-control-list [RFC8519]
o ietf访问控制列表[RFC8519]
o ietf-mud (RFC 8520)
o ietf mud（RFC 8520）
o ietf-acldns (RFC 8520)
o ietf acldns（RFC 8520）
Extensions may be used to add additional schema. This is described further on.
扩展可用于添加其他架构。这将在后面进一步描述。
To provide the widest possible deployment, publishers of MUD files SHOULD make use of the abstractions in this memo and avoid the use of IP addresses. A MUD manager SHOULD NOT automatically implement any MUD file that contains IP addresses, especially those that might have local significance. The addressing of one side of an access list is implicit, based on whether it is applied as to-device-policy or from-device-policy.
为了提供尽可能广泛的部署，MUD文件的发布者应该使用本备忘录中的摘要，并避免使用IP地址。MUD管理器不应自动实现任何包含IP地址的MUD文件，尤其是那些可能具有本地意义的文件。访问列表一侧的寻址是隐式的，取决于它是应用于设备策略还是应用于设备策略。
With the exceptions of the "name" of the ACL, "type", "name" of the Access Control Entry (ACE), and TCP and UDP source and destination port information, publishers of MUD files SHOULD limit the use of ACL model leaf nodes expressed to those found in this specification. Absent any extensions, MUD files are assumed to implement only the following ACL model features:
除了ACL的“名称”、访问控制条目（ACE）的“类型”、“名称”以及TCP和UDP源端口和目标端口信息之外，MUD文件的发布者应限制使用本规范中表示的ACL模型叶节点。如果没有任何扩展名，则假定MUD文件仅实现以下ACL模型功能：
o match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-on-icmp
o ipv4匹配、ipv6匹配、tcp匹配、udp匹配、icmp匹配
Furthermore, only "accept" or "drop" actions SHOULD be included. A MUD manager MAY choose to interpret "reject" as "drop". A MUD manager SHOULD ignore all other actions. This is because manufacturers do not have sufficient context within a local deployment to know whether reject is appropriate. That is a decision that should be left to a network administrator.
此外，只应包括“接受”或“放弃”操作。泥浆管理人员可选择将“拒绝”解释为“放弃”。泥浆管理人员应忽略所有其他操作。这是因为制造商在本地部署中没有足够的上下文来知道拒绝是否合适。这是一个应该留给网络管理员的决定。
Given that MUD does not deal with interfaces, the support of the "ietf-interfaces" module [RFC8343] is not required. Specifically, the support of interface-related features and branches (e.g., interface-attachment and interface-stats) of the ACL YANG module is not required.
鉴于MUD不处理接口，因此不需要支持“ietf接口”模块[RFC8343]。具体而言，不需要支持ACL模块的接口相关特性和分支（例如，接口附件和接口统计数据）。
In fact, MUD managers MAY ignore any particular component of a description or MAY ignore the description in its entirety, and they SHOULD carefully inspect all MUD descriptions. Publishers of MUD files MUST NOT include other nodes except as described in Section 3.9. See that section for more information.
事实上，泥浆管理人员可能会忽略描述的任何特定部分，也可能会忽略整个描述，他们应该仔细检查所有泥浆描述。除第3.9节所述外，MUD文件的发布者不得包括其他节点。有关更多信息，请参阅该部分。
This module is structured into three parts:
本模块分为三个部分：
o The first component, the "mud" container, holds information that is relevant to retrieval and validity of the MUD file itself, as well as policy intended to and from the Thing.
o 第一个组件是“mud”容器，它保存与mud文件本身的检索和有效性相关的信息，以及与该对象相关的策略。
o The second component augments the matching container of the ACL model to add several nodes that are relevant to the MUD URL, or they are otherwise abstracted for use within a local environment.
o 第二个组件扩展了ACL模型的匹配容器，以添加与MUD URL相关的几个节点，或者将它们抽象为在本地环境中使用。
o The third component augments the tcp-acl container of the ACL model to add the ability to match on the direction of initiation of a TCP connection.
o 第三个组件增强了acl模型的tcp acl容器，以添加匹配tcp连接启动方向的能力。
A valid MUD file will contain two root objects: a "mud" container and an "acls" container. Extensions may add additional root objects as required. As a reminder, when parsing acls, elements within a "match" block are logically ANDed. In general, a single abstraction in a match statement should be used. For instance, it makes little sense to match both "my-controller" and "controller" with an argument, since they are highly unlikely to be the same value.
有效的MUD文件将包含两个根对象：“MUD”容器和“acls”容器。扩展可以根据需要添加其他根对象。作为提醒，在解析ACL时，“match”块中的元素在逻辑上被AND。通常，应该在match语句中使用单个抽象。例如，将“我的控制器”和“控制器”与参数匹配没有什么意义，因为它们不太可能是相同的值。
A simplified graphical representation of the data models is used in this document. The meaning of the symbols in these diagrams is explained in [RFC8340].
本文件中使用了数据模型的简化图形表示。[RFC8340]中解释了这些图中符号的含义。
module: ietf-mud
+--rw mud!
+--rw mud-version uint8
+--rw mud-url inet:uri
+--rw last-update yang:date-and-time
+--rw mud-signature? inet:uri
+--rw cache-validity? uint8
+--rw is-supported boolean
+--rw systeminfo? string
+--rw mfg-name? string
+--rw model-name? string
+--rw firmware-rev? string
+--rw software-rev? string
+--rw documentation? inet:uri
+--rw extensions* string
+--rw from-device-policy
| +--rw acls
| +--rw access-list* [name]
| +--rw name -> /acl:acls/acl/name
+--rw to-device-policy
+--rw acls
+--rw access-list* [name]
+--rw name -> /acl:acls/acl/name
module: ietf-mud
+--rw mud!
+--rw mud-version uint8
+--rw mud-url inet:uri
+--rw last-update yang:date-and-time
+--rw mud-signature? inet:uri
+--rw cache-validity? uint8
+--rw is-supported boolean
+--rw systeminfo? string
+--rw mfg-name? string
+--rw model-name? string
+--rw firmware-rev? string
+--rw software-rev? string
+--rw documentation? inet:uri
+--rw extensions* string
+--rw from-device-policy
| +--rw acls
| +--rw access-list* [name]
| +--rw name -> /acl:acls/acl/name
+--rw to-device-policy
+--rw acls
+--rw access-list* [name]
+--rw name -> /acl:acls/acl/name
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw mud
+--rw manufacturer? inet:host
+--rw same-manufacturer? empty
+--rw model? inet:uri
+--rw local-networks? empty
+--rw controller? inet:uri
+--rw my-controller? empty
augment
/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
/acl:l4/acl:tcp/acl:tcp:
+--rw direction-initiated? direction
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw mud
+--rw manufacturer? inet:host
+--rw same-manufacturer? empty
+--rw model? inet:uri
+--rw local-networks? empty
+--rw controller? inet:uri
+--rw my-controller? empty
augment
/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
/acl:l4/acl:tcp/acl:tcp:
+--rw direction-initiated? direction
This node specifies the integer version of the MUD specification. This memo specifies version 1.
此节点指定MUD规范的整数版本。本备忘录规定了第1版。
This URL identifies the MUD file. This is useful when the file and associated signature are manually uploaded, say, in an offline mode.
此URL标识MUD文件。当手动上传文件和相关签名时（例如，在脱机模式下），这非常有用。
[RFC8519] describes access lists. In the case of MUD, a MUD file must be explicit in describing the communication pattern of a Thing, and that includes indicating what is to be permitted or denied in either direction of communication. Hence, each of these containers indicates the appropriate direction of a flow in association with a particular Thing. They contain references to specific access lists.
[RFC8519]描述访问列表。在MUD的情况下，MUD文件在描述事物的通信模式时必须是明确的，这包括指示在通信的任一方向上允许或拒绝什么。因此，这些容器中的每一个都指示与特定事物相关联的流的适当方向。它们包含对特定访问列表的引用。
This is a date-and-time value of when the MUD file was generated. This is akin to a version number. Its form is taken from [RFC6991].
这是生成MUD文件的日期和时间值。这类似于版本号。其形式取自[RFC6991]。
This uint8 is the period of time in hours that a network management station MUST wait since its last retrieval before checking for an update. It is RECOMMENDED that this value be no less than 24, and it MUST NOT be more than 168 for any Thing that is supported. This period SHOULD be no shorter than any period determined through HTTP caching directives (e.g., "cache-control" or "Expires"). N.B., the expiring of this timer does not require the MUD manager to discard the MUD file, nor terminate access to a Thing. See Section 16 for more information.
此uint8是网络管理站自上次检索以来在检查更新之前必须等待的时间段（以小时为单位）。建议该值不小于24，对于任何受支持的对象，该值不得大于168。此时间段不得短于通过HTTP缓存指令确定的任何时间段（例如，“缓存控制”或“过期”）。注意，此计时器的过期不要求MUD管理器丢弃MUD文件，也不要求终止对某个对象的访问。更多信息请参见第16节。
This boolean is an indication from the manufacturer to the network administrator as to whether or not the Thing is supported. In this context, a Thing is said to not be supported if the manufacturer intends never to issue a firmware or software update to the Thing or never to update the MUD file. A MUD manager MAY still periodically check for updates.
该布尔值表示制造商向网络管理员指示是否支持该设备。在这种情况下，如果制造商打算从不向某件东西发布固件或软件更新，或者从不更新MUD文件，则称该东西不受支持。泥浆管理器仍然可以定期检查更新。
This is a textual UTF-8 description of the Thing to be connected. The intent is for administrators to be able to see a brief displayable description of the Thing. It SHOULD NOT exceed 60 characters worth of display space.
这是要连接的对象的文本UTF-8描述。其目的是让管理员能够看到该事物的简短的可显示描述。显示空间不得超过60个字符。
These optional fields are filled in as specified by [RFC8348]. Note that 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. This would be the case, for instance, with MUD URLs that are contained in 802.1AR certificates.
这些可选字段按照[RFC8348]的规定填写。请注意，如果可以升级设备，但无法更新MUD URL，则不得在MUD文件中填充固件版本和软件版本。例如，802.1AR证书中包含的MUD URL就是这种情况。
This optional leaf-list names MUD extensions that are used in the MUD file. Note that MUD extensions MUST NOT be used in a MUD file without the extensions being declared. Implementations MUST ignore any node in this file that they do not understand.
此可选叶列表命名MUD文件中使用的MUD扩展名。请注意，在未声明扩展名的情况下，不得在MUD文件中使用MUD扩展名。实现必须忽略此文件中他们不理解的任何节点。
Note that extensions can either extend the MUD file as described in the previous paragraph or reference other work. An extension example can be found in Appendix B.
请注意，扩展可以按照上一段所述扩展MUD文件，也可以引用其他工作。附录B中提供了一个扩展示例。
Note that in this section, when we use the term "match", we are referring to the ACL model "matches" node.
请注意，在本节中，当我们使用术语“匹配”时，我们指的是ACL模型“匹配”节点。
This node consists of a hostname that would be matched against the authority component of another Thing's MUD URL. In its simplest form, "manufacturer" and "same-manufacturer" may be implemented as access lists. In more complex forms, additional network capabilities may be used. For example, if one saw the line "manufacturer" : "flobbidy.example.com", then all Things that registered with a MUD URL that contained flobbity.example.com in its authority section would match.
这个节点由一个主机名组成，该主机名将与另一事物的MUD URL的authority组件相匹配。在其最简单的形式中，“制造商”和“同一制造商”可以实现为访问列表。在更复杂的形式中，可以使用额外的网络功能。例如，如果看到行“manufacturer”：“flobbidy.example.com”，那么在其权限部分包含flobbity.example.com的MUD URL中注册的所有内容都将匹配。
This null-valued node is an equivalent for when the manufacturer element is used to indicate that the authority found in another Thing's MUD URL matches that of the authority found in this Thing's MUD URL. For example, if the Thing's MUD URL were "https://b1.example.com/ThingV1", then all devices that had a MUD URL with an authority section of b1.example.com would match.
当使用manufacturer元素指示在另一事物的MUD URL中找到的权限与在该事物的MUD URL中找到的权限匹配时，此空值节点是等效的。例如，如果对象的MUD URL为“https://b1.example.com/ThingV1“，则所有具有具有b1.example.com权限部分的MUD URL的设备都将匹配。
This URI consists of a URL that points to documentation relating to the device and the MUD file. This can prove particularly useful when the "controller" class is used, so that its use can be explained.
此URI由一个URL组成，该URL指向与设备和MUD文件相关的文档。这在使用“controller”类时特别有用，因此可以解释它的用法。
This string matches the entire MUD URL, thus covering the model that is unique within the context of the authority. It may contain not only model information, but versioning information as well, and any other information that the manufacturer wishes to add. The intended use is for devices of this precise class to match, to permit or deny communication between one another.
该字符串匹配整个MUD URL，从而覆盖权限上下文中唯一的模型。它可能不仅包含模型信息，还包含版本控制信息，以及制造商希望添加的任何其他信息。预期用途是使该类设备相互匹配、允许或拒绝彼此之间的通信。
This null-valued node expands to include local networks. Its default expansion is that packets must not traverse toward a default route that is received from the router. However, administrators may expand the expression as is appropriate in their deployments.
此空值节点扩展为包括本地网络。它的默认扩展是，数据包不能朝着从路由器接收的默认路由移动。但是，管理员可以在其部署中适当地展开表达式。
This URI specifies a value that a controller will register with the MUD manager. The node then is expanded to the set of hosts that are so registered. This node may also be a URN. In this case, the URN describes a well-known service, such as DNS or NTP, that has been standardized. Both of those URNs may be found in Section 17.7.
此URI指定控制器将向MUD管理器注册的值。然后将节点扩展到这样注册的主机集。此节点也可以是URN。在本例中，URN描述了一个众所周知的服务，例如DNS或NTP，该服务已经标准化。这两个骨灰盒见第17.7节。
When "my-controller" is used, it is possible that the administrator will be prompted to populate that class for each and every model. Use of "controller" with a named class allows the user to populate that class only once for many different models that a manufacturer may produce.
使用“我的控制器”时，可能会提示管理员为每个模型填充该类。将“控制器”与命名类一起使用允许用户仅为制造商可能生产的许多不同型号填充该类一次。
Controller URIs MAY take the form of a URL (e.g., "http[s]://"). However, MUD managers MUST NOT resolve and retrieve such files, and it is RECOMMENDED that there be no such file at this time, as their form and function may be defined at a point in the future. For now, URLs should serve simply as class names and may be populated by the local deployment administrator.
控制器URI可以采用URL的形式（例如，“http[s]：/”）。但是，泥浆管理人员不得解析和检索此类文件，建议目前不存在此类文件，因为它们的形式和功能可能在将来某个时候定义。目前，URL应仅用作类名，并可由本地部署管理员填充。
Great care should be taken by MUD managers when invoking the controller class in the form of URLs. For one thing, it requires some understanding by the administrator as to when it is appropriate.
当以URL的形式调用控制器类时，MUD管理器应该非常小心。首先，它需要管理员对何时合适有所了解。
Pre-registration in such classes by controllers with the MUD server is encouraged. The mechanism to do that is beyond the scope of this work.
鼓励控制器在MUD服务器上预先注册此类课程。这样做的机制超出了这项工作的范围。
This null-valued node signals to the MUD manager to use whatever mapping it has for this MUD URL to a particular group of hosts. This may require prompting the administrator for class members. Future work should seek to automate membership management.
此空值节点向MUD管理器发出信号，要求其使用此MUD URL到特定主机组的任何映射。这可能需要提示管理员输入类成员。未来的工作应该寻求自动化成员管理。
This MUST only be applied to TCP. This matches the direction in which a TCP connection is initiated. When the direction initiated is "from-device", packets that are transmitted in the direction of a Thing MUST be dropped unless the Thing has first initiated a TCP connection. By way of example, this node may be implemented in its simplest form by looking at naked SYN bits, but it may also be implemented through more stateful mechanisms.
这只能应用于TCP。这与TCP连接启动的方向相匹配。当启动的方向是“来自设备”时，必须丢弃沿某个对象的方向传输的数据包，除非该对象已首先启动TCP连接。举例来说，该节点可以通过查看裸SYN位以其最简单的形式实现，但也可以通过更有状态的机制实现。
When applied, this matches packets when the flow was initiated in the corresponding direction. [RFC6092] specifies IPv6 guidance best practices. While that document is scoped specifically to IPv6, its contents are applicable for IPv4 as well.
当应用时，这与在相应方向上启动流时的数据包相匹配。[RFC6092]指定了IPv6指导最佳实践。虽然该文档专门针对IPv6，但其内容也适用于IPv4。
To keep things relatively simple in addition to whatever definitions exist, we also apply two additional default behaviors:
除了现有的定义外，为了使事情相对简单，我们还应用了两种额外的默认行为：
o Anything not explicitly permitted is denied.
o 任何未明确允许的内容都将被拒绝。
o Local DNS and NTP are, by default, permitted to and from the Thing.
o 默认情况下，本地DNS和NTP被允许进出该对象。
An explicit description of the defaults can be found in Appendix A. These are applied AFTER all other explicit rules. Thus, a default behavior can be changed with a "drop" action.
在附录A中可以找到默认值的明确描述。这些默认值在所有其他明确规则之后应用。因此，可以通过“删除”操作更改默认行为。
MUD URLs are required to use the "https" scheme, in order to establish the MUD file server's identity and assure integrity of the MUD file.
MUD URL需要使用“https”方案，以建立MUD文件服务器的身份并确保MUD文件的完整性。
Any "https://" URL can be a MUD URL. For example:
任何“https://”URL都可以是MUD URL。例如：
https://things.example.org/product_abc123/v5
https://www.example.net/mudfiles/temperature_sensor/
https://example.com/lightbulbs/colour/v1
https://things.example.org/product_abc123/v5
https://www.example.net/mudfiles/temperature_sensor/
https://example.com/lightbulbs/colour/v1
A manufacturer may construct a MUD URL in any way, so long as it makes use of the "https" scheme.
制造商可以以任何方式构造MUD URL，只要它使用“https”方案。
<CODE BEGINS>file "ietf-mud@2019-01-28.yang"
module ietf-mud {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud";
prefix ietf-mud;
<CODE BEGINS>file "ietf-mud@2019-01-28.yang"
module ietf-mud {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud";
prefix ietf-mud;
import ietf-access-control-list {
prefix acl;
}
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
import ietf-access-control-list {
prefix acl;
}
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
Author: Eliot Lear lear@cisco.com
作者：艾略特·李尔lear@cisco.com
Author: Ralph Droms rdroms@gmail.com
作者：拉尔夫·德罗姆斯rdroms@gmail.com
Author: Dan Romascanu dromasca@gmail.com "; description "This YANG module defines a component that augments the IETF description of an access list. This specific module focuses on additional filters that include local, model, and same-manufacturer.
作者：Dan Romascanudromasca@gmail.com“描述”该模块定义了一个组件，该组件增强了访问列表的IETF描述。本特定模块重点介绍其他过滤器，包括本地过滤器、型号过滤器和同一制造商过滤器。
This module is intended to be serialized via JSON and stored as a file, as described in RFC 8520.
该模块旨在通过JSON序列化并存储为文件，如RFC 8520所述。
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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可能”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14（RFC 2119）（RFC 8174）所述进行解释。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
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 Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8520; see the RFC itself for full legal notices.";
此模块的此版本是RFC 8520的一部分；有关完整的法律通知，请参见RFC本身。“；
revision 2019-01-28 {
description
"Initial proposed standard.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
revision 2019-01-28 {
description
"Initial proposed standard.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
typedef direction {
type enumeration {
enum to-device {
description
"packets or flows destined to the target
Thing.";
}
enum from-device {
description
"packets or flows destined from
the target Thing.";
}
}
description
"Which way are we talking about?";
}
typedef direction {
type enumeration {
enum to-device {
description
"packets or flows destined to the target
Thing.";
}
enum from-device {
description
"packets or flows destined from
the target Thing.";
}
}
description
"Which way are we talking about?";
}
container mud {
集装箱泥浆{
presence "Enabled for this particular MUD URL";
description
"MUD-related information, as specified
by RFC 8520.";
uses mud-grouping;
}
presence "Enabled for this particular MUD URL";
description
"MUD-related information, as specified
by RFC 8520.";
uses mud-grouping;
}
grouping mud-grouping {
description
"Information about when support ends (or ended)
and when to refresh.";
leaf mud-version {
type uint8;
mandatory true;
description
"This is the version of the MUD
specification. This memo specifies version 1.";
}
leaf mud-url {
type inet:uri;
mandatory true;
description
"This is the MUD URL associated with the entry found
in a MUD file.";
}
leaf last-update {
type yang:date-and-time;
mandatory true;
description
"This is intended to be when the current MUD file
was generated. MUD managers SHOULD NOT check
for updates between this time plus cache validity.";
}
leaf mud-signature {
type inet:uri;
description
"A URI that resolves to a signature as
described in this specification.";
}
leaf cache-validity {
type uint8 {
range "1..168";
}
units "hours";
default "48";
description
"The information retrieved from the MUD server is
valid for these many hours, after which it should
grouping mud-grouping {
description
"Information about when support ends (or ended)
and when to refresh.";
leaf mud-version {
type uint8;
mandatory true;
description
"This is the version of the MUD
specification. This memo specifies version 1.";
}
leaf mud-url {
type inet:uri;
mandatory true;
description
"This is the MUD URL associated with the entry found
in a MUD file.";
}
leaf last-update {
type yang:date-and-time;
mandatory true;
description
"This is intended to be when the current MUD file
was generated. MUD managers SHOULD NOT check
for updates between this time plus cache validity.";
}
leaf mud-signature {
type inet:uri;
description
"A URI that resolves to a signature as
described in this specification.";
}
leaf cache-validity {
type uint8 {
range "1..168";
}
units "hours";
default "48";
description
"The information retrieved from the MUD server is
valid for these many hours, after which it should
be refreshed. N.B., MUD manager implementations
need not discard MUD files beyond this period.";
}
leaf is-supported {
type boolean;
mandatory true;
description
"This boolean indicates whether or not the Thing is
currently supported by the manufacturer.";
}
leaf systeminfo {
type string;
description
"A UTF-8 description of this Thing. This
should be a brief description that may be
displayed to the user to determine whether
to allow the Thing on the
network.";
}
leaf mfg-name {
type string;
description
"Manufacturer name, as described in
the ietf-hardware YANG module.";
}
leaf model-name {
type string;
description
"Model name, as described in the
ietf-hardware YANG module.";
}
leaf firmware-rev {
type string;
description
"firmware-rev, as described in the
ietf-hardware YANG module. Note that this field
MUST NOT be included when the device can be
updated but the MUD URL cannot.";
}
leaf software-rev {
type string;
description
"software-rev, as described in the
ietf-hardware YANG module. Note that this field
MUST NOT be included when the device can be
updated but the MUD URL cannot.";
}
leaf documentation {
be refreshed. N.B., MUD manager implementations
need not discard MUD files beyond this period.";
}
leaf is-supported {
type boolean;
mandatory true;
description
"This boolean indicates whether or not the Thing is
currently supported by the manufacturer.";
}
leaf systeminfo {
type string;
description
"A UTF-8 description of this Thing. This
should be a brief description that may be
displayed to the user to determine whether
to allow the Thing on the
network.";
}
leaf mfg-name {
type string;
description
"Manufacturer name, as described in
the ietf-hardware YANG module.";
}
leaf model-name {
type string;
description
"Model name, as described in the
ietf-hardware YANG module.";
}
leaf firmware-rev {
type string;
description
"firmware-rev, as described in the
ietf-hardware YANG module. Note that this field
MUST NOT be included when the device can be
updated but the MUD URL cannot.";
}
leaf software-rev {
type string;
description
"software-rev, as described in the
ietf-hardware YANG module. Note that this field
MUST NOT be included when the device can be
updated but the MUD URL cannot.";
}
leaf documentation {
type inet:uri;
description
"This URL points to documentation that
relates to this device and any classes that it uses
in its MUD file. A caution: MUD managers need
not resolve this URL on their own but rather simply
provide it to the administrator. Parsing HTML is
not an intended function of a MUD manager.";
}
leaf-list extensions {
type string {
length "1..40";
}
description
"A list of extension names that are used in this MUD
file. Each name is registered with the IANA and
described in an RFC.";
}
container from-device-policy {
description
"The policies that should be enforced on traffic
coming from the device. These policies are not
necessarily intended to be enforced at a single
point but may be rendered by the controller to any
relevant enforcement points in the network or
elsewhere.";
uses access-lists;
}
container to-device-policy {
description
"The policies that should be enforced on traffic
going to the device. These policies are not
necessarily intended to be enforced at a single
point but may be rendered by the controller to any
relevant enforcement points in the network or
elsewhere.";
uses access-lists;
}
}
type inet:uri;
description
"This URL points to documentation that
relates to this device and any classes that it uses
in its MUD file. A caution: MUD managers need
not resolve this URL on their own but rather simply
provide it to the administrator. Parsing HTML is
not an intended function of a MUD manager.";
}
leaf-list extensions {
type string {
length "1..40";
}
description
"A list of extension names that are used in this MUD
file. Each name is registered with the IANA and
described in an RFC.";
}
container from-device-policy {
description
"The policies that should be enforced on traffic
coming from the device. These policies are not
necessarily intended to be enforced at a single
point but may be rendered by the controller to any
relevant enforcement points in the network or
elsewhere.";
uses access-lists;
}
container to-device-policy {
description
"The policies that should be enforced on traffic
going to the device. These policies are not
necessarily intended to be enforced at a single
point but may be rendered by the controller to any
relevant enforcement points in the network or
elsewhere.";
uses access-lists;
}
}
grouping access-lists {
description
"A grouping for access lists in the context of device
policy.";
container access-lists {
description
"The access lists that should be applied to traffic
to or from the device.";
grouping access-lists {
description
"A grouping for access lists in the context of device
policy.";
container access-lists {
description
"The access lists that should be applied to traffic
to or from the device.";
list access-list {
key "name";
description
"Each entry on this list refers to an ACL that
should be present in the overall access list
data model. Each ACL is identified by name and
type.";
leaf name {
type leafref {
path "/acl:acls/acl:acl/acl:name";
}
description
"The name of the ACL for this entry.";
}
}
}
}
list access-list {
key "name";
description
"Each entry on this list refers to an ACL that
should be present in the overall access list
data model. Each ACL is identified by name and
type.";
leaf name {
type leafref {
path "/acl:acls/acl:acl/acl:name";
}
description
"The name of the ACL for this entry.";
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
description
"adding abstractions to avoid the need of IP addresses.";
container mud {
description
"MUD-specific matches.";
leaf manufacturer {
type inet:host;
description
"A domain that is intended to match the authority
section of the MUD URL. This node is used to specify
one or more manufacturers a device should
be authorized to access.";
}
leaf same-manufacturer {
type empty;
description
"This node matches the authority section of the MUD URL
of a Thing. It is intended to grant access to all
devices with the same authority section.";
}
leaf model {
type inet:uri;
description
"Devices of the specified model type will match if
they have an identical MUD URL.";
}
leaf local-networks {
type empty;
description
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
description
"adding abstractions to avoid the need of IP addresses.";
container mud {
description
"MUD-specific matches.";
leaf manufacturer {
type inet:host;
description
"A domain that is intended to match the authority
section of the MUD URL. This node is used to specify
one or more manufacturers a device should
be authorized to access.";
}
leaf same-manufacturer {
type empty;
description
"This node matches the authority section of the MUD URL
of a Thing. It is intended to grant access to all
devices with the same authority section.";
}
leaf model {
type inet:uri;
description
"Devices of the specified model type will match if
they have an identical MUD URL.";
}
leaf local-networks {
type empty;
description
"IP addresses will match this node if they are
considered local addresses. A local address may be
a list of locally defined prefixes and masks
that indicate a particular administrative scope.";
}
leaf controller {
type inet:uri;
description
"This node names a class that has associated with it
zero or more IP addresses to match against. These
may be scoped to a manufacturer or via a standard
URN.";
}
leaf my-controller {
type empty;
description
"This node matches one or more network elements that
have been configured to be the controller for this
Thing, based on its MUD URL.";
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l4/acl:tcp/acl:tcp" {
description
"add direction-initiated";
leaf direction-initiated {
type direction;
description
"This node matches based on which direction a
connection was initiated. The means by which that
is determined is discussed in this document.";
}
}
}
<CODE ENDS>
"IP addresses will match this node if they are
considered local addresses. A local address may be
a list of locally defined prefixes and masks
that indicate a particular administrative scope.";
}
leaf controller {
type inet:uri;
description
"This node names a class that has associated with it
zero or more IP addresses to match against. These
may be scoped to a manufacturer or via a standard
URN.";
}
leaf my-controller {
type empty;
description
"This node matches one or more network elements that
have been configured to be the controller for this
Thing, based on its MUD URL.";
}
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l4/acl:tcp/acl:tcp" {
description
"add direction-initiated";
leaf direction-initiated {
type direction;
description
"This node matches based on which direction a
connection was initiated. The means by which that
is determined is discussed in this document.";
}
}
}
<CODE ENDS>
This module specifies an extension to the IETF-ACL model such that domain names may be referenced by augmenting the "matches" node. Different implementations may deploy differing methods to maintain the mapping between the IP address and domain name, if indeed any are needed. However, the intent is that resources that are referred to using a name should be authorized (or not) within an access list.
该模块指定IETF-ACL模型的扩展，以便通过增加“匹配”节点来引用域名。如果确实需要，不同的实现可能会部署不同的方法来维护IP地址和域名之间的映射。但是，目的是使用名称引用的资源应该在访问列表中得到授权（或不授权）。
The structure of the change is as follows:
变更的结构如下：
module: ietf-acldns
augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv4/acl:ipv4:
+--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host
augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv6/acl:ipv6:
+--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host
module: ietf-acldns
augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv4/acl:ipv4:
+--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host
augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv6/acl:ipv6:
+--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host
The choice of these particular points in the access control list model is based on the assumption that we are in some way referring to IP-related resources, as that is what the DNS returns. A domain name in our context is defined in [RFC6991]. The augmentations are replicated across IPv4 and IPv6 to allow MUD file authors the ability to control the IP version that the Thing may utilize.
在访问控制列表模型中选择这些特定点是基于这样的假设，即我们在某种程度上引用了与IP相关的资源，因为这是DNS返回的。[RFC6991]中定义了我们上下文中的域名。这些扩展是跨IPv4和IPv6复制的，以使MUD文件作者能够控制可能使用的IP版本。
The following nodes are defined.
定义了以下节点。
The argument corresponds to a domain name of a source as specified by inet:host. A number of means may be used to resolve hosts. What is important is that such resolutions be consistent with ACLs that are required by Things to properly operate.
参数对应于inet:host指定的源域名。可以使用多种方法来解析主机。重要的是，这些解决方案必须与正常运行所需的ACL保持一致。
The argument corresponds to a domain name of a destination as specified by inet:host. See the previous section (Section 8.1) relating to resolution.
该参数对应于inet:host指定的目标域名。见上一节（第8.1节）有关决议的内容。
Note that when using either of these with a MUD file, because access is associated with a particular Thing, MUD files MUST NOT contain either a src-dnsname in an ACL associated with from-device-policy or a dst-dnsname associated with to-device-policy.
请注意，在将其中任何一个与MUD文件一起使用时，由于访问与特定内容相关联，MUD文件不得在与from设备策略关联的ACL中包含src dnsname，也不得在与to设备策略关联的dst dnsname中包含src dnsname。
<CODE BEGINS>file "ietf-acldns@2019-01-28.yang"
module ietf-acldns {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
prefix ietf-acldns;
<CODE BEGINS>file "ietf-acldns@2019-01-28.yang"
module ietf-acldns {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
prefix ietf-acldns;
import ietf-access-control-list {
prefix acl;
}
import ietf-inet-types {
prefix inet;
}
import ietf-access-control-list {
prefix acl;
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
Author: Eliot Lear lear@cisco.com
作者：艾略特·李尔lear@cisco.com
Author: Ralph Droms rdroms@gmail.com
作者：拉尔夫·德罗姆斯rdroms@gmail.com
Author: Dan Romascanu dromasca@gmail.com "; description "This YANG module defines a component that augments the IETF description of an access list to allow DNS names as matching criteria.
作者：Dan Romascanudromasca@gmail.com“描述”此模块定义了一个组件，该组件扩展了访问列表的IETF描述，以允许DNS名称作为匹配标准。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权（c）2019 IETF信托基金和被认定为代码作者的人员。版权所有。
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 Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).";
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(http://trustee.ietf.org/license-info).";
revision 2019-01-28 {
description
"Base version of dnsname extension of the ACL model.";
revision 2019-01-28 {
description
"Base version of dnsname extension of the ACL model.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
grouping dns-matches {
description
"Domain names for matching.";
leaf src-dnsname {
type inet:host;
description
"domain name to be matched against.";
}
leaf dst-dnsname {
type inet:host;
description
"domain name to be matched against.";
}
}
grouping dns-matches {
description
"Domain names for matching.";
leaf src-dnsname {
type inet:host;
description
"domain name to be matched against.";
}
leaf dst-dnsname {
type inet:host;
description
"domain name to be matched against.";
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l3/acl:ipv4/acl:ipv4" {
description
"Adding domain names to matching.";
uses dns-matches;
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l3/acl:ipv6/acl:ipv6" {
description
"Adding domain names to matching.";
uses dns-matches;
}
}
<CODE ENDS>
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l3/acl:ipv4/acl:ipv4" {
description
"Adding domain names to matching.";
uses dns-matches;
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches"
+ "/acl:l3/acl:ipv6/acl:ipv6" {
description
"Adding domain names to matching.";
uses dns-matches;
}
}
<CODE ENDS>
This example contains two access lists that are intended to provide outbound access to a cloud service on TCP port 443.
此示例包含两个访问列表，用于提供对TCP端口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",
{
"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"
}
}
]
}
}
]
}
}
"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.
可以映射到“service.bms.example.com”域名的东西。对于每个访问列表，执行点应该期望该对象启动了连接。
The IPv4 MUD URL client option has the following format:
IPv4 MUD URL客户端选项具有以下格式：
+------+-----+------------------------------
| code | len | MUDstring
+------+-----+------------------------------
+------+-----+------------------------------
| 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:
代码选项\u MUD\u URL\u V4（161）已由IANA分配。len是一个八位字节，以八位字节表示泥浆串的长度。泥浆管柱定义如下：
MUDstring = mudurl [ " " reserved ]
mudurl = URI; a URL [RFC3986] that uses the "https" scheme [RFC7230]
reserved = 1*( OCTET ) ; from [RFC5234]
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.
整个选项不得超过255个八位字节。如果MUD URL后面有空格，则后面会有一个保留字符串，该字符串将在将来的规范中定义。不了解该字段的泥浆管理人员必须忽略该字段。
The IPv6 MUD URL client option has the following format:
IPv6 MUD URL客户端选项具有以下格式：
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
选项\u MUD\u URL\u V6（112）。
option-length contains the length of the MUDstring, as defined above, in octets.
选项长度包含MUDstring的长度，如上所述，以八位字节为单位。
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.
选项只是以结构化的方式向网络标识对象的类型，这样就可以使用现有的工具集轻松找到策略。
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.
DHCPv4客户端可以发出DHCPv4选项，而DHCPv6客户端可以发出DHCPv6选项。这些选项是单例，如[RFC7227]中所述。因为客户机最多有一个与之相关联的MUD-URL，所以它们最多可以通过DHCPv4发出一个MUD-URL选项，通过DHCPv6发出一个MUD-URL选项。在同时发出v4和v6 DHCP选项的情况下，必须使用相同的URL。
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服务器可能会忽略这些选项，或者根据收到的选项采取操作。当服务器使用此选项时，它会将URL和相关客户端信息（如网关地址或giaddr和请求的IP地址以及租赁长度）转发到网络管理系统，或者通过解析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).
DHCP服务器可以自行实现MUD功能，也可以将适当的信息传递给网络管理系统或MUD管理器。处理MUD URL的DHCP服务器必须遵循[RFC2818]和[RFC5280]中指定的过程，以验证承载MUD文件的web服务器的TLS证书。这些服务器将检索文件，对其进行处理，并在相关网元上创建和安装必要的配置。服务器应监控网关在给定接口上的状态更改。不提供MUD功能且已将MUD URL转发给MUD管理器的DHCP服务器必须将客户端DHCP状态的任何相应更改（如网络地址租约到期或明确释放）通知MUD管理器。
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.
如果DHCP服务器出现故障，在它实现MUD管理器功能的情况下，任何备份机制都应该包括MUD状态，并且服务器应该在重新启动时解析客户端的状态，这与缺少MUD管理器功能时的情况类似。在DHCP服务器将信息转发给MUD管理器的情况下，MUD管理器将使用冗余DHCP服务器获取信息，或基于其他网络信息清除状态，例如通过SNMP、Radius记帐或类似机制监控交换机上的端口状态。
There are no additional requirements for relays.
对继电器没有额外要求。
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].
本节定义了一个X.509非关键证书扩展，该扩展包含一个URL，该URL指向与证书主题相关的在线制造商使用说明。URI必须按照[RFC5280]第7.4节所述表示。
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.
在将任何国际化资源标识符（IRI）放入证书扩展之前，必须按照[RFC3987]第3.1节的规定将其映射到URI。
The semantics of the URL are defined Section 6 of this document.
URL的语义在本文档第6节中定义。
The choice of id-pe is based on guidance found in Section 4.2.2 of [RFC5280]:
id pe的选择基于[RFC5280]第4.2.2节中的指南：
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.
MUD的URL就是：关于特定主题的在线信息。
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.
此外，一个单独的新扩展被定义为id pe mudsigner。它包含MUD文件的签名证书的主题字段。第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.
此签名的目的是声明在服务器上找到的MUD文件对给定设备有效，与任何其他因素无关。第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.
还定义了一个新的内容类型id ct mud。虽然现在已分离签名，但如果MUD文件作为加密消息语法（CMS）消息的一部分传输，则应使用此内容类型。
This module imports from [RFC5912] and [RFC6268]. The new extension is identified as follows:
此模块从[RFC5912]和[RFC6268]导入。新的扩展标识如下：
<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
<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
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 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 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) } ;
-- 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, ... }
MUDCertExtensions EXTENSION ::=
{ ext-MUDURL | ext-MUDsigner, ... }
ext-MUDURL EXTENSION ::=
ext-MUDURL EXTENSION ::=
{ SYNTAX MUDURLSyntax IDENTIFIED BY id-pe-mud-url }
{SYNTAX MUDURLSyntax由id pe mud url标识}
id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 }
id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 }
MUDURLSyntax ::= IA5String
MUDURLSyntax ::= IA5String
ext-MUDsigner EXTENSION ::=
{ SYNTAX MUDsignerSyntax IDENTIFIED BY id-pe-mudsigner }
ext-MUDsigner EXTENSION ::=
{ SYNTAX MUDsignerSyntax IDENTIFIED BY id-pe-mudsigner }
id-pe-mudsigner OBJECT IDENTIFIER ::= { id-pe 30 }
id-pe-mudsigner OBJECT IDENTIFIER ::= { id-pe 30 }
MUDsignerSyntax ::= Name
MUDsignerSyntax ::= Name
-- -- CMS Content Types --
----CMS内容类型--
MUDContentTypes CONTENT-TYPE ::=
{ ct-mud, ... }
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.
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 }
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.
虽然此扩展可以出现在802.AR制造商证书（IDevID）或部署证书（LDevID）中，但这两种证书都不能保证它，也不能保证它可以继续使用。建议mudmanager实现维护一个表，该表基于IDevIDs将事物映射到它的mudmurl。
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.
IEEE802.1AB链路层发现协议（LLDP）是一种单跳、供应商中立的链路层协议，终端主机网络使用该协议在IEEE 802局域网上公布其身份、功能和邻居。其类型长度值（TLV）设计允许定义“特定于供应商”的扩展。IANA具有注册的IEEE 802组织唯一标识符（OUI），定义见[RFC7042]。MUD LLDP扩展使用本文档中定义的子类型来承载MUD URL。
The LLDP vendor-specific frame has the following format:
LLDP供应商特定框架的格式如下：
+--------+--------+----------+---------+--------------
|TLV Type| len | OUI |subtype | MUDString
| =127 | |= 00 00 5E| = 1 |
|(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
+--------+--------+----------+---------+--------------
+--------+--------+----------+---------+--------------
|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 TLV类型=127表示特定于供应商的TLV
o len = indicates the TLV string length
o len=表示TLV字符串长度
o OUI = 00 00 5E is the organizationally unique identifier of IANA
o OUI=00 5E是IANA的组织唯一标识符
o subtype = 1 (as assigned by IANA for the MUDstring)
o 子类型=1（由IANA为MUDstring指定）
o MUDstring = the length MUST NOT exceed 255 octets
o MUDstring=长度不得超过255个八位字节
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.
实现此选项的主机、路由器或其他网络元素最多有一个与之关联的MUD URL，因此它们最多可以传输一个MUD URL值。
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.
实现此选项的主机、路由器或其他网络元件可能会忽略这些选项，或根据收到的这些选项采取措施。例如，他们可以在LLDP管理信息库（MIB）的相应扩展中填写信息。LLDP单向运行。链路层发现协议数据单元（LLDPDU）不作为一方的信息请求和另一方发送的响应进行交换。其他事物不确认从事物接收到的LLDP信息。不保证特定的网络行为。当某个对象使用此扩展时，它可以将URL和相关的远程对象信息转发给MUD管理器，或者通过根据正常HTTP语义解析URL来检索使用说明。
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.
因为MUD文件包含可用于配置网络访问列表的信息，所以它们是敏感的。为了确保它们没有被篡改，必须对它们进行签名。为此，我们使用DER编码的加密消息语法（CMS）[RFC5652]。
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".
MUD文件必须使用CMS作为不透明的二进制对象进行签名。为了使验证更可能成功，应包括中间证书。签名存储在MUD文件中指定的位置。使用内容类型“application/pkcs7 signature”传输签名。
For example:
例如：
% openssl cms -sign -signer mancertfile -inkey mankey \
-in mudfile -binary -outform DER -binary \
-certfile intermediatecert -out mudfile.p7s
% 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.
注意：如果签名过期，可能需要重新签名MUD文件。
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.
在处理MUD文件的其余部分之前，MUD管理器必须通过检索“MUD签名”的值并验证MUD文件中的签名来检索MUD签名文件。签名证书中的密钥使用扩展必须存在，并且必须设置位digitalSignature（0）。当设备的X.509证书中存在id pe mudsigner扩展名时，MUD签名文件必须由其主题与id pe mudsigner扩展名内容匹配的证书生成。如果不满足这些条件，或者无法验证对已知信任锚的信任链，则MUD经理必须停止处理MUD文件，直到管理员批准。
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.
文件上签名的目的是将责任分配给实体，该实体的声誉可用于指导管理员是否接受给定的MUD文件。检查文件所在服务器位置上的web信誉已经是常见的做法。虽然制造商很可能是文件的签字人，但严格来说，这不是必要的，也可能不可取。首先，在某些环境中，集成商可以安装自己的证书。另一方面，更重要的是建议的责任性，而不仅仅是内容和文件之间的关系。
An example:
例如：
% openssl cms -verify -in mudfile.p7s -inform DER -content mudfile
% openssl cms -verify -in mudfile.p7s -inform DER -content mudfile
Note the additional step of verifying the common trust root.
请注意验证公共信任根的附加步骤。
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:
我们的设计目标之一是确保MUD文件能够被尽可能广泛的系统理解。再加上我们也选择利用现有机制的事实，我们没有能力协商扩展，并且在任何情况下对这些扩展的愿望都是有限的。因此，采用了两层可扩展性框架，如下所示：
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.
1. 粗略地说，协议版本包含在MUD URL中。本备忘录规定了MUD版本1。当此版本被碰撞时，将接受任何和所有更改。版本之间的转换方法将在将来的版本中讨论。
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.
2. 在更细的粒度上，只允许不会对事物产生额外风险的扩展。具体地说，允许将节点添加到mud容器中，但要理解，不知情的实现将忽略这些添加。任何此类扩展都应通过IETF流程进行标准化，并且必须在“扩展”列表中进行命名。MUD管理者必须忽略他们不理解的节点，并且应该创建一个异常，由管理员解决，以避免任何策略不一致。
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.
因为MUD由许多架构构建块组成，所以可以组合不同的部署场景。一个关键方面是在何处实施策略。为了在本地部署中保护该对象不受其他对象的影响，可以在最近的交换机或访问点上实施策略。为了限制网络中不需要的通信量，建议尽可能靠近互联网实施策略。在某些情况下，可能无法在最近的跃点执行策略。在这一点上，横向感染的风险（居住在彼此附近的设备感染）增加到能够在没有保护的情况下进行通信的数量。
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.
因为到目前为止，编写MUD是一个新概念，所以可以预期很多设备都没有实现它。对于第一次连接的设备是否允许广泛或有限的访问，这仍然是本地部署的决定。此外，如引言中所述，部署可能会选择完全忽略MUD策略，而只是将MUD URL作为分类器考虑，作为本地策略决策的一部分。
Finally, please see directly below information regarding device lifetimes and use of domain names.
最后，请直接查看下面有关设备寿命和域名使用的信息。
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.
根据MUD URL的发出方式，一个东西可能会隐瞒它是什么，从而获得额外的网络访问。当设备使用DHCP或LLDP发出MUD URL时，这可能以多种方式发生，例如不适当地被允许进入“同一制造商”之类的类别，被授予访问“我的控制器”之类的设备的权限，或者被允许访问Internet资源，否则这种访问将被禁止。情况是否如此将取决于部署情况。实现应该是可配置的，以禁止使用未以安全方式（如证书）发出的MUD URL的设备的附加访问。类似地，实现不应将提升的权限（不包括不提供MUD策略的设备的权限）授予那些不将其标识强绑定到其L2/L3传输的设备。当MUD管理器使用不安全的方法时，类不应包含同时使用不安全和安全方法的设备，以防止权限提升攻击，并且不得包含具有从强和弱身份验证方法派生的相同MUD URL的设备。
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.
设备可能伪造源（L2/L3）信息。部署应应用适当的保护，将通信绑定到已发生的身份验证。对于802.1X身份验证，IEEE 802.1AE（MACsec）[IEEE8021AE]是实现此功能的一种方法。802.11i（Wi-Fi保护访问2（WPA2））[IEEE801i]也可以使用类似的方法。其他低层技术也提供了其他方法。使用非加密绑定的面向会话访问的实现应注意在检测到会话中任何形式的中断时删除状态。
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.
流氓证书颁发机构（CA）可能会签署一份证书，该证书包含与制造商证书中MUDsigner字段中列出的相同的主体名称，因此似乎允许使用替代设备的MUD文件。有两种缓解措施可用：首先，如果签名者发生变化，MUD经理可能会将其标记为例外情况。其次，如果MUD文件也发生更改，MUD经理应寻求管理员批准（在任何情况下都应这样做）。在任何情况下，MUD管理器都必须为此维护受信任CA的缓存。当发现这样的流氓时，应该将其清除。
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 URL可以充当一个分类器，可以被证明或反驳。指纹识别还可能具有其他优势：当使用802.1AR证书时，因为它们本身无法更改，所以指纹识别提供了以第10节中讨论的保留字段的形式向泥浆串添加伪影的机会。这些人工制品的意义留作将来的工作。
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.
MUD管理员不应接受具有相同媒体访问控制（MAC）地址的事物的使用说明，该地址指示URL权限的更改，而无需进行其他验证（如网络管理员的审查）。当新事物呈现某种形式的未经验证的MUD URL时，应该通过一些外部手段对其进行验证，以增加对网络的访问。
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.
流氓制造商可能会不适当地使用MUD文件解析器，以利用漏洞进行攻击。有两种建议的方法来应对这一威胁。第一个是验证MUD文件的签名者是否为MUD管理器所知并受其信任。第二种方法是让系统对文件进行主扫描，以确保文件在某种程度上是可解析和可信的。首先，MUD文件可能相对较小。任何给定事物使用的ACE数量也应该相对较少。将MUD URL的检索限制在那些已知具有良好的web或域声誉的站点也可能有用。
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
使用URL需要使用域名。如果域名更改所有权，则该域的新所有者可能能够提供泥管理者认为有效的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.
管理员应该缓存MUD文件服务器使用的证书。无论出于何种原因检索新证书时，MUD管理器都应检查域的所有权是否已更改。当域的名称服务器发生更改时，这是一个公平的编程近似值。如果实际的MUD文件已更改，MUD管理器可能会检查WHOIS数据库，以查看域的注册所有权是否已更改。如果发生了变化，或者由于某种原因无法确定所有权是否发生了变化，则可能需要进一步审查。注意，这种补救措施不考虑很久以前生产、最近才投入使用的产品，也不考虑安装了新泥浆管理器的情况。
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.
某个东西发布的MUD URL揭示了该东西是什么，并为攻击者提供了关于可能存在哪些漏洞的指导。
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.
虽然MUD URL本身并不是特定事物所独有的，但URL的发布可能有助于观察者在与其他信息结合时识别个人。这是对隐私的考虑。
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].
在解决这两个问题时，实现者应该考虑他们通过多播DNS（MDN）[RFC6872]等机制宣传的其他信息；一个事物如何被识别，也许是通过它连接到网络时的行为；以及一件物品是否打算供个人使用或携带个人识别信息，然后应用适当的数据最小化技术。一种方法是利用技经评估组[RFC7170]作为与网络中经授权的组成部分共享信息的手段。网络元件还可以通过使用DHCPv6屏蔽[RFC7610]等机制来帮助限制对MUD URL的访问。
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.
MUD管理器本身存在被监视的风险，以确定哪些东西连接到网络。为了解决这一风险，MUD经理可以选择使用他们信任的TLS代理来聚合其他信息。
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.
请注意，[RFC8407]第3.7节中提到的安全注意事项不适用于这种情况，因为YANG序列化不打算通过NETCONF访问。但是，对于那些试图通过网络配置协议（NETCONF）在网元中实例化此模型的人来说，本文档中每个模型中的所有对象都显示出与[RFC8519]类似的安全特性。MUD的基本目的是配置访问，因此就其本质而言，如果被未授权方使用，它可能会造成破坏。
The following YANG modules have been registered in the "YANG Module Names" registry:
以下YANG模块已在“YANG模块名称”注册表中注册：
Name: ietf-mud
URN: urn:ietf:params:xml:ns:yang:ietf-mud
Prefix: ietf-mud
Registrant contact: The IESG
Reference: RFC 8520
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 8520
Name: ietf-acldns
URI: urn:ietf:params:xml:ns:yang:ietf-acldns
Prefix: ietf-acldns
Registrant contact: The IESG
Reference: RFC 8520
IANA has added the following entries to the "IETF XML registry":
IANA已将以下条目添加到“IETF XML注册表”：
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 acldns注册人联系人：IESG。XML:不适用。请求的URI是XML命名空间。
URI: urn:ietf:params:xml:ns:yang:ietf-mud Registrant Contact: The IESG. XML: N/A. The requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf mud注册人联系人：IESG。XML:不适用。请求的URI是XML命名空间。
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.
IANA已在“动态主机配置协议（DHCP）和引导协议（BOOTP）参数”注册表中分配了选项\u MUD\u URL\u V4（161），并在“IPv6动态主机配置协议（DHCPv6）”注册表中分配了选项\u MUD\u URL\u V6（112），如第10节所述。
IANA has made the following assignments for:
IANA已完成以下任务：
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 “PKIX模块标识符SMI安全”注册表（1.3.6.1.5.5.7.0）中的MudurExtnModule-2016 ASN.1模块（88）。
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 mud url对象标识符（25），来自“用于PKIX证书扩展的SMI安全性”注册表（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 pe mudsigner对象标识符（30），来自“SMI Security for PKIX证书扩展”注册表。
o id-ct-mudtype object identifier (41) from the "SMI Security for S/MIME CMS Content Type" registry.
o id ct mudtype对象标识符（41），来自“S/MIME CMS内容类型的SMI安全性”注册表。
o The use of these values is specified in Section 11.
o 第11节规定了这些值的使用。
The following media type is defined for the transfer of MUD files:
为传输MUD文件定义了以下介质类型：
o Type name: application
o 类型名称：应用程序
o Subtype name: mud+json
o 子类型名称：mud+json
o Required parameters: N/A
o 所需参数：不适用
o Optional parameters: N/A
o 可选参数：不适用
o Encoding considerations: 8bit; "application/mud+json" values are represented as JSON objects; UTF-8 encoding MUST be employed [RFC3629].
o 编码考虑：8位；“application/mud+json”值表示为json对象；必须采用UTF-8编码[RFC3629]。
o Security considerations: See Security Considerations of RFC 8520 and Section 12 of [RFC8259].
o 安全注意事项：参见RFC 8520的安全注意事项和[RFC8259]第12节。
o Interoperability considerations: N/A
o 互操作性注意事项：不适用
o Published specification: RFC 8520
o 已发布规范：RFC 8520
o Applications that use this media type: MUD managers as specified by RFC 8520.
o 使用此介质类型的应用程序：RFC 8520指定的泥浆管理器。
o Fragment identifier considerations: N/A
o 片段标识符注意事项：不适用
o Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A
o 其他信息：幻数：不适用文件扩展名：不适用Macintosh文件类型代码：不适用
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 联系人和电子邮件地址，以获取更多信息：Eliot Lear<lear@cisco.com>，拉尔夫·德罗姆斯<rdroms@gmail.com>，Dan Romascanu<dromasca@gmail.com>
o Intended usage: COMMON
o 预期用途：普通
o Restrictions on usage: none
o 使用限制：无
o Author: Eliot Lear <lear@cisco.com> Ralph Droms <rdroms@gmail.com> Dan Romascanu <dromasca@gmail.com>
o 作者：艾略特·李尔<lear@cisco.com>拉尔夫·德罗姆斯<rdroms@gmail.com>丹·罗马斯卡努<dromasca@gmail.com>
o Change controller: IESG
o 更改控制器：IESG
o Provisional registration? (standards tree only): No.
o 临时登记？（仅限标准树）：否。
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在“IEEE 802编号”下创建了一个名为“IANA链路层发现协议（LLDP）TLV子类型”的新注册表。此注册表的策略为专家评审[RFC8126]。注册表中的最大条目数为256。
IANA has populated the initial registry as follows:
IANA已填充初始注册表，如下所示：
LLDP subtype value: 1 (All the other 255 values are initially marked as "Unassigned".)
LLDP子类型值：1（所有其他255个值最初标记为“未分配”。）
Description: the Manufacturer Usage Description (MUD) Uniform Resource Locator (URL)
描述：制造商使用说明（MUD）统一资源定位器（URL）
Reference: RFC 8520
参考：RFC 8520
The following parameter registry has been added in accordance with [RFC3553].
已根据[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]
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）”注册表中：
"urn:ietf:params:mud:dns" refers to the service specified by [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified by [RFC5905].
“urn:ietf:params:mud:dns”是指[RFC1123]指定的服务。“urn:ietf:params:mud:ntp”是指[RFC5905]指定的服务。
The IANA has established a registry of extensions as follows:
IANA已建立了如下扩展注册：
Registry name: MUD Extensions Registry policy: Standards Action Reference: RFC 8520 Extension name: UTF-8-encoded string, not to exceed 40 characters.
注册表名称：MUD扩展注册表策略：标准操作参考：RFC 8520扩展名称：UTF-8编码字符串，不超过40个字符。
Each extension MUST follow the rules specified in this specification. As is usual, the IANA issues early allocations in accordance with [RFC7120].
每个扩展必须遵循本规范中指定的规则。通常，IANA根据[RFC7120]发布早期分配。
[IEEE8021AB] IEEE, "IEEE Standard for Local and Metropolitan Area Networks-- Station and Media Access Control Connectivity Discovery", IEEE 802.1AB.
[IEEE8021AB]IEEE，“局域网和城域网的IEEE标准——站点和媒体访问控制连接发现”，IEEE 802.1AB。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<https://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<https://www.rfc-editor.org/info/rfc2131>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<https://www.rfc-editor.org/info/rfc3748>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<https://www.rfc-editor.org/info/rfc3987>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<https://www.rfc-editor.org/info/rfc5905>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，DOI 10.17487/RFC5912，2010年6月<https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
[RFC6268]Schaad，J.和S.Turner，“加密消息语法（CMS）和使用X.509（PKIX）的公钥基础设施的额外新ASN.1模块”，RFC 6268，DOI 10.17487/RFC6268，2011年7月<https://www.rfc-editor.org/info/rfc6268>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<https://www.rfc-editor.org/info/rfc6991>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<https://www.rfc-editor.org/info/rfc7120>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<https://www.rfc-editor.org/info/rfc7227>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.
[RFC7610]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6防护：防范恶意DHCPv6服务器”，BCP 199，RFC 7610，DOI 10.17487/RFC7610，2015年8月<https://www.rfc-editor.org/info/rfc7610>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC7951]Lhotka，L.，“用YANG建模的数据的JSON编码”，RFC 7951，DOI 10.17487/RFC7951，2016年8月<https://www.rfc-editor.org/info/rfc7951>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, <https://www.rfc-editor.org/info/rfc8348>.
[RFC8348]Bierman，A.，Bjorklund，M.，Dong，J.，和D.Romascanu，“硬件管理的杨数据模型”，RFC 8348，DOI 10.17487/RFC8348，2018年3月<https://www.rfc-editor.org/info/rfc8348>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415]Mrugalski，T.，Siodelski，M.，Volz，B.，Yourtchenko，A.，Richardson，M.，Jiang，S.，Lemon，T.，和T.Winters，“IPv6动态主机配置协议（DHCPv6）”，RFC 8415，DOI 10.17487/RFC8415，2018年11月<https://www.rfc-editor.org/info/rfc8415>.
[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, <https://www.rfc-editor.org/info/rfc8519>.
[RFC8519]Jethanandani，M.，Agarwal，S.，Huang，L.，和D.Blair，“网络访问控制列表（ACL）的YANG数据模型”，RFC 8519，DOI 10.17487/RFC8519，2019年3月<https://www.rfc-editor.org/info/rfc8519>.
[FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", First Edition, November 1995.
[FW95]Chapman，D.和E.Zwicky，“构建互联网防火墙”，第一版，1995年11月。
[IEEE80211i] IEEE, "IEEE Standard for information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE 802.11i.
[IEEE801I]IEEE，“系统局域网和城域网之间信息技术电信和信息交换的IEEE标准特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：修改件6：介质访问控制（MAC）安全增强”，IEEE 802.11i。
[IEEE8021AE] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE.
[IEEE8021AE]IEEE，“局域网和城域网媒体访问控制（MAC）安全的IEEE标准”，IEEE 802.1AE。
[IEEE8021AR] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR.
[IEEE8021AR]IEEE，“局域网和城域网的IEEE标准-安全设备标识”，IEEE 802.1AR。
[IEEE8021X] IEEE, "IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control", IEEE 802.1X.
[IEEE8021X]IEEE，“局域网和城域网的IEEE标准——基于端口的网络访问控制”，IEEE 802.1X。
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>.
[RFC1984]IAB和IESG，“IAB和IESG关于加密技术和互联网的声明”，BCP 200，RFC 1984，DOI 10.17487/RFC1984，1996年8月<https://www.rfc-editor.org/info/rfc1984>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<https://www.rfc-editor.org/info/rfc3553>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，DOI 10.17487/RFC6092，2011年1月<https://www.rfc-editor.org/info/rfc6092>.
[RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, DOI 10.17487/RFC6872, February 2013, <https://www.rfc-editor.org/info/rfc6872>.
[RFC6872]Gurbani，V.，Ed.，Burger，E.，Ed.，Anjali，T.，Abdelnur，H.，和O.Festor，“会话启动协议（SIP）的通用日志格式（CLF）：框架和信息模型”，RFC 6872，DOI 10.17487/RFC6872，2013年2月<https://www.rfc-editor.org/info/rfc6872>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<https://www.rfc-editor.org/info/rfc7042>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <https://www.rfc-editor.org/info/rfc7170>.
[RFC7170]Zhou，H.，Cam Winget，N.，Salowey，J.，和S.Hanna，“隧道可扩展认证协议（TEAP）版本1”，RFC 7170，DOI 10.17487/RFC7170，2014年5月<https://www.rfc-editor.org/info/rfc7170>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <https://www.rfc-editor.org/info/rfc7452>.
[RFC7452]Tschofenig，H.，Arkko，J.，Thaler，D.，和D.McPherson，“智能对象网络中的架构考虑”，RFC 7452，DOI 10.17487/RFC7452，2015年3月<https://www.rfc-editor.org/info/rfc7452>.
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. Reddy, "Port Control Protocol (PCP) Server Selection", RFC 7488, DOI 10.17487/RFC7488, March 2015, <https://www.rfc-editor.org/info/rfc7488>.
[RFC7488]Boucadair，M.，Penno，R.，Wing，D.，Patil，P.，和T.Reddy，“端口控制协议（PCP）服务器选择”，RFC 7488，DOI 10.17487/RFC7488，2015年3月<https://www.rfc-editor.org/info/rfc7488>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 8343，DOI 10.17487/RFC8343，2018年3月<https://www.rfc-editor.org/info/rfc8343>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.
[RFC8407]Bierman，A.，“包含YANG数据模型的文件的作者和审查者指南”，BCP 216，RFC 8407，DOI 10.17487/RFC8407，2018年10月<https://www.rfc-editor.org/info/rfc8407>.
What follows is the portion of a MUD file that permits DNS traffic to a controller that is registered with the URN "urn:ietf:params:mud:dns" and traffic NTP to a controller that is registered with "urn:ietf:params:mud:ntp". This is considered the default behavior, and the ACEs are in effect appended to whatever other "ace" entries that a MUD file contains. To block DNS or NTP, one repeats the matching statement but replaces the "forwarding" action "accept" with "drop". Because ACEs are processed in the order they are received, the defaults would not be reached. A MUD manager might further decide to optimize to simply not include the defaults when they are overridden.
下面是MUD文件的一部分，该部分允许DNS通信到注册了URN“URN:ietf:params:MUD:DNS”的控制器，以及NTP通信到注册了“URN:ietf:params:MUD:NTP”的控制器。这被视为默认行为，ace实际上附加到MUD文件包含的任何其他“ace”条目中。要阻止DNS或NTP，可以重复匹配语句，但将“转发”操作“接受”替换为“删除”。由于ACE是按接收顺序处理的，因此不会达到默认值。泥浆管理器可能进一步决定进行优化，以便在覆盖默认值时不包括默认值。
Four "acl" list entries that implement default MUD nodes are listed below. Two are for IPv4 and two are for IPv6 (one in each direction for both versions of IP). Note that neither the access list name nor the ace name need be retained or used in any way by local implementations; they are simply there for the sake of completeness.
下面列出了实现默认MUD节点的四个“acl”列表项。两个用于IPv4，两个用于IPv6（两个IP版本的每个方向一个）。请注意，本地实现不需要保留或以任何方式使用访问列表名称或ace名称；它们只是为了完整而存在。
"ietf-access-control-list:acls": {
"acl": [
{
"name": "mud-59776-v4to",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "ent0-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv4": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "mud-59776-v4to",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "ent0-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv4": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v4fr",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v4fr",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6to",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6to",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6fr",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6fr",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
Appendix B. A Sample Extension: DETNET-indicator
附录B.A扩展示例：DETNET指示器
In this sample extension, we augment the core MUD model to indicate whether the device implements DETNET. If a device claims not to use DETNET, but then later attempts to do so, a notification or exception might be generated. Note that this example is intended only for illustrative purposes.
在此示例扩展中，我们增加了岩心泥浆模型，以指示设备是否实现了DETNET。如果设备声称不使用DETNET，但随后又尝试使用，则可能会生成通知或异常。请注意，此示例仅用于说明目的。
Extension Name: "Example-Extension" (to be used in the extensions list) Standard: RFC 8520 (but do not register the example)
扩展名：“示例扩展”（将在扩展列表中使用）标准：RFC 8520（但不注册示例）
This extension augments the MUD model to include a single node, using the following sample module that has the following tree structure:
此扩展扩展扩展了MUD模型，使用具有以下树结构的以下示例模块包括单个节点：
module: ietf-mud-detext-example
augment /ietf-mud:mud:
+--rw is-detnet-required? boolean
module: ietf-mud-detext-example
augment /ietf-mud:mud:
+--rw is-detnet-required? boolean
The model is defined as follows:
该模型定义如下：
<CODE BEGINS>file "ietf-mud-detext-example@2019-01-28.yang"
module ietf-mud-detext-example {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example;
<CODE BEGINS>file "ietf-mud-detext-example@2019-01-28.yang"
module ietf-mud-detext-example {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example;
import ietf-mud {
prefix ietf-mud;
}
import ietf-mud {
prefix ietf-mud;
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
Author: Eliot Lear lear@cisco.com
作者：艾略特·李尔lear@cisco.com
Author: Ralph Droms rdroms@gmail.com
作者：拉尔夫·德罗姆斯rdroms@gmail.com
Author: Dan Romascanu
dromasca@gmail.com
";
description
"Sample extension to a MUD module to indicate a need
for DETNET support.";
Author: Dan Romascanu
dromasca@gmail.com
";
description
"Sample extension to a MUD module to indicate a need
for DETNET support.";
revision 2019-01-28 {
description
"Initial revision.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
revision 2019-01-28 {
description
"Initial revision.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
augment "/ietf-mud:mud" {
description
"This adds a simple extension for a manufacturer
to indicate whether DETNET is required by a
device.";
leaf is-detnet-required {
type boolean;
description
"This value will equal 'true' if a device requires
augment "/ietf-mud:mud" {
description
"This adds a simple extension for a manufacturer
to indicate whether DETNET is required by a
device.";
leaf is-detnet-required {
type boolean;
description
"This value will equal 'true' if a device requires
DETNET to properly function.";
}
}
}
<CODE ENDS>
DETNET to properly function.";
}
}
}
<CODE ENDS>
Using the previous example, we now show how the extension would be expressed:
使用前面的示例，我们现在展示如何表示扩展：
{
"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,
"extensions": [
"ietf-mud-detext-example"
],
"ietf-mud-detext-example:is-detnet-required": "false",
"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": [
{
{
"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,
"extensions": [
"ietf-mud-detext-example"
],
"ietf-mud-detext-example:is-detnet-required": "false",
"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"
}
}
]
}
}
"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"
}
}
]
}
}
]
}
}
]
}
}
Acknowledgments
致谢
The authors would like to thank Einar Nilsen-Nygaard, who singlehandedly updated the model to match the updated ACL model, Bernie Volz, Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, Steve Rich, Jim Bieda, Dan Wing, Joe Clarke, Henk Birkholz, Adam Montville, Jim Schaad, and Robert Sparks for their valuable advice and reviews. Russ Housley entirely rewrote Section 11 to be a complete module. Adrian Farrel provided the basis for the privacy considerations text. Kent Watsen provided a thorough review of the architecture and the YANG model. The remaining errors in this work are entirely the responsibility of the authors.
作者要感谢Einar Nilsen Nygaard，他单独更新了模型以匹配更新的ACL模型，Bernie Volz，Tom Gindin，Brian Weis，Sandeep Kumar，Thorsten Dahm，John Bashinski，Steve Rich，Jim Bieda，Dan Wing，Joe Clarke，Henk Birkholz，Adam Montville，Jim Schaad，罗伯特·斯帕克斯为他们提供了宝贵的建议和评论。Russ Housley将第11节完全改写为一个完整的模块。Adrian Farrel为隐私注意事项文本提供了基础。肯特·沃特森（Kent Watsen）对建筑和杨模型进行了全面的回顾。这项工作中的其余错误完全由作者负责。
Authors' Addresses
作者地址
Eliot Lear Cisco Systems Richtistrasse 7 Wallisellen CH-8304 Switzerland
Eliot Lear Cisco Systems Richtistrasse 7 Wallisellen CH-8304瑞士
Phone: +41 44 878 9200
Email: lear@cisco.com
Phone: +41 44 878 9200
Email: lear@cisco.com
Ralph Droms Google 355 Main St., 5th Floor Cambridge, MA 02142 United States of America
Ralph Droms谷歌美国马萨诸塞州剑桥市正街355号5楼，邮编02142
Phone: +1 978 376 3731
Email: rdroms@gmail.com
Phone: +1 978 376 3731
Email: rdroms@gmail.com
Dan Romascanu
丹·罗马斯卡努
Phone: +972 54 5555347
Email: dromasca@gmail.com
Phone: +972 54 5555347
Email: dromasca@gmail.com