idnits 2.17.1 draft-ietf-dots-signal-filter-control-02.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 (September 16, 2019) is 1684 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 995, but not defined == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-37 Summary: 1 error (**), 0 flaws (~~), 3 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: March 19, 2020 Orange 6 T. Reddy 7 McAfee 8 T. Nagata 9 Lepidum 10 September 16, 2019 12 Controlling Filtering Rules Using Distributed Denial-of-Service Open 13 Threat Signaling (DOTS) Signal Channel 14 draft-ietf-dots-signal-filter-control-02 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 these statements with the RFC number to be assigned to 43 the following documents: 45 o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling 46 (DOTS) Signal Channel Specification" (used to be 47 [I-D.ietf-dots-signal-channel]) 49 o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling 50 (DOTS) Data Channel Specification" (used to be 51 [I-D.ietf-dots-data-channel]) 53 Please update the "revision" date of the YANG module. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on March 19, 2020. 72 Copyright Notice 74 Copyright (c) 2019 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 92 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 93 3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5 94 3.1. Binding DOTS Data and Signal Channels . . . . . . . . . . 5 95 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 96 3.2.1. Parameters and Behaviors . . . . . . . . . . . . . . 6 97 3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 9 98 3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 9 99 3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 10 100 4. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 12 101 4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 12 102 4.2. On-Demand Activation of an Accept-List Filter . . . . . . 17 103 4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 18 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 22 106 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 23 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 8.2. Informative References . . . . . . . . . . . . . . . . . 24 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 114 1. Introduction 116 1.1. The Problem 118 The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used 119 for bulk data exchange between DOTS agents to improve the 120 coordination of parties involved in the response to the Distributed 121 Denial-of-Service (DDoS) attack. Filter management is one of its 122 tasks which enables a DOTS client to retrieve the filtering 123 capabilities of a DOTS server and to manage filtering rules. 124 Typically, these Filtering rules are used for dropping or rate- 125 limiting unwanted traffic, and permitting accept-listed traffic. 127 Unlike the DOTS signal channel protocol 128 [I-D.ietf-dots-signal-channel], the DOTS data channel protocol is not 129 expected to deal with attack conditions. As such, an issue that 130 might be encountered in some deployments is when filters installed by 131 means of the DOTS data channel protocol may not function as expected 132 during DDoS attacks or, worse, exacerbate an ongoing DDoS attack. 133 The DOTS data channel protocol cannot be used then to change these 134 filters, which may complicate DDoS mitigation operations [Interop]. 136 A typical case is a DOTS client which configures during 'idle' time 137 (i.e., no mitigation is active) some filtering rules using the DOTS 138 data channel protocol to permit traffic from accept-listed sources, 139 but during a volumetric DDoS attack the DDoS mitigator identifies the 140 source addresses/prefixes in the accept-listed filtering rules are 141 attacking the target. For example, an attacker can spoof the IP 142 addresses of accept-listed sources to generate attack traffic or the 143 attacker can compromise the accept-listed sources and program them to 144 launch a DDoS attack. 146 [I-D.ietf-dots-signal-channel] is designed so that the DDoS server 147 notifies the conflict to the DOTS client (that is, 'conflict-cause' 148 parameter set to 2 (Conflicts with an existing accept list)), but the 149 DOTS client may not be able to withdraw the accept-list rules during 150 the attack period due to the high-volume attack traffic saturating 151 the inbound link to the DOTS client domain. In other words, the DOTS 152 client cannot use the DOTS data channel protocol to withdraw the 153 accept-list filters when a DDoS attack is in progress. This assumes 154 that this DOTS client is the owner of the filtering rule. 156 1.2. The Solution 158 This specification addresses the problems discussed in Section 1.1 by 159 adding the capability of managing filtering rules using the DOTS 160 signal channel protocol, which enables a DOTS client to request the 161 activation (or deactivation) of filtering rules during a DDoS attack. 163 The DOTS signal channel protocol is designed to enable a DOTS client 164 to contact a DOTS server for help even under severe network 165 congestion conditions. Therefore, extending the DOTS signal channel 166 protocol to manage the filtering rules during an attack will enhance 167 the protection capability offered by DOTS protocols. 169 Note: The experiment at the IETF103 hackathon [Interop] showed 170 that even when the inbound link is saturated by DDoS attack 171 traffic, the DOTS client can signal mitigation requests using the 172 DOTS signal channel over the saturated link. 174 Conflicts that are induced by filters installed by other DOTS clients 175 of the same domain are not discussed in this specification. 177 An augment to the DOTS signal channel YANG module is defined in 178 Section 3.2.2. 180 Sample examples are provided in Section 4, in particular: 182 o Section 4.1 illustrates how the filter control extension is used 183 when conflicts with Access Control List (ACLs) are detected and 184 reported by a DOTS server. 186 o Section 4.2 shows how a DOTS client can instruct a DOTS server to 187 safely forward some specific traffic in 'attack' time. 189 o Section 4.3 shows how a DOTS client can react if the DDoS traffic 190 is still being forwarded to the DOTS client domain even if 191 mitigation requests were sent to a DOTS server. 193 The JavaScript Object Notation (JSON) encoding of YANG-modeled data 194 [RFC7951] is used to illustrate the examples. 196 2. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 The reader should be familiar with the terms defined in [RFC8612]. 206 The terminology for describing YANG modules is defined in [RFC7950]. 207 The meaning of the symbols in the tree diagram is defined in 208 [RFC8340]. 210 3. Controlling Filtering Rules of a DOTS Client 212 3.1. Binding DOTS Data and Signal Channels 214 The filtering rules eventually managed using the DOTS signal channel 215 protocol are created a priori by the same DOTS client using the DOTS 216 data channel protocol. Managing conflicts with filters installed by 217 other DOTS clients of the same domain is out of scope. 219 As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a 220 DOTS client must use the same 'cuid' for both the DOTS signal and 221 data channels. This requirement is meant to facilitate binding DOTS 222 channels used by the same DOTS client. 224 The DOTS signal and data channels from a DOTS client may or may not 225 use the same DOTS server. Nevertheless, the scope of the mitigation 226 request, alias, and filtering rules are not restricted to the DOTS 227 server but to the DOTS server domain. To that aim, DOTS servers 228 within a domain are assumed to have a mechanism to coordinate the 229 mitigation requests, aliases, and filtering rules to coordinate their 230 decisions for better mitigation operation efficiency. The exact 231 details about such mechanism is out of the scope of this document. 233 A filtering rule controlled by the DOTS signal channel is identified 234 by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). Note 235 that an ACL name unambiguously identifies an ACL bound to a DOTS 236 client, but the same name may be used by distinct DOTS clients. 238 The activation or deactivation of an ACL by the DOTS signal channel 239 overrides the 'activation-type' (defined in Section 7.2 of 241 [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering 242 rules using the DOTS data channel protocol. 244 3.2. DOTS Signal Channel Extension 246 3.2.1. Parameters and Behaviors 248 This specification extends the mitigation request defined in 249 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 250 intended control of configured filtering rules. Concretely, the DOTS 251 client conveys 'acl-list' attribute with the following sub-attributes 252 in the CBOR body of a mitigation request (see the YANG-encoded 253 structure in Section 3.2.2.1): 255 acl-name: A name of an access list defined using the DOTS data 256 channel (Section 7.2 of [I-D.ietf-dots-data-channel]) that is 257 associated with the DOTS client. 259 As a reminder, an ACL is an ordered list of Access Control Entries 260 (ACE). Each Access Control Entry has a list of match criteria and 261 a list of actions [I-D.ietf-dots-data-channel]. The list of 262 configured ACLs can be retrieved using the DOTS data channel 263 during 'idle' time. 265 This is an optional attribute. 267 activation-type: Indicates the activation type of an ACL overriding 268 the existing 'activation-type' installed by the DOTS client using 269 the DOTS data channel. 271 As a reminder, this attribute can be set to 'deactivate', 272 'immediate', or 'activate-when-mitigating' as defined in 273 [I-D.ietf-dots-data-channel]. 275 Note that both 'immediate' and 'activate-when-mitigating' have an 276 immediate effect when a mitigation request is being processed by 277 the DOTS server. 279 This is an optional attribute. 281 The JSON/YANG mapping to CBOR for 'activation-type' is shown in 282 Table 1. 284 +-------------------+------------+--------+---------------+--------+ 285 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 286 | | Type | Key | Type & | Type | 287 | | | | Information | | 288 +-------------------+------------+--------+---------------+--------+ 289 | activation-type | enumeration| 0x0031 | 0 unsigned | String | 290 | | | (TBD1) | | | 291 +-------------------+------------+--------+---------------+--------+ 293 Table 1: JSON/YANG Mapping to CBOR for 'activation-type' 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 As a reminder, the 'acl-list' and 'acl-name' parameters are defined 330 as comprehension-required parameters in Table 6 of 331 [I-D.ietf-dots-signal-channel]. Also, the 'activation-type' is 332 defined as a comprehension-required parameter (Section 5.1). 333 Following the rules in Section 6 of [I-D.ietf-dots-signal-channel], 334 if the DOTS server does not understand the 'acl-list' or 'acl-name' 335 or 'activation-type' attributes, it responds with a "4.00 (Bad 336 Request)" error response code. 338 If the DOTS server does not find the ACL name ('acl-name') conveyed 339 in the mitigation request for this DOTS client, it MUST respond with 340 4.04 (Not Found) error response code. 342 If the DOTS server finds the ACL name for this DOTS client, and 343 assuming the request passed the validation checks in Section 4.4.1 of 344 [I-D.ietf-dots-signal-channel], the DOTS server MUST proceed with the 345 'activation-type' update. The update is immediately enforced by the 346 DOTS server and will be maintained as the new activation type for the 347 ACL name even after the termination of the mitigation request. In 348 addition, the DOTS server MUST update the lifetime of the 349 corresponding ACL similar to the update when a refresh request is 350 received using the DOTS data channel (Section 7.2 of 351 [I-D.ietf-dots-data-channel]). If, for some reason, the DOTS server 352 fails to apply the filter update, it MUST respond with 5.03 (Service 353 Unavailable) error response code and include the failed ACL update in 354 the diagnostic payload of the response (an example is shown in 355 Figure 1). Else, the DOTS server replies with the appropriate 356 response code defined in Section 4.4.1 of 357 [I-D.ietf-dots-signal-channel]. 359 { 360 "ietf-dots-signal-channel:mitigation-scope": { 361 "scope": [ 362 { 363 "mid": 123, 364 "ietf-dots-signal-control:acl-list": [ 365 { 366 "ietf-dots-signal-control:acl-name": "an-accept-list", 367 "ietf-dots-signal-control:activation-type": "deactivate" 368 } 369 ] 370 } 371 ] 372 } 373 } 375 Figure 1: Example of a Diagnostic Payload Including Failed ACL Update 377 If the DOTS client receives a 5.03 (Service Unavailable) with a 378 diagnostic payload indicating a failed ACL update as a response to an 379 initial mitigation or a mitigation with adjusted scope, the DOTS 380 client MUST immediately send a new request which repeats all the 381 parameters as sent in the failed mitigation request but without 382 including the ACL attributes. After the expiry of Max-Age returned 383 in the 5.03 (Service Unavailable) response, the DOTS client retries 384 with a new mitigation request (i.e., a new 'mid') that repeats all 385 the parameters as sent in the failed mitigation request. 387 If, during an active mitigation, the 'activation-type' is changed at 388 the DOTS server (e.g., as a result of an external action) for an ACL 389 bound to a DOTS client, the DOTS server notifies that DOTS client 390 with the change by including the corresponding ACL parameters in an 391 asynchronous notification (the DOTS client is observing the active 392 mitigation) or in a response to a polling request (Section 4.4.2.2 of 393 [I-D.ietf-dots-signal-channel]). 395 If the DOTS signal and data channels of a DOTS client are not 396 established with the same DOTS server of a DOTS server domain, the 397 above request processing operations are undertaken using the 398 coordination mechanism discussed in Section 3.1. 400 This specification does not require any modification to the efficacy 401 update and the withdrawal procedures defined in 402 [I-D.ietf-dots-signal-channel]. In particular, ACL-related clauses 403 are not included in a PUT request used to send an efficacy update and 404 DELETE requests. 406 3.2.2. DOTS Signal Filtering Control Module 408 3.2.2.1. Tree Structure 410 This document augments the "ietf-dots-signal-channel" DOTS signal 411 YANG module defined in [I-D.ietf-dots-signal-channel] for managing 412 filtering rules. 414 This document defines the YANG module "ietf-dots-signal-control", 415 which has the following tree structure: 417 module: ietf-dots-signal-control 418 augment /ietf-signal:dots-signal/ietf-signal:message-type 419 /ietf-signal:mitigation-scope/ietf-signal:scope: 420 +--rw acl-list* [acl-name] {control-filtering}? 421 +--rw acl-name 422 | -> /ietf-data:dots-data/dots-client/acls/acl/name 423 +--rw activation-type? ietf-data:activation-type 425 3.2.2.2. YANG Module 427 This module uses types defined in [I-D.ietf-dots-data-channel]. 429 file "ietf-dots-signal-control@2019-05-13.yang" 431 module ietf-dots-signal-control { 432 yang-version 1.1; 433 namespace 434 "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; 435 prefix signal-control; 437 import ietf-dots-signal-channel { 438 prefix ietf-signal; 439 reference 440 "RFC SSSS: Distributed Denial-of-Service Open Threat 441 Signaling (DOTS) Signal Channel Specification"; 442 } 443 import ietf-dots-data-channel { 444 prefix ietf-data; 445 reference 446 "RFC DDDD: Distributed Denial-of-Service Open Threat 447 Signaling (DOTS) Data Channel Specification"; 448 } 450 organization 451 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 452 contact 453 "WG Web: 454 WG List: 456 Author: Kaname Nishizuka 457 459 Author: Mohamed Boucadair 460 462 Author: Konda, Tirumaleswar Reddy 463 465 Author: Takahiko Nagata 466 "; 468 description 469 "This module contains YANG definition for the signaling 470 messages exchanged between a DOTS client and a DOTS server 471 to control, by means of the DOTS signal channel, filtering 472 rules configured using the DOTS data channel. 474 Copyright (c) 2019 IETF Trust and the persons identified as 475 authors of the code. All rights reserved. 477 Redistribution and use in source and binary forms, with or 478 without modification, is permitted pursuant to, and subject 479 to the license terms contained in, the Simplified BSD License 480 set forth in Section 4.c of the IETF Trust's Legal Provisions 481 Relating to IETF Documents 482 (http://trustee.ietf.org/license-info). 484 This version of this YANG module is part of RFC XXXX; see 485 the RFC itself for full legal notices."; 487 revision 2019-05-13 { 488 description 489 "Initial revision."; 490 reference 491 "RFC XXXX: Controlling Filtering Rules Using Distributed 492 Denial-of-Service Open Threat Signaling (DOTS) 493 Signal Channel"; 494 } 496 feature control-filtering { 497 description 498 "This feature means that the DOTS signal channel is able 499 to manage the filtering rules created by the same DOTS 500 client using the DOTS data channel."; 501 } 503 augment "/ietf-signal:dots-signal/ietf-signal:message-type" 504 + "/ietf-signal:mitigation-scope/ietf-signal:scope" { 505 if-feature control-filtering; 507 description "ACL name and activation type."; 509 list acl-list { 510 key "acl-name"; 511 description 512 "List of ACLs as defined using the DOTS data 513 channel. ACLs bound to a DOTS client are uniquely 514 identified by a name."; 515 leaf acl-name { 516 type leafref { 517 path "/ietf-data:dots-data/ietf-data:dots-client" 518 + "/ietf-data:acls/ietf-data:acl/ietf-data:name"; 519 } 520 description 521 "Reference to the ACL name bound to a DOTS client."; 523 } 524 leaf activation-type { 525 type ietf-data:activation-type; 526 default "activate-when-mitigating"; 527 description 528 "Sets the activation type of an ACL."; 529 } 530 } 531 } 532 } 533 535 4. Sample Examples 537 This section provides sample examples to illustrate the behavior 538 specified in Section 3.2.1. These examples are provided for 539 illustration purposes; they should not be considered as deployment 540 recommendations. 542 4.1. Conflict Handling 544 Let's consider a DOTS client which contacts its DOTS server during 545 'idle' time to install an accept-list allowing for UDP traffic issued 546 from 2001:db8:1234::/48 with a destination port number 443 to be 547 forwarded to 2001:db8:6401::2/127. It does so by sending, for 548 example, a PUT request shown in Figure 2. 550 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 551 /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ 552 /acl=an-accept-list HTTP/1.1 553 Host: {host}:{port} 554 Content-Type: application/yang-data+json 556 { 557 "ietf-dots-data-channel:acls": { 558 "acl": [ 559 { 560 "name": "an-accept-list", 561 "type": "ipv6-acl-type", 562 "activation-type": "activate-when-mitigating", 563 "aces": { 564 "ace": [ 565 { 566 "name": "test-ace-ipv6-udp", 567 "matches": { 568 "ipv6": { 569 "destination-ipv6-network": "2001:db8:6401::2/127", 570 "source-ipv6-network": "2001:db8:1234::/48" 571 }, 572 "udp": { 573 "destination-port": { 574 "operator": "eq", 575 "port": 443 576 } 577 } 578 }, 579 "actions": { 580 "forwarding": "accept" 581 } 582 } 583 ] 584 } 585 } 586 ] 587 } 588 } 590 Figure 2: DOTS Data Channel Request to Create a Filter 592 Some time later, consider that a DDoS attack is detected by the DOTS 593 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends 594 a mitigation request to its DOTS server as shown in Figure 3. 596 Header: PUT (Code=0.03) 597 Uri-Path: ".well-known" 598 Uri-Path: "dots" 599 Uri-Path: "mitigate" 600 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 601 Uri-Path: "mid=123" 602 Content-Format: "application/dots+cbor" 604 { 605 "ietf-dots-signal-channel:mitigation-scope": { 606 "scope": [ 607 { 608 "target-prefix": [ 609 "2001:db8:6401::2/127" 610 ], 611 "target-protocol": [ 612 17 613 ], 614 "lifetime": 3600 615 } 616 ] 617 } 618 } 620 Figure 3: DOTS Signal Channel Mitigation Request 622 The DOTS server accepts immediately the request by replying with 2.01 623 (Created) (Figure 4 depicts the message body of the response). 625 { 626 "ietf-dots-signal-channel:mitigation-scope": { 627 "scope": [ 628 { 629 "mid": 123, 630 "lifetime": 3600 631 } 632 ] 633 } 634 } 636 Figure 4: Status Response (Message Body) 638 Assuming the DOTS client subscribed to asynchronous notifications, 639 when the DOTS server concludes that some of the attack sources belong 640 to 2001:db8:1234::/48, it sends a notification message with 'status' 641 code set to '1 (Attack mitigation is in progress)' and 'conflict- 642 cause' set to '2' (conflict-with-acceptlist) to the DOTS client to 643 indicate that this mitigation request is in progress, but a conflict 644 is detected. 646 Upon receipt of the notification message from the DOTS server, the 647 DOTS client sends a PUT request to deactivate the "an-accept-list" 648 ACL as shown in Figure 5. 650 The DOTS client can also decide to send a PUT request to deactivate 651 the "an-accept-list" ACL, if suspect traffic is received from an 652 accept-listed source (2001:db8:1234::/48). The structure of that PUT 653 is the same as the one shown in Figure 5. 655 Header: PUT (Code=0.03) 656 Uri-Path: ".well-known" 657 Uri-Path: "dots" 658 Uri-Path: "mitigate" 659 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 660 Uri-Path: "mid=124" 661 Content-Format: "application/dots+cbor" 663 { 664 "ietf-dots-signal-channel:mitigation-scope": { 665 "scope": [ 666 { 667 "target-prefix": [ 668 "2001:db8:6401::2/127" 669 ], 670 "target-protocol": [ 671 17 672 ], 673 "ietf-dots-signal-control:acl-list": [ 674 { 675 "ietf-dots-signal-control:acl-name": "an-accept-list", 676 "ietf-dots-signal-control:activation-type": "deactivate" 677 } 678 ] 679 "lifetime": 3600 680 } 681 ] 682 } 683 } 685 Figure 5: PUT for Deactivating a Conflicting Filter 687 Then, the DOTS server deactivates "an-accept-list" ACL and replies 688 with 2.04 (Changed) response to the DOTS client to confirm the 689 successful operation. The message body is similar to the one 690 depicted in Figure 4. 692 Once the attack is mitigated, the DOTS client may use the data 693 channel to retrieve its ACLs maintained by the DOTS server. As shown 694 in Figure 6, the activation type is set to 'deactivate' as set by the 695 DOTS signal channel (Figure 5) instead of the type initially set 696 using the DOTS data channel (Figure 2). 698 { 699 "ietf-dots-data-channel:acls": { 700 "acl": [ 701 { 702 "name": "an-accept-list", 703 "type": "ipv6-acl-type", 704 "activation-type": "deactivate", 705 "pending-lifetime": 10021, 706 "aces": { 707 "ace": [ 708 { 709 "name": "test-ace-ipv6-udp", 710 "matches": { 711 "ipv6": { 712 "destination-ipv6-network": "2001:db8:6401::2/127", 713 "source-ipv6-network": "2001:db8:1234::/48" 714 }, 715 "udp": { 716 "destination-port": { 717 "operator": "eq", 718 "port": 443 719 } 720 } 721 }, 722 "actions": { 723 "forwarding": "accept" 724 } 725 } 726 ] 727 } 728 } 729 ] 730 } 731 } 733 Figure 6: DOTS Data Channel GET Response after Mitigation (Message 734 Body) 736 4.2. On-Demand Activation of an Accept-List Filter 738 Let's consider a DOTS client which contacts its DOTS server during 739 'idle' time to install an accept-list allowing for UDP traffic issued 740 from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It 741 does so by sending, for example, a PUT request shown in Figure 7. 742 The DOTS server installs this filter with a "deactivated" state. 744 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 745 /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ 746 /acl=my-accept-list HTTP/1.1 747 Host: {host}:{port} 748 Content-Type: application/yang-data+json 750 { 751 "ietf-dots-data-channel:acls": { 752 "acl": [ 753 { 754 "name": "my-accept-list", 755 "type": "ipv6-acl-type", 756 "activation-type": "deactivate", 757 "aces": { 758 "ace": [ 759 { 760 "name": "an-ace", 761 "matches": { 762 "ipv6": { 763 "destination-ipv6-network": "2001:db8:6401::2/127", 764 "source-ipv6-network": "2001:db8:1234::/48", 765 "protocol": 17 766 } 767 }, 768 "actions": { 769 "forwarding": "accept" 770 } 771 } 772 ] 773 } 774 } 775 ] 776 } 777 } 779 Figure 7: DOTS Data Channel Request to Create an Accept-List Filter 781 Sometime later, consider that a UDP DDoS attack is detected by the 782 DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let 783 the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS 784 client domain. Consequently, the DOTS client sends a mitigation 785 request to its DOTS server as shown in Figure 8. 787 Header: PUT (Code=0.03) 788 Uri-Path: ".well-known" 789 Uri-Path: "dots" 790 Uri-Path: "mitigate" 791 Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" 792 Uri-Path: "mid=4879" 793 Content-Format: "application/dots+cbor" 795 { 796 "ietf-dots-signal-channel:mitigation-scope": { 797 "scope": [ 798 { 799 "target-prefix": [ 800 "2001:db8:6401::2/127" 801 ], 802 "target-protocol": [ 803 17 804 ], 805 "ietf-dots-signal-control:acl-list": [ 806 { 807 "ietf-dots-signal-control:acl-name": "my-accept-list", 808 "ietf-dots-signal-control:activation-type": "immediate" 809 } 810 "lifetime": 3600 811 } 812 ] 813 } 814 } 816 Figure 8: DOTS Signal Channel Mitigation Request with a Filter 817 Control 819 The DOTS server activates "my-accept-list" ACL and replies with 2.01 820 (Created) response to the DOTS client to confirm the successful 821 operation. 823 4.3. DOTS Servers/Mitigators Lacking Capacity 825 This section describes a scenario in which a DOTS client activates a 826 drop-list or a rate-limit filter during an attack. 828 Consider a DOTS client that contacts its DOTS server during 'idle' 829 time to install an accept-list that rate-limits all (or a part 830 thereof) traffic to be forwarded to 2001:db8:123::/48 as a last 831 resort countermeasure whenever required. It does so by sending, for 832 example, a PUT request shown in Figure 9. The DOTS server installs 833 this filter with a "deactivated" state. 835 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 836 /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ 837 /acl=my-ratelimit-list HTTP/1.1 838 Host: {host}:{port} 839 Content-Type: application/yang-data+json 841 { 842 "ietf-dots-data-channel:acls": { 843 "acl": [ 844 { 845 "name": "my-ratelimit-list", 846 "type": "ipv6-acl-type", 847 "activation-type": "deactivate", 848 "aces": { 849 "ace": [ 850 { 851 "name": "my-ace", 852 "matches": { 853 "ipv6": { 854 "destination-ipv6-network": "2001:db8:123::/48" 855 } 856 }, 857 "actions": { 858 "forwarding": "accept", 859 "rate-limit": "20.00" 860 } 861 } 862 ] 863 } 864 } 865 ] 866 } 867 } 869 Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter 871 Consider now that a DDoS attack is detected by the DOTS client on 872 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 873 request to its DOTS server (Figure 10). 875 Header: PUT (Code=0.03) 876 Uri-Path: ".well-known" 877 Uri-Path: "dots" 878 Uri-Path: "mitigate" 879 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 880 Uri-Path: "mid=85" 881 Content-Format: "application/dots+cbor" 883 { 884 "ietf-dots-signal-channel:mitigation-scope": { 885 "scope": [ 886 { 887 "target-prefix": [ 888 "2001:db8:123::/48" 889 ], 890 "lifetime": 3600 891 } 892 ] 893 } 894 } 896 Figure 10: DOTS Signal Channel Mitigation Request to Activate a Rate- 897 Limit Filter 899 For some reason (e.g., the DOTS server, or the mitigator, is lacking 900 a capability or capacity), the DOTS client is still receiving the 901 attack traffic which saturates available links. To soften the 902 problem, the DOTS client decides to activate the filter that rate- 903 limits the traffic destined to the DOTS client domain. To that aim, 904 the DOTS client sends the mitigation request to its DOTS server shown 905 in Figure 11. 907 Header: PUT (Code=0.03) 908 Uri-Path: ".well-known" 909 Uri-Path: "dots" 910 Uri-Path: "mitigate" 911 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 912 Uri-Path: "mid=86" 913 Content-Format: "application/dots+cbor" 915 { 916 "ietf-dots-signal-channel:mitigation-scope": { 917 "scope": [ 918 { 919 "target-prefix": [ 920 "2001:db8:123::/48" 921 ], 922 "ietf-dots-signal-control:acl-list": [ 923 { 924 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 925 "ietf-dots-signal-control:activation-type": "immediate" 926 } 927 ] 928 "lifetime": 3600 929 } 930 ] 931 } 932 } 934 Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate- 935 Limit Filter 937 Then, the DOTS server activates "my-ratelimit-list" ACL and replies 938 with 2.04 (Changed) response to the DOTS client to confirm the 939 successful operation. 941 As the attack mitigation evolves, the DOTS client may decide to 942 deactivate the rate-limit policy (e.g., upon receipt of notification 943 status change from 'attack-exceeded-capability' to 'attack- 944 mitigation-in-progress'). Based on the mitigation status conveyed by 945 the DOTS server, the DOTS client can de-activate the rate-limit 946 action. ). It does so by sending the request shown in Figure 12. 948 Header: PUT (Code=0.03) 949 Uri-Path: ".well-known" 950 Uri-Path: "dots" 951 Uri-Path: "mitigate" 952 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 953 Uri-Path: "mid=87" 954 Content-Format: "application/dots+cbor" 956 { 957 "ietf-dots-signal-channel:mitigation-scope": { 958 "scope": [ 959 { 960 "target-prefix": [ 961 "2001:db8:123::/48" 962 ], 963 "ietf-dots-signal-control:acl-list": [ 964 { 965 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 966 "ietf-dots-signal-control:activation-type": "deactivate" 967 } 968 ] 969 "lifetime": 3600 970 } 971 ] 972 } 973 } 975 Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a 976 Rate-Limit Filter 978 5. IANA Considerations 980 5.1. DOTS Signal Channel CBOR Mappings Registry 982 This specification registers the 'activation-type' parameter in the 983 IANA "DOTS Signal Channel CBOR Key Values" registry established by 984 [I-D.ietf-dots-signal-channel]. 986 o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is 987 assigned from the (0x0001 - 0x3FFF) range. Please update Table 1 988 accordingly. 990 +--------------------+--------+-------+------------+---------------+ 991 | Parameter Name | CBOR | CBOR | Change | Specification | 992 | | Key | Major | Controller | Document(s) | 993 | | Value | Type | | | 994 +--------------------+--------+-------+------------+---------------+ 995 | activation-type | 0x0031 | 0 | IESG | [RFCXXXX] | 996 | | (TBD1) | | | | 997 +--------------------+--------+-------+------------+---------------+ 999 5.2. DOTS Signal Filtering Control YANG Module 1001 This document requests IANA to register the following URI in the "ns" 1002 subregistry within the "IETF XML Registry" [RFC3688]: 1004 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1005 Registrant Contact: The IESG. 1006 XML: N/A; the requested URI is an XML namespace. 1008 This document requests IANA to register the following YANG module in 1009 the "YANG Module Names" subregistry [RFC7950] within the "YANG 1010 Parameters" registry. 1012 Name: ietf-dots-signal-control 1013 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1014 Maintained by IANA: N 1015 Prefix: signal-control 1016 Reference: RFC XXXX 1018 6. Security Considerations 1020 The security considerations discussed in 1021 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need 1022 to be taken into account. 1024 A DOTS client is entitled to access only to resources it creates. In 1025 particular, a DOTS client can not tweak filtering rules created by 1026 other DOTS clients of the same DOTS client domain. 1028 A compromised DOTS client can use the filtering control capability to 1029 exacerbate an ongoing attack. Likewise, such compromised DOTS client 1030 may abstain from reacting to an ACL conflict notification received 1031 from the DOTS server during attacks. These are not new attack 1032 vectors, but variations of threats discussed in 1033 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel]. 1034 DOTS operators should carefully monitor and audit DOTS agents to 1035 detect misbehaviors and to deter misuses. 1037 7. Acknowledgements 1039 Many thanks to Wei Pan, Xia Liang, Jon Shallow, and Dan Wing for the 1040 comments. 1042 8. References 1044 8.1. Normative References 1046 [I-D.ietf-dots-data-channel] 1047 Boucadair, M. and R. K, "Distributed Denial-of-Service 1048 Open Threat Signaling (DOTS) Data Channel Specification", 1049 draft-ietf-dots-data-channel-31 (work in progress), July 1050 2019. 1052 [I-D.ietf-dots-signal-channel] 1053 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1054 Teague, "Distributed Denial-of-Service Open Threat 1055 Signaling (DOTS) Signal Channel Specification", draft- 1056 ietf-dots-signal-channel-37 (work in progress), July 2019. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1064 DOI 10.17487/RFC3688, January 2004, 1065 . 1067 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1068 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1069 . 1071 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1072 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1073 May 2017, . 1075 8.2. Informative References 1077 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 1078 test report, IETF 103 Hackathon", November 2018, 1079 . 1083 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1084 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1085 . 1087 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1088 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1089 . 1091 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1092 Threat Signaling (DOTS) Requirements", RFC 8612, 1093 DOI 10.17487/RFC8612, May 2019, 1094 . 1096 Authors' Addresses 1098 Kaname Nishizuka 1099 NTT Communications 1100 GranPark 16F 3-4-1 Shibaura, Minato-ku 1101 Tokyo 108-8118 1102 Japan 1104 Email: kaname@nttv6.jp 1106 Mohamed Boucadair 1107 Orange 1108 Rennes 35000 1109 France 1111 Email: mohamed.boucadair@orange.com 1113 Tirumaleswar Reddy 1114 McAfee, Inc. 1115 Embassy Golf Link Business Park 1116 Bangalore, Karnataka 560071 1117 India 1119 Email: kondtir@gmail.com 1121 Takahiko Nagata 1122 Lepidum 1123 Japan 1125 Email: nagata@lepidum.co.jp