idnits 2.17.1 draft-chen-dots-attack-informations-03.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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (August 22, 2019) is 1708 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) == Unused Reference: 'I-D.ietf-dots-architecture' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dots-signal-channel' is defined on line 881, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-14 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-37 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-19 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS M. Chen 3 Internet-Draft Li. Su 4 Intended status: Standards Track Jin. Peng 5 Expires: February 23, 2020 CMCC 6 August 22, 2019 8 DOTS client carry ddos attack informations in signal channel 9 draft-chen-dots-attack-informations-03 11 Abstract 13 This document describes DDoS attack information which can be obtained 14 by DOTS client when the enterprise suspects it is under DDoS attack, 15 these informations will be send from DOTS client to DOTS server in 16 mitigation request using Signal channel or Data channel. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 23, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 56 3. Alarm attributes for mitigation request . . . . . . . . . . . 5 57 3.1. Bandwidth consuming attack . . . . . . . . . . . . . . . 5 58 3.1.1. Attack_Target_IP . . . . . . . . . . . . . . . . . . 5 59 3.1.2. Alarm_Begin_time . . . . . . . . . . . . . . . . . . 5 60 3.1.3. Direction . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.4. Target_Attack_Type . . . . . . . . . . . . . . . . . 5 62 3.1.5. Target_Attack_Type_Threshold . . . . . . . . . . . . 5 63 3.1.6. Attack_Target_IP_Peak . . . . . . . . . . . . . . . . 5 64 3.1.7. Attack_Source_IP_Num . . . . . . . . . . . . . . . . 5 65 3.1.8. Attack_Bandwidth . . . . . . . . . . . . . . . . . . 6 66 3.2. Host resource consuming attack . . . . . . . . . . . . . 6 67 3.2.1. Attack_Target_IP . . . . . . . . . . . . . . . . . . 6 68 3.2.2. Attack_Target_Packet_Rate . . . . . . . . . . . . . . 6 69 3.2.3. Alarm_Begin_Time . . . . . . . . . . . . . . . . . . 6 70 3.2.4. Direction . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2.5. Target_Attack_Type . . . . . . . . . . . . . . . . . 6 72 4. mitigation attributes for mitigation response . . . . . . . . 6 73 4.1. Bandwidth consuming attack . . . . . . . . . . . . . . . 6 74 4.1.1. Attack_Target_IP . . . . . . . . . . . . . . . . . . 6 75 4.1.2. Alarm_End_time . . . . . . . . . . . . . . . . . . . 7 76 4.1.3. Target_Attack_Type . . . . . . . . . . . . . . . . . 7 77 4.1.4. Total_Traffic . . . . . . . . . . . . . . . . . . . . 7 78 4.1.5. Residual_Traffic . . . . . . . . . . . . . . . . . . 7 79 4.1.6. Attack_Traffic . . . . . . . . . . . . . . . . . . . 7 80 4.1.7. Attack_Target_IP_Peak . . . . . . . . . . . . . . . . 7 81 4.1.8. Attack_Source_IP_Num . . . . . . . . . . . . . . . . 7 82 4.2. Host resource consuming attack . . . . . . . . . . . . . 7 83 4.2.1. Attack_Target_IP . . . . . . . . . . . . . . . . . . 7 84 4.2.2. Alarm_End_time . . . . . . . . . . . . . . . . . . . 7 85 4.2.3. Target_Attack_Type . . . . . . . . . . . . . . . . . 8 86 4.2.4. Attack_Source_IP . . . . . . . . . . . . . . . . . . 8 87 4.2.5. Attack_Target_Packet_Rate . . . . . . . . . . . . . . 8 88 5. Mitigation Use Case 1 . . . . . . . . . . . . . . . . . . . . 8 89 5.1. Mitigations for attack flow . . . . . . . . . . . . . . . 8 90 5.2. Optimal device selection . . . . . . . . . . . . . . . . 9 91 5.3. Optimum path for disposal . . . . . . . . . . . . . . . . 9 92 5.4. Mitigation request parameters . . . . . . . . . . . . . . 10 93 6. Mitigation Use Case 2 . . . . . . . . . . . . . . . . . . . . 10 94 6.1. classified disposal . . . . . . . . . . . . . . . . . . . 10 95 6.2. Standard of Attack Type Definition . . . . . . . . . . . 11 96 7. Mitigation Use Case 3 . . . . . . . . . . . . . . . . . . . . 12 97 7.1. Mitigation alarm baseline . . . . . . . . . . . . . . . . 12 99 8. Mitigation request optional parameters . . . . . . . . . . . 13 100 8.1. Bandwidth consuming attack . . . . . . . . . . . . . . . 13 101 8.2. Host resource consuming attack . . . . . . . . . . . . . 14 102 9. Mitigation response parameters . . . . . . . . . . . . . . . 16 103 9.1. Bandwidth consuming attack . . . . . . . . . . . . . . . 16 104 9.2. Host resource consuming attack . . . . . . . . . . . . . 17 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 107 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 109 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 110 13.2. Informative References . . . . . . . . . . . . . . . . . 19 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Introduction 115 Distributed Denial of Service (DDoS) is a type of resource-consuming 116 attack, which exploits a large number of attack resources and uses 117 standard protocols to attack target objects. DDoS attacks consume a 118 large amount of target network resources or server resources 119 (including computing power, storage capacity, etc.), this means there 120 are two types of the DDoS attack, one is bandwidth consuming attack, 121 the other is host resource consuming attack. At present, DDoS attack 122 is one of the most powerful and indefensible attacks on the Internet, 123 and due to the extensive use of mobile devices and IoT devices in 124 recent years, it is easier for DDoS attackers to attack with real 125 attack sources (broilers). 127 The IETF is specifying the DDoS Open Threat Signaling (DOTS) 128 [I-D.ietf-dots-architecture]architecture, where a DOTS client can 129 inform a DOTS server that the attack target is under a potential 130 attack and that appropriate mitigation actions are required. In the 131 architecture draft, it says in the draft the enterprise has a DOTS 132 client, which obtains information about the DDoS attack, and signals 133 the DOTS server for help in mitigating the attack. but it doesn't 134 says what the information of DDoS attack is. the scope of this draft 135 is about the information of DDoS attack which DOTS client can obtain. 137 In the architecture draft, it says in the draft the client signal may 138 also include telemetry information about the attack, if the DOTS 139 client has such information available. But in the signal channel 140 draft it doesn't define optional parameter about the telemetry 141 information which will be regarded as DDoS portrait information. 143 "DDoS portrait information" is defined as the collection of 144 attributes characterizing the attacks(or suspected attack) that have 145 been detected and mitigated. The DDoS portrait information is an 146 optional set of attributes that can be signaled. The portrait can be 147 optionally sent from the DOTS Client to Server and vice versa. 149 This document will divide into two directions, before mitigation 150 request and after mitigation is complete. Before mitigation request, 151 DOTS client can obtain informations of attack; After mitigation, DOTS 152 server can obtain from mitigator. 154 2. Terminology 156 2.1. Key Words 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 [RFC2119] 163 2.2. Definition of Terms 165 The readers should be familiar with the terms defined in 166 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 168 The terminology related to YANG data modules is defined in [RFC7950] 170 In addition, this document uses the terms defined below: 172 Bandwidth consuming attack DDoS attack that causes network 173 congestion. 175 Host resources consuming attack DDoS attack that consuming the 176 ability of the protocol stack to process resources, or make host 177 engaged in high-consumption business, thus unable to respond to 178 normal business 180 Attack-bandwidth: the amount of traffic under attack, it is usually 181 expressed numerically. 183 Flow clean: one selection of Attack traffic deposition, the 184 operation contains recognize, discard and reinage. 186 Attack Type: used to distinguish between different methods of ddos 187 attack. 189 Attack type definition: General definition method, Covers most 190 current attack types. 192 Attack-source-ip-number: Number of all attack sources(ip). 194 Target-attack-type-threshold: The DDoS detection device sets a 195 threshold for each type of attack, this threshold is usually 196 exceeded to generate DDoS alarms. 198 3. Alarm attributes for mitigation request 200 3.1. Bandwidth consuming attack 202 3.1.1. Attack_Target_IP 204 The IP address of attack target, which can be either IPv4 or IPv6, 205 supports address block notation. For example, if a company's IP 206 address is attacked, it can aggregate IP addresses. 208 3.1.2. Alarm_Begin_time 210 If the alarm is confirmed to be real and effective after mitigation, 211 the alarm start time is the same as the attack start time. 213 3.1.3. Direction 215 The direction of the attack, divided into inward and outward, 0 means 216 inward, 1 means outward. Inward means attack target suffers DDoS 217 attack, outward means attack target is launching DDoS attack. 219 3.1.4. Target_Attack_Type 221 A list of attack types involved in an attack. 223 3.1.5. Target_Attack_Type_Threshold 225 The alarm threshold set for each attack type, measurement unit can be 226 pps or bps. 228 3.1.6. Attack_Target_IP_Peak 230 Peak of attack traffic, measurement unit can be pps or bps. We use 231 peak of attack traffic rather than averages because peak of attack is 232 more indicative of attacks. 234 3.1.7. Attack_Source_IP_Num 236 The number of attack source ip, measure the number of attacker's is 237 much more helpful for the scale of attack for Bandwidth consuming 238 attack. 240 3.1.8. Attack_Bandwidth 242 The proportion of the current traffic bandwidth to the total 243 bandwidth of the pipeline. The attack bandwidth is described in 244 terms of percentage. The total bandwidth is preset in the attack 245 target. 247 3.2. Host resource consuming attack 249 3.2.1. Attack_Target_IP 251 The IP address of attack target, which can be either IPv4 or IPv6, 252 supports address block notation. For example, if a company's IP 253 address is attacked, it can aggregate IP addresses. 255 3.2.2. Attack_Target_Packet_Rate 257 All packet rates for the same protocol and the same attack target in 258 one period. for example, A is suffering CC attack, then 259 attack_target_packet_rate is used to calculate the number of all HTTP 260 packets in 5 minites. 262 3.2.3. Alarm_Begin_Time 264 If the alarm is confirmed to be real and effective after mitigation, 265 the alarm start time is the same as the attack start time. 267 3.2.4. Direction 269 The direction of the attack, divided into inward and outward, 0 means 270 inward, 1 means outward. Inward means attack target suffers DDoS 271 attack, outward means attack target is launching DDoS attack. 273 3.2.5. Target_Attack_Type 275 A list of attack types involved in an attack. 277 4. mitigation attributes for mitigation response 279 4.1. Bandwidth consuming attack 281 4.1.1. Attack_Target_IP 283 The IP address of attack target, which can be either IPv4 or IPv6, 284 supports address block notation. For example, if a company's IP 285 address is attacked, it can aggregate IP addresses. 287 4.1.2. Alarm_End_time 289 The end time of mitigation, denoted by -1 if the remission is not 290 finished temporarily 292 4.1.3. Target_Attack_Type 294 A list of attack types involved in an attack. 296 4.1.4. Total_Traffic 298 Total traffic received by the attack target, measurement unit can be 299 pps or bps. 301 4.1.5. Residual_Traffic 303 Residual traffic can also be considered normal business traffic, In 304 the actual cleaning operation, that is the normal service flow 305 injected into the link. 307 4.1.6. Attack_Traffic 309 The total attack traffic, It can be calculated by the Total_Traffic 310 minus the Residual_Traffic 312 4.1.7. Attack_Target_IP_Peak 314 Peak of attack traffic, measurement unit can be pps or bps. After 315 mitigation, the Attack_Target_IP_peak will be more precise for 316 measurement. 318 4.1.8. Attack_Source_IP_Num 320 The number of attackers in the case of this whole attack. 322 4.2. Host resource consuming attack 324 4.2.1. Attack_Target_IP 326 The IP address of attack target, which can be either IPv4 or IPv6, 327 supports address block notation. For example, if a company's IP 328 address is attacked, it can aggregate IP addresses. 330 4.2.2. Alarm_End_time 332 The end time of mitigation, denoted by -1 if the remission is not 333 finished temporarily 335 4.2.3. Target_Attack_Type 337 A list of attack types involved in an attack. 339 4.2.4. Attack_Source_IP 341 All the attack IP addresses involved in an attack. 343 4.2.5. Attack_Target_Packet_Rate 345 All packet rates for the same protocol and the same attack target in 346 one period. for example, A is suffering CC attack, then 347 attack_target_packet_rate is used to calculate the number of all HTTP 348 packets in 5 minites. 350 5. Mitigation Use Case 1 352 5.1. Mitigations for attack flow 354 when attack target is under attack, it has to make corresponding 355 disposal, there are two options for disposal, one is blackhole 356 directly which may be take effect in routers, in this way all the 357 attack flow will be discarded by router upper path of attack target, 358 this means that the attack target will not receive any traffic during 359 the attack depending on the routing strategy, all the traffic 360 forwards attack target will be discarded, this has a huge impact on 361 the work environment, especially the host that provide external 362 service. The other way of the disposition is to drainage all the 363 traffic flow to clean center from router, then the clean center will 364 use pattern matching or any other method to find out the attack 365 traffic flow to discard, finally, clean center reinage the normal 366 business traffic back to attack target by upper router, the whole 367 process above is defined as flow clean(Figure 1). 369 attack flow +--------+ +--------+ 370 ----------->| router |------------------>| clean | 371 1 +--------+ 2 | center | 372 | +--------+ 373 3 | | 374 | +--------+ | 375 +------>| attack |<-------------+ 376 | target | 377 +--------+ 379 Figure 1: diagram of DDoS Mitigation usecase 381 Generally, the bandwidth of the link 1 must be larger than link 2 and 382 link 3, and the clean ability of clean center limited to hardware 383 resources. An example of link situation is as below(Figure 2): 385 +------------+------------+ 386 | figure | bandwidth/ | 387 | tag | capability | 388 +------------+------------+ 389 | link 1 | 100Gb | 390 | link 2 | 50Gb | 391 | link 3 | 10Gb | 392 |clean center| 80Gb | 393 +------------+------------+ 395 Figure 2: an example of link bandwidth 397 The Figure2 is a scenario of the link bandwidth, when a ddos attack 398 is ongoing, if the link 1 bandwidth is completely jammed, the best 399 way to mitigate the attack is to discard all the attack flow; if the 400 amount of the traffic flow is lower than the remainder cleaning 401 ability, the most suitable disposition is to drainage all the attack 402 flow to clean center. Therefore, it is an obvious requirement in the 403 current network environment. 405 5.2. Optimal device selection 407 Mitigator may owns a cleaning device cluster and can manage cleaning 408 devices. The capacity of each cleaning equipment is variable, 409 usually each cleaning equipment utilization rate is different, then 410 the remaining cleaning capacity is not consistent. When the attack 411 flow is less than the ability of a cleaning equipment, according to 412 the attack-bandwidth can choose a suitable cleaning equipment, that 413 is conducive to the utilization of equipment; When the attack flow is 414 larger than the cleaning capacity of one cleaning device, several 415 cleaning devices can be optimally scheduled according to the attack- 416 bandwidth. 418 5.3. Optimum path for disposal 420 When mitigator is an attack flow cleaning service, they typically 421 deployed the mitigator in a distributed way because of the cost of 422 bandwidth usage with their own leased operator's link bandwidth, and 423 choosing the best traction path was the key to profitability. If the 424 parameter of attack-bandwidth is carried, then the generation of the 425 best drainage path is very meaningful. 427 When mitigator is at the upstream service operator level, they might 428 have multiple networks, with the attack alert using one network and 429 the flow drainage using another, and the link load is not the same, 430 then carrying the attack-bandwidth is very beneficial for choosing 431 the drainage path, mainly for link load balancing. 433 5.4. Mitigation request parameters 435 When a DOTS client requires mitigation for some reason, the DOTS 436 client uses the CoAP PUT method to send a mitigation request to its 437 DOTS server(s). If a DOTS client is entitled to solicit the DOTS 438 service, the DOTS server enables mitigation on behalf of the DOTS 439 client by communicating the DOTS client's request to a mitigator 440 (which may be colocated with the DOTS server) and relaying the 441 feedback of the thus-selected mitigator to the requesting DOTS 442 client. 444 DOTS clients use the PUT method to request mitigation from a DOTS 445 server. During active mitigation, DOTS clients may use PUT requests 446 to carry mitigation efficacy updates to the DOTS server. We suggest 447 to add attack bandwidth to satiesfy the requirement. 449 total traffic when ddos attack occur, reflects the urgency of the 450 current attack. Serious attacks are treated with blackhole, Other 451 cases use flow cleaning, attack-bandwidth is conducive to the 452 selection of disposal mode. 454 This is an optional attribute. 456 6. Mitigation Use Case 2 458 6.1. classified disposal 460 DDoS attack is a hybrid attack across multiple protocol layers and 461 multiple method, when we deal with DDoS attacks, we find it more 462 reasonable and effective to deal with them according to the types of 463 attacks, It is easier to handle if the type of attack is already 464 included in the mitigation request. There is no doubt that the 465 information may not be accurate, but we can take it as a reference. 466 Therefore, with attack type the disposal process is more helpful. 467 The ddos attack alarm in the industry is set according to the attack 468 type, from the point of view of cleaning, different types of attacks 469 are handled differently. For example, Memcached reflection flood use 470 UDP 11211 port for DDoS flood, but tcp syn flood use defects of TCP 471 three-way handshake to consuming connection resources. This two 472 attacks are alarmed respectively and cleaned in different ways. We 473 suggest to add attack type to satiesfy the requirement. 475 A list of attack types involved in an attack. 477 There is no uniform definition of attack types, It is often the case 478 that the same type of attack has different names, An attack type is 479 defined in section 4. 481 The parameter of Target_Attack_Type contains three values: 482 Attack_Name, Attack_Alias and Target_Attack_Type_Threshold, 483 Attack_Alias will solve the abbreviation problem.An attack could be a 484 hybrid attack, then the target_Attack_Type represents major types of 485 attacks 487 This is an optional attribute. 489 6.2. Standard of Attack Type Definition 491 For the Target_Attack_Type field, we define it as a string Type, and 492 define the two fields according to the attack method and extension 493 name. there may be problems in the actual network environment, that 494 attack target and mitigator (such as cleaning equipment) belong to 495 different models of different vendors, because different vendors have 496 different definitions of Attack in understanding and implementation. 497 When an attack occurs, some devices may not be considered as an 498 attack. It is also possible that the detection device considere it 499 as A type attack, while the cleaning device consider it as B type 500 attack. When performing the cleaning schedule, it will cause the 501 problem of incorrect cleaning or over-cleaning. Both of these errors 502 will cause the normal business to fail to link. Therefore, it is 503 necessary to unify the attack definition, form a standard attack 504 definition, and solve the problem of cleaning errors from the source. 505 we give out a complete format for DDoS attacks as below: 507 [protocol layer] [protocol name] [message name/operation name/port] 508 [attack methods feature description field 1] [attack methods feature 509 description field 2] [attack methods describe the standard field] 511 protocol layer(mandatory): Network layer, transport layer, 512 application layer; 514 protocol name(mandatory): The protocol type used for the attack, such 515 as http, TCP, ICMP, NTP...; 517 message name/ operation name/ port(optional): The message name, 518 operation name, or port used for the attack is a further addition to 519 the protocol used for the attack, with message names such as SYN and 520 operation names such as GET, Post, SYN, ACK, Query...; 521 attack methods feature description field 1 or 2 (optional): 522 Description of the method used in the attack, such as Fragment, 523 Amplification, Misuse, Slow...; 525 attack methods describe the standard field(mandatory): Used to 526 describe the type of attack, as the end field, such as flood, attack; 528 The protocol name and message name must contain at least one item in 529 the abbreviation. 531 interval between each field operators use special symbol or any other 532 symbol agreed. For example:HTTP Get Flood(CC) definition, we defined 533 the Target_Attack_Type field as below(Figure 3): 535 { 536 "Attack_Name":" Application_Layer, HTTP, Get,,, Flood" 537 "Attack_Alias":"HTTP CC Flood" 538 "Target_Attack_Type_Threshold":"1000pps" 540 } 542 Figure 3: Attack type definition example 544 An example of abbreviation: Define the target-attack-type using the 545 methods specified above, complete attack name: Transport_Layer TCP 546 SYN Flood; abbreviated form: TCP SYN Flood. 548 7. Mitigation Use Case 3 550 7.1. Mitigation alarm baseline 552 Attack target looks like to be attacked by DDoS, then DOTS client 553 send mitigation request to DOTS server, So there are exist false 554 alarms. In practice, there are standards for alerting whether or not 555 they are appropriate, such as alarm baseline. With this parameter, 556 it is possible to determine whether the standard is reasonable or 557 not, False alarms can be corrected and normal alarms can be 558 optimized. It is suggested to use Target_Attack_Type_Threshold to 559 carry this information. 561 DDoS attacks are distributed attacks, it means there are many sources 562 of attack that the traffic from each attack source varies little, so 563 it is more efficient to record the numbers of source ip than the 564 details ip address. Blocking every IP address is a thankless task 565 and short-lived. After mitigation, mitigators can feedback the 566 source ip number to DOTS server, and this information must be more 567 closer to the attack scene, these informations will be used in the 568 feedback module for more application. 570 Target_Attack_Type_Threshold: Baseline for a type of attack . 572 If attack target have the ability to classify each type of DDoS 573 attack, it must have ability to feedback criteria for each type of 574 attack. It doesn't matter that if it can not provide this 575 information, it is just an optional attribute. 577 This is an optional attribute. 579 8. Mitigation request optional parameters 581 8.1. Bandwidth consuming attack 583 Added parameters show in put method for Bandwidth consuming attack 584 are show as below(Figure 4) 586 Content-Format: "application/dots+cbor" 587 { 588 "ietf-dots-signal-channel:mitigation-scope": { 589 "scope": [ 590 { 591 "target-prefix": [ 592 "string" 593 ], 594 "target-port-range": [ 595 { 596 "lower-port": number, 597 "upper-port": number 598 } 599 ], 600 "target-protocol": [ 601 number 602 ], 603 "target-fqdn": [ 604 "string" 605 ], 606 "Attack_Target_IP":[ 607 "string" 608 ], 609 "Alarm_Begin_time":[ 610 "string" 611 ], 612 "Direction":[ 613 number 614 ], 615 "Attack_Target_IP_peak":[ 616 "string" 617 ], 618 "Attack_Source_IP_Num":[ 619 "string" 620 ], 621 "Target_Attack_Type": [ 622 { 623 "Attack-Name": ["string"], 624 "Attack-Alias": ["string"], 625 "Target_attack_Type_threshold":["string"] 626 } 627 ], 628 "Attack_Bandwidth":[ 629 "string" 630 ], 631 attack_src_ip_number:[ 632 "string" 633 ], 635 "target-uri": [ 636 "string" 637 ], 638 "alias-name": [ 639 "string" 640 ], 641 "lifetime": number, 642 "trigger-mitigation": true|false 643 } 644 ] 645 } 646 } 648 Figure 4: Mitigation request for Bandwidth consuming attack 650 8.2. Host resource consuming attack 652 Added parameters show in put method for Host resource consuming 653 attack are show as below(Figure 5) 655 Content-Format: "application/dots+cbor" 656 { 657 "ietf-dots-signal-channel:mitigation-scope": { 658 "scope": [ 659 { 660 "target-prefix": [ 661 "string" 662 ], 663 "target-port-range": [ 664 { 665 "lower-port": number, 666 "upper-port": number 667 } 668 ], 669 "target-protocol": [ 670 number 671 ], 672 "target-fqdn": [ 673 "string" 674 ], 675 "Attack_Target_IP":[ 676 "string" 677 ], 678 "Alarm_Begin_time":[ 679 "string" 680 ], 681 "Direction":[ 682 number 683 ], 684 "Attack_Target_Packet_Rate":[ 685 "string" 686 ], 687 "Target_Attack_Type": [ 688 { 689 "Attack-Name": ["string"], 690 "Attack-Alias": ["string"], 691 } 692 ], 693 "target-uri": [ 694 "string" 695 ], 696 "alias-name": [ 697 "string" 698 ], 699 "lifetime": number, 700 "trigger-mitigation": true|false 701 } 702 ] 703 } 704 } 706 Figure 5: Mitigation request for Host resource consuming attack 708 9. Mitigation response parameters 710 After the mitigation of a DDoS attack, DOTS server can obtain some 711 informations from mitigator, these informations are optional 712 parameters only as a suggestion when use DOTS to inform the message 713 between attack target and mitigator. 715 9.1. Bandwidth consuming attack 717 added parameters of Mitigation response for Bandwidth consuming 718 attack, Figure6Figure 6 720 Content-Format: "application/dots+cbor" 721 { 722 "ietf-dots-signal-channel:mitigation-scope": { 723 "scope": [ 724 { 725 "target-prefix": [ 726 "string" 727 ], 728 "target-port-range": [ 729 { 730 "lower-port": number, 731 "upper-port": number 732 } 733 ], 734 "target-protocol": [ 735 number 736 ], 737 "target-fqdn": [ 738 "string" 739 ], 740 "Attack_Target_IP":[ 741 "string" 742 ], 743 "Alarm_End_time":[ 744 "string" 745 "], 746 "Total_Traffic":[ 747 "string" 748 ], 749 "Residual_Traffic":[ 750 "string" 751 ], 752 "Attack_Traffic":[ 753 "string" 754 ], 755 "Attack_Target_IP_Peak":[ 756 "string" 757 ], 758 "Attack-Source-IP-Num":[ 759 "string" 760 ], 761 "Target_Attack_Type": [ 762 { 763 "Attack-Name": ["string"], 764 "Attack-Alias": ["string"], 765 "Target_attack_Type_threshold":["string"] 766 } 767 ], 768 "target-uri": [ 769 "string" 770 ], 771 "alias-name": [ 772 "string" 773 ], 774 "lifetime": number, 775 "trigger-mitigation": true|false 776 } 777 ] 778 } 779 } 781 Figure 6: Mitigation response for Bandwidth consuming attack 783 9.2. Host resource consuming attack 785 added parameters of Mitigation response for Bandwidth consuming 786 attack, Figure7Figure 7 788 Content-Format: "application/dots+cbor" 789 { 790 "ietf-dots-signal-channel:mitigation-scope": { 791 "scope": [ 792 { 793 "target-prefix": [ 794 "string" 795 ], 796 "target-port-range": [ 797 { 798 "lower-port": number, 799 "upper-port": number 800 } 801 ], 802 "target-protocol": [ 803 number 804 ], 805 "target-fqdn": [ 806 "string" 807 ], 808 "Attack_Target_IP":[ 809 "string" 810 ], 811 "Alarm_End_time":[ 812 "string" 813 "], 815 "Attack_Source_IP":[ 816 "string" 817 ], 818 "Attack_Target_Packet_Rate":[ 819 "string" 820 ], 821 "Target_Attack_Type": [ 822 { 823 "Attack-Name": ["string"], 824 "Attack-Alias": ["string"], 825 } 826 ], 827 "target-uri": [ 828 "string" 829 ], 830 "alias-name": [ 831 "string" 832 ], 833 "lifetime": number, 834 "trigger-mitigation": true|false 835 } 836 ] 837 } 838 } 840 Figure 7: Mitigation response for Host resource consuming attack 842 10. Security Considerations 844 TBD 846 11. IANA Considerations 848 TBD 850 12. Acknowledgement 852 TBD 854 13. References 856 13.1. Normative References 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 864 RFC 7950, DOI 10.17487/RFC7950, August 2016, 865 . 867 13.2. Informative References 869 [I-D.ietf-dots-architecture] 870 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 871 Compton, "Distributed-Denial-of-Service Open Threat 872 Signaling (DOTS) Architecture", draft-ietf-dots- 873 architecture-14 (work in progress), May 2019. 875 [I-D.ietf-dots-requirements] 876 Mortensen, A., K, R., and R. Moskowitz, "Distributed 877 Denial of Service (DDoS) Open Threat Signaling 878 Requirements", draft-ietf-dots-requirements-22 (work in 879 progress), March 2019. 881 [I-D.ietf-dots-signal-channel] 882 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 883 Teague, "Distributed Denial-of-Service Open Threat 884 Signaling (DOTS) Signal Channel Specification", draft- 885 ietf-dots-signal-channel-37 (work in progress), July 2019. 887 [I-D.ietf-dots-use-cases] 888 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 889 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 890 Open Threat Signaling", draft-ietf-dots-use-cases-19 (work 891 in progress), July 2019. 893 Authors' Addresses 895 Meiling Chen 896 CMCC 897 32, Xuanwumen West 898 BeiJing , BeiJing 100053 899 China 901 Email: chenmeiling@chinamobile.com 903 Li Su 904 CMCC 905 32, Xuanwumen West 906 BeiJing 100053 907 China 909 Email: suli@chinamobile.com 911 Jin Peng 912 CMCC 913 32, Xuanwumen West 914 BeiJing 100053 915 China 917 Email: pengjin@chinamobile.com