idnits 2.17.1 draft-ietf-dots-data-channel-12.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 362 has weird spacing: '...er-port ine...' == Line 363 has weird spacing: '...er-port ine...' == Line 437 has weird spacing: '...er-port ine...' == Line 441 has weird spacing: '...er-port ine...' == Line 458 has weird spacing: '...er-port ine...' == (1 more instance...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 11, 2018) is 2296 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) == Unused Reference: 'RFC8126' is defined on line 1501, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-05 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-16 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-14 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-22) exists of draft-ietf-dots-requirements-10 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-04 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy, Ed. 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair, Ed. 5 Expires: July 15, 2018 Orange 6 K. Nishizuka 7 NTT Communications 8 L. Xia 9 Huawei 10 P. Patil 11 Cisco 12 A. Mortensen 13 Arbor Networks, Inc. 14 N. Teague 15 Verisign, Inc. 16 January 11, 2018 18 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel 19 draft-ietf-dots-data-channel-12 21 Abstract 23 The document specifies a Distributed Denial-of-Service Open Threat 24 Signaling (DOTS) data channel used for bulk exchange of data that 25 cannot easily or appropriately communicated through the DOTS signal 26 channel under attack conditions. 28 This is a companion document to the DOTS signal channel 29 specification. 31 Editorial Note (To be removed by RFC Editor) 33 Please update these statements with the RFC number to be assigned to 34 this document: 36 o "This version of this YANG module is part of RFC XXXX;" 38 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 39 (DOTS) Data Channel"; 41 o reference: RFC XXXX 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on July 15, 2018. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Notational Conventions and Terminology . . . . . . . . . . . 5 79 3. DOTS Data Channel: Design Overview . . . . . . . . . . . . . 5 80 4. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . . . 8 81 5. DOTS Data Channel YANG Module . . . . . . . . . . . . . . . . 8 82 5.1. Identifier YANG Tree Structure . . . . . . . . . . . . . 8 83 5.2. Filter YANG Tree Structure . . . . . . . . . . . . . . . 8 84 5.2.1. DOTS ACL YANG Profile . . . . . . . . . . . . . . . . 8 85 5.2.2. DOTS Augmentation to the IETF-ACL YANG Module . . . . 11 86 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 87 6. DOTS Aliases . . . . . . . . . . . . . . . . . . . . . . . . 19 88 6.1. Create Aliases . . . . . . . . . . . . . . . . . . . . . 19 89 6.2. Retrieve Installed Aliases . . . . . . . . . . . . . . . 24 90 6.3. Delete Aliases . . . . . . . . . . . . . . . . . . . . . 26 91 7. DOTS Filtering Rules . . . . . . . . . . . . . . . . . . . . 26 92 7.1. Install Filtering Rules . . . . . . . . . . . . . . . . . 27 93 7.2. Retrieve Installed Filtering Rules . . . . . . . . . . . 29 94 7.3. Remove Filtering Rules . . . . . . . . . . . . . . . . . 30 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 101 12.2. Informative References . . . . . . . . . . . . . . . . . 33 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 104 1. Introduction 106 A distributed denial-of-service (DDoS) attack is an attempt to make 107 machines or network resources unavailable to their intended users. 108 In most cases, sufficient scale can be achieved by compromising 109 enough end-hosts and using those infected hosts to perpetrate and 110 amplify the attack. The victim of such attack can be an application 111 server, a router, a firewall, an entire network, etc. 113 As discussed in [I-D.ietf-dots-requirements], the lack of a common 114 method to coordinate a real-time response among involved actors and 115 network domains inhibits the speed and effectiveness of DDoS attack 116 mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS) 117 [I-D.ietf-dots-architecture] defines an architecture that allows a 118 DOTS client to send requests to a DOTS server for DDoS attack 119 mitigation. The DOTS approach is thus meant to minimize the impact 120 of DDoS attacks, thereby contributing to the enforcement of more 121 efficient defensive if not proactive security strategies. To that 122 aim, DOTS defines two channels: the signal and the data channels 123 (Figure 1). 125 +---------------+ +---------------+ 126 | | <------- Signal Channel ------> | | 127 | DOTS Client | | DOTS Server | 128 | | <======= Data Channel ======> | | 129 +---------------+ +---------------+ 131 Figure 1: DOTS Channels 133 The DOTS signal channel is used to carry information about a device 134 or a network (or a part thereof) that is under a DDoS attack. Such 135 information is sent by a DOTS client to an upstream DOTS server so 136 that appropriate mitigation actions are undertaken on traffic deemed 137 suspicious. The DOTS signal channel is further elaborated in 138 [I-D.ietf-dots-signal-channel]. 140 As for the DOTS data channel, it is used for infrequent bulk data 141 exchange between DOTS agents to significantly improve the 142 coordination of all the parties involved in the response to the 143 attack. Section 2 of [I-D.ietf-dots-architecture] mentions that the 144 DOTS data channel is used to perform the following tasks: 146 o Creating aliases for resources for which mitigation may be 147 requested. 149 A DOTS client may submit to its DOTS server a collection of 150 prefixes which it would like to refer to by an alias when 151 requesting mitigation. The DOTS server can respond to this 152 request with either a success or failure response (see Section 2 153 in [I-D.ietf-dots-architecture]). 155 Refer to Section 6 for more details. 157 o Filter management, which enables a DOTS client to request the 158 installation or withdrawal of traffic filters, dropping or rate- 159 limiting unwanted traffic, and permitting white-listed traffic. 161 Sample use cases for populating black- or white-list filtering 162 rules are detailed hereafter: 164 * If a network resource (DOTS client) detects a potential DDoS 165 attack from a set of IP addresses, the DOTS client informs its 166 servicing DOTS gateway of all suspect IP addresses that need to 167 be blocked or black-listed for further investigation. The DOTS 168 client could also specify a list of protocols and port numbers 169 in the black-list rule. 171 The DOTS gateway then propagates the black-listed IP addresses 172 to a DOTS server which will undertake appropriate actions so 173 that traffic originated by these IP addresses to the target 174 network (specified by the DOTS client) is blocked. 176 * A network, that has partner sites from which only legitimate 177 traffic arrives, may want to ensure that the traffic from these 178 sites is not subjected to DDoS attack mitigation. The DOTS 179 client uses the DOTS data channel to convey the white-listed IP 180 prefixes of the partner sites to its DOTS server. 182 The DOTS server uses this information to white-list flows 183 originated by such IP prefixes and which reach the network. 185 Refer to Section 7 for more details. 187 2. Notational Conventions and Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 The reader should be familiar with the terms defined in 194 [I-D.ietf-dots-architecture]. 196 The terminology for describing YANG data modules is defined in 197 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 198 [I-D.ietf-netmod-yang-tree-diagrams]. 200 For the sake of simplicity, all of the examples in this document use 201 "/restconf" as the discovered RESTCONF API root path. Many protocol 202 header lines and message-body text within examples throughout the 203 document are split into multiple lines for display purposes only. 204 When a line ends with backslash ('\') as the last character, the line 205 is wrapped for display purposes. It is to be considered to be joined 206 to the next line by deleting the backslash, the following line break, 207 and the leading whitespace of the next line. 209 3. DOTS Data Channel: Design Overview 211 Unlike the DOTS signal channel [I-D.ietf-dots-signal-channel], which 212 must remain operational even when confronted with signal degradation 213 due to packets loss, the DOTS data channel is not expected to be 214 fully operational at all times, especially when a DDoS attack is 215 underway. The requirements for a DOTS data channel protocol are 216 documented in [I-D.ietf-dots-requirements]. 218 This specification does not require an order of DOTS signal and data 219 channel creations nor mandates a time interval between them. These 220 considerations are implementation- and deployment-specific. 222 As the primary function of the data channel is data exchange, a 223 reliable transport mode is required in order for DOTS agents to 224 detect data delivery success or failure. This document uses RESTCONF 225 [RFC8040] over TLS [RFC5246] over TCP as the DOTS data channel 226 protocol (Figure 2). 228 Note: RESTCONF is a protocol based on HTTP [RFC7230] to provide 229 CRUD (create, read, update, delete) operations on a conceptual 230 datastore containing YANG data. Concretely, RESTCONF is used for 231 configuring data defined in YANG version 1 [RFC6020] or YANG 232 version 1.1 [RFC7950], using the datastore concepts defined in the 233 Network Configuration Protocol (NETCONF) [RFC6241]. RESTCONF 234 combines the simplicity of the HTTP protocol with the 235 predictability and automation potential of a schema-driven API. 236 RESTCONF offers a simple subset of NETCONF functionality and 237 provides a simplified interface using REST-like API which 238 addresses the needs of the DOTS data channel and hence an optimal 239 choice. 241 +-------------------+ 242 | DOTS Data Channel | 243 +-------------------+ 244 | RESTCONF | 245 +-------------------+ 246 | TLS | 247 +-------------------+ 248 | TCP | 249 +-------------------+ 250 | IP | 251 +-------------------+ 253 Figure 2: Abstract Layering of DOTS Data Channel over RESTCONF over 254 TLS 256 The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data 257 resources represented by DOTS data channel YANG data modules. These 258 basic edit operations allow the DOTS data channel running 259 configuration to be altered by a DOTS client. 261 DOTS data channel configuration information as well as state 262 information can be retrieved with the GET method. An HTTP status- 263 line header field is returned for each request to report success or 264 failure for RESTCONF operations (Section 5.4 of [RFC8040]). 266 The DOTS client performs the root resource discovery procedure 267 discussed in Section 3.1 of [RFC8040] to determine the root of the 268 RESTCONF API. After discovering the RESTCONF API root, the DOTS 269 client uses this value as the initial part of the path in the request 270 URI, in any subsequent request to the DOTS server. The DOTS server 271 may support the retrieval of the YANG modules it supports 272 (Section 3.7 in [RFC8040]). For example, a DOTS client may use 273 RESTCONF to retrieve the vendor-specific YANG modules supported by 274 the DOTS server. 276 JavaScript Object Notation (JSON) [RFC7159] payload is used to 277 propagate the DOTS data channel specific payload messages that carry 278 request parameters and response information, such as errors. This 279 specification uses the encoding rules defined in [RFC7951] for 280 representing DOTS data channel configuration data using YANG 281 (Section 5) as JSON text. 283 A DOTS client registers itself to its DOTS server(s) in order to set 284 up DOTS data channel-related configuration data and receive state 285 data (i.e., non-configuration data) from the DOTS server(s). 287 A single DOTS data channel between DOTS agents can be used to 288 exchange multiple requests and multiple responses. To reduce DOTS 289 client and DOTS server workload, DOTS client SHOULD re-use the same 290 TLS session. While the communication to the DOTS server is 291 quiescent, the DOTS client MAY probe the server to ensure it has 292 maintained cryptographic state. Such probes can also keep alive 293 firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies 294 that the DOTS server still has TLS state by returning a TLS message. 296 In deployments where one or more translators (e.g., NAT44, NAT64, 297 NPTv6) are enabled between the client's network and the DOTS server, 298 DOTS data channel messages forwarded to a DOTS server must not 299 include internal IP addresses/prefixes and/or port numbers; external 300 addresses/prefixes and/or port numbers as assigned by the translator 301 must be used instead. This document does not make any recommendation 302 about possible translator discovery mechanisms. The following are 303 some (non-exhaustive) deployment examples that may be considered: 305 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 306 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 307 external addresses/prefixes and/or port numbers. Information 308 retrieved by means of PCP or STUN will be used to feed the DOTS 309 data channel messages that will be sent to a DOTS server. 311 o A DOTS gateway may be co-located with the translator. The DOTS 312 gateway will need to update the DOTS messages, based upon the 313 local translator's binding table. 315 When a server-domain DOTS gateway is involved in DOTS data channel 316 exchanges, the same considerations for manipulating the 'client- 317 domain-hash' parameter as specified in [I-D.ietf-dots-signal-channel] 318 MUST be followed by DOTS agents. 320 A DOTS server may detect conflicting filtering requests from the same 321 or distinct DOTS clients which belong to the same domain. For 322 example, a DOTS client would request to blacklist a prefix, while 323 another DOTS client would request to whitelist that same prefix. It 324 is out of scope of this specification to recommend the behavior to 325 follow for handling conflicting requests (e.g., reject all, reject 326 the new request, notify an administrator for validation). DOTS 327 servers SHOULD support a configuration parameter to indicate the 328 behavior to follow when a conflict is detected. Section 7.1 329 specifies the behavior when no instruction is supplied to a DOTS 330 server. 332 4. DOTS Server(s) Discovery 334 This document assumes that DOTS clients are provisioned with the 335 reachability information of their DOTS server(s) using a variety of 336 means (e.g., local configuration, or dynamic means such as DHCP). 337 The specification of such means are out of scope of this document. 339 Likewise, it is out of scope of this document to specify the behavior 340 to follow by a DOTS client to place its requests (e.g., contact all 341 servers, select one server among the list) when multiple DOTS servers 342 are provisioned. 344 5. DOTS Data Channel YANG Module 346 5.1. Identifier YANG Tree Structure 348 The YANG module (ietf-dots-data-channel) allows to create aliases, 349 for resources for which mitigation may be requested. Such aliases 350 may be used in subsequent DOTS signal channel exchanges to refer more 351 efficiently to the resources under attack. The tree structure for 352 DOTS aliases is as follows: 354 +--rw aliases 355 +--rw dots-client* [cuid] 356 +--rw cuid string 357 +--rw client-domain-hash? string 358 +--rw alias* [alias-name] 359 +--rw alias-name string 360 +--rw target-prefix* inet:ip-prefix 361 +--rw target-port-range* [lower-port upper-port] 362 | +--rw lower-port inet:port-number 363 | +--rw upper-port inet:port-number 364 +--rw target-protocol* uint8 365 +--rw target-fqdn* inet:domain-name 366 +--rw target-uri* inet:uri 368 This structure is aligned with [I-D.ietf-dots-signal-channel]. 370 5.2. Filter YANG Tree Structure 372 5.2.1. DOTS ACL YANG Profile 374 This document augments the Access Control List (ACL) YANG module 375 [I-D.ietf-netmod-acl-model] for managing DOTS filtering rules. The 376 notion of ACL is explained in Section 1 of 377 [I-D.ietf-netmod-acl-model]. 379 Examples of ACL management in a DOTS context include, but not limited 380 to: 382 o Black-list management, which enables a DOTS client to inform a 383 DOTS server about sources from which traffic should be discarded. 385 o White-list management, which enables a DOTS client to inform a 386 DOTS server about sources from which traffic should always be 387 accepted. 389 o Filter management, which enables a DOTS client to request the 390 installation or withdrawal of traffic filters, dropping or rate- 391 limiting unwanted traffic and permitting white-listed traffic. 393 DOTS implementations MUST support the following features defined in 394 [I-D.ietf-netmod-acl-model]: 396 match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match- 397 on-icmp, ipv4, and ipv6. 399 Given that DOTS data channel does not deal with interfaces, the 400 support of the "ietf-interfaces" module [RFC7223] and its 401 augmentation in the "ietf-access-control-list" module are not 402 required for DOTS. Specifically, the support of interface-related 403 features and branches (e.g., interface-attachment, interface-stats, 404 acl-aggregate-stats, and interface-acl-aggregate) of the ACL YANG 405 module is not required. 407 The following forwarding actions MUST be supported: 409 'accept' and 'drop' 411 The support of 'reject' action is NOT RECOMMENDED because it is not 412 appropriate in the context of DDoS mitigation. Generating ICMP 413 messages to notify drops when mitigating a DDoS attack will 414 exacerbate the DDoS attack. Further, it will be used by an attacker 415 as an explicit signal that the traffic is being blocked. 417 The following tree structure provides the excerpt of the "ietf- 418 access-control-list" module to be supported by DOTS implementations. 420 +--rw access-lists 421 +--rw acl* [name] 422 | +--rw name string 423 | +--rw acl-type? acl-type 424 | +--rw aces 425 | +--rw ace* [rule-name] 426 | +--rw rule-name string 427 | +--rw matches 428 | | +--rw (l3)? 429 | | | +--:(ipv4) 430 | | | | +--rw ipv4 {match-on-ipv4}? 431 | | | | +--rw dscp? inet:dscp 432 | | | | +--rw ecn? uint8 433 | | | | +--rw length? uint16 434 | | | | +--rw ttl? uint8 435 | | | | +--rw protocol? uint8 436 | | | | +--rw source-port-range! 437 | | | | | +--rw lower-port inet:port-number 438 | | | | | +--rw upper-port? inet:port-number 439 | | | | | +--rw operation? operator 440 | | | | +--rw destination-port-range! 441 | | | | | +--rw lower-port inet:port-number 442 | | | | | +--rw upper-port? inet:port-number 443 | | | | | +--rw operations? operator 444 | | | | +--rw ihl? uint8 445 | | | | +--rw flags? bits 446 | | | | +--rw offset? uint16 447 | | | | +--rw identification? uint16 448 | | | | +--rw destination-ipv4-network? inet:ipv4-prefix 449 | | | | +--rw source-ipv4-network? inet:ipv4-prefix 450 | | | +--:(ipv6) 451 | | | +--rw ipv6 {match-on-ipv6}? 452 | | | +--rw dscp? inet:dscp 453 | | | +--rw ecn? uint8 454 | | | +--rw length? uint16 455 | | | +--rw ttl? uint8 456 | | | +--rw protocol? uint8 457 | | | +--rw source-port-range! 458 | | | | +--rw lower-port inet:port-number 459 | | | | +--rw upper-port? inet:port-number 460 | | | | +--rw operation? operator 461 | | | +--rw destination-port-range! 462 | | | | +--rw lower-port inet:port-number 463 | | | | +--rw upper-port? inet:port-number 464 | | | | +--rw operations? operator 465 | | | +--rw next-header? uint8 466 | | | +--rw destination-ipv6-network? inet:ipv6-prefix 467 | | | +--rw source-ipv6-network? inet:ipv6-prefix 468 | | | +--rw flow-label? inet:ipv6-flow-label 469 | | +--rw (l4)? 470 | | | +--:(tcp) 471 | | | | +--rw tcp {match-on-tcp}? 472 | | | | +--rw sequence-number? uint32 473 | | | | +--rw acknowledgement-number? uint32 474 | | | | +--rw data-offset? uint8 475 | | | | +--rw reserved? uint8 476 | | | | +--rw flags? bits 477 | | | | +--rw window-size? uint16 478 | | | | +--rw urgent-pointer? uint16 479 | | | | +--rw options? uint32 480 | | | +--:(udp) 481 | | | | +--rw udp {match-on-udp}? 482 | | | | +--rw length? uint16 483 | | | +--:(icmp) 484 | | | +--rw icmp {match-on-icmp}? 485 | | | +--rw type? uint8 486 | | | +--rw code? uint8 487 | | | +--rw rest-of-header? uint32 488 | +--ro matched-packets? yang:counter64 489 | +--ro matched-octets? yang:counter64 491 5.2.2. DOTS Augmentation to the IETF-ACL YANG Module 493 This document defines the DOTS Data Channel YANG to augment the 494 "ietf-access-control-list" module to support filters based on the 495 DOTS client unique identifier (cuid) and/or the client domain 496 identity (client-domain-hash), to support rate-limit action (rate- 497 limit), and to handle fragmented packets (fragments). The tree 498 structure for augmented DOTS filtering rules is as follows: 500 augment /ietf-acl:access-lists/ietf-acl:acl: 501 +--rw cuid string 502 +--rw client-domain-hash? string 503 +--rw lifetime int32 504 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces 505 /ietf-acl:ace/ietf-acl:actions: 506 +--rw rate-limit? decimal64 507 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces 508 /ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl: 509 +--rw fragments? empty 510 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces 511 /ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl: 512 +--rw fragments? empty 513 augment /ietf-acl:access-lists: 514 +--rw dots-acl-order 515 +--rw acl-set* [cuid name type] 516 +--rw cuid -> /ietf-acl:access-lists/acl/cuid 517 +--rw client-domain-hash? -> /ietf-acl:access-lists/acl/client-domain-hash 518 +--rw name -> /ietf-acl:access-lists/acl/acl-name 519 +--rw type -> /ietf-acl:access-lists/acl/acl-type 521 Filtering fragments adds an additional layer of protection against a 522 DoS attack that uses non-initial fragments only. When there is only 523 Layer 3 information in the ACL entry and the fragments keyword is 524 present, for non-initial fragments matching the ACL entry, the 'deny' 525 or 'permit' action associated with the ACL entry will be enforced. 526 For initial or non-fragment matching the ACL entry, the next ACL 527 entry will be processed. When there is both Layer 3 and Layer 4 528 information in the ACL entry and the fragments keyword is present, 529 the ACL action is conservative for both permit and deny actions. The 530 actions are conservative to not accidentally deny a fragmented 531 portion of a flow because the fragments do not contain sufficient 532 information to match all of the filter attributes. In the deny 533 action case, instead of denying a non-initial fragment, the next ACL 534 entry is processed. In the permit case, it is assumed that the Layer 535 4 information in the non-initial fragment, if available, matches the 536 Layer 4 information in the ACL entry. 538 5.3. YANG Module 540 file "ietf-dots-data-channel@2018-01-09.yang" 542 module ietf-dots-data-channel { 543 yang-version 1.1; 544 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel"; 546 prefix "data-channel"; 548 import ietf-inet-types {prefix "inet";} 549 import ietf-access-control-list {prefix "ietf-acl";} 551 organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 553 contact 554 "WG Web: 555 WG List: 557 Editor: Konda, Tirumaleswar Reddy 558 560 Editor: Mohamed Boucadair 561 563 Author: Kaname Nishizuka 564 566 Author: Liang Xia 567 569 Author: Prashanth Patil 570 572 Author: Andrew Mortensen 573 575 Author: Nik Teague 576 "; 578 description 579 "This module contains YANG definition for configuring 580 aliases for resources and filtering rules using DOTS 581 data channel. 583 Copyright (c) 2017 IETF Trust and the persons identified as 584 authors of the code. All rights reserved. 586 Redistribution and use in source and binary forms, with or 587 without modification, is permitted pursuant to, and subject 588 to the license terms contained in, the Simplified BSD License 589 set forth in Section 4.c of the IETF Trust's Legal Provisions 590 Relating to IETF Documents 591 (http://trustee.ietf.org/license-info). 593 This version of this YANG module is part of RFC XXXX; see 594 the RFC itself for full legal notices."; 596 revision 2018-01-09 { 597 description 598 "Initial revision."; 599 reference 600 "RFC XXXX: Distributed Denial-of-Service Open Threat 601 Signaling (DOTS) Data Channel"; 602 } 604 container aliases { 605 description "Top level container for aliases"; 607 list dots-client { 608 key cuid; 609 description 610 "List of DOTS clients"; 612 leaf cuid { 613 type string; 614 description 615 "A unique identifier that is randomly 616 generated by a DOTS client to prevent 617 request collisions."; 618 reference 619 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 620 Open Threat Signaling (DOTS) Signal Channel"; 621 } 623 leaf client-domain-hash { 624 type string; 625 description 626 "A client domain identifier conveyed by a 627 server-domain DOTS gateway to a remote DOTS server."; 628 reference 629 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 630 Open Threat Signaling (DOTS) Signal Channel"; 631 } 633 list alias { 634 key alias-name; 635 description 636 "List of aliases"; 638 leaf alias-name { 639 type string; 640 description "alias name"; 641 } 643 leaf-list target-prefix { 644 type inet:ip-prefix; 645 description 646 "IPv4 or IPv6 prefix identifying the target."; 647 } 649 list target-port-range { 650 key "lower-port upper-port"; 652 description 653 "Port range. When only lower-port is 654 present, it represents a single port."; 656 leaf lower-port { 657 type inet:port-number; 658 mandatory true; 659 description 660 "Lower port number."; 661 } 663 leaf upper-port { 664 type inet:port-number; 665 must ". >= ../lower-port" { 666 error-message 667 "The upper port number must be greater than 668 or equal to the lower port number."; 669 } 670 description 671 "Upper port number."; 672 } 673 } 675 leaf-list target-protocol { 676 type uint8; 677 description 678 "Identifies the target protocol number. 680 The value '0' means 'all protocols'. 682 Values are taken from the IANA protocol registry: 683 https://www.iana.org/assignments/protocol-numbers/ 684 protocol-numbers.xhtml 686 For example, 6 for a TCP or 17 for UDP."; 687 } 689 leaf-list target-fqdn { 690 type inet:domain-name; 691 description 692 "FQDN identifying the target."; 693 } 695 leaf-list target-uri { 696 type inet:uri; 697 description 698 "URI identifying the target."; 699 } 700 } 701 } 702 } 704 /*augment "/ietf-acl:access-lists" { 705 description 706 "Augment ACLs with the identity of the DOTS 707 client and client's domain hash."; 709 leaf cuid { 710 type string; 711 description 712 "A unique identifier that is randomly 713 generated by a DOTS client to prevent 714 request collisions."; 715 reference 716 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 717 Open Threat Signaling (DOTS) Signal Channel"; 718 } 720 leaf client-domain-hash { 721 type string; 722 description 723 "A client identifier conveyed by a server-domain DOTS 724 gateway to a remote DOTS server."; 725 } 726 } */ 728 augment "/ietf-acl:access-lists/ietf-acl:acl" { 729 when "derived-from(ietf-acl:acl-type, 'ietf-acl:ipv4-acl')" + 730 " or derived-from(ietf-acl:acl-type, 'ietf-acl:ipv6-acl')"; 732 description 733 "Augments ACLs with the identity of the DOTS 734 client, the client's domain hash, and the lifetime."; 736 leaf cuid { 737 type string; 738 mandatory true; 739 description 740 "A unique identifier that is randomly 741 generated by a DOTS client to prevent 742 request collisions."; 743 reference 744 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 745 Open Threat Signaling (DOTS) Signal Channel"; 746 } 748 leaf client-domain-hash { 749 type string; 750 description 751 "A client identifier conveyed by a server-domain DOTS 752 gateway to a remote DOTS server."; 753 } 755 leaf lifetime { 756 type int32; 757 units "minutes"; 758 mandatory true; 759 description 760 "Indicates the lifetime of the filtering rule 762 A lifetime of negative one (-1) indicates indefinite 763 lifetime for the filtering request."; 765 } 766 } 768 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 769 "/ietf-acl:ace/ietf-acl:actions" { 770 description 771 "rate-limit action"; 772 leaf rate-limit { 773 when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/" + 774 "ietf-acl:ace/ietf-acl:actions/" + 775 "ietf-acl:forwarding = 'ietf-acl:accept'" { 776 description 777 "rate-limit valid only when accept action is used"; 778 } 779 type decimal64 { 780 fraction-digits 2; 781 } 782 description 783 "rate-limit traffic"; 784 } 785 } 787 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 788 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl" { 789 description 790 "Handle non-initial and initial fragments for IPv4 packets."; 792 leaf fragments { 793 type empty; 794 description 795 "Handle fragments."; 796 } 797 } 799 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 800 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl" { 801 description 802 "Handle non-initial and initial fragments for IPv6 packets."; 804 leaf fragments { 805 type empty; 806 description 807 "Handle fragments."; 808 } 809 } 811 augment "/ietf-acl:access-lists" { 812 description 813 "Handle ordering of ACLs from a DOTS client"; 815 container dots-acl-order { 816 description 817 "Enclosing container for ordering 818 the ACLs from a DOTS client"; 820 list acl-set { 821 key "cuid name type"; 822 ordered-by user; 823 description 824 "List of ACLs"; 826 leaf cuid { 827 type leafref { 828 path "/ietf-acl:access-lists/ietf-acl:acl" + 829 "/cuid"; 830 } 831 description 832 "Reference to the CUID"; 833 } 835 leaf client-domain-hash { 836 type leafref { 837 path "/ietf-acl:access-lists/ietf-acl:acl" + 838 "/client-domain-hash"; 839 } 840 description 841 "Reference to the client domain hash."; 842 } 844 leaf name { 845 type leafref { 846 path "/ietf-acl:access-lists/ietf-acl:acl" + 847 "/ietf-acl:acl-name"; 848 } 849 description 850 "Reference to the ACL set name"; 851 } 853 leaf type { 854 type leafref { 855 path "/ietf-acl:access-lists/ietf-acl:acl" + 856 "/ietf-acl:acl-type"; 857 } 858 description 859 "Reference to the ACL set type"; 860 } 862 } 863 } 864 } 865 } 866 868 6. DOTS Aliases 870 6.1. Create Aliases 872 A POST request is used to create aliases, for resources for which a 873 mitigation may be requested. Such aliases may be used in subsequent 874 DOTS signal channel exchanges to refer more efficiently to the 875 resources under attack (Figure 3). 877 DOTS clients within the same domain can create different aliases for 878 the same resource. 880 POST /restconf/data/ietf-dots-data-channel:aliases HTTP/1.1 881 Host: {host}:{port} 882 Content-Type: application/yang-data+json 883 { 884 "ietf-dots-data-channel:dots-client": { 885 "cuid": string, 886 "alias": [ 887 { 888 "alias-name": "string", 889 "target-prefix": [ 890 "string" 891 ], 892 "target-port-range": [ 893 { 894 "lower-port": integer, 895 "upper-port": integer 896 } 897 ], 898 "target-protocol": [ 899 integer 900 ], 901 "target-fqdn": [ 902 "string" 903 ], 904 "target-uri": [ 905 "string" 906 ] 907 } 908 ] 909 } 910 } 912 Figure 3: POST to Create Aliases 914 The parameters are described below: 916 cuid: A unique identifier that is meant to prevent collisions among 917 DOTS clients that belong to the same domain. This attribute has 918 the same meaning, syntax, and processing rules as the 'cuid' 919 attribute defined in [I-D.ietf-dots-signal-channel]. 921 This is a mandatory attribute. 923 alias-name: Name of the alias. 925 This is a mandatory attribute. 927 target-prefix: Prefixes are separated by commas. Prefixes are 928 represented using Classless Inter-domain Routing (CIDR) notation 929 [RFC4632]. As a reminder, the prefix length must be less than or 930 equal to 32 (resp. 128) for IPv4 (resp. IPv6). 932 This is an optional attribute. 934 target-port-range: A range of port numbers. 936 The port range is defined by two bounds, a lower port number 937 (lower-port) and an upper port number (upper-port). 939 When only 'lower-port' is present, it represents a single port 940 number. 942 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 943 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 944 [RFC4340], the range of port numbers can be, for example, 945 1024-65535. 947 This is an optional attribute. 949 target-protocol: A list of protocols. Values are taken from the 950 IANA protocol registry [proto_numbers]. 952 The value '0' has a special meaning for 'all protocols'. 954 This is an optional attribute. 956 target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An 957 FQDN is the full name of a resource, rather than just its 958 hostname. For example, "venera" is a hostname, and 959 "venera.isi.edu" is an FQDN. 961 This is an optional attribute. 963 target-uri: A list of Uniform Resource Identifiers (URIs) 964 [RFC3986]. 966 This is an optional attribute. 968 In deployments where server-domain DOTS gateways are enabled, 969 identity information about the origin source client domain has to be 970 supplied to the DOTS server. That information is meant to assist the 971 DOTS server to enforce some policies. Figure 4 shows an example of a 972 request relayed by a server-domain DOTS gateway. 974 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 975 Host: {host}:{port} 976 Content-Type: application/yang-data+json 977 { 978 "ietf-dots-data-channel:dots-client": { 979 "client-domain-hash": "string", 980 "cuid": "string", 981 "alias": [ 982 { 983 "alias-name": "string", 984 "target-prefix": [ 985 "string" 986 ], 987 "target-port-range": [ 988 { 989 "lower-port": integer, 990 "upper-port": integer 991 } 992 ], 993 "target-protocol": [ 994 integer 995 ], 996 "target-fqdn": [ 997 "string" 998 ], 999 "target-uri": [ 1000 "string" 1001 ] 1002 } 1003 ] 1004 } 1005 } 1007 Figure 4: POST to Create Aliases (DOTS Gateway) 1009 A server-domain DOTS gateway may add the following attribute: 1011 client-domain-hash: This attribute has the same meaning, syntax, and 1012 processing rules as the 'client-domain-hash' attribute defined in 1013 [I-D.ietf-dots-signal-channel]. 1015 This is an optional attribute. 1017 In the POST request, at least one of the 'target-prefix' or 'target- 1018 fqdn' or 'target-uri' attributes MUST be present. DOTS agents can 1019 safely ignore Vendor-Specific parameters they don't understand. 1021 Figure 5 shows a POST request to create alias called "https1" for 1022 HTTPS servers with IP addresses 2001:db8:6401::1 and 2001:db8:6401::2 1023 listening on port number 443. 1025 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 1026 Host: www.example.com 1027 Content-Type: application/yang-data+json 1028 { 1029 "ietf-dots-data-channel:dots-client": { 1030 "cuid": "7dec-11d0-a765-00a0c91e6bf6@foo.bar.example", 1031 "alias": [ 1032 { 1033 "alias-name": "https1", 1034 "target-protocol": [ 1035 6 1036 ], 1037 "target-prefix": [ 1038 "2001:db8:6401::1/128", 1039 "2001:db8:6401::2/128" 1040 ], 1041 "target-port-range": [ 1042 { 1043 "lower-port": 443 1044 } 1045 ] 1046 } 1047 ] 1048 } 1049 } 1051 Figure 5: Example of a POST to Create Aliases 1053 The DOTS server indicates the result of processing the POST request 1054 using status-line codes. Status codes in the range "2xx" codes are 1055 success, "4xx" codes are some sort of invalid requests and "5xx" 1056 codes are returned if the DOTS server has erred or is incapable of 1057 accepting the alias. 1059 "201 Created" status-line is returned in the response if the DOTS 1060 server has accepted the alias. 1062 If the request is missing one or more mandatory attributes, or if the 1063 request contains invalid or unknown parameters, then "400 Bad 1064 Request" status-line MUST be returned in the response. The HTTP 1065 response will include the JSON body received in the request. 1067 A DOTS client MAY use the PUT request (Section 4.5 in [RFC8040]) to 1068 create or modify the aliases in the DOTS server. 1070 6.2. Retrieve Installed Aliases 1072 A GET request is used to retrieve one or all installed aliases by a 1073 DOTS client from a DOTS server (Section 3.3.1 in [RFC8040]). If no 1074 'alias-name' parameter is included in the request, this is an 1075 indication that the request is about retrieving all identifiers 1076 instantiated by the DOTS client. 1078 Figure 6 shows an example to retrieve all the identifiers that were 1079 instantiated by the DOTS client. The content parameter and its 1080 permitted values are defined in Section 4.8.1 of [RFC8040]. 1082 GET /restconf/data/ietf-dots-data-channel:aliases\ 1083 /cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example?content=config HTTP/1.1 1084 Host: {host}:{port} 1085 Accept: application/yang-data+json 1087 Figure 6: GET to Retrieve All Installed Aliases 1089 Figure 7 shows an example of response message body that includes all 1090 the aliases that are maintained by the DOTS server for the DOTS 1091 client identified by the 'cuid' parameter. 1093 { 1094 "ietf-dots-data-channel:dots-client": { 1095 "cuid": "7dec-11d0-a765-00a0c91e6bf6@foo.bar.example", 1096 "alias": [ 1097 { 1098 "alias-name": "Server1", 1099 "traffic-protocol": [ 1100 6 1101 ], 1102 "target-prefix": [ 1103 "2001:db8:6401::1/128", 1104 "2001:db8:6401::2/128" 1105 ], 1106 "target-port-range": [ 1107 { 1108 "lower-port": 443 1109 } 1110 ] 1111 }, 1112 { 1113 "alias-name": "Server2", 1114 "target-protocol": [ 1115 6 1116 ], 1117 "target-prefix": [ 1118 "2001:db8:6401::10/128", 1119 "2001:db8:6401::20/128" 1120 ], 1121 "target-port-range": [ 1122 { 1123 "lower-port": 80 1124 } 1125 ] 1126 } 1127 ] 1128 } 1129 } 1131 Figure 7: An Example of Response Body 1133 If the 'alias-name' parameter is included in the request, but the 1134 DOTS server does not find that alias name in its configuration data, 1135 it MUST respond with a "404 Not Found" status-line. 1137 6.3. Delete Aliases 1139 A DELETE request is used to delete aliases maintained by a DOTS 1140 server. 1142 In RESTCONF, URI-encoded path expressions are used. A RESTCONF data 1143 resource identifier is encoded from left to right, starting with the 1144 top-level data node, according to the 'api-path' rule defined in 1145 Section 3.5.3.1 of [RFC8040]. The data node in the path expression 1146 is a YANG list node and MUST be encoded according to the rules 1147 defined in Section 3.5.1 of [RFC8040]. 1149 If the DOTS server does not find the alias name conveyed in the 1150 DELETE request in its configuration data, it MUST respond with a "404 1151 Not Found" status-line. 1153 The DOTS server successfully acknowledges a DOTS client's request to 1154 remove the alias using "204 No Content" status-line in the response. 1156 Figure 8 shows an example of a request to delete an alias. 1158 DELETE /restconf/data/ietf-dots-data-channel:aliases\ 1159 /cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example/alias-name=Server1 HTTP/1.1 1160 Host: {host}:{port} 1162 Figure 8: Delete an Alias 1164 7. DOTS Filtering Rules 1166 The DOTS server either receives the filtering rules directly from the 1167 DOTS client or via a DOTS gateway. 1169 If the DOTS client signals the filtering rules via a DOTS gateway, 1170 the DOTS gateway first verifies that the DOTS client is authorized to 1171 signal the filtering rules. If the client is authorized, it 1172 propagates the rules to the DOTS server. Likewise, the DOTS server 1173 verifies that the DOTS gateway is authorized to signal the filtering 1174 rules. To create or purge filters, the DOTS client sends HTTP 1175 requests to its DOTS gateway. The DOTS gateway validates the rules 1176 in the requests and proxies the requests containing the filtering 1177 rules to a DOTS server. When the DOTS gateway receives the 1178 associated HTTP response from the DOTS server, it propagates the 1179 response back to the DOTS client. 1181 The following sub-sections define means for a DOTS client to 1182 configure filtering rules on a DOTS server. 1184 7.1. Install Filtering Rules 1186 A POST request is used to push filtering rules to a DOTS server. 1188 Figure 9 shows a POST request example to block traffic from 1189 192.0.2.0/24 and destined to 198.51.100.0/24. The ACL JSON 1190 configuration for the filtering rule is generated using the ACL YANG 1191 module (Section 4.3 of [I-D.ietf-netmod-acl-model]). 1193 POST /restconf/data/ietf-access-control-list HTTP/1.1 1194 Host: www.example.com 1195 Content-Type: application/yang-data+json 1196 { 1197 "ietf-access-control-list:access-lists": { 1198 "acl": [ 1199 { 1200 "acl-name": "sample-ipv4-acl", 1201 "acl-type": "ipv4-acl", 1202 "data-channel:cuid": "7dec-11d0-a765-00a0c91e6bf6@foo.bar.example", 1203 "data-channel:lifetime": 10080, 1204 "aces": { 1205 "ace": [ 1206 { 1207 "rule-name": "rule1", 1208 "matches": { 1209 "ipv4-acl": { 1210 "source-ipv4-network": "192.0.2.0/24", 1211 "destination-ipv4-network": "198.51.100.0/24" 1212 } 1213 }, 1214 "actions": { 1215 "forwarding": "drop" 1216 } 1217 } 1218 ] 1219 } 1220 } 1221 ] 1222 } 1223 } 1225 Figure 9: POST to Install Filtering Rules 1227 The meaning of these parameters is as follows: 1229 acl-name: The name of the access-list. 1231 This is a mandatory attribute. 1233 acl-type: Indicates the primary intended type of match criteria 1234 (e.g., IPv4, IPv6). It is set to 'ipv4-acl' in this example. 1236 This is a mandatory attribute. 1238 cuid: A unique identifier that is meant to prevent collisions among 1239 DOTS clients that belong to the same domain 1240 [I-D.ietf-dots-signal-channel]. 1242 This is a mandatory attribute. 1244 lifetime: Lifetime of the ACL, in minutes. The RECOMMENDED lifetime 1245 of a ACL is 10080 minutes (1 week). DOTS clients MUST include 1246 this parameter in their filtering requests. Upon the expiry of 1247 this lifetime, and if the request is not refreshed but no 1248 mitigation is active, the filtering request is removed. The 1249 request can be refreshed by sending the same request again. 1251 A lifetime of '0' in a request is an invalid value. 1253 A lifetime of negative one (-1) indicates indefinite lifetime for 1254 the filtering request. The DOTS server MAY refuse indefinite 1255 lifetime, for policy reasons; the granted lifetime value is 1256 returned in the response. DOTS clients MUST be prepared to not be 1257 granted filtering with indefinite lifetimes. 1259 The DOTS server MUST always indicate the actual lifetime in the 1260 response and the remaining lifetime in status messages sent to the 1261 DOTS client. 1263 This is a mandatory attribute. 1265 source-ipv4-network: The source IPv4 prefix. 1267 This is an optional attribute. 1269 destination-ipv4-network: The destination IPv4 prefix. 1271 This is an optional attribute. 1273 actions: Actions in the forwarding ACL category can be "drop" or 1274 "accept" or "rate-limit". The "accept" action is used to white- 1275 list traffic. The "drop" action is used to black-list traffic. 1276 The "rate-limit" action is used to rate-limit traffic, the allowed 1277 traffic rate is represented in bytes per second indicated in IEEE 1278 floating point format [IEEE.754.1985]. 1280 This is a mandatory attribute. 1282 The DOTS server indicates the result of processing the POST request 1283 using the status-line header. "2xx" codes are success, 4xx codes are 1284 some sort of invalid requests, and 5xx codes are returned if the DOTS 1285 server has erred or is incapable of configuring the filtering rules. 1286 Concretely, "201 Created" status-line MUST be returned in the 1287 response if the DOTS server has accepted the filtering rules. If the 1288 request is missing one or more mandatory attributes or contains 1289 invalid or unknown parameters, then "400 Bad Request" status-line 1290 MUST be returned in the response. 1292 If the request is conflicting with an existing filtering, the DOTS 1293 server returns "409 Conflict" status-line to the requesting DOTS 1294 client. The error-tag "invalid-value" is used in this case. 1296 The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used 1297 to specify how an Access Control Entry (ACE) is inserted within an 1298 ACL and how an ACL is inserted within an ACL set in container dots- 1299 acl-order. 1301 The DOTS client MAY use the PUT request to create or modify the 1302 filtering rules in the DOTS server. 1304 7.2. Retrieve Installed Filtering Rules 1306 The DOTS client periodically queries the DOTS server to check the 1307 counters for installed filtering rules. A GET request is used to 1308 retrieve filtering rules from a DOTS server. 1310 If the DOTS server does not find the access list name and access list 1311 type conveyed in the GET request in its configuration data, it 1312 responds with a "404 Not Found" status-line. 1314 Figure 10 shows how to retrieve all the filtering rules programmed by 1315 the DOTS client and the number of matches for the installed filtering 1316 rules. 1318 GET /restconf/data/ietf-access-control-list:access-lists\ 1319 /data-channel:cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example?\ 1320 content=all HTTP/1.1 1321 Host: {host}:{port} 1322 Accept: application/yang-data+json 1324 Figure 10: GET to Retrieve the Configuration Data and State Data for 1325 the Filtering Rules 1327 7.3. Remove Filtering Rules 1329 A DELETE request is used to delete filtering rules from a DOTS 1330 server. 1332 If the DOTS server does not find the access list name and access list 1333 type carried in the DELETE request in its configuration data, it 1334 responds with a "404 Not Found" status-line. The DOTS server 1335 successfully acknowledges a DOTS client's request to withdraw the 1336 filtering rules using "204 No Content" status-line, and removes the 1337 filtering rules accordingly. 1339 Figure 11 shows an example of a request to remove the IPv4 ACL named 1340 "sample-ipv4-acl". 1342 DELETE /restconf/data/ietf-access-control-list:access-lists\ 1343 /data-channel:cuid=7dec-11d0-a765-00a0c91e6bf6@foo.bar.example\ 1344 /acl-name=sample-ipv4-acl\ 1345 /acl-type=ipv4-acl HTTP/1.1 1346 Host: {host}:{port} 1348 Figure 11: DELETE to Remove the Filtering Rules 1350 8. IANA Considerations 1352 This document requests IANA to register the following URI in the 1353 "IETF XML Registry" [RFC3688]: 1355 URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1356 Registrant Contact: The IESG. 1357 XML: N/A; the requested URI is an XML namespace. 1359 This document requests IANA to register the following YANG module in 1360 the "YANG Module Names" registry [RFC7950]. 1362 name: ietf-dots-data-channel 1363 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1364 prefix: data-channel 1365 reference: RFC XXXX 1367 9. Contributors 1369 The following individuals have contributed to this document: 1371 Dan Wing 1373 Email: dwing-ietf@fuggles.com 1375 10. Security Considerations 1377 RESTCONF security considerations are discussed in [RFC8040]. In 1378 particular, DOTS agents MUST follow the security recommendations in 1379 Sections 2 and 12 of [RFC8040] and support the mutual authentication 1380 TLS profile discussed in Sections 7.1 and 8 of 1381 [I-D.ietf-dots-signal-channel]. 1383 Authenticated encryption MUST be used for data confidentiality and 1384 message integrity. The interaction between the DOTS agents requires 1385 Transport Layer Security (TLS) with a cipher suite offering 1386 confidentiality protection and the guidance given in [RFC7525] MUST 1387 be followed to avoid attacks on TLS. 1389 An attacker may be able to inject RST packets, bogus application 1390 segments, etc., regardless of whether TLS authentication is used. 1391 Because the application data is TLS protected, this will not result 1392 in the application receiving bogus data, but it will constitute a DoS 1393 on the connection. This attack can be countered by using TCP-AO 1394 [RFC5925]. If TCP-AO is used, then any bogus packets injected by an 1395 attacker will be rejected by the TCP-AO integrity check and therefore 1396 will never reach the TLS layer. 1398 In order to prevent leaking internal information outside a client- 1399 domain, client-side DOTS gateways SHOULD NOT reveal the identity of 1400 internal DOTS clients (e.g., source IP address, client's hostname) 1401 unless explicitly configured to do so. 1403 Special care should be taken in order to ensure that the activation 1404 of the proposed mechanism will not affect the stability of the 1405 network (including connectivity and services delivered over that 1406 network). 1408 All data nodes defined in the YANG module which can be created, 1409 modified, and deleted (i.e., config true, which is the default) are 1410 considered sensitive. Write operations applied to these data nodes 1411 without proper protection can negatively affect network operations. 1412 Appropriate security measures are recommended to prevent illegitimate 1413 users from invoking DOTS data channel primitives. Nevertheless, an 1414 attacker who can access a DOTS client is technically capable of 1415 launching various attacks, such as: 1417 o Set an arbitrarily low rate-limit, which may prevent legitimate 1418 traffic from being forwarded (rate-limit). 1420 o Set an arbitrarily high rate-limit, which may lead to the 1421 forwarding of illegitimate DDoS traffic (rate-limit). 1423 o Communicate invalid aliases to the server (alias), which will 1424 cause the failure of associating both data and signal channels. 1426 o Set invalid ACL entries, which may prevent legitimate traffic from 1427 being forwarded. Likewise, invalid ACL entries may lead to 1428 forward DDoS traffic. 1430 11. Acknowledgements 1432 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud 1433 Doron, Russ White, Jon Shallow, Gilbert Clark, and Nesredien Suleiman 1434 for the discussion and comments. 1436 12. References 1438 12.1. Normative References 1440 [I-D.ietf-dots-architecture] 1441 Mortensen, A., Andreasen, F., Reddy, T., 1442 christopher_gray3@cable.comcast.com, c., Compton, R., and 1443 N. Teague, "Distributed-Denial-of-Service Open Threat 1444 Signaling (DOTS) Architecture", draft-ietf-dots- 1445 architecture-05 (work in progress), October 2017. 1447 [I-D.ietf-dots-signal-channel] 1448 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 1449 Teague, "Distributed Denial-of-Service Open Threat 1450 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 1451 channel-16 (work in progress), January 2018. 1453 [I-D.ietf-netmod-acl-model] 1454 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 1455 "Network Access Control List (ACL) YANG Data Model", 1456 draft-ietf-netmod-acl-model-14 (work in progress), October 1457 2017. 1459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1460 Requirement Levels", BCP 14, RFC 2119, 1461 DOI 10.17487/RFC2119, March 1997, 1462 . 1464 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1465 DOI 10.17487/RFC3688, January 2004, 1466 . 1468 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1469 (CIDR): The Internet Address Assignment and Aggregation 1470 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1471 2006, . 1473 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1474 (TLS) Protocol Version 1.2", RFC 5246, 1475 DOI 10.17487/RFC5246, August 2008, 1476 . 1478 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1479 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1480 June 2010, . 1482 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1483 Protocol (HTTP/1.1): Message Syntax and Routing", 1484 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1485 . 1487 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1488 "Recommendations for Secure Use of Transport Layer 1489 Security (TLS) and Datagram Transport Layer Security 1490 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1491 2015, . 1493 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1494 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1495 . 1497 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1498 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1499 . 1501 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1502 Writing an IANA Considerations Section in RFCs", BCP 26, 1503 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1504 . 1506 12.2. Informative References 1508 [I-D.ietf-dots-requirements] 1509 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1510 Denial of Service (DDoS) Open Threat Signaling 1511 Requirements", draft-ietf-dots-requirements-10 (work in 1512 progress), January 2018. 1514 [I-D.ietf-netmod-yang-tree-diagrams] 1515 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1516 ietf-netmod-yang-tree-diagrams-04 (work in progress), 1517 December 2017. 1519 [IEEE.754.1985] 1520 Institute of Electrical and Electronics Engineers, 1521 "Standard for Binary Floating-Point Arithmetic", August 1522 1985. 1524 [proto_numbers] 1525 "IANA, "Protocol Numbers"", 2011, 1526 . 1528 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1529 Resource Identifier (URI): Generic Syntax", STD 66, 1530 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1531 . 1533 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1534 Congestion Control Protocol (DCCP)", RFC 4340, 1535 DOI 10.17487/RFC4340, March 2006, 1536 . 1538 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1539 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1540 . 1542 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1543 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1544 DOI 10.17487/RFC5389, October 2008, 1545 . 1547 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1548 the Network Configuration Protocol (NETCONF)", RFC 6020, 1549 DOI 10.17487/RFC6020, October 2010, 1550 . 1552 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1553 and A. Bierman, Ed., "Network Configuration Protocol 1554 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1555 . 1557 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1558 Layer Security (TLS) and Datagram Transport Layer Security 1559 (DTLS) Heartbeat Extension", RFC 6520, 1560 DOI 10.17487/RFC6520, February 2012, 1561 . 1563 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1564 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1565 DOI 10.17487/RFC6887, April 2013, 1566 . 1568 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1569 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1570 2014, . 1572 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1573 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1574 . 1576 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1577 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1578 . 1580 Authors' Addresses 1582 Tirumaleswar Reddy (editor) 1583 McAfee, Inc. 1584 Embassy Golf Link Business Park 1585 Bangalore, Karnataka 560071 1586 India 1588 Email: kondtir@gmail.com 1590 Mohamed Boucadair (editor) 1591 Orange 1592 Rennes 35000 1593 France 1595 Email: mohamed.boucadair@orange.com 1597 Kaname Nishizuka 1598 NTT Communications 1599 GranPark 16F 3-4-1 Shibaura, Minato-ku 1600 Tokyo 108-8118 1601 Japan 1603 Email: kaname@nttv6.jp 1604 Liang Xia 1605 Huawei 1606 101 Software Avenue, Yuhuatai District 1607 Nanjing, Jiangsu 210012 1608 China 1610 Email: frank.xialiang@huawei.com 1612 Prashanth Patil 1613 Cisco Systems, Inc. 1615 Email: praspati@cisco.com 1617 Andrew Mortensen 1618 Arbor Networks, Inc. 1619 2727 S. State St 1620 Ann Arbor, MI 48104 1621 United States 1623 Email: amortensen@arbor.net 1625 Nik Teague 1626 Verisign, Inc. 1627 United States 1629 Email: nteague@verisign.com