idnits 2.17.1 draft-ietf-dots-use-cases-22.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 (May 29, 2020) is 1421 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-03 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: November 30, 2020 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 May 29, 2020 16 Use cases for DDoS Open Threat Signaling 17 draft-ietf-dots-use-cases-22 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 November 30, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 7.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 attack 94 detection, mitigation requests, and attack characterization patterns. 96 As DDoS solutions are broadly heterogeneous among vendors, the 97 primary goal of DOTS is to provide high-level interaction amongst 98 differing DDoS solutions, such as detecting DDoS attacks, initiating/ 99 terminating DDoS mitigation assistance, or requesting the status of a 100 DDoS mitigation. 102 This document provides sample use cases that provided input for the 103 design of the DOTS protocols [RFC8772][RFC8773]. The use cases are 104 not exhaustive and future use cases are expected to emerge as DOTS is 105 adopted and evolves. 107 2. Terminology and Acronyms 109 This document makes use of the same terminology and definitions as 110 [RFC8612]. In addition it uses the terms defined below: 112 o DDoS Mitigation Service Provider: designates the administrative 113 entity providing the DDoS Mitigation Service. 115 o DDoS Mitigation System (DMS): A system that performs DDoS 116 mitigation. The DDoS Mitigation System may be composed by a 117 cluster of hardware and/or software resources, but could also 118 involve an orchestrator that may take decisions such as 119 outsourcing some or all of the mitigation to another DDoS 120 Mitigation System. 122 o DDoS Mitigation: The action performed by the DDoS Mitigation 123 System. 125 o DDoS Mitigation Service: designates a service provided to a 126 customer to mitigate DDoS attacks. Service subscriptions usually 127 involve Service Level Agreement (SLA) that have to be met. It is 128 the responsibility of the DDoS Service provider to instantiate the 129 DDoS Mitigation System to meet these SLAs. 131 o Internet Transit Provider (ITP): designates the entity that 132 delivers the traffic to a customer network. It can be an Internet 133 Service Provider (ISP), or an upstream entity delivering the 134 traffic to the ISP. 136 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. 144 For clarity of discussion, the targeted network is indicated as an 145 enterprise network, but the same scenario applies to any downstream 146 network, including residential and cloud hosting networks. 148 As the ITP provides connectivity to the enterprise network, it is 149 already on the path of the inbound and outbound traffic of the 150 enterprise network and well aware of the networking parameters 151 associated to the enterprise network WAN connectivity. This eases 152 both the configuration and the instantiation of a DDoS Mitigation 153 Service. 155 This section considers two kind of DDoS Mitigation Service between an 156 enterprise network and an ITP: 158 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 159 upon receiving a request from the enterprise network. This 160 typically corresponds to the case when the enterprise network is 161 under attack. 163 o On the other hand, the ITP may identify an enterprise network as 164 the source of an attack and send a mitigation request to the 165 enterprise DMS to mitigate this at the source. 167 The two scenarios, thought different, have similar interactions 168 between the DOTS client and server. For the sake of simplicity, only 169 the first scenario will be detailed in this section. Nevertheless, 170 the second scenario is also in scope for DOTS. 172 In the first scenario, as depicted in Figure 1, an enterprise network 173 with self-hosted Internet-facing properties such as Web servers, 174 authoritative DNS servers, and VoIP servers has a DMS deployed to 175 protect those servers and applications from DDoS attacks. In 176 addition to on-premise DDoS defense capability, the enterprise has 177 contracted with its ITP for DDoS Mitigation Services when attacks 178 threaten to overwhelm the bandwidth of their WAN link(s). 180 +------------------+ +------------------+ 181 | Enterprise | | Upstream | 182 | Network | | Internet Transit | 183 | | | Provider | 184 | +--------+ | | DDoS Attack 185 | | DDoS | | <================================= 186 | | Target | | <================================= 187 | +--------+ | | +------------+ | 188 | | +-------->| DDoS | | 189 | | | |S | Mitigation | | 190 | | | | | System | | 191 | | | | +------------+ | 192 | | | | | 193 | | | | | 194 | | | | | 195 | +------------+ | | | | 196 | | DDoS |<---+ | | 197 | | Mitigation |C | | | 198 | | System | | | | 199 | +------------+ | | | 200 +------------------+ +------------------+ 202 * C is for DOTS client functionality 203 * S is for DOTS server functionality 205 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 207 The enterprise DMS is configured such that if the incoming Internet 208 traffic volume exceeds 50% of the provisioned upstream Internet WAN 209 link capacity, the DMS will request DDoS mitigation assistance from 210 the upstream transit provider. More sophisticated detection means 211 may be considered as well. 213 The requests to trigger, manage, and finalize a DDoS Mitigation 214 between the enterprise DMS and the ITP is performed using DOTS. The 215 enterprise DMS implements a DOTS client while the ITP implements a 216 DOTS server which is integrated with their DMS in this example. 218 When the enterprise DMS locally detects an inbound DDoS attack 219 targeting its resources (e.g., servers, hosts, or applications), it 220 immediately begins a DDoS Mitigation. 222 During the course of the attack, the inbound traffic volume to the 223 enterprise network exceeds the 50% threshold and the enterprise DMS 224 escalates the DDoS mitigation. The enterprise DMS DOTS client 225 signals to the DOTS server on the upstream ITP to initiate DDoS 226 Mitigation. The DOTS server replies to the DOTS client that it can 227 serve this request, and mitigation is initiated on the ITP network by 228 the ITP DMS. 230 Over the course of the attack, the DOTS server of the ITP 231 periodically informs the DOTS client on the mitigation status, 232 statistics related to DDoS attack traffic mitigation, and related 233 information. Once the DDoS attack has ended, or decreased to the 234 certain level that the enterprise DMS might handle by itself, the 235 DOTS server signals the enterprise DMS DOTS client that the attack 236 has subsided. 238 The DOTS client on the enterprise DMS then requests the ITP to 239 terminate the DDoS Mitigation. The DOTS server on the ITP receives 240 this request and once the mitigation has ended, confirms the end of 241 upstream DDoS Mitigation to the enterprise DMS DOTS client. 243 The following is an overview of the DOTS communication model for this 244 use-case: 246 o (a) A DDoS attack is initiated against resources of a network 247 organization (here, the enterprise) which has deployed a DOTS- 248 capable DMS - typically a DOTS client. 250 o (b) The enterprise DMS detects, classifies, and begins the DDoS 251 Mitigation. 253 o (c) The enterprise DMS determines that its capacity and/or 254 capability to mitigate the DDoS attack is insufficient, and sends 255 via its DOTS client a DOTS DDoS Mitigation request to one or more 256 DOTS servers residing on the upstream ITP. 258 o (d) The DOTS server which receives the DOTS Mitigation request 259 determines that it has been configured to honor requests from the 260 requesting DOTS client, and honors the request by orchestrating 261 its own DMS. 263 o (e) While the DDoS Mitigation is active, the DOTS server regularly 264 transmits DOTS DDoS Mitigation status updates to the DOTS client. 266 o (f) Informed by the DOTS server status update that the attack has 267 ended or subsided, the DOTS client transmits a DOTS DDoS 268 Mitigation termination request to the DOTS server. 270 o (g) The DOTS server terminates DDoS Mitigation, and sends the 271 notification to the DOTS client. 273 Note that communications between the enterprise DOTS client and the 274 upstream ITP DOTS server may take place in-band within the main 275 Internet WAN link between the enterprise and the ITP; out-of-band via 276 a separate, dedicated wireline network link utilized solely for DOTS 277 signaling; or out-of-band via some other form of network connectivity 278 such as a third-party wireless 4G network connectivity. 280 Note also that a DOTS client that sends a DOTS Mitigation request may 281 be also triggered by a network admin that manually confirms the 282 request to the upstream ITP, in which case the request may be sent 283 from an application such as a web browser or a dedicated mobile 284 application. 286 Note also that when the enterprise is multihomed and connected to 287 multiple upstream ITPs, each ITP is only able to provide a DDoS 288 Mitigation Service for the traffic it transits. As a result, the 289 enterprise network may be required to coordinate the various DDoS 290 Mitigation Services associated to each link. More multi-homing 291 considerations are discussed in [I-D.ietf-dots-multihoming]. 293 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider 295 This use case differs from the previous use case described in 296 Section 3.1 in that the DDoS Mitigation Service is not provided by an 297 upstream ITP. In other words, as represented in Figure 2, the 298 traffic is not forwarded through the DDoS Mitigation Service Provider 299 by default. In order to steer the traffic to the DDoS Mitigation 300 Service Provider, some network configuration changes are required. 301 As such, this use case is likely to apply to large enterprises or 302 large data centers, but as for the other use cases is not exclusively 303 limited to them. 305 Another typical scenario for this use case is for there to be a 306 relationship between DDoS Mitigation Service Providers, forming an 307 overlay of DMS. When a DDoS Mitigation Service Provider mitigating a 308 DDoS attack reaches its resources capacity, it may chose to delegate 309 the DDoS Mitigation to another DDoS Mitigation Service Provider. 311 +------------------+ +------------------+ 312 | Enterprise | | Upstream | 313 | Network | | Internet Transit | 314 | | | Provider | 315 | +--------+ | | DDoS Attack 316 | | DDoS | | <================================= 317 | | Target | | <================================= 318 | +--------+ | | | 319 | | | | 320 | | +------------------+ 321 | | 322 | | +------------------+ 323 | | | DDoS Mitigation | 324 | | | Service Provider | 325 | | | | 326 | +------------+ | | +------------+ | 327 | | DDoS |<------------>| DDoS | | 328 | | Mitigation |C | | S| Mitigation | | 329 | | System | | | | System | | 330 | +------------+ | | +------------+ | 331 +------------------+ +------------------+ 333 * C is for DOTS client functionality 334 * S is for DOTS server functionality 336 Figure 2: DDoS Mitigation between an Enterprise Network and Third 337 Party DDoS Mitigation Service Provider 339 In this scenario, an enterprise network has entered into a pre- 340 arranged DDoS mitigation assistance agreement with one or more third- 341 party DDoS Mitigation Service Providers in order to ensure that 342 sufficient DDoS mitigation capacity and/or capabilities may be 343 activated in the event that a given DDoS attack threatens to 344 overwhelm the ability of the enterprise's or any other given DMS to 345 mitigate the attack on its own. 347 The pre-arrangement typically includes agreement on the mechanisms 348 used to redirect the traffic to the DDoS Mitigation Service Provider, 349 as well as the mechanism to re-inject the traffic back to the 350 Enterprise Network. Redirection to the DDoS Mitigation Service 351 Provider typically involves BGP prefix announcement or DNS 352 redirection, while re-injection of the scrubbed traffic to the 353 enterprise network may be performed via tunneling mechanisms (e.g., 354 GRE). These exact mechanisms used for traffic steering are out of 355 scope of DOTS, but will need to be pre-arranged, while in some 356 contexts such changes could be detected and considered as an attack. 358 In some cases the communication between the enterprise DOTS client 359 and the DOTS server of the DDoS Mitigation Service Provider may go 360 through the ITP carrying the DDoS attack, which would affect the 361 communication. On the other hand, the communication between the DOTS 362 client and DOTS server may take a path that is not undergoing a DDoS 363 attack. 365 +------------------+ +------------------+ 366 | Enterprise | | Upstream | 367 | Network | | Internet Transit | 368 | | | Provider | 369 | +--------+ | | DDoS Attack 370 | | DDoS | |<----------------+ | ++==== 371 | | Target | | Mitigated | | || ++= 372 | +--------+ | | | | || || 373 | | | | | || || 374 | | +--------|---------+ || || 375 | | | || || 376 | | +--------|---------+ || || 377 | | | DDoS Mitigation | || || 378 | | | Service Provider | || || 379 | | | | | || || 380 | +------------+ | | +------------+ | || || 381 | | DDoS |<------------>| DDoS | | || || 382 | | mitigation |C | |S | mitigation |<===++ || 383 | | system | | | | system |<======++ 384 | +------------+ | | +------------+ | 385 +------------------+ +------------------+ 387 * C is for DOTS client functionality 388 * S is for DOTS server functionality 390 Figure 3: Redirection to a DDoS Mitigation Service Provider 392 When the enterprise network is under attack or at least is reaching 393 its capacity or ability to mitigate a given DDoS attack, the DOTS 394 client sends a DOTS request to the DDoS Mitigation Service Provider 395 to initiate network traffic diversion - as represented in Figure 3 - 396 and DDoS mitigation activities. Ongoing attack and mitigation status 397 messages may be passed between the enterprise network and the DDoS 398 Mitigation Service Provider using DOTS. If the DDoS attack has 399 stopped or the severity of the attack has subsided, the DOTS client 400 can request the DDoS Mitigation Service Provider to terminate the 401 DDoS Mitigation. 403 3.3. DDoS Orchestration 405 In this use case, one or more DDoS telemetry systems or monitoring 406 devices monitor a network - typically an ISP network, an enterprise 407 network, or a data center. Upon detection of a DDoS attack, these 408 DDoS telemetry systems alert an orchestrator in charge of 409 coordinating the various DMS's within the domain. The DDoS telemetry 410 systems may be configured to provide required information, such as a 411 preliminary analysis of the observation, to the orchestrator. 413 The orchestrator analyses the various information it receives from 414 DDoS telemetry systems, and initiates one or more DDoS mitigation 415 strategies. For example, the orchestrator could select the DDoS 416 mitigation system in the enterprise network or one provided by the 417 ITP. 419 DDoS Mitigation System selection and DDoS Mitigation techniques may 420 depend on the type of the DDoS attack. In some case, a manual 421 confirmation or selection may also be required to choose a proposed 422 strategy to initiate a DDoS Mitigation. The DDoS Mitigation may 423 consist of multiple steps such as configuring the network, or of 424 updating already instantiated DDoS mitigation functions. Eventually, 425 the coordination of the mitigation may involve external DDoS 426 mitigation resources such as a transit provider or a Third Party DDoS 427 Mitigation Service Provider. 429 The communication used to trigger a DDoS Mitigation between the DDoS 430 telemetry and monitoring systems and the orchestrator is performed 431 using DOTS. The DDoS telemetry system implements a DOTS client while 432 the orchestrator implements a DOTS server. 434 The communication between a network administrator and the 435 orchestrator is also performed using DOTS. The network administrator 436 uses a web interface which interacts with a DOTS client, while the 437 orchestrator implements a DOTS server. 439 The communication between the orchestrator and the DDoS Mitigation 440 Systems is performed using DOTS. The orchestrator implements a DOTS 441 client while the DDoS Mitigation Systems implement a DOTS server. 443 The configuration aspects of each DDoS Mitigation System, as well as 444 the instantiations of DDoS mitigation functions or network 445 configuration is not part of DOTS. Similarly, the discovery of 446 available DDoS mitigation functions is not part of DOTS; and as such 447 is out of scope. 449 +----------+ 450 | network |C (Enterprise Network) 451 | adminis |<-+ 452 | trator | | 453 +----------+ | 454 | 455 +----------+ | S+--------------+ +-----------+ 456 |telemetry/| +->| |C S| DDoS |+ 457 |monitoring|<--->| Orchestrator |<--->| mitigation|| 458 |systems |C S| |<-+ | systems || 459 +----------+ +--------------+C | +-----------+| 460 | +----------+ 461 -----------------------------------|----------------- 462 | 463 | 464 (Internet Transit Provider) | 465 | +-----------+ 466 | S| DDoS |+ 467 +->| mitigation|| 468 | systems || 469 +-----------+| 470 * C is for DOTS client functionality +----------+ 471 * S is for DOTS server functionality 473 Figure 4: DDoS Orchestration 475 The DDoS telemetry systems monitor various network traffic and 476 perform some measurement tasks. 478 These systems are configured so that when an event or some 479 measurement indicators reach a predefined level their associated DOTS 480 client sends a DOTS mitigation request to the orchestrator DOTS 481 server. The DOTS mitigation request may be associated with some 482 optional mitigation hints to let the orchestrator know what has 483 triggered the request. In particular, it's possible for something 484 that locally to one telemetry system looks like an attack is not 485 actually an attack when seen from the broader scope (e.g., of the 486 orchestrator) 488 Upon receipt of the DOTS mitigation request from the DDoS telemetry 489 system, the orchestrator DOTS server responds with an acknowledgment, 490 to avoid retransmission of the request for mitigation. The 491 orchestrator may begin collecting additional fine-grained and 492 specific information from various DDoS telemetry systems in order to 493 correlate the measurements and provide an analysis of the event. 494 Eventually, the orchestrator may ask for additional information from 495 the DDoS telemetry system; however, the collection of this 496 information is out of scope of DOTS. 498 The orchestrator may be configured to start a DDoS Mitigation upon 499 approval from a network administrator. The analysis from the 500 orchestrator is reported to the network administrator via a web 501 interface. If the network administrator decides to start the 502 mitigation, the network administrator triggers the DDoS mitigation 503 request using the web interface of a DOTS client communicating to the 504 orchestrator DOTS server. This request is expected to be associated 505 with a context that provides sufficient information to the 506 orchestrator DOTS server to infer the DDoS Mitigation to elaborate 507 and coordinate. 509 Upon receiving a request to mitigate a DDoS attack aimed at a target, 510 the orchestrator may evaluate the volume of the attack as well as the 511 value that the target represents. The orchestrator may select the 512 DDoS Mitigation Service Provider based on the attack severity. It 513 may also coordinate the DDoS Mitigation performed by the DDoS 514 Mitigation Service Provider with some other tasks such as, for 515 example, moving the target to another network so new sessions will 516 not be impacted. The orchestrator requests a DDoS Mitigation by the 517 selected DDoS mitigation systems via its DOTS client, as described in 518 Section 3.1. 520 The orchestrator DOTS client is notified that the DDoS Mitigation is 521 effective by the selected DDoS mitigation systems. The orchestrator 522 DOTS servers returns this information back to the network 523 administrator. 525 Similarly, when the DDoS attack has stopped, the orchestrator DOTS 526 client is notified and the orchestrator's DOTS servers indicate to 527 the DDoS telemetry systems as well as to the network administrator 528 the end of the DDoS Mitigation. 530 In addition to the above DDoS Orchestration, the selected DDoS 531 mitigation system can return back a mitigation request to the 532 orchestrator as an offloading. For example, when the DDoS attack 533 becomes severe and the DDoS mitigation system's utilization rate 534 reaches its maximum capacity, the DDoS mitigation system can send 535 mitigation requests with additional hints such as its blocked traffic 536 information to the orchestrator. Then the orchestrator can take 537 further actions like requesting forwarding nodes such as routers to 538 filter the traffic. In this case, the DDoS mitigation system 539 implements a DOTS client while the orchestrator implements a DOTS 540 server. Similar to other DOTS use cases, the offloading scenario 541 assumes that some validation checks are followed by the DMS, the 542 orchestrator, or both (e.g., avoid exhausting the resources of the 543 forwarding nodes or inadvertent disruption of legitimate services). 544 These validation checks are part of the mitigation, and are therefore 545 out of the scope of the document. 547 4. Security Considerations 549 The document does not describe any protocol, though there are still a 550 few high-level security considerations to discuss. 552 DOTS is at risk from three primary attacks: DOTS agent impersonation, 553 traffic injection, and signaling blocking. 555 Impersonation and traffic injection mitigation can be mitigated 556 through current secure communications best practices including mutual 557 authentication. Preconfigured mitigation steps to take on the loss 558 of keepalive traffic can partially mitigate signal blocking, but in 559 general it is impossible to comprehensively defend against an 560 attacker that can selectively block any or all traffic. Alternate 561 communication paths that are (hopefully) not subject to blocking by 562 the attacker in question is another potential mitigation. 564 Additional details of DOTS security requirements can be found in 565 [RFC8612]. 567 Service disruption may be experienced if inadequate mitigation 568 actions are applied. These considerations are out of the scope of 569 DOTS. 571 5. IANA Considerations 573 No IANA considerations exist for this document. 575 6. Acknowledgments 577 The authors would like to thank among others Tirumaleswar Reddy; 578 Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon 579 Shallow, Yuuhei Hayashi, the DOTS WG chairs, Roman Danyliw and Tobias 580 Gondrom as well as the Security AD Benjamin Kaduk for their valuable 581 feedback. 583 We also would like to thank Stephan Fouant that was part of the 584 initial co-authors of the documents. 586 7. References 588 7.1. Normative References 590 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 591 Threat Signaling (DOTS) Requirements", RFC 8612, 592 DOI 10.17487/RFC8612, May 2019, 593 . 595 [RFC8772] Hu, S., Eastlake, D., Qin, F., Chua, T., and D. Huang, 596 "The China Mobile, Huawei, and ZTE Broadband Network 597 Gateway (BNG) Simple Control and User Plane Separation 598 Protocol (S-CUSP)", RFC 8772, DOI 10.17487/RFC8772, May 599 2020, . 601 [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based 602 Authentication with an External Pre-Shared Key", RFC 8773, 603 DOI 10.17487/RFC8773, March 2020, 604 . 606 7.2. Informative References 608 [I-D.ietf-dots-multihoming] 609 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 610 Deployment Considerations for Distributed-Denial-of- 611 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 612 multihoming-03 (work in progress), January 2020. 614 Authors' Addresses 616 Roland Dobbins 617 Arbor Networks 618 Singapore 620 EMail: rdobbins@arbor.net 622 Daniel Migault 623 Ericsson 624 8275 Trans Canada Route 625 Saint Laurent, QC 4S 0B6 626 Canada 628 EMail: daniel.migault@ericsson.com 630 Robert Moskowitz 631 HTT Consulting 632 Oak Park, MI 48237 633 USA 635 EMail: rgm@labs.htt-consult.com 636 Nik Teague 637 Iron Mountain Data Centers 638 UK 640 EMail: nteague@ironmountain.co.uk 642 Liang Xia 643 Huawei 644 No. 101, Software Avenue, Yuhuatai District 645 Nanjing 646 China 648 EMail: Frank.xialiang@huawei.com 650 Kaname Nishizuka 651 NTT Communications 652 GranPark 16F 3-4-1 Shibaura, Minato-ku 653 Tokyo 108-8118 654 Japan 656 EMail: kaname@nttv6.jp