idnits 2.17.00 (12 Aug 2021) /tmp/idnits52966/draft-hayashi-dots-dms-offload-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 (July 20, 2019) is 1029 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4271' is defined on line 813, but no explicit reference was found in the text == Outdated reference: draft-ietf-dots-data-channel has been published as RFC 8783 == Outdated reference: draft-ietf-dots-signal-call-home has been published as RFC 9066 == Outdated reference: draft-ietf-dots-signal-channel has been published as RFC 8782 == Outdated reference: draft-ietf-dots-signal-filter-control has been published as RFC 9133 == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 K. Nishizuka 5 Expires: January 21, 2020 NTT Communications 6 M. Boucadair 7 Orange 8 July 20, 2019 10 DDoS Mitigation Offload: DOTS Applicability and Deployment 11 Considerations 12 draft-hayashi-dots-dms-offload-00 14 Abstract 16 This document describes a deployment scenario to assess the 17 applicability of DOTS protocols together with a discussion on DOTS 18 deployment considerations of such scenario. This scenario assumes 19 that a DMS (DDoS Mitigation System) whose utilization rate is high 20 sends its blocked traffic information to an orchestrator using DOTS 21 protocols, then the orchestrator requests forwarding nodes such as 22 routers to filter the traffic. Doing so enables service providers to 23 mitigate the DDoS attack traffic automatically while ensuring 24 interoperability and distributed filter enforcement. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 21, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. DDoS Mitigation Offload Scenario . . . . . . . . . . . . . . 4 64 5. DOTS Deployment Considerations . . . . . . . . . . . . . . . 6 65 5.1. DOTS Signaling via Out-of-band Link . . . . . . . . . . . 8 66 5.1.1. Example of using Data Channel . . . . . . . . . . . . 8 67 5.2. DOTS Signaling via In-band Link . . . . . . . . . . . . . 9 68 5.2.1. Example of using Signal Channel . . . . . . . . . . . 10 69 5.2.2. Example of using Signal Channel Call Home . . . . . . 12 70 5.2.3. Data Channel and Signal Channel Controlling Filtering 14 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 76 9.2. Informative References . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 Volume-based distributed Denial-of-Service (DDoS) attacks such as DNS 82 amplification attacks are critical threats to be handled by service 83 providers. When such attacks occur, service providers have to 84 mitigate them immediately to protect or recover their services. 86 Therefore, for the service providers to immediately protect their 87 network services from DDoS attacks, DDoS mitigation needs to be 88 automated. To automate DDoS attack mitigation, it is desirable that 89 multi-vendor elements involved in DDoS attack detection and 90 mitigation collaborate and support standard interfaces to 91 communicate. 93 DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time 94 signaling, threat-handling requests, and data filtering between the 95 multi-vendor elements [I-D.ietf-dots-signal-channel] 97 [I-D.ietf-dots-signal-call-home] 98 [I-D.ietf-dots-signal-filter-control] [I-D.ietf-dots-data-channel]. 99 This document describes an automated DDoS Mitigation offload scenario 100 inherited from the DDoS orchestration scenario 101 [I-D.ietf-dots-use-cases], which ambitions to enable cost-effective 102 DDoS Mitigation. Furthermore, this document describes deployment 103 consideration for network operators who carry out this scenario using 104 DOTS protocols in their network. 106 This document aims to assess to what extent DOTS protocols can be 107 used to provide the intended functionality and identify any gaps. 109 2. Terminology 111 The readers should be familiar with the terms defined in [RFC8612] 112 [I-D.ietf-dots-use-cases] 114 In addition, this document makes use of the following terms: 116 Mitigation offload: Getting rid of a DMS's mitigation action and 117 assigning the action to another entity when the utilization rate 118 of the DMS reaches a given threshold. How such threshold is set 119 is deployment-specific. 121 Utilization rate: A scale to measure load of an entity such as link 122 utilization rate or CPU utilization rate. 124 3. The Problem 126 In general, DDoS countermeasures are divided into detection and 127 filtering. Detection is technically challenging given the dynamic of 128 attacks and sophisticated attack strategies. DDoS Mitigation System 129 (DMS) can detect attack traffic based on a specific technology 130 (provided and supposed to be updated and maintained by vendors to 131 detect complex attacks), so service providers can increase DDoS 132 countermeasure level by deploying the DMS in their network. 134 However, the number/capacity of DMS instances that can be deployed in 135 a service providers network is limited due to equipment cost and 136 dimensioning matters. Thus, DMS's utilization rate can reach its 137 maximum capacity faster when the volume of DDoS attacks is enormous. 138 When the rate reaches maximum capacity, the mitigation strategy needs 139 to offload mitigation actions from the DMS to cost-effective 140 forwarding nodes such as routers. 142 4. DDoS Mitigation Offload Scenario 144 This section describes offloading mitigation actions from DMS whose 145 utilization rate is high to cost-effective forwarding node using DOTS 146 protocols. This section does not consider deployments where the 147 network orchestrator and DMS are co-located. 149 Figures 1 and 2 show a sample component diagram and a sequence 150 diagram of the deployment scenario, respectively. 152 +--------------+ +-----------+ 153 | | | DDoS |+ 154 | Orchestrator |<-------| mitigation|| 155 | |S DOTS C| systems || 156 +--------------+ +-----------+| 157 | +----------+ 158 | e.g., BGP, BGP Flowspec 159 | 160 | +------------------+ 161 +->| Forwarding nodes |+ 162 +------------------+| 163 +-----------------+ 164 * C is for DOTS Client function 165 * S is for DOTS Server function 167 Figure 1: Component Diagram of DDoS Mitigation Offload Scenario 169 The component diagram shown in Figure 1 differs from that of DDoS 170 Orchestration scenario in [I-D.ietf-dots-use-cases] in some respects. 171 First, the DMS embeds a DOTS client to send DOTS requests to the 172 orchestrator. Second, the orchestrator sends a request to underlying 173 forwarding nodes to filter the attack traffic. 175 +------------+ +----------+ +------------+ 176 | | |DDoS |+ | Forwarding |+ 177 |Orchestrator| |Mitigation|| | Nodes || 178 | | |Systems || | || 179 +------------+ +----------+| +------------+| 180 | +----------+ +------------+ 181 | | | 182 | DOTS Request | | 183 |S<----------------------C| | 184 | | | 185 | e.g., BGP, BGP Flowspec | | 186 | Filter Attack Traffic | | 187 |-------------------------|------------->| 188 | | | 189 * C is for DOTS Client function 190 * S is for DOTS Server function 192 Figure 2: Sequence Diagram of DDoS Mitigation Offload Scenario 194 In this scenario, it is assumed that volume based attack already hits 195 a network and attack traffic is detected and blocked by a DMS in the 196 network. When the volume-based attack becomes intense, DMS's 197 utilization rate can reach a certain threshold (e.g., maximum 198 capacity). Then, the DMS sends a DOTS request as offload request to 199 the orchestrator with the actions to enforce on the traffic. After 200 that, the orchestrator requests the forwarding nodes to filter attack 201 traffic by dissemination of flow specification rules protocols such 202 as BGP Flowspec [RFC5575] on the basis of the blocked traffic 203 information. 205 This schenario is divided into two cases based on type of link 206 between the DMS and the orchestrator: "out-of-band case" and "in-band 207 case". 209 "Out-of-band case" is that the DMS sends a DOTS request to the 210 orchestrator with blocked traffic information by the DMS via out-of- 211 band link. The link is not congested when it is under volume attack- 212 time, so the link can convey a lot of information. 214 On the other hand, "in-band case" is that the DMS sends a mitigation 215 request to the orchestrator with blocked traffic information by the 216 DMS via in-band channel. The link can be congested when it is under 217 volume attack-time, so the link can convey limited information. 219 5. DOTS Deployment Considerations 221 This section describes deployment considerations: what type of DOTS 222 protocol can be used and what type of information can be conveyed and 223 effective by DOTS protocol in this scenario. Figure 3 shows overview 224 of the DOTS signaling method and conveyed information for the out-of- 225 band case and in-band case. 227 The volume of information should be considered carefully when DOTS 228 protocol is used in the in-band case. What type of information can 229 be conveyed by DMS relays on attack type detected by the DMS: 230 reflection attack or non-reflection attack. When it is under non- 231 reflection attack, src_ip and src_port information cannot be conveyed 232 because attackers usually randomize the parameters so number of its 233 become enormous. On the other hand, when it is under reflection 234 attack, dst_port information cannot be conveyed because attackers 235 usually randomize src_port so the number of dst_port of attack 236 packets reached to victim become enormous. Furthermore, when it is 237 under reflection attack, src_ip information cannot be conveyed when 238 number of reflector is enormous. 240 +-------------+-----------------------------------+------------------+ 241 | | Reflection Attack | Non-Reflection | 242 | | | Attack | 243 +-------------+-----------------------------------+------------------+ 244 | Out-of-band | Attack Time | 245 | case | Method : Data Channel | 246 | | Info : src_ip, src_port, dst_ip, dst_port, protocol | 247 +-------------+-----------------------------------+------------------+ 248 | In-band | Attack Time | Attack Time | 249 | case | (Number of reflector is small) | Method : Signal | 250 | | Method : Signal Channel with src | Channel | 251 | | Info : src_ip, src_port, | Info : dst_ip, | 252 | | dst_ip, protocol | dst_port, | 253 | +-----------------------------------+ protocol | 254 | | Attack Time | | 255 | | (Number of reflector is enormous) | | 256 | | Method : Signal Channel with src | | 257 | | Info : src_port, dst_ip, protocol | | 258 | +-----------------------------------+------------------+ 259 | | Peace Time | Peace Time | 260 | | Method : Data Channel | Method : Data | 261 | | Info : src_port, | Channel | 262 | | dst_ip, protocol | Info : dst_ip, | 263 | | | dst_port, | 264 | | | protocol | 265 | | | | 266 | | Attack Time | Attack Time | 267 | | Method : Signal Channel | Method : Signal | 268 | | Control Filtering | Channel | 269 | | Info : ACL name | Control Filtering| 270 | | | Info : ACL name | 271 |-------------+------------------------------------------------------+ 273 Figure 3: Signaling Method and Conveyed Information 275 About offloading DMS against reflection attack, the current signal 276 channel [I-D.ietf-dots-signal-channel] is insufficient in terms of 277 conveying source information. On the other hand, both signal channel 278 extensions defined in [I-D.ietf-dots-signal-call-home] (called, 279 source-* clauses hereafter) and the filtering control extensions 280 [I-D.ietf-dots-signal-filter-control] allow for sending source 281 information. 283 Using src-* attributes defined in [I-D.ietf-dots-signal-call-home] 284 enables signal channel to convey src_ip information and src_port 285 information in attack time. On the other hand, filtering control 286 extensions can activate filtering rule configured in peacetime. 288 Filtering rule for well-known port numbers abused for reflection 289 attack can be configured to DOTS server in peacetime. However, 290 filtering rule for reflector's IP address in attack time can't be 291 known in peace time. So filtering control expansion can convey 292 src_port information but can't send src_ip information against 293 reflection attack. About sending source information in the DMS 294 offload s scenario, the capability of the call home extension 295 encompasses the capabilities of the filtering control extension. 297 The following sub-sections describes example of use DOTS protocols in 298 each case. 300 5.1. DOTS Signaling via Out-of-band Link 302 In this case, the link is not congested when it is under volume 303 attack-time, so DOTS data channel [I-D.ietf-dots-data-channel] is 304 suitable because DOTS data channel has capability of conveying the 305 drop-listed filtering rules including (src_ip, src_port, dst_ip, 306 dst_port, protocol) information (and other actions such as 'rate- 307 limit'). 309 5.1.1. Example of using Data Channel 311 The procedure to use DOTS Data Channel in such case is as follows: 313 o The DMS generates a list of flow (src_ip, src_port, dst_ip, 314 dst_port, protocol) information which the DMS is blocking/rate- 315 limiting and wants to offload. 317 o The DMS creates data-channel ACL such as shown figure 4. 319 o The DMS sends the data-channel ACL to the orchestrator. 321 { 322 "ietf-dots-data-channel:acls": { 323 "acl": [ 324 { 325 "name": "DMS_Offload_scenario_ACL", 326 "type": "ipv4-acl-type", 327 "activation-type": "immediate", 328 "aces": { 329 "ace": [ 330 { 331 "name": "DMS_Offload_scenario_ACE_00", 332 "matches": { 333 "ipv4": { 334 "destination-ipv4-network": "192.0.2.2/32", 335 "source-ipv4-network": "203.0.113.2/32", 336 "protocol":17 337 }, 338 "udp": { 339 "source-port": { 340 "operator": "eq", 341 "port": 53 342 } 343 } 344 }, 345 "actions": { 346 "forwarding": "drop" 347 } 348 }, 349 { 350 "name": "DMS_Offload_scenario_ACE_01", 351 "matches": { 352 "ipv4": { 353 "destination-ipv4-network": "192.0.2.2/32", 354 "source-ipv4-network": "203.0.113.3/32", 355 "protocol":17 356 }, 357 "udp": { 358 "source-port": { 359 "operator": "eq", 360 "port": 53 361 } 362 } 363 }, 364 "actions": { 365 "forwarding": "drop" 366 } 367 } 368 ] 369 } 370 } 371 ] 372 } 373 } 375 Figure 4: JSON Example of ACL including (src_ip, src_port, dst_ip, 376 dst_port, protocol) information conveyed by DOTS data channel 378 5.2. DOTS Signaling via In-band Link 380 In this case, the link can be congested when it is under volume 381 attack-time, so DOTS data channel can't be used to convey the drop- 382 listed filtering rules as blocked traffic information [Interop]. On 383 the other hand, DOTS signal channel [I-D.ietf-dots-signal-channel], 384 the source-* clauses defined in [I-D.ietf-dots-signal-call-home] and 385 filtering control [I-D.ietf-dots-signal-filter-control] can be used 386 to communicate the policies to the orchestrator. 388 5.2.1. Example of using Signal Channel 390 DOTS signal channel has capability to send (dst_ip, dst_port, 391 protocol) information. The procedure to use DOTS Signal Channel in 392 this case is as follows: 394 o The DMS generates a list of (dst_ip, dst_port, protocol) 395 information which the DMS is blocking/rate-limiting and wants to 396 offload. 398 o The DMS creates mitigation request such as shown figure 5. 400 o The DMS sends the mitigation requests to the orchestrator. 402 { 403 "ietf-dots-signal-channel:mitigation-scope": { 404 "scope": [ 405 { 406 "target-prefix": [ 407 "192.0.2.2/32" 408 ], 409 "target-port-range": [ 410 { 411 "lower-port": 80 412 }, 413 { 414 "lower-port": 443 415 } 416 ], 417 "target-protocol": [ 418 6 419 ], 420 "lifetime": 3600 421 }, 422 { 423 "target-prefix": [ 424 "192.0.2.2/32" 425 ], 426 "target-port-range": [ 427 { 428 "lower-port": 53 429 }, 430 { 431 "lower-port": 123 432 } 433 ], 434 "target-protocol": [ 435 17 436 ], 437 "lifetime": 3600 438 } 439 ] 440 } 441 } 443 Figure 5: JSON Example of offload request including (dst_ip, 444 dst_port, protocol) information conveyed by DOTS signal channel 446 5.2.2. Example of using Signal Channel Call Home 448 [I-D.ietf-dots-signal-call-home] extends the DOTS signal channel to 449 convey (dst_ip, dst_port, src_ip, src_port, protocol) information in 450 a mitigation request. A mitigation request can convey src_ip 451 information when the number of reflectors detected by a DMS is small. 452 The procedure to use DOTS src-* clauses is as follows: 454 o The DMS generates a list of (dst_ip, src_ip, src_port, protocol) 455 information which the DMS is blocking/rate-limiting and wants to 456 offload. 458 o The DMS creates mitigation request such as shown figure 6. 460 o The DMS sends the mitigation requests to the orchestrator. 462 { 463 "ietf-dots-signal-channel:mitigation-scope": { 464 "scope": [ 465 { 466 "target-prefix": [ 467 "192.0.2.2/32" 468 ], 469 "target-protocol": [ 470 6 471 ], 472 "ietf-dots-call-home:source-prefix": [ 473 "203.0.113.2/32" 474 ], 475 "ietf-dots-call-home:source-port-range" : [ 476 { 477 "ietf-dots-call-home:lower-port": 53 478 }, 479 { 480 "ietf-dots-call-home:lower-port": 123 481 } 482 ], 483 "lifetime": 3600 484 }, 485 { 486 "target-prefix": [ 487 "192.0.2.2/32" 488 ], 489 "target-protocol": [ 490 6 491 ], 492 "ietf-dots-call-home:source-prefix": [ 493 "203.0.113.3/32" 494 ], 495 "ietf-dots-call-home:source-port-range" : [ 496 { 497 "ietf-dots-call-home:lower-port": 19 498 }, 499 { 500 "ietf-dots-call-home:lower-port": 11211 501 } 502 ], 503 "lifetime": 3600 504 } 505 ] 506 } 507 } 509 Figure 6: JSON Example of offload request including (dst_ip, src_ip, 510 src_port, protocol) information conveyed by DOTS signal channel 512 On the other hand, a mitigation request cannot convey src_ip 513 information when number of reflector detected by DMS exceeds a 514 certain number (cannot fit within one single request). The procedure 515 to use the DOTS signal channel in the situation is as follows: 517 o The DMS generates a list of (dst_ip, src_port, protocol) 518 information which the DMS is blocking/rate-limiting and wants to 519 offload. 521 o The DMS creates mitigation request such as shown in Figure 7. 523 o The DMS sends the mitigation requests to the orchestrator. 525 { 526 "ietf-dots-signal-channel:mitigation-scope": { 527 "scope": [ 528 { 529 "target-prefix": [ 530 "192.0.2.2/32" 531 ], 532 "target-protocol": [ 533 6 534 ], 535 "ietf-dots-call-home:source-port-range" : [ 536 { 537 "ietf-dots-call-home:lower-port": 53 538 }, 539 { 540 "ietf-dots-call-home:lower-port": 123 541 }, 542 { 543 "ietf-dots-call-home:lower-port": 19 544 }, 545 { 546 "ietf-dots-call-home:lower-port": 11211 547 } 548 ], 549 "lifetime": 3600 550 } 551 ] 552 } 553 } 555 Figure 7: JSON Example of offload request including (dst_ip, 556 src_port, protocol) information conveyed by DOTS signal channel 558 5.2.3. Data Channel and Signal Channel Controlling Filtering 560 DOTS signal channel controlling filtering 561 [I-D.ietf-dots-signal-filter-control] has capability to activate or 562 deactivate ACL configured by Data Channel. Against reflection 563 attack, DOTS client configures ACL including (dst_ip, src_port, 564 protocol) information in peace time by Data Channel, and DOTS client 565 activate the ACL in attack time by Signal Channel controlling 566 filtering. Note that the src_port is well known port abused to carry 567 out reflection attack by attacker. The procedure to use DOTS data 568 channel and signal channel controlling filtering is as follows: 570 o In peace time, the DMS sends the ACL including (dst_ip, src_port, 571 protocol) information such as figure 8. 573 o In attack time, the DMS generates a list of (dst_ip, src_port, 574 protocol) which the DMS is blocking/rate-limiting and wants to 575 offload. After that, the DMS sends the mitigation requests to 576 activate corresponding ACL configured to the orchestrator such as 577 figure 9. 579 { 580 "ietf-dots-data-channel:acls": { 581 "acl": [ 582 { 583 "name": "DMS_Offload_scenario_ACL", 584 "type": "ipv4-acl-type", 585 "activation-type": "activate-when-mitigating", 586 "aces": { 587 "ace": [ 588 { 589 "name": "DMS_Offload_scenario_ACL_DNS_amp", 590 "matches": { 591 "ipv4": { 592 "destination-ipv4-network": "192.0.2.2/32", 593 "protocol":17 594 }, 595 "udp": { 596 "source-port": { 597 "operator": "eq", 598 "port": 53 599 } 600 } 601 }, 602 "actions": { 603 "forwarding": "drop" 604 } 605 }, 606 { 607 "name": "DMS_Offload_scenario_ACL_NTP_amp", 608 "matches": { 609 "ipv4": { 610 "destination-ipv4-network": "192.0.2.2/32", 611 "protocol":17 612 }, 613 "udp": { 614 "source-port": { 615 "operator": "eq", 616 "port": 123 617 } 618 } 619 }, 620 "actions": { 621 "forwarding": "drop" 622 } 623 } 624 ] 625 } 626 } 627 ] 628 } 629 } 631 Figure 8: JSON Example of ACL including (dst_ip, src_port, protocol) 632 information conveyed by DOTS data channel 634 { 635 "ietf-dots-signal-channel:mitigation-scope": { 636 "scope": [ 637 { 638 "target-prefix": [ 639 "192.0.2.2/32" 640 ], 641 "target-protocol": [ 642 17 643 ], 644 "acl-list": [ 645 { 646 "acl-name": "DMS_Offload_scenario_ACL_DNS_amp", 647 "activation-type": "immediate" 648 } 649 "lifetime": 3600 650 } 651 ] 652 } 653 } 655 Figure 9: JSON Example of including acl name conveyed by DOTS signal 656 channel 658 Against non-reflection attack, DOTS client configures ACL including 659 (dst_ip, dst_port, protocol) information in peace time by Data 660 Channel, and DOTS client activate the 'acl' in attack time by Signal 661 Channel. Note that the dst_port is well known port abused to carry 662 out non-reclection attack by attacker. The procedure to use DOTS 663 data channel and signal channel controlling filtering is as follows: 665 o In peace time, the DMS sends the ACL including (dst_ip, dst_port, 666 protocol) information such as figure 10. 668 o In attack time, the DMS generates a list of (dst_ip, dst_port, 669 protocol) which the DMS is blocking/rate-limiting and wants to 670 offload. After that, the DMS sends the mitigation requests to 671 activate corresponding ACL configured to the orchestrator such as 672 figure 11. 674 { 675 "ietf-dots-data-channel:acls": { 676 "acl": [ 677 { 678 "name": "DMS_Offload_scenario_ACL", 679 "type": "ipv4-acl-type", 680 "activation-type": "activate-when-mitigating", 681 "aces": { 682 "ace": [ 683 { 684 "name": "DMS_Offload_scenario_HTTP_GET_Flooding", 685 "matches": { 686 "ipv4": { 687 "destination-ipv4-network": "192.0.2.2/32", 688 "protocol":6 689 }, 690 "tcp": { 691 "destination-port": { 692 "operator": "eq", 693 "port": 80 694 } 695 } 696 }, 697 "actions": { 698 "forwarding": "drop" 699 } 700 }, 701 { 702 "name": "DMS_Offload_scenario_SYN_Flooding_FTP", 703 "matches": { 704 "ipv4": { 705 "destination-ipv4-network": "192.0.2.2/32", 706 "protocol":6 707 }, 708 "tcp": { 709 "destination-port": { 710 "operator": "eq", 711 "port": 20 712 } 713 } 714 }, 715 "actions": { 716 "forwarding": "drop" 717 } 718 } 719 ] 720 } 721 } 722 ] 723 } 724 } 726 Figure 10: JSON Example of ACL including (dst_ip, dst_port, protocol) 727 information conveyed by DOTS data channel 729 { 730 "ietf-dots-signal-channel:mitigation-scope": { 731 "scope": [ 732 { 733 "target-prefix": [ 734 "192.0.2.2/32" 735 ], 736 "target-protocol": [ 737 6 738 ], 739 "acl-list": [ 740 { 741 "acl-name": "DMS_Offload_scenario_HTTP_GET_Flooding", 742 "activation-type": "immediate" 743 } 744 "lifetime": 3600 745 } 746 ] 747 } 748 } 750 Figure 11: JSON Example of including ACL name conveyed by DOTS signal 751 channel 753 6. Security Considerations 755 Security considerations discussed in [I-D.ietf-dots-data-channel] and 756 [I-D.ietf-dots-signal-channel] are to be taken into account. 758 7. IANA Considerations 760 This document does not require any action from IANA. 762 8. Acknowledgement 764 Thanks to Tirumaleswar Reddy, Shunsuke Homma, Pan Wei, and Xia Liang 765 for the comments. 767 Thanks to Koichi Sakurada for demonstrating proof of concepts of this 768 proposal . 770 9. References 772 9.1. Normative References 774 [I-D.ietf-dots-data-channel] 775 Boucadair, M. and R. K, "Distributed Denial-of-Service 776 Open Threat Signaling (DOTS) Data Channel Specification", 777 draft-ietf-dots-data-channel-30 (work in progress), July 778 2019. 780 [I-D.ietf-dots-signal-call-home] 781 K, R., Boucadair, M., and J. Shallow, "Distributed Denial- 782 of-Service Open Threat Signaling (DOTS) Signal Channel 783 Call Home", draft-ietf-dots-signal-call-home-03 (work in 784 progress), July 2019. 786 [I-D.ietf-dots-signal-channel] 787 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 788 Teague, "Distributed Denial-of-Service Open Threat 789 Signaling (DOTS) Signal Channel Specification", draft- 790 ietf-dots-signal-channel-35 (work in progress), July 2019. 792 [I-D.ietf-dots-signal-filter-control] 793 Nishizuka, K., Boucadair, M., K, R., and T. Nagata, 794 "Controlling Filtering Rules Using Distributed Denial-of- 795 Service Open Threat Signaling (DOTS) Signal Channel", 796 draft-ietf-dots-signal-filter-control-01 (work in 797 progress), May 2019. 799 9.2. Informative References 801 [I-D.ietf-dots-use-cases] 802 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 803 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 804 Open Threat Signaling", draft-ietf-dots-use-cases-18 (work 805 in progress), July 2019. 807 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 808 test report, IETF 103 Hackathon", November 2018, 809 . 813 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 814 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 815 DOI 10.17487/RFC4271, January 2006, 816 . 818 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 819 and D. McPherson, "Dissemination of Flow Specification 820 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 821 . 823 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 824 Threat Signaling (DOTS) Requirements", RFC 8612, 825 DOI 10.17487/RFC8612, May 2019, 826 . 828 Authors' Addresses 830 Yuhei Hayashi 831 NTT 832 3-9-11, Midori-cho 833 Musashino-shi, Tokyo 180-8585 834 Japan 836 Email: yuuhei.hayashi@gmail.com 838 Kaname Nishizuka 839 NTT Communications 840 GranPark 16F 3-4-1 Shibaura, Minato-ku 841 Tokyo 108-8118 842 Japan 844 Email: kaname@nttv6.jp 846 Mohamed Boucadair 847 Orange 848 Rennes 35000 849 France 851 Email: mohamed.boucadair@orange.com