idnits 2.17.1 draft-mglt-dots-use-cases-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 (April 20, 2015) is 3293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 538, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational April 20, 2015 5 Expires: October 22, 2015 7 DDoS Open Threat Signaling use cases 8 draft-mglt-dots-use-cases-00 10 Abstract 12 The document details use cases to mitigate DDoS attacks. These use 13 cases are expected to illustrates involved communications to detect 14 and mitigate DDoS attacks. It is expected that these communications 15 will be in the future handled by the DDoS Open Threat Signaling 16 (DOTS). These scenarios are intended to be useful to derive 17 requirements for the design of DDoS Open threat Signaling. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 22, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 55 3. On-premise use case . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Asymmetric . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Cloud Use Case . . . . . . . . . . . . . . . . . . . . . . . 10 59 5. Hybrid Cloud Use Case . . . . . . . . . . . . . . . . . . . . 11 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 DDoS is a major threat that affects any organizations of any size. 70 In addition, these attacks have become more and more frequent, 71 complex and sophisticated which makes DDoS attacks harder to be 72 detected at a single point. 74 More specifically, traditional SYN TCP or ICMP flood attacks were 75 relatively easy to detect at the border of the network by an on- 76 premise device. Although such DDoS attacks remain, DDoS attacks 77 become more and more applications specific. This results in more 78 specialized DDoS attacks, that require a fine grained monitoring to 79 detect suspicious traffic. 81 For example, DNS can be used as a channel to establish a 82 communication channel between a bot and its Command and Control (CC) 83 channel. A generic DNS flow traffic monitoring is not sufficient to 84 detect such attacks. Instead it may require monitoring FQDNs with 85 NXDOMAIN associated to behavioral traffic analysis. DNS(SEC) or NTP 86 are used to perform DDoS reflection attacks. Detection of these 87 attacks may involve monitoring how the source IP address may be 88 unusually associated to heavy traffic. That said, more specific 89 traffic monitoring and analysis is not sufficient when DDoS attacks 90 target a specific application. In the case of slowloris flows DDoS 91 attacks for example, the attacker initiates regular conversations 92 with the servers, except that it maintains these conversations open. 93 The use of TLS/DTLS makes on path monitoring impossible. 95 The complexity and the multitude of potential targets results in 96 making DDoS detection a distributed system over a network. Flood 97 attacks can be detected at the entrance of the network, SYN flood may 98 be detected by firewalls associated to behavioral analysis. TLS and 99 HTTP floods or low and slow and application based DDoS attacks are 100 expected to be detected on the server side. 102 The multitude of DDoS monitoring appliance requires coordination. 103 Coordination is necessary in order to manage the DDoS appliances as 104 well as to collect the various information provided by each appliance 105 and correlate these piece of information. Such correlation is 106 expected to provide early detection, as well as more accurate alarms. 107 Once a DDoS attack has been detected, the mitigation should proceed. 108 Mitigation could be handled locally or outsourced. 110 The document details use cases to mitigate DDoS attacks. These use 111 cases are expected to illustrates involved communications to detect 112 and mitigate DDoS attacks. It is expected that these communications 113 will be in the future handled by the DDoS Open Threat Signaling 114 (DOTS). These scenarios are intended to be useful to derive 115 requirements for the design of DDoS Open threat Signaling. 117 The document illustrates how DOTS makes possible DDoS to go beyond 118 the scope of an isolated appliance and : 120 - A) Make possible a global and cross layered DDoS Monitoring, to 121 make DDoS detection more accurate and earlier. 123 - B) Make possible a global and cross layer DDoS Mitigation, to 124 mitigate in an coherent and efficient way. 126 - C) Make possible to share monitored information between multiple 127 parties. 129 - D) Make possible to share and delegate DDoS monitoring and 130 mitigation to third party. 132 2. Terminology and Acronyms 134 - Deny of Service (DoS): is an attack that makes resource of a 135 service unavailable for its intended users. The resource may 136 be computing or networking resource. 138 - Distributed Deny of Service (DDoS): is a DoS attack where the 139 resources used by the attacker to perform the attack are 140 distributed. 142 - DDoS Monitoring: designates the ability to inspect and monitor 143 the traffic. This may include, exporting flow information to a 144 Flow Repository or generating an alarm to the DDoS Controller 145 when some threshold have been reached. In this document, DDoS 146 Monitoring represents indifferently either a specific and 147 dedicated DDoS Appliance, a virtual DDoS Appliance or a module. 149 - DDoS Mitigation: designates the ability to mitigate the DDoS 150 attack. This may include providing filtering rules for 151 example. In this document, DDoS Mitigation represents 152 indifferently either a specific and dedicated DDoS Appliance, a 153 virtual DDoS Appliance or a module. 155 - DDoS Controller: designates the entity that centralized 156 monitoring, the alarms received and provides the mitigation 157 actions. As DDoS attacks become more and more complex, a 158 single DDoS monitoring device become dedicated to limited 159 aspect of DDoS. As a result, these devices have only a 160 fractional view of the ongoing activity. On the other hand, 161 the DDoS Controller can aggregate and correlate this 162 information have as such has a global view of the attacks. As 163 result the DDoS Controller is more likely to take the 164 appropriated decision to mitigate the attack. 166 - DDoS Appliance: designates an appliance that embeds DDoS 167 Monitoring and/or DDoS Mitigation function. In this document, 168 DDoS Appliance can be indifferently a hardware or virtual 169 virtual DDoS Appliance. 171 - Flow Repository: designates the entity that centralized all the 172 flow information. The Repository, may be shared between 173 various entities and third parties. In fact, it is expected 174 that information could be shared between independent actors, in 175 order to mitigate DDoS Internet wild. 177 - Service: designates the destination of the traffic and the 178 service that is under attack. 180 3. On-premise use case 182 The on-premise uses cases describe scenarios where DDoS is detected 183 and mitigated on site. Section 3.1 describes the symmetric on- 184 premise scenario, where the DDoS Appliance is place on path both the 185 inbound and outbound traffic to the Service. Section 3.2, on the 186 other hand presents the case where only a sub traffic is dynamically 187 directed to the DDoS Appliance. 189 3.1. Symmetric 191 As depicted in Figure 1 the DDoS Appliance is on path of the inbound 192 and outbound traffic to the Service. In other words, traffic coming 193 from the Service to the end users goes also through the DDOS 194 Appliance. 196 Such scenario may be associated to Small Office Home Office (SOHO) 197 networks. In this case, the network, most likely, has a single DDoS 198 Appliance. On the other hand, this scenario may also apply to large 199 data center where, for example, each VM could be associated to a 200 virtual DDoS Appliance. 202 The typical use case includes the following steps: 204 1. The DDoS Controller requests the DDoS Monitoring and DDoS 205 Mitigation capabilities of the DDoS Appliance. Such request 206 provides flexibility for both the DDoS Controller and the DDoS 207 Appliances. First the DDoS Controller does not need to be tied 208 to the DDoS Appliance, and so a single DDoS Controller may be 209 used for various heterogeneous DDoS Appliances. Heterogeneity 210 can be in term of vendors and/or in term of proposed 211 capabilities. Similarly, this provides flexibility for the 212 DDoS Appliances, as a DDoS Appliance may implement a subset of 213 capabilities. In our example, the DDoS Controller, discovers 214 both the DDoS Monitoring and DDoS Mitigating capabilities. 215 DDoS Monitoring capabilities are necessary for monitoring the 216 traffic and latter setting the alarms (see 2.). DDoS 217 Mitigation capabilities are not mandatory to be requested here, 218 as they are only expected to be used when the network is under 219 attack. The reason the DDoS Controller requests those at this 220 stage is to be able to plan its strategy for DDoS mitigation in 221 advance instead of doing so while being under attack. 223 2. The DDoS Controller, then configures the appropriated 224 capabilities on the DDoS Appliance. The configuration can 225 typically be setting the thresholds upon which an alarm is 226 raised by the DDoS Appliance to the DDoS Controller. Another 227 type of setting may also be related to monitoring. DDoS 228 Appliance may be configured to provide flow or resource (like 229 CPU usage) information. These information may be exported to 230 the Flow Repository in an appropriated format that enabled 231 processing and correlation analysis by the DDoS Controller. 233 3. The DDoS Appliance sends the monitoring information to the Flow 234 Repository. Note that the Flow Repository must be provided 235 some means to authenticated the received packets as well as to 236 check the received information corresponds to the one requested 237 by the DDoS Controller. 239 4. The DDoS Appliance raises an alarm that some suspicious traffic 240 has been detected. This alarm corresponds to the settings 241 performed by the DDoS Controller in step 2. As mentioned in 242 Section 1 it may be difficult for the DDoS Appliance to 243 determine from a local observation that a DDoS attack is 244 ongoing or not. This is the reason the alarm is raised for 245 suspicious traffic. 247 5. The DDoS Controller analyzes and correlates the received alarm 248 for suspicious traffic and confirm or not that a DDoS attack is 249 ongoing. Confirmation may require the DDoS Controller to 250 perform some traffic analysis and correlates the alarm with 251 some additional data. To do so, the DDoS Controller may 252 consult the Flow Repository. 254 6. The DDoS Controller concludes that the network is under attack, 255 and so proceeds to DDoS mitigation. In this example, the DDoS 256 Controller is aware of the DDoS Mitigation capabilities of the 257 DDoS Appliance as it has proceeded to the discovery mechanism 258 in step 1. If that is not the case, the DDoS Controller should 259 discover the DDoS mitigation capacities now. DDoS mitigations 260 performed by the DDoS Controller are related to DDoS service. 261 This may include for example setting some filtering rules or 262 activation rate limitation. If traffic redirection should be 263 performed, it is not expected to be performed by the DDoS 264 Controller. In fact redirection implies a network 265 reconfiguration and is considered outside the scope of the DDoS 266 Controller. In addition to mitigate the DDoS attack, the DDoS 267 Controller may also adjust its DDoS Monitoring settings. 268 Motivations for doing so, may be for example to reduce the 269 traffic on the network, or reversely, to provide a more 270 accurate monitoring. 272 6bis. Eventually, the DDoS Controller may conclude that the network 273 is not under attack. In this case the alarm is ignored or 274 acknowledged to avoid the alert is re-sent and eventually load 275 the network or the DDoS Controller. Similarly to step 6, the 276 DDoS may also decide to adjust the monitoring settings to 277 reduce false positive alarms. Note that the latest should be 278 used cautiously as, such mechanism may be used as a vector of 279 attack. 281 ***** DDoS traffic 282 ooooo Legitimate traffic 284 | 285 Internet | Attacked Network 286 | 287 | DDoS Appliance 288 | +-----------------+ +---------+ 289 >***>***> |* | DDoS Monitor | | | 290 >ooo>ooo> |o | ---------- | >ooo> | Service | 291 | DDoS Control | 302 +---------------------+ +------------------+ 303 5. Alert Correlation 305 Figure 1: On-premise Symmetric Use Case 307 Figure 1 shows the DDoS Controller as distinct from the DDoS 308 Appliance. In fact nothing prevents the DDoS Controller to be 309 located on the DDoS Appliance. In this case the communications 310 between the DDoS Controller and the DDoS Monitoring or DDoS 311 Mitigation functions would be implementation dependent and thus 312 outside of the scope of DOTS. The DDoS Appliance may embed a basic 313 and limited DDoS Controller for basic configuration of the device. 314 This is one reason why a DDOS Appliance may be configured by multiple 315 DDoS Controllers. 317 Similarly, there is no requirements that the DDoS Controller belongs 318 to the same network as the DDoS Appliances. The DDoS Controller 319 could be placed inside the on-premise DDoS Appliances' network or 320 remotely see Section 5 for more details. 322 How the DDoS Controller handles alarms and determines a suspicious 323 traffic corresponds or not to a DDoS attack is out of scope of DOTS. 324 Similarly, the mitigating strategies are also out of scope of DOTS. 326 3.2. Asymmetric 328 The asymmetric on-premise scenario optimize resources compared to the 329 symmetric on-premise scenario. More specifically, in the symmetric 330 on premise scenario, the traffic going from the Service to the end 331 users also goes through the DDoS Appliance. Such deployment may lead 332 to unnecessary load on the DDoS Appliance. In fact, the outbound 333 traffic may not need to be either monitored or mitigated, and as such 334 may reduce the packet rate or bit rate upper bound limit for inbound 335 traffic. This may be one motivation for splitting the DDoS 336 Monitoring module and the DDoS Mitigation modules in two different 337 DDoS Appliances. In addition, for large networks, having a dedicated 338 DDoS Appliance for DDoS mitigation may rationalize the cost and use 339 of DDoS Mitigation Appliances. In fact, DDoS Mitigation Appliances 340 may be shared by multiple Services or instances of VM of a given 341 Service. As a result, the DDoS Mitigation Appliance do not need to 342 scale the service traffic but instead the traffic of DDoS attacks -- 343 which is most likely expected to remain smaller. This may not be the 344 case for the DDoS Monitor Appliance as there is a need to always 345 monitor the whole service traffic. 347 In the use case depicted by Figure 2 and Figure 3 the DDoS Mitigation 348 Appliance only handles DDoS traffic. 350 The typical use case includes the following steps: 352 1. corresponds to the capabilities discovery phase. It is similar 353 as the one exposed in Section 3.1. The main difference remains 354 that DDoS Monitoring capabilities and DDoS Mitigating 355 capabilities are discovered on two distinct DDoS Appliances. 357 2., 3., 4. and 5. corresponds to the monitoring and alarms 358 settings. Monitoring may result in exporting data to the Flow 359 Repository. This is similar as the steps described in 360 Section 3.1. 362 6. If the DDoS Controller determines the network is under a DDoS 363 attack, mitigation is performed in two steps. They may be 364 ordered differently depending on criteria that are beyond the 365 scope of this use case. First, the DDoS Mitigation is 366 configured as described in Section 3.1 as a result of an 367 analysis performed by the DDoS Controller. Then, traffic 368 redirection is performed. In our case, the redirected traffic 369 corresponds only to the inbound traffic from the end users. 370 The traffic from the service to the end users is not 371 redirected. This operation is not directly handled by the DDoS 372 Controller. It can be performed manually, or upon a request 373 from the DDoS Controller. This request is then treated by a 374 network management function in order to perform the 375 appropriated network configurations. 377 6bis. In the case, the DDoS Controller determines the network is 378 not under a DDoS attack, this step similar to the one described 379 in Section 3.1. 381 ***** DDoS traffic 382 Internet Attacked Network ooooo Legitimate traffic 383 | 384 | 385 | 386 | DDoS Appliance 387 | +-----------------+ +---------+ +---------+ 388 ooo>ooo> | | DDoS Monitor | >ooo> | Network | >ooo> | Service | 390 >***>***> | | | >***> | | >***> | | 391 | +-----------------+ +---------+ +---------+ 392 | | ^ 393 | | | 1. Capabilities 394 | | | 2. Monitoring settings 395 | | | +---------------------+ 396 | | +----------------+ | DDoS Mitigation | 397 | | | +---------------------+ 398 | | 3. Monitored | DDoS Appliance ^ 399 | | Flows | | 400 | v v 1. Capabilities | 401 +-----------------+ +-----------------------------------+ 402 | Flow Repository |<------>| DDoS Controller | 403 +-----------------+ +-----------------------------------+ 405 Figure 2: On-premise Asymmetric Use Case Monitoring Phase 406 ***** DDoS traffic 407 Internet Attacked Network ooooo Legitimate traffic 408 | 409 | +------------ 410 | | Traffic Redirection 411 | DDoS Appliance v 412 | +-----------------+ +---------+ +---------+ 413 ooo>ooo> | | DDoS Monitor | >ooo> | Network | | Service | 415 >***>***> | | | >***> | | | | 416 | +-----------------+ +---------+ +---------+ 417 | | ^ vv ^ 418 | | | *o o 419 | | | vv ^ 420 | | | 4. Alarm is raised +---------------------+ 421 | | +----------------+ | DDoS Mitigation | 422 | | | +---------------------+ 423 | | 3. Monitored | DDoS Appliance ^ 424 | | Flows | | 425 | v v 6. Mitigation settings 426 +-----------------+ +-----------------------------------+ 427 | Flow Repository |<------>| DDoS Controller | 428 +-----------------+ +-----------------------------------+ 429 5. Alert Correlation 431 Figure 3: On-premise Asymmetric Use Case Mitigation Phase 433 4. Cloud Use Case 435 Figure 4 illustrates the Cloud use case. In this scenario, the 436 entire DDoS monitoring and mitigation service is outsourced to a 437 third party designated as Cloud Based DDoS Cleaning Service or Cloud 438 for short. In order to do so, the traffic associated to the Service 439 goes through the Cloud Based DDoS Cleaning Service as detailed in 440 Figure 4. On the other hand, this scenario makes DDoS mitigation 441 transparent to the Service provider, which then benefits from a 442 "clean pipe". 444 Figure 4 presents the case where the Cloud is on path of both inbound 445 and outbound traffic, a similar scenario may also consider that only 446 the inbound traffic, that is the traffic destined to the service is 447 directed to the cloud whereas the outbound traffic destined to the 448 users does not. 450 Internal organization of the Cloud Based DDoS Cleaning Service is 451 transparent to the Service provider. A combination of the on- 452 premises scenarios may be used. 454 ***** DDoS traffic 455 ooooo Legitimate traffic 457 +----------------------------------+ 458 | Cloud Base DDoS Cleaning Service | 459 | | 460 | DDoS Monitor | 461 | / | 462 | DDoS Mitigation | 463 +----------------------------------+ 464 ^^ v v ^ 465 *o o o o 466 ^^ v v ^ 467 >***>***> ,---------. +---------+ 468 Users >ooo>ooo>,-' `-. | | 469 ( Internet ) | Service | 470