idnits 2.17.1 draft-ietf-dots-data-channel-11.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 36 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 360 has weird spacing: '...er-port ine...' == Line 361 has weird spacing: '...er-port ine...' -- The document date (December 18, 2017) is 2320 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-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-13 == 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-08 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 -- 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) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 4 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: June 21, 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 December 18, 2017 18 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel 19 draft-ietf-dots-data-channel-11 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. 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 June 21, 2018. 60 Copyright Notice 62 Copyright (c) 2017 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 . . . . . . . . . . . 4 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.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. DOTS Identifiers . . . . . . . . . . . . . . . . . . . . . . 15 86 6.1. Create Identifiers . . . . . . . . . . . . . . . . . . . 15 87 6.2. Retrieve Installed Identifiers . . . . . . . . . . . . . 18 88 6.3. Delete Identifiers . . . . . . . . . . . . . . . . . . . 20 89 7. DOTS Filtering Rules . . . . . . . . . . . . . . . . . . . . 20 90 7.1. Install Filtering Rules . . . . . . . . . . . . . . . . . 21 91 7.2. Retrieve Installed Filtering Rules . . . . . . . . . . . 22 92 7.3. Remove Filtering Rules . . . . . . . . . . . . . . . . . 23 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 94 8.1. DOTS Data Channel JSON Attribute Mappings Registry . . . 23 95 8.1.1. Registration Template . . . . . . . . . . . . . . . . 24 96 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 24 97 8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 98 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 12.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 106 1. Introduction 108 A distributed denial-of-service (DDoS) attack is an attempt to make 109 machines or network resources unavailable to their intended users. 110 In most cases, sufficient scale can be achieved by compromising 111 enough end-hosts and using those infected hosts to perpetrate and 112 amplify the attack. The victim in such attack can be an application 113 server, a router, a firewall, an entire network, etc. 115 As discussed in [I-D.ietf-dots-requirements], the lack of a common 116 method to coordinate a real-time response among involved actors and 117 network domains inhibits the speed and effectiveness of DDoS attack 118 mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS) 119 [I-D.ietf-dots-architecture] defines an architecture enabling 120 requests for DDoS attack mitigation, reducing attack impact, and 121 contributing to more efficient defensive strategies. To that aim, 122 DOTS defines two channels: signal and data channels (Figure 1). 124 +---------------+ +---------------+ 125 | | <------- Signal Channel ------> | | 126 | DOTS Client | | DOTS Server | 127 | | <======= Data Channel ======> | | 128 +---------------+ +---------------+ 130 Figure 1: DOTS Channels 132 The DOTS signal channel is used to convey that a network is under a 133 DDoS attack to an upstream DOTS server so that appropriate mitigation 134 actions are undertaken on the suspect traffic. The DOTS signal 135 channel is further elaborated in [I-D.ietf-dots-signal-channel]. 137 The DOTS data channel is used for infrequent bulk data exchange 138 between DOTS agents in the aim to significantly augment attack 139 response coordination. Section 2 of [I-D.ietf-dots-architecture] 140 identifies that the DOTS data channel is used to perform the 141 following tasks: 143 o Creating identifiers, such as names or aliases, for resources for 144 which mitigation may be requested. 146 A DOTS client may submit to its DOTS server a collection of 147 prefixes which it would like to refer to by an alias when 148 requesting mitigation. The DOTS server can respond to this 149 request with either a success or failure response (see Section 2 150 in [I-D.ietf-dots-architecture]). 152 Refer to Section 6 for more details. 154 o Filter management, which enables a DOTS client to request the 155 installation or removal of traffic filters, dropping or rate- 156 limiting unwanted traffic, and permitting white-listed traffic. 158 Sample use cases for populating black- or white-list filtering 159 rules are detailed hereafter: 161 * If a network resource (DOTS client) detects a potential DDoS 162 attack from a set of IP addresses, the DOTS client informs its 163 servicing DOTS gateway of all suspect IP addresses that need to 164 be blocked or black-listed for further investigation. The DOTS 165 client could also specify a list of protocols and port numbers 166 in the black-list rule. 168 The DOTS gateway in-turn propagates the black-listed IP 169 addresses to a DOTS server which will undertake appropriate 170 actions so that traffic from these IP addresses to the target 171 network (specified by the DOTS client) is blocked. 173 * A network, that has partner sites from which only legitimate 174 traffic arrives, may want to ensure that the traffic from these 175 sites is not penalized during DDoS attacks. The DOTS client 176 uses the DOTS data channel to convey the white-listed IP 177 prefixes of the partner sites to its DOTS server. 179 The DOTS server uses this information to white-list flows from 180 such IP prefixes reaching the network. 182 Refer to Section 7 for more details. 184 2. Notational Conventions and Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 The reader should be familiar with the terms defined in 191 [I-D.ietf-dots-architecture]. 193 The terminology for describing YANG data modules is defined in 194 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 195 [I-D.ietf-netmod-yang-tree-diagrams]. 197 For simplicity, all of the examples in this document use "/restconf" 198 as the discovered RESTCONF API root path. Many protocol header lines 199 and message-body text within examples throughout the document are 200 split into multiple lines for display purposes only. When a line 201 ends with backslash ('\') as the last character, the line is wrapped 202 for display purposes. It is to be considered to be joined to the 203 next line by deleting the backslash, the following line break, and 204 the leading whitespace of the next line. 206 3. DOTS Data Channel: Design Overview 208 Unlike the DOTS signal channel [I-D.ietf-dots-signal-channel], which 209 must operate nominally even when confronted with signal degradation 210 due to packets loss, the DOTS data channel is not expected to be 211 constructed to deal with DDoS attack conditions. The requirements 212 for DOTS data channel protocol are documented in 213 [I-D.ietf-dots-requirements]. 215 This specification does not require an order of contact nor the time 216 interval between DOTS signal and data channel creations. These 217 considerations are implementation- and deployment-specific. 219 As the primary function of the data channel is data exchange, a 220 reliable transport is required in order for DOTS agents to detect 221 data delivery success or failure. This document uses RESTCONF 222 [RFC8040] over TLS [RFC5246] over TCP as the DOTS data channel 223 protocol (Figure 2). 225 Note: RESTCONF is a protocol based on HTTP [RFC7230] to provide 226 CRUD (create, read, update, delete) operations on a conceptual 227 datastore containing YANG data. Concretely, RESTCONF is used for 228 configuring data defined in YANG version 1 [RFC6020] or YANG 229 version 1.1 [RFC7950], using the datastore concepts defined in the 230 Network Configuration Protocol (NETCONF) [RFC6241]. RESTCONF 231 combines the simplicity of the HTTP protocol with the 232 predictability and automation potential of a schema-driven API. 233 RESTCONF offers a simple subset of NETCONF functionality and 234 provides a simplified interface using REST-like API which 235 addresses the needs of the DOTS data channel and hence an optimal 236 choice. 238 +-------------------+ 239 | DOTS Data Channel | 240 +-------------------+ 241 | RESTCONF | 242 +-------------------+ 243 | TLS | 244 +-------------------+ 245 | TCP | 246 +-------------------+ 247 | IP | 248 +-------------------+ 250 Figure 2: Abstract Layering of DOTS Data Channel over RESTCONF over 251 TLS 253 The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data 254 resources represented by DOTS data channel YANG data modules. These 255 basic edit operations allow the DOTS data channel running 256 configuration to be altered by a DOTS client. 258 DOTS data channel configuration data and state data can be retrieved 259 with the GET method. An HTTP status-line header field is returned 260 for each request to report success or failure for RESTCONF operations 261 (Section 5.4 of [RFC8040]). 263 The DOTS client performs the root resource discovery procedure 264 discussed in Section 3.1 of [RFC8040] to determine the root of the 265 RESTCONF API. After discovering the RESTCONF API root, the DOTS 266 client uses this value as the initial part of the path in the request 267 URI, in any subsequent request to the DOTS server. The DOTS server 268 may support retrieval of the YANG modules it supports (Section 3.7 in 269 [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve 270 the company proprietary YANG modules supported by the DOTS server. 272 JavaScript Object Notation (JSON) [RFC7159] payload is used to 273 propagate data channel specific payload messages that convey request 274 parameters and response information such as errors. This 275 specification uses the encoding rules defined in [RFC7951] for 276 representing DOTS data channel configuration data defined using YANG 277 (Section 5) as JSON text. 279 A DOTS client registers itself to its DOTS server(s) in order to set 280 up DOTS data channel related configuration data and receive state 281 data (i.e., non-configuration data) from the DOTS server(s). 283 A single DOTS data channel between DOTS agents can be used to 284 exchange multiple requests and multiple responses. To reduce DOTS 285 client and DOTS server workload, DOTS client SHOULD re-use the same 286 TLS session. While the communication to the DOTS server is 287 quiescent, the DOTS client MAY probe the server to ensure it has 288 maintained cryptographic state. Such probes can also keep alive 289 firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies the 290 DOTS server still has TLS state by returning a TLS message. 292 In deployments where one or more translators (e.g., NAT44, NAT64, 293 NPTv6) are enabled between the client's network and the DOTS server, 294 DOTS data channel messages forwarded to a DOTS server must not 295 include internal IP addresses/prefixes and/or port numbers; external 296 addresses/prefixes and/or port numbers as assigned by the translator 297 must be used instead. This document does not make any recommendation 298 about possible translator discovery mechanisms. The following are 299 some (non-exhaustive) deployment examples that may be considered: 301 o Port Control Protocol (PCP) [RFC6887] or Session Traversal 302 Utilities for NAT (STUN) [RFC5389] may be used to retrieve the 303 external addresses/prefixes and/or port numbers. Information 304 retrieved by means of PCP or STUN will be used to feed the DOTS 305 data channel messages that will be sent to a DOTS server. 307 o A DOTS gateway may be co-located with the translator. The DOTS 308 gateway will need to update the DOTS messages, based upon the 309 local translator's binding table. 311 When a DOTS gateway is involved in DOTS data channel exchanges, the 312 same considerations for manipulating 'client-identifier' parameter as 313 specified in [I-D.ietf-dots-signal-channel] MUST be followed by DOTS 314 agents. This specification includes examples to illustrate sample 315 messages without any 'client-identifier' parameter, messages with 316 'client-identifier' parameter having one single value, and messages 317 with 'client-identifier' parameter listing multiple values. 319 A DOTS server may detect conflicting filtering requests from the same 320 or distinct DOTS clients which belong to the same domain. For 321 example, a DOTS client would request to blacklist a prefix, while 322 another DOTS client would request to whitelist that same prefix. It 323 is out of scope of this specification to recommend the behavior to 324 follow for handling conflicting requests (e.g., reject all, reject 325 the new request, notify an administrator for validation). DOTS 326 servers SHOULD support a configuration parameter to indicate the 327 behavior to follow when a conflict is detected. Section 7.1 328 specifies the behavior when no instruction is supplied to a DOTS 329 server. 331 4. DOTS Server(s) Discovery 333 This document assumes that DOTS clients are provisioned with the 334 reachability information of their DOTS server(s) using a variety of 335 means (e.g., local configuration, or dynamic means such as DHCP). 336 These means are out of scope of this document. 338 Likewise, it is out of scope of this document to specify the behavior 339 to follow by a DOTS client to place its requests (e.g., contact all 340 servers, select one server among the list) when multiple DOTS servers 341 are provisioned. 343 5. DOTS Data Channel YANG Module 345 5.1. Identifier YANG Tree Structure 347 The YANG module (ietf-dots-data-channel) allows to create 348 identifiers, such as names or aliases, for resources for which 349 mitigation may be requested. Such identifiers may be used in 350 subsequent DOTS signal channel exchanges to refer more efficiently to 351 the resources under attack. The tree structure for DOTS identifiers 352 is as follows: 354 +--rw identifier 355 +--rw client-identifier* binary 356 +--rw alias* [alias-name] 357 +--rw alias-name string 358 +--rw target-prefix* inet:ip-prefix 359 +--rw target-port-range* [lower-port upper-port] 360 | +--rw lower-port inet:port-number 361 | +--rw upper-port inet:port-number 362 +--rw target-protocol* uint8 363 +--rw target-fqdn* inet:domain-name 364 +--rw target-uri* inet:uri 366 This structure is aligned with [I-D.ietf-dots-signal-channel]. 368 5.2. Filter YANG Tree Structure 370 This document augments the Access Control List (ACL) YANG module 371 [I-D.ietf-netmod-acl-model] for managing DOTS filtering rules. The 372 notion of ACL is explained in Section 1 of 373 [I-D.ietf-netmod-acl-model]. 375 Examples of ACL management in a DOTS context include, but not limited 376 to: 378 o Black-list management, which enables a DOTS client to inform a 379 DOTS server about sources from which traffic should be suppressed. 381 o White-list management, which enables a DOTS client to inform a 382 DOTS server about sources from which traffic should always be 383 accepted. 385 o Filter management, which enables a DOTS client to request the 386 installation or removal of traffic filters, dropping or rate- 387 limiting unwanted traffic and permitting white-listed traffic. 389 This document defines the DOTS Data Channel YANG to augment the 390 "ietf-access-control-list" module to support filters based on the 391 client identifier (client-identifier), to support rate-limit action 392 (rate-limit), and to handle fragmented packets (fragments). 394 Filtering fragments adds an additional layer of protection against a 395 DoS attack that uses only non-initial fragments. When there is only 396 Layer 3 information in the ACL entry and the fragments keyword is 397 present, for non-initial fragments matching the ACL entry, the deny 398 or permit action associated with the ACL entry will be enforced and 399 for initial or non-fragment matching the ACL entry, the next ACL 400 entry will be processed. When there is both Layer 3 and Layer 4 401 information in the ACL entry and the fragments keyword is present, 402 the ACL action is conservative for both permit and deny actions. The 403 actions are conservative to not accidentally deny a fragmented 404 portion of a flow because the fragments do not contain sufficient 405 information to match all of the filter attributes. In the deny 406 action case, instead of denying a non-initial fragment, the next ACL 407 entry is processed. In the permit case, it is assumed that the Layer 408 4 information in the non-initial fragment, if available, matches the 409 Layer 4 information in the ACL entry. 411 The tree structure for DOTS filtering rules is as follows: 413 augment /ietf-acl:access-lists: 414 +--rw client-identifier* binary 415 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:actions: 416 +--rw rate-limit? decimal64 417 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl: 418 +--rw fragments? empty 419 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl: 420 +--rw fragments? empty 421 augment /ietf-acl:access-lists: 422 +--rw dots-acl-order 423 +--rw acl-set* [set-name type] 424 +--rw set-name -> /ietf-acl:access-lists/acl/acl-name 425 +--rw type -> /ietf-acl:access-lists/acl/acl-type 427 5.3. YANG Module 429 file "ietf-dots-data-channel@2017-12-18.yang" 431 module ietf-dots-data-channel { 432 yang-version 1.1; 433 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel"; 435 prefix "data-channel"; 437 import ietf-inet-types {prefix "inet";} 438 import ietf-access-control-list {prefix "ietf-acl";} 440 organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 442 contact 443 "WG Web: 444 WG List: 446 Editor: Konda, Tirumaleswar Reddy 447 449 Editor: Mohamed Boucadair 450 452 Author: Kaname Nishizuka 453 455 Author: Liang Xia 456 458 Author: Prashanth Patil 459 461 Author: Andrew Mortensen 462 464 Author: Nik Teague 465 "; 467 description 468 "This module contains YANG definition for configuring 469 identifiers for resources and filtering rules using DOTS 470 data channel. 472 Copyright (c) 2017 IETF Trust and the persons identified as 473 authors of the code. All rights reserved. 475 Redistribution and use in source and binary forms, with or 476 without modification, is permitted pursuant to, and subject 477 to the license terms contained in, the Simplified BSD License 478 set forth in Section 4.c of the IETF Trust's Legal Provisions 479 Relating to IETF Documents 480 (http://trustee.ietf.org/license-info). 482 This version of this YANG module is part of RFC XXXX; see 483 the RFC itself for full legal notices."; 485 revision 2017-12-18 { 486 description 487 "Initial revision."; 488 reference 489 "RFC XXXX: Distributed Denial-of-Service Open Threat 490 Signaling (DOTS) Data Channel"; 491 } 493 container identifier { 494 description "Top level container for identifiers"; 496 leaf-list client-identifier { 497 type binary; 498 description 499 "A client identifier conveyed by a 500 server-side DOTS gateway to a remote DOTS server."; 501 reference 502 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 503 Open Threat Signaling (DOTS) Signal Channel"; 504 } 506 list alias { 507 key alias-name; 508 description 509 "List of identifiers"; 511 leaf alias-name { 512 type string; 513 description "alias name"; 514 } 516 leaf-list target-prefix { 517 type inet:ip-prefix; 518 description 519 "IPv4 or IPv6 prefix identifying the target."; 520 } 522 list target-port-range { 523 key "lower-port upper-port"; 525 description 526 "Port range. When only lower-port is 527 present, it represents a single port."; 529 leaf lower-port { 530 type inet:port-number; 531 mandatory true; 532 description 533 "Lower port number."; 534 } 536 leaf upper-port { 537 type inet:port-number; 538 must ". >= ../lower-port" { 539 error-message 540 "The upper port number must be greater than 541 or equal to lower port number."; 542 } 543 description 544 "Upper port number."; 545 } 546 } 548 leaf-list target-protocol { 549 type uint8; 550 description 551 "Identifies the target protocol number. 553 The value '0' means 'all protocols'. 555 Values are taken from the IANA protocol registry: 556 https://www.iana.org/assignments/protocol-numbers/ 557 protocol-numbers.xhtml 559 For example, 6 for a TCP or 17 for UDP."; 560 } 562 leaf-list target-fqdn { 563 type inet:domain-name; 564 description 565 "FQDN identifying the target."; 566 } 568 leaf-list target-uri { 569 type inet:uri; 570 description 571 "URI identifying the target."; 572 } 573 } 574 } 576 augment "/ietf-acl:access-lists" { 577 description 578 "client-identifier parameter."; 580 leaf-list client-identifier { 581 type binary; 582 description 583 "A client identifier conveyed by a server-side DOTS 584 gateway to a remote DOTS server."; 585 } 586 } 588 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 589 "/ietf-acl:ace/ietf-acl:actions" { 590 description 591 "rate-limit action"; 592 leaf rate-limit { 593 when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/" + 594 "ietf-acl:ace/ietf-acl:actions/" + 595 "ietf-acl:forwarding = 'ietf-acl:accept'" { 596 description 597 "rate-limit valid only when accept action is used"; 598 } 599 type decimal64 { 600 fraction-digits 2; 601 } 602 description 603 "rate-limit traffic"; 604 } 605 } 607 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 608 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl" { 609 description 610 "Handle non-initial and initial fragments for IPv4 packets."; 612 leaf fragments { 613 type empty; 614 description 615 "Handle fragments."; 616 } 617 } 618 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 619 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl" { 620 description 621 "Handle non-initial and initial fragments for IPv6 packets."; 623 leaf fragments { 624 type empty; 625 description 626 "Handle fragments."; 627 } 628 } 630 augment "/ietf-acl:access-lists" { 631 description 632 "Handle ordering of ACLs from a DOTS client"; 634 container dots-acl-order { 635 description 636 "Enclosing container for ordering 637 the ACLs from a DOTS client"; 639 list acl-set { 640 key "set-name type"; 641 ordered-by user; 642 description 643 "List of ACLs"; 645 leaf set-name { 646 type leafref { 647 path "/ietf-acl:access-lists/ietf-acl:acl" + 648 "/ietf-acl:acl-name"; 649 } 650 description 651 "Reference to the ACL set name"; 652 } 653 leaf type { 654 type leafref { 655 path "/ietf-acl:access-lists/ietf-acl:acl" + 656 "/ietf-acl:acl-type"; 657 } 658 description 659 "Reference to the ACL set type"; 660 } 661 } 662 } 663 } 664 } 665 667 6. DOTS Identifiers 669 6.1. Create Identifiers 671 A POST request is used to create identifiers, such as names or 672 aliases, for resources for which a mitigation may be requested. Such 673 identifiers may be used in subsequent DOTS signal channel exchanges 674 to refer more efficiently to the resources under attack (Figure 3). 676 DOTS clients within the same domain can create different aliases for 677 the same resource. 679 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 680 Host: {host}:{port} 681 Content-Type: "application/yang-data+json" 682 { 683 "ietf-dots-data-channel:identifier": { 684 "client-identifier": [ 685 "string" 686 ], 687 "alias": [ 688 { 689 "alias-name": "string", 690 "target-prefix": [ 691 "string" 692 ], 693 "target-port-range": [ 694 { 695 "lower-port": integer, 696 "upper-port": integer 697 } 698 ], 699 "target-protocol": [ 700 integer 701 ], 702 "target-fqdn": [ 703 "string" 704 ], 705 "target-uri": [ 706 "string" 707 ] 708 } 709 ] 710 } 711 } 713 Figure 3: POST to create identifiers 715 The parameters are described below: 717 client-identifier: This attribute has the same meaning, syntax, and 718 processing rules as the 'client-identifier' attribute defined in 719 [I-D.ietf-dots-signal-channel]. 721 This is an optional attribute. 723 alias-name: Name of the alias. 725 This is a mandatory attribute. 727 target-prefix: Prefixes are separated by commas. Prefixes are 728 represented using Classless Inter-domain Routing (CIDR) notation 729 [RFC4632]. As a reminder, the prefix length must be less than or 730 equal to 32 (resp. 128) for IPv4 (resp. IPv6). 732 This is an optional attribute. 734 target-port-range: A range of port numbers. 736 The port range is defined by two bounds, a lower port number 737 (lower-port) and an upper port number (upper-port). 739 When only 'lower-port' is present, it represents a single port 740 number. 742 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 743 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 744 [RFC4340], the range of port numbers can be, for example, 745 1024-65535. 747 This is an optional attribute. 749 target-protocol: A list of protocols. Values are taken from the 750 IANA protocol registry [proto_numbers]. 752 The value '0' has a special meaning for 'all protocols'. 754 This is an optional attribute. 756 target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An 757 FQDN is the full name of a resource, rather than just its 758 hostname. For example, "venera" is a hostname, and 759 "venera.isi.edu" is an FQDN. 761 This is an optional attribute. 763 target-uri: A list of Uniform Resource Identifiers (URIs) 764 [RFC3986]. 766 This is an optional attribute. 768 In the POST request at least one of the attributes 'target-prefix' or 769 'target-fqdn' or 'target-uri' MUST be present. DOTS agents can 770 safely ignore Vendor-Specific parameters they don't understand. 772 Figure 4 shows a POST request to create alias called "https1" for 773 HTTPS servers with IP addresses 2001:db8:6401::1 and 2001:db8:6401::2 774 listening on port 443. 776 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 777 Host: www.example.com 778 Content-Type: "application/yang-data+json" 779 { 780 "ietf-dots-data-channel:identifier": { 781 "alias": [ 782 { 783 "alias-name": "https1", 784 "target-protocol": [ 785 6 786 ], 787 "target-prefix": [ 788 "2001:db8:6401::1/128", 789 "2001:db8:6401::2/128" 790 ], 791 "target-port-range": [ 792 { 793 "lower-port": 443 794 } 795 ] 796 } 797 ] 798 } 799 } 801 Figure 4: POST to create identifiers 803 The DOTS server indicates the result of processing the POST request 804 using status-line codes. Status codes in the range "2xx" codes are 805 success, "4xx" codes are some sort of invalid requests and "5xx" 806 codes are returned if the DOTS server has erred or it is incapable of 807 accepting the alias. 809 "201 Created" status-line is returned in the response if the DOTS 810 server has accepted the alias. 812 If the request is missing one or more mandatory attributes or if the 813 request contains invalid or unknown parameters, then "400 Bad 814 Request" status-line MUST be returned in the response. The HTTP 815 response will include the JSON body received in the request. 817 A DOTS client MAY use the PUT request (Section 4.5 in [RFC8040]) to 818 create or modify the aliases in the DOTS server. 820 6.2. Retrieve Installed Identifiers 822 A GET request is used to retrieve one or all installed identifiers by 823 a DOTS client from a DOTS server (Section 3.3.1 in [RFC8040]). If no 824 'alias-name' parameter is included in the request, this is an 825 indication the request is about retrieving all identifiers 826 instantiated by the DOTS client. 828 Figure 5 shows an example to retrieve all the identifiers that were 829 instantiated by the DOTS client. The content parameter and its 830 permitted values are defined in Section 4.8.1 of [RFC8040]. 832 GET /restconf/data/ietf-dots-data-channel:identifier\ 833 /client-identifier=dz6pHjaADkaFTbjr0JGBpw?\ 834 content=config HTTP/1.1 835 Host: {host}:{port} 836 Accept: application/yang-data+json 838 Figure 5: GET to retrieve all the installed identifiers 840 Figure 6 shows an example of response message body that includes all 841 the identifiers that are maintained by the DOTS server for DOTS 842 client identified by the 'client-identifier' parameter. 844 { 845 "ietf-dots-data-channel:identifier": { 846 "client-identifier": [ 847 "dz6pHjaADkaFTbjr0JGBpw" 848 ], 849 "alias": [ 850 { 851 "alias-name": "Server1", 852 "traffic-protocol": [ 853 6 854 ], 855 "target-prefix": [ 856 "2001:db8:6401::1/128", 857 "2001:db8:6401::2/128" 858 ], 859 "target-port-range": [ 860 { 861 "lower-port": 443 862 } 863 ] 864 }, 865 { 866 "alias-name": "Server2", 867 "target-protocol": [ 868 6 869 ], 870 "target-prefix": [ 871 "2001:db8:6401::10/128", 872 "2001:db8:6401::20/128" 873 ], 874 "target-port-range": [ 875 { 876 "lower-port": 80 877 } 878 ] 879 } 880 ] 881 } 882 } 884 Figure 6: Response body 886 If 'alias-name' parameter is included in the request, but the DOTS 887 server does not find that alias name in its configuration data, it 888 MUST respond with a "404 Not Found" status-line. 890 6.3. Delete Identifiers 892 A DELETE request is used to delete identifiers maintained by a DOTS 893 server. 895 In RESTCONF, URI-encoded path expressions are used. A RESTCONF data 896 resource identifier is encoded from left to right, starting with the 897 top-level data node, according to the 'api-path' rule defined in 898 Section 3.5.3.1 of [RFC8040]. The data node in the path expression 899 is a YANG list node and MUST be encoded according to the rules 900 defined in Section 3.5.1 of [RFC8040]. 902 If the DOTS server does not find the alias name conveyed in the 903 DELETE request in its configuration data, it MUST respond with a "404 904 Not Found" status-line. 906 The DOTS server successfully acknowledges a DOTS client's request to 907 remove the identifier using "204 No Content" status-line in the 908 response. 910 Figure 7 shows an example of a request to delete an alias. 912 DELETE /restconf/data/ietf-dots-data-channel:identifier\ 913 /client-identifier=dz6pHjaADkaFTbjr0JGBpw,\ 914 iAYmCNPmrYoKoqzgFMiobw/alias-name=Server1 HTTP/1.1 915 Host: {host}:{port} 917 Figure 7: DELETE an identifier 919 7. DOTS Filtering Rules 921 The DOTS server either receives the filtering rules directly from the 922 DOTS client or via a DOTS gateway. 924 If the DOTS client signals the filtering rules via a DOTS gateway, 925 the DOTS gateway validates first if the DOTS client is authorized to 926 signal the filtering rules. If the client is authorized, it 927 propagates the rules to the DOTS server. Likewise, the DOTS server 928 validates if the DOTS gateway is authorized to signal the filtering 929 rules. To create or purge filters, the DOTS client sends HTTP 930 requests to its DOTS gateway. The DOTS gateway validates the rules 931 in the requests and proxies the requests containing the filtering 932 rules to a DOTS server. When the DOTS gateway receives the 933 associated HTTP response from the DOTS server, it propagates the 934 response back to the DOTS client. 936 The following sub-sections define means for a DOTS client to 937 configure filtering rules on a DOTS server. 939 7.1. Install Filtering Rules 941 A POST request is used to push filtering rules to a DOTS server. 943 Figure 8 shows a POST request example to block traffic from 944 192.0.2.0/24, destined to 198.51.100.0/24. The ACL JSON 945 configuration for the filtering rule is generated using the ACL YANG 946 module (Section 4.3 of [I-D.ietf-netmod-acl-model]). 948 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 949 Host: www.example.com 950 Content-Type: "application/yang-data+json" 951 { 952 "ietf-dots-data-channel:access-lists": { 953 "client-identifier": [ 954 "dz6pHjaADkaFTbjr0JGBpw" 955 ], 956 "acl": [ 957 { 958 "acl-name": "sample-ipv4-acl", 959 "acl-type": "ipv4-acl", 960 "aces": { 961 "ace": [ 962 { 963 "rule-name": "rule1", 964 "matches": { 965 "ipv4-acl": { 966 "source-ipv4-network": "192.0.2.0/24", 967 "destination-ipv4-network": "198.51.100.0/24" 968 } 969 }, 970 "actions": { 971 "forwarding" : "drop" 972 } 973 } 974 ] 975 } 976 } 977 ] 978 } 979 } 981 Figure 8: POST to install filtering rules 983 The parameters defined in [I-D.ietf-netmod-acl-model] are discussed 984 below: 986 acl-name: The name of access-list. This is a mandatory attribute. 988 acl-type: Indicates the primary intended type of match criteria 989 (e.g., IPv4, IPv6). This is a mandatory attribute. 991 protocol: Internet Protocol numbers. This is an optional 992 attribute. 994 source-ipv4-network: The source IPv4 prefix. This is an optional 995 attribute. 997 destination-ipv4-network: The destination IPv4 prefix. This is an 998 optional attribute. 1000 actions: Actions in the forwarding ACL category can be "drop" or 1001 "accept" or "rate-limit". "accept" action is used to white-list 1002 traffic. "drop" action is used to black-list traffic. "rate- 1003 limit" action is used to rate-limit traffic, the allowed traffic 1004 rate is represented in bytes per second indicated in IEEE floating 1005 point format [IEEE.754.1985]. This is an optional attribute. 1007 The DOTS server indicates the result of processing the POST request 1008 using status-line header. "2xx" codes are success, 4xx codes are some 1009 sort of invalid requests, and 5xx codes are returned if the DOTS 1010 server has erred or it is incapable of configuring the filtering 1011 rules. Concretely, "201 Created" status-line MUST be returned in the 1012 response if the DOTS server has accepted the filtering rules. If the 1013 request is missing one or more mandatory attributes or contains 1014 invalid or unknown parameters, then "400 Bad Request" status-line 1015 MUST be returned in the response. 1017 If the request is conflicting with an existing filtering, the DOTS 1018 server returns "409 Conflict" status-line to the requesting DOTS 1019 client. The error-tag "invalid-value" is used in this case. 1021 The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] 1022 MAY be used to specify how a ACE is inserted within an ACL and how a 1023 ACL is inserted within an ACL list. 1025 The DOTS client MAY use the PUT request to create or modify the 1026 filtering rules in the DOTS server. 1028 7.2. Retrieve Installed Filtering Rules 1030 The DOTS client periodically queries the DOTS server to check the 1031 counters for installed filtering rules. A GET request is used to 1032 retrieve filtering rules from a DOTS server. 1034 If the DOTS server does not find the access list name and access list 1035 type conveyed in the GET request in its configuration data, it 1036 responds with a "404 Not Found" status-line. 1038 Figure 9 shows how to retrieve all the filtering rules programmed by 1039 the DOTS client and the number of matches for the installed filtering 1040 rules. 1042 GET /restconf/data/ietf-dots-data-channel:access-lists\ 1043 /client-identifier=dz6pHjaADkaFTbjr0JGBpw?\ 1044 content=all HTTP/1.1 1045 Host: {host}:{port} 1046 Accept: application/yang-data+json 1048 Figure 9: GET to retrieve the configuration data and state data for 1049 the filtering rules 1051 7.3. Remove Filtering Rules 1053 A DELETE request is used to delete filtering rules from a DOTS 1054 server. 1056 If the DOTS server does not find the access list name and access list 1057 type conveyed in the DELETE request in its configuration data, then 1058 it responds with a "404 Not Found" status-line. The DOTS server 1059 successfully acknowledges a DOTS client's request to withdraw the 1060 filtering rules using "204 No Content" status-line, and removes the 1061 filtering rules as soon as possible. 1063 Figure 10 shows an example of a request to remove the IPv4 ACL named 1064 "sample-ipv4-acl". This request is being relayed by a DOTS gateway 1065 as hinted by the presence of the 'client-identifier' parameter. 1067 DELETE /restconf/data/ietf-dots-data-channel:access-lists\ 1068 /client-identifier=dz6pHjaADkaFTbjr0JGBpw\ 1069 /acl-name=sample-ipv4-acl&\ 1070 acl-type=ipv4-acl HTTP/1.1 1071 Host: {host}:{port} 1073 Figure 10: DELETE to remove the filtering rules 1075 8. IANA Considerations 1077 8.1. DOTS Data Channel JSON Attribute Mappings Registry 1079 The document requests IANA to create a new registry, entitled "DOTS 1080 Data Channel JSON Attribute Mappings Registry". The structure of 1081 this registry is provided in Section 8.1.1. 1083 The registry is initially populated with the values in Section 8.1.2. 1085 Values from that registry MUST be assigned via Expert Review 1086 [RFC8126]. 1088 8.1.1. Registration Template 1090 JSON Attribute: 1091 JSON attribute name. 1093 Description: 1094 Brief description of the attribute. 1096 Change Controller: 1097 For Standards Track RFCs, list the "IESG". For others, give the 1098 name of the responsible party. Other details (e.g., postal 1099 address, email address, home page URI) may also be included. 1101 Specification Document(s): 1102 Reference to the document or documents that specify the parameter, 1103 preferably including URIs that can be used to retrieve copies of 1104 the documents. An indication of the relevant sections may also be 1105 included but is not required. 1107 8.1.2. Initial Registry Contents 1109 o JSON Attribute: "client-identifier" 1110 o Description: Client identifier. 1111 o Change Controller: IESG 1112 o Specification Document(s): this document 1114 o JSON Attribute: "alias-name" 1115 o Description: Name of alias. 1116 o Change Controller: IESG 1117 o Specification Document(s): this document 1119 o JSON Attribute: "target-protocol" 1120 o Description: Internet protocol numbers. 1121 o Change Controller: IESG 1122 o Specification Document(s): this document 1124 o JSON Attribute: "target-port-range" 1125 o Description: The port range, lower-port for lower port number and 1126 upper-port for upper port number. For TCP, UDP, SCTP, or DCCP: a 1127 range of ports can be, e.g., 80 to 8080. 1128 o Change Controller: IESG 1129 o Specification Document(s): this document 1130 o JSON Attribute: "lower-port" 1131 o Description: Lower port number for the port range. 1132 o Change Controller: IESG 1133 o Specification Document(s): this document 1135 o JSON Attribute: "upper-port" 1136 o Description: Upper port number for the port range. 1137 o Change Controller: IESG 1138 o Specification Document(s): this document 1140 o JSON Attribute: "target-prefix" 1141 o Description: IP prefix 1142 o Change Controller: IESG 1143 o Specification Document(s): this document 1145 o JSON Attribute: "target-fqdn" 1146 o Description: Fully Qualified Domain Name, is the full name of a 1147 system, rather than just its hostname. For example, "venera" is a 1148 hostname, and "venera.isi.edu" is an FQDN. 1149 o Change Controller: IESG 1150 o Specification Document(s): this document 1152 o JSON Attribute: "target-uri" 1153 o Description: Uniform Resource Identifier (URI). 1154 o Change Controller: IESG 1155 o Specification Document(s): this document 1157 8.2. YANG Module 1159 This document requests IANA to register the following URI in the 1160 "IETF XML Registry" [RFC3688]: 1162 URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1163 Registrant Contact: The IESG. 1164 XML: N/A; the requested URI is an XML namespace. 1166 This document requests IANA to register the following YANG module in 1167 the "YANG Module Names" registry [RFC7950]. 1169 name: ietf-dots-data-channel 1170 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1171 prefix: data-channel 1172 reference: RFC XXXX 1174 9. Contributors 1176 The following individuals have contributed to this document: 1178 Dan Wing 1180 Email: dwing-ietf@fuggles.com 1182 10. Security Considerations 1184 RESTCONF security considerations are discussed in [RFC8040]. In 1185 particular, DOTS agents MUST follow the security recommendations in 1186 Sections 2 and 12 of [RFC8040] and the mutual authentication TLS 1187 profile discussed in Section 7.1 of [I-D.ietf-dots-signal-channel]. 1189 Authenticated encryption MUST be used for data confidentiality and 1190 message integrity. The interaction between the DOTS agents requires 1191 Transport Layer Security (TLS) with a cipher suite offering 1192 confidentiality protection and the guidance given in [RFC7525] MUST 1193 be followed to avoid attacks on TLS. 1195 An attacker may be able to inject RST packets, bogus application 1196 segments, etc., regardless of whether TLS authentication is used. 1197 Because the application data is TLS protected, this will not result 1198 in the application receiving bogus data, but it will constitute a DoS 1199 on the connection. This attack can be countered by using TCP-AO 1200 [RFC5925]. If TCP-AO is used, then any bogus packets injected by an 1201 attacker will be rejected by the TCP-AO integrity check and therefore 1202 will never reach the TLS layer. 1204 In order to prevent leaking internal information outside a client- 1205 domain, client-side DOTS gateways SHOULD NOT reveal the identity of 1206 internal DOTS clients (client-identifier) unless explicitly 1207 configured to do so. 1209 Special care should be taken in order to ensure that the activation 1210 of the proposed mechanism won't have an impact on the stability of 1211 the network (including connectivity and services delivered over that 1212 network). 1214 All data nodes defined in the YANG module which can be created, 1215 modified, and deleted (i.e., config true, which is the default) are 1216 considered sensitive. Write operations applied to these data nodes 1217 without proper protection can negatively affect network operations. 1218 Appropriate security measures are recommended to prevent illegitimate 1219 users from invoking DOTS data channel primitives. Nevertheless, an 1220 attacker who is able to access to a DOTS client can undertake various 1221 attacks, such as: 1223 o Set an arbitrarily low rate-limit that may lead to discarding 1224 legitimate traffic to be forwarded (rate-limit). 1225 o Set an arbitrarily high rate-limit that may lead to allowing 1226 illegitimate DDoS traffic to be forwarded (rate-limit). 1227 o Communicate invalid aliases to the server (alias) that will lead 1228 to failure to associate both data and signal channels. 1229 o Set invalid ACL entries that may lead to discard legitimate 1230 traffic from being forwarding. Likewise, invalid ACL entries may 1231 lead to forward DDoS traffic. 1233 11. Acknowledgements 1235 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud 1236 Doron, Russ White, Jon Shallow, Gilbert Clark, and Nesredien Suleiman 1237 for the discussion and comments. 1239 12. References 1241 12.1. Normative References 1243 [I-D.ietf-dots-architecture] 1244 Mortensen, A., Andreasen, F., Reddy, T., 1245 christopher_gray3@cable.comcast.com, c., Compton, R., and 1246 N. Teague, "Distributed-Denial-of-Service Open Threat 1247 Signaling (DOTS) Architecture", draft-ietf-dots- 1248 architecture-05 (work in progress), October 2017. 1250 [I-D.ietf-dots-signal-channel] 1251 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 1252 Teague, "Distributed Denial-of-Service Open Threat 1253 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 1254 channel-13 (work in progress), December 2017. 1256 [I-D.ietf-netmod-acl-model] 1257 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 1258 "Network Access Control List (ACL) YANG Data Model", 1259 draft-ietf-netmod-acl-model-14 (work in progress), October 1260 2017. 1262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1263 Requirement Levels", BCP 14, RFC 2119, 1264 DOI 10.17487/RFC2119, March 1997, 1265 . 1267 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1268 DOI 10.17487/RFC3688, January 2004, 1269 . 1271 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1272 (CIDR): The Internet Address Assignment and Aggregation 1273 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1274 2006, . 1276 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1277 (TLS) Protocol Version 1.2", RFC 5246, 1278 DOI 10.17487/RFC5246, August 2008, 1279 . 1281 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1282 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1283 June 2010, . 1285 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1286 Protocol (HTTP/1.1): Message Syntax and Routing", 1287 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1288 . 1290 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1291 "Recommendations for Secure Use of Transport Layer 1292 Security (TLS) and Datagram Transport Layer Security 1293 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1294 2015, . 1296 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1297 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1298 . 1300 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1301 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1302 . 1304 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1305 Writing an IANA Considerations Section in RFCs", BCP 26, 1306 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1307 . 1309 12.2. Informative References 1311 [I-D.ietf-dots-requirements] 1312 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1313 Denial of Service (DDoS) Open Threat Signaling 1314 Requirements", draft-ietf-dots-requirements-08 (work in 1315 progress), December 2017. 1317 [I-D.ietf-netmod-yang-tree-diagrams] 1318 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1319 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1320 October 2017. 1322 [IEEE.754.1985] 1323 Institute of Electrical and Electronics Engineers, 1324 "Standard for Binary Floating-Point Arithmetic", August 1325 1985. 1327 [proto_numbers] 1328 "IANA, "Protocol Numbers"", 2011, 1329 . 1331 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1332 Resource Identifier (URI): Generic Syntax", STD 66, 1333 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1334 . 1336 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1337 Congestion Control Protocol (DCCP)", RFC 4340, 1338 DOI 10.17487/RFC4340, March 2006, 1339 . 1341 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1342 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1343 . 1345 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1346 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1347 DOI 10.17487/RFC5389, October 2008, 1348 . 1350 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1351 the Network Configuration Protocol (NETCONF)", RFC 6020, 1352 DOI 10.17487/RFC6020, October 2010, 1353 . 1355 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1356 and A. Bierman, Ed., "Network Configuration Protocol 1357 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1358 . 1360 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1361 Layer Security (TLS) and Datagram Transport Layer Security 1362 (DTLS) Heartbeat Extension", RFC 6520, 1363 DOI 10.17487/RFC6520, February 2012, 1364 . 1366 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1367 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1368 DOI 10.17487/RFC6887, April 2013, 1369 . 1371 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1372 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1373 2014, . 1375 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1376 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1377 . 1379 Authors' Addresses 1381 Tirumaleswar Reddy (editor) 1382 McAfee, Inc. 1383 Embassy Golf Link Business Park 1384 Bangalore, Karnataka 560071 1385 India 1387 Email: kondtir@gmail.com 1389 Mohamed Boucadair (editor) 1390 Orange 1391 Rennes 35000 1392 France 1394 Email: mohamed.boucadair@orange.com 1396 Kaname Nishizuka 1397 NTT Communications 1398 GranPark 16F 3-4-1 Shibaura, Minato-ku 1399 Tokyo 108-8118 1400 Japan 1402 Email: kaname@nttv6.jp 1404 Liang Xia 1405 Huawei 1406 101 Software Avenue, Yuhuatai District 1407 Nanjing, Jiangsu 210012 1408 China 1410 Email: frank.xialiang@huawei.com 1411 Prashanth Patil 1412 Cisco Systems, Inc. 1414 Email: praspati@cisco.com 1416 Andrew Mortensen 1417 Arbor Networks, Inc. 1418 2727 S. State St 1419 Ann Arbor, MI 48104 1420 United States 1422 Email: amortensen@arbor.net 1424 Nik Teague 1425 Verisign, Inc. 1426 United States 1428 Email: nteague@verisign.com