idnits 2.17.1 draft-ietf-dots-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF' is mentioned on line 122, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-00 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: September 22, 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 March 21, 2016 16 Use cases for DDoS Open Threat Signaling 17 draft-ietf-dots-use-cases-01.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 September 22, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Primary Use Cases . . . . . . . . . . . . . . . . . . . . 6 69 3.1.1. Automatic or Operator-Assisted CPE or PE Mitigators 70 Request Upstream DDoS Mitigation Services . . . . . . 6 71 3.1.2. Automatic or Operator-Assisted CPE or PE Network 72 Infrastructure Element Request to Upstream Mitigator 8 73 3.1.3. Automatic or Operator-Assisted CPE or PE Attack 74 Telemetry Detection/Classification System Request to 75 Upstream Mitigator . . . . . . . . . . . . . . . . 10 76 3.1.4. Automatic or Operator-Assisted Targeted Service/ 77 Application Request to Upstream Mitigator . . . . . . 11 78 3.1.5. Manual Web Portal Request to Upstream Mitigator . . 13 79 3.1.6. Manual Mobile Device Application Request to 80 Upstream Mitigator . . . . . . . . . . . . . . . . . 15 81 3.1.7. Unsuccessful Automatic or Operator-Assisted CPE or 82 PE Mitigators Request Upstream DDoS Mitigation 83 Services . . . . . . . . . . . . . . . . . . . . . . 17 84 3.2. Ancillary Use Cases . . . . . . . . . . . . . . . . . . . 18 85 3.2.1. Auto-registration of DOTS clients with DOTS servers 18 86 3.2.2. Auto-provisioning of DDoS countermeasures . . . . . . 18 87 3.2.3. Informational DDoS attack notification to 88 interested and authorized third parties . . . . . . . 19 89 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 7.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 Currently, distributed denial-of-service (DDoS) attack mitigation 100 solutions/services are largely based upon siloed, proprietary 101 communications paradigms which result in vendor/service lock-in, and 102 as a side-effect make the configuration, provisioning, operation, and 103 activation of these solutions a highly manual and often time- 104 consuming process. Additionally, coordination of multiple DDoS 105 mitigation solutions/services simultaneously engaged in defending the 106 same organization against DDoS attacks is fraught with both technical 107 and process-related hurdles which greatly increase operational 108 complexity and often result in suboptimal DDoS attack mitigation 109 efficacy. 111 The DDoS Open Threat Signaling (DOTS) effort is intended to 112 facilitate interoperability between DDoS solutions/services by 113 providing a standards-based, programmatic communications mechanism 114 for the invitation and termination of heterogeneous DDoS attack 115 mitigation systems and services. This allows for a much higher 116 degree of automation and concomitant efficacy and rapidity of DDoS 117 attack mitigation involving multiple DDoS mitigation systems and 118 services than is currently the norm, as well as providing additional 119 benefits such as automatic DDoS mitigation service registration and 120 provisioning. It should be noted that DOTS is not in and of itself 121 intended to perform orchestration functions duplicative of the 122 functionality being developed by the [I2NSF] WG; rather, DOTS is 123 intended to allow devices, services, and applications to request 124 mitigation assistance and receive mitigation status updates from 125 systems of this nature. 127 This document provides an overview of common DDoS mitigation system/ 128 service deployment and operational models which are in use today, but 129 which are currently limited in scope to a single vendor or service 130 provider and are often highly manual in nature, which can lead to 131 miscommunications, misconfigurations, and delays in bringing 132 mitigation services to bear against an attack. The introduction of 133 DOTS into these scenarios will reduce reaction times and the risks 134 associated with manual processes, simplify the use of multiple types 135 of DDoS mitigation systems and services as required, and make 136 practical the simultaneous use multiple DDoS mitigation systems and 137 services as circumstances warrant. 139 2. Terminology and Acronyms 141 2.1. Requirements Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 2.2. Acronyms 149 This document makes use of the same terminology and definitions as 150 [I-D.ietf-dots-requirements], except where noted. 152 3. Use Cases 154 This section provides a high-level overview of likely use cases and 155 deployment scenarios for DOTS-enabled DDoS mitigation services. It 156 should be noted that DOTS servers may be standalone entities which, 157 upon receiving a DOTS mitigation service request from a DOTS client, 158 proceed to initiate DDoS mitigation service by communicating directly 159 or indirectly with DDoS mitigators, and likewise terminate the 160 service upon receipt of a DOTS service termination request; 161 conversely, the DDoS mitigators themselves may incorporate DOTS 162 servers and/or DOTS clients. The mechanisms by which DOTS servers 163 initiate and terminate DDoS mitigation service with DDoS mitigators 164 is beyond the scope of this document. 166 All of the primary use cases described in this section are derived 167 from current, real-world DDoS mitigation functionality, capabilities, 168 and operational models. 170 The posited ancillary use cases described in this section are 171 reasonable and highly desirable extrapolations of the functionality 172 of baseline DOTS capabilities, and are readily attainable in the near 173 term. 175 Each of the primary and ancillary use cases described in this section 176 may be read as involving one or more DDoS mitigation service 177 providers; DOTS makes multi-provider coordinated DDoS defenses much 178 more effective and practical due to abstraction of the particulars of 179 a given DDoS mitigation service/solution set. 181 Both the primary and ancillary use cases may be facilitated by direct 182 DOTS client - DOTS server communications or via DOTS relays deployed 183 in order to aggregate DOTS mitigation service requests/responses, to 184 mediate between stateless and stateful underlying transport 185 protocols, to aggregate multiple DOTS requests and/or responses, to 186 filter DOTS requests and/or responses via configured policy 187 mechanisms, or some combination of these functions. 189 All DOTS messages exchanged between the DOTS clients and DOTS servers 190 in these use cases may be communicated directly between DOTS clients 191 and servers, or mediated by one or more DOTS relays residing on the 192 network of the originating network, the network where upstream DDoS 193 mitigation service takes place, an intervening network or networks, 194 or some combination of the above. 196 DOTS is intended to apply to both inter- and intra-domain DDoS attack 197 mitigation scenarios. The technical and operational requirements for 198 inter- and intra-domain DOTS communications are identical. The main 199 difference is administrative in nature; although it should be noted 200 that provisioning challenges which are typically associated with 201 inter- domain DOTS communications relationships may also apply in 202 intra- domain deployment scenarios, based upon organizational 203 factors. All of the same complexities surrounding authentication and 204 authorization can apply in both contexts, including considerations 205 such as network access policies to allow DOTS communications, DOTS 206 transport selection (including considerations of the implications of 207 link congestion if a stateful DOTS transport option is selected), 208 etc. Registration of well-known ports for DOTS transports per 209 [RFC6335] should be considered in light of these challenges. 211 It should also be noted that DOTS does not directly ameliorate the 212 various administrative challenges required for successful DDoS attack 213 mitigation. Letters of authorization, RADB updates, DNS zone 214 delegations, alteration of network access policies, technical 215 configurations required to facilitate network traffic diversion and 216 re-injection, etc., are all outside the scope of DOTS. DOTS may, 217 however, prove useful in automating the registration of DOTS clients 218 with DOTS servers, as well as in the automatic provisioning of 219 situationally- appropriate DDoS defenses and countermeasures. This 220 ancillary DOTS functionality is described in Section 3.2. 222 Many of the 'external' administrative challenges associated with 223 establishing workable DDoS attack mitigation service may be addressed 224 by work currently in progress in the I2RS and I2NSF WGs. Interested 225 parties may wish to consider tracking those efforts, and coordination 226 with both I2RS and I2NSF is highly desirable. 228 Note that all the use-cases in this document are universal in nature. 229 They apply equally to endpoint networks, transit backbone providers, 230 cloud providers, broadband access providers, ASPs, CDNs, etc. They 231 are not specific to particular business models, topological models, 232 or application types, and are deliberately generalizable. Both 233 networks targeted for attack as well as any adjacent or topologically 234 distant networks involved in a given scenario may be either single- 235 or multi-homed. In the accompanying vector illustrations 236 incorporated into draft-ietf-dots-use-cases-01.pdf, specific business 237 and topological models are described in order to provide context. 239 Likewise, both DOTS itself and the use cases described in this 240 document are completely independent of technologies utilized for the 241 detection, classification, traceback, and mitigation of DDoS attacks. 242 Flow telemetry such as NetFlow and IPFIX, direct full-packet 243 analysis, log-file analysis, indirection manual observation, etc. can 244 and will be enablers for detection, classification and traceback. 245 Intelligent DDoS mitigation systems (IDMSes), flowspec, S/RTBH, ACLs, 246 and other network traffic manipulation tools and techniques may be 247 used for DDoS attack mitigation. BGP, flowspec, DNS, inline 248 deployment, and various 'NFV' technologies may be used for network 249 traffic diversion into mitigation centers or devices in applicable 250 scenarios; GRE, MPLS, 'NFV', inline deployment and other techniques 251 may be utilized for 'cleaned' traffic re-injection to its intended 252 destination. 254 The scope, format, and content of all DOTS message types cited in 255 this document must be codified by the DOTS WG. 257 The following use cases are intended to inform the DOTS requirements 258 described in [I-D.ietf-dots-requirements]. 260 3.1. Primary Use Cases 262 3.1.1. Automatic or Operator-Assisted CPE or PE Mitigators Request 263 Upstream DDoS Mitigation Services 265 One or more CPE or PE mitigators with DOTS client capabilities may be 266 configured to signal to one or more DOTS servers in order to request 267 upstream DDoS mitigation service initiation during an attack when 268 DDoS attack volumes and/or attack characteristics exceed the 269 capabilities of such CPE mitigators. DDoS mitigation service may be 270 terminated either automatically or manually via a DOTS mitigation 271 service termination request initiated by the mitigator when it has 272 been determined that the DDoS attack has ended. 274 (a) A DDoS attack is initiated against online properties of an 275 organization which has deployed DOTS-client-capable DDoS 276 mitigators. 278 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 279 the DDoS attack. 281 (c) CPE or PE DDoS mitigators determine that their capacity and/or 282 capability to mitigate the DDoS attack is insufficient, and 283 utilize their DOTS client functionality to send a DOTS 284 mitigation service initiation request to one or more DOTS 285 servers residing on one or more upstream transit networks, peer 286 networks, or overlay MSSP networks. This DOTS mitigation 287 service initiation request may be automatically initiated by the 288 CPE or PE DDoS mitigators, or may be manually triggered by 289 personnel of the requesting organization in response to an alert 290 from the mitigators (the mechanism by which this process takes 291 place is beyond the scope of this document). 293 (d) The DOTS servers which receive the DOTS mitigation service 294 initiation requests determine that they have been configured to 295 honor requests from the requesting CPE or PE mitigators, and 296 initiate situationally-appropriate DDoS mitigation service on 297 their respective networks (the mechanism by which this process 298 takes place is beyond the scope of this document). 300 (e) The DOTS servers transmit a DOTS service status message to the 301 requesting CPE or PE mitigators indicating that upstream DDoS 302 mitigation service has been initiated. 304 (f) While DDoS mitigation services are active, the DOTS servers 305 regularly transmit DOTS mitigation status updates to the 306 requesting CPE or PE mitigators. 308 (g) While DDoS mitigation services are active, the CPE or PE 309 mitigators may optionally regularly transmit DOTS mitigation 310 efficacy updates to the relevant DOTS servers. 312 (h) When the upstream DDoS mitigators determine that the DDoS attack 313 has ceased, they indicate this change in status to their 314 respective DOTS servers (the mechanism by which this process 315 takes place is beyond the scope of this document). 317 (i) The DOTS servers transmit a DOTS mitigation status update to the 318 CPE or PE mitigators indicating that the DDoS attack has ceased. 320 (j) The CPE or PE DDoS mitigators transmit a DOTS mitigation service 321 termination request to the DOTS servers. This DOTS mitigation 322 service termination request may be automatically initiated by 323 the CPE or PE DDoS mitigators, or may be manually triggered by 324 personnel of the requesting organization in response to an alert 325 from the mitigators or a management system which monitors them 326 (the mechanism by which this process takes place is beyond the 327 scope of this document). 329 (k) The DOTS servers terminate DDoS mitigation service on their 330 respective networks (the mechanism by which this process takes 331 place is beyond the scope of this document). 333 (l) The DOTS servers transmit a DOTS mitigation status update to the 334 CPE or PE mitigators indicating that DDoS mitigation services 335 have been terminated. 337 (m) The CPE or PE DDoS mitigators transmit a DOTS mitigation 338 termination status acknowledgement to the DOTS servers. 340 3.1.2. Automatic or Operator-Assisted CPE or PE Network Infrastructure 341 Element Request to Upstream Mitigator 343 CPE or PE network infrastructure elements such as routers, switches, 344 load-balancers, firewalls, 'IPSes', etc. which have the capability to 345 detect and classify DDoS attacks and which have DOTS client 346 capabilities may be configured to signal to one or more DOTS servers 347 in order to request upstream DDoS mitigation service initiation 348 during an attack. DDoS mitigation service may be terminated either 349 automatically or manually via a DOTS mitigation service termination 350 request initiated by the network element when it has been determined 351 that the DDoS attack has ended. 353 In this use-case, the network elements involved are not engaged in 354 mitigating DDoS attack traffic. They are signaling for upstream 355 attack mitigation assistance. This can be an inter- or intra- domain 356 use-case. 358 (a) A DDoS attack is initiated against online properties of an 359 organization with DOTS-client-capable network infrastructure 360 elements deployed. 362 (b) The network infrastructure elements utilize their DOTS client 363 functionality to send a DOTS mitigation service initiation 364 request to one or more DOTS servers residing on one or more 365 upstream transit networks, peer networks, or overlay MSSP 366 networks, either directly or via intermediate DOTS relays 367 residing upon the requesting organization's network, the 368 upstream mitigation provider's network, or both. The scope, 369 format, and content of these messages must be codified by the 370 DOTS WG. This DOTS mitigation service initiation request may be 371 automatically initiated by the network infrastructure elements, 372 or may be manually triggered by personnel of the requesting 373 organization in response to an alert from the network elements 374 or a management system which monitors them (the mechanism by 375 which this process takes place is beyond the scope of this 376 document). 378 (c) The DOTS servers which receive the DOTS mitigation service 379 initiation requests determine that they have been configured to 380 honor requests from the requesting network infrastructure 381 elements, and initiate situationally-appropriate DDoS mitigation 382 service on their respective networks (the mechanism by which 383 this process takes place is beyond the scope of this document). 385 (d) The DOTS servers transmit a DOTS service status message to the 386 requesting network infrastructure elements indicating that 387 upstream DDoS mitigation service has been initiated. 389 (e) While DDoS mitigation services are active, the DOTS servers 390 regularly transmit DOTS mitigation status updates to the 391 requesting requesting network infrastructure elements. 393 (f) While DDoS mitigation services are active, the network 394 infrastructure elements may optionally regularly transmit DOTS 395 mitigation efficacy updates to the relevant DOTS servers. 397 (g) When the upstream DDoS mitigators determine that the DDoS attack 398 has ceased, they indicate this change in status to their 399 respective DOTS servers (the mechanism by which this process 400 takes place is beyond the scope of this document). 402 (h) The DOTS servers transmit a DOTS mitigation status update to the 403 network infrastructure elements indicating that the DDoS attack 404 has ceased. 406 (i) The network infrastructure elements transmit a DOTS mitigation 407 service termination request to the DOTS servers. This DOTS 408 mitigation service termination request may be automatically 409 initiated by the network infrastructure elements, or may be 410 manually triggered by personnel of the requesting organization 411 in response to an alert from the mitigators (the mechanism by 412 which this process takes place is beyond the scope of this 413 document). 415 (j) The DOTS servers terminate DDoS mitigation service on their 416 respective networks (the mechanism by which this process takes 417 place is beyond the scope of this document). 419 (k) The DOTS servers transmit a DOTS mitigation status update to the 420 network infrastructure elements indicating that DDoS mitigation 421 services have been terminated. 423 (l) The network infrastructure elements transmit a DOTS mitigation 424 termination status acknowledgement to the DOTS servers. 426 3.1.3. Automatic or Operator-Assisted CPE or PE Attack Telemetry 427 Detection/Classification System Request to Upstream Mitigator 429 CPE or PE Attack Telemetry Detection/Classification Systems which 430 have DOTS client capabilities may be configured so that upon 431 detecting and classifying a DDoS attack, they signal one or more DOTS 432 servers in order to request upstream DDoS mitigation service 433 initiation. DDoS mitigation service may be terminated either 434 automatically or manually via a DOTS mitigation service termination 435 request initiated by the Attack Telemetry Detection/Classification 436 System when it has been determined that the DDoS attack has ended. 438 In this use-case, the Attack Telemetry Detection/Classification does 439 not possess any inherent capability to mitigate DDoS attack traffic, 440 and is signaling for upstream mitigation assistance. This can be an 441 inter- or intra-domain use-case. 443 (a) A DDoS attack is initiated against online properties of an 444 organization with DOTS-client-capable CPE or PE Attack Telemetry 445 Detection/Classification Systems deployed. 447 (b) The CPE or PE Attack Telemetry Detection/Classification Systems 448 utilize their DOTS client functionality to send a DOTS 449 mitigation service initiation request to one or more DOTS 450 servers residing on one or more upstream transit networks, peer 451 networks, or overlay MSSP networks, either directly or via 452 intermediate DOTS relays residing upon the requesting 453 organization's network, the upstream mitigation provider's 454 network, or both. This DOTS mitigation service initiation 455 request may be automatically initiated by the CPE or PE Attack 456 Telemetry Detection/Classification Systems, or may be manually 457 triggered by personnel of the requesting organization in 458 response to an alert from the CPE or PE Attack Telemetry 459 Detection/Classification Systems (the mechanism by which this 460 process takes place is beyond the scope of this document). 462 (c) The DOTS servers which receive the DOTS mitigation service 463 initiation requests determine that they have been configured to 464 honor requests from the requesting CPE or PE Attack Telemetry 465 Detection/Classification Systems, and initiate situationally- 466 appropriate DDoS mitigation service on their respective networks 467 (the mechanism by which this process takes place is beyond the 468 scope of this document). 470 (d) The DOTS servers transmit a DOTS service status message to the 471 requesting CPE or PE Attack Telemetry Detection/Classification 472 Systems indicating that upstream DDoS mitigation service has 473 been initiated. 475 (e) While DDoS mitigation services are active, the DOTS servers 476 regularly transmit DOTS mitigation status updates to the 477 requesting CPE or PE Attack Telemetry Detection/Classification 478 Systems. 480 (f) While DDoS mitigation services are active, the CPE or PE Attack 481 Telemetry Detection/Classification Systems may optionally 482 regularly transmit DOTS mitigation efficacy updates to the 483 relevant DOTS servers. 485 (g) When the upstream DDoS mitigators determine that the DDoS attack 486 has ceased, they indicate this change in status to their 487 respective DOTS servers (the mechanism by which this process 488 takes place is beyond the scope of this document). 490 (h) The DOTS servers transmit a DOTS mitigation status update to the 491 CPE or PE Attack Telemetry Detection/Classification Systems 492 indicating that the DDoS attack has ceased. 494 (i) The CPE or PE Attack Telemetry Detection/Classification Systems 495 transmit a DOTS mitigation service termination request to the 496 DOTS servers. This DOTS mitigation service termination request 497 may be automatically initiated by the CPE or PE Attack Telemetry 498 Detection/Classification Systems, or may be manually triggered 499 by personnel of the requesting organization in response to an 500 alert from the CPE or PE Attack Telemetry Detection/ 501 Classification Systems (the mechanism by which this process 502 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. 512 (l) The CPE or PE Attack Telemetry Detection/Classification Systems 513 transmit a DOTS mitigation termination status acknowledgement to 514 the DOTS servers. 516 3.1.4. Automatic or Operator-Assisted Targeted Service/ Application 517 Request to Upstream Mitigator 519 A service or application which is the target of a DDoS attack and 520 which has the capability to detect and classify DDoS attacks (i.e, 521 Apache mod_security [APACHE], BIND RRL [RRL], etc.) as well as DOTS 522 client functionality may be configured so that upon detecting and 523 classifying a DDoS attack, it signals one or more DOTS servers in 524 order to request upstream DDoS mitigation service initiation. DDoS 525 mitigation service may be terminated either automatically or manually 526 via a DOTS mitigation service termination request initiated by the 527 service/application when it has been determined that the DDoS attack 528 has ended. 530 In this use-case, the service/application does not possess inherent 531 DDoS attack mitigation capabilities, and is signaling for upstream 532 mitigation assistance. This can be an inter- or intra-domain use- 533 case. 535 (a) A DDoS attack is initiated against online properties of an 536 organization which include DOTS-client-capable services or 537 applications that are the specific target(s) of the attack. 539 (b) The targeted services or applications utilize their DOTS client 540 functionality to send a DOTS mitigation service initiation 541 request to one or more DOTS servers residing on the same network 542 as the services or applications, one or more upstream transit 543 networks, peer networks, or overlay MSSP networks, either 544 directly or via intermediate DOTS relays residing upon the 545 requesting organization's network, the upstream mitigation 546 provider's network, or both. This DOTS mitigation service 547 initiation request may be automatically initiated by the 548 targeted services or applications, or may be manually triggered 549 by personnel of the requesting organization in response to an 550 alert from the targeted services or applications or a system 551 which monitors them (the mechanism by which this process takes 552 place is beyond the scope of this document). 554 (c) The DOTS servers which receive the DOTS mitigation service 555 initiation requests determine that they have been provisioned to 556 honor requests from the requesting services or applications, and 557 initiate situationally-appropriate DDoS mitigation service on 558 their respective networks (the mechanism by which this process 559 takes place is beyond the scope of this document). 561 (d) The DOTS servers transmit a DOTS service status message to the 562 services or applications indicating that upstream DDoS 563 mitigation service has been initiated 565 (e) While DDoS mitigation services are active, the DOTS servers 566 regularly transmit DOTS mitigation status updates to the 567 requesting services or applications. 569 (f) While DDoS mitigation services are active, the requesting 570 services or applications may optionally regularly transmit DOTS 571 mitigation efficacy updates to the relevant DOTS servers. 573 (g) When the upstream DDoS mitigators determine that the DDoS attack 574 has ceased, they indicate this change in status to their 575 respective DOTS servers (the mechanism by which this process 576 takes place is beyond the scope of this document). 578 (h) The DOTS servers transmit a DOTS mitigation status update to the 579 requesting services or applications indicating that the DDoS 580 attack has ceased. 582 (i) The targeted services or applications transmit a DOTS mitigation 583 service termination request to the DOTS servers. This DOTS 584 mitigation service termination request may be automatically 585 initiated by the targeted services or applications, or may be 586 manually triggered by personnel of the requesting organization 587 in response to an alert from a system which monitors them (the 588 mechanism by which this process takes place is beyond the scope 589 of this document). 591 (j) The DOTS servers terminate DDoS mitigation service on their 592 respective networks (the mechanism by which this process takes 593 place is beyond the scope of this document). 595 (k) The DOTS servers transmit a DOTS mitigation status update to the 596 targeted services or applications indicating that DDoS 597 mitigation services have been terminated. 599 (l) The targeted services or applications transmit a DOTS mitigation 600 termination status acknowledgement to the DOTS servers. 602 3.1.5. Manual Web Portal Request to Upstream Mitigator 604 A Web portal which has DOTS client capabilities has been configured 605 in order to allow authorized personnel of organizations which are 606 targeted by DDoS attacks to manually request upstream DDoS mitigation 607 service initiation from a DOTS server. When an organization has 608 reason to believe that it is under active attack, authorized 609 personnel may utilize the Web portal to manually initiate a DOTS 610 client mitigation request to one or more DOTS servers. DDoS 611 mitigation service may be terminated manually via a DOTS mitigation 612 service termination request through the Web portal when it has been 613 determined that the DDoS attack has ended. 615 In this use-case, the organization targeted for attack does not 616 possess any automated or operator-assisted mechanisms for DDoS attack 617 detection, classification, traceback, or mitigation; the existence of 618 an attack has been inferred manually, and the organization is 619 requesting upstream mitigation assistance. This can theoretically be 620 an inter- or intra-domain use-case, but is more typically an inter- 621 domain scenario. 623 (a) A DDoS attack is initiated against online properties of an 624 organization have access to a Web portal which incorporates DOTS 625 client functionality and can generate DOTS mitigation service 626 requests upon demand. 628 (b) Authorized personnel utilize the Web portal to send a DOTS 629 mitigation service initiation request to one or more upstream 630 transit networks, peer networks, or overlay MSSP networks, 631 either directly or via intermediate DOTS relays residing upon 632 the requesting organization's network, the upstream mitigation 633 provider's network, or both. This DOTS mitigation service 634 initiation request is manually triggered by personnel of the 635 requesting organization when it is judged that the organization 636 is under DDoS attack (the mechanism by which this process takes 637 place is beyond the scope of this document). 639 (c) The DOTS servers which receive the DOTS mitigation service 640 initiation requests determine that they have been provisioned to 641 honor requests from the Web portal, and initiate situationally- 642 appropriate DDoS mitigation service on their respective networks 643 (the mechanism by which this process takes place is beyond the 644 scope of this document). 646 (d) The DOTS servers transmit a DOTS service status message to the 647 Web portal indicating that upstream DDoS mitigation service has 648 been initiated. 650 (e) While DDoS mitigation services are active, the DOTS servers 651 regularly transmit DOTS mitigation status updates to the Web 652 portal. 654 (f) While DDoS mitigation services are active, the Web portal may 655 optionally regularly transmit manually-triggered DOTS mitigation 656 efficacy updates to the relevant DOTS servers. 658 (g) When the upstream DDoS mitigators determine that the DDoS attack 659 has ceased, they indicate this change in status to their 660 respective DOTS servers (the mechanism by which this process 661 takes place is beyond the scope of this document). 663 (h) The DOTS servers transmit a DOTS mitigation status update to the 664 Web portal indicating that the DDoS attack has ceased. 666 (i) The Web portal transmits a manually-triggered DOTS mitigation 667 service termination request to the DOTS servers (the mechanism 668 by which this process takes place is beyond the scope of this 669 document). 671 (j) The Web portal transmits a manually-triggered DOTS mitigation 672 service termination request to the DOTS servers (the mechanism 673 by which this process takes place is beyond the scope of this 674 document). 676 (k) The DOTS servers transmit a DOTS mitigation status update to the 677 Web portal indicating that DDoS mitigation services have been 678 terminated. 680 (l) The Web portal transmits a DOTS mitigation termination status 681 acknowledgement to the DOTS servers. 683 3.1.6. Manual Mobile Device Application Request to Upstream Mitigator 685 An application for mobile devices such as smartphones and tablets 686 which incorporates DOTS client capabilities has been made available 687 to authorized personnel of an organization. When the organization 688 has reason to believe that it is under active DDoS attack, authorized 689 personnel may utilize the mobile device application to manually 690 initiate a DOTS client mitigation request to one or more DOTS servers 691 in order to initiate upstream DDoS mitigation services. DDoS 692 mitigation service may be terminated manually via a DOTS mitigation 693 service termination request initiated through the mobile device 694 application when it has been determined that the DDoS attack has 695 ended. 697 This use-case is similar to the one described in Section 3.1.5; the 698 difference is that a mobile application provided by the DDoS 699 mitigation service provider is used to request upstream attack 700 mitigation assistance. This can theoretically be an inter- or intra- 701 domain use-case, but is more typically an inter-domain scenario. 703 (a) A DDoS attack is initiated against online properties of an 704 organization have access to a Web portal which incorporates DOTS 705 client functionality and can generate DOTS mitigation service 706 requests upon demand. 708 (b) Authorized personnel utilize the mobile application to send a 709 DOTS mitigation service initiation request to one or more DOTS 710 servers residing on the same network as the targeted Internet 711 properties, one or more upstream transit networks, peer 712 networks, or overlay MSSP networks, either directly or via 713 intermediate DOTS relays residing upon the requesting 714 organization's network, the upstream mitigation provider's 715 network, or both. This DOTS mitigation service initiation 716 request is manually triggered by personnel of the requesting 717 organization when it is judged that the organization is under 718 DDoS attack (the mechanism by which this process takes place is 719 beyond the scope of this document). 721 (c) The DOTS servers which receive the DOTS mitigation service 722 initiation requests determine that they have been provisioned to 723 honor requests from the mobile application, and initiate 724 situationally-appropriate DDoS mitigation service on their 725 respective networks (the mechanism by which this process takes 726 place is beyond the scope of this document). 728 (d) The DOTS servers transmit a DOTS service status message to the 729 mobile application indicating that upstream DDoS mitigation 730 service has been initiated. 732 (e) While DDoS mitigation services are active, the DOTS servers 733 regularly transmit DOTS mitigation status updates to the mobile 734 application. 736 (f) While DDoS mitigation services are active, the mobile 737 application may optionally regularly transmit manually-triggered 738 DOTS mitigation efficacy updates to the relevant DOTS servers. 740 (g) When the upstream DDoS mitigators determine that the DDoS attack 741 has ceased, they indicate this change in status to their 742 respective DOTS servers (the mechanism by which this process 743 takes place is beyond the scope of this document). 745 (h) The DOTS servers transmit a DOTS mitigation status update to the 746 mobile application indicating that the DDoS attack has ceased. 748 (i) The mobile application transmits a manually-triggered DOTS 749 mitigation service termination request to the DOTS servers (the 750 mechanism by which this process takes place is beyond the scope 751 of this document). 753 (j) The DOTS servers terminate DDoS mitigation service on their 754 respective networks (the mechanism by which this process takes 755 place is beyond the scope of this document). 757 (k) The DOTS servers transmit a DOTS mitigation status update to the 758 mobile application indicating that DDoS mitigation services have 759 been terminated. 761 (l) The mobile application transmits a DOTS mitigation termination 762 status acknowledgement to the DOTS servers. 764 3.1.7. Unsuccessful Automatic or Operator-Assisted CPE or PE Mitigators 765 Request Upstream DDoS Mitigation Services 767 One or more CPE or PE mitigators with DOTS client capabilities may be 768 configured to signal to one or more DOTS servers in order to request 769 upstream DDoS mitigation service initiation during an attack when 770 DDoS attack volumes and/or attack characteristics exceed the 771 capabilities of such CPE mitigators. DDoS mitigation service may be 772 terminated either automatically or manually via a DOTS mitigation 773 service termination request initiated by the mitigator when it has 774 been determined that the DDoS attack has ended. 776 This can theoretically be an inter- or intra-domain use-case, but is 777 more typically an inter-domain scenario. 779 (a) A DDoS attack is initiated against online properties of an 780 organization which has deployed DOTS-client-capable DDoS 781 mitigators. 783 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating 784 the DDoS attack. 786 (c) CPE or PE DDoS mitigators determine that their capacity and/or 787 capability to mitigate the DDoS attack is insufficient, and 788 utilize their DOTS client functionality to send a DOTS 789 mitigation service initiation request to one or more DOTS 790 servers residing on one or more upstream transit networks, peer 791 networks, or overlay MSSP networks. This DOTS mitigation 792 service initiation request may be automatically initiated by the 793 CPE or PE DDoS mitigators, or may be manually triggered by 794 personnel of the requesting organization in response to an alert 795 from the mitigators (the mechanism by which this process takes 796 place is beyond the scope of this document). 798 (d) The DOTS servers which receive the DOTS mitigation service 799 initiation requests determine that they have been configured to 800 honor requests from the requesting CPE or PE mitigators, and 801 attempt to initiate situationally-appropriate DDoS mitigation 802 service on their respective networks (the mechanism by which 803 this process takes place is beyond the scope of this document). 805 (e) The DDoS mitigators on the upstream network report back to the 806 DOTS servers that they are unable to initiate DDoS mitigation 807 service for the requesting organization due to mitigation 808 capacity constraints, bandwidth constraints, functionality 809 constraints, hardware casualties, or other impediments (the 810 mechanism by which this process takes place is beyond the scope 811 of this document). 813 (f) The DOTS servers transmit a DOTS service status message to the 814 requesting CPE or PE mitigators indicating that upstream DDoS 815 mitigation service cannot be initiated as requested. 817 (g) The CPE or PE mitigators may optionally regularly re-transmit 818 DOTS mitigation status request messages to the relevant DOTS 819 servers until acknowledgement that mitigation services have been 820 initiated. 822 (h) The CPE or PE mitigators may optionally transmit a DOTS 823 mitigation service initiation request to DOTS servers associated 824 with a configured fallback upstream DDoS mitigation service. 825 Multiple fallback DDoS mitigation services may optionally be 826 configured. 828 (i) The process describe above cyclically continues until the DDoS 829 mitigation service request is fulfilled; the CPE or PE 830 mitigators determine that the DDoS attack volume has decreased 831 to a level and/or complexity which they themselves can 832 successfully mitigate; the DDoS attack has ceased; or manual 833 intervention by personnel of the requesting organization has 834 taken place. 836 3.2. Ancillary Use Cases 838 3.2.1. Auto-registration of DOTS clients with DOTS servers 840 An additional benefit of DOTS is that by utilizing agreed-upon 841 authentication mechanisms, DOTS clients can automatically register 842 for DDoS mitigation service with one or more upstream DOTS servers. 843 The details of such registration are beyond the scope of this 844 document. 846 3.2.2. Auto-provisioning of DDoS countermeasures 848 The largely manual tasks associated with provisioning effective, 849 situationally-appropriate DDoS countermeasures is a significant 850 barrier to providing/obtaining DDoS mitigation services for both 851 mitigation providers and mitigation recipients. Due to the 'self- 852 descriptive' nature of DOTS registration messages and mitigation 853 requests, the implementation and deployment of DOTS has the potential 854 to automate countermeasure selection and configuration for DDoS 855 mitigators. The details of such provisioning are beyond the scope of 856 this document. 858 This can theoretically be an inter- or intra-domain use-case, but is 859 more typically an inter-domain scenario. 861 3.2.3. Informational DDoS attack notification to interested and 862 authorized third parties 864 In addition to its primary role of providing a standardized, 865 programmatic approach to the automated and/or operator-assisted 866 request of DDoS mitigation services and providing status updates of 867 those mitigations to requesters, DOTS may be utilized to notify 868 security researchers, law enforcement agencies, regulatory bodies, 869 etc. of DDoS attacks against attack targets, assuming that 870 organizations making use of DOTS choose to share such third-party 871 notifications, in keeping with all applicable laws, regulations, 872 privacy and confidentiality considerations, and contractual 873 agreements between DOTS users and said third parties. 875 This is an inter-domain scenario. 877 4. Security Considerations 879 DOTS is at risk from three primary attacks: DOTS agent impersonation, 880 traffic injection, and signaling blocking. The DOTS protocol MUST be 881 designed for minimal data transfer to address the blocking risk. 883 Impersonation and traffic injection mitigation can be managed through 884 current secure communications best practices. DOTS is not subject to 885 anything new in this area. One consideration could be to minimize 886 the security technologies in use at any one time. The more needed, 887 the greater the risk of failures coming from assumptions on one 888 technology providing protection that it does not in the presence of 889 another technology. 891 Additional details of DOTS security requirements may be found in 892 [I-D.ietf-dots-requirements]. 894 5. IANA Considerations 896 No IANA considerations exist for this document at this time. 898 6. Acknowledgments 900 TBD 902 7. References 904 7.1. Normative References 906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 907 Requirement Levels", BCP 14, RFC 2119, 908 DOI 10.17487/RFC2119, March 1997, 909 . 911 7.2. Informative References 913 [APACHE] "Apache mod_security", . 915 [I-D.ietf-dots-requirements] 916 Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open 917 Threat Signaling Requirements", draft-ietf-dots- 918 requirements-00 (work in progress), October 2015. 920 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 921 Cheshire, "Internet Assigned Numbers Authority (IANA) 922 Procedures for the Management of the Service Name and 923 Transport Protocol Port Number Registry", BCP 165, 924 RFC 6335, DOI 10.17487/RFC6335, August 2011, 925 . 927 [RRL] "BIND RRL", . 931 Authors' Addresses 933 Roland Dobbins (editor) 934 Arbor Networks 935 30 Raffles Place 936 Level 17 Chevron House 937 Singapore 048622 938 Singapore 940 Email: rdobbins@arbor.net 942 Stefan Fouant 943 Corero Network Security 945 Email: Stefan.Fouant@corero.com 946 Daniel Migault 947 Ericsson 948 8400 boulevard Decarie 949 Montreal, QC H4P 2N2 950 Canada 952 Phone: +1 514-452-2160 953 Email: daniel.migault@ericsson.com 955 Robert Moskowitz 956 HTT Consulting 957 Oak Park, MI 48237 958 USA 960 Email: rgm@labs.htt-consult.com 962 Nik Teague 963 Verisign Inc 964 12061 Bluemont Way 965 Reston, VA 20190 966 USA 968 Phone: +44 791 763 5384 969 Email: nteague@verisign.com 971 Liang Xia 972 Huawei 973 No. 101, Software Avenue, Yuhuatai District 974 Nanjing 975 China 977 Email: Frank.xialiang@huawei.com