idnits 2.17.1 draft-faibish-iot-ddos-usecases-01.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 (December 25, 2019) is 1584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 2 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 December 25, 2019 4 Expires: June 25, 2020 6 Usecases definition for IoT DDoS attacks prevention 7 draft-faibish-iot-ddos-usecases-01 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 present 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 June 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Upgradable OS less IoT devices . . . . . . . . . . . . . . 5 70 4.2. IoT devices connected to a gateway server . . . . . . . . 6 71 4.3. Smart IoT devices with full OS . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Problems with IoT devices arise from the fact that manufacturers 83 ship their devices with almost no security measures and the 84 companies that buy these IoT devices don't have proper 85 visibility/understanding of their networks with these new products. 86 Applications executing in an IoT device are exposed to many different 87 attacks intended to compromise the execution of the application, or 88 reveal the data upon which those applications are operating. The 89 problem is more acute for IoT devices that run low level of OS or no 90 OS at all and have limited ability to prevent malicious network 91 traffic leading to DDoS. These attacks increase with the number of 92 applications running on the device, with such other applications 93 coming from potentially untrustworthy sources or due to 94 man-in-the-middle mangling with the application code inserting 95 random packets in the communication of the IoT back to operator. 97 The potential for attacks generated by these devices further 98 increases with the complexity of features and applications on 99 devices, with limited OS capabilities, running code that is 100 downloaded from untrustworthy operators. 102 The danger of attacks on an OS-less system increases as the data 103 transmitted by the devices to the operator increases. There is 104 provision in the MUD protocol [RFC8520] to add security measures 105 but it does not replace other security measures and only complement 106 existing security measures if they are already in place. 108 But for MUD to work, every IoT device requires a unique MUD-URL 109 specific to the kind of device type/model and matches the needed 110 configuration manifest. There is a MUD file that SHOULD be provided 111 by the device manufacturing that contains instructions for the 112 expected behavior of the device. For cheap OS-less devices the 113 manufacturer does not always provide the accurate behavior and 114 require the network routers to detect malicious traffic and stop 115 it. Abnormal behavior could be limiting the peak request rate 116 of how many requests per minute is normal for the device that is 117 used as prevention control of DDoS. Unfortunately IoT devices 118 manufacturers do not always generate MUD profiles specific to their 119 devices or even their companies. MUD in itself is an important step 120 towards securing IoT devices but it is not enough for preventing 121 DDoS attacks. 123 As an example, an IoT device that sends pollution data each minute 124 from city wide sensors to a cloud application that analyses city air 125 quality and generate reports and warning to the public can be used 126 to send random data at much higher frequency like 1000 per second. 127 This malicious transmission can shut down the cloud receiving this 128 data. The worst part of this is that the IoT device OS has no idea 129 that the transmission is wrong and is creating DDoS for the cloud 130 used by the IoT devices. Additional there could be coordinated 131 attacks coming from many IoT devices connected to the same cloud 132 and shut down all the cloud services. 134 In general case there is an edge server to which the IoT devices 135 are connected and the server is managing the management of the 136 data transmitted to the OA. In this case the edge server has an 137 OS and a TEE that can prevent DDoS attacks that were generated 138 by the IoT devices if the transmission is malicious. Moreover 139 the edge server will facilitate the code upgrade and prevent 140 malicious code being stored on the device code. So, the edge 141 server will become the TEE for all the devices connected to it. 142 Moreover if the code of the device is compromised the edge 143 server will block the packets that were generated by the IoT 144 devices connected to it. 146 According to analysts study DDoS originated from IoT devices 147 accounted for 90% of all the DDoS attacks and increased 10x 148 in 2018 ([1]) and the majority of the attacks were from devices 149 with limited compute and OS resources as well as webcams with REE. 151 This will require special TEE protocol support preventing the use 152 of these devices for DDoS attacks. This draft is trying to present 153 the usecases that enable such attacks with the intention to request 154 that TEEP WG addresses this special security loophole. And the major 155 problem resides in the inability of IoT devices to prevent 156 broadcasting network packets generated by unauthorized code, inserted 157 at upgrade time, to execute on devices with low compute capabilities. 159 Trusted Execution Environments (TEEs), including Intel SGX, ARM 160 TrustZone, Secure Elements, and others, can enforce that only 161 authorized code can execute within the TEE, and any memory used by 162 such code is protected against tampering or disclosure outside the 163 TEE. This observation is only true if there is awareness that IoT 164 devices are enabled to send data back to the cloud and or the SP 165 that did the upgrade. In such environments malicious code includes 166 a method of external triggered or time based attacks. 168 In most such devices there is none or limited "Trusted Agent" or 169 "Trusted Application Manager (TAM)" on the client side running 170 inside the TEE. The purpose of this draft is to present 3 DDoS 171 usecases that TEEP needs to address prevention of using the IoT 172 devices as the origin of such attacks. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 This document also uses various terms defined in 183 [I-D.ietf-teep-architecture], including Trusted Execution Environment 184 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 185 Agent, and Broker. 187 3. Assumptions 188 This draft assumes that an applicable device may or may not be 189 equipped with any TEEs nor pre-provisioned with a device-unique 190 public/private key pair, which is securely stored. 192 A TEE uses an isolation mechanism between Trusted Applications to 193 ensure that one TA cannot read, modify or delete the data and code of 194 another TA. We also assume that there can be a TEE running in a edge 195 server to which the devices may be connected. The edge server will 196 include such a TEE and will become the secure gateway as 197 client/agent. 199 4. Usecases 201 4.1 Upgradable OS less IoT devices 203 The simplest IoT device we refer to here is a device that has enough 204 OS and EE to perform a single function like sending back to the 205 broker time series at given time intervals, Figure 1. As an example 206 an IoT device that monitors the air quality in a city and send back 207 to the cloud this data that will be aggregated with many sensors 208 around the city. The device will run simple code that can be executed 209 on the device and at a minimum it will be capable to receive and 210 install code upgrades from the Broker. Such devices have very 211 limited or no security or trust protection and it can be exposed 212 to man-in-the-middle attacks target by malicious actors that are 213 trying to insert malicious code MA (Malicious Application) in the 214 upgraded code. 216 One example of such code may include a trigger, that can be activated 217 in a similar manner as the code upgrade request, and used to start 218 DDoS attacks coordinated as a cluster. As the device function is to 219 send time series data to the cloud the malicious code can send same 220 data 1000s of times fludding the recipient cloud from all the devices 221 in the cluster. As a second example the malicious code can use a 222 timer and start sending empty network packets back to the provider 223 network and also targeting a given IP address of a victim. Such 224 examples are attackes related to Mirai botnets also in [2] as 225 similar attacks were uncovered tergeting for example financial 226 institutions in order to hide cyberattacks for stilling money or 227 even crypto-currency. 228 +-------------------------------------------+ 229 | Device | 230 | | Service Provider 231 | | | 232 | +-------------+ | +--------+ | 233 | | TEE |<------------------------------| |<-+ 234 | | | | | TAM | 235 | | | | | |<-+ 236 | | +---+ +---+ | | +---+----+ | 237 | | |MA | |TA | | | | | 238 | | | | | | | +-------+ | | | 239 | | | | | |<---------| App |<-----------------+ | 240 | | +-+-+ +-+-+ | | | | Device 241 | +---|-----|---+ +-------+ | Administrator 242 +--------|-----|----------------------------+ 243 | +---------------------------------> Legitimate traffic 244 | 245 +---------------------------------------> DDoS traffic 247 Figure 1: OS less IoT devices diagram 249 4.2 IoT devices connected to a gateway server 251 In this case the OS less IoT device is connected to a local edge 252 TEEP server which has rich execution OS and acts as a bridge between 253 the device and the cloud collecting the time series from the device. 254 In this usecase the upgrades are done via the edge gateway server 255 that has full TEEP capabilities and can detect DDoS attacks and 256 prevent the DDoS traffic to escape outside the edge server. For 257 example the edge gateway server could be a computer with full 258 security protection or a mobile device such as a tablet or even a 259 cell phone. We assume that in this case the edge server has a full 260 TEE and can manage several IoT devices running multiple different 261 applications. We also assume that the edge server is connected to 262 a TEEP Broker. For example webcams can be such IoT devices connected 263 to gateway server used for DDoS attacks [1]. 265 +--------------> Legitimate traffic 266 +-------------------------------|-----------+ 267 | Edge gateway | | 268 | +----+---+ | Service Provider 269 | | |----------+ | 270 | +-------------+ | TEEP | | | | 271 | | Device |<------| Broker | | | +--------+ | 272 | | DDoS | | | | +-->| |<-+ 273 | | +---------------->|blocked | | | TAM-1 | 274 | | | traffic|blocked| |<-+ | | |<-+ 275 | | +-+-+ +---+ | +--------+ | | +--------+ | 276 | | |MA | |TA | | | | | 277 | | | | | | | +-------+ | | | 278 | | | | | |<---------| App |--+ | | 279 | | +---+ +---+ | | | | Device Administrator 280 | +-------------+ | | | 281 | | | | 282 | +-------+ | 283 | | 284 | | 285 +-------------------------------------------+ 287 Figure 2: OS less IoT devices connected to gateway server 289 In this scenario the DDoS traffic is only generating network traffic 290 inside the edge limits and can be stopped by the TEE inside the 291 server. For example when an edge server is connected to home 292 appliances such as home temperature control or electricity and water 293 meters that are supposed to send time series to the cloud, 294 triggering a DDoS will not be allowed to send packets outside the 295 gateway limits. 297 It can still prevent sending the sensing data to 298 the cloud destination but TEEP will prevent DDoS traffic outside 299 the edge server. Additional to this using TEEP will prevent 300 code upgrades done from untrusted sources and even detect 301 malicious code to install on the device. In this configuration 302 (Figure 2) SPs do not directly interact with devices. DAs may 303 elect to use a TAM for remote administration of TAs instead of 304 managing each device directly. Moreover the Legitimate traffic 305 can be sanitized to prevent malicious code spread to other devices. 307 4.3 Smart IoT devices with full OS 309 The Internet of Things (IoT) has been posing threats to networks and 310 national infrastructures because of existing weak security in 311 devices. But there are IoT devices and systems that have the OS 312 and compute power to detect and prevent malware for generation DDoS 313 attacks. It is possible that for such devices can implement measures 314 to prevent malware from manipulating actuators (e.g., IoT controlling 315 computer assisted automobiles or self driving cars), or forcing such 316 cars into accidents and damage infrastructures and even lose life. 318 Such an experiment was done in the research communities and there was 319 even a contest about how fast hackers can take control of a car 320 using automatic driving. The results were that the current security 321 of such cars is not strong enough to prevent taking control over the 322 internet. A TEE can be the best way to implement such IoT security 323 functions for "smart" environments using advanced OSes such as cars. 325 TEEs could be used to store variety of sensitive data for IoT 326 devices. For example, a TEE could be used in smart cars to 327 store a driver's biometric information for identification, available 328 in some new cars, and for protecting access driving wheel control 329 mechanism. Figure 3 presents the architecture of such a self 330 driving car. In this usecase the applications run inside the TEE and 331 are connected to the service provider's cloud similar to some 332 "connected" cars (BMW for example). The applications running inside 333 the TEE can be either monitoring functions or car status (TA1) or 334 diagnostic malfunctions (TA2). All these applications can be vital to 335 the operation of the car and the safety of the drivers and roads. 336 In general in this usecase the Service provider and the Device 337 Administrator are represented by the vehicle manufacturer during 338 the warranty time and after that they can be a different service 339 provider doing maintenance. 341 There are additional usecases similar to this one like electric 342 power and grid monitoring and control that have rich compute and 343 memory resources running in a centralized location (secure) or 344 in the cloud (unsecure) but need high levels of security. 346 +-------------------------------------------+ 347 | Device | Car Manufacturer 348 | +--------+ | or Service Provider 349 | | |----------+ | 350 | +-------------+ | TEEP |---------+| | 351 | | TEE-1 |<------| Broker | | || +--------+ | 352 | | | | |<---+ | |+-->| |<-+ 353 | | | | | | | | +-| TAM-1 | 354 | | | | |<-+ | | +->| | |<-+ 355 | | +---+ +---+ | +--------+ | | | | +--------+ | 356 | | |TA1| |TA2| | | | | | TAM-2 | | 357 | +-->| | | | | +-------+ | | | +--------+ | 358 | | | | | | |<---------| App-2 |--+ | | | 359 | | | +---+ +---+ | +-------+ | | | Car Manufacturer 360 | | +-------------+ | App-1 | | | | 361 | | | | | | | 362 | +--------------------| |---+ | | 363 | | |--------+ | 364 | +-------+ | 365 +-------------------------------------------+ 366 Figure 3: OS capable IoT devices for connected cars 368 There are additional security models of IoT devices that can fit 369 in these 3 examples and we will extend the protocols to apply to 370 as many as we can consider as useful. 372 5. Security Considerations 374 Although TEEP architecture document [I-D.ietf-teep-architecture] 375 addresses some IoT devices examples there are IoT usecases that 376 require more detailed design and better definitions of the Broker 377 behavior in different usecases discussed in this draft. As such, 378 Broker implementations MUST support many of this usecases critical 379 for security and safety. 381 6. IANA Considerations 383 This document does not require actions by IANA. 385 7. References 387 7.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, . 394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 396 May 2017, . 398 [RFC8520] Lear, E., Droms, R. and Romascanu, D., "Manufacturer 399 Usage Description Specification", March 2019, 400 402 7.2. Informative References 404 [1] Vlajic, N., and Zhou, D., "IoT as a Land of Opportunity 405 for DDoS Hackers", Computer Magazine, July 2018, pp. 406 26-34. 408 [2] Kolias, C., Kambourakis, G., Stavrou, A., and Voas, J., 409 "DDoS in the IoT: Mirai and Other Botnets", Computer 410 Magazine, July 2017, pp. 80-84. 412 [I-D.ietf-teep-architecture] 413 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 414 Liu, "Trusted Execution Environment Provisioning (TEEP) 415 Architecture", draft-ietf-teep-architecture-05 (work in 416 progress), March 2019. 418 Acknowledgments 420 This draft has attempted to capture many IoT security usecases known 421 to the author and presented in the literature as well as discussed 422 in the security forums. These usecases present challenges both for 423 DDoS attacks that became critical as well as applied security for 424 new autonomous devices. We proposed to add these usecases to the 425 TEEP Architecture draft. 427 Author's Address 429 Sorin Faibish 430 Dell EMC 431 228 South Street 432 Hopkinton, MA 01774 433 United States of America 435 Phone: +1 508-249-5745 436 Email: faibish.sorin@dell.com