idnits 2.17.1 draft-chen-dots-attack-type-unification-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 : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 18 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 17, 2019) is 1624 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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-20 Summary: 1 error (**), 0 flaws (~~), 4 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 CMCC 5 Expires: April 19, 2020 October 17, 2019 7 attack type unification 8 draft-chen-dots-attack-type-unification-00 10 Abstract 12 This document put forward a method to unify DDoS attack type 13 classification and attack definition description, this will help 14 different mitigators to mitigate DDoS attacks together. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 19, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. DDoS Attack Type Classification Framework . . . . . . . . . . 3 53 4. DDoS Attack Definition Description . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 59 8.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 Distributed Denial of Service (DDoS) is a type of resource-consuming 65 attack, which exploits a large number of attack resources and uses 66 standard protocols to attack target objects. With the cost of DDoS 67 attack become more cheaper, DDoS attack become more and more 68 frequently, a single mitigator unable to cope with all the DDoS 69 attack, so DOTS come up to solve the problem. 71 From the charter of DOTS working group, it writes that elements may 72 be deployed as part of a wider strategy incorporating multiple points 73 of DDoS detection, classification, traceback and mitigation, both on 74 premise or service provider based. As so far, DDoS classification 75 have not written to DOTS. This draft will from the perspective of 76 the type of DDoS attack to do DDoS classification. 78 Different understanding of DDoS attacks will result in different 79 classification and that's why do we need uniform attack types. At 80 present, telecom operators, cloud service providers and third-party 81 manufacturers have their own anti-ddos solutions.The construction of 82 DDoS attack mitigation and disposal system involves two devices, 83 namely detection equipment and cleaning equipment. In the actual 84 network deployment, the core nodes of the network will deploy 85 detection equipment and cleaning equipment at the same time to detect 86 and dispose attacks. After an alarm is given, the cleaning equipment 87 will be triggered to carry out traffic drainage and cleaning 88 operations. At present, the detection equipment adopts the coarse- 89 grained attack type determination method, which greatly reduces the 90 false alarm rate of attack.Different disposal of cleaning equipment 91 is different for different attack types. For example, TCP attack 92 types can be discarded directly after matching, but HTTP CC Flood can 93 be further determined only after interactive operation is required at 94 the disposal. Interactive operation may be redirection or 95 verification code sending. In the actual environment, there are many 96 manufacturers of detection equipment and cleaning equipment, and each 97 manufacturer has its own definition method of attack type, so it is 98 easy to lead to the same attack, but the field of attack type 99 detected by different equipment manufacturers is different, which may 100 easily lead to disposal confusion. The attack type is inconsistently 101 defined, it is difficult or controversial to judge the ability of 102 test selection of DDoS attack detection and clean equipment. 104 Volume based distributed denial-of-service attack have many types 105 based on different protocol layer, for the service providers to 106 immediately protect their network services from DDoS attacks, DDoS 107 mitigation needs to be automated. DDoS Open Threat Signaling (DOTS) 108 is a protocol to standardize real-time signaling, threat-handling 109 requests[I-D.ietf-dots-signal-channel], when attack target is under 110 attack, dots client send mitigation request to dots server for help, 111 If the mitigation request contains enough messages of the attack, 112 then the mitigator can respond very effectively. This document 113 recommand a method for attack type unification. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 [RFC2119] 122 The readers should be familiar with the terms defined in 123 [I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases] 125 The terminology related to YANG data modules is defined in [RFC7950] 127 In addition, this document uses the terms defined below: 129 Attack Type: used to distinguish between different methods of ddos 130 attack. 132 Attack type definition: General definition method, Covers most 133 current attack types. 135 3. DDoS Attack Type Classification Framework 137 The existing classification of DDoS attack type is divided into 138 multiple dimensions: by the protocol used, such as SYN Flood, HTTP 139 Flood, ICMP Flood; by attack effect, such as bandwidth occupancy 140 attack, Connection attack, slow attack; by the attack method, such as 141 abnormal message attack, reflection amplification attack; 142 In the above definition of multiple types of attacks, there is 143 partial overlap. Combined with the existing classification of DDoS 144 attack, the consensus of classifying DDoS attack by protocol layer is 145 the highest. 147 This draft of protocol layer is based on the TCP/IP model, the basic 148 classification framework of DDoS attack as follows: Firstly, protocol 149 layer, such as Network layer, transport layer and application layer; 150 Secondly, Protocol and Messaging, Divide by protocol exploited by the 151 attack, Then define the message and port involved in the protocol, 152 User-defined (Protocol+port) format identifies attack types that are 153 not well defined or standardized.Finally, Attack method, defined 154 according to the method used in DDoS attack. 156 ..................................................................... 157 Protocol layer | 158 +-------------+ +---------------+ +-----------------+ 159 |Network layer|-----|Transport layer|------|Application layer| 160 +-------------+ +---------------+ +-----------------+ 161 | | | 162 ..............|....................|.......................|......... 163 Protocol and | | | 164 Messaging | | | 165 +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 166 |...|---|ICMP| |TCP|---|UDP|---|...| |HTTP|--|DNS|--|...| 167 +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 168 | | | 169 ..............|....................|.......................|......... 170 Attack Method | | | 171 | | | 172 +--------------+ +---------------+ +--------------+ 173 |Flood | |Flood | |Flood | 174 |Fragment Flood| |Fragment Flood | |Slow attack | 175 |... | |... | |... | 176 +--------------+ +---------------+ +--------------+ 177 ..................................................................... 179 Figure 1: Basic classification framework 181 4. DDoS Attack Definition Description 183 In view of the difference in attack definition, the method of this 184 draft is based on the basic classification framework to standardize 185 the format as follows. 187 [protocol layer] [protocol name] [message name/operation name/port] 188 [attack methods feature description field 1] [attack methods feature 189 description field 2] [attack methods describe the standard field]. 190 Note1: the field of [message name/operation name/port] and [attack 191 methods feature description field 1] and [attack methods feature 192 description field 2] are optional. Note2: [protocol name] and 193 [message name/operation name/port] must contain at least one in the 194 abbreviation. Note3: The fields should be distinguished by the space 195 character. 197 The field of [message name/operation name/port] can have many 198 choices, such as "Get/Post/SYN/ACK/Query/Memcached"; The field of 199 [attack methods feature description field 1 or 2] can represent by 200 "Connection", "Fragment", "Amplification", "Reflection", "Misuse", 201 "BandWidth", or "Slow"; The field of [attack methods describe the 202 standard field] just have two choice, one is "Flood" and the other is 203 "Attack". 205 .......................................................................................... 206 |Protocol layer |Protocol|message name |attack methods |attack methods |attack methods| 207 | |Name |/operation name|feature field 1|feature field 2|describe the | 208 | | |/port | | |standard field| 209 .......................................................................................... 210 |Network_Layer | ICMP | ------ | ------ | ------ | Flood | 211 .......................................................................................... 212 |Transport_Layer | TCP | SYN | ------ | ------ | Flood | 213 .......................................................................................... 214 |Transport_Layer | UDP | Memcached | Reflection | Amplification | Flood | 215 .......................................................................................... 216 |Application_Layer| HTTP | GET | ------ | ------ | Flood | 217 .......................................................................................... 219 Figure 2: Attack Definition Example 221 The complete DDoS attack definition and the abbreviated definition 222 examples shown as bellow: 224 .......................................................................................... 225 | complete DDoS attack definition | abbreviated definition | 226 .......................................................................................... 227 |Network_Layer ICMP Flood | ICMP Flood | 228 .......................................................................................... 229 |Transport_Layer TCP SYN Flood | TCP SYN Flood | 230 .......................................................................................... 231 |Transport_Layer UDP Memcached Reflection Amplification Flood | UDP Memcached Flood | 232 .......................................................................................... 233 |Application_Layer HTTP GET Flood | HTTP GET Flood | 234 .......................................................................................... 236 Figure 3: Attack Definition and Abbreviated Definition Example 238 5. Security Considerations 240 TBD 242 6. IANA Considerations 244 TBD 246 7. Acknowledgement 248 TBD 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 260 RFC 7950, DOI 10.17487/RFC7950, August 2016, 261 . 263 8.2. Informative References 265 [I-D.ietf-dots-requirements] 266 Mortensen, A., K, R., and R. Moskowitz, "Distributed 267 Denial of Service (DDoS) Open Threat Signaling 268 Requirements", draft-ietf-dots-requirements-22 (work in 269 progress), March 2019. 271 [I-D.ietf-dots-signal-channel] 272 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 273 Teague, "Distributed Denial-of-Service Open Threat 274 Signaling (DOTS) Signal Channel Specification", draft- 275 ietf-dots-signal-channel-37 (work in progress), July 2019. 277 [I-D.ietf-dots-use-cases] 278 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 279 L., and K. Nishizuka, "Use cases for DDoS Open Threat 280 Signaling", draft-ietf-dots-use-cases-20 (work in 281 progress), September 2019. 283 Authors' Addresses 285 Meiling Chen 286 CMCC 287 32, Xuanwumen West 288 BeiJing , BeiJing 100053 289 China 291 Email: chenmeiling@chinamobile.com 293 Li Su 294 CMCC 295 32, Xuanwumen West 296 BeiJing 100053 297 China 299 Email: suli@chinamobile.com