idnits 2.17.1 draft-ietf-dots-data-channel-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 8 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 267 has weird spacing: '...er-port ine...' == Line 268 has weird spacing: '...er-port ine...' -- The document date (June 5, 2017) is 2510 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) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-02 ** Downref: Normative reference to an Informational draft: draft-ietf-dots-architecture (ref. 'I-D.ietf-dots-architecture') == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-10 ** 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-04 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-01 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: December 7, 2017 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 June 5, 2017 18 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel 19 draft-ietf-dots-data-channel-01 21 Abstract 23 The document specifies a Distributed Denial-of-Service Open Threat 24 Signaling (DOTS) data channel used for bulk exchange of data not 25 easily or appropriately communicated through the DOTS signal channel 26 under attack conditions. This is a companion document to the DOTS 27 signal channel specification. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 7, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notational Conventions and Terminology . . . . . . . . . . . 4 65 3. DOTS Data Channel . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. DOTS Data Channel YANG Model . . . . . . . . . . . . . . 6 67 3.1.1. Identifier Model structure . . . . . . . . . . . . . 6 68 3.1.2. Identifier Model . . . . . . . . . . . . . . . . . . 6 69 3.1.3. Filter Model and structure . . . . . . . . . . . . . 8 70 3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.2.1. Create Identifiers . . . . . . . . . . . . . . . . . 8 72 3.2.2. Delete Identifiers . . . . . . . . . . . . . . . . . 11 73 3.2.3. Retrieving Installed Identifiers . . . . . . . . . . 11 74 3.3. Filtering Rules . . . . . . . . . . . . . . . . . . . . . 14 75 3.3.1. Install Filtering Rules . . . . . . . . . . . . . . . 14 76 3.3.2. Remove Filtering Rules . . . . . . . . . . . . . . . 16 77 3.3.3. Retrieving Installed Filtering Rules . . . . . . . . 16 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 4.1. DOTS Data Channel JSON Attribute Mappings Registry . . . 17 80 4.2. Registration Template . . . . . . . . . . . . . . . . . . 17 81 4.3. Initial Registry Contents . . . . . . . . . . . . . . . . 17 82 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 8.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 A distributed denial-of-service (DDoS) attack is an attempt to make 93 machines or network resources unavailable to their intended users. 94 In most cases, sufficient scale can be achieved by compromising 95 enough end-hosts and using those infected hosts to perpetrate and 96 amplify the attack. The victim in this attack can be an application 97 server, a client, a router, a firewall, or an entire network. 99 DDoS Open Threat Signaling (DOTS) defines two channels: signal and 100 data channels [I-D.ietf-dots-architecture] (Figure 1). The DOTS 101 signal channel used to convey that a network is under a DDOS attack 102 to an upstream DOTS server so that appropriate mitigation actions are 103 undertaken on the suspect traffic is further elaborated in 104 [I-D.ietf-dots-signal-channel]. The DOTS data channel is used for 105 infrequent bulk data exchange between DOTS agents in the aim to 106 significantly augment attack response coordination. 108 +---------------+ +---------------+ 109 | | <------- Signal Channel ------> | | 110 | DOTS Client | | DOTS Server | 111 | | <======= Data Channel ======> | | 112 +---------------+ +---------------+ 114 Figure 1: DOTS Channels 116 Section 2 of [I-D.ietf-dots-architecture] identifies that the DOTS 117 data channel is used to perform the tasks listed below: 119 o Filter management, which enables a DOTS client to install or 120 remove traffic filters, dropping or rate-limiting unwanted traffic 121 and permitting white-listed traffic. Sample use cases for 122 populating black- or white-list filtering rules are detailed 123 hereafter: 125 A. If a network resource (DOTS client) detects a potential DDoS 126 attack from a set of IP addresses, the DOTS client informs its 127 servicing router (DOTS gateway) of all suspect IP addresses 128 that need to be blocked or black-listed for further 129 investigation. The DOTS client could also specify a list of 130 protocols and ports in the black-list rule. That DOTS gateway 131 in-turn propagates the black-listed IP addresses to the DOTS 132 server which will undertake appropriate action so that traffic 133 from these IP addresses to the target network (specified by 134 the DOTS client) is blocked. 136 B. A network has partner sites from which only legitimate traffic 137 arrives and the network wants to ensure that the traffic from 138 these sites is not penalized during DDOS attacks. The DOTS 139 client uses the DOTS data channel to convey the white-listed 140 IP addresses or prefixes of the partner sites to its DOTS 141 server. The DOTS server uses this information to white-list 142 flows from such IP addresses or prefixes reaching the network. 144 o Creating identifiers, such as names or aliases, for resources for 145 which mitigation may be requested: 147 A. The DOTS client may submit to the DOTS server a collection of 148 prefixes which it would like to refer to by alias when 149 requesting mitigation. The server can respond to this request 150 with either with a success or failure response (see 151 requirement OP-006 in [I-D.ietf-dots-requirements] and 152 Section 2 in [I-D.ietf-dots-architecture]). 154 2. Notational Conventions and Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 The reader should be familiar with the terms defined in 161 [I-D.ietf-dots-architecture]. 163 For simplicity, all of the examples in this document use "/restconf" 164 as the discovered RESTCONF API root path. Many protocol header lines 165 and message-body text within examples throughout the document are 166 split into multiple lines for display purposes only. When a line 167 ends with backslash ('\') as the last character, the line is wrapped 168 for display purposes. It is to be considered to be joined to the 169 next line by deleting the backslash, the following line break, and 170 the leading whitespace of the next line. 172 3. DOTS Data Channel 174 The DOTS data channel is intended to be used for bulk data exchanges 175 between DOTS agents. Unlike the signal channel, which must operate 176 nominally even when confronted with signal degradation due to packet 177 loss, the data channel is not expected to be constructed to deal with 178 DDoS attack conditions. 180 As the primary function of the data channel is data exchange, a 181 reliable transport is required in order for DOTS agents to detect 182 data delivery success or failure. RESTCONF [RFC8040] over TLS 183 [RFC5246] over TCP is used for DOTS data channel (Figure 2). 184 RESTCONF uses HTTP methods to provide CRUD operations on a conceptual 185 datastore containing YANG-defined data, which is compatible with a 186 server which implements NETCONF datastores. The HTTP POST, PUT, 187 PATCH, and DELETE methods are used to edit data resources represented 188 by DOTS data channel YANG data models. These basic edit operations 189 allow the DOTS data channel running configuration to be altered by a 190 DOTS client. DOTS data channel configuration data and state data can 191 be retrieved with the GET method. HTTP status codes are used to 192 report success or failure for RESTCONF operations. The DOTS client 193 will perform the root resource discovery procedure discussed in 194 Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. 195 After discovering the RESTCONF API root, the DOTS client MUST use 196 this value as the initial part of the path in the request URI, in any 197 subsequent request to the DOTS server. The DOTS server can 198 optionally support retrieval of the YANG modules it supports 199 (Section 3.7 in [RFC8040]), for example, DOTS client can use RESTCONF 200 to retrieve the company proprietary YANG model supported by the DOTS 201 server. 203 Note: This document uses RESTCONF, a protocol based on HTTP 204 [RFC7230], for configuring data defined in YANG version 1 [RFC6020] 205 or YANG version 1.1 [RFC7950], using the datastore concepts defined 206 in the Network Configuration Protocol (NETCONF) [RFC6241]. RESTCONF 207 combines the simplicity of the HTTP protocol with the predictability 208 and automation potential of a schema-driven API. RESTCONF offers a 209 simple subset of NETCONF functionality and provides a simplified 210 interface using REST-like API which addresses the needs of the DOTS 211 data channel and hence an optimal choice. 213 +--------------+ 214 | DOTS | 215 +--------------+ 216 | RESTCONF | 217 +--------------+ 218 | TLS | 219 +--------------+ 220 | TCP | 221 +--------------+ 222 | IP | 223 +--------------+ 225 Figure 2: Abstract Layering of DOTS data channel over RESTCONF over 226 TLS 228 JavaScript Object Notation (JSON) [RFC7159] payload is used to 229 propagate data channel specific payload messages that convey request 230 parameters and response information such as errors. This 231 specification uses the encoding rules defined in [RFC7951] for 232 representing DOTS data channel configuration data defined using YANG 233 (Section 3.1) as JSON text. 235 A DOTS client registers itself to its DOTS server(s) in order to set 236 up DOTS data channel related configuration data on the DOTS server 237 and receive state data (i.e., non-configuration data) from the DOTS 238 server. A single DOTS data channel between DOTS agents can be used 239 to exchange multiple requests and multiple responses. To reduce DOTS 240 client and DOTS server workload, DOTS client SHOULD re-use the TLS 241 session. While the communication to the DOTS server is quiescent, 242 the DOTS client MAY probe the server to ensure it has maintained 243 cryptographic state. Such probes can also keep alive firewall or NAT 244 bindings. A TLS heartbeat [RFC6520] verifies the DOTS server still 245 has TLS state by returning a TLS message. 247 3.1. DOTS Data Channel YANG Model 249 3.1.1. Identifier Model structure 251 This document defines a YANG [RFC6020] data model for creating 252 identifiers, such as names or aliases, for resources for which 253 mitigation may be requested. Such identifiers may then be used in 254 subsequent DOTS signal channel exchanges to refer more efficiently to 255 the resources under attack. 257 This document defines the YANG module "ietf-dots-data-channel- 258 identifier", which has the following structure: 260 module: ietf-dots-data-channel-identifier 261 +--rw identifier 262 +--rw alias* [alias-name] 263 +--rw alias-name string 264 +--rw ip* inet:ip-address 265 +--rw prefix* inet:ip-prefix 266 +--rw port-range* [lower-port upper-port] 267 | +--rw lower-port inet:port-number 268 | +--rw upper-port inet:port-number 269 +--rw traffic-protocol* uint8 270 +--rw fqdn* inet:domain-name 271 +--rw uri* inet:uri 273 3.1.2. Identifier Model 275 file "ietf-dots-data-channel-identifier@2016-11-28.yang" 277 module ietf-dots-data-channel-identifier { 278 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel-identifier"; 279 prefix "alias"; 280 import ietf-inet-types { 281 prefix "inet"; 282 } 284 organization "McAfee, Inc."; 285 contact "Konda, Tirumaleswar Reddy "; 287 description 288 "This module contains YANG definition for 289 configuring identifiers for resources using DOTS data channel"; 291 revision 2016-11-28 { 292 reference 293 "https://tools.ietf.org/html/draft-reddy-dots-data-channel"; 294 } 296 container identifier { 297 description "top level container for identifiers"; 298 list alias { 299 key alias-name; 300 description "list of identifiers"; 301 leaf alias-name { 302 type string; 303 description "alias name"; 304 } 305 leaf-list ip { 306 type inet:ip-address; 307 description "IP address"; 308 } 309 leaf-list prefix { 310 type inet:ip-prefix; 311 description "prefix"; 312 } 313 list port-range { 314 key "lower-port upper-port"; 315 description 316 "Port range. When only lower-port is present, 317 it represents a single port."; 318 leaf lower-port { 319 type inet:port-number; 320 mandatory true; 321 description "lower port"; 322 } 323 leaf upper-port { 324 type inet:port-number; 325 must ". >= ../lower-port" { 326 error-message 327 "The upper-port must be greater than or 328 equal to lower-port"; 329 } 330 description "upper port"; 331 } 333 } 334 leaf-list traffic-protocol { 335 type uint8; 336 description "Internet Protocol number"; 337 } 338 leaf-list fqdn { 339 type inet:domain-name; 340 description "FQDN"; 341 } 342 leaf-list uri { 343 type inet:uri; 344 description "URI"; 345 } 346 } 347 } 348 } 349 351 3.1.3. Filter Model and structure 353 This document uses the Access Control List (ACL) YANG data model 354 [I-D.ietf-netmod-acl-model] for the configuration of filtering rules. 355 ACL is explained in Section 1 of [I-D.ietf-netmod-acl-model]. 357 Examples of such configuration include: 359 o Black-list management, which enables a DOTS client to inform the 360 DOTS server about sources from which traffic should be suppressed. 362 o White-list management, which enables a DOTS client to inform the 363 DOTS server about sources from which traffic should always be 364 accepted. 366 o Filter management, which enables a DOTS client to install or 367 remove traffic filters, dropping or rate-limiting unwanted traffic 368 and permitting white-listed traffic. 370 3.2. Identifiers 372 3.2.1. Create Identifiers 374 A POST request is used to create identifiers, such as names or 375 aliases, for resources for which a mitigation may be requested. Such 376 identifiers may then be used in subsequent DOTS signal channel 377 exchanges to refer more efficiently to the resources under attack 378 (Figure 3). 380 POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 381 Host: {host}:{port} 382 Content-Format: "application/yang.api+json" 383 { 384 "ietf-dots-data-channel-identifier:identifier": { 385 "alias": [ 386 { 387 "alias-name": "string", 388 "ip": [ 389 "string" 390 ], 391 "prefix": [ 392 "string" 393 ], 394 "port-range": [ 395 { 396 "lower-port": integer, 397 "upper-port": integer 398 } 399 ], 400 "traffic-protocol": [ 401 integer 402 ], 403 "fqdn": [ 404 "string" 405 ], 406 "uri": [ 407 "string" 408 ] 409 } 410 ] 411 } 412 } 414 Figure 3: POST to create identifiers 416 The header parameters are described below: 418 alias-name: Name of the alias. This is a mandatory attribute. 420 traffic-protocol: Internet Protocol numbers. This is an optional 421 attribute. 423 port-range: The port range, lower-port for lower port number and 424 upper-port for upper port number. For TCP, UDP, SCTP, or DCCP: 425 the range of ports (e.g., 80 to 8080). This is an optional 426 attribute. 428 ip: IP addresses are separated by commas. This is an optional 429 attribute. 431 prefix: Prefixes are separated by commas. This is an optional 432 attribute. 434 fqdn: Fully Qualified Domain Name, is the full name of a system, 435 rather than just its hostname. For example, "venera" is a 436 hostname, and "venera.isi.edu" is an FQDN. This is an optional 437 attribute. 439 uri: Uniform Resource Identifier (URI). This is an optional 440 attribute. 442 In the POST request at least one of the attributes ip or prefix or 443 fqdn or uri MUST be present. DOTS agents can safely ignore Vendor- 444 Specific parameters they don't understand. 446 Figure 4 shows a POST request to create alias called "https1" for 447 HTTP(S) servers with IP addresses 2001:db8:6401::1 and 448 2001:db8:6401::2 listening on port 443. 450 POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 451 Host: www.example.com 452 Content-Format: "application/yang.api+json" 453 { 454 "ietf-dots-data-channel-identifier:identifier": { 455 "alias": [ 456 { 457 "alias-name": "Server1", 458 "traffic-protocol": [ 459 6 460 ], 461 "ip": [ 462 "2001:db8:6401::1", 463 "2001:db8:6401::2" 464 ], 465 "port-range": [ 466 { 467 "lower-port": 443 468 } 469 ] 470 } 471 ] 472 } 473 } 475 Figure 4: POST to create identifiers 477 The DOTS server indicates the result of processing the POST request 478 using HTTP response codes. HTTP 2xx codes are success, HTTP 4xx 479 codes are some sort of invalid requests and 5xx codes are returned if 480 the DOTS server has erred or it is incapable of accepting the alias. 481 Response code 201 (Created) will be returned in the response if the 482 DOTS server has accepted the alias. If the request is missing one or 483 more mandatory attributes then 400 (Bad Request) will be returned in 484 the response or if the request contains invalid or unknown parameters 485 then 400 (Invalid query) will be returned in the response. The HTTP 486 response will include the JSON body received in the request. 488 The DOTS client can use the PUT request (Section 4.5 in [RFC8040]) to 489 create or modify the aliases in the DOTS server. 491 3.2.2. Delete Identifiers 493 A DELETE request is used to delete identifiers maintained by a DOTS 494 server (Figure 5). 496 DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ 497 /alias=Server1 HTTP/1.1 498 Host: {host}:{port} 500 Figure 5: DELETE identifier 502 In RESTCONF, URI-encoded path expressions are used. A RESTCONF data 503 resource identifier is encoded from left to right, starting with the 504 top-level data node, according to the "api-path" rule defined in 505 Section 3.5.3.1 of [RFC8040]. The data node in the above path 506 expression is a YANG list node and MUST be encoded according to the 507 rules defined in Section 3.5.1 of [RFC8040]. 509 If the DOTS server does not find the alias name conveyed in the 510 DELETE request in its configuration data, then it responds with a 404 511 (Not Found) error response code. The DOTS server successfully 512 acknowledges a DOTS client's request to remove the identifier using 513 204 (No Content) in the response. 515 3.2.3. Retrieving Installed Identifiers 517 A GET request is used to retrieve the set of installed identifiers 518 from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how 519 to retrieve all the identifiers that were instantiated by the DOTS 520 client. The content parameter and its permitted values are defined 521 in Section 4.8.1 of [RFC8040]. 523 GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ 524 content=config HTTP/1.1 525 Host: {host}:{port} 526 Accept: application/yang-data+json 528 Figure 6: GET to retrieve all the installed identifiers 530 Figure 7 shows response for all identifiers on the DOTS server. 532 { 533 "ietf-dots-data-channel-identifier:identifier": [ 534 { 535 "alias": [ 536 { 537 "alias-name": "Server1", 538 "traffic-protocol": [ 539 6 540 ], 541 "ip": [ 542 "2001:db8:6401::1", 543 "2001:db8:6401::2" 544 ], 545 "port-range": [ 546 { 547 "lower-port": 443 548 } 549 ] 550 } 551 ] 552 }, 553 { 554 "alias": [ 555 { 556 "alias-name": "Server2", 557 "traffic-protocol": [ 558 6 559 ], 560 "ip": [ 561 "2001:db8:6401::10", 562 "2001:db8:6401::20" 563 ], 564 "port-range": [ 565 { 566 "lower-port": 80 567 } 568 ] 569 } 570 ] 571 } 572 ] 573 } 575 Figure 7: Response body 577 If the DOTS server does not find the alias name conveyed in the GET 578 request in its configuration data, then it responds with a 404 (Not 579 Found) error response code. 581 3.3. Filtering Rules 583 The DOTS server either receives the filtering rules directly from the 584 DOTS client or via the DOTS gateway. If the DOTS client signals the 585 filtering rules via the DOTS gateway then the DOTS gateway validates 586 if the DOTS client is authorized to signal the filtering rules and if 587 the client is authorized propagates the rules to the DOTS server. 588 Likewise, the DOTS server validates if the DOTS gateway is authorized 589 to signal the filtering rules. To create or purge filters, the DOTS 590 client sends HTTP requests to the DOTS gateway. The DOTS gateway 591 validates the rules in the requests and proxies the requests 592 containing the filtering rules to a DOTS server. When the DOTS 593 gateway receives the associated HTTP response from the DOTS server, 594 it propagates the response back to the DOTS client. 596 The following APIs define means for a DOTS client to configure 597 filtering rules on a DOTS server. 599 3.3.1. Install Filtering Rules 601 A POST request is used to push filtering rules to a DOTS server. 602 Figure 8 shows a POST request example to block traffic from 603 192.0.2.0/24, destined to 198.51.100.0/24. The ACL JSON 604 configuration for the filtering rule is generated using the ACL YANG 605 data model defined in [I-D.ietf-netmod-acl-model] and the ACL 606 configuration XML for the filtering rule is specified in Section 4.3 607 of [I-D.ietf-netmod-acl-model]. This specification updates the ACL 608 YANG data model defined in [I-D.ietf-netmod-acl-model] to support 609 rate-limit action. 611 POST /restconf/data/ietf-access-control-list HTTP/1.1 612 Host: www.example.com 613 Content-Format: "application/yang.api+json" 614 { 615 "ietf-access-control-list:access-lists": { 616 "acl": [ 617 { 618 "acl-name": "sample-ipv4-acl", 619 "acl-type": "ipv4", 620 "access-list-entries": { 621 "ace": [ 622 { 623 "rule-name": "rule1", 624 "matches": { 625 "source-ipv4-network": "192.0.2.0/24", 626 "destination-ipv4-network": "198.51.100.0/24" 627 }, 628 "actions": { 629 "deny": [null] 630 } 631 } 632 ] 633 } 634 } 635 ] 636 } 637 } 639 Figure 8: POST to install filterng rules 641 The header parameters defined in [I-D.ietf-netmod-acl-model] are 642 discussed below: 644 acl-name: The name of access-list. This is a mandatory attribute. 646 acl-type: Indicates the primary intended type of match criteria 647 (e.g. IPv4, IPv6). This is a mandatory attribute. 649 protocol: Internet Protocol numbers. This is an optional 650 attribute. 652 source-ipv4-network: The source IPv4 prefix. This is an optional 653 attribute. 655 destination-ipv4-network: The destination IPv4 prefix. This is an 656 optional attribute. 658 actions: "deny" or "permit" or "rate-limit". "permit" action is 659 used to white-list traffic. "deny" action is used to black-list 660 traffic. "rate-limit" action is used to rate-limit traffic, the 661 allowed traffic rate is represented in bytes per second indicated 662 in IEEE floating point format [IEEE.754.1985]. If actions 663 attribute is not specified in the request then the default action 664 is "deny". This is an optional attribute. 666 The DOTS server indicates the result of processing the POST request 667 using HTTP response codes. HTTP 2xx codes are success, HTTP 4xx 668 codes are some sort of invalid requests and 5xx codes are returned if 669 the DOTS server has erred or it is incapable of configuring the 670 filtering rules. Response code 201 (Created) will be returned in the 671 response if the DOTS server has accepted the filtering rules. If the 672 request is missing one or more mandatory attributes then 400 (Bad 673 Request) will be returned in the response or if the request contains 674 invalid or unknown parameters then 400 (Invalid query) will be 675 returned in the response. 677 The DOTS client can use the PUT request to create or modify the 678 filtering rules in the DOTS server. 680 3.3.2. Remove Filtering Rules 682 A DELETE request is used to delete filtering rules from a DOTS server 683 (Figure 9). 685 DELETE /restconf/data/ietf-access-control-list:access-lists/acl-name\ 686 =sample-ipv4-acl&acl-type=ipv4 HTTP/1.1 687 Host: {host}:{port} 689 Figure 9: DELETE to remove the filtering rules 691 If the DOTS server does not find the access list name and access list 692 type conveyed in the DELETE request in its configuration data, then 693 it responds with a 404 (Not Found) error response code. The DOTS 694 server successfully acknowledges a DOTS client's request to withdraw 695 the filtering rules using 204 (No Content) response code, and removes 696 the filtering rules as soon as possible. 698 3.3.3. Retrieving Installed Filtering Rules 700 The DOTS client periodically queries the DOTS server to check the 701 counters for installed filtering rules. A GET request is used to 702 retrieve filtering rules from a DOTS server. Figure 10 shows how to 703 retrieve all the filtering rules programmed by the DOTS client and 704 the number of matches for the installed filtering rules. 706 GET /restconf/data/ietf-access-control-list:access-lists?content=all HTTP/1.1 707 Host: {host}:{port} 708 Accept: application/yang-data+json 710 Figure 10: GET to retrieve the configuration data and state data for 711 the filtering rules 713 If the DOTS server does not find the access list name and access list 714 type conveyed in the GET request in its configuration data, then it 715 responds with a 404 (Not Found) error response code. 717 4. IANA Considerations 719 This specification registers new parameters for the DOTS data channel 720 and establishes registries for mappings to JSON attributes. 722 4.1. DOTS Data Channel JSON Attribute Mappings Registry 724 A new registry will be requested from IANA, entitled "DOTS data 725 channel JSON attribute Mappings Registry". The registry is to be 726 created as Expert Review Required. 728 4.2. Registration Template 730 JSON Attribute: 731 JSON attribute name. 733 Description: 734 Brief description of the attribute. 736 Change Controller: 737 For Standards Track RFCs, list the "IESG". For others, give the 738 name of the responsible party. Other details (e.g., postal 739 address, email address, home page URI) may also be included. 741 Specification Document(s): 742 Reference to the document or documents that specify the parameter, 743 preferably including URIs that can be used to retrieve copies of 744 the documents. An indication of the relevant sections may also be 745 included but is not required. 747 4.3. Initial Registry Contents 749 o JSON Attribute: "alias-name" 750 o Description: Name of alias. 751 o Change Controller: IESG 752 o Specification Document(s): this document 753 o JSON Attribute: "traffic-protocol" 754 o Description: Internet protocol numbers. 755 o Change Controller: IESG 756 o Specification Document(s): this document 758 o JSON Attribute: "port-range" 759 o Description: The port range, lower-port for lower port number and 760 upper-port for upper port number. For TCP, UDP, SCTP, or DCCP: 761 the range of ports (e.g., 80 to 8080). 762 o Change Controller: IESG 763 o Specification Document(s): this document 765 o JSON Attribute: "lower-port" 766 o Description: Lower port number for port range. 767 o Change Controller: IESG 768 o Specification Document(s): this document 770 o JSON Attribute: "upper-port" 771 o Description: Upper port number for port range. 772 o Change Controller: IESG 773 o Specification Document(s): this document 775 o JSON Attribute: "ip" 776 o Description: IP address. 777 o Change Controller: IESG 778 o Specification Document(s): this document 780 o JSON Attribute: "prefix" 781 o Description: IP prefix 782 o Change Controller: IESG 783 o Specification Document(s): this document 785 o JSON Attribute: "fqdn" 786 o Description: Fully Qualified Domain Name, is the full name of a 787 system, rather than just its hostname. For example, "venera" is a 788 hostname, and "venera.isi.edu" is an FQDN. 789 o Change Controller: IESG 790 o Specification Document(s): this document 792 o JSON Attribute: "uri" 793 o Description: Uniform Resource Identifier (URI). 794 o Change Controller: IESG 795 o Specification Document(s): this document 797 5. Contributors 799 The following individuals have contributed to this document: 801 Dan Wing 803 Email: dwing-ietf@fuggles.com 805 6. Security Considerations 807 Authenticated encryption MUST be used for data confidentiality and 808 message integrity. TLS based on client certificate MUST be used for 809 mutual authentication. The interaction between the DOTS agents 810 requires Transport Layer Security (TLS) with a cipher suite offering 811 confidentiality protection and the guidance given in [RFC7525] MUST 812 be followed to avoid attacks on TLS. 814 An attacker may be able to inject RST packets, bogus application 815 segments, etc., regardless of whether TLS authentication is used. 816 Because the application data is TLS protected, this will not result 817 in the application receiving bogus data, but it will constitute a DoS 818 on the connection. This attack can be countered by using TCP-AO 819 [RFC5925]. If TCP-AO is used, then any bogus packets injected by an 820 attacker will be rejected by the TCP-AO integrity check and therefore 821 will never reach the TLS layer. 823 Special care should be taken in order to ensure that the activation 824 of the proposed mechanism won't have an impact on the stability of 825 the network (including connectivity and services delivered over that 826 network). 828 Involved functional elements in the cooperation system must establish 829 exchange instructions and notification over a secure and 830 authenticated channel. Adequate filters can be enforced to avoid 831 that nodes outside a trusted domain can inject request such as 832 deleting filtering rules. Nevertheless, attacks can be initiated 833 from within the trusted domain if an entity has been corrupted. 834 Adequate means to monitor trusted nodes should also be enabled. 836 7. Acknowledgements 838 Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, 839 Roman Danyliw, Ehud Doron, Russ White and Gilbert Clark for the 840 discussion and comments. 842 8. References 844 8.1. Normative References 846 [I-D.ietf-dots-architecture] 847 Mortensen, A., Andreasen, F., Reddy, T., 848 christopher_gray3@cable.comcast.com, c., Compton, R., and 849 N. Teague, "Distributed-Denial-of-Service Open Threat 850 Signaling (DOTS) Architecture", draft-ietf-dots- 851 architecture-02 (work in progress), May 2017. 853 [I-D.ietf-netmod-acl-model] 854 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 855 "Network Access Control List (ACL) YANG Data Model", 856 draft-ietf-netmod-acl-model-10 (work in progress), March 857 2017. 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, 861 DOI 10.17487/RFC2119, March 1997, 862 . 864 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 865 (TLS) Protocol Version 1.2", RFC 5246, 866 DOI 10.17487/RFC5246, August 2008, 867 . 869 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 870 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 871 June 2010, . 873 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 874 Protocol (HTTP/1.1): Message Syntax and Routing", 875 RFC 7230, DOI 10.17487/RFC7230, June 2014, 876 . 878 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 879 "Recommendations for Secure Use of Transport Layer 880 Security (TLS) and Datagram Transport Layer Security 881 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 882 2015, . 884 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 885 RFC 7951, DOI 10.17487/RFC7951, August 2016, 886 . 888 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 889 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 890 . 892 8.2. Informative References 894 [I-D.ietf-dots-requirements] 895 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 896 Denial of Service (DDoS) Open Threat Signaling 897 Requirements", draft-ietf-dots-requirements-04 (work in 898 progress), March 2017. 900 [I-D.ietf-dots-signal-channel] 901 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 902 Teague, "Distributed Denial-of-Service Open Threat 903 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 904 channel-01 (work in progress), April 2017. 906 [IEEE.754.1985] 907 Institute of Electrical and Electronics Engineers, 908 "Standard for Binary Floating-Point Arithmetic", August 909 1985. 911 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 912 the Network Configuration Protocol (NETCONF)", RFC 6020, 913 DOI 10.17487/RFC6020, October 2010, 914 . 916 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 917 and A. Bierman, Ed., "Network Configuration Protocol 918 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 919 . 921 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 922 Layer Security (TLS) and Datagram Transport Layer Security 923 (DTLS) Heartbeat Extension", RFC 6520, 924 DOI 10.17487/RFC6520, February 2012, 925 . 927 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 928 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 929 2014, . 931 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 932 RFC 7950, DOI 10.17487/RFC7950, August 2016, 933 . 935 Authors' Addresses 937 Tirumaleswar Reddy 938 McAfee, Inc. 939 Embassy Golf Link Business Park 940 Bangalore, Karnataka 560071 941 India 943 Email: kondtir@gmail.com 945 Mohamed Boucadair 946 Orange 947 Rennes 35000 948 France 950 Email: mohamed.boucadair@orange.com 952 Kaname Nishizuka 953 NTT Communications 954 GranPark 16F 3-4-1 Shibaura, Minato-ku 955 Tokyo 108-8118 956 Japan 958 Email: kaname@nttv6.jp 960 Liang Xia 961 Huawei 962 101 Software Avenue, Yuhuatai District 963 Nanjing, Jiangsu 210012 964 China 966 Email: frank.xialiang@huawei.com 968 Prashanth Patil 969 Cisco Systems, Inc. 971 Email: praspati@cisco.com 972 Andrew Mortensen 973 Arbor Networks, Inc. 974 2727 S. State St 975 Ann Arbor, MI 48104 976 United States 978 Email: amortensen@arbor.net 980 Nik Teague 981 Verisign, Inc. 982 United States 984 Email: nteague@verisign.com