idnits 2.17.1 draft-ietf-dots-use-cases-02.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 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF' is mentioned on line 135, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 4, 2017 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 31, 2016 16 Use cases for DDoS Open Threat Signaling 17 draft-ietf-dots-use-cases-02.txt 19 Abstract 21 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 22 protocol that facilitates interoperability between multivendor 23 solutions/services. This document presents use cases to evaluate the 24 interactions expected between the DOTS components as well as the DOTS 25 exchanges. The purpose of the use cases is to identify the 26 interacting DOTS component, how they collaborate and what are the 27 type of informations to be exchanged. 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 May 4, 2017. 46 Copyright Notice 48 Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 65 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 66 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. CPE Intra-domain DDoS Mitigation . . . . . . . . . . . . 4 69 3.2. Service/System Intra-domain DDoS Mitigation . . . . . . . 5 70 3.3. Orchestrating Intra-domain DDoS Mitigation . . . . . . . 6 71 3.4. Inter-domain DDoS Mitigation . . . . . . . . . . . . . . 6 72 4. Use Cases Taxonomy . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. DOTS Client Taxonomy . . . . . . . . . . . . . . . . . . 7 74 4.2. DOTS Server Taxonomy . . . . . . . . . . . . . . . . . . 9 75 4.3. DOTS Message Taxonomy . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 12 83 A.1. Primary Use Cases . . . . . . . . . . . . . . . . . . . . 14 84 A.1.1. Automatic or Operator-Assisted CPE or PE Mitigators 85 Request Upstream DDoS Mitigation Services . . . . . . 14 86 A.1.2. Automatic or Operator-Assisted CPE or PE Network 87 Infrastructure Element Request to Upstream Mitigator 16 88 A.1.3. Automatic or Operator-Assisted CPE or PE Attack 89 Telemetry Detection/Classification System Request to 90 Upstream Mitigator . . . . . . . . . . . . . . . . 17 91 A.1.4. Automatic or Operator-Assisted Targeted Service/ 92 Application Request to Upstream Mitigator . . . . . . 19 93 A.1.5. Manual Web Portal Request to Upstream Mitigator . . 21 94 A.1.6. Manual Mobile Device Application Request to 95 Upstream Mitigator . . . . . . . . . . . . . . . . . 23 96 A.1.7. Unsuccessful Automatic or Operator-Assisted CPE or 97 PE Mitigators Request Upstream DDoS Mitigation 98 Services . . . . . . . . . . . . . . . . . . . . . . 25 99 A.2. Ancillary Use Cases . . . . . . . . . . . . . . . . . . . 26 100 A.2.1. Auto-registration of DOTS clients with DOTS servers 26 101 A.2.2. Auto-provisioning of DDoS countermeasures . . . . . . 26 102 A.2.3. Informational DDoS attack notification to 103 interested and authorized third parties . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 Currently, distributed denial-of-service (DDoS) attack mitigation 109 solutions/services are largely based upon siloed, proprietary 110 communications paradigms which result in vendor/service lock-in, and 111 as a side-effect make the configuration, provisioning, operation, and 112 activation of these solutions a highly manual and often time- 113 consuming process. Additionally, coordination of multiple DDoS 114 mitigation solutions/services simultaneously engaged in defending the 115 same organization against DDoS attacks is fraught with both technical 116 and process-related hurdles which greatly increase operational 117 complexity and often result in suboptimal DDoS attack mitigation 118 efficacy. 120 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 121 protocol that facilitates interoperability between multivendor 122 solutions/services. As DDoS solutions/services are broadly 123 heterogeneous among different vendor, the primary goal for DOTS is to 124 provide a high level interaction with these DDoS solutions/services 125 such as initiating or terminating the the service/solution. In 126 addition, DOTS is limited to DDoS and may be used by a node under 127 attack. More specifically, DOTS does not intend to become a generic 128 purpose used to orchestrate different DDoS mitigation services/ 129 solutions and the use of DOTS by node under a DDoS attack is expected 130 to impact the design of the DOTS protocol. As a result, although 131 DOTS may be used in the future for further signaling, the current 132 document limits DOTS to a DDoS signaling protocol. It should be 133 noted that DOTS is not in and of itself intended to perform 134 orchestration functions duplicative of the functionality being 135 developed by the [I2NSF] WG; rather, DOTS is intended to allow 136 devices, services, and applications to request mitigation assistance 137 and receive mitigation status updates from systems of this nature. 139 This document provides use cases where DDoS mitigation is handled 140 using DOTS. The use case presented in the document are intended to 141 clarify what interactions are envisioned with DOTS, as well as the 142 nodes interacting using DOTS. In both cases, the use cases are 143 expected to provide inputs for the design of DOTS. 145 2. Terminology and Acronyms 147 2.1. Requirements Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2.2. Acronyms 155 This document makes use of the same terminology and definitions as 156 [I-D.ietf-dots-requirements], except where noted. 158 3. Use Cases Scenarios 160 This section provides a high level description of scenarios addressed 161 by DOTS. These scenarios are described in more details in 162 Appendix A. In both sections, the scenarios are provided in order to 163 illustrate the purpose of DOTS. They are not limitative and other 164 use cases are expected to appear during the deployment of DOTS. 166 All scenarios presents a coordination between the DDoS target, the 167 DDoS attack telemetry and the mitigator. The coordination and 168 communication between these entity depends, for example on the 169 characteristic or functionality of the equipment, the reliability of 170 the information provided by DDoS attack telemetry, the business 171 relationship between the DDoS target domain and the mitigator. 173 More explicitly, in some cases, the DDoS telemetry attack may simply 174 activate a DDoS mitigation, whereas in some case, it may collaborate 175 by providing some information. In some cases, the DDoS mitigation 176 may be orchestrated, which includes selecting an specific appliance 177 as well as starting/ending a mitigation. 179 3.1. CPE Intra-domain DDoS Mitigation 181 The most elementary scenario considers a equipment such as a CPE that 182 when overloaded sends an alert to specific equipment located 183 upstream. In most cases, these very basic equipment are unlikely to 184 diagnose whether an DDoS attack is ongoing or not and detection as 185 well as potential mitigation is left to the upstream equipment. 187 In most deployment, the upstream equipment belong to the same domain 188 as the CPE. In such case, it is not expected that a specific 189 contract is established between the CPE and the DDoS mitigation 190 service. The CPE and concerned traffic is likely to be identified by 191 the source of the alert, which also imply the mitigator is aware of 192 the nature of the equipment as well as the architecture of the 193 domain. 195 The DDoS mitigation service may be for example an equipment that is 196 located on path or a controller that will configure the network to 197 the traffic to be analyzed and mitigated is redirected to a dedicated 198 vendor specific equipment or solution. The DDoS mitigation service 199 may be activated only for the traffic associated to the CPE sending 200 the alert or instead to the traffic associated to all CPE. Such 201 decision are not part of DOTS, but instead depends on the policies of 202 the network administrator. 204 The DDoS mitigation service is expected to acknowledge the reception 205 of the alert in order to avoid retransmission. This may become an 206 issue for example if an ISP receives alerts from all CPEs multiple 207 time. However, it is unlikely that in such cases the CPE will follow 208 the status of the mitigation. Instead, as the DDoS mitigation 209 service and the CPE belongs to the same administrative domain, it is 210 expected that the decision of mitigating or not, as well as the 211 decision to end an ongoing mitigation will be left to DDoS mitigation 212 service without notice to the CPEs. 214 3.2. Service/System Intra-domain DDoS Mitigation 216 This section considers that some more specialized equipment are 217 sending the DDoS alert. As opposed to the CPE, these equipment are 218 likely to provide reliable information about the ongoing attack. 219 Such equipment could typically be a telemetry system, or a specific 220 target service such as a specific instance of web server, or a 221 specific web application detecting application specific attacks. 223 Such information is likely to be carried in the alert and taken into 224 account by the DDoS mitigation service to proceed to further action. 225 Typically a telemetry system may indicate selectors of the suspicious 226 traffic as well indicators or qualification of the detected attack. 227 As the telemetry system is expected to monitor multiple aspect of the 228 traffic. Similarly when an attack is detected by the target service. 229 The destination of the alert is likely to receive alert from multiple 230 different services (DNS, HTTP, TCP, UDP, application layer 231 specific...). Such information is likely to be trusted and 232 considered by the mitigator to apply the appropriated security 233 appliance. 235 Note that within a single domain it likely that the service or the 236 telemetry system are most accurate equipment to qualify the attack. 237 As a result, not providing the information is likely to re-do the 238 analysis phase. Providing the information while sending the alert 239 avoid re-processing the analysis. Instead the mitigator uses 240 directly the information to redirect the traffic to the appropriated 241 specialized appliance. 243 For the same reasons as the CPE, as mitigation of the DDoS Service is 244 performed in a single administrative domain, the source of the alert 245 may not manage the end of the mitigation service and leave such 246 decision to the administrator of domain or the DDoS mitigation 247 service. 249 3.3. Orchestrating Intra-domain DDoS Mitigation 251 This section presents a generalization of the Service/System intra- 252 domain scenario. Orchestration goes one step further and considers 253 that the information carried by the alert could have some management 254 purpose. This includes explicitly starting / ending a mitigation as 255 well as selecting a specific DDoS mitigation service. This differs 256 from the previous case in that the source of the alert does not leave 257 anymore the decision on how to mitigate the attack by the mitigator. 258 Instead the mitigator is orchestrated. 260 Typical example of orchestrators could be a network administrator 261 that monitors the traffic and initiates manually a DDoS mitigation 262 from its web portal. Orchestration may also applied automatically by 263 an orchestrator. 265 3.4. Inter-domain DDoS Mitigation 267 In the case of inter-domain mitigation, it is expected that the DDoS 268 mitigation service has more resource, know-how than the target 269 domain. As a result, there is little benefit of sharing the 270 information collected in the target domain. In addition, the 271 relation between the two domains are also expected to be described 272 into a pre-agreed contract. In that sense, the alert can be 273 restraint to an activation of the DDoS mitigation service. 275 On the other hand, has there is a contract agreement, it is also 276 expected that target domain is able to stop the DDoS mitigation 277 service itself, and that the end of the mitigation is not 278 unilaterally provided to the DDoS mitigation service. 280 4. Use Cases Taxonomy 282 The purpose of DDoS Open Threat Signaling DOTS is to enable the 283 coordination of multiple vendor DDoS mitigation services/systems. 284 DOTS communication is a communication between a DOTS Client and a 285 DOTS Server. A DOTS Client or DOTS Server can be hosted on different 286 nodes which are associated to different functionalities, and thus 287 leading to different expectations from DOTS. This section provides a 288 classification of the DOTS Client, the DOTS Servers as well as the 289 different type of exchanges. 291 The high level classification is then illustrated on concrete nodes 292 and examples. Appendix also illustrate the current classification 293 with scenario and complete description of the process. 295 4.1. DOTS Client Taxonomy 297 DOTS Client initiates a DOTS communication in order to alert an DDoS 298 attack is ongoing or to coordinate a DDoS mitigation. Coordination 299 of a DDOS Mitigation with DOTS includes initiating/terminations of an 300 DDoS mitigation service/system as well as controlling the status of 301 an ongoing DDoS mitigation. 303 Note that the section only considers DOTS Client that are actually 304 initiating an exchange with a DOTS Server, and nodes that simply 305 relay DOTS messages are not considered here. 307 Here are the categories of DOTS Client envisioned in this document: 309 (a) DOTS Client alerting a DDoS attack is ongoing 311 i) hosted on the target attack 313 ii) hosted on a monitoring service/system 315 (b) DOTS Client coordinating an DDoS attack mitigation 317 i) hosted on an orchestrator 319 ii) hosted on administrative GUI 321 When the DOTS Client is hosted on the attack target. The DOTS Client 322 mostly raised an alert to the DDoS Mitigation service/system. When a 323 alert is raised by the node under attack, very little information is 324 expected to be provided by DOTS Client to the DDoS mitigation 325 service/system. More particularly telemetric information or 326 characteristics of the attack are likely to be unreliable as the host 327 is already overload. As a result, such DOTS Client may raise an 328 alert without any additional information. Eventually, information 329 such as the asset under attack which can simply be configured. The 330 asset under attack is especially useful for the DDoS mitigation 331 service/system to indicate the origin of the alert. It is not 332 necessary, for example, if the origin of the alert is implicit. The 333 origin of the alert my be implicit, for example when DOTS Clients are 334 authenticated or when the device is identified by the links (i.e when 335 the host is a CPE). Note also that the asset to protect is only 336 informational and optional. This information may be spoofed, and the 337 DDoS mitigation is likely to be derived from the authentication of 338 the alert. In most cases, the DDoS mitigation has been pre-agreed 339 between the host under attack and the DDoS mitigation service/system. 341 When the DOTS Client is hosted on a monitoring system, the monitoring 342 system may raise an alert an attack is ongoing. Unlike the host 343 under attack, the monitoring system is expected to have sufficient 344 resource so it is not itself overload and impacted by the ongoing 345 attack. As a result, the DOTS Client is more likely to provide 346 additional information associated to the alert, as this information 347 is expected to be reliable. The type of information associated may 348 be associated to the asset to protect and eventually some information 349 qualifying the attack. On the other hand, the information associated 350 also depends on how the what has been agreed with DDoS mitigation 351 service/system. In most cases, when a DDoS attack is detected all 352 the traffic is redirected to the DDoS mitigation procedure has been 353 agreed between the DDoS mitigation service/system and the entity 354 hosting the monitoring service. In such cases, very few information 355 is needed. 357 When the DOTS Client is hosted on an orchestrator, the DOTS Client 358 contacts the DDoS mitigation service/system to initiates a DDoS 359 mitigation. The orchestrator is responsible for setting the network 360 to redirect the traffic to the DDoS mitigation service/system. If 361 the DDoS mitigation service/system is not available, the orchestrator 362 is responsible to find an alternative. Again the orchestrator is 363 likely to provide additional information to the DDoS mitigation 364 service/system. For example, typical information may be the asset to 365 protect, as well as the specific mitigation function requested. On 366 the other hand, the service is usually expected to be associated to 367 the mitigation service, and so may not be explicitly specified. In 368 addition, the DOTS Client is also expected to control how the DDoS 369 mitigation is performed. More specifically, it is expected that the 370 DOTS Client can terminate the DDoS mitigation. In addition, the DOTS 371 Client should have sufficient information to decide how to operate 372 next. For example, it should be able to check if the mitigation is 373 ongoing as well as the efficiency of the mitigation. 375 When the DOTS client is hosted on an administrative system, the DOTS 376 Client may be triggered by the network administrator to initiate a 377 DDoS mitigation. In this case, the DOTS Server is likely to be an 378 orchestrator, and all necessary information may be provided so the 379 DDoS mitigation can be initiated. This includes, the asset to be 380 protected, the action expected to be performed by the orchestrator, 381 the DDoS mitigation service/system to contact... 383 Note that information associated by the DOTS Client to a request for 384 mitigation is not limited. However, as DDoS mitigation systems are 385 highly heterogeneous, if there is a need to provide interoperability 386 between the vendors and DDoS mitigation services/systems, that 387 actions provided by a DOTS Clients remains small and accepted by all 388 services/systems. As a result here are the envisioned optional 389 information provided by the DOTS Client. 391 (a) recommended asset to protect (IP, port). This information 392 specifies the expected action from the DDoS mitigation service/ 393 system. 395 (b) optional DDoS Mitigation Contract ID: which references the 396 contract agreed out-of-band. This information specifies the 397 expected action from the DDoS mitigation service/system. 399 (c) optional Requested Service: which designates the function or 400 service associated to the DDoS mitigation service/system. This 401 information specifies the expected action from the DDoS 402 mitigation service/system. 404 (d) optional DDoS attack information (suspected attack, telemetry ): 405 This information is expected to help the mitigation service/ 406 system to diagnose the ongoing attack. 408 In both cases, the DOTS Client sends a request for DDoS mitigation to 409 the DOTS Server, and expects the DDoS mitigation service/system 410 mitigates the DDoS attack. The difference between sending a request 411 for DDoS mitigation as an alert or for coordinating an DDoS 412 mitigation is that an alert is a request to completely outsource the 413 mitigation, whereas the coordination requires additional control over 414 the DDoS mitigation. An alert may be acknowledged by the DOTS Server 415 to acknowledge the reception whereas during the coordination, the the 416 DOTS server may acknowledge the initiation of the DDoS mitigation. 418 4.2. DOTS Server Taxonomy 420 DOTS Servers terminate the DOTS communication. The DOTS Server is 421 typically hosted on a DDoS mitigation service/system or an 422 intermediary node such as an orchestrator. 424 The DOTS Server is expected to be the entry point of a DDoS 425 mitigation service/system. Some DOTS Client do not expect any 426 interaction from the DOTS Server, once a DDoS mitigation has been 427 requested. This is especially true for DOTS Client hosted on attack 428 target. Other DOTS Client hosted on orchestrators or DDoS mitigation 429 service/systems are likely to expect for the DOTS Server a 430 confirmation the system accepts the DDoS mitigation task. 432 Respectively, these DOTS Client are also likely to expect a 433 confirmation when a DDoS mitigation termination has been requested. 434 In addition, DOTS Server are also expected to provide information 435 related to the mitigation status when requested by the DOTS Client. 436 In addition, it is also expected that the DOTS Server could provide 437 some status report of the DDoS mitigation on a push basis. 439 4.3. DOTS Message Taxonomy 441 The core essential messages to coordination an heterogeneous set of 442 DDoS mitigation services/system needs to be small and enable future 443 options. Here are the different exchanges envisioned in this 444 document between a DOTS Client and a DOTS Server. 446 (a) DOTS MITIGATION CONTROL messages are used by the DOTS Client to 447 initiate or terminate a DDoS mitigation. The initiator the 448 termination can be specified by the action type START or STOP. 449 Such message can carry some additional options that specify 450 additional information such as the asset under attack for 451 example. These DOTS MITIGATION CONTROL messages are expected to 452 be ACKed by the DOTS Server, in order to indicate the DOTS 453 Server will perform the requested action. In any other case an 454 error is expected to be returned. ven in the case of a DOTS 455 Client sends an alert, ACK is recommended so the DOTS Client 456 stop sending the alert. 458 (b) DOTS MITIGATION INFORMATIONAL message are left for any 459 additional interaction between a DOTS Client and DOTS Server 460 regarding an ongoing request. INFORMATIONAL message can be 461 ignored by the receiver if it does not not understand the the 462 requested information or options. In the current document an 463 informational message can be the status of the ongoing 464 mitigation. 466 (c) DOTS ERROR contains the errors associated to a request. 468 DOTS OPTIONS: options can be used to indicate some optional 469 information. The option is expected to specify whether the DOTS 470 Server can ignore it or must return an error if it is not understood. 471 Options are not message, but part of the message. 473 5. Security Considerations 475 DOTS is at risk from three primary attacks: DOTS agent impersonation, 476 traffic injection, and signaling blocking. The DOTS protocol MUST be 477 designed for minimal data transfer to address the blocking risk. 479 Impersonation and traffic injection mitigation can be managed through 480 current secure communications best practices. DOTS is not subject to 481 anything new in this area. One consideration could be to minimize 482 the security technologies in use at any one time. The more needed, 483 the greater the risk of failures coming from assumptions on one 484 technology providing protection that it does not in the presence of 485 another technology. 487 Additional details of DOTS security requirements may be found in 488 [I-D.ietf-dots-requirements]. 490 6. IANA Considerations 492 No IANA considerations exist for this document at this time. 494 7. Acknowledgments 496 TBD 498 8. References 500 8.1. Normative References 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 8.2. Informative References 509 [APACHE] "Apache mod_security", . 511 [I-D.ietf-dots-requirements] 512 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 513 Denial of Service (DDoS) Open Threat Signaling 514 Requirements", draft-ietf-dots-requirements-03 (work in 515 progress), October 2016. 517 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 518 Cheshire, "Internet Assigned Numbers Authority (IANA) 519 Procedures for the Management of the Service Name and 520 Transport Protocol Port Number Registry", BCP 165, 521 RFC 6335, DOI 10.17487/RFC6335, August 2011, 522 . 524 [RRL] "BIND RRL", . 528 Appendix A. Use Cases 530 This section provides a high-level overview of likely use cases and 531 deployment scenarios for DOTS-enabled DDoS mitigation services. It 532 should be noted that DOTS servers may be standalone entities which, 533 upon receiving a DOTS mitigation service request from a DOTS client, 534 proceed to initiate DDoS mitigation service by communicating directly 535 or indirectly with DDoS mitigators, and likewise terminate the 536 service upon receipt of a DOTS service termination request; 537 conversely, the DDoS mitigators themselves may incorporate DOTS 538 servers and/or DOTS clients. The mechanisms by which DOTS servers 539 initiate and terminate DDoS mitigation service with DDoS mitigators 540 is beyond the scope of this document. 542 All of the primary use cases described in this section are derived 543 from current, real-world DDoS mitigation functionality, capabilities, 544 and operational models. 546 The posited ancillary use cases described in this section are 547 reasonable and highly desirable extrapolations of the functionality 548 of baseline DOTS capabilities, and are readily attainable in the near 549 term. 551 Each of the primary and ancillary use cases described in this section 552 may be read as involving one or more DDoS mitigation service 553 providers; DOTS makes multi-provider coordinated DDoS defenses much 554 more effective and practical due to abstraction of the particulars of 555 a given DDoS mitigation service/solution set. 557 Both the primary and ancillary use cases may be facilitated by direct 558 DOTS client - DOTS server communications or via DOTS relays deployed 559 in order to aggregate DOTS mitigation service requests/responses, to 560 mediate between stateless and stateful underlying transport 561 protocols, to aggregate multiple DOTS requests and/or responses, to 562 filter DOTS requests and/or responses via configured policy 563 mechanisms, or some combination of these functions. 565 All DOTS messages exchanged between the DOTS clients and DOTS servers 566 in these use cases may be communicated directly between DOTS clients 567 and servers, or mediated by one or more DOTS relays residing on the 568 network of the originating network, the network where upstream DDoS 569 mitigation service takes place, an intervening network or networks, 570 or some combination of the above. 572 DOTS is intended to apply to both inter- and intra-domain DDoS attack 573 mitigation scenarios. The technical and operational requirements for 574 inter- and intra-domain DOTS communications are identical. The main 575 difference is administrative in nature; although it should be noted 576 that provisioning challenges which are typically associated with 577 inter- domain DOTS communications relationships may also apply in 578 intra- domain deployment scenarios, based upon organizational 579 factors. All of the same complexities surrounding authentication and 580 authorization can apply in both contexts, including considerations 581 such as network access policies to allow DOTS communications, DOTS 582 transport selection (including considerations of the implications of 583 link congestion if a stateful DOTS transport option is selected), 584 etc. Registration of well-known ports for DOTS transports per 585 [RFC6335] should be considered in light of these challenges. 587 It should also be noted that DOTS does not directly ameliorate the 588 various administrative challenges required for successful DDoS attack 589 mitigation. Letters of authorization, RADB updates, DNS zone 590 delegations, alteration of network access policies, technical 591 configurations required to facilitate network traffic diversion and 592 re-injection, etc., are all outside the scope of DOTS. DOTS may, 593 however, prove useful in automating the registration of DOTS clients 594 with DOTS servers, as well as in the automatic provisioning of 595 situationally- appropriate DDoS defenses and countermeasures. This 596 ancillary DOTS functionality is described in Appendix A.2. 598 Many of the 'external' administrative challenges associated with 599 establishing workable DDoS attack mitigation service may be addressed 600 by work currently in progress in the I2RS and I2NSF WGs. Interested 601 parties may wish to consider tracking those efforts, and coordination 602 with both I2RS and I2NSF is highly desirable. 604 Note that all the use-cases in this document are universal in nature. 605 They apply equally to endpoint networks, transit backbone providers, 606 cloud providers, broadband access providers, ASPs, CDNs, etc. They 607 are not specific to particular business models, topological models, 608 or application types, and are deliberately generalizable. Both 609 networks targeted for attack as well as any adjacent or topologically 610 distant networks involved in a given scenario may be either single- 611 or multi-homed. In the accompanying vector illustrations 612 incorporated into draft-ietf-dots-use-cases-01.pdf, specific business 613 and topological models are described in order to provide context. 615 Likewise, both DOTS itself and the use cases described in this 616 document are completely independent of technologies utilized for the 617 detection, classification, traceback, and mitigation of DDoS attacks. 618 Flow telemetry such as NetFlow and IPFIX, direct full-packet 619 analysis, log-file analysis, indirection manual observation, etc. can 620 and will be enablers for detection, classification and traceback. 621 Intelligent DDoS mitigation systems (IDMSes), flowspec, S/RTBH, ACLs, 622 and other network traffic manipulation tools and techniques may be 623 used for DDoS attack mitigation. BGP, flowspec, DNS, inline 624 deployment, and various 'NFV' technologies may be used for network 625 traffic diversion into mitigation centers or devices in applicable 626 scenarios; GRE, MPLS, 'NFV', inline deployment and other techniques 627 may be utilized for 'cleaned' traffic re-injection to its intended 628 destination. 630 The scope, format, and content of all DOTS message types cited in 631 this document must be codified by the DOTS WG. 633 The following use cases are intended to inform the DOTS requirements 634 described in [I-D.ietf-dots-requirements]. 636 A.1. Primary Use Cases 638 A.1.1. Automatic or Operator-Assisted CPE or PE Mitigators Request 639 Upstream DDoS Mitigation Services 641 One or more CPE or PE mitigators with DOTS client capabilities may be 642 configured to signal to one or more DOTS servers in order to request 643 upstream DDoS mitigation service initiation during an attack when 644 DDoS attack volumes and/or attack characteristics exceed the 645 capabilities of such CPE mitigators. DDoS mitigation service may be 646 terminated either automatically or manually via a DOTS mitigation 647 service termination request initiated by the mitigator when it has 648 been determined that the DDoS attack has ended. 650 (a) A DDoS attack is initiated against online properties of an 651 organization which has deployed DOTS-client-capable DDoS 652 mitigators. 654 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 655 the DDoS attack. 657 (c) CPE or PE DDoS mitigators determine that their capacity and/or 658 capability to mitigate the DDoS attack is insufficient, and 659 utilize their DOTS client functionality to send a DOTS 660 mitigation service initiation request to one or more DOTS 661 servers residing on one or more upstream transit networks, peer 662 networks, or overlay MSSP networks. This DOTS mitigation 663 service initiation request may be automatically initiated by the 664 CPE or PE DDoS mitigators, or may be manually triggered by 665 personnel of the requesting organization in response to an alert 666 from the mitigators (the mechanism by which this process takes 667 place is beyond the scope of this document). 669 (d) The DOTS servers which receive the DOTS mitigation service 670 initiation requests determine that they have been configured to 671 honor requests from the requesting CPE or PE mitigators, and 672 initiate situationally-appropriate DDoS mitigation service on 673 their respective networks (the mechanism by which this process 674 takes place is beyond the scope of this document). 676 (e) The DOTS servers transmit a DOTS service status message to the 677 requesting CPE or PE mitigators indicating that upstream DDoS 678 mitigation service has been initiated. 680 (f) While DDoS mitigation services are active, the DOTS servers 681 regularly transmit DOTS mitigation status updates to the 682 requesting CPE or PE mitigators. 684 (g) While DDoS mitigation services are active, the CPE or PE 685 mitigators may optionally regularly transmit DOTS mitigation 686 efficacy updates to the relevant DOTS servers. 688 (h) When the upstream DDoS mitigators determine that the DDoS attack 689 has ceased, they indicate this change in status to their 690 respective DOTS servers (the mechanism by which this process 691 takes place is beyond the scope of this document). 693 (i) The DOTS servers transmit a DOTS mitigation status update to the 694 CPE or PE mitigators indicating that the DDoS attack has ceased. 696 (j) The CPE or PE DDoS mitigators transmit a DOTS mitigation service 697 termination request to the DOTS servers. This DOTS mitigation 698 service termination request may be automatically initiated by 699 the CPE or PE DDoS mitigators, or may be manually triggered by 700 personnel of the requesting organization in response to an alert 701 from the mitigators or a management system which monitors them 702 (the mechanism by which this process takes place is beyond the 703 scope of this document). 705 (k) The DOTS servers terminate DDoS mitigation service on their 706 respective networks (the mechanism by which this process takes 707 place is beyond the scope of this document). 709 (l) The DOTS servers transmit a DOTS mitigation status update to the 710 CPE or PE mitigators indicating that DDoS mitigation services 711 have been terminated. 713 (m) The CPE or PE DDoS mitigators transmit a DOTS mitigation 714 termination status acknowledgement to the DOTS servers. 716 A.1.2. Automatic or Operator-Assisted CPE or PE Network Infrastructure 717 Element Request to Upstream Mitigator 719 CPE or PE network infrastructure elements such as routers, switches, 720 load-balancers, firewalls, 'IPSes', etc. which have the capability to 721 detect and classify DDoS attacks and which have DOTS client 722 capabilities may be configured to signal to one or more DOTS servers 723 in order to request upstream DDoS mitigation service initiation 724 during an attack. DDoS mitigation service may be terminated either 725 automatically or manually via a DOTS mitigation service termination 726 request initiated by the network element when it has been determined 727 that the DDoS attack has ended. 729 In this use-case, the network elements involved are not engaged in 730 mitigating DDoS attack traffic. They are signaling for upstream 731 attack mitigation assistance. This can be an inter- or intra- domain 732 use-case. 734 (a) A DDoS attack is initiated against online properties of an 735 organization with DOTS-client-capable network infrastructure 736 elements deployed. 738 (b) The network infrastructure elements utilize their DOTS client 739 functionality to send a DOTS mitigation service initiation 740 request to one or more DOTS servers residing on one or more 741 upstream transit networks, peer networks, or overlay MSSP 742 networks, either directly or via intermediate DOTS relays 743 residing upon the requesting organization's network, the 744 upstream mitigation provider's network, or both. The scope, 745 format, and content of these messages must be codified by the 746 DOTS WG. This DOTS mitigation service initiation request may be 747 automatically initiated by the network infrastructure elements, 748 or may be manually triggered by personnel of the requesting 749 organization in response to an alert from the network elements 750 or a management system which monitors them (the mechanism by 751 which this process takes place is beyond the scope of this 752 document). 754 (c) The DOTS servers which receive the DOTS mitigation service 755 initiation requests determine that they have been configured to 756 honor requests from the requesting network infrastructure 757 elements, and initiate situationally-appropriate DDoS mitigation 758 service on their respective networks (the mechanism by which 759 this process takes place is beyond the scope of this document). 761 (d) The DOTS servers transmit a DOTS service status message to the 762 requesting network infrastructure elements indicating that 763 upstream DDoS mitigation service has been initiated. 765 (e) While DDoS mitigation services are active, the DOTS servers 766 regularly transmit DOTS mitigation status updates to the 767 requesting requesting network infrastructure elements. 769 (f) While DDoS mitigation services are active, the network 770 infrastructure elements may optionally regularly transmit DOTS 771 mitigation efficacy updates to the relevant DOTS servers. 773 (g) When the upstream DDoS mitigators determine that the DDoS attack 774 has ceased, they indicate this change in status to their 775 respective DOTS servers (the mechanism by which this process 776 takes place is beyond the scope of this document). 778 (h) The DOTS servers transmit a DOTS mitigation status update to the 779 network infrastructure elements indicating that the DDoS attack 780 has ceased. 782 (i) The network infrastructure elements transmit a DOTS mitigation 783 service termination request to the DOTS servers. This DOTS 784 mitigation service termination request may be automatically 785 initiated by the network infrastructure elements, or may be 786 manually triggered by personnel of the requesting organization 787 in response to an alert from the mitigators (the mechanism by 788 which this process takes place is beyond the scope of this 789 document). 791 (j) The DOTS servers terminate DDoS mitigation service on their 792 respective networks (the mechanism by which this process takes 793 place is beyond the scope of this document). 795 (k) The DOTS servers transmit a DOTS mitigation status update to the 796 network infrastructure elements indicating that DDoS mitigation 797 services have been terminated. 799 (l) The network infrastructure elements transmit a DOTS mitigation 800 termination status acknowledgement to the DOTS servers. 802 A.1.3. Automatic or Operator-Assisted CPE or PE Attack Telemetry 803 Detection/Classification System Request to Upstream Mitigator 805 CPE or PE Attack Telemetry Detection/Classification Systems which 806 have DOTS client capabilities may be configured so that upon 807 detecting and classifying a DDoS attack, they signal one or more DOTS 808 servers in order to request upstream DDoS mitigation service 809 initiation. DDoS mitigation service may be terminated either 810 automatically or manually via a DOTS mitigation service termination 811 request initiated by the Attack Telemetry Detection/Classification 812 System when it has been determined that the DDoS attack has ended. 814 In this use-case, the Attack Telemetry Detection/Classification does 815 not possess any inherent capability to mitigate DDoS attack traffic, 816 and is signaling for upstream mitigation assistance. This can be an 817 inter- or intra-domain use-case. 819 (a) A DDoS attack is initiated against online properties of an 820 organization with DOTS-client-capable CPE or PE Attack Telemetry 821 Detection/Classification Systems deployed. 823 (b) The CPE or PE Attack Telemetry Detection/Classification Systems 824 utilize their DOTS client functionality to send a DOTS 825 mitigation service initiation request to one or more DOTS 826 servers residing on one or more upstream transit networks, peer 827 networks, or overlay MSSP networks, either directly or via 828 intermediate DOTS relays residing upon the requesting 829 organization's network, the upstream mitigation provider's 830 network, or both. This DOTS mitigation service initiation 831 request may be automatically initiated by the CPE or PE Attack 832 Telemetry Detection/Classification Systems, or may be manually 833 triggered by personnel of the requesting organization in 834 response to an alert from the CPE or PE Attack Telemetry 835 Detection/Classification Systems (the mechanism by which this 836 process takes place is beyond the scope of this document). 838 (c) The DOTS servers which receive the DOTS mitigation service 839 initiation requests determine that they have been configured to 840 honor requests from the requesting CPE or PE Attack Telemetry 841 Detection/Classification Systems, and initiate situationally- 842 appropriate DDoS mitigation service on their respective networks 843 (the mechanism by which this process takes place is beyond the 844 scope of this document). 846 (d) The DOTS servers transmit a DOTS service status message to the 847 requesting CPE or PE Attack Telemetry Detection/Classification 848 Systems indicating that upstream DDoS mitigation service has 849 been initiated. 851 (e) While DDoS mitigation services are active, the DOTS servers 852 regularly transmit DOTS mitigation status updates to the 853 requesting CPE or PE Attack Telemetry Detection/Classification 854 Systems. 856 (f) While DDoS mitigation services are active, the CPE or PE Attack 857 Telemetry Detection/Classification Systems may optionally 858 regularly transmit DOTS mitigation efficacy updates to the 859 relevant DOTS servers. 861 (g) When the upstream DDoS mitigators determine that the DDoS attack 862 has ceased, they indicate this change in status to their 863 respective DOTS servers (the mechanism by which this process 864 takes place is beyond the scope of this document). 866 (h) The DOTS servers transmit a DOTS mitigation status update to the 867 CPE or PE Attack Telemetry Detection/Classification Systems 868 indicating that the DDoS attack has ceased. 870 (i) The CPE or PE Attack Telemetry Detection/Classification Systems 871 transmit a DOTS mitigation service termination request to the 872 DOTS servers. This DOTS mitigation service termination request 873 may be automatically initiated by the CPE or PE Attack Telemetry 874 Detection/Classification Systems, or may be manually triggered 875 by personnel of the requesting organization in response to an 876 alert from the CPE or PE Attack Telemetry Detection/ 877 Classification Systems (the mechanism by which this process 878 takes place is beyond the scope of this document). 880 (j) The DOTS servers terminate DDoS mitigation service on their 881 respective networks (the mechanism by which this process takes 882 place is beyond the scope of this document). 884 (k) The DOTS servers transmit a DOTS mitigation status update to the 885 CPE or PE Attack Telemetry Detection/Classification Systems 886 indicating that DDoS mitigation services have been terminated. 888 (l) The CPE or PE Attack Telemetry Detection/Classification Systems 889 transmit a DOTS mitigation termination status acknowledgement to 890 the DOTS servers. 892 A.1.4. Automatic or Operator-Assisted Targeted Service/ Application 893 Request to Upstream Mitigator 895 A service or application which is the target of a DDoS attack and 896 which has the capability to detect and classify DDoS attacks (i.e, 897 Apache mod_security [APACHE], BIND RRL [RRL], etc.) as well as DOTS 898 client functionality may be configured so that upon detecting and 899 classifying a DDoS attack, it signals one or more DOTS servers in 900 order to request upstream DDoS mitigation service initiation. DDoS 901 mitigation service may be terminated either automatically or manually 902 via a DOTS mitigation service termination request initiated by the 903 service/application when it has been determined that the DDoS attack 904 has ended. 906 In this use-case, the service/application does not possess inherent 907 DDoS attack mitigation capabilities, and is signaling for upstream 908 mitigation assistance. This can be an inter- or intra-domain use- 909 case. 911 (a) A DDoS attack is initiated against online properties of an 912 organization which include DOTS-client-capable services or 913 applications that are the specific target(s) of the attack. 915 (b) The targeted services or applications utilize their DOTS client 916 functionality to send a DOTS mitigation service initiation 917 request to one or more DOTS servers residing on the same network 918 as the services or applications, one or more upstream transit 919 networks, peer networks, or overlay MSSP networks, either 920 directly or via intermediate DOTS relays residing upon the 921 requesting organization's network, the upstream mitigation 922 provider's network, or both. This DOTS mitigation service 923 initiation request may be automatically initiated by the 924 targeted services or applications, or may be manually triggered 925 by personnel of the requesting organization in response to an 926 alert from the targeted services or applications or a system 927 which monitors them (the mechanism by which this process takes 928 place is beyond the scope of this document). 930 (c) The DOTS servers which receive the DOTS mitigation service 931 initiation requests determine that they have been provisioned to 932 honor requests from the requesting services or applications, and 933 initiate situationally-appropriate DDoS mitigation service on 934 their respective networks (the mechanism by which this process 935 takes place is beyond the scope of this document). 937 (d) The DOTS servers transmit a DOTS service status message to the 938 services or applications indicating that upstream DDoS 939 mitigation service has been initiated 941 (e) While DDoS mitigation services are active, the DOTS servers 942 regularly transmit DOTS mitigation status updates to the 943 requesting services or applications. 945 (f) While DDoS mitigation services are active, the requesting 946 services or applications may optionally regularly transmit DOTS 947 mitigation efficacy updates to the relevant DOTS servers. 949 (g) When the upstream DDoS mitigators determine that the DDoS attack 950 has ceased, they indicate this change in status to their 951 respective DOTS servers (the mechanism by which this process 952 takes place is beyond the scope of this document). 954 (h) The DOTS servers transmit a DOTS mitigation status update to the 955 requesting services or applications indicating that the DDoS 956 attack has ceased. 958 (i) The targeted services or applications transmit a DOTS mitigation 959 service termination request to the DOTS servers. This DOTS 960 mitigation service termination request may be automatically 961 initiated by the targeted services or applications, or may be 962 manually triggered by personnel of the requesting organization 963 in response to an alert from a system which monitors them (the 964 mechanism by which this process takes place is beyond the scope 965 of this document). 967 (j) The DOTS servers terminate DDoS mitigation service on their 968 respective networks (the mechanism by which this process takes 969 place is beyond the scope of this document). 971 (k) The DOTS servers transmit a DOTS mitigation status update to the 972 targeted services or applications indicating that DDoS 973 mitigation services have been terminated. 975 (l) The targeted services or applications transmit a DOTS mitigation 976 termination status acknowledgement to the DOTS servers. 978 A.1.5. Manual Web Portal Request to Upstream Mitigator 980 A Web portal which has DOTS client capabilities has been configured 981 in order to allow authorized personnel of organizations which are 982 targeted by DDoS attacks to manually request upstream DDoS mitigation 983 service initiation from a DOTS server. When an organization has 984 reason to believe that it is under active attack, authorized 985 personnel may utilize the Web portal to manually initiate a DOTS 986 client mitigation request to one or more DOTS servers. DDoS 987 mitigation service may be terminated manually via a DOTS mitigation 988 service termination request through the Web portal when it has been 989 determined that the DDoS attack has ended. 991 In this use-case, the organization targeted for attack does not 992 possess any automated or operator-assisted mechanisms for DDoS attack 993 detection, classification, traceback, or mitigation; the existence of 994 an attack has been inferred manually, and the organization is 995 requesting upstream mitigation assistance. This can theoretically be 996 an inter- or intra-domain use-case, but is more typically an inter- 997 domain scenario. 999 (a) A DDoS attack is initiated against online properties of an 1000 organization have access to a Web portal which incorporates DOTS 1001 client functionality and can generate DOTS mitigation service 1002 requests upon demand. 1004 (b) Authorized personnel utilize the Web portal to send a DOTS 1005 mitigation service initiation request to one or more upstream 1006 transit networks, peer networks, or overlay MSSP networks, 1007 either directly or via intermediate DOTS relays residing upon 1008 the requesting organization's network, the upstream mitigation 1009 provider's network, or both. This DOTS mitigation service 1010 initiation request is manually triggered by personnel of the 1011 requesting organization when it is judged that the organization 1012 is under DDoS attack (the mechanism by which this process takes 1013 place is beyond the scope of this document). 1015 (c) The DOTS servers which receive the DOTS mitigation service 1016 initiation requests determine that they have been provisioned to 1017 honor requests from the Web portal, and initiate situationally- 1018 appropriate DDoS mitigation service on their respective networks 1019 (the mechanism by which this process takes place is beyond the 1020 scope of this document). 1022 (d) The DOTS servers transmit a DOTS service status message to the 1023 Web portal indicating that upstream DDoS mitigation service has 1024 been initiated. 1026 (e) While DDoS mitigation services are active, the DOTS servers 1027 regularly transmit DOTS mitigation status updates to the Web 1028 portal. 1030 (f) While DDoS mitigation services are active, the Web portal may 1031 optionally regularly transmit manually-triggered DOTS mitigation 1032 efficacy updates to the relevant DOTS servers. 1034 (g) When the upstream DDoS mitigators determine that the DDoS attack 1035 has ceased, they indicate this change in status to their 1036 respective DOTS servers (the mechanism by which this process 1037 takes place is beyond the scope of this document). 1039 (h) The DOTS servers transmit a DOTS mitigation status update to the 1040 Web portal indicating that the DDoS attack has ceased. 1042 (i) The Web portal transmits a manually-triggered DOTS mitigation 1043 service termination request to the DOTS servers (the mechanism 1044 by which this process takes place is beyond the scope of this 1045 document). 1047 (j) The Web portal transmits a manually-triggered DOTS mitigation 1048 service termination request to the DOTS servers (the mechanism 1049 by which this process takes place is beyond the scope of this 1050 document). 1052 (k) The DOTS servers transmit a DOTS mitigation status update to the 1053 Web portal indicating that DDoS mitigation services have been 1054 terminated. 1056 (l) The Web portal transmits a DOTS mitigation termination status 1057 acknowledgement to the DOTS servers. 1059 A.1.6. Manual Mobile Device Application Request to Upstream Mitigator 1061 An application for mobile devices such as smartphones and tablets 1062 which incorporates DOTS client capabilities has been made available 1063 to authorized personnel of an organization. When the organization 1064 has reason to believe that it is under active DDoS attack, authorized 1065 personnel may utilize the mobile device application to manually 1066 initiate a DOTS client mitigation request to one or more DOTS servers 1067 in order to initiate upstream DDoS mitigation services. DDoS 1068 mitigation service may be terminated manually via a DOTS mitigation 1069 service termination request initiated through the mobile device 1070 application when it has been determined that the DDoS attack has 1071 ended. 1073 This use-case is similar to the one described in Appendix A.1.5; the 1074 difference is that a mobile application provided by the DDoS 1075 mitigation service provider is used to request upstream attack 1076 mitigation assistance. This can theoretically be an inter- or intra- 1077 domain use-case, but is more typically an inter-domain scenario. 1079 (a) A DDoS attack is initiated against online properties of an 1080 organization have access to a Web portal which incorporates DOTS 1081 client functionality and can generate DOTS mitigation service 1082 requests upon demand. 1084 (b) Authorized personnel utilize the mobile application to send a 1085 DOTS mitigation service initiation request to one or more DOTS 1086 servers residing on the same network as the targeted Internet 1087 properties, one or more upstream transit networks, peer 1088 networks, or overlay MSSP networks, either directly or via 1089 intermediate DOTS relays residing upon the requesting 1090 organization's network, the upstream mitigation provider's 1091 network, or both. This DOTS mitigation service initiation 1092 request is manually triggered by personnel of the requesting 1093 organization when it is judged that the organization is under 1094 DDoS attack (the mechanism by which this process takes place is 1095 beyond the scope of this document). 1097 (c) The DOTS servers which receive the DOTS mitigation service 1098 initiation requests determine that they have been provisioned to 1099 honor requests from the mobile application, and initiate 1100 situationally-appropriate DDoS mitigation service on their 1101 respective networks (the mechanism by which this process takes 1102 place is beyond the scope of this document). 1104 (d) The DOTS servers transmit a DOTS service status message to the 1105 mobile application indicating that upstream DDoS mitigation 1106 service has been initiated. 1108 (e) While DDoS mitigation services are active, the DOTS servers 1109 regularly transmit DOTS mitigation status updates to the mobile 1110 application. 1112 (f) While DDoS mitigation services are active, the mobile 1113 application may optionally regularly transmit manually-triggered 1114 DOTS mitigation efficacy updates to the relevant DOTS servers. 1116 (g) When the upstream DDoS mitigators determine that the DDoS attack 1117 has ceased, they indicate this change in status to their 1118 respective DOTS servers (the mechanism by which this process 1119 takes place is beyond the scope of this document). 1121 (h) The DOTS servers transmit a DOTS mitigation status update to the 1122 mobile application indicating that the DDoS attack has ceased. 1124 (i) The mobile application transmits a manually-triggered DOTS 1125 mitigation service termination request to the DOTS servers (the 1126 mechanism by which this process takes place is beyond the scope 1127 of this document). 1129 (j) The DOTS servers terminate DDoS mitigation service on their 1130 respective networks (the mechanism by which this process takes 1131 place is beyond the scope of this document). 1133 (k) The DOTS servers transmit a DOTS mitigation status update to the 1134 mobile application indicating that DDoS mitigation services have 1135 been terminated. 1137 (l) The mobile application transmits a DOTS mitigation termination 1138 status acknowledgement to the DOTS servers. 1140 A.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE Mitigators 1141 Request Upstream DDoS Mitigation Services 1143 One or more CPE or PE mitigators with DOTS client capabilities may be 1144 configured to signal to one or more DOTS servers in order to request 1145 upstream DDoS mitigation service initiation during an attack when 1146 DDoS attack volumes and/or attack characteristics exceed the 1147 capabilities of such CPE mitigators. DDoS mitigation service may be 1148 terminated either automatically or manually via a DOTS mitigation 1149 service termination request initiated by the mitigator when it has 1150 been determined that the DDoS attack has ended. 1152 This can theoretically be an inter- or intra-domain use-case, but is 1153 more typically an inter-domain scenario. 1155 (a) A DDoS attack is initiated against online properties of an 1156 organization which has deployed DOTS-client-capable DDoS 1157 mitigators. 1159 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 1160 the DDoS attack. 1162 (c) CPE or PE DDoS mitigators determine that their capacity and/or 1163 capability to mitigate the DDoS attack is insufficient, and 1164 utilize their DOTS client functionality to send a DOTS 1165 mitigation service initiation request to one or more DOTS 1166 servers residing on one or more upstream transit networks, peer 1167 networks, or overlay MSSP networks. This DOTS mitigation 1168 service initiation request may be automatically initiated by the 1169 CPE or PE DDoS mitigators, or may be manually triggered by 1170 personnel of the requesting organization in response to an alert 1171 from the mitigators (the mechanism by which this process takes 1172 place is beyond the scope of this document). 1174 (d) The DOTS servers which receive the DOTS mitigation service 1175 initiation requests determine that they have been configured to 1176 honor requests from the requesting CPE or PE mitigators, and 1177 attempt to initiate situationally-appropriate DDoS mitigation 1178 service on their respective networks (the mechanism by which 1179 this process takes place is beyond the scope of this document). 1181 (e) The DDoS mitigators on the upstream network report back to the 1182 DOTS servers that they are unable to initiate DDoS mitigation 1183 service for the requesting organization due to mitigation 1184 capacity constraints, bandwidth constraints, functionality 1185 constraints, hardware casualties, or other impediments (the 1186 mechanism by which this process takes place is beyond the scope 1187 of this document). 1189 (f) The DOTS servers transmit a DOTS service status message to the 1190 requesting CPE or PE mitigators indicating that upstream DDoS 1191 mitigation service cannot be initiated as requested. 1193 (g) The CPE or PE mitigators may optionally regularly re-transmit 1194 DOTS mitigation status request messages to the relevant DOTS 1195 servers until acknowledgement that mitigation services have been 1196 initiated. 1198 (h) The CPE or PE mitigators may optionally transmit a DOTS 1199 mitigation service initiation request to DOTS servers associated 1200 with a configured fallback upstream DDoS mitigation service. 1201 Multiple fallback DDoS mitigation services may optionally be 1202 configured. 1204 (i) The process describe above cyclically continues until the DDoS 1205 mitigation service request is fulfilled; the CPE or PE 1206 mitigators determine that the DDoS attack volume has decreased 1207 to a level and/or complexity which they themselves can 1208 successfully mitigate; the DDoS attack has ceased; or manual 1209 intervention by personnel of the requesting organization has 1210 taken place. 1212 A.2. Ancillary Use Cases 1214 A.2.1. Auto-registration of DOTS clients with DOTS servers 1216 An additional benefit of DOTS is that by utilizing agreed-upon 1217 authentication mechanisms, DOTS clients can automatically register 1218 for DDoS mitigation service with one or more upstream DOTS servers. 1219 The details of such registration are beyond the scope of this 1220 document. 1222 A.2.2. Auto-provisioning of DDoS countermeasures 1224 The largely manual tasks associated with provisioning effective, 1225 situationally-appropriate DDoS countermeasures is a significant 1226 barrier to providing/obtaining DDoS mitigation services for both 1227 mitigation providers and mitigation recipients. Due to the 'self- 1228 descriptive' nature of DOTS registration messages and mitigation 1229 requests, the implementation and deployment of DOTS has the potential 1230 to automate countermeasure selection and configuration for DDoS 1231 mitigators. The details of such provisioning are beyond the scope of 1232 this document. 1234 This can theoretically be an inter- or intra-domain use-case, but is 1235 more typically an inter-domain scenario. 1237 A.2.3. Informational DDoS attack notification to interested and 1238 authorized third parties 1240 In addition to its primary role of providing a standardized, 1241 programmatic approach to the automated and/or operator-assisted 1242 request of DDoS mitigation services and providing status updates of 1243 those mitigations to requesters, DOTS may be utilized to notify 1244 security researchers, law enforcement agencies, regulatory bodies, 1245 etc. of DDoS attacks against attack targets, assuming that 1246 organizations making use of DOTS choose to share such third-party 1247 notifications, in keeping with all applicable laws, regulations, 1248 privacy and confidentiality considerations, and contractual 1249 agreements between DOTS users and said third parties. 1251 This is an inter-domain scenario. 1253 Authors' Addresses 1255 Roland Dobbins (editor) 1256 Arbor Networks 1257 30 Raffles Place 1258 Level 17 Chevron House 1259 Singapore 048622 1260 Singapore 1262 Email: rdobbins@arbor.net 1264 Stefan Fouant 1265 Corero Network Security 1267 Email: Stefan.Fouant@corero.com 1269 Daniel Migault 1270 Ericsson 1271 8400 boulevard Decarie 1272 Montreal, QC H4P 2N2 1273 Canada 1275 Phone: +1 514-452-2160 1276 Email: daniel.migault@ericsson.com 1277 Robert Moskowitz 1278 HTT Consulting 1279 Oak Park, MI 48237 1280 USA 1282 Email: rgm@labs.htt-consult.com 1284 Nik Teague 1285 Verisign Inc 1286 12061 Bluemont Way 1287 Reston, VA 20190 1288 USA 1290 Phone: +44 791 763 5384 1291 Email: nteague@verisign.com 1293 Liang Xia 1294 Huawei 1295 No. 101, Software Avenue, Yuhuatai District 1296 Nanjing 1297 China 1299 Email: Frank.xialiang@huawei.com