idnits 2.17.1 draft-ietf-dots-use-cases-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2018) is 2192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-14 Summary: 0 errors (**), 0 flaws (~~), 2 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: September 29, 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 March 28, 2018 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-11 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide a 24 protocol to facilitate interoperability across disparate 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 https://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 September 29, 2018. 48 Copyright Notice 50 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . 3 68 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Upstream DDoS Mitigation between an Enterprise Network 71 and an Upstream Internet Transit Provider . . . . . . . . 4 72 3.2. DDoS Mitigation between an Enterprise Network and third 73 party DDoS Mitigation Service Provider . . . . . . . . . 7 74 3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 9 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 7.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 At the time of writing, distributed denial-of-service (DDoS) attack 86 mitigation solutions are largely based upon siloed, proprietary 87 communications schemes with vendor lock-in as a side-effect. This 88 can result in the configuration, provisioning, operation, and 89 activation of these solutions being a highly manual and often time- 90 consuming process. Additionally, coordination of multiple DDoS 91 mitigation solutions simultaneously is fraught with both technical 92 and process-related hurdles. This greatly increases operational 93 complexity which, in turn, can degrade the efficacy of mitigations. 95 The DDoS Open Threat Signaling (DOTS) effort is intended to specify a 96 protocol that facilitates interoperability between diverse DDoS 97 mitigation solutions and ensures greater integration in term of 98 mitigation requests and attack characterization patterns. As DDoS 99 solutions are broadly heterogeneous among vendors, the primary goal 100 of DOTS is to provide high-level interaction amongst differing DDoS 101 solutions, such as initiating, terminating DDoS mitigation assistance 102 or requesting the status of a DDoS mitigation. 104 This document provides use cases to provide inputs for the design of 105 the DOTS protocol(s) as well as to illustrate the purpose of goals. 106 The use cases are not exhaustive and future use cases are expected to 107 emerge as DOTS is adopted and evolves. 109 2. Terminology and Acronyms 111 2.1. Requirements Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2.2. Acronyms 119 This document makes use of the same terminology and definitions as 120 [I-D.ietf-dots-requirements]. In addition it uses the terms defined 121 below: 123 o DDoS Mitigation Service Provider: designates the administrative 124 entity providing the DDoS Mitigation Service. 126 o DDoS Mitigation Service: designates a service provides to a 127 customer. Services usually involves Service Level Agreement (SLA) 128 that have to be met. It is the responsibility of the service 129 provider to instantiate the DDoS Mitigation System to meet these 130 SLA. 132 o DDoS Mitigation System (DMS): A system that performs DDoS 133 mitigation. The DDoS Mitigation System may be composed by a 134 cluster of hardware and/or software resources, but could also 135 involve an orchestrator that may take decisions such as 136 outsourcing partial or more of the mitigation to another DDoS 137 Mitigation System. 139 o DDoS Mitigation: The action performed by the DDoS Mitigation 140 System. 142 o Internet Transit Provider (ITP): 144 3. Use Cases 146 3.1. Upstream DDoS Mitigation between an Enterprise Network and an 147 Upstream Internet Transit Provider 149 This use case describes how an enterprise network may take advantage 150 of a pre-existing relation with its Internet Transit Provider (ITP) 151 in order to mitigate a DDoS attack targeting its network. As the ITP 152 provides connectivity to the enterprise network, it is already on the 153 path of the inbound or outbound traffic of the enterprise network and 154 well aware of the networking parameters associated to the enterprise 155 network connectivity. This eases both the configuration and the 156 instantiation of a DDoS Mitigation Service. This section considers 157 two kind of DDoS Mitigation Service between an enterprise network and 158 an ITP: 160 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 161 upon receiving a request from the enterprise network. This 162 typically corresponds to the case when the enterprise network is 163 under attack. 165 o On the other hand, the ITP may identify an enterprise network as 166 the source of an attack and send a mitigation request for the 167 enterprise to mitigate this at the source. 169 In the first scenario, as depicted in Figure 1, an enterprise network 170 with self-hosted Internet-facing properties such as Web servers, 171 authoritative DNS servers, and VoIP PBXes has a DMS deployed to 172 protect those servers and applications from DDoS attacks. In 173 addition to their on-premise DDoS defense capability, they have 174 contracted with their Internet transit provider for DDoS Mitigation 175 Services which threaten to overwhelm their transit link bandwidth. 177 +------------------+ +------------------+ 178 | Entreprise | | Upstream | 179 | Network | | Internet Transit | 180 | | | Provider | 181 | +--------+ | | DDoS Attack 182 | | DDoS | | <================================= 183 | | Target | | <================================= 184 | +--------+ | | +------------+ | 185 | | +-------->| DDoS | | 186 | | | |S | Mitigation | | 187 | | | | | System | | 188 | | | | +------------+ | 189 | | | | | 190 | | | | | 191 | +------------+ | | | | 192 | | DDoS |<---+ | | 193 | | Mitigation |C | | | 194 | | System | | | | 195 | +------------+ | | | 196 +------------------+ +------------------+ 198 * C is for DOTS Client functionality 199 * S is for DOTS Server functionality 201 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 203 The enterprise DMS is configured such that if the incoming Internet 204 traffic volume exceeds 50% of the provisioned upstream Internet 205 transit link capacity, the DMS will request DDoS mitigation 206 assistance from the upstream transit provider. 208 The requests to trigger, manage, and finalize a DDoS Mitigation 209 between the enterprise DMS and the ITP is performed using DOTS. The 210 enterprise DMS implements a DOTS Client while the ITP implements a 211 DOTS Server which is integrated with their DMS. 213 When the enterprise DMS detects an inbound DDoS attack targeting its 214 servers and applications, it immediately begins a DDoS Mitigation. 216 During the course of the attack, the inbound traffic volume exceeds 217 the 50% threshold; the DMS DOTS Client signals the DOTS Server on the 218 upstream ITP to initiate DDoS Mitigation. The DOTS Server signals 219 the DOTS Client that it can serve this request, and mitigation is 220 initiated on the ITP network by the DMS. 222 Over the course of the attack, the DOTS Server of the ITP 223 periodically informs the DOTS Client on the enterprise DMS mitigation 224 status, statistics related to DDoS attack traffic mitigation, and 225 related information. Once the DDoS attack has ended, the DOTS Server 226 signals the enterprise DMS DOTS Client that the attack has subsided. 228 The enterprise DMS then requests the ITP to terminate the DDoS 229 Mitigation. The DOTS Server on the ITP receives this request and 230 once the mitigation has ended, confirms the end of upstream DDoS 231 Mitigation to the enterprise DMS DOTS Client. 233 The following is an overview of the DOTS communication model for this 234 use-case: 236 o (a) A DDoS attack is initiated against online properties of an 237 network organization which has deployed a DOTS-Client-capable DMS. 239 o (b) The DMS detects, classifies, and begins the DDoS Mitigation. 241 o (c) The DMS determines that its capacity and/or capability to 242 mitigate the DDoS attack is insufficient, and sends via its DOTS 243 Client a DOTS DDoS Mitigation request to one or more DOTS Servers 244 residing on the upstream ITP. 246 o (d) The DOTS Server which receive the DOTS Mitigation request 247 determines that they have been configured to honor requests from 248 the requesting DOTS Client, and honored its DDoS Mitigation by 249 orchestrating its DMS. 251 o (e) While the DDoS Mitigation is active, the DOTS Servers 252 regularly transmit DOTS DDoS Mitigation status updates to the DOTS 253 Client. 255 o (f) The DOTS Client transmits a DOTS DDoS Mitigation termination 256 request to the DOTS Server. 258 o (g) The DOTS Server terminates DDoS Mitigation. 260 Note that communications between the enterprise DOTS Client and the 261 upstream transit provider DOTS Server may take place in-band within 262 the main Internet transit link between the enterprise and the ITP; 263 out-of-band via a separate, dedicated wireline network link utilized 264 solely for DOTS signaling; or out-of-band via some other form of 265 network connectivity such as a third-party wireless 4G network link. 267 Note also that the DOTS Clients that sends the DOTS Mitigation 268 request may be also triggered by a network admin that manually 269 confirms the request to the upstream ITP, in which case the request 270 my be sent from an application such as a web browser in a mobile 271 phone. 273 Note also that when the enterprise is multihomed and connected to 274 multiple upstream ITP, each ITP is only able to provide a DDoS 275 Mitigation Service for the traffic it transits. As a result, the 276 enterprise network may require to coordinate the various DDoS 277 Mitigation Services associated to each link. 279 The current scenario describes the case where the DDoS Target is in 280 the enterprise network while the DMS is provided by the upstream ITP. 281 An alternate use case may consider the case where the ITP informs the 282 enterprise network it is involved into an ongoing attack or that 283 infected machines have been identified. In this case the DOTS Client 284 and DOTS Server roles are inverted. The DOTS Client is located in 285 the ITP network and the DOTS Server is hosted in the enterprise 286 network. The enterprise network is then responsible to perform the 287 DDoS Mitigation. In some case the DDoS Mitigation may be delegated 288 back to the upstream ITP, as described in this section. 290 3.2. DDoS Mitigation between an Enterprise Network and third party DDoS 291 Mitigation Service Provider 293 This use case differs from the previous use case in that the DDoS 294 Mitigation Service is not provided by an upstream ITP. In other 295 words, as represented in figure 2, the traffic does not not go 296 through the DDoS Mitigation Service Provider by default. In order to 297 steer the traffic to the DDoS Mitigation Service Provider, some 298 network configuration are required. As such it may be reserved for 299 large enterprises or large data centers. 301 We follow the terminology of section Section 3.1, however the 302 Enterprise Network is not limited to the network hosting the DDoS 303 Target. In fact, it could also be a DDoS Mitigation Service Provider 304 that has reached it resources capacities and delegate the DDoS 305 Mitigation to other DDoS Mitigation Service Providers, thus forming 306 an overlay of DMS. 308 +------------------+ +------------------+ 309 | Entreprise | | Upstream | 310 | Network | | Internet Transit | 311 | | | Provider | 312 | +--------+ | | DDoS Attack 313 | | DDoS | | <================================= 314 | | Target | | <================================= 315 | +--------+ | | | 316 | | +------------------+ 317 | | 318 | | +------------------+ 319 | | | DDoS Mitigation | 320 | | | Service Provider | 321 | | | | 322 | +------------+ | | +------------+ | 323 | | DDoS |<------------>| DDoS | | 324 | | Mitigation |C | | S| Mitigation | | 325 | | System | | | | System | | 326 | +------------+ | | +------------+ | 327 +------------------+ +------------------+ 329 * C is for DOTS Client functionality 330 * S is for DOTS Server functionality 332 Figure 2: DDoS Mitigation between an Enterprise Network and third 333 party DDoS Mitigation Service Provider 335 In this scenario, an Enterprise Network has entered into a pre- 336 arranged DDoS mitigation assistance agreement with one or more other 337 DDoS Mitigation Service Providers in order to ensure that sufficient 338 DDoS mitigation capacity and/or capabilities may be activated in the 339 event that a given DDoS attack threatens to overwhelm the ability of 340 a given DMS to mitigate the attack on its own. 342 The pre-arrangement typically includes the agreement on the 343 mechanisms used to redirect the traffic to the DDoS Mitigation 344 Service Provider, as well as the mechanism to to re-inject the 345 traffic back to the Enterprise Network. Redirection to the DDoS 346 Mitigation Service Provider typically involves BGP prefix 347 announcement eventually combined with DNS redirection, while re- 348 injection may be performed via tunneling mechanisms such as GRE for 349 example. Of course, such mechanisms needs to be regularly tested and 350 evaluated. 352 +------------------+ +------------------+ 353 | Entreprise | | Upstream | 354 | Network | | Internet Transit | 355 | | | Provider | 356 | +--------+ | | DDoS Attack 357 | | DDoS | |<----------------+ | ++==== 358 | | Target | | | | | || ++= 359 | +--------+ | | | | || || 360 | | +--------|---------+ || || 361 | | | || || 362 | | +--------|---------+ || || 363 | | | DDoS Mitigation | || || 364 | | | Service Provider | || || 365 | | | | | || || 366 | +------------+ | | +------------+ | || || 367 | | DDoS |<------------>| DDoS | | || || 368 | | mitigation |C | |S | mitigation |<===++ || 369 | | system | | | | system |<======++ 370 | +------------+ | | +------------+ | 371 +------------------+ +------------------+ 373 * C is for DOTS Client functionality 374 * S is for DOTS Server functionality 376 Figure 3: Redirection to a DDoS Mitigation Service Provider 378 When the Enterprise Network is under attack or at least is reaching 379 its capacity or ability to mitigate a given DDoS attack traffic, the 380 DOTS Client sends a DOTS request to the DDoS Mitigation Service 381 Provider to initiate network traffic diversion - as represented in 382 figure 3 - and DDoS mitigation activities. Ongoing attack and 383 mitigation status messages may be passed between the Enterprise 384 Network and the DDoS Mitigation Service Provider. 386 Once the requesting Enterprise Network is confident that the DDoS 387 attack has either ceased or has fallen to levels of traffic/ 388 complexity which they can handle on their own or that it has received 389 a DOTS DDoS Mitigation termination request from a downstream 390 Enterprise Network or DDoS Mitigation Service Provider, the 391 requesting Enterprise Network DOTS Client sends a DOTS DDoS 392 Mitigation termination requests to the DDoS Mitigation Service 393 Provider. 395 3.3. DDoS Orchestration 397 In this use case, one or more DDoS telemetry systems or monitoring 398 devices such as a flow telemetry collector monitor a network - 399 typically an ISP network. Upon detection of a DDoS attack, these 400 telemetry systems alert an orchestrator in charge of coordinating the 401 various DMS within the domain. The telemetry systems may be 402 configured to provide necessary and useful pieces of information, 403 such as a preliminary analysis of the observation to the 404 orchestrator. 406 The orchestrator analyses the various information it receives from 407 specialized equipements, and elaborates one or multiple DDoS 408 mitigation strategies. In some case, a manual confirmation may also 409 be required to choose a proposed strategy or to initiate a DDoS 410 Mitigation. The DDoS Mitigation may consist of multiple steps such 411 as configuring the network, various hardware, or updating already 412 instantiated DDoS mitigation functions. In some cases, some specific 413 virtual DDoS mitigation functions must be instantiated and properly 414 ordered. Eventually, the coordination of the mitigation may involve 415 external DDoS resources such as a transit provider or a DDoS 416 Mitigation Service Provider. 418 The communications used to trigger a DDoS Mitigation between the 419 telemetry and monitoring systems and the orchestrator is performed 420 using DOTS. The telemetry systems implements a DOTS Client while the 421 orchestrator implements a DOTS Server. 423 The communication between a network administrator and the 424 orchestrator is also performed using DOTS. The network administrator 425 via its web interfaces implements a DOTS Client, while the 426 Orchestrator implements a DOTS Server. 428 The communication between the Orchestrator and the DDoS mitigation 429 systems is performed using DOTS. The Orchestrator implements a DOTS 430 Client while the DDoS mitigation systems implement a DOTS Server. 432 The configuration aspects of each DDoS mitigation system, as well as 433 the instantiations of DDoS mitigation functions or network 434 configuration is not part of DOTS. Similarly, the discovery of 435 available DDoS mitigation functions is not part of DOTS. 437 +----------+ 438 | network |C 439 | adminis |<-+ 440 | trator | | 441 +----------+ | 442 | (internal) 443 +----------+ | S+--------------+ +-----------+ 444 |telemetry/| +->| |C S| DDoS |+ 445 |monitoring|<--->| Orchestrator |<--->| mitigation|| 446 |systems |C S| |<-+ | systems || 447 +----------+ +--------------+C | +-----------+| 448 | +----------+ 449 | 450 | (external) 451 | +-----------+ 452 | S| DDoS | 453 +->| mitigation| 454 | systems | 455 +-----------+ 456 * C is for DOTS Client functionality 457 * S is for DOTS Server functionality 459 Figure 4: DDoS Orchestration 461 The telemetry systems monitor various traffic network and perform 462 their measurement tasks. They are configured so that when an event 463 or some measurements reach a predefined level to report a DOTS 464 mitigation request to the Orchestrator. The DOTS mitigation request 465 may be associated with some element such as specific reporting. 467 Upon receipt of the DOTS mitigation request from the telemetry 468 system, the Orchestrator responds with an acknowledgment, to avoid 469 retransmission of the request for mitigation. The status of the DDoS 470 mitigation indicates the Orchestrator is in an analyzing phase. The 471 Orchestrator begins collecting various information from various 472 telemetry systems in order to correlate the measurements and provide 473 an analysis of the event. Eventually, the Orchestrator may ask 474 additional information to the telemetry system, however, the 475 collection of these information is performed outside DOTS. 477 The orchestrator may be configured to start a DDoS Mitigation upon 478 approval from a network administrator. The analysis from the 479 orchestrator is reported to the network administrator via a web 480 interface. If the network administrator decides to start the 481 mitigation, she orders through her web interface a DOTS Client to 482 send a request for DDoS mitigation. This request is expected to be 483 associated with a context that identifies the DDoS mitigation 484 selected. 486 Upon receiving the DOTS request for DDoS mitigation from the network 487 administrator, the orchestrator orchestrates the DDoS mitigation 488 according to the specified strategy. Its status indicates the DDoS 489 mitigation is starting while not effective. 491 Orchestration of the DDoS mitigation systems works similarly as 492 described in Section XXX. The Orchestrator indicates with its status 493 whether the DDoS Mitigation is effective. 495 When the DDoS mitigation is finished on the DDoS mitigation systems, 496 the orchestrator indicates to the Telemetry systems as well as to the 497 network administrator the DDoS mitigation is finished. 499 4. Security Considerations 501 DOTS is at risk from three primary attacks: DOTS agent impersonation, 502 traffic injection, and signaling blocking. The DOTS protocol MUST be 503 designed for minimal data transfer to address the blocking risk. 505 Impersonation and traffic injection mitigation can be managed through 506 current secure communications best practices. DOTS is not subject to 507 anything new in this area. One consideration could be to minimize 508 the security technologies in use at any one time. The more needed, 509 the greater the risk of failures coming from assumptions on one 510 technology providing protection that it does not in the presence of 511 another technology. 513 Additional details of DOTS security requirements may be found in 514 [I-D.ietf-dots-requirements]. 516 5. IANA Considerations 518 No IANA considerations exist for this document at this time. 520 6. Acknowledgments 522 The authors would like to thank among others Tirumaleswar Reddy; 523 Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; and the 524 DOTS WG chairs, Roman D. Danyliw and Tobias Gondrom, for their 525 valuable feedback. 527 7. References 529 7.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, 534 . 536 7.2. Informative References 538 [I-D.ietf-dots-requirements] 539 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 540 Denial of Service (DDoS) Open Threat Signaling 541 Requirements", draft-ietf-dots-requirements-14 (work in 542 progress), February 2018. 544 Authors' Addresses 546 Roland Dobbins 547 Arbor Networks 548 Singapore 550 EMail: rdobbins@arbor.net 552 Daniel Migault 553 Ericsson 554 8275 Trans Canada Route 555 Saint Laurent, QC 4S 0B6 556 Canada 558 EMail: daniel.migault@ericsson.com 560 Stefan Fouant 561 USA 563 EMail: stefan.fouant@copperriverit.com 565 Robert Moskowitz 566 HTT Consulting 567 Oak Park, MI 48237 568 USA 570 EMail: rgm@labs.htt-consult.com 571 Nik Teague 572 Verisign 573 12061 Bluemont Way 574 Reston, VA 20190 576 EMail: nteague@verisign.com 578 Liang Xia 579 Huawei 580 No. 101, Software Avenue, Yuhuatai District 581 Nanjing 582 China 584 EMail: Frank.xialiang@huawei.com 586 Kaname Nishizuka 587 NTT Communications 588 GranPark 16F 3-4-1 Shibaura, Minato-ku 589 Tokyo 108-8118 590 Japan 592 EMail: kaname@nttv6.jp