idnits 2.17.1 draft-ietf-dots-signal-filter-control-01.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 (May 24, 2019) is 1792 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 992, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-29 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-34 Summary: 1 error (**), 0 flaws (~~), 4 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 25, 2019 Orange 6 T. Reddy 7 McAfee 8 T. Nagata 9 Lepidum 10 May 24, 2019 12 Controlling Filtering Rules Using Distributed Denial-of-Service Open 13 Threat Signaling (DOTS) Signal Channel 14 draft-ietf-dots-signal-filter-control-01 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 November 25, 2019. 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 . . . . . . 16 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 205 [I-D.ietf-dots-requirements]. 207 The terminology for describing YANG modules is defined in [RFC7950]. 208 The meaning of the symbols in the tree diagram is defined in 209 [RFC8340]. 211 3. Controlling Filtering Rules of a DOTS Client 213 3.1. Binding DOTS Data and Signal Channels 215 The filtering rules eventually managed using the DOTS signal channel 216 protocol are created a priori by the same DOTS client using the DOTS 217 data channel protocol. Managing conflicts with filters installed by 218 other DOTS clients of the same domain is out of scope. 220 As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a 221 DOTS client must use the same 'cuid' for both the DOTS signal and 222 data channels. This requirement is meant to facilitate binding DOTS 223 channels used by the same DOTS client. 225 The DOTS signal and data channels from a DOTS client may or may not 226 use the same DOTS server. Nevertheless, the scope of the mitigation 227 request, alias, and filtering rules are not restricted to the DOTS 228 server but to the DOTS server domain. To that aim, DOTS servers 229 within a domain are assumed to have a mechanism to coordinate the 230 mitigation requests, aliases, and filtering rules to coordinate their 231 decisions for better mitigation operation efficiency. The exact 232 details about such mechanism is out of the scope of this document. 234 A filtering rule controlled by the DOTS signal channel is identified 235 by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). Note 236 that an ACL name unambiguously identifies an ACL bound to a DOTS 237 client, but the same name may be used by distinct DOTS clients. 239 The activation or deactivation of an ACL by the DOTS signal channel 240 overrides the 'activation-type' (defined in Section 7.2 of 242 [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering 243 rules using the DOTS data channel protocol. 245 3.2. DOTS Signal Channel Extension 247 3.2.1. Parameters and Behaviors 249 This specification extends the mitigation request defined in 250 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 251 intended control of configured filtering rules. Concretely, the DOTS 252 client conveys 'acl-list' attribute with the following sub-attributes 253 in the CBOR body of a mitigation request (see the YANG-encoded 254 structure in Section 3.2.2.1): 256 acl-name: A name of an access list defined using the DOTS data 257 channel (Section 7.2 of [I-D.ietf-dots-data-channel]) that is 258 associated with the DOTS client. 260 As a reminder, an ACL is an ordered list of Access Control Entries 261 (ACE). Each Access Control Entry has a list of match criteria and 262 a list of actions [I-D.ietf-dots-data-channel]. The list of 263 configured ACLs can be retrieved using the DOTS data channel 264 during 'idle' time. 266 This is an optional attribute. 268 activation-type: Indicates the activation type of an ACL overriding 269 the existing 'activation-type' installed by the DOTS client using 270 the DOTS data channel. 272 As a reminder, this attribute can be set to 'deactivate', 273 'immediate', or 'activate-when-mitigating' as defined in 274 [I-D.ietf-dots-data-channel]. 276 Note that both 'immediate' and 'activate-when-mitigating' have an 277 immediate effect when a mitigation request is being processed by 278 the DOTS server. 280 This is an optional attribute. 282 The JSON/YANG mapping to CBOR for 'activation-type' is shown in 283 Table 1. 285 +-------------------+------------+--------+---------------+--------+ 286 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 287 | | Type | Key | Type & | Type | 288 | | | | Information | | 289 +-------------------+------------+--------+---------------+--------+ 290 | activation-type | enumeration| 0x0031 | 0 unsigned | String | 291 | | | (TBD1) | | | 292 +-------------------+------------+--------+---------------+--------+ 294 Table 1: JSON/YANG mapping to CBOR for 'activation-type' 296 By default, ACL-related operations are achieved using the DOTS data 297 channel protocol when no attack is ongoing. DOTS clients MUST NOT 298 use the filtering control over DOTS signal channel in 'idle' time; 299 such requests MUST be discarded by DOTS servers with 4.00 (Bad 300 Request). 302 During an attack time, DOTS clients may include 'acl-list', 'acl- 303 name', and 'activation-type' attributes in a mitigation request. 304 This request may be the initial mitigation request for a given 305 mitigation scope or a new one overriding an existing request. In 306 both cases, a new 'mid' MUST be used. Nevertheless, it is NOT 307 RECOMMENDED to include ACL attributes in an initial mitigation 308 request for a given mitigation scope or in a mitigation request 309 adjusting the mitigation scope. 311 As the attack evolves, DOTS clients can adjust the 'activation-type' 312 of an ACL conveyed in a mitigation request or control other filters 313 as necessary. This can be achieved by sending a PUT request with a 314 new 'mid' value. 316 It is RECOMMENDED for a DOTS client to subscribe to asynchronous 317 notifications of the attack mitigation, as detailed in 318 Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the 319 polling mechanism in Section 4.4.2.2 of 320 [I-D.ietf-dots-signal-channel] has to be followed by the DOTS client. 322 A DOTS client relies on the information received from the DOTS server 323 and/or local information to the DOTS client domain to trigger a 324 filter control request. Only filters that are pertinent for an 325 ongoing mitigation should be controlled by a DOTS client using the 326 DOTS signal channel. 328 As a reminder, the 'acl-list' and 'acl-name' parameters are defined 329 as comprehension-required parameters in Table 6 of 330 [I-D.ietf-dots-signal-channel]. Also, the 'activation-type' is 331 defined as a comprehension-required parameter (Section 5.1). 332 Following the rules in Section 6 of [I-D.ietf-dots-signal-channel], 333 if the DOTS server does not understand the 'acl-list' or 'acl-name' 334 or 'activation-type' attributes, it responds with a "4.00 (Bad 335 Request)" error response code. 337 If the DOTS server does not find the ACL name ('acl-name') conveyed 338 in the mitigation request for this DOTS client, it MUST respond with 339 4.04 (Not Found) error response code. 341 If the DOTS server finds the ACL name for this DOTS client, and 342 assuming the request passed the validation checks in Section 4.4.1 of 343 [I-D.ietf-dots-signal-channel], the DOTS server MUST proceed with the 344 'activation-type' update. The update is immediately enforced by the 345 DOTS server and will be maintained as the new activation type for the 346 ACL name even after the termination of the mitigation request. In 347 addition, the DOTS server MUST update the lifetime of the 348 corresponding ACL similar to the update when a refresh request is 349 received using the DOTS data channel (Section 7.2 of 350 [I-D.ietf-dots-data-channel]). If, for some reason, the DOTS server 351 fails to apply the filter update, it MUST respond with 5.03 (Service 352 Unavailable) error response code and include the failed ACL update in 353 the diagnostic payload of the response (an example is shown in 354 Figure 1). Else, the DOTS server replies with the appropriate 355 response code defined in Section 4.4.1 of 356 [I-D.ietf-dots-signal-channel]. 358 { 359 "ietf-dots-signal-channel:mitigation-scope": { 360 "scope": [ 361 { 362 "mid": 123, 363 "ietf-dots-signal-control:acl-list": [ 364 { 365 "ietf-dots-signal-control:acl-name": "an-accept-list", 366 "ietf-dots-signal-control:activation-type": "deactivate" 367 } 368 ] 369 } 370 ] 371 } 372 } 374 Figure 1: Example of a Diagnostic Payload Including Failed ACL Update 376 If the DOTS client receives a 5.03 (Service Unavailable) with a 377 diagnostic payload indicating a failed ACL update as a response to an 378 initial mitigation or a mitigation with adjusted scope, the DOTS 379 client MUST immediately send a new request which repeats all the 380 parameters as sent in the failed mitigation request but without 381 including the ACL attributes. After the expiry of Max-Age returned 382 in the 5.03 (Service Unavailable) response, the DOTS client retries 383 with a new mitigation request (i.e., a new 'mid') that repeats all 384 the parameters as sent in the failed mitigation request. 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" DOTS signal 410 YANG module defined in [I-D.ietf-dots-signal-channel] for managing 411 filtering 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 module uses types defined in [I-D.ietf-dots-data-channel]. 428 file "ietf-dots-signal-control@2019-05-13.yang" 430 module ietf-dots-signal-control { 431 yang-version 1.1; 432 namespace 433 "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; 434 prefix signal-control; 436 import ietf-dots-signal-channel { 437 prefix ietf-signal; 438 reference 439 "RFC SSSS: Distributed Denial-of-Service Open Threat 440 Signaling (DOTS) Signal Channel Specification"; 441 } 442 import ietf-dots-data-channel { 443 prefix ietf-data; 444 reference 445 "RFC DDDD: Distributed Denial-of-Service Open Threat 446 Signaling (DOTS) Data Channel Specification"; 447 } 449 organization 450 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 451 contact 452 "WG Web: 453 WG List: 455 Author: Konda, Tirumaleswar Reddy 456 458 Author: Mohamed Boucadair 459 461 Author: Kaname Nishizuka 462 464 Author: Takahiko Nagata 465 "; 467 description 468 "This module contains YANG definition for the signaling 469 messages exchanged between a DOTS client and a DOTS server 470 to control, by means of the DOTS signal channel, filtering 471 rules configured using the DOTS data channel. 473 Copyright (c) 2019 IETF Trust and the persons identified as 474 authors of the code. All rights reserved. 476 Redistribution and use in source and binary forms, with or 477 without modification, is permitted pursuant to, and subject 478 to the license terms contained in, the Simplified BSD License 479 set forth in Section 4.c of the IETF Trust's Legal Provisions 480 Relating to IETF Documents 481 (http://trustee.ietf.org/license-info). 483 This version of this YANG module is part of RFC XXXX; see 484 the RFC itself for full legal notices."; 486 revision 2019-05-13 { 487 description 488 "Initial revision."; 489 reference 490 "RFC XXXX: Controlling Filtering Rules Using Distributed 491 Denial-of-Service Open Threat Signaling (DOTS) 492 Signal Channel"; 493 } 495 feature control-filtering { 496 description 497 "This feature means that the DOTS signal channel is able 498 to manage the filtering rules created by the same DOTS 499 client using the DOTS data channel."; 500 } 502 augment "/ietf-signal:dots-signal/ietf-signal:message-type" 503 + "/ietf-signal:mitigation-scope/ietf-signal:scope" { 504 if-feature control-filtering; 506 description "ACL name and activation type."; 508 list acl-list { 509 key "acl-name"; 510 description 511 "List of ACLs as defined using the DOTS data 512 channel. ACLs bound to a DOTS client are uniquely 513 identified by a name."; 514 leaf acl-name { 515 type leafref { 516 path "/ietf-data:dots-data/ietf-data:dots-client" 517 + "/ietf-data:acls/ietf-data:acl/ietf-data:name"; 518 } 519 description 520 "Reference to the ACL name bound to a DOTS client."; 522 } 523 leaf activation-type { 524 type ietf-data:activation-type; 525 default "activate-when-mitigating"; 526 description 527 "Sets the activation type of an ACL."; 528 } 529 } 530 } 531 } 532 534 4. Sample Examples 536 This section provides sample examples to illustrate the behavior 537 specified in Section 3.2.1. These examples are provided for 538 illustration purposes; they should not be considered as deployment 539 recommendations. 541 4.1. Conflict Handling 543 Let's consider a DOTS client which contacts its DOTS server during 544 'idle' time to install an accept-list allowing for UDP traffic issued 545 from 2001:db8:1234::/48 with a destination port number 443 to be 546 forwarded to 2001:db8:6401::2/127. It does so by sending, for 547 example, a PUT request shown in Figure 2. 549 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 550 /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ 551 /acl=an-accept-list HTTP/1.1 552 Host: {host}:{port} 553 Content-Type: application/yang-data+json 555 { 556 "ietf-dots-data-channel:acls": { 557 "acl": [ 558 { 559 "name": "an-accept-list", 560 "type": "ipv6-acl-type", 561 "activation-type": "activate-when-mitigating", 562 "aces": { 563 "ace": [ 564 { 565 "name": "test-ace-ipv6-udp", 566 "matches": { 567 "ipv6": { 568 "destination-ipv6-network": "2001:db8:6401::2/127", 569 "source-ipv6-network": "2001:db8:1234::/48" 570 }, 571 "udp": { 572 "destination-port": { 573 "operator": "eq", 574 "port": 443 575 } 576 } 577 }, 578 "actions": { 579 "forwarding": "accept" 580 } 581 } 582 ] 583 } 584 } 585 ] 586 } 587 } 589 Figure 2: DOTS Data Channel Request to Create a Filtering 591 Some time later, consider that a DDoS attack is detected by the DOTS 592 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends 593 a mitigation request to its DOTS server as shown in Figure 3. 595 Header: PUT (Code=0.03) 596 Uri-Path: ".well-known" 597 Uri-Path: "dots" 598 Uri-Path: "mitigate" 599 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 600 Uri-Path: "mid=123" 601 Content-Format: "application/dots+cbor" 603 { 604 "ietf-dots-signal-channel:mitigation-scope": { 605 "scope": [ 606 { 607 "target-prefix": [ 608 "2001:db8:6401::2/127" 609 ], 610 "target-protocol": [ 611 17 612 ], 613 "lifetime": 3600 614 } 615 ] 616 } 617 } 619 Figure 3: DOTS Signal Channel Mitigation Request 621 The DOTS server accepts immediately the request by replying with 2.01 622 (Created) (Figure 4 depicts the message body of the response). 624 { 625 "ietf-dots-signal-channel:mitigation-scope": { 626 "scope": [ 627 { 628 "mid": 123, 629 "lifetime": 3600 630 } 631 ] 632 } 633 } 635 Figure 4: Status Response (Message Body) 637 Assuming the DOTS client subscribed to asynchronous notifications, 638 when the DOTS server concludes that some of the attack sources belong 639 to 2001:db8:1234::/48, it sends a notification message with 'status' 640 code set to '1 (Attack mitigation is in progress)' and 'conflict- 641 cause' set to '2' (conflict-with-acceptlist) to the DOTS client to 642 indicate that this mitigation request is in progress, but a conflict 643 is detected. 645 Upon receipt of the notification message from the DOTS server, the 646 DOTS client sends a PUT request to deactivate the "an-accept-list" 647 ACL as shown in Figure 5. 649 The DOTS client can also decide to send a PUT request to deactivate 650 the "an-accept-list" ACL, if suspect traffic is received from an 651 accept-listed source (2001:db8:1234::/48). The structure of that PUT 652 is the same as the one shown in Figure 5. 654 Header: PUT (Code=0.03) 655 Uri-Path: ".well-known" 656 Uri-Path: "dots" 657 Uri-Path: "mitigate" 658 Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" 659 Uri-Path: "mid=124" 660 Content-Format: "application/dots+cbor" 662 { 663 "ietf-dots-signal-channel:mitigation-scope": { 664 "scope": [ 665 { 666 "target-prefix": [ 667 "2001:db8:6401::2/127" 668 ], 669 "target-protocol": [ 670 17 671 ], 672 "ietf-dots-signal-control:acl-list": [ 673 { 674 "ietf-dots-signal-control:acl-name": "an-accept-list", 675 "ietf-dots-signal-control:activation-type": "deactivate" 676 } 677 ] 678 "lifetime": 3600 679 } 680 ] 681 } 682 } 684 Figure 5: PUT for Deactivating a Conflicting Filter 686 Then, the DOTS server deactivates "an-accept-list" ACL and replies 687 with 2.04 (Changed) response to the DOTS client to confirm the 688 successful operation. The message body is similar to the one 689 depicted in Figure 4. 691 Once the attack is mitigated, the DOTS client may use the data 692 channel to retrieve its ACLs maintained by the DOTS server. As shown 693 in Figure 6, the activation type is set to 'deactivate' as set by the 694 signal channel (Figure 5) instead of the type initially set using the 695 data channel (Figure 2). 697 { 698 "ietf-dots-data-channel:acls": { 699 "acl": [ 700 { 701 "name": "an-accept-list", 702 "type": "ipv6-acl-type", 703 "activation-type": "deactivate", 704 "pending-lifetime": 10021, 705 "aces": { 706 "ace": [ 707 { 708 "name": "test-ace-ipv6-udp", 709 "matches": { 710 "ipv6": { 711 "destination-ipv6-network": "2001:db8:6401::2/127", 712 "source-ipv6-network": "2001:db8:1234::/48" 713 }, 714 "udp": { 715 "destination-port": { 716 "operator": "eq", 717 "port": 443 718 } 719 } 720 }, 721 "actions": { 722 "forwarding": "accept" 723 } 724 } 725 ] 726 } 727 } 728 ] 729 } 730 } 732 Figure 6: DOTS Data Channel GET Response after Mitigation 734 4.2. On-Demand Activation of an Accept-List Filter 736 Let's consider a DOTS client which contacts its DOTS server during 737 'idle' time to install an accept-list allowing for UDP traffic issued 738 from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It 739 does so by sending, for example, a PUT request shown in Figure 7. 740 The DOTS server installs this filter with a "deactivated" state. 742 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 743 /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ 744 /acl=my-accept-list HTTP/1.1 745 Host: {host}:{port} 746 Content-Type: application/yang-data+json 748 { 749 "ietf-dots-data-channel:acls": { 750 "acl": [ 751 { 752 "name": "my-accept-list", 753 "type": "ipv6-acl-type", 754 "activation-type": "deactivate", 755 "aces": { 756 "ace": [ 757 { 758 "name": "an-ace", 759 "matches": { 760 "ipv6": { 761 "destination-ipv6-network": "2001:db8:6401::2/127", 762 "source-ipv6-network": "2001:db8:1234::/48", 763 "protocol": 17 764 } 765 }, 766 "actions": { 767 "forwarding": "accept" 768 } 769 } 770 ] 771 } 772 } 773 ] 774 } 775 } 777 Figure 7: DOTS Data Channel Request to Create an Accept-List Filter 779 Sometime later, consider that a UDP DDoS attack is detected by the 780 DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let 781 the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS 782 client domain. Consequently, the DOTS client sends a mitigation 783 request to its DOTS server as shown in Figure 8. 785 Header: PUT (Code=0.03) 786 Uri-Path: ".well-known" 787 Uri-Path: "dots" 788 Uri-Path: "mitigate" 789 Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" 790 Uri-Path: "mid=4879" 791 Content-Format: "application/dots+cbor" 793 { 794 "ietf-dots-signal-channel:mitigation-scope": { 795 "scope": [ 796 { 797 "target-prefix": [ 798 "2001:db8:6401::2/127" 799 ], 800 "target-protocol": [ 801 17 802 ], 803 "ietf-dots-signal-control:acl-list": [ 804 { 805 "ietf-dots-signal-control:acl-name": "my-accept-list", 806 "ietf-dots-signal-control:activation-type": "immediate" 807 } 808 "lifetime": 3600 809 } 810 ] 811 } 812 } 814 Figure 8: DOTS Signal Channel Mitigation Request with a Filter 815 Control 817 The DOTS server activates "my-accept-list" ACL and replies with 2.01 818 (Created) response to the DOTS client to confirm the successful 819 operation. 821 4.3. DOTS Servers/Mitigators Lacking Capacity 823 This section describes a scenario in which a DOTS client activates a 824 drop-list or a rate-limit filter during an attack. 826 Consider a DOTS client that contacts its DOTS server during 'idle' 827 time to install an accept-list that rate-limits all (or a part 828 thereof) traffic to be forwarded to 2001:db8:123::/48 as a last 829 resort countermeasure whenever required. It does so by sending, for 830 example, a PUT request shown in Figure 9. The DOTS server installs 831 this filter with a "deactivated" state. 833 PUT /restconf/data/ietf-dots-data-channel:dots-data\ 834 /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ 835 /acl=my-ratelimit-list HTTP/1.1 836 Host: {host}:{port} 837 Content-Type: application/yang-data+json 839 { 840 "ietf-dots-data-channel:acls": { 841 "acl": [ 842 { 843 "name": "my-ratelimit-list", 844 "type": "ipv6-acl-type", 845 "activation-type": "deactivate", 846 "aces": { 847 "ace": [ 848 { 849 "name": "my-ace", 850 "matches": { 851 "ipv6": { 852 "destination-ipv6-network": "2001:db8:123::/48" 853 } 854 }, 855 "actions": { 856 "forwarding": "accept", 857 "rate-limit": "20.00" 858 } 859 } 860 ] 861 } 862 } 863 ] 864 } 865 } 867 Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter 869 Consider now that a DDoS attack is detected by the DOTS client on 870 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 871 request to its DOTS server (Figure 10). 873 Header: PUT (Code=0.03) 874 Uri-Path: ".well-known" 875 Uri-Path: "dots" 876 Uri-Path: "mitigate" 877 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 878 Uri-Path: "mid=85" 879 Content-Format: "application/dots+cbor" 881 { 882 "ietf-dots-signal-channel:mitigation-scope": { 883 "scope": [ 884 { 885 "target-prefix": [ 886 "2001:db8:123::/48" 887 ], 888 "lifetime": 3600 889 } 890 ] 891 } 892 } 894 Figure 10: DOTS Signal Channel Mitigation Request to Activate a Rate- 895 Limit Filter 897 For some reason (e.g., the DOTS server, or the mitigator, is lacking 898 a capability or capacity), the DOTS client is still receiving the 899 attack trafic which saturates available links. To soften the 900 problem, the DOTS client decides to activate the filter that rate- 901 limits the traffic destined to the DOTS client domain. To that aim, 902 the DOTS client sends the mitigation request to its DOTS server shown 903 in Figure 11. 905 Header: PUT (Code=0.03) 906 Uri-Path: ".well-known" 907 Uri-Path: "dots" 908 Uri-Path: "mitigate" 909 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 910 Uri-Path: "mid=86" 911 Content-Format: "application/dots+cbor" 913 { 914 "ietf-dots-signal-channel:mitigation-scope": { 915 "scope": [ 916 { 917 "target-prefix": [ 918 "2001:db8:123::/48" 919 ], 920 "ietf-dots-signal-control:acl-list": [ 921 { 922 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 923 "ietf-dots-signal-control:activation-type": "immediate" 924 } 925 ] 926 "lifetime": 3600 927 } 928 ] 929 } 930 } 932 Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate- 933 Limit Filter 935 Then, the DOTS server activates "my-ratelimit-list" ACL and replies 936 with 2.04 (Changed) response to the DOTS client to confirm the 937 successful operation. 939 As the attack mitigation evolves, the DOTS client may decide to 940 deactivate the rate-limit policy (e.g., upon receipt of notification 941 status change from 'attack-exceeded-capability' to 'attack- 942 mitigation-in-progress'). Based on the mitigation status conveyed by 943 the DOTS server, the DOTS client can de-activate the rate-limit 944 action. ). It does so by sending the request shown in Figure 12. 946 Header: PUT (Code=0.03) 947 Uri-Path: ".well-known" 948 Uri-Path: "dots" 949 Uri-Path: "mitigate" 950 Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" 951 Uri-Path: "mid=87" 952 Content-Format: "application/dots+cbor" 954 { 955 "ietf-dots-signal-channel:mitigation-scope": { 956 "scope": [ 957 { 958 "target-prefix": [ 959 "2001:db8:123::/48" 960 ], 961 "ietf-dots-signal-control:acl-list": [ 962 { 963 "ietf-dots-signal-control:acl-name": "my-ratelimit-list", 964 "ietf-dots-signal-control:activation-type": "deactivate" 965 } 966 ] 967 "lifetime": 3600 968 } 969 ] 970 } 971 } 973 Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a 974 Rate-Limit Filter 976 5. IANA Considerations 978 5.1. DOTS Signal Channel CBOR Mappings Registry 980 This specification registers the 'activation-type' parameter in the 981 IANA "DOTS Signal Channel CBOR Key Values" registry established by 982 [I-D.ietf-dots-signal-channel]. 984 o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is 985 assigned from the (0x0001 - 0x3FFF) range. 987 +--------------------+--------+-------+------------+---------------+ 988 | Parameter Name | CBOR | CBOR | Change | Specification | 989 | | Key | Major | Controller | Document(s) | 990 | | Value | Type | | | 991 +--------------------+--------+-------+------------+---------------+ 992 | activation-type | 0x0031 | 0 | IESG | [RFCXXXX] | 993 | | (TBD1) | | | | 994 +--------------------+--------+-------+------------+---------------+ 996 5.2. DOTS Signal Filtering Control YANG Module 998 This document requests IANA to register the following URI in the 999 "IETF XML Registry" [RFC3688]: 1001 URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1002 Registrant Contact: The IESG. 1003 XML: N/A; the requested URI is an XML namespace. 1005 This document requests IANA to register the following YANG module in 1006 the "YANG Module Names" registry [RFC7950]. 1008 Name: ietf-dots-signal-control 1009 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control 1010 Maintained by IANA: N 1011 Prefix: signal-control 1012 Reference: RFC XXXX 1014 6. Security Considerations 1016 The security considerations discussed in 1017 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need 1018 to be taken into account. 1020 A DOTS client is entitled to access only to resources it creates. In 1021 particular, a DOTS client can not tweak filtering rules created by 1022 other DOTS clients of the same DOTS client domain. 1024 A compromised DOTS client can use the filtering control capability to 1025 exacerbate an ongoing attack. Likewise, such compromised DOTS client 1026 may abstain from reacting to an ACL conflict notification received 1027 from the DOTS server during attacks. These are not new attack 1028 vectors, but variations of threats discussed in 1029 [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel]. 1030 DOTS operators should carefully monitor and audit DOTS agents to 1031 detect misbehaviors and to deter misuses. 1033 7. Acknowledgements 1035 Many thanks to Takahiko Nagata, Wei Pan, Xia Liang, Jon Shallow, and 1036 Dan Wing for the comments. 1038 8. References 1040 8.1. Normative References 1042 [I-D.ietf-dots-data-channel] 1043 Boucadair, M. and R. K, "Distributed Denial-of-Service 1044 Open Threat Signaling (DOTS) Data Channel Specification", 1045 draft-ietf-dots-data-channel-29 (work in progress), May 1046 2019. 1048 [I-D.ietf-dots-signal-channel] 1049 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1050 Teague, "Distributed Denial-of-Service Open Threat 1051 Signaling (DOTS) Signal Channel Specification", draft- 1052 ietf-dots-signal-channel-34 (work in progress), May 2019. 1054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 14, RFC 2119, 1056 DOI 10.17487/RFC2119, March 1997, 1057 . 1059 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1060 DOI 10.17487/RFC3688, January 2004, 1061 . 1063 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1064 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1065 . 1067 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1068 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1069 May 2017, . 1071 8.2. Informative References 1073 [I-D.ietf-dots-requirements] 1074 Mortensen, A., K, R., and R. Moskowitz, "Distributed 1075 Denial of Service (DDoS) Open Threat Signaling 1076 Requirements", draft-ietf-dots-requirements-22 (work in 1077 progress), March 2019. 1079 [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 1080 test report, IETF 103 Hackathon", November 2018, 1081 . 1085 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1086 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1087 . 1089 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1090 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1091 . 1093 Authors' Addresses 1095 Kaname Nishizuka 1096 NTT Communications 1097 GranPark 16F 3-4-1 Shibaura, Minato-ku 1098 Tokyo 108-8118 1099 Japan 1101 Email: kaname@nttv6.jp 1103 Mohamed Boucadair 1104 Orange 1105 Rennes 35000 1106 France 1108 Email: mohamed.boucadair@orange.com 1110 Tirumaleswar Reddy 1111 McAfee, Inc. 1112 Embassy Golf Link Business Park 1113 Bangalore, Karnataka 560071 1114 India 1116 Email: kondtir@gmail.com 1118 Takahiko Nagata 1119 Lepidum 1120 Japan 1122 Email: nagata@lepidum.co.jp