idnits 2.17.1 draft-ietf-dots-use-cases-17.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 (January 10, 2019) is 1904 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-16 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: July 14, 2019 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 January 10, 2019 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-17 21 Abstract 23 The DDoS Open Threat Signaling (DOTS) effort is intended to provide 24 protocols to facilitate interoperability across disparate DDoS 25 mitigation solutions. This document presents use cases which 26 describe the interactions expected between the DOTS components as 27 well as DOTS messaging exchanges. These use cases are meant to 28 identify the interacting DOTS components, how they collaborate and 29 what are the typical 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 July 14, 2019. 48 Copyright Notice 50 Copyright (c) 2019 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 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit 69 Provider . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service 71 Provider . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Informative References . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 At the time of writing, distributed denial-of-service (DDoS) attack 82 mitigation solutions are largely based upon siloed, proprietary 83 communications schemes with vendor lock-in as a side-effect. This 84 can result in the configuration, provisioning, operation, and 85 activation of these solutions being a highly manual and often time- 86 consuming process. Additionally, coordinating multiple DDoS 87 mitigation solutions simultaneously is fraught with both technical 88 and process-related hurdles. This greatly increases operational 89 complexity which, in turn, can degrade the efficacy of mitigations. 91 The DDoS Open Threat Signaling (DOTS) effort is intended to specify 92 protocols that facilitate interoperability between diverse DDoS 93 mitigation solutions and ensure greater integration in term of 94 mitigation requests and attack characterization patterns. As DDoS 95 solutions are broadly heterogeneous among vendors, the primary goal 96 of DOTS is to provide high-level interaction amongst differing DDoS 97 solutions, such as initiating, terminating DDoS mitigation assistance 98 or requesting the status of a DDoS mitigation. 100 This document provides use cases to provide inputs for the design of 101 the DOTS protocol(s). The use cases are not exhaustive and future 102 use cases are expected to emerge as DOTS is adopted and evolves. 104 2. Terminology and Acronyms 106 This document makes use of the same terminology and definitions as 107 [I-D.ietf-dots-requirements]. In addition it uses the terms defined 108 below: 110 o DDoS Mitigation Service Provider: designates the administrative 111 entity providing the DDoS Mitigation Service. 113 o DDoS Mitigation System (DMS): A system that performs DDoS 114 mitigation. The DDoS Mitigation System may be composed by a 115 cluster of hardware and/or software resources, but could also 116 involve an orchestrator that may take decisions such as 117 outsourcing partial or more of the mitigation to another DDoS 118 Mitigation System. 120 o DDoS Mitigation: The action performed by the DDoS Mitigation 121 System. 123 o DDoS Mitigation Service: designates a DDoS mitigation service 124 provided to a customer and which is scoped to mitigate DDoS 125 attacks. Services usually involve Service Level Agreement (SLA) 126 that have to be met. It is the responsibility of the DDoS Service 127 provider to instantiate the DDoS Mitigation System to meet these 128 SLAs. 130 o Internet Transit Provider (ITP): designates the entity that 131 delivers the traffic to the network. It can be an Internet 132 Service Provider (ISP), or an upstream entity delivering the 133 traffic to the ISP. 135 3. Use Cases 137 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider 139 This use case describes how an enterprise or a residential customer 140 network may take advantage of a pre-existing relation with its 141 Internet Transit Provider (ITP) in order to mitigate a DDoS attack 142 targeting its network. To improve the clarity of our purpose, the 143 targeted network will be designated as enterprise network, but the 144 same scenario applies to any downstream network, including 145 residential network and cloud hosting network. As the ITP provides 146 connectivity to the enterprise network, it is already on the path of 147 the inbound or outbound traffic of the enterprise network and well 148 aware of the networking parameters associated to the enterprise 149 network connectivity. This eases both the configuration and the 150 instantiation of a DDoS Mitigation Service. This section considers 151 two kind of DDoS Mitigation Service between an enterprise network and 152 an ITP: 154 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 155 upon receiving a request from the enterprise network. This 156 typically corresponds to the case when the enterprise network is 157 under attack. 159 o On the other hand, the ITP may identify an enterprise network as 160 the source of an attack and send a mitigation request to the 161 enterprise DMS to mitigate this at the source. 163 In the first scenario, as depicted in Figure 1, an enterprise network 164 with self-hosted Internet-facing properties such as Web servers, 165 authoritative DNS servers, and VoIP servers has a DMS deployed to 166 protect those servers and applications from DDoS attacks. In 167 addition to on-premise DDoS defense capability, enterprises have 168 contracted with their ITP for DDoS Mitigation Services which threaten 169 to overwhelm their WAN link(s) bandwidth. 171 +------------------+ +------------------+ 172 | Enterprise | | Upstream | 173 | Network | | Internet Transit | 174 | | | Provider | 175 | +--------+ | | DDoS Attack 176 | | DDoS | | <================================= 177 | | Target | | <================================= 178 | +--------+ | | +------------+ | 179 | | +-------->| DDoS | | 180 | | | |S | Mitigation | | 181 | | | | | System | | 182 | | | | +------------+ | 183 | | | | | 184 | | | | | 185 | | | | | 186 | +------------+ | | | | 187 | | DDoS |<---+ | | 188 | | Mitigation |C | | | 189 | | System | | | | 190 | +------------+ | | | 191 +------------------+ +------------------+ 193 * C is for DOTS client functionality 194 * S is for DOTS server functionality 196 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 198 The enterprise DMS is configured such that if the incoming Internet 199 traffic volume exceeds 50% of the provisioned upstream Internet WAN 200 link capacity, the DMS will request DDoS mitigation assistance from 201 the upstream transit provider. 203 The requests to trigger, manage, and finalize a DDoS Mitigation 204 between the enterprise DMS and the ITP is performed using DOTS. The 205 enterprise DMS implements a DOTS client while the ITP implements a 206 DOTS server which is integrated with their DMS. 208 When the enterprise DMS detects an inbound DDoS attack targeting its 209 resources ( e.g. servers, hosts or applications), it immediately 210 begins a DDoS Mitigation. 212 During the course of the attack, the inbound traffic volume exceeds 213 the 50% threshold; the DMS DOTS client signals the DOTS server on the 214 upstream ITP to initiate DDoS Mitigation. The DOTS server signals 215 the DOTS client that it can serve this request, and mitigation is 216 initiated on the ITP network by the ITP DMS. 218 Over the course of the attack, the DOTS server of the ITP 219 periodically informs the DOTS client on the enterprise DMS mitigation 220 status, statistics related to DDoS attack traffic mitigation, and 221 related information. Once the DDoS attack has ended, or decreased to 222 the certain level that the DOTS client can handle by itself, the DOTS 223 server signals the enterprise DMS DOTS client that the attack has 224 subsided. 226 The enterprise DMS then requests the ITP to terminate the DDoS 227 Mitigation. The DOTS server on the ITP receives this request and 228 once the mitigation has ended, confirms the end of upstream DDoS 229 Mitigation to the enterprise DMS DOTS client. 231 The following is an overview of the DOTS communication model for this 232 use-case: 234 o (a) A DDoS attack is initiated against resources of a network 235 organization which has deployed a DOTS-capable DMS - typically a 236 DOTS client. 238 o (b) The enterprise DMS detects, classifies, and begins the DDoS 239 Mitigation. 241 o (c) The enterprise DMS determines that its capacity and/or 242 capability to mitigate the DDoS attack is insufficient, and sends 243 via its DOTS client a DOTS DDoS Mitigation request to one or more 244 DOTS servers residing on the upstream ITP. 246 o (d) The DOTS server which receives the DOTS Mitigation request 247 determines that it has been configured to honor requests from the 248 requesting DOTS client, and honored its DDoS Mitigation by 249 orchestrating its DMS. 251 o (e) While the DDoS Mitigation is active, DOTS server regularly 252 transmits DOTS DDoS Mitigation status updates to the DOTS client. 254 o (f) Informed by the DOTS server status update that the attack has 255 ended or subsided, the DOTS client transmits a DOTS DDoS 256 Mitigation termination request to the DOTS server. 258 o (g) The DOTS server terminates DDoS Mitigation, and sends the 259 notification to the DOTS client. 261 Note that communications between the enterprise DOTS client and the 262 upstream ITP DOTS Server may take place in-band within the main 263 Internet WAN link between the enterprise and the ITP; out-of-band via 264 a separate, dedicated wireline network link utilized solely for DOTS 265 signaling; or out-of-band via some other form of network connectivity 266 such as a third-party wireless 4G network connectivity. 268 Note also that a DOTS client that sends a DOTS Mitigation request may 269 be also triggered by a network admin that manually confirms the 270 request to the upstream ITP, in which case the request may be sent 271 from an application such as a web browser or a dedicated mobile 272 application. 274 Note also that when the enterprise is multihomed and connected to 275 multiple upstream ITPs, each ITP is only able to provide a DDoS 276 Mitigation Service for the traffic it transits. As a result, the 277 enterprise network may require to coordinate the various DDoS 278 Mitigation Services associated to each link. More multi-homing 279 considerations are discussed in [I-D.boucadair-dots-multihoming]. 281 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider 283 This use case differs from the previous use case described in 284 Section 3.1 in that the DDoS Mitigation Service is not provided by an 285 upstream ITP. In other words, as represented in Figure 2, the 286 traffic is not forwarded through the DDoS Mitigation Service Provider 287 by default. In order to steer the traffic to the DDoS Mitigation 288 Service Provider, some network configuration changes are required. 289 As such, this use case likely to match large enterprises or large 290 data centers, but not exclusively. Another typical scenario for this 291 use case is the relation between DDoS Mitigation Service Providers 292 forming an overlay of DMS. When a DDoS Mitigation Service Provider 293 mitigating a DDoS attack reaches it resources capacities, it may 294 chose to delegate the DDoS Mitigation to another DDoS Mitigation 295 Service Provider. 297 +------------------+ +------------------+ 298 | Enterprise | | Upstream | 299 | Network | | Internet Transit | 300 | | | Provider | 301 | +--------+ | | DDoS Attack 302 | | DDoS | | <================================= 303 | | Target | | <================================= 304 | +--------+ | +----------------------------+ 305 | | | | | | 306 | | | +------------------+ | 307 | | | | 308 | | | +------------------+ | 309 | | | | DDoS Mitigation | | 310 | | | | Service Provider | | 311 | | | | | | 312 | +------------+ | | | +------------+ | | 313 | | DDoS |<---+ | | DDoS |<----+ 314 | | Mitigation |C | | | Mitigation |S | 315 | | System | | | | System | | 316 | +------------+ | | +------------+ | 317 +------------------+ +------------------+ 319 * C is for DOTS client functionality 320 * S is for DOTS server functionality 322 Figure 2: DDoS Mitigation between an Enterprise Network and Third 323 Party DDoS Mitigation Service Provider 325 In this scenario, an Enterprise Network has entered into a pre- 326 arranged DDoS mitigation assistance agreement with one or more other 327 DDoS Mitigation Service Providers in order to ensure that sufficient 328 DDoS mitigation capacity and/or capabilities may be activated in the 329 event that a given DDoS attack threatens to overwhelm the ability of 330 a given DMS to mitigate the attack on its own. 332 The pre-arrangement typically includes the agreement on the 333 mechanisms used to redirect the traffic to the DDoS Mitigation 334 Service Provider, as well as the mechanism to re-inject the traffic 335 back to the Enterprise Network. Redirection to the DDoS Mitigation 336 Service Provider typically involves BGP prefix announcement or DNS 337 redirection, while re-injection of the scrubbed traffic to the 338 enterprise network may be performed via tunneling mechanisms such as 339 GRE for example. These exact mechanisms used for traffic steering 340 are out of scope. 342 +------------------+ +------------------+ 343 | Enterprise | | Upstream | 344 | Network | | Internet Transit | 345 | | | Provider | 346 | +--------+ | | DDoS Attack 347 | | DDoS | |<----------------+ | ++==== 348 | | Target | | Mitigated | | || ++= 349 | +--------+ | | | | || || 350 | | | | | || || 351 | | +--------|---------+ || || 352 | | | || || 353 | | +--------|---------+ || || 354 | | | DDoS Mitigation | || || 355 | | | Service Provider | || || 356 | | | | | || || 357 | +------------+ | | +------------+ | || || 358 | | DDoS |<------------>| DDoS | | || || 359 | | mitigation |C | |S | mitigation |<===++ || 360 | | system | | | | system |<======++ 361 | +------------+ | | +------------+ | 362 +------------------+ +------------------+ 364 * C is for DOTS client functionality 365 * S is for DOTS server functionality 367 Figure 3: Redirection to a DDoS Mitigation Service Provider 369 When the Enterprise Network is under attack or at least is reaching 370 its capacity or ability to mitigate a given DDoS attack traffic, the 371 DOTS client sends a DOTS request to the DDoS Mitigation Service 372 Provider to initiate network traffic diversion - as represented in 373 Figure 3 - and DDoS mitigation activities. Ongoing attack and 374 mitigation status messages may be passed between the Enterprise 375 Network and the DDoS Mitigation Service Provider. If the DDoS attack 376 has stopped or the severity of the attack has subsided, the DOTS 377 client can request the DDoS Mitigation Service Provider to stop the 378 DDoS Mitigation. 380 3.3. DDoS Orchestration 382 In this use case, one or more DDoS telemetry systems or monitoring 383 devices monitor a network - typically an ISP network, an Enterprise 384 network, or a data center. Upon detection of a DDoS attack, these 385 DDoS telemetry systems alert an orchestrator in charge of 386 coordinating the various DMS within the domain. The DDoS telemetry 387 systems may be configured to provide required information, such as a 388 preliminary analysis of the observation to the orchestrator. 390 The orchestrator analyses the various information it receives from 391 DDoS telemetry system, and initiates one or multiple DDoS mitigation 392 strategies. For example, the orchestrator could select the DDoS 393 mitigation system in the Enterprise network or one provided by the 394 ITP. DDoS Mitigation System selection and DDoS Mitigation technique 395 may depends on the type of DDoS attack. In some case, a manual 396 confirmation or selection may also be required to choose a proposed 397 strategy to initiate a DDoS Mitigation. The DDoS Mitigation may 398 consist of multiple steps such as configuring the network, or 399 updating already instantiated DDoS mitigation functions. Eventually, 400 the coordination of the mitigation may involve external DDoS 401 mitigation resources such as a transit provider or a Third Party DDoS 402 Mitigation Service Provider. 404 The communication used to trigger a DDoS Mitigation between the DDoS 405 telemetry and monitoring systems and the orchestrator is performed 406 using DOTS. The DDoS telemetry system implements a DOTS client while 407 the orchestrator implements a DOTS server. 409 The communication between a network administrator and the 410 orchestrator is also performed using DOTS. The network administrator 411 via its web interfaces implements a DOTS client, while the 412 Orchestrator implements a DOTS server. 414 The communication between the orchestrator and the DDoS mitigation 415 systems is performed using DOTS. The orchestrator implements a DOTS 416 Client while the DDoS mitigation systems implement a DOTS Server. 418 The configuration aspects of each DDoS mitigation system, as well as 419 the instantiations of DDoS mitigation functions or network 420 configuration is not part of DOTS. Similarly, the discovery of 421 available DDoS mitigation functions is not part of DOTS; and as such 422 is out of scope. 424 +----------+ 425 | network |C (Enterprise Network) 426 | adminis |<-+ 427 | trator | | 428 +----------+ | 429 | 430 +----------+ | S+--------------+ +-----------+ 431 |telemetry/| +->| |C S| DDoS |+ 432 |monitoring|<--->| Orchestrator |<--->| mitigation|| 433 |systems |C S| |<-+ | systems || 434 +----------+ +--------------+C | +-----------+| 435 | +----------+ 436 -----------------------------------|----------------- 437 | 438 | 439 (Internet Transit Provider) | 440 | +-----------+ 441 | S| DDoS | 442 +->| mitigation| 443 | systems | 444 +-----------+ 445 * C is for DOTS client functionality 446 * S is for DOTS server functionality 448 Figure 4: DDoS Orchestration 450 The DDoS telemetry systems monitor various network traffic and 451 perform some measurement tasks. 453 These systems are configured so that when an event or some 454 measurement indicators reach a predefined level to send DOTS 455 mitigation request to the orchestrator. The DOTS mitigation request 456 may be associated with some optional mitigation hints to let the 457 orchestrator know what has triggered the request. 459 Upon receipt of the DOTS mitigation request from the DDoS telemetry 460 system, the orchestrator responds with an acknowledgment, to avoid 461 retransmission of the request for mitigation. The orchestrator may 462 begin collecting additional fined grain and specific information from 463 various DDoS telemetry systems in order to correlate the measurements 464 and provide an analysis of the event. Eventually, the orchestrator 465 may ask additional information to the DDoS telemetry system, however, 466 the collection of these information is out of scope. 468 The orchestrator may be configured to start a DDoS Mitigation upon 469 approval from a network administrator. The analysis from the 470 orchestrator is reported to the network administrator via a web 471 interface. If the network administrator decides to start the 472 mitigation, the network administrator triggers the DDoS mitigation 473 request using the web interface of a DOTS client connected to the 474 orchestrator. This request is expected to be associated with a 475 context that provides sufficient information to the orchestrator to 476 infer the DDoS Mitigation to elaborate and coordinate. 478 Upon receiving a request to mitigate a DDoS attack performed over a 479 target, the orchestrator, may evaluate the volumetry of the attack as 480 well as the value that represent the target. The orchestrator may 481 select the DDoS Mitigation Service Provider based on the attack 482 severity. It may also coordinate the DDoS Mitigation performed by 483 the DDoS Mitigation Service Provider with some other tasks such as 484 for example, moving the target to another network so new sessions 485 will not be impacted. When DDoS Mitigation is requested, the status 486 indicates the DDoS Mitigation is starting while not effective. The 487 DOTS client of the orchestrator will later be notified that the DDoS 488 Mitigation is effective. 490 Orchestration of the DDoS mitigation systems works similarly as 491 described in Section 3.1. The orchestrator indicates with its status 492 whether the DDoS Mitigation is effective. 494 When the DDoS attack has stopped, the orchestrator indicates to the 495 DDoS telemetry systems as well as to the network administrator the 496 end of the DDoS Mitigation. 498 4. Security Considerations 500 The document does not describe any protocol. 502 DOTS is at risk from three primary attacks: DOTS agent impersonation, 503 traffic injection, and signaling blocking. 505 Impersonation and traffic injection mitigation can be mitigated 506 through current secure communications best practices. 508 Additional details of DOTS security requirements can be found in 509 [I-D.ietf-dots-requirements]. 511 5. IANA Considerations 513 No IANA considerations exist for this document at this time. 515 6. Acknowledgments 517 The authors would like to thank among others Tirumaleswar Reddy; 518 Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; Jon 519 Shallow and the DOTS WG chairs, Roman Danyliw and Tobias Gondrom, for 520 their valuable feedback. 522 7. Informative References 524 [I-D.boucadair-dots-multihoming] 525 Boucadair, M. and R. K, "Multi-homing Deployment 526 Considerations for Distributed-Denial-of-Service Open 527 Threat Signaling (DOTS)", draft-boucadair-dots- 528 multihoming-04 (work in progress), October 2018. 530 [I-D.ietf-dots-requirements] 531 Mortensen, A., Moskowitz, R., and R. K, "Distributed 532 Denial of Service (DDoS) Open Threat Signaling 533 Requirements", draft-ietf-dots-requirements-16 (work in 534 progress), October 2018. 536 Authors' Addresses 538 Roland Dobbins 539 Arbor Networks 540 Singapore 542 EMail: rdobbins@arbor.net 544 Daniel Migault 545 Ericsson 546 8275 Trans Canada Route 547 Saint Laurent, QC 4S 0B6 548 Canada 550 EMail: daniel.migault@ericsson.com 552 Stefan Fouant 553 USA 555 EMail: stefan.fouant@copperriverit.com 557 Robert Moskowitz 558 HTT Consulting 559 Oak Park, MI 48237 560 USA 562 EMail: rgm@labs.htt-consult.com 563 Nik Teague 564 Verisign 565 12061 Bluemont Way 566 Reston, VA 20190 568 EMail: nteague@verisign.com 570 Liang Xia 571 Huawei 572 No. 101, Software Avenue, Yuhuatai District 573 Nanjing 574 China 576 EMail: Frank.xialiang@huawei.com 578 Kaname Nishizuka 579 NTT Communications 580 GranPark 16F 3-4-1 Shibaura, Minato-ku 581 Tokyo 108-8118 582 Japan 584 EMail: kaname@nttv6.jp