idnits 2.17.1 draft-lin-sacm-nid-mp-security-baseline-02.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 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 == Line 259 has weird spacing: '...in-type uint8...' == Line 318 has weird spacing: '...-enable boole...' == Line 542 has weird spacing: '...-change boo...' == Line 547 has weird spacing: '...n-event boo...' == Line 558 has weird spacing: '...eration boo...' == (6 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 1, 2018) is 2241 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 (-01) exists of draft-dong-sacm-nid-infra-security-baseline-00 == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-05 == Outdated reference: A later version (-40) exists of draft-ietf-netconf-ssh-client-server-05 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-05 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-16 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-23 == Outdated reference: A later version (-03) exists of draft-xia-sacm-nid-dp-security-baseline-01 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring (SACM) Q. Lin 3 Internet-Draft L. Xia 4 Intended status: Standards Track Huawei 5 Expires: September 2, 2018 March 1, 2018 7 The Data Model of Network Infrastructure Device Management Plane 8 Security Baseline 9 draft-lin-sacm-nid-mp-security-baseline-02 11 Abstract 13 This document provides security baseline for network infrastructure 14 device management plane, which is represented by YANG data model. 15 The corresponding values of this YANG data model can be transported 16 between Security Automation and Continuous Monitoring (SACM) 17 components and used for network infrastructure device security 18 evaluation. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 2, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Administrator Account Management Security . . . . . . . . 5 60 5.1.1. Administrator Account Configuration Security . . . . 6 61 5.1.2. Administrator Login Security . . . . . . . . . . . . 6 62 5.1.3. AAA Configuration Security . . . . . . . . . . . . . 9 63 5.1.4. Administrator Access Statistics . . . . . . . . . . . 10 64 5.2. System Management Security . . . . . . . . . . . . . . . 11 65 5.2.1. SNMP Management Security . . . . . . . . . . . . . . 11 66 5.2.2. NETCONF Management Security . . . . . . . . . . . . . 12 67 5.2.3. Port Management Security . . . . . . . . . . . . . . 12 68 5.3. Log Security . . . . . . . . . . . . . . . . . . . . . . 13 69 5.4. File Security . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Network Infrastructure Device Security Baseline Yang Module . 17 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 76 10.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 Besides user devices and servers, network infrastructure devices such 83 as routers, switches, and firewalls are crucial to enterprise network 84 security. Security baseline provides a minimal set of security 85 requirements that are essential to protect enterprise network. The 86 security baseline and organization specific requirements can then be 87 used to assess the security posture of network infrastructure 88 devices. 90 In order to address threats and attacks to network infrastructure 91 devices, different security functions and configurations are 92 implemented in application layer, network layer and infrastructure 93 layer. Network layer is typically categorized into three planes of 94 operation: management plane, control plane and data plane. All the 95 planes should be protected and monitored to provide network security. 97 This document focuses on security baseline for network infrastructure 98 device management plane. Management plane provides configuration and 99 monitoring services to network administrator or device owner. 100 Unauthorized access, insecure access channels, weak cryptographic 101 algorithms are common security issues that break management plane 102 security. Security configuration and monitoring should be 103 implemented to ensure proper control of network infrastructure 104 devices. A number of security best practices have been proposed, 105 such as disabling unused services and ports, discarding insecure 106 access channels, and enforcing strong user authentication and 107 authorization. In this document, we propose a minimal set of 108 configuration and status requirements that are expected to be widely 109 applicable to common network infrastructure devices. Additional 110 requirements can be supported by specific vendors. Thus 111 interoperability and extensibility can be achieved. 113 Interface to Network Security Functions (I2NSF) working group 114 provides standard interfaces for controlling and monitoring NSFs, the 115 work of this document is different from that of I2NSF working group. 116 The main differences include: 118 o I2NSF focuses on flow-based NSFs, while this document works on 119 network infrastructure devices (physical or virtual) including 120 routing and forwarding devices as well as network security 121 devices. 123 o I2NSF focuses on the provision and monitor of I2NSF policy rules 124 for flow-based NSFs, while this document doesn't work on the 125 functional configuration of NSFs policy rules. This document 126 focuses on security configuration of account management, system 127 management protocols, system ports, log, and local file system to 128 provide operation security. For example, configuration of 129 firewall rules is out of scope, but the configuration of ACL rules 130 for remote access administrator is considered in this document. 132 YANG data model is used in this document to model the security 133 baseline for network infrastructure device management plane. 134 [I-D.birkholz-sacm-yang-content] defines a method of constructing the 135 YANG data model scheme for the security posture assessment of the 136 network infrastructure device by brokering of YANG push telemetry via 137 SACM statements. In this document, we follow the same way to define 138 the YANG output for network infrastructure device security posture 139 based on the [I-D.ietf-sacm-information-model]. 141 Besides management plane security baseline, the security baselines 142 for control plane, data plane, and infrastructure layer of network 143 infrastructure devices are described in 144 [I-D.dong-sacm-nid-cp-security-baseline], 146 [I-D.xia-sacm-nid-dp-security-baseline] and 147 [I-D.dong-sacm-nid-infra-security-baseline] respectively. 149 2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Terminology 157 This document uses the terms defined in [RFC6020]. 159 4. Tree Diagrams 161 Tree diagram defined in [I-D.ietf-netmod-yang-tree-diagrams] is used 162 to represent the YANG data model of network infrastructure device 163 management plane security. The meaning of the symbols used in the 164 tree diagram and the syntax are as follows: 166 o A module is identified by "module:" followed the module-name. The 167 top-level data nodes defined in the module, offset by 2 spaces. 168 Submodules are represented in the same fashion as modules, but are 169 identified by "submodule:" followed the (sub)module-name. 171 o Groupings, offset by 2 spaces, and identified by the keyword 172 "grouping" followed by the name of the grouping and a colon (":") 173 character. 175 o Each node in the tree is prefaces with "+--". Schema nodes that 176 are children of another node are offset from the parent by 3 177 spaces. 179 o Brackets "[" and "]" enclose list keys. 181 o Abbreviations before data node names: "rw" means configuration 182 (read-write) and "ro" means state data (read-only), "x" is used to 183 mark rpcs and actions, "w" denotes the input parameters to rpcs 184 and actions, and "u" indicates the use of a predefined grouping. 186 o Symbols after data node names: "?" means an optional node, "!" 187 means a presence container, and "*" denotes a "list" and "leaf- 188 list". 190 o Parentheses enclose choice and case nodes, and case nodes are also 191 marked with a colon (":"). 193 o Ellipsis ("...") stands for contents of subtrees that are not 194 shown. 196 o Curly brackets and a question mark "{...}?" are combined to 197 represent the features that node depends on. 199 5. Data Model Structure 201 This document focuses on network infrastructure device management 202 plane security, including security of account management, system 203 management protocols, sytem ports, log, and local file system. Both 204 security configuration and runtime state of security controls are 205 taken into consideration. Four submodules will be illustrated in the 206 following sections to represent the security baseline for: 208 o Administrator account management security 210 o System management protocol security and port management security 212 o Log security 214 o Local file system security 216 There exists a multitude of YANG models for network devices and 217 network protocols. For management plane security, several RFCs and 218 drafts has defined some related parts. But an overall data model of 219 management plane security is still missing. Moreover, the related 220 data models may only focus on part of the security functions. 221 Besides defining new YANG models or groupings, the following sections 222 will also reuse the existing YANG models and provide additional 223 attributes or groupings for the missing parts. Appendix A provides a 224 summary of existing YANG models and the relationship to the security 225 baseline defined in this document. 227 5.1. Administrator Account Management Security 229 The "admin-account-management-security" submodule is divided into 230 four parts: 232 submodule: admin-account-management-security 233 +--rw admin-account-management-security 234 +--rw admin-account-config-security 235 +--rw admin-login-security 236 +--rw aaa-config-security 237 +--rw admin-access-statistics 239 5.1.1. Administrator Account Configuration Security 241 In order to provide basic protection of administrator accounts, 242 configuration requirements on account names and passwords should be 243 applied. The commonly applied security controls includes: the 244 account name should not be too short, the password should contain 245 multiple types of characters, password should be resetted after a 246 period of time, the new password should be different with the past 247 one, etc. The following data model illustrates these kinds of 248 security controls. 250 +--rw admin-account-config-security 251 +--rw account-name-requirement! 252 | +--rw account-name-min-length uint8 253 +--rw account-password-requirement! 254 | +--rw password-min-length uint8 255 | +--rw password-expire-days uint16 256 | +--rw password-complexity-check? 257 | +--rw password-character? 258 | | +--rw password-character-type enumeration 259 | | +--rw password-character-min-type uint8 260 | +--rw check-past-password? 261 | | +--rw past-times uint8 262 | +--rw check-account-name? boolean 263 +--rw account-password-encryption identityref 265 5.1.2. Administrator Login Security 267 Network infrastructure devices typically can be managed through 268 command line interface (CLI) or web user interface. The web user 269 interface provides basic maintenance and management functions. 270 Sometimes an administrator still needs to use the CLI to implement 271 complex or fine-grained management. If insecure access channels have 272 to be used, several security controls should be enforced. 274 +--rw admin-login-security 275 +--rw (user-interface-type) 276 +--:(console) 277 | +--rw console-authen-mode identityref 278 | +--rw console-user-level uint8 279 +--:(vty) 280 | +--rw vty* [vty-number] 281 | +--rw vty-number uint8 282 | +--rw vty-user-authen-mode identityref 283 | +--rw vty-user-level uint8 284 | +--rw (service-type) 285 | +--:(telnet) 286 | | +--rw telnet-enable boolean 287 | | +--rw telnet-server-source? uint16 288 | | +--rw telnet-server-port inet:port-number 289 | | +--rw telnet-timeout? uint16 290 | | +--u common-security-policy 291 | +--:(ssh) 292 | +--rw ssh-enable boolean 293 | +--u ssh-server-grouping 294 | [I-D.ietf-netconf-ssh-client-server] 295 | +--u ssh-server-security-hardening 296 | +--u common-security-policy 297 +--:(web) 298 +--rw web-authen-mode identityref 299 +--rw web-user-level uint8 300 +--rw http-server-source uint16 301 +--rw https-ipv4-enable boolean 302 +--rw https-ipv6-enable boolean 303 +--rw https-source-port inet:port-number 304 +--rw https-timeout uint16 305 +--u common-security-policy 306 +--u tls-server-grouping 307 [I-D.ietf-netconf-tls-client-server] 309 The structure of "ssh-server-security-hardening" is: 311 grouping ssh-server-security-hardening: 312 +--rw ssh-authen-mode* identityref 313 +--rw ssh-dh-exchange-min-len? uint16 314 +--rw ssh-server-port? inet:port-number 315 +--rw ssh-rekey-interval? uint16 316 +--rw ssh-timeout? uint8 317 +--rw ssh-retry-times? uint8 318 +--rw ssh-compatible-ssh1x-enable boolean 319 +--rw ssh-server-source? uint16 321 The structure of "common-security-policy" is: 323 grouping common-security-policy: 324 +--rw authen-fail-ip-block? 325 | +--rw ip-block-enable boolean 326 | +--rw retry-interval uint8 327 | +--rw retry-time uint8 328 | +--rw block-time uint16 329 | +--ro blocked-ip* [ip-address] 330 | +--ro ip-address inet:host 331 | +--ro unblocked-interval uint16 332 +--rw authen-fail-account-block? 333 | +--rw account-block-enable boolean 334 | +--rw retry-interval uint8 335 | +--rw retry-time uint8 336 | +--rw block-time uint16 337 | +--ro blocked-account* [account-name] 338 | +--ro account-name string 339 | +--ro unblocked-interval uint16 340 +--rw ip-white-list*? inet:host 341 +--rw login-delay-enable? boolean 342 +--rw authentication-code-enable? boolean 343 +--rw acl-name-list*? [I-D.ietf-netmod-acl-model] 345 In the above structure, several groupings are used. 347 o When an administrator log in to a device through SSH based 348 service, e.g. STelnet, the device acts as a SSH server. Thus, 349 the grouping "ssh-server-grouping" defined in 350 [I-D.ietf-netconf-ssh-client-server] is used. This grouping only 351 focuses on SSH-specific configuration, transport-level 352 configuration such as what ports to listen-on is not included. 353 Thus, configurations related to security hardening of SSH server, 354 for example, configuration of port number and rekey interval, are 355 added as grouping "ssh-server-security-hardening" in this 356 document. 358 o When an administrator log in to a device through web interface, 359 the device acts as a web server. Thus, the grouping "tls-server- 360 grouping" defined in [I-D.ietf-netconf-tls-client-server] is used. 361 This grouping also focuses on TLS-specific configuration, 362 additional security configuration nodes are provided to augment it 363 in this document. 365 o Grouping "common-security-policy" is defined to provide the re- 366 usability of common security policy to protect the devices from 367 password brute force attacks. Different types of security 368 controls can be used according to different deployment scenarios 369 and device capabilities. 371 5.1.3. AAA Configuration Security 373 Authentication, Authorization, and Accounting (AAA) provides user 374 management for network devices. RADIUS (Remote Authentication Dial 375 In User Service) and TACACS (Terminal Access Controller Access 376 Control System) are the commonly used AAA mechanisms. In order to 377 implement AAA, network infrastructure devices act as RADIUS/TACACS 378 clients to communicate with RADIUS/TACACS servers. Configuring the 379 connection to AAA servers and security controls should be 380 implemented. 382 o RADIUS configuration security: The subtree marked with [RFC7317] 383 uses the RADIUS server configuration subtree of RADIUS client 384 model defined in [RFC7317]. For security hardening, enabling 385 message authenticator and checking RADIUS attributes are 386 illustrated. Besides, the actions that may be taken when 387 authentication fail event or authorization check fail event 388 happens are modelled. 390 o TACACS configuration security: The following subtree models the 391 configuration of the connection to TACACS servers as well as 392 security controls to authentication or authorization check 393 failure. 395 +--rw aaa-config-security 396 +--rw (aaa-mode) 397 +--:(radius) 398 | +--rw radius-server* [name] [RFC7317] 399 | | +--rw name string 400 | | +--rw (transport) 401 | | | +--:(udp) 402 | | | +--rw address inet:host 403 | | | +--rw authentication-port? inet:port-number 404 | | | +--rw shared-secret string 405 | | +--rw authentication-type? identityref 406 | +--rw message-authenticator-enable? boolean 407 | +--rw check-radius-attribute*? identityref 408 | +--rw authorization-check-fail-policy? boolean 409 | +--rw authen-fail-policy!? 410 | +--rw retry-interval uint8 411 | +--rw retry-time uint8 412 | +--rw block-time uint16 413 +--:(tacacs) 414 +--rw tacacs-server* [name] 415 | +--rw name string 416 | +--rw (transport) 417 | | +--:(tcp) 418 | | +--rw address inet:host 419 | | +--rw authentication-port? inet:port-number 420 | | +--rw shared-secret string 421 | +--rw authentication-type? identityref 422 +--rw authorization-check-fail-policy? boolean 423 +--rw authen-fail-policy!? 424 +--rw retry-interval uint8 425 +--rw retry-time uint8 426 +--rw block-time uint16 428 5.1.4. Administrator Access Statistics 430 The statistics of the current online administrators and the failed 431 login attempts are useful for the monitoring of network 432 infrastructure devices. The structure is as follows: 434 +--ro admin-access-statistics 435 +--ro online-admin-list 436 | +--ro total-online-users uint8 437 | +--ro online-users* [account-name] 438 | +--ro account-name string 439 | +--ro ip-address inet:host 440 | +--ro mac-address yang:mac-address 441 +--ro online-fail-admin-list 442 +--ro fail-users* [account-name] 443 +--ro account-name string 444 +--ro ip-address inet:host 445 +--ro mac-address yang:mac-address 447 5.2. System Management Security 449 The "system-management-security" submodule is divided into three 450 parts: 452 submodule: system-management-security 453 +--rw system-management-security 454 +--rw snmp-security 455 +--rw netconf-security 456 +--rw port-management-security 458 5.2.1. SNMP Management Security 460 Simple Network Management Protocol (SNMP) is a network management 461 standard to monitor network devices. Three SNMP versions are 462 available: SNMPv1, SNMPv2c, and SNMPv3. [RFC7407] defines community- 463 based security model for SNMPv1 and SNMPv2c, view-based access 464 control model and user-based security model for SNMPv3. The 465 following module reuses the subtrees defined in RFC7407 for SNMP 466 security configuration, and only supplements ACL configuration for 467 VACM group. 469 +--rw snmp-security [RFC7407] 470 +--rw target* [name] 471 | ... 472 +--rw target-params* [name] 473 | ... 474 +--rw community* [index] 475 | ... 476 +--rw vacm 477 | +--rw group* [name] 478 | +--rw name snmp:group-name 479 | +--rw access* [context security-model security-level] 480 | ... 481 | +--rw acl-name-list* string 482 +--rw usm 483 ... 485 5.2.2. NETCONF Management Security 487 The NETCONF server model defined in 488 [I-D.ietf-netconf-netconf-client-server] supports both the SSH and 489 TLS transport protocols. To conduct more security controls on 490 NETCONF based operations, authorization rules can be used to control 491 which operations can be done and which resources can be accessed. 493 +--rw netconf-security 494 +--rw listen {listen}? [I-D.ietf-netconf-netconf-client-server] 495 | ... 496 +--rw call-home {call-home}? [I-D.ietf-netconf-netconf-client-server] 497 | ... 498 +--rw netconf-authorization? 499 +--rw task-group-rules* [task-group-name] 500 | +--rw task-group-name string 501 | +--rw task-group-rule* [rule-name] 502 | +--rw rule-name string 503 | +--rw rule-type identityref 504 +--rw user-group-rules* [user-group-name] 505 +--rw user-group-name string 506 +--rw user-group-rule* [rule-name] 507 +--rw rule-name string 508 +--rw rule-type identityref 510 5.2.3. Port Management Security 512 The current status of the ports that are available on the network 513 infrastructure devices can be retrieved and compared to the 514 communication matrix. 516 +--rw port-management-security 517 +--rw port-list* [port-number] 518 +--rw port-number inet:port-number 519 +--rw port-status boolean 521 5.3. Log Security 523 To monitor the running status and diagnose faults or attacks on 524 network infrastructure devices, the activities of network 525 administrators, the operations conducted on devices, and the security 526 notification of abnormal events are needed to be recorded in logs. 527 Besides, policy should be defined to deal with log overflow. Log 528 records can be outputted to console, or stored locally, or outputted 529 to remote Syslog server. The following defined "log-mode" subtree 530 reuses the security configuration of log remote transfer in 531 [I-D.ietf-netmod-syslog-model], and adds access control for locally 532 stored log files. 534 submodule: log-security 535 +--rw log-security 536 +--rw log-record 537 | +--rw admin-activity 538 | | +--rw admin-online-offline boolean 539 | | +--rw admin-create-delete boolean 540 | | +--rw admin-lock-unlock boolean 541 | | +--rw admin-level-change boolean 542 | | +--rw admin-attribute-change boolean 543 | | +--rw resource-activity 544 | | | +--rw file-delete-modify boolean 545 | | +--rw security-config-activity 546 | | | +--rw log-policy-change boolean 547 | | | +--rw log-operation-event boolean 548 | | | +--rw log-storage-event boolean 549 | | | +--rw security-policy-change boolean 550 | | +--rw broke-security-policy boolean 551 | | +--rw session-event boolean 552 | +--rw operation-activity 553 | | +--rw system-config-change boolean 554 | | +--rw system-status-change boolean 555 | | +--rw service-status-change boolean 556 | | +--rw software-update boolean 557 | | +--rw cmd-operation-event boolean 558 | +--rw key-cert-status-operation boolean 559 | +--rw security-alg-operation boolean 560 +--rw alert-notification 561 | +--rw login-fail-threshold uint8 562 | +--rw system-abnormal boolean 563 | +--rw attack boolean 564 | +--rw log-overflow-lost boolean 565 +--rw (log-overflow-action) 566 | +--:(rewrite-when-overflow) boolean 567 | | +--ro rewrite-numbers uint16 568 | +--:(discard-new-logs) boolean 569 | +--ro discard-numbers uint16 570 +--rw (log-mode) 571 +--:(file) {file-action}? 572 | +--rw user-level-for-read uint8 573 | +--rw user-level-for-delete uint8 574 +--:(remote) {remote-action}? [I-D.ietf-netmod-syslog-model] 575 +--rw destination* [name] 576 +--rw name string 577 +--rw (transport) 578 | ... 579 +--rw signing! {signed-messages}? 580 ... 582 5.4. File Security 584 Patches, packages, configuration files, password files are critical 585 system files for network infrastructure devices. To provide 586 security, only administrators with certain security privilege levels 587 are allowed to access or operate on these files. For file transfer 588 security, secure protocol should be used. If insecure protocol has 589 to be used, security hardening needs to be implemented. 591 +--rw file-security 592 +--rw (file-operation) 593 +--:(local) 594 | +--rw (file-type) 595 | +--:(patch) 596 | | +--rw user-level-for-execute uint8 597 | | +--rw patch-integrity-check boolean 598 | | +--rw integrity-alg* identityref 599 | +--:(package) 600 | | +--rw user-level-for-execute uint8 601 | | +--rw package-integrity-check boolean 602 | | +--rw integrity-alg* identityref 603 | +--:(configuration-file) 604 | | +--rw user-level-for-modify uint8 605 | | +--rw user-level-for-delete uint8 606 | | +--rw user-level-for-read uint8 607 | +--:(password-file) 608 | +--rw user-level-for-read uint8 609 +--:(remote-transfer) 610 +--rw (transfer-channel) 611 +--:(ftp) 612 | +--rw ftp-enable boolean 613 | +--rw ftp-server-port inet:port-number 614 | +--rw ftp-source-ip inet:host 615 | +--u common-security-policy 616 +--:(sftp) 617 | +--rw sftp-enable boolean 618 | +--rw sftp-server-port inet:port-number 619 | +--u ssh-server-grouping 620 | [I-D.ietf-netconf-ssh-client-server] 621 | +--u ssh-server-security-hardening 622 | +--u common-security-policy 623 +--:(scp) 624 | +--rw scp-enable boolean 625 | +--rw scp-server-port inet:port-number 626 | +--rw ssh-server-grouping 627 | [I-D.ietf-netconf-ssh-client-server] 628 | +--u ssh-server-security-hardening 629 | +--u common-security-policy 630 +--:(ftps) 631 +--rw ftps-enable boolean 632 +--rw ftps-server-port inet:port-number 633 +--u tls-server-grouping 634 [I-D.ietf-netconf-tls-client-server] 635 +--u common-security-policy 637 6. Network Infrastructure Device Security Baseline Yang Module 639 TBD 641 7. Acknowledgements 643 8. IANA Considerations 645 This document requires no IANA actions. 647 9. Security Considerations 649 Secure transport should be used to retrieve the current status of 650 management plane security baseline. 652 10. References 654 10.1. Normative References 656 [I-D.birkholz-sacm-yang-content] 657 Birkholz, H. and N. Cam-Winget, "YANG subscribed 658 notifications via SACM Statements", draft-birkholz-sacm- 659 yang-content-01 (work in progress), January 2018. 661 [I-D.dong-sacm-nid-cp-security-baseline] 662 Dong, Y. and L. Xia, "The Data Model of Network 663 Infrastructure Device Control Plane Security Baseline", 664 draft-dong-sacm-nid-cp-security-baseline-00 (work in 665 progress), September 2017. 667 [I-D.dong-sacm-nid-infra-security-baseline] 668 Dong, Y. and L. Xia, "The Data Model of Network 669 Infrastructure Device Infrastructure Layer Security 670 Baseline", draft-dong-sacm-nid-infra-security-baseline-00 671 (work in progress), January 2018. 673 [I-D.ietf-netconf-netconf-client-server] 674 Watsen, K. and G. Wu, "NETCONF Client and Server Models", 675 draft-ietf-netconf-netconf-client-server-05 (work in 676 progress), October 2017. 678 [I-D.ietf-netconf-ssh-client-server] 679 Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and 680 SSH Servers", draft-ietf-netconf-ssh-client-server-05 681 (work in progress), October 2017. 683 [I-D.ietf-netconf-tls-client-server] 684 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and 685 TLS Servers", draft-ietf-netconf-tls-client-server-05 686 (work in progress), October 2017. 688 [I-D.ietf-netmod-acl-model] 689 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 690 "Network Access Control List (ACL) YANG Data Model", 691 draft-ietf-netmod-acl-model-16 (work in progress), 692 February 2018. 694 [I-D.ietf-netmod-syslog-model] 695 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 696 Configuration", draft-ietf-netmod-syslog-model-23 (work in 697 progress), March 2018. 699 [I-D.ietf-sacm-information-model] 700 Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, 701 M., Haynes, D., and H. Birkholz, "SACM Information Model", 702 draft-ietf-sacm-information-model-10 (work in progress), 703 April 2017. 705 [I-D.xia-sacm-nid-dp-security-baseline] 706 Xia, L. and G. Zheng, "The Data Model of Network 707 Infrastructure Device Data Plane Security Baseline", 708 draft-xia-sacm-nid-dp-security-baseline-01 (work in 709 progress), January 2018. 711 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 712 System Management", RFC 7317, DOI 10.17487/RFC7317, August 713 2014, . 715 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 716 SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, 717 December 2014, . 719 10.2. Informative References 721 [I-D.ietf-netmod-yang-tree-diagrams] 722 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 723 ietf-netmod-yang-tree-diagrams-06 (work in progress), 724 February 2018. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, 728 DOI 10.17487/RFC2119, March 1997, 729 . 731 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 732 the Network Configuration Protocol (NETCONF)", RFC 6020, 733 DOI 10.17487/RFC6020, October 2010, 734 . 736 Appendix A. 738 The following is the whole structure of the YANG tree diagram for 739 network infrastructure device management plane. The existed RFCs and 740 drafts that related this document are listed at the right side. 742 module: nid-management-plane-security 743 +--rw admin-account-management-security 744 | +--rw admin-account-config-security 745 | +--rw admin-login-security [I-D.ietf-netconf-ssh-client-server] 746 | [I-D.ietf-netconf-tls-client-server] 747 | +--rw aaa-config-security [RFC7317] 748 | +--rw admin-access-statistics 749 +--rw system-management-security 750 | +--rw snmp-security [RFC7407] 751 | +--rw netconf-security [I-D.ietf-netconf-netconf-client-server] 752 | +--rw port-management-security 753 +--rw log-security 754 | +--rw log-record 755 | +--rw alert-notification 756 | +--rw log-overflow-action 757 | +--rw log-mode [I-D.ietf-netmod-syslog-model] 758 +--rw file-security [I-D.ietf-netconf-ssh-client-server] 759 [I-D.ietf-netconf-tls-client-server] 761 Draft [I-D.ietf-netconf-tls-client-server] and draft 762 [I-D.ietf-netconf-ssh-client-server] focus on YANG models for TLS- 763 specific configuration and SSH-specific configuration respectively. 764 The transport-level configuration, such as what ports to listen-on or 765 connect-to, is not included. Draft 766 [I-D.ietf-netconf-netconf-client-server] defines NETCONF YANG model 767 based on the data models defined in the above two documents. 769 [RFC7317] defines a YANG data model for system management of device 770 containing a NETCONF sever. It summarizes data modules for NETCONF 771 user authentication, and RADIUS server configuration. Three methods 772 are defined for user authentication: public key for local users over 773 SSH, password for local users over any secure transport, password for 774 RADIUS users over any secure transport. 776 [RFC7407] defines a YANG model for SNMP configuration, including 777 community-based security module for SNMPv1 and SNMPv2c, as well as 778 view-based access control module and user-based security module for 779 SNMPv3. 781 Draft [I-D.ietf-netmod-syslog-model] defines a YANG model for Syslog 782 configuration, including TLS based transport security and syslog 783 messages signing. 785 Authors' Addresses 787 Qiushi Lin 788 Huawei 789 Huawei Industrial Base 790 Shenzhen, Guangdong 518129 791 China 793 Email: linqiushi@huawei.com 795 Liang Xia 796 Huawei 797 101 Software Avenue, Yuhuatai District 798 Nanjing, Jiangsu 210012 799 China 801 Email: Frank.xialiang@huawei.com