idnits 2.17.1 draft-nishizuka-dots-signal-control-filtering-05.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 ([I-D.ietf-dots-data-channel], [I-D.ietf-dots-signal-channel], [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 (March 8, 2019) is 1875 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 826, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-27 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-30 == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-20 Summary: 1 error (**), 0 flaws (~~), 5 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: September 9, 2019 Orange 6 T. Reddy 7 McAfee 8 T. Nagata 9 Lepidum 10 March 8, 2019 12 Controlling Filtering Rules Using DOTS Signal Channel 13 draft-nishizuka-dots-signal-control-filtering-05 15 Abstract 17 This document specifies an extension to the DOTS signal channel to 18 control the filtering rules when an attack mitigation is active. 20 Particularly, this extension allows a DOTS client to activate or de- 21 activate existing filtering rules during a DDoS attack. The 22 characterization of these filtering rules is supposed to be conveyed 23 by a DOTS client during peace time by means of DOTS data channel. 25 Editorial Note (To be removed by RFC Editor) 27 Please update these statements within the document with the RFC 28 number to be assigned to this document: 30 o "This version of this YANG module is part of RFC XXXX;" 32 o "RFC XXXX: Controlling Filtering Rules Using DOTS Signal Channel"; 34 o reference: RFC XXXX 36 o [RFCXXXX] 38 Please update these statements with the RFC number to be assigned to 39 the following documents: 41 o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling 42 (DOTS) Signal Channel Specification" (used to be 43 [I-D.ietf-dots-signal-channel]) 45 o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling 46 (DOTS) Data Channel Specification" (used to be 47 [I-D.ietf-dots-data-channel]) 49 Please update the "revision" date of the YANG module. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at https://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on September 9, 2019. 68 Copyright Notice 70 Copyright (c) 2019 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (https://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 88 2. Notational Conventions and Terminology . . . . . . . . . . . 4 89 3. Controlling Filtering Rules . . . . . . . . . . . . . . . . . 4 90 3.1. Binding the Data and Signal Channels . . . . . . . . . . 4 91 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 5 92 3.2.1. Filtering Control . . . . . . . . . . . . . . . . . . 5 93 3.2.2. Sample Examples . . . . . . . . . . . . . . . . . . . 7 94 3.2.2.1. Conflict Handling . . . . . . . . . . . . . . . . 7 95 3.2.2.2. Activate an Accept-List Filter . . . . . . . . . 11 96 3.2.2.3. Activate Rate-Limit or Drop Filters . . . . . . . 12 98 3.2.3. DOTS Signal Filtering Control Module . . . . . . . . 15 99 3.2.3.1. Tree Structure . . . . . . . . . . . . . . . . . 15 100 3.2.3.2. YANG Module . . . . . . . . . . . . . . . . . . . 16 101 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 102 4.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 19 103 4.2. DOTS Signal Control Filtering YANG Module . . . . . . . . 19 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 105 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 108 7.2. Informative References . . . . . . . . . . . . . . . . . 21 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 111 1. Introduction 113 1.1. The Problem 115 The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used 116 for bulk data exchange between DOTS agents to improve the 117 coordination of all the parties involved in the response to the DDoS 118 attack. Filter management is one of its tasks which enables a DOTS 119 client to retrieve DOTS server filtering capabilities and to manage 120 filtering rules. Filtering rules are used for dropping or rate- 121 limiting unwanted traffic, and permitting accept-listed traffic. 123 Unlike the DOTS signal channel, the DOTS data channel is not expected 124 to deal with attack conditions. As such, an issue that might be 125 encountered in some deployments is when filters installed by means of 126 DOTS data channel protocol may not function as expected during DDoS 127 attacks or exacerbate an ongoing DDoS attack. The DOTS data channel 128 cannot be used then to change these filters, which may complicate 129 DDoS mitigation operations [Interop]. 131 A typical case is a DOTS client which configures during 'idle' time 132 (i.e., no mitigation is active) filtering rules using DOTS data 133 channel to permit traffic from accept-listed sources, but during a 134 volumetric DDoS attack the DDoS mitigator identifies the source 135 addresses/prefixes in the accept-listed filtering rules are attacking 136 the target. For example, an attacker can spoof the IP addresses of 137 accept-listed sources to generate attack traffic or the attacker can 138 compromise the accept-listed sources and program them to launch DDoS 139 attack. 141 [I-D.ietf-dots-signal-channel] is designed so that the DDoS server 142 notifies the conflict to the DOTS client ('conflict-cause' set to 2 143 (Conflicts with an existing accept list)), but the DOTS client may 144 not be able to withdraw the accept-list rules during the attack 145 period due to the high-volume attack traffic saturating the inbound 146 link. In other words, the DOTS client cannot use the DOTS data 147 channel to withdraw the accept-list filters when the DDoS attack is 148 in progress. This assumes that this DOTS client is the owner of the 149 filtering rule. 151 1.2. The Solution 153 This specification addresses the problems discussed in Section 1.1 by 154 adding the capability of managing filtering rules using the DOTS 155 signal channel, which enables a DOTS client to request the activation 156 or de-activation of filtering rules during a DDoS attack. 158 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 159 designed to enable a DOTS client to contact a DOTS server for help 160 even under severe network congestion conditions. Therefore, 161 extending the DOTS signal channel protocol to manage the filtering 162 rules during a attack will enhance the protection capability offered 163 by DOTS protocols. Sample examples are provided in Section 3.2.2. 165 Note: The experiment at the IETF103 hackathon [Interop] showed 166 that even when the incoming link is saturated by DDoS attack 167 traffic, the DOTS client can signal mitigation requests using the 168 DOTS signal channel over the saturated link. 170 Conflicts that are induced by filters installed by other DOTS clients 171 of the same domain are not discussed in this specification. 173 2. Notational Conventions and Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 The reader should be familiar with the terms defined in 182 [I-D.ietf-dots-requirements]. 184 3. Controlling Filtering Rules 186 3.1. Binding the Data and Signal Channels 188 The filtering rules eventually managed using the DOTS signal channel 189 must be created a priori by the same DOTS client using the DOTS data 190 channel. Managing conflicts with filters installed by other DOTS 191 clients of the same domain is out of scope. 193 As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a 194 DOTS client must use the same 'cuid' for both the signal and data 195 channels. This requirement is meant to facilitate binding channels 196 used by the same DOTS client. 198 The DOTS signal and data channels from a DOTS client may or may not 199 use the same DOTS server. Nevertheless, the scope of the mitigation 200 request, alias, and filtering rules are not restricted to the DOTS 201 server but to the DOTS server domain. To that aim, DOTS servers 202 within a domain are assumed to have a mechanism to coordinate the 203 mitigation requests, aliases, and filtering rules to coordinate their 204 decisions for better mitigation operation efficiency. The exact 205 details about such mechanism is out of scope of this document. 207 A filtering rule controlled by the DOTS signal channel is identified 208 by its Access Control List (ACL) name. Note that an ACL name 209 unambiguously identifies an ACL bound to a DOTS client, but the same 210 name may be used by distinct DOTS clients. 212 The activation or de-activation of an ACL by the signal channel 213 overrides the 'activation-type' (defined in Section 7.2 214 [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering 215 rules using the DOTS data channel. 217 3.2. DOTS Signal Channel Extension 219 3.2.1. Filtering Control 221 This specification extends the mitigation request defined in 222 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 223 intended control of the configured filtering rules. The DOTS client 224 conveys the following parameters in the CBOR body of the mitigation 225 request: 227 acl-name: A name of an access list defined in the data channel. 229 As a reminder, an ACL is an ordered list of Access Control Entries 230 (ACE). Each Access Control Entry has a list of match criteria and 231 a list of actions [I-D.ietf-dots-data-channel]. The list of 232 configured ACLs can be retrieved using the DOTS data channel 233 during 'idle' time. 235 This is an optional attribute. 237 activation-type: Indicates the activation type of an ACL overriding 238 the existing 'activation-type' installed by the DOTS client using 239 the DOTS data channel. 241 This attribute can be set to 'deactivate', 'immediate', or 242 'activate-when-mitigating' defined [I-D.ietf-dots-data-channel]. 244 Note that both 'immediate' and 'activate-when-mitigating' have an 245 immediate effect when a mitigation request is being processed by 246 the DOTS server. 248 If this attribute is not provided, the DOTS server MUST use 249 'activate-when-mitigating' as the default value. 251 This is an optional attribute. 253 The JSON/YANG mapping to CBOR for 'activation-type' is shown in 254 Table 1. 256 +-------------------+------------+--------+---------------+--------+ 257 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 258 | | Type | Key | Type & | Type | 259 | | | | Information | | 260 +-------------------+------------+--------+---------------+--------+ 261 | activation-type | enumeration| 0x0031 | 0 unsigned | String | 262 | | | (TBD1) | | | 263 +-------------------+------------+--------+---------------+--------+ 265 Table 1: JSON/YANG mapping to CBOR for 'activation-type' 267 When acl-* attributes are to be included in a request with an 268 existing 'mid', the DOTS client MUST repeat all the other parameters 269 as sent in the original mitigation request (i.e., having that 'mid') 270 apart from a possible change to the lifetime parameter value. 272 If the DOTS server does not find the ACL name conveyed in the 273 mitigation request in its configuration data for this DOTS client, it 274 MUST respond with a "4.04 (Not Found)" error response code. 276 It is RECOMMENDED for a DOTS client to subscribe to asynchronous 277 notifications of the attack mitigation, as detailed in 278 Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the 279 polling mechanism in Section 4.4.2.2 of 280 [I-D.ietf-dots-signal-channel] has to be followed by the DOTS client. 282 A DOTS client MUST NOT use the filtering control over DOTS signal 283 channel if no attack (mitigation) is active; such requests MUST be 284 discarded by the DOTS server with 4.00 (Bad Request). By default, 285 ACL-related operations are achieved using the DOTS data channel 286 [I-D.ietf-dots-data-channel] when no attack is ongoing. 288 A DOTS client relies on the information received from the DOTS server 289 and/or local information to the DOTS client domain to trigger a 290 filter control request. Obviously, only filters that are pertinent 291 for an ongoing mitigation should be controlled by a DOTS client using 292 the DOTS signal channel. 294 This specification does not require any modification to the efficacy 295 update, the retrieval of mitigation requests, and the withdrawal 296 procedures defined in [I-D.ietf-dots-signal-channel]. In particular, 297 ACL-related clauses are not included in a PUT request used to send an 298 efficacy update, GET responses, and DELETE requests. 300 3.2.2. Sample Examples 302 This section provides sample examples to illustrate the behavior 303 specified in Section 3.2.1. These examples are provided for 304 illustration purposes; they should not be considered as deployment 305 recommendations. 307 3.2.2.1. Conflict Handling 309 Let's consider a DOTS client which contacts its DOTS server during 310 'idle' time to install an accept-list allowing for UDP traffic issued 311 from 2001:db8:1234::/48 with a destination port number 443 to be 312 forwarded to 2001:db8:6401::2/127. It does so by sending, for 313 example, a PUT request shown in Figure 1. 315 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 316 /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ 317 /acl=an-accept-list HTTP/1.1 318 Host: {host}:{port} 319 Content-Type: application/yang-data+json 320 { 321 "ietf-dots-data-channel:acls": { 322 "acl": [ 323 { 324 "name": "an-accept-list", 325 "type": "ipv6-acl-type", 326 "activation-type": "activate-when-mitigating", 327 "aces": { 328 "ace": [ 329 { 330 "name": "test-ace-ipv6-udp", 331 "matches": { 332 "ipv6": { 333 "destination-ipv6-network": "2001:db8:6401::2/127", 334 "source-ipv6-network": "2001:db8:1234::/48" 335 }, 336 "udp": { 337 "destination-port": { 338 "operator": "eq", 339 "port": 443 340 } 341 } 342 }, 343 "actions": { 344 "forwarding": "accept" 345 } 346 } 347 ] 348 } 349 } 350 ] 351 } 352 } 354 Figure 1: DOTS Data Channel Request to Create a Filtering 356 Some time later, consider that a DDoS attack is detected by the DOTS 357 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends 358 a mitigation request to its DOTS server as shown in Figure 2. 360 Header: PUT (Code=0.03) 361 Uri-Path: ".well-known" 362 Uri-Path: "dots" 363 Uri-Path: "mitigate" 364 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 365 Uri-Path: "mid=123" 366 Content-Format: "application/dots+cbor" 367 { 368 "ietf-dots-signal-channel:mitigation-scope": { 369 "scope": [ 370 { 371 "target-prefix": [ 372 "2001:db8:6401::2/127" 373 ], 374 "target-protocol": [ 375 17 376 ], 377 "lifetime": 3600 378 } 379 ] 380 } 381 } 383 Figure 2: DOTS Signal Channel Mitigation Request 385 The DOTS server accepts immediately the request by replying with 2.01 386 (Created) (Figure 3). 388 { 389 "ietf-dots-signal-channel:mitigation-scope": { 390 "scope": [ 391 { 392 "mid": 123, 393 "lifetime": 3600 394 } 395 ] 396 } 397 } 399 Figure 3: Status Response 401 Assuming the DOTS client subscribed to asynchronous notifications, 402 when the DOTS server concludes that some of the attack sources belong 403 to 2001:db8:1234::/48, it sends a notification message with 'status' 404 code set to '1 (Attack mitigation is in progress)' and 'conflict- 405 cause' set to '2' (conflict-with-acceptlist) to the DOTS client to 406 indicate that this mitigation request is in progress, but a conflict 407 is detected. 409 Upon receipt of the notification message from the DOTS server, the 410 DOTS client sends a PUT request to deactivate the "an-accept-list" 411 ACL as shown in Figure 4. 413 The DOTS client can also decide to send a PUT request to deactivate 414 the "an-accept-list" ACL, if suspect traffic is received from an 415 accept-listed source (2001:db8:1234::/48). The structure of that PUT 416 is the same as the one shown in Figure 4. 418 Header: PUT (Code=0.03) 419 Uri-Path: ".well-known" 420 Uri-Path: "dots" 421 Uri-Path: "mitigate" 422 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 423 Uri-Path: "mid=123" 424 Content-Format: "application/dots+cbor" 425 { 426 "ietf-dots-signal-channel:mitigation-scope": { 427 "scope": [ 428 { 429 "target-prefix": [ 430 "2001:db8:6401::2/127" 431 ], 432 "target-protocol": [ 433 17 434 ], 435 "acl-list": [ 436 { 437 "acl-name": "an-accept-list", 438 "activation-type": "deactivate" 439 } 440 ] 441 "lifetime": 3600 442 } 443 ] 444 } 445 } 447 Figure 4: PUT for Deactivating a Conflicting Filter 449 Then, the DOTS server deactivates "an-accept-list" ACL and replies 450 with 2.04 (Changed) response to the DOTS client to confirm the 451 successful operation. 453 3.2.2.2. Activate an Accept-List Filter 455 Let's consider a DOTS client which contacts its DOTS server during 456 'idle' time to install an accept-list allowing for UDP traffic issued 457 from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It 458 does so by sending, for example, a PUT request shown in Figure 5. 459 The DOTS server installs this filter with a "deactivated" state. 461 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 462 /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ 463 /acl=my-accept-list HTTP/1.1 464 Host: {host}:{port} 465 Content-Type: application/yang-data+json 466 { 467 "ietf-dots-data-channel:acls": { 468 "acl": [ 469 { 470 "name": "my-accept-list", 471 "type": "ipv6-acl-type", 472 "activation-type": "deactivate", 473 "aces": { 474 "ace": [ 475 { 476 "name": "an-ace", 477 "matches": { 478 "ipv6": { 479 "destination-ipv6-network": "2001:db8:6401::2/127", 480 "source-ipv6-network": "2001:db8:1234::/48", 481 "protocol": 17 482 } 483 }, 484 "actions": { 485 "forwarding": "accept" 486 } 487 } 488 ] 489 } 490 } 491 ] 492 } 493 } 495 Figure 5: DOTS Data Channel Request to Create an Accep-List Filter 497 Sometime later, consider that a UDP DDoS attack is detected by the 498 DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let 499 the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS 500 client domain. Consequently, the DOTS client sends a mitigation 501 request to its DOTS server as shown in Figure 6. 503 Header: PUT (Code=0.03) 504 Uri-Path: ".well-known" 505 Uri-Path: "dots" 506 Uri-Path: "mitigate" 507 Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" 508 Uri-Path: "mid=4879" 509 Content-Format: "application/dots+cbor" 510 { 511 "ietf-dots-signal-channel:mitigation-scope": { 512 "scope": [ 513 { 514 "target-prefix": [ 515 "2001:db8:6401::2/127" 516 ], 517 "target-protocol": [ 518 17 519 ], 520 "acl-list": [ 521 { 522 "acl-name": "my-accept-list", 523 "activation-type": "immediate" 524 } 525 "lifetime": 3600 526 } 527 ] 528 } 529 } 531 Figure 6: DOTS Signal Channel Mitigation Request with a Filter 532 Control 534 The DOTS server activates "my-accept-list" ACL and replies with 2.01 535 (Created) response to the DOTS client to confirm the successful 536 operation. 538 3.2.2.3. Activate Rate-Limit or Drop Filters 540 This section describes a scenario in which a DOTS client activates a 541 drop-list or a rate-limit filter during an attack. 543 Consider a DOTS client that contacts its DOTS server during 'idle' 544 time to install an accept-list that rate-limits all (or a part 545 thereof) traffic to be forwarded to 2001:db8:123::/48 as a last 546 resort countermeasure whenever required. It does so by sending, for 547 example, a PUT request shown in Figure 7. The DOTS server installs 548 this filter with a "deactivated" state. 550 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 551 /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ 552 /acl=my-ratelimit-list HTTP/1.1 553 Host: {host}:{port} 554 Content-Type: application/yang-data+json 555 { 556 "ietf-dots-data-channel:acls": { 557 "acl": [ 558 { 559 "name": "my-ratelimit-list", 560 "type": "ipv6-acl-type", 561 "activation-type": "deactivate", 562 "aces": { 563 "ace": [ 564 { 565 "name": "my-ace", 566 "matches": { 567 "ipv6": { 568 "destination-ipv6-network": "2001:db8:123::/48" 569 } 570 }, 571 "actions": { 572 "forwarding": "accept", 573 "rate-limit": "20.00" 574 } 575 } 576 ] 577 } 578 } 579 ] 580 } 581 } 583 Figure 7: DOTS Data Channel Request to Create a Rate-Limit Filter 585 Consider now that a DDoS attack is detected by the DOTS client on 586 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 587 request to its DOTS server (Figure 8). 589 Header: PUT (Code=0.03) 590 Uri-Path: ".well-known" 591 Uri-Path: "dots" 592 Uri-Path: "mitigate" 593 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 594 Uri-Path: "mid=85" 595 Content-Format: "application/dots+cbor" 596 { 597 "ietf-dots-signal-channel:mitigation-scope": { 598 "scope": [ 599 { 600 "target-prefix": [ 601 "2001:db8:123::/48" 602 ], 603 "lifetime": 3600 604 } 605 ] 606 } 607 } 609 Figure 8: DOTS Signal Channel Mitigation Request to Activate a Rate- 610 Limit Filter 612 For some reason (e.g., the DOTS server, or the mitigator, is lacking 613 a capability or capacity), the DOTS client is still receiving the 614 attack trafic which saturates available links. To soften the 615 problem, the DOTS client decides to activate the filter that rate- 616 limits the traffic destined to the DOTS client domain. To that aim, 617 the DOTS client sends the mitigation request to its DOTS server shown 618 in Figure 9. 620 Header: PUT (Code=0.03) 621 Uri-Path: ".well-known" 622 Uri-Path: "dots" 623 Uri-Path: "mitigate" 624 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 625 Uri-Path: "mid=85" 626 Content-Format: "application/dots+cbor" 627 { 628 "ietf-dots-signal-channel:mitigation-scope": { 629 "scope": [ 630 { 631 "target-prefix": [ 632 "2001:db8:123::/48" 633 ], 634 "acl-list": [ 635 { 636 "acl-name": "my-ratelimit-list", 637 "activation-type": "activate" 638 } 639 ] 640 "lifetime": 3600 641 } 642 ] 643 } 644 } 646 Figure 9: DOTS Signal Channel Mitigation Request to Activate a Rate- 647 Limit Filter 649 Then, the DOTS server activates "my-ratelimit-list" ACL and replies 650 with 2.04 (Changed) response to the DOTS client to confirm the 651 successful operation. 653 3.2.3. DOTS Signal Filtering Control Module 655 3.2.3.1. Tree Structure 657 This document augments the "dots-signal-channel" DOTS signal YANG 658 module defined in [I-D.ietf-dots-signal-channel] for managing the 659 filtering rules. 661 This document defines the YANG module "ietf-dots-signal-control- 662 filter", which has the following tree structure: 664 module: ietf-dots-signal-control-filter 665 augment /ietf-signal:dots-signal/ietf-signal:message-type 666 /ietf-signal:mitigation-scope/ietf-signal:scope: 667 +--rw acl-list* [acl-name] {control-filtering}? 668 +--rw acl-name 669 | -> /ietf-data:dots-data/dots-client/acls/acl/name 670 +--rw activation-type? activation-type 672 3.2.3.2. YANG Module 674 file "ietf-dots-signal-control-filter@2019-02-15.yang" 676 module ietf-dots-signal-control-filter { 677 yang-version 1.1; 678 namespace 679 "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter"; 680 prefix signal-control-filter; 682 import ietf-dots-signal-channel { 683 prefix ietf-signal; 684 reference 685 "RFC SSSS: Distributed Denial-of-Service Open Threat 686 Signaling (DOTS) Signal Channel Specification"; 687 } 688 import ietf-dots-data-channel { 689 prefix ietf-data; 690 reference 691 "RFC DDDD: Distributed Denial-of-Service Open Threat 692 Signaling (DOTS) Data Channel Specification"; 693 } 695 organization 696 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 697 contact 698 "WG Web: 699 WG List: 701 Author: Konda, Tirumaleswar Reddy 702 704 Author: Mohamed Boucadair 705 707 Author: Kaname Nishizuka 708 710 Author: Takahiko Nagata 711 "; 713 description 714 "This module contains YANG definition for the signaling 715 messages exchanged between a DOTS client and a DOTS server 716 for the DOTS signal channel controlling the filtering rules 717 configured using the DOTS data channel. 719 Copyright (c) 2019 IETF Trust and the persons identified as 720 authors of the code. All rights reserved. 722 Redistribution and use in source and binary forms, with or 723 without modification, is permitted pursuant to, and subject 724 to the license terms contained in, the Simplified BSD License 725 set forth in Section 4.c of the IETF Trust's Legal Provisions 726 Relating to IETF Documents 727 (http://trustee.ietf.org/license-info). 729 This version of this YANG module is part of RFC XXXX; see 730 the RFC itself for full legal notices."; 732 revision 2019-02-15 { 733 description 734 "Initial revision."; 735 reference 736 "RFC XXXX: Controlling Filtering Rules Using DOTS Signal 737 Channel "; 738 } 740 feature control-filtering { 741 description 742 "This feature means that DOTS signal channel is able to 743 manage the filtering rules created by the same DOTS 744 client using the DOTS data channel."; 745 } 747 typedef activation-type { 748 type enumeration { 749 enum "activate-when-mitigating" { 750 value 1; 751 description 752 "The ACL is installed only when a mitigation is active. 753 The ACL is specific to this DOTS client."; 754 } 755 enum "immediate" { 756 value 2; 757 description 758 "The ACL is immediately activated."; 760 } 761 enum "deactivate" { 762 value 3; 763 description 764 "The ACL is maintained by the DOTS server, but it is 765 deactivated."; 766 } 767 } 768 description 769 "Set the activation type of an ACL."; 770 } 772 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" + 773 "ietf-signal:mitigation-scope/ietf-signal:scope" { 774 if-feature control-filtering; 776 description "ACL name and activation type"; 778 list acl-list { 779 key "acl-name"; 780 description 781 "List of ACLs as defined in the DOTS data 782 channel. These ACLs are uniquely defined by 783 cuid and name."; 784 leaf acl-name { 785 type leafref { 786 path "/ietf-data:dots-data/ietf-data:dots-client/" + 787 "ietf-data:acls/ietf-data:acl/ietf-data:name"; 788 } 789 description 790 "Reference to the ACL name bound to a DOTS client."; 791 } 792 leaf activation-type { 793 type activation-type; 794 default activate-when-mitigating; 795 description 796 "Set the activation type of an ACL."; 797 } 798 } 799 } 800 } 801 803 4. IANA Considerations 804 4.1. DOTS Signal Channel CBOR Mappings Registry 806 This specification registers the 'activation-type' parameter in the 807 IANA "DOTS Signal Channel CBOR Key Values" registry established by 808 [I-D.ietf-dots-signal-channel]. 810 The 'activation-type' is a comprehension-required parameter. The 811 'acl-list' and 'acl-name' parameters are defined as comprehension- 812 required parameters in Table 6 in [I-D.ietf-dots-signal-channel]. 813 Following the rules in [I-D.ietf-dots-signal-channel], if the DOTS 814 server does not understand the 'acl-list' or 'acl-name' or 815 'activation-type' attributes, it responds with a "4.00 (Bad Request)" 816 error response code. 818 o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is 819 assigned from the (0x0001 - 0x3FFF) range. 821 +--------------------+--------+-------+------------+---------------+ 822 | Parameter Name | CBOR | CBOR | Change | Specification | 823 | | Key | Major | Controller | Document(s) | 824 | | Value | Type | | | 825 +--------------------+--------+-------+------------+---------------+ 826 | activation-type | 0x0031 | 0 | IESG | [RFCXXXX] | 827 | | (TBD1) | | | | 828 +--------------------+--------+-------+------------+---------------+ 830 4.2. DOTS Signal Control Filtering YANG Module 832 This document requests IANA to register the following URI in the 833 "IETF XML Registry" [RFC3688]: 835 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter 836 Registrant Contact: The IESG. 837 XML: N/A; the requested URI is an XML namespace. 839 This document requests IANA to register the following YANG module in 840 the "YANG Module Names" registry [RFC7950]. 842 name: ietf-dots-signal-control-filter 843 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control-filter 844 maintained by IANA: N 845 prefix: signal-control-filter 846 reference: RFC XXXX 848 5. Security Considerations 850 The security considerations discussed in 851 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need 852 to be taken into account. 854 6. Acknowledgements 856 Thank you to Takahiko Nagata, Wei Pan, and Xia Liang for the 857 comments. 859 7. References 861 7.1. Normative References 863 [I-D.ietf-dots-data-channel] 864 Boucadair, M. and R. K, "Distributed Denial-of-Service 865 Open Threat Signaling (DOTS) Data Channel Specification", 866 draft-ietf-dots-data-channel-27 (work in progress), 867 February 2019. 869 [I-D.ietf-dots-signal-channel] 870 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 871 Teague, "Distributed Denial-of-Service Open Threat 872 Signaling (DOTS) Signal Channel Specification", draft- 873 ietf-dots-signal-channel-30 (work in progress), March 874 2019. 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 882 DOI 10.17487/RFC3688, January 2004, 883 . 885 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 886 RFC 7950, DOI 10.17487/RFC7950, August 2016, 887 . 889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 891 May 2017, . 893 7.2. Informative References 895 [I-D.ietf-dots-requirements] 896 Mortensen, A., K, R., and R. Moskowitz, "Distributed 897 Denial of Service (DDoS) Open Threat Signaling 898 Requirements", draft-ietf-dots-requirements-20 (work in 899 progress), February 2019. 901 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 902 test report, IETF 103 Hackathon", November 2018, 903 . 907 Authors' Addresses 909 Kaname Nishizuka 910 NTT Communications 911 GranPark 16F 3-4-1 Shibaura, Minato-ku 912 Tokyo 108-8118 913 Japan 915 Email: kaname@nttv6.jp 917 Mohamed Boucadair 918 Orange 919 Rennes 35000 920 France 922 Email: mohamed.boucadair@orange.com 924 Tirumaleswar Reddy 925 McAfee, Inc. 926 Embassy Golf Link Business Park 927 Bangalore, Karnataka 560071 928 India 930 Email: kondtir@gmail.com 932 Takahiko Nagata 933 Lepidum 934 Japan 936 Email: nagata@lepidum.co.jp