idnits 2.17.1 draft-hares-i2rs-yang-sec-consider-00.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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Mandatory requirement to run I2RS protocol over a TLS sesssion with X.509 mutual authentication whether I2RS protocol uses NETCONF-style messages or RESTCONF-style messages (I2RS protocol MUST not use NETCONF over SSH). -- The document date (January 19, 2017) is 2626 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC5264' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC7920' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC7921' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'RFC7923' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-ephemeral-state' is defined on line 937, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-02 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-00 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** 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 (-09) exists of draft-ietf-netconf-rfc6536bis-00 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational January 19, 2017 5 Expires: July 23, 2017 7 I2RS Revision to Yang Module Security Considerations Section 8 draft-hares-i2rs-yang-sec-consider-00 10 Abstract 12 This document suggests changes to the yang security considerations 13 section for yang module draft supporting the I2RS protocol security 14 requirements. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 23, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Basic Yang Security Considerations versus I2RS Yang Security 52 Considerations . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Mandatory to implement transport layer . . . . . . . . . 4 54 2.1.1. Mandatory to implement NETCONF Transport Layer . . . 6 55 2.1.2. Mandatory to implement RESTCONF Transport Layer . . . 6 56 2.1.3. Mandatory to implement I2RS Transport Layer . . . . . 6 57 2.1.4. Change to Security Considerations for Mandatory 58 Transport Layer . . . . . . . . . . . . . . . . . . . 7 59 2.2. Priority and Opaque Secondary Identity . . . . . . . . . 7 60 2.2.1. TLS User-Id Formats . . . . . . . . . . . . . . . . . 8 61 2.2.2. I2RS use of priority . . . . . . . . . . . . . . . . 8 62 2.3. I2RS Yang Models Exist in I2RS Ephemeral DataStores . . . 9 63 2.3.1. Security Considerations for Datastore Interactions . 11 64 2.4. Different Validations . . . . . . . . . . . . . . . . . . 13 65 2.5. Different NACM Policy . . . . . . . . . . . . . . . . . . 13 66 2.6. Optional Insecure Protocol . . . . . . . . . . . . . . . 14 67 3. I2RS YANG Model Security Explanation . . . . . . . . . . . . 15 68 3.1. Basic YANG Model Security Considerations . . . . . . . . 15 69 3.2. I2RS YANG Model Security Considerations . . . . . . . . . 15 70 4. Revised Security Considerations Template for I2RS Yang 71 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 4.1. Basic YANG Model Security Considerations . . . . . . . . 17 73 4.2. I2RS Yang Models for Secure-Only transports . . . . . . . 17 74 4.3. I2RS Data Sent Across Insecure Transport . . . . . . . . 18 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 8.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 This document proposes language for the the security consideration 86 section for Yang modules from the I2RS Working group which utilize 87 the I2RS protocol enhancements to the NETCONF/RESTCONF. The I2RS 88 protocol enhancement to the NETCONF/RESTCONF protocol must meet the 89 protocol security requirements established in 90 [I-D.ietf-i2rs-protocol-security-requirements], and the environment 91 requirements set in [I-D.ietf-i2rs-security-environment-reqs]. 93 [I-D.ietf-netmod-revised-datastores] desribes a revised network 94 management datastore structure for management configuration data 95 stores used for configuration and operational state. Within this 96 context, the I2RS protocol is a control plane protocol which creates 97 a control-plane datastore separate from the NETCONF/RESTCONF 98 configuration datastores which are write-able (candidate, running, 99 and startup datstores) or expanded uninstalled configuration 100 (intended datastores). The I2RS protocol creates the I2RS ephemeral 101 datastore which is one of the control plane datastores. Any I2RS 102 protocol implementation merges the control plane datastore with the 103 processed intended datastore (removing missing resources or delays) 104 to create the applied datastore. The I2RS ephemeral datastore is 105 defined by the YANG data modeling language augmenting to support the 106 I2RS protocol's control plane ephemeral datastore. 108 The I2RS YANG data models exist in the I2RS ephemeral control plane 109 datastore. Some I2RS Yang Models exist only within the I2RS 110 protocol's ephemeral control plane datastore. Some YANG models which 111 augment configuration datastore and operational state modules. These 112 I2RS YANG data models may augment YANG models for system functions 113 (e.g. interface Yang model), routing information models (RIBS), 114 routing protocol models, or network management protocol. I2RS YANG 115 models MAY import data from the routing system (e.g. OSPF state 116 topology models for L3). 118 The format of this document is: 120 o section 2 - compares I2RS protocol security requirements with 121 requirements describe in yang module security considerations found 122 at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. 124 o section 3 - suggests new Explanatory text for Yang module security 125 considerations for I2RS yang modules, and 127 o section 4 - suggests a new template for Security Considerations 128 section for any I2RS yang module or any module based on an I2RS 129 yang module. 131 2. Basic Yang Security Considerations versus I2RS Yang Security 132 Considerations 134 The I2RS mandatory-to-implement protocol security features are 135 different than the basic NETCONF [RFC6241] mandatory-to-implement 136 features or RESTCONF mandatory-to-implement features 137 [I-D.ietf-netconf-restconf] in the following way: 139 o different mandatory transport features, 141 o I2RS Protocol supports a priority and secondary opaque associated 142 with each Peer Identity, 144 o I2RS Yang Models exist in control plane data stores rather than in 145 the configuration data stores, 147 o Different validation processes, 149 o different NACM policies, 151 o optional non-secure transport can be used for a restricted set of 152 non-confidential data that does not have privacy issues. 154 2.1. Mandatory to implement transport layer 156 NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf] utilize 157 secure transports to establish a session between a server on a 158 network node and a client (often on a end-system). The secure 159 transport layer in these two protocol is a lower layer than the 160 application layer exchange between the server and client. Figure 1 161 provides shows how NETCONF, RESTCONF, and I2RS start their transport 162 connections (1a or 1b), establish secure connections (2a or 2b), and 163 send messges between a client and an NETCONF/RESCONF or I2RS agent. 165 NETCONF server NETCONF client 166 RESTCONF Servers RESTCONF client 167 I2RS Agent I2RS Client 169 <--(1a)--TCP-------- client starts 170 ---(1b)---TCP---> call-home service 172 <--(2a)--TLS X.509v3 --- NETCONF, RESTCONF, 173 I2RS protocol 175 < (2b)--SSH ------ (NETCONF only ) 177 <--(3a)--rpc/rpc-reply--: NETCONF messagese 178 rpc-error (get-config, edit-config, 179 lock, unlock, close-session, 180 kill-session) 182 <--(3b)---http---- RESTCONF (messages) 183 (OPTIONS, HEAD, POST 184 PUT,PATCH, DELETE, 185 Event-streams] 187 <--(3c)--rpc/rpc-reply --I2RS Protocol 188 (NETCONF-like messages) 189 [open-session priority] 190 [open transport transport-id] 191 [get-data I2RS-datastore] 192 [get-state I2RS-datastore] 193 [write-data I2RS-datastore] 194 [notify I2RS-datastore] 195 [action I2RS-datastore] 196 [close-transport transport-id] 197 [close-session] 199 <--(3d)--http -----I2RS Protocol 200 [RESTCONF-like messages] 201 [OPTIONS, HEAD, GET 202 POST [datastore | Data | Operation] 203 PUT [datastore | Data ] 205 Note, in the drawing above, the I2RS agent features MAY utilize the 206 NETCONF server methodology with different protocol commands (get- 207 data, get-state, write-data, notify, action) which can be directed at 208 a particular datastore. 210 Similarily, the RESTCONF methodology can be augmented with different 211 commands to reference the I2RS datastore. 213 This section reviews the manadatory to implement secure transport 214 layer for NETCONF, RESTCONF, and I2RS protocol. For NETCONF, the 215 I2RS agent features utilizes the NETCONF server functions, but allows 216 multiple trasnports between the I2RS Client and I2RS Agent. For 217 RESTCONF, the I2RS agent features utilize the RESTCONF server 218 functions. Based on this review, it suggest I2RS Yang modules must 219 utilize a TLS connection with X.509v3. 221 2.1.1. Mandatory to implement NETCONF Transport Layer 223 NETCONF's [RFC6241] mandatory-to-implement transport (SSH) [RFC6242] 224 augmented by NETCONF's access control module [RFC6536] provides 225 security for Data passed via NETCONF. NETCONF allows user to run 226 NETCONF over TLS using X.509 authentication [RFC7589] which mandates 227 support for of TLS 1.2 [RFC5246] with its mandatory-to-implement 228 Cipher suite ("TLS_RSA_WITH_AES_CBC_SHA"), and suggests implementers 229 abide by recommendations in [RFC7525]. 231 2.1.2. Mandatory to implement RESTCONF Transport Layer 233 RESTCONF [I-D.ietf-netconf-restconf] MUST operate over HTTP over the 234 TLS using TLS [RFC7230] [RFC5246] with the https URI scheme with port 235 443. RESTCONF server MUST present an X.509v3 based certificate when 236 establishing a connection with an RESTCONF Client. The RESTCONF use 237 of X.509v3 certifications is consistent with NTECONF use of X.509 238 ceritifications. 240 2.1.3. Mandatory to implement I2RS Transport Layer 242 The I2RS protocol security requirements 243 [I-D.ietf-i2rs-protocol-security-requirements] require I2RS Yang 244 modules to be accessed peer [identity] authentication, 245 confidentiality, data integrity, and [practical] replay protection 246 for I2RS messages" and support "mechanism that mitigate DoS attacks" 247 and "DDos prevention" SEC-REQ-01 to SEC-REQ-05, SEC-REQ-09 to SEQ- 248 REQ-11). The I2RS client and I2RS Agent MUST use mutual peer 249 authentication based on unique identifier (see SEC-REQ-01, SEC-REQ- 250 02, SEC-REQ-03). 252 The I2RS transport layer transport protocol "MUST be associated with 253 a key management system that guarantees that only the entities having 254 sufficient privileges can get the keys to encrypt/decrypt the 255 sensitive data" (see SEC-REQ-12). The transport protocol the I2RS 256 messages are passed over MUST be able to support multiple transport 257 between the I2RS client and I2RS Agent, but a single connection 258 between I2RS client and I2RS Agent MAY elect to use one transport 259 (SEC-REQ-14). 261 The security association between an I2RS Agent and I2RS client 262 continues even when a secure transport connections (TLS over TCP) 263 exists. Therefore, all I2RS clients receiving a message over a 264 secure connection to an I2RS agent MUST confirm that the I2RS agent 265 has a valid identifier (SEC-REQ-05) and all I2RS agents recieving a 266 messages over a secure connection from an I2RS client MUST confirm 267 that the I2RS client has a valid identity (SEC-REQ-04). 269 According to [I-D.ietf-taps-transports], the secure transport 270 protocols which support peer authentication, confidentiality, data 271 integrity, and replay protection are the following: 273 1. TLS [RFC5246] over TCP or SCTP, 275 2. DTLS over UDP with replay detection and anti-DoS stateless cookie 276 mechanism required for the I2RS protocol, and the I2RS protocol 277 allow DTLS options of record size negotiation and and conveyance 278 of "don't" fragment bits to be optional in deployments. 280 3. HTTP over TLS (over TCP or SCTP), and 282 4. HTTP over DTLS (with the requirements and optional features 283 specified above in item 2). 285 2.1.4. Change to Security Considerations for Mandatory Transport Layer 287 Based on these additional requirements, the mandatory-to-implement 288 NETCONF transport for I2RS Yang modules is NETCONF over TLS with 289 Mutual X.509 authentication [RFC7589] augmented by NETCONF's access 290 control module. The mandatory-to-implement RESTCONF transport for 291 I2RS YANG Modules is HTTP over TLS with mutual X.509 authentication. 293 This requirement should replace the existing requirement for the 294 NETCONF transport of SSH [RFC6242] in the Yang modules. 296 2.2. Priority and Opaque Secondary Identity 298 The I2RS protocol security requirements require that a priority and a 299 secondary opaque identifier be associated with the primary I2RS 300 identifier (client or agent) (see SEC-REQ-07 and SEC-REQ-08). In 301 NETCONF the X.509v3 identity which is used for mutual authentication, 302 becomes a NETCONF user name. NETCONF links a NTECONF user name to a 303 NETCONF group. Network access control policy 304 [I-D.ietf-netconf-rfc6536bis] is associated with this user name for 305 the configuration datastore. In RESTCONF, the X.509v3 identity used 306 for mutual authentication, becomes a RESTCONF user name. Similar to 307 NETCONF the RESTCONF user name links to a RESTCONF user name. 308 RESTCONF network access policy MAY link the RESTCONF user name to 309 group identifier to apply NACM policy. 311 I2RS protocol links the X.509v3 identity which is used for X.509v3 312 mutual identification to a I2RS user identity (user-id) on the I2RS 313 agent. Associated with the I2RS user-id is one priority per security 314 session, one secondary identifier per protocol transaction (NETCONF 315 or RESTCONF), and multiple transport sessions. The I2RS user-id 316 links to a policy-id that can be utilized to set NAMCs on transports 317 sessions or secondary identifiers, or other constraints. 319 This section describes the format of these user identifiers in 320 X.509v3 use, and how I2RS uses the priority associated with the I2RS 321 user-id. 323 2.2.1. TLS User-Id Formats 325 NETCONF over TLS with Mutual X.509 authentication [RFC7589] requires 326 that the NETCONF server keep a order list of mapping of certificates 327 to that the X.509v3 certification is mapped to a NETCONF user name. 328 The mapping requires keeping ordered list of these mappings with each 329 list entry containing the following: 331 o certificate fingerprint, 333 o map type (specified, san-rfc822-name, san-dns-name, san-ip- 334 adderss, san-any, common-nam), and 336 o optional auxillary data. 338 The map type "specified" indicates the NETCONF username is specified 339 in the auxilary data. The map types begining with "san-..." indicate 340 the user name is found in the subjectAltName and take a particular 341 form (rfc822-name, dns-name, ip-address) or anyone of these forms 342 (san-any). The common-nam map type indicates CommonName is mapped to 343 the user name after being converted to UTF-8. 345 In a similar fashion, the I2RS will utilize user name found in the 346 formats as an I2RS identity. 348 2.2.2. I2RS use of priority 350 The I2RS data models define some data models which MUST exist within 351 the I2RS protocol's ephemeral datastore (e.g. I2RS Ephemeral Data 352 Store, I2RS Protocol), and some which MAY exist (e.g. protocol 353 independents models or modules which augment routing protocol 354 modules). The YANG Modules which define state in the I2RS Control 355 plane data store may have both configuration state and operational 356 state. The I2RS Data Models installed in an I2RS ephemeral state 357 data MUST be able to be read by multiple I2RS Clients (if security 358 network access policies allow it) and written by one I2RS Client at a 359 time. If multiple I2RS client attempt to write the same I2RS data, 360 it is considered an operational error situation (which causes I2RS 361 agent to notify both client's about if security policies allow). To 362 resolve these contentions, a priority scheme is used. The link 363 between the I2RS client identity and the priority must be established 364 before the I2RS Client makes write changes to the I2RS Agent. The 365 client identity's link to a priority controls multiple write access 366 rather than mutual identification. 368 How does the I2RS security requirement for a single to user to have 369 only one priority (SEC-REQ-07) and one secondary opaque identifier 370 (SEC-REQ-08) impact the security of I2RS Yang Data Models? 372 The client priority allows the I2RS agent to select which I2RS client 373 has priority when multiple I2RS clients try to write the same data 374 node in an I2RS ephemeral control plane datastore. This priority 375 resolution of multiple writes occurs after both I2RS clients are 376 allowed to have network access (policy set by NACM 377 [I-D.ietf-netconf-rfc6536bis]) to a data model. Therefore, the 378 security considerations of the I2RS YANG Data models do not have to 379 consider priority contention. The secondary opaque associated for 380 the period of a I2RS protocol operation only provides tracing 381 capability to determine what happened. 383 2.3. I2RS Yang Models Exist in I2RS Ephemeral DataStores 385 The I2RS protocol is a higher layer protocol encourages which reuses 386 other IETF protocols (NETCONF/RESTCONF) and modeling language (YANG), 387 but modifies these protocols (NETCONF/RESTCONF) and the modeling 388 language to support the required features. Figure 2 provides a 389 diagram of how I2RS ephemeral configuration state ("config=true" 390 nodes), and I2RS operational state nodes ("config=false" nodes) which 391 are part of the I2RS Control Plane Ephemeral datastore interact with 392 datastores in the updated IETF management datastore model 393 [I-D.ietf-netmod-revised-datastores], and not a part of the 394 configuration datastore. The I2RS protocol implementation merges the 395 I2RS ephemeral datastore with currently appplied datastore. 397 +-------------+ +-----------+ 398 | [candidate] | | [startup] | 399 | (ct, rw) |%lt;---+ +---%gt;| (ct, rw) | 400 +-------------+ | | +-----------+ 401 | | | | 402 | +-----------+ | 403 +--------%gt;| [runnin] |<--------+ 404 | (ct, rw) | 405 +-----------+ 406 | 407 | // e.g., removal of 'inactive' 408 | // nodes, expansion of templates 409 v 410 +------------+ 411 | [intended] | // subject to validation 412 | (ct, ro) | 413 +------------+ 414 | 415 | // e.g., missing resources or 416 | // delays 417 v 418 +-----------+ 419 | [applied] |<---+--- dynamic configuration 420 | (ct, ro) | | protocols 421 +-----------+ +--- control-plane datastores 422 | +---I2RS ephemeral datastore 423 | +---BGP ephemeral configuration 424 | (Flow Specification filters) 425 | 426 | +--- auto-discovery 427 | +-----+--- control-plane protocols 428 | | +--- control-plane datastores 429 | | +---I2RS operational state 430 | | +---BGP operational state 431 | | (Flowspec filters) 432 | | 433 v v 434 +---------------------+ 435 | [operational-state] | 436 | (ct + cf, ro) | 437 +---------------------+ 439 ct = config true; cf = config false 440 rw = read-write; ro = read-only 441 boxes denote datastores 443 Figure 2 - modified from NETMOD Revised datastores 444 (draft-ietf-netmod-revised-datastores-00.txt) 446 The I2RS ephemeral datastore is a control plane datastore which 447 contains configuration data ("config=true") which does not persist 448 over a reboot. The I2RS datastore may only be one of the ephemeral 449 configuration datastores. The I2RS protocol creates, reads, writes, 450 updates, deletes, notifies, signals events, performs actions,and 451 traces (CRUD-NEAT) the data in the I2RS ephemeral datastore. The 452 I2RS protocol mechanisms validate the I2RS ephemeral datastore 453 values. If a routing system reboots, the information in an I2RS 454 ephemeral datastore does not persist across the reboot. 456 2.3.1. Security Considerations for Datastore Interactions 458 An I2RS protocol implementation applies this configuration to a 459 routing system which will also have basic IP routing functions (e.g. 460 interfaces, IP address, routing), system management functions (e.g. 461 syslog), and security functions (e.g. keystore, keychain, Network 462 Access Control Management (NACM)). The I2RS implementation is 463 required to have configuration knobs that will specify how the 464 intended configuration is validated, checked, and merged with the 465 I2RS ephemeral configuration state. If a system with I2RS protocol 466 implementation also has dynamic configuration protocols (e.g. dhcp) 467 or other control plane configuraton protocols (e.g. BGP Flow 468 Specification filters passed in the BGP protocol, but defined to be 469 installed as ephemeral state in the routing system), then the 470 implementation must have configuration knobs and policy to merge the 471 configuration (that is "config=true") data modules in a known manner. 472 The applied configuration state stored by system must be able to 473 identify which datastore (intended, dynamic configuration protocol 474 datastore, I2RS ephemeral control-plane datastore) installed each 475 piece of configuration in the running system. 477 Similar to NETCONF or RESTCONF configuration data stores (candidate, 478 running, start-up, intended, and applied), some writable data nodes 479 in a Yang Data Model that could be especially disruptive if abused. 480 These data nodes MUST Be explicitly listed by name and the associated 481 security risks MUST be spelled out. In addition, some writable data 482 nodes in an I2RS ephemeral configuration could cause problems with 483 nodes if: data models have write or read/write scoped data which can 484 cause security threats by: 486 o I2RS ephemeral data read by the user could cause a security 487 threats 489 o overwriting NETCONF/RESTCONF configuration with I2RS ephemeral 490 control plane configurations could cause network security risks or 491 Denial of Service (DoS), 493 o fluctuating between I2RS ephemeral configuration datastore data 494 and other control plane datastores could cause security risks or 495 denial of service (DoS), 497 o I2RS ephemeral configuration overwriting dynamic configuration 498 protocol configuration (e.g. dhcp leases) could cause security 499 risks or denial of service attacks (DoS), or fluctuation between 500 I2RS ephemeral control plane confguration and dynamic 501 configuration control plane could cause problems. 503 I2RS data models containing I2RS ephemeral configuration which might 504 cause these problems should provide this information in the security 505 considerations section. 507 Operational state contains all configured data used by the system 508 ("config=true" nodes) and applied configuration and operational state 509 as read-only data. Operational state data does not persist across a 510 reboot of the routing system, but is regenerated. This requirement 511 to regenerate data requires the I2RS protocol to reload any 512 operational state it regenerates. 514 The I2RS protocol implementations MUST support I2RS Yang models which 515 define operational state. System-wide operational state may come 516 from auto-discovery, control plane protocols (e.g. BFD, BGP), or 517 control plane datastores such as the I2RS Ephemeral Control Plane 518 Datastore. The I2RS protocol implementation must extend the read of 519 operational state so that the operational data may get all 520 operational data, or data specific to the I2RS operational data. 522 I2RS ephemeral data store, similar to NETCONF/RESTCONF operational 523 state, may have read-only data in the each ephemeral configuration 524 datastore or the ephemeral operational datastores that contains 525 especially sensitive information or that raise significant privacy 526 concerns. It is important that the security section MUST be 527 explicitly listed this data by name and the reasons for the 528 sensitivity/privacy concerns MUST be explained. 530 I2RS ephemeral datastores may overwrite with ephemeral data sensitive 531 information stored in NETCONF/RESTCONF configuration datastores or 532 operational datastores. This overwriting may decrease the concerns 533 for sensitivity/privacy of the information or increase it. The 534 ovewriting and the policy that controls it must be explained in the 535 I2RS Yang Data Model. 537 2.4. Different Validations 539 The I2RS protocol is to designed to operate on top of the operates on 540 top of the TLS connection using modified network management protocols 541 (NETCONF, RESTCONF, and others ) to: 543 o create, read, update, delete ephemeral configuration data within 544 the I2RS ephemeral data store (CRUD) 546 o to notify the I2RS client when an event occurs in the I2RS Agent, 547 or the I2RS agent when an event occurs as part of a subscription 548 servic, 550 o signal the occurrence of individual events (I2RS agent to I2RS 551 client or I2RS client to I2RS agent), 553 o act if a action is request (e.g. rpc), 555 o trace information 557 (These can be summarizes as CRUD-NEAT operations). 559 The validation for these processes is specific to the I2RS protocol 560 so the validations will be different, but defined in the I2RS 561 protocol. Therefore, the security considerations will need to 562 consider any differences in I2RS protocol features. 564 2.5. Different NACM Policy 566 The expanded NETCONF NACM [I-D.ietf-netconf-rfc6536bis] proposes 567 changes to the NACM procedure so that it focuses on: 569 o Permission to invoke specific protocol operations, 571 o Permission to read and/or alter specific data nodes within any 572 datastore, 574 o Permission to receive specific notification event types. 576 The NETCONF NACM is based on a netconf group's permissions where each 577 netconf user identifier is linked to 1 or more group permissions. 578 NETCONF which runs over TLS with X.509v3 services [RFC7589] passes a 579 name which becomes the netconf user name. As described above the 580 I2RS protocol also a user name which becomes the I2RS usser 581 identifier (user-id) The I2RS user-id may be mapped to different NACM 582 policy based on a I@RS protocol implementation and the I2RS protocol 583 features. 585 An I2RS protocol implementation also interacts with the following 586 systems to import/export data: to the following: 588 routing system (defined as Routing Access Control Management 589 (RACM)), 591 host system functions (defined as System Access control Management 592 (SACM), 594 NACM policy for I2RS protocol will need to be augment by this RACM 595 and SACM policy. A security consideration section should discuss 596 these issues. 598 2.6. Optional Insecure Protocol 600 The I2RS protocol allow an implementation of I2RS protocol (NETCONF 601 or RESTCONF) to optionally support of an insecure transport as well 602 as a secure transport if a set of mandatory constraints are met. of 603 the following constraints are met: 605 o the content that is suitable for insecure transport (see SEC-REQ- 606 06), 608 o Yang models with non-confidential data must provide an indication 609 that non-confidential data exists within the model in a machine 610 readable form. A non-secure transport may be used to publish only 611 read scope data or notification scope data if the associated data 612 model indicates the data is non-confidential (see SEC-REQ-13), 614 o The I2RS protocol makes use of both secure and insecure 615 transports, but this use MUST NOT be done in any way that weakens 616 the secure transport protocol used in the I2RS protocol or other 617 contexts that do not have this requirement for mixing secure and 618 insecure modes of operation (SEC-REQ-16) 620 o The I2RS higher-layer protocol MUST provide a mechanism for 621 message traceability (requirements in [RFC7922]) that supports the 622 tracking higher-layer functions run across secure connection or a 623 non-secure transport (SEC-REQ-19). 625 Any I2RS Data model proposing to transmit a portion of the data over 626 an insecure transport MUST provide a section of security 627 considerations that explains how these constraints are net. 629 3. I2RS YANG Model Security Explanation 631 Any security consideration section for an I2RS YANG data model must 632 contain the following sections: 634 o Basic Yang Module Data considerations - relating to sensitive 635 writeable nodes, sensitive read-able nodes, sensitive rpc 636 operations), 638 o I2RS related Yang Model considerations - relating to mandatory 639 transport, I2RS use of priority and opaque secondary identity, 640 validation of I2RS protocol operations, NACM interactions in a 641 multiple datastore (config + I2RS control plane datastore), and 642 use of optional insecure data. 644 This section provide an overview of what goes in each of these two 645 sections. Section 4 provides abbrev template for this information. 647 3.1. Basic YANG Model Security Considerations 649 Each specification that defines one or more YANG modules MUST contain 650 a section that discusses security considerations relevant to those 651 modules. The following data usage must be explained in the security 652 consideratinon section: 654 1. If any writable data nodes that could be especially disruptive if 655 abused, then these nodes MUST be explicitly listed by name and 656 the associated security risks MUST be spelled out. 658 2. If any readable data nodes that contain especially sensitive 659 information or that raise significant privacy concerns, then 660 these data nodes MUST be explicitly listed by name and the 661 reasons for the sensitivity/privacy concerns MUST be explained. 663 3. If any new RPC operations have been defined, then the security 664 considerations of each new RPC operation MUST be explained. 666 3.2. I2RS YANG Model Security Considerations 668 The I2RS YANG Models is design to exists in the I2RS control plane 669 ephemeral state. Therefore, a security consideration section for an 670 I2RS YANG Data Model must contain the following information: 672 Mandatory requirement to run I2RS protocol over a TLS sesssion 673 with X.509 mutual authentication whether I2RS protocol uses 674 NETCONF-style messages or RESTCONF-style messages (I2RS protocol 675 MUST not use NETCONF over SSH). 677 Description of how multiple client write-contentions are resolved 678 via I2RS priority linked to the I2RS user-id and how I2RS 679 secondary identity may trace this. It is important to provide 680 operational insight how how I2RS secondary identity may change and 681 how this will impact tracing. 683 Validation of I2RS protocol operations may be new. Any concerns 684 with time delays or depth of validation, should be indicated. 686 NACM policy for network access to an I2RS Ephemeral control plane 687 datastore may be augmented by an access control method for routing 688 protocols (RACM), system information (SACM), and an inter- 689 datastore access (DACM). A discussion how sensitive read 690 information, write information, or I2RS actions are protected in 691 the system. 693 If a portion of the data model is available via a non-secure 694 transport session, describe how the following restrictions are met 696 * content of data is suitable for insecure transport, 698 * YANG modules provide indication of non-confidential data in 699 machine readable form, 701 * the YANG module's use of secure and insecure transport does not 702 weaken the secure transport, 704 * the higher layer protocol MUST provide a mechnisms for message 705 traceability. 707 4. Revised Security Considerations Template for I2RS Yang Modules 709 The YANG module defined in this draft is designed to be accessed via 710 the I2RS control plane protocol and reside in the I2RS ephemeral 711 control plane datastore that contains both configuration data and 712 operational state. I2RS ephemeral control plane datastore does not 713 persist (that is does not keep data) across a system reboot. 715 This consideration section for I2RS Yang Data Models contains three 716 parts: basic YANG model considerations, I2RS ephemeral datstore 717 considerations, and considerations for I2RS Yang Models with non- 718 confidential data sent over an insecure session. The basic model 719 security considerations are common to all YANG modules whether the 720 YANG modules belong to the configuration datastore, or control-plane 721 datastores. 723 Any I2RS Yang module is required to run the I2RS protocol over a TLS 724 session with X.509v3 mutual authentication whether the I2RS protocol 725 uses NETCONF-style messages or RESTCONF-style messages. The I2RS 726 protocol implementation uses the name passed as the I2RS user 727 identifier (user-id). Write contention between two clients (with 728 valid write permissions) attempting to write the same data node in a 729 I2RS Yang data model is an operational error, but implementations 730 should use the priority associated with each I2RS user-id to resolve 731 it. Tracing of such content resolution will be done by the system, 732 and will include the opaque secondary identifier which indicates 733 which applications are operationally contending. Only one opaque 734 secondary identifier is linked to a I2RS userid at a time, but the 735 opaque secondary identifier may change multiple times during a 736 security association. The opaque secondary identifier may be passed 737 during transport connection establishment as part of a write-action 738 (write datastore where the datastore is I2RS). All of these features 739 are basic I2RS functionality, and not specific to any I2RS data 740 model. 742 4.1. Basic YANG Model Security Considerations 744 What to put in this section: (Instructions to authors) 746 Each specification that defines one or more YANG modules MUST contain 747 a section that discusses security considerations relevant to those 748 modules. The following data usage must be explained in the security 749 consideration. 751 1. If there is readable data nodes contain especially sensitive 752 information or that raise significant privacy concerns, these 753 nodes MUST be explicitly listed by name and the reasons for the 754 sensitivity/privacy concerns MUST be explained. One is example 755 is if the data might reveal customer information or violate 756 personal privacy laws (such as those of the European Union) if 757 the data was sent via an unauthorized port. 759 2. If any writable data nodes that could be especially disruptive if 760 abused, these writeable data nodes MUST be explicitly listed by 761 name and the associated security risks MUST be spelled out. 763 3. If thre are any new RPC operations have been defined, then the 764 security considerations of each new RPC operation MUST be 765 explained. 767 4.2. I2RS Yang Models for Secure-Only transports 769 The I2RS YANG models may utilize new rpc commands for to access the 770 I2RS ephemeral datastore which create, read, update, and delete data 771 nodes; or notify a client of informatio, signal events, perform 772 actions, and perform tracing (CRUD-NEAT) notifies, signals events. 774 Authors should provide a list of any new rpc commands and any 775 security considerations regarding their use. 777 NACM policy for network access to an I2RS Ephemeral control plane 778 datastore may be augmented by an access control method for routing 779 protocols (RACM), system information (SACM), and an inter-datastore 780 access (DACM). 782 Authors should provide a discussion of any data which is retrieved 783 from the routing protocols in the control plane system, system 784 information, or from anyother datastore (configuration, operational 785 state, dynamic configuration protocols, auto-discovery, control-plane 786 protocols). Authors should discuss how fluctuation of the data 787 retrieved from the routing protocols in control plane system, host 788 system, or other datastores could impact data reliability or 789 sensitive data nodes listed in the Basic Yang Module Security 790 considerations. This discussion SHOULD include suggested operational 791 knobs that control the overlay of I2RS configuration data over 792 configuration data or I2RS operation state over other types of 793 operational state. 795 4.3. I2RS Data Sent Across Insecure Transport 797 I2RS YANG Modules may contain data which MAY be passed across a non- 798 secure transport session as well as a secure transport. Any I2RS 799 YANG model sending allowing some data to be sent cross an non-secure 800 transport MUST provide adhere to the following requirements: 802 o content of data model (e.g. nodes or subtrees) which is suitable 803 for insecure transport, 805 o YANG modules provide indication of non-confidential data in 806 machine readable form, 808 o how the YANG module's use of secure and insecure transport does 809 not weaken the secure transport, 811 o How I2RS protocol provide a mechnisms for message traceability. 813 Authors provide the following: 815 o a list of nodes in this YANG data model which MAY be passed across 816 an insecure transport, 818 o How the YANG Module provides the indication of non-condidential 819 data existing in the data model, 821 o How access to the data is limited to reads of data nodes, or 822 notifications sent. 824 o How the use of secure and insecure transport does not weaken the 825 secure transport operationally in a deployment, and 827 o How traceability supports detecting any security intrusions for 828 this data model. 830 5. Security Considerations 832 The document provides an updated YANG security considerations for 833 I2RS data models. 835 6. IANA Considerations 837 No IANA considerations for this requirements. 839 7. Acknowledgments 841 Authors of the protocol security document, protocol security 842 environment document, ADs (routing, security, OPS) 844 8. References 846 8.1. Normative References 848 [I-D.ietf-i2rs-protocol-security-requirements] 849 Hares, S., Migault, D., and J. Halpern, "I2RS Security 850 Related Requirements", draft-ietf-i2rs-protocol-security- 851 requirements-17 (work in progress), September 2016. 853 [I-D.ietf-i2rs-security-environment-reqs] 854 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 855 Security Requirements", draft-ietf-i2rs-security- 856 environment-reqs-02 (work in progress), November 2016. 858 [I-D.ietf-netconf-restconf] 859 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 860 Protocol", draft-ietf-netconf-restconf-18 (work in 861 progress), October 2016. 863 [I-D.ietf-netmod-revised-datastores] 864 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 865 and R. Wilton, "A Revised Conceptual Model for YANG 866 Datastores", draft-ietf-netmod-revised-datastores-00 (work 867 in progress), December 2016. 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, 871 DOI 10.17487/RFC2119, March 1997, 872 . 874 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 875 (TLS) Protocol Version 1.2", RFC 5246, 876 DOI 10.17487/RFC5246, August 2008, 877 . 879 [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 880 Partial Presence Information", RFC 5264, 881 DOI 10.17487/RFC5264, September 2008, 882 . 884 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 885 and A. Bierman, Ed., "Network Configuration Protocol 886 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 887 . 889 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 890 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 891 . 893 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 894 Protocol (NETCONF) Access Control Model", RFC 6536, 895 DOI 10.17487/RFC6536, March 2012, 896 . 898 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 899 Protocol (HTTP/1.1): Message Syntax and Routing", 900 RFC 7230, DOI 10.17487/RFC7230, June 2014, 901 . 903 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 904 "Recommendations for Secure Use of Transport Layer 905 Security (TLS) and Datagram Transport Layer Security 906 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 907 2015, . 909 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 910 NETCONF Protocol over Transport Layer Security (TLS) with 911 Mutual X.509 Authentication", RFC 7589, 912 DOI 10.17487/RFC7589, June 2015, 913 . 915 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 916 Statement for the Interface to the Routing System", 917 RFC 7920, DOI 10.17487/RFC7920, June 2016, 918 . 920 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 921 Nadeau, "An Architecture for the Interface to the Routing 922 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 923 . 925 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 926 the Routing System (I2RS) Traceability: Framework and 927 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 928 2016, . 930 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 931 for Subscription to YANG Datastores", RFC 7923, 932 DOI 10.17487/RFC7923, June 2016, 933 . 935 8.2. Informative References 937 [I-D.ietf-i2rs-ephemeral-state] 938 Haas, J. and S. Hares, "I2RS Ephemeral State 939 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 940 progress), November 2016. 942 [I-D.ietf-netconf-rfc6536bis] 943 Bierman, A. and M. Bjorklund, "Network Configuration 944 Protocol (NETCONF) Access Control Model", draft-ietf- 945 netconf-rfc6536bis-00 (work in progress), January 2017. 947 [I-D.ietf-taps-transports] 948 Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 949 provided by IETF transport protocols and congestion 950 control mechanisms", draft-ietf-taps-transports-14 (work 951 in progress), December 2016. 953 Author's Address 955 Susan Hares 956 Huawei 957 7453 Hickory Hill 958 Saline, MI 48176 959 USA 961 Email: shares@ndzh.com