Manufacturer usage description for lightweight machine-to-machine protocol

Abstract

A method for an IoT device includes: hosting a MUD file in the local memory of the IoT device; and opening the contents of the MUD file from the local memory of the IoT device as a CoAP resource. A related method for a MUD manager includes: receiving a URL from the IoT device using CoAP that announces the location of a MUD file stored in the local memory of the IoT device; and obtaining the contents of the MUD file from the local memory of the IoT device using CoAP. A related method for an LwM2M server includes: receiving a registration command from an LwM2M client for the IoT device using CoAP; determining a policy to be used to control communication with the IoT device; determining the contents of the MUD file based on the determined policy; and providing the contents of the MUD file to the LwM2M client for the IoT device using CoAP.

Description

Technical Field

[0001] The present disclosure relates to Internet of Things (IoT) devices, and more particularly to using Manufacturer Usage Description (MUD) files with IoT devices. Background Art

[0002] The Constrained Application Protocol (CoAP) is a specialized network transport protocol, i.e., an application layer protocol based on Representational State Transfer (REST), for devices with constrained system resources (e.g., processing power and memory size). CoAP (Internet Engineering Task Force (IETF) Request for Comments (RFC) 7252, June 2014) is designed for use over the User Datagram Protocol (UDP) on the Internet.

[0003] In current deployments, CoAP-based solutions, such as Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LwM2M), are becoming increasingly popular for managing devices in a REST-based manner.

[0004] The Manufacturer Usage Description (MUD) (RFC8520, March 2019) is used to announce to the network the optimal configuration (e.g., preferred configuration) or operationally restricted configuration for Internet of Things (IoT) devices. The MUD includes an announced URL that can be used to locate the MUD description. One purpose of the MUD is to provide a way for end devices to signal to the network what access and network functionality they require in order to operate properly. The MUD can announce device specifications, including the expected communication mode of the device when connected to the network. The network can then use this intent to create context-specific access policies so that the device only operates within these parameters. In this way, the MUD becomes the authoritative identifier and policy enforcer for devices on the network.

[0005] The term "manufacturer" generally refers to the entity or organization that will declare how the device is intended to be used. For example, in the context of a light bulb, this might be the bulb manufacturer. In the context of a smarter device with a built-in Linux stack, it might be the device's integrator. The key point is that the device itself is assumed to serve a limited purpose, and there is an organization in the supply chain for that device that will be responsible for informing the network of that purpose.

[0006] MUD is used to provide a means for end devices (IoT devices) to signal to the network what access and network functionality they require in order to function properly. In a MUD scenario, an "IoT device" opens a "MUD URL" to someone, and a "MUD processor" queries a "MUD file server" and retrieves a "MUD file" from it. After processing, the "MUD processor" applies an "access policy" to the IoT device. IoT devices may also be referred to interchangeably as "devices," "things," and "IoT things" in this article.

[0007] The MUD configuration can provide any one or more of the following:

[0008] o Significantly reduces the threat surface on the device to those communications intended by the manufacturer.

[0009] o Provide a means to extend network policy to the ever-increasing types of devices in the network.

[0010] o Provide a means to address at least some vulnerabilities faster than it would take to update the system. This is especially true for systems that are no longer supported. Keep the implementation cost of such a system to a minimum.

[0011] o Provides an extensible means for manufacturers to express additional device capabilities or requirements.

[0012] When reference Figure 1A and 1B The following terms used may be defined as follows:

[0013] MUD file: A file containing YANG-based JSON that describes an IoT device and the associated recommended specific network behavior.

[0014] MUD file server: A network server that hosts MUD files.

[0015] MUD Manager: A system that requests and receives MUD files from a MUD Server. After it processes a MUD file, it may include information directing changes to related network elements.

[0016] MUD controller: A synonym for MUD manager.

[0017] MUD URL: The URL that the MUD manager can use to receive MUD files.

[0018] IoT device: An electronic device that issues a MUD URL.

[0019] Manufacturer: The entity that configures an IoT device to issue a MUD URL, and the entity that asserts the recommendation in the MUD file. The manufacturer may not always be the entity that builds the IoT device. It could be, for example, a system integrator, or even a component provider.

[0020] like Figure 1A As shown, the MUD architecture can include IoT devices, MUD managers and MUD file servers. Figure 1B An example MUD process flow is shown. Figure 1B , the IoT device sends the MUD URL to the MUD manager. When the IoT device first connects to a router or switch (e.g., a network access point), the IoT device can send (step 1) a MUD URL embedded in an LLDP, DHCP, or 802.1X request. The router or switch (e.g., a network access point) extracts the URL, encapsulates the URL in a Radius packet, and sends (step 2) the URL to the AAA server. When the MUD URL is embedded in a DHCP packet, some networks may instead forward the entire DHCP packet to the AAA server.

[0021] The AAA server then passes the URL (step 3) to the MUD manager. The MUD manager then contacts (step 4) the manufacturer's internet-hosted MUD file server pointed to by the URL via HTTPS. After the MUD file server verifies that the MUD file was generated by the device manufacturer, the MUD file server sends (step 5) the MUD file corresponding to the device to the MUD manager. This MUD file (which can be a YANG data model represented as a JSON object) contains the abstract communication intent of the relevant IoT device.

[0022] The MUD manager converts this abstract intent into a context-specific policy, which is passed (step 6) to the AAA server / Identity Services Engine (ISE). The ISE then enforces (step 7) the policy on the network in the form of a port-based access control list (ACL) for the IoT device's connection point.

[0023] Based on the manufacturer's stated intent, access to the device is then provided (step 8).

[0024] The MUD process can be used to automatically allow a device to send and receive only the traffic required to perform its intended function. The MUD process can also be used to mitigate distributed denial of service (DDoS) attacks, for example, by prohibiting unauthorized traffic to and from IoT devices. Even if an IoT device is compromised, the contents of the MUD file can prevent the IoT device from being used in any attack that would require the IoT device to send traffic to unauthorized destinations.

[0025] The MUD process is not designed to address network authorization for general-purpose computers, but rather for IoT devices. However, MUD URLs are currently mandatory in the "https" scheme (RFC7230, June 2014). Summary of the Invention

[0026] Some embodiments of the present disclosure relate to a method for an IoT device, comprising: hosting a MUD file in a local memory of the IoT device; and opening the contents of the MUD file from the local memory of the IoT device as a CoAP resource.

[0027] Some other related embodiments relate to a method for a MUD manager. The method includes: receiving a URL from an IoT device using CoAP that announces the location of a MUD file stored in a local memory of the IoT device. The method also includes: obtaining the contents of the MUD file from the local memory of the IoT device using CoAP.

[0028] Some other related embodiments relate to a method of an LwM2M server. The method includes receiving a registration command from an LwM2M client for an IoT device using CoAP. The method determines a policy to be used to control communications with the IoT device and, based on the determined policy, determines the content of a MUD file. The method then provides the content of the MUD file to the LwM2M client for the IoT device using CoAP.

[0029] Some other related embodiments relate to a method of a resource directory (RD) server. The method includes receiving a command from an Internet of Things (IoT) device to register a URL of a MUD file stored in a local memory of the IoT device. The method stores the URL as a MUD-based resource type in an object structure maintained by the RD server. The method responds to a query from an electronic device identifying the MUD-based resource type by providing the URL to the electronic device.

[0030] Some other embodiments relate to a corresponding IoT device, comprising at least one processor and at least one memory, the at least one memory being coupled to the at least one processor and comprising computer-readable program code that, when executed by the at least one processor, causes the at least one processor to perform operations configured to: host a MUD file in a local memory of the IoT device; and expose the contents of the MUD file from the local memory of the IoT device as a CoAP resource.

[0031] Some other embodiments relate to a corresponding MUD manager, comprising at least one processor and at least one memory, the at least one memory coupled to the at least one processor and comprising computer-readable program code that, when executed by the at least one processor, causes the at least one processor to perform operations configured to: receive, from an IoT device using CoAP, a URL advertising a location of a MUD file stored in a local memory of the IoT device; and obtain, from the local memory of the IoT device using CoAP, content of the MUD file.

[0032] Some other embodiments relate to a corresponding LwM2M server, comprising at least one processor and at least one memory, the at least one memory being coupled to the at least one processor and comprising computer-readable program code that, when executed by the at least one processor, causes the at least one processor to perform operations. The operations are configured to: receive a registration command from a LwM2M client for an IoT device using CoAP; determine a policy to be used to control communications with the IoT device; and, based on the determined policy, determine content of a MUD file; and then provide the content of the MUD file to the LwM2M client for the IoT device using CoAP.

[0033] Some other embodiments relate to a corresponding RD server, the RD server comprising at least one processor and at least one memory, the at least one memory being coupled to the at least one processor and comprising computer-readable program code that, when executed by the at least one processor, causes the at least one processor to perform operations. The operations are configured to: receive a command from an IoT device to register a URL of a MUD file stored in a local memory of the IoT device, and store the URL as a MUD-based resource type in an object structure maintained by the RD server. The operations respond to a query from the electronic device identifying the MUD-based resource type by providing the URL to the electronic device.

[0034] Potential advantages of these and other embodiments disclosed herein include: by hosting MUD files on IoT devices, the MUD manager is able to manage communication policies with IoT devices without requiring an internet connection to a remote MUD file server, and is therefore able to operate without such an internet connection. Furthermore, by having the MUD manager communicate locally with the IoT devices, without relying on an internet connection to a remote MUD file server, lower latency and higher reliability policy determination can be achieved. The operational efficiency of the MUD architecture can also be improved by using CoAP to transfer the contents of the MUD file from a CoAP server on the IoT device to a CoAP client on the MUD manager. The contents of the MUD file hosted by the IoT device can be efficiently managed by an LwM2M server that communicates with an LwM2M client on the IoT device. The IoT device can provide a resource directory (RD) server with the URL of the location where the MUD file is stored locally at the IoT device, and other electronic devices can then query the RD server to discover which IoT devices have locally stored MUD files and obtain the URL of the MUD file.

[0035] Note that aspects described with respect to one embodiment may be included in a different embodiment, even though not specifically described with respect to the different embodiments. That is, all embodiments and / or features of any embodiment may be combined in any manner and / or combination. In addition, other IoT devices, MUD managers, LwM2M servers, RD servers, and corresponding methods and computer program products according to the embodiments will be or become apparent to those skilled in the art upon reading the following figures and detailed description. All such other IoT devices, MUD managers, LwM2M servers, RD servers, and corresponding methods and computer program products are intended to be included in this description and protected by the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The various aspects of the present disclosure are illustrated by way of example and not limitation in the accompanying drawings. In the drawings:

[0037] Figure 1A This is a block diagram of the MUD architecture;

[0038] Figure 1B An example MUD process flow is shown;

[0039] Figure 2 is a block diagram of a MUD architecture for CoAP according to some embodiments of the present disclosure;

[0040] Figure 3 is a combined data flow diagram and flowchart illustrating the sequence of operations and data flow used by a MUD between various components of the MUD architecture according to some embodiments;

[0041] Figure 4 is a block diagram of an electronic node (e.g., an IoT device, a MUD manager, and / or a LwM2M server) of a MUD architecture including elements configured according to some embodiments;

[0042] Figure 5 and 6 is a flowchart of the operation of an IoT device according to some embodiments;

[0043] Figure 7 and 8 is a flow chart of the operation of a MUD manager according to some embodiments;

[0044] Figure 9 and 10 is a flowchart of the operation of an LwM2M server according to some embodiments; and

[0045] Figure 11 is a flow chart of the operation of a resource directory server according to some embodiments. DETAILED DESCRIPTION

[0046] The concept of the present invention will now be described more fully below with reference to the accompanying drawings, in which examples of embodiments of the concept of the present invention are shown. However, the concept of the present invention can be embodied in a variety of different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided to make this disclosure detailed and complete, and to fully convey the scope of the various concepts of the present invention to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be assumed to exist / be used in another embodiment.

[0047] Current MUD specifications do little to expose the Constrained Application Protocol (CoAP) or the Lightweight Machine-to-Machine Protocol (LwM2M).

[0048] The Constrained Application Protocol (CoAP) is a common Representational State Transfer (REST) ​​application protocol for constrained devices, defined in RFC 7252. CoAP is designed for use over the User Datagram Protocol (UDP) (RFC 0768) on the Internet. CoAP variants such as the Lightweight Machine-to-Machine Protocol (LwM2M) are becoming increasingly popular for managing devices in a RESTful manner.

[0049] As mentioned above, Figure 1A is a block diagram of the MUD architecture, and Figure 1BAn example MUD process flow is shown. According to the embodiments of this article, MUD can become a common component of IoT devices. Like other components, this common component needs to be configured and managed. The MUD URL uses mandatory https. RFC7252 states

[0050] "Manufacturers can construct MUD URLs in any way, as long as it utilizes "https"

[0051] Example: https: / / cisco.com / product_abc123 / v5

[0052] The MUD URL is issued using DHCP, LLDP, or via 802.1X, and the network switch or network router then sends the URI to an IoT control entity, which retrieves the MUD file from a MUD file server over the Internet using HTTP [SECCONS].

[0053] This is not an ideal mechanism for a CoAP endpoint. As shown above, the MUD is not specified as an open CoAP resource, but rather as a URL pointing to an external MUD file server shared via DHCP; an open CoAP " / mud" resource would be an operationally more efficient and robust solution than the current approach.

[0054] A CoAP device can expose both the URL and the MUD file that it is hosting.

[0055] Figure 21 is a block diagram of a MUD architecture for CoAP according to some embodiments of the present disclosure. The MUD architecture includes an IoT device 100, a MUD manager 120, and a network router 110 or network switch 110 in communication with a network 140, which can be one or more private or public networks, such as the Internet. The MUD architecture can also include an LwM2M server 130 and a resource directory (RD) server 150. According to embodiments herein, the IoT device 100 locally stores and hosts MUD files in its local memory. As explained in further detail below, the MUD manager 120 is used to retrieve the contents of the MUD file from the IoT device, validate the contents of the MUD file, and, in response to correct validation, provide the contents to the network router 110 or network switch 110 to control communication with the IoT device 100. The LwM2M server 130 can be used to manage (e.g., create and / or modify) the contents of the MUD file stored in the IoT device 100. The IoT device 100 can communicate with the RD server 150 to register (e.g., POST) the URL of the MUD file stored in the local memory of the IoT device 100. The RD server 150 may maintain a database containing a list of IoT devices that locally store their MUD files and the URLs of these MUD files. An electronic device 160 (e.g., a user equipment (UE), a server, etc.) may query the RD server 150 to obtain a list of URLs of MUD files stored at the IoT device.

[0056] Although the MUD manager 120 is shown as being separate from the IoT device 100 and the network router 110 or the network switch 110, the functionality of the MUD manager 120 may be at least partially implemented in another component of the MUD architecture, such as in the network router 110 or the network switch 110, in the IoT device 100, and / or elsewhere. Similarly, although the LwM2M server 130 is shown as being separate from the RD server 150, the functionality of the LwM2M server 130 and the RD server 150 may be at least partially integrated into a common unit.

[0057] The MUD architecture shown can be an operationally more efficient design that enables direct integration with IoT networks, allowing other IoT devices to use the MUD directly. This architecture can also allow for easier integration with management protocols such as LwM2M, as well as provide resiliency in situations where Internet connectivity is unavailable in constrained networks.

[0058] Various embodiments of the present disclosure relate to a MUD file that is signed by the manufacturer, hosted in the local memory of an IoT device, and exposed as a CoAP resource to enable such MUD usage over a managed network context.

[0059] Various embodiments relate to mechanisms for devices to use MUD in CoAP (discovery, reading, authentication...) and for integration with other systems such as MUD managers (provisioning, updating) and manufacturers (signing), as well as other use cases with software updates.

[0060] In some embodiments, the CoAP server is configured to open a new resource, for example, under / mud, and make the new resource available for CoAP discovery so that other network elements can utilize the new resource.

[0061] The LwM2M / IPSO model can be used to create a MUD object for LwM2M. In LwM2M, the MUD manager that handles the MUD can use the information provided by the IoT device to create an access policy. Trust is ensured through certificates. The IoT device can also use the MUD to announce the required access policy (see "from-device"). Various embodiments disclosed herein relate to operations that enable a device to join a network and be configured with a MUD, and if configured, to retrieve the correct policy and enable it.

[0062] Advantages provided by some or all of these embodiments may include any one or more of the following:

[0063] 1. According to the operations in this article, reuse MUD files, LwM2M and CoAP;

[0064] 2. Allow devices to host MUDs, thereby eliminating or reducing the need for MUD file servers;

[0065] 3. Open MUD functionality to the CoAP ecosystem, making it valuable for managed endpoints and for device-to-device interactions;

[0066] 4. Allowing MUD use even without an internet connection; and

[0067] 5. Use DHCP to renew the lease as the operation used to announce MUD changes.

[0068] Two different approaches to using MUD with CoAP are described below.

[0069] The first approach involves self-hosted MUDs using CoAP. The IoT device contains a MUD file in the device's local storage and exposes its own MUD file via CoAP so that other network elements can utilize the MUD file. This approach can eliminate or reduce the need for using a MUD file server. The IoT device exposes one or both of the MUD URL and the MUD file, and the manager that handles the MUD can use the information provided by the device to create an access policy. Trust can be operationally ensured through certificates used in the communication. In addition, as mentioned above, Figure 2 , the IoT device 100 can communicate with the RD server 150 to register (e.g., POST) the URL of the MUD file stored in the local memory of the IoT device 100. The RD server 150 can maintain a database containing a list of IoT devices that store their MUD files locally and the URLs of these MUD files. An electronic device 160 (e.g., a user equipment (UE), a server, etc.) can query the RD server 150 to obtain a list of URLs of MUD files stored at the IoT device. The electronic device 160 can use one or more URLs in the list to obtain the content of the addressed MUD file. The electronic device 160 can determine the communication capabilities or policies of the IoT device, for example, through the content of the addressed MUD file, and select among the IoT devices to establish a connection and / or control communication with the IoT device based on the determined capabilities and / or policies.

[0070] The second approach involves a management system that uses LwM2M to provide MUD configuration, uses MUD during registration, and configures IoT devices accordingly. The system can have: a CoAP URL; a description hosted as a resource; and discoverability using the CoAP discovery mechanism.

[0071] Reference below Figure 2 The first approach involving a self-hosted MUD is described first. Figure 2 is a block diagram of a MUD architecture for CoAP according to some embodiments of the present disclosure.

[0072] refer to Figure 2 , the CoAP endpoint exposes a URL pointing to the path " / mud" (where the path will host the manufacturer-signed mud), so this will meet the requirements of RFC8520. Figure 2In the example above, a MUD file is opened via CoAP at "coaps: / / [IPv6] / mud". Its basic configuration is that the IoT device is the initiating device, so inbound communication is not allowed. Below is an example of a MUD-compliant description using CoAP and LwM2M, indicating to the LwM2M server that all communication is device-initiated. The MUD-compliant description uses two non-restrictive policy examples: "from-device-policy" and "to-device-policy".

[0073]

[0074]

[0075] A MUD can be signed using the manufacturer's public key for verification purposes.

[0076] When using the CoRE link format, a CoAP client can send a GET request to / .well-known / core to a CoAP server and, in return, get a list of hypermedia links pointing to other resources hosted in that server. Among other things, the CoAP client will get the path to the MUD file, e.g., " / mud". The CoAP server can be, for example, Figure 2 A portion of a Resource Directory (RD) server 150 and / or a LwM2M server 130 is shown.

[0077] A managed network method with MUDs and discovering MUDs is now described.

[0078] Powered IoT devices should register MUD files with the RD server and also use the RD server as a repository for MUD file URLs. Using known RD lookup procedures, such as by querying the RD server, other electronic devices can discover MUD file URLs. These operations can provide a powerful discovery mechanism, such as the following example:

[0079]

[0080] A new resource type (rt) can be created to enable MUD to be used in the RD ecosystem. For example, a query for "rt=mud":

[0081] REQ:GET coap: / / rd.company.com / rd-lookup / res? rt=mud

[0082] When querying for this resource type (rt=mud), RD will return a list of links to hosted mud resources, such as the following example:

[0083]

[0084] You can also use multicast to discover all manufacturer descriptions on a subnet.

[0085] The second method involves a managed network with a MUD and is referred to below. Figure 3 Describes the use of LwM2M, Figure 3 is a combined data flow diagram and flowchart illustrating the sequence of operations and data flow used by a MUD between various components of the MUD architecture according to some embodiments.

[0086] refer to Figure 3 , illustrates the operations and related communications of an LwM2M endpoint (EP), a MUD manager 120, and an LwM2M server 130 within an IoT device 100. These operations are grouped into an operation 310 for discovering a MUD (e.g., the contents of a MUD file), an operation 320 for updating the contents of a MUD file, and an operation 330 for advertising the MUD file. When the LwM2M server 130 modifies the contents of a MUD file stored in the local memory of the IoT device 100, operation 330 may be repeated to advertise the modified MUD file to the MUD manager 120, enabling the MUD manager 120 to revalidate the MUD file and, if appropriate, generate new policies to control communications with the IoT device 100 via the network router (or network switch) 110. Although various arrows are used to convey example communication directions, the arrows shown are not limiting, and communication may occur in the opposite direction to that shown, as well as in both directions.

[0087] To use MUD in LwM2M, various embodiments map MUD to LwM2M object structure. An example mapping between MUD and LwM2M object structure is provided below.

[0088]

[0089] For the sake of brevity, the objects mapped above are a non-limiting example of a minimal MUD configuration in LwM2M. The term "ro" refers to an object that allows only read access, and the term "rw" refers to an object that allows both read and write access. In LwM2M, the controller can be "urn:ietf:params:mud:coap" (urn should be registered), and the two policy resources "from-device-policy" and "to-device-policy" point to two other objects that define the connection characteristics of the device. For the sake of simplicity, this embodiment adds three resources "controller", "name" and "ace" (access control entry) in succession.

[0090] refer to Figure 3 In the example embodiment shown, the IoT device 100 registers a MUD object (i.e., the contents of the MUD file) on the LwM2M server 130, and the LwM2M server 130 applies different policies (e.g., communication policies) to the IoT device 100 based on the characteristics of the IoT device 100. Finally, the LwM2M client "LwM2M Endpoint (EP)" will update the MUD and announce the MUD.

[0091] The contents of the MUD file can be created by the boot server during the boot process, or can be predefined in memory by the manufacturer (e.g., at the factory). In either case, during registration, the IoT device 100 using the MUD file also registers the MUD object. The IoT device 100 can perform a simple registration as specified in the Open Mobile Alliance's Lightweight Machine-to-Machine Technical Specification: Core (OMA-TS-LightweightM2M_Core-V1_1-20180710-A, Version 1.1, July 10, 2018).

[0092] exist Figure 3 In the example, the LwM2M server 130 and the LwM2M endpoint (EP) on the IoT device 100 perform operation 310 to enable the LwM2M server 130 to discover the MUD file. For example, the IoT device 100 boots up and registers with the LwM2M server 130 via a POST command. The path for rd is provided. The LwM2M server 130 discovers whether the capability is available at the LwM2M client (LwM2M EP). This is expected to be necessary because the capability may not be mandatory.

[0093] The "GET" command provides the well-known core and provides the contents of the MUD file. The IoT device 100 returns a "2.05Content" response with the content " / mud", in this case the object "MUD". Example code can be provided as follows:

[0094]

[0095] The LwM2M server 130 performs a GET operation on the specific object.

[0096] The IoT device 100 returns a “2.05Content” response, which may include the following SenML:

[0097]

[0098]

[0099] The MUD manager 120 queries its internal database for policies that it has applied to the IoT device 100, or creates a new policy. The policy is sent as a serialized MUD that edits the existing MUD. If the MUD does not exist, the MUD manager 120 will use the existing device object to provide a default MUD on the IoT device 100.

[0100] The MUD manager 120 performs a POST or PATCH operation to modify the contents of the MUD file. For example, the following SenML changes an endpoint from advertising that it only uses ipv4 to advertising that it uses ipv6.

[0101] The IoT device 100 responds with a “2.04Changed” response to indicate the successful change of the parameter:

[0102]

[0103] The IoT device 100 (endpoint) will update the "last-update" field ("n": "2") value at this time and use the DHCP renewal lease (new) to announce the MUD file and the new MUD URL. Otherwise, the network can periodically update this field based on the cache validity period (value 99).

[0104] A fabric network element (eg, network router 110 ) will apply the MUD process and forward the URL to MUD manager 120 .

[0105] The MUD manager 120 will then query the IoT devices 100 (endpoints) within the local network, which will provide the contents of the current MUD file.

[0106] The opening of the MUD file to other network elements (i.e., other electronic devices 160 on the network) may be performed in the same manner as specified by the RFC and as explained above for the discovery MUD embodiment in operation 310. New mechanisms including IP multicast may be used with these embodiments.

[0107] exist Figure 3 In the example, the Advertise MUD operation 330 may also be performed before the Discover MUD operation 310, such as when the IoT device (item) is powered on and the device boots and registers. Figure 3 The illustrated LwM2M EP (End Point) (also referred to as an LwM2M Client) typically resides in the IoT device 100 , but may reside elsewhere and be communicatively connected to the IoT device 100 .

[0108] Thus, various embodiments provide a mechanism for configuring the contents of a MUD file for use in CoAP, which can be particularly beneficial for device environments without internet connectivity and can operate better with the CoAP architecture. These embodiments can improve current MUD usage by utilizing a CoAP server (e.g., LwM2M EP) running on a constrained device. These embodiments can introduce usage in LwM2M and provisioning and MUD signing mechanisms.

[0109] Described below are example components of an electronic node 400 , which may be an IoT device, a MUD manager, a LwM2M server, and / or an RD server as described herein and illustrated in one or more of FIGS. 1-3 .

[0110] Figure 4 4 is a block diagram of an electronic node 400 of a MUD architecture including elements configured according to some embodiments. The electronic node 400 may include one or more network interfaces 420 (referred to simply as "network interfaces"), one or more processors 400 (referred to simply as "processors"), and one or more memories 410 (referred to simply as "memories") containing program code 412.

[0111] The network interface 420 can be configured to communicate via a wired interface (e.g., Ethernet) and / or a wireless interface (e.g., a wireless transceiver) according to one or more proprietary protocols and / or industry-standardized protocols (e.g., WiFi, Zigbee, Bluetooth, 3GPP 4G, 5G (NR), etc.). The processor 400 may include one or more data processing circuits, such as general-purpose and / or special-purpose processors (e.g., microprocessors and / or digital signal processors), which may be co-located on one or more networks or distributed across one or more networks. The processor 400 is configured to execute program code 412 in the memory 410 (described below as a computer-readable medium) to perform some or all of the operations and methods described above for one or more embodiments of the IoT electronic device (e.g., with respect to one or more embodiments described herein, such as in the context of any one or more of Figures 1 to 3).

[0112] Now refer to Figure 5-11 The above and more general operations and methods that may be performed by the IoT device 100 , the MUD manager 120 , the LwM2M server 130 , and the RD server 150 are explained.

[0113] Figure 5 and 6 is a flowchart of the operation of the IoT device 100 according to some embodiments.

[0114] First reference Figure 5, the IoT device 100 may host 500 the MUD file in the local memory of the IoT device 100. The device may open 502 the content of the MUD file from the local memory of the IoT device 100 as a Constrained Application Protocol (CoAP) resource.

[0115] In another embodiment, the operation of opening 502 the contents of the MUD file from the local memory of the IoT device 100 as a CoAP resource may include providing 504 the contents of the MUD file from the local memory of the IoT device 100 to the MUD manager 120 using CoAP to create an access policy that controls communication with the IoT device 100 through at least one of the network router 110 and the network switch 110.

[0116] In another embodiment, providing 504 the contents of the MUD file from the local memory of the IoT device 100 to the MUD manager 120 using CoAP may include providing a to-device-policy to the MUD manager that controls communications to the IoT device and providing a from-device-policy to the MUD manager that controls communications from the IoT device.

[0117] In another embodiment, the operation of providing 504 the content of the MUD file from the local memory of the IoT device 100 to the MUD manager 120 using CoAP may include: receiving, by the CoAP server on the IoT device 100, a CoAP GET command from the MUD manager 120; and providing, by the CoAP server on the IoT device 100, the content of the MUD file to the MUD manager 120 in response to the CoAP GET command.

[0118] The content of the MUD file provided 504 to the MUD manager 120 may include YANG-based JSON objects that describe network behavior for the IoT device 100 .

[0119] refer to Figure 6 In another embodiment, the IoT device 100 may be further configured to obtain 600 a MUD object from the LwM2M server 130 by a LwM2M client (e.g., LwM2M EP) for the IoT device 100. The IoT device 100 may then be further configured to store 602 the MUD object in a MUD file in a local memory of the IoT device 100.

[0120] In another embodiment, the operation of obtaining 600 a MUD object from the LwM2M server 130 by the LwM2M client for the IoT device 100 may include: receiving resources defined in the LwM2M resource structure from the LwM2M server 130; accessing a mapping between the resources and the MUD objects; and generating or updating a MUD file in a local memory of the IoT device 100 based on the MUD objects being mapped to the resources received from the LwM2M server 130.

[0121] In another embodiment, the IoT device 100 is further configured to: in response to generating or updating a MUD file in the local memory of the IoT device 100, provide the content of the generated or updated MUD file to the MUD manager 120 using CoAP to create another access policy, which controls communication with the IoT device 100 through at least one of the network router 110 and the network switch 110.

[0122] Now, in Figure 7 and 8 Various corresponding operations to be performed by MUD manager 120 are described in the context of .

[0123] First reference Figure 7 , the MUD manager 120 may be configured to: receive 700 a URL announcing a location of a MUD file stored in a local memory of the IoT device 100 using CoAP from the IoT device 100 ; and obtain 702 the content of the MUD file from the local memory of the IoT device 100 using CoAP.

[0124] The operation of obtaining 702 the content of the MUD file from the local memory of the IoT device 100 using CoAP may include sending 704 a CoAP GET command to a CoAP server on the IoT device 100 .

[0125] refer to Figure 8 In another embodiment, the MUD manager 120 may be further configured to create 800 an access policy based on the content of the MUD file, the access policy controlling communication with the IoT device 100 through at least one of the network router 110 and the network switch 110 .

[0126] The operation of creating 800 access policy may include: creating a to-device-policy that controls communication to the IoT device 100 through at least one of the network router 110 and the network switch 110; and creating a from-device-policy that controls communication from the IoT device 100 through at least one of the network router 110 and the network switch 110.

[0127] The MUD manager 120 may also be configured to provide 802 access policies for the IoT devices 100 to the network routers 110 and the network switches 110 .

[0128] The MUD manager 120 may also be configured to determine whether a certificate contained in the contents of the MUD file is verified; and create 800 an access policy to control communications with the IoT device 100 only if the certificate is determined to be verified.

[0129] Now, in Figure 9 and 10 Various corresponding operations to be performed by the LwM2M server 130 are described in the context of FIG.

[0130] First reference Figure 9 The LwM2M server 130 is configured to receive 900 a registration command from the LwM2M client for the IoT device 100 using CoAP. The LwM2M server 130 is further configured to determine 902 a policy to be used to control communications with the IoT device 100 and, based on the determined policy, determine 904 the content of a MUD file. The LwM2M server 130 is further configured to provide 906 the content of the MUD file to the LwM2M client for the IoT device 100 using CoAP.

[0131] refer to Figure 10 In another embodiment, the LwM2M server 130 is further configured to: receive 1000 a command from the LwM2M client for the IoT device 100 for registering a URL of a MUD file stored in a local memory of the IoT device 100; store 1002 the URL as a MUD-based resource type in an LwM2M object structure maintained by the LwM2M server 130; and Figure 2 160) provides 1004 a URL in response to 1004 a query from the electronic device to identify a MUD-based resource type. The command 1000 may be received from the LwM2M client for the IoT device 100 using CoAP. The URL 1000 may be received in a POST CoAP command from the LwM2M client for the IoT device 100.

[0132] Providing 906 the contents of the MUD file to the LwM2M client for the IoT device 100 using CoAP may include providing the MUD object using a POST CoAP command or a PUT CoAP command. Providing the MUD object using the POST CoAP command or the PUT CoAP command may include accessing resources defined in an LwM2M resource structure of the LwM2M server 130; accessing a mapping between the resources and the MUD object; and generating or updating the MUD file in the local memory of the IoT device 100 based on the mapping of the MUD object to the resource.

[0133] Now, in Figure 11 Various corresponding operations to be performed by the RD server 150 are described in the context of Figure 11 , the RD server 150 is used to receive 1100 a command from the IoT device 100 for registering the URL of the MUD file stored in the local memory of the IoT device 100. The RD server 150 stores 1102 the URL as a MUD-based resource type in an object structure maintained by the RD server 150. The RD server 150 sends 1102 the URL to the electronic device ( Figure 2 160) provides 1104 a URL in response to 1104 a query from the electronic device to identify a MUD-based resource type.

[0134] In the above description of various embodiments of the present disclosure, it will be understood that the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention. Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as those generally understood by those of ordinary skill in the art to which the present disclosure belongs. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of this specification and related art, and will not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0135] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of the systems, methods, and computer program products according to various aspects of the present disclosure, including architectures, functions, and operations. In this regard, each box in a flowchart or block diagram may represent a module, segment, or code portion that includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions annotated in the boxes may not occur in the order annotated in the accompanying drawings. For example, two consecutive boxes may actually be executed substantially in parallel, and these boxes may sometimes be executed in the opposite order, depending on the functions involved. It will also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs the specified function or operation.

[0136] The terms used herein are for the purpose of describing particular aspects only and are not intended to limit the present disclosure. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "comprising", when used in this specification, specifies the presence of stated features, integers, steps, operations, units and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, units, components and / or combinations thereof. As used herein, the term "and / or" includes any and all combinations of one or more listed associated items. Identical reference numerals within the description of the figures represent identical elements.

[0137] The corresponding structures, materials, operations and equivalents of all functionally defined means or steps in the following claims are intended to include any disclosed structure, material or operation for performing the function in combination with other units specifically indicated in the claims. The description of the present disclosure is provided for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. Various aspects of the disclosure herein are selected and described in order to best explain the principles and practical applications of the disclosure and to enable others of ordinary skill in the art to understand the disclosure with various modifications suitable for the specific purposes envisioned.

[0138] Various abbreviations used in this article include:

[0139] Abbreviation

[0140] CoAP Constrained Application Protocol, an IETF standard for a REST-based application layer protocol for the Internet of Things

[0141] LwM2M Lightweight Machine to Machine, OMA standard

[0142] IETF Internet Engineering Task Force, a standards development organization

[0143] IoT

[0144] MUD Manufacturer Usage Description

[0145] OMA Open Mobile Alliance, a standards development organization

[0146] RD Resource Directory

[0147] rt resource type

[0148] URL Uniform Resource Locator

Claims

1. A method for an Internet of Things (IoT) device, the method comprising: Hosting (500) a manufacturer usage description MUD file in a local memory of the IoT device; Obtaining, by a lightweight machine-to-machine (LwM2M) client for the IoT device and in the IoT device, a MUD object from an LwM2M server; Storing the MUD object in the MUD file in the local memory of the IoT device; as well as The content of the MUD file is opened (502) from the local memory of the IoT device as a Constrained Application Protocol (CoAP) resource.

2. The method according to claim 1, wherein Opening (502) the contents of the MUD file from the local memory of the IoT device as the CoAP resource includes: The contents of the MUD file are provided (504) from the local memory of the IoT device to a MUD manager using CoAP to create an access policy that controls communication with the IoT device through at least one of a network router and a network switch.

3. The method according to claim 2, wherein: Providing (504) the contents of the MUD file from the local memory of the IoT device to the MUD manager using CoAP includes: providing the MUD manager with a to-device-policy that controls communications to the IoT device; and The MUD manager is provided with a from-device-policy, which controls communications from the IoT device.

4. The method according to any one of claims 2 to 3, wherein Providing (504) the contents of the MUD file from the local memory of the IoT device to the MUD manager using CoAP includes: Receiving, by the CoAP server on the IoT device, a CoAP GET command from the MUD manager; and The CoAP server on the IoT device provides the content of the MUD file to the MUD manager in response to the CoAP GET command.

5. The method according to any one of claims 2 to 3, wherein: The content of the MUD file provided (504) to the MUD manager includes a YANG-based JSON object describing network behavior for the IoT device.

6. The method according to any one of claims 1 to 3, wherein Obtaining (600) the MUD object from the LwM2M server by the LwM2M client for the IoT device includes: Receiving resources defined in an LwM2M resource structure from the LwM2M server; accessing the mapping between the resource and the MUD object; and The MUD file in the local memory of the IoT device is generated or updated based on the MUD object mapped to the resource received from the LwM2M server.

7. The method according to claim 6, further comprising: In response to generating or updating the MUD file in the local memory of the IoT device, providing the content of the generated or updated MUD file to the MUD manager using CoAP to create another access policy, wherein the another access policy controls communication with the IoT device through at least one of a network router and a network switch.

8. A non-transitory computer-readable medium storing instructions, wherein the instructions are configured to be executed by at least one processor of an Internet of Things (IoT) electronic device so as to cause the at least one processor to perform the method according to any one of claims 1 to 3.

9. A method for a lightweight machine-to-machine (LwM2M) server, the method comprising: receiving (900) a registration command from a LwM2M client for an Internet of Things (IoT) device using the Constrained Application Protocol CoAP; determining ( 902 ) a policy to be used to control communications with the IoT device; Determining (904) content of a manufacturer usage description MUD file based on the determined policy; as well as The contents of the MUD file are provided (906) to the LwM2M client for the IoT device using CoAP.

10. The method according to claim 9, further comprising: receiving ( 1000 ) a command from the LwM2M client for the IoT device to register a URL of a MUD file stored in a local memory of the IoT device; Storing (1002) the URL as a MUD-based resource type in a LwM2M object structure maintained by the LwM2M server; as well as A query identifying the MUD-based resource type from the electronic device is responded to (1004) by providing (1004) the URL to the electronic device.

11. The method according to claim 10, wherein: The command is received (1000) from the LwM2M client for the IoT device using CoAP.

12. The method according to any one of claims 10 to 11, wherein The URL is received (1000) in a POST CoAP command from the LwM2M client for the IoT device.

13. The method according to any one of claims 9 to 11, wherein Providing (906) the content of the MUD file to the LwM2M client for the IoT device using CoAP includes: Use the POST CoAP command or the PUT CoAP command to provide the MUD object.

14. The method according to claim 13, wherein Providing the MUD object using the POST CoAP command or the PUT CoAP command includes: Accessing resources defined in the LwM2M resource structure of the LwM2M server; accessing the mapping between the resource and the MUD object; and Based on the MUD object mapped to the resource, the MUD file in the local memory of the IoT device is generated or updated. 15 . A non-transitory computer-readable medium storing instructions configured to be executed by at least one processor of a lightweight machine-to-machine (LwM2M) server so as to cause the at least one processor to perform the method according to claim 9 .

16. An Internet of Things (IoT) device (100), comprising: at least one processor (400); as well as At least one memory (410) coupled to the at least one processor (400) and comprising computer readable program code which, when executed by the at least one processor (400), causes the at least one processor (400) to perform the method according to any one of claims 1 to 7.

17. A lightweight machine-to-machine (LwM2M) server (130), comprising: at least one processor (400); as well as At least one memory (410) coupled to the at least one processor (400) and comprising computer readable program code which, when executed by the at least one processor (400), causes the at least one processor (400) to perform the method according to any one of claims 9 to 14.

Images