Defend the World from IoT Remote-threats & Malware

Introduction The DWIRM extension to DHCP defines an "IoT Profile" JSON object defining which services are provided and consumed by that device broken into categories, and specific requirements. Based on local router policies and potential interaction with the network administrator, an optionally amended service confirmation is provided and enforced. For example, consider the following DHCPDWIRMCLIENT message: The IoT device (DWIRMCLIENT) identifies itself as "Example Brand Security Camera," providing "Video Stream" and "Management" services, and consuming a "Firmware Update" service. In addition to specific port ranges, the expected transfer rates and operational time windows are offered. If DWIRM is supported by the local router, this message would be followed by a corresponding DHCPDWIRMSERVER message notifying the DWIRM client device of any changes in enforcement based on the local router policy. If, for any reason, this the local router is unable to respond within 100 milliseconds, it will continue with a DHCPOFFER. In this scenario, the DWIRM client will accept an unsolicited DHCPDWIRMSERVER message from the local router. In this example, the the DWIRM server, responds with the following message: This DHCPDWIRMSERVER message is identical to the request, with the exception of the "PortFwd" option, which has been left blank, indicating port-forwarding will not be enabled. The DWIRM server may also a special JSON object to fully allow or deny the DWIRM client request, by using the "Status" sub-object, as shown below.

Problem Statement A myriad of IoT devices currently exist on the internet, with more each day. This poses great risks to the local network, as well as to the internet as a whole. By requiring devices to provide specifics around how it is seen on the local network, safeguards can be put in place to restrict those devices to those services (least privilege). It is the hopes of the authors, that by understanding how a device expects to be used, will lead to the elimination of large scale malware bots targeting IoT devices.

Background and Terminology The reader is assumed to be familiar with the basic DHCP terminology defined in and subsequent RFCs that update them in , , , and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

The "IoT Profile" Object Fundamental to DWIRM negotiation is the structure of the "IoT Profile" object. It defines how services are to be advertised and managed and is broken into the following strings and sub-objects:

Description: The description is a string used to provide a user friendly device description to the user.

Provide: The provide object contains one or more category objects, described below, that the device offers to the network.

Consume: The consume object contains one or more category objects, described below, that the device connects to, over the network.

Status: The status object is used exclusively by the DWIRM server and MUST contain a value of "Accept" or "Deny." This is used to accept or deny the DWIRM client's request, in full.

Category: The category object provides specific requirements for that specific service category. The category key name will be used to inform the local router policy or local network administrator the type of service consumed or provided. This key name will come from a managed DWIRM category registry. Default option values from each category are also provided as part of this registry.

Defined Categories: This document defines the following baseline categories:

Full Access: This is a special access request for home computing devices, such as smartphones, desktops, laptops and tablets. It is strongly recommended this category be accompanied by a form of DHCP based authentication so it cannot be abused by IoT devices.

HTTP: This defines an HTTP service around the clock on ports 80 and 443.

Category Options: The options listed in this section must exist or be defaulted to the local network administrator's settings. It is strongly recommended these defaults are of least-privileged.

Endpoints: The endpoints option provides an array of hostnames, IP-Addresses, and URL's the device expects to connect to. Based on local router capabilities, it can enforce restrictions based on this option.

Hints: The hints option provides protocol specific details that can be used to identify and restrict activity being conducted over provided ports.

PortFwd: The portfwd option provides a request to the local router that MAY be used to automatically provide a port-forwarding service from the external WAN connection to the internal IP-address assigned to the requesting IoT device. The format for this field is a list of ranges [a-b] separated by commas [,] for this internal ports of the device; a colon [:]; and a list of ranges [a-b] separated by commas [,] for the external ports on the WAN. Ranges can be a hyphenated range of low port to high port, or a single port, without a hyphen. The number of ranges and number of usable ports within those ranges on the internal side MUST match the number of ranges and number of usable within those ranges on the external side.

Ports: The ports option provides a list of ranges [a-b] separated by commas [,]. Ranges can be a hyphenated range of low port to high port, or a single port, without a hyphen.

Rate: This option specifies the maximum throughput to be expected by the device for the specified service. Common abbreviations for (k)ilo, (m)ega, and (g)igi, can be used in this option, and are case-insensitive. The value of "Line" may also be used to specify the line-rate of the local router's network interface.

Schedule: This option specifies when this service is authorized to be active. It consists of two time-fields separated by a hyphen [-]. Each time-field consists of a two digit hour field, in 24-hour format, followed by a colon [:], followed by a two digit minute field. The time-zone for this option defaults to Greenwich Mean Time (GMT), but may be overridden by appending "L" for the local time zone, or a standard three character time-zone abbreviation to the end of this field. The string of "All Day" is also accepted as an alias for "00:00-23:59".

DHCP Message Type-53 Types

DHCPDWIRMCLIENT: This provides the mechanism for the client to provide the JSON encapsulated "IoT Profile" object.

DHCPDWIRMSERVER: This provides the mechanism for the server to respond with the JSON encapsulated "IoT Profile" object.

Interactions with other IoT Management Offerings This does not take into account other IoT management offerings such as Matter or Threads at this time. There are possibilities for collaboration.

Known Limitations There are no known limitations.

Security Considerations There are no known security considerations.

Privacy Considerations There are no known privacy considerations.

IANA Considerations IANA is requested to assign DHCP Message Types for DHCPDWIRMCLIENT and DHCPDWIRMSERVER, as well as a registry for managing categories and default service capabilities.