idnits 2.17.1 draft-ietf-dots-use-cases-24.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 == Line 88 has weird spacing: '...ends on a tim...' -- The document date (July 02, 2020) is 1393 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-04 -- Obsolete informational reference (is this intentional?): RFC 8782 (Obsoleted by RFC 9132) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 3, 2021 Ericsson 6 R. Moskowitz 7 HTT Consulting 8 N. Teague 9 Iron Mountain Data Centers 10 L. Xia 11 Huawei 12 K. Nishizuka 13 NTT Communications 14 July 02, 2020 16 Use cases for DDoS Open Threat Signaling 17 draft-ietf-dots-use-cases-24 19 Abstract 21 The DDoS Open Threat Signaling (DOTS) effort is intended to provide 22 protocols to facilitate interoperability across disparate DDoS 23 mitigation solutions. This document presents sample use cases which 24 describe the interactions expected between the DOTS components as 25 well as DOTS messaging exchanges. These use cases are meant to 26 identify the interacting DOTS components, how they collaborate, and 27 what are the typical information to be exchanged. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 3, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit 67 Provider . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service 69 Provider . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 10 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Informative References . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 At the time of writing, distributed denial-of-service (DDoS) attack 80 mitigation solutions are largely based upon siloed, proprietary 81 communications schemes with vendor lock-in as a side-effect. This 82 can result in the configuration, provisioning, operation, and 83 activation of these solutions being a highly manual and often time- 84 consuming process. Additionally, coordinating multiple DDoS 85 mitigation solutions simultaneously is fraught with both technical 86 and process-related hurdles. This greatly increases operational 87 complexity which, in turn, can degrade the efficacy of mitigations - 88 which highly depends on a timely reaction. 90 The DDoS Open Threat Signaling (DOTS) effort is intended to specify 91 protocols that facilitate interoperability between diverse DDoS 92 mitigation solutions and ensure greater integration in term of attack 93 detection, mitigation requests, and attack characterization patterns. 95 As DDoS solutions are broadly heterogeneous among vendors, the 96 primary goal of DOTS is to provide high-level interaction amongst 97 differing DDoS solutions, such as detecting DDoS attacks, initiating/ 98 terminating DDoS mitigation assistance, or requesting the status of a 99 DDoS mitigation. 101 This document provides sample use cases that provided input for the 102 requirements [RFC8612] and design of the DOTS protocols 103 [RFC8782][RFC8783]. The use cases are not exhaustive and future use 104 cases are expected to emerge as DOTS is adopted and evolves. 106 2. Terminology and Acronyms 108 This document makes use of the same terminology and definitions as 109 [RFC8612]. In addition it uses the terms defined below: 111 o DDoS Mitigation System (DMS): A system that performs DDoS 112 mitigation. The DDoS Mitigation System may be composed by a 113 cluster of hardware and/or software resources, but could also 114 involve an orchestrator that may take decisions such as 115 outsourcing some or all of the mitigation to another DDoS 116 Mitigation System. 118 o DDoS Mitigation: The action performed by the DDoS Mitigation 119 System. 121 o DDoS Mitigation Service: designates a service provided to a 122 customer to mitigate DDoS attacks. Each service subscription 123 usually involve Service Level Agreement (SLA) that have to be met. 124 It is the responsibility of the DDoS Service provider to 125 instantiate the DDoS Mitigation System to meet these SLAs. 127 o DDoS Mitigation Service Provider: designates the administrative 128 entity providing the DDoS Mitigation Service. 130 o Internet Transit Provider (ITP): designates the entity that 131 delivers the traffic to a customer 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 ITP in 141 order to mitigate a DDoS attack targeting its network. 143 For clarity of discussion, the targeted network is indicated as an 144 enterprise network, but the same scenario applies to any downstream 145 network, including residential and cloud hosting networks. 147 As the ITP provides connectivity to the enterprise network, it is 148 already on the path of the inbound and outbound traffic of the 149 enterprise network and well aware of the networking parameters 150 associated to the enterprise network WAN connectivity. This eases 151 both the configuration and the instantiation of a DDoS Mitigation 152 Service. 154 This section considers two kind of DDoS Mitigation Service between an 155 enterprise network and an ITP: 157 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 158 upon receiving a request from the enterprise network. This 159 typically corresponds to the case when the enterprise network is 160 under attack. 162 o On the other hand, the ITP may identify an enterprise network as 163 the source of an attack and send a mitigation request to the 164 enterprise DMS to mitigate this at the source. 166 The two scenarios, though different, have similar interactions 167 between the DOTS client and server. For the sake of simplicity, only 168 the first scenario will be detailed in this section. Nevertheless, 169 the second scenario is also in scope for DOTS. 171 In the first scenario, as depicted in Figure 1, an enterprise network 172 with self-hosted Internet-facing properties such as Web servers, 173 authoritative DNS servers, and VoIP servers has a DMS deployed to 174 protect those servers and applications from DDoS attacks. In 175 addition to on-premise DDoS defense capability, the enterprise has 176 contracted with its ITP for DDoS Mitigation Services when attacks 177 threaten to overwhelm the bandwidth of their WAN link(s). 179 +------------------+ +------------------+ 180 | Enterprise | | Upstream | 181 | Network | | Internet Transit | 182 | | | Provider | 183 | +--------+ | | DDoS Attack 184 | | DDoS | | <================================= 185 | | Target | | <================================= 186 | +--------+ | | +------------+ | 187 | | +-------->| DDoS | | 188 | | | |S | Mitigation | | 189 | | | | | System | | 190 | | | | +------------+ | 191 | | | | | 192 | | | | | 193 | | | | | 194 | +------------+ | | | | 195 | | DDoS |<---+ | | 196 | | Mitigation |C | | | 197 | | System | | | | 198 | +------------+ | | | 199 +------------------+ +------------------+ 201 * C is for DOTS client functionality 202 * S is for DOTS server functionality 204 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 206 The enterprise DMS is configured such that if the incoming Internet 207 traffic volume exceeds 50% of the provisioned upstream Internet WAN 208 link capacity, the DMS will request DDoS mitigation assistance from 209 the upstream transit provider. More sophisticated detection means 210 may be considered as well. 212 The requests to trigger, manage, and finalize a DDoS Mitigation 213 between the enterprise DMS and the ITP is performed using DOTS. The 214 enterprise DMS implements a DOTS client while the ITP implements a 215 DOTS server which is integrated with their DMS in this example. 217 When the enterprise DMS locally detects an inbound DDoS attack 218 targeting its resources (e.g., servers, hosts, or applications), it 219 immediately begins a DDoS Mitigation. 221 During the course of the attack, the inbound traffic volume to the 222 enterprise network exceeds the 50% threshold and the enterprise DMS 223 escalates the DDoS mitigation. The enterprise DMS DOTS client 224 signals to the DOTS server on the upstream ITP to initiate DDoS 225 Mitigation. The DOTS server replies to the DOTS client that it can 226 serve this request, and mitigation is initiated on the ITP network by 227 the ITP DMS. 229 Over the course of the attack, the DOTS server of the ITP 230 periodically informs the DOTS client on the mitigation status, 231 statistics related to DDoS attack traffic mitigation, and related 232 information. Once the DDoS attack has ended, or decreased to the 233 certain level that the enterprise DMS might handle by itself, the 234 DOTS server signals the enterprise DMS DOTS client that the attack 235 has subsided. 237 The DOTS client on the enterprise DMS then requests the ITP to 238 terminate the DDoS Mitigation. The DOTS server on the ITP receives 239 this request and once the mitigation has ended, confirms the end of 240 upstream DDoS Mitigation to the enterprise DMS DOTS client. 242 The following is an overview of the DOTS communication model for this 243 use-case: 245 1. A DDoS attack is initiated against resources of a network 246 organization (here, the enterprise) which has deployed a DOTS- 247 capable DMS - typically a DOTS client. 249 2. The enterprise DMS detects, classifies, and begins the DDoS 250 Mitigation. 252 3. The enterprise DMS determines that its capacity and/or capability 253 to mitigate the DDoS attack is insufficient, and sends via its 254 DOTS client a DOTS DDoS Mitigation request to one or more DOTS 255 servers residing on the upstream ITP. 257 4. The DOTS server which receives the DOTS Mitigation request 258 determines that it has been configured to honor requests from the 259 requesting DOTS client, and honors the request by orchestrating 260 its own DMS. 262 5. While the DDoS Mitigation is active, the DOTS server regularly 263 transmits DOTS DDoS Mitigation status updates to the DOTS client. 265 6. Informed by the DOTS server status update that the attack has 266 ended or subsided, the DOTS client transmits a DOTS DDoS 267 Mitigation termination request to the DOTS server. 269 7. The DOTS server terminates DDoS Mitigation, and sends the 270 notification to the DOTS client. 272 Note that communications between the enterprise DOTS client and the 273 upstream ITP DOTS server may take place in-band within the main 274 Internet WAN link between the enterprise and the ITP; out-of-band via 275 a separate, dedicated wireline network link utilized solely for DOTS 276 signaling; or out-of-band via some other form of network connectivity 277 such as a third-party wireless 4G network connectivity. 279 Note also that a DOTS client that sends a DOTS Mitigation request may 280 be also triggered by a network admin that manually confirms the 281 request to the upstream ITP, in which case the request may be sent 282 from an application such as a web browser or a dedicated mobile 283 application. 285 Note also that when the enterprise is multihomed and connected to 286 multiple upstream ITPs, each ITP is only able to provide a DDoS 287 Mitigation Service for the traffic it transits. As a result, the 288 enterprise network may be required to coordinate the various DDoS 289 Mitigation Services associated to each link. More multi-homing 290 considerations are discussed in [I-D.ietf-dots-multihoming]. 292 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider 294 This use case differs from the previous use case described in 295 Section 3.1 in that the DDoS Mitigation Service is not provided by an 296 upstream ITP. In other words, as represented in Figure 2, the 297 traffic is not forwarded through the DDoS Mitigation Service Provider 298 by default. In order to steer the traffic to the DDoS Mitigation 299 Service Provider, some network configuration changes are required. 300 As such, this use case is likely to apply to large enterprises or 301 large data centers, but as for the other use cases is not exclusively 302 limited to them. 304 Another typical scenario for this use case is for there to be a 305 relationship between DDoS Mitigation Service Providers, forming an 306 overlay of DMS. When a DDoS Mitigation Service Provider mitigating a 307 DDoS attack reaches its resources capacity, it may chose to delegate 308 the DDoS Mitigation to another DDoS Mitigation Service Provider. 310 +------------------+ +------------------+ 311 | Enterprise | | Upstream | 312 | Network | | Internet Transit | 313 | | | Provider | 314 | +--------+ | | DDoS Attack 315 | | DDoS | | <================================= 316 | | Target | | <================================= 317 | +--------+ | | | 318 | | | | 319 | | +------------------+ 320 | | 321 | | +------------------+ 322 | | | DDoS Mitigation | 323 | | | Service Provider | 324 | | | | 325 | +------------+ | | +------------+ | 326 | | DDoS |<------------>| DDoS | | 327 | | Mitigation |C | | S| Mitigation | | 328 | | System | | | | System | | 329 | +------------+ | | +------------+ | 330 +------------------+ +------------------+ 332 * C is for DOTS client functionality 333 * S is for DOTS server functionality 335 Figure 2: DDoS Mitigation between an Enterprise Network and Third 336 Party DDoS Mitigation Service Provider 338 In this scenario, an enterprise network has entered into a pre- 339 arranged DDoS mitigation assistance agreement with one or more third- 340 party DDoS Mitigation Service Providers in order to ensure that 341 sufficient DDoS mitigation capacity and/or capabilities may be 342 activated in the event that a given DDoS attack threatens to 343 overwhelm the ability of the enterprise's or any other given DMS to 344 mitigate the attack on its own. 346 The pre-arrangement typically includes agreement on the mechanisms 347 used to redirect the traffic to the DDoS Mitigation Service Provider, 348 as well as the mechanism to re-inject the traffic back to the 349 Enterprise Network. Redirection to the DDoS Mitigation Service 350 Provider typically involves BGP prefix announcement or DNS 351 redirection, while re-injection of the scrubbed traffic to the 352 enterprise network may be performed via tunneling mechanisms (e.g., 353 GRE). The exact mechanisms used for traffic steering are out of 354 scope of DOTS, but will need to be pre-arranged, while in some 355 contexts such changes could be detected and considered as an attack. 357 In some cases the communication between the enterprise DOTS client 358 and the DOTS server of the DDoS Mitigation Service Provider may go 359 through the ITP carrying the DDoS attack, which would affect the 360 communication. On the other hand, the communication between the DOTS 361 client and DOTS server may take a path that is not undergoing a DDoS 362 attack. 364 +------------------+ +------------------+ 365 | Enterprise | | Upstream | 366 | Network | | Internet Transit | 367 | | | Provider | 368 | +--------+ | | DDoS Attack 369 | | DDoS | |<----------------+ | ++==== 370 | | Target | | Mitigated | | || ++= 371 | +--------+ | | | | || || 372 | | | | | || || 373 | | +--------|---------+ || || 374 | | | || || 375 | | +--------|---------+ || || 376 | | | DDoS Mitigation | || || 377 | | | Service Provider | || || 378 | | | | | || || 379 | +------------+ | | +------------+ | || || 380 | | DDoS |<------------>| DDoS | | || || 381 | | mitigation |C | |S | mitigation |<===++ || 382 | | system | | | | system |<======++ 383 | +------------+ | | +------------+ | 384 +------------------+ +------------------+ 386 * C is for DOTS client functionality 387 * S is for DOTS server functionality 389 Figure 3: Redirection to a DDoS Mitigation Service Provider 391 When the enterprise network is under attack or at least is reaching 392 its capacity or ability to mitigate a given DDoS attack, the DOTS 393 client sends a DOTS request to the DDoS Mitigation Service Provider 394 to initiate network traffic diversion - as represented in Figure 3 - 395 and DDoS mitigation activities. Ongoing attack and mitigation status 396 messages may be passed between the enterprise network and the DDoS 397 Mitigation Service Provider using DOTS. If the DDoS attack has 398 stopped or the severity of the attack has subsided, the DOTS client 399 can request the DDoS Mitigation Service Provider to terminate the 400 DDoS Mitigation. 402 3.3. DDoS Orchestration 404 In this use case, one or more DDoS telemetry systems or monitoring 405 devices monitor a network - typically an ISP network, an enterprise 406 network, or a data center. Upon detection of a DDoS attack, these 407 DDoS telemetry systems alert an orchestrator in charge of 408 coordinating the various DMS's within the domain. The DDoS telemetry 409 systems may be configured to provide required information, such as a 410 preliminary analysis of the observation, to the orchestrator. 412 The orchestrator analyses the various sets of information it receives 413 from DDoS telemetry systems, and initiates one or more DDoS 414 mitigation strategies. For example, the orchestrator could select 415 the DDoS mitigation system in the enterprise network or one provided 416 by the ITP. 418 DDoS Mitigation System selection and DDoS Mitigation techniques may 419 depend on the type of the DDoS attack. In some case, a manual 420 confirmation or selection may also be required to choose a proposed 421 strategy to initiate a DDoS Mitigation. The DDoS Mitigation may 422 consist of multiple steps such as configuring the network, or of 423 updating already instantiated DDoS mitigation functions. Eventually, 424 the coordination of the mitigation may involve external DDoS 425 mitigation resources such as a transit provider or a Third Party DDoS 426 Mitigation Service Provider. 428 The communication used to trigger a DDoS Mitigation between the DDoS 429 telemetry and monitoring systems and the orchestrator is performed 430 using DOTS. The DDoS telemetry system implements a DOTS client while 431 the orchestrator implements a DOTS server. 433 The communication between a network administrator and the 434 orchestrator is also performed using DOTS. The network administrator 435 uses, for example, a web interface which interacts with a DOTS 436 client, while the orchestrator implements a DOTS server. 438 The communication between the orchestrator and the DDoS Mitigation 439 Systems is performed using DOTS. The orchestrator implements a DOTS 440 client while the DDoS Mitigation Systems implement a DOTS server. 442 The configuration aspects of each DDoS Mitigation System, as well as 443 the instantiations of DDoS mitigation functions or network 444 configuration is not part of DOTS. Similarly, the discovery of 445 available DDoS mitigation functions is not part of DOTS; and as such 446 is out of scope. 448 +----------+ 449 | network |C (Enterprise Network) 450 | adminis |<-+ 451 | trator | | 452 +----------+ | 453 | 454 +----------+ | S+--------------+ +-----------+ 455 |telemetry/| +->| |C S| DDoS |+ 456 |monitoring|<--->| Orchestrator |<--->| mitigation|| 457 |systems |C S| |<-+ | systems || 458 +----------+ +--------------+C | +-----------+| 459 | +----------+ 460 -----------------------------------|----------------- 461 | 462 | 463 (Internet Transit Provider) | 464 | +-----------+ 465 | S| DDoS |+ 466 +->| mitigation|| 467 | systems || 468 +-----------+| 469 * C is for DOTS client functionality +----------+ 470 * S is for DOTS server functionality 472 Figure 4: DDoS Orchestration 474 The DDoS telemetry systems monitor various aspect of the network 475 traffic and perform some measurement tasks. 477 These systems are configured so that when an event or some 478 measurement indicators reach a predefined level their associated DOTS 479 client sends a DOTS mitigation request to the orchestrator DOTS 480 server. The DOTS mitigation request may be associated with some 481 optional mitigation hints to let the orchestrator know what has 482 triggered the request. In particular, it is possible for something 483 that locally to one telemetry system looks like an attack is not 484 actually an attack when seen from the broader scope (e.g., of the 485 orchestrator) 487 Upon receipt of the DOTS mitigation request from the DDoS telemetry 488 system, the orchestrator DOTS server responds with an acknowledgment, 489 to avoid retransmission of the request for mitigation. The 490 orchestrator may begin collecting additional fine-grained and 491 specific information from various DDoS telemetry systems in order to 492 correlate the measurements and provide an analysis of the event. 493 Eventually, the orchestrator may ask for additional information from 494 the DDoS telemetry system; however, the collection of this 495 information is out of scope of DOTS. 497 The orchestrator may be configured to start a DDoS Mitigation upon 498 approval from a network administrator. The analysis from the 499 orchestrator is reported to the network administrator via, for 500 example, a web interface. If the network administrator decides to 501 start the mitigation, the network administrator triggers the DDoS 502 mitigation request using, for example, a web interface of a DOTS 503 client communicating to the orchestrator DOTS server. This request 504 is expected to be associated with a context that provides sufficient 505 information to the orchestrator DOTS server to infer, elaborate and 506 coordinate the appropriated DDoS Mitigation. 508 Upon receiving a request to mitigate a DDoS attack aimed at a target, 509 the orchestrator may evaluate the volume of the attack as well as the 510 value that the target represents. The orchestrator may select the 511 DDoS Mitigation Service Provider based on the attack severity. It 512 may also coordinate the DDoS Mitigation performed by the DDoS 513 Mitigation Service Provider with some other tasks such as, for 514 example, moving the target to another network so new sessions will 515 not be impacted. The orchestrator requests a DDoS Mitigation by the 516 selected DDoS mitigation systems via its DOTS client, as described in 517 Section 3.1. 519 The orchestrator DOTS client is notified that the DDoS Mitigation is 520 effective by the selected DDoS mitigation systems. The orchestrator 521 DOTS server returns this information back to the network 522 administrator. 524 Similarly, when the DDoS attack has stopped, the orchestrator DOTS 525 client is notified and the orchestrator's DOTS server indicates to 526 the DDoS telemetry systems as well as to the network administrator 527 the end of the DDoS Mitigation. 529 In addition to the above DDoS Orchestration, the selected DDoS 530 mitigation system can return back a mitigation request to the 531 orchestrator as an offloading. For example, when the DDoS attack 532 becomes severe and the DDoS mitigation system's utilization rate 533 reaches its maximum capacity, the DDoS mitigation system can send 534 mitigation requests with additional hints such as its blocked traffic 535 information to the orchestrator. Then the orchestrator can take 536 further actions such as requesting forwarding nodes such as routers 537 to filter the traffic. In this case, the DDoS mitigation system 538 implements a DOTS client while the orchestrator implements a DOTS 539 server. Similar to other DOTS use cases, the offloading scenario 540 assumes that some validation checks are followed by the DMS, the 541 orchestrator, or both (e.g., avoid exhausting the resources of the 542 forwarding nodes or inadvertent disruption of legitimate services). 543 These validation checks are part of the mitigation, and are therefore 544 out of the scope of the document. 546 4. Security Considerations 548 The document does not describe any protocol, though there are still a 549 few high-level security considerations to discuss. 551 DOTS is at risk from three primary attacks: DOTS agent impersonation, 552 traffic injection, and signaling blocking. 554 Impersonation and traffic injection mitigation can be mitigated 555 through current secure communications best practices including mutual 556 authentication. Preconfigured mitigation steps to take on the loss 557 of keepalive traffic can partially mitigate signal blocking, but in 558 general it is impossible to comprehensively defend against an 559 attacker that can selectively block any or all traffic. Alternate 560 communication paths that are (hopefully) not subject to blocking by 561 the attacker in question is another potential mitigation. 563 Additional details of DOTS security requirements can be found in 564 [RFC8612]. 566 Service disruption may be experienced if inadequate mitigation 567 actions are applied. These considerations are out of the scope of 568 DOTS. 570 5. IANA Considerations 572 No IANA considerations exist for this document. 574 6. Acknowledgments 576 The authors would like to thank among others Tirumaleswar Reddy; 577 Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon 578 Shallow, Yuuhei Hayashi, Elwyn Davies, the DOTS WG chairs, Roman 579 Danyliw and Tobias Gondrom as well as the Security AD Benjamin Kaduk 580 for their valuable feedback. 582 We also would like to thank Stephan Fouant that was part of the 583 initial co-authors of the documents. 585 7. Informative References 587 [I-D.ietf-dots-multihoming] 588 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 589 Deployment Considerations for Distributed-Denial-of- 590 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 591 multihoming-04 (work in progress), May 2020. 593 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 594 Threat Signaling (DOTS) Requirements", RFC 8612, 595 DOI 10.17487/RFC8612, May 2019, 596 . 598 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 599 Mortensen, A., and N. Teague, "Distributed Denial-of- 600 Service Open Threat Signaling (DOTS) Signal Channel 601 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 602 . 604 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 605 Denial-of-Service Open Threat Signaling (DOTS) Data 606 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 607 May 2020, . 609 Authors' Addresses 611 Roland Dobbins 612 Arbor Networks 613 Singapore 615 EMail: rdobbins@arbor.net 617 Daniel Migault 618 Ericsson 619 8275 Trans Canada Route 620 Saint Laurent, QC 4S 0B6 621 Canada 623 EMail: daniel.migault@ericsson.com 625 Robert Moskowitz 626 HTT Consulting 627 Oak Park, MI 48237 628 USA 630 EMail: rgm@labs.htt-consult.com 632 Nik Teague 633 Iron Mountain Data Centers 634 UK 636 EMail: nteague@ironmountain.co.uk 637 Liang Xia 638 Huawei 639 No. 101, Software Avenue, Yuhuatai District 640 Nanjing 641 China 643 EMail: Frank.xialiang@huawei.com 645 Kaname Nishizuka 646 NTT Communications 647 GranPark 16F 3-4-1 Shibaura, Minato-ku 648 Tokyo 108-8118 649 Japan 651 EMail: kaname@nttv6.jp