idnits 2.17.1 draft-ietf-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 (October 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-dots-requirements' is mentioned on line 218, but not defined == Unused Reference: 'RFC0768' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'RFC1518' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 956, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS WG R. Dobbins, Ed. 3 Internet-Draft Arbor Networks 4 Intended status: Informational S. Fouant 5 Expires: April 21, 2016 Corero Network Security 6 D. Migault 7 Ericsson 8 R. Moskowitz 9 HTT Consulting 10 N. Teague 11 Verisign Inc 12 L. Xia 13 Huawei 14 October 19, 2015 16 Use cases for DDoS Open Threat Signaling 17 draft-ietf-dots-use-cases-00.txt 19 Abstract 21 This document delineates principal and ancillary use cases for DDoS 22 Open Threat Signaling (DOTS), a communications protocol intended to 23 facilitate the programmatic, coordinated mitigation of Distributed 24 Denial of Service (DDoS) attacks via a standards-based mechanism. 25 DOTS is purposely designed to support requests for DDoS mitigation 26 services and status updates across inter-organizational 27 administrative boundaries. 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 This Internet-Draft will expire on April 21, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 66 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Primary Use Cases . . . . . . . . . . . . . . . . . . . . 5 68 4.1.1. Successful Automatic or Operator-Assisted CPE or PE 69 Mitigators Request Upstream DDoS Mitigation Services 5 70 4.1.2. Successful Automatic or Operator-Assisted CPE or PE 71 Network Infrastructure Element Request to Upstream 72 Mitigator . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.3. Successful Automatic or Operator-Assisted CPE or PE 74 Attack Telemetry Detection/Classification System 75 Request to Upstream Mitigator . . . . . . . . . . . . 9 76 4.1.4. Successful Automatic or Operator-Assisted Targeted 77 Service/Application Request to Upstream Mitigator . . 12 78 4.1.5. Successful Manual Web Portal Request to Upstream 79 Mitigator . . . . . . . . . . . . . . . . . . . . . . 14 80 4.1.6. Successful Manual Mobile Device Application Request 81 to Upstream Mitigator . . . . . . . . . . . . . . . . 16 82 4.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE 83 Mitigators Request Upstream DDoS Mitigation Services 18 84 4.2. Ancillary Use Cases . . . . . . . . . . . . . . . . . . . 19 85 4.2.1. Auto-registration of DOTS clients with DOTS servers . 19 86 4.2.2. Auto-provisioning of DDoS countermeasures . . . . . . 20 87 4.2.3. Informational DDoS attack notification to interested 88 and authorized third parties . . . . . . . . . . . . 20 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 94 8.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 Currently, distributed denial-of-service (DDoS) attack mitigation 106 solutions/services are largely based upon siloed, proprietary 107 communications paradigms which result in vendor/service lock-in, and 108 as a side-effect make the configuration, provisioning, operation, and 109 activation of these solutions a highly manual and often time- 110 consuming process. Additionally, coordination of multiple DDoS 111 mitigation solutions/services simultaneously engaged in defending the 112 same organization against DDoS attacks is fraught with both technical 113 and process-related hurdles which greatly increase operational 114 complexity and often result in suboptimal DDoS attack mitigation 115 efficacy. 117 The DDoS Open Threat Signaling (DOTS) effort is intended to 118 facilitate interoperability between DDoS solutions/services by 119 providing a standards-based, programmatic communications mechanism 120 for the invitation and termination of heterogeneous DDoS attack 121 mitigation systems and services. This allows for a much higher 122 degree of automation and concomitant efficacy and rapidity of DDoS 123 attack mitigation involving multiple DDoS mitigation systems and 124 services than is currently the norm, as well as providing additional 125 benefits such as automatic DDoS mitigation service registration and 126 provisioning. 128 This document provides an overview of common DDoS mitigation system/ 129 service deployment and operational models which are in use today, but 130 which are currently limited in scope to a single vendor and/or 131 service provider and are often highly manual in nature, which can 132 lead to miscommunications, misconfigurations, and delays in bringing 133 mitigation services to bear against an attack. The introduction of 134 DOTS into these scenarios will reduce reaction times and the risks 135 associated with manual processes, simplify the use of multiple types 136 of DDoS mitigation systems and services as required, and make 137 practical the simultaneous use multiple DDoS mitigation systems and 138 services as circumstances warrant. 140 3. Terminology and Acronyms 142 This document makes use of the same terminology and definitions as 143 [I-D.draft-ietf-dots-requirements], except where noted below: 145 - DDoS: A distributed denial-of-service attack. DDoS attacks are 146 intended to cause a negative impact on the availability of 147 servers, services, applications, and/or other functionality of 148 an attack target. 150 - Attack target: The intended target of a DDoS attack. 152 - Attack telemetry: Collected network traffic characteristics 153 enabling the detection, classification, and in many cases 154 traceback of a DDoS attack. 156 - Mitigation: A defensive response against a detected DDoS attack, 157 performed by an entity in the network path between attack 158 sources and the attack target, either through inline deployment 159 or some form of traffic diversion, consisting of one or more 160 countermeasures. The form a given mitigation takes is out of 161 scope for this document. 163 - Countermeasure: An action or set of actions taken by a mitigator 164 to evaluate and filter out a significant proportion of DDoS 165 attack traffic while forwarding onwards a significant 166 proportion of legitimate traffic directed towards an attack 167 target. 169 4. Use Cases 171 This section provides a high-level overview of likely use cases and 172 deployment scenarios for DOTS-enabled DDoS mitigation services. It 173 should be noted that DOTS servers may be standalone entities which, 174 upon receiving a DOTS mitigation service request from a DOTS client, 175 then initiate DDoS mitigation service by communicating directly or 176 indirectly with DDoS mitigators, and likewise terminate the service 177 upon receipt of a DOTS service termination request; conversely, the 178 DDoS mitigators themselves may incorporate DOTS servers and/or DOTS 179 clients. The mechanisms by which DOTS servers initiate and terminate 180 DDoS mitigation service with DDoS mitigators is beyond the scope of 181 this document. 183 All of the primary use cases described in this section are derived 184 from current, real-world DDoS mitigation functionality, capabilities, 185 and operational models which have been implemented in a largely 186 proprietary manner by various DDoS mitigation solution vendor and/or 187 service providers, resulting in vendor/service lock-in and mutually 188 incompatible solutions/services. The overarching goal of the DOTS 189 effort is to provide a standards-based mechanism to allow 190 heterogeneous DDoS mitigation solutions and services to be woven 191 together in order to allow broader, more pervasive adoption of 192 coordinated DDoS defense. 194 The posited ancillary use cases described in this section are 195 reasonable and highly desirable extrapolations of the functionality 196 of baseline DOTS capabilities, and are readily attainable in the near 197 term. 199 Another important goal of DOTS is interoperability and coordination 200 via a common standards-based mechanism between multiple DDoS 201 mitigation service providers contemporaneously engaged in defending 202 the same organization against DDoS attacks. Each of the primary and 203 ancillary use cases described in this section may be read as 204 involving one or more DDoS mitigation service providers; DOTS makes 205 multi-provider coordinated DDoS defenses much more effective and 206 practical due to abstraction of the particulars of a given DDoS 207 mitigation service/solution set. 209 Both the primary and ancillary use cases may be facilitated by direct 210 DOTS client - DOTS server communications or via DOTS relays deployed 211 in order to aggregate DOTS mitigation service requests/responses, to 212 mediate between stateless and stateful underlying transport 213 protocols, to aggregate multiple DOTS requests and/or responses, to 214 filter DOTS requests and/or responses via configured policy 215 mechanisms, or some combination of these functions. 217 These use cases requirements are intended to inform the DOTS 218 requirements described in [I-D.draft-ietf-dots-requirements]. 220 4.1. Primary Use Cases 222 4.1.1. Successful Automatic or Operator-Assisted CPE or PE Mitigators 223 Request Upstream DDoS Mitigation Services 225 In this scenario, one or more CPE or PE mitigators with DOTS client 226 capabilities may be configured to signal to one or more DOTS servers 227 in order to request upstream DDoS mitigation service initiation 228 during an attack when DDoS attack volumes and/or attack 229 characteristics exceed the capabilities of such CPE mitigators. DDoS 230 mitigation service may be terminated either automatically or manually 231 via a DOTS mitigation service termination request initiated by the 232 mitigator when it has been determined that the DDoS attack has ended. 234 All DOTS messages exchanged between the DOTS clients and DOTS servers 235 in this use case may be communicated directly between the DOTS 236 clients and servers, or mediated by one or more DOTS relays residing 237 on the network of the originating network, the network where upstream 238 DDoS mitigation service takes place, an intervening network or 239 networks, or some combination of the above. 241 (a) A DDoS attack is initiated against online properties of an 242 organization which has deployed DOTS-client-capable DDoS 243 mitigators. 245 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 246 the DDoS attack. 248 (c) CPE or PE DDoS mitigators determine that their capacity and/or 249 capability to mitigate the DDoS attack is insufficient, and 250 utilize their DOTS client functionality to send a DOTS 251 mitigation service initiation request to one or more DOTS 252 servers residing on one or more upstream transit networks, peer 253 networks, or overlay MSSP networks. The scope, format, and 254 content of these messages must be codified by the DOTS WG. This 255 DOTS mitigation service initiation request may be automatically 256 initiated by the CPE or PE DDoS mitigators, or may be manually 257 triggered by personnel of the requesting organization in 258 response to an alert from the mitigators (the mechanism by which 259 this process takes place is beyond the scope of this document). 261 (d) The DOTS servers which receive the DOTS mitigation service 262 initiation requests determine that they have been to honor 263 requests from the requesting CPE or PE mitigators, and initiate 264 situationally-appropriate DDoS mitigation service on their 265 respective networks (the mechanism by which this process takes 266 place is beyond the scope of this document). 268 (e) The DOTS servers transmit a DOTS service status message to the 269 requesting CPE or PE mitigators indicating that upstream DDoS 270 mitigation service has been initiated. 272 (f) While DDoS mitigation services are active, the DOTS servers 273 regularly transmit DOTS mitigation status updates to the 274 requesting CPE or PE mitigators. The scope, format, and content 275 of these messages must be codified by the DOTS WG. 277 (g) While DDoS mitigation services are active, the CPE or PE 278 mitigators may optionally regularly transmit DOTS mitigation 279 efficacy updates to the relevant DOTS servers. The scope, 280 format, and content of these messages must be codified by the 281 DOTS WG. 283 (h) When the upstream DDoS mitigators determine that the DDoS attack 284 has ceased, they indicate this change in status to their 285 respective DOTS servers (the mechanism by which this process 286 takes place is beyond the scope of this document). 288 (i) The DOTS servers transmit a DOTS mitigation status update to the 289 CPE or PE mitigators indicating that the DDoS attack has ceased. 290 The scope, format, and content of these messages must be 291 codified by the DOTS WG. 293 (j) The CPE or PE DDoS mitigators transmit a DOTS mitigation service 294 termination request to the DOTS servers. [The scope, format, 295 and content of these messages must be codified by the DOTS WG.] 296 This DOTS mitigation service termination request may be 297 automatically initiated by the CPE or PE DDoS mitigators, or may 298 be manually triggered by personnel of the requesting 299 organization in response to an alert from the mitigators or a 300 management system which monitors them (the mechanism by which 301 this process takes place is beyond the scope of this document). 303 (k) The DOTS servers terminate DDoS mitigation service on their 304 respective networks (the mechanism by which this process takes 305 place is beyond the scope of this document). 307 (l) The DOTS servers transmit a DOTS mitigation status update to the 308 CPE or PE mitigators indicating that DDoS mitigation services 309 have been terminated. The scope, format, and content of these 310 messages must be codified by the DOTS WG. 312 (m) The CPE or PE DDoS mitigators transmit a DOTS mitigation 313 termination status acknowledgement to the DOTS servers. [The 314 scope, format, and content of these messages must be codified by 315 the DOTS WG.] 317 4.1.2. Successful Automatic or Operator-Assisted CPE or PE Network 318 Infrastructure Element Request to Upstream Mitigator 320 In this scenario, CPE or PE network infrastructure elements such as 321 routers, switches, load-balancers, firewalls, 'IPSes', etc. which 322 have the capability to detect and classify DDoS attacks and which 323 have DOTS client capabilities may be configured to signal to one or 324 more DOTS servers in order to request upstream DDoS mitigation 325 service initiation during an attack. DDoS mitigation service may be 326 terminated either automatically or manually via a DOTS mitigation 327 service termination request initiated by the network element when it 328 has been determined that the DDoS attack has ended. 330 All DOTS messages exchanged between the DOTS clients and DOTS servers 331 in this use case may be communicated directly between the DOTS 332 clients and servers, or mediated by one or more DOTS relays residing 333 on the network of the originating network, the network where upstream 334 DDoS mitigation service takes place, an intervening network or 335 networks, or some combination of the above. 337 (a) A DDoS attack is initiated against online properties of an 338 organization with DOTS-client-capable network infrastructure 339 elements deployed. 341 (b) The network infrastructure elements utilize their DOTS client 342 functionality to send a DOTS mitigation service initiation 343 request to one or more DOTS servers residing on one or more 344 upstream transit networks, peer networks, or overlay MSSP 345 networks, either directly or via intermediate DOTS relays 346 residing upon the requesting organization's network, the 347 upstream mitigation provider's network, or both. The scope, 348 format, and content of these messages must be codified by the 349 DOTS WG. This DOTS mitigation service initiation request may be 350 automatically initiated by the network infrastructure elements, 351 or may be manually triggered by personnel of the requesting 352 organization in response to an alert from the network elements 353 or a management system which monitors them (the mechanism by 354 which this process takes place is beyond the scope of this 355 document). 357 (c) The DOTS servers which receive the DOTS mitigation service 358 initiation requests determine that they have been to honor 359 requests from the requesting network infrastructure elements, 360 and initiate situationally-appropriate DDoS mitigation service 361 on their respective networks (the mechanism by which this 362 process takes place is beyond the scope of this document). 364 (d) The DOTS servers transmit a DOTS service status message to the 365 requesting network infrastructure elements indicating that 366 upstream DDoS mitigation service has been initiated. The scope, 367 format, and content of these messages must be codified by the 368 DOTS WG. 370 (e) While DDoS mitigation services are active, the DOTS servers 371 regularly transmit DOTS mitigation status updates to the 372 requesting requesting network infrastructure elements. The 373 scope, format, and content of these messages must be codified by 374 the DOTS WG. 376 (f) While DDoS mitigation services are active, the network 377 infrastructure elements may optionally regularly transmit DOTS 378 mitigation efficacy updates to the relevant DOTS servers. The 379 scope, format, and content of these messages must be codified by 380 the DOTS WG. 382 (g) When the upstream DDoS mitigators determine that the DDoS attack 383 has ceased, they indicate this change in status to their 384 respective DOTS servers (the mechanism by which this process 385 takes place is beyond the scope of this document). 387 (h) The DOTS servers transmit a DOTS mitigation status update to the 388 network infrastructure elements indicating that the DDoS attack 389 has ceased. The scope, format, and content of these messages 390 must be codified by the DOTS WG. 392 (i) The network infrastructure elements transmit a DOTS mitigation 393 service termination request to the DOTS servers. The scope, 394 format, and content of these messages must be codified by the 395 DOTS WG. This DOTS mitigation service termination request may 396 be automatically initiated by the network infrastructure 397 elements, or may be manually triggered by personnel of the 398 requesting organization in response to an alert from the 399 mitigators (the mechanism by which this process takes place is 400 beyond the scope of this document). 402 (j) The DOTS servers terminate DDoS mitigation service on their 403 respective networks (the mechanism by which this process takes 404 place is beyond the scope of this document). 406 (k) The DOTS servers transmit a DOTS mitigation status update to the 407 network infrastructure elements indicating that DDoS mitigation 408 services have been terminated. The scope, format, and content 409 of these messages must be codified by the DOTS WG. 411 (l) The network infrastructure elements transmit a DOTS mitigation 412 termination status acknowledgement to the DOTS servers. The 413 scope, format, and content of these messages must be codified by 414 the DOTS WG. 416 4.1.3. Successful Automatic or Operator-Assisted CPE or PE Attack 417 Telemetry Detection/Classification System Request to Upstream 418 Mitigator 420 In this scenario, CPE or PE Attack Telemetry Detection/Classification 421 Systems which have DOTS client capabilities may be configured so that 422 upon detecting and classifying a DDoS attack, they signal one or more 423 DOTS servers in order to request upstream DDoS mitigation service 424 initiation. DDoS mitigation service may be terminated either 425 automatically or manually via a DOTS mitigation service termination 426 request initiated by the Attack Telemetry Detection/Classification 427 System when it has been determined that the DDoS attack has ended. 429 All DOTS messages exchanged between the DOTS clients and DOTS servers 430 in this use case may be communicated directly between the DOTS 431 clients and servers, or mediated by one or more DOTS relays residing 432 on the network of the originating network, the network where upstream 433 DDoS mitigation service takes place, an intervening network or 434 networks, or some combination of the above. 436 (a) A DDoS attack is initiated against online properties of an 437 organization with DOTS-client-capable CPE or PE Attack Telemetry 438 Detection/Classification Systems deployed. 440 (b) The CPE or PE Attack Telemetry Detection/Classification Systems 441 utilize their DOTS client functionality to send a DOTS 442 mitigation service initiation request to one or more DOTS 443 servers residing on one or more upstream transit networks, peer 444 networks, or overlay MSSP networks, either directly or via 445 intermediate DOTS relays residing upon the requesting 446 organization's network, the upstream mitigation provider's 447 network, or both. [The scope, format, and content of these 448 messages must be codified by the DOTS WG.] This DOTS mitigation 449 service initiation request may be automatically initiated by the 450 CPE or PE Attack Telemetry Detection/Classification Systems, or 451 may be manually triggered by personnel of the requesting 452 organization in response to an alert from the CPE or PE Attack 453 Telemetry Detection/Classification Systems (the mechanism by 454 which this process takes place is beyond the scope of this 455 document). 457 (c) The DOTS servers which receive the DOTS mitigation service 458 initiation requests determine that they have been to honor 459 requests from the requesting CPE or PE Attack Telemetry 460 Detection/Classification Systems, and initiate situationally- 461 appropriate DDoS mitigation service on their respective networks 462 (the mechanism by which this process takes place is beyond the 463 scope of this document). 465 (d) The DOTS servers transmit a DOTS service status message to the 466 requesting CPE or PE Attack Telemetry Detection/Classification 467 Systems indicating that upstream DDoS mitigation service has 468 been initiated. The scope, format, and content of these 469 messages must be codified by the DOTS WG. 471 (e) While DDoS mitigation services are active, the DOTS servers 472 regularly transmit DOTS mitigation status updates to the 473 requesting CPE or PE Attack Telemetry Detection/Classification 474 Systems. The scope, format, and content of these messages must 475 be codified by the DOTS WG. 477 (f) While DDoS mitigation services are active, the CPE or PE Attack 478 Telemetry Detection/Classification Systems may optionally 479 regularly transmit DOTS mitigation efficacy updates to the 480 relevant DOTS servers. The scope, format, and content of these 481 messages must be codified by the DOTS WG. 483 (g) When the upstream DDoS mitigators determine that the DDoS attack 484 has ceased, they indicate this change in status to their 485 respective DOTS servers (the mechanism by which this process 486 takes place is beyond the scope of this document). 488 (h) The DOTS servers transmit a DOTS mitigation status update to the 489 CPE or PE Attack Telemetry Detection/Classification Systems 490 indicating that the DDoS attack has ceased. The scope, format, 491 and content of these messages must be codified by the DOTS WG. 493 (i) The CPE or PE Attack Telemetry Detection/Classification Systems 494 transmit a DOTS mitigation service termination request to the 495 DOTS servers. The scope, format, and content of these messages 496 must be codified by the DOTS WG. This DOTS mitigation service 497 termination request may be automatically initiated by the CPE or 498 PE Attack Telemetry Detection/Classification Systems, or may be 499 manually triggered by personnel of the requesting organization 500 in response to an alert from the CPE or PE Attack Telemetry 501 Detection/Classification Systems (the mechanism by which this 502 process takes place is beyond the scope of this document). 504 (j) The DOTS servers terminate DDoS mitigation service on their 505 respective networks (the mechanism by which this process takes 506 place is beyond the scope of this document). 508 (k) The DOTS servers transmit a DOTS mitigation status update to the 509 CPE or PE Attack Telemetry Detection/Classification Systems 510 indicating that DDoS mitigation services have been terminated. 511 The scope, format, and content of these messages must be 512 codified by the DOTS WG. 514 (l) The CPE or PE Attack Telemetry Detection/Classification Systems 515 transmit a DOTS mitigation termination status acknowledgement to 516 the DOTS servers. The scope, format, and content of these 517 messages must be codified by the DOTS WG. 519 4.1.4. Successful Automatic or Operator-Assisted Targeted Service/ 520 Application Request to Upstream Mitigator 522 In this scenario, a service or application which is the target of a 523 DDoS attack and which has the capability to detect and classify DDoS 524 attacks (i.e, Apache mod_security [APACHE], BIND RRL [RRL], etc.) as 525 well as DOTS client functionality may be configured so that upon 526 detecting and classifying a DDoS attack, it signals one or more DOTS 527 servers in order to request upstream DDoS mitigation service 528 initiation. DDoS mitigation service may be terminated either 529 automatically or manually via a DOTS mitigation service termination 530 request initiated by the service/application when it has been 531 determined that the DDoS attack has ended. 533 All DOTS messages exchanged between the DOTS clients and DOTS servers 534 in this use case may be communicated directly between the DOTS 535 clients and servers, or mediated by one or more DOTS relays residing 536 on the network of the originating network, the network where upstream 537 DDoS mitigation service takes place, an intervening network or 538 networks, or some combination of the above. 540 (a) A DDoS attack is initiated against online properties of an 541 organization which include DOTS-client-capable services or 542 applications that are the specific target(s) of the attack. 544 (b) The targeted services or applications utilize their DOTS client 545 functionality to send a DOTS mitigation service initiation 546 request to one or more DOTS servers residing on the same network 547 as the services or applications, one or more upstream transit 548 networks, peer networks, or overlay MSSP networks, either 549 directly or via intermediate DOTS relays residing upon the 550 requesting organization's network, the upstream mitigation 551 provider's network, or both. The scope, format, and content of 552 these messages must be codified by the DOTS WG. This DOTS 553 mitigation service initiation request may be automatically 554 initiated by the targeted services or applications, or may be 555 manually triggered by personnel of the requesting organization 556 in response to an alert from the targeted services or 557 applications or a system which monitors them (the mechanism by 558 which this process takes place is beyond the scope of this 559 document). 561 (c) The DOTS servers which receive the DOTS mitigation service 562 initiation requests determine that they have been provisioned to 563 honor requests from the requesting services or applications, and 564 initiate situationally-appropriate DDoS mitigation service on 565 their respective networks (the mechanism by which this process 566 takes place is beyond the scope of this document). 568 (d) The DOTS servers transmit a DOTS service status message to the 569 services or applications indicating that upstream DDoS 570 mitigation service has been initiated. [The scope, format, and 571 content of these messages must be codified by the DOTS WG. 573 (e) While DDoS mitigation services are active, the DOTS servers 574 regularly transmit DOTS mitigation status updates to the 575 requesting services or applications. The scope, format, and 576 content of these messages must be codified by the DOTS WG. 578 (f) While DDoS mitigation services are active, the requesting 579 services or applications may optionally regularly transmit DOTS 580 mitigation efficacy updates to the relevant DOTS servers. The 581 scope, format, and content of these messages must be codified by 582 the DOTS WG. 584 (g) When the upstream DDoS mitigators determine that the DDoS attack 585 has ceased, they indicate this change in status to their 586 respective DOTS servers (the mechanism by which this process 587 takes place is beyond the scope of this document). 589 (h) The DOTS servers transmit a DOTS mitigation status update to the 590 requesting services or applications indicating that the DDoS 591 attack has ceased. The scope, format, and content of these 592 messages must be codified by the DOTS WG. 594 (i) The targeted services or applications transmit a DOTS mitigation 595 service termination request to the DOTS servers. [The scope, 596 format, and content of these messages must be codified by the 597 DOTS WG.] This DOTS mitigation service termination request may 598 be automatically initiated by the targeted services or 599 applications, or may be manually triggered by personnel of the 600 requesting organization in response to an alert from a system 601 which monitors them (the mechanism by which this process takes 602 place is beyond the scope of this document). 604 (j) The DOTS servers terminate DDoS mitigation service on their 605 respective networks (the mechanism by which this process takes 606 place is beyond the scope of this document). 608 (k) The DOTS servers transmit a DOTS mitigation status update to the 609 targeted services or applications indicating that DDoS 610 mitigation services have been terminated. The scope, format, 611 and content of these messages must be codified by the DOTS WG. 613 (l) The targeted services or applications transmit a DOTS mitigation 614 termination status acknowledgement to the DOTS servers. The 615 scope, format, and content of these messages must be codified by 616 the DOTS WG. 618 4.1.5. Successful Manual Web Portal Request to Upstream Mitigator 620 In this scenario, a Web portal which has DOTS client capabilities has 621 been configured in order to allow authorized personnel of 622 organizations which are targeted by DDoS attacks to manually request 623 upstream DDoS mitigation service initiation from a DOTS server. When 624 an organization has reason to believe that it is under active attack, 625 authorized personnel may utilize the Web portal to manually initiate 626 a DOTS client mitigation request to one or more DOTS servers. DDoS 627 mitigation service may be terminated manually via a DOTS mitigation 628 service termination request through the Web portal when it has been 629 determined that the DDoS attack has ended. 631 All DOTS messages exchanged between the DOTS client and DOTS servers 632 in this use case may be communicated directly between the DOTS client 633 and servers, or mediated by one or more DOTS relays residing on the 634 network of the originating network, the network where upstream DDoS 635 mitigation service takes place, an intervening network or networks, 636 or some combination of the above. 638 (a) A DDoS attack is initiated against online properties of an 639 organization have access to a Web portal which incorporates DOTS 640 client functionality and can generate DOTS mitigation service 641 requests upon demand. 643 (b) Authorized personnel utilize the Web portal to send a DOTS 644 mitigation service initiation request to one or more upstream 645 transit networks, peer networks, or overlay MSSP networks, 646 either directly or via intermediate DOTS relays residing upon 647 the requesting organization's network, the upstream mitigation 648 provider's network, or both. [The scope, format, and content of 649 these messages must be codified by the DOTS WG.] This DOTS 650 mitigation service initiation request is manually triggered by 651 personnel of the requesting organization when it is judged that 652 the organization is under DDoS attack (the mechanism by which 653 this process takes place is beyond the scope of this document). 655 (c) The DOTS servers which receive the DOTS mitigation service 656 initiation requests determine that they have been provisioned to 657 honor requests from the Web portal, and initiate situationally- 658 appropriate DDoS mitigation service on their respective networks 659 (the mechanism by which this process takes place is beyond the 660 scope of this document). 662 (d) The DOTS servers transmit a DOTS service status message to the 663 Web portal indicating that upstream DDoS mitigation service has 664 been initiated. [The scope, format, and content of these 665 messages must be codified by the DOTS WG. 667 (e) While DDoS mitigation services are active, the DOTS servers 668 regularly transmit DOTS mitigation status updates to the Web 669 portal. The scope, format, and content of these messages must 670 be codified by the DOTS WG. 672 (f) While DDoS mitigation services are active, the Web portal may 673 optionally regularly transmit manually-triggered DOTS mitigation 674 efficacy updates to the relevant DOTS servers. The scope, 675 format, and content of these messages must be codified by the 676 DOTS WG. 678 (g) When the upstream DDoS mitigators determine that the DDoS attack 679 has ceased, they indicate this change in status to their 680 respective DOTS servers (the mechanism by which this process 681 takes place is beyond the scope of this document). 683 (h) The DOTS servers transmit a DOTS mitigation status update to the 684 Web portal indicating that the DDoS attack has ceased. [The 685 scope, format, and content of these messages must be codified by 686 the DOTS WG. 688 (i) The Web portal transmits a manually-triggered DOTS mitigation 689 service termination request to the DOTS servers (the mechanism 690 by which this process takes place is beyond the scope of this 691 document). The scope, format, and content of these messages 692 must be codified by the DOTS WG. 694 (j) The DOTS servers terminate DDoS mitigation service on their 695 respective networks (the mechanism by which this process takes 696 place is beyond the scope of this document). 698 (k) The DOTS servers transmit a DOTS mitigation status update to the 699 Web portal indicating that DDoS mitigation services have been 700 terminated. The scope, format, and content of these messages 701 must be codified by the DOTS WG. 703 (l) The Web portal transmits a DOTS mitigation termination status 704 acknowledgement to the DOTS servers. The scope, format, and 705 content of these messages must be codified by the DOTS WG. 707 4.1.6. Successful Manual Mobile Device Application Request to Upstream 708 Mitigator 710 In this scenario, an application for mobile devices such as 711 smartphones and tablets which incorporates DOTS client capabilities 712 has been made available to authorized personnel of an organization. 713 When the organization has reason to believe that it is under active 714 DDoS attack, authorized personnel may utilize the mobile device 715 application to manually initiate a DOTS client mitigation request to 716 one or more DOTS servers in order to initiate upstream DDoS 717 mitigation services. DDoS mitigation service may be terminated 718 manually via a DOTS mitigation service termination request initiated 719 through the mobile device application when it has been determined 720 that the DDoS attack has ended. 722 All DOTS messages exchanged between the DOTS client and DOTS servers 723 in this use case may be communicated directly between the DOTS client 724 and servers, or mediated by one or more DOTS relays residing on the 725 network of the originating network, the network where upstream DDoS 726 mitigation service takes place, an intervening network or networks, 727 or some combination of the above. 729 (a) A DDoS attack is initiated against online properties of an 730 organization have access to a Web portal which incorporates DOTS 731 client functionality and can generate DOTS mitigation service 732 requests upon demand. 734 (b) Authorized personnel utilize the mobile application to send a 735 DOTS mitigation service initiation request to one or more DOTS 736 servers residing on the same network as the targeted Internet 737 properties, one or more upstream transit networks, peer 738 networks, or overlay MSSP networks, either directly or via 739 intermediate DOTS relays residing upon the requesting 740 organization's network, the upstream mitigation provider's 741 network, or both. [The scope, format, and content of these 742 messages must be codified by the DOTS WG.] This DOTS mitigation 743 service initiation request is manually triggered by personnel of 744 the requesting organization when it is judged that the 745 organization is under DDoS attack (the mechanism by which this 746 process takes place is beyond the scope of this document). 748 (c) The DOTS servers which receive the DOTS mitigation service 749 initiation requests determine that they have been provisioned to 750 honor requests from the mobile application, and initiate 751 situationally-appropriate DDoS mitigation service on their 752 respective networks (the mechanism by which this process takes 753 place is beyond the scope of this document). 755 (d) The DOTS servers transmit a DOTS service status message to the 756 mobile application indicating that upstream DDoS mitigation 757 service has been initiated. The scope, format, and content of 758 these messages must be codified by the DOTS WG. 760 (e) While DDoS mitigation services are active, the DOTS servers 761 regularly transmit DOTS mitigation status updates to the mobile 762 application. The scope, format, and content of these messages 763 must be codified by the DOTS WG. 765 (f) While DDoS mitigation services are active, the mobile 766 application may optionally regularly transmit manually-triggered 767 DOTS mitigation efficacy updates to the relevant DOTS servers. 768 The scope, format, and content of these messages must be 769 codified by the DOTS WG. 771 (g) When the upstream DDoS mitigators determine that the DDoS attack 772 has ceased, they indicate this change in status to their 773 respective DOTS servers (the mechanism by which this process 774 takes place is beyond the scope of this document). 776 (h) The DOTS servers transmit a DOTS mitigation status update to the 777 mobile application indicating that the DDoS attack has ceased. 778 The scope, format, and content of these messages must be 779 codified by the DOTS WG. 781 (i) The mobile application transmits a manually-triggered DOTS 782 mitigation service termination request to the DOTS servers (the 783 mechanism by which this process takes place is beyond the scope 784 of this document). The scope, format, and content of these 785 messages must be codified by the DOTS WG. 787 (j) The DOTS servers terminate DDoS mitigation service on their 788 respective networks (the mechanism by which this process takes 789 place is beyond the scope of this document). 791 (k) The DOTS servers transmit a DOTS mitigation status update to the 792 mobile application indicating that DDoS mitigation services have 793 been terminated. The scope, format, and content of these 794 messages must be codified by the DOTS WG. 796 (l) The mobile application transmits a DOTS mitigation termination 797 status acknowledgement to the DOTS servers. The scope, format, 798 and content of these messages must be codified by the DOTS WG. 800 4.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE Mitigators 801 Request Upstream DDoS Mitigation Services 803 In this scenario, one or more CPE or PE mitigators with DOTS client 804 capabilities may be configured to signal to one or more DOTS servers 805 in order to request upstream DDoS mitigation service initiation 806 during an attack when DDoS attack volumes and/or attack 807 characteristics exceed the capabilities of such CPE mitigators. DDoS 808 mitigation service may be terminated either automatically or manually 809 via a DOTS mitigation service termination request initiated by the 810 mitigator when it has been determined that the DDoS attack has ended. 812 All DOTS messages exchanged between the DOTS clients and DOTS servers 813 in this use case may be communicated directly between the DOTS 814 clients and servers, or mediated by one or more DOTS relays residing 815 on the network of the originating network, the network where upstream 816 DDoS mitigation service takes place, an intervening network or 817 networks, or some combination of the above. 819 (a) A DDoS attack is initiated against online properties of an 820 organization which has deployed DOTS-client-capable DDoS 821 mitigators. 823 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 824 the DDoS attack. 826 (c) CPE or PE DDoS mitigators determine that their capacity and/or 827 capability to mitigate the DDoS attack is insufficient, and 828 utilize their DOTS client functionality to send a DOTS 829 mitigation service initiation request to one or more DOTS 830 servers residing on one or more upstream transit networks, peer 831 networks, or overlay MSSP networks. The scope, format, and 832 content of these messages must be codified by the DOTS WG.] 833 This DOTS mitigation service initiation request may be 834 automatically initiated by the CPE or PE DDoS mitigators, or may 835 be manually triggered by personnel of the requesting 836 organization in response to an alert from the mitigators (the 837 mechanism by which this process takes place is beyond the scope 838 of this document). 840 (d) The DOTS servers which receive the DOTS mitigation service 841 initiation requests determine that they have been to honor 842 requests from the requesting CPE or PE mitigators, and attempt 843 to initiate situationally-appropriate DDoS mitigation service on 844 their respective networks (the mechanism by which this process 845 takes place is beyond the scope of this document). 847 (e) The DDoS mitigators on the upstream network report back to the 848 DOTS servers that they are unable to initiate DDoS mitigation 849 service for the requesting organization due to mitigation 850 capacity constraints, bandwidth constraints, functionality 851 constraints, hardware casualties, or other impediments (the 852 mechanism by which this process takes place is beyond the scope 853 of this document). 855 (f) The DOTS servers transmit a DOTS service status message to the 856 requesting CPE or PE mitigators indicating that upstream DDoS 857 mitigation service cannot be initiated as requested. The scope, 858 format, and content of these messages must be codified by the 859 DOTS WG. 861 (g) The CPE or PE mitigators may optionally regularly re-transmit 862 DOTS mitigation status request messages to the relevant DOTS 863 servers until acknowledgement that mitigation services have been 864 initiated. The scope, format, and content of these messages 865 must be codified by the DOTS WG. 867 (h) The CPE or PE mitigators may optionally transmit a DOTS 868 mitigation service initiation request to DOTS servers associated 869 with a configured fallback upstream DDoS mitigation service. 870 The scope, format, and content of these messages must be 871 codified by the DOTS WG. Multiple fallback DDoS mitigation 872 services may optionally be configured. 874 (i) The process describe above cyclically continues until the DDoS 875 mitigation service request is fulfilled; the CPE or PE 876 mitigators determine that the DDoS attack volume has decreased 877 to a level and/or complexity which they themselves can 878 successfully mitigate; the DDoS attack has ceased; or manual 879 intervention by personnel of the requesting organization has 880 taken place. 882 4.2. Ancillary Use Cases 884 4.2.1. Auto-registration of DOTS clients with DOTS servers 886 An additional benefit of DOTS is that by utilizing agreed-upon 887 authentication mechanisms, DOTS clients can automatically register 888 for DDoS mitigation service with one or more upstream DOTS servers. 889 The details of such registration are beyond the scope of this 890 document. 892 4.2.2. Auto-provisioning of DDoS countermeasures 894 The largely manual tasks associated with provisioning effective, 895 situationally-appropriate DDoS countermeasures is a significant 896 barrier to providing/obtaining DDoS mitigation services for both 897 mitigation providers and mitigation recipients. Due to the 'self- 898 descriptive' nature of DOTS registration messages and mitigation 899 requests, the implementation and deployment of DOTS has the potential 900 to automate countermeasure selection and configuration for DDoS 901 mitigators. The details of such provisioning are beyond the scope of 902 this document. 904 4.2.3. Informational DDoS attack notification to interested and 905 authorized third parties 907 In addition to its primary role of providing a standardized, 908 programmatic approach to the automated and/or operator-assisted 909 request of DDoS mitigation services and providing status updates of 910 those mitigations to requesters, DOTS may be utilized to notify 911 security researchers, law enforcement agencies, regulatory bodies, 912 etc. of DDoS attacks against attack targets, assuming that 913 organizations making use of DOTS choose to share such third-party 914 notifications, in keeping with all applicable laws, regulations, 915 privacy and confidentiality considerations, and contractual 916 agreements between DOTS users and said third parties. 918 5. Security Considerations 920 DOTS is at risk from three primary attacks: DOTS agent impersonation, 921 traffic injection, and signaling blocking. The DOTS protocol MUST be 922 designed for minimal data transfer to address the blocking risk. 924 Impersonation and traffic injection mitigation can be managed through 925 current secure communications best practices. DOTS is not subject to 926 anything new in this area. One consideration could be to minimize 927 the security technologies in use at any one time. The more needed, 928 the greater the risk of failures coming from assumptions on one 929 technology providing protection that it does not in the presence of 930 another technology. 932 6. IANA Considerations 934 7. Acknowledgments 935 8. References 937 8.1. Normative References 939 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 940 10.17487/RFC0768, August 1980, 941 . 943 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 944 793, DOI 10.17487/RFC0793, September 1981, 945 . 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 949 RFC2119, March 1997, 950 . 952 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 953 Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, 954 September 1993, . 956 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 957 (CIDR): The Internet Address Assignment and Aggregation 958 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 959 2006, . 961 8.2. Informative References 963 [APACHE] "Apache mod_security", . 965 [RRL] "BIND RRL", . 969 Authors' Addresses 971 Roland Dobbins (editor) 972 Arbor Networks 973 30 Raffles Place 974 Level 17 Chevron House 975 Singapore 048622 976 Singapore 978 Email: rdobbins@arbor.net 979 Stephane Fouant 980 Corero Network Security 982 Email: Stefan.Fouant@corero.com 984 Daniel Migault 985 Ericsson 986 8400 boulevard Decarie 987 Montreal, QC H4P 2N2 988 Canada 990 Phone: +1 514-452-2160 991 Email: daniel.migault@ericsson.com 993 Robert Moskowitz 994 HTT Consulting 995 Oak Park, MI 48237 996 USA 998 Email: rgm@labs.htt-consult.com 1000 Nik Teague 1001 Verisign Inc 1002 12061 Bluemont Way 1003 Reston, VA 20190 1004 US 1006 Phone: +44 791 763 5384 1007 Email: nteague@verisign.com 1009 Liang Xia 1010 Huawei 1011 No. 101, Software Avenue, Yuhuatai District 1012 Nanjing 1013 China 1015 Email: Frank.xialiang@huawei.com