idnits 2.17.1 draft-ietf-dots-telemetry-use-cases-10.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 (2 April 2022) is 755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Target' is mentioned on line 362, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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: 4 October 2022 Li. Su 6 CMCC 7 2 April 2022 9 Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry 10 draft-ietf-dots-telemetry-use-cases-10 12 Abstract 14 DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS 15 protocols to assist the mitigator in using efficient DDoS attack 16 mitigation techniques in a network. This document presents sample 17 use cases for DOTS Telemetry. It discusses in particular what 18 components are deployed in the network, how they cooperate, and what 19 information is exchanged to effectively use these techniques. 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 4 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Telemetry Use Cases . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Mitigation Resources Assignment . . . . . . . . . . . . . 3 58 3.1.1. Mitigating Attack Flow of Top-talker 59 Preferentially . . . . . . . . . . . . . . . . . . . 3 60 3.1.2. Optimal DMS Selection for Mitigation . . . . . . . . 6 61 3.1.3. Best-path Selection for Redirection . . . . . . . . . 9 62 3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 11 63 3.1.5. Selecting Mitigation Technique Based on Attack 64 Type . . . . . . . . . . . . . . . . . . . . . . . . 14 65 3.2. Detailed DDoS Mitigation Report . . . . . . . . . . . . . 18 66 3.3. Tuning Mitigation Resources . . . . . . . . . . . . . . . 21 67 3.3.1. Supervised Machine Learning of Flow Collector . . . . 21 68 3.3.2. Unsupervised Machine Learning of Flow Collector . . . 24 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 71 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 74 7.2. Informative References . . . . . . . . . . . . . . . . . 26 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 77 1. Introduction 79 Distributed Denial-of-Service (DDoS) attacks, such as volumetric 80 attacks and resource-consumption attacks, are critical threats to be 81 handled by service providers. When such DDoS attacks occur, service 82 providers have to mitigate them immediately to protect or recover 83 their services. 85 Therefore, for service providers to immediately protect their network 86 services from DDoS attacks, DDoS mitigation needs to be highly 87 automated. To that aim, multi-vendor components involved in DDoS 88 attack detection and mitigation should cooperate and support standard 89 interfaces. 91 DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time 92 signaling, threat-handling requests, and data filtering between the 93 multi-vendor elements [RFC9132][RFC8783]. DOTS Telemetry enriches 94 the DOTS protocols with various telemetry attributes allowing optimal 95 DDoS attack mitigation [I-D.ietf-dots-telemetry]. This document 96 presents sample use cases for DOTS Telemetry, which makes concrete 97 overview and purpose described in [I-D.ietf-dots-telemetry]: what 98 components are deployed in the network, how they cooperate, and what 99 information is exchanged to effectively use attack-mitigation 100 techniques. 102 2. Terminology 104 The readers should be familiar with the terms defined in [RFC8612], 105 [RFC8903] and [I-D.ietf-dots-telemetry]. 107 In addition, this document uses the following terms: 109 Top-talker: A list of attack sources that are involved in an attack 110 and which are generating an important part of the attack traffic. 112 Supervised Machine Learning: A machine-learning technique in which 113 labeled data is used to train the algorithms (the input and output 114 data are known). 116 Unsupervised Machine Learning: A machine learning technique in which 117 unlabeled data is used to train the algorithms (the data has no 118 historical labels). 120 3. Telemetry Use Cases 122 This section describes DOTS telemetry use cases that use attributes 123 included in DOTS telemetry specifications [I-D.ietf-dots-telemetry]. 125 3.1. Mitigation Resources Assignment 127 3.1.1. Mitigating Attack Flow of Top-talker Preferentially 129 Some transit providers have to mitigate such large-scale DDoS attacks 130 by using DDoS Mitigation Systems (DMSes) with limited resources, 131 which is already deployed in their network. For example, recent 132 reported large DDoS attacks exceeded 1 Tps. 134 The aim of this use case is to enable transit providers to use their 135 DMS efficiently under volume-based DDoS attacks whose volume is more 136 than the available capacity of the DMS. To enable this, the attack 137 traffic of top-talkers is redirected to the DMS preferentially by 138 cooperation among forwarding nodes, flow collectors, and 139 orchestrators. 141 Figure 1 gives an overview of this use case. Figure 2 provides an 142 example of a DOTS telemetry message body that is used to signal top- 143 talkers (2001:db8::2/128 and 2001:db8::3/128). 145 (Internet Transit Provider) 147 +-----------+ +--------------+ e.g., SNMP 148 e.g., IPFIX +-----------+| DOTS | |<--- 149 --->| Flow ||C<-->S| Orchestrator | e.g., BGP Flowspec 150 | collector |+ | |---> (Redirect) 151 +-----------+ +--------------+ 153 +-------------+ 154 e.g., IPFIX +-------------+| e.g., BGP Flowspec 155 <---| Forwarding ||<--- (Redirect) 156 | nodes || 157 | || DDoS Attack 158 [ Target ]<============|=============================== 159 [ or ] | ++=========================[top-talker] 160 [ Targets ] | || ++======================[top-talker] 161 +----|| ||---+ 162 || || 163 || || 164 |/ |/ 165 +----x--x----+ 166 | DDoS | e.g., SNMP 167 | mitigation |<--- 168 | system | 169 +------------+ 171 * C is for DOTS client functionality 172 * S is for DOTS server functionality 174 Figure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially 175 { 176 "ietf-dots-telemetry:telemetry": { 177 "pre-or-ongoing-mitigation": [ 178 { 179 "target": { 180 "target-prefix": [ 181 "2001:db8::1/128" 182 ] 183 }, 184 "total-attack-traffic-protocol": [ 185 { 186 "protocol": 17, 187 "unit": "megabit-ps", 188 "mid-percentile-g": "900" 189 } 190 ], 191 "attack-detail": [ 192 { 193 "vendor-id": 32473, 194 "attack-id": 77, 195 "start-time": "1645057211", 196 "attack-severity": "high", 197 "top-talker":{ 198 "talker": [ 199 { 200 "source-prefix": "2001:db8::2/128", 201 "total-attack-traffic": [ 202 { 203 "unit": "megabit-ps", 204 "mid-percentile-g": "100" 205 } 206 ] 207 }, 208 { 209 "source-prefix": "2001:db8::3/128", 210 "total-attack-traffic": [ 211 { 212 "unit": "megabit-ps", 213 "mid-percentile-g": "90" 214 } 215 ] 216 } 217 ] 218 } 219 } 220 ] 221 } 222 ] 224 } 225 } 227 Figure 2: An Example of Message Body to Signal Top-Talkers 229 The forwarding nodes send traffic statistics to the flow collectors 230 using, e.g., IP Flow Information Export (IPFIX) [RFC7011]. When DDoS 231 attacks occur, the flow collectors identifies the attack traffic and 232 send information of the top-talkers to the orchestrator using the 233 "target-prefix" and "top-talkers" DOTS telemetry attributes. The 234 orchestrator, then, checks the available capacity of the DMSes by 235 using a network management protocol, such as Simple Network 236 Management Protocol (SNMP) [RFC3413]. After that, the orchestrator 237 orders the forwarding nodes to redirect as much of the top-talker's 238 traffic to the DMS as possible by dissemination of Flow 239 Specifications relying upon tools, such as Border Gateway Protocol 240 Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. 242 The flow collector implements a DOTS client while the orchestrator 243 implements a DOTS server. 245 3.1.2. Optimal DMS Selection for Mitigation 247 Transit providers can deploy their DMSes in clusters. Then, they can 248 select the DMS to be used to mitigate a DDoS attack under attack 249 time. 251 The aim of this use case is to enable transit providers to select an 252 optimal DMS for mitigation based on the volume of the attack traffic 253 and the capacity of a DMS. Figure 3 gives an overview of this use 254 case. Figure 4 provides an example of a DOTS telemetry message body 255 that is used to signal various attack traffic percentiles. 257 (Internet Transit Provider) 259 +-----------+ +--------------+ e.g., SNMP 260 e.g., IPFIX +-----------+| DOTS | |<--- 261 --->| Flow ||C<-->S| Orchestrator | e.g., BGP 262 | collector |+ | |---> (Redirect) 263 +-----------+ +--------------+ 265 +------------+ 266 e.g., IPFIX +------------+| e.g., BGP 267 <---| Forwarding ||<--- (Redirect) 268 | nodes || 269 | || DDoS Attack 270 [Target] | ++============================ 271 [Target] | || ++======================== 272 +-||--||-----+ 273 || || 274 ++====++ || (congested DMS) 275 || || +-----------+ 276 || |/ | DMS3 | 277 || +-----x------+ |<--- e.g., SNMP 278 |/ | DMS2 |--------+ 279 +--x---------+ |<--- e.g., SNMP 280 | DMS1 |------+ 281 | |<--- e.g., SNMP 282 +------------+ 284 * C is for DOTS client functionality 285 * S is for DOTS server functionality 287 Figure 3: Optimal DMS Selection for Mitigation 288 { 289 "ietf-dots-telemetry:telemetry": { 290 "pre-or-ongoing-mitigation": [ 291 { 292 "target": { 293 "target-prefix": [ 294 "2001:db8::1/128" 295 ] 296 }, 297 "total-attack-traffic": [ 298 { 299 "unit": "megabit-ps", 300 "low-percentile-g": "600", 301 "mid-percentile-g": "800", 302 "high-percentile-g": "1000", 303 "peak-g":"1100", 304 "current-g":"700" 305 } 306 ] 307 } 308 ] 309 } 310 } 312 Figure 4: Example of Message Body with Total Attack Traffic 314 The forwarding nodes send traffic statistics to the flow collectors 315 using, e.g., IPFIX. When DDoS attacks occur, the flow collectors 316 identify the attack traffic and send information of the attack 317 traffic volume to the orchestrator by using the "target-prefix" and 318 "total-attack-traffic" DOTS telemetry attributes. The orchestrator, 319 then, checks the available capacity of the DMSes by using a network 320 management protocol, such as SNMP. After that, the orchestrator 321 selects an optimal DMS to which each attack traffic should be 322 redirected. For example, a simple DMS selection algorithm is to 323 choose a DMS whose available capacity is greater than the "peak-g" 324 atribute indicated in the DOTS telemetry message. The orchestrator 325 orders the appropriate forwarding nodes to redirect the attack 326 traffic to the optimal DMS relying upon routing policies, such as BGP 327 [RFC4271]. 329 The detailed DMS selection algorithm is out of the scope of this 330 document. 332 The flow collector implements a DOTS client while the orchestrator 333 implements a DOTS server. 335 3.1.3. Best-path Selection for Redirection 337 A transit provider network has multiple paths to convey an attack 338 traffic to a DMS. In such a network, the attack traffic can be 339 conveyed while avoiding congested links by adequately selecting an 340 available path. 342 The aim of this use case is to enable transit providers to select an 343 optimal path for redirecting attack traffic to a DMS according to the 344 bandwidth of the attack traffic and total traffic. Figure 5 gives an 345 overview of this use case. Figure 6 provides an example of a DOTS 346 telemetry message body that is used to signal various attack traffic 347 percentiles and total traffic percentiles. 349 (Internet Transit Provider) 351 +-----------+ +--------------+ DOTS 352 e.g., +-----------+| | |S<--- 353 IPFIX | Flow || DOTS | Orchestrator | 354 -->| collector ||C<-->S| | e.g., BGP Flowspec 355 | |+ | |---> (Redirect) 356 +-----------+ +--------------+ 358 DOTS +------------+ DOTS +------------+ e.g., IPFIX 359 --->C| Forwarding | --->C| Forwarding |---> 360 e.g., BGP Flowspec | node | | node | 361 (Redirect) --->| | | | DDoS Attack 362 [Target] | ++==================================== 363 +-------||---+ +------------+ 364 || / 365 || / (congested link) 366 || / 367 DOTS +-||----------------+ e.g., BGP Flowspec 368 --->C| || Forwarding |<--- (Redirect) 369 | ++=== node | 370 +----||-------------+ 371 |/ 372 +--x-----------+ 373 | DMS | 374 +--------------+ 376 * C is for DOTS client functionality 377 * S is for DOTS server functionality 379 Figure 5: Best-path Selection for Redirection 380 { 381 "ietf-dots-telemetry:telemetry": { 382 "pre-or-ongoing-mitigation": [ 383 { 384 "target": { 385 "target-prefix": [ 386 "2001:db8::1/128" 387 ] 388 }, 389 "total-traffic": [ 390 { 391 "unit": "megabit-ps", 392 "mid-percentile-g": "1300", 393 "peak-g": "800" 394 } 395 ], 396 "total-attack-traffic": [ 397 { 398 "unit": "megabit-ps", 399 "low-percentile-g": "600", 400 "mid-percentile-g": "800", 401 "high-percentile-g": "1000", 402 "peak-g": "1100", 403 "current-g": "700" 404 } 405 ] 406 } 407 ] 408 } 409 } 411 Figure 6: An Example of Message Body with Total Attack 412 Traffic and Total Traffic 414 The forwarding nodes send traffic statistics to the flow collectors 415 by using, e.g., IPFIX. When DDoS attacks occur, the flow collectors 416 identify attack traffic and send information of the attack traffic 417 volume to the orchestrator by using a "target-prefix" and "total- 418 attack-traffic" DOTS telemetry attributes. On the other hands, the 419 underlying forwarding nodes send volume of the total traffic passing 420 the node to the orchestrator by using "total-traffic" telemetry 421 attributes. The orchestrator then selects an optimal path to which 422 each attack-traffic flow should be redirected. For example, the 423 simple algorithm of the selection is to choose a path whose available 424 capacity is greater than the "peak-g" attribute that was indicated in 425 a DOTS telemetry message. After that, the orchestrator orders the 426 appropriate forwarding nodes to redirect the attack traffic to the 427 optimal DMS by dissemination of Flow Specifications relying upon 428 tools, such as BGP Flowspec. 430 The detailed path selection algorithm is out of the scope of this 431 document. 433 The flow collector and forwarding nodes implement a DOTS client while 434 the orchestrator implements a DOTS server. 436 3.1.4. Short but Extreme Volumetric Attack Mitigation 438 Short, but extreme volumetric attacks, such as pulse wave DDoS 439 attacks, are threats to internet transit provider networks. The 440 feature of the attack is that start from zero and go to maximum 441 values in a very short time span, then go back to zero, and back to 442 maximum, repeating in continuous cycles at short intervals. It is 443 difficult for them to mitigate an attack by DMS by redirecting attack 444 flows because it may cause route flapping in the network. The 445 practical way to mitigate short but extreme volumetric attacks is to 446 offload mitigation actions to a forwarding node. 448 The aim of this use case is to enable transit providers to mitigate 449 short but extreme volumetric attacks. Furthermore, the aim is to 450 estimate the network-access success rate based on the bandwidth of 451 attack traffic. Figure 7 gives an overview of this use case. 452 Figure 8 provides an example of a DOTS telemetry message body that is 453 used to signal total pipe capacity. Figure 9 provides an example of 454 a DOTS telemetry message body that is used to signal various attack 455 traffic percentiles and total traffic percentiles. 457 (Internet Transit Provider) 459 +------------+ +----------------+ 460 e.g., | Network | DOTS | Administrative | 461 Alert ----->| Management |C<--->S| System | e.g., BGP Flowspec 462 | System | | |---> (Rate-Limit) 463 +------------+ +----------------+ 465 +------------+ +------------+ e.g., BGP Flowspec 466 | Forwarding | | Forwarding |<--- (Rate-Limit X bps) 467 | node | | node | 468 Link1 | | | | DDoS & Normal traffic 469 [Target]<------------------------------------================ 470 Pipe +------------+ +------------+ Attack Traffic 471 Capability Bandwidth 472 e.g., X bps e.g., Y bps 474 Network access success rate 475 e.g., X / (X + Y) 477 * C is for DOTS client functionality 478 * S is for DOTS server functionality 480 Figure 7: Short but Extreme Volumetric Attack Mitigation 482 { 483 "ietf-dots-telemetry:telemetry-setup": { 484 "telemetry": [ 485 { 486 "total-pipe-capacity": [ 487 { 488 "link-id": "link1", 489 "capacity": "1000", 490 "unit": "megabit-ps" 491 } 492 ] 493 } 494 ] 495 } 496 } 497 Figure 8: Example of Message Body with Total Pipe Capacity 498 { 499 "ietf-dots-telemetry:telemetry": { 500 "pre-or-ongoing-mitigation": [ 501 { 502 "target": { 503 "target-prefix": [ 504 "2001:db8::1/128" 505 ] 506 }, 507 "total-traffic": [ 508 { 509 "unit": "megabit-ps", 510 "mid-percentile-g": "800", 511 "peak-g": "1300" 512 } 513 ], 514 "total-attack-traffic": [ 515 { 516 "unit": "megabit-ps", 517 "low-percentile-g": "200", 518 "mid-percentile-g": "400", 519 "high-percentile-g": "500", 520 "peak-g": "600", 521 "current-g": "400" 522 } 523 ] 524 } 525 ] 526 } 527 } 529 Figure 9: Example of Message Body with Total Attack Traffic, 530 and Total Traffic 532 When DDoS attacks occur, the network management system receives 533 alerts. Then, it sends the target IP address(es) and volume of the 534 DDoS attack traffic to the administrative system by using the 535 "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. 536 After that, the administrative system orders relevant forwarding 537 nodes to carry out rate-limit all traffic destined to the target 538 based on the pipe capability by the dissemination of the Flow 539 Specifications relying upon tools, such as BGP Flowspec. In 540 addition, the administrative system estimates the network-access 541 success rate of the target, which is calculated by (total-pipe- 542 capability / (total-pipe-capability + total-attack-traffic)). 544 Note that total pipe capability information can be gatherd by 545 telemetry setup in advance (Section 7.2 of 546 [I-D.ietf-dots-telemetry]). 548 The network management system implements a DOTS client while the 549 administrative system implements a DOTS server. 551 3.1.5. Selecting Mitigation Technique Based on Attack Type 553 Some volumetric attacks, such as amplification attacks, can be 554 detected with high accuracy by checking the Layer 3 or Layer 4 555 information of attack packets. These attacks can be detected and 556 mitigated through cooperation among forwarding nodes and flow 557 collectors by using IPFIX. It may also be necessary to inspect the 558 Layer 7 information of suspecious packets to detect attacks such as 559 DNS Water Torture Attacks. Such an attack traffic should be detected 560 and mitigated at a DMS. 562 The aim of this use case is to enable transit providers to select a 563 mitigation technique based on the type of attack traffic: 564 amplification attack or not. To use such a technique, the attack 565 traffic is blocked by forwarding nodes or redirected to a DMS based 566 on the attack type through cooperation among forwarding nodes, flow 567 collectors, and an orchestrator. 569 Figure 10 gives an overview of this use case. Figure 11 provides an 570 example of attack mappings as below are shared by using the DOTS data 571 channel in advance. Figure 12 provides an example of a DOTS 572 telemetry message body that is used to signal various attack traffic 573 percentiles, total traffic percentiles, total attack connection and 574 attack type. 576 The example in Figure 11 uses the folding defined in [RFC8792] for 577 long lines. 579 (Internet Transit Provider) 581 +-----------+ DOTS +--------------+ e.g., 582 e.g., +-----------+|<---->| | BGP (Redirect) 583 IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) 584 --->| collector |+ | |---> 585 +-----------+ +--------------+ 587 +------------+ e.g., BGP (Redirect) 588 e.g., IPFIX +------------+| BGP Flowspec (Drop) 589 <---| Forwarding ||<--- 590 | nodes || DDoS Attack 591 | ++=====||================ 592 | || ||x<==============[e.g., DNS Amp] 593 | || |+x<==============[e.g., NTP Amp] 594 +-----||-----+ 595 || 596 |/ 597 +-----x------+ 598 | DDoS | 599 | mitigation | 600 | system | 601 +------------+ 603 * C is for DOTS client functionality 604 * S is for DOTS server functionality 605 * DNS Amp: DNS Amplification 606 * NTP Amp: NTP Amplification 608 Figure 10: DDoS Mitigation Based on Attack Type 609 =============== NOTE: '\' line wrapping per RFC 8792 ================ 611 { 612 "ietf-dots-mapping:vendor-mapping": { 613 "vendor": [ 614 { 615 "vendor-id": 32473, 616 "vendor-name": "mitigator-c", 617 "last-updated": "1629898958", 618 "attack-mapping": [ 619 { 620 "attack-id": 77, 621 "attack-description": 622 "attack-description": "DNS amplification Attack: \ 623 This attack is a type of reflection attack in which attackers \ 624 spoof a target's IP address. The attackers abuse vulnerbilities \ 625 in DNS servers to turn small queries into larger payloads." 626 }, 627 { 628 "attack-id": 92, 629 "attack-description": 630 "attack-description":"NTP amplification Attack: \ 631 This attack is a type of reflection attack in which attackers \ 632 spoof a target's IP address. The attackers abuse vulnerbilities \ 633 in NTP servers to turn small queries into larger payloads." 634 } 635 ] 636 } 637 ] 638 } 639 } 641 Figure 11: Example of Message Body with Attack Mappings 643 { 644 "ietf-dots-telemetry:telemetry": { 645 "pre-or-ongoing-mitigation": [ 646 { 647 "target": { 648 "target-prefix": [ 649 "2001:db8::1/128" 650 ] 651 }, 652 "total-attack-traffic": [ 653 { 654 "unit": "megabit-ps", 655 "low-percentile-g": "600", 656 "mid-percentile-g": "800", 657 "high-percentile-g": "1000", 658 "peak-g": "1100", 659 "current-g": "700" 660 } 661 ], 662 "total-attack-traffic-protocol": [ 663 { 664 "protocol": 17, 665 "unit": "megabit-ps", 666 "mid-percentile-g": "500" 667 }, 668 { 669 "protocol": 15, 670 "unit": "megabit-ps", 671 "mid-percentile-g": "200" 672 } 673 ], 674 "total-attack-connection": [ 675 { 676 "mid-percentile-l": [ 677 { 678 "protocol": 15, 679 "connection": 200 680 } 681 ], 682 "high-percentile-l": [ 683 { 684 "protocol": 17, 685 "connection": 300 686 } 687 ] 688 } 689 ], 690 "attack-detail": [ 691 { 692 "vendor-id": 32473, 693 "attack-id": 77, 694 "start-time": "1641169211", 695 "attack-severity": "high" 696 }, 697 { 698 "vendor-id": 32473, 699 "attack-id": 92, 700 "start-time": "1641172809", 701 "attack-severity": "high" 702 } 703 ] 704 } 706 ] 707 } 708 } 710 Figure 12: Example of Message Body with Total Attack Traffic, 711 Total Attack Traffic Protocol, Total Attack Connection and Attack Type 713 Attack mappings are shared by using the DOTS data channel in advance 714 (Section 8.1.6 of [I-D.ietf-dots-telemetry]). The forwarding nodes 715 send traffic statistics to the flow collectors by using, e.g., IPFIX. 716 When DDoS attacks occur, the flow collectors identify attack traffic 717 and send attack type information to the orchestrator by using 718 "vendor-id" and "attack-id" telemetry attributes. The orchestrator, 719 then, resolves abused port numbers and orders relevant forwarding 720 nodes to block the amplification attack traffic flow by dissemination 721 of Flow Specifications, e.g. [RFC8955]. Also, the orchestrator 722 orders relevant forwarding nodes to redirect other traffic than the 723 amplification attack traffic by using a routing protocol, such as 724 BGP. 726 The flow collector implements a DOTS client while the orchestrator 727 implements a DOTS server. 729 3.2. Detailed DDoS Mitigation Report 731 It is possible for the transit provider to add value to the DDoS 732 mitigation service by reporting on-going and detailed DDoS 733 countermeasure status to the enterprise network. In addition, it is 734 possible for the transit provider to know whether the DDoS counter 735 measure is effective or not by receiving reports from the enterprise 736 network. 738 The aim of this use case is to share the information about on-going 739 DDoS counter measure between the transit provider and the enterprise 740 network mutually. Figure 13 gives an overview of this use case. 741 Figure 14 provides an example of a DOTS telemetry message body that 742 is used to signal total pipe capacity from the enterprise network 743 administrator to the orchestrator in the ISP. Figure 15 provides an 744 example of a DOTS telemetry message body that is used to signal 745 various total traffic percentiles, total attack traffic percentiles 746 and attack detail from the orchestrator to the network. 748 +------------------+ +------------------------+ 749 | Enterprise | | Upstream | 750 | Network | | Internet Transit | 751 | +------------+ | | Provider | 752 | | Network |C | | S+--------------+ | 753 | | admini- |<-----DOTS---->| Orchestrator | | 754 | | strator | | | +--------------+ | 755 | +------------+ | | C ^ | 756 | | | | DOTS | 757 | | | S v | 758 | | | +---------------+ DDoS Attack 759 | | | | DMS |+======= 760 | | | +---------------+ | 761 | | | || Clean | 762 | | | |/ Traffic | 763 | +---------+ | | +---------------+ | 764 | | DDoS | | | | Forwarding | Normal Traffic 765 | | Target |<================| Node |======== 766 | +---------+ | Link1 | +---------------+ | 767 +------------------+ +------------------------+ 769 * C is for DOTS client functionality 770 * S is for DOTS server functionality 772 Figure 13: Detailed DDoS Mitigation Report 774 { 775 "ietf-dots-telemetry:telemetry-setup": { 776 "telemetry": [ 777 { 778 "total-pipe-capacity": [ 779 { 780 "link-id": "link1", 781 "capacity": "1000", 782 "unit": "megabit-ps" 783 } 784 ] 785 } 786 ] 787 } 788 } 789 Figure 14: An Example of Message Body with Total Pipe Capacity 790 { 791 "ietf-dots-telemetry:telemetry": { 792 "pre-or-ongoing-mitigation": [ 793 { 794 "tmid": 567, 795 "target": { 796 "target-prefix": [ 797 "2001:db8::1/128" 798 ] 799 }, 800 "target-protocol": [ 801 17 802 ], 803 "total-traffic": [ 804 { 805 "unit": "megabit-ps", 806 "mid-percentile-g": "800" 807 } 808 ], 809 "total-attack-traffic": [ 810 { 811 "unit": "megabit-ps", 812 "mid-percentile-g": "100" 813 } 814 ], 815 "attack-detail": [ 816 { 817 "vendor-id": 32473, 818 "attack-id": 77, 819 "start-time": "1644819611", 820 "attack-severity": "high" 821 } 822 ] 823 } 824 ] 825 } 826 } 828 Figure 15: An Example of Message Body with Total Traffic, 829 Total Attack Traffic Protocol, and Attack Detail 831 The network management system in the enterprise network reports 832 limits of incoming traffic volume from the transit provider to the 833 orchestrator in the transit provider in advance. It is reported by 834 using "total-pipe-capacity" telemetry attribute in DOTS telemetry 835 setup. 837 When DDoS attacks occur, DDoS mitugation orchestration [RFC8903] is 838 carried out in the transit provider. Then, the DDoS mitigation 839 systems reports the status of DDoS countermeasures to the 840 orchestrator by sending "attack-detail" telemetry attributes. After 841 that, the orchestrator integrates the reports from the DDoS 842 mitigation system, while removing duplicate contents, and sends them 843 to a network administrator by using DOTS telemetry periodically. 845 During the DDoS mitigation, the orchestrator in the transit provider 846 retrieves link congestion status from the network manager in the 847 enterprise network by using "total-traffic" telemetry attributes. 848 Then, the orchestrator checks whether the DDoS countermeasures are 849 effective or not by comparing the "total-traffic" and the "total- 850 pipe-capacity" attributes. 852 The DMS implements a DOTS server while the orchestrator behaves as a 853 DOTS client and a server in the transit provider. In addition, the 854 network administrator implements a DOTS client. 856 3.3. Tuning Mitigation Resources 858 3.3.1. Supervised Machine Learning of Flow Collector 860 DDoS detection based on tools, such as IPFIX, is a lighter weight 861 method of detecting DDoS attacks than DMSes in internet transit 862 provider networks. On the other hand, DDoS detection based on the 863 DMSes is a more accurate method for detecting attack traffic than 864 flow monitoring. 866 The aim of this use case is to increase flow collector's detection 867 accuracy by carrying out supervised machine-learning techniques 868 according to attack detail reported by the DMSes. To use such a 869 technique, forwarding nodes, flow collector, and a DMS should 870 cooperate. Figure 16 gives an overview of this use case. Figure 17 871 provides an example of a DOTS telemetry message body that is used to 872 signal various total attack traffic percentiles and attack detail. 874 +-----------+ 875 +-----------+| DOTS 876 e.g., IPFIX | Flow ||S<--- 877 --->| collector || 878 +-----------++ 880 +------------+ 881 e.g., IPFIX +------------+| 882 <---| Forwarding || 883 | nodes || DDoS Attack 884 [ Target ] | ++============================== 885 | || ++=========================== 886 | || || ++======================== 887 +---||-|| ||-+ 888 || || || 889 |/ |/ |/ 890 DOTS +---X--X--X--+ 891 --->C| DDoS | 892 | mitigation | 893 | system | 894 +------------+ 896 * C is for DOTS client functionality 897 * S is for DOTS server functionality 899 Figure 16: Training Supervised Machine Learning of Flow Collectors 900 { 901 "ietf-dots-telemetry:telemetry": { 902 "pre-or-ongoing-mitigation": [ 903 { 904 "target": { 905 "target-prefix": [ 906 "2001:db8::1/128" 907 ] 908 }, 909 "attack-detail": [ 910 { 911 "vendor-id": 32473, 912 "attack-id": 77, 913 "start-time": "1634192411", 914 "attack-severity": "high", 915 "top-talker": { 916 "talker": [ 917 { 918 "source-prefix": "2001:db8::2/128" 919 }, 920 { 921 "source-prefix": "2001:db8::3/128" 922 } 923 ] 924 } 925 } 926 ] 927 } 928 ] 929 } 930 } 932 Figure 17: An Example of Message Body with Attack Type 933 and top-talkers 935 The forwarding nodes send traffic statistics to the flow collectors 936 by using, e.g., IPFIX. When DDoS attacks occur, DDoS mitigation 937 orchestration is carried out (as per Section 3.3 of [RFC8903]) and 938 the DMS mitigates all attack traffic destined for a target. The DDoS 939 mitigation system reports the "vendor-id", "attack-id", and "top- 940 talker" telemetry attributes to a flow collector. 942 After mitigating a DDoS attack, the flow collector attaches outputs 943 of the DMS as labels to the statistics of traffic flow of top- 944 talkers. The outputs, for example, are the "attack-id" telemetry 945 attributes. The flow collector, then, carries out supervised machine 946 learning to increase its detection accuracy, setting the statistics 947 as an explanatory variable and setting the labels as an objective 948 variable. 950 The DMS implements a DOTS client while the flow collector implements 951 a DOTS server. 953 3.3.2. Unsupervised Machine Learning of Flow Collector 955 DMSes can detect DDoS attack traffic, which means DMSes can also 956 identify clean traffic. The aim of this use case is to carry out 957 unsupervised machine-learning for anomaly detection according to 958 baseline reported by DMSes. To use such a technique, forwarding 959 nodes, flow collector, and a DMS should cooperate. Figure 18 gives 960 an overview of this use case. Figure 19 provides an example of a 961 DOTS telemetry message body that is used to signal baseline. 963 +-----------+ 964 +-----------+| 965 DOTS | Flow || 966 --->S| collector || 967 +-----------++ 969 +------------+ 970 +------------+| 971 | Forwarding || 972 | nodes || Traffic 973 [ Dst ] <========================++============================== 974 | || || 975 | || |+ 976 +---||-------+ 977 || 978 |/ 979 DOTS +---X--------+ 980 --->C| DDoS | 981 | mitigation | 982 | system | 983 +------------+ 985 * C is for DOTS client functionality 986 * S is for DOTS server functionality 988 Figure 18: Training Unsupervised Machine Learning of Flow Collectors 989 { 990 "ietf-dots-telemetry:telemetry-setup": { 991 "telemetry": [ 992 { 993 "baseline": [ 994 { 995 "id": 1, 996 "target-prefix": [ 997 "2001:db8:6401::1/128" 998 ], 999 "target-port-range": [ 1000 { 1001 "lower-port": "53" 1002 } 1003 ], 1004 "target-protocol": [ 1005 17 1006 ], 1007 "total-traffic-normal": [ 1008 { 1009 "unit": "megabit-ps", 1010 "mid-percentile-g": "30", 1011 "mid-percentile-g": "50", 1012 "high-percentile-g": "60", 1013 "peak-g": "70" 1014 } 1015 ] 1016 } 1017 ] 1018 } 1019 ] 1020 } 1021 } 1023 Figure 19: An Example of Message Body with Traffic Baseline 1025 The forwarding nodes carry out mirroring traffic destined IP address. 1026 The DMS then identifies "clean" traffic and reports the baseline 1027 attributes to the flow collector by using DOTS telemetry. 1029 The flow collector, then, carries out unsupervised machine learning 1030 to be able to carry out anomaly detection. 1032 The DMS implements a DOTS client while the flow collector implements 1033 a DOTS server. 1035 4. Security Considerations 1037 DOTS telemetry security considerations are discussed in Section 14 of 1038 [I-D.ietf-dots-telemetry]. These considerations apply for the 1039 communication interfaces where DOTS is used. 1041 Some use cases involve controllers, orchestrators, and programmable 1042 interfaces. These interfaces can be misused by misbehaving nodes to 1043 further exacerbate DDoS attacks. Section 5 of [RFC7149] discusses 1044 some generic security considerations to take into account in such 1045 contexts (e.g., reliable access control). Specific security measures 1046 depend on the actual mechanism used to control underlying forwarding 1047 nodes and other controlled elements. For example, Section 13 of 1048 [RFC8955] discusses security considerations that are relevant to BGP 1049 Flowspec. IPFIX-specific considerations are discussed in Section 11 1050 of [RFC7011]. 1052 5. IANA Considerations 1054 This document does not require any action from IANA. 1056 6. Acknowledgement 1058 The authors would like to thank Mohamed Boucadair and Valery Smyslov 1059 for their valuable feedback. 1061 7. References 1063 7.1. Normative References 1065 [I-D.ietf-dots-telemetry] 1066 Boucadair, M., Reddy.K, T., Doron, E., Chen, M., and J. 1067 Shallow, "Distributed Denial-of-Service Open Threat 1068 Signaling (DOTS) Telemetry", Work in Progress, Internet- 1069 Draft, draft-ietf-dots-telemetry-25, 21 March 2022, 1070 . 1073 7.2. Informative References 1075 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1076 Management Protocol (SNMP) Applications", STD 62, 1077 RFC 3413, DOI 10.17487/RFC3413, December 2002, 1078 . 1080 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1081 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1082 DOI 10.17487/RFC4271, January 2006, 1083 . 1085 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1086 "Specification of the IP Flow Information Export (IPFIX) 1087 Protocol for the Exchange of Flow Information", STD 77, 1088 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1089 . 1091 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1092 Networking: A Perspective from within a Service Provider 1093 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1094 . 1096 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1097 Threat Signaling (DOTS) Requirements", RFC 8612, 1098 DOI 10.17487/RFC8612, May 2019, 1099 . 1101 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1102 Denial-of-Service Open Threat Signaling (DOTS) Data 1103 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1104 May 2020, . 1106 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 1107 "Handling Long Lines in Content of Internet-Drafts and 1108 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 1109 . 1111 [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1112 L., and K. Nishizuka, "Use Cases for DDoS Open Threat 1113 Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, 1114 . 1116 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1117 Bacher, "Dissemination of Flow Specification Rules", 1118 RFC 8955, DOI 10.17487/RFC8955, December 2020, 1119 . 1121 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 1122 "Distributed Denial-of-Service Open Threat Signaling 1123 (DOTS) Signal Channel Specification", RFC 9132, 1124 DOI 10.17487/RFC9132, September 2021, 1125 . 1127 Authors' Addresses 1129 Yuhei Hayashi 1130 NTT 1131 3-9-11, Midori-cho, Tokyo 1132 180-8585 1133 Japan 1134 Email: yuuhei.hayashi@gmail.com 1136 Meiling Chen 1137 CMCC 1138 32, Xuanwumen West 1139 BeiJing 1140 BeiJing, 100053 1141 China 1142 Email: chenmeiling@chinamobile.com 1144 Li Su 1145 CMCC 1146 32, Xuanwumen West 1147 BeiJing, BeiJing 1148 100053 1149 China 1150 Email: suli@chinamobile.com