Internet DRAFT - draft-yang-uta-dtls13-for-iot
draft-yang-uta-dtls13-for-iot
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
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.
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
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 [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
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.
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
(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:
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc7925>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Author's Address
Yang Boyle
China Mobile
China
Email: boyxd@hotmail.com
Yang Expires April 22, 2019 [Page 5]
