Requirements for DTLS 1.3 in Constrained IoT Devices

Document Type Active Internet-Draft (individual)
Last updated 2018-10-22
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
UTA                                                              B. Yang
Internet-Draft                                              China Mobile
Intended status: Informational                          October 19, 2018
Expires: April 22, 2019

          Requirements for DTLS 1.3 in Constrained IoT Devices


   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

   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
   ( 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.

Yang                     Expires April 22, 2019                 [Page 1]
Internet-Draft              DTLS 1.3 for IoT                October 2018

Table of Contents

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

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

   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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Yang                     Expires April 22, 2019                 [Page 2]
Internet-Draft              DTLS 1.3 for IoT                October 2018

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.

   o  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

      *  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

      *  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.

   o  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.

   o  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.

   o  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.

Yang                     Expires April 22, 2019                 [Page 3]
Internet-Draft              DTLS 1.3 for IoT                October 2018

   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:

   o  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.

   o  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

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:

   o  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.

Yang                     Expires April 22, 2019                 [Page 4]
Internet-Draft              DTLS 1.3 for IoT                October 2018

   o  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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC7925]  Tschofenig, H., Ed. and T. Fossati, "Transport Layer
              Security (TLS) / Datagram Transport Layer Security (DTLS)
              Profiles for the Internet of Things", RFC 7925,
              DOI 10.17487/RFC7925, July 2016,

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

Author's Address

   Yang Boyle
   China Mobile


Yang                     Expires April 22, 2019                 [Page 5]