idnits 2.17.1 draft-nishizuka-dots-inter-domain-mechanism-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 15) being 77 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 27, 2016) is 2669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ITU-T X.509' is mentioned on line 546, but not defined == Unused Reference: 'I-D.draft-reddy-dots-transport' is defined on line 1286, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-dots-use-cases (ref. 'I-D.draft-ietf-dots-use-cases') == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-requirements (ref. 'I-D.draft-ietf-dots-requirements') ** Downref: Normative reference to an Informational draft: draft-mortensen-dots-architecture (ref. 'I-D.draft-mortensen-dots-architecture') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS K. Nishizuka 3 Internet-Draft NTT Communications 4 Intended status: Standards Track L. Xia 5 Expires: June 30, 2017 J. Xia 6 Huawei Technologies Co., Ltd. 7 D. Zhang 9 L. Fang 10 Microsoft 11 C. Gray 12 Comcast, Inc. 13 R. Compton 14 Charter Communications, Inc. 15 December 27, 2016 17 Inter-organization cooperative DDoS protection mechanism 18 draft-nishizuka-dots-inter-domain-mechanism-02 20 Abstract 22 As DDoS attacks evolve rapidly in the aspect of volume and 23 sophistication, cooperation among operators has become very necessary 24 because it gives us quicker and more sophisticated protection to cope 25 with the varius DDoS attacks. This document describes possible 26 mechanisms which implement the cooperative inter-organization DDoS 27 protection by DOTS protocol. The described data models are intended 28 to cover intra-organization and inter-organization solutions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 30, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 69 3. Inter-organization DDoS Protection Requirements . . . . . . . 4 70 3.1. Provisioning Requirements . . . . . . . . . . . . . . . . 4 71 3.1.1. Automatic Provisioning vs Manual Provisioning . . . . 5 72 3.2. Coordination Requirements . . . . . . . . . . . . . . . . 5 73 3.2.1. Near Source Protection Problem . . . . . . . . . . . 5 74 3.3. Returning Path Requirements . . . . . . . . . . . . . . . 6 75 4. Inter-organization DOTS Architecture . . . . . . . . . . . . 6 76 4.1. Distributed Architecture . . . . . . . . . . . . . . . . 7 77 4.2. Centralized Architecture . . . . . . . . . . . . . . . . 10 78 5. Inter-organization DOTS Protocol . . . . . . . . . . . . . . 11 79 5.1. Provisioning Stage . . . . . . . . . . . . . . . . . . . 13 80 5.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . 13 81 5.1.2. Operations . . . . . . . . . . . . . . . . . . . . . 17 82 5.2. Signaling Stage . . . . . . . . . . . . . . . . . . . . . 18 83 5.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 18 84 5.2.2. Operations . . . . . . . . . . . . . . . . . . . . . 24 85 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 86 6.1. Billing Data . . . . . . . . . . . . . . . . . . . . . . 25 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 9. Normative References . . . . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 These days, DDoS attacks are getting bigger and more sophisticated. 95 All organizations facing to the internet should be prepared for such 96 attacks in order to minimize damages to their business. There are 97 still too big platforms of DDoS attacks which consist of vulnerable 98 servers, broadband routers and other network equipments including IoT 99 devices distributed all over the world. Because of the amplification 100 feature of the reflection attack, attackers can generate massive 101 attacks with small resources. Moreover, there are many booters who 102 are selling DDoS attacks as a service. DDoS attack is commoditized, 103 so frequency of DDoS attacks is also increasing. 105 These trends of the attack could exceed a capacity of a protection 106 system of one organization in the aspect of volume and frequency. 107 Therefore, sharing the capacity and capability of the protection 108 system with each other has become very necessary. 110 By utilizing other organization's resources, the burden of the 111 protection can be shared. The shared resources are not only CPU/ 112 memory resources of dedicated mitigation devices but also the 113 capability of mitigation actions such as blackholing and filtering. 114 We call the protection which utilize resources of each other 115 "cooperative DDoS protection". 117 The cooperative DDoS protection have numerous merits. First, as 118 described above, it can leverage the capacity of the protection by 119 sharing the resources among organizations. Generally DDoS attack 120 happens unexpectedly, thus the capacity utilization ratio of a 121 protection system is not constant. So, while the utilization ratio 122 is low, it can be used by other organization which is under attack. 123 Second, organizations can get various countermeasures. If an attack 124 is highly sophisticated and there is no countermeasure in the system, 125 cooperative DDoS protection can offer optimal countermeasure of all 126 partners. Third, it can block malicious traffic near to the origin 127 of the attack. Near source defense is ideal for the health of the 128 internet because it can reduce the total cost of forwarding packets 129 which are mostly consist of useless massive attack traffic. 130 Sometimes uplink circuits get congested by massive attacks, so 131 cooperative DDoS protection by uplink organization is the only way to 132 solve such a congestion problem. Finally, it can reduce time to 133 respond. After getting attacked, prompt response is important 134 because the outage of the service can make significant loss to the 135 victim organization. Cooperating channel between partner 136 organizations can be automated by DOTS protocol. 138 The proposed solutions are covering both intra-organization and 139 inter-organization situations. 141 1.1. Scope 143 The solutions described in this draft are based on intra-organization 144 and inter-organization usecases in [I-D.draft-ietf-dots-use-cases]. 145 The DOTS protocols coordinating DDoS protection in inter-organization 146 situations in this draft are compliant with requirements in [I- 147 D.draft-ietf-dots-requirements]. Generally DOTS is assumed to be 148 most effective when aiding coordination of attack response between 149 two or more organizations, but single organization scenarios are also 150 valuable[I-D.draft-mortensen-dots-architecture]. The data model 151 described in this draft is mainly focusing on inter-organization 152 coordination of DDoS protection because it also covers single 153 organization scenarios. The information required in single 154 organization scenarios is assumed to be a subset of the information 155 required in inter-organization scenarios. 157 2. Terminology 159 2.1. Key Words 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 2.2. Definition of Terms 167 This document uses the terms defined in [I-D.draft-ietf-dots- 168 requirements]. 170 3. Inter-organization DDoS Protection Requirements 172 In this section, requirements unique to inter-organization 173 cooperative DDoS protection are described. 175 3.1. Provisioning Requirements 177 In inter-organization situation, a DOTS client is in a different 178 organization from a DOTS server. To enable the protection in other 179 organization, provisioning information should be informed to a DOTS 180 server in advance. In the later section, the total scenario is 181 divided into two stages: provisioning stage and signaling stage. In 182 provisioning stage, a DOTS client is required to communicate 183 registration messages with DOTS server which include the capacity 184 building of protection. The data model of registration message is 185 defined in the protocol section of this draft. It is also required 186 to find a way to provision other organization's DDoS protection 187 service in secure manner. All of the messages should have 188 confidentiality, integrity and authenticity. The requirments of the 189 message protocol is following [I-D.draft-ietf-dots-requirements]. 191 3.1.1. Automatic Provisioning vs Manual Provisioning 193 Manual provisioning is easier way to utilize DDoS protection service 194 of other organizations. An organization can trust other organization 195 who are going to use their DDoS protection service by any means like 196 phone, e-mail, Web portal, etc,. However, it will take much time to 197 provision the DDoS protection system, therefore the attack will 198 succeed to make significant impact on the protected service. To 199 reduce the time to start the protection, automatic provisioning is 200 desirable. If an organization could build a capacity of protection 201 by exchanging information of the DDoS protection service via dots 202 protocol in short time, the cooperative DDoS protection will succeed 203 at a certain level. Other important works carried out in the 204 bootstrapping process are auto-discovery, automatic capability 205 building between the member DDoS protection service providers as the 206 basis for the following coordination process. 208 3.2. Coordination Requirements 210 The number of the member DDoS protection service provider of 211 cooperative DDoS protection is important factor. If only two 212 providers are involved, there is a bilateral relationship only. It 213 is easy to negotiate about the capacity of their own DDoS protection 214 system. In the state of emergency, they can decide to ask for help 215 each other if the capacity of their own system is insufficient. When 216 a lot of providers are joining cooperative DDoS protection, it is 217 difficult to decide where to ask for help. They need to negotiate 218 about their capacity with every participant. It is needed to take 219 into account all combinations to do appropriate protection. The 220 coordination between the member providers of cooperative DDoS 221 protection is a complete process consisting of mitigation start/stop, 222 status notification, mitigation policy updates and so on. The Inter- 223 organization DOTS architectures described in the later section are 224 intended to fulfill these requirements. 226 3.2.1. Near Source Protection Problem 228 Stopping malicious traffic at the nearest point in the internet will 229 reduce exhaustion of resources in all the path of the attack. To 230 find the entry point of the attack, traceback of the attack traffic 231 to the origin is needed. If there is cooperative partner near the 232 attack source, asking for help to that network is most effective. 233 However, the problem is that it is difficult to decide which network 234 is nearest to the attack source because in many cases source address 235 of attack packets are spoofed to avoid to be visible from others. 237 Moreover, uncovering some topology information of operator's network 238 would be required in order to make the decision correctly, however 239 there could be privacy protection issue between operators. Those 240 problems will lead to the difficulties of locating the attack source. 242 3.3. Returning Path Requirements 244 As one of protection methods, some DDoS protection service provider 245 announce BGP route to detour the attack traffic to their own network 246 to deal with it. After scrubbing, cleaned traffic should be returned 247 to the original destination. The returning path is often called 248 "clean pipe". The DDoS service provider should be careful about 249 routing loop because if the end point of a clean pipe is still 250 included in a reach of the announced BGP route, the traffic will 251 return to the mitigation path again and again. In the case of inter- 252 organization DDoS protection, returning path information should be 253 propagated to partners. 255 4. Inter-organization DOTS Architecture 257 With the fast growth of DDoS attack volume and sophistication, a 258 global cooperative DDoS protection service is desirable. This 259 service can not only address the inter-organization uplink congestion 260 problem, but also take full advantage of global DDoS mitigation 261 resources from different operators efficiently and enable the near 262 source mitigation. Moreover, with the way of providing DDoS 263 mitigation as service, more customers will get the service flexibly 264 by their demands with maximized territory and resources. Together 265 with on- premise DDoS protection appliance, the multiple layer DDoS 266 protection system provides a comprehensive DDoS protection against 267 all types of attacks, such as application layer attacks, network 268 layer large traffic attacks and others. 270 DOTS protocol is used among DOTS agents to facilitate the coordinated 271 DDoS protection service as a whole. [I-D.draft-ietf-dots-use-cases] 272 lists most options that DOTS agents could be, and describes their 273 communications. Although this document is initiated to specify the 274 DOTS protocol for the inter-organization use cases, the final 275 protocol would and should be the same since it is all about the 276 signaling messages and their process between the DOTS clients and 277 DOTS servers essentially. In other words, the protocol described 278 here would also apply to all the intra-organization use cases. To 279 support all the identified use cases and possibly new use cases in 280 future, DOTS protocol must be extensible in terms of the message 281 definition, protocol process, etc, which will be discussed in details 282 in the following section. The text below discusses the protocol 283 mainly in respect of inter-organization use cases. 285 The inter-organization DDoS protection service is set up by the 286 member operators' own DDoS protection system and the coordination 287 protocol between them. The inter-organization protocol for the goal 288 of DDoS protection coordination is the main focus of this document. 289 Note that both network operators and cloud based DDoS protection 290 service providers can participate in the inter-organization DDoS 291 protection service. In general, the member operator's own DDoS 292 protection system should at least consist of attack detector, 293 customer (DOTS client), controller (DOTS server, and possible DOTS 294 client for the inter-organization use cases) and mitigator. 296 Attack Detector: be responsible for attack detection and source 297 traceback. An example is the flow analyzer 299 Customer: when certain DDoS attack is detected, it requests 300 mitigation service to the controller and exchanges status with 301 controller regularly 303 Controller: be responsible for intra-organization DDoS mitigation 304 controlling and communication with customer and other 305 operators' controller for inter-organization coordination 307 Mitigator: be responsible for mitigation and results reporting 309 There are two ways for operators to implement the inter-organization 310 DDoS protection service: distributed way or centralized way. The 311 following parts give the respective discussion to them with aligning 312 to DOTS terms. 314 4.1. Distributed Architecture 316 Operators can set up the bilateral cooperative relation of DDoS 317 protection between each other, thereby a distributed inter- 318 organization DDoS protection service is realized, which has the peer 319 to peer Communication among all the participated operators. The 320 distributed architecture is illustrated in the following diagram: 322 Customer 323 +-------+ 324 |DOTS | 325 |Client | 326 +----A--+ 327 | 328 ---------------- --+------ 329 ////- \\\\ /// | \\\ 330 /// +-----------------------------+-------+ \\ 331 // +-----------------+-------+ \\ / | | \ 332 || | | | || +-----V-+-----V-+ | 333 | +----V----------+ +---V---+---V---+ | | |DOTS |DOTS | | 334 | |DOTS |DOTS <-->DOTS |DOTS <--+----+--->Server |Client | | 335 | |Server |Client | |Server |Client | | | +-----A-+------A+ | 336 | +--A----+-------+ +----A--+---A---+ | | Controller / | 337 | | Controller Controller\ | | / / | 338 || | | \ \ || \ // // / 339 \\| | \ // \\/ ISP2 / // 340 |\\ ISP1 | \ // \ / \\ / /// 341 | \\\\- | -//// \ / ----/---- 342 | -+-----------+- \ \ / / 343 | | \ \ / / 344 | | \ \ / / 345 +---V---+ +----V--+ \ -----/--- // 346 |DOTS | |DOTS | \// / \\ \\ / 347 |Client | |Client | // \ / \ /\\ 348 +-------+ +-------+ / \ / \ / \ 349 Customer Customer +---V---+----V--+ | +-------+ 350 | |DOTS |DOTS | | |DOTS | 351 | |Client |Server <---+---->Client | 352 | +-------+-------+ | +-------+ 353 | Controller | Customer 354 | | 355 \ cloud based / 356 \\ Anti-DDoS // 357 \\\ Provider /// 358 -------- 360 Figure 1: Distributed Architecture for Inter-organization DDoS 361 Protection Service 363 As shown in above diagram, when the customer is suffering a large 364 traffic DDoS attack, it acts as the DOTS client to request DDoS 365 protection service to its operator. The operator's controller acts 366 as the DOTS server to authenticate the customer's validity and then 367 initiate the intra-organization DDoS mitigation service with its own 368 resource for the customer. If the controller finds the attack volume 369 exceeds it capacity, or the attack type is unknown type, or its 370 inter-organization upstream link is congested, it should act as the 371 DOTS client to request inter-organization coordinated DDoS Protection 372 service to its upstream operators' controller which it has 373 cooperative relation with. The operator's controller should support 374 the functions of DOTS server and DOTS client at the same time in 375 order to participate in the system of inter-organization DDoS 376 protection service. In other words, as the representative for an 377 operator's DDoS protection service, the controller manages and 378 provides DDoS mitigation service to its customer in one hand, but may 379 require helps from other operators under some situation especially 380 when the attack volume exceeds its capacity or the attack is from 381 other operators. The inter-organization coordination can be a 382 repeated process until the nearest operator located from the attack 383 source receives the inter-organization coordination request and 384 starts to mitigate the attack traffic. 386 In particular, each operator is able to decide its responding actions 387 to its peering operator's request flexibly by its internal policies, 388 such as whether or not perform the mitigation function, or relay the 389 request message to other operators. But these are out of the scope 390 of this document. 392 The distributed architecture is straightforward and simple when the 393 number of member operators are not too large. For deployment, all 394 the work an operator needs to do is to configure other cooperative 395 member operator's information (i.e., IP, port, DNS name, etc) and 396 relevant policies for subsequent inter-organization communication. 397 Regarding to operation, each operator's controller just performs the 398 mitigation service according to customer's request and possibly 399 requests for inter-organization helps to other operators if 400 necessary. In the meantime, the mitigation report and statistics 401 information is exchanged between the peering operators for the goal 402 of monitoring and accounting. 404 Some points for this architecture are noted as below: 406 o Every operator controller only has the information of those 407 opeators which have cooperative relation with it, and does not 408 necessarily have the information of all operators participated in 409 the inter-organization DDoS protection service. The incomplete 410 information may not lead to the most optimized operation 412 o When the number of member operators is very large, a new joining 413 operator will be required to configure and maintain a lot of 414 peering operators' information. It's very complex and error-prone 416 o Due to the exclusive repeating nature of the this architecture 417 mentioned above, it's possible that the really effective 418 mitigation service by one upstream operator starts after several 419 rounds of repeating the inter-organization coordination process. 420 It may take a long time and is unacceptable 422 4.2. Centralized Architecture 424 For the centralized architecture, the biggest difference from the 425 distributed architecture is that a centralized orchestrator exists 426 for controlling the inter-organization DDoS protection coordination 427 centrally. The centralized architecture for the inter-organization 428 DDoS protection service is illustrated in the following diagram: 430 Orchestrator 431 +-------+-------+ 432 ADOTS |DOTS A 433 /|Server |Client |\ 434 / +---AA--+A--A---+ \ 435 / | \ / \ 436 / |/ /\ \ 437 / /| / \ \ 438 -----/---------- / / \ --\------ 439 ////- / /\\\\| \ /// \ \\\ 440 /// / / / |\\ \ // \ \\ 441 // / / / | \\ \/ \ \ 442 || / / / | || \ +-------+---V---+ | 443 | +-----V---------+ /+---V---+---V---+ | | \|DOTS |DOTS | | 444 | |DOTS |DOTS V |DOTS |DOTS | | | VClient |Server | | 445 | |Client |Server | |Server |Client | | | +-------+---A---+ | 446 | +-------+---A---+ +----A--+-------+ | | Controller | | 447 | Controller | | Controller | | | | 448 || | | || \ | / 449 \\ | | // \\ ISP2 | // 450 \\\ | ISP1 | // \\\ |/// 451 \\\\- | | -//// --------+ 452 -+-----------+- | 453 | | | 454 | | | 455 +-----V-+ +----V--+ +---V---+ 456 |DOTS | |DOTS | |DOTS | 457 |Client | |Client | |Client | 458 +-------+ +-------+ +-------+ 459 Customer Customer Customer 461 Figure 2: Centralized Architecture for Inter-organization DDoS 462 Protection Service 464 As shown in above diagram, the orchestrator is the core component to 465 the whole system. Each operator controller only communicates with it 466 for the goal of registering, coordination requesting and reporting. 467 When it receives the inter-organization coordination request message 468 from the operator controller, a simple way is to notify all the other 469 operator controllers which have registered to the orchestrator, to 470 enable the possible mitigation services. Another way is to choose a 471 number of operators to notify them to enable the mitigation services 472 according to the traceback result or other policies. The details 473 about traceback are to be discussed in future. Based on the above 474 analysis, the orchestrator is also a combination of DOTS server and 475 DOTS client which support both functions at the same time. 477 In addition to the orchestrator and its related functions, the 478 signaling and operations of centralized architecture are very similar 479 to the distributed architecture. 481 The centralized architecture has its own characteristics as below: 483 o Since it is the centralized architecture, the orchestrator is easy 484 to suffer the single failure problem like failure, congestion and 485 performance downgrade, which directly influences the availability 486 of the whole system. This can be improved by some redundancy 487 mechanism 489 o A centralized orchestrator facilitates the auto-discovery 490 mechanism for the member operators. And for each controller, its 491 deployment and operation becomes easy since it is only required to 492 communicate with the orchestrator during the whole process 494 o Due to the direct communication between the orchestrator and all 495 controllers, the inter-organization DDoS coordination is able to 496 be finished in a short and fixed time period 498 o Only the central orchestrator is required to support different 499 transport protocols (e.g., TCP, UDP, CoAP) to communicate with all 500 the controllers. The orchestrator is able to translate and relay 501 different transport protocols among all the operators. So, the 502 operator controller uses one transport protocol to communicate 503 with orchestrator and is not required to support multiple kinds of 504 transport protocol 506 5. Inter-organization DOTS Protocol 508 According to [I-D.draft-ietf-dots-requirements], DOTS protocols MUST 509 take steps to protect the confidentiality, integrity and authenticity 510 of messages sent between the DOTS client and server, and provide peer 511 mutual authentication between the DOTS client and server before a 512 DOTS session is considered active. The DOTS agents can use HTTPS 513 (with TLS) for the goal of protocol security. The HTTP RESTful APIs 514 are used in this section as the protocol channel, and the DOTS 515 message content can be in JSON format. 517 With respect to the inter-organization DOTS protocol, all the DOTS 518 messages are exchanged between DOTS client and server, no matter what 519 the architecture (distributed or centralized) is. So, the message 520 formats and operations of DOTS protocol ought to be the same for all 521 architecture options. The DOTS messages can be categorized by which 522 time period they are mainly required in for DDoS protection, as 523 below: 525 o Provisioning stage: Before getting attacked by malicious traffic, 526 a DOTS client should register itself to the DOTS server, as well 527 as enable capacity building in advance 529 o Signaling stage: Once the DOTS client has registered itself to the 530 DOTS server, the DOTS session is created between them and the 531 signaling stage begins. The signaling stage ends when the DOTS 532 client cancels its registration to the DOTS server and the DOTS 533 session is closed. During the signaling stage, the DOTS client 534 should ask the DOTS server for DDoS mitigation service to the 535 customer service under attack once the attack is detected. When 536 the attack is over, the DOTS client should notify the DOTS server 537 to stop the mitigation service. 539 DOTS protocol can run on HTTPS (with TLS) and support several 540 different ways for authentication: 542 o Employ bidirectional certificate authentication ([ITU-T X.509]) on 543 the DOTS server and client: Both DOTS server and client need to 544 verify the certificates of each other 546 o Employ unidirectional certificate authentication ([ITU-T X.509]) 547 on the DOTS server: Only the DOTS server needs to install the 548 certificate. The DOTS client needs to verify its certificate. In 549 the opposite direction, DOTS server can authenticate DOTS client 550 by the ways of user/role:password, IP address white-list or 551 digital signature 553 o Employ bidirectional digital signature authentication on the DOTS 554 server and client: In this condition, the DOTS server and client 555 must keep the customer's private key safely, which is used for 556 calculate the digital signature 558 Besides authenticating the DOTS client, the DOTS server also verifies 559 the timestamp of the packets from the DOTS client. If the time 560 difference between the timestamp and the current time of the DOTS 561 server exceeds the specified threshold (60 seconds as an example), 562 the DOTS server will consider the packet invalid and will not process 563 it. Therefore, NTP must be configured on both the DOTS server and 564 client to ensure time synchronization. This method can protect DOTS 565 server against the replay attack effectively. 567 The following sections present the detailed description of all the 568 DOTS messages for each stage, and the relevant DOTS protocol 569 operations. 571 5.1. Provisioning Stage 573 In the provisioning stage, DOTS client can be located either in the 574 customer side, in the operator controller or in the inter- 575 organization orchestrator (for the centralized architecture). In any 576 cases, the DOTS client should register itself to its peering DOTS 577 server which provides the intra/inter organization DDoS mitigation 578 service to it, in order to set up the DOTS protocol session. More 579 importantly, the registration process also facilitates the auto- 580 discovery, capacity building and configuration between the DOTS 581 client and server. 583 5.1.1. Messages 585 In the provisioning stage, the messages of registration (DOTS client 586 to server), registration response (DOTS server to client), 587 registration cancelling (DOTS client to server) and registration 588 cancelling response (DOTS server to client) are required. Since all 589 the messages in this stage are not expected to be used under the DDoS 590 attack conditions, transmitting all the messages through DOTS data 591 channel over the TLS is able to meet the requirements of reliability, 592 privacy and integrity. 594 The HTTP POST method with the message body in JSON format is used for 595 the registration and registration response messages as below: 597 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/registration 598 registration body: 599 { 600 "customer_name": string; 601 "ip_version": string; 602 "protected_zone": [ 603 "index": number; 604 "need_alias": string; 605 "ipv4_CIDR": string; 606 "ipv6_address": string; 607 "BGP_route": string; 608 "SIP_URI": string; 609 "E164_number": string; 610 "DNS_name": string; 611 ]; 612 "protected_port": string; 613 "protected_protocol": string; 614 "countermeasures": string; 615 "tunnel_information": string; 616 "next_hop": string; 617 "security_profile": { 618 "TLS": string; 619 "DTLS": string; 620 "CoAP": string; 621 } 622 "white_list": [ 623 "name": string; 624 "source_ip": string; 625 "destination_ip": string; 626 "source_port": string; 627 "destination_port": string; 628 "protocol": string; 629 "length": string; 630 "TTL": string; 631 "DSCP": number; 632 "ip_flags": number; 633 "tcp_flags": number; 634 ]; 635 "black_list": [ 636 "name": string; 637 "source_ip": string; 638 "destination_ip": string; 639 "source_port": string; 640 "destination_port": string; 641 "protocol": string; 642 "length": string; 643 "TTL": string; 644 "DSCP": number; 645 "ip_flags": number; 646 "tcp_flags": number; 647 ]; 648 } 649 registration response body: 650 { 651 "customer_name": string; 652 "customer_id": string; 653 "alias_of_mitigation_address": [ 654 "index": number; 655 "alias": string; 656 ]; 657 "security_profile": string; 658 "access_token": string; 659 "thresholds_bps": number; 660 "thresholds_pps": number; 661 "duration": number; 662 "capable_attack_type": string; 663 "registration_time": string; 664 "mitigation_status": string; 665 } 667 Registration body: 668 customer_name: The name of the customer (DOTS client); 669 ip_version: Current IP version. It can be "v4" or "v6"; 670 protected_zone: Limit the address range of protection. Especially 671 it will be limited to the prefixes possessed by the customer; 672 index: index of the protected zone; 673 need_alias: the flag representing if this protected zone needs 674 an alias. "true" represents that the alias is needed; 675 ipv4_CIDR: ipv4 CIDR address or prefix scope of 676 the protected zone; 677 ipv6_address: ipv6 address or prefix scope of the protected 678 zone; 679 BGP_route: BGP route of the protected zone; 680 SIP_URI: SIP URI of the protected zone; 681 E164_number: E.164 number of the protected zone; 682 DNS_name: DNS name of the protected zone; 683 protected_port: Limit the port range of protection, "0" represents 684 all the ports are to be protected; 685 protected_protocol: Valid protected protocol values include tcp and 686 udp, "all" represents all the protocols are to be protected; 687 countermeasures: Some of the protection need mitigation and others 688 need Blackholing, "all" represents the DOTS client can accept all 689 kinds of countermeasures; 690 tunnel_information: The tunnel between the mitigation provider's 691 network and the customer's network. Tunnel technologies such as 692 GRE[RFC2784] can be used to return normal traffic. "null" represents 693 there is no tunnel information provided and the DOTS server can 694 decide the return tunnel for the normal traffic by itself; 695 next_hop: The returning path to the customer's network. "null" 696 represents there is no next hop information provided and the DOTS 697 server can decide it by itself; 698 security_profile: The security profile in transport layer for the 699 DOTS signaling channel that DOTS client supports; 700 TLS: "true" represents that the DOTS client supports TLS over 701 TCP, "false" represents the opposite side; 702 DTLS: "true" represents that the DOTS client supports DTLS 703 over UDP, "false" represents the opposite side; 704 CoAP: "true" represents that the DOTS client supports CoAP, 705 "false" represents the opposite side; 706 white_list: The white-list information provided to the DOTS server; 707 name: Name of the white-list; 708 source_ip: The source ip address attribute used in the white-list; 709 destination_ip: The destination ip address attribute used in the 710 white-list; 711 source_port: The source port attribute used in the white-list; 712 destination_port": The destination port attribute used in the 713 white-list; 714 protocol: The protocol attribute in ip packet header used in the 715 white-list; 716 length: The length attribute in ip packet header used in the 717 white-list; 718 TTL: The TTL attribute in ip packet header used in the white-list; 719 DSCP: The DSCP attribute in ip packet header used in the 720 white-list; 721 ip_flags: The ip flags attribute used in the white-list; 722 tcp_flags: The tcp flags attribute used in the white-list; 724 black_list: The black-list information provided to the DOTS 725 server; 726 name: Name of the black-list; 727 source_ip: The source ip address attribute used in the black-list; 728 destination_ip: The destination ip address attribute used in the 729 black-list; 730 source_port: The source port attribute used in the black-list; 731 destination_port: The destination port attribute used in the 732 black-list; 733 protocol: The protocol attribute in ip packet header used in the 734 black-list; 735 length: The length attribute in ip packet header used in the 736 black-list; 737 TTL: The TTL attribute in ip packet header used in the black-list; 738 DSCP: The DSCP attribute in ip packet header used in the 739 black-list; 740 ip_flags: The ip flags attribute used in the black-list; 741 tcp_flags: The tcp flags attribute used in the black-list; 743 registration response body: 744 customer_name: The name of the customer (DOTS client); 745 customer_id: The unique id of the customer (DOTS client); 746 alias_of_mitigation_address: 747 index: index of the protected zone; 748 alias: The alias that the DOTS server assigns to this 749 protected zone; 750 security_profile: The negotiated security profile for the DOTS 751 session; 752 access_token: Authentication token (e.g. pre-shared nonce). 753 "null" represents there is no access token; 754 thresholds_bps: If an attack volume is over this threshold, 755 the controller will reject the protection in order to comply with 756 the negotiated contract; 757 thresholds_pps: If an attack volume is over this threshold, the 758 controller will reject the protection in order to comply with the 759 negotiated contract; 760 duration: If an attack longed over this threshold, the controller 761 will reject the protection in order to comply with the negotiated 762 contract; 763 capable_attack_type: Limit the protectable attack type; 764 registration_time: The time of registration; 765 mitigation_status: The status of current mitigation service of 766 the ISP. 768 Similarly, another HTTP POST method with the message body in JSON 769 format is used for the registration cancelling and registration 770 cancelling response messages as below: 772 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 773 registration_cancelling 774 registration cancelling body: 775 { 776 "customer_id": string; 777 "reasons": string; 778 } 779 registration cancelling response body: 780 { 781 "customer_id": string; 782 "result": string; 783 } 785 Registration cancelling body: 786 customer_id: The unique id of the customer (DOTS client); 787 reasons: The reasons why the DOTS client cancel the registration; 789 registration cancelling response body: 790 customer_id: The unique id of the customer (DOTS client); 791 result: The final result if the DOTS controller accepts the 792 registration cancelling request. 794 5.1.2. Operations 796 The main operations in the provisioning stage include: 798 o The customers (DOTS client) registers to operator controller with 799 configuration and capability building including protection 800 methods, process capacity, protected zone, security profile, 801 white/black-list, etc; 803 o The DOTS client in operator controller registers to the DOTS 804 server in inter-organization orchestrator (centralized 805 architecture) or other operator controllers (distributed 806 architecture) according to inter-organization DDoS protection 807 requirements; 809 o The DOTS client can send the registration cancelling message to 810 the DOTS server for cancelling its DDoS protection service. 812 The DOTS server indicates the result of processing the POST request 813 using HTTP response codes: 815 o Response code 200 (OK) will be returned in the response if the 816 DOTS server has accepted the mitigation request and will try to 817 mitigate the attack. The HTTP response will include the JSON body 818 of response messages specified above; 820 o If the request is missing one or more mandatory attributes then 821 400 (Bad Request) will be returned in the response or if the 822 request contains invalid or unknown parameters then 500 (Invalid 823 query) will be returned in the response. The HTTP response will 824 include the JSON body received in the request, with an extra 825 attribute to represent the specific error reason: 827 "error_reason": number; 828 0: Bad Request; 829 1: Invalid Query; 830 2: Server Error; 831 3: Protected Zone Confliction; 832 4: Countermeasure Not Support; 833 5: Security Profile Not Support; 834 6: Confliction Exists for White-list or Black-list; 835 255: Others; 837 5.2. Signaling Stage 839 During the signaling stage, the DOTS signaling channel created with 840 the negotiated security profile in the provisioning stage is used for 841 the DDoS attack mitigation coordination. Once the DOTS client 842 detects the attack to the customer service, a mitigation initiation 843 request message is created and sent to the provisioned DOTS server to 844 call for the DDoS protection service. The DOTS server decides to 845 protect the customer service based on the information from the 846 request message and its configured policy. One operator's DOTS 847 server may ask the co-located DOTS client to resume sending the 848 mitigation initiation request message to other operators' DOTS server 849 to request the inter-organization coordinated mitigation service 850 while it isn't able to deal with the attack by itself. Meanwhile, 851 some other messages are required to be communicated between DOTS 852 client and server for information updates about status, efficacy and 853 scope. When the DOTS server is informed from the mitigator that the 854 attack is over, it should notify the DOTS client to terminate the 855 mitigation service. 857 5.2.1. Messages 859 In the signaling stage, the DOTS signaling channel is expected to 860 transmit DOTS messages under extremely hostile network conditions 861 such as link saturation. To meet the requirements of resilience and 862 robustness, unidirectional messages MUST be supported within the 863 bidirectional signal channel to allow for unsolicited message 864 delivery, enabling asynchronous notifications between DOTS client and 865 server. So, the listed DOTS messages are required: mitigation 866 initiation request (DOTS client to server), mitigation efficacy 867 updates (DOTS client to server), mitigation status updates (DOTS 868 server to client), mitigation termination (DOTS client to server), 869 mitigation termination status acknowledgement (DOTS client to server) 870 and heartbeat (bidirectional message). 872 Mitigation Request: 874 A HTTP POST method with the message body in JSON is used for the 875 mitigation request message: 877 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 878 mitigation_request 879 mitigation request body: 880 { 881 "version": string; 882 "type": string; 883 "alert_id": string; 884 "sender_id": string; 885 "sender_asn": string; 886 "mitigation_action": number; 887 "lifetime": number; 888 "max_bandwidth": number; 889 "packet_header": { 890 "dst_ip": string; 891 "dst_ports": string; 892 "src_ips": string; 893 "src_ports": string; 894 "protocols": string; 895 "tcp_flags": string; 896 "fragment": string; 897 "pkt_len": string; 898 "icmp_type": string; 899 "icmp_code": string; 900 "DSCP": string; 901 "TTL": string; 902 } 903 "current_throughputs": { 904 "bps": string; 905 "pps": string; 906 } 907 "peak_throughputs": { 908 "bps": string; 909 "pps": string; 910 } 911 "average_throughputs": { 912 "bps": string; 913 "pps": string; 914 } 915 "info": { 916 "attack_types": string; 917 "started": number; 918 "ongoing": number; 919 "severity": number; 920 "direction": number; 921 "health": number; 922 } 923 "vendor": { 924 "name": string; 925 "version": string; 926 "payload": { 927 "offset": number; 928 "content": string; 929 "hash": string; 930 } 931 } 932 } 934 mitigation request body: 935 version: A 3 digit set, similar to linux. (Major.Minor.Revision); 936 type: Only "attack" in scope for v1; 937 alert_id: A SHA-256 hash that is derived from DST_IP and started 938 with some random nonce; 939 sender_id: A SHA-256 hash signature of the sender. This is used 940 to validate who sent it; 941 sender_asn: Asn of the sender. Could be used to link back to 942 sender_id to validate the sender of being a valid sender_id; 943 mitigation_action: The requested mitigation actions by DOTS client. 944 Possible value could be: 1 - mitigation, 2 - blackhole, 945 3 - flowspec, ...; 946 lifetime: The desired lifetime of the mitigation service from the 947 DOTS client. Upon the expiry of this lifetime, and if the request 948 is not refreshed, the mitigation service is stopped. 949 The service can be refreshed by sending the message with the same 950 "alert_id" again. A lifetime of zero indicates indefinite lifetime 951 for the mitigation service. This is an optional attribute in the 952 request message; 953 max_bandwidth: The max bandwidth DOTS client can undertake. 954 The unit is "G bytes"; 955 packet_header: IP packet header contents used for report. 956 CSV (Comma Separated Values) format is used here when multiple 957 values are possible. Note that no spaces between comma's for CSV 958 format, and the multiple values for every attribute should be in 959 the same order as they are assigned. 960 dst_ip: A single /32 ip under attack; 961 dst_ports: The destination port(s) used for the attack; 962 src_ips: The list of source ips of the attack; 963 src_ports: The source port(s) used for the attack; 964 protocols: The protocol numbers used for the attack. The list 965 of IP protocol numbers are defined and maintained by IANA; 966 tcp_flags: The tcp flags used for the attack. Possible value 967 could be: SYN, FIN, ACK, PSH, RST, URG, NULL; 968 fragment: The fragment flags in ip header for the attack. 969 Possible value could be: DF - Don't fragment, IsF - Is a 970 fragment, FF - First fragment, LF - Last fragment; 971 pkt_len: The packet length used for the attack; 972 icmp_type: The icmp type used for the attack; 973 icmp_code: The icmp code used for the attack; 974 DSCP: The DSCP value used for the attack.; 975 TTL: The TTL value used for the attack; 976 current_throughputs: Current throughput in bps/pps for the 977 above attack flows 978 bps: bytes per second; 979 pps: packets per second; 981 peak_throughputs: The peak throughput in bps/pps for the above 982 attack flows until the time the DOTS request message is sent 983 bps: bytes per second; 984 pps: packets per second; 985 average_throughputs: The calculated average throughput in 986 bps/pps for the above attack flows until the time the DOTS 987 request message is sent 988 bps: bytes per second; 989 pps: packets per second; 990 info: Other general information which is possibly useful 991 attack_types: List of attacks being used together for this 992 attack, on this single DST_IP; 993 started: Unix EPOCH when the attack is started; 994 ongoing: The value representing whether the attack is still 995 ongoning. 1 - yes, 0 - no; 996 severity: The severity level of the attack. 1, 2, 3 - low, 997 medium, high; 998 direction: The direction of the attack. in or out; 999 health: The health condition of the DOTS client. 0-100; 1000 vendor: 1001 name: Company name; 1002 version: version of the DOTS client on the vendors device; 1003 payload: The attack packet payload provided to DOTS server 1004 for further analysis 1005 offset: The payload offset; 1006 content: The payload content that is base64 encoded; 1007 hash: A SHA-256 hash used as a checksum, of the original 1008 payload before being base64 encoded. This is to proof the 1009 payload is complete. Not to prove if 1010 it has been tampered with; 1012 Mitigation Status Exchange: 1014 A HTTP POST method with the message body in JSON is used for the 1015 mitigation efficacy updates message: 1017 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 1018 mitigation_efficacy_updates 1019 mitigation efficacy updates body: 1020 { 1021 "version": string; 1022 "alert_id": string; 1023 "sender_id": string; 1024 "sender_asn": string; 1025 "attack_status": string; 1026 "health": number; 1027 } 1029 mitigation efficacy updates body: 1030 version: A 3 digit set, similar to linux. 1031 (Major.Minor.Revision); 1032 alert_id: A SHA-256 hash that is derived from DST_IP and 1033 started with some random nonce; 1034 sender_id: A SHA-256 hash signature of the sender. 1035 This is used to validate who sent it; 1036 sender_asn: Asn of the sender. Could be used to link back to 1037 sender_id to validate the sender of being a valid sender_id; 1038 attack_status: The current attack status of the DOTS client. 1039 Possible value could be: 0 - in-process, 1 - terminated; 1040 health: The health condition of the DOTS client. 0-100; 1042 A HTTP POST method with the message body in JSON is used for the 1043 mitigation status updates message: 1045 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 1046 mitigation_status_updates 1047 mitigation status updates body: 1048 { 1049 "version": string; 1050 "alert_id": string; 1051 "sender_id": string; 1052 "sender_asn": string; 1053 "status": number; 1054 "error_reason": number; 1055 "lifetime": number; 1056 "source_ports": string; 1057 "destination_ports": string; 1058 "source_ips": string; 1059 "destination_ip": string; 1060 "TCP_flags": string; 1061 "start_time": number; 1062 "end_time": number; 1063 "forwarded_total_packets": number; 1064 "forwarded_total_bits": number; 1065 "forwarded_peak_pps": number; 1066 "forwarded_peak_bps": number; 1067 "forwarded_average_pps": number; 1068 "forwarded_average_bps": number; 1069 "malicious_total_packets": number; 1070 "malicious_total_bits": number; 1071 "malicious_peak_pps": number; 1072 "malicious_peak_bps": number; 1073 "malicious_average_pps": number; 1074 "malicious_average_bps": number; 1075 "record_time": string; 1076 } 1078 mitigation status updates body: 1079 version: A 3 digit set, similar to linux. 1080 (Major.Minor.Revision); 1081 alert_id: A SHA-256 hash that is derived from DST_IP and started 1082 with some random nonce; 1083 sender_id: A SHA-256 hash signature of the sender. This is used to 1084 validate who sent it. The sender is the DOTS server for this 1085 message; 1086 sender_asn: Asn of the sender. Could be used to link back to 1087 sender_id to validate the sender of being a valid sender_id; 1088 status: Current mitigation status, such as: pending, ongoing, done, 1089 error; 1090 error_reason: If status attribute is error, then this attribute 1091 expresses its reason, the possible value could be: 0 - Bad Request, 1092 1 - Server Error, 3 - Mitigation Scope Confliction, 4 - Mitigation 1093 Action Not Support, 255 - Others; 1094 lifetime: The lifetime of mitigation service that DOTS server has 1095 assigned to DOTS client. DOTS client MUST follow this value; 1096 source_ports: For TCP or UDP or SCTP or DCCP: the source range of 1097 ports (e.g., 1024-65535) of the discarded traffic; 1098 destination_ports: For TCP or UDP or SCTP or DCCP: the destination 1099 range of ports (e.g., 1-443) of the discarded traffic; 1100 source_ips: The source IP addresses or prefixes of the discarded 1101 traffic; 1102 destination_ip: The destination IP addresses or prefixes of the 1103 discarded traffic; 1104 TCP_flags: TCP flag of the discarded traffic; 1105 start_time: The start time for the duration of this mitigation 1106 status message; 1107 end_time: The end time for the duration of this mitigation status 1108 message; 1109 forwarded_total_packets: The total number of packets forwarded; 1110 forwarded_total_bits: The total bits for all the packets forwarded; 1111 forwarded_peak_pps: The peak pps of the traffic forwarded; 1112 forwarded_peak_bps: The peak bps of the traffic forwarded; 1113 forwarded_average_pps: The average pps of the traffic forwarded; 1114 forwarded_average_bps: The average bps of the traffic forwarded; 1115 malicious_total_packets: The total number of malicious packets; 1116 malicious_total_bits: The total bits of malicious packets; 1117 malicious_peak_pps: The peak pps of the malicious traffic; 1118 malicious_peak_bps: The peak bps of the malicious traffic; 1119 malicious_average_pps: The average pps of the malicious traffic; 1120 malicious_average_bps: The average bps of the malicious traffic; 1121 record_time: The time the mitigation status updates message is 1122 created; 1124 Mitigation Termination: 1126 A HTTP POST method with the message body in JSON is used for the 1127 mitigation termination request message: 1129 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 1130 mitigation_termination_request 1131 mitigation termination request body: 1132 { 1133 "version": string; 1134 "alert_id": string; 1135 "sender_id": string; 1136 "sender_asn": string; 1137 } 1139 mitigation termination request body: 1140 version: A 3 digit set, similar to linux. (Major.Minor.Revision); 1141 alert_id: A SHA-256 hash that is derived from DST_IP and started 1142 with some random nonce; 1143 sender_id: A SHA-256 hash signature of the sender. This is used 1144 to validate who sent it; 1145 sender_asn: Asn of the sender. Could be used to link back to 1146 sender_id to validate the sender of being a valid sender_id; 1148 A HTTP POST method with the message body in JSON is used for the 1149 mitigation termination status acknowledgement message: 1151 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/ 1152 mitigation_termination_status_acknowledgement 1153 mitigation termination status acknowledgement body: 1154 { 1155 "version": string; 1156 "alert_id": string; 1157 "sender_id": string; 1158 "sender_asn": string; 1159 } 1161 mitigation termination status acknowledgement body: 1162 version: A 3 digit set, similar to linux. 1163 (Major.Minor.Revision); 1164 alert_id: A SHA-256 hash that is derived from DST_IP and started 1165 with some random nonce; 1166 sender_id: A SHA-256 hash signature of the sender. This is used 1167 to validate who sent it; 1168 sender_asn: Asn of the sender. Could be used to link back to 1169 sender_id to validate the sender of being a valid sender_id; 1171 Heartbeat: 1173 A HTTP POST method with the message body in JSON is used for the 1174 heartbeat message: 1176 METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/heartbeat 1177 heartbeat body 1178 { 1179 "version": string; 1180 "sender_id": string; 1181 "sender_asn": string; 1182 } 1184 heartbeat body: 1185 version: A 3 digit set, similar to linux. 1186 (Major.Minor.Revision); 1187 sender_id: A SHA-256 hash signature of the sender. This is used 1188 to validate who sent it; 1189 sender_asn: Asn of the sender. Could be used to link back to 1190 sender_id to validate the sender of being a valid sender_id; 1192 5.2.2. Operations 1194 The main operations in the signaling stage include: 1196 o The customer (DOTS client) detects malicious attack, requests 1197 mitigation service to its operator controller (DOTS server); 1199 o DOTS server authenticates and provides its intra- organization 1200 mitigation service to the DOTS client; 1202 o When the DOTS server are mitigating the attack and finding the 1203 attack volume exceeds it capacity, or the attack type is unknown 1204 type, or its upstream link is congested, it should request to 1205 other DOTS server for inter-organization cooperation; 1207 o Working DOTS server report their statistics results by mitigation 1208 status updates message to the DOTS client; 1210 o The DOTS client can updates its mitigation scope to the DOTS 1211 server by resending the mitigation request message. It also can 1212 update its mitigation efficacy result to the DOTS server; 1214 o When the DOTS server is informed from the mitigator that the 1215 attack is over, it should notify the DOTS client by the mitigation 1216 status updates message to terminate the mitigation service; 1218 o When DOTS client is notified by the DOTS server to terminate its 1219 mitigation service, it should send a DOTS termination request 1220 message to the DOTS server. The DOTS server stop its mitigation 1221 service and notifies it to DOTS client by sending DOTS status 1222 updates message. At last, DOTS client sends a DOTS mitigation 1223 termination acknowledgement message to finish the whole DOTS 1224 session; 1226 o The heartbeat message is exchange between the DOTS client and DOTS 1227 server to check their respective status. If any side of the 1228 channel fails to receive the heartbeat message, then it will 1229 trigger an alert or further investigation into why they never 1230 reached their destination. 1232 6. Other Considerations 1234 6.1. Billing Data 1236 This is not technical nor a part of dots protocol but it has relation 1237 to deployment models. If other organization utilized resources of 1238 DDoS protection service, it is natural to charge it according to the 1239 amount of use. However, how to count the amount of use differs among 1240 DDoS protection service providers. For example, some DDoS protection 1241 service provider charges users by volume of the attack traffic or 1242 dropped packets. On the other hand, some of them use volume of 1243 normal traffic. Number of execution can be also used. We can not 1244 decide what information should be taken into account for billing 1245 purpose in advance, however those information is needed to be 1246 exchanged while coordinating DDoS protection. These information 1247 could be also used to determine which service would be used when 1248 asking for help. Though it is out of the scope of dots, coordinating 1249 and optimizing the cooperation in the aspect of business is difficult 1250 to solve. 1252 7. Security Considerations 1254 TBD 1256 8. IANA Considerations 1258 No need to describe any request regarding number assignment. 1260 9. Normative References 1262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1263 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1264 RFC2119, March 1997, 1265 . 1267 [RFC2784] D. Farinacci., T. Li., S. Hanks., D. Meyer., and P. 1268 Traina., "Generic Routing Encapsulation (GRE), March 1269 2000". 1271 [I-D.draft-ietf-dots-use-cases] 1272 R. Dobbins, Ed., S. Fouant., D. Migault., R. Moskowitz., 1273 N. Teague., L. Xia, K. Nishizuka., "Use cases for DDoS 1274 Open Threat Signaling, October 2015". 1276 [I-D.draft-ietf-dots-requirements] 1277 A. Mortensen., R. Moskowitz., and T. Reddy., "DDoS Open 1278 Threat Signaling Requirements, draft-ietf-dots- 1279 requirements-00, October 2015". 1281 [I-D.draft-mortensen-dots-architecture] 1282 A. Mortensen., F. Andreasen., T. Reddy., C. Gray., R. 1283 Compton., and N. Teague., "Distributed-Denial-of-Service 1284 (DDoS) Open Threat Signaling Architecture, March 2016". 1286 [I-D.draft-reddy-dots-transport] 1287 T. Reddy., D. Wing., P. Patil., M. Geller., M. 1288 Boucadair., and R. Moskowitz., "Co-operative DDoS 1289 Mitigation, October 2015". 1291 Authors' Addresses 1293 Kaname Nishizuka 1294 NTT Communications 1295 GranPark 16F 1296 3-4-1 Shibaura, Minato-ku, Tokyo 1297 108-8118,Japan 1299 EMail: kaname@nttv6.jp 1300 Liang Xia 1301 Huawei Technologies Co., Ltd. 1302 101 Software Avenue, Yuhuatai District 1303 Nanjing, Jiangsu 1304 210012, China 1306 EMail: frank.xialiang@huawei.com 1308 Jinwei Xia 1309 Huawei Technologies Co., Ltd. 1310 101 Software Avenue, Yuhuatai District 1311 Nanjing, Jiangsu 1312 210012, China 1314 EMail: xiajinwei@huawei.com 1316 Dacheng Zhang 1317 Beijing 1318 China 1320 EMail: dacheng.zdc@alibaba-inc.com 1322 Luyuan Fang 1323 Microsoft 1324 15590 NE 31st St 1325 Redmond, WA 98052 1327 EMail: lufang@microsoft.com 1329 Christopher Gray 1330 Comcast, Inc. 1331 United States 1333 EMail: Christopher_Gray3@cable.comcast.com 1335 Rich Compton 1336 Charter Communications, Inc. 1338 EMail: Rich.Compton@charter.com