跳到主要内容

1. Introduction (简介)

1. Introduction (简介)​

互联网在很大程度上是为通用计算机构建的, 这些设备可以被其所有者用于指定的目的。在 [RFC1984] 中, 人们假设终端设备最有能力保护自己。当典型设备是工作站或大型机时, 这是有意义的, 对于今天的通用计算设备 (包括笔记本电脑、智能手机和平板电脑) 来说, 这仍然是有意义的。

[RFC7452] 讨论了智能对象的设计模式, 并提出了相关问题。那么让我们假设有一组对象, 它们专门不用于通用计算任务。这些设备 (本备忘录称之为 Things) 具有特定目的。因此, 根据定义, 所有其他用途都不是预期的。如果少量通信模式来自这少量用途, 那么这两个陈述的组合可以重新表述为制造商使用描述 (Manufacturer Usage Description, MUD), 可以应用于网络内的各个点。MUD 主要解决对设备的威胁, 而不是将设备作为威胁。然而, 在某些情况下, MUD 可能会在后一种情况下提供一些保护, 这取决于 MUD URL 的通信方式以及设备及其通信的身份验证方式。

在这个上下文中, 我们宽松地使用"制造商"这个概念来指代将说明设备预期如何使用的实体或组织。例如, 在灯泡的上下文中, 这确实可能是灯泡制造商。在具有内置 Linux 堆栈的智能设备的上下文中, 它可能是该设备的集成商。关键点是假设设备本身服务于有限的目的, 并且在该设备的供应链中存在一个组织, 该组织将负责向网络通报该目的。

MUD 的目标是提供以下内容:

  • 将设备上的威胁面大幅减少到制造商预期的那些通信。

  • 提供一种方法, 将网络策略扩展到网络中不断增加的设备类型数量。

  • 提供一种方法, 以比更新系统可能需要的时间更快的方式解决至少某些漏洞。对于不再受支持的系统, 这将尤其如此。

  • 将这种系统的实施成本保持在最低限度。

  • 为制造商提供一种可扩展性方法, 以表达其他设备能力或要求。

MUD 由三个架构构建块组成:

  • 可用于定位描述的 URL;

  • 描述本身, 包括如何解释它; 以及

  • 本地网络管理系统检索描述的方法。

当网络能够以某种方式识别 Things 将与之通信的远程端点时, MUD 最有效。

在本规范中, 我们描述了这些构建块中的每一个以及它们如何一起使用。但是, 它们也可以独立于本规范, 由本地部署用于其自己的目的而单独使用。

1.1. What MUD Doesn't Do (MUD 不做什么)​

MUD 不旨在解决通用计算机的网络授权, 因为它们的制造商无法设想要描述的特定通信模式。此外, 即使是具有单一或少数用途的设备也可能具有非常广泛的通信模式。MUD 本身也不适合它们。

尽管当设备漏洞存在时, MUD 可以为网络管理员提供一些额外的保护, 但它永远不会取代制造商修补漏洞的需要。

最后, 无论制造商在 MUD 文件中指定什么, 这些都不是指令, 而是建议。如何在本地实例化它们将取决于许多因素, 最终将由本地网络管理员决定, 他们必须决定在特定情况下什么是合适的。

1.2. A Simple Example (简单示例)​

灯泡旨在照亮房间。它可以通过网络远程控制, 并且可能使用会合服务 (可以通过智能手机上的应用程序访问)。那么我们可以说关于那个灯泡的是, 所有其他网络访问都是不需要的。它不会联系新闻服务, 也不会与冰箱通话, 它不需要打印机或其他设备。它没有社交网络朋友。因此, 对它应用一个访问列表, 声明它只会连接到单个会合服务, 不会妨碍执行其功能; 同时, 这将允许网络为灯泡和其他设备提供额外的保护层。

1.3. Terminology (术语)​

MUD: 制造商使用描述 (Manufacturer Usage Description)。

MUD file (MUD 文件): 包含基于 YANG 的 JSON 的文件, 该文件描述 Thing 以及相关建议的特定网络行为。

MUD file server (MUD 文件服务器): 托管 MUD 文件的 Web 服务器。

MUD manager (MUD 管理器): 从 MUD 服务器请求并接收 MUD 文件的系统。在处理 MUD 文件后, 它可能会指示相关网络元素进行更改。

MUD controller (MUD 控制器): 过去用于 MUD 管理器的同义词。

MUD URL: MUD 管理器可以用来接收 MUD 文件的 URL。

Thing: 发出 MUD URL 的设备。

Manufacturer (制造商): 配置 Thing 发出 MUD URL 的实体, 以及在 MUD 文件中断言建议的实体。制造商可能并不总是构建 Thing 的实体。例如, 它可能是系统集成商, 甚至是组件提供商。

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释, 当且仅当它们以全部大写字母出现时, 如此处所示。

1.4. Determining Intended Use (确定预期用途)​

预期用途的概念本身并不新鲜。网络管理员每天都应用访问列表来只允许这种使用。Chapman 和 Zwicky 在 [FW95] 中很好地描述了这种白名单的概念。使用启发式方法识别系统类型的分析系统也已存在多年。

Thing 可以同样轻松地告诉网络它需要什么样的访问, 而不用深入了解它是什么样的系统。实际上, 这将是 [RFC7488] 的相反。然而, 在寻求通用解决方案时, 我们假设设备将实现履行其有限目的所需的功能。这是基本的经济约束。除非网络会拒绝访问这样的设备, 否则其开发人员将没有理由向网络提供任何信息。迄今为止, 这种断言一直成立。

1.5. Finding a Policy: The MUD URL (查找策略: MUD URL)​

我们的工作从设备发出通用资源定位符 (Universal Resource Locator, URL) [RFC3986] 开始。此 URL 既用于对设备类型进行分类, 又提供了一种定位策略文件的方法。

MUD URL 必须使用 "https" 方案 [RFC7230]。

在本备忘录中, 定义了三种发出 MUD URL 的方法, 如下所示:

  • DHCP 选项 [RFC2131] [RFC8415], DHCP 客户端使用该选项通知 DHCP 服务器。DHCP 服务器可能会采取进一步的操作, 例如充当 MUD 管理器或将 MUD URL 传递给 MUD 管理器。

  • X.509 约束。IEEE 已开发 IEEE 802.1AR [IEEE8021AR] 以提供基于证书的方法来通信设备特性, 它本身依赖于 [RFC5280]。根据 IEEE 802.1AR 的要求, MUD URL 扩展是非关键的。可以使用各种方法来通信该证书, 包括隧道可扩展身份验证协议 (Tunnel Extensible Authentication Protocol, TEAP) [RFC7170]。

  • 最后, 定义了链路层发现协议 (Link Layer Discovery Protocol, LLDP) 帧 [IEEE8021AB]。

网络可能有其他方法来学习 MUD URL。例如, 某些设备可能已经部署或通信 MUD URL 的能力非常有限, 但它们可以通过某种方式识别, 例如序列号或公钥。在这些情况下, 制造商可能能够将这些标识符映射到特定的 MUD URL (甚至文件本身)。类似地, 对于互联网连接受限或不存在的情况, 可能有可用的替代解析机制。这些机制在本备忘录中没有描述, 但它们是可能的。鼓励实现者允许灵活地学习 MUD URL。

1.6. Processing of the MUD URL (MUD URL 的处理)​

能够这样做的 MUD 管理器应该根据 [RFC7230] 使用 GET 方法 [RFC7231] 检索 MUD URL 和签名文件。它们必须使用 [RFC2818] 第 3.1 节中的规则验证证书。

对 MUD URL 的请求应该包含包含 "application/mud+json" 的 "Accept" 头字段 ([RFC7231], 第 5.3.2 节)、"Accept-Language" 头字段 ([RFC7231], 第 5.3.5 节) 和 "User-Agent" 头字段 ([RFC7231], 第 5.5.3 节)。

MUD 管理器应该自动处理 3xx 响应状态码。

如果 MUD 管理器无法获取 MUD URL, 则可以使用其他方法导入 MUD 文件和相关签名文件。只要可以验证文件的签名, 就可以使用该文件。在这样的环境中, 控制器应该在缓存有效性到期即将到来时警告管理员, 以便他们可以检查新文件。

MUD 管理器在任何给定时间可能无法检索 MUD 文件。如果 MUD 管理器无法检索 MUD 文件, 它应该至少在一段时间内认为现有文件是安全的。一段时间后, 它应该记录它无法检索文件。这种失败可能有非常好的原因, 包括 MUD 管理器处于离线环境、本地互联网连接失败或远程互联网连接失败的可能性。攻击者也可能试图干扰设备的部署。如何处理这种情况是本地决策。

1.7. Types of Policies (策略类型)​

当 MUD URL 被解析时, MUD 管理器检索描述设备设计具有什么样通信的文件。制造商可以为基于云的服务指定特定主机, 或为操作网络内的访问指定某些类。类的示例可能是"指定制造商类型的设备", 其中制造商类型本身仅由 MUD URL 的权限组件 (例如域名) 指示。另一个示例可能是允许或不允许本地访问。就像其他策略一样, 这些可以组合。例如:

  • 允许访问同一制造商的设备

  • 允许通过受约束应用协议 (Constrained Application Protocol, COAP) [RFC7252] 访问控制器

  • 允许访问本地 DNS/NTP

  • 拒绝所有其他访问

打印机可能有这样的描述:

  • 允许访问端口 IPP 或端口 LPD

  • 允许本地访问端口 HTTP

  • 拒绝所有其他访问

这样, 任何人都可以打印到打印机, 但管理界面需要本地访问。

检索的文件旨在与现有网络架构紧密对齐, 以便易于部署。我们使用 YANG [RFC7950], 因为它为网络设备的使用提供了准确和充分的模型。JSON [RFC8259] 被用作序列化格式, 相对于 XML 而言, 具有紧凑性和可读性。可以在更高版本的 MUD 中选择其他格式。

虽然此处给出的策略示例侧重于访问控制, 但这并不是唯一的重点。通过使用清晰的扩展点构建本文档中描述的模型, 可以包括其他描述。经常想到的一个是服务质量。

此处指定的 YANG 模块是 [RFC8519] 的扩展。对该模型的扩展允许制造商表达制造商认为设备正常功能所必需的系统类。指定了两个模块。第一个模块指定了一种在访问控制列表 (Access Control Lists, ACLs) 中使用域名的方法, 以便将控制器置于云中的设备可以使用域名适当授权, 其中这些名称到地址的映射可能会快速变化。

另一个模块将 IP 地址抽象为某些类, 这些类通过本地处理实例化为实际的 IP 地址。通过这些类, 制造商可以指定设备的通信设计方式, 以便网络元素可以由具有本地拓扑知识的本地系统配置。也就是说, 部署填充制造商指定的类。以下抽象映射到零个或多个主机, 如下所示:

Manufacturer (制造商): 由特定制造商制造的设备, 由其 MUD URL 的权限组件标识。

same-manufacturer (同一制造商): 具有相同 MUD URL 权限组件的设备。

controller (控制器): 本地网络管理员允许进入特定类的设备。

my-controller (我的控制器): 旨在作为 Thing 发出的 MUD URL 的控制器的设备。

local (本地): 在某个管理边界内作用域的 IP 地址类。默认情况下, 建议这是本地子网。

"制造商"类可以由制造商轻松指定, 而控制器类最初设想由管理员指定。

因为制造商不知道谁将使用他们的设备, 所以在使用描述中引用的功能相对普遍和成熟是很重要的。出于这些原因, MUD 文件中基于 YANG 的配置仅限于本文档中指定或引用的模块, 或在文档化扩展中指定的模块。

1.8. The Manufacturer Usage Description Architecture (制造商使用描述架构)​

有了这些组件, 我们现在就有了架构的基础。这导致我们使用 ASCII 艺术。

.......................................
.                      ____________   .           _____________
.                     |            |  .          |             |
.                     |    MUD     |-->get URL-->|    MUD      |
.                     |  Manager   |  .(https)   | File Server |
.  End system network |____________|<-MUD file<-<|_____________|
.                             .       .
.                             .       .
. _______                 _________   .
.|       | (DHCP et al.) | router  |  .
.| Thing |---->MUD URL-->|   or    |  .
.|_______|               | switch  |  .
.                        |_________|  .
.......................................

图 1: MUD 架构

在上图中, 交换机或路由器收集 MUD URL 并将其转发到 MUD 管理器 (网络管理系统) 进行处理。这以不同的方式发生, 具体取决于 URL 的通信方式。例如, 在 DHCP 的情况下, DHCP 服务器可能会接收 URL 然后处理它。在 IEEE 802.1X [IEEE8021X] 的情况下, 交换机将通过可扩展身份验证协议 (Extensible Authentication Protocol, EAP) over Radius [RFC3748] 通过证书将 URL 传送到身份验证服务器, 然后该服务器将处理它。一种方法是 TEAP, 如 [RFC7170] 中所述。下面描述了证书扩展。

MUD 文件服务器返回的信息在 Thing 连接期间一直有效。没有到期。但是, 如果 MUD 管理器检测到 Thing 的 MUD 文件已更改, 它应该迅速更新策略, 考虑到部署中所需的任何批准流程。通过这种方式, 可以及时处理制造商的新建议。

MUD 文件服务器 (Web 服务器) 返回的信息在 Thing 连接期间有效, 或按描述中指定的时间有效。因此, 如果 Thing 断开连接, 可以删除交换机中的任何相关配置。类似地, 描述可能会不时刷新, 基于新的能力或通信模式或漏洞。

Web 服务器通常由制造商或代表制造商运行。其域名是在 MUD URL 中找到的权限。对于 Things 无法发出 URL 的遗留情况, 如果交换机能够确定适当的 URL, 它可以代理它。在一个简单的情况下, 它可能在交换机端口上硬编码 MUD URL, 或者从某些可用标识符 (例如 L2 地址或证书哈希) 到 MUD URL 的映射。

在此环境中, MUD 管理器的角色是执行以下操作:

  • 接收 MUD URL,

  • 获取 MUD 文件,

  • 将 MUD 文件中的抽象转换为特定的网络元素配置,

  • 维护和更新抽象的任何所需映射, 以及

  • 使用适当的配置更新网络元素。

MUD 管理器可以是身份验证、授权和计费 (Authentication, Authorization, and Accounting, AAA) 系统或网络管理系统的组件。这些系统内以及从这些系统到网络元素的通信超出了本备忘录的范围。

1.9. Order of Operations (操作顺序)​

如上所述, MUD 包含架构构建块, 因此操作顺序可能会有所不同。但是, 这里有一个明确的预期示例:

  1. Thing 发出 URL。

  2. 该 URL 由最近的交换机转发到 MUD 管理器 (这取决于发出 MUD URL 的方式)。

  3. MUD 管理器从 MUD 文件服务器检索 MUD 文件和签名, 假设它还没有副本。在验证签名后, 它可能会针对 Web 或域声誉服务测试 URL, 并且它可能会根据需要针对这些声誉服务测试文件中的任何主机。

  4. MUD 管理器可能会查询管理员以获得添加 Thing 和相关策略的权限。如果 Thing 是已知的或 Thing 类型是已知的, 它可能会跳过此步骤。

  5. MUD 管理器基于本文档中定义的抽象实例化本地配置。

  6. MUD 管理器配置离 Thing 最近的交换机。其他系统也可能被配置。

  7. 当 Thing 断开连接时, 策略被删除。

最后于 更新