idnits 2.17.1 draft-chen-dots-attack-bandwidth-expansion-01.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 (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-20 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-30 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 12, 2019 CMCC 6 March 11, 2019 8 Using attack bandwidth in signal channel 9 draft-chen-dots-attack-bandwidth-expansion-01 11 Abstract 13 This document describes a DDoS Mitigation Request parameter used in 14 the Signal Channel request, as an expansion of the signal channel for 15 mitigating DDoS attack accurately with target-bandwidth. The 16 proposed parameter will help to choose the appropriate mitigator or 17 mitigators for mitigation, When An attack occurs that is greater than 18 the maximum clean capability, this paramter can decide to be 19 blackhole directly or to be drainaged for clean. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 12, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Mitigation Use Case . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. directly discard attack flow . . . . . . . . . . . . . . 4 59 3.2. Optimal device selection . . . . . . . . . . . . . . . . 5 60 3.3. Optimum path for disposal . . . . . . . . . . . . . . . . 5 61 4. Request Mitigation expansion . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Distributed Denial of Service (DDoS) is a type of resource-consuming 73 attack, which exploits a large number of attack resources and uses 74 standard protocols to attack target objects. DDoS attacks consume a 75 large amount of target object network resources or server resources 76 (including computing power, storage capacity, etc.) of the target 77 object, so that the target object cannot provide network services 78 normally. At present, DDoS attack is one of the most powerful and 79 indefensible attacks on the Internet, and due to the extensive use of 80 mobile devices and IoT devices in recent years, it is easier for DDoS 81 attackers to attack with real attack sources (broilers). 83 Volume based distributed denial-of-service attack bring huge amount 84 of attack traffic on the link, and the peaks keep hitting new highs, 85 the economic loss that causes is bigger also. For the service 86 providers to immediately protect their network services from DDoS 87 attacks, DDoS mitigation needs to be automated. 89 DDoS Open Threat Signaling (DOTS) is a protocol to standardize real- 90 time signaling, threat-handling 91 requests[I-D.ietf-dots-signal-channel], when attack target is under 92 attack, dots client send mitigation request to dots server for help, 93 If the mitigation request contains enough messages of the attack, 94 then the mitigator can respond very effectively. 96 Currently, there are two selections to deal with ddos attacks on the 97 link, one is blackhole, the other is flow clean. Blackhole means 98 that all packets send to the attack target will be discarded by 99 routers on the path, this way can instantly reduce the link load, 100 Other managed services on this link will not be affected, but for the 101 attack target all the normal business messages will be severely 102 damaged, for example, if the attack target provide News and 103 information services and under ddos attack, all users will be 104 inaccessible if the attack target choose blackhole for mitigation. 105 Flow clean means that all the flow will be drainaged by routers to 106 clean center, the clean center will recognize the attack flow from 107 normal business traffic, then reinjects normal business traffic to 108 network link by routers after the operation of attack flow discard, 109 in this way the attack target will not be effected. 111 Currently, mitigator usually has the ability to cluster cleaning 112 equipment and manage a large number of cleaning equipment. 113 Increasing the attack-bandwidth is also very convenient for the 114 scheduling of cleaning equipment, so it can match to find the most 115 suitable cleaning equipment and improve the usage rate of cleaning 116 equipment. Mitigator can also be companies who provide flow cleaning 117 service, they rent the bandwidth from Upstream Service Provider 118 themselves, so they are very careful with their link bandwidth usage. 119 Another scenario is that the link of attack warning is inconsistent 120 with the link of actual traffic drainage, so increasing the parameter 121 of attack-bandwidth is conducive to selecting the BGP path of 122 drainage. 124 This document describes attack-bandwidth, as a parameter expansion 125 used in the mitigation request. attack-bandwidth means the amount of 126 traffic under attack, this parameter can effectively reflect the 127 degree of an attack, it will be more convenient for mitigator to 128 dispose attack flow when carry target-bandwidth in the mitigation 129 request. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119] 138 The readers should be familiar with the terms defined in 139 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 141 The terminology related to YANG data modules is defined in [RFC7950] 143 In addition, this document uses the terms defined below: 145 Attack-bandwidth: the amount of traffic under attack, it is usually 146 expressed numerically. 148 Flow clean: one selection of Attack traffic deposition, the 149 operation contains recognize, discard and reinage. 151 3. Mitigation Use Case 153 3.1. directly discard attack flow 155 when attack target is under attack, it has to make corresponding 156 disposal, there are two options for disposal, one is blackhole 157 directly, in this way all the attack flow will be discarded by router 158 upper path of attack target, this means that the attack target will 159 not receive any traffic during the attack, all the traffic forwards 160 attack target will be discarded, this has a huge impact on the work 161 environment, especially the host that provide external service. 163 The other way of the disposition is to drainage all the traffic flow 164 to clean center from router, then the clean center will use pattern 165 matching or any other method to find out the attack traffic flow to 166 discard, finally, clean center reinage the normal business traffic 167 back to attack target by upper router, the whole process above is 168 defined as flow clean(Figure 1). 170 attack flow +--------+ +--------+ 171 ----------->| router |------------------>| clean | 172 1 +--------+ 2 | center | 173 | +--------+ 174 3 | | 175 | +--------+ | 176 +------>| attack |<-------------+ 177 | target | 178 +--------+ 180 Figure 1: diagram of DDoS Mitigation usecase 182 Generally, the bandwidth of the link 1 must be larger than link 2 and 183 link 3, and the clean ability of clean center limited to hardware 184 resources. An example of link situation is as below(Figure 2): 186 +------------+------------+ 187 | figure | bandwidth/ | 188 | tag | capability | 189 +------------+------------+ 190 | link 1 | 100Gb | 191 | link 2 | 50Gb | 192 | link 3 | 10Gb | 193 |clean center| 80Gb | 194 +------------+------------+ 196 Figure 2: an example of link bandwidth 198 The Figure2 is a scenario of the link bandwidth, when a ddos attack 199 is ongoing, if the link 1 bandwidth is completely jammed, the best 200 way to mitigate the attack is to discard all the attack flow; if the 201 amount of the traffic flow is lower than the remainder cleaning 202 ability, the most suitable deposition is to drainage all the attack 203 flow to clean center. 205 Therefore, it is an obvious requirement in the current network 206 environment. In the architecture of DOTS, Dots client send 207 mitigation request to dots server, the parameters in the mitigation 208 request contains some message of attack target, but there have not 209 any messages of attack, if add attack-bandwidth to mitigation request 210 as an expansion, it will be more effective and convenient for the 211 disposition of mitigator. 213 3.2. Optimal device selection 215 Mitigator may owns a cleaning device cluster and can manage cleaning 216 devices.The capacity of each cleaning equipment is not the same, 217 usually each cleaning equipment utilization rate is not the same, 218 then the remaining cleaning capacity is not consistent.When the 219 attack flow is less than the ability of a cleaning equipment, 220 according to the attack-bandwidth can choose a suitable cleaning 221 equipment,that is conducive to the utilization of equipment;When the 222 attack flow is larger than the cleaning capacity of one cleaning 223 device, several cleaning devices can be optimally scheduled according 224 to the attack-bandwidth. 226 3.3. Optimum path for disposal 228 When mitigator is an attack flow cleaning service, they typically 229 deployed the mitigator in a distributed way because of the cost of 230 bandwidth usage with their own leased operator's link bandwidth, and 231 choosing the best traction path was the key to profitability.If the 232 parameter of attack-bandwidth is carried, then the generation of the 233 best drainage path is very meaningful. 235 When mitigator is at the upstream service operator level, they might 236 have multiple networks, with the attack alert using one network and 237 the flow drainage using another, and the link load is not the same, 238 then carrying the attack-bandwidth is very beneficial for choosing 239 the drainage path, mainly for link load balancing. 241 4. Request Mitigation expansion 243 When a DOTS client requires mitigation for some reason, the DOTS 244 client uses the CoAP PUT method to send a mitigation request to its 245 DOTS server(s). If a DOTS client is entitled to solicit the DOTS 246 service, the DOTS server enables mitigation on behalf of the DOTS 247 client by communicating the DOTS client's request to a mitigator 248 (which may be colocated with the DOTS server) and relaying the 249 feedback of the thus-selected mitigator to the requesting DOTS 250 client. 252 DOTS clients use the PUT method to request mitigation from a DOTS 253 server. During active mitigation, DOTS clients may use PUT requests 254 to carry mitigation efficacy updates to the DOTS server. 256 The new parameter in the CBOR body (Figure 3) is described below: 258 Content-Format: "application/dots+cbor" 259 { 260 "ietf-dots-signal-channel:mitigation-scope": { 261 "scope": [ 262 { 263 "target-prefix": [ 264 "string" 265 ], 266 "target-port-range": [ 267 { 268 "lower-port": number, 269 "upper-port": number 270 } 271 ], 272 "target-protocol": [ 273 number 274 ], 275 "target-fqdn": [ 276 "string" 277 ], 278 "attack-bandwidth":[ 279 "string" 280 ], 281 "target-uri": [ 282 "string" 283 ], 284 "alias-name": [ 285 "string" 286 ], 287 "lifetime": number, 288 "trigger-mitigation": true|false 289 } 290 ] 291 } 292 } 294 Figure 3: PUT to Convey DOTS Mitigation Requests 296 attack-bandwidth: bandwidth occupied by an attack, The recommended 297 format is numerical form, such as xxGb. Different attack has 298 different attack bandwidth, numerical value directly reflects the 299 urgency of the current attack. Serious attacks are treated with 300 blackhole, Other cases use flow cleaning, attack-bandwidth is 301 conducive to the selection of disposal mode. 303 This is an optional attribute. 305 The definition of the rest parameters are the same as the 306 [I-D.ietf-dots-signal-channel] 308 5. Security Considerations 310 TBD 312 6. IANA Considerations 314 TBD 316 7. Acknowledgement 318 TBD 320 8. References 322 8.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 330 RFC 7950, DOI 10.17487/RFC7950, August 2016, 331 . 333 8.2. Informative References 335 [I-D.ietf-dots-requirements] 336 Mortensen, A., K, R., and R. Moskowitz, "Distributed 337 Denial of Service (DDoS) Open Threat Signaling 338 Requirements", draft-ietf-dots-requirements-20 (work in 339 progress), February 2019. 341 [I-D.ietf-dots-signal-channel] 342 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 343 Teague, "Distributed Denial-of-Service Open Threat 344 Signaling (DOTS) Signal Channel Specification", draft- 345 ietf-dots-signal-channel-30 (work in progress), March 346 2019. 348 [I-D.ietf-dots-use-cases] 349 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 350 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 351 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 352 in progress), January 2019. 354 Authors' Addresses 356 Meiling Chen 357 CMCC 358 32, Xuanwumen West 359 BeiJing , BeiJing 100053 360 China 362 Email: chenmeiling@chinamobile.com 364 Li Su 365 CMCC 366 32, Xuanwumen West 367 BeiJing 100053 368 China 370 Email: suli@chinamobile.com 372 Jin Peng 373 CMCC 374 32, Xuanwumen West 375 BeiJing 100053 376 China 378 Email: pengjin@chinamobile.com