Requirements for DTLS 1.3 in Constrained IoT Devices
draft-yang-uta-dtls13-for-iot-00

Abstract

The purpose of this document is to summarize several typical terminals and service types in using DTLS 1.3 for constrained IoT devices, especially those of cellular networks, analyses the existing problems on TLS/DTLS solution on constrained devices and provides some suggestions are given.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 22, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. IoT Services Scenarios and Devices
• 4. Suggestions and Considerations
• 4.1. Shorten Message Size of Handshaking
• 4.2. Problems Introduced by NAT
• 4.3. Long-time Dormancy Devices
• 5. Normative References
• Author's Address

1. Introduction

There are many kinds of IoT devices, thus many classification methods accrodingly. From the communication throughput aspect, IoT devices can be divided into low-speed, high-speed devices. From the geographical location aspects, they can be divided into: mobile devices, fixed devices. From the processing capacity, they can be divided into simple mobile devices, smart mobile devices.

IoT Services can be divided into personal application, family application, vertical industry application according to different usage situations.

Different types of devices and services have different communication and service characteristics, but in general, saving resources and communication security are common requirements.

[RFC 7925] introduced the IoT profiles in using TLS/DTLS 1.2. [RFC 8446] introduced a new and clean TLS 1.3. [draft-tschofenig-uta-tls13-profile-01] offered communication security services for IoT applications and is reasonably implementable on many constrained devices.

This document summarizes several terminal and service types in using DTLS 1.3 for constrained IoT devices, especially those of cellular networks, analyses the existing problems on TLS/DTLS solution on constrained devices and provides some suggestions are given.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. IoT Services Scenarios and Devices

In different scenarios, IoT services show different characteristics, and their device and security requirements are considerably different. This section lists several typical IoT usage scenarios to analyze its device features and security requirements.

• Low mobility, low traffic applications: these devices mainly rely on battery power, reduce communication costs means effectively extend the battery life, thereby saving operation and maintenance costs.
  • Watt-hour meter/water meter: This kind of device is always installed in a fixed location, usually periodically reports the measurement data, for example, sends the data to the server once a month; The traffic is tiny, but IP address (NAT address) is assigned when establish connections, so it is always not fixed.
  • Electrical appliances control: These devices move in restricted locations and communicate at low frequencies, usually communicate several times a day; these devices usually have relatively fixed IP addresses or NAT address ranges.

• Low mobility, high communication throughput applications, such as wireless surveillance cameras. This kind of equipment moves in the limited location, the communication frequency is high, the bandwidth is hug, but the processing capability of this kind is low. Reducing resources consumption for the security functions shall obviously cut down the hardware cost.
• High mobility and low communication throughput applications such as, temperature sensors on refrigerated trucks. Such devices move fast, but only send data to the server when the specific time or condition is satisfied, such as temperature is beyond the threshold. Because of its mobility, cellular network is usually used to transmit data. Similarly, because of mobility, the IP address and network signal of these devices always changes. How to reduce affect of handover and the reliability of communication shall be the key issue.
• High mobility and high traffic applications: such as: live news broadcast, such as equipment moving fast, with high communication frequency and large communication bandwidth requirement. Reducing the cost of security processing during these frequent network handover is beneficial to avoid the decline of service quality caused by resource competition.

As can be seen from the above four scenarios, it is of great value for any Internet of Things application to save the cost of security functions from the device apect.

4. Suggestions and Considerations

For the application of DTLS 1.3 profile on IoT, protocol level optimization focused on features of device capacity and the network connection, the communication processing overhead of DTLS 1.3 can be reduced, the life cycle of the devices can be prolonged, the cost of device manufacturing and maintenance can be reduced, and the service experience can be improved. This section provides the following suggestions and considerations for DTLS 1.3 IoT implementation.

4.1. Shorten Message Size of Handshaking

In TLS 1.3, the size of handshaking message can be very large. If TCP is used, it will not have a significant impact, but when transmission of large messages on the UDP, it means fragmentation, loss, retransmission, disordering and waiting, which shall contribute to the long latency for DTLS handshake process. This effect is more significant when the device communication traffic rate is low and the network coverage is poor. Simplifying handshaking message size shall reduce the probability of fragmentation and fragmentation. The observations may include:

• Under the precondition that security level is not decreased, the number of fields in the agreement is reduced and the value of the field is shortened.
• Reduce the X.509 certificate fields and omit these unnecessary optional fields. Commonly, the size of the certificate is about 1K bytes, which always cause the message length to exceed MTU (1500).

4.2. Problems Introduced by NAT

Because of the large number of IoT devices, NAT is used in most IoT networks. The problems introduced by NAT include:

• Cookie mismatch issues. Because Client-IP is a input for HMAC of cookie value, when NAT is used, the device and server side have different client-IP, for high-speed mobile devices, due to the frequent device hand-over, the IP address changes shall lead to cookie mismatch.
• Keepalive costs a lot of resources, especially on low-traffic devices, appropriate mechanisms to balance NAT aging and maintaining secure channels is needed.

4.3. Long-time Dormancy Devices

Long-time dormant devices such as Watt-hour meter and water meters, because of the huge number devices with each have low communication frequency, greatly increase the burden in storing PSK in network side and device side. The storage of PSK also increases the risk of PSK leakage. If DTLS 1.3 session initiation process is used each time, a large number of interactions will occur, and the net service traffic is much less than the TLS protocol overhead. We need to consider improving the DTLS mechanism for such devices.

5. Normative References

Author's Address