idnits 2.17.1 draft-ietf-dots-data-channel-10.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 307 has weird spacing: '...er-port ine...' == Line 308 has weird spacing: '...er-port ine...' -- The document date (December 7, 2017) is 2325 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-09 == 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-07 == 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 7159 (Obsoleted by RFC 8259) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 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 10, 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 7, 2017 18 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel 19 draft-ietf-dots-data-channel-10 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 10, 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 . . . . . . . . . . . . . . . . . . 6 81 5. DOTS Data Channel YANG Module . . . . . . . . . . . . . . . . 7 82 5.1. Identifier YANG Tree Structure . . . . . . . . . . . . . 7 83 5.2. Filter YANG Tree Structure . . . . . . . . . . . . . . . 7 84 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 85 6. DOTS Identifiers . . . . . . . . . . . . . . . . . . . . . . 13 86 6.1. Create Identifiers . . . . . . . . . . . . . . . . . . . 13 87 6.2. Retrieve Installed Identifiers . . . . . . . . . . . . . 17 88 6.3. Delete Identifiers . . . . . . . . . . . . . . . . . . . 19 89 7. DOTS Filtering Rules . . . . . . . . . . . . . . . . . . . . 19 90 7.1. Install Filtering Rules . . . . . . . . . . . . . . . . . 20 91 7.2. Retrieve Installed Filtering Rules . . . . . . . . . . . 21 92 7.3. Remove Filtering Rules . . . . . . . . . . . . . . . . . 22 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 8.1. DOTS Data Channel JSON Attribute Mappings Registry . . . 22 95 8.1.1. Registration Template . . . . . . . . . . . . . . . . 23 96 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23 97 8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24 98 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 103 12.2. Informative References . . . . . . . . . . . . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 this attack can be an application 113 server, a client, a router, a firewall, or an entire network. 115 DDoS Open Threat Signaling (DOTS) [I-D.ietf-dots-architecture] 116 defines two channels: signal and data channels (Figure 1). The DOTS 117 signal channel used to convey that a network is under a DDOS attack 118 to an upstream DOTS server so that appropriate mitigation actions are 119 undertaken on the suspect traffic is further elaborated in 120 [I-D.ietf-dots-signal-channel]. The DOTS data channel is used for 121 infrequent bulk data exchange between DOTS agents in the aim to 122 significantly augment attack response coordination. 124 +---------------+ +---------------+ 125 | | <------- Signal Channel ------> | | 126 | DOTS Client | | DOTS Server | 127 | | <======= Data Channel ======> | | 128 +---------------+ +---------------+ 130 Figure 1: DOTS Channels 132 Section 2 of [I-D.ietf-dots-architecture] identifies that the DOTS 133 data channel is used to perform the tasks listed below: 135 o Creating identifiers, such as names or aliases, for resources for 136 which mitigation may be requested: 138 A. The DOTS client may submit to the DOTS server a collection of 139 prefixes which it would like to refer to by alias when 140 requesting mitigation. The server can respond to this request 141 with either with a success or failure response (see 142 requirement OP-006 in [I-D.ietf-dots-requirements] and 143 Section 2 in [I-D.ietf-dots-architecture]). 145 Refer to Section 6. 147 o Filter management, which enables a DOTS client to request the 148 installation or removal of traffic filters, dropping or rate- 149 limiting unwanted traffic and permitting white-listed traffic. 150 Sample use cases for populating black- or white-list filtering 151 rules are detailed hereafter: 153 A. If a network resource (DOTS client) detects a potential DDoS 154 attack from a set of IP addresses, the DOTS client informs its 155 servicing router (DOTS gateway) of all suspect IP addresses 156 that need to be blocked or black-listed for further 157 investigation. The DOTS client could also specify a list of 158 protocols and ports in the black-list rule. That DOTS gateway 159 in-turn propagates the black-listed IP addresses to the DOTS 160 server which will undertake appropriate action so that traffic 161 from these IP addresses to the target network (specified by 162 the DOTS client) is blocked. 164 B. A network has partner sites from which only legitimate traffic 165 arrives and the network wants to ensure that the traffic from 166 these sites is not penalized during DDOS attacks. The DOTS 167 client uses the DOTS data channel to convey the white-listed 168 IP addresses or prefixes of the partner sites to its DOTS 169 server. The DOTS server uses this information to white-list 170 flows from such IP addresses or prefixes reaching the network. 172 Refer to Section 7. 174 2. Notational Conventions and Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 The reader should be familiar with the terms defined in 181 [I-D.ietf-dots-architecture]. 183 The terminology for describing YANG data modules is defined in 184 [RFC7950]. The meaning of the symbols in tree diagrams is defined in 185 [I-D.ietf-netmod-yang-tree-diagrams]. 187 For simplicity, all of the examples in this document use "/restconf" 188 as the discovered RESTCONF API root path. Many protocol header lines 189 and message-body text within examples throughout the document are 190 split into multiple lines for display purposes only. When a line 191 ends with backslash ('\') as the last character, the line is wrapped 192 for display purposes. It is to be considered to be joined to the 193 next line by deleting the backslash, the following line break, and 194 the leading whitespace of the next line. 196 3. DOTS Data Channel: Design Overview 198 The DOTS data channel is intended to be used for bulk data exchanges 199 between DOTS agents. Unlike the signal channel 200 [I-D.ietf-dots-signal-channel], which must operate nominally even 201 when confronted with signal degradation due to packets loss, the data 202 channel is not expected to be constructed to deal with DDoS attack 203 conditions. 205 As the primary function of the data channel is data exchange, a 206 reliable transport is required in order for DOTS agents to detect 207 data delivery success or failure. RESTCONF [RFC8040] over TLS 208 [RFC5246] over TCP is used for DOTS data channel (Figure 2). 209 RESTCONF uses HTTP methods to provide CRUD (create, read, update, 210 delete) operations on a conceptual datastore containing YANG data, 211 which is compatible with a server implementing NETCONF datastores. 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 The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data 229 resources represented by DOTS data channel YANG data models. These 230 basic edit operations allow the DOTS data channel running 231 configuration to be altered by a DOTS client. 233 DOTS data channel configuration data and state data can be retrieved 234 with the GET method. HTTP status codes are used to report success or 235 failure for RESTCONF operations. 237 The DOTS client will perform the root resource discovery procedure 238 discussed in Section 3.1 of [RFC8040] to determine the root of the 239 RESTCONF API. After discovering the RESTCONF API root, the DOTS 240 client uses this value as the initial part of the path in the request 241 URI, in any subsequent request to the DOTS server. The DOTS server 242 may support retrieval of the YANG modules it supports (Section 3.7 in 243 [RFC8040]), for example, a DOTS client may use RESTCONF to retrieve 244 the company proprietary YANG modules supported by the DOTS server. 246 Note: This document uses RESTCONF, a protocol based on HTTP 247 [RFC7230], for configuring data defined in YANG version 1 248 [RFC6020] or YANG version 1.1 [RFC7950], using the datastore 249 concepts defined in the Network Configuration Protocol (NETCONF) 250 [RFC6241]. RESTCONF combines the simplicity of the HTTP protocol 251 with the predictability and automation potential of a schema- 252 driven API. RESTCONF offers a simple subset of NETCONF 253 functionality and provides a simplified interface using REST-like 254 API which addresses the needs of the DOTS data channel and hence 255 an optimal choice. 257 JavaScript Object Notation (JSON) [RFC7159] payload is used to 258 propagate data channel specific payload messages that convey request 259 parameters and response information such as errors. This 260 specification uses the encoding rules defined in [RFC7951] for 261 representing DOTS data channel configuration data defined using YANG 262 (Section 5) as JSON text. 264 A DOTS client registers itself to its DOTS server(s) in order to set 265 up DOTS data channel related configuration data and receive state 266 data (i.e., non-configuration data) from the DOTS server(s). 268 A single DOTS data channel between DOTS agents can be used to 269 exchange multiple requests and multiple responses. To reduce DOTS 270 client and DOTS server workload, DOTS client SHOULD re-use the same 271 TLS session. While the communication to the DOTS server is 272 quiescent, the DOTS client MAY probe the server to ensure it has 273 maintained cryptographic state. Such probes can also keep alive 274 firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies the 275 DOTS server still has TLS state by returning a TLS message. 277 4. DOTS Server(s) Discovery 279 This document assumes that DOTS clients are provisioned with the 280 reachability information of their DOTS server(s) using a variety of 281 means (e.g., local configuration, or dynamic means such as DHCP). 282 These means are out of scope of this document. 284 Likewise, it is out of scope of this document to specify the behavior 285 to follow by a DOTS client to place its requests (e.g., contact all 286 servers, select one server among the list) when multiple DOTS servers 287 are provisioned. 289 5. DOTS Data Channel YANG Module 291 5.1. Identifier YANG Tree Structure 293 This document defines a YANG module (ietf-dots-data-channel) for 294 creating identifiers, such as names or aliases, for resources for 295 which mitigation may be requested. Such identifiers may be used in 296 subsequent DOTS signal channel exchanges to refer more efficiently to 297 the resources under attack. The tree structure for DOTS identifiers 298 is as follows: 300 +--rw identifier 301 +--rw client-identifier* binary 302 +--rw alias* [alias-name] 303 +--rw alias-name string 304 +--rw target-ip* inet:ip-address 305 +--rw target-prefix* inet:ip-prefix 306 +--rw target-port-range* [lower-port upper-port] 307 | +--rw lower-port inet:port-number 308 | +--rw upper-port inet:port-number 309 +--rw target-protocol* uint8 310 +--rw target-fqdn* inet:domain-name 311 +--rw target-uri* inet:uri 313 This structure is aligned with [I-D.ietf-dots-signal-channel]. 315 5.2. Filter YANG Tree Structure 317 This document augments the "ietf-access-control-list" Access Control 318 List (ACL) YANG module [I-D.ietf-netmod-acl-model] for managing 319 filtering rules. ACL is explained in Section 1 of 320 [I-D.ietf-netmod-acl-model]. 322 Examples of ACL management include, but not limited to,: 324 o Black-list management, which enables a DOTS client to inform the 325 DOTS server about sources from which traffic should be suppressed. 327 o White-list management, which enables a DOTS client to inform the 328 DOTS server about sources from which traffic should always be 329 accepted. 331 o Filter management, which enables a DOTS client to request the 332 installation or removal of traffic filters, dropping or rate- 333 limiting unwanted traffic and permitting white-listed traffic. 335 This document defines the DOTS Data Channel YANG to augment the 336 "ietf-access-control-list" module to support filters based on the 337 client identifier (client-identifier), to support rate-limit action 338 (rate-limit), and to handle fragmented packets (fragments). 340 Filtering fragments adds an additional layer of protection against a 341 DoS attack that uses only non-initial fragments. When there is only 342 Layer 3 information in the ACL entry and the fragments keyword is 343 present, for non-initial fragments matching the ACL entry, the deny 344 or permit action associated with the ACL entry will be enforced and 345 for initial or non-fragment matching the ACL entry, the next ACL 346 entry will be processed. When there is both Layer 3 and Layer 4 347 information in the ACL entry and the fragments keyword is present, 348 the ACL action is conservative for both permit and deny actions. The 349 actions are conservative to not accidentally deny a fragmented 350 portion of a flow because the fragments do not contain sufficient 351 information to match all of the filter attributes. In the deny 352 action case, instead of denying a non-initial fragment, the next ACL 353 entry is processed. In the permit case, it is assumed that the Layer 354 4 information in the non-initial fragment, if available, matches the 355 Layer 4 information in the ACL entry. 357 The tree structure for DOTS filtering rules is as follows: 359 augment /ietf-acl:access-lists: 360 +--rw client-identifier* binary 361 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:actions: 362 +--rw rate-limit? decimal64 363 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl: 364 +--rw fragments? empty 365 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl: 366 +--rw fragments? empty 367 augment /ietf-acl:access-lists: 368 +--rw dots-acl-order 369 +--rw acl-set* [set-name type] 370 +--rw set-name -> /ietf-acl:access-lists/acl/acl-name 371 +--rw type -> /ietf-acl:access-lists/acl/acl-type 373 5.3. YANG Module 375 file "ietf-dots-data-channel@2017-12-08.yang" 377 module ietf-dots-data-channel { 378 yang-version 1.1; 379 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel"; 381 prefix "data-channel"; 383 import ietf-inet-types {prefix "inet";} 384 import ietf-access-control-list {prefix "ietf-acl";} 385 organization "IETF DOTS Working Group"; 387 contact 388 "Konda, Tirumaleswar Reddy 389 Mohamed Boucadair 390 Kaname Nishizuka 391 Liang Xia 392 Prashanth Patil 393 Andrew Mortensen 394 Nik Teague "; 396 description 397 "This module contains YANG definition for configuring 398 identifiers for resources and filtering rules using DOTS 399 data channel. 401 Copyright (c) 2017 IETF Trust and the persons identified as 402 authors of the code. All rights reserved. 404 Redistribution and use in source and binary forms, with or 405 without modification, is permitted pursuant to, and subject 406 to the license terms contained in, the Simplified BSD License 407 set forth in Section 4.c of the IETF Trust's Legal Provisions 408 Relating to IETF Documents 409 (http://trustee.ietf.org/license-info). 411 This version of this YANG module is part of RFC XXXX; see 412 the RFC itself for full legal notices."; 414 revision 2017-12-08 { 415 description 416 "Initial revision."; 417 reference 418 "RFC XXXX: Distributed Denial-of-Service Open Threat 419 Signaling (DOTS) Data Channel"; 420 } 422 container identifier { 423 description "Top level container for identifiers"; 425 leaf-list client-identifier { 426 type binary; 427 description 428 "A client identifier conveyed by a 429 DOTS gateway to a remote DOTS server."; 430 reference 431 "I-D.itef-dots-signal-channel: Distributed Denial-of-Service 432 Open Threat Signaling (DOTS) Signal Channel"; 434 } 436 list alias { 437 key alias-name; 438 description 439 "List of identifiers"; 441 leaf alias-name { 442 type string; 443 description "alias name"; 444 } 446 leaf-list target-ip { 447 type inet:ip-address; 448 description 449 "IPv4 or IPv6 address identifying the target."; 450 } 452 leaf-list target-prefix { 453 type inet:ip-prefix; 454 description 455 "IPv4 or IPv6 prefix identifying the target."; 456 } 458 list target-port-range { 459 key "lower-port upper-port"; 461 description 462 "Port range. When only lower-port is 463 present, it represents a single port."; 465 leaf lower-port { 466 type inet:port-number; 467 mandatory true; 468 description "Lower port number."; 469 } 471 leaf upper-port { 472 type inet:port-number; 473 must ". >= ../lower-port" { 474 error-message 475 "The upper port number must be greater than 476 or equal to lower port number."; 477 } 478 description "Upper port number."; 479 } 480 } 481 leaf-list target-protocol { 482 type uint8; 483 description 484 "Identifies the target protocol number. 486 The value '0' means 'all protocols'. 488 Values are taken from the IANA protocol registry: 489 https://www.iana.org/assignments/protocol-numbers/ 490 protocol-numbers.xhtml 492 For example, 6 for a TCP or 17 for UDP."; 493 } 495 leaf-list target-fqdn { 496 type inet:domain-name; 497 description "FQDN identifying the target."; 498 } 500 leaf-list target-uri { 501 type inet:uri; 502 description "URI identifying the target."; 503 } 504 } 505 } 507 augment "/ietf-acl:access-lists" { 508 description "client-identifier parameter."; 510 leaf-list client-identifier { 511 type binary; 512 description 513 "A client identifier conveyed by a DOTS gateway 514 to a remote DOTS server."; 515 } 516 } 518 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 519 "/ietf-acl:ace/ietf-acl:actions" { 520 description "rate-limit action"; 521 leaf rate-limit { 522 when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/" + 523 "ietf-acl:ace/ietf-acl:actions/" + 524 "ietf-acl:forwarding = 'ietf-acl:accept'" { 525 description 526 "rate-limit valid only when accept action is used"; 527 } 528 type decimal64 { 529 fraction-digits 2; 530 } 531 description "rate-limit traffic"; 532 } 533 } 535 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 536 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv4-acl" { 537 description 538 "Handle non-initial and initial fragments for IPv4 packets."; 540 leaf fragments { 541 type empty; 542 description "Handle fragments."; 543 } 544 } 546 augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + 547 "/ietf-acl:ace/ietf-acl:matches/ietf-acl:ipv6-acl" { 548 description 549 "Handle non-initial and initial fragments for IPv6 packets."; 551 leaf fragments { 552 type empty; 553 description 554 "Handle fragments."; 555 } 556 } 558 augment "/ietf-acl:access-lists" { 559 description 560 "Handle ordering of ACLs from a DOTS client"; 562 container dots-acl-order { 563 description 564 "Enclosing container for ordering 565 the ACLs from a DOTS client"; 567 list acl-set { 568 key "set-name type"; 569 ordered-by user; 570 description 571 "List of ACLs"; 573 leaf set-name { 574 type leafref { 575 path "/ietf-acl:access-lists/ietf-acl:acl" + 576 "/ietf-acl:acl-name"; 578 } 579 description 580 "Reference to the ACL set name"; 581 } 582 leaf type { 583 type leafref { 584 path "/ietf-acl:access-lists/ietf-acl:acl" + 585 "/ietf-acl:acl-type"; 586 } 587 description 588 "Reference to the ACL set type"; 589 } 590 } 591 } 592 } 593 } 594 596 6. DOTS Identifiers 598 6.1. Create Identifiers 600 A POST request is used to create identifiers, such as names or 601 aliases, for resources for which a mitigation may be requested. Such 602 identifiers may then be used in subsequent DOTS signal channel 603 exchanges to refer more efficiently to the resources under attack 604 (Figure 3). 606 POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 607 Host: {host}:{port} 608 Content-Type: "application/yang-data+json" 609 { 610 "ietf-dots-data-channel:identifier": { 611 "client-identifier": [ 612 "string" 613 ], 614 "alias": [ 615 { 616 "alias-name": "string", 617 "target-ip": [ 618 "string" 619 ], 620 "target-prefix": [ 621 "string" 622 ], 623 "target-port-range": [ 624 { 625 "lower-port": integer, 626 "upper-port": integer 627 } 628 ], 629 "target-protocol": [ 630 integer 631 ], 632 "target-fqdn": [ 633 "string" 634 ], 635 "target-uri": [ 636 "string" 637 ] 638 } 639 ] 640 } 641 } 643 Figure 3: POST to create identifiers 645 The header parameters are described below: 647 client-identifier: This attribute has the same meaning, syntax and 648 processing rules as the 'client-identifier' attribute defined in 649 [I-D.ietf-dots-signal-channel]. This is an optional attribute. 651 alias-name: Name of the alias. This is a mandatory attribute. 653 target-ip: IP addresses are separated by commas. This is an 654 optional attribute. 656 target-prefix: Prefixes are separated by commas. This is an 657 optional attribute. 659 target-port-range: A range of port numbers. 661 The port range is defined by two bounds, a lower port number 662 (lower-port) and an upper port number (upper-port). When only 663 'lower-port' is present, it represents a single port number. For 664 TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], 665 or Datagram Congestion Control Protocol (DCCP) [RFC4340], the 666 range of ports can be, for example, 1024-65535. 668 This is an optional attribute. 670 target-protocol: A list of protocols. Values are taken from the 671 IANA protocol registry [proto_numbers]. 673 The value 0 has a special meaning for 'all protocols'. 675 This is an optional attribute. 677 target-fqdn: A list of Fully Qualified Domain Names (FQDNs). An 678 FQDN is the full name of a resource, rather than just its 679 hostname. For example, "venera" is a hostname, and 680 "venera.isi.edu" is an FQDN. 682 This is an optional attribute. 684 target-uri: A list of Uniform Resource Identifiers (URIs) 685 [RFC3986]. 687 This is an optional attribute. 689 In the POST request at least one of the attributes 'target-ip' or 690 'target-prefix' or 'target-fqdn' or 'target-uri' MUST be present. 691 DOTS agents can safely ignore Vendor-Specific parameters they don't 692 understand. 694 Figure 4 shows a POST request to create alias called "https1" for 695 HTTP(S) servers with IP addresses 2001:db8:6401::1 and 696 2001:db8:6401::2 listening on port 443. 698 POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 699 Host: www.example.com 700 Content-Type: "application/yang-data+json" 701 { 702 "ietf-dots-data-channel:identifier": { 703 "client-identifier": [ 704 "dz6pHjaADkaFTbjr0JGBpw", 705 "iAYmCNPmrYoKoqzgFMiobw" 706 ], 707 "alias": [ 708 { 709 "alias-name": "Server1", 710 "target-protocol": [ 711 6 712 ], 713 "target-ip": [ 714 "2001:db8:6401::1", 715 "2001:db8:6401::2" 716 ], 717 "target-port-range": [ 718 { 719 "lower-port": 443 720 } 721 ] 722 } 723 ] 724 } 725 } 727 Figure 4: POST to create identifiers 729 The DOTS server indicates the result of processing the POST request 730 using HTTP response codes. HTTP 2xx codes are success, HTTP 4xx 731 codes are some sort of invalid requests and 5xx codes are returned if 732 the DOTS server has erred or it is incapable of accepting the alias. 733 Response code 201 (Created) will be returned in the response if the 734 DOTS server has accepted the alias. If the request is missing one or 735 more mandatory attributes or if the request contains invalid or 736 unknown parameters, then 400 (Bad Request) will be returned in the 737 response. The HTTP response will include the JSON body received in 738 the request. 740 The DOTS client can use the PUT request (Section 4.5 in [RFC8040]) to 741 create or modify the aliases in the DOTS server. 743 6.2. Retrieve Installed Identifiers 745 A GET request is used to retrieve the set of installed identifiers 746 from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 5 shows how 747 to retrieve all the identifiers that were instantiated by the DOTS 748 client. The content parameter and its permitted values are defined 749 in Section 4.8.1 of [RFC8040]. 751 GET /restconf/data/ietf-dots-data-channel:identifier\ 752 /client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\ 753 content=config HTTP/1.1 754 Host: {host}:{port} 755 Accept: application/yang-data+json 757 Figure 5: GET to retrieve all the installed identifiers 759 Figure 6 shows response for all identifiers on the DOTS server. 761 { 762 "ietf-dots-data-channel:identifier": { 763 "client-identifier": [ 764 "dz6pHjaADkaFTbjr0JGBpw", 765 "iAYmCNPmrYoKoqzgFMiobw" 766 ], 767 "alias": [ 768 { 769 "alias-name": "Server1", 770 "traffic-protocol": [ 771 6 772 ], 773 "target-ip": [ 774 "2001:db8:6401::1", 775 "2001:db8:6401::2" 776 ], 777 "target-port-range": [ 778 { 779 "lower-port": 443 780 } 781 ] 782 }, 783 { 784 "alias-name": "Server2", 785 "target-protocol": [ 786 6 787 ], 788 "target-ip": [ 789 "2001:db8:6401::10", 790 "2001:db8:6401::20" 791 ], 792 "target-port-range": [ 793 { 794 "lower-port": 80 795 } 796 ] 797 } 798 ] 799 } 800 } 802 Figure 6: Response body 804 If the DOTS server does not find the alias name conveyed in the GET 805 request in its configuration data, then it responds with a 404 (Not 806 Found) error response code. 808 6.3. Delete Identifiers 810 A DELETE request is used to delete identifiers maintained by a DOTS 811 server (Figure 7). 813 DELETE /restconf/data/ietf-dots-data-channel:identifier\ 814 /client-identifier=dz6pHjaADkaFTbjr0JGBpw,\ 815 iAYmCNPmrYoKoqzgFMiobw/alias-name=Server1 HTTP/1.1 816 Host: {host}:{port} 818 Figure 7: DELETE identifier 820 In RESTCONF, URI-encoded path expressions are used. A RESTCONF data 821 resource identifier is encoded from left to right, starting with the 822 top-level data node, according to the 'api-path' rule defined in 823 Section 3.5.3.1 of [RFC8040]. The data node in the above path 824 expression is a YANG list node and MUST be encoded according to the 825 rules defined in Section 3.5.1 of [RFC8040]. 827 If the DOTS server does not find the alias name conveyed in the 828 DELETE request in its configuration data, then it responds with a 404 829 (Not Found) error response code. The DOTS server successfully 830 acknowledges a DOTS client's request to remove the identifier using 831 204 (No Content) in the response. 833 7. DOTS Filtering Rules 835 The DOTS server either receives the filtering rules directly from the 836 DOTS client or via a DOTS gateway. 838 If the DOTS client signals the filtering rules via a DOTS gateway, 839 then the DOTS gateway validates if the DOTS client is authorized to 840 signal the filtering rules and if the client is authorized propagates 841 the rules to the DOTS server. Likewise, the DOTS server validates if 842 the DOTS gateway is authorized to signal the filtering rules. To 843 create or purge filters, the DOTS client sends HTTP requests to its 844 DOTS gateway. The DOTS gateway validates the rules in the requests 845 and proxies the requests containing the filtering rules to a DOTS 846 server. When the DOTS gateway receives the associated HTTP response 847 from the DOTS server, it propagates the response back to the DOTS 848 client. 850 The following APIs define means for a DOTS client to configure 851 filtering rules on a DOTS server. 853 7.1. Install Filtering Rules 855 A POST request is used to push filtering rules to a DOTS server. 856 Figure 8 shows a POST request example to block traffic from 857 192.0.2.0/24, destined to 198.51.100.0/24. The ACL JSON 858 configuration for the filtering rule is generated using the ACL YANG 859 data model defined in [I-D.ietf-netmod-acl-model] and the ACL 860 configuration XML for the filtering rule is specified in Section 4.3 861 of [I-D.ietf-netmod-acl-model]. 863 POST /restconf/data/ietf-dots-data-channel HTTP/1.1 864 Host: www.example.com 865 Content-Type: "application/yang-data+json" 866 { 867 "ietf-dots-data-channel:access-lists": { 868 "client-identifier": [ 869 "dz6pHjaADkaFTbjr0JGBpw", 870 "iAYmCNPmrYoKoqzgFMiobw" 871 ], 872 "acl": [ 873 { 874 "acl-name": "sample-ipv4-acl", 875 "acl-type": "ipv4-acl", 876 "aces": { 877 "ace": [ 878 { 879 "rule-name": "rule1", 880 "matches": { 881 "ipv4-acl": { 882 "source-ipv4-network": "192.0.2.0/24", 883 "destination-ipv4-network": "198.51.100.0/24" 884 } 885 }, 886 "actions": { 887 "forwarding" : "drop" 888 } 889 } 890 ] 891 } 892 } 893 ] 894 } 895 } 897 Figure 8: POST to install filterng rules 899 The header parameters defined in [I-D.ietf-netmod-acl-model] are 900 discussed below: 902 acl-name: The name of access-list. This is a mandatory attribute. 904 acl-type: Indicates the primary intended type of match criteria 905 (e.g., IPv4, IPv6). This is a mandatory attribute. 907 protocol: Internet Protocol numbers. This is an optional 908 attribute. 910 source-ipv4-network: The source IPv4 prefix. This is an optional 911 attribute. 913 destination-ipv4-network: The destination IPv4 prefix. This is an 914 optional attribute. 916 actions: "drop" or "accept" or "rate-limit". "accept" action is 917 used to white-list traffic. "drop" action is used to black-list 918 traffic. "rate-limit" action is used to rate-limit traffic, the 919 allowed traffic rate is represented in bytes per second indicated 920 in IEEE floating point format [IEEE.754.1985]. This is an 921 optional attribute. 923 The DOTS server indicates the result of processing the POST request 924 using HTTP response codes. HTTP 2xx codes are success, HTTP 4xx 925 codes are some sort of invalid requests and 5xx codes are returned if 926 the DOTS server has erred or it is incapable of configuring the 927 filtering rules. Response code 201 (Created) will be returned in the 928 response if the DOTS server has accepted the filtering rules. If the 929 request is missing one or more mandatory attributes or contains 930 invalid or unknown parameters, then 400 (Bad Request) will be 931 returned in the response. 933 The "insert" query parameter discussed in Section 4.8.5 of [RFC8040] 934 can be used to specify how a ACE is inserted within an ACL and how a 935 ACL is inserted within an ACL list. 937 The DOTS client can use the PUT request to create or modify the 938 filtering rules in the DOTS server. 940 7.2. Retrieve Installed Filtering Rules 942 The DOTS client periodically queries the DOTS server to check the 943 counters for installed filtering rules. A GET request is used to 944 retrieve filtering rules from a DOTS server. Figure 9 shows how to 945 retrieve all the filtering rules programmed by the DOTS client and 946 the number of matches for the installed filtering rules. 948 GET /restconf/data/ietf-dots-data-channel:access-lists\ 949 /client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\ 950 content=all HTTP/1.1 951 Host: {host}:{port} 952 Accept: application/yang-data+json 954 Figure 9: GET to retrieve the configuration data and state data for 955 the filtering rules 957 If the DOTS server does not find the access list name and access list 958 type conveyed in the GET request in its configuration data, then it 959 responds with a 404 (Not Found) error response code. 961 7.3. Remove Filtering Rules 963 A DELETE request is used to delete filtering rules from a DOTS server 964 (Figure 10). 966 DELETE /restconf/data/ietf-dots-data-channel:access-lists\ 967 /client-identifier=dz6pHjaADkaFTbjr0JGBpw,\ 968 iAYmCNPmrYoKoqzgFMiobw/acl-name=sample-ipv4-acl&\ 969 acl-type=ipv4-acl HTTP/1.1 970 Host: {host}:{port} 972 Figure 10: DELETE to remove the filtering rules 974 If the DOTS server does not find the access list name and access list 975 type conveyed in the DELETE request in its configuration data, then 976 it responds with a 404 (Not Found) error response code. The DOTS 977 server successfully acknowledges a DOTS client's request to withdraw 978 the filtering rules using 204 (No Content) response code, and removes 979 the filtering rules as soon as possible. 981 8. IANA Considerations 983 8.1. DOTS Data Channel JSON Attribute Mappings Registry 985 The document requests IANA to create a new registry, entitled "DOTS 986 Data Channel JSON Attribute Mappings Registry". The structure of 987 this registry is provided in Section 8.1.1. 989 The registry is initially populated with the values in Section 8.1.2. 991 Values from that registry MUST be assigned via Expert Review 992 [RFC8126]. 994 8.1.1. Registration Template 996 JSON Attribute: 997 JSON attribute name. 999 Description: 1000 Brief description of the attribute. 1002 Change Controller: 1003 For Standards Track RFCs, list the "IESG". For others, give the 1004 name of the responsible party. Other details (e.g., postal 1005 address, email address, home page URI) may also be included. 1007 Specification Document(s): 1008 Reference to the document or documents that specify the parameter, 1009 preferably including URIs that can be used to retrieve copies of 1010 the documents. An indication of the relevant sections may also be 1011 included but is not required. 1013 8.1.2. Initial Registry Contents 1015 o JSON Attribute: "client-identifier" 1016 o Description: Client identifier. 1017 o Change Controller: IESG 1018 o Specification Document(s): this document 1020 o JSON Attribute: "alias-name" 1021 o Description: Name of alias. 1022 o Change Controller: IESG 1023 o Specification Document(s): this document 1025 o JSON Attribute: "target-protocol" 1026 o Description: Internet protocol numbers. 1027 o Change Controller: IESG 1028 o Specification Document(s): this document 1030 o JSON Attribute: "target-port-range" 1031 o Description: The port range, lower-port for lower port number and 1032 upper-port for upper port number. For TCP, UDP, SCTP, or DCCP: a 1033 range of ports can be, e.g., 80 to 8080. 1034 o Change Controller: IESG 1035 o Specification Document(s): this document 1037 o JSON Attribute: "lower-port" 1038 o Description: Lower port number for the port range. 1039 o Change Controller: IESG 1040 o Specification Document(s): this document 1041 o JSON Attribute: "upper-port" 1042 o Description: Upper port number for the port range. 1043 o Change Controller: IESG 1044 o Specification Document(s): this document 1046 o JSON Attribute: "target-ip" 1047 o Description: IP address. 1048 o Change Controller: IESG 1049 o Specification Document(s): this document 1051 o JSON Attribute: "target-prefix" 1052 o Description: IP prefix 1053 o Change Controller: IESG 1054 o Specification Document(s): this document 1056 o JSON Attribute: "target-fqdn" 1057 o Description: Fully Qualified Domain Name, is the full name of a 1058 system, rather than just its hostname. For example, "venera" is a 1059 hostname, and "venera.isi.edu" is an FQDN. 1060 o Change Controller: IESG 1061 o Specification Document(s): this document 1063 o JSON Attribute: "target-uri" 1064 o Description: Uniform Resource Identifier (URI). 1065 o Change Controller: IESG 1066 o Specification Document(s): this document 1068 8.2. YANG Module 1070 This document requests IANA to register the following URI in the 1071 "IETF XML Registry" [RFC3688]: 1073 URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1074 Registrant Contact: The IESG. 1075 XML: N/A; the requested URI is an XML namespace. 1077 This document requests IANA to register the following YANG module in 1078 the "YANG Module Names" registry [RFC7950]. 1080 name: ietf-dots-data-channel 1081 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel 1082 prefix: data-channel 1083 reference: RFC XXXX 1085 9. Contributors 1087 The following individuals have contributed to this document: 1089 Dan Wing 1091 Email: dwing-ietf@fuggles.com 1093 10. Security Considerations 1095 Authenticated encryption MUST be used for data confidentiality and 1096 message integrity. TLS based on client certificate MUST be used for 1097 mutual authentication. The interaction between the DOTS agents 1098 requires Transport Layer Security (TLS) with a cipher suite offering 1099 confidentiality protection and the guidance given in [RFC7525] MUST 1100 be followed to avoid attacks on TLS. 1102 An attacker may be able to inject RST packets, bogus application 1103 segments, etc., regardless of whether TLS authentication is used. 1104 Because the application data is TLS protected, this will not result 1105 in the application receiving bogus data, but it will constitute a DoS 1106 on the connection. This attack can be countered by using TCP-AO 1107 [RFC5925]. If TCP-AO is used, then any bogus packets injected by an 1108 attacker will be rejected by the TCP-AO integrity check and therefore 1109 will never reach the TLS layer. 1111 In order to prevent leaking internal information outside a client- 1112 domain, DOTS gateways located in the client-domain SHOULD NOT reveal 1113 the identity of internal DOTS clients (client-identifier) unless 1114 explicitly configured to do so. 1116 Special care should be taken in order to ensure that the activation 1117 of the proposed mechanism won't have an impact on the stability of 1118 the network (including connectivity and services delivered over that 1119 network). 1121 Involved functional elements in the cooperation system must establish 1122 exchange instructions and notification over a secure and 1123 authenticated channel. Adequate filters can be enforced to avoid 1124 that nodes outside a trusted domain can inject request such as 1125 deleting filtering rules. Nevertheless, attacks can be initiated 1126 from within the trusted domain if an entity has been corrupted. 1127 Adequate means to monitor trusted nodes should also be enabled. 1129 RESTCONF security considerations are discussed in [RFC8040]. 1131 All data nodes defined in the YANG module which can be created, 1132 modified, and deleted (i.e., config true, which is the default) are 1133 considered sensitive. Write operations applied to these data nodes 1134 without proper protection can negatively affect network operations. 1135 Appropriate security measures are recommended to prevent illegitimate 1136 users from invoking DOTS data channel primitives. Nevertheless, an 1137 attacker who is able to access to a DOTS client can undertake various 1138 attacks, such as: 1140 o Set an arbitrarily low rate-limit that may lead to discarding 1141 legitimate traffic to be forwarded (rate-limit). 1142 o Set an arbitrarily high rate-limit that may lead to allowing 1143 illegitimate DDoS traffic to be forwarded (rate-limit). 1144 o Communicate invalid aliases to the server (alias) that will lead 1145 to failure to associate both data and signal channels. 1146 o Set invalid ACL entries that may lead to discard legitimate 1147 traffic from being forwarding. Likewise, invalid ACL entries may 1148 lead to forward DDoS traffic. 1150 11. Acknowledgements 1152 Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud 1153 Doron, Russ White, Jon Shallow, and Gilbert Clark for the discussion 1154 and comments. 1156 12. References 1158 12.1. Normative References 1160 [I-D.ietf-dots-architecture] 1161 Mortensen, A., Andreasen, F., Reddy, T., 1162 christopher_gray3@cable.comcast.com, c., Compton, R., and 1163 N. Teague, "Distributed-Denial-of-Service Open Threat 1164 Signaling (DOTS) Architecture", draft-ietf-dots- 1165 architecture-05 (work in progress), October 2017. 1167 [I-D.ietf-dots-signal-channel] 1168 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 1169 Teague, "Distributed Denial-of-Service Open Threat 1170 Signaling (DOTS) Signal Channel", draft-ietf-dots-signal- 1171 channel-09 (work in progress), November 2017. 1173 [I-D.ietf-netmod-acl-model] 1174 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 1175 "Network Access Control List (ACL) YANG Data Model", 1176 draft-ietf-netmod-acl-model-14 (work in progress), October 1177 2017. 1179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1180 Requirement Levels", BCP 14, RFC 2119, 1181 DOI 10.17487/RFC2119, March 1997, 1182 . 1184 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1185 DOI 10.17487/RFC3688, January 2004, 1186 . 1188 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1189 (TLS) Protocol Version 1.2", RFC 5246, 1190 DOI 10.17487/RFC5246, August 2008, 1191 . 1193 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1194 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1195 June 2010, . 1197 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1198 Protocol (HTTP/1.1): Message Syntax and Routing", 1199 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1200 . 1202 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1203 "Recommendations for Secure Use of Transport Layer 1204 Security (TLS) and Datagram Transport Layer Security 1205 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1206 2015, . 1208 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1209 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1210 . 1212 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1213 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1214 . 1216 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1217 Writing an IANA Considerations Section in RFCs", BCP 26, 1218 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1219 . 1221 12.2. Informative References 1223 [I-D.ietf-dots-requirements] 1224 Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed 1225 Denial of Service (DDoS) Open Threat Signaling 1226 Requirements", draft-ietf-dots-requirements-07 (work in 1227 progress), October 2017. 1229 [I-D.ietf-netmod-yang-tree-diagrams] 1230 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1231 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1232 October 2017. 1234 [IEEE.754.1985] 1235 Institute of Electrical and Electronics Engineers, 1236 "Standard for Binary Floating-Point Arithmetic", August 1237 1985. 1239 [proto_numbers] 1240 "IANA, "Protocol Numbers"", 2011, 1241 . 1243 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1244 Resource Identifier (URI): Generic Syntax", STD 66, 1245 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1246 . 1248 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1249 Congestion Control Protocol (DCCP)", RFC 4340, 1250 DOI 10.17487/RFC4340, March 2006, 1251 . 1253 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1254 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1255 . 1257 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1258 the Network Configuration Protocol (NETCONF)", RFC 6020, 1259 DOI 10.17487/RFC6020, October 2010, 1260 . 1262 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1263 and A. Bierman, Ed., "Network Configuration Protocol 1264 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1265 . 1267 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1268 Layer Security (TLS) and Datagram Transport Layer Security 1269 (DTLS) Heartbeat Extension", RFC 6520, 1270 DOI 10.17487/RFC6520, February 2012, 1271 . 1273 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1274 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1275 2014, . 1277 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1278 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1279 . 1281 Authors' Addresses 1283 Tirumaleswar Reddy (editor) 1284 McAfee, Inc. 1285 Embassy Golf Link Business Park 1286 Bangalore, Karnataka 560071 1287 India 1289 Email: kondtir@gmail.com 1291 Mohamed Boucadair (editor) 1292 Orange 1293 Rennes 35000 1294 France 1296 Email: mohamed.boucadair@orange.com 1298 Kaname Nishizuka 1299 NTT Communications 1300 GranPark 16F 3-4-1 Shibaura, Minato-ku 1301 Tokyo 108-8118 1302 Japan 1304 Email: kaname@nttv6.jp 1305 Liang Xia 1306 Huawei 1307 101 Software Avenue, Yuhuatai District 1308 Nanjing, Jiangsu 210012 1309 China 1311 Email: frank.xialiang@huawei.com 1313 Prashanth Patil 1314 Cisco Systems, Inc. 1316 Email: praspati@cisco.com 1318 Andrew Mortensen 1319 Arbor Networks, Inc. 1320 2727 S. State St 1321 Ann Arbor, MI 48104 1322 United States 1324 Email: amortensen@arbor.net 1326 Nik Teague 1327 Verisign, Inc. 1328 United States 1330 Email: nteague@verisign.com