idnits 2.17.1 draft-hayashi-dots-telemetry-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 (March 2, 2020) is 1488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Target' is mentioned on line 264, but not defined == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-02 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) 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 Y. Hayashi 3 Internet-Draft NTT 4 Intended status: Informational M. Chen 5 Expires: September 3, 2020 CMCC 6 March 2, 2020 8 Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry 9 draft-hayashi-dots-telemetry-use-cases-00 11 Abstract 13 Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the 14 base DOTS protocols to assist the mitigator in using efficient DDoS- 15 attack-mitigation techniques in a network. This document presents 16 sample use cases for DOTS Telemetry: what components are deployed in 17 the network, how they cooperate, and what information is exchanged to 18 effectively use these techniques. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 3, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. DDoS Mitigation Based on Attack Traffic Bandwidth . . . . 3 58 3.1.1. Mitigating Attack Flow of Top-talker Preferentially . 3 59 3.1.2. Optimal DMS Selection for Mitigation . . . . . . . . 5 60 3.1.3. Best-path Selection for Redirection . . . . . . . . . 6 61 3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 8 62 3.2. DDoS Mitigation Based on Attack Type . . . . . . . . . . 9 63 3.2.1. Selecting Mitigation Technique . . . . . . . . . . . 9 64 3.3. Training Flow Collector Using Supervised Machine Learning 11 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 70 7.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Denial-of-Service (DDoS), attacks such as volumetric attacks and 76 resource-consumption attacks, are critical threats to be handled by 77 service providers. When such DDoS attacks occur, service providers 78 have to mitigate them immediately to protect or recover their 79 services. 81 Therefore, for service providers to immediately protect their network 82 services from DDoS attacks, DDoS mitigation needs to be automated. 83 To automate DDoS-attack mitigation, multi-vendor components involved 84 in DDoS-attack detection and mitigation should cooperate and support 85 standard interfaces to communicate. 87 DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time 88 signaling, threat-handling requests, and data filtering between the 89 multi-vendor elements 90 [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. 91 Furthermore, DOTS Telemetry enriches the DOTS protocols with various 92 telemetry attributes allowing optimal DDoS-attack mitigation 93 [I-D.ietf-dots-telemetry]. This document presents sample use cases 94 for DOTS Telemetry: what components are deployed in the network, how 95 they cooperate, and what information is exchanged to effectively use 96 attack-mitigation techniques. 98 2. Terminology 100 The readers should be familiar with the terms defined in [RFC8612] 102 In addition, this document uses the following terms: 104 Top-talker: A top N list of attackers who attack the same target or 105 targets. The list is ordered in terms of a two-tuple bandwidth 106 such as bps or pps. 108 Supervised Machine Learning: A machine-learning technique that maps 109 an input to an output based on example input-output pairs 111 3. Use Cases 113 This section describes DOTS-Telemetry use cases that use attributes 114 included in DOTS Telemetry specifications. 116 3.1. DDoS Mitigation Based on Attack Traffic Bandwidth 118 3.1.1. Mitigating Attack Flow of Top-talker Preferentially 120 Large-scale DDoS attacks, such as amplification attacks, often occur. 121 Some transit providers have to mitigate large-scale DDoS attacks 122 using DMS with limited resources, which is already deployed in their 123 network. 125 The aim of this use case is to enable transit providers to use their 126 DMS efficiently under volume-based DDoS attacks whose bandwidth is 127 more than the available capacity of the DMS. To enable this, attack 128 traffic of top talkers is redirected to the DMS preferentially by 129 cooperation among forwarding nodes, flow collectors, and 130 orchestrators. Figure 1 gives an overview of this use case. 132 (Internet Transit Provider) 134 +-----------+ +--------------+ e.g., SNMP 135 e.g., IPFIX +-----------+| DOTS | |<--- 136 --->| Flow ||C<-->S| Orchestrator | e.g., BGP Flowspec 137 | collector |+ | |---> (Redirect) 138 +-----------+ +--------------+ 140 +-------------+ 141 e.g., IPFIX +-------------+| e.g., BGP Flowspec 142 <---| Forwarding ||<--- (Redirect) 143 | nodes || 144 | || DDoS Attack 145 [ Target ]<============|=============================== 146 [ or ] | ++=========================[top talker] 147 [ Targets ] | || ++======================[top talker] 148 +----|| ||---+ 149 || || 150 || || 151 |/ |/ 152 +----x--x----+ 153 | DDoS | e.g., SNMP 154 | mitigation |<--- 155 | system | 156 +------------+ 158 * C is for DOTS client functionality 159 * S is for DOTS client functionality 161 Figure 1: Mitigating DDoS Attack Flow of Top-talker Preferentially 163 In this use case, the forwarding nodes always send statistics of 164 traffic flow to the flow collectors by using monitoring functions 165 such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors 166 detect attack traffic and send (src_ip, dst_ip, bandwidth)-tuple 167 information of the top talker to the orchestrator using the top- 168 talkers attribute of DOTS Telemetry. The orchestrator then checks 169 the available capacity of DMS by using a network management protocol 170 such as SNMP[RFC3413]. After that, the orchestrator orders 171 forwarding nodes to redirect as much of the top taker's traffic to 172 the DMS as possible by dissemination of flow-specification-rule 173 protocols such as BGP Flowspec[RFC5575]. 175 In this case, the flow collector implements a DOTS client while the 176 orchestrator implements a DOTS server. 178 3.1.2. Optimal DMS Selection for Mitigation 180 Transit providers, which have a number of DMSs, usually deploy a DMS 181 in various forms to satisfy their requirements; individual or 182 clustered. In both forms, they can identify attributes of the DMSs 183 such as total capacity, available capacity, and the last hop 184 bandwidth. 186 The aim of this use case is to enable transit providers to select an 187 optimal DMS for mitigation based on the bandwidth of attack traffic, 188 capacity of a DMS, and the last hop bandwidth. Figure 2 gives an 189 overview of this use case. 191 (Internet Transit Provider) 193 +-----------+ +--------------+ e.g., SNMP 194 e.g., IPFIX +-----------+| DOTS | |<--- 195 --->| Flow ||C<-->S| Orchestrator | e.g., BGP 196 | collector |+ | |---> (Redirect) 197 +-----------+ +--------------+ 199 +------------+ 200 e.g., IPFIX +------------+| e.g., BGP 201 <---| Forwarding ||<--- (Redirect) 202 | nodes || 203 | || DDoS Attack 204 [Target] | ++============================ 205 [Target] | || ++======================== 206 +-||--||-----+ 207 || || 208 ++====++ || (congested DMS) 209 || || +-----------+ 210 || |/ | DMS3 | 211 || +-----x------+ |<--- e.g., SNMP 212 |/ | DMS2 |--------+ 213 +--x---------+ |<--- e.g., SNMP 214 | DMS1 |------+ 215 | |<--- e.g., SNMP 216 +------------+ 218 * C is for DOTS client functionality 219 * S is for DOTS client functionality 221 Figure 2: Optimal DMS selection for Mitigation 223 In this use case, the forwarding nodes always send statistics of 224 traffic flow to the flow collectors by using monitoring functions 225 such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors 226 detect attack traffic and send (dst_ip, bandwidth)-tuple information 227 to the orchestrator using the total-attack-traffic attribute of DOTS 228 Telemetry. The orchestrator then checks the available capacity of 229 the DMSs by using a network management protocol such as 230 SNMP[RFC3413]. After that, the orchestrator chooses optimal DMS 231 which each attack traffic should be redirected. The orchestrator 232 then orders forwarding nodes to redirect the attack traffic to the 233 optimal DMS by a routing protocol such as BGP[RFC4271]. The 234 algorithm of selecting a DMS is out of the scope of this draft. 236 In this case, the flow collector implements a DOTS client while the 237 orchestrator implements a DOTS server. 239 3.1.3. Best-path Selection for Redirection 241 A transit-provider network, which adopts a mesh network, has multiple 242 paths to convey attack traffic to a DMS. In this network, attack 243 traffic can be conveyed while avoiding congested links by selecting 244 an available path. 246 The aim of this use case is to enable transit providers to select an 247 optimal path for redirecting attack traffic to a DMS according to the 248 bandwidth of the attack traffic, total traffic, and total pipe 249 capability. Figure 3 gives an overview of this use case. 251 (Internet Transit Provider) 253 +-----------+ +--------------+ DOTS 254 e.g., +-----------+| | |S<--- 255 IPFIX | Flow || DOTS | Orchestrator | 256 -->| collector ||C<-->S| | e.g., BGP Flow spec 257 | |+ | |---> (Redirect) 258 +-----------+ +--------------+ 260 DOTS +------------+ DOTS +------------+ e.g., IPFIX 261 --->C| Forwarding | --->C| Forwarding |---> 262 e.g., BGP Flow spec | node | | node | 263 (Redirect) --->| | | | DDoS Attack 264 [Target] | ++==================================== 265 +-------||---+ +------------+ 266 || / 267 || / (congested link) 268 || / 269 DOTS +-||----------------+ e.g., BGP Flow spec 270 --->C| || Forwarding |<--- (Redirect) 271 | ++=== node | 272 +----||-------------+ 273 |/ 274 +--x-----------+ 275 | DMS | 276 +--------------+ 278 * C is for DOTS client functionality 279 * S is for DOTS client functionality 281 Figure 3: Best-path Selection for Redirection 283 In this use case, the forwarding nodes always send statistics of 284 traffic flow to the flow collectors by using monitoring functions 285 such as IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors 286 detect attack traffic and send (dst_ip, bandwidth)-tuple information 287 to the orchestrator using a total-attack-traffic attribute of DOTS 288 Telemetry. On the other hands, forwarding nodes send bandwidth of 289 total traffic passing the node and total pipe capability to the 290 orchestrator using total-traffic and total-pipe-capability attributes 291 of DOTS Telemetry. The orchestrator then selects an optimal path to 292 which each attack-traffic flow should be redirected. After that, the 293 orchestrator orders forwarding nodes to redirect the attack traffic 294 to the optimal DMS by dissemination of flow-specification-rules 295 protocols such as BGP Flowspec[RFC5575]. The algorithm of selecting 296 a path is out of the scope of this draft. 298 3.1.4. Short but Extreme Volumetric Attack Mitigation 300 Short but extreme volumetric attacks, such as pulse wave DDoS 301 attacks, are threats to internet transit provider networks. It is 302 difficult for them to mitigate an attack by DMS by redirecting attack 303 flows because it may cause route flapping in the network. The 304 practical way to mitigate short but extreme volumetric attacks is to 305 offload a mitigation actions to a forwarding node. 307 The aim of this use case is to enable transit providers to mitigate 308 short but extreme volumetric attacks and estimate the network-access 309 success rate based on the bandwidth of attack traffic and total pipe 310 capability. Figure 4 gives an overview of this use case. 312 (Internet Transit Provider) 314 +------------+ +----------------+ 315 e.g., | Network | DOTS | Administrative | 316 Alert --->| Management |C<--->S| System | e.g., BGP Flow spec 317 | System | | |---> (Rate-Limit) 318 +------------+ +----------------+ 320 +------------+ +------------+ e.g., BGP Flow spec 321 | Forwarding | | Forwarding |<--- (Rate-Limit X bps) 322 | node | | node | 323 | | | | DDoS & Normal traffic 324 [Target]<------------------------------------================ 325 Pipe +------------+ +------------+ Attack Traffic 326 Capability Bandwidth 327 e.g., X bps e.g., Y bps 329 Network access success rate 330 e.g., X / (X + Y) 332 * C is for DOTS client functionality 333 * S is for DOTS client functionality 335 Figure 4: Short but Extreme Volumetric Attack Mitigation 337 In this use case, when DDoS attacks occur, the network management 338 system receives alerts. It then sends the target ip address, pipe 339 capability of the target's link, and bandwidth of the DDoS attack 340 traffic to the administrative system using the target, total-pipe- 341 capability and total-attack-traffic attributes of DOTS Telemetry. 342 After that, the administrative system orders upper forwarding nodes 343 to carry out rate-limit all traffic destined to the target based on 344 the pipe capability by the dissemination of the flow -specification- 345 rules protocols such as BGP Flowspec[RFC5575]. In addition, the 346 administrative system estimates the network-access success rate of 347 the target, which is calculated by total pipe capability / (total 348 pipe capability + total attack traffic). 350 3.2. DDoS Mitigation Based on Attack Type 352 3.2.1. Selecting Mitigation Technique 354 Some volumetric attacks, such as amplification attacks, can be 355 detected with high accuracy by checking the layer-3 or layer-4 356 information of attack packets. These attacks can be detected and 357 mitigated through cooperation among forwarding nodes and flow 358 collectors using IPFIX[RFC7011]. On the other hand, it is necessary 359 to inspect the layer-7 information of attack packets to detect 360 attacks such as DNS Water Torture Attacks. Such attack traffic 361 should be detected and mitigated at a DMS. 363 The aim of this use case is to enable transit providers to select a 364 mitigation technique based on the type of attack traffic: 365 amplification attack or not. To use such a technique, attack traffic 366 is blocked at forwarding nodes or redirected to a DMS based on attack 367 type through cooperation among forwarding nodes, flow collectors, and 368 an orchestrator. Figure 5 gives an overview of this use case. 370 (Internet Transit Provider) 372 +-----------+ DOTS +--------------+ e.g., 373 e.g., +-----------+|<---->| | BGP (Redirect) 374 IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) 375 --->| collector |+ | |---> 376 +-----------+ +--------------+ 378 +------------+ e.g., BGP (Redirect) 379 e.g., IPFIX +------------+| BGP Flowspec (Drop) 380 <---| Forwarding ||<--- 381 | nodes || DDoS Attack 382 | ++=====||================ 383 | || ||x<==============[e.g.,DNS Amp] 384 | || |+x<==============[e.g.,NTP Amp] 385 +-----||-----+ 386 || 387 |/ 388 +-----x------+ 389 | DDoS | 390 | mitigation | 391 | system | 392 +------------+ 394 * C is for DOTS client functionality 395 * S is for DOTS server functionality 397 Figure 5: DDoS Mitigation Based on Attack Type 399 In this use case, the forwarding nodes send statistics of traffic 400 flow to the flow collectors by using a monitoring function such as 401 IPFIX[RFC7011]. When DDoS attacks occur, the flow collectors detect 402 attack traffic and send (dst_ip, src_port, attack_type)-tuple 403 information to the orchestrator the using attack-name attribute of 404 DOTS Telemetry. The orchestrator then orders forwarding nodes to 405 block the (dst_ip, src_port)-tuple flow of amp attack traffic by 406 dissemination of flow-specification-rule protocols such as BGP 407 Flowspec[RFC5575]. On the other hand, the orchestrator orders 408 forwarding nodes to redirect other traffic than the amp attack 409 traffic by a routing protocol such as BGP[RFC4271]. 411 In this case, the flow collector implements a DOTS client while the 412 orchestrator implements a DOTS server. 414 3.3. Training Flow Collector Using Supervised Machine Learning 416 DDoS detection based on monitoring functions, such as IPFIX[RFC7011], 417 is a lighter weight method of detecting DDoS attacks than DMSs in 418 internet transit provider networks. On the other hand, DDoS 419 detection based on the DMSs is a more accurate method of detecting 420 DDoS attacks than DDoS detection based on flow monitoring. 422 The aim of this use case is to increases flow collector's detection 423 accuracy by carrying out supervised machine-learning techniques based 424 on the detection results of the DMSs. To use such a technique, 425 forwarding nodes, flow collector, and a DMS should cooperate. 426 Figure 5 gives an overview of this use case. 428 +-----------+ 429 +-----------+| DOTS 430 e.g., IPFIX | Flow ||S<--- 431 --->| collector || 432 +-----------++ 434 +------------+ 435 e.g., IPFIX +------------+| 436 <---| Forwarding || 437 | nodes || DDoS Attack 438 [ Target ] | ++============================== 439 | || ++=========================== 440 | || || ++======================== 441 +---||-|| ||-+ 442 || || || 443 |/ |/ |/ 444 DOTS +---X--X--X--+ 445 --->C| DDoS | 446 | mitigation | 447 | system | 448 +------------+ 450 * C is for DOTS client functionality 451 * S is for DOTS client functionality 453 Figure 6: Training Flow Collector Using Supervised Machine Learning 455 In this use case, the forwarding nodes always send statistics of 456 traffic flow to the flow collectors by using monitoring functions 457 such as IPFIX[RFC7011]. When DDoS attacks occur, DDoS orchestration 458 use case[I-D.ietf-dots-use-cases] is carried out and the DMS 459 mitigates all attack traffic destined for a target. The DDoS- 460 mitigation system reports the (src_ip, dst_ip)-tuple information of 461 the top talker to the orchestrator the using top-talkers attribute of 462 DOTS Telemetry. 464 After mitigating a DDoS attack, the flow collector attaches teacher 465 labels to the statistics of traffic flow based on the reports. The 466 label shows normal traffic or attack name. The flow collector then 467 carries out supervised machine learning to increase its detection 468 accuracy, setting the statistics as an explanatory variable and 469 setting the labels as an objective variable. 471 In this case, the DMS implements a DOTS client while the flow 472 collector implements a DOTS server. 474 4. Security Considerations 476 TBD 478 5. IANA Considerations 480 This document does not require any action from IANA. 482 6. Acknowledgement 484 The authors would like to thank among others brabra... 486 7. References 488 7.1. Normative References 490 [I-D.ietf-dots-telemetry] 491 Boucadair, M., Reddy.K, T., Doron, E., and c. chenmeiling, 492 "Distributed Denial-of-Service Open Threat Signaling 493 (DOTS) Telemetry", draft-ietf-dots-telemetry-02 (work in 494 progress), February 2020. 496 [I-D.ietf-dots-use-cases] 497 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 498 L., and K. Nishizuka, "Use cases for DDoS Open Threat 499 Signaling", draft-ietf-dots-use-cases-20 (work in 500 progress), September 2019. 502 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 503 Management Protocol (SNMP) Applications", STD 62, 504 RFC 3413, DOI 10.17487/RFC3413, December 2002, 505 . 507 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 508 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 509 DOI 10.17487/RFC4271, January 2006, 510 . 512 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 513 and D. McPherson, "Dissemination of Flow Specification 514 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 515 . 517 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 518 "Specification of the IP Flow Information Export (IPFIX) 519 Protocol for the Exchange of Flow Information", STD 77, 520 RFC 7011, DOI 10.17487/RFC7011, September 2013, 521 . 523 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 524 Threat Signaling (DOTS) Requirements", RFC 8612, 525 DOI 10.17487/RFC8612, May 2019, 526 . 528 7.2. Informative References 530 [I-D.ietf-dots-data-channel] 531 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 532 Service Open Threat Signaling (DOTS) Data Channel 533 Specification", draft-ietf-dots-data-channel-31 (work in 534 progress), July 2019. 536 [I-D.ietf-dots-signal-channel] 537 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 538 N. Teague, "Distributed Denial-of-Service Open Threat 539 Signaling (DOTS) Signal Channel Specification", draft- 540 ietf-dots-signal-channel-41 (work in progress), January 541 2020. 543 Authors' Addresses 545 Yuhei Hayashi 546 NTT 547 3-9-11, Midori-cho 548 Musashino-shi, Tokyo 180-8585 549 Japan 551 Email: yuuhei.hayashi@gmail.com 552 Meiling Chen 553 CMCC 554 32, Xuanwumen West 555 BeiJing, BeiJing 100053 556 China 558 Email: 559 chenmeiling@chinamobile.com