idnits 2.17.1 draft-faibish-iot-ddos-usecases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'GPTEE' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEEP WG S. Faibish 2 Internet-Draft Dell EMC 3 Intended status: Informational July 7, 2019 4 Expires: January 7, 2020 6 Usecases definition for IoT DDoS attacks prevention 7 draft-faibish-iot-ddos-usecases-00 9 Abstract 11 This document specifies several usecases related to the different 12 ways IoT devices are exploited by malicious adversaries to 13 instantiate Distributed Denial of Services (DDoS) attacks. The 14 attacks are generted from IoT devices that have no proper protection 15 against generating unsolicited communication messages targeting a 16 certain network and creating large amounts of network traffic. The 17 attackers take advantage of breaches in the configuration data in 18 unprotected IoT devices exploited for DDoS attacks. The attackers 19 take advantage of the IoT devices that can send network packets 20 that were generated by malicious code that interacts with an OS 21 implementation that runs on the IoT devices. The prupose of this 22 draft is to prsent possible IoT DDoS usecases that need to be 23 prevented by TEE. The major enabler of such attacks is related to 24 IoT devices that have no OS or unprotected EE OS and run 25 code that is downloaded to them from the TA and modified by 26 man-in-the-middle that inserts malicious code in the OS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of Internet-Draft Shadow Directories can be accessed at 44 https://www.ietf.org/standards/ids/internet-draft-mirror-sites/. 46 This Internet-Draft will expire on January 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Upgradable OS less IoT devices . . . . . . . . . . . . . . 4 70 4.2. IoT devices connected to a gateway server . . . . . . . . 5 71 4.3. Smart IoT devices with full OS . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 10.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Applications executing in an IoT device are exposed to many different 83 attacks intended to compromise the execution of the application, or 84 reveal the data upon which those applications are operating. The 85 problem is more acute for IoT devices that run low level of OS or no 86 OS at all and have limited ability to prevent malicious network 87 traffic leading to DDoS. These attacks increase with the number of 88 applications running on the device, with such other applications 89 coming from potentially untrustworthy sources or due to 90 man-in-the-middle mangling with the application code inserting 91 random packets in the communication of the IoT back to operator. 93 The potential for attacks generated by these devices further 94 increases with the complexity of features and applications on 95 devices, with limited OS capabilities, running code that is 96 downloaded from untrustworthy operators. The 97 danger of attacks on a OS less system increases as the data 98 transmitted by the devices to the operator increases. 100 As an example, an IoT device that sends pollution data each minute 101 from city wide sensors to a cloud application that analyses city air 102 quality and generate reports and warning to the public can be used 103 to send random data at much higher frequency like 1000 per second. 104 This malicious transmission can shut down the cloud receiving this 105 data. The worst part of this is that the IoT device OS has no idea 106 that the transmission is wrong and is creating DDoS for the cloud 107 used by the IoT devices. Additional there could be coordinated 108 attacks coming from many IoT devices connected to the same cloud 109 and shut down all the cloud services. 111 In general case there is an edge server to which the IoT devices 112 are connected and the server is managing the management of the 113 data transmitted to the OA. In this case the edge server has an 114 OS and a TEE that can prevent DDoS attacks that were generated 115 by the IoT devices if the transmission is malicious. Moreover 116 the edge server will facilitate the code upgrade and prevent 117 malicious code being stored on the device code. So, the edge 118 server will become the TEE for all the devices connected to it. 119 Moreover if the code of the device is compromised the edge 120 server will block the packets that were generated by the IoT 121 devices connected to it. 123 According to analysts study DDoS originated from IoT devices 124 accounted for 90% of all the DDoS attacks and increased 10x 125 in 2018 ([1]) and the majority of the attacks were from devices 126 with limited compute and OS resources as well as webcams with REE. 127 This will require special TEE protocol support preventing the use 128 of these devices for DDoS attacks. This draft is trying to present 129 the usecases that enable such attacks with the intention to request 130 that TEEP WG addresses this special security loophole. And the major 131 problem resides in the inability of IoT devices to prevent 132 broadcasting network packets generated by unauthorized code, inserted 133 at upgrade time, to execute on devices with low compute capabilities. 135 Trusted Execution Environments (TEEs), including Intel SGX, ARM 136 TrustZone, Secure Elements, and others, can enforce that only 137 authorized code can execute within the TEE, and any memory used by 138 such code is protected against tampering or disclosure outside the 139 TEE. This observation is only true if there is awareness that IoT 140 devices are enabled to send data back to the cloud and or the SP 141 that did the upgrade. In such environments malicious code includes 142 a method of external triggered or time based attacks. 144 In most such devices there is none or limited "Trusted Agent" or 145 "Trusted Application Manager (TAM)" on the client side running 146 inside the TEE. The purpose of this draft is to present 3 DDoS 147 usecases that TEEP needs to address prevention of using the IoT 148 devices as the origin of such attacks. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 This document also uses various terms defined in 159 [I-D.ietf-teep-architecture], including Trusted Execution Environment 160 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 161 Agent, and Broker. 163 3. Assumptions 164 This draft assumes that an applicable device may or may not be 165 equipped with any TEEs nor pre-provisioned with a device-unique 166 public/private key pair, which is securely stored. 168 A TEE uses an isolation mechanism between Trusted Applications to 169 ensure that one TA cannot read, modify or delete the data and code of 170 another TA. We also assume that there can be a TEE running in a edge 171 server to which the devices may be connected. The edge server will 172 include such a TEE and will become the secure gateway as 173 client/agent. 175 4. Usecases 177 4.1 Upgradable OS less IoT devices 179 The simplest IoT device we refer to here is a device that has enough 180 OS and EE to perform a single function like sending back to the 181 broker time series at given time intervals, Figure 1. As an example 182 an IoT device that monitors the air quality in a city and send back 183 to the cloud this data that will be aggregated with many sensors 184 around the city. The device will run simple code that can be executed 185 on the device and at a minimum it will be capable to receive and 186 install code upgrades from the Broker. Such devices have very 187 limited or no security or trust protection and it can be exposed 188 to man-in-the-middle attacks target by malicious actors that are 189 trying to insert malicious code MA (Malicious Application) in the 190 upgraded code. 192 One example of such code may include a trigger, that can be activated 193 in a similar manner as the code upgrade request, and used to start 194 DDoS attacks coordinated as a cluster. As the device function is to 195 send time series data to the cloud the malicious code can send same 196 data 1000s of times fludding the recipient cloud from all the devices 197 in the cluster. As a second example the malicious code can use a 198 timer and start sending empty network packets back to the provider 199 network and also targeting a given IP address of a victim. Such 200 examples are attackes related to Mirai botnets also in [2] as 201 similar attacks were uncovered tergeting for example financial 202 institutions in order to hide cyberattacks for stilling money or 203 even crypto-currency. 204 +-------------------------------------------+ 205 | Device | 206 | | Service Provider 207 | | | 208 | +-------------+ | +--------+ | 209 | | TEE |<------------------------------| |<-+ 210 | | | | | TAM | 211 | | | | | |<-+ 212 | | +---+ +---+ | | +---+----+ | 213 | | |MA | |TA | | | | | 214 | | | | | | | +-------+ | | | 215 | | | | | |<---------| App |<-----------------+ | 216 | | +-+-+ +-+-+ | | | | Device 217 | +---|-----|---+ +-------+ | Administrator 218 +--------|-----|----------------------------+ 219 | +---------------------------------> Legitimate traffic 220 | 221 +---------------------------------------> DDoS traffic 223 Figure 1: OS less IoT devices diagram 225 4.2 IoT devices connected to a gateway server 227 In this case the OS less IoT device is connected to a local edge 228 TEEP server which has rich execution OS and acts as a bridge between 229 the device and the cloud collecting the time series from the device. 230 In this usecase the upgrades are done via the edge gateway server 231 that has full TEEP capabilities and can detect DDoS attacks and 232 prevent the DDoS traffic to escape outside the edge server. For 233 example the edge gateway server could be a computer with full 234 security protection or a mobile device such as a tablet or even a 235 cell phone. We assume that in this case the edge server has a full 236 TEE and can manage several IoT devices running multiple different 237 applications. We also assume that the edge server is connected to 238 a TEEP Broker. For example webcams can be such IoT devices connected 239 to gateway server used for DDoS attacks [1]. 241 +--------------> Legitimate traffic 242 +-------------------------------|-----------+ 243 | Edge gateway | | 244 | +----+---+ | Service Provider 245 | | |----------+ | 246 | +-------------+ | TEEP | | | | 247 | | Device |<------| Broker | | | +--------+ | 248 | | DDoS | | | | +-->| |<-+ 249 | | +---------------->|blocked | | | TAM-1 | 250 | | | traffic|blocked| |<-+ | | |<-+ 251 | | +-+-+ +---+ | +--------+ | | +--------+ | 252 | | |MA | |TA | | | | | 253 | | | | | | | +-------+ | | | 254 | | | | | |<---------| App |--+ | | 255 | | +---+ +---+ | | | | Device Administrator 256 | +-------------+ | | | 257 | | | | 258 | +-------+ | 259 | | 260 | | 261 +-------------------------------------------+ 263 Figure 2: OS less IoT devices connected to gateway server 265 In this scenario the DDoS traffic is only generating network traffic 266 inside the edge limits and can be stopped by the TEE inside the 267 server. For example when an edge server is connected to home 268 appliances such as home temperature control or electricity and water 269 meters that are supposed to send time series to the cloud, 270 triggering a DDoS will not be allowed to send packets outside the 271 gateway limits. It can still prevent sending the sensing data to 272 the cloud destination but TEEP will prevent DDoS traffic outside 273 the edge server. Additional to this using TEEP will prevent 274 code upgrades done from untrusted sources and even detect 275 malicious code to install on the device. In this configuration 276 (Figure 2) SPs do not directly interact with devices. DAs may 277 elect to use a TAM for remote administration of TAs instead of 278 managing each device directly. Moreover the Legitimate traffic 279 can be sanitized to prevent malicious code spread to other devices. 281 4.3 Smart IoT devices with full OS 283 The Internet of Things (IoT) has been posing threats to networks and 284 national infrastructures because of existing weak security in 285 devices. But there are IoT devices and systems that have the OS 286 and compute power to detect and prevent malware for generation DDoS 287 attacks. It is possible that for such devices can implement measures 288 to prevent malware from manipulating actuators (e.g., IoT controlling 289 computer assisted automobiles or self driving cars), or forcing such 290 cars into accidents and damage infrastructures and even lose life. 292 Such an experiment was done in the research communities and there was 293 even a contest about how fast hackers can take control of a car 294 using automatic driving. The results were that the current security 295 of such cars is not strong enough to prevent taking control over the 296 internet. A TEE can be the best way to implement such IoT security 297 functions for "smart" environments using advanced OSes such as cars. 299 TEEs could be used to store variety of sensitive data for IoT 300 devices. For example, a TEE could be used in smart cars to 301 store a driver's biometric information for identification, available 302 in some new cars, and for protecting access driving wheel control 303 mechanism. Figure 3 presents the architecture of such a self 304 driving car. In this usecase the applications run inside the TEE and 305 are connected to the service provider's cloud similar to some 306 "connected" cars (BMW for example). The applications running inside 307 the TEE can be either monitoring functions or car status (TA1) or 308 diagnostic malfunctions (TA2). All these applications can be vital to 309 the operation of the car and the safety of the drivers and roads. 310 In general in this usecase the Service provider and the Device 311 Administrator are represented by the vehicle manufacturer during 312 the warranty time and after that they can be a different service 313 provider doing maintenance. 315 +-------------------------------------------+ 316 | Device | Car Manufacturer 317 | +--------+ | or Service Provider 318 | | |----------+ | 319 | +-------------+ | TEEP |---------+| | 320 | | TEE-1 |<------| Broker | | || +--------+ | 321 | | | | |<---+ | |+-->| |<-+ 322 | | | | | | | | +-| TAM-1 | 323 | | | | |<-+ | | +->| | |<-+ 324 | | +---+ +---+ | +--------+ | | | | +--------+ | 325 | | |TA1| |TA2| | | | | | TAM-2 | | 326 | +-->| | | | | +-------+ | | | +--------+ | 327 | | | | | | |<---------| App-2 |--+ | | | 328 | | | +---+ +---+ | +-------+ | | | Car Manufacturer 329 | | +-------------+ | App-1 | | | | 330 | | | | | | | 331 | +--------------------| |---+ | | 332 | | |--------+ | 333 | +-------+ | 334 +-------------------------------------------+ 335 Figure 3: OS capable IoT devices for connected cars 337 There are additional usecases similar to this one like electric 338 power and grid monitoring and control that have rich compute and 339 memory resources running in a centralized location (secure) or 340 in the cloud (unsecure) but need high levels of security. 342 There are additional security models of IoT devices that can fit 343 in these 3 examples and we will extend the protocols to apply to 344 as many as we can consider as useful. 346 8. Security Considerations 348 Although TEEP architecture document [I-D.ietf-teep-architecture] 349 addresses some IoT devices examples there are IoT usecases that 350 require more detailed design and better definitions of the Broker 351 behavior in different usecases discussed in this draft. As such, 352 Broker implementations MUST support many of this usecases critical 353 for security and safety. 355 9. IANA Considerations 357 This document does not require actions by IANA. 359 10. References 361 10.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, . 368 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 369 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 370 May 2017, . 372 10.2. Informative References 374 [1] Vlajic, N., and Zhou, D., "IoT as a Land of Opportunity 375 for DDoS Hackers", Computer Magazine, July 2018, pp. 376 26-34. 378 [2] Kolias, C., Kambourakis, G., Stavrou, A., and Voas, J., 379 "DDoS in the IoT: Mirai and Other Botnets", Computer 380 Magazine, July 2017, pp. 80-84. 382 [I-D.ietf-teep-architecture] 383 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 384 Liu, "Trusted Execution Environment Provisioning (TEEP) 385 Architecture", draft-ietf-teep-architecture-02 (work in 386 progress), March 2019. 388 [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE 389 System Architecture, v1.1", Global Platform GPD_SPE_009, 390 January 2017, . 393 Acknowledgments 395 This draft has attempted to capture many IoT security usecases known 396 to the author and presented in the literature as well as discussed 397 in the security forums. These usecases present challenges both for 398 DDoS attacks that became critical as well as applied security for 399 new autonomous devices. We proposed to add these usecases to the 400 TEEP Architecture draft. 402 Author's Address 404 Sorin Faibish 405 Dell EMC 406 228 South Street 407 Hopkinton, MA 01774 408 United States of America 410 Phone: +1 508-249-5745 411 Email: faibish.sorin@dell.com