idnits 2.17.1 draft-chen-dots-attack-informations-00.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 (July 07, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dots-architecture' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dots-signal-channel' is defined on line 481, 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-34 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 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: Informational Jin. Peng 5 Expires: January 8, 2020 CMCC 6 July 07, 2019 8 DOTS client carry ddos attack information in signal channel 9 draft-chen-dots-attack-informations-00 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 using 16 Signal channel within Mitigation Request. 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 January 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 56 3. Mitigation Use Case 1 . . . . . . . . . . . . . . . . . . . . 4 57 3.1. directly discard attack flow . . . . . . . . . . . . . . 4 58 3.2. Optimal device selection . . . . . . . . . . . . . . . . 5 59 3.3. Optimum path for disposal . . . . . . . . . . . . . . . . 5 60 3.4. Mitigation request parameter . . . . . . . . . . . . . . 6 61 4. Mitigation Use Case 2 . . . . . . . . . . . . . . . . . . . . 6 62 4.1. classified disposal . . . . . . . . . . . . . . . . . . . 6 63 4.2. Standard of Attack Type Definition . . . . . . . . . . . 7 64 5. Mitigation Use Case 3 . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Mitigation alarm baseline . . . . . . . . . . . . . . . . 7 66 6. Mitigation request optional parameters . . . . . . . . . . . 8 67 7. Mitigation response parameters . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 11.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Distributed Denial of Service (DDoS) is a type of resource-consuming 79 attack, which exploits a large number of attack resources and uses 80 standard protocols to attack target objects. DDoS attacks consume a 81 large amount of target network resources or server resources 82 (including computing power, storage capacity, etc.). At present, 83 DDoS attack is one of the most powerful and indefensible attacks on 84 the Internet, and due to the extensive use of mobile devices and IoT 85 devices in recent years, it is easier for DDoS attackers to attack 86 with real attack sources (broilers). 88 The IETF is specifying the DDoS Open Threat Signaling (DOTS) 89 [I-D.ietf-dots-architecture]architecture, where a DOTS client can 90 inform a DOTS server that the network is under a potential attack and 91 that appropriate mitigation actions are required. In the 92 architecture draft, it says in the draft the enterprise has a DOTS 93 client, which obtains information about the DDoS attack, and signals 94 the DOTS server for help in mitigating the attack. but it doesn't 95 says what the information of DDoS attack is. the scope of this draft 96 is about the information of DDoS attack which DOTS client can obtain. 98 In the architecture draft, it says in the draft the client signal may 99 also include telemetry information about the attack, if the DOTS 100 client has such information available. But in the signal channel 101 draft it doesn't define optional parameter about the telemetry 102 information which will be regarded as DDoS portrait information. 104 "DDoS portrait information" is defined as the collection of 105 attributes characterizing the actual attacks that have been detected 106 and mitigated. The DDoS portrait information is an optional set of 107 attributes that can be signaled in the DOTS signal channel. The 108 portrait can be optionally sent from the DOTS Client to Server and 109 vice versa. 111 This document will divide two directions, before mitigation request 112 and after mitigation is complete. Before mitigation request, DOTS 113 client can obtain informations of attack; After mitigation, DOTS 114 server can obtain from mitigator. 116 2. Terminology 118 2.1. Key Words 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119] 125 2.2. Definition of Terms 127 The readers should be familiar with the terms defined in 128 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 130 The terminology related to YANG data modules is defined in [RFC7950] 132 In addition, this document uses the terms defined below: 134 Attack-bandwidth: the amount of traffic under attack, it is usually 135 expressed numerically. 137 Flow clean: one selection of Attack traffic deposition, the 138 operation contains recognize, discard and reinage. 140 Attack Type: used to distinguish between different methods of ddos 141 attack. 143 Attack type definition: General definition method, Covers most 144 current attack types. 146 3. Mitigation Use Case 1 148 3.1. directly discard attack flow 150 when attack target is under attack, it has to make corresponding 151 disposal, there are two options for disposal, one is blackhole 152 directly which may be take effect in routers, in this way all the 153 attack flow will be discarded by router upper path of attack target, 154 this means that the attack target will not receive any traffic during 155 the attack, all the traffic forwards attack target will be discarded, 156 this has a huge impact on the work environment, especially the host 157 that provide external service. The other way of the disposition is 158 to drainage all the traffic flow to clean center from router, then 159 the clean center will use pattern matching or any other method to 160 find out the attack traffic flow to discard, finally, clean center 161 reinage the normal business traffic back to attack target by upper 162 router, the whole process above is defined as flow clean(Figure 1). 164 attack flow +--------+ +--------+ 165 ----------->| router |------------------>| clean | 166 1 +--------+ 2 | center | 167 | +--------+ 168 3 | | 169 | +--------+ | 170 +------>| attack |<-------------+ 171 | target | 172 +--------+ 174 Figure 1: diagram of DDoS Mitigation usecase 176 Generally, the bandwidth of the link 1 must be larger than link 2 and 177 link 3, and the clean ability of clean center limited to hardware 178 resources. An example of link situation is as below(Figure 2): 180 +------------+------------+ 181 | figure | bandwidth/ | 182 | tag | capability | 183 +------------+------------+ 184 | link 1 | 100Gb | 185 | link 2 | 50Gb | 186 | link 3 | 10Gb | 187 |clean center| 80Gb | 188 +------------+------------+ 190 Figure 2: an example of link bandwidth 192 The Figure2 is a scenario of the link bandwidth, when a ddos attack 193 is ongoing, if the link 1 bandwidth is completely jammed, the best 194 way to mitigate the attack is to discard all the attack flow; if the 195 amount of the traffic flow is lower than the remainder cleaning 196 ability, the most suitable deposition is to drainage all the attack 197 flow to clean center.Therefore, it is an obvious requirement in the 198 current network environment. 200 3.2. Optimal device selection 202 Mitigator may owns a cleaning device cluster and can manage cleaning 203 devices.The capacity of each cleaning equipment is not the same, 204 usually each cleaning equipment utilization rate is not the same, 205 then the remaining cleaning capacity is not consistent.When the 206 attack flow is less than the ability of a cleaning equipment, 207 according to the attack-bandwidth can choose a suitable cleaning 208 equipment,that is conducive to the utilization of equipment;When the 209 attack flow is larger than the cleaning capacity of one cleaning 210 device, several cleaning devices can be optimally scheduled according 211 to the attack-bandwidth. 213 3.3. Optimum path for disposal 215 When mitigator is an attack flow cleaning service, they typically 216 deployed the mitigator in a distributed way because of the cost of 217 bandwidth usage with their own leased operator's link bandwidth, and 218 choosing the best traction path was the key to profitability.If the 219 parameter of attack-bandwidth is carried, then the generation of the 220 best drainage path is very meaningful. 222 When mitigator is at the upstream service operator level, they might 223 have multiple networks, with the attack alert using one network and 224 the flow drainage using another, and the link load is not the same, 225 then carrying the attack-bandwidth is very beneficial for choosing 226 the drainage path, mainly for link load balancing. 228 3.4. Mitigation request parameter 230 When a DOTS client requires mitigation for some reason, the DOTS 231 client uses the CoAP PUT method to send a mitigation request to its 232 DOTS server(s). If a DOTS client is entitled to solicit the DOTS 233 service, the DOTS server enables mitigation on behalf of the DOTS 234 client by communicating the DOTS client's request to a mitigator 235 (which may be colocated with the DOTS server) and relaying the 236 feedback of the thus-selected mitigator to the requesting DOTS 237 client. 239 DOTS clients use the PUT method to request mitigation from a DOTS 240 server. During active mitigation, DOTS clients may use PUT requests 241 to carry mitigation efficacy updates to the DOTS server. We suggest 242 to add attack bandwidth to satiesfy the requirement. 244 total traffic when ddos attack occur, The recommended format is 245 numerical form, such as xxGb. Different attack has different attack 246 bandwidth, numerical value directly reflects the urgency of the 247 current attack. Serious attacks are treated with blackhole, Other 248 cases use flow cleaning, attack-bandwidth is conducive to the 249 selection of disposal mode. 251 This is an optional attribute. 253 4. Mitigation Use Case 2 255 4.1. classified disposal 257 DDoS attack is a hybrid attack across multiple protocol layers and 258 multiple method, when we deal with DDoS attacks, we find it more 259 reasonable and effective to deal with them according to the types of 260 attacks, It is easier to handle if the type of attack is already 261 included in the mitigation request. There is no doubt that the 262 information may not be accurate, but we can take it as a reference. 263 Therefore, with attack type the disposal process is more helpful. 264 From the point of view of cleaning, different types of attacks are 265 handled differently, for example, Memcached reflection flood use UDP 266 11211 port for DDoS flood, but tcp syn flood use defects of TCP 267 three-way handshake to consuming connection resources. This two 268 attacks are cleaned in different ways. We suggest to add attack type 269 to satiesfy the requirement. 271 A list of attack types involved in an attack. 273 There is no uniform definition of attack types, It is often the case 274 that the same type of attack has different names, An attack type is 275 defined in section 4. 277 The parameter of Target-attack-type contains two value, one is 278 Attack-Name, the other is Attack-Alias, Attack-Alias will solve the 279 abbreviation problem.An attack could be a hybrid attack, then the 280 target-attack-type represents major types of attacks 282 This is an optional attribute. 284 4.2. Standard of Attack Type Definition 286 For the target-attack-type field, we define it as a string Type, and 287 define the two fields according to the attack method and extension 288 name. there may be problems in the actual network environment, that 289 attack target and mitigator (such as cleaning equipment) belong to 290 different models of different vendors, because different vendors have 291 different definitions of Attack in understanding and implementation. 292 When an attack occurs, some devices may not be considered as an 293 attack. It is also possible that the detection device considere it 294 as A type attack, while the cleaning device consider it as B type 295 attack. When performing the cleaning schedule, it will cause the 296 problem of incorrect cleaning or over-cleaning. Both of these errors 297 will cause the normal business to fail to link. Therefore, it is 298 necessary to unify the attack definition, form a standard attack 299 definition, and solve the problem of cleaning errors from the source. 300 we give out a complete format for DDoS attacks as below: 302 [protocol layer] [protocol name] [message name/operation name/port] 303 [attack methods feature description field 1] [attack methods feature 304 description field 2] [attack methods describe the standard field] 306 interval between each field operators use special symbol or any other 307 symbol agreed.For example:HTTP Get Flood(CC) definition,we defined 308 the target-Attack-Type field as below(Figure 3): 310 { 311 "Attack-Name":" Application_Layer, HTTP, Get,,, Flood" 312 "Attack-Alias":"HTTP CC Flood" 314 } 316 Figure 3: Attack type definition example 318 5. Mitigation Use Case 3 320 5.1. Mitigation alarm baseline 322 Attack target look like to be attacked by DDoS, then DOTS client send 323 mitigation request to DOTS server, So there are exist false alarms. 324 In practice, there are standards for alerting whether or not they are 325 appropriate, such as alarm baseline. With this parameter, it is 326 possible to determine whether the standard is reasonable or not, 327 False alarms can be corrected and normal alarms can be optimized. It 328 is suggested to use target_attack_Type_threshold to carry this 329 information. 331 DDoS attacks are distributed attacks, it means there are many sources 332 of attack that the traffic from each attack source varies little, so 333 it is more efficient to record the numbers of source ip than the 334 details ip address. Blocking every IP address is a thankless task 335 and short-lived. After mitigation, mitigators can feedback the 336 source ip number to DOTS server, and this information must be more 337 closer to the attack scene. 339 target_attack_Type_threshold: Baseline for a type of attack . 341 If attack target have the ability to classify each type of DDoS 342 attack, it must have ability to feedback criteria for each type of 343 attack. It doesn't matter that if it can not provide this 344 information, it is just an optional attribute. 346 This is an optional attribute. 348 attack_src_ip_number: Estimated number of attack sources . 350 This is an optional attribute. 352 6. Mitigation request optional parameters 354 Added parameter show in put method are show as below(Figure 4) 356 Content-Format: "application/dots+cbor" 357 { 358 "ietf-dots-signal-channel:mitigation-scope": { 359 "scope": [ 360 { 361 "target-prefix": [ 362 "string" 363 ], 364 "target-port-range": [ 365 { 366 "lower-port": number, 367 "upper-port": number 368 } 369 ], 370 "target-protocol": [ 371 number 372 ], 373 "target-fqdn": [ 374 "string" 375 ], 376 "target-Attack-Type": [ 377 { 378 "Attack-Name": ["string"], 379 "Attack-Alias": ["string"] 380 "target_attack_Type_threshold":["string"] 381 } 382 ], 383 "target-bandwidth":[ 384 "string" 385 ], 386 attack_src_ip_number:[ 387 "string" 388 ], 390 "target-uri": [ 391 "string" 392 ], 393 "alias-name": [ 394 "string" 395 ], 396 "lifetime": number, 397 "trigger-mitigation": true|false 398 } 399 ] 400 } 401 } 403 Figure 4: Mitigation Response for Get Request 405 7. Mitigation response parameters 407 After the mitigation of a DDoS attack, DOTS server can obtain some 408 informations from mitigator, these informations are optional 409 parameters only as a suggestion when use DOTS to inform the message 410 between attack target and mitigator.Figure5Figure 5 shows a response 411 example of a mitigation request. 413 Content-Format: "application/dots+cbor" 414 { 415 "ietf-dots-signal-channel:mitigation-scope": { 416 "scope": [ 417 { 418 "mid": 12332, 419 "mitigation-start": "1507818434", 420 "target-prefix": [ 421 "2001:db8:6401::1/128", 422 "2001:db8:6401::2/128" 423 ], 424 "target-protocol": [ 425 17 426 ], 427 "lifetime": 1756, 428 "status": "attack-successfully-mitigated", 429 "bytes-dropped": "134334555", 430 "bps-dropped": "43344", 431 "pkts-dropped": "333334444", 432 "pps-dropped": "432432", 433 "attack_src_ip_number": "5231" 434 }, 435 ] 436 } 437 } 438 } 440 Figure 5: PUT to Convey DOTS Mitigation Requests 442 8. Security Considerations 444 TBD 446 9. IANA Considerations 448 TBD 450 10. Acknowledgement 452 TBD 454 11. References 456 11.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 464 RFC 7950, DOI 10.17487/RFC7950, August 2016, 465 . 467 11.2. Informative References 469 [I-D.ietf-dots-architecture] 470 Mortensen, A., K, R., Andreasen, F., Teague, N., and R. 471 Compton, "Distributed-Denial-of-Service Open Threat 472 Signaling (DOTS) Architecture", draft-ietf-dots- 473 architecture-14 (work in progress), May 2019. 475 [I-D.ietf-dots-requirements] 476 Mortensen, A., K, R., and R. Moskowitz, "Distributed 477 Denial of Service (DDoS) Open Threat Signaling 478 Requirements", draft-ietf-dots-requirements-22 (work in 479 progress), March 2019. 481 [I-D.ietf-dots-signal-channel] 482 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 483 Teague, "Distributed Denial-of-Service Open Threat 484 Signaling (DOTS) Signal Channel Specification", draft- 485 ietf-dots-signal-channel-34 (work in progress), May 2019. 487 [I-D.ietf-dots-use-cases] 488 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 489 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 490 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 491 in progress), January 2019. 493 Authors' Addresses 495 Meiling Chen 496 CMCC 497 32, Xuanwumen West 498 BeiJing , BeiJing 100053 499 China 501 Email: chenmeiling@chinamobile.com 502 Li Su 503 CMCC 504 32, Xuanwumen West 505 BeiJing 100053 506 China 508 Email: suli@chinamobile.com 510 Jin Peng 511 CMCC 512 32, Xuanwumen West 513 BeiJing 100053 514 China 516 Email: pengjin@chinamobile.com