Method and system for delivering IoT device communication configuration using manufacturer's usage description file signaling

Abstract

A method for configuration of an Internet of Things (IoT) device using a Manufacturer Use Description (MUD) file at a network element, the method comprising receiving at least one MUD uniform resource locator (URL) from the IoT device; sending a uniform resource indicator from the network element to at least one MUD server based on the MUD URL; receiving a plurality of MUD files from the MUD server in response to the sending; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and a secondary operating mode; and forwarding the plurality of policies from the network element to a gateway.

Description

Technical Field

[0001] The present disclosure relates to emergency service response, and in particular to providing supplemental data to emergency service providers. Background Art

[0002] Some Internet of Things (IoT) devices provide information that must be continuously available to emergency services. Examples of such devices include smoke or fire alarms that can immediately provide information to the fire department, or burglar alarms or intrusion detection systems that can immediately provide information to the police force. Such devices are referred to herein as "Class 1" devices.

[0003] However, other types of IoT devices are not used for the purpose of indicating the start of a safety or security event, but can provide useful functions in handling emergency events. Examples include light bulbs that can tell firefighters whether the building is illuminated, or thermometers that can tell the fire department about the way a fire is spreading, etc. Other cases include brakes that can control doors used for safety (fire doors) or security doors (allowing only authorized personnel to enter or exit). Such IoT devices are referred to herein as "Class 2" IoT devices.

[0004] Class 2 IoT devices typically connect to communications networks and cloud-based applications, but typically do not include functionality that would make them available to emergency services. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The present disclosure will be better understood with reference to the accompanying drawings, in which:

[0006] Figure 1 is a block diagram illustrating an example IoT communication architecture;

[0007] Figure 2 is a block diagram illustrating an example Manufacturer Usage Description (MUD) architecture;

[0008] Figure 3 is a data flow diagram illustrating MUD policy retrieval;

[0009] Figure 4 is a data flow diagram illustrating an instantiation of a MUD system;

[0010] Figure 5 is a data flow diagram illustrating an example Bootstrapping Remote Key Infrastructure (BRSKI) message flow;

[0011] Figure 6 is a block diagram illustrating an example of sequentially utilizing MUD and BRSKI;

[0012] Figure 7 is a block diagram illustrating an example of utilizing MUD and BRSKI simultaneously;

[0013] Figure 8 is a data flow diagram illustrating the configuration and operation of an IoT device in both normal and emergency operating modes;

[0014] Figure 9 is a data flow diagram illustrating sending a separate MUD URL and receiving two policies at a router or gateway;

[0015] Figure 10 is a data flow diagram illustrating sending a single MUD URL and receiving two policies at a router or gateway;

[0016] Figure 11 is a data flow diagram illustrating transitioning from a normal operating mode to an emergency operating mode based on a decision at an IoT application server;

[0017] Figure 12 is a data flow diagram illustrating transitioning from a normal operating mode to an emergency operating mode based on a decision at a switch;

[0018] Figure 13 This is the data flow diagram of the MUD manager retrieving the emergency contact information and adding it to the local domain side;

[0019] Figure 14 is a data flow diagram for the OEM server to retrieve and add emergency contact information in the system including both BRSKI and MUD;

[0020] Figure 15 is a data flow diagram for an OEM server to retrieve and add emergency contact information in a system that includes only MUDs; and

[0021] Figure 16 is a block diagram of a simplified electronic device that can be used with the methods and systems herein, according to one embodiment. DETAILED DESCRIPTION

[0022] The present disclosure provides a method for configuring an Internet of Things (IoT) device using a Manufacturer Use Description (MUD) file at a network element, the method comprising: receiving at least one MUD uniform resource locator (URL) from the IoT device; sending a uniform resource indicator from the network element to at least one MUD server based on the MUD URL; receiving a plurality of MUD files from the MUD server in response to the sending; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and a secondary operating mode; and forwarding the plurality of policies from the network element to a gateway.

[0023] The present disclosure also provides a network element for configuring an Internet of Things (IoT) device using a Manufacturer Use Description (MUD) file, the network element comprising: a processor; and a communication subsystem, wherein the network element is configured to: receive at least one MUD uniform resource locator (URL) from the IoT device; send a uniform resource indicator to at least one MUD server based on the MUD URL; receive a plurality of MUD files from the MUD server in response to sending the uniform resource indicator; create a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and an auxiliary operating mode; and forward the plurality of policies from the network element to a gateway.

[0024] The present disclosure also provides a computer-readable medium for storing instruction codes for configuring an Internet of Things (IoT) device using a Manufacturer Use Description (MUD) file, which, when executed by a processor of a network element, causes the network element to: receive at least one MUD uniform resource locator (URL) from the IoT device; send a uniform resource indicator to at least one MUD server based on the MUD URL; receive a plurality of MUD files from the MUD server in response to sending the uniform resource indicator; create a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and an auxiliary operating mode; and forward the plurality of policies from the network element to a gateway.

[0025] Thus, the present disclosure provides embodiments that allow Class 2 IoT devices to communicate directly with emergency services during an emergency event. According to the present disclosure, "direct communication" means Internet Protocol (IP) level routing between the Class 2 IoT device and the emergency services server or device, which bypasses conventional ("normal operating mode") communication servers and / or gateways.

[0026] As described below, one option for communication is through an emergency clearinghouse. However, the clearinghouse server may be physically located far away from the actual emergency and relies on accurate location information to distribute data to the appropriate emergency response system. This is also a single point of failure.

[0027] Furthermore, in some cases, requirements and / or architectural designs may be imposed whereby the IoT device needs to call an emergency services server or public safety access point (PSAP) directly. Specifically, it may be desirable to minimize the processing load and latency on the application server side that must receive the data and send it to the emergency services.

[0028] Additionally, there may be cybersecurity requirements for such Class 2 devices, perhaps requiring "communication on demand." Specifically, "communication on demand" means that such direct communication should be excluded during normal operations, allowed during emergencies, and then disallowed once the emergency is over. This can be done to minimize security issues, including attackers attempting to extract IoT device data in an unauthorized manner, such as by impersonating or spoofing emergency service servers. It can also be done to prevent attackers from attempting to take control of IoT devices and use them to launch (distributed) denial of service ((D)DoS) attacks against local emergency service servers or PSAPs.

[0029] Restricting communications is typically accomplished via firewall rules instantiated on network nodes such as gateways. A permanently open "pinhole" allowing communication with emergency services at any time would constitute an additional attack vector.

[0030] Therefore, according to embodiments of the present disclosure, methods and systems are provided to enable on-demand direct communication between Class 2 IoT devices (such as sensors and actuators) and (local) emergency services during an emergency event. To this end, IoT devices can be designed or configured to operate differently in emergency situations, for example by changing communication endpoints or protocols, or changing access control policies in effect at the device or its gateway to allow access to data collected by first responders or similar entities, or to obtain commands from first responders or similar entities.

[0031] Example device use in emergency communications

[0032] IoT devices are deployed in many verticals including but not limited to smart buildings or homes, utilities, healthcare, vehicles, etc. Such IoT devices communicate by taking input from or sending information to another node in the network.

[0033] The behavior and communication patterns of IoT devices may change to adapt to abnormal conditions in the area they are deployed in. For example, such abnormal conditions may be emergency or disaster situations.

[0034] The International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) has a reference IoT architecture defined in IEC ISO / IEC JTC1 / SC 4130141, "Information technology - Internet of Things Reference Architecture (IoTRA)." This architecture includes use cases for emergency situations in buildings where doors are unlocked without additional access control. For example, this architecture specifies:

[0035] "In the event of an emergency such as a fire, the arrival of the fire department requires that the building's doors be unlocked. The security policy governing access to the doors can be supplemented with context. The context here is that the building is currently experiencing an emergency and the emergency services are nearby.

[0036] Based on these two contextual inputs, the policy can enable the system to automatically unlock the door and provide access without requiring additional authorization.”

[0037] Other examples exist to define the behavior of IoT devices in different contexts.

[0038] In the first example, the European Network and Information Security Agency (ENISA) recommends in its November 2017 document, "Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures," "[GP-TM-30]: Ensure context-based security and privacy, reflecting different levels of criticality (e.g., emergency crisis, home automation)." One interpretation is that security / privacy characteristics should be different for emergency situations than for normal situations.

[0039] In a second example, the U.S. Department of Homeland Security recommends in its November 2016 document, "Strategic principles for securing IoT," that "controls be established to allow manufacturers, service providers, and consumers to disable network connections or specific ports to enable selective connectivity when needed or desired." One way to interpret selective connectivity enablement might be that when telemetry data exceeds a certain threshold, it can assume it is in an event, so it can attempt to connect / accept incoming connections from other entities (e.g., peers) that it would not normally be allowed to connect to.

[0040] In a third example, oneM2M, in their TR-0001 V2.4.1, "Use Cases Collection" document, includes several scenarios where the behavior of IoT devices can be changed in emergency situations. The first relates to enterprise: smart buildings, where devices can behave differently when an emergency occurs, such as doors unlocking, sirens being triggered, etc. The second relates to healthcare: secure remote patient care and monitoring, where first responders can be called when an emergency occurs. The third relates to public services: streetlight automation, where the brightness of streetlights can be changed when an emergency vehicle is detected within a certain close range (e.g., via proximity sensors, from a server, from other street furniture such as traffic lights).

[0041] In a fourth example, the European Telecommunications Standards Institute (ETSI) provides document TR-103 582, “EMTEL; Study of use cases and communications involving IoT devices in provision of emergency situations,” July 2019. The document contains several scenarios for IoT in emergency situations. In the first scenario, an IoT device can make a direct emergency call. In the second scenario, an IoT service platform operator can make an emergency call based on the data it receives from the IoT device. Such a call may include additional data from the device. In a third scenario, the emergency services team may have access to a pre-deployed IoT device that they would not normally be able to access. A potential conflict is flagged when two entities (building management and emergency rescue team) both have access to a device at the service level (rather than the network / transport level). The third scenario points to a change in access control policy.

[0042] Clearing House

[0043] In one use case, an emergency service team can access pre-deployed IoT device control or data. The emergency service team can include members who manage and coordinate emergency service operations and can include members of the emergency mission in or near the incident area. Examples include first responders such as firefighters, police, technical and medical personnel, etc. For example, now refer to Figure 1 .exist Figure 1 In an embodiment, IoT devices such as mobile phones 112, alarm systems 114, temperature monitoring systems 116, cameras 118, and other options for IoT devices can communicate with an IoT network 122 via an access point 120. The IoT network 122 can be a long-range or short-range wireless network or a wired network. In this case, an IoT service platform 130, along with the IoT devices, can be pre-deployed to communicate with emergency service decision-makers 140. Thus, in private or public buildings or areas with pre-deployed IoT-based security systems, the IoT devices and building security systems can provide additional useful information to emergency service teams.

[0044] As used herein, a clearinghouse is a standards-compliant location information server (LIS) and additional data repository (ADR) that emergency responders can access through a portal or through integration with existing devices and software at the PSAP. An example of such a clearinghouse is the RapidSOS Clearinghouse, as described, for example, in RapidSOS - Karen Marquez, "RapidSOS Clearinghouse," April 2019.

[0045] Furthermore, the IoT service platform serves as the intelligent layer between applications, networks, and IoT devices. It is a consistent set of standardized functions. As outlined in ETSI TR 103 582, the IoT service platform is considered an enabler for communication and data interoperability. In some cases, the IoT service platform can include an IoT application server.

[0046] Manufacturer's description

[0047] The Manufacturer Usage Description (MUD) system includes a schema and data format defined by the Internet Engineering Task Force (IETF) that allows and places the responsibility on IoT device manufacturers to specify the intended communication patterns for their devices when they connect to a network. For example, this schema and data format are defined in IETF RFC 8520, "Manufacturer Usage Description Specification," dated March 2019. The network of which the device is a part can use this intent to write access policies for the context of the network, thereby enforcing the device's capabilities. This mechanism is expected to reduce communication-related security incidents and protect devices from external threats, rather than attempting to protect the network from the device itself.

[0048] IoT devices are expected to have very few uses, so they should have a limited number of communication modes. Therefore, by providing intents, this approach is traceable and scalable. Furthermore, assuming no other communication modes are allowed, the manufacturer is in the best position to determine what normal communication the device should allow.

[0049] Network administrators can then leverage a logical entity called a "MUD manager" to write local policies based on the MUD file. The MUD manager is a tool and functional block that runs under the guidance of the system administrator. The MUD manager can ask the administrator for permission to add an IoT "thing" and the associated policies that should be applied to that device. Therefore, the MUD manager is a logical component. Physically, the functionality provided by the MUD manager can be, and often is, combined with the functionality of a network router within a single network device.

[0050] As used herein, "policy" includes the rules governing the management of a network of managed nodes, including the handling (e.g., permitting or dropping) of traffic to and from entities within or outside the network. In the context of MUD, switches / routers implement policies based on IP access control lists using DNS names. Such policies are not MUD files. Instead, the policy is "written" by the on-premises network (or IoT service platform) based on information from a retrieved MUD file.

[0051] According to IETF RFC 8520, a MUD consists of three architectural building blocks. The first is a Uniform Resource Locator (URL) that can be used to locate a description file. The second is the description itself, including how it will be interpreted. The third is a means for a local network management system to retrieve the description.

[0052] The URL is used both to classify the device type (e.g., where the decision to allow a device to join the local network is based on the device type rather than a unique device identifier) and to provide a means to locate the access rule description file. The manufacturer or type itself can simply be indicated by the authority component of the MUD URL (such as a domain name). The MUD URL can be sent or "transmitted" by the thing (the IoT device) in at least three ways. In the first way, the MUD URL can be sent via the Dynamic Host Configuration Protocol (DHCP) in a DHCP option. In the second way, the MUD URL can be sent via the Link Layer Discovery Protocol (LLDP). In the third way, the MUD URL can be sent via a message using the IEEE 802.1AR or 802.1X standards to embed the MUD URL in an X.509 certificate extension, such as for use in IEEE 802.1X authentication messages.

[0053] The MUD access rules in the MUD file description defined by the manufacturer can cover a variety of scenarios, including but not limited to communicating through the cloud, such as communicating with a given application server in an IoT service platform in one case. In another case, the MUD file can include rules for communicating with other devices of the same manufacturer within a local deployment. Other options are possible.

[0054] Specific protocols and port numbers can also be specified for each of these communications. The focus is on network access control. However, these rules can be extended to other areas, including quality of service.

[0055] Now refer to Figure 2 , which shows an example MUD architecture from IETF RFC 8520. Figure 2 In the example of

[0015] , the MUD architecture and format allow for the automation of network access policy definition based on MUD profiles defined by the manufacturer. The method used to instantiate these profiles depends on the network domain in which the device is deployed.

[0056] In the specification, the MUD file format uses Yet Another Next Generation (YANG) for formatting and JavaScript Object Notation (JSON) for serialization.

[0057] The method for translating between the access control lists (ACLs) in the MUD file and the local policies that are enforced by the router / switch / gateway is not specified in the IETF RFC. Examples of access control entries in the policy include firewall rules and flow rules. These rules are intended to restrict the flow of traffic between the device (thing) and external domains, or between the device (thing) and other devices on the local network.

[0058] Therefore, in Figure 2 In the example of FIG, the terminal system network 210 (or the local IoT deployment network) includes a thing 220. The thing 220 transmits a URL, for example, as described above. The URL can be configured in the thing 220 (or IoT device) by the device manufacturer.

[0059] The router or switch 222 extracts the URL from the protocol frame. The URL is then forwarded to the MUD manager 224.

[0060] The MUD manager 224 retrieves the MUD file and signature, assuming it does not already have a copy, from the MUD file server 230. The MUD manager 224 verifies the signature and tests the URL.

[0061] MUD manager 224 may ask the administrator for permission and associated policies for adding thing 220. If the thing is already known or the type of thing is known, MUD manager 224 may skip this step.

[0062] The MUD manager 224 instantiates a local configuration based on the abstractions defined in the RFC.

[0063] The MUD manager 224 configures the switch closest to the thing 220. Other systems may also be configured.

[0064] When the Thing 220 disconnects, the policy may be removed.

[0065] exist Figure 2 In the example of , a person (such as a domain administrator) may be involved in reading the MUD files and writing policies to be enforced at the network devices.

[0066] Similarly, Figure 3 Describes the MUD policy retrieval. Figure 3 In the example of , IoT devices 310 are shown as including an alarm 312, a camera 314, a thermostat 316, and a mobile device 318. However, these are provided merely as examples, and other examples of IoT devices 310 are possible.

[0067] In an exemplary implantation in the art, reference is made to Figure 3, one of the IoT devices 310 sends a MUD URL to the network device 320, which may include a router, gateway, or switch, among other options. The MUD URL is then forwarded to the Figure 2 24. The MUD controller 330 may then request and receive a policy file using the MUD file server 340. In some cases, the MUD controller 330 may then send the policy (such as an access control list) back to the network device 320.

[0068] In another example, a MUD can be used with a certificate. This is a more secure way for a device to communicate its configuration and the location of the MUD file, but like any digital certificate that can be configured as part of an IoT device, it is more expensive to implement.

[0069] For example, an X.509 certificate embedded in an IoT device may have an extension (such as "ext-MUDURL") to contain a URL pointing to an online MUD description valid for the device holding the certificate. Another certificate extension may be defined as "ext-MUDsigner" to identify the server or subject field of the MUD file's signing certificate.

[0070] For example, the National Institute of Standards and Technology (NIST) outlined a proof of concept using off-the-shelf IoT and network boxes, called NIST-MUD, to demonstrate the feasibility of MUD and published it as NIST SP 1800-15B "Securing Small-Business and Home Internet of Things (IoT) Devices; Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)" in November 2019. Figure 2 .4 to 4 with the present disclosure Figure 4 Related.

[0071] exist Figure 4 In the embodiment of FIG. 4 , IoT device 410 communicates with router 411 . Router 411 includes router firewall 412 , router DHCP server 414 , router MUD manager 415 , and router database 416 .

[0072] Additionally, cloud 418 includes a MUD file server 419 .

[0073] Device 410 connects to a network (eg, a wired or wireless network) as shown in block 420. Thereafter, a DHCP DISCOVER message 430 may be sent to DHCP server 414. DHCP DISCOVER message 430 includes the MUD URL.

[0074] DHCP server 414 may send a DHCP OFFER message 432 back to device 410. Additionally, device 410 may send a DHCP REQUEST message 434 to router DHCP server 414 and DHCP server 414 may send a DHCP ACK message 436 back to IoT device 410, including the assigned IP address.

[0075] After receiving DHCP discover message 430, router DHCP server 414 may send the MUD URL to router MUD manager 415 in message 440. Router MUD manager 415 may then register the device's media access control (MAC) and MUD URL using message 450 to router database 416.

[0076] Additionally, router MUD manager 415 may send an https GET MUD file message 460 to MUD file server 419 .

[0077] In response, MUD file server 419 may send the MUD file back to router MUD manager 415 in message 462 .

[0078] Thereafter, router MUD manager 415 may send an https GET MUD signature file message 470 to MUD file server 419 and receive the MUD signature file in message 472 in response.

[0079] Once message 472 is received, router MUD manager 415 may verify the MUD file using the signature file at block 474. Assuming this verification is successful, router MUD manager 415 may send firewall rules to router firewall 412 in message 480. Firewall rules are a set of policies based on the information in the MUD file.

[0080] Thereafter, the router firewall 412 may install the firewall rules from the MUD file, as shown in block 482 .

[0081] Boot Remote Key Infrastructure (BRSKI)

[0082] The IETF's Automated Networking Integration Models and Methods (ANIMA) working group is developing standards for Bootstrapping Remote Secure Key Infrastructures (BRSKI), as outlined in "IETF Draft Draft-ietf-anima-bootstrapping-keyinfra-38: Bootstrapping Remote Secure Key Infrastructures (BRSKI)" published in March 2020. The BRSKI standard outlines a means to automatically provision identities to devices, allowing them to be authorized on the network and establish secure communications. This enables zero-touch device provisioning, suitable for industrial IoT and smart home scenarios.

[0083] The entities involved are: Pledge (a term for the device / client), Switch / Router, Registrar (all in the local domain), Manufacturer with Manufacturer Authorized Signing Authority (MASA) in the OEM domain and an optional ownership tracker.

[0084] BRSKI requires an authentication, authorization, and accounting (AAA) infrastructure, which in some cases can be combined with the registrar functionality. Security features include the use of X.509 certificates and Transport Layer Security (TLS) during authentication and authorization of all parties involved.

[0085] Using BRSKI, a device requests a voucher from its trusted manufacturer. The registrar forwards the voucher request, obtains the voucher, and sends it to the device for verification. The voucher uses a standardized format and contains statements made by the manufacturer about the device and its local deployment.

[0086] At the end of the process, the device trusts the local domain (or local IoT deployment network) and the local domain trusts the device.

[0087] In particular, now refer to Figure 5 .exist Figure 5 In the example of , device 510 can establish a temporary TLS connection 520 with registrar 512 .

[0088] Device 510 may send credential request 530 to registrar 512. Registrar 512 may then forward the credential request in message 532 to MASA 514.

[0089] The credentials may then be provided back to the registrar 512 in message 534. The registrar 512 may then forward the credentials back to the device 510 in message 536.

[0090] The process may then involve verification of the TLS connection as shown by arrow 540 and downloading of an additional certificate authority as shown by arrow 550 .

[0091] At arrow 560, registration is established using the protocol defined by IETF RFC 7030, "Registration over Secure Transport."

[0092] Use BRSKI and MUD to configure devices and routers

[0093] In some cases, it is possible to use both BRSKI and MUD to configure devices and switches, one after the other. Figure 6 .exist Figure 6 In the example of , IoT device 610 communicates with local domain 611 including switch 612 , registrar / AAA 614 , and MUD manager 615 .

[0094] Furthermore, the OEM domain 616 includes a MASA 617 and a MUD server 618 .

[0095] IoT device 610 may first utilize the above Figure 5 The BRSKI process described above is used to configure device trust, as shown by arrow 620. After 620, a trust relationship is established between the IoT device 610 and the local domain 611.

[0096] Subsequently, the switch 612 may be based on, for example, the above Figure 2 and 3 Outlined in and Figure 6 In the embodiment of FIG. 6 , a MUD is configured, as shown by arrow 630. After 630, the local domain 611 has a MUD file and the switch can be configured with a policy based on the MUD file.

[0097] In some other examples, BRSKI and MUD can be used together to configure both IoT devices and routers / switches. Figure 7 .

[0098] exist Figure 7 In the example of , IoT device 710 can communicate with local domain 711, which includes switch 712, registrar / AAA 714 and MUD manager 715.

[0099] Furthermore, OEM domain 716 includes MASA 717 and MUD server 718 .

[0100] exist Figure 7 In the example of , configuring device trust using the BRSKI process is shown by arrow 720 and includes configuring the switch using MUD, as shown by arrow 730.

[0101] Aspect: Modifications to the MUD system

[0102] Based on the above, MUD and its associated protocols are a common method for configuring networks to support IoT devices based on the OEM's vision for the device. BRSKI is an IETF-defined method for automating the bootstrapping of a local domain key infrastructure based on the manufacturer's installed device certificates and trust roots. Both are used for the task of configuring IoT devices at onboarding.

[0103] However, these protocols do not define how to configure switches / routers and the firewalls therein to support IoT devices with both normal communication modes and auxiliary (e.g., emergency / abnormal) operating modes. Furthermore, there is no definition of a trigger for changing the configuration from a normal operating mode to an auxiliary operating mode (or vice versa), nor is there a definition of how such a trigger should be signaled or what entity determines whether the trigger is satisfied.

[0104] Furthermore, the protocol does not define how the system determines the address of the appropriate communication endpoint for use during an emergency. Specifically, in some cases, the URL or fully qualified domain name (FQDN) of the auxiliary server associated with the IoT device location may not be known in advance on the OEM side.

[0105] Therefore, according to the embodiments of the present disclosure, Figure 8 The example in provides a schema with three domains. Figure 8 The flowchart shown involves three domains, namely the local domain where the IoT devices are deployed, the IoT OEM domain, and the auxiliary service domain, which is called the auxiliary server domain in this example.

[0106] Specifically, refer to Figure 8 , IoT devices 810 communicate within a local domain 811. Local domain 811 includes a switch 812, on which may reside applications 814 and potential triggers 815. In some cases, switch application 814 may determine whether trigger 815 is satisfied, so that switch 812 may change to a different policy.

[0107] The local domain 811 also includes a MUD manager 816, which can interact with a server lookup function 817. For example, the server lookup function 817 can involve a lookup to locate a local emergency services network. However, in other cases, in addition to emergency services, the present disclosure can handle other exceptions or situations where an IoT device has a primary and secondary operating mode. In this case, the server lookup 817 can involve a lookup to determine which server to communicate with during the IoT device's secondary operating mode.

[0108] Additionally, the local domain 811 may include an IoT application server 818, which may also include a trigger 819 indicating the conditions for switching from the primary mode of operation to the secondary mode of operation (and possibly also returning to the primary mode in the same or different trigger).

[0109] The second domain is the IoT OEM domain 820 , which may include a MUD server 822 .

[0110] The third domain is an auxiliary server domain 824, which may include auxiliary servers 826. For example, the auxiliary server domain 824 may be an emergency server domain. However, in other cases where the IoT device operates in two modes, the auxiliary server domain 824 may be any other server with which communication may occur while the IoT device is operating in its second mode.

[0111] There are two stages in the use of IoT devices. The first stage is the configuration stage, and the second stage is the operation stage.

[0112] During the configuration phase, the IoT device 810 may send the MUD URL to the MUD manager 816 in a message 830 .

[0113] The MUD manager 816 may then provide a uniform resource identifier (URI) to the OEM domain 820 MUD server 822 , as shown by message 832 .

[0114] In response to receiving message 832, MUD server 822 may provide a MUD file, which may include a trigger indicating a change in operating mode, back to MUD manager 816 in message 834. The trigger may include one or more conditions for triggering a change in operating mode.

[0115] The MUD manager 816 may provide / write both regular and auxiliary (e.g., exception or emergency) policies to the switch 812 based on the MUD file(s) received in message 834, as shown by message 840. The switch 812 may store the regular and auxiliary policies received in message 840. The switch 812 may store both regular and auxiliary policies received in message 840.

[0116] Additionally, the trigger received in message 834 (which may be part of or based on the MUD file) may be provided to the IoT application server 818 within message 842. In some cases, the trigger received in message 834 may also be provided to the switch 812.

[0117] exist Figure 8In an embodiment, an identifier, network address, or location for the emergency network or other auxiliary operations processing network may be provided back to the IoT device 810 as part of a message 844 from the MUD manager 816. The MUD manager may have obtained this information from the server lookup function 817. The identifier, network address, or location for the emergency network or other auxiliary operations processing network may also be provided to the switch 812.

[0118] At this point, the configuration phase for setting up the IoT device 810 is complete.

[0119] During the operation phase, the IoT device 810 may provide a normal data flow as indicated by arrow 850 to the IoT application server 818 via the switch 812 applying normal policies.

[0120] In some cases, the assistance server 826 detects an emergency or assistance condition and signals this to the IoT application server 818 in a message 860. For example, the message 860 may include an emergency indication (such as a 911 call indication) from a source other than the IoT device 810. The assistance condition 860 may include a request to the IoT application server 818 to enable data from the IoT device 810 to flow directly to the assistance server domain 824, potentially bypassing the IoT application server 818.

[0121] Based on the trigger information received in message 842 , the IoT application server 818 may determine whether the trigger condition is met based on data 850 received from the IoT device 810 , other emergency indications (such as a 911 call indication) received in message 860 , or both, as shown in block 862 .

[0122] If one or more triggering conditions are found to be met at block 862 , the IoT application server 818 may send a command to start auxiliary data flow message 864 to the IoT device 810 .

[0123] Additionally, the IoT application server 818 may send a message to the switch 812 to open the auxiliary communication port, as shown in message 866. The message 866 may instruct the switch 812 to use the auxiliary policy.

[0124] Thereafter, as the trigger condition is met and the auxiliary communication port is open, emergency or auxiliary data can flow from the IoT device 810 to the auxiliary server 826 via the switch 812 applying the auxiliary policy, possibly bypassing the IoT application server 818, e.g. Figure 8 In some embodiments, the auxiliary data may flow to both the IoT application server 818 and the auxiliary server 826.

[0125] therefore, Figure 8 Embodiments provide for enforcing policies at network devices (such as switches in the local domain of IoT devices) that allow direct communication between IoT devices and auxiliary service endpoints during auxiliary states (such as emergency states). For example, direct communication is enabled between IoT device 810 and auxiliary server 826 without having to pass data through IoT application server 818.

[0126] Once the emergency or auxiliary operating condition has expired, the system can transition back to normal data flow. This may involve providing a trigger condition back to the IoT application server 818, which can then send a command to the IoT device 810 to resume normal data flow and also send a command to the switch 812 to close the emergency or auxiliary communication port. Similar to the decision at box 862, the decision to transition back to normal operation can be based on an indication from the auxiliary server domain 824 (e.g., an indication of the end of the emergency situation), data from the IoT device 810, or both. In some other cases, the emergency or auxiliary operating condition may be time-limited, and when the time expires, the IoT application server can transition the local domain and IoT device 810 back to normal data flow. Other options are possible.

[0127] Thus, the embodiments described herein provide a solution that covers the situations when a change in the permissible communication mode is required at a switch or router for an IoT to find itself in an emergency or secondary operation situation.

[0128] According to the embodiments described herein, a MUD is extended or modified to support two or more profiles or policies for IoT or other such devices. For example, a normal use profile and an emergency profile can be two types of profiles. The embodiments herein provide a solution for devices that are intended to communicate via a network router, switch, or gateway and a MUD manager. To this end, the MUD is extended or modified compared to the currently defined implementation for MUDs.

[0129] In a first aspect of the embodiments described herein, a challenge exists in configuring switches or routers and firewalls that will support IoT devices that have both a normal communication mode and an auxiliary communication mode. According to an embodiment of the present disclosure, an IoT device can have two different associated MUD files associated with it, and signaling this fact and the manner in which the auxiliary configuration is obtained is one aspect of the present disclosure.

[0130] In the first case, in addition to the normal MUD URL, a second (and optionally a third, fourth, etc.) URL is added to be transmitted by the device. For example, these URLs can be carried in another extension of the IoT device's certificate, as configured by the manufacturer, or in another DHCP extension, or in another LLDP sent by the device. Each additional URL points to the location of a file that specifies auxiliary device behavior, where such behavior will be specified by some other server other than the MUD server. Such other server is pointed to by the second (or third, fourth, etc.) URL, i.e., the server that hosts the file that specifies the auxiliary behavior of the device.

[0131] Alternatively, if certificates are used, the manufacturer certificate may indicate in a new field the existence of a special MUD file for the auxiliary context, rather than the actual URL. In this case, the MUD manager must find other means to locate this special MUD file.

[0132] Now refer to Figure 9 , which shows a process for obtaining multiple policies at a router or gateway. Figure 9 In the embodiment of the present invention, IoT device 910 communicates with a router or gateway 912. In addition, router or gateway 912 can communicate with MUD manager 914.

[0133] exist Figure 9 In the example, Figure 9 Multiple MUD servers, referred to in the example as MUD server 916 and MUD server 918, can provide different MUD files for different operating contexts. The two servers can be combined in the same physical network node, or logically combined but physically separate.

[0134] Specifically, as shown by arrow 920, IoT device 910 transmits the regular MUD URL. A second MUD URL, depicted in arrow 922, is also transmitted by IoT device 910. For example, this transmission may be accomplished via an extension to DHCP, LLDP, or X.509 certificates as described above and as used in the corresponding protocols between IoT device 910 and router or gateway 912. Figure 9 The transmission can be done in various ways. For example, in some cases it can be done at the application layer. In other cases, it can be done via a QR code. In other cases, the transmission can be done as printed in a manual and can be manually entered via a smartphone or directly into a router or gateway interface, etc. In such a case, the smartphone can then connect to the gateway, causing the gateway to obtain the MUD URL.

[0135] Router or gateway 912 may forward both URLs to MUD manager 1314 as indicated by arrow 930 .

[0136] The MUD manager 914, for example using an HTTPS GET ("HTTPS Get") request, may send such a request to the MUD URL, as indicated by arrow 940. This is similar to the existing process for obtaining MUD files.

[0137] In response, the MUD server 916 sends back the MUD file, as indicated by arrow 942.

[0138] In one aspect, MUD manager 914 also has a second, additional URL for an auxiliary (e.g., emergency) context, and can use such a URL to retrieve the MUD file from the server pointed to by the URL. For example, as indicated by arrow 950, an HTTPS GET request can be sent to MUD server 918, and in response, the auxiliary MUD file is received from MUD server 1318, as indicated by arrow 952. In some cases, MUD server 918 can be the same as MUD server 916. In other cases, the two servers can be different servers.

[0139] Upon receiving a MUD file, as indicated by arrow 942, the MUD manager 914 constructs a policy for the normal context, as currently executed. Additionally, upon receiving an auxiliary MUD file, as indicated by arrow 952, the MUD manager 914 writes a policy for the auxiliary context. For example, this could be an emergency context, which, from the IoT device's perspective, includes environmental conditions, parameters, and playback status during an emergency.

[0140] As indicated by arrow 960, MUD manager 914 sends the first policy to router or gateway 912. Additionally, MUD manager 914 sends the second policy (optionally along with a trigger) to router or gateway 912, as indicated by arrow 962.

[0141] Therefore, according to Figure 9 In an embodiment, two URLs are provided and two policies are returned to the router or gateway 912.

[0142] In another embodiment, only one URL is used, and it is the MUD server that has knowledge of the existence of the auxiliary MUD file. The MUD server can signal this information to the MUD manager when it returns the MUD file. Figure 10 .

[0143] exist Figure 10In one embodiment, the secondary MUD file is downloaded from the same URL. That is, the MUD file server can return any one or both of the two or more MUD files associated with the IoT device. In another option, the MUD file server can return the normal MUD file and additional redirection commands to another MUD file server for the secondary usage policy. For example, this can include returning a secondary URL for the MUD manager to obtain the second MUD file.

[0144] In the simplest context, a normal MUD file contains information for both the primary-use communication endpoint and the secondary-use communication endpoint.

[0145] When there is no indication of a secondary MUD file from the device, the MUD manager may not know whether a MUD file exists for emergency or secondary use until the MUD server actually returns both files.

[0146] Therefore, in Figure 10 In the example of FIG, IoT device 1010 communicates with a router, switch, or gateway 1012. In addition, router or gateway 1012 can communicate with MUD manager 1014.

[0147] exist Figure 10 In the embodiment of FIG. 1 , a primary MUD server 1016 exists along with a secondary MUD server 1018 .

[0148] In this case, the IoT device 1010 transmits the normal MUD URL, as indicated by arrow 1020, and as is currently done in the art.

[0149] Router or gateway 1012 forwards the received URL to MUD manager 1014, as is currently done in the art.

[0150] The MUD manager 1014 can send the MUD URL, for example using an HTTPS GET request. This is shown by arrow 1040, where the request is sent to the MUD server 1016.

[0151] In response, MUD manager 1014 receives the MUD file, as indicated by arrow 1042. The returned MUD file may contain an extension indicating parameters for the auxiliary communication endpoint, or may contain a URL for obtaining an auxiliary use MUD file. Such a URL may point to a different file (resource) on the same server or may point to a different server.

[0152] Alternatively, the MUD server sends a second MUD file for auxiliary use along with the original MUD file.

[0153] Figure 10 The example of shows the case where the extension includes a URL for a second MUD server.

[0154] Therefore, in Figure 10 In an optional step, MUD manager 1014 extracts the URL for secondary MUD server 1018 and sends an HTTP GET request to secondary MUD server 1018, for example, as indicated by arrow 1050.

[0155] In response, MUD manager 1014 receives the auxiliary MUD file, as indicated by arrow 1052. MUD server 1016 and MUD server 1018 may be the same server or may be different servers.

[0156] The MUD manager 1014 may then build the normal context policy, as currently done using the MUD file received at arrow 1042. The MUD manager 1014 may also use the MUD file received at arrow 1052 to write a policy for the auxiliary context.

[0157] The MUD manager 1014 may send the first policy to the router or gateway 1012, as indicated by arrow 1060. The MUD manager 1014 may further send the second policy and optionally a trigger to the router or gateway 1012, as indicated by arrow 1062.

[0158] for Figure 9 and 10 In both embodiments, a given MUD file server hosts MUD files for auxiliary policies. The same MUD file server can be used for MUD files for normal use, such as for all types of IoT devices, or for devices from a given manufacturer, among other options. In other cases, normal MUD files may originate from a different MUD file server.

[0159] trigger

[0160] From a manufacturer's perspective, a MUD file for an auxiliary context may include a new element to indicate the trigger that is expected to cause the IoT device to change its policy. For example, this new element may be called "auxiliary-trigger" or "emergency-trigger," among other options.

[0161] For example, for a temperature sensor, the trigger could be any reading of 140 degrees Fahrenheit (60 degrees Celsius) or higher.

[0162] The trigger may have a condition for transitioning to the auxiliary state and, in some cases, may also have a condition for transitioning back to the main or normal state. The conditions may be the same or different. For example, in some cases, a temperature sensor may need to have a reading below 122 degrees Fahrenheit (50 degrees Celsius) to return to the normal state.

[0163] Regarding such triggers, a trigger may have a trigger element syntax. The trigger may be use case specific, so the element itself in the MUD file may be a string or some other type of defined node / element that allows for flexible expression of the trigger. In some cases, such a string may be human-readable.

[0164] As an example, an element with the same syntax as the "systeminfo" element of the IETF MUD file can be used for triggering. Both of these and other information are intended for use by human users (administrators). Such other information may include, for example, whether the device is still supported by the manufacturer, as well as other information.

[0165] These fields are common to many devices, such as all sensors of type "X" in an industrial IoT scenario, so the decision to accept this type of IoT device onto the network can be made once for each device type and additional device acceptance can be automated, as described below.

[0166] In some cases, triggering elements may be incorporated into the auxiliary usage policy that a switch, router, or gateway may enforce upon declaration of an auxiliary mode of operation (eg, a state of emergency).

[0167] Furthermore, to allow network administrators (such as those supporting building management systems) to also have control over trigger settings, in some cases the trigger threshold settings received in the auxiliary use MUD file can be supplemented or overwritten when generating auxiliary policies written by the network administrator. This, therefore, allows for local domain control.

[0168] For example, a manufacturer may indicate that an emergency condition exists for its thermometer when the reading is above 140 degrees Fahrenheit (60 degrees Celsius). However, a network administrator in a local deployment may override this to 130 degrees Fahrenheit (54 degrees Celsius) because the facility where the IoT device is deployed is climate-controlled. In other cases, the network administrator may specify that even a reading of 130 degrees Fahrenheit is not sufficient, and that some other condition must be met. For example, the temperature must remain at the threshold level for 15 minutes, among other options.

[0169] like Figure 8 、 9Once the MUD manager has obtained the trigger from the MUD file or via other means, it can notify the IoT platform server of the trigger for the device as provided in 10. The protocol may be application specific.

[0170] In other cases, the IoT device can be configured to know what the trigger is and can take action when the trigger threshold is met, such as connecting to a different endpoint (an emergency response server) and sending the same (as in normal use) or different data to the endpoint. Additionally or alternatively, the IoT device can take input (application layer commands) from the endpoint.

[0171] Alternatively, the IoT device may be unaware of the trigger but may obtain application layer commands from the IoT service platform to send data to different endpoints.

[0172] The decision that a trigger is satisfied can be made by the IoT device itself, in some cases by a router, gateway, or switch, and / or by an IoT platform server (e.g., from Figure 8 The decision is made by the IoT application server 818 in the IoT platform server domain. If the decision is made on a router, gateway, switch, or server, then that entity may not only need to know what the trigger is, but also need to include application layer logic to be able to process the data from the device and decide whether to declare an emergency / assistance condition and therefore warrant a policy change. In the case of an IoT platform server, the emergency / assistance condition decision can alternatively be made independently of any IoT device data, such as, but not limited to, a 911 or 112 call indication or other human-sourced information from the assistance server domain 824, or based on both external input and data from one or more IoT devices.

[0173] The IoT platform server determines that the trigger condition is met

[0174] Therefore, according to one embodiment, the IoT platform server (or IoT application server) determines that the trigger condition is met and then notifies the device and the switch. This decision may be based on the data it receives from the IoT device and / or other data.

[0175] In this case, the trigger condition is determined to be met at the IoT service platform server, which may limit attacks whereby an attacker-controlled device can cause an emergency or other auxiliary state, as well as policy changes or any other actions that such a state may cause.

[0176] In particular, now refer to Figure 11 , which shows a flow chart between an IoT device 1110 , a switch 1112 and an IoT application server 1114 , which is also referred to herein as an IoT service platform server.

[0177] In this case, the IoT application server 1114 may have information about triggers 1116 for emergency / assistance situations.

[0178] During normal operation, normal data flow, as shown by arrow 1120 , occurs between the IoT device 1110 and the IoT application server 1114 .

[0179] The IoT application server 1114 may determine when an emergency situation or an auxiliary situation may be declared, as shown by block 1130 .

[0180] Once an emergency or assistance situation is declared, the IoT application server 1114 may send a message 1140 to the IoT devices requesting them to switch policies. Switching policies allows additional or different destination addresses and ports to be used for data communications. Figure 11 In the embodiment of FIG. 1 , message 1140 is shown as starting an emergency data flow. However, in other cases, the message may be starting an auxiliary condition data flow. In other cases, if the trigger at block 1130 is a trigger to restore normal conditions, the message may be to restore normal data flow. Other options exist.

[0181] The IoT application server 1114 can also send a message 1150 to the affected routers / gateways to switch policies. This is similar to the Figure 8 Message 866. Switch 1112 may be required to change the policy for all of its devices even if none of the devices it serves actually meet the trigger threshold condition.

[0182] The IoT device whose policy needs to be changed might just be the device that triggered it, or it might include other devices under the gateway / router.

[0183] To avoid race conditions, the IoT device 1110 should not switch policies without the router switching policies. If the IoT application server 1114 commands a policy change, the IoT application server 1114 may need to notify both the router (switch 1112) and the IoT device 1110 so that the router does not drop packets intended for the emergency / assistance server by the IoT device 1110. This can be achieved, for example, by including an "activation time" in messages sent to the IoT device 1110 and the switch 1112, where the "activation time" indicates when both should begin applying the new policy.

[0184] In one example of how the IoT application server 1114 causes the switch 1112 to change policy, the firewall provider can make an application programming interface (API) available to a firewall configuration application running on the switch 1112 and in a server (e.g., the IoT application server 1114). The API can be called by the IoT application server 1114 that is running the IoT application.

[0185] The end result is that a new data pipeline to the emergency communication or auxiliary communication endpoint is instantiated at the IoT device 1110, such as in Figure 8 The process proceeds as shown at arrow 870 in the embodiment of FIG. 1 , and additionally updates the access control list on switch 1112, including the firewall. Once another trigger for emergency is received at IoT application server 1114, indicating that the emergency / auxiliary context no longer exists, the policy can be switched back to normal use for the affected devices and switches. In some cases, the access control list includes a set of IP addresses from which communication is permitted.

[0186] The application layer logic on the switch determines that the trigger condition is met

[0187] In an alternative embodiment, application layer logic on the switch can determine that the trigger condition is met, for example by intercepting data from the device. The switch also notifies the IoT platform server that the trigger condition has been met.

[0188] In particular, now refer to Figure 12 , which shows a flow chart between an IoT device 1210, a switch 1212 with application layer logic 1214, and an IoT application server 1216 (also referred to herein as an IoT service platform server).

[0189] In this case, the switch 1212 may have information about the trigger 1218 for the emergency / auxiliary situation.

[0190] During normal operation, normal data flow, as shown by arrow 1220 , occurs between the IoT device 1210 and the IoT application server 1216 .

[0191] If trigger 1218 is enabled in switch 1212, which occurs in a deployment where switch 1212 has application knowledge that enables it to declare an emergency state based on sensor data it receives from device 1210, switch 1212 makes a determination at box 1230 that the trigger is satisfied and changes the policy, as shown by box 1232, from a normal use policy to an emergency / secondary use policy.

[0192] The switch 1212 may use application layer signaling to notify the IoT device 1210 to change the communication endpoint, as shown by message 1240 .

[0193] The end result in this embodiment is a new data pipe to the emergency / auxiliary communication endpoint instantiated at the IoT device 1210. Once another trigger for the emergency situation is obtained, indicating that the emergency / auxiliary context no longer exists, the policy can switch back to normal use for the device.

[0194] The address of the appropriate auxiliary / emergency endpoint

[0195] In another embodiment of the present disclosure, the local deployment domain can locate appropriate emergency / secondary communication servers (multiple) and add this information to the ACLs enforced at the switches / routers / gateways in the network where the IoT device finds itself. This operation can be performed by the network administrator. The embodiment described below uses emergency situations for the secondary mode of operation. However, this is not restrictive and is for illustration only.

[0196] The local emergency / secondary server FQDN is used to update the ACL. For example, in an emergency, the switch / router of an IoT deployment looks up the Emergency Services IP Network (ESInet) FQDN at a high level and adds it to the ACL for its emergency use policy. In some cases, this may require some level of application (specifically, Domain Name System (DNS) protocol) awareness of the entity enforcing the ACL on the switch.

[0197] In subsequent operations, the device can be notified to ESInet so that it knows where to send data in the event of an emergency being declared. For example, this can be accomplished using application layer messages from application layer logic on a router / switch or via application layer messages from an IoT service platform server.

[0198] There are various options for determining the emergency service address (FQDN or IP address). In a first example, the emergency service address can be determined in the local deployment domain. In a second example, the emergency service address can be determined in the OEM cloud or OEM domain. Figure 8 Describes how to process this information.

[0199] Therefore, in one aspect of the present embodiment, an entity or function block is introduced to find the local ESInet / PSAP based on location, which is called "ESInet lookup function" or "server lookup" function. Such an entity can be deployed in the local domain ("internal") or at the OEM cloud, and the lookup can be completed by the network administrator.

[0200] Specifically, emergency information (such as PSAP and ESInet domain name including FQDN) depends on the region or geographical area that the device is located in. This information is retrieved at the manufacturer's site or at the deployment site, for example by the MUD manager, BRSKI registrar or by a third entity.

[0201] In addition, the FQDN / URL of the emergency server can be constructed by the device or by the MUD manager using a potentially standardized method for constructing FQDN / URLs. The constructed FQDN / URL can be customized for each geographic region, for example by inserting the country name for that particular location into a string with specified elements. This may be similar to the method used in the Third Generation Partnership Project (3GPP), where emergency numbers (as opposed to IP addresses) can be obtained via a DNS query using the FQDN construction defined in 3GPP TS 23.003, for example using the string of comma-separated tags: "sos.en.epc.mcc <mcc>.visited-country.pub.3gppnetwork.org", where MCC is the Mobile Country Code used in 3GPP telephony.

[0202] In the first case of this embodiment, the emergency endpoint (or other auxiliary endpoint) server address information is determined at the local deployment. In this case, the URL of the emergency MUD file, or the communication endpoint for emergencies that will be used to build the emergency policy, is not given in the normal process of MUD provisioning. However, an indication that such a policy exists somewhere may have been given, but the exact location (URI) of the file is not given. That is, the MUD manager's task is to find the emergency communication endpoint information from which to formulate the local policy.

[0203] In the second case of this embodiment, the emergency endpoint server address information can be determined at the manufacturer's domain. In this case, no MUD URL is used, but the OEM can return a MUD file supplemented with auxiliary endpoint information, such as ESInet and / or PSAP information for the local domain. The OEM uses the information typically carried in the message sent by the BRSKI registrar or MUD manager to the OEM server during the boot or load process, respectively, to find the local domain of the IoT in question.

[0204] Specifically, when BRSKI is used to bootstrap a device, it enables the local domain to securely configure the device with information and credentials that the device can use in communications. The MUD functionality similarly provides a mechanism for performing corresponding configuration of switches / routers in the local domain. Since both IoT devices and switches / routers need to be configured to support communications, it is possible that the BRSKI (device configuration) functionality can be utilized by the MUD (router configuration) functionality, and vice versa. Therefore, if the BRSKI registrar determines the address of an auxiliary server, such as an ESInet server required for configuration of the IoT device, this information can also be made available to the MUD manager for configuring the router, and vice versa.

[0205] In the above, local emergency contacts refer to locally relevant ESInet server(s) and / or PSAP addresses, including IP addresses, URLs and / or SIP URIs, etc. The geographical scope of ESInet can range from "local" (as a single PSAP, county, or small call center area) to regional, national, and international.

[0206] Both ESInet information and PSAP information can be FQDN, URL or URI. This information is retrieved given a geographic region and can be stored in the OEM cloud and / or at a local deployment.

[0207] Furthermore, domains can span multiple areas, including regions or countries. For emergencies, a DNS lookup can return a local server IP address to handle emergency calls targeting that region or geographic area.

[0208] Therefore, based on the above, emergency information can be added at the deployment network or at the OEM cloud.

[0209] Added emergency information at the deployment network

[0210] According to this aspect of the present embodiment, the solution is based on MUD. It includes a MUD manager that looks up the local ESInet or auxiliary server and then includes this information in the access control list or firewall settings as part of the onboarding of the IoT device.

[0211] Now refer to Figure 13 , which shows the Figure 8 A more detailed view of messages 830, 832, 834, 840, and 844. Figure 13 In the embodiment of FIG, IoT device 1310 communicates with local domain 1311. Within local domain 1311, there are switch 1312 and MUD manager 1316.

[0212] The server lookup function 1317 may include an ESInet lookup.

[0213] Additionally, OEM domain 1320 includes a MUD server 1322 .

[0214] For the emergency services example, the emergency contact is the locally relevant ESInet server(s) and / or PSAP address, including but not limited to IP addresses, SIP URIs, and other options. These can be learned at the MUD manager 1316 by looking them up or storing them by a special entity (such as a server lookup entity 1317) or by the MUD manager itself.

[0215] Figure 13 The process outlined in the embodiment of FIG begins with the IoT device 1310 sending the MUD URL to the MUD manager 1316 in a message 1330. The message 1330 may be sent via the switch 1312.

[0216] MUD manager 1316 obtains a MUD file, which in some cases may include a trigger, by sending a URI to MUD server 1322 in message 1332 and receiving the MUD file and possibly a trigger in message 1334 from MUD server 1322.

[0217] The MUD manager 1316 can formulate regular or normal use policies, and it can also formulate auxiliary policies (such as emergency policies). For example, emergency policies can be formulated by supplementing regular use policies. The creation of auxiliary policies can be based on stored emergency contact information or other auxiliary information. These policies can be sent to the switch 1312 in message 1340.

[0218] The MUD manager 1316 may then inform the IoT device 1310 of ESInet using a message 1344 .

[0219] Emergency (Assistance) information added in OEM Cloud

[0220] In some embodiments, the OEM may have both a MASA server and a MUD server from BRSKI. In other cases, the OEM may only have a MUD server and an optional auxiliary service (e.g., ESInet) lookup function that obtains a geographic region and returns the FQDN, URL, or URI of a local, relevant auxiliary / emergency service ESInet or PSAP. The embodiment described below will refer to emergency services as auxiliary services. However, this is non-restrictive and other forms of auxiliary services are possible.

[0221] According to the first case, the OEM has both a MASA server and a MUD server. In this case, the MASA server looks for a locally relevant ESInet in at least one of two ways.

[0222] The first involves a direct search using the ESInet search function.

[0223] The second way involves looking it up in the ownership tracker (if used), assuming that the ownership tracker records the IoT device deployment network, location, and the ESInet used for that location. A locally relevant ESInet is an ESInet serving the local domain, as reported by the BRSKI registry or obtained from a lookup of the source IP address of the BRSKI traffic. The MASA server informs the MUD server of the local emergency FQDNs, and the MUD server includes them in the MUD file.

[0224] Optionally, this operation is triggered when the MUD server asks the MASA server to look up a local emergency FQDN, URI, or URL.

[0225] Now refer to Figure 14 , which shows an architecture where the BRSKI registrar and the MUD manager are assumed to communicate or be co-located in the local domain. Figure 14 In the example, on the OEM side, the BRSKI MASA server and the MUD server have a secure communication channel.

[0226] Furthermore, in this architecture, an "emergency contact" or "ESInet" is a locally relevant ESInet server(s) and / or PSAP address, including but not limited to an IP address, SIP URI, FQDN, URI or URL, etc. Furthermore, the MASA server has access to such information or is able to obtain such information.

[0227] In particular, Figure 14 In the embodiment of FIG, IoT device 1410 communicates with local domain 1411. Local domain 1411 includes switch 1412, MUD manager 1414 and registrar / AAA 1416.

[0228] The OEM domain 1420 includes a MASA server 1422 and a MUD server 1424 .

[0229] At message 1430, the IoT device 1410 sends the MUD URL to the MUD manager 1414. The MUD manager 1414 may then inform the BRSKI registry of the MUD URL (not shown).

[0230] In message 1432 , the IoT device 1410 sends a BRSKI credential request to the registrar / AAA 1416 .

[0231] The registrar / AAA 1416 may then send a credential (authentication) request 1440 to the MASA server 1422, including the MUD URL and location. For example, such location may include the current state, province, or country, as well as other such geographic information.

[0232] The MASA server may then determine the authenticity of the IoT device 1410 , as shown in block 1442 .

[0233] The MASA server can then look up ESInet for that location. This can be done, for example, by querying an ownership tracker 1426, as indicated by arrow 1442. This can be done if information for such an ownership tracker is provided with the domain of the deployed IoT device 1410. Alternatively, or in addition, it can involve querying ESInet (or other auxiliary server) lookup 1428, as indicated by arrow 1446, for example based on geographic region.

[0234] MASA server 1422 may then send a message 1450 to MUD server 1424 using the MUD URL and request the MUD file for IoT device 1410 from MUD server 1424. MASA server 1422 may optionally send the ESInet address looked up using arrows 1444 and / or 1446 to MUD server 1424.

[0235] The MUD server 1424 then sends the MUD file to the MASA server 1422 in a message 1452, optionally including an ESInet address in the MUD file.

[0236] In message 1454, MASA server 1422 returns the authenticity certificate of IoT device 1410 along with the MUD file to MUD manager 1414. In addition, message 1454 may contain emergency contact information (e.g., the obtained ES1net address) or another MUD file for auxiliary use.

[0237] The registrar / AAA 1416 completes authentication / authorization of the IoT device 1410 using the authenticity credentials.

[0238] MUD manager 1414 formulates two policies for switch 1412 of IoT device 1410. One policy is for normal use, and the other is for auxiliary use. The policy for auxiliary use includes allowing communication between the IoT device and the auxiliary server contact (e.g., ESINet) obtained from message 1454. In other embodiments, MUD manager 1412 may combine these two policies into one. The normal policy and the auxiliary policy are then provided to switch 1412 in message 1460.

[0239] Additionally, the determined auxiliary server address may be reported to the IoT device 1410 in a message 1462 .

[0240] In the absence of a BRSKI node, the MUD server looks up an ESInet address, such as an FQDN, URI, URL, and / or SIP URI, and other options, for the geographic area, as given by the MUD manager or determined from the source IP address of the endpoint providing the traffic. The MUD server then includes this "Emergency Contact" information in the MUD file for the device and re-signs the MUD file. Alternatively, the MUD server may return the information to the MUD manager separately from the MUD file, or in an Emergency Use MUD file. Figure 15 .

[0241] exist Figure 15 In the embodiment of FIG. 1 , IoT device 1510 communicates with local domain 1511. Local domain 1511 includes switch 1512 and MUD manager 1514. OEM domain 1520 includes MUD server 1524.

[0242] exist Figure 15 In the example of , the "emergency contact" is the address of the local relevant ESInet server(s) and / or PSAP address, including but not limited to FQDN, URI, URL, IP address, SIP phone number, etc. The MUD server 1524 has access to this information.

[0243] The MUD URL is sent from the IoT device 1510 to the MUD manager 1514 , as shown by message 1530 .

[0244] The MUD manager 1514 then contacts the MUD server 1524 in the OEM domain via, for example, an HTTPS GET, and includes the local domain's location, and optionally an identifier for the device, in a message 1540. The location may include any geographic indicator, including state, province, country, and other options.

[0245] MUD server 1524 obtains local domain emergency information from ESInet / auxiliary server lookup entity 1528, which looks up such information based on location information provided by MUD manager 1514. Alternatively, the MUD server obtains this information directly from ownership tracker 1526, assuming such a database stores a device identifier and its deployed location and emergency contact information; the MUD server provides the device identifier to the ownership tracker and obtains the emergency contact information (e.g., ESInet) or auxiliary server contact information for the device. Figure 15 In the embodiment of , these searches are illustrated using arrows 1544 and 1546, respectively.

[0246] MUD server 1524 then incorporates this ESInet information in one of a variety of ways. In a first approach, MUD server 1524 can modify the MUD file to add the MUD URL for a different auxiliary server. In a second approach, MUD server 1524 can add emergency / auxiliary contact information to the MUD file and re-sign the MUD file. In a third approach, MUD server 1524 can create a new auxiliary MUD file to return with the original MUD file. Other options are possible.

[0247] Once the ESInet / auxiliary server information is combined, MUD server 1524 then returns this information to MUD manager 1514 in message 1550.

[0248] Following the general process of IETF RFC 8520 for writing policies from MUD files, MUD manager 1514 can formulate two policies for switch 1512 of IoT device 1510. The first policy can be for normal use, and the other policy can be for auxiliary use. In some cases, MUD manager 1514 can combine the two into a single policy, perhaps after obtaining an emergency-use MUD file from another MUD file server provided above.

[0249] The normal policy and the auxiliary policy may then be provided to the switch 1512 in a message 1560 .

[0250] Where to initiate the connection

[0251] exist Figures 7 to 15 In this embodiment, once an emergency occurs, the device will need to know where to initiate an emergency connection. If the device has stored the emergency service's FQDN as part of its configuration, then when the device is instructed by the IoT service platform server to switch to emergency mode, it can perform a DNS query for the stored emergency service's FQDN. The router or switch can sniff the IP address returned from the DNS server and then configure an ACL to allow connectivity to that address. This process is similar to that employed by application-aware firewalls.

[0252] In the event that the device does not store the FQDN of the emergency service, the instruction to switch to emergency mode from the switch or router or from the IoT platform server to the IoT device may also contain the URL of the (multiple) IP addresses of the local relevant service IP level entity to which the device is required to now prepare to send data.

[0253] Message Format

[0254] Various methods can be used to signal to the MUD manager that an emergency (secondary) policy exists for an IoT device and how to retrieve it as part of the IoT device's onboarding. In a first option, the device carries or transmits two different MUD URLs, one for retrieving the normal operation MUD file and another for retrieving the emergency / secondary operation MUD file. The MUD manager can then retrieve both in any order.

[0255] For example, the URL may be in the form described in Table 1 below.

[0256] conventional "mud-url":"https: / / iot-device.example.com / name" Assist "mud-url":"https: / / iot-device-emergency.example.com / name"

[0257] Table 1: Example MUD URLs

[0258] In another option, the IoT device transmits the MUD URL, but also transmits another new data field indicating the existence of an emergency policy. For example, a field could be called "emergency-policy-exists." This information could be printed or displayed in a paper or online device manual, on a label on the device, via an attached QR code, or other options. This new data field is processed by the MUD manager, which then must find the location of the emergency MUD file.

[0259] Based on these signaling options, in one case, if DHCP is the method that the IoT device (thing) is initially configured to use, the MUD manager anticipates the existence of an emergency policy based on the fact that the IoT device (thing) can change the way it uses DHCP. The modification is that the DHCP option defined in RFC 8520, Section 10, can contain a URI for an emergency-use MUD file appended after a space after the MUD URI string, for example, as allowed by RFC 8520.

[0260] In the second case, if LLDP is the method the IoT device (thing) was first configured to use, then the MUD manager anticipates the existence of an emergency policy based on the fact that the IoT device (thing) changes the way it uses LLDP. The modification will be an extension with a new subtype.

[0261] In a third case, the MUD manager foresees the presence of an emergency policy from the fact that the IoT device (thing) presents a device certificate including an additional extension holding the emergency MUD URI.

[0262] Details of the specific changes to the signaling required to implement the method of Table 1 above are now disclosed as a way to extend the MUD RFC. Similar extensions can be made to the method of adding new data fields.

[0263] In one case, the extension can be via the "reserved" string (1 octet) in the MUD URL DHCP, per Section 10 of IETF RFC 8520. Specifically, if the MUD manager knows the URL of the emergency-use MUD file, the DHCP method is modified as follows: After a space after the MUD string, add the emergencyuseMUD string, e.g., as shown in bold in Table 2 below.

[0264] Code len MUDstring emergencyUseMUDstring

[0265] Table 2: Example IPv4 MUD URL DHCP

[0266] Table 2 shows an example for IPv4. An alternative for IPv4 is shown in Table 3 below, which adds a new field for the emergency use MUD string.

[0267]

[0268] Table 3: Example IPv4 MUD URL DHCP

[0269] For IPv6, the options are shown with respect to Table 4 below.

[0270]

[0271]

[0272] Table 4: Example IPv6 MUD URL DHCP

[0273] The above thus provides DHCP options.

[0274] For the LLDP option, an LLDP extension is defined to hold the MUD URL according to IETF RFC 8520. A new subtype may be introduced for vendor-specific event extensions to carry new emergency MUD strings for emergency-use MUD files (or other auxiliary-use MUD files).

[0275] Additions to the LLDP provider specific frame are shown in bold with respect to Table 5 below.

[0276]

[0277] Table 5: Example LLDP provider-specific frame for eMUDstring

[0278] From the example of Table 5 above, the actual assigned subtype may be different from 2, but will not be 1 as this has already been defined.

[0279] For the third case, where an IoT device (thing) presents a device certificate that includes a new extension for IEEE 802.1AR certificates, such a new extension can be defined to signal the presence and possible location of an emergency-use MUD file. Typically, this will involve the IETF standardization process.

[0280] Referring to Table 6 below, the new extensions follow those defined in MUD extensions. This code can be found in Section 11 of IETF RFC 8520, and the added extensions are provided in bold in Table 6 below.

[0281]

[0282]

[0283] Table 6: Example extensions to IEEE 802.1AR certification

[0284] There are alternative embodiments for signaling the presence of emergency or secondary MUD files. In an alternative class of methods, the MUD manager is informed of the need to retrieve MUD files without requiring high-level signaling of the presence of such a policy from the IoT device.

[0285] For example, in one case, the device transmits the MUD URL as currently specified, but the server sends back two separate MUD files, one for normal conditions and another for auxiliary or emergency conditions.

[0286] In another case, the device may transmit a mud URL as specified above, but the MUD file returned from the MUD server to the MUD manager has additional separate entries (such as extensions) for emergency behavior definitions, such as a new field "mud-emergency-url", and / or a new "from-device-emergency-policy", "to-device-emergency-policy", or simply "Emergency policy may exist".

[0287] Given the URL, the MUD manager may also need to retrieve the file again via https / GET MUD URL. Alternatively, the MUD manager may need to find the location of the emergency MUD file.

[0288] trigger

[0289] Regarding triggers, one question is how to signal the emergency trigger information in the MUD file. Because ACL configuration is highly dependent on the firewall implementation, in one case, the emergency trigger information signaled in the MUD file is a string intended for human users (network administrators). However, in other cases, it may take a different machine-readable form.

[0290] Thus, a new element in the MUD file indicates the triggering of an emergency based on the data available to the device. Additionally, or alternatively, there may be two trigger elements: one for signaling the transition from normal to emergency, and another for signaling the transition from emergency back to normal.

[0291] With respect to Table 7 below, examples of single trigger elements are shown in bold.

[0292]

[0293]

[0294] Table 7: Example new elements in a MUD file

[0295] An example of displaying text to be displayed to the user is provided in Table 7 above.

[0296] In the example of Table 8 below, one trigger is used to transition from the normal operating mode to the emergency operating mode. It is assumed that the same trigger can be used to transition from the emergency operating mode to the normal operating mode.

[0297] Changes are shown in bold.

[0298]

[0299]

[0300] Table 8: Example Triggers Alternatively, there may be two emergency triggers, such as shown in bold in Table 9 below.

[0301]

[0302] Table 9: Example with two emergency triggers

[0303] While the above signaling focuses on emergency use cases, similar modifications can be made to such signaling for any other auxiliary use cases for IoT devices. The present disclosure is therefore not limited to emergency use cases.

[0304] hardware

[0305] The servers, IoT devices, gateways, repeaters, switches, MUD managers, ownership trackers, ESInet lookups, MASA servers, MUDS servers, and electronic devices that perform the above methods can be any electronic device or network node. Such electronic devices or network nodes can include any type of computing device, including but not limited to mobile devices such as smartphones or cellular phones. Examples can also include fixed or mobile user devices such as IoT devices, endpoints, home automation devices, medical devices in hospital or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or devices for vehicles, fixed electronic devices, and the like. Vehicles include motor vehicles (e.g., cars, sedans, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, space shuttles, space capsules, space stations, satellites, etc.), vessels (e.g., ships, boats, hovercrafts, submarines, etc.), rail vehicles (e.g., trains and trams, etc.), pedestrians and bicycles, and other types of vehicles, including any combination of any of the above, whether currently existing or later developed.

[0306] about Figure 16 A simplified diagram of a network element or electronic device is shown.

[0307] exist Figure 16 In the embodiment, the device 1610 includes a processor 1620 and a communication subsystem 1630, wherein the processor 1620 and the communication subsystem 1630 cooperate to perform the method of the above embodiment. In some embodiments, the communication subsystem 1620 may include multiple subsystems, for example, for different radio and wired technologies.

[0308] Processor 1620 is configured to execute programmable logic that may be stored on device 1610 along with data and Figure 16 In the example of FIG, 1640 is shown as memory 1640. Memory 1640 can be any tangible, non-transitory computer-readable storage medium. The computer-readable storage medium can be a tangible or transient / non-transitory medium, such as an optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0309] Alternatively, or in addition to memory 1640 , device 1610 may access data or programmable logic from external storage media, such as through communications subsystem 1630 .

[0310] The communication subsystem 1630 allows the device 1610 to communicate with other devices or network elements and can vary based on the type of communication being performed. Additionally, the communication subsystem 1630 can include a variety of communication technologies, including any wired or wireless communication technology.

[0311] In one embodiment, communication between the various elements of device 1610 may be through internal bus 1660. However, other forms of communication are possible.

[0312] The embodiments described herein are examples of structures, systems or methods that have elements corresponding to the elements of the technology of the present application. This written description can enable those skilled in the art to make and use embodiments of alternative elements with elements that also correspond to the technology of the present application. Therefore, the intended scope of the technology of the present application includes other structures, systems or methods that are not different from the technology of the present application as described herein, and also includes other structures, systems or methods that are not essentially different from the technology of the present application as described herein.

[0313] Although operations are depicted in a particular order in the accompanying drawings, this should not be construed as requiring that such operations be performed in the particular order shown or in sequence, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be employed. Furthermore, the separation of various system components in the above-described implementations should not be construed as requiring such separation in all implementations. It should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0314] In addition, techniques, systems, subsystems, and methods described and illustrated in various implementations as discrete or separate can be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and variations are ascertainable and may be made by those skilled in the art.

[0315] While the above detailed description has shown, described, and pointed out the basic novel features of the present disclosure as applied to various implementations, it will be understood that various omissions, substitutions, and changes in the form and details of the illustrated systems may be made by those skilled in the art. Furthermore, the order of the method steps does not imply the order in which they appear in the claims.

[0316] When sending messages to / from an electronic device, such operations may not be immediate or directly from the server. They may be delivered synchronously or asynchronously from a server or other computing system infrastructure that supports the device / method / system described herein. The aforementioned steps may include, in whole or in part, synchronous / asynchronous communications to / from the device / infrastructure. In addition, the communication from the electronic device may be to one or more endpoints on the network. These endpoints may be served by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) may also provide communication with electronic devices. For example, in addition to typical server responses, a server may also provide or indicate data to a content delivery network (CDN) to wait for download by the electronic device at a later time (such as subsequent activity of the electronic device). Therefore, data can be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) as part of the system or separately from the system.

[0317] In general, the storage medium may include any one or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed across a large system, possibly with multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or product). An article or product may refer to any manufactured single component or multiple components. The one or more storage media may be located in the machine that runs the machine-readable instructions, or at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0318] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations of the foregoing details. The appended claims are intended to cover such modifications and variations.< / mcc>

Claims

1. A method for configuring an Internet of Things (IoT) device at a network element using a Manufacturer Use Description (MUD) file, the method comprising: receiving at least one MUD uniform resource locator URL from an IoT device; sending a uniform resource indicator from the network element to at least one MUD server based on the MUD URL; In response to the sending, receiving a plurality of MUD files from the MUD server; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and a secondary operating mode, the normal operating mode being associated with a first set of contact information, and the secondary operating mode being associated with a second set of contact information; as well as forwarding the plurality of policies from the network element to a gateway, wherein receiving the plurality of MUD files comprises receiving at least one trigger, the at least one trigger defining a condition for transitioning to the secondary mode of operation; as well as A lookup for the second set of contact information is performed based on the geographic location of the IoT device, the second set of contact information including an identifier, a network address, or a location for a secondary network.

2. The method of claim 1 , wherein the receiving at least one MUD URL comprises receiving a first MUD URL and a second MUD URL from the IoT device; and The sending includes sending the uniform resource indicator to a first MUD server based on the first MUD URL and sending the uniform resource indicator to a second MUD server based on the second MUD URL.

3. The method of claim 1 , wherein said receiving said at least one MUD URL comprises receiving a single MUD URL; and Wherein receiving the multiple MUD files includes receiving two MUD files.

4. The method of claim 1 , wherein said receiving said at least one MUD URL comprises receiving a single MUD URL; and Wherein, receiving the plurality of MUD files comprises: Receiving a first MUD file and an extension within the first MUD file; extracting the extension from the first MUD file; and A second MUD file is retrieved based on the extension. The method of claim 1 , further comprising forwarding the trigger to one of an application server and the gateway. 6 . The method of claim 1 , further comprising forwarding the contact information from the network element to the IoT device and the gateway. The method of claim 1 , wherein the secondary operating mode is an emergency services operating mode.

8. A network element for configuring an Internet of Things (IoT) device using a Manufacturer Usage Description (MUD) file, the network element comprising: processor; as well as Communication subsystem, The network element is configured to: receiving at least one MUD uniform resource locator URL from an IoT device; sending a uniform resource indicator to at least one MUD server based on the MUD URL; receiving a plurality of MUD files from the MUD server in response to sending the uniform resource indicator; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and a secondary operating mode, the normal operating mode being associated with a first set of contact information, and the secondary operating mode being associated with a second set of contact information; as well as forwarding the plurality of policies from the network element to a gateway, wherein receiving the plurality of MUD files comprises receiving at least one trigger, the at least one trigger defining a condition for transitioning to the secondary mode of operation; as well as A lookup for the second set of contact information is performed based on the geographic location of the IoT device, the second set of contact information including an identifier, a network address, or a location for a secondary network.

9. The network element of claim 8, wherein the network element is configured to receive at least one MUD URL by receiving a first MUD URL and a second MUD URL from the IoT device; and The network element is configured to send the uniform resource indicator by sending the uniform resource indicator to a first MUD server based on the first MUD URL and sending the uniform resource indicator to a second MUD server based on the second MUD URL.

10. The network element of claim 8, wherein the network element is configured to receive the at least one MUD URL by receiving a single MUD URL; and The network element is configured to receive the plurality of MUD files by receiving two MUD files.

11. The network element of claim 8, wherein the network element is configured to receive the at least one MUD URL by receiving a single MUD URL; and The network element is configured to receive the plurality of MUD files by: Receiving a first MUD file and an extension within the first MUD file; extracting the extension from the first MUD file; and A second MUD file is retrieved based on the extension.

12. The network element of claim 8, wherein the network element is further configured to forward the trigger to one of an application server and the gateway.

13. The network element of claim 8, wherein the network element is further configured to forward the contact information from the network element to the IoT device and the gateway.

14. The network element of claim 8, wherein the secondary operating mode is an emergency services operating mode.

15. A computer-readable medium storing instruction codes for configuring an Internet of Things (IoT) device using a manufacturer usage description (MUD) file, the instruction codes, when executed by a processor of a network element, causing the network element to: receiving at least one MUD uniform resource locator URL from an IoT device; sending a uniform resource indicator to at least one MUD server based on the MUD URL; receiving a plurality of MUD files from the MUD server in response to sending the uniform resource indicator; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal operating mode and a secondary operating mode, the normal operating mode being associated with a first set of contact information, and the secondary operating mode being associated with a second set of contact information; as well as forwarding the plurality of policies from the network element to a gateway, wherein receiving the plurality of MUD files comprises receiving at least one trigger, the at least one trigger defining a condition for transitioning to the secondary mode of operation; as well as A lookup for the second set of contact information is performed based on the geographic location of the IoT device, the second set of contact information including an identifier, a network address, or a location for a secondary network.

Images