idnits 2.17.1 draft-ietf-dots-use-cases-09.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 13, 2017) is 2346 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6335' is defined on line 1025, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS R. Dobbins 3 Internet-Draft Arbor Networks 4 Intended status: Informational D. Migault 5 Expires: May 17, 2018 Ericsson 6 S. Fouant 8 R. Moskowitz 9 HTT Consulting 10 N. Teague 11 Verisign 12 L. Xia 13 Huawei 14 K. Nishizuka 15 NTT Communications 16 November 13, 2017 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-09 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 24 protocol to facilitate interoperability between multivendor DDoS 25 mitigation solutions and services. This document presents use cases 26 which describe the interactions expected between the DOTS components 27 as well as DOTS messaging exchanges. The purpose of describing use 28 cases is to identify the interacting DOTS components, how they 29 collaborate and what are the types of information to be exchanged. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 17, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 68 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . 4 70 3.1.1. Upstream Transit Providers Offering DDoS Mitigation 71 Services . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.2. Overlay MSSPs Offering DDoS Mitigation Services . . . 10 73 3.1.3. Examples of DOTS clients integrated with 74 applications, services, and network infrastructure 75 devices . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . 13 77 3.2.1. Suppression of outbound DDoS traffic originating from 78 a consumer broadband access network . . . . . . . . . 14 79 3.2.2. Home Network DDoS Detection Collaboration for ISP 80 network management . . . . . . . . . . . . . . . . . 16 81 3.2.3. DDoS Orchestration . . . . . . . . . . . . . . . . . 19 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 87 7.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 Currently, distributed denial-of-service (DDoS) attack mitigation 93 solutions are largely based upon siloed, proprietary communications 94 schemes which result in vendor lock-in. As a side-effect, this makes 95 the configuration, provisioning, operation, and activation of these 96 solutions a highly manual and often time-consuming process. 97 Additionally, coordination of multiple DDoS mitigation solutions 98 simultaneously engaged in defending the same organization (resources) 99 against DDoS attacks is fraught with both technical and process- 100 related hurdles. This greatly increase operational complexity and 101 often results in suboptimal DDoS attack mitigation efficacy. 103 The DDoS Open Threat Signaling (DOTS) effort is intended to specify a 104 protocol that facilitates interoperability between multivendor DDoS 105 mitigation solutions and ensures more automation in term of 106 mitigation requests and attack characterization patterns. As DDoS 107 solutions are broadly heterogeneous among vendors, the primary goal 108 of DOTS is to provide high-level interaction amongst differeing DDoS 109 solutions, such as initiating or terminating DDoS mitigation 110 assistance. 112 It should be noted that DOTS is not intended toperform orchestration 113 functions; rather, DOTS is intended to allowdevices, services, and 114 applications to request DDoS attack mitigation assistance and receive 115 mitigation status updates. 117 These use cases are expected to provide inputs for the design of the 118 DOTS protocol(s). 120 2. Terminology and Acronyms 122 This document makes use of the terms defined in 123 [I-D.ietf-dots-requirements]. 125 In addition, this document introduces the following terms: 127 Inter-domain: a DOTS communications relationship between distinct 128 organizations with separate spans of administrative control. 129 Typical inter-domain DOTS communication relationships would be 130 between a DDoS mitigation service provider and an end-customer who 131 requires DDoS mitigation assistance; between multiple DDoS 132 mitigation service providers coordinating mutual defense of a 133 mutual end-customer; or between DDoS mitigation service providers 134 which are requesting additional DDoS mitigation assistance in for 135 attacks which exceed their inherent DDoS mitigation capacities 136 and/or capabilities. 138 Intra-domain: a DOTS communications relationship between various 139 (network) elements that are owned and operated by the same 140 administrative entity. A typical intra-domain DOTS communications 141 relationship would be between DOTS agents [I-D.ietf-dots- 142 requirements] within the same organization. 144 2.1. Requirements Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 3. Use Cases Scenarios 152 This section provides a high-level description of scenarios addressed 153 by DOTS. In both sub-sections, the scenarios are provided in order 154 to illustrate the use of DOTS in typical DDoS attack scenarios. They 155 are not definitive, and other use cases are expected to emerge with 156 widespread DOTS deployment. 158 All scenarios present a coordination between the targeted 159 organization, the DDoS attack telemetry and the mitigator. The 160 coordination and communication between these entities depends, for 161 example, on the characteristic or functionality of the entity itself, 162 the reliability of the information provided by DDoS attack telemetry, 163 and the business relationship between the DDoS target domain and the 164 mitigator. 166 More explicitly, in some cases, the DDoS attack telemetry may simply 167 activate a DDoS mitigation, whereas in other cases, it may 168 collaborate by providing some information about an attack. In some 169 cases, the DDoS mitigation may be orchestrated, which includes 170 selecting a specific appliance as well as starting/ending a 171 mitigation. 173 3.1. Inter-domain Use Cases 175 Inter-domain DOTS deployment scenarios encompass two or more distinct 176 spans of administrative control. A typical inter-domain DOTS 177 deployment may consist of an endpoint network such as an Internet- 178 connected enterprise requesting DDoS mitigation assistance from one 179 or more upstream transit providers offering DDoS mitigation services, 180 or from a topologically-distant MSSP offering cloud-based overlay 181 DDoS mitigation services. DOTS may also be used to facilitate 182 coordination of DDoS mitigation activities between mitigation 183 providers. 185 Coordination between organizations making use of DOTS in such 186 scenarios is necessary. Along with DOTS-specific tasks such as DOTS 187 peering and validating the exchange of DOTS messaging between the 188 relevant organizations, externalities relating to routing 189 advertisements, authoritative DNS records (for DNS-based diversion), 190 network access policies for DOTS nodes, service-level agreements 191 (SLAs), and DDoS mitigation provisioning are required. 193 3.1.1. Upstream Transit Providers Offering DDoS Mitigation Services 195 The use-cases in this section reflect scenarios in which the 196 immediate upstream transit network(s) offer DDoS mitigation services 197 to their end-customers. The DOTS communications models in these use- 198 cases are largely identical with that decribed in Section 3.1.1.1, 199 with the exceptions of Section 3.1.1.4 and Section 3.1.1.5. These 200 variations are mainly of interest from the operational point of view, 201 as they illustrate processes, procedures, and topological details 202 which are externalities from the standpoint of the DOTS ecosystem, 203 but which are of great importance for network operators and DDoS 204 mitigation service providers. 206 3.1.1.1. End-customer with a single upstream transit provider offering 207 DDoS mitigation services 209 In this scenario, an enterprise network with self-hosted Internet- 210 facing properties such as Web servers, authoritative DNS servers, and 211 VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed 212 to protect those servers and applications from DDoS attacks. In 213 addition to their on-premise DDoS defense capability, they have 214 contracted with their Internet transit provider for DDoS mitigation 215 services which threaten to overwhelm their transit link bandwidth. 217 The IDMS is configured such that if the incoming Internet traffic 218 volume exceeds 50% of the provisioned upstream Internet transit link 219 capacity, the IDMS will request DDoS mitigation assistance from the 220 upstream transit provider. 222 The requests to trigger, manage, and finalize a DDoS mitigation 223 between the enterprise IDMS and the transit provider is performed 224 using DOTS. The enterprise IDMS implements a DOTS client while the 225 transit provider implements a DOTS server which is integrated with 226 their DDoS mitigation orchestration system. 228 When the IDMS detects an inbound DDoS attack targeting the enterprise 229 servers and applications, it immediately begins mitigating the 230 attack. 232 During the course of the attack, the inbound traffic volume exceeds 233 the 50% threshold; the IDMS DOTS client signals the DOTS server on 234 the upstream transit provider network to initiate DDoS mitigation. 235 The DOTS server signals the DOTS client that it can service this 236 request, and mitigation is initiated on the transit provider network. 238 Over the course of the attack, the DOTS server on the transit 239 provider network periodically signals the DOTS client on the 240 enterprise IDMS in order to provide mitigation status information, 241 statistics related to DDoS attack traffic mitigation, and related 242 information. Once the DDoS attack has ended, the DOTS server signals 243 the enterprise IDMS DOTS client that the attack has subsided. 245 The enterprise IDMS then requests that DDoS mitigation services on 246 the upstream transit provider network be terminated. The DOTS server 247 on the transit provider network receives this request, communicates 248 with the transit provider orchestration system controlling its DDoS 249 mitigation system to terminate attack mitigation, and once the 250 mitigation has ended, confirms the end of upstream DDoS mitigation 251 service to the enterprise IDMS DOTS client. 253 Note that communications between the enterprise DOTS client and the 254 upstream transit provider DOTS server may take place in-band within 255 the main Internet transit link between the enterprise and the transit 256 provider; out-of-band via a separate, dedicated wireline network link 257 utilized solely for DOTS signaling; or out-of-band via some other 258 form of network connectivity such as a third-party wireless 4G 259 network link. 261 The following is an overview of the DOTS communication model for this 262 use-case: 264 (a) A DDoS attack is initiated against online properties of an 265 organization which has deployed a DOTS-client-capable IDMS. 267 (b) The IDMS detects, classifies, and begins mitigating the DDoS 268 attack. 270 (c) The IDMS determines that its capacity and/or capability to 271 mitigate the DDoS attack is insufficient, and utilize its DOTS client 272 functionality to send a DOTS mitigation service initiation request to 273 one or more DOTS servers residing on the upstream transit networks. 274 This DOTS mitigation service initiation request is automatically 275 initiated by the DOTS client. 277 (d) The DOTS servers which receive the DOTS mitigation service 278 initiation requests determine that they have been configured to honor 279 requests from the requesting DOTS client, and initiate situationally- 280 appropriate DDoS mitigation service. 282 (e) The DOTS servers transmit a DOTS service status message to the 283 DOTS client indicating that upstream DDoS mitigation service has been 284 initiated. 286 (f) While DDoS mitigation services are active, the DOTS servers 287 regularly transmit DOTS mitigation status updates to the DOTS client. 289 (g) While DDoS mitigation services are active, the DOTS client may 290 optionally regularly transmit DOTS mitigation efficacy updates to the 291 DOTS server. 293 (h) When the upstream DDoS mitigators determine that the DDoS attack 294 has ceased, they indicate this change in status to the DOTS server. 296 (i) The DOTS server transmist a DOTS mitigation status update to the 297 DOTS client indicating that the DDoS attack has ceased. 299 (j) The DOTS client transmits a DOTS mitigation service termination 300 request to the DOTS server. 302 (k) The DOTS server terminates DDoS mitigation service. 304 (l) The DOTS server transmis a DOTS mitigation status update to the 305 DOTS client indicating that DDoS mitigation services have been 306 terminated. 308 (m) The DOTS client transmits a DOTS mitigation termination status 309 acknowledgement to the DOTS servers. 311 3.1.1.2. End-customer with multiple upstream transit providers offering 312 DDoS mitigation services 314 This scenario shares many characteristics with Section 3.1.1.1, but 315 with the key difference that the enterprise in question is multi- 316 homed, i.e., has two or more upstream transit providers, and that 317 they all provide DDoS mitigation services. 319 In most cases, the communications model for a multi-homed model would 320 be the same as in the single-homed model, merely duplicated in 321 parallel. However, if two or more of the upstream transit providers 322 have entered into a mutual DDoS mitigation agreement and have 323 established DOTS peering relationships, DDoS mitigation status 324 messages may exchanged between their respective DOTS servers in order 325 to provide a more complete picture of the DDoS attack scope. This 326 will also allow for either automated or operator-assisted 327 programmatic cooperative DDoS mitigation activities on the part of 328 the DOTS-peered transit providers. 330 The addtional DOTS communications between the upstream transit 331 providers will consist of mitigation start, mitigation status, and 332 mitigation termination messages. 334 3.1.1.3. End-customer with multiple upstream transit providers, but 335 only a single upstream transit provider offering DDoS 336 mitigation services 338 This scenario is similar to that outlined in Section 3.1.1.2; 339 however, only one of the upstream transit providers in question 340 offers DDoS mitigation services. In this situation, the enterprise 341 would cease advertising the relevant network prefixes via the transit 342 providers which do not provide DDoS mitigation services - or, in the 343 case where the enterprise does not control its own routing, request 344 that the upstream transit providers which do not offer DDoS 345 mitigation services stop advertising the relevant network prefixes on 346 their behalf. 348 Once it has been determined that the DDoS attack has ceased, the 349 enterprise once again announces the relevant routes to the upstream 350 transit providers which do not offer DDoS mitigation services, or 351 requests that they resume announcing the relevant routes on behalf of 352 the enterprise. 354 Note that falling back to a single transit provider has the effect of 355 reducing available inbound transit bandwidth during a DDoS attack. 356 Without proper planning and sufficient provisioning of both the link 357 capacity and DDoS mitigation capacity of the sole transit provider 358 offering DDoS mitigation services, this reduction of available 359 bandwidth could lead to network link congestion caused by legitimate 360 inbound network traffic. Therefore, careful planning and 361 provisioning of both upstream transit bandwidth as well as DDoS 362 mitigation capacity is required in scenarios of this nature. 364 The withdrawal and announcement of routing prefixes described in this 365 use-case falls outside the scope of DOTS, although they could 366 conceivably be triggered as a result of provider-specific 367 orchestration triggered by the receipt of specific DOTS messages from 368 the enterprise in question. 370 3.1.1.4. End-customer with an upstream transit provider offering DDoS 371 mitigation services on an ongoing basis 373 This scenario is similar to that described in Section 3.1.1.1, except 374 that due to the lack of a capable local IDMS solution, strict uptime 375 requirements, or other considerations, the end-customer has 376 previously arranged for continuous active DDoS mitigation coverage; 377 thus, the concepts of initiating or terminating DDoS mitigation 378 services do not apply. 380 During an attack, the DOTS server on the upstream transit provider 381 network immediately notifies the DOTS client on the enterprise 382 network about the attack and periodically signals the DOTS client in 383 order to provide mitigation status information and related 384 information. The end-customer may then use this information to add 385 capacity or implement configuration changes intended to increase 386 resilience, to plan maintenance windows or changes to routing 387 policies, etc. 389 3.1.1.5. End-customer with an upstream transit provider offering DDoS 390 mitigation services, but DDoS mitigation service is refused 392 This scenario is similar to that described in Section 3.1.1.1, except 393 that the upstream transit provider is unable to honor the DDoS 394 mitigation service request from the end-customer due to mitigation 395 capacity limitations, technical faults, or other circumstances. The 396 end-customer DOTS client may be configured to make repeated attempts 397 to engage DDoS mitigation service from the refusing provider, or 398 alternately may be configured to request DDoS mitigation service from 399 alternate providers. 401 The following is an overview of the DOTS communication model for this 402 use-case: 404 (a) A DDoS attack is initiated against online properties of an 405 organization which has deployed a DOTS-client-capable IDMS. 407 (b) The IDMS detects, classifies, and begins mitigating the DDoS 408 attack. 410 (c) The IDMS determines that its capacity and/or capability to 411 mitigate the DDoS attack is insufficient, and utilizes its DOTS 412 client functionality to send a DOTS mitigation service initiation 413 request to a DOTS server residing on an upstream transit network. 415 (d) The DOTS servers which receives the DOTS mitigation service 416 initiation requests determines that it has been configured to honor 417 requests from the requesting DOTS client, and attempts to initiate 418 situationally-appropriate DDoS mitigation service. 420 (e) The DDoS mitigators on the upstream network report back to the 421 DOTS server that they are unable to initiate DDoS mitigation service 422 for the requesting organization due to mitigation capacity 423 constraints, bandwidth constraints, functionality constraints, 424 hardware casualties, or other impediments. 426 (f) The DOTS servers transmits a DOTS service status message to the 427 DOTS client indicating that upstream DDoS mitigation service cannot 428 be initiated as requested. 430 (g) The DOTS client may optionally regularly re-transmit DOTS 431 mitigation status request messages to the DOTS server until receiving 432 acknowledgement that DDos mitigation services have been initiated. 434 (h) The DOTS client may optionally transmit a DOTS mitigation service 435 initiation request to a DOTS server associated with a configured 436 fallback upstream DDoS mitigation service. Multiple fallback DDoS 437 mitigation services may optionally be configured. 439 (i) The process describe above cyclically continues until the DDoS 440 mitigation service request is fulfilled; the DOTS client determines 441 that the DDoS attack volume has decreased to a level and/or 442 complexity which it can successfully mitigate; the DDoS attack has 443 ceased; or manual intervention by personnel of the requesting 444 organization has taken place. 446 3.1.2. Overlay MSSPs Offering DDoS Mitigation Services 448 The use-cases in this section reflect scenarios in which 449 topologically-distant managed security service providers (MSSPs) 450 offer DDoS mitigation services to end-customers. The DOTS 451 communications models in these use-cases are largely identical with 452 that decribed in Section 3.1.1.1. These variations are mainly of 453 interest from the operational point of view, as they illustrate 454 processes, procedures, and topological details which are 455 externalities from the standpoint of the DOTS ecosystem, but which 456 are of great importance for network operators and DDoS mitigation 457 service providers. 459 3.1.2.1. End-customer with an overlay DDoS mitigation managed security 460 service provider (MSSP) 462 This use case details an enterprise that has a local DDoS detection 463 and classification capability and may or may not have an on-premise 464 mitigation capability. The enterprise is contracted with an overlay 465 DDoS mitigation MSSP, topologically distant from the enterprise 466 network (i.e., not a direct upstream transit provider), which can 467 redirect (divert) traffic away from the enterprise, provide DDoS 468 mitigation services services, and then forward (re-inject) legitimate 469 traffic to the enterprise on an on-demand basis. In this scenario, 470 diversion of Internet traffic destined for the enterprise network 471 into the overlay DDoS mitigation MSSP network is typically 472 accomplished via eBGP announcements of the relevant enterprise 473 network CIDR blocks, or via authoritative DNS subdomain-based 474 mechanisms (other mechanisms are not precluded, these are merely the 475 most common ones in use today). 477 The enterprise determines thresholds at which a request for 478 mitigation is triggered indicating to the MSSP that inbound network 479 traffic should be diverted into the MSSP network and that DDoS 480 mitigation should be initiated. The enterprise may also elect to 481 manually request diversion and mitigation via the MSSP network as 482 desired. 484 The communications required to initiate, manage, and terminate active 485 DDoS mitigation by the MSSP is performed using DOTS. The enterprise 486 DDoS detection/classification system implements a DOTS client, while 487 the MSSP implements a DOTS server integrated with its DDoS mitigation 488 orchestration system. One or more out-of-band methods for initiating 489 a mitigation request, such as a Web portal, a smartphone app, or 490 voice support hotline, may also be made available by the MSSP. 492 When an attack is detected, an automated or manual DOTS mitigation 493 request is generated by the enterprise and sent to the MSSP. The 494 enterprise DOTS mitigation request is processed by the MSSP DOTS 495 server, which validates the origin of the request and passes it to 496 the MSSP DDoS mitigation orchestration system, which then initiates 497 active DDoS mitigation. This action will usually involve the 498 diversion of all network traffic destined for the targeted enterprise 499 into the MSSP DDoS mitigation network, where it will be subjected to 500 further scrutiny, with DDoS attack traffic filtered by the MSSP. 501 Successful mitigation of the DDoS attack will not only result 502 preserving the availability of services and applications resident on 503 the enterprise network, but will also prevent DDoS attack traffic 504 from ingressing the networks of the enterprise upstream transit 505 providers and/or peers. 507 The MSSP should signal via DOTS to the enterprise that a mitigation 508 request has been received and acted upon, and should also include an 509 update of the mitigation status. The MSSP may respond periodically 510 with additional updates on the mitigation status to in order to 511 enable the enterprise to make an informed decision on whether to 512 maintain or terminate the mitigation. An alternative approach would 513 be for the DOTS client mitigation request to include a time to live 514 (TTL) for the mitigation, which may also be extended by the client 515 should the attack still be ongoing as the TTL reaches expiration. 517 A variation of this use case may be that the enterprise is providing 518 a DDoS monitoring and analysis service to customers whose networks 519 may be protected by any one of a number of third-party providers. 520 The enterprise in question may integrate with these third-party 521 providers using DOTS and signal accordingly when a customer is 522 attacked - the MSSP may then manage the life-cycle of the attack 523 mitigation on behalf of the enterprise. 525 3.1.2.2. MSSP as an end-customer requesting overflow DDoS mitigation 526 assistance from other MSSPs 528 This is a more complex use-case involving multiple DDoS MSSPs, 529 whether transit operators, overlay MSSPs, or both. In this scenario, 530 an MSSP has entered into a pre-arranged DDoS mitigation assistance 531 agreement with one or more other DDoS MSSPs in order to ensure that 532 sufficient DDoS mitigation capacity and/or capabilities may be 533 activated in the event that a given DDoS attack threatens to 534 overwhelm the ability of a given DDoS MSSP to mitigate the attack on 535 its own. 537 BGP-based diversion (including relevant Letters of Authorization, or 538 LoAs), DNS-based diversion (including relevant LoAs), traffic re- 539 injection mechanisms such as Generic Routing Encapsulation (GRE) 540 tunnels, provisioning of DDoS orchestration systems, et. al,. must be 541 arranged in advance between the DDoS MSSPs which are parties to the 542 agreement. They should also be tested on a regular basis. 544 When a DDoS MSSP which is party to the agreement is nearing its 545 capacity or ability to mitigate a given DDoS attack traffic, the DOTS 546 client integrated with the MSSP DDoS mitigation orchestration system 547 signals partner MSSPs to initiate network traffic diversion and DDoS 548 mitigation activities. Ongoing attack and mitigation status messages 549 may be passed between the DDoS MSSPs, and between the requesting MSSP 550 and the ultimate end-customer of the attack. 552 Once the requesting DDoS MSSP is confident that the DDoS attack has 553 either ceased or has fallen to levels of traffic/complexity which 554 they can handle on their own, the requesting DDoS MSSP DOTS client 555 sends mitigation termination requests to the participating overflow 556 DDoS MSSPs. 558 3.1.3. Examples of DOTS clients integrated with applications, services, 559 and network infrastructure devices 561 The use-cases in this section reflect scenarios in which DOTS clients 562 are integrated into devices and services which have heretofore been 563 unable to request DDoS mitigation services on an as-needed basis. 564 The DOTS communications models in these use-cases are largely 565 identical with those decribed in {{interdomain-use-cases}. These 566 variations are mainly of interest because they illustrate how DOTS 567 allows DDoS mitigation services to expand in scope and utility. 569 3.1.3.1. End-customer operating an application or service with an 570 integrated DOTS client 572 In this scenario, a Web server has a built-in mechanism to detect and 573 classify DDoS attacks, which also incorporates a DOTS client. When 574 an attack is detected, the self-defense mechanism is activated, and 575 local DDoS mitigation is initiated. 577 The DOTS client built into the Web server has been configured to 578 request DDoS mitigation services from an upstream transit provider or 579 overlay MSSP once specific attack traffic thresholds have been 580 reached, or certain network traffic conditions prevail. Once attack 581 traffic subsides below configured thresholds and/or the specified 582 network traffic conditions no longer apply, the DOTS client requests 583 the termination of DDoS mitigation services. 585 3.1.3.2. End-customer operating a CPE network infrastructure device 586 with an integrated DOTS client 588 Similar to the above use-case featuring applications or services with 589 built-in DDoS attack detection/classification and DOTS client 590 capabilities, in this scenario, an end-customer network 591 infrastructure CPE device such as a router, layer-3 switch, firewall, 592 IDS/IPS, Web application firewall or load-balancer incorporates both 593 the functionality required to detect and classify incoming DDoS 594 attacks as well as DOTS client functionality. 596 3.1.3.3. End-customer with an out-of-band smartphone application 597 featuring DOTS client capabilities 599 This scenario would typically apply in a small office or home office 600 (SOHO) setting, where the end-customer does not have CPE equipment or 601 software capable of detecting/classifying/mitigating DDoS attack, yet 602 still has a requirement for on-demand DDoS mitigation services. A 603 smartphone application containing a DOTS client would be provided by 604 the upstream transit mitigation provider or overlay DDoS MSSP to the 605 SOHO end-customer; this application would allow a manual 'panic- 606 button' to request the initiation and termination of DDoS mitigation 607 services. The end-customer DOTS client application will display 608 mitigation status information while DDoS mitigation activities are 609 taking place. 611 3.2. Intra-domain Use Cases 613 While many of the DOTS-specific elements of inter-domain DOTS 614 deployment scenarios apply to intra-domain scenarios, it is expected 615 that many externalities such as coordination of and authorization for 616 routing advertisements and authoritative DNS updates may be automated 617 to a higher degree than is practicable in inter-domain scenarios, 618 given that the scope of required activities and authorizations are 619 confined to a single organization. In theory, provisioning and 620 change-control related both to DOTS itself as well as relevant 621 externalities may require less administrative overhead and less 622 implementation lead-times. 624 The scope of potential DDoS mitigation actions may also be broader in 625 intra-organizational scenarios, as presumably an organization will 626 have a higher degree of autonomy with regards to both techically and 627 administratively feasible activities. 629 The DOTS communications model in these scenarios are largely 630 identical to that described in Section 3.1, except that all the DOTS 631 communications take place within the same span of administrative 632 control and the same network. These variations are mainly of 633 interest from the operational point of view, as they illustrate 634 processes, procedures, and topological details which are 635 externalities from the standpoint of the DOTS ecosystem, but which 636 are of great importance for network operators and DDoS mitigation 637 service providers. 639 3.2.1. Suppression of outbound DDoS traffic originating from a consumer 640 broadband access network 642 While most DDoS defenses concentrate on inbound DDoS attacks 643 ingressing from direct peering links or upstream transit providers, 644 the DDoS attack traffic in question originates from one or more 645 Internet-connected networks. In some cases, compromised devices 646 residing on the local networks of broadband access customers are used 647 to directly generate this DDoS attack traffic; in others, 648 misconfigured devices residing on said local customer networks are 649 exploited by attackers to launch reflection/amplification DDoS 650 attacks. In either scenario, the outbound DDoS traffic emanating 651 from these devices can be just as disruptive as an inbound DDoS 652 attack, and can cause disruption for substantial proportions of the 653 broadband access network operator's customer base. 655 Some broadband access network operators provide CPE devices (DSL 656 modems/routers, cablemodems, FTTH routers, etc.) to their end- 657 customers. Others allow end-customers to provide their own CPE 658 devices. Many will either provide CPE devices or allow end-customers 659 to supply their own. 661 Broadband access network operators typically have mechanisms to 662 detect and classify both inbound and outbound DDoS attacks, utilizing 663 flow telemetry exported from their peering/transit and customer 664 aggregation routers. In the event of an outbound DDoS attack, they 665 may make use of internally-developed systems which leverage their 666 subscriber-management systems to de-provision end-customers who are 667 sourcing outbound DDoS traffic; in some cases, they may have 668 implemented quarantine systems to block all outbound traffic sourced 669 from the offending end-customers. In either case, the perceived 670 disruption of the end-customer's Internet access often prompts a 671 help-desk call, which erodes the margins of the broadband access 672 provider and can cause end-customer dissatisfaction. 674 Increasingly, CPE devices themselves are targeted by attackers who 675 exploit security flaws in these devices in order to compromise them 676 and subsume them into botnets, and then leverage them to launch 677 outbound DDoS attacks. In all of the described scenarios, the end- 678 customers are unaware that their computers and/or CPE devices have 679 been compromised and are being used to launch outbound DDoS attacks - 680 however, they may notice a degradation of their Internet connectivity 681 as a result of outbound bandwidth consumption or other disruption. 683 By deploying DOTS-enabled telemetry systems and CPE devices (and 684 possibly requiring DOTS functionality in customer-provided CPE 685 devices), broadband access providers can utilize a standards-based 686 mechanism to suppress outbound DDoS attack traffic while optionally 687 allowing legitimate end-customer traffic to proceed unmolested. 689 In order to achieve this capability, the telemetry analysis system 690 utilized by the broadband access provider must have DOTS client 691 functionality, and the end-customer CPE devices must have DOTS server 692 functionality. When the telemetry analysis system detects and 693 classifies an outbound DDoS attack sourced from one or more end- 694 customer networks/devices, the DOTS client of the telemetry analysis 695 system sends a DOTS request to the DOTS server implemented on the CPE 696 devices, requesting local mitigation assistance in suppressing either 697 the identified outbound DDoS traffic, or all outbound traffic sourced 698 from the end-customer networks/devices. The DOTS server residing 699 within the CPE device(s) would then perform predefined actions such 700 as implementing on-board access-control lists (ACLs) to suppress the 701 outbound traffic in question and prevent it from leaving the local 702 end-customer network(s). 704 Broadband access network operators may choose to implement a 705 quarantine of all or selected network traffic originating from end- 706 customer networks/devices which are sourcing outbound DDoS traffic, 707 redirecting traffic from interactive applications such as Web 708 browsers to an internal portal which informs the end-customer of the 709 quarantine action, and providing instructions for self-remediation 710 and/or helpdesk contact information. 712 Quarantine systems for broadband access networks are typically 713 custom-developed and -maintained, and are generally deployed only by 714 a relatively small number of broadband access providers with 715 considerable internal software development and support capabilities. 716 By requiring the manufacturers of operator-supplied CPE devices to 717 implement DOTS server functionality, and requiring customer-provided 718 CPE devices to feature DOTS server functionality, broadband access 719 network operators who previously could not afford the development 720 expense of creating custom quarantine systems to integrate DOTS- 721 enabled network telemetry systems to act as DOTS clients and perform 722 effective quarantine of end-customer networks and devices until such 723 time as they have been remediated. 725 The DOTS communications model in this scenario resembles that 726 described in Section 3.1.1.1, except that all the DOTS communications 727 take place within the same span of administrative control and the 728 same network. 730 3.2.2. Home Network DDoS Detection Collaboration for ISP network 731 management 733 Home networks run with (limited) bandwidth as well as limited routing 734 resources, while they are expected to provide services reachable from 735 the outside [RFC7368]. This makes such networks some easy targets to 736 DDoS attacks via their WAN interface. As these DDoS attacks are easy 737 to perform, they may remain undetected by the upstream ISP. When the 738 CPE is congested, the customer is likely to call the ISP hotline. In 739 order to improve the quality of experience of the connectivity as 740 well as to automate the request for DDoS mitigation, ISPs are likely 741 to consider a standard mean for CPEs to automatically inform a 742 dedicated service mitigation platform when they are under a suspected 743 DDoS. 745 Note also that this section only considers DDoS attacks CPE or 746 services in the home network are encountering. This differs from 747 DDoS attacks the CPE or any device within the home network may take 748 part of - such as botnets. In the later attacks, the home network 749 generates traffic under the control of a botmaster. Such attacks may 750 only be detected once the attacks have been characterized. It would 751 be tempting to consider a feature in the DOTS protocol to allow a 752 DOTS server to inform a CPE that some suspect traffic is being sent 753 by the CPE so that appropriate actions are undertaken by the CPE/ 754 user. Nevertheless, this feature would require some interaction with 755 the CPE administrator. Such scenario is outside the scope of this 756 document. 758 In this use case, ISPs are willing to prevent their customer 759 undergoing DDoS attacks in order to enhance the quality of experience 760 of their customers, to avoid unnecessary costly call on hot lines as 761 well as to optimize the bandwidth of their network. A key challenge 762 for the ISP is to detect DDoS attacks. In fact, DDoS detection is 763 not only fine grained but is also expected to be different for each 764 home network or small businesses networks (SOHO), and the ISP is 765 unlikely to have sufficient resource to inspect the traffic of all 766 its customers. 768 In order to address these challenges, ISPs are delegating the DDoS 769 detection to CPE of home network or SOHO. Outsourcing the detection 770 on the CPE provides the following advantages to the ISP: 1) Avoid the 771 ISP to dedicate a huge amount of resource for deep packet inspection 772 over a large amount of traffic with a specific security policies 773 associated to each home network. It is expected that such traffic 774 only constitutes a small fraction of the total traffic the ISP is 775 responsible for. 2) DDoS detection is deployed in a scalable way. 3) 776 Provide more deterministic DDoS attack detection. For example, what 777 could be suspected to be an UDP flood by the ISP may be consented by 778 the terminating point hosted in the home network or SOHO. In fact, 779 without specific home network security policies, the ISP is likely to 780 detect DDoS attack over regular traffic or to miss DDoS attacks 781 targeting a specific home network or CPE. In the first case, this 782 would result in the ISP spending unnecessary resources and in the 783 second case this would directly impact the quality of experience of 784 the customer. 786 Note that in this scenario slightly differs from the "Enterprise with 787 an upstream transit provider DDoS mitigation Service" scenario 788 described in Section 3.1.1. In this scenario, the detection DDoS is 789 motivated by the ISP in order to operate appropriately its network. 791 For that purpose, it requires some collaboration with the home 792 network. In Section 3.1.1, the target network requests a mitigation 793 service from the upstream transit provider in order to operate its 794 services. 796 Even though the motivations differ, there are still significant 797 advantages for the home network to collaborate. On the home network 798 or SOHO perspective such collaboration provides the following 799 advantages: 1) If it removes the flows contributing to a DDoS 800 attacks, then it enhances the quality of experience of the users of 801 the targeted services or the entire home network. 2) If mitigation is 802 being handled by the ISP rather then the home network, then it 803 reduces the management of DDoS attacks by the network administrator 804 which involves detection as well as mitigation as well as the 805 provisioning of extra resources. 3) If the DDoS detection is based on 806 information specific to the home network, such as for example the 807 description of the services, the hosts capacities or the network 808 topology, then performing the DDoS detection by the home network 809 instead of the ISP avoids the home network to leak private 810 information to the ISP. In that sense, it better preserves the home 811 network or SOHO privacy while enabling a better detection. However, 812 the request for mitigation may still leak some informations. ISPs 813 must not retrieve sensitive data without the consent of the user. 814 This is usually captured in administrative contracts that are out of 815 scope of this document. 817 When the CPE suspects an attack, it notifies automatically or the 818 ISP. The contact address of the DDoS Mitigation service of the ISP 819 may be hard coded or may be configured manually or automatically 820 (e.g., eventually the DHCP server may provide the DDoS mitigation 821 service via specific DHCP options). 823 The communication to trigger a DDoS mitigation between the home 824 network and the ISP is performed using DOTS. The home network CPE 825 implements a DOTS client while the ISP implements a DOTS server. 827 The DOTS client on the CPE monitors the status of CPE's resource and 828 WAN link bandwidth usage. If something unusual happens based on 829 preconfigured throughput, traffic patter, explicit action from the 830 user, or some heuristics methods, the DOTS client sends a DOTS 831 mitigation request to the ISP DOTS server. Typically, a default 832 configuration with no additional information associated to the DOTS 833 mitigation request is expected. The ISP derives traffic to mitigate 834 from the CPE IP address. 836 In some cases, the DOTS mitigation request contains options such as 837 some IP addresses or prefixes that belongs to a whitelist or a 838 blacklist. In this case, the white and black lists are not 839 associated to some analysis performed by the CPE - as the CPE is 840 clearly not expected to analyze such attacks. Instead these are part 841 of some configuration parameters. For example, in the case of small 842 business, one may indicate specific legitimate IP addresses such as 843 those used for VPNs, or third party services the company is likely to 844 set a session. Similarly, the CPE may provide the IP addresses 845 targeting the assets to be protected inside the network. Note that 846 the IP address is the IP address used to reach the asset from the 847 internet, and as such is expected to be globally routable. Such 848 options may include the IP address as well as a service description. 849 Similarly to the previous blacklist and whitelist, such information 850 are likely not derived from a traffic analysis performed by the CPE, 851 but instead are more related to configuration parameters. 853 Upon receiving the DOTS mitigation request, the DOTS server 854 acknowledges its reception and confirms DDoS mitigation starts or 855 not. Such feed back is mostly to avoid retransmission of the 856 request. 858 Note that the ISP is connected to multiple CPEs and as such the CPE 859 can potentially perform DDoS attack to the DOTS server. ISP may use 860 gateways to absorbs the traffic. These gateways, will typically 861 aggregate a smaller number of CPEs and retransmit to the destination 862 DOTS Server a selected information. Note that such gateways may 863 somehow act as a DOTS relay, which is implemented with a DOTS Server 864 and a DOTS Client. Note also that the case of a large DDoS attack 865 targeting simultaneously multiple CPEs is expected to be detected and 866 mitigated by the upstream architecture, eventually without DOTS 867 alerts sent by each single CPE. 869 ISP may activate mitigation for the traffic associated to the CPE 870 sending the alert or instead to the traffic associated to all CPE. 871 Such decisions are not part of DOTS, but instead depend on the 872 policies of the ISP. 874 It is unlikely the CPE will follow the status of the mitigation. The 875 ISP is only expected to inform the CPE the mitigation has been 876 stopped. 878 Upon receipt of such notification the CPE may, for example, re- 879 activate the monitoring jobs and thus is likely to provide some 880 further DOTS alert. 882 3.2.3. DDoS Orchestration 884 In this use case, one or more DDoS telemetry systems or monitoring 885 devices such as a flow telemetry collector monitor a network -- 886 typically an ISP network. Upon detection of a DDoS attack, these 887 telemetry systems alert an orchestrator in charge of coordinating the 888 various DDoS mitigation systems within the domain. The telemetry 889 systems may be configured to provide necessary and useful pieces of 890 information, such as a preliminary analysis of the observation to the 891 orchestrator. 893 The orchestrator analyses the various information it receives from 894 specialized equipement, and elaborates one or multiple DDoS 895 mitigation strategies. In some case, a manual confirmation may also 896 be required to choose a proposed strategy or to initiate a DDoS 897 mitigation. The DDoS mitigation may consist of multiple steps such 898 as configuring the network, various hardware, or updating already 899 instantiated DDoS mitigation functions. In some cases, some specific 900 virtual DDoS mitigation functions must be instantiated and properly 901 ordered. Eventually, the coordination of the mitigation may involve 902 external DDoS resources such as a transit provider (Section 3.1.1.1) 903 or an MSSP (Section 3.1.2.1). 905 The communications used to trigger a DDoS mitigation between the 906 telemetry and monitoring systems and the orchestrator is performed 907 using DOTS. The telemetry systems implements a DOTS client while the 908 orchestrator implements a DOTS server. 910 The communication between a network administrator and the 911 orchestrator is also performed using DOTS. The network administrator 912 via its web interfaces implements a DOTS client, while the 913 Orchestrator implements a DOTS server. 915 The communication between the Orchestrator and the DDoS mitigation 916 systems is performed using DOTS. The Orchestrator implements a DOTS 917 client while the DDoS mitigation systems implement a DOTS server. 919 The configuration aspects of each DDoS mitigation system, as well as 920 the instantiations of DDoS mitigation functions or network 921 configuration is not part of DOTS. Similarly, the discovery of 922 available DDoS mitigation functions is not part of DOTS. 924 +----------+ 925 | network |C 926 | adminis |<-+ 927 | trator | | 928 +----------+ | 929 | (internal) 930 +----------+ | S+--------------+ +-----------+ 931 |telemetry/| +->| |C S| DDoS |+ 932 |monitoring|<--->| Orchestrator |<--->| mitigation|| 933 |systems |C S| |<-+ | systems || 934 +----------+ +--------------+C | +-----------+| 935 | +----------+ 936 | 937 | (external) 938 | +-----------+ 939 | S| DDoS | 940 +->| mitigation| 941 | systems | 942 +-----------+ 943 * C is for DOTS client functionality 944 * S is for DOTS server functionality 946 Figure 1: DDoS Orchestration 948 The telemetry systems monitor various traffic network and perform 949 their measurement tasks. They are configured so that when an event 950 or some measurements reach a predefined level to report a DOTS 951 mitigation request to the Orchestrator. The DOTS mitigation request 952 may be associated with some element such as specific reporting. 954 Upon receipt of the DOTS mitigation request from the telemetry 955 system, the Orchestrator responds with an acknowledgement, to avoid 956 retransmission of the request for mitigation. The status of the DDoS 957 mitigation indicates the Orchestrator is in an analysing phase. The 958 Orchestrator begins collecting various information from various 959 telemetry systems in order to correlate the measurements and provide 960 an analysis of the event. Eventually, the Orchestrator may ask 961 additional information to the telemetry system, however, the 962 collection of these information is performed outside DOTS. 964 The orchestrator may be configured to start a DDoS mitigation upon 965 approval from a network administrator. The analysis from the 966 orchestrator is reported to the network administrator via a web 967 interface. If the network administrator decides to start the 968 mitigation, she orders through her web interface a DOTS client to 969 send a request for DDoS mitigation. This request is expected to be 970 associated with a context that identifies the DDoS mitigation 971 selected. 973 Upon receiving the DOTS request for DDoS mitigation from the network 974 administrator, the orchestrator orchestrates the DDoS mitigation 975 according to the specified strategy. Its status indicates the DDoS 976 mitigation is starting while not effective. 978 Orchestration of the DDoS mitigation systems works similarly as 979 described in Section 3.1.1.1 and Section 3.1.2.1. The Orchestrator 980 indicates with its status whether the DDoS Mitigation is effective. 982 When the DDoS mitigation is finished on the DDoS mitigation systems, 983 the orchestrator indicates to the Telemetry systems as well as to the 984 network administrator the DDoS mitigation is finished. 986 4. Security Considerations 988 DOTS is at risk from four primary forms of attack: DOTS agent 989 impersonation, traffic injection, signal-blocking, and DDoS attacks. 990 Associated security requirements and additional ones are defined in 991 [I-D.ietf-dots-requirements]. 993 These security risks can be managed through current secure 994 communications best practices. 995 DOTS is not subject to anything new or unique in this area. 997 5. IANA Considerations 999 No IANA considerations exist for this document at this time. 1001 6. Acknowledgments 1003 The authors would like to thank among others Tirumaleswar Reddy; 1004 Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; and the 1005 DOTS WG chairs, Roman D. Danyliw and Tobias Gondrom, for their 1006 valuable feedback. 1008 7. References 1010 7.1. Normative References 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, 1014 DOI 10.17487/RFC2119, March 1997, . 1017 7.2. Informative References 1019 [I-D.ietf-dots-requirements] 1020 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1021 Denial of Service (DDoS) Open Threat Signaling 1022 Requirements", draft-ietf-dots-requirements-07 (work in 1023 progress), October 2017. 1025 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1026 Cheshire, "Internet Assigned Numbers Authority (IANA) 1027 Procedures for the Management of the Service Name and 1028 Transport Protocol Port Number Registry", BCP 165, 1029 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1030 . 1032 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1033 Weil, "IPv6 Home Networking Architecture Principles", 1034 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1035 . 1037 Authors' Addresses 1039 Roland Dobbins 1040 Arbor Networks 1041 Singapore 1043 EMail: rdobbins@arbor.net 1044 Daniel Migault 1045 Ericsson 1046 8400 boulevard Decarie 1047 Montreal, QC H4P 2N2 1048 Canada 1050 EMail: daniel.migault@ericsson.com 1052 Stefan Fouant 1053 USA 1055 EMail: stefan.fouant@copperriverit.com 1057 Robert Moskowitz 1058 HTT Consulting 1059 Oak Park, MI 48237 1060 USA 1062 EMail: rgm@labs.htt-consult.com 1064 Nik Teague 1065 Verisign 1066 12061 Bluemont Way 1067 Reston, VA 20190 1069 EMail: nteague@verisign.com 1071 Liang Xia 1072 Huawei 1073 No. 101, Software Avenue, Yuhuatai District 1074 Nanjing 1075 China 1077 EMail: Frank.xialiang@huawei.com 1079 Kaname Nishizuka 1080 NTT Communications 1081 GranPark 16F 3-4-1 Shibaura, Minato-ku 1082 Tokyo 108-8118 1083 Japan 1085 EMail: kaname@nttv6.jp