idnits 2.17.1 draft-meiling-dots-attack-type-expansion-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 (March 9, 2019) is 1869 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == 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: Experimental CMCC 5 Expires: September 10, 2019 March 9, 2019 7 expand attack type in signal channel 8 draft-meiling-dots-attack-type-expansion-00 10 Abstract 12 This document describes a DDoS Mitigation Request parameter used in 13 the Signal Channel request, as an expansion of the signal channel for 14 mitigating DDoS attack accurately with attack types. The proposed 15 parameter will help to achieve fine-grained disposition for the 16 attack traffic to be cleaned. 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 September 10, 2019. 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 3. Request Mitigation expansion . . . . . . . . . . . . . . . . 4 55 4. Standard of Attack Type Definition . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 8.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 Distributed Denial of Service (DDoS) is a type of resource-consuming 67 attack, which exploits a large number of attack resources and uses 68 standard protocols to attack target objects. DDoS attacks consume a 69 large amount of target object network resources or server resources 70 (including computing power, storage capacity, etc.) of the target 71 object, so that the target object cannot provide network services 72 normally. At present, DDoS attack is one of the most powerful and 73 indefensible attacks on the Internet, and due to the extensive use of 74 mobile devices and IoT devices in recent years, it is easier for DDoS 75 attackers to attack with real attack sources (broilers). 77 Why again raise the parameter of attack type to add to mitigation 78 request for discussion; Although the scope of DOTS work now is the 79 interaction between DOTS client and DOTS server, the mitigator and 80 attack target roles must be considered in the implementation when use 81 DOTS mechanism. It has been discussed before whether it is 82 appropriate to carry the type of attack in the mitigation request 83 parameters. Some views hold that the type of attack reported is not 84 credible.The premise of this view is that both attack detection and 85 attack disposal belong to the mitigator role. But there is another 86 scenario in which attack detection and attack disposal are separated, 87 and one possible scenario in which the attack detection is at the 88 attack target and the attack disposal is at the mitigator, then 89 attack informations such as the attack type is trusted.We can also 90 consider a scenario, if an entity is not only the attack target, but 91 also a mitigator, when ddos attack occurs, it requires other 92 mitigators upper link to mitigate the attack flow, so it will use 93 dots client send mitigation reqest to other top link mitigator 94 together, in this case all the mitigators can share informations of 95 the attack, and the informations are fully trusted, in this way, 96 other mitigator does not need to waste of resources for detecting 97 again. 99 Why do we need uniform attack types. At present, telecom operators, 100 cloud service providers and third-party manufacturers have their own 101 anti-ddos solutions.The construction of DDoS attack mitigation and 102 disposal system involves two devices, namely detection equipment and 103 cleaning equipment. In the actual network deployment, the core nodes 104 of the network will deploy detection equipment and cleaning equipment 105 at the same time to detect and dispose attacks. After an alarm is 106 given, the cleaning equipment will be triggered to carry out traffic 107 drainage and cleaning operations. At present, the detection 108 equipment adopts the coarse-grained attack type determination method, 109 which greatly reduces the false alarm rate of attack.Different 110 disposal of cleaning equipment is different for different attack 111 types. For example, UDP attack types can be discarded directly after 112 matching, but HTTP CC Flood can be further determined only after 113 interactive operation is required at the disposal. Interactive 114 operation may be redirection or verification code sending. In the 115 actual environment, there are many manufacturers of detection 116 equipment and cleaning equipment, and each manufacturer has its own 117 definition method of attack type, so it is easy to lead to the same 118 attack, but the field of attack type detected by different equipment 119 manufacturers is not the same, which may easily lead to disposal 120 confusion. 122 Volume based distributed denial-of-service attack have many types 123 based on different protocol layer, for the service providers to 124 immediately protect their network services from DDoS attacks, DDoS 125 mitigation needs to be automated. DDoS Open Threat Signaling (DOTS) 126 is a protocol to standardize real-time signaling, threat-handling 127 requests[I-D.ietf-dots-signal-channel], when attack target is under 128 attack, dots client send mitigation request to dots server for help, 129 If the mitigation request contains enough messages of the attack, 130 then the mitigator can respond very effectively. This document 131 describe attack type in the mitigation request. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 [RFC2119] 140 The readers should be familiar with the terms defined in 141 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 143 The terminology related to YANG data modules is defined in [RFC7950] 145 In addition, this document uses the terms defined below: 147 Attack Type: used to distinguish between different methods of ddos 148 attack. 150 Attack type definition: General definition method, Covers most 151 current attack types. 153 3. Request Mitigation expansion 155 The purpose of this expansion is to propose the attack traffic more 156 accurately. When we deal with DDoS attacks, we find it more 157 reasonable and effective to deal with them according to the types of 158 attacks, It is easier to handle if the type of attack is already 159 included in the mitigation request. AS the mitigator doesn't have to 160 detect the attack type again, the mitigator can directly do the 161 drainage of attack flow. Therefore, with attack type the disposal 162 process is more efficient. 164 From the point of view of cleaning, different types of attacks are 165 handled differently, for example, Memcached reflection flood use UDP 166 11211 port for DDoS flood, but tcp syn flood use defects of TCP 167 three-way handshake to consuming connection resources. This two 168 attacks are cleaned in different ways. Therefore, it is necessary to 169 add attack type parameters in the mitigation request. 171 When a DOTS client requires mitigation for some reason, the DOTS 172 client uses the CoAP PUT method to send a mitigation request to its 173 DOTS server(s). If a DOTS client is entitled to solicit the DOTS 174 service, the DOTS server enables mitigation on behalf of the DOTS 175 client by communicating the DOTS client's request to a mitigator 176 (which may be colocated with the DOTS server) and relaying the 177 feedback of the thus-selected mitigator to the requesting DOTS 178 client. 180 DOTS clients use the PUT method to request mitigation from a DOTS 181 server. During active mitigation, DOTS clients may use PUT requests 182 to carry mitigation efficacy updates to the DOTS server. 184 The two new parameters in the CBOR body (Figure 1) are described 185 below: 187 Content-Format: "application/dots+cbor" 188 { 189 "ietf-dots-signal-channel:mitigation-scope": { 190 "scope": [ 191 { 192 "target-prefix": [ 193 "string" 194 ], 195 "target-port-range": [ 196 { 197 "lower-port": number, 198 "upper-port": number 199 } 200 ], 201 "target-protocol": [ 202 number 203 ], 204 "target-fqdn": [ 205 "string" 206 ], 207 "target-Attack-Type": [ 208 { 209 "Attack-Name": ["string"], 210 "Attack-Alias": ["string"] 211 } 212 ], 213 "target-uri": [ 214 "string" 215 ], 216 "alias-name": [ 217 "string" 218 ], 219 "lifetime": number, 220 "trigger-mitigation": true|false 221 } 222 ] 223 } 224 } 226 Figure 1: PUT to Convey DOTS Mitigation Requests 228 target-attack-type: A list of attack types involved in an attack. 230 There is no uniform definition of attack types, It is often the 231 case that the same type of attack has different names, An attack 232 type is defined in section 4. 234 The parameter of Target-attack-type contains two value, one is 235 Attack-Name, the other is Attack-Alias, Attack-Alias will solve 236 the abbreviation problem.An attack could be a hybrid attack, then 237 the target-attack-type represents major types of attacks 239 This is an optional attribute. 241 The definition of the rest parameters are the same as the 242 [I-D.ietf-dots-signal-channel] 244 4. Standard of Attack Type Definition 246 For the target-attack-type field, we define it as a string Type, and 247 define the two fields according to the attack method and extension 248 name. there may be problems in the actual network environment, that 249 attack target and mitigator (such as cleaning equipment) belong to 250 different models of different vendors, because different vendors have 251 different definitions of Attack in understanding and implementation. 252 When an attack occurs, some devices may not be considered as an 253 attack. It is also possible that the detection device considere it 254 as A type attack, while the cleaning device consider it as B type 255 attack. When performing the cleaning schedule, it will cause the 256 problem of incorrect cleaning or over-cleaning. Both of these errors 257 will cause the normal business to fail to link. Therefore, it is 258 necessary to unify the attack definition, form a standard attack 259 definition, and solve the problem of cleaning errors from the source. 260 we give out a complete format for DDoS attacks as below: 262 [protocol level] [protocol name] [message name/operation name/port] 263 [attack methods feature description field 1] [attack methods feature 264 description field 2] [attack methods describe the standard field] 266 interval between each field operators use special symbol or any other 267 symbol agreed.For example:HTTP Get Flood(CC) definition,we defined 268 the target-Attack-Type field as: 270 { 271 "Attack-Name":" Application _Layer, HTTP, Get,,, Flood" 272 "Attack-Alias":"HTTP CC Flood" 274 } 276 Figure 2: Attack type definition example 278 Based on the extension, the DOTS Server can accurately inform 279 Mitigator of the objects and attack types that need to be disposed 280 when the mitigation instructions are delivered to the Mitigation, so 281 that the Mitigator can be accurately disposed. 283 5. Security Considerations 285 TBD 287 6. IANA Considerations 289 TBD 291 7. Acknowledgement 293 TBD 295 8. References 297 8.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 305 RFC 7950, DOI 10.17487/RFC7950, August 2016, 306 . 308 8.2. Informative References 310 [I-D.ietf-dots-requirements] 311 Mortensen, A., K, R., and R. Moskowitz, "Distributed 312 Denial of Service (DDoS) Open Threat Signaling 313 Requirements", draft-ietf-dots-requirements-20 (work in 314 progress), February 2019. 316 [I-D.ietf-dots-signal-channel] 317 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 318 Teague, "Distributed Denial-of-Service Open Threat 319 Signaling (DOTS) Signal Channel Specification", draft- 320 ietf-dots-signal-channel-30 (work in progress), March 321 2019. 323 [I-D.ietf-dots-use-cases] 324 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 325 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 326 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 327 in progress), January 2019. 329 Authors' Addresses 331 Meiling Chen 332 CMCC 333 32, Xuanwumen West 334 BeiJing , BeiJing 100053 335 China 337 Email: chenmeiling@chinamobile.com 339 Li Su 340 CMCC 341 32, Xuanwumen West 342 BeiJing 100053 343 China 345 Email: suli@chinamobile.com