idnits 2.17.1 draft-ietf-dots-use-cases-13.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 (June 27, 2018) is 2120 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-boucadair-dots-multihoming-03 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS R. Dobbins 3 Internet-Draft Arbor Networks 4 Intended status: Informational D. Migault 5 Expires: December 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 June 27, 2018 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-13 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 December 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 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 Service: designates a DDoS service provided to a 121 customer and which is scoped to mitigate DDoS attacks. Services 122 usually involve Service Level Agreement (SLA) that have to be met. 123 It is the responsibility of the service provider to instantiate 124 the DDoS Mitigation System to meet these SLAs. 126 o DDoS Mitigation: The action performed by the DDoS Mitigation 127 System. 129 o Internet Transit Provider (ITP): designates the entity that 130 delivers the traffic to the network. It can be an Internet 131 Service Provider (ISP), or an upstream entity delivering the 132 traffic to the ISP. 134 3. Use Cases 136 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider 138 This use case describes how an enterprise or a residential customer 139 network may take advantage of a pre-existing relation with its 140 Internet Transit Provider (ITP) in order to mitigate a DDoS attack 141 targeting its network. To improve the clarity of our purpose, the 142 targeted network will be designated as enterprise network, but the 143 same scenario applies to any downstream network, including 144 residential network. As the ITP provides connectivity to the 145 enterprise network, it is already on the path of the inbound or 146 outbound traffic of the enterprise network and well aware of the 147 networking parameters associated to the enterprise network 148 connectivity. This eases both the configuration and the 149 instantiation of a DDoS Mitigation Service. This section considers 150 two kind of DDoS Mitigation Service between an enterprise network and 151 an ITP: 153 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 154 upon receiving a request from the enterprise network. This 155 typically corresponds to the case when the enterprise network is 156 under attack. 158 o On the other hand, the ITP may identify an enterprise network as 159 the source of an attack and send a mitigation request to the 160 enterprise DMS to mitigate this at the source. 162 In the first scenario, as depicted in Figure 1, an enterprise network 163 with self-hosted Internet-facing properties such as Web servers, 164 authoritative DNS servers, and VoIP servers has a DMS deployed to 165 protect those servers and applications from DDoS attacks. In 166 addition to on-premise DDoS defense capability, enterprises have 167 contracted with their Internet transit provider for DDoS Mitigation 168 Services which threaten to overwhelm their WAN link(s) bandwidth. 170 +------------------+ +------------------+ 171 | Entreprise | | Upstream | 172 | Network | | Internet Transit | 173 | | | Provider | 174 | +--------+ | | DDoS Attack 175 | | DDoS | | <================================= 176 | | Target | | <================================= 177 | +--------+ | | +------------+ | 178 | | +-------->| DDoS | | 179 | | | |S | Mitigation | | 180 | | | | | System | | 181 | | | | +------------+ | 182 | | | | | 183 | | | | | 184 | | | | | 185 | +------------+ | | | | 186 | | DDoS |<---+ | | 187 | | Mitigation |C | | | 188 | | System | | | | 189 | +------------+ | | | 190 +------------------+ +------------------+ 192 * C is for DOTS client functionality 193 * S is for DOTS server functionality 195 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 197 The enterprise DMS is configured such that if the incoming Internet 198 traffic volume exceeds 50% of the provisioned upstream Internet WAN 199 link capacity, the DMS will request DDoS mitigation assistance from 200 the upstream transit provider. 202 The requests to trigger, manage, and finalize a DDoS Mitigation 203 between the enterprise DMS and the ITP is performed using DOTS. The 204 enterprise DMS implements a DOTS client while the ITP implements a 205 DOTS server which is integrated with their DMS. 207 When the enterprise DMS detects an inbound DDoS attack targeting its 208 resources ( e.g. servers, hosts or applications), it immediately 209 begins a DDoS Mitigation. 211 During the course of the attack, the inbound traffic volume exceeds 212 the 50% threshold; the DMS DOTS client signals the DOTS server on the 213 upstream ITP to initiate DDoS Mitigation. The DOTS server signals 214 the DOTS client that it can serve this request, and mitigation is 215 initiated on the ITP network by the ITP DMS. 217 Over the course of the attack, the DOTS server of the ITP 218 periodically informs the DOTS client on the enterprise DMS mitigation 219 status, statistics related to DDoS attack traffic mitigation, and 220 related information. Once the DDoS attack has ended, the DOTS server 221 signals the enterprise DMS DOTS client that the attack has subsided. 223 The enterprise DMS then requests the ITP to terminate the DDoS 224 Mitigation. The DOTS server on the ITP receives this request and 225 once the mitigation has ended, confirms the end of upstream DDoS 226 Mitigation to the enterprise DMS DOTS client. 228 The following is an overview of the DOTS communication model for this 229 use-case: 231 o (a) A DDoS attack is initiated against resources of a network 232 organization which has deployed a DOTS-capable DMS - typically a 233 DOTS client. 235 o (b) The DMS detects, classifies, and begins the DDoS Mitigation. 237 o (c) The DMS determines that its capacity and/or capability to 238 mitigate the DDoS attack is insufficient, and sends via its DOTS 239 client a DOTS DDoS Mitigation request to one or more DOTS servers 240 residing on the upstream ITP. 242 o (d) The DOTS server which receive the DOTS Mitigation request 243 determines that they have been configured to honor requests from 244 the requesting DOTS client, and honored its DDoS Mitigation by 245 orchestrating its DMS. 247 o (e) While the DDoS Mitigation is active, DOTS servers regularly 248 transmit DOTS DDoS Mitigation status updates to the DOTS client. 250 o (f) The DOTS client transmits a DOTS DDoS Mitigation termination 251 request to the DOTS server. 253 o (g) The DOTS server terminates DDoS Mitigation. 255 Note that communications between the enterprise DOTS client and the 256 upstream transit provider DOTS Server may take place in-band within 257 the main Internet WAN link between the enterprise and the ITP; out- 258 of-band via a separate, dedicated wireline network link utilized 259 solely for DOTS signaling; or out-of-band via some other form of 260 network connectivity such as a third-party wireless 4G network 261 connectivity. 263 Note also that a DOTS clients that sends a DOTS Mitigation request 264 may be also triggered by a network admin that manually confirms the 265 request to the upstream ITP, in which case the request may be sent 266 from an application such as a web browser or a dedicated mobile 267 application. 269 Note also that when the enterprise is multihomed and connected to 270 multiple upstream ITPs, each ITP is only able to provide a DDoS 271 Mitigation Service for the traffic it transits. As a result, the 272 enterprise network may require to coordinate the various DDoS 273 Mitigation Services associated to each link. More multi-homing 274 considerations are discussed in [I-D.boucadair-dots-multihoming]. 276 3.2. DDoS Mitigation by a Third party DDoS Mitigation Service Provider 278 This use case differs from the previous use case described in 279 Section 3.1 in that the DDoS Mitigation Service is not provided by an 280 upstream ITP. In other words, as represented in Figure 2, the 281 traffic is not forwarded through the DDoS Mitigation Service Provider 282 by default. In order to steer the traffic to the DDoS Mitigation 283 Service Provider, some network configuration changes are required. 284 As such, this use case likely to match large enterprises or large 285 data centers, but not exclusively. Another typical scenario for this 286 use case is the relation between DDoS Mitigation Service Provider 287 forming an overlay of DMS. When an DDoS Mitigation Service Provider 288 mitigating a DDoS attack reaches it resources capacities, it may 289 chose to delegate the DDoS Mitigation to another DDoS Mitigation 290 Service Provider. 292 +------------------+ +------------------+ 293 | Entreprise | | Upstream | 294 | Network | | Internet Transit | 295 | | | Provider | 296 | +--------+ | | DDoS Attack 297 | | DDoS | | <================================= 298 | | Target | | <================================= 299 | +--------+ | +----------------------------+ 300 | | | | | | 301 | | | +------------------+ | 302 | | | | 303 | | | +------------------+ | 304 | | | | DDoS Mitigation | | 305 | | | | Service Provider | | 306 | | | | | | 307 | +------------+ | | | +------------+ | | 308 | | DDoS |<---+ | | DDoS |<----+ 309 | | Mitigation |C | | | Mitigation |S | 310 | | System | | | | System | | 311 | +------------+ | | +------------+ | 312 +------------------+ +------------------+ 314 * C is for DOTS client functionality 315 * S is for DOTS server functionality 317 Figure 2: DDoS Mitigation between an Enterprise Network and third 318 party DDoS Mitigation Service Provider 320 In this scenario, an Enterprise Network has entered into a pre- 321 arranged DDoS mitigation assistance agreement with one or more other 322 DDoS Mitigation Service Providers in order to ensure that sufficient 323 DDoS mitigation capacity and/or capabilities may be activated in the 324 event that a given DDoS attack threatens to overwhelm the ability of 325 a given DMS to mitigate the attack on its own. 327 The pre-arrangement typically includes the agreement on the 328 mechanisms used to redirect the traffic to the DDoS Mitigation 329 Service Provider, as well as the mechanism to re-inject the traffic 330 back to the Enterprise Network. Redirection to the DDoS Mitigation 331 Service Provider typically involves BGP prefix announcement or DNS 332 redirection, while re-injection of the scrubbed traffic to the 333 enterprise network may be performed via tunneling mechanisms such as 334 GRE for example. These exact mechanisms used for traffic steering 335 are out of scope. 337 +------------------+ +------------------+ 338 | Entreprise | | Upstream | 339 | Network | | Internet Transit | 340 | | | Provider | 341 | +--------+ | | DDoS Attack 342 | | DDoS | |<----------------+ | ++==== 343 | | Target | | Mitigated | | || ++= 344 | +--------+ | | | | || || 345 | | | | | || || 346 | | +--------|---------+ || || 347 | | | || || 348 | | +--------|---------+ || || 349 | | | DDoS Mitigation | || || 350 | | | Service Provider | || || 351 | | | | | || || 352 | +------------+ | | +------------+ | || || 353 | | DDoS |<------------>| DDoS | | || || 354 | | mitigation |C | |S | mitigation |<===++ || 355 | | system | | | | system |<======++ 356 | +------------+ | | +------------+ | 357 +------------------+ +------------------+ 359 * C is for DOTS client functionality 360 * S is for DOTS server functionality 362 Figure 3: Redirection to a DDoS Mitigation Service Provider 364 When the Enterprise Network is under attack or at least is reaching 365 its capacity or ability to mitigate a given DDoS attack traffic, the 366 DOTS client sends a DOTS request to the DDoS Mitigation Service 367 Provider to initiate network traffic diversion - as represented in 368 Figure 3 - and DDoS mitigation activities. Ongoing attack and 369 mitigation status messages may be passed between the Enterprise 370 Network and the DDoS Mitigation Service Provider. If the DDoS attack 371 has stopped or the severity of the attack has subsided, the DOTS 372 client can request the DDoS Mitigation Service Provider to stop the 373 DDoS Mitigation. 375 3.3. DDoS Orchestration 377 In this use case, one or more DDoS telemetry systems or monitoring 378 devices monitor a network - typically an ISP network. Upon detection 379 of a DDoS attack, these telemetry systems alert an orchestrator in 380 charge of coordinating the various DMS within the domain. The 381 telemetry systems may be configured to provide required information, 382 such as a preliminary analysis of the observation to the 383 orchestrator. 385 The orchestrator analyses the various information it receives from 386 specialized equipment, and elaborates one or multiple DDoS mitigation 387 strategies. In some case, a manual confirmation may also be required 388 to choose a proposed strategy or to initiate a DDoS Mitigation. The 389 DDoS Mitigation may consist of multiple steps such as configuring the 390 network, or updating already instantiated DDoS mitigation functions. 391 In some cases, some specific DDoS mitigation functions must be 392 instantiated and properly ordered. Eventually, the coordination of 393 the mitigation may involve external DDoS resources such as a transit 394 provider or a DDoS Mitigation Service Provider. 396 The communications used to trigger a DDoS Mitigation between the 397 telemetry and monitoring systems and the orchestrator is performed 398 using DOTS. The telemetry systems implements a DOTS client while the 399 orchestrator implements a DOTS server. 401 The communication between a network administrator and the 402 orchestrator is also performed using DOTS. The network administrator 403 via its web interfaces implements a DOTS client, while the 404 Orchestrator implements a DOTS server. 406 The communication between the orchestrator and the DDoS mitigation 407 systems is performed using DOTS. The orchestrator implements a DOTS 408 Client while the DDoS mitigation systems implement a DOTS Server. 410 The configuration aspects of each DDoS mitigation system, as well as 411 the instantiations of DDoS mitigation functions or network 412 configuration is not part of DOTS. Similarly, the discovery of 413 available DDoS mitigation functions is not part of DOTS; and as such 414 is out of scope. 416 +----------+ 417 | network |C (Enterprise Network) 418 | adminis |<-+ 419 | trator | | 420 +----------+ | 421 | 422 +----------+ | S+--------------+ +-----------+ 423 |telemetry/| +->| |C S| DDoS |+ 424 |monitoring|<--->| Orchestrator |<--->| mitigation|| 425 |systems |C S| |<-+ | systems || 426 +----------+ +--------------+C | +-----------+| 427 | +----------+ 428 -----------------------------------|----------------- 429 | 430 | 431 (Internet Transit Provider) | 432 | +-----------+ 433 | S| DDoS | 434 +->| mitigation| 435 | systems | 436 +-----------+ 437 * C is for DOTS client functionality 438 * S is for DOTS server functionality 440 Figure 4: DDoS Orchestration 442 The telemetry systems monitor various network traffic and perform 443 some measurement tasks. 445 These systems are configured so that when an event or some 446 measurement indicators reach a predefined level to send DOTS 447 mitigation request to the orchestrator. The DOTS mitigation request 448 may be associated with some optional mitigation hints to let the 449 orchestrator know what has triggered the request. 451 Upon receipt of the DOTS mitigation request from the telemetry 452 system, the orchestrator responds with an acknowledgment, to avoid 453 retransmission of the request for mitigation. The orchestrator may 454 begin collecting additional fined grain and specific information from 455 various telemetry systems in order to correlate the measurements and 456 provide an analysis of the event. Eventually, the orchestrator may 457 ask additional information to the telemetry system, however, the 458 collection of these information is out of scope. 460 The orchestrator may be configured to start a DDoS Mitigation upon 461 approval from a network administrator. The analysis from the 462 orchestrator is reported to the network administrator via a web 463 interface. If the network administrator decides to start the 464 mitigation, the network administrator triggers the DDoS mitigation 465 request using the web interface of a DOTS client. This request is 466 expected to be associated with a context that provides sufficient 467 information to the orchestrator to infer the DDoS Mitigation to 468 elaborate and coordinate. 470 Upon receiving a request to mitigate a DDoS attack performed over a 471 target, the orchestrator, may evaluate the volumetry of the attack as 472 well as the value that represent the target. The orchestrator may 473 select the DDoS Mitigation Service Provider based on the attack 474 severity. It may also coordinate the DDoS Mitigation performed by 475 the DDoS Mitigation Service Provider with some other tasks such as 476 for example, moving the target to another network so new sessions 477 will not be impacted. When DDoS Mitigation is requested, the status 478 indicates the DDoS Mitigation is starting while not effective. The 479 DOTS client of the orchestrator will later be notified that the DDoS 480 Mitigation is effective. 482 Orchestration of the DDoS mitigation systems works similarly as 483 described in Section 3.1. The orchestrator indicates with its status 484 whether the DDoS Mitigation is effective. 486 When the DDoS attack has stopped, the orchestrator indicates to the 487 telemetry systems as well as to the network administrator the end of 488 the DDoS Mitigation. 490 4. Security Considerations 492 DOTS is at risk from three primary attacks: DOTS agent impersonation, 493 traffic injection, and signaling blocking. 495 Impersonation and traffic injection mitigation can be managed through 496 current secure communications best practices. 498 Additional details of DOTS security requirements can be found in 499 [I-D.ietf-dots-requirements]. 501 5. IANA Considerations 503 No IANA considerations exist for this document at this time. 505 6. Acknowledgments 507 The authors would like to thank among others Tirumaleswar Reddy; 508 Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; Jon 509 Shallow and the DOTS WG chairs, Roman D. Danyliw and Tobias Gondrom, 510 for their valuable feedback. 512 7. Informative References 514 [I-D.boucadair-dots-multihoming] 515 Boucadair, M. and T. Reddy, "Multi-homing Deployment 516 Considerations for Distributed-Denial-of-Service Open 517 Threat Signaling (DOTS)", draft-boucadair-dots- 518 multihoming-03 (work in progress), April 2018. 520 [I-D.ietf-dots-requirements] 521 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 522 Denial of Service (DDoS) Open Threat Signaling 523 Requirements", draft-ietf-dots-requirements-14 (work in 524 progress), February 2018. 526 Authors' Addresses 528 Roland Dobbins 529 Arbor Networks 530 Singapore 532 EMail: rdobbins@arbor.net 534 Daniel Migault 535 Ericsson 536 8275 Trans Canada Route 537 Saint Laurent, QC 4S 0B6 538 Canada 540 EMail: daniel.migault@ericsson.com 542 Stefan Fouant 543 USA 545 EMail: stefan.fouant@copperriverit.com 547 Robert Moskowitz 548 HTT Consulting 549 Oak Park, MI 48237 550 USA 552 EMail: rgm@labs.htt-consult.com 553 Nik Teague 554 Verisign 555 12061 Bluemont Way 556 Reston, VA 20190 558 EMail: nteague@verisign.com 560 Liang Xia 561 Huawei 562 No. 101, Software Avenue, Yuhuatai District 563 Nanjing 564 China 566 EMail: Frank.xialiang@huawei.com 568 Kaname Nishizuka 569 NTT Communications 570 GranPark 16F 3-4-1 Shibaura, Minato-ku 571 Tokyo 108-8118 572 Japan 574 EMail: kaname@nttv6.jp