CN115668879A - 使用制造方使用描述文件信号传递IoT设备通信配置的方法和系统 - Google Patents

使用制造方使用描述文件信号传递IoT设备通信配置的方法和系统 Download PDF

Info

Publication number
CN115668879A
CN115668879A CN202180036258.5A CN202180036258A CN115668879A CN 115668879 A CN115668879 A CN 115668879A CN 202180036258 A CN202180036258 A CN 202180036258A CN 115668879 A CN115668879 A CN 115668879A
Authority
CN
China
Prior art keywords
mud
url
server
network element
iot
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180036258.5A
Other languages
English (en)
Inventor
M·范德尔维恩
S·J·巴雷特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
BlackBerry Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BlackBerry Ltd filed Critical BlackBerry Ltd
Publication of CN115668879A publication Critical patent/CN115668879A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种在网络元件处用于使用制造方使用描述(MUD)文件的物联网(IoT)设备的配置的方法，该方法包括从IoT设备接收至少一个MUD统一资源定位符(URL)；基于MUD URL，从网络元件向至少一个MUD服务器发送统一资源指示符；响应于该发送，从MUD服务器接收多个MUD文件；从多个MUD文件创建多个策略，该多个策略对应于正常操作模式和辅助操作模式；以及将多个策略从网络元件转发给网关。

Description

使用制造方使用描述文件信号传递IoT设备通信配置的方法 和系统
技术领域
本公开涉及紧急服务响应，并且具体地涉及向紧急服务提供方提供补充数据。
背景技术
一些物联网(IoT)设备提供必须对紧急服务持续可用的信息。此类设备的示例包括，可以立即向消防部门提供信息的烟雾或火灾警报器、或者可以立即向警察部队提供信息的防盗警报器或入侵检测系统，等等。此类设备在本文中被称为“类1”设备。
然而，其他类型的IoT设备不用于指示安全或安保事件的开始的目的，而是可以在处理紧急事件时提供有用的功能。示例可以包括，能够告知消防员建筑物是否被照亮的灯泡、或者可以能够告知消防部门关于火灾蔓延的方式的温度计，等等。其他情况包括可以控制用于安全的门(防火门)或安保的门(仅允许授权人员进入或退出)的制动器。这种IoT设备在本文中被称为“类2”IoT设备。
类2IoT设备通常连接到通信网络和基于云的应用，但通常不包括对紧急服务可用的功能。
附图说明
参考附图将更好地理解本公开，在附图中：
图1是示出示例物联网通信架构的框图；
图2是示出示例制造方使用描述(MUD)架构的框图；
图3是示出MUD策略取回的数据流图；
图4是示出MUD系统的实例化的数据流图；
图5是示出示例引导远程密钥基础设施(BRSKI)消息流的数据流图；
图6是示出顺序利用MUD和BRSKI的示例的框图；
图7是示出同时利用MUD和BRSKI的示例的框图；
图8是示出IoT设备在正常和紧急操作模式两者下的配置和操作的数据流图；
图9是示出在路由器或网关处发送分开的MUD URL和接收两个策略的数据流图；
图10是示出在路由器或网关处发送单个MUD URL和接收两个策略的数据流图；
图11是示出基于IoT应用服务器处的决定从正常操作模式转变到紧急操作模式的数据流图；
图12是示出基于开关处的决定从正常操作模式转变到紧急操作模式的数据流图；
图13是MUD管理器取回紧急联系信息并在本地域侧添加该信息的数据流图；
图14是原始设备制造方服务器在包括BRSKI和MUD两者的系统中取回和添加紧急联系信息的数据流图；
图15是原始设备制造方服务器在仅包括MUD的系统中取回和添加紧急联系信息的数据流图；以及
图16是根据一个实施例的能够与本文的方法和系统一起使用的简化电子设备的框图。
具体实施方式
本公开提供了一种在网络元件处用于使用制造方使用描述(MUD)文件对物联网(IoT)设备的配置的方法，该方法包括：从IoT设备接收至少一个MUD统一资源定位符(URL)；基于MUD URL，从网络元件向至少一个MUD服务器发送统一资源指示符；响应于该发送，从MUD服务器接收多个MUD文件；从多个MUD文件创建多个策略，该多个策略对应于正常操作模式和辅助操作模式；以及将多个策略从网络元件转发给网关。
本公开还提供了一种用于使用制造方使用描述(MUD)文件对物联网(IoT)设备的配置的网络元件，该网络元件包括：处理器；以及通信子系统，其中网络元件被配置为：从IoT设备接收至少一个MUD统一资源定位符(URL)；基于MUD URL向至少一个MUD服务器发送统一资源指示符；响应于发送统一资源指示符，从MUD服务器接收多个MUD文件；从多个MUD文件创建多个策略，多个策略对应于正常操作模式和辅助操作模式；以及将多个策略从网络元件转发给网关。
本公开还提供了一种计算机可读介质，用于存储用于使用制造方使用描述(MUD)文件对物联网(IoT)设备的配置的指令代码，该指令代码在由网络元件的处理器执行时使网络元件：从IoT设备接收至少一个MUD统一资源定位符(URL)；基于MUD URL向至少一个MUD服务器发送统一资源指示符；响应于发送统一资源指示符，从MUD服务器接收多个MUD文件；从多个MUD文件创建多个策略，多个策略对应于正常操作模式和辅助操作模式；以及将多个策略从网络元件转发给网关。
因此，本公开提供了允许类2IoT设备能够在紧急事件期间与紧急服务直接通信的实施例。根据本公开，“直接通信”意味着类2IoT设备和紧急服务服务器或设备之间的互联网协议(IP)级路由，该路由绕过常规(“正常操作模式”)通信服务器和/或网关。
如下所述，用于通信的一个选项是通过紧急票据交换所(clearinghouse)。但是，票据交换所服务器可能物理地位于远离实际紧急情况，并且需要依靠准确的位置信息才能将数据分发到适当的紧急响应系统。这也是单点故障。
此外，在某些情况下，可能会施加IoT设备需要直接呼叫紧急服务服务器或公共安全接入点(PSAP)的要求和/或架构设计。具体来说，可能期望最小化应用服务器侧的处理负载和延迟，该应用服务器必须接收数据并将其发送到紧急服务。
此外，针对这样的类2设备可能存在网络安全要求，这可能是针对“基于需求的通信”的要求。特别是，“基于需求的通信”意味着这种直接通信应该在正常操作期间被排除，但在紧急情况期间被允许，并且一旦紧急情况结束则不被允许。这样做可以为了最大限度地减少安全问题，包括攻击者试图以未经授权的方式提取IoT设备数据，例如通过冒充或欺骗紧急服务服务器。这样做还可以是为了避免攻击者试图控制IoT设备并使用它们对本地紧急服务服务器或PSAP发起(分布式)拒绝服务((D)DoS)攻击。
约束通信通常经由在网络节点(诸如网关)上实例化的防火墙规则来完成。一个永久开放的“针孔”允许随时与紧急服务进行通信，这将构成一个附加的攻击向量。
因此，根据本公开的实施例，提供方法和系统以在紧急事件期间启用类2IoT设备(诸如传感器和致动器)与(本地)紧急服务之间基于需求的直接通信。为此，可以将IoT设备设计或配置为在紧急的情况下以不同方式操作，例如通过改变通信端点或协议，或者改变设备或其网关处生效的接入控制策略以允许接入其由第一响应器或类似实体收集的数据，或从第一响应器或类似实体取得命令。
紧急通信中的示例设备使用
IoT设备部署在许多垂直领域，包括但不限于智能建筑或家居、公用事业、医疗保健、车辆等。此类IoT设备通过从网络中的另一个节点取得输入或向其发送信息来通信。
IoT设备的行为和通信的模式可能会发生变化，以适应其被部署的区域中出现异常条件的情况。例如，这种异常条件可能是紧急情况或灾难情形。
国际标准化组织/国际电工委员会(ISO/IEC)具有在IEC ISO/IEC JTC1/SC 4130141“Information technology-Internet of Things Reference Architecture(IoTRA)”中定义的参考IoT架构。该架构包含针对建筑物中的紧急情况的用例，其中门被解锁而没有另外的接入控制。例如，此架构指定：
“在如火灾的紧急情况的情况下，消防部门的到来要求建筑物的门被解锁。管理门的接入的安全策略可以利用上下文来补充。此处的上下文是该建筑物当前正在经历紧急情况，并且紧急服务就在附近。
基于这两个上下文输入，该策略可以使系统自动解锁门并提供接入，而无需另外的授权。”
存在其他示例来定义IoT设备在不同上下文中的行为。
在第一示例中，欧洲网络和信息安全局(ENISA)在其2017年11月的文档“BaselineSecurity Recommendations for IoT in the context of Critical InformationInfrastructures”中建议“[GP-TM-30]：确保基于上下文的安全和隐私，反映不同级别的重要性(例如紧急危机、家庭自动化)”。一种解释是，安全/隐私特性针对紧急状态与正常状态应该不同。
在第二示例中，美国国土安全部在其2016年11月的文档“Strategic principlesfor securing IoT”中建议“建立控制以允许制造方、服务提供方和消费者在需要或期望时禁用网络连接或特定端口以启用选择性连接”。解释选择性连接启用的一种方法可能是，当遥测数据超过某个阈值时，可以假设它处于事件中，因此它可以尝试连接/接受来自通常不受允许的其他实体(例如对等方)的传入连接。
在第三示例中，oneM2M在他们的TR-0001V2.4.1，“Use Cases Collection”文档中，包括IoT设备的行为在紧急情形中被改变的几种场景。第一种涉及企业：智能建筑，其中当紧急情形发生时，设备的行为会有所不同，例如门解锁，警报器被触发等。第二种涉及医疗保健：安全的远程患者护理和监测，在其中当紧急情形发生时，急救人员可以被呼叫。第三种涉及公共服务：路灯自动化，其中当紧急车辆在某个近距内被检测时(例如经由接近传感器、从服务器、从其他街道设施(例如交通信号灯))，路灯的亮度可以被改变。
在第四示例中，欧洲电信标准协会(ETSI)提供了文档TR-103 582，“EMTEL；Studyof use cases and communications involving IoT devices in provision ofemergency situations”，2019年7月。该文档包含紧急情形中关于IoT的几种场景。在第一种场景中，IoT设备可以拨打直接紧急电话。在第二种场景中，IoT服务平台运营方可以基于其从IoT设备接收的数据进行紧急呼叫。此类呼叫可能包括来自设备的附加数据。在第三种场景中，紧急服务团队可能会接入他们通常无法接入的预部署的IoT设备。当两个实体(建筑管理和紧急救援队)两者都在服务级(而不是网络/传输级)都具有对设备的接入时，潜在冲突被标记。第三种场景指出接入控制策略中的变化。
票据交换所
在一个用例中，紧急服务团队可以接入预部署的IoT设备控制或数据。紧急服务团队可以包括管理和协调紧急服务操作的成员，并且可以包括事件区域内或附近的紧急任务的成员。示例包括现场急救人员，诸如消防人员、警察、技术和医务人员等。例如，现在参考图1。在图1的实施例中，IoT设备，诸如移动电话112、警报系统114、温度监测系统116、摄像机118，以及用于IoT设备的其他选项可以通过接入点120与IoT网络122通信。IoT网络122可以是远程或短程无线网络或有线网络。在这种情况下，IoT服务平台130连同IoT设备一起可以被预部署以与紧急服务决定方140通信。因此，在私人或公共建筑或具有预部署的基于IoT的安全系统的区域、IoT设备和建筑安全系统可以向紧急服务团队提供附加的有用信息。
如本文所用，票据交换所是符合标准的位置信息服务器(LIS)和附加数据储存库(ADR)，紧急救援人员可以通过门户或通过与PSAP的以有设备和软件的集成来接入。这种票据交换所的一个示例是RapidSOS票据交换所，如例如RapidSOS-Karen Marquez“RapidSOSClearinghouse”，2019年4月中所述。
此外，IoT服务平台是应用、网络和IoT设备之间的智能层。它是标准化功能的一致集合。正如ETSI TR 103 582中所提供的，IoT服务平台被视为用于通信和数据互操作性的使能者。在某些情况下，IoT服务平台可以包括IoT应用服务器。
制造方使用描述
制造方使用描述(MUD)系统包括互联网工程任务组(IETF)定义的架构和数据格式，该系统允许并赋予IoT设备制造方责任以在其设备连接到网络时为此类设备指定意图的通信模式。例如，此架构和数据格式在2019年3月的IETF RFC 8520，“ManufacturerUsage Description Specification”中定义。此类设备作为一部分的网络可以使用此意图为网络的上下文编写接入策略，从而强制执行设备的功能。这种机制预计减少与通信相关的安全事件，保护设备免受外部威胁，而不是试图保护网络免受设备的影响。
预计IoT设备具有非常少的用途，因此它应该具有少量的通信模式。因此，通过提供意图，该方法是可跟踪/可扩展的。此外，假设不允许任何其他通信模式，假设制造方处于最佳位置来说什么是设备应该允许的正常通信。
然后，网络管理员可以能够利用名为“MUD管理器”的逻辑实体基于MUD文件编写本地策略。MUD管理器是在系统管理员的指导下运行的工具和功能块。MUD管理器可以向管理员询问添加物联网“事物”的许可和应该应用于该设备的相关联策略。因此，MUD管理器是逻辑组件。在物理上，MUD管理器提供的功能可以并且经常与单个网络设备中的网络路由器的功能组合。
如本文所用，“策略”包括管理节点网络的管理的规则，包括对进出该网络内部或外部实体的流量的处理(例如，允许或丢弃)。在MUD的上下文中，交换机/路由器使用DNS名称实现基于IP接入控制列表的策略。这样的策略不是MUD文件。该策略由本地部署网络(或IoT服务平台)基于取回的MUD文件中的信息“编写”。
根据IETF RFC 8520，MUD包括三个架构构建块。第一个是可以用于定位描述文件的统一资源定位器(URL)。第二个是描述本身，包括将如何解释它。第三个是本地网络管理系统取回描述的手段。
URL用于对设备类型进行分类(例如在允许设备加入本地网络的决定是基于设备类型而不是唯一设备标识符的情况下)以及提供用以定位接入规则描述文件的手段两者。制造方或类型本身可以简单地由MUD URL的权限分量(诸如域名)指示。MUD URL可以由事物(物联网设备)以至少三种方式发送或“发射”。在第一种方式中，MUD URL可以经由DHCP选项中的动态主机配置协议(DHCP)发送。在第二种方式中，MUD URL可以经由链路层发现协议(LLDP)发送。在第三种方式中，MUD URL可以经由使用IEEE 802.1AR或802.1X标准的消息发送，以将MUD URL嵌入X.509证书扩展中，例如用于IEEE 802.1X认证消息。
由制造方定义的MUD文件描述中的MUD接入规则可以涵盖各种场景，包括但不限于通过云进行通信，例如在一种情况下与IoT服务平台中的给定应用服务器通信。在另一种情况下，MUD文件可以包括用于在本地部署内与相同制造方的其他设备进行通信的规则。其他选项是可能的。
特定协议和端口号还可以针对这些通信中的每个指定。重点是网络接入控制。但是，这些规则可以扩展到其他领域，包括服务质量。
现在参考图2，其显示了IETF RFC 8520中的示例MUD架构。在图2的示例中，MUD架构和格式允许基于由制造方定义的MUD配置文件(profile)来自动化网络接入策略的定义。用以实例化这些配置文件的方法取决于设备被部署的网络域。
在说明书中，MUD文件格式使用又一下一代(YANG)用于格式和JavaScript对象表示法(JSON)用于序列化。
MUD文件中的接入控制列表(ACL)与准备好用于路由器/交换机/网关以强制执行的本地策略之间的转换方法在IETF RFC中未指定。策略中的接入控制条目的示例包括防火墙规则、流规则等。这些规则旨在限制设备(事物)与外部域之间或者设备(事物)与本地网络中其他设备之间的流量。
因此，在图2的示例中，终端系统网络210(或本地IoT部署网络)包括事物220。事物220例如如上所述地发射URL。URL可以由设备制造方在事物220(或IoT设备)中配置。
路由器或交换机222从协议帧提取URL。该URL然后被转发给MUD管理器224。
MUD管理器224从MUD文件服务器230取回MUD文件和签名，假设它还没有副本。MUD管理器224验证签名并测试URL。
MUD管理器224可以向管理员询问用于添加事物220的许可和相关联策略。如果事物已知或事物类型已知，则MUD管理器224可以跳过该步骤。
MUD管理器224基于RFC中定义的抽象来实例化本地配置。
MUD管理器224配置最接近事物220的交换机。其他系统也可以被配置。
当事物220断开连接时，策略可以被移除。
在图2的示例中，人(诸如域管理员)可能参与读取MUD文件和编写要在网络设备处强制执行的策略。
类似地，图3描述了MUD策略取回。在图3的示例中，IoT设备310被示为包括警报器312、相机314、恒温器316和移动设备318。然而，这些仅作为示例提供，并且IoT设备310的其他示例是可能的。
在本领域的示例植入中，参考图3，IoT设备310中的一个IoT设备向网络设备320发送MUD URL，网络设备320可以包括路由器、网关或交换机，以及其他选项。然后MUD URL被转发给与图2中的MUD管理器224相同的MUD控制器330。MUD控制器330然后可以使用MUD文件服务器340来请求和接收策略文件。在一些情况下，MUD控制器330然后可以将策略(诸如接入控制列表)发送回给网络设备320。
在另一个示例中，MUD可以与证书一起使用。对于设备来说，这是传达其配置和MUD文件位置的一种更安全的方式，但与可以配置为IoT设备的一部分的任何数字证书一样，实现成本更高。
例如，嵌入在IoT设备中的X.509证书可以具有扩展(诸如“ext-MUDURL”)，以包含指向对持有证书的设备有效的在线MUD描述的URL。另一个证书扩展可以定义为“ext-MUDsigner”，以标识MUD文件的签名证书的服务器或主题字段。
例如，美国国家标准与技术研究院(NIST)概述了使用现成的IoT和网络盒的概念的证明，称为NIST-MUD，以示出MUD的可行性，并将其发表为NIST SP 1800-15B“SecuringSmall-Business and Home Internet of Things(IoT)Devices；Mitigating Network-Based Attacks Using Manufacturer Usage Description(MUD)”，2019年11月。该发表的图2.4至4与本公开的图4相关。
在图4的实施例中，IoT设备410与路由器411通信。路由器411包括路由器防火墙412、路由器DHCP服务器414、路由器MUD管理器415和路由器数据库416。
此外，云418包括MUD文件服务器419。
如框420所示，设备410连接到网络(例如，有线或无线网络)。此后，DHCP DISCOVER(“DHCP发现”)消息430可以被发送给DHCP服务器414。DHCP DISCOVER消息430包括MUD URL。
DHCP服务器414可以将DHCP OFFER(“DHCP提供”)消息432发送回给设备410。此外，设备410可以向路由器DHCP服务器414发送DHCP REQUEST(“DHCP请求”)消息434并且DHCP服务器414可以发送DHCP ACK(“DHCP确认”)消息436回给IoT设备410，DHCP ACK消息436包括分配的IP地址。
在接收DHCP发现消息430之后，路由器DHCP服务器414可以在消息440中讲MUD URL发送给路由器MUD管理器415。路由器MUD管理器415然后可以使用到路由器数据库416的消息450注册设备的媒体接入控制(MAC)和MUD URL。
此外，路由器MUD管理器415可以向MUD文件服务器419发送https GET MUD文件(https获取MUD文件)消息460。
作为响应，MUD文件服务器419可以在消息462中将MUD文件发送回给路由器MUD管理器415。
此后，路由器MUD管理器415可以向MUD文件服务器419发送https GET MUD签名文件(https获取MUD签名文件)消息470，并作为响应在消息472中接收MUD签名文件。
一旦消息472被接收，路由器MUD管理器415可以在框474处利用签名文件在MUD文件处验证。假设这种验证成功，则路由器MUD管理器415可以在消息480中向路由器发送防火墙412发送防火墙规则。防火墙规则是基于MUD文件中的信息的策略集合。
此后，路由器防火墙412可以安装来自MUD文件的防火墙规则，如框482所示。
引导远程密钥基础设施(BRSKI)
IETF的自动联网集成模型和方法(ANIMA)工作组正在围绕引导远程安全密钥基础设施(BRSKI)开发标准，即“IETF Draft Draft-ietf-anima-bootstr应用ing-keyinfra-38:Bootstr应用ing Remote Secure Key Infrastructures(BRSKI)”，2020年3月。BRSKI标准概述了向设备自动部署身份的手段，使得它们可以在网络上被授权并建立安全通信。这实现了设备的零接触供应，适用于工业IoT和智能家居场景。
所涉及的实体包括：质押(表示设备/客户端的术语)、交换机/路由器、注册方(Registrar)(都在本地域中)、在原始设备制造方(OEM)域中具有制造方授权的签署权限(MASA)和可选所有权跟踪器的制造方。
BRSKI需要认证、授权和记帐(AAA)基础设施，在某些情况下，该基础设施可以与注册方功能组合。安全特性包括在涉及所有方的认证和授权期间使用X.509证书和传输层安全性(TLS)。
利用BRSKI，设备向其受信任的制造方请求凭证(voucher)。注册方转发该凭证请求，获得凭证，并将凭证发送给设备以进行验证。凭证采用标准化格式，并且包含由制造方关于设备和本地部署做出的声明。
在该过程结束时，设备信任本地域(或本地IoT部署网络)并且本地域信任设备。
特别地，现在参考图5。在图5的示例中，设备510可以与注册方512建立临时TLS连接520。
设备510可以向注册方512发送凭证请求530。然后，注册方512可以将消息532中的凭证请求转发给MASA 514。
然后凭证可以在消息534中被提供回给注册方512。然后，注册方512可以在消息536中将凭证转发回给设备510。
该过程然后可以涉及如箭头540所示的TLS连接的验证和如箭头550所示的附加证书授权的下载。
在箭头560处，使用由IETF RFC 7030定义的协议“通过安全传输的登记”，登记被建立。
使用BRSKI和MUD来配置设备和路由器
在某些情况下，有可能使用BRSKI和MUD两者来配置设备和交换机，一个接一个。现在参考图6。在图6的示例中，IoT设备610与包括交换机612、注册方/AAA 614和MUD管理器615的本地域611通信。
此外，OEM域616包括MASA 617和MUD服务器618。
IoT设备610可以首先利用上文关于图5描述的BRSKI过程来配置设备信任，如箭头620所示。在620之后，信任关系在IoT设备610和本地域611之间被建立。
随后，交换机612可以基于例如在上面的图2和3中概述并且在图6的实施例中用箭头630示出的MUD被配置。在630之后，本地域611具有MUD文件并且交换机可以被配置有基于MUD文件的策略。
在其他一些示例中，BRSKI和MUD可以一起使用以配置IoT设备和路由器/交换机两者。现在参考图7。
在图7的示例中，IoT设备710可以与本地域711通信，本地域711包括交换机712、注册方/AAA 714和MUD管理器715。
此外，OEM域716包括MASA 717和MUD服务器718。
在图7的示例中，利用BRSKI过程配置设备信任用箭头720示出，并且包括利用MUD配置交换机，如箭头730所示。
方面：对MUD系统的修改
基于以上所述，MUD及其相关联的协议是根据OEM对IOT设备的愿景来配置网络以支持该设备的常用方法。BRSKI是IETF定义的一种方法，用于基于制造方安装的设备证书和信任根来自动化本地域密钥基础设施的引导。两者都用于在载入时配置IoT设备的任务。
然而，这些协议没有定义如何配置交换机/路由器和其中的防火墙以支持具有正常通信模式和辅助(例如紧急/异常)操作模式两者的IOT设备。此外，没有定义用于将配置从正常操作模式更改为辅助操作模式(反之亦然)的触发(trigger)，也没有定义应该如何用信号发送这样的触发以及什么实体决定该触发是否被满足。
此外，协议没有定义系统如何确定用于在紧急情况期间使用的适当通信端点的地址。具体而言，在某些情况下，与IoT设备位置相关的辅助服务器的URL或完全限定域名(FQDN)在OEM侧可能事先不知道。
因此，根据本公开的实施例，在图8的示例中提供了具有三个域的架构。图8所示的流程图涉及三个域，即IoT设备被部署的本地域、IoT OEM域和辅助服务域，在本示例中称为辅助服务器域。
具体地，参考图8，IoT设备810在本地域811内通信。本地域811包括交换机812，在此之上可以存在应用814和潜在触发815。在一些情况下，交换机应用814可以确定触发815是否被满足，使得交换机812可以改变为不同的策略。
本地域811还包括MUD管理器816，其可以与服务器查找功能817交互。例如，服务器查找功能817可以涉及找到本地紧急服务网络的查找。然而，在其他一些情况下，除了紧急服务，本公开可以处理IoT设备具有主操作模式和辅助操作模式的其他异常或情形。在这种情况下，服务器查找817可以涉及查找在IoT设备的辅助操作模式期间与哪个服务器通信。
此外，本地域811可以包括IoT应用服务器818，IOT应用服务器818还可以包括触发819，该触发819指示从主操作模式切换到辅助操作模式(并且也可能在相同或不同的触发中返回到主模式)的条件。
第二域是IoT OEM域820，其可以包括MUD服务器822。
第三域是辅助服务器域824，其可以包括辅助服务器826。例如，辅助服务器域824可以是紧急服务器域。然而，在IoT设备在两种模式下操作的其他一些情况下，辅助服务器域824可以是任何其他服务器，当IoT设备正在其第二模式下操作的同时与该其他服务器的通信可能存在。
IoT设备使用时间有两个阶段。第一阶段是配置阶段，并且第二阶段是操作阶段。
在配置阶段期间，IoT设备810可以在消息830中向MUD管理器816发送MUD URL。
MUD管理器816然后可以向OEM域820MUD服务器822提供统一资源标识符(URI)，如消息832所示。
响应于接收消息832，MUD服务器822可以在消息834中将MUD文件提供回给MUD管理器816，该MUD文件可以包括指示操作模式改变的触发。触发可以包括用于触发操作模式改变的一个或多个条件。
MUD管理器816可以基于在消息834中接收的(多个)MUD文件向交换机812提供/编写常规和辅助(例如异常或紧急)策略两者，如由消息840所示。交换机812可以存储在消息840中接收到的常规策略和辅助策略。交换机812可以存储在消息840中接收的常规和辅助策略两者。
此外，在消息834中接收的触发(其可以是MUD文件的一部分或基于MUD文件)可以在消息842内被提供给IoT应用服务器818。在一些情况下，在消息834中接收的触发也可以被提供给交换机812。
在图8的实施例中，用于紧急网络或其他辅助操作处理网络的标识符、网络地址或位置可以作为来自MUD管理器816的消息844的一部分被提供回给IoT设备810。MUD管理器可以已经从服务器查找功能817获得了该信息。用于紧急网络或其他辅助操作处理网络的标识符、网络地址或位置也可以被提供给交换机812。
此时，用于设置IoT设备810的配置阶段完成。
在操作阶段，IoT设备810可以经由应用常规策略的交换机812向IoT应用服务器818提供如箭头850所示的正常数据流。
在一些情况下，辅助服务器826检测紧急情况或辅助条件，并在消息860中将此用信号发送给IoT应用服务器818。例如，消息860可以包括来自不同于IoT设备810的源的紧急指示(诸如911呼叫指示)。辅助条件860可以包括对IoT应用服务器818的请求，以使来自IoT设备810的数据能够直接流向辅助服务器域824，可能绕过IoT应用服务器818。
基于在消息842中接收到的触发信息，IoT应用服务器818可以基于从IoT设备810接收的数据850、在消息860中接收的其他紧急指示(诸如911呼叫指示)或两者来决定触发条件是否被满足，如框862所示。
如果在框862发现一个或多个触发条件被满足，则IoT应用服务器818可以向IoT设备810发送开始辅助数据流消息864的命令。
此外，IoT应用服务器818可以向交换机812发送消息以打开辅助通信端口，如消息866所示。消息866可以指示交换机812使用辅助策略。
此后，由于触发条件被满足并且辅助通信端口打开，紧急或辅助数据可以从IoT设备810经由应用辅助策略的交换机812流向辅助服务器826，可能绕过IoT应用服务器818，如图8的实施例中由箭头870所示。在一些情况下，辅助数据可以流向IoT应用服务器818和辅助服务器826两者。
因此，图8的实施例提供了用于在网络设备(诸如在IoT设备本地域的交换机)处强制执行的策略，该策略允许在辅助状态(诸如紧急状态)期间IoT设备与辅助服务端点之间的直接通信。例如，直接通信在IoT设备810和辅助服务器826之间被启用，而不必通过IoT应用服务器818传递数据。
一旦紧急或辅助操作条件已经到期，系统可以转变回正常数据流。这可能涉及向IoT应用服务器818提供回触发条件，该IoT应用服务器818然后可以向IoT设备810发送用以恢复正常数据流的命令，并且还向交换机812发送用以关闭紧急或辅助通信端口的命令。与框862处的决定相似，转变回到正常操作的决定可以基于来自辅助服务器域824的指示(例如，紧急情形的结束的指示)、来自IoT设备810的数据或两者。在其他一些情况下，紧急或辅助操作条件可能是时间受限的，并且在该时间到期时，IoT应用服务器可以将本地域和IoT设备810转变回正常数据流。其他选项是可能的。
因此，本文描述的实施例提供了一种解决方案，该解决方案涵盖了当针对IoT发现自己处于紧急或辅助操作情形而在交换机或路由器处需要可允许的通信模式中的改变时的情况。
根据本文描述的实施例，MUD被扩展或修改以支持用于IoT或其他此类设备的两个或更多个配置文件或策略。例如，正常使用配置文件和紧急配置文件可以是两种类型的配置文件。本文的实施例为旨在经由网络路由器、交换机或网关以及MUD管理器通信的设备提供解决方案。为此目的，与当前针对MUD定义的实现相比，MUD被扩展或修改。
在本文描述的实施例的第一方面中，挑战存在于如何配置将支持如下IoT设备的交换机或路由器和防火墙，该IoT设备具有正常通信模式和辅助通信模式两者。根据本公开的实施例，IoT设备可以具有与其相关的两个不同的相关联的MUD文件，并且用信号发送该事实以及辅助配置被获得的方式是本公开的一个方面。
在第一种情况下，除了正常MUD URL之外，第二(以及可选地第三、第四等)URL被添加以由设备发射。例如，这些URL可以在如由制造方配置的IoT设备的证书的另一扩展中携带，或者在另一DHCP扩展中携带，或者在由设备发送的另一个LLDP中携带。每个附加的URL指向指定辅助设备行为的文件的位置，其中此类行为将由MUD服务器以外的某个其他服务器指定。此类其他服务器由第二(或第三、第四等)URL指向，即该服务器托管指定设备的辅助行为的文件。
备选地，如果证书被使用，则制造方证书可以在新字段中指示存在用于辅助上下文的特殊MUD文件，而不是实际URL。在这种情况下，MUD管理器必须找到其他手段来定位这个特殊的MUD文件。
现在参考图9，其示出了用于在路由器或网关处获得多个策略的流程。在图9的实施例中，IoT设备910与路由器或网关912通信。此外，路由器或网关912可以与MUD管理器914通信。
在图9的示例中，在图9的示例中称为MUD服务器916和MUD服务器918的多个MUD服务器可以为不同的操作上下文提供不同的MUD文件。这两个服务器可以被组合在相同的物理网络节点中，或者在逻辑上组合但在物理上是分开的。
具体地，如箭头920所示，IoT设备910发射常规MUD URL。箭头922中描绘的第二个MUD URL也由IoT设备910发射。例如，该发射可以经由对如上所述并且如在IoT设备910和路由器或网关912之间的相应协议中使用的DHCP、LLDP或X.509证书的扩展来完成。这在图9的示例中用箭头924示出。发射可以以各种方式完成。例如，在某些情况下可以在应用层完成。在其他一些情况下，它可能经由QR码完成。在其他一些情况下，发射可以按照手册中打印的方式执行，并且可以经由智能手机手动输入或直接输入到路由器或网关接口中，等等。在这样的情况下，智能手机然后可以连接到网关，使得网关获取MUD URL。
路由器或网关912可以将两个URL转发给MUD管理器1314，如箭头930所示。
MUD管理器914，例如使用HTTPS GET(“HTTPS获取”)请求，可以将这样的请求发送给MUD URL，如箭头940所示。这类似于获得MUD文件的已有过程。
作为响应，MUD服务器916发送回MUD文件，如箭头942所示。
在一方面，MUD管理器914还具有用于辅助(例如紧急)上下文的第二附加URL，并且可以使用这样的URL从由URL指向的服务器获取MUD文件。例如，如由箭头950所示，HTTPSGET请求可以被发送给MUD服务器918，并且作为响应，辅助MUD文件从MUD服务器1318接收，如由箭头952所示。在一些情况下，MUD服务器918可以与MUD服务器916相同。在其他一些情况下，这两个服务器可以是不同的服务器。
在接收如箭头942所示的MUD文件时，MUD管理器914构建如当前执行的正常上下文策略。此外，在接收辅助MUD文件时，如箭头952所示，MUD管理器914为辅助上下文编写策略。例如，这可以是紧急上下文，从IoT设备的角度来看，紧急上下文包括紧急情况期间的环境条件、参数和播放状态。
如由箭头960所示，MUD管理器914向路由器或网关912发送第一策略。此外，MUD管理器914向路由器或网关912发送第二策略(可选地连同触发一起)，如利用箭头962所示。
因此，根据图9的实施例，两个URL被提供，并且两个策略被返回给路由器或网关912。
在另外的实施例中，仅一个URL被使用，并且是MUD服务器具有辅助MUD文件存在的知识。MUD服务器可以在其返回MUD文件时将此信息用信号发送给MUD管理器。现在参考图10。
在图10的实施例中，辅助MUD文件从相同的URL下载。也就是说，MUD文件服务器可以返回与IoT设备相关联的两个或更多个MUD文件中的任何一个或两个MUD文件。在另一选项中，MUD文件服务器可以将正常MUD文件和附加的重定向命令返回给用于辅助使用策略的另一MDU文件服务器。例如，这可以包括为MUD管理器返回辅助URL以获得第二MUD文件。
在最简单的上下文中，正常MUD文件包含用于主使用通信端点和辅助使用通信端点两者的信息。
当没有来自设备的对辅助MUD文件的指示时，MUD管理器可能不知道是否存在用于紧急或辅助使用的MUD文件，直到MUD服务器实际返回两个文件。
因此，在图10的示例中，IoT设备1010与路由器、交换机或网关1012通信。此外，路由器或网关1012可以与MUD管理器1014通信。
在图10的实施例中，主MUD服务器1016连同辅助MUD服务器1018一起存在。
在这种情况下，IoT设备1010发射正常MUD URL，如由箭头1020所示，并且如本领域当前所做的那样。
路由器或网关1012将接收到的URL转发给MUD管理器1014，如本领域当前所做的那样。
MUD管理器1014，例如使用HTTPS GET请求，可以发送MUD URL。这利用箭头1040示出，其中请求被发送到MUD服务器1016。
作为响应，MUD管理器1014接收MUD文件，如利用箭头1042所示。返回的MUD文件可以包含用于指示用于辅助通信端点的参数的扩展，或者可以包含用于获得辅助使用MUD文件的URL。这样的URL可以指向相同服务器上的不同文件(资源)或者可以指向不同的服务器。
备选地，MUD服务器连同原始MUD文件一起发送用于辅助使用的第二MUD文件。
图10的示例示出了扩展包括用于第二MUD服务器的URL的情况。
因此，在图10中的可选步骤中，MUD管理器1014提取用于辅助MUD服务器1018的URL并且例如向辅助MUD服务器1018发送HTTP GET请求，如利用箭头1050所示。
作为响应，MUD管理器1014接收辅助MUD文件，如利用箭头1052所示。MUD服务器1016和MUD服务器1018可以是相同的服务器或可以是不同的服务器。
然后，MUD管理器1014可以构建正常上下文策略，如当前使用在箭头1042处接收的MUD文件所做的那样。MUD管理器1014还可以使用在箭头1052处接收的MUD文件来编写用于辅助上下文的策略。
MUD管理器1014可以向路由器或网关1012发送第一策略，如利用箭头1060所示。MUD管理器1014可以进一步向路由器或网关1012发送第二策略以及可选地发送触发，如箭头1062所示。
对于图9和10的实施例两者，给定的MUD文件服务器托管用于辅助策略的MUD文件。相同的MUD文件服务器可用于正常使用的MUD文件，例如用于所有类型的IoT设备，或者用于来自给定制造方的设备，以及其他选项。在其他一些情况下，正常MUD文件可能来自不同的MUD文件服务器。
触发
从制造方的角度来看，用于辅助上下文的MUD文件可以包含新元素以指示预期使IoT设备改变策略的触发。例如，这种新元素可以被称为“辅助-触发”或“紧急-触发”，以及其他选项。
例如，对于温度传感器，触发可以是140华氏度(60摄氏度)或更高的任何读数。
触发可以具有转变到辅助状态的条件，并且在一些情况下还可以具有转变回到主或正常状态的条件。条件可以相同也可以不同。例如，在某些情况下，温度传感器可能需要具有低于122华氏度(50摄氏度)的读数以恢复到正常状态。
关于这样的触发，触发可以具有触发元素语法。该触发可能是用例特定的，因此MUD文件中的元素本身可能是允许灵活地表达该触发的字符串或某些其他类型的已定义节点/元素。在某些情况下，这样的字符串可能是人类可读的。
作为示例，与IETF MUD文件的称为“systeminfo”的元素具有相同语法的元素可以用于触发。这两者以及其他信息都旨在供人类用户(管理员)使用。这样的其他信息可以包括，例如，设备是否仍被制造方支持，以及其他信息。
这些字段对许多设备是公共的，例如工业IoT场景中的所有类型“X”的传感器，因此接受这种类型的IoT设备到网络上的决定可以对每种设备类型做出一次并且附加设备接受可以被自动化，如下所述。
在一些情况下，触发元素可以被并入到辅助使用策略中，一旦宣布了辅助操作模式(例如紧急的状态)，交换机、路由器或网关就可以强制执行该辅助使用策略。
此外，为了允许网络管理员(诸如那些支持建筑物管理系统的网络管理员)也可以具有对触发设置的控制，在某些情况下，在产生由网络管理员编写的辅助策略时，在辅助使用MUD文件中接收的触发阈值设置可以被补充或被覆写。因此，这允许本地域控制。
例如，制造方可以指示用于其温度计的紧急的状态在读数高于140华氏度(60摄氏度)时存在。但是本地部署中的网络管理员可能会将其覆写为130华氏度(54摄氏度)，因为该IoT设备被部署的设施是受气候控制的。在其他一些情况下，网络管理员可能会指定即使是130华氏度的读数也是不够的，而是一些其他条件必须被满足。例如，温度必须保持在阈值水平15分钟，以及其他选项。
如图8、9或10中提供的，一旦MUD管理器已经从MUD文件或经由其他手段获得触发，其就可以向IoT平台服务器通知用于该设备的触发。该协议可能是应用特定的。
在其他一些情况下，IoT设备可以被配置为知道触发是什么，并且当触发阈值被满足时可以能够采取行动，例如连接到不同的端点(紧急响应服务器)，以及向端点发送相同(如正常使用)或不同的数据。附加地或备选地，IoT设备可以从该端点取得输入(应用层命令)。
备选地，IoT设备可以不知道触发但可以从IoT服务平台取得应用层命令以将数据发送给不同端点。
决定触发被满足可以由IoT设备本身、在某些情况下由路由器、网关或交换机、和/或由IoT平台服务器(例如，来自图8中的IoT应用服务器818)来完成。如果决定是在路由器、网关、交换机或服务器上执行的，那么该实体可能不仅需要知道触发是什么，还需要包括应用层逻辑以能够处理来自设备的数据，并且决定是否保证紧急/辅助条件的宣布，并因此保证策略改变。在IoT平台服务器的情况下，紧急/辅助情况的决定可以备选地独立于任何IoT设备数据做出，诸如但不限于来自辅助服务器域824的911或112呼叫指示或其他人源信息，或者基于外部输入和来自一个或多个IoT设备数据两者。
IoT平台服务器决定触发条件被满足
因此，根据一个实施例，IoT平台服务器(或IoT应用服务器)决定触发条件被满足，并且然后通知设备和交换机。该决定可能基于它从IoT设备接收的数据和/或其他数据。
在这种情况下，触发条件被满足是在IoT服务平台服务器处被决定的。这可能会限制由攻击者控制的设备借此引起紧急状态或其他辅助状态、以及策略改变或此类状态可能引起的任何其他动作的攻击。
特别地，现在参考图11，其示出了IoT设备1110、交换机1112和IoT应用服务器1114之间的流程图，IoT应用服务器1114在本文中也称为IoT服务平台服务器。
在这种情况下，IoT应用服务器1114可以具有关于用于紧急/辅助情形的触发1116的信息。
在正常操作期间，如利用箭头1120所示的正常数据流发生在IoT设备1110和IoT应用服务器1114之间。
IoT应用服务器1114可以确定何时紧急情形或辅助情形可以被宣布，如利用框1130所示。
一旦紧急或辅助情形被宣布，IoT应用服务器1114可以向IoT设备发送消息1140，请求它们切换策略。切换策略允许附加或不同的目的地地址和端口用于数据通信。在图11的实施例中，消息1140被示出为开始紧急数据流。然而，在其他一些情况下，该消息可能是开始辅助条件数据流。在其他一些情况下，如果框1130处的触发是用以恢复正常条件的触发，则消息可以是用以恢复正常数据流。存在其他选项。
IoT应用服务器1114还可以向受影响的路由器/网关发送消息1150以切换策略。这类似于来自图8的消息866。交换机1112可能被要求改变用于其所有设备的策略，即使它所服务的设备实际上都没有满足触发阈值条件。
其策略需要改变的IoT设备可能只是触发它的设备，或者它可能包括网关/路由器下的其他设备。
为了避免竞争条件，IoT设备1110不应该在路由器没有切换策略的情况下切换策略。如果IoT应用服务器1114命令策略改变，则IoT应用服务器1114可能需要通知路由器(交换机1112)和IoT设备1110两者，使得路由器不会丢弃IoT设备1110旨在发送给紧急/辅助服务器的分组。例如，这可以通过在发送给IoT设备1110和交换机1112的消息内包括“激活的时间”来实现，其中“激活的时间”指示两者都应该开始应用新策略的时间。
在IoT应用服务器1114如何使交换机1112改变策略的一个示例中，防火墙供应方可以使应用程序接口(API)对于在交换机1112上和服务器中(例如，IoT应用服务器1114)运行的防火墙配置应用可用。该API可以由正在运行IoT应用的IoT应用服务器1114调用。
最终结果是到紧急通信或辅助通信端点的新数据管道在IoT设备1110处被实例化，如例如在图8的实施例中的箭头870处进行，并且附加地对交换机1112上的接入控制列表进行更新，包括防火墙。一旦用于紧急的另一触发在IoT应用服务器1114处获得，指示紧急/辅助上下文不再存在，则策略可以被切换回针对受影响的设备和交换机的正常使用。在某些情况下，接入控制列表包括通信被允许的IP地址集合。
交换机上的应用层逻辑决定触发条件被满足
在备选实施例中，交换机上的应用层逻辑可以决定触发条件被满足，例如通过拦截来自设备的数据。交换机还通知IoT平台服务器触发条件已经被满足。
特别地，现在参考图12，其示出了IoT设备1210、具有应用层逻辑1214的交换机1212和IoT应用服务器1216(本文也称为IoT服务平台服务器)之间的流程图。
在这种情况下，交换机1212可以具有关于用于紧急/辅助情形的触发1218的信息。
在正常操作期间，如利用箭头1220所示的正常数据流发生在IoT设备1210和IoT应用服务器1216之间。
如果触发1218在交换机1212中被启用，这发生在交换机1212具有使其能够基于其从设备1210接收的传感器数据宣布紧急状态的应用知识的部署中，则交换机1212在框1230做出触发被满足的决定并改变策略，如由框1232所示，从正常使用策略改变到紧急/辅助使用策略。
交换机1212可以使用应用层信令来通知IoT设备1210改变通信端点，如由消息1240所示。
该实施例中的最终结果是在IoT设备1210处实例化到紧急/辅助通信端点的新数据管道。一旦用于紧急情况的另一触发被获得，指示紧急/辅助上下文不再存在，则策略可以切换回针对该设备的正常使用。
适当的辅助/紧急端点的地址
在本公开的另一实施例中，本地部署域可以找到(多个)适当的紧急/辅助通信服务器，并将该信息添加到在IoT设备找到自己的网络中的交换机/路由器/网关处强制执行的ACL。这样的操作可以由网络管理员来完成。下面描述的实施例将紧急情形用于辅助操作模式。然而，这不是限制性的，并且仅用于说明。
本地紧急/辅助服务器FQDN用于更新ACL。例如，在紧急情况下，IoT部署的交换机/路由器在较高水平上查找紧急服务IP网络(ESInet)FQDN，并将其添加到ACL以用于其紧急使用策略。在某些情况下，这可能需要由交换机上的ACL强制执行实体的某个级别的应用(特别是域名系统(DNS)协议)感知。
在后续的操作中，设备可以被通知ESInet，使得它知道在紧急情况被宣布的情况下将数据发送到哪里。例如，此操作可以使用来自路由器/交换机上的应用层逻辑的应用层消息或经由来自IoT服务平台服务器的应用层消息来完成。
存在用于确定紧急服务地址(FQDN或IP地址)的各种选项。在第一示例中，紧急服务地址可以在本地部署域确定。在第二示例中，紧急服务地址可以在OEM云或OEM域中确定。之后，上面关于图8描述了如何处理这些信息。
因此，在本实施例的一个方面，引入了基于位置来查找本地ESInet/PSAP的实体或功能块，称为“ESInet查找功能”或“服务器查找”功能。这样的实体可以部署在本地域(“内部”)或OEM云处，并且查找可以由网络管理员完成。
具体地，紧急信息(诸如PSAP和包括FQDN的ESInet域名)取决于设备所在的地区或地理区域。此信息在制造方站点处或部署站点处取回，例如由MUD管理器、BRSKI注册方或由第三实体。
此外，紧急服务器的FQDN/URL可以由设备或由MUD管理器使用用于构造FQDN/URL的潜在标准化方法来构造。构造的FQDN/URL可以针对每个地理地区被定制，例如通过将针对该特定位置的国家名称插入到具有规定元素的字符串中。这可能类似于在第三代合作伙伴项目(3GPP)中使用的方法，其中紧急号码(如与IP地址相对的)可以通过使用3GPP TS23.003中定义的FQDN构造经由DNS查询获得，例如使用逗号分隔标签的字符串：“sos.en.epc.mcc<MCC>.visited-cou ntry.pub.3gppnetwork.org”，其中MCC是3GPP电话中使用的移动国家代码。
在本实施例的第一种情况下，紧急端点(或其他辅助端点)服务器地址信息是在本地部署处确定的。在这种情况下，紧急MUD文件的URL，或将被用于构建紧急策略的用于紧急的通信端点，在MUD供应的正常过程中没有给出。但是，这种策略在某处存在的指示可能已经给出，但该文件的确切位置(URI)没有给出。即，MUD管理器的任务是找到紧急通信端点信息，从其制定本地策略。
在本实施例的第二种情况下，紧急端点服务器地址信息可以在制造方域处确定。在这种情况下，不使用MUD URL，但OEM可以返回MUD文件，该MUD文件补充有辅助端点信息，诸如用于本地域的ESInet和/或PSAP信息。OEM使用通常由BRSKI注册方或MUD管理器相应地在引导或载入过程中发送给OEM服务器的消息中搭载的信息，找出有问题的IoT的本地域。
具体地，当BRSKI用于引导设备时，它使本地域能够安全地为设备配置该设备可以在通信中使用的信息和凭证。MUD功能类似地提供了用于在本地域中进行交换机/路由器的对应配置的机制。由于IoT设备和交换机/路由器两者都需要被配置为支持通信，因此，有可能BRSKI(设备配置)功能可以由MUD(路由器配置)功能利用，反之亦然。因此，如果BRSKI注册方确定了辅助服务器的地址，诸如IoT设备的配置所需的ESInet服务器，则该信息也可以对MUD管理器可用以用于配置路由器，反之亦然。
在上文中，本地紧急联系方是指本地相关的(多个)ESInet服务器和/或PSAP地址，包括IP地址、URL和/或SIP URI等。ESInet的地域范围可以从“本地”(作为单个PSAP、县或小呼叫中心区域)到地区、国家和国际。
ESInet信息和PSAP信息两者都可以是FQDN、URL或URI。该信息在给定地理区域的情况下被取回，并且可以被存储在OEM云和/或本地部署处。
此外，域可以跨越多个区域，包括地区或国家。对于紧急情况，DNS查找可以返回本地服务器IP地址，以处理针对该地区或地理区域的紧急呼叫。
因此，基于以上所述，紧急信息可以在部署网络处或在OEM云处被添加。
在部署网络处添加的紧急信息
根据本实施例的这个方面，该解决方案基于MUD。它包括MUD管理器，该MUD管理器查找本地ESInet或辅助服务器，并且然后将该信息包括在接入控制列表或防火墙设置中，作为IoT设备的载入的一部分。
现在参考图13，其示出了来自图8的消息830、832、834、840和844的更详细视图。在图13的实施例中，IoT设备1310与本地域1311通信。在本地域1311内，存在交换机1312和MUD管理器1316。
服务器查找功能1317可以包括ESInet查找。
此外，OEM域1320包括MUD服务器1322。
对于紧急服务示例，紧急联系方是本地相关的(多个)ESInet服务器和/或PSAP地址，包括但不限于IP地址、SIP URI以及其他选项。这些可以通过由特殊实体(诸如服务器查找实体1317)或由MUD管理器本身查找或存储而在MUD管理器1316处被获知。
图13的实施例中概述的过程开始于IoT设备1310在消息1330中向MUD管理器1316发送MUD URL。消息1330可以经由交换机1312发送。
MUD管理器1316获得MUD文件，该MUD文件在一些情况下可以包括触发。这是通过在消息1332中向MUD服务器1322发送URI并在来自MUD服务器1322的消息1334中接收MUD文件和可能地接收触发来完成的。
MUD管理器1316可以制定常规或正常使用策略，并且它还可以制定辅助策略(诸如紧急策略)。例如，紧急策略可以通过补充常规使用策略来制定。辅助策略的创建可以基于所存储的紧急联系信息或其他辅助信息。这些策略可以在消息1340中被发送给交换机1312。
MUD管理器1316然后可以使用消息1344将ESInet告知IoT设备1310。
在OEM云处添加的紧急(辅助)信息
在一些实施例中，OEM可以具有来自BRSKI的MASA服务器和MUD服务器两者。在其他一些情况下，OEM可以只有MUD服务器，以及可选的辅助服务(例如ESInet)查找功能，该辅助服务查找功能取得地理区域并返回本地相关辅助/紧急服务ESInet或PSAP的FQDN、URL或URI。下面描述的实施例将把紧急服务称为辅助服务。然而，这是非限制性的并且其他形式的辅助服务是可能的。
根据第一种情况，OEM具有MASA服务器和MUD服务器两者。在这种情况下，MASA服务器至少以两种方式之一查找本地相关的ESInet。
第一种方式包括使用ESInet查找功能的直接查找。
第二种方式包括在所有权跟踪器(如果采用)中查找，假设所有权跟踪器记录IoT设备部署网络、位置和用于该位置的ESInet。本地相关ESInet是服务本地域的ESInet，如由BRSKI注册方报告的，或从BRSKI流量的源IP地址的查找获得。MASA服务器将本地紧急FQDN告知MUD服务器，并且MUD服务器将它们包含在MUD文件中。
可选地，当MUD服务器要求MASA服务器查找本地紧急FQDN、URI或URL时，该操作被触发。
现在参考图14，该图示出了一种架构，其中BRSKI注册方和MUD管理器被假设在本地域中进行通信或共址。在图14的示例中，在OEM侧，BRSKI MASA服务器和MUD服务器具有安全通信信道。
此外，在该架构中，“紧急联系方”或“ESInet”是本地相关的(多个)ESInet服务器和/或PSAP地址，包括但不限于IP地址、SIP URI、FQDN、URI或URL等。此外，MASA服务器具有对此类信息的接入，或者能够获得此类信息。
特别地，在图14的实施例中，IoT设备1410与本地域1411通信。本地域1411包括交换机1412、MUD管理器1414和注册方/AAA 1416。
OEM域1420包括MASA服务器1422和MUD服务器1424。
在消息1430，IoT设备1410向MUD管理器1414发送MUD URL。MUD管理器1414然后可以告知BRSKI注册方该MUD URL(未示出)。
在消息1432中，IoT设备1410向注册方/AAA 1416发送BRSKI凭证请求。
注册方/AAA 1416然后可以将凭证(认证)请求1440发送给MASA服务器1422，包含MUD URL和地点。例如，这样的地点可以包括当前的州、省或国家，以及其他这样的地理信息。
MASA服务器然后可以确定IoT设备1410的真实性，如框1442所示。
MASA服务器然后可以针对该地点查找ESInet。这可以例如通过查询所有权跟踪器1426来完成，如利用箭头1442所示。如果用于这样的所有权跟踪器的信息与部署的IoT设备1410的域一起提供，则可以这样做。备选地，或者附加地，它可能涉及查询ESInet(或其他辅助服务器)查找1428，如利用箭头1446所示，例如基于地理地区。
MASA服务器1422然后可以使用MUD URL向MUD服务器1424发送消息1450并且向MUD服务器1424请求用于IoT设备1410的MUD文件。MASA服务器1422可以可选地向MUD服务器1424发送使用箭头1444和/或1446查找的ESInet地址。
然后，MUD服务器1424在消息1452中将MUD文件发送到MASA服务器1422，可选地在MUD文件中包括ESInet地址。
在消息1454中，MASA服务器1422将IoT设备1410的真实性凭证连同MUD文件一起返回给MUD管理器1414。此外，消息1454可能包含紧急联系信息(例如，获得的ESlnet地址)或另一个MUD文件以用于辅助使用。
注册方/AAA 1416使用真实性凭证完成IoT设备1410的认证/授权。
MUD管理器1414为IoT设备1410的交换机1412制定两个策略。一个策略用于常规使用，而另一个策略用于辅助使用。用于辅助使用的策略包括允许在IoT设备和从消息1454获得的辅助服务器联系人(例如ESINet)之间进行通信。在其他实施例中，MUD管理器1412可以将这两个策略组合为一个。然后在消息1460中将常规策略和辅助策略提供给交换机1412。
此外，可以在消息1462中将确定的辅助服务器地址报告给IoT设备1410。
在不存在BRSKI节点的情况下，MUD服务器查找如用于由MUD管理器给出的、或根据提供流量的端点的源IP地址确定的针对地理区域的ESInet地址，例如FQDN、URI、URL和/或SIP URI以及其他选项。然后，MUD服务器将该“紧急联系方”信息包括在用于该设备的MUD文件中，并重新签署该MUD文件。备选地，MUD服务器可以将信息与MUD文件分开地返回给MUD管理器，或者在紧急使用MUD文件中返回。现在参考图15。
在图15的实施例中，IoT设备1510与本地域1511通信。本地域1511包括交换机1512和MUD管理器1514。OEM域1520包括MUD服务器1524。
在图15的示例中，“紧急联系方”是(多个)本地相关ESInet服务器的地址和/或PSAP地址，包括但不限于FQDN、URI、URL、IP地址、SIP电话数字等。MUD服务器1524具有对该信息的接入。
MUD URL从IoT设备1510发送到MUD管理器1514，如由消息1530所示。
然后，MUD管理器1514经由例如HTTPS GET联系OEM域中的MUD服务器1524，并且在消息1540中包括本地域的地点，并且可选地包括设备的标识符。地点可以包括任何地理指示符，包括州、省、国家以及其他选项。
MUD服务器1524从基于由MUD管理器1514提供的位置信息查找此类信息的ESInet/辅助服务器查找实体1528获得本地域紧急信息。备选地，MUD服务器直接从所有权跟踪器1526取得该信息，假设这样的数据库存储了某设备标识符及其部署位置和紧急联系方信息的话；MUD服务器将设备标识符提供给所有权跟踪器，并获得用于该设备的紧急联系信息(例如ESInet)或辅助服务器联系信息。在图15的实施例中，这些查找相应地利用箭头1544和1546示出。
MUD服务器1524然后以各种方式之一结合该ESInet信息。在第一种方式中，MUD服务器1524可以修改MUD文件以添加针对不同辅助服务器的MUD URL。在第二种方式中，MUD服务器可以将紧急/辅助联系信息添加到MUD文件并重新签署该MUD文件。在第三种方式中，MUD服务器1524可以制作新的辅助MUD文件以与原始MUD文件一起返回。其他选项是可能的。
一旦结合了ESInet/辅助服务器信息，MUD服务器1524然后在消息1550中将此信息返回给MUD管理器1514。
遵循用于根据MUD文件编写出策略的IETF RFC 8520的通用过程，MUD管理器1514可以为IoT设备1510的交换机1512制定两个策略。第一策略可以是用于常规使用，另一策略可以是用于辅助使用。在一些情况下，MUD管理器1514可以将两者组合成一个策略，可能在从上面提供的另一MUD文件服务器获取紧急使用MUD文件之后。
然后可以在消息1560中将常规策略和辅助策略提供给交换机1512。
在哪里发起连接
在图7至图15的实施例中，一旦发生紧急情况，设备将需要知道在哪里发起紧急连接。如果设备已经将紧急服务的FQDN作为配置的一部分存储为上述配置的一部分，那么当设备被IoT服务平台服务器指令切换到紧急模式时，此时IoT设备可以执行针对其已经存储的紧急服务的FQDN的DNS查询。路由器或交换机可以嗅探从DNS服务器返回的IP地址，并且然后配置ACL以允许到该地址的连接性。此过程类似于由应用感知防火墙所采用的过程。
在设备没有存储紧急服务的FQDN的情况下，从交换机或路由器或从IoT平台服务器到IoT设备的切换到紧急模式的指令也可以包含本地相关服务IP级实体的(多个)IP地址的URL，该设备被要求现在准备向该本地相关服务IP级实体发送数据。
消息格式
可以应用各种方法来向MUD管理器用信号通知存在针对IoT设备的紧急(辅助)策略，以及如何将其作为IoT设备载入的一部分来取回。在第一选项中，设备带有或发射两个不同的MUD URL，一个用于取回常规操作MUD文件，另一个用于取回紧急/辅助操作MUD文件。然后，MUD管理器可以按任何顺序取回两者。
例如，URL可以是下表1中描述的形式。
常规 “mud-url”:“https://iot-device.example.com/name”
辅助 “mud-url”:“https://iot-device-emergency.example.com/name”
表1：示例MUD URL
在另一个选项中，IoT设备发射MUD URL，但也发射指示紧急策略的存在的另一新数据字段。例如，一个字段可以被称为“emergency-policy-exists(紧急-策略-存在)”。此信息可以在纸质或在线的设备手册中、设备上的标签上、通过附加的QR码、以及其他选项被打印或示出。这个新的数据字段由MUD管理器处理，MUD管理器然后必须找到紧急MUD文件的位置。
根据这些信令选项，在一种情况下，如果DHCP是IoT设备(事物)首先被配置为使用的方式，则MUD管理器根据IoT设备(事物)可以改变它使用DHCP的方式这一事实预知紧急策略的存在。修改是在RFC 8520第10节中定义的DHCP选项可以包含附加在MUD URI字符串之后的空格之后的紧急使用MUD文件的URI，例如如RFC 8520所允许的。
在第二种情况下，如果LLDP是IoT设备(事物)首先被配置为使用的方式，则MUD管理器根据IoT设备(事物)改变它使用LLDP的方式这一事实预知紧急策略的存在。修改将是具有新子类型的扩展。
在第三种情况下，MUD管理器根据IoT设备(事物)呈现包括保存紧急MUD URI的附加扩展的设备证书这一事实预知紧急策略的存在。
实现上述表1的方法所需的信令的具体改变的详细信息现在作为扩展MUD RFC的方式公开。可以对添加新数据字段的方法进行类似的扩展。
在一种情况下，扩展可以经由MUD URL DHCP中的“保留”字符串(1个八位字节)，根据IETF RFC 8520的第10节。具体而言，如果MUD管理器知道紧急使用MUD文件的URL，则DHCP方法按照如下修改。在MUDstring之后的一个空格之后，添加emergencyuseMUDstring，例如如下面的表2中的粗体所示。
代码 len MUDstring emergencyUseMUDstring
表2：示例IPv4 MUD URL DHCP
表2示出了针对IPv4的示例。针对IPv4的备选关于下面的表3，被示出，其添加用于紧急使用MUD字符串(emgergency use MUD string)的新字段。
Figure BDA0003949628980000321
表3：示例IPv4 MUD URL DHCP
对于IPv6，选项关于下表4被示出。
Figure BDA0003949628980000322
Figure BDA0003949628980000331
表4：示例IPv6 MUD URL DHCP
以上因此提供了DHCP选项。
对于LLDP选项，根据IETF RFC 8520，LLDP扩展被定义为保存MUD URL。新的子类型可以针对供应方特定的事件扩展被引入，以携带针对紧急使用MUD文件(或其他辅助使用MUD文件)的新紧急MUD字符串。
对LLDP供应方特定帧的添加关于下表5以粗体示出。
Figure BDA0003949628980000332
表5：用于eMUDstring的示例LLDP供应方特定帧
从以上表5的示例，实际分配的子类型可能不同于2，但不会是1，因为这已经被定义。
对于第三种情况，其中IoT设备(事物)呈现包括针对IEEE 802.1AR证书的新扩展的设备证书。这样的新扩展可以被定义来用信号发送紧急使用MUD文件的存在和可能的位置。通常，这将涉及IETF标准化过程。
参考下面的表6，新的扩展遵循在MUD扩展中定义的扩展。该代码可在IETF RFC8520的第11节中找到，并且添加的扩展在下面的表6中以粗体提供。
Figure BDA0003949628980000333
Figure BDA0003949628980000341
表6：对IEEE 802.1AR证书(certification)的示例扩展(extension)
存在用于用信号发送紧急或辅助MUD文件的存在的备选实施例。在备选的一类方法中，MUD管理器获知需要取回MUD文件，而无需来自IoT设备的此类策略存在的高级信令。
例如，在一种情况下，设备发射如当前指定的MUD URL，但是服务器发回两个分开的MUD文件，一个用于常规条件，另一个用于辅助或紧急条件。
在另一种情况下，设备可以发射当如前指定的一个mud URL，但是从MUD服务器返回给MUD管理器的MUD文件具有附加分开的条目(诸如扩展)用于紧急行为定义。例如，新的字段“mud-emergency-url(mud紧急url)”，和/或新的“from-device-emergency-policy(来自设备紧急策略)”、“to-device-emergency-policy(针对设备紧急策略)”，或者只是“Emergency policy may exist(紧急策略可能存在)”。
在给出URL的情况下，MUD管理器可能还需要再次经由https/GET MUD URL取回该文件。备选地，MUD管理器可能需要找到紧急MUD文件的位置。
触发
关于触发，一个问题是如何在MUD文件中用信号发送紧急触发信息。由于ACL配置高度依赖于防火墙实现，在一种情况下，MUD文件中用信号发送的紧急触发信息是供人类用户(网络管理员)使用的字符串。但是，在其他一些情况下，它可能采用不同的机器可读形式。
因此，MUD文件中的新元素根据对设备可用的数据指示紧急情况的触发。另外，或备选地，可以有两个触发元素：一个用于用信号通知从正常到紧急的转变，而另一个用信号通知从紧急回到正常的转变。
关于下表7，单个触发元素的示例以粗体显示。
Figure BDA0003949628980000351
Figure BDA0003949628980000361
表7：MUD文件中的示例新元素
在上面的表7中提供了显示要向用户显示的文本的示例。
在下表8的示例中，一个触发用于从正常操作模式转变到紧急操作模式。假设相同的触发可用于从紧急操作模式转变为正常操作模式。
改变以粗体显示。
Figure BDA0003949628980000362
Figure BDA0003949628980000371
表8：示例触发备选地，可以存在两个紧急触发，例如如下表9中粗体所示。
Figure BDA0003949628980000372
表9：具有两个紧急触发的示例
虽然上述信令关注于紧急用例，但是对于用于物联网设备的任何其他辅助用例，可以对这种信令进行类似的修改。本公开因此不限于紧急用例。
硬件
执行上述方法的服务器、IoT设备、网关、中继器、交换机、MUD管理器、所有权跟踪器、ESInet查找、MASA服务器、MUDS服务器和电子设备可以是任何电子设备或网络节点。这种电子设备或网络节点可以包括任何类型的计算设备，包括但不限于移动设备，诸如智能手机或蜂窝电话。示例还可以包括固定或移动用户设备，诸如IoT设备、端点、家庭自动化设备、医院或家庭环境中的医疗设备、库存跟踪设备、环境监测设备、能源管理设备、基础设施管理设备、交通工具或用于交通工具的设备、固定电子设备等。交通工具包括机动车辆(例如汽车、轿车、卡车、公共汽车、摩托车等)、飞机(例如飞机、无人驾驶飞行器、无人驾驶飞机系统、无人机、直升机等)、航天器(例如航天飞机、太空航天飞机、太空舱、空间站、卫星等)、船舶(如轮船、船只、气垫船、潜艇等)、有轨交通工具(例如火车和电车等)、行人和自行车以及其他类型的交通工具，包括上述任何一种的任何组合，无论是当前存在的还是之后出现的。
关于图16示出了网络元件或电子设备的一个简化图。
在图16中，设备1610包括处理器1620和通信子系统1630，其中处理器1620和通信子系统1630协作以执行上述实施例的方法。在一些实施例中，通信子系统1620可以包括多个子系统，例如用于不同的无线电和有线技术。
处理器1620被配置为执行可编程逻辑，该可编程逻辑可以与数据一起存储在设备1610上，并且在图16的示例中被示为存储器1640。存储器1640可以是任何有形的、非暂态的计算机可读的存储介质。计算机可读存储介质可以是有形或暂态/非暂态介质，诸如光学(例如，CD、DVD等)、磁性(例如，磁带)、闪存驱动器、硬盘驱动器或本领域已知的其他存储器。
备选地，或者除了存储器1640之外，设备1610可以访问来自外部存储介质的数据或可编程逻辑，例如通过通信子系统1630。
通信子系统1630允许设备1610与其他设备或网络元件通信并且可以基于正在执行的通信的类型而变化。此外，通信子系统1630可以包括多种通信技术，包括任何有线或无线通信技术。
在一个实施例中，设备1610的各种元件之间的通信可以通过内部总线1660。然而，其他形式的通信也是可能的。
本文描述的实施例是结构、系统或方法的示例，其具有与本申请的技术的元素相对应的元素。该书面描述可以使本领域技术人员能够制作和使用具有同样对应于本申请的技术的元素的备选元素的实施例。因此，本申请的技术的预期范围包括与本文所述的本申请的技术没有区别的其他结构、系统或方法，并且还包括与本文所述的本申请的技术没有本质区别的其他结构、系统或方法。
虽然在附图中以特定顺序描绘了操作，但这不应被理解为需要以所示特定顺序或按顺序执行此类操作，或者应执行所有所示操作以获得期望的结果。在某些情况下，可以采用多任务和并行处理。此外，上述实现中各种系统组件的分开不应理解为在所有实现中都需要这种分开，应当理解，所描述的程序组件和系统通常可以一起集成在一个信号软件产品中或封装到多个软件产品中。
此外，在各种实现中描述和图示为分立或分开的技术、系统、子系统和方法可以与其他系统、模块、技术或方法组合或集成。显示或讨论为彼此耦合或直接耦合或通信的其他项可以通过一些接口、设备或中间组件间接耦合或通信，无论是电的、机械的还是其他方式。改变、替换和变更的其他示例是可以由本领域技术人员确定的并且可以做出。
虽然以上详细描述已经示出、描述和指出了应用于各种实现的本公开的基本新颖特征，但是将理解，本领域技术人员可以对所示系统的形式和细节进行各种省略、替换和改变。此外，方法步骤的顺序并不暗示它们在权利要求中出现的顺序。
当向电子设备发送消息/从电子设备发送消息时，这样的操作可能不是立即的或直接来自服务器的。它们可以从支持本文中描述的设备/方法/系统的服务器或其他计算系统基础设施同步或异步传递。前述步骤可以全部或部分地包括去往/来自设备/基础设施的同步/异步通信。此外，来自电子设备的通信可以是到网络上的一个或多个端点。这些端点可以由服务器、分布式计算系统、流处理器等提供服务。内容交付网络(CDN)也可以提供与电子设备的通信。例如，除了典型的服务器响应之外，服务器还可以为内容交付网络(CDN)提供或指示数据以等待在稍后时间(诸如电子设备的随后活动)由电子设备下载。因此，数据可以直接从服务器或其他基础设施(诸如分布式基础设施或CDN)作为系统的一部分或与系统分开发送。
通常，存储介质可以包括以下任何一种或一些组合：半导体存储器设备，诸如动态或静态随机存取存储器(DRAM或SRAM)、可擦可编程只读存储器(EPROM)、电可擦可编程只读存储器(EEPROM)和闪存；磁盘，诸如固定盘、软盘和可移动磁盘；另一种磁性介质，包括磁带；光学介质，诸如光盘(CD)或数字视频光盘(DVD)；或其他类型的存储设备。注意，上面讨论的指令可以在一个计算机可读或机器可读存储介质上提供，或者备选地，可以在分布在可能具有多个节点的大型系统中的多个计算机可读或机器可读存储介质上提供。这样的一个或多个计算机可读或机器可读存储介质被认为是物品(或制品)的一部分。物品或制品可以指任何制造的单个组件或多个组件。一个或多个存储介质可以位于运行机器可读指令的机器中，或者位于可以通过网络从其下载机器可读指令以供执行的远程站点。
在前述描述中，阐述了许多细节以提供对本文公开的主题的理解。然而，可以在没有这些细节中的一些的情况下实践实现。其他实现可以包括对上述细节的修改和变化。所附权利要求旨在涵盖这样的修改和变化。

Claims (19)

1.一种在网络元件处用于使用制造方使用描述(MUD)文件的针对物联网(IoT)设备的配置的方法，所述方法包括：
从IoT设备接收至少一个MUD统一资源定位符(URL)；
基于所述MUD URL，从所述网络元件向至少一个MUD服务器发送统一资源指示符；
响应于所述发送，从所述MUD服务器接收多个MUD文件；
从所述多个MUD文件创建多个策略，所述多个策略对应于正常操作模式和辅助操作模式；以及
将所述多个策略从所述网络元件转发给网关。
2.根据权利要求1所述的方法，其中所述接收至少一个MUD URL包括从所述IoT设备接收第一MUD URL和第二MUD URL；并且
其中所述发送包括基于所述第一MUD URL向第一MUD服务器发送所述统一资源指示符和基于所述第二MUD URL向第二MUD服务器发送所述统一资源指示符。
3.根据权利要求1所述的方法，其中所述接收所述至少一个MUD URL包括接收单个MUDURL；并且
其中所述接收所述多个MUD文件包括接收两个MUD文件。
4.根据权利要求1所述的方法，其中所述接收所述至少一个MUD URL包括接收单个MUDURL；并且
其中所述接收所述多个MUD文件包括：
接收第一MUD文件和所述第一MUD文件内的扩展；
从所述第一MUD文件提取所述扩展；以及
基于所述扩展取回第二MUD文件。
5.根据权利要求1所述的方法，其中所述接收所述多个MUD文件包括接收用以转变到所述辅助操作模式的至少一个触发。
6.根据权利要求5所述的方法，还包括将所述触发转发给应用服务器和所述网关中的一项。
7.根据权利要求1所述的方法，还包括基于所述IoT设备的地理位置来执行针对用于所述辅助操作模式的联系信息的查找。
8.根据权利要求7所述的方法，还包括将所述联系信息从所述网络元件转发给所述IoT设备和所述网关。
9.根据权利要求1所述的方法，其中所述辅助操作模式是紧急服务操作模式。
10.一种用于使用制造方使用描述(MUD)文件的针对物联网(IoT)设备的配置的网络元件，所述网络元件包括：
处理器；以及
通信子系统，
其中所述网络元件被配置为：
从IoT设备接收至少一个MUD统一资源定位符(URL)；
基于所述MUD URL向至少一个MUD服务器发送统一资源指示符；
响应于发送所述统一资源指示符，从所述MUD服务器接收多个MUD文件；
从所述多个MUD文件创建多个策略，所述多个策略对应于正常操作模式和辅助操作模式；以及
将所述多个策略从所述网络元件转发给网关。
11.根据权利要求10所述的网络元件，其中所述网络元件被配置为通过从所述IoT设备接收第一MUD URL和第二MUD URL来接收至少一个MUD URL；并且
其中所述网络元件被配置为通过基于所述第一MUD URL向第一MUD服务器发送所述统一资源指示符和基于所述第二MUD URL向第二MUD服务器发送所述统一资源指示符来发送。
12.根据权利要求10所述的网络元件，其中所述网络元件被配置为通过接收单个MUDURL来接收所述至少一个MUD URL；并且
其中所述网络元件被配置为通过接收两个MUD文件来接收所述多个MUD文件。
13.根据权利要求10所述的网络元件，其中所述网络元件被配置为通过接收单个MUDURL来接收所述至少一个MUD URL；并且
其中所述网络元件被配置为通过以下接收所述多个MUD文件：
接收第一MUD文件和所述第一MUD文件内的扩展；
从所述第一MUD文件提取所述扩展；以及
基于所述扩展取回第二MUD文件。
14.根据权利要求10所述的网络元件，其中所述网络元件被配置为通过接收用以转变到所述辅助操作模式的至少一个触发来接收所述多个MUD文件。
15.根据权利要求14所述的网络元件，其中所述网络元件还被配置为将所述触发转发给应用服务器和所述网关中的一项。
16.根据权利要求10所述的网络元件，其中所述网络元件还被配置为基于所述IoT设备的地理位置来执行针对用于所述辅助操作模式的联系信息的查找。
17.根据权利要求16所述的网络元件，其中所述网络元件还被配置为将所述联系信息从所述网络元件转发给所述IoT设备和所述网关。
18.根据权利要求10所述的网络元件，其中所述辅助操作模式是紧急服务操作模式。
19.一种计算机可读介质，用于存储用于使用制造方使用描述(MUD)文件的针对物联网(IoT)设备的配置的指令代码，所述指令代码在由网络元件的处理器执行时使所述网络元件：
从IoT设备接收至少一个MUD统一资源定位符(URL)；
基于所述MUD URL向至少一个MUD服务器发送统一资源指示符；
响应于发送所述统一资源指示符，从所述MUD服务器接收多个MUD文件；
从所述多个MUD文件创建多个策略，所述多个策略对应于正常操作模式和辅助操作模式；以及
将所述多个策略从所述网络元件转发给网关。
CN202180036258.5A 2020-05-21 2021-04-23 使用制造方使用描述文件信号传递IoT设备通信配置的方法和系统 Pending CN115668879A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/880,252 2020-05-21
US16/880,252 US11533229B2 (en) 2020-05-21 2020-05-21 Method and system for signaling communication configuration for Iot devices using manufacturer usage description files
PCT/CA2021/050561 WO2021232144A1 (en) 2020-05-21 2021-04-23 Method and system for signaling communication configuration for iot devices using manufacturer usage description files

Publications (1)

Publication Number Publication Date
CN115668879A true CN115668879A (zh) 2023-01-31

Family

ID=78608530

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180036258.5A Pending CN115668879A (zh) 2020-05-21 2021-04-23 使用制造方使用描述文件信号传递IoT设备通信配置的方法和系统

Country Status (5)

Country Link
US (2) US11533229B2 (zh)
EP (1) EP4115563A4 (zh)
CN (1) CN115668879A (zh)
CA (1) CA3173415A1 (zh)
WO (1) WO2021232144A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4027608A1 (en) * 2021-01-08 2022-07-13 Advanced Digital Broadcast S.A. A system and method for transmitting data using dns protocol
US20230300130A1 (en) * 2022-03-17 2023-09-21 Nile Global, Inc. Methods and systems for network security

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3786328B2 (ja) * 1998-07-27 2006-06-14 株式会社日立製作所 サーバおよび通信制御方法
US8275352B2 (en) * 2007-06-28 2012-09-25 Apple Inc. Location-based emergency information
US20090024722A1 (en) * 2007-07-17 2009-01-22 International Business Machines Corporation Proxying availability indications in a failover configuration
US8538376B2 (en) * 2007-12-28 2013-09-17 Apple Inc. Event-based modes for electronic devices
US8149262B2 (en) * 2008-04-02 2012-04-03 Freeport Technologies Network management server for managing multiple operating modes of a conferencing network with different sets of policies
US8929875B2 (en) * 2013-05-13 2015-01-06 Lawrence R Youst Wireless communications device having contact specific silent mode disabling capabilities
US20140378089A1 (en) * 2013-06-24 2014-12-25 Serge V. Monros Wireless mobile emergency system
KR20180019771A (ko) * 2013-09-20 2018-02-26 콘비다 와이어리스, 엘엘씨 근접성 서비스 및 사물 인터넷 서비스를 위한 조인트 등록 및 등록 해제 방법
CN105491557B (zh) * 2014-09-15 2020-04-21 中兴通讯股份有限公司 一种实现能力开放的系统、方法及能力开放平台
EP3021257A1 (en) * 2014-11-14 2016-05-18 Soundisplay Limited A sensor utilising overlapping signals and method thereof
US9836386B2 (en) * 2014-12-18 2017-12-05 Red Hat Israel, Ltd. Automatic switch to debugging mode
US9763029B2 (en) * 2015-08-26 2017-09-12 Verizon Patent And Licensing Inc. Bluetooth internet of things sensor network
US10484477B2 (en) * 2015-12-30 2019-11-19 Verizon Patent And Licensing Inc. Internet of things (IoT) device activation and management
US11343226B2 (en) * 2016-02-26 2022-05-24 Cable Television Laboratories, Inc. Systems and methods for micro network segmentation
US10097517B2 (en) * 2016-09-01 2018-10-09 Cybersight, Inc. Secure tunnels for the internet of things
US10609647B2 (en) * 2016-09-29 2020-03-31 Intel IP Corporation Multi-band link-aggregation pre-negotiated power save modes
KR101723984B1 (ko) * 2017-01-31 2017-04-06 (주)그립 ＩｏＴ 게이트웨이 및 그 동작 방법
US10601664B2 (en) * 2017-04-28 2020-03-24 Cisco Technology, Inc. Dynamic network and security policy for IoT devices
US10298581B2 (en) * 2017-04-28 2019-05-21 Cisco Technology, Inc. Zero-touch IoT device provisioning
KR102022265B1 (ko) * 2017-05-22 2019-09-18 (주)에프씨아이 저 전력 모드를 구비한 IoT 장치 및 그것의 동작 방법
US10897475B2 (en) * 2017-08-10 2021-01-19 Cisco Technology, Inc. DNS metadata-based signaling for network policy control
KR102405307B1 (ko) * 2018-01-16 2022-06-07 삼성전자주식회사 전자 장치, 그 제어 방법 및 컴퓨터 판독가능 기록 매체
US11443230B2 (en) * 2018-01-26 2022-09-13 Cisco Technology, Inc. Intrusion detection model for an internet-of-things operations environment
US10841164B2 (en) * 2018-02-09 2020-11-17 Cisco Technology, Inc. Online generation and updates of IoT mud policies
JP6795527B2 (ja) * 2018-02-14 2020-12-02 日本電信電話株式会社 通信システム、及び、サーバ切替方法
US10848495B2 (en) * 2018-02-18 2020-11-24 Cisco Technology, Inc. Internet of things security system
US10581690B2 (en) * 2018-03-15 2020-03-03 Cisco Technology, Inc. Update specific policies for internet of things devices
EP3777339B1 (en) * 2018-03-27 2022-10-05 Telefonaktiebolaget LM Ericsson (publ) Optimized transmission of application data to an iot device
US11025628B2 (en) * 2018-04-17 2021-06-01 Cisco Technology, Inc. Secure modification of manufacturer usage description files based on device applications
EP3565191B1 (en) * 2018-04-30 2021-07-07 Hewlett Packard Enterprise Development LP Provisioning and managing internet-of-thing devices over a network
US10609147B2 (en) * 2018-05-23 2020-03-31 Cisco Technology, Inc. Target wake time and grouping scheme for IoT transmitters
US10884474B2 (en) * 2018-07-19 2021-01-05 Hewlett Packard Enterprise Development Lp Method for managing non-chatty IoT devices to remain in an authenticated state
JP6962476B2 (ja) * 2018-08-06 2021-11-05 日本電気株式会社 通信装置、通信方法、及び、通信プログラム
US10498611B1 (en) * 2018-08-29 2019-12-03 Charter Communications Operating, Llc System architecture and methods for controlling and managing networking devices and expediting new service delivery in a subscriber's home network using micro-domains
US11038814B2 (en) 2018-10-27 2021-06-15 Cisco Technology, Inc. Establishing quality of service for internet of things devices
US11411999B2 (en) * 2018-10-29 2022-08-09 Johnson Controls Tyco IP Holdings LLP Building system with dynamic manufacturer usage description (MUD) files based on building model queries
US20200162517A1 (en) * 2018-11-21 2020-05-21 Cisco Technology, Inc. Method and apparatus to have entitlement follow the end device in network
US20200177485A1 (en) * 2018-12-04 2020-06-04 Cisco Technology, Inc. Network traffic metrics and trends for internet of things management
US20200186383A1 (en) * 2018-12-07 2020-06-11 Hewlett Packard Enterprise Development Lp Networking device as data server for connected iot devices
EP3672159A1 (en) * 2018-12-19 2020-06-24 Orange Internet of things connectivity device and method

Also Published As

Publication number Publication date
US20230086759A1 (en) 2023-03-23
WO2021232144A1 (en) 2021-11-25
CA3173415A1 (en) 2021-11-25
EP4115563A1 (en) 2023-01-11
EP4115563A4 (en) 2023-08-16
US11533229B2 (en) 2022-12-20
US20210367839A1 (en) 2021-11-25

Similar Documents

Publication Publication Date Title
US20220247678A1 (en) Methods, systems, kits and apparatuses for providing end-to-end, secured and dedicated fifth generation telecommunication
US7092943B2 (en) Location based data
US20180013786A1 (en) Systems and methods for mitigating and/or preventing distributed denial-of-service attacks
US20170279803A1 (en) Systems and methods for cloud based unified service discovery and secure availability
US20230086759A1 (en) Method and system for signaling communication configuration for iot devices using manufacturer usage description files
US11411957B2 (en) Broker-coordinated selective sharing of data
Massonet et al. Security in lightweight network function virtualisation for federated cloud and IoT
EP3367289A1 (en) Internet connection setup between computing devices using blockchains
US11681813B2 (en) System and method for enforcing context-based data transfer and access
Rashmi et al. Challenges for convergence of cloud and IoT in applications and edge computing
US20180220477A1 (en) Mobile communication system and pre-authentication filters
Amiri et al. Survey on network access control technology in MANETs
KR20180022565A (ko) 비-ue 관련 시그널링을 지원하는 통신 방법 및 장치
Hu et al. A framework for security on demand
AU2018304187B2 (en) Systems and methods for mitigating and/or preventing distributed denial-of-service attacks
CA2815923A1 (en) Location aware data network
CN117914505A (zh) 控制终端安全访问互联网和内网的方法及设备
CN117579352A (zh) 业务节点的服务访问方法、系统、电子设备及存储介质
KR20150066390A (ko) 비정상 m2m 노드 복구 방법 및 시스템

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination