idnits 2.17.1 draft-ietf-dots-signal-filter-control-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2020) is 1422 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1007, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS K. Nishizuka 3 Internet-Draft NTT Communications 4 Intended status: Standards Track M. Boucadair 5 Expires: November 28, 2020 Orange 6 T. Reddy 7 McAfee 8 T. Nagata 9 Lepidum 10 May 27, 2020 12 Controlling Filtering Rules Using Distributed Denial-of-Service Open 13 Threat Signaling (DOTS) Signal Channel 14 draft-ietf-dots-signal-filter-control-04 16 Abstract 18 This document specifies an extension to the DOTS signal channel 19 protocol so that DOTS clients can control their filtering rules when 20 an attack mitigation is active. 22 Particularly, this extension allows a DOTS client to activate or de- 23 activate existing filtering rules during a DDoS attack. The 24 characterization of these filtering rules is supposed to be conveyed 25 by a DOTS client during an idle time by means of the DOTS data 26 channel protocol. 28 Editorial Note (To be removed by RFC Editor) 30 Please update these statements within the document with the RFC 31 number to be assigned to this document: 33 o "This version of this YANG module is part of RFC XXXX;" 35 o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial- 36 of-Service Open Threat Signaling (DOTS) Signal Channel"; 38 o reference: RFC XXXX 40 o [RFCXXXX] 42 Please update the "revision" date of the YANG module. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on November 28, 2020. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5 83 3.1. Binding DOTS Data and Signal Channels . . . . . . . . . . 5 84 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 85 3.2.1. Parameters and Behaviors . . . . . . . . . . . . . . 6 86 3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 10 87 3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 10 88 3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 10 89 4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 13 91 4.2. On-Demand Activation of an Accept-List Filter . . . . . . 18 92 4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 19 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 94 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 23 95 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 24 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 100 8.2. Informative References . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 1.1. The Problem 107 The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used 108 for bulk data exchange between DOTS agents to improve the 109 coordination of parties involved in the response to a Distributed 110 Denial-of-Service (DDoS) attack. Filter management is one of its 111 tasks which enables a DOTS client to retrieve the filtering 112 capabilities of a DOTS server and to manage filtering rules. 113 Typically, these Filtering rules are used for dropping or rate- 114 limiting unwanted traffic, and permitting accept-listed traffic. 116 Unlike the DOTS signal channel protocol 117 [I-D.ietf-dots-signal-channel], the DOTS data channel protocol is not 118 expected to deal with attack conditions. As such, an issue that 119 might be encountered in some deployments is when filters installed by 120 means of the DOTS data channel protocol may not function as expected 121 during DDoS attacks or, worse, exacerbate an ongoing DDoS attack. 122 The DOTS data channel protocol cannot be used then to change these 123 filters, which may complicate DDoS mitigation operations [Interop]. 125 A typical case is a DOTS client which configures during 'idle' time 126 (i.e., no mitigation is active) some filtering rules using the DOTS 127 data channel protocol to permit traffic from accept-listed sources, 128 but during a volumetric DDoS attack the DDoS mitigator identifies the 129 source addresses/prefixes in the accept-listed filtering rules are 130 attacking the target. For example, an attacker can spoof the IP 131 addresses of accept-listed sources to generate attack traffic or the 132 attacker can compromise the accept-listed sources and program them to 133 launch a DDoS attack. 135 [I-D.ietf-dots-signal-channel] is designed so that the DDoS server 136 notifies the conflict to the DOTS client (that is, 'conflict-cause' 137 parameter set to 2 (Conflicts with an existing accept list)), but the 138 DOTS client may not be able to withdraw the accept-list rules during 139 the attack period due to the high-volume attack traffic saturating 140 the inbound link to the DOTS client domain. In other words, the DOTS 141 client cannot use the DOTS data channel protocol to withdraw the 142 accept-list filters when a DDoS attack is in progress. 144 1.2. The Solution 146 This specification addresses the problems discussed in Section 1.1 by 147 adding a capability for managing filtering rules using the DOTS 148 signal channel protocol, which enables a DOTS client to request the 149 activation (or deactivation) of filtering rules during a DDoS attack. 151 The DOTS signal channel protocol is designed to enable a DOTS client 152 to contact a DOTS server for help even under severe network 153 congestion conditions. Therefore, extending the DOTS signal channel 154 protocol to manage the filtering rules during an attack will enhance 155 the protection capability offered by DOTS protocols. 157 Note: The experiment at the IETF103 hackathon [Interop] showed 158 that even when the inbound link is saturated by DDoS attack 159 traffic, the DOTS client can signal mitigation requests using the 160 DOTS signal channel over the saturated link. 162 Conflicts that are induced by filters installed by other DOTS clients 163 of the same domain are not discussed in this specification. 165 An augment to the DOTS signal channel YANG module is defined in 166 Section 3.2.2. 168 Sample examples are provided in Section 4, in particular: 170 o Section 4.1 illustrates how the filter control extension is used 171 when conflicts with Access Control Lists (ACLs) are detected and 172 reported by a DOTS server. 174 o Section 4.2 shows how a DOTS client can instruct a DOTS server to 175 safely forward some specific traffic in 'attack' time. 177 o Section 4.3 shows how a DOTS client can react if the DDoS traffic 178 is still being forwarded to the DOTS client domain even if 179 mitigation requests were sent to a DOTS server. 181 The JavaScript Object Notation (JSON) encoding of YANG-modeled data 182 [RFC7951] is used to illustrate the examples. 184 2. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 The reader should be familiar with the terms defined in [RFC8612]. 194 The terminology for describing YANG modules is defined in [RFC7950]. 195 The meaning of the symbols in the tree diagram is defined in 196 [RFC8340]. 198 3. Controlling Filtering Rules of a DOTS Client 200 3.1. Binding DOTS Data and Signal Channels 202 The filtering rules eventually managed using the DOTS signal channel 203 protocol are created a priori by the same DOTS client using the DOTS 204 data channel protocol. Managing conflicts with filters installed by 205 other DOTS clients of the same domain is out of scope. 207 As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a 208 DOTS client must use the same 'cuid' for both the DOTS signal and 209 data channels. This requirement is meant to facilitate binding DOTS 210 channels used by the same DOTS client. 212 The DOTS signal and data channels from a DOTS client may or may not 213 use the same DOTS server. Nevertheless, the scope of the mitigation 214 request, alias, and filtering rules are not restricted to the DOTS 215 server but to the DOTS server domain. To that aim, DOTS servers 216 within a domain are assumed to have a mechanism to coordinate the 217 mitigation requests, aliases, and filtering rules to coordinate their 218 decisions for better mitigation operation efficiency. The exact 219 details about such mechanism is out of the scope of this document. 221 A filtering rule controlled by the DOTS signal channel is identified 222 by its ACL name (Section 4.3 of [I-D.ietf-dots-data-channel]). Note 223 that an ACL name unambiguously identifies an ACL bound to a DOTS 224 client, but the same name may be used by distinct DOTS clients. 226 The activation or deactivation of an ACL by the DOTS signal channel 227 overrides the 'activation-type' (defined in Section 4.3 of 228 [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering 229 rules using the DOTS data channel protocol. 231 Once the attack is mitigated, the DOTS client may use the data 232 channel to control the 'activation-type' (e.g., revert to a default 233 value) of some of the filtering rules controlled by the DOTS signal 234 channel or delete some of these filters. This behavior is deployment 235 specific. 237 3.2. DOTS Signal Channel Extension 239 3.2.1. Parameters and Behaviors 241 This specification extends the mitigation request defined in 242 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 243 intended control of configured filtering rules. Concretely, the DOTS 244 client conveys 'acl-list' attribute with the following sub-attributes 245 in the CBOR body of a mitigation request (see the YANG structure in 246 Section 3.2.2.1): 248 acl-name: A name of an access list defined using the DOTS data 249 channel (Section 4.3 of [I-D.ietf-dots-data-channel]) that is 250 associated with the DOTS client. 252 As a reminder, an ACL is an ordered list of Access Control Entries 253 (ACE). Each Access Control Entry has a list of match criteria and 254 a list of actions [I-D.ietf-dots-data-channel]. The list of 255 configured ACLs can be retrieved using the DOTS data channel 256 during 'idle' time. 258 This is a mandatory attribute when 'acl-list' is included. 260 activation-type: Indicates the activation type of an ACL overriding 261 the existing 'activation-type' installed by the DOTS client using 262 the DOTS data channel. 264 As a reminder, this attribute can be set to 'deactivate', 265 'immediate', or 'activate-when-mitigating' as defined in 266 [I-D.ietf-dots-data-channel]. 268 Note that both 'immediate' and 'activate-when-mitigating' have an 269 immediate effect when a mitigation request is being processed by 270 the DOTS server. 272 This is an optional attribute. 274 The JSON/YANG mappings for DOTS filter control attributes are shown 275 in Table 1. 277 +-------------------+------------+--------+---------------+--------+ 278 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 279 | | Type | Key | Type & | Type | 280 | | | | Information | | 281 +-------------------+------------+--------+---------------+--------+ 282 |ietf-dots-signal- | | | | | 283 |control:activation-| | | | | 284 | type | enumeration| TBA1 | 0 unsigned | String | 285 | | | | | | 286 |ietf-dots-signal- | | | | | 287 | control:acl-list | list | TBA2 | 4 array | Array | 288 | | | | | | 289 |ietf-dots-signal- | | | | | 290 | control:acl-name | leafref | TBA3 | 3 text string | String | 291 +-------------------+------------+--------+---------------+--------+ 293 Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes 295 By default, ACL-related operations are achieved using the DOTS data 296 channel protocol when no attack is ongoing. DOTS clients MUST NOT 297 use the filtering control over DOTS signal channel in 'idle' time; 298 such requests MUST be discarded by DOTS servers with 4.00 (Bad 299 Request). 301 During an attack time, DOTS clients may include 'acl-list', 'acl- 302 name', and 'activation-type' attributes in a mitigation request. 303 This request may be the initial mitigation request for a given 304 mitigation scope or a new one overriding an existing request. In 305 both cases, a new 'mid' MUST be used. Nevertheless, it is NOT 306 RECOMMENDED to include ACL attributes in an initial mitigation 307 request for a given mitigation scope or in a mitigation request 308 adjusting the mitigation scope. This recommendation is meant to 309 avoid delaying attack mitigations because of failures to process ACL 310 attributes. 312 As the attack evolves, DOTS clients can adjust the 'activation-type' 313 of an ACL conveyed in a mitigation request or control other filters 314 as necessary. This can be achieved by sending a PUT request with a 315 new 'mid' value. 317 It is RECOMMENDED for a DOTS client to subscribe to asynchronous 318 notifications of the attack mitigation, as detailed in 319 Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the 320 polling mechanism in Section 4.4.2.2 of 321 [I-D.ietf-dots-signal-channel] has to be followed by the DOTS client. 323 A DOTS client relies on the information received from the DOTS server 324 and/or local information to the DOTS client domain to trigger a 325 filter control request. Only filters that are pertinent for an 326 ongoing mitigation should be controlled by a DOTS client using the 327 DOTS signal channel. 329 'acl-list', 'acl-name', and 'activation-type' are defined as 330 comprehension-required parameters (Section 5.1). Following the rules 331 in Section 6 of [I-D.ietf-dots-signal-channel], if the DOTS server 332 does not understand the 'acl-list' or 'acl-name' or 'activation-type' 333 attributes, it responds with a "4.00 (Bad Request)" error response 334 code. 336 If the DOTS server does not find the ACL name ('acl-name') conveyed 337 in the mitigation request for this DOTS client, it MUST respond with 338 4.04 (Not Found) error response code. 340 If the DOTS server finds the ACL name for this DOTS client, and 341 assuming the request passed the validation checks in Section 4.4.1 of 342 [I-D.ietf-dots-signal-channel], the DOTS server MUST proceed with the 343 'activation-type' update. The update is immediately enforced by the 344 DOTS server and will be maintained as the new activation type for the 345 ACL name even after the termination of the mitigation request. In 346 addition, the DOTS server MUST update the lifetime of the 347 corresponding ACL similar to the update when a refresh request is 348 received using the DOTS data channel (Section 7.2 of 349 [I-D.ietf-dots-data-channel]). If, for some reason, the DOTS server 350 fails to apply the filter update, it MUST respond with 5.03 (Service 351 Unavailable) error response code and include the failed ACL update in 352 the diagnostic payload of the response (an example is shown in 353 Figure 1). Else, the DOTS server replies with the appropriate 354 response code defined in Section 4.4.1 of 355 [I-D.ietf-dots-signal-channel]. 357 { 358 "ietf-dots-signal-channel:mitigation-scope": { 359 "scope": [ 360 { 361 "mid": 123, 362 "ietf-dots-signal-control:acl-list": [ 363 { 364 "ietf-dots-signal-control:acl-name": "an-accept-list", 365 "ietf-dots-signal-control:activation-type": "deactivate" 366 } 367 ] 368 } 369 ] 370 } 371 } 373 Figure 1: Example of a Diagnostic Payload Including Failed ACL Update 375 If the DOTS client receives a 5.03 (Service Unavailable) with a 376 diagnostic payload indicating a failed ACL update as a response to an 377 initial mitigation or a mitigation with adjusted scope, the DOTS 378 client MUST immediately send a new request which repeats all the 379 parameters as sent in the failed mitigation request but without 380 including the ACL attributes. After the expiry of Max-Age returned 381 in the 5.03 (Service Unavailable) response, the DOTS client retries 382 with a new mitigation request (i.e., a new 'mid') that repeats all 383 the parameters as sent in the failed mitigation request (i.e., the 384 one including the ACL attributes). 386 If, during an active mitigation, the 'activation-type' is changed at 387 the DOTS server (e.g., as a result of an external action) for an ACL 388 bound to a DOTS client, the DOTS server notifies that DOTS client 389 with the change by including the corresponding ACL parameters in an 390 asynchronous notification (the DOTS client is observing the active 391 mitigation) or in a response to a polling request (Section 4.4.2.2 of 392 [I-D.ietf-dots-signal-channel]). 394 If the DOTS signal and data channels of a DOTS client are not 395 established with the same DOTS server of a DOTS server domain, the 396 above request processing operations are undertaken using the 397 coordination mechanism discussed in Section 3.1. 399 This specification does not require any modification to the efficacy 400 update and the withdrawal procedures defined in 401 [I-D.ietf-dots-signal-channel]. In particular, ACL-related clauses 402 are not included in a PUT request used to send an efficacy update and 403 DELETE requests. 405 3.2.2. DOTS Signal Filtering Control Module 407 3.2.2.1. Tree Structure 409 This document augments the "ietf-dots-signal-channel" YANG module 410 defined in [I-D.ietf-dots-signal-channel] for managing filtering 411 rules. 413 This document defines the YANG module "ietf-dots-signal-control", 414 which has the following tree structure: 416 module: ietf-dots-signal-control 417 augment /ietf-signal:dots-signal/ietf-signal:message-type 418 /ietf-signal:mitigation-scope/ietf-signal:scope: 419 +--rw acl-list* [acl-name] {control-filtering}? 420 +--rw acl-name 421 | -> /ietf-data:dots-data/dots-client/acls/acl/name 422 +--rw activation-type? ietf-data:activation-type 424 3.2.2.2. YANG Module 426 This YANG module is not intended to be used via NETCONF/RESTCONF for 427 DOTS server management purposes; such module is out of the scope of 428 this document. It serves only to provide a data model and encoding, 429 but not a management data model. 431 This module uses types defined in [I-D.ietf-dots-data-channel]. 433 file "ietf-dots-signal-control@2019-05-13.yang" 435 module ietf-dots-signal-control { 436 yang-version 1.1; 437 namespace 438 "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; 439 prefix dots-control; 441 import ietf-dots-signal-channel { 442 prefix ietf-signal; 443 reference 444 "RFC 8782: Distributed Denial-of-Service Open Threat 445 Signaling (DOTS) Signal Channel Specification"; 446 } 447 import ietf-dots-data-channel { 448 prefix ietf-data; 449 reference 450 "RFC 8783: Distributed Denial-of-Service Open Threat 451 Signaling (DOTS) Data Channel Specification"; 453 } 455 organization 456 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 457 contact 458 "WG Web: 459 WG List: 461 Author: Kaname Nishizuka 462 464 Author: Mohamed Boucadair 465 467 Author: Konda, Tirumaleswar Reddy 468 470 Author: Takahiko Nagata 471 "; 473 description 474 "This module contains YANG definition for the signaling 475 messages exchanged between a DOTS client and a DOTS server 476 to control, by means of the DOTS signal channel, filtering 477 rules configured using the DOTS data channel. 479 Copyright (c) 2020 IETF Trust and the persons identified as 480 authors of the code. All rights reserved. 482 Redistribution and use in source and binary forms, with or 483 without modification, is permitted pursuant to, and subject 484 to the license terms contained in, the Simplified BSD License 485 set forth in Section 4.c of the IETF Trust's Legal Provisions 486 Relating to IETF Documents 487 (http://trustee.ietf.org/license-info). 489 This version of this YANG module is part of RFC XXXX; see 490 the RFC itself for full legal notices."; 492 revision 2019-05-13 { 493 description 494 "Initial revision."; 495 reference 496 "RFC XXXX: Controlling Filtering Rules Using Distributed 497 Denial-of-Service Open Threat Signaling (DOTS) 498 Signal Channel"; 499 } 500 feature control-filtering { 501 description 502 "This feature means that the DOTS signal channel is able 503 to manage the filtering rules created by the same DOTS 504 client using the DOTS data channel."; 505 } 507 augment "/ietf-signal:dots-signal/ietf-signal:message-type" 508 + "/ietf-signal:mitigation-scope/ietf-signal:scope" { 509 if-feature control-filtering; 511 description "ACL name and activation type."; 513 list acl-list { 514 key "acl-name"; 515 description 516 "List of ACLs as defined using the DOTS data 517 channel. ACLs bound to a DOTS client are uniquely 518 identified by a name."; 519 leaf acl-name { 520 type leafref { 521 path "/ietf-data:dots-data/ietf-data:dots-client" 522 + "/ietf-data:acls/ietf-data:acl/ietf-data:name"; 523 } 524 description 525 "Reference to the ACL name bound to a DOTS client."; 526 } 527 leaf activation-type { 528 type ietf-data:activation-type; 529 default "activate-when-mitigating"; 530 description 531 "Sets the activation type of an ACL."; 532 } 533 } 534 } 535 } 536 538 4. Some Examples 540 This section provides some examples to illustrate the behavior 541 specified in Section 3.2.1. These examples are provided for 542 illustration purposes; they should not be considered as deployment 543 recommendations. 545 4.1. Conflict Handling 547 Let's consider a DOTS client which contacts its DOTS server during 548 'idle' time to install an accept-list allowing for UDP traffic issued 549 from 2001:db8:1234::/48 with a destination port number 443 to be 550 forwarded to 2001:db8:6401::2/127. It does so by sending, for 551 example, a PUT request shown in Figure 2. 553 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 554 /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ 555 /acl=an-accept-list HTTP/1.1 556 Host: example.com 557 Content-Type: application/yang-data+json 559 { 560 "ietf-dots-data-channel:acls": { 561 "acl": [ 562 { 563 "name": "an-accept-list", 564 "type": "ipv6-acl-type", 565 "activation-type": "activate-when-mitigating", 566 "aces": { 567 "ace": [ 568 { 569 "name": "test-ace-ipv6-udp", 570 "matches": { 571 "ipv6": { 572 "destination-ipv6-network": "2001:db8:6401::2/127", 573 "source-ipv6-network": "2001:db8:1234::/48" 574 }, 575 "udp": { 576 "destination-port-range-or-operator": { 577 "operator": "eq", 578 "port": 443 579 } 580 } 581 }, 582 "actions": { 583 "forwarding": "accept" 584 } 585 } 586 ] 587 } 588 } 589 ] 590 } 591 } 593 Figure 2: DOTS Data Channel Request to Create a Filter 595 Some time later, consider that a DDoS attack is detected by the DOTS 596 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends 597 a mitigation request to its DOTS server as shown in Figure 3. 599 Header: PUT (Code=0.03) 600 Uri-Path: ".well-known" 601 Uri-Path: "dots" 602 Uri-Path: "mitigate" 603 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 604 Uri-Path: "mid=123" 605 Content-Format: "application/dots+cbor" 607 { 608 "ietf-dots-signal-channel:mitigation-scope": { 609 "scope": [ 610 { 611 "target-prefix": [ 612 "2001:db8:6401::2/127" 613 ], 614 "target-protocol": [ 615 17 616 ], 617 "lifetime": 3600 618 } 619 ] 620 } 621 } 623 Figure 3: DOTS Signal Channel Mitigation Request 625 The DOTS server accepts immediately the request by replying with 2.01 626 (Created) (Figure 4 depicts the message body of the response). 628 { 629 "ietf-dots-signal-channel:mitigation-scope": { 630 "scope": [ 631 { 632 "mid": 123, 633 "lifetime": 3600 634 } 635 ] 636 } 637 } 639 Figure 4: Status Response (Message Body) 641 Assuming the DOTS client subscribed to asynchronous notifications, 642 when the DOTS server concludes that some of the attack sources belong 643 to 2001:db8:1234::/48, it sends a notification message with 'status' 644 code set to '1 (Attack mitigation is in progress)' and 'conflict- 645 cause' set to '2' (conflict-with-acceptlist) to the DOTS client to 646 indicate that this mitigation request is in progress, but a conflict 647 is detected. 649 Upon receipt of the notification message from the DOTS server, the 650 DOTS client sends a PUT request to deactivate the "an-accept-list" 651 ACL as shown in Figure 5. 653 The DOTS client can also decide to send a PUT request to deactivate 654 the "an-accept-list" ACL, if suspect traffic is received from an 655 accept-listed source (2001:db8:1234::/48). The structure of that PUT 656 is the same as the one shown in Figure 5. 658 Header: PUT (Code=0.03) 659 Uri-Path: ".well-known" 660 Uri-Path: "dots" 661 Uri-Path: "mitigate" 662 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 663 Uri-Path: "mid=124" 664 Content-Format: "application/dots+cbor" 666 { 667 "ietf-dots-signal-channel:mitigation-scope": { 668 "scope": [ 669 { 670 "target-prefix": [ 671 "2001:db8:6401::2/127" 672 ], 673 "target-protocol": [ 674 17 675 ], 676 "ietf-dots-signal-control:acl-list": [ 677 { 678 "ietf-dots-signal-control:acl-name": "an-accept-list", 679 "ietf-dots-signal-control:activation-type": "deactivate" 680 } 681 ], 682 "lifetime": 3600 683 } 684 ] 685 } 686 } 688 Figure 5: PUT for Deactivating a Conflicting Filter 690 Then, the DOTS server deactivates "an-accept-list" ACL and replies 691 with 2.04 (Changed) response to the DOTS client to confirm the 692 successful operation. The message body is similar to the one 693 depicted in Figure 4. 695 Once the attack is mitigated, the DOTS client may use the data 696 channel to retrieve its ACLs maintained by the DOTS server. As shown 697 in Figure 6, the activation type is set to 'deactivate' as set by the 698 DOTS signal channel (Figure 5) instead of the type initially set 699 using the DOTS data channel (Figure 2). 701 { 702 "ietf-dots-data-channel:acls": { 703 "acl": [ 704 { 705 "name": "an-accept-list", 706 "type": "ipv6-acl-type", 707 "activation-type": "deactivate", 708 "pending-lifetime": 10021, 709 "aces": { 710 "ace": [ 711 { 712 "name": "test-ace-ipv6-udp", 713 "matches": { 714 "ipv6": { 715 "destination-ipv6-network": "2001:db8:6401::2/127", 716 "source-ipv6-network": "2001:db8:1234::/48" 717 }, 718 "udp": { 719 "destination-port-range-or-operator": { 720 "operator": "eq", 721 "port": 443 722 } 723 } 724 }, 725 "actions": { 726 "forwarding": "accept" 727 } 728 } 729 ] 730 } 731 } 732 ] 733 } 734 } 736 Figure 6: DOTS Data Channel GET Response after Mitigation (Message 737 Body) 739 4.2. On-Demand Activation of an Accept-List Filter 741 Let's consider a DOTS client which contacts its DOTS server during 742 'idle' time to install an accept-list allowing for UDP traffic issued 743 from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It 744 does so by sending, for example, a PUT request shown in Figure 7. 745 The DOTS server installs this filter with a "deactivated" state. 747 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 748 /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ 749 /acl=my-accept-list HTTP/1.1 750 Host: example.com 751 Content-Type: application/yang-data+json 753 { 754 "ietf-dots-data-channel:acls": { 755 "acl": [ 756 { 757 "name": "my-accept-list", 758 "type": "ipv6-acl-type", 759 "activation-type": "deactivate", 760 "aces": { 761 "ace": [ 762 { 763 "name": "an-ace", 764 "matches": { 765 "ipv6": { 766 "destination-ipv6-network": "2001:db8:6401::2/127", 767 "source-ipv6-network": "2001:db8:1234::/48", 768 "protocol": 17 769 } 770 }, 771 "actions": { 772 "forwarding": "accept" 773 } 774 } 775 ] 776 } 777 } 778 ] 779 } 780 } 782 Figure 7: DOTS Data Channel Request to Create an Accept-List Filter 784 Sometime later, consider that a UDP DDoS attack is detected by the 785 DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let 786 the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS 787 client domain. Consequently, the DOTS client sends a mitigation 788 request to its DOTS server as shown in Figure 8. 790 Header: PUT (Code=0.03) 791 Uri-Path: ".well-known" 792 Uri-Path: "dots" 793 Uri-Path: "mitigate" 794 Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" 795 Uri-Path: "mid=4879" 796 Content-Format: "application/dots+cbor" 798 { 799 "ietf-dots-signal-channel:mitigation-scope": { 800 "scope": [ 801 { 802 "target-prefix": [ 803 "2001:db8:6401::2/127" 804 ], 805 "target-protocol": [ 806 17 807 ], 808 "ietf-dots-signal-control:acl-list": [ 809 { 810 "ietf-dots-signal-control:acl-name": "my-accept-list", 811 "ietf-dots-signal-control:activation-type": "immediate" 812 } 813 ], 814 "lifetime": 3600 815 } 816 ] 817 } 818 } 820 Figure 8: DOTS Signal Channel Mitigation Request with a Filter 821 Control 823 The DOTS server activates "my-accept-list" ACL and replies with 2.01 824 (Created) response to the DOTS client to confirm the successful 825 operation. 827 4.3. DOTS Servers/Mitigators Lacking Capacity 829 This section describes a scenario in which a DOTS client activates a 830 drop-list or a rate-limit filter during an attack. 832 Consider a DOTS client that contacts its DOTS server during 'idle' 833 time to install an accept-list that rate-limits all (or a part 834 thereof) traffic to be forwarded to 2001:db8:123::/48 as a last 835 resort countermeasure whenever required. Installing the accept-list 836 can be done by sending, for example, the PUT request shown in 837 Figure 9. The DOTS server installs this filter with a "deactivated" 838 state. 840 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 841 /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ 842 /acl=my-ratelimit-list HTTP/1.1 843 Host: example.com 844 Content-Type: application/yang-data+json 846 { 847 "ietf-dots-data-channel:acls": { 848 "acl": [ 849 { 850 "name": "my-ratelimit-list", 851 "type": "ipv6-acl-type", 852 "activation-type": "deactivate", 853 "aces": { 854 "ace": [ 855 { 856 "name": "my-ace", 857 "matches": { 858 "ipv6": { 859 "destination-ipv6-network": "2001:db8:123::/48" 860 } 861 }, 862 "actions": { 863 "forwarding": "accept", 864 "rate-limit": "20000.00" 865 } 866 } 867 ] 868 } 869 } 870 ] 871 } 872 } 874 Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter 876 Consider now that a DDoS attack is detected by the DOTS client on 877 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 878 request to its DOTS server (Figure 10). 880 Header: PUT (Code=0.03) 881 Uri-Path: ".well-known" 882 Uri-Path: "dots" 883 Uri-Path: "mitigate" 884 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 885 Uri-Path: "mid=85" 886 Content-Format: "application/dots+cbor" 888 { 889 "ietf-dots-signal-channel:mitigation-scope": { 890 "scope": [ 891 { 892 "target-prefix": [ 893 "2001:db8:123::/48" 894 ], 895 "lifetime": 3600 896 } 897 ] 898 } 899 } 901 Figure 10: DOTS Signal Channel Mitigation Request 903 For some reason (e.g., the DOTS server, or the mitigator, is lacking 904 a capability or capacity), the DOTS client is still receiving attack 905 traffic which saturates available links. To soften the problem, the 906 DOTS client decides to activate the filter that rate-limits the 907 traffic destined to the DOTS client domain. To that aim, the DOTS 908 client sends the mitigation request to its DOTS server shown in 909 Figure 11. 911 Header: PUT (Code=0.03) 912 Uri-Path: ".well-known" 913 Uri-Path: "dots" 914 Uri-Path: "mitigate" 915 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 916 Uri-Path: "mid=86" 917 Content-Format: "application/dots+cbor" 919 { 920 "ietf-dots-signal-channel:mitigation-scope": { 921 "scope": [ 922 { 923 "target-prefix": [ 924 "2001:db8:123::/48" 925 ], 926 "ietf-dots-signal-control:acl-list": [ 927 { 928 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 929 "ietf-dots-signal-control:activation-type": "immediate" 930 } 931 ], 932 "lifetime": 3600 933 } 934 ] 935 } 936 } 938 Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate- 939 Limit Filter 941 Then, the DOTS server activates "my-ratelimit-list" ACL and replies 942 with 2.04 (Changed) response to the DOTS client to confirm the 943 successful operation. 945 As the attack mitigation evolves, the DOTS client may decide to 946 deactivate the rate-limit policy (e.g., upon receipt of notification 947 status change from 'attack-exceeded-capability' to 'attack- 948 mitigation-in-progress'). Based on the mitigation status conveyed by 949 the DOTS server, the DOTS client can de-activate the rate-limit 950 action. It does so by sending the request shown in Figure 12. 952 Header: PUT (Code=0.03) 953 Uri-Path: ".well-known" 954 Uri-Path: "dots" 955 Uri-Path: "mitigate" 956 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 957 Uri-Path: "mid=87" 958 Content-Format: "application/dots+cbor" 960 { 961 "ietf-dots-signal-channel:mitigation-scope": { 962 "scope": [ 963 { 964 "target-prefix": [ 965 "2001:db8:123::/48" 966 ], 967 "ietf-dots-signal-control:acl-list": [ 968 { 969 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 970 "ietf-dots-signal-control:activation-type": "deactivate" 971 } 972 ], 973 "lifetime": 3600 974 } 975 ] 976 } 977 } 979 Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a 980 Rate-Limit Filter 982 5. IANA Considerations 984 5.1. DOTS Signal Channel CBOR Mappings Registry 986 This specification registers the following parameters in the IANA 987 "DOTS Signal Channel CBOR Key Values" registry established by 988 [I-D.ietf-dots-signal-channel] 989 (https://www.iana.org/assignments/dots/dots.xhtml#dots-signal- 990 channel-cbor-key-values). 992 o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once the 993 CBOR keys are assigned from the 1-16383 range. Please update 994 Table 1 accordingly. 996 +--------------------+--------+-------+------------+---------------+ 997 | Parameter Name | CBOR | CBOR | Change | Specification | 998 | | Key | Major | Controller | Document(s) | 999 | | Value | Type | | | 1000 +--------------------+--------+-------+------------+---------------+ 1001 |ietf-dots-signal- | | | | | 1002 |control:activation- | 52 | | | | 1003 | type | (TBA1) | 0 | IESG | [RFCXXXX] | 1004 |ietf-dots-signal- | 53 | | | | 1005 | control:acl-list | (TBA2) | 4 | IESG | [RFCXXXX] | 1006 |ietf-dots-signal- | 54 | | | | 1007 | control:acl-name | (TBA3) | 3 | IESG | [RFCXXXX] | 1008 +--------------------+--------+-------+------------+---------------+ 1010 5.2. DOTS Signal Filtering Control YANG Module 1012 This document requests IANA to register the following URI in the "ns" 1013 subregistry within the "IETF XML Registry" [RFC3688]: 1015 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1016 Registrant Contact: The IESG. 1017 XML: N/A; the requested URI is an XML namespace. 1019 This document requests IANA to register the following YANG module in 1020 the "YANG Module Names" subregistry [RFC7950] within the "YANG 1021 Parameters" registry. 1023 Name: ietf-dots-signal-control 1024 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1025 Maintained by IANA: N 1026 Prefix: dots-control 1027 Reference: RFC XXXX 1029 6. Security Considerations 1031 The security considerations discussed in 1032 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need 1033 to be taken into account. 1035 This specification does not allow to create new filtering rules, 1036 which is the responsibility of the DOTS data channel. DOTS client 1037 domains should be adequately prepared prior to an attack, e.g., by 1038 creating filters that will be activated on demand when an attack is 1039 detected. 1041 A DOTS client is entitled to access only to resources it creates. In 1042 particular, a DOTS client can not tweak filtering rules created by 1043 other DOTS clients of the same DOTS client domain. As a reminder, 1044 DOTS servers must associate filtering rules with the DOTS client that 1045 created these resources. Failure to ensure such association by a 1046 DOTS server will have severe impact on DOTS client domains. 1048 A compromised DOTS client can use the filtering control capability to 1049 exacerbate an ongoing attack. Likewise, such a compromised DOTS 1050 client may abstain from reacting to an ACL conflict notification 1051 received from the DOTS server during attacks. These are not new 1052 attack vectors, but variations of threats discussed in 1053 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel]. 1054 DOTS operators should carefully monitor and audit DOTS agents to 1055 detect misbehaviors and to deter misuses. 1057 7. Acknowledgements 1059 Many thanks to Wei Pan, Xia Liang, Jon Shallow, and Dan Wing for the 1060 comments. 1062 Thanks to Benjamin Kaduk for the AD review. 1064 8. References 1066 8.1. Normative References 1068 [I-D.ietf-dots-data-channel] 1069 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 1070 Service Open Threat Signaling (DOTS) Data Channel 1071 Specification", draft-ietf-dots-data-channel-31 (work in 1072 progress), July 2019. 1074 [I-D.ietf-dots-signal-channel] 1075 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1076 N. Teague, "Distributed Denial-of-Service Open Threat 1077 Signaling (DOTS) Signal Channel Specification", draft- 1078 ietf-dots-signal-channel-41 (work in progress), January 1079 2020. 1081 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1082 Requirement Levels", BCP 14, RFC 2119, 1083 DOI 10.17487/RFC2119, March 1997, 1084 . 1086 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1087 DOI 10.17487/RFC3688, January 2004, 1088 . 1090 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1091 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1092 . 1094 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1095 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1096 May 2017, . 1098 8.2. Informative References 1100 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 1101 test report, IETF 103 Hackathon", November 2018, 1102 . 1106 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1107 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1108 . 1110 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1111 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1112 . 1114 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1115 Threat Signaling (DOTS) Requirements", RFC 8612, 1116 DOI 10.17487/RFC8612, May 2019, 1117 . 1119 Authors' Addresses 1121 Kaname Nishizuka 1122 NTT Communications 1123 GranPark 16F 3-4-1 Shibaura, Minato-ku 1124 Tokyo 108-8118 1125 Japan 1127 Email: kaname@nttv6.jp 1129 Mohamed Boucadair 1130 Orange 1131 Rennes 35000 1132 France 1134 Email: mohamed.boucadair@orange.com 1135 Tirumaleswar Reddy 1136 McAfee, Inc. 1137 Embassy Golf Link Business Park 1138 Bangalore, Karnataka 560071 1139 India 1141 Email: kondtir@gmail.com 1143 Takahiko Nagata 1144 Lepidum 1145 Japan 1147 Email: nagata@lepidum.co.jp