idnits 2.17.1 draft-ietf-dots-use-cases-06.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 (July 03, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF' is mentioned on line 125, but not defined == Unused Reference: 'APACHE' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC7368' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RRL' is defined on line 704, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-05 Summary: 0 errors (**), 0 flaws (~~), 7 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: January 4, 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 July 03, 2017 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-06 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 24 protocol that facilitates interoperability between multivendor 25 solutions/services. This document presents use cases to evaluate the 26 interactions expected between the DOTS components as well as DOTS 27 messaging exchanges. The purpose of describing use cases is to 28 identify the interacting DOTS components, how they collaborate and 29 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 January 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 68 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . 5 72 3.1.1. End-customer with a single upstream transit provider 73 offering DDoS mitigation services . . . . . . . . . . 5 74 3.1.2. End-customer with multiple upstream transit providers 75 offering DDoS mitigation services . . . . . . . . . . 6 76 3.1.3. End-customer with multiple upstream transit 77 providers, but only a single upstream transit 78 provider offering DDoS mitigation services . . . . . 6 79 3.1.4. End-customer with an overlay DDoS mitigation managed 80 security service provider (MSSP) . . . . . . . . . . 7 81 3.1.5. End-customer operating an application or service with 82 an integrated DOTS client . . . . . . . . . . . . . . 8 83 3.1.6. End-customer operating a CPE network infrastructure 84 device with an integrated DOTS client . . . . . . . . 9 85 3.1.7. End-customer with an out-of-band smartphone 86 application featuring DOTS client capabilities . . . 9 87 3.1.8. MSSP as an end-customer requesting overflow DDoS 88 mitigation assistance from other MSSPs . . . . . . . 9 89 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . 10 90 3.2.1. Suppression of outbound DDoS traffic originating from 91 a consumer broadband access network . . . . . . . . . 10 92 3.2.2. DDoS Orchestration . . . . . . . . . . . . . . . . . 12 93 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 7.2. Informative References . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 101 1. Introduction 103 Currently, distributed denial-of-service (DDoS) attack mitigation 104 solutions/services are largely based upon siloed, proprietary 105 communications paradigms which result in vendor/service lock-in. As 106 a side-effect, this makes the configuration, provisioning, operation, 107 and activation of these solutions a highly manual and often time- 108 consuming process. Additionally, coordination of multiple DDoS 109 mitigation solutions/services simultaneously engaged in defending the 110 same organization against DDoS attacks is fraught with both technical 111 and process-related hurdles. This greatly increase operational 112 complexity and often results in suboptimal DDoS attack mitigation 113 efficacy. 115 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 116 protocol that facilitates interoperability between multivendor DDoS 117 mitigation solutions/services. As DDoS solutions/services are 118 broadly heterogeneous among different vendors, the primary goal for 119 DOTS is to provide a high level interaction with these DDoS 120 solutions/services such as initiating or terminating DDoS mitigation 121 assistance. 123 It should be noted that DOTS is not in and of itself intended to 124 perform orchestration functions duplicative of the functionality 125 being developed by the [I2NSF] WG; rather, DOTS is intended to allow 126 devices, services, and applications to request DDoS attack mitigation 127 assistance and receive mitigation status updates from systems of this 128 nature. 130 The use cases presented in the document are intended to provide 131 examples of communications interactions DOTS-enabled nodes in both 132 inter- and intra-organizational DDoS mitigation scenarios. These use 133 cases are expected to provide inputs for the design of the DOTS 134 protocol(s). 136 2. Terminology and Acronyms 138 2.1. Requirements Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2.2. Acronyms 146 This document makes use of the same terminology and definitions as 147 [I-D.ietf-dots-requirements], except where noted. 149 2.3. Terms 151 Inter-organizational: a DOTS communications relationship between 152 distinct organizations with separate spans of administrative control. 153 Typical inter-organizational DOTS communication relationships would 154 be between a DDoS mitigation service provider and an end-customer 155 organizational which requires DDoS mitigation assistance; between 156 multiple DDoS mitigation service providers coordinating mutual 157 defense of a mutual end-customer; or between DDoS mitigation service 158 providers which are requesting additional DDoS mitigation assistance 159 in for attacks which exceed their inherent DDoS mitigation capacities 160 and/or capabilities. 162 Intra-organizational: a DOTS communications relationship between 163 various elements within a single span of administrative control. A 164 typical intra-organizational DOTS communications relationship would 165 be between DOTS clients, DOTS gateways, and DOTS servers within the 166 same organization. 168 3. Use Cases Scenarios 170 This section provides a high-level description of scenarios addressed 171 by DOTS. In both sections, the scenarios are provided in order to 172 illustrate the use of DOTS in typical DDoS attack scenarios. They 173 are not definitive, and other use cases are expected to emerge with 174 widespread DOTS deployment. 176 All scenarios present a coordination between the targeted 177 organization, the DDoS attack telemetry and the mitigator. The 178 coordination and communication between these entity depends, for 179 example on the characteristic or functionality of the equipment, the 180 reliability of the information provided by DDoS attack telemetry, and 181 the business relationship between the DDoS target domain and the 182 mitigator. 184 More explicitly, in some cases, the DDoS attack telemetry may simply 185 activate a DDoS mitigation, whereas in other cases, it may 186 collaborate by providing some information about an attack. In some 187 cases, the DDoS mitigation may be orchestrated, which includes 188 selecting a specific appliance as well as starting/ending a 189 mitigation. 191 3.1. Inter-domain Use Cases 193 3.1.1. End-customer with a single upstream transit provider offering 194 DDoS mitigation services 196 In this scenario, an enterprise network with self-hosted Internet- 197 facing properties such as Web servers, authoritative DNS servers, and 198 VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed 199 to protect those servers and applications from DDoS attacks. In 200 addition to their on-premise DDoS defense capability, they have 201 contracted with their Internet transit provider for DDoS mitigation 202 services which threaten to overwhelm their transit link bandwidth. 204 The IDMS is configured such that if the incoming Internet traffic 205 volume exceeds 50% of the provisioned upstream Internet transit link 206 capacity, the IDMS will request DDoS mitigation assistance from the 207 upstream transit provider. 209 The requests to trigger, manage, and finalize a DDoS mitigation 210 between the enterprise IDMS and the transit provider is performed 211 using DOTS. The enterprise IDMS implements a DOTS client while the 212 transit provider implements a DOTS server which is integrated with 213 their DDoS mitigation orchestration system. 215 When the IDMS detects an inbound DDoS attack targeting the enterprise 216 servers and applications, it immediately begins mitigating the 217 attack. 219 During the course of the attack, the inbound traffic volume exceeds 220 the 50% threshold; the IDMS DOTS client signals the DOTS server on 221 the upstream transit provider network to initiate DDoS mitigation. 222 The DOTS server signals the DOTS client that it can service this 223 request, and mitigation is initiated on the transit provider network. 225 Over the course of the attack, the DOTS server on the transit 226 provider network periodically signals the DOTS client on the 227 enterprise IDMS in order to provide mitigation status information, 228 statistics related to DDoS attack traffic mitigation, and related 229 information. Once the DDoS attack has ended, the DOTS server signals 230 the enterprise IDMS DOTS client that the attack has subsided. 232 The enterprise IDMS then requests that DDoS mitigation services on 233 the upstream transit provider network be terminated. The DOTS server 234 on the transit provider network receives this request, communicates 235 with the transit provider orchestration system controlling its DDoS 236 mitigation system to terminate attack mitigation, and once the 237 mitigation has ended, confirms the end of upstream DDoS mitigation 238 service to the enterprise IDMS DOTS client. 240 Note that communications between the enterprise DOTS client and the 241 upstream transit provider DOTS server may take place in-band within 242 the main Internet transit link between the enterprise and the transit 243 provider; out-of-band via a separate, dedicated wireline network link 244 utilized solely for DOTS signaling; or out-of-band via some other 245 form of network connectivity such as a third-party wireless 4G 246 network link. 248 3.1.2. End-customer with multiple upstream transit providers offering 249 DDoS mitigation services 251 This scenario shares many characteristics with the above, but with 252 the key difference that the enterprise in question is multi-homed, 253 i.e., has two or more upstream transit providers, and that they all 254 provide DDoS mitigation services. 256 In most cases, the communications model for a multi-homed model would 257 be the same as in the single-homed model, merely duplicated in 258 parallel. However, if two or more of the upstream transit providers 259 have entered into a mutual DDoS mitigation agreement and have 260 established DOTS peering between the participants, DDoS mitigation 261 status messages may exchanged between the DOTS servers of the 262 participants in order to provide a more complete picture of the DDoS 263 attack scope, and allow for either automated or operator-assisted 264 programmatic cooperative DDoS mitigation activities on the part of 265 the transit providers. 267 3.1.3. End-customer with multiple upstream transit providers, but only 268 a single upstream transit provider offering DDoS mitigation 269 services 271 This scenario is similar to the multi-homed scenario referenced 272 above; however, only one of the upstream transit providers in 273 question offers DDoS mitigation services. In this situation, the 274 enterprise would cease advertising the relevant network prefixes via 275 the transit providers which do not provide DDoS mitigation services - 276 or, in the case where the enterprise does not control its own 277 routing, request that the upstream transit providers which do not 278 offer DDoS mitigation services stop advertising the relevant network 279 prefixes on their behalf. 281 Once it has been determined that the DDoS attack has ceased, the 282 enterprise once again announces the relevant routes to the upstream 283 transit providers which do not offer DDoS mitigation services, or 284 requests that they resume announcing the relevant routes on behalf of 285 the enterprise. 287 Note that falling back to a single transit provider has the effect of 288 reducing available inbound transit bandwidth during a DDoS attack. 289 Without proper planning and sufficient provisioning of both the link 290 capacity and DDoS mitigation capacity of the sole transit provider 291 offering DDoS mitigation services, this reduction of available 292 bandwidth could lead to network link congestion caused by legitimate 293 inbound network traffic. Therefore, careful planning and 294 provisioning of both upstream transit bandwidth as well as DDoS 295 mitigation capacity is required in scenarios of this nature. 297 The withdrawal and announcement of routing prefixes described in this 298 use-case falls outside the scope of DOTS, although they could 299 conceivably be triggered as a result of provider-specific 300 orchestration triggered by the receipt of specific DOTS messages from 301 the enterprise in question. 303 3.1.4. End-customer with an overlay DDoS mitigation managed security 304 service provider (MSSP) 306 This use case details an enterprise that has a local DDoS detection 307 and classification capability and may or may not have an on-premise 308 mitigation capability. The enterprise is contracted with an overlay 309 DDoS mitigation MSSP, topologically distant from the enterprise 310 network (i.e., not a direct upstream transit provider), which can 311 redirect (divert) traffic away from the enterprise, provide DDoS 312 mitigation services services, and then forward (re-inject) legitimate 313 traffic to the enterprise on an on-demand basis. In this scenario, 314 diversion of Internet traffic destined for the enterprise network 315 into the overlay DDoS mitigation MSSP network is typically 316 accomplished via eBGP announcements of the relevant enterprise 317 network CIDR blocks, or via authoritative DNS subdomain-based 318 mechanisms (other mechanisms are not precluded, these are merely the 319 most common ones in use today). 321 The enterprise determines thresholds at which a request for 322 mitigation is triggered indicating to the MSSP that inbound network 323 traffic should be diverted into the MSSP network and that DDoS 324 mitigation should be initiated. The enterprise may also elect to 325 manually request diversion and mitigation via the MSSP network as 326 desired. 328 The communications required to initiate, manage, and terminate active 329 DDoS mitigation by the MSSP is performed using DOTS. The enterprise 330 DDoS detection/classification system implements a DOTS client, while 331 the MSSP implements a DOTS server integrated with its DDoS mitigation 332 orchestration system. One or more out-of-band methods for initiating 333 a mitigation request, such as a Web portal, a smartphone app, or 334 voice support hotline, may also be made available by the MSSP. 336 When an attack is detected, an automated or manual DOTS mitigation 337 request is be generated by the enterprise and sent to the MSSP. The 338 enterprise DOTS mitigation request is processed by the MSSP DOTS 339 server, which validates the origin of the request and passes it to 340 the MSSP DDoS mitigation orchestration system, which then initiates 341 active DDoS mitigation. This action will usually involve the 342 diversion of all network traffic destined for the targeted enterprise 343 into the MSSP DDoS mitigation network, where it will be subjected to 344 further scrutiny, with DDoS attack traffic filtered by the MSSP. 345 Successful mitigation of the DDoS attack will not only result 346 preserving the availability of services and applications resident on 347 the enterprise network, but will also prevent DDoS attack traffic 348 from ingressing the networks of the enterprise upstream transit 349 providers/peers. 351 The MSSP should signal via DOTS to the enterprise that a mitigation 352 request has been received and acted upon, and should also include an 353 update of the mitigation status. The MSSP may respond periodically 354 with additional updates on the mitigation status to in order to 355 enable the enterprise to make an informed decision on whether to 356 maintain or terminate the mitigation. An alternative approach would 357 be for the DOTS client mitigation request to include a time to live 358 (TTL) for the mitigation, which may also be extended by the client 359 should the attack still be ongoing as the TTL reaches expiration. 361 A variation of this use case may be that the enterprise is providing 362 a DDoS monitoring and analysis service to customers whose networks 363 may be protected by any one of a number of third-party providers. 364 The enterprise in question may integrate with these third-party 365 providers using DOTS and signal accordingly when a customer is 366 attacked - the MSSP may then manage the life-cycle of the attack 367 mitigation on behalf of the enterprise. 369 3.1.5. End-customer operating an application or service with an 370 integrated DOTS client 372 In this scenario, a Web server has a built-in mechanism to detect and 373 classify DDoS attacks, which also incorporates a DOTS client. When 374 an attack is detected, the self-defense mechanism is activated, and 375 local DDoS mitigation is initiated. 377 The DOTS client built into the Web server has been configured to 378 request DDoS mitigation services from an upstream transit provider or 379 overlay MSSP once specific attack traffic thresholds have been 380 reached, or certain network traffic conditions prevail. Once the 381 specified conditions have been met, the DOTS communications dialogue 382 and subsequent DDoS mitigation initiation and termination actions 383 described above take place. 385 3.1.6. End-customer operating a CPE network infrastructure device with 386 an integrated DOTS client 388 Similar to the above use-case featuring applications or services with 389 built-in DDoS attack detection/classification and DOTS client 390 capabilities, in this scenario, an end-customer network 391 infrastructure CPE device such as a router, layer-3 switch, firewall, 392 or load-balance incorporates both the functionality required to 393 detect and classify incoming DDoS attacks as well as DOTS client 394 functionality. 396 The subsequent DOTS communications dialogue and resultant DDoS 397 mitigation initiation and termination activities take place in the 398 same manner as the use-cases described above. 400 3.1.7. End-customer with an out-of-band smartphone application 401 featuring DOTS client capabilities 403 This scenario would typically apply in a small office/home office 404 (SOHO) setting, where the end-customer does not have CPE equipment or 405 software capable of detecting/classifying/mitigating DDoS attack, yet 406 still has a requirement for on-demand DDoS mitigation services. A 407 smartphone application containing a DOTS client would be provided by 408 the upstream transit mitigation provider or overlay DDoS MSSP to the 409 SOHO end-customer; this application would allow a manual 'panic- 410 button' to request the initiation and termination of DDoS mitigation 411 services. 413 The DOTS communications dialogue and resultant DDoS mitigation 414 initiation/status reporting/termination actions would then take place 415 as in the other use-cases described above, with the end-customer DOTS 416 client serving to display received status information while DDoS 417 mitigation activities are taking place. 419 3.1.8. MSSP as an end-customer requesting overflow DDoS mitigation 420 assistance from other MSSPs 422 This is a more complex use-case involving multiple DDoS MSSPs, 423 whether transit operators, overlay MSSPs, or both. In this scenario, 424 an MSSP has entered into a pre-arranged DDoS mitigation assistance 425 agreement with one or more other DDoS MSSPs in order to ensure that 426 sufficient DDoS mitigation capacity and/or capabilities may be 427 activated in the event that a given DDoS attack threatens to 428 overwhelm the ability of a given DDoS MSSP to mitigate the attack on 429 its own. 431 BGP-based diversion (including relevant Letters of Authorization, or 432 LoAs), DNS-based diversion (including relevant LoAs), traffic re- 433 injection mechanisms such as Generic Routing Encapsulation (GRE) 434 tunnels, provisioning of DDoS orchestration systems, et. al. must be 435 arranged in advance between the DDoS MSSPs which are parties to the 436 agreement. They should also be tested on a regular basis. 438 When a DDoS MSSP which is party to the agreement is nearing its 439 capacity or ability to mitigate a given DDoS attack traffic, the DOTS 440 client integrated with the MSSP DDoS mitigation orchestration system 441 signals partner MSSPs to initiate network traffic diversion and DDoS 442 mitigation activities. Ongoing attack and mitigation status messages 443 may be passed between the DDoS MSSPs, and between the requesting MSSP 444 and the ultimate end-customer of the attack. 446 The DOTS dialogues and resultant DDoS mitigation-related activities 447 in this scenario progress as described in the other use-cases 448 detailed above. Once the requesting DDoS MSSP is confident that the 449 DDoS attack has either ceased or has fallen to levels of traffic/ 450 complexity which they can handle on their own, the requesting DDoS 451 MSSP DOTS client sends mitigation termination requests to the 452 participating overflow DDoS MSSPs. 454 3.2. Intra-domain Use Cases 456 3.2.1. Suppression of outbound DDoS traffic originating from a consumer 457 broadband access network 459 While most DDoS defenses concentrate on inbound DDoS attacks 460 ingressing from direct peering links or upstream transit providers, 461 the DDoS attack traffic in question originates from one or more 462 Internet-connected networks. In some cases, compromised devices 463 residing on the local networks of broadband access customers are used 464 to directly generate this DDoS attack traffic; in others, 465 misconfigured devices residing on said local customer networks are 466 exploited by attackers to launch reflection/amplification DDoS 467 attacks. In either scenario, the outbound DDoS traffic emanating 468 from these devices can be just as disruptive as an inbound DDoS 469 attack, and can cause disruption for substantial proportions of the 470 broadband access network operator's customer base. 472 Some broadband access network operators provide CPE devices (DSL 473 modems/routers, cablemodems, FTTH routers, etc.) to their end- 474 customers. Others allow end-customers to provide their own CPE 475 devices. Many will either provide CPE devices or allow end-customers 476 to supply their own. 478 Broadband access network operators typically have mechanisms to 479 detect and classify both inbound and outbound DDoS attacks, utilizing 480 flow telemetry exported from their peering/transit and customer 481 aggregation routers. In the event of an outbound DDoS attack, they 482 may make use of internally-developed systems which leverage their 483 subscriber-management systems to de-provision end-customers who are 484 sourcing outbound DDoS traffic; in some cases, they may have 485 implemented quarantine systems to block all outbound traffic sourced 486 from the offending end-customers. In either case, the perceived 487 disruption of the end-customer's Internet access often prompts a 488 help-desk call, which erodes the margins of the broadband access 489 provider and can cause end-customer dissatisfaction. 491 Increasingly, CPE devices themselves are targeted by attackers who 492 exploit security flaws in these devices in order to compromise them 493 and subsume them into botnets, and then leverage them to launch 494 outbound DDoS attacks. In all of the described scenarios, the end- 495 customers are unaware that their computers and/or CPE devices have 496 been compromised and are being used to launch outbound DDoS attacks - 497 however, they may notice a degradation of their Internet connectivity 498 as a result of outbound bandwidth consumption or other disruption. 500 By deploying DOTS-enabled telemetry systems and CPE devices (and 501 possibly requiring DOTS functionality in customer-provided CPE 502 devices), broadband access providers can utilize a standards-based 503 mechanism to suppress outbound DDoS attack traffic while optionally 504 allowing legitimate end-customer traffic to proceed unmolested. 506 In order to achieve this capability, the telemetry analysis system 507 utilized by the broadband access provider must have DOTS client 508 functionality, and the end-customer CPE devices must have DOTS server 509 functionality. When the telemetry analysis system detects and 510 classifies an outbound DDoS attack sourced from one or more end- 511 customer networks/devices, the DOTS client of the telemetry analysis 512 system sends a DOTS request to the DOTS server implemented on the CPE 513 devices, requesting local mitigation assistance in suppressing either 514 the identified outbound DDoS traffic, or all outbound traffic sourced 515 from the end-customer networks/devices. The DOTS server residing 516 within the CPE device(s) would then perform predefined actions such 517 as implementing on-board access-control lists (ACLs) to suppress the 518 outbound traffic in question and prevent it from leaving the local 519 end-customer network(s). 521 Broadband access network operators may choose to implement a 522 quarantine of all or selected network traffic originating from end- 523 customer networks/devices which are sourcing outbound DDoS traffic, 524 redirecting traffic from interactive applications such as Web 525 browsers to an internal portal which informs the end-customer of the 526 quarantine action, and providing instructions for self-remediation 527 and/or helpdesk contact information. 529 Quarantine systems for broadband access networks are typically 530 custom-developed and -maintained, and are generally deployed only by 531 a relatively small number of broadband access providers with 532 considerable internal software development and support capabilities. 533 By requiring the manufacturers of operator-supplied CPE devices to 534 implement DOTS server functionality, and requiring customer-provided 535 CPE devices to feature DOTS server functionality, broadband access 536 network operators who previously could not afford the development 537 expense of creating custom quarantine systems to integrate DOTS- 538 enabled network telemetry systems to act as DOTS clients and perform 539 effective quarantine of end-customer networks and devices until such 540 time as they have been remediated. 542 3.2.2. DDoS Orchestration 544 In this use case, one or multiple telemetry systems or monitoring 545 devices like a flow collector monitor a network -- typically an ISP 546 network. Upon detection of a DDoS attack, these telemetry systems 547 alert an orchestrator in charge of coordinating the various DDoS 548 mitigation systems within the domain. The telemetry systems may be 549 configured to provide some necessary or useful pieces of 550 informations, such as a preliminary analysis of the observation to 551 the orchestrator. 553 The orchestrator analyses the various information it receives from 554 specialized equipements, and elaborates one or multiple DDoS 555 mitigation strategies. In some case, a manual confirmation may also 556 be required to chose a proposed strategy or to start the DDoS 557 mitigation. The DDoS mitigation may consists in multiple steps such 558 as configuring the network, the various hardware or already 559 instantiated DDoS mitigation functions. In some cases, some specific 560 virtual DDoS mitigation functions need to be instantiated and 561 properly chained between each other. Eventually, the coordination of 562 the mitigation may involved external DDoS resources such as a transit 563 provider (Section 3.1.1) or an MSSP (Section 3.1.4). 565 The communication to trigger a DDoS mitigation between the telemetry 566 and monitoring systems and the orchestrator is performed using DOTS. 567 The telemetry systems implements a DOTS client while the Orchestrator 568 implements a DOTS server. 570 The communication between to select a DDoS strategy by a network 571 administrator and the orchestrator is also performed using DOTS. The 572 network administrator via its web interfaces implements a DOTS client 573 while the Orchestrator implements a DOTS server. 575 The communication between the Orchestrator and the DDoS mitigation 576 systems is performed using DOTS. The Orchestrator implements a DOTS 577 client while the DDoS mitigation systems implement a DOTS server. 579 The configuration aspects of each DDoS mitigation systems, as well as 580 the instantiations of DDoS mitigation functions or network 581 configuration is not part of DOTS. Similarly the discovery of the 582 available DDoS mitigation functions is not part of DOTS. 584 +----------+ 585 | network |C 586 | adminis |<-+ 587 | trator | | 588 +----------+ | 589 | (internal) 590 +----------+ | S+--------------+ +-----------+ 591 |telemetry/| +->| |C S| DDoS |+ 592 |monitoring|<--->| Orchestrator |<--->| mitigation|| 593 |systems |C S| |<-+ | systems || 594 +----------+ +--------------+C | +-----------+| 595 | +----------+ 596 | 597 | (external) 598 | +-----------+ 599 | S| DDoS | 600 +->| mitigation| 601 | systems | 602 +-----------+ 603 * C is for DOTS client functionality 604 * S is for DOTS server functionality 606 Figure 1: DDoS Orchestration 608 The telemetry systems monitor various traffic network and perform 609 their measurement tasks. They are configured so that when an event 610 or some measurements reach a predefined level to report a DOTS 611 mitigation request to the Orchestrator. The DOTS mitigation request 612 may be associated with some element such as specific reporting. 614 Upon receipt of the DOTS mitigation request from the telemetry 615 system, the orchestrator responds with an acknowledgement, to avoid 616 retransmission of the request for mitigation. The status of the DDoS 617 mitigation indicates the orchestrator is in an analysing phase. The 618 orchestrator begins collecting various informations from various 619 telemetry systems on the network in order to correlate the 620 measurements and provide an analyse of the event. Eventually, the 621 orchestrator may ask additional informations to the telemetry system 622 that just sent the DOTS request, however, the collection of these 623 information is performed outside DOTS. 625 The orchestrator may be configured to start a DDoS mitigation upon 626 approval from a network administrator. The analysis from the 627 orchestrator is reported to the network administrator via a web 628 interface. If the network administrator decides to start the 629 mitigation, she order through her web interface a DOTS client to send 630 a request for DDoS mitigation. This request is expected to be 631 associated with a context that identifies the DDoS mitigation 632 selected. 634 Upon receiving the DOTS request for DDoS mitigation from the network 635 administrator, the orchestrator orchestrates the DDoS mitigation 636 according to the specified strategy. It status first indicates the 637 DDoS mitigation is starting while not effective. 639 Orchestration of the DDoS mitigation systems works similarly as 640 described in Section 3.1.1 or Section 3.1.4. The orchestrator 641 indicates with its status the DDoS Mitigation is effective. 643 When the DDoS mitigation is finished on the DDoS mitigation systems, 644 the orchestrator indicates to the Telemetry systems as well as to the 645 network administrator the DDoS mitigation is finished. 647 4. Security Considerations 649 DOTS is at risk from three primary attacks: DOTS agent impersonation, 650 traffic injection, and signaling blocking. The DOTS protocol MUST be 651 designed for minimal data transfer to address the blocking risk. 653 Impersonation and traffic injection mitigation can be managed through 654 current secure communications best practices. DOTS is not subject to 655 anything new in this area. One consideration could be to minimize 656 the security technologies in use at any one time. The more needed, 657 the greater the risk of failures coming from assumptions on one 658 technology providing protection that it does not in the presence of 659 another technology. 661 Additional details of DOTS security requirements may be found in 662 [I-D.ietf-dots-requirements]. 664 5. IANA Considerations 666 No IANA considerations exist for this document at this time. 668 6. Acknowledgments 670 TBD 672 7. References 674 7.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 7.2. Informative References 683 [APACHE] "Apache mod_security", n.d., 684 . 686 [I-D.ietf-dots-requirements] 687 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 688 Denial of Service (DDoS) Open Threat Signaling 689 Requirements", draft-ietf-dots-requirements-05 (work in 690 progress), June 2017. 692 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 693 Cheshire, "Internet Assigned Numbers Authority (IANA) 694 Procedures for the Management of the Service Name and 695 Transport Protocol Port Number Registry", BCP 165, 696 RFC 6335, DOI 10.17487/RFC6335, August 2011, 697 . 699 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 700 Weil, "IPv6 Home Networking Architecture Principles", 701 RFC 7368, DOI 10.17487/RFC7368, October 2014, 702 . 704 [RRL] "BIND RRL", August 2014, 705 . 708 Authors' Addresses 710 Roland Dobbins 711 Arbor Networks 712 Singapore 714 EMail: rdobbins@arbor.net 715 Daniel Migault 716 Ericsson 717 8400 boulevard Decarie 718 Montreal, QC H4P 2N2 719 Canada 721 EMail: daniel.migault@ericsson.com 723 Stefan Fouant 724 USA 726 EMail: stefan.fouant@copperriverit.com 728 Robert Moskowitz 729 HTT Consulting 730 Oak Park, MI 48237 731 USA 733 EMail: rgm@labs.htt-consult.com 735 Nik Teague 736 Verisign 737 12061 Bluemont Way 738 Reston, VA 20190 740 EMail: nteague@verisign.com 742 Liang Xia 743 Huawei 744 No. 101, Software Avenue, Yuhuatai District 745 Nanjing 746 China 748 EMail: Frank.xialiang@huawei.com 750 Kaname Nishizuka 751 NTT Communications 752 GranPark 16F 3-4-1 Shibaura, Minato-ku 753 Tokyo 108-8118 754 Japan 756 EMail: kaname@nttv6.jp