idnits 2.17.1 draft-ietf-dots-use-cases-19.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 (July 26, 2019) is 1736 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-02 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: January 27, 2020 Ericsson 6 S. Fouant 8 R. Moskowitz 9 HTT Consulting 10 N. Teague 11 Iron Mountain Data Centers 12 L. Xia 13 Huawei 14 K. Nishizuka 15 NTT Communications 16 July 26, 2019 18 Use cases for DDoS Open Threat Signaling 19 draft-ietf-dots-use-cases-19 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 sample 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 January 27, 2020. 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 . . . . . . . . . . . . . . . . . . . . . 13 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 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 attack 94 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, initiating, terminating 98 DDoS mitigation assistance or requesting the status of a DDoS 99 mitigation. 101 This document provides sample use cases to provide inputs for the 102 design of the DOTS protocols. The use cases are not exhaustive and 103 future use cases are expected to emerge as DOTS is adopted and 104 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 Service Provider: designates the administrative 112 entity providing the DDoS Mitigation Service. 114 o DDoS Mitigation System (DMS): A system that performs DDoS 115 mitigation. The DDoS Mitigation System may be composed by a 116 cluster of hardware and/or software resources, but could also 117 involve an orchestrator that may take decisions such as 118 outsourcing partial or more of the mitigation to another DDoS 119 Mitigation System. 121 o DDoS Mitigation: The action performed by the DDoS Mitigation 122 System. 124 o DDoS Mitigation Service: designates a service provided to a 125 customer to mitigate DDoS attacks. Service subscriptions usually 126 involve Service Level Agreement (SLA) that have to be met. It is 127 the responsibility of the DDoS Service provider to instantiate the 128 DDoS Mitigation System to meet these SLAs. 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 141 Internet Transit Provider (ITP) in order to mitigate a DDoS attack 142 targeting its network. 144 To improve the clarity of our purpose, the targeted network will be 145 designated as enterprise network, but the same scenario applies to 146 any downstream network, including residential network and cloud 147 hosting network. 149 As the ITP provides connectivity to the enterprise network, it is 150 already on the path of the inbound and outbound traffic of the 151 enterprise network and well aware of the networking parameters 152 associated to the enterprise network WAN connectivity. This eases 153 both the configuration and the instantiation of a DDoS Mitigation 154 Service. 156 This section considers two kind of DDoS Mitigation Service between an 157 enterprise network and an ITP: 159 o The upstream ITP may instantiate a DDoS Mitigation System (DMS) 160 upon receiving a request from the enterprise network. This 161 typically corresponds to the case when the enterprise network is 162 under attack. 164 o On the other hand, the ITP may identify an enterprise network as 165 the source of an attack and send a mitigation request to the 166 enterprise DMS to mitigate this at the source. 168 The two scenarios, thought different, have similar interactions 169 between the DOTS client and server. For the sake of simplicity, only 170 the first scenario will be detailed in this section. Nevertheless, 171 the second scenario is also in scope of DOTS. 173 In the first scenario, as depicted in Figure 1, an enterprise network 174 with self-hosted Internet-facing properties such as Web servers, 175 authoritative DNS servers, and VoIP servers has a DMS deployed to 176 protect those servers and applications from DDoS attacks. In 177 addition to on-premise DDoS defense capability, the enterprise has 178 contracted with its ITP for DDoS Mitigation Services which threaten 179 to overwhelm their WAN link(s) bandwidth. 181 +------------------+ +------------------+ 182 | Enterprise | | Upstream | 183 | Network | | Internet Transit | 184 | | | Provider | 185 | +--------+ | | DDoS Attack 186 | | DDoS | | <================================= 187 | | Target | | <================================= 188 | +--------+ | | +------------+ | 189 | | +-------->| DDoS | | 190 | | | |S | Mitigation | | 191 | | | | | System | | 192 | | | | +------------+ | 193 | | | | | 194 | | | | | 195 | | | | | 196 | +------------+ | | | | 197 | | DDoS |<---+ | | 198 | | Mitigation |C | | | 199 | | System | | | | 200 | +------------+ | | | 201 +------------------+ +------------------+ 203 * C is for DOTS client functionality 204 * S is for DOTS server functionality 206 Figure 1: Upstream Internet Transit Provider DDoS Mitigation 208 The enterprise DMS is configured such that if the incoming Internet 209 traffic volume exceeds 50% of the provisioned upstream Internet WAN 210 link capacity, the DMS will request DDoS mitigation assistance from 211 the upstream transit provider. More sophisticated detection means 212 may be considered. 214 The requests to trigger, manage, and finalize a DDoS Mitigation 215 between the enterprise DMS and the ITP is performed using DOTS. The 216 enterprise DMS implements a DOTS client while the ITP implements a 217 DOTS server which is integrated with their DMS in this example. 219 When the enterprise DMS locally detects an inbound DDoS attack 220 targeting its resources (e.g., servers, hosts, or applications), it 221 immediately begins a DDoS Mitigation. 223 During the course of the attack, the inbound traffic volume to the 224 enterprise network exceeds the 50% threshold and the enterprise DMS 225 escalates the DDoS mitigation. The enterprise DMS DOTS client 226 signals to the DOTS server on the upstream ITP to initiate DDoS 227 Mitigation. The DOTS server replies to the DOTS client that it can 228 serve this request, and mitigation is initiated on the ITP network by 229 the ITP DMS. 231 Over the course of the attack, the DOTS server of the ITP 232 periodically informs the DOTS client on the enterprise DMS mitigation 233 status, statistics related to DDoS attack traffic mitigation, and 234 related information. Once the DDoS attack has ended, or decreased to 235 the certain level that the enterprise DMS can handle by itself, the 236 DOTS server signals the enterprise DMS DOTS client that the attack 237 has subsided. 239 The DOTS client on the enterprise DMS then requests the ITP to 240 terminate the DDoS Mitigation. The DOTS server on the ITP receives 241 this request and once the mitigation has ended, confirms the end of 242 upstream DDoS Mitigation to the enterprise DMS DOTS client. 244 The following is an overview of the DOTS communication model for this 245 use-case: 247 o (a) A DDoS attack is initiated against resources of a network 248 organization (here, the enterprise) which has deployed a DOTS- 249 capable DMS - typically a DOTS client. 251 o (b) The enterprise DMS detects, classifies, and begins the DDoS 252 Mitigation. 254 o (c) The enterprise DMS determines that its capacity and/or 255 capability to mitigate the DDoS attack is insufficient, and sends 256 via its DOTS client a DOTS DDoS Mitigation request to one or more 257 DOTS servers residing on the upstream ITP. 259 o (d) The DOTS server which receives the DOTS Mitigation request 260 determines that it has been configured to honor requests from the 261 requesting DOTS client, and honors its DDoS Mitigation by 262 orchestrating its DMS. 264 o (e) While the DDoS Mitigation is active, the DOTS server regularly 265 transmits DOTS DDoS Mitigation status updates to the DOTS client. 267 o (f) Informed by the DOTS server status update that the attack has 268 ended or subsided, the DOTS client transmits a DOTS DDoS 269 Mitigation termination request to the DOTS server. 271 o (g) The DOTS server terminates DDoS Mitigation, and sends the 272 notification to the DOTS client. 274 Note that communications between the enterprise DOTS client and the 275 upstream ITP DOTS server may take place in-band within the main 276 Internet WAN link between the enterprise and the ITP; out-of-band via 277 a separate, dedicated wireline network link utilized solely for DOTS 278 signaling; or out-of-band via some other form of network connectivity 279 such as a third-party wireless 4G network connectivity. 281 Note also that a DOTS client that sends a DOTS Mitigation request may 282 be also triggered by a network admin that manually confirms the 283 request to the upstream ITP, in which case the request may be sent 284 from an application such as a web browser or a dedicated mobile 285 application. 287 Note also that when the enterprise is multihomed and connected to 288 multiple upstream ITPs, each ITP is only able to provide a DDoS 289 Mitigation Service for the traffic it transits. As a result, the 290 enterprise network may require to coordinate the various DDoS 291 Mitigation Services associated to each link. More multi-homing 292 considerations are discussed in [I-D.ietf-dots-multihoming]. 294 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider 296 This use case differs from the previous use case described in 297 Section 3.1 in that the DDoS Mitigation Service is not provided by an 298 upstream ITP. In other words, as represented in Figure 2, the 299 traffic is not forwarded through the DDoS Mitigation Service Provider 300 by default. In order to steer the traffic to the DDoS Mitigation 301 Service Provider, some network configuration changes are required. 302 As such, this use case is likely to match large enterprises or large 303 data centers, but not exclusively. 305 Another typical scenario for this use case is the relation between 306 DDoS Mitigation Service Providers forming an overlay of DMS. When a 307 DDoS Mitigation Service Provider mitigating a DDoS attack reaches it 308 resources capacities, it may chose to delegate the DDoS Mitigation to 309 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 other 341 DDoS Mitigation Service Providers in order to ensure that sufficient 342 DDoS mitigation capacity and/or capabilities may be activated in the 343 event that a given DDoS attack threatens to overwhelm the ability of 344 the enterprise's or any other given DMS to mitigate the attack on its 345 own. 347 The pre-arrangement typically includes the agreement on the 348 mechanisms used to redirect the traffic to the DDoS Mitigation 349 Service Provider, as well as the mechanism to re-inject the traffic 350 back to the Enterprise Network. Redirection to the DDoS Mitigation 351 Service 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. 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 traffic, the 393 DOTS client sends a DOTS request to the DDoS Mitigation Service 394 Provider to initiate network traffic diversion - as represented in 395 Figure 3 - and DDoS mitigation activities. Ongoing attack and 396 mitigation status messages may be passed between the enterprise 397 network and the DDoS Mitigation Service Provider using DOTS. If the 398 DDoS attack has stopped or the severity of the attack has subsided, 399 the DOTS client can request the DDoS Mitigation Service Provider to 400 stop the 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 information it receives from 413 DDoS telemetry system, and initiates one or multiple DDoS mitigation 414 strategies. For example, the orchestrator could select the DDoS 415 mitigation system in the enterprise network or one provided by the 416 ITP. 418 DDoS Mitigation System selection and DDoS Mitigation techniques may 419 depends 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 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 a web interface which interacts with a DOTS client, while the 436 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 network traffic and 475 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. 484 Upon receipt of the DOTS mitigation request from the DDoS telemetry 485 system, the orchestrator DOTS server responds with an acknowledgment, 486 to avoid retransmission of the request for mitigation. The 487 orchestrator may begin collecting additional fine-grained and 488 specific information from various DDoS telemetry systems in order to 489 correlate the measurements and provide an analysis of the event. 490 Eventually, the orchestrator may ask for additional information from 491 the DDoS telemetry system; however, the collection of this 492 information is out of scope. 494 The orchestrator may be configured to start a DDoS Mitigation upon 495 approval from a network administrator. The analysis from the 496 orchestrator is reported to the network administrator via a web 497 interface. If the network administrator decides to start the 498 mitigation, the network administrator triggers the DDoS mitigation 499 request using the web interface of a DOTS client communicating to the 500 orchestrator DOTS server. This request is expected to be associated 501 with a context that provides sufficient information to the 502 orchestrator DOTS server to infer the DDoS Mitigation to elaborate 503 and coordinate. 505 Upon receiving a request to mitigate a DDoS attack performed over a 506 target, the orchestrator may evaluate the volumetry of the attack as 507 well as the value that the target represents. The orchestrator may 508 select the DDoS Mitigation Service Provider based on the attack 509 severity. It may also coordinate the DDoS Mitigation performed by 510 the DDoS Mitigation Service Provider with some other tasks such as 511 for example, moving the target to another network so new sessions 512 will not be impacted. The orchestrator requests a DDoS Mitigation to 513 the selected DDoS mitigation systems via its DOTS client, as 514 described in Section 3.1. 516 The orchestrator DOTS client is notified that the DDoS Mitigation is 517 effective by the selected DDoS mitigation systems. The orchestrator 518 DOTS servers returns back this information to the network 519 administrator. 521 Similarly, when the DDoS attack has stopped, the orchestrator DOTS 522 client are being notified and the orchestrator's DOTS servers 523 indicate to the DDoS telemetry systems as well as to the network 524 administrator the end of the DDoS Mitigation. 526 In addition to the above DDoS Orchestration, the selected DDoS 527 mitigation systems can return back a mitigation request to the 528 orchestrator as an offloading. When the DDoS attack becomes severe 529 and the DDoS mitigation system's utilization rate reaches its maximum 530 capacity, the DDoS mitigation system can send mitigation requests 531 with additional hints such as its blocked traffic information to the 532 orchestrator. Then the orchestrator can take further actions like 533 requesting forwarding nodes such as routers to filter the traffic. 534 In this case, the DDoS mitigation system implements a DOTS client 535 while the orchestrator implements a DOTS server. 537 4. Security Considerations 539 The document does not describe any protocol. 541 DOTS is at risk from three primary attacks: DOTS agent impersonation, 542 traffic injection, and signaling blocking. 544 Impersonation and traffic injection mitigation can be mitigated 545 through current secure communications best practices. Preconfigured 546 mitigation steps to take on the loss of keepalive traffic can 547 partially mitigate signal blocking, but in general it is impossible 548 to comprehensively defend against an attacker that can selectively 549 block any or all traffic 551 Additional details of DOTS security requirements can be found in 552 [RFC8612]. 554 5. IANA Considerations 556 No IANA considerations exist for this document. 558 6. Acknowledgments 560 The authors would like to thank among others Tirumaleswar Reddy; 561 Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon 562 Shallow, Yuuhei Hayashi, the DOTS WG chairs, Roman Danyliw and Tobias 563 Gondrom as well as the Security AD Benjamin Kaduk for their valuable 564 feedback. 566 7. Informative References 568 [I-D.ietf-dots-multihoming] 569 Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment 570 Considerations for Distributed-Denial-of-Service Open 571 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 572 (work in progress), July 2019. 574 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 575 Threat Signaling (DOTS) Requirements", RFC 8612, 576 DOI 10.17487/RFC8612, May 2019, 577 . 579 Authors' Addresses 581 Roland Dobbins 582 Arbor Networks 583 Singapore 585 EMail: rdobbins@arbor.net 586 Daniel Migault 587 Ericsson 588 8275 Trans Canada Route 589 Saint Laurent, QC 4S 0B6 590 Canada 592 EMail: daniel.migault@ericsson.com 594 Stefan Fouant 595 USA 597 EMail: stefan.fouant@copperriverit.com 599 Robert Moskowitz 600 HTT Consulting 601 Oak Park, MI 48237 602 USA 604 EMail: rgm@labs.htt-consult.com 606 Nik Teague 607 Iron Mountain Data Centers 608 UK 610 EMail: nteague@ironmountain.co.uk 612 Liang Xia 613 Huawei 614 No. 101, Software Avenue, Yuhuatai District 615 Nanjing 616 China 618 EMail: Frank.xialiang@huawei.com 620 Kaname Nishizuka 621 NTT Communications 622 GranPark 16F 3-4-1 Shibaura, Minato-ku 623 Tokyo 108-8118 624 Japan 626 EMail: kaname@nttv6.jp