idnits 2.17.00 (12 Aug 2021) /tmp/idnits17972/draft-xia-dots-extended-use-cases-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 date (June 27, 2015) is 2513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 357, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 367, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DOTS L. Xia 2 H. Song 3 Internet Draft Huawei 4 Intended status: Informational June 27, 2015 5 Expires: December 2015 7 The Extended DDoS Open Threat Signaling Use Cases 8 draft-xia-dots-extended-use-cases-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on December 27, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 (http://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 43 respect to this document. 45 Abstract 46 This draft proposes two extended use cases which illustrate more 47 scenarios and multiple ways of implementation within the existing 48 DOTS work scope. One is the data mining and SDN based centralized 49 Anti-DDoS use case, the other is the NFV based distributed DDoS 50 mitigation use case. 52 Table of Contents 54 1. Introduction ................................................ 2 55 1.1. Background ............................................. 2 56 2. Conventions used in this document ........................... 4 57 3. Data Mining and SDN Based Centralized DDoS Protection ....... 5 58 4. NFV Based Distributed DDoS Mitigation Use Case .............. 7 59 5. Security Considerations ..................................... 9 60 6. IANA Considerations ......................................... 9 61 7. References .................................................. 9 62 7.1. Normative References ................................... 9 63 7.2. Informative References ................................. 9 64 8. Acknowledgments ............................................. 9 66 1. Introduction 68 DDoS attacks are one of the largest threats to the Internet, and are 69 evolving very quickly whatever its volume size or complexity. The 70 DDoS attack victims include ISPs, enterprises, and websites. To 71 defend their network resource or services against DDoS attack, Anti- 72 DDoS solutions are needed. According to specific scenarios or 73 requirements, as well as the emerging new technologies such as cloud, 74 NFV and big data, various Anti-DDoS solutions exist in current 75 industry. 77 This document will present two use cases for a distributed Anti-DDOS 78 solution based on standard inter-system communications between the 79 components. These standards will permit a mix of "best of breed" 80 deployment. 82 1.1. Background 84 Current Anti-DDoS solution is to deploy a proprietary Anti-DDoS 85 system close to the protected site, or in the network, close to the 86 protected site. Anti-DDoS systems can be either one physical box or 87 a distributed system. The former application means that the 88 detection and mitigation modules are all located in the same box. In 89 comparison, the latter is a distributed system which includes 90 distributed devices responsible for detection (i.e., DPI), 91 mitigation (i.e., scrubbing) and central control respectively. The 92 latter application is better in overall performance and deployment 93 flexibility. To meet the various requirements, the Anti-DDoS system 94 is deployed in various locations in a network. For example, it is 95 deployed near the protected sites for easily detecting application- 96 layer attacks, or near to the attack source to mitigate attacking 97 traffic as soon as possible and prevent them flooding into the 98 network. 100 Due to the challenges of high volume and complexity brought by 101 today's DDoS attacks, the cloud-based Anti-DDoS service is becoming 102 attractive and adopted by more and more customers. By this way, all 103 of the customer's traffic is monitored and scrubbed by the Anti-DDoS 104 service provider in real time, and the customer can manage its own 105 Anti-DDoS service and get the related information through the web- 106 based customer portal. This type of service has the benefits of high 107 performance and scalability. 109 On the other hand, Network Function Virtualization (NFV) is 110 considered as a promising technology used by network operators for 111 its great benefits such as saving cost and speeding up new service's 112 provision. Specifically, for the Anti-DDoS service provided by 113 network operators, they can dynamically create the Anti-DDoS Virtual 114 Network Functions (VNFs) and deploy them to the appropriate 115 locations in the network (i.e., near to the attack source or 116 destination, or both) as needed, because they have the information 117 and control of the whole network. The network operators have the 118 inherent advantage comparing with the third-party Anti-DDoS service 119 providers in this aspect. 121 Furthermore, in addition to the detection by specific devices (e.g., 122 Deep Packet Inspection (DPI)), normal network forwarding devices 123 (e.g., router or switch) can also be involved in the DDoS attack 124 detection by collecting the L3/L4 flow information and sending them 125 to the centralized platform for analysis or data mining. It can be a 126 complimentary way to current DDoS detection mechanism, or an 127 independent detection method by itself. 129 During the last few years, the above technologies are in the process 130 of integration, aiming to develop a comprehensive distributed and 131 collaborative Anti-DDoS solution. One example is the hybrid solution 132 by combining the specified on-premise Anti-DDoS devices with cloud- 133 based Anti-DDoS service. The on-premise devices monitor all the 134 traffic of customer and effectively mitigate the application-layer 135 attacks. When attack size reaches customer-established thresholds, 136 mitigation can be moved to the cloud platform. The ultimate goal of 137 the integration is forming a full spectrum of Layer 3-7 defenses 138 both on-premise and in the cloud. For all the distributed and 139 collaborative Anti-DDoS solutions, the coordination among all the 140 member elements is necessary for managing them, as well as 141 collecting and correlating various information from them so as to 142 form a holistic network security view. 144 [I-D.draft-mglt-dots-use-cases] describes several DDoS Open Threat 145 Signaling (DOTS) use cases for communication across distributed 146 Anti-DDoS devices or between on-premise device and cloud platform. 147 Additionally, it also illustrates the benefits the DOTS work can 148 bring. 150 This draft proposes two new use cases which illustrate more 151 scenarios and multiple ways of implementation within the existing 152 DOTS work scope: 154 o Collect and correlate security related flow information from 155 network forwarding devices and proactively detect the DDoS attack 156 by centralized analysis or data mining; 158 o Dynamic and distributed Anti-DDoS solution by creating VNFs and 159 deploying them to the edge network on demand. 161 2. Conventions used in this document 163 DDoS - Distributed Denial of Service 165 DOTS - DDos Open Threat Signaling 167 SDN - Software Defined Network 169 NFV - Network Function Virtualization 171 DPI - Deep Packet Inspection 173 CAPEX - Capital Expenditure 175 IPFIX - IP Flow Information Export 177 ACL - Access Control List 179 PoP - Point of Presence 181 3. Data Mining and SDN Based Centralized DDoS Protection 183 With the development of big data and SDN/NFV technologies, new ways 184 of thinking of DDoS protection come along as well. A centralized 185 data mining and SDN-like control platform plays a key role for DDoS 186 protection in this use case. 188 The centralized platform collects L3/L4 flow information from normal 189 network forwarding devices (e.g., router or switch) in the whole 190 network, and then analyzes them with data mining technology to get 191 the holistic view of network DDoS threats leading to an easy DDoS 192 attack detection. Compared with traditional signature based solution, 193 data mining analysis focuses more on the behaviors and patterns of 194 the data flows other than the content of the packets. Multi- 195 dimension to ultra-high dimension models can be built to accurately 196 profile the data flows on-line, which allows detecting and even 197 predicting DDoS attacks in real-time. By this way, operators can 198 greatly reduce the Capital Expenditure (CAPEX), as complicated and 199 expensive detecting devices with Deep Packet Inspection (DPI) 200 functions will be no longer essential. Furthermore, in contrast to 201 dedicated Anti-DDoS devices, the data mining platform is highly 202 scalable without obvious performance limit (the data mining 203 functions can be executed on the elastic computing environment). And 204 it has self-adapting capability to proactively detect new mutations 205 of DDoS attacks. 207 This Anti-DDoS solution involves a large number of elements, i.e., 208 routers, switches, data mining platform, dedicated Anti-DDoS devices, 209 and etc, as well as frequent information exchange between them to 210 fulfill its essential functions, i.e., packet/flow sampling, traffic 211 diversion, sending security policies, and etc. All these elements 212 and related control processes can be integrated into the SDN-like 213 control architecture to improve the automation level so as to reduce 214 operational involvement in DDoS attack management. 216 +----------+2.Monitoring +--------------+ 5.DPI and Scrubbing 217 | SDN | Report | Data Mining | statistics information 218 |Controller<-------------+ Platform <-------------------+ 219 | | | | | 220 +--+-------+ +-----^--------+ | 221 | | | 222 |3.Policies of | | 223 | flow sampling, | | 224 | device security, |1.Flow Sampling | 225 | traffic redirection, | | 226 | source tracking, etc | | 227 ..V...........................|.......... | 228 . . 4. Traffic | 229 . +------+ +------+ +------+ . redirection +----+-----+ 230 . |Router| ... |Router| ... |Router| . and clean | Specified| 231 . | | | | | | <-------------> Anti-DDoS| 232 . +------+ +------+ +------+ . | Device | 233 . . +----------+ 234 . Network . 235 ......................................... 237 Figure 1. Data Mining and SDN Based Centralized Anti-DDoS Use Case 239 As illustrated in Figure 1, a data mining and SDN based centralized 240 Anti-DDoS solution forms a closed-loop control system which includes 241 the following steps: 243 1. Data mining platform monitors network traffics by big data 244 analysis algorithms based on received IP Flow Information Export 245 (IPFIX) packet sampling records, and it probably needs some 246 extensions to current IPFIX specification for security 247 requirements [I-D.draft-fu-ipfix-network-security]. 249 2. Data mining platform sends the monitoring report to the SDN 250 controller, which provides the inputs for SDN controller to take 251 next step actions. The report contains the information about the 252 detected DDoS attacks based on the data mining models taken by 253 the platform, the information could be the abnormal flows, the 254 suspicious DDoS attack sources or destinations. 256 3. Based on the monitoring reports input, the SDN controller can 257 control the network forwarding devices to perform various 258 operations, e.g., adjusting the IPFIX flow sampling policies, or 259 configuring device security policies such as rate-limiting or 260 Access Control List (ACL), or traffic redirection to specified 261 mitigation devices or tracking the attack sources and etc. 263 4. The suspicious traffic is identified and redirected to specified 264 Anti-DDoS devices for further inspection and cleaning, and then 265 clean traffic is transmit back to the network; 267 5. At last, the DPI and scrubbing statistics information created by 268 the specified Anti-DDoS devices are reported to the data mining 269 platform, which are used to help it to improve and derive further 270 security intelligence by self-learning mechanism. 272 4. NFV Based Distributed DDoS Mitigation Use Case 274 Previously, due to the deployment limit of physical DDoS mitigation 275 devices and the third-party Anti-DDoS service provider does not have 276 the control of the network infrastructure, the centralized 277 deployment of DDoS mitigation devices is more suitable than the 278 distributed deployment. The centralized way is not optimized in 279 saving network bandwidth, and is possible to make DDoS mitigation 280 devices to be the bottleneck. 282 Now, the distributed deployment of DDoS mitigation appliances to the 283 network edge is becoming feasible as NFV technologies grows quickly 284 and are widely adopted by network operators for managing network 285 infrastructure. By the way of dynamic deployment, the virtual DDoS 286 mitigation appliances (i.e., virtual FW, scrubbing center, etc) are 287 distributed at the network edges to relieve the performance and 288 network bandwidth consuming problems. 290 Generally, for the distributed Anti-DDoS solution, the DDoS 291 monitoring appliances should be closer to the attacked destination 292 for easy detection, and the DDoS mitigation appliances should be 293 closer to the attacking sources for saving network bandwidth. So, 294 the source tracking mechanism is an important part of the whole 295 solution. 297 ............... 298 . Virtual DDoS. 299 . Mitigation . 300 . Appliance . 301 ............... --------- 302 | //-- --\\ 303 3.Network | // +----------+ \\ 304 Edge |// |Anti-DDoS <---+ \\ 305 Depolyment| /Controller| |1.Monitoring 306 ---- || /+--+-----+-+ | Report 307 /// \\\ | | 2 | | | | 308 / \ | | / | |+----+-----+| +--------+ 309 | | | +V-V+ | || DDoS | | |Service | 310 | +---+-----+-+PoP| 2.Source 2|Monitoring+-+---+ | 311 | | | | +---+ Tracking ||appliance | | +--------+ 312 | ISP2| | | | |+----------+| 313 \ | / | | | | 314 \\\ |// | | | ISP1 | 315 ----| \ +-V-+ +V--+ / ............... 316 | \\ |PoP| |PoP<------------. Virtual DDoS. 317 +--+----+ \\ +-+-+ +--++ 3.Network . Mitigation . 318 | Bot | \\--| |--//Edge . Appliance . 319 |Network| +-------+ Deployment............... 320 +-------+ | | 321 | | 322 +-----+-+ +--+----+ 323 | Other | | Bot | 324 |Network| |Network| 325 +-------+ +-------+ 326 Figure 2. NFV Based Distributed DDoS Mitigation Use Case 328 Figure 2 illustrates the use case including the following steps: 330 1. DDoS monitoring appliance sends the monitoring report to the 331 Anti-DDoS controller, providing the inputs for next step actions; 333 2. Anti-DDoS controller performs the attacking source tracing 334 mechanism to locate the network edges (i.e., PoPs) needed to 335 deploy the virtual DDoS mitigation appliances; 337 3. ISP's NFV orchestration center dynamically deploys the virtual 338 DDoS mitigation appliances on the network edge to filter/clean 339 the attacking traffic. 341 5. Security Considerations 343 This specification talks about the use cases for anti-DDoS solutions, 344 which does not introduce any new security threats to the network. 345 However, if the anti-DDoS system could be hacked by attackers, then 346 it could be used for malicious purposes, such as protecting the 347 attacks, or generating new attacks. 349 6. IANA Considerations 351 There is no IANA consideration for this specification. 353 7. References 355 7.1. Normative References 357 [1] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 361 Syntax Specifications: ABNF", RFC 2234, Internet Mail 362 Consortium and Demon Internet Ltd., November 1997. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 368 Syntax Specifications: ABNF", RFC 2234, Internet Mail 369 Consortium and Demon Internet Ltd., November 1997. 371 7.2. Informative References 373 [I-D.draft-mglt-dots-use-cases] Migault, D., "DDos Open Threat 374 Signaling use cases", work in progress, April 2015. 376 [I-D.draft-fu-ipfix-network-security] Fu, T., Zhang, D., He, D., and 377 Xia, L., "IPFIX Information Elements for inspecting 378 network security issues", work in progress, April 2015. 380 8. Acknowledgments 382 This document was prepared using 2-Word-v2.0.template.dot. 384 Authors' Addresses 386 Liang Xia (Frank) 387 Huawei 388 101 Software Avenue, Yuhuatai District 389 Nanjing, Jiangsu 210012 390 China 392 Email: Frank.xialiang@huawei.com 394 Haibin Song 395 Huawei 396 101 Software Avenue, Yuhuatai District 397 Nanjing, Jiangsu 210012 398 China 400 Email: haibin.song@huawei.com