idnits 2.17.1 draft-yang-uta-dtls13-for-iot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7925' is mentioned on line 79, but not defined == Unused Reference: 'RFC7925' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 218, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA B. Yang 3 Internet-Draft China Mobile 4 Intended status: Informational October 19, 2018 5 Expires: April 22, 2019 7 Requirements for DTLS 1.3 in Constrained IoT Devices 8 draft-yang-uta-dtls13-for-iot-00 10 Abstract 12 The purpose of this document is to summarize several typical 13 terminals and service types in using DTLS 1.3 for constrained IoT 14 devices, especially those of cellular networks, analyses the existing 15 problems on TLS/DTLS solution on constrained devices and provides 16 some suggestions are given. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 22, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. IoT Services Scenarios and Devices . . . . . . . . . . . . . 3 55 4. Suggestions and Considerations . . . . . . . . . . . . . . . 4 56 4.1. Shorten Message Size of Handshaking . . . . . . . . . . . 4 57 4.2. Problems Introduced by NAT . . . . . . . . . . . . . . . 4 58 4.3. Long-time Dormancy Devices . . . . . . . . . . . . . . . 5 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 There are many kinds of IoT devices, thus many classification methods 65 accrodingly. From the communication throughput aspect, IoT devices 66 can be divided into low-speed, high-speed devices. From the 67 geographical location aspects, they can be divided into: mobile 68 devices, fixed devices. From the processing capacity, they can be 69 divided into simple mobile devices, smart mobile devices. 71 IoT Services can be divided into personal application, family 72 application, vertical industry application according to different 73 usage situations. 75 Different types of devices and services have different communication 76 and service characteristics, but in general, saving resources and 77 communication security are common requirements. 79 [RFC 7925] introduced the IoT profiles in using TLS/DTLS 1.2. [RFC 80 8446] introduced a new and clean TLS 1.3. [draft-tschofenig-uta- 81 tls13-profile-01] offered communication security services for IoT 82 applications and is reasonably implementable on many constrained 83 devices. 85 This document summarizes several terminal and service types in using 86 DTLS 1.3 for constrained IoT devices, especially those of cellular 87 networks, analyses the existing problems on TLS/DTLS solution on 88 constrained devices and provides some suggestions are given. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. IoT Services Scenarios and Devices 98 In different scenarios, IoT services show different characteristics, 99 and their device and security requirements are considerably 100 different. This section lists several typical IoT usage scenarios to 101 analyze its device features and security requirements. 103 o Low mobility, low traffic applications: these devices mainly rely 104 on battery power, reduce communication costs means effectively 105 extend the battery life, thereby saving operation and maintenance 106 costs. 108 * Watt-hour meter/water meter: This kind of device is always 109 installed in a fixed location, usually periodically reports the 110 measurement data, for example, sends the data to the server 111 once a month; The traffic is tiny, but IP address (NAT address) 112 is assigned when establish connections, so it is always not 113 fixed. 115 * Electrical appliances control: These devices move in restricted 116 locations and communicate at low frequencies, usually 117 communicate several times a day; these devices usually have 118 relatively fixed IP addresses or NAT address ranges. 120 o Low mobility, high communication throughput applications, such as 121 wireless surveillance cameras. This kind of equipment moves in 122 the limited location, the communication frequency is high, the 123 bandwidth is hug, but the processing capability of this kind is 124 low. Reducing resources consumption for the security functions 125 shall obviously cut down the hardware cost. 127 o High mobility and low communication throughput applications such 128 as, temperature sensors on refrigerated trucks. Such devices move 129 fast, but only send data to the server when the specific time or 130 condition is satisfied, such as temperature is beyond the 131 threshold. Because of its mobility, cellular network is usually 132 used to transmit data. Similarly, because of mobility, the IP 133 address and network signal of these devices always changes. How 134 to reduce affect of handover and the reliability of communication 135 shall be the key issue. 137 o High mobility and high traffic applications: such as: live news 138 broadcast, such as equipment moving fast, with high communication 139 frequency and large communication bandwidth requirement. Reducing 140 the cost of security processing during these frequent network 141 handover is beneficial to avoid the decline of service quality 142 caused by resource competition. 144 As can be seen from the above four scenarios, it is of great value 145 for any Internet of Things application to save the cost of security 146 functions from the device apect. 148 4. Suggestions and Considerations 150 For the application of DTLS 1.3 profile on IoT, protocol level 151 optimization focused on features of device capacity and the network 152 connection, the communication processing overhead of DTLS 1.3 can be 153 reduced, the life cycle of the devices can be prolonged, the cost of 154 device manufacturing and maintenance can be reduced, and the service 155 experience can be improved. This section provides the following 156 suggestions and considerations for DTLS 1.3 IoT implementation. 158 4.1. Shorten Message Size of Handshaking 160 In TLS 1.3, the size of handshaking message can be very large. If 161 TCP is used, it will not have a significant impact, but when 162 transmission of large messages on the UDP, it means fragmentation, 163 loss, retransmission, disordering and waiting, which shall contribute 164 to the long latency for DTLS handshake process. This effect is more 165 significant when the device communication traffic rate is low and the 166 network coverage is poor. Simplifying handshaking message size shall 167 reduce the probability of fragmentation and fragmentation. The 168 observations may include: 170 o Under the precondition that security level is not decreased, the 171 number of fields in the agreement is reduced and the value of the 172 field is shortened. 174 o Reduce the X.509 certificate fields and omit these unnecessary 175 optional fields. Commonly, the size of the certificate is about 176 1K bytes, which always cause the message length to exceed MTU 177 (1500). 179 4.2. Problems Introduced by NAT 181 Because of the large number of IoT devices, NAT is used in most IoT 182 networks. The problems introduced by NAT include: 184 o Cookie mismatch issues. Because Client-IP is a input for HMAC of 185 cookie value, when NAT is used, the device and server side have 186 different client-IP, for high-speed mobile devices, due to the 187 frequent device hand-over, the IP address changes shall lead to 188 cookie mismatch. 190 o Keepalive costs a lot of resources, especially on low-traffic 191 devices, appropriate mechanisms to balance NAT aging and 192 maintaining secure channels is needed. 194 4.3. Long-time Dormancy Devices 196 Long-time dormant devices such as Watt-hour meter and water meters, 197 because of the huge number devices with each have low communication 198 frequency, greatly increase the burden in storing PSK in network side 199 and device side. The storage of PSK also increases the risk of PSK 200 leakage. If DTLS 1.3 session initiation process is used each time, a 201 large number of interactions will occur, and the net service traffic 202 is much less than the TLS protocol overhead. We need to consider 203 improving the DTLS mechanism for such devices. 205 5. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 213 Security (TLS) / Datagram Transport Layer Security (DTLS) 214 Profiles for the Internet of Things", RFC 7925, 215 DOI 10.17487/RFC7925, July 2016, 216 . 218 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 219 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 220 . 222 Author's Address 224 Yang Boyle 225 China Mobile 226 China 228 Email: boyxd@hotmail.com