idnits 2.17.1 draft-faibish-iot-ddos-usecases-04.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 21, 2020) is 1215 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-11 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 Independent Contributor 3 Intended status: Informational M. K. Chowdhury 4 Expires: June 21, 2021 Deloitte Canada 5 December 21, 2020 7 Test Tools for IoT DDoS vulnerability scanning 8 draft-faibish-iot-ddos-usecases-04 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. This draft 27 adds list of MUD files for most IoT devices. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of Internet-Draft Shadow Directories can be accessed at 45 https://www.ietf.org/standards/ids/internet-draft-mirror-sites/. 47 This Internet-Draft will expire on June 21, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Upgradable OS less IoT devices . . . . . . . . . . . . . . 5 71 4.2. IoT devices connected to a gateway server . . . . . . . . 6 72 4.3. Smart IoT devices with full OS . . . . . . . . . . . . . . 7 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 7.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Problems with IoT devices arise from the fact that manufacturers 84 ship their devices with almost no security measures and the 85 companies that buy these IoT devices don't have proper 86 visibility/understanding of their networks with these new products. 87 Applications executing in an IoT device are exposed to many different 88 attacks intended to compromise the execution of the application, or 89 reveal the data upon which those applications are operating. The 90 problem is more acute for IoT devices that run low level of OS or no 91 OS at all and have limited ability to prevent malicious network 92 traffic leading to DDoS. These attacks increase with the number of 93 applications running on the device, with such other applications 94 coming from potentially untrustworthy sources or due to 95 man-in-the-middle mangling with the application code inserting 96 random packets in the communication of the IoT back to operator. 98 The potential for attacks generated by these devices further 99 increases with the complexity of features and applications on 100 devices, with limited OS capabilities, running code that is 101 downloaded from untrustworthy operators. 103 The danger of attacks on an OS-less system increases as the data 104 transmitted by the devices to the operator increases. There is 105 provision in the MUD protocol [RFC8520] to add security measures 106 but it does not replace other security measures and only complement 107 existing security measures if they are already in place. 109 But for MUD to work, every IoT device requires a unique MUD-URL 110 specific to the kind of device type/model and matches the needed 111 configuration manifest. There is a MUD file that SHOULD be provided 112 by the device manufacturing that contains instructions for the 113 expected behavior of the device. For cheap OS-less devices the 114 manufacturer does not always provide the accurate behavior and 115 require the network routers to detect malicious traffic and stop 116 it. Abnormal behavior could be limiting the peak request rate 117 of how many requests per minute is normal for the device that is 118 used as prevention control of DDoS. Unfortunately IoT devices 119 manufacturers do not always generate MUD profiles specific to their 120 devices or even their companies. MUD in itself is an important step 121 towards securing IoT devices but it is not enough for preventing 122 DDoS attacks. 124 As an example, an IoT device that sends pollution data each minute 125 from city wide sensors to a cloud application that analyses city air 126 quality and generate reports and warning to the public can be used 127 to send random data at much higher frequency like 1000 per second. 128 This malicious transmission can shut down the cloud receiving this 129 data. The worst part of this is that the IoT device OS has no idea 130 that the transmission is wrong and is creating DDoS for the cloud 131 used by the IoT devices. Additional there could be coordinated 132 attacks coming from many IoT devices connected to the same cloud 133 and shut down all the cloud services. 135 In general case there is an edge server to which the IoT devices 136 are connected and the server is managing the management of the 137 data transmitted to the OA. In this case the edge server has an 138 OS and a TEE that can prevent DDoS attacks that were generated 139 by the IoT devices if the transmission is malicious. Moreover 140 the edge server will facilitate the code upgrade and prevent 141 malicious code being stored on the device code. So, the edge 142 server will become the TEE for all the devices connected to it. 143 Moreover if the code of the device is compromised the edge 144 server will block the packets that were generated by the IoT 145 devices connected to it. 147 According to analysts study DDoS originated from IoT devices 148 accounted for 90% of all the DDoS attacks and increased 10x 149 in 2018 ([1]) and the majority of the attacks were from devices 150 with limited compute and OS resources as well as webcams with REE. 152 This will require special TEE protocol support preventing the use 153 of these devices for DDoS attacks. This draft is trying to present 154 the usecases that enable such attacks with the intention to request 155 that TEEP WG addresses this special security loophole. And the major 156 problem resides in the inability of IoT devices to prevent 157 broadcasting network packets generated by unauthorized code, inserted 158 at upgrade time, to execute on devices with low compute capabilities. 160 Trusted Execution Environments (TEEs), including Intel SGX, ARM 161 TrustZone, Secure Elements, and others, can enforce that only 162 authorized code can execute within the TEE, and any memory used by 163 such code is protected against tampering or disclosure outside the 164 TEE. This observation is only true if there is awareness that IoT 165 devices are enabled to send data back to the cloud and or the SP 166 that did the upgrade. In such environments malicious code includes 167 a method of external triggered or time based attacks. 169 In most such devices there is none or limited "Trusted Agent" or 170 "Trusted Application Manager (TAM)" on the client side running 171 inside the TEE. The purpose of this draft is to present 3 DDoS 172 usecases that TEEP needs to address prevention of using the IoT 173 devices as the origin of such attacks. 175 2. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 This document also uses various terms defined in 184 [I-D.ietf-teep-architecture], including Trusted Execution Environment 185 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 186 Agent, and Broker. 188 3. Assumptions 189 This draft assumes that an applicable device may or may not be 190 equipped with any TEEs nor pre-provisioned with a device-unique 191 public/private key pair, which is securely stored. 193 A TEE uses an isolation mechanism between Trusted Applications to 194 ensure that one TA cannot read, modify or delete the data and code of 195 another TA. We also assume that there can be a TEE running in a edge 196 server to which the devices may be connected. The edge server will 197 include such a TEE and will become the secure gateway as 198 client/agent. 200 4. Usecases 202 4.1 Upgradable OS less IoT devices 204 The simplest IoT device we refer to here is a device that has enough 205 OS and EE to perform a single function like sending back to the 206 broker time series at given time intervals, Figure 1. As an example 207 an IoT device that monitors the air quality in a city and send back 208 to the cloud this data that will be aggregated with many sensors 209 around the city. The device will run simple code that can be executed 210 on the device and at a minimum it will be capable to receive and 211 install code upgrades from the Broker. Such devices have very 212 limited or no security or trust protection and it can be exposed 213 to man-in-the-middle attacks target by malicious actors that are 214 trying to insert malicious code MA (Malicious Application) in the 215 upgraded code. 217 One example of such code may include a trigger, that can be activated 218 in a similar manner as the code upgrade request, and used to start 219 DDoS attacks coordinated as a cluster. As the device function is to 220 send time series data to the cloud the malicious code can send same 221 data 1000s of times fludding the recipient cloud from all the devices 222 in the cluster. As a second example the malicious code can use a 223 timer and start sending empty network packets back to the provider 224 network and also targeting a given IP address of a victim. Such 225 examples are attackes related to Mirai botnets also in [2] as 226 similar attacks were uncovered tergeting for example financial 227 institutions in order to hide cyberattacks for stilling money or 228 even crypto-currency. 229 +-------------------------------------------+ 230 | Device | 231 | | Service Provider 232 | | | 233 | +-------------+ | +--------+ | 234 | | TEE |<------------------------------| |<-+ 235 | | | | | TAM | 236 | | | | | |<-+ 237 | | +---+ +---+ | | +---+----+ | 238 | | |MA | |TA | | | | | 239 | | | | | | | +-------+ | | | 240 | | | | | |<---------| App |<-----------------+ | 241 | | +-+-+ +-+-+ | | | | Device 242 | +---|-----|---+ +-------+ | Administrator 243 +--------|-----|----------------------------+ 244 | +---------------------------------> Legitimate traffic 245 | 246 +---------------------------------------> DDoS traffic 248 Figure 1: OS less IoT devices diagram 250 4.2 IoT devices connected to a gateway server 252 In this case the OS less IoT device is connected to a local edge 253 TEEP server which has rich execution OS and acts as a bridge between 254 the device and the cloud collecting the time series from the device. 255 In this usecase the upgrades are done via the edge gateway server 256 that has full TEEP capabilities and can detect DDoS attacks and 257 prevent the DDoS traffic to escape outside the edge server. For 258 example the edge gateway server could be a computer with full 259 security protection or a mobile device such as a tablet or even a 260 cell phone. We assume that in this case the edge server has a full 261 TEE and can manage several IoT devices running multiple different 262 applications. We also assume that the edge server is connected to 263 a TEEP Broker. For example webcams can be such IoT devices connected 264 to gateway server used for DDoS attacks [1] spoofing [4]. A list of 265 such IoT devices MUD files is found in [3] used by python tool [5] 266 to test vulnerabilities is available. 268 +--------------> Legitimate traffic 269 +-------------------------------|-----------+ 270 | Edge gateway | | 271 | +----+---+ | Service Provider 272 | | |----------+ | 273 | +-------------+ | TEEP | | | | 274 | | Device |<------| Broker | | | +--------+ | 275 | | DDoS | | | | +-->| |<-+ 276 | | +---------------->|blocked | | | TAM-1 | 277 | | | traffic|blocked| |<-+ | | |<-+ 278 | | +-+-+ +---+ | +--------+ | | +--------+ | 279 | | |MA | |TA | | | | | 280 | | | | | | | +-------+ | | | 281 | | | | | |<---------| App |--+ | | 282 | | +---+ +---+ | | | | Device Administrator 283 | +-------------+ | | | 284 | | | | 285 | +-------+ | 286 | | 287 | | 288 +-------------------------------------------+ 290 Figure 2: OS less IoT devices connected to gateway server 292 In this scenario the DDoS traffic is only generating network traffic 293 inside the edge limits and can be stopped by the TEE inside the 294 server. For example when an edge server is connected to home 295 appliances such as home temperature control or electricity and water 296 meters that are supposed to send time series to the cloud, 297 triggering a DDoS will not be allowed to send packets outside the 298 gateway limits. 300 It can still prevent sending the sensing data to 301 the cloud destination but TEEP will prevent DDoS traffic outside 302 the edge server. Additional to this using TEEP will prevent 303 code upgrades done from untrusted sources and even detect 304 malicious code to install on the device. In this configuration 305 (Figure 2) SPs do not directly interact with devices. DAs may 306 elect to use a TAM for remote administration of TAs instead of 307 managing each device directly. Moreover the Legitimate traffic 308 can be sanitized to prevent malicious code spread to other devices. 310 4.3 Smart IoT devices with full OS 312 The Internet of Things (IoT) has been posing threats to networks and 313 national infrastructures because of existing weak security in 314 devices. But there are IoT devices and systems that have the OS 315 and compute power to detect and prevent malware for generation DDoS 316 attacks. It is possible that for such devices can implement measures 317 to prevent malware from manipulating actuators (e.g., IoT controlling 318 computer assisted automobiles or self driving cars), or forcing such 319 cars into accidents and damage infrastructures and even lose life. 321 Such an experiment was done in the research communities and there was 322 even a contest about how fast hackers can take control of a car 323 using automatic driving. The results were that the current security 324 of such cars is not strong enough to prevent taking control over the 325 internet. A TEE can be the best way to implement such IoT security 326 functions for "smart" environments using advanced OSes such as cars. 328 TEEs could be used to store variety of sensitive data for IoT 329 devices. For example, a TEE could be used in smart cars to 330 store a driver's biometric information for identification, available 331 in some new cars, and for protecting access driving wheel control 332 mechanism. Figure 3 presents the architecture of such a self 333 driving car. In this usecase the applications run inside the TEE and 334 are connected to the service provider's cloud similar to some 335 "connected" cars (BMW for example). The applications running inside 336 the TEE can be either monitoring functions or car status (TA1) or 337 diagnostic malfunctions (TA2). All these applications can be vital to 338 the operation of the car and the safety of the drivers and roads. 339 In general in this usecase the Service provider and the Device 340 Administrator are represented by the vehicle manufacturer during 341 the warranty time and after that they can be a different service 342 provider doing maintenance. 344 There are additional usecases similar to this one like electric 345 power and grid monitoring and control that have rich compute and 346 memory resources running in a centralized location (secure) or 347 in the cloud (unsecure) but need high levels of security. 349 +-------------------------------------------+ 350 | Device | Car Manufacturer 351 | +--------+ | or Service Provider 352 | | |----------+ | 353 | +-------------+ | TEEP |---------+| | 354 | | TEE-1 |<------| Broker | | || +--------+ | 355 | | | | |<---+ | |+-->| |<-+ 356 | | | | | | | | +-| TAM-1 | 357 | | | | |<-+ | | +->| | |<-+ 358 | | +---+ +---+ | +--------+ | | | | +--------+ | 359 | | |TA1| |TA2| | | | | | TAM-2 | | 360 | +-->| | | | | +-------+ | | | +--------+ | 361 | | | | | | |<---------| App-2 |--+ | | | 362 | | | +---+ +---+ | +-------+ | | | Car Manufacturer 363 | | +-------------+ | App-1 | | | | 364 | | | | | | | 365 | +--------------------| |---+ | | 366 | | |--------+ | 367 | +-------+ | 368 +-------------------------------------------+ 369 Figure 3: OS capable IoT devices for connected cars 371 There are additional security models of IoT devices that can fit 372 in these 3 examples and we will extend the protocols to apply to 373 as many as we can consider as useful. 375 5. Security Considerations 377 Although TEEP architecture document [I-D.ietf-teep-architecture] 378 addresses some IoT devices examples there are IoT usecases that 379 require more detailed design and better definitions of the Broker 380 behavior in different usecases discussed in this draft. As such, 381 Broker implementations MUST support many of this usecases critical 382 for security and safety. 384 6. IANA Considerations 386 This document does not require actions by IANA. 388 7. References 390 7.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, . 397 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 398 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 399 May 2017, . 401 [RFC8520] Lear, E., Droms, R. and Romascanu, D., "Manufacturer 402 Usage Description Specification", March 2019, 403 405 7.2. Informative References 407 [1] Vlajic, N., and Zhou, D., "IoT as a Land of Opportunity 408 for DDoS Hackers", Computer Magazine, July 2018, pp. 409 26-34. 411 [2] Kolias, C., Kambourakis, G., Stavrou, A., and Voas, J., 412 IP Spoofing In and Out of the Public Cloud: From Policy 413 to Practice, 415 [3] MUD files for testing DDoS vulnerabilities of IoT devices, 416 https://iotanalytics.unsw.edu.au/mudprofiles/ 418 [4] Vlajic N., Chowdhury M., and Marin Litoiu, 419 "IP Spoofing In and Out of the Public Cloud: From Policy 420 to Practice", Computers 421 2019, 8(4), 81; https://doi.org/10.3390/computers8040081 423 [5] IoT devices scanner for DDoS vulnerabilities test tool, 424 python code, https://github.com/mashrufkabir/IoTScanner 426 [I-D.ietf-teep-architecture] 427 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 428 Liu, "Trusted Execution Environment Provisioning (TEEP) 429 Architecture", draft-ietf-teep-architecture-11 (work in 430 progress), July 2020. 432 Acknowledgments 434 This draft has attempted to capture many IoT security usecases known 435 to the author and presented in the literature as well as discussed 436 in the security forums. These usecases present challenges both for 437 DDoS attacks that became critical as well as applied security for 438 new autonomous devices. We proposed to add these usecases to the 439 TEEP Architecture draft. 441 Author's Address 443 Sorin Faibish 444 Independent Contributor 445 11 Selwyn Road 446 Newton, MA 02461 447 United States of America 449 Phone: +1 617-510-0422 450 Email: sfaibish@comcast.net 452 Mashruf Kabir Chowdhury 453 Deloitte Canada 454 Apt 2112 - 70 Temperance St 455 Toronto, Ontario M5H 0B1 456 Canada 458 Phone: +1-416-388-5146 459 Email: mashrufkabir@icloud.com