Security Automation and Continuous Monitoring (SACM) Q. Lin Internet-Draft L. Xia Intended status: Standards Track Huawei Expires: September 2, 2018 March 1, 2018 The Data Model of Network Infrastructure Device Management Plane Security Baseline draft-lin-sacm-nid-mp-security-baseline-02 Abstract This document provides security baseline for network infrastructure device management plane, which is represented by YANG data model. The corresponding values of this YANG data model can be transported between Security Automation and Continuous Monitoring (SACM) components and used for network infrastructure device security evaluation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 2, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Lin & Xia Expires September 2, 2018 [Page 1] Internet-Draft Network Device Management Plane Security March 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 5 5.1. Administrator Account Management Security . . . . . . . . 5 5.1.1. Administrator Account Configuration Security . . . . 6 5.1.2. Administrator Login Security . . . . . . . . . . . . 6 5.1.3. AAA Configuration Security . . . . . . . . . . . . . 9 5.1.4. Administrator Access Statistics . . . . . . . . . . . 10 5.2. System Management Security . . . . . . . . . . . . . . . 11 5.2.1. SNMP Management Security . . . . . . . . . . . . . . 11 5.2.2. NETCONF Management Security . . . . . . . . . . . . . 12 5.2.3. Port Management Security . . . . . . . . . . . . . . 12 5.3. Log Security . . . . . . . . . . . . . . . . . . . . . . 13 5.4. File Security . . . . . . . . . . . . . . . . . . . . . . 15 6. Network Infrastructure Device Security Baseline Yang Module . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Besides user devices and servers, network infrastructure devices such as routers, switches, and firewalls are crucial to enterprise network security. Security baseline provides a minimal set of security requirements that are essential to protect enterprise network. The security baseline and organization specific requirements can then be used to assess the security posture of network infrastructure devices. In order to address threats and attacks to network infrastructure devices, different security functions and configurations are implemented in application layer, network layer and infrastructure layer. Network layer is typically categorized into three planes of operation: management plane, control plane and data plane. All the planes should be protected and monitored to provide network security. Lin & Xia Expires September 2, 2018 [Page 2] Internet-Draft Network Device Management Plane Security March 2018 This document focuses on security baseline for network infrastructure device management plane. Management plane provides configuration and monitoring services to network administrator or device owner. Unauthorized access, insecure access channels, weak cryptographic algorithms are common security issues that break management plane security. Security configuration and monitoring should be implemented to ensure proper control of network infrastructure devices. A number of security best practices have been proposed, such as disabling unused services and ports, discarding insecure access channels, and enforcing strong user authentication and authorization. In this document, we propose a minimal set of configuration and status requirements that are expected to be widely applicable to common network infrastructure devices. Additional requirements can be supported by specific vendors. Thus interoperability and extensibility can be achieved. Interface to Network Security Functions (I2NSF) working group provides standard interfaces for controlling and monitoring NSFs, the work of this document is different from that of I2NSF working group. The main differences include: o I2NSF focuses on flow-based NSFs, while this document works on network infrastructure devices (physical or virtual) including routing and forwarding devices as well as network security devices. o I2NSF focuses on the provision and monitor of I2NSF policy rules for flow-based NSFs, while this document doesn't work on the functional configuration of NSFs policy rules. This document focuses on security configuration of account management, system management protocols, system ports, log, and local file system to provide operation security. For example, configuration of firewall rules is out of scope, but the configuration of ACL rules for remote access administrator is considered in this document. YANG data model is used in this document to model the security baseline for network infrastructure device management plane. [I-D.birkholz-sacm-yang-content] defines a method of constructing the YANG data model scheme for the security posture assessment of the network infrastructure device by brokering of YANG push telemetry via SACM statements. In this document, we follow the same way to define the YANG output for network infrastructure device security posture based on the [I-D.ietf-sacm-information-model]. Besides management plane security baseline, the security baselines for control plane, data plane, and infrastructure layer of network infrastructure devices are described in [I-D.dong-sacm-nid-cp-security-baseline], Lin & Xia Expires September 2, 2018 [Page 3] Internet-Draft Network Device Management Plane Security March 2018 [I-D.xia-sacm-nid-dp-security-baseline] and [I-D.dong-sacm-nid-infra-security-baseline] respectively. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the terms defined in [RFC6020]. 4. Tree Diagrams Tree diagram defined in [I-D.ietf-netmod-yang-tree-diagrams] is used to represent the YANG data model of network infrastructure device management plane security. The meaning of the symbols used in the tree diagram and the syntax are as follows: o A module is identified by "module:" followed the module-name. The top-level data nodes defined in the module, offset by 2 spaces. Submodules are represented in the same fashion as modules, but are identified by "submodule:" followed the (sub)module-name. o Groupings, offset by 2 spaces, and identified by the keyword "grouping" followed by the name of the grouping and a colon (":") character. o Each node in the tree is prefaces with "+--". Schema nodes that are children of another node are offset from the parent by 3 spaces. o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" means state data (read-only), "x" is used to mark rpcs and actions, "w" denotes the input parameters to rpcs and actions, and "u" indicates the use of a predefined grouping. o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a "list" and "leaf- list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). Lin & Xia Expires September 2, 2018 [Page 4] Internet-Draft Network Device Management Plane Security March 2018 o Ellipsis ("...") stands for contents of subtrees that are not shown. o Curly brackets and a question mark "{...}?" are combined to represent the features that node depends on. 5. Data Model Structure This document focuses on network infrastructure device management plane security, including security of account management, system management protocols, sytem ports, log, and local file system. Both security configuration and runtime state of security controls are taken into consideration. Four submodules will be illustrated in the following sections to represent the security baseline for: o Administrator account management security o System management protocol security and port management security o Log security o Local file system security There exists a multitude of YANG models for network devices and network protocols. For management plane security, several RFCs and drafts has defined some related parts. But an overall data model of management plane security is still missing. Moreover, the related data models may only focus on part of the security functions. Besides defining new YANG models or groupings, the following sections will also reuse the existing YANG models and provide additional attributes or groupings for the missing parts. Appendix A provides a summary of existing YANG models and the relationship to the security baseline defined in this document. 5.1. Administrator Account Management Security The "admin-account-management-security" submodule is divided into four parts: submodule: admin-account-management-security +--rw admin-account-management-security +--rw admin-account-config-security +--rw admin-login-security +--rw aaa-config-security +--rw admin-access-statistics Lin & Xia Expires September 2, 2018 [Page 5] Internet-Draft Network Device Management Plane Security March 2018 5.1.1. Administrator Account Configuration Security In order to provide basic protection of administrator accounts, configuration requirements on account names and passwords should be applied. The commonly applied security controls includes: the account name should not be too short, the password should contain multiple types of characters, password should be resetted after a period of time, the new password should be different with the past one, etc. The following data model illustrates these kinds of security controls. +--rw admin-account-config-security +--rw account-name-requirement! | +--rw account-name-min-length uint8 +--rw account-password-requirement! | +--rw password-min-length uint8 | +--rw password-expire-days uint16 | +--rw password-complexity-check? | +--rw password-character? | | +--rw password-character-type enumeration | | +--rw password-character-min-type uint8 | +--rw check-past-password? | | +--rw past-times uint8 | +--rw check-account-name? boolean +--rw account-password-encryption identityref 5.1.2. Administrator Login Security Network infrastructure devices typically can be managed through command line interface (CLI) or web user interface. The web user interface provides basic maintenance and management functions. Sometimes an administrator still needs to use the CLI to implement complex or fine-grained management. If insecure access channels have to be used, several security controls should be enforced. Lin & Xia Expires September 2, 2018 [Page 6] Internet-Draft Network Device Management Plane Security March 2018 +--rw admin-login-security +--rw (user-interface-type) +--:(console) | +--rw console-authen-mode identityref | +--rw console-user-level uint8 +--:(vty) | +--rw vty* [vty-number] | +--rw vty-number uint8 | +--rw vty-user-authen-mode identityref | +--rw vty-user-level uint8 | +--rw (service-type) | +--:(telnet) | | +--rw telnet-enable boolean | | +--rw telnet-server-source? uint16 | | +--rw telnet-server-port inet:port-number | | +--rw telnet-timeout? uint16 | | +--u common-security-policy | +--:(ssh) | +--rw ssh-enable boolean | +--u ssh-server-grouping | [I-D.ietf-netconf-ssh-client-server] | +--u ssh-server-security-hardening | +--u common-security-policy +--:(web) +--rw web-authen-mode identityref +--rw web-user-level uint8 +--rw http-server-source uint16 +--rw https-ipv4-enable boolean +--rw https-ipv6-enable boolean +--rw https-source-port inet:port-number +--rw https-timeout uint16 +--u common-security-policy +--u tls-server-grouping [I-D.ietf-netconf-tls-client-server] The structure of "ssh-server-security-hardening" is: grouping ssh-server-security-hardening: +--rw ssh-authen-mode* identityref +--rw ssh-dh-exchange-min-len? uint16 +--rw ssh-server-port? inet:port-number +--rw ssh-rekey-interval? uint16 +--rw ssh-timeout? uint8 +--rw ssh-retry-times? uint8 +--rw ssh-compatible-ssh1x-enable boolean +--rw ssh-server-source? uint16 The structure of "common-security-policy" is: Lin & Xia Expires September 2, 2018 [Page 7] Internet-Draft Network Device Management Plane Security March 2018 grouping common-security-policy: +--rw authen-fail-ip-block? | +--rw ip-block-enable boolean | +--rw retry-interval uint8 | +--rw retry-time uint8 | +--rw block-time uint16 | +--ro blocked-ip* [ip-address] | +--ro ip-address inet:host | +--ro unblocked-interval uint16 +--rw authen-fail-account-block? | +--rw account-block-enable boolean | +--rw retry-interval uint8 | +--rw retry-time uint8 | +--rw block-time uint16 | +--ro blocked-account* [account-name] | +--ro account-name string | +--ro unblocked-interval uint16 +--rw ip-white-list*? inet:host +--rw login-delay-enable? boolean +--rw authentication-code-enable? boolean +--rw acl-name-list*? [I-D.ietf-netmod-acl-model] In the above structure, several groupings are used. o When an administrator log in to a device through SSH based service, e.g. STelnet, the device acts as a SSH server. Thus, the grouping "ssh-server-grouping" defined in [I-D.ietf-netconf-ssh-client-server] is used. This grouping only focuses on SSH-specific configuration, transport-level configuration such as what ports to listen-on is not included. Thus, configurations related to security hardening of SSH server, for example, configuration of port number and rekey interval, are added as grouping "ssh-server-security-hardening" in this document. o When an administrator log in to a device through web interface, the device acts as a web server. Thus, the grouping "tls-server- grouping" defined in [I-D.ietf-netconf-tls-client-server] is used. This grouping also focuses on TLS-specific configuration, additional security configuration nodes are provided to augment it in this document. o Grouping "common-security-policy" is defined to provide the re- usability of common security policy to protect the devices from password brute force attacks. Different types of security controls can be used according to different deployment scenarios and device capabilities. Lin & Xia Expires September 2, 2018 [Page 8] Internet-Draft Network Device Management Plane Security March 2018 5.1.3. AAA Configuration Security Authentication, Authorization, and Accounting (AAA) provides user management for network devices. RADIUS (Remote Authentication Dial In User Service) and TACACS (Terminal Access Controller Access Control System) are the commonly used AAA mechanisms. In order to implement AAA, network infrastructure devices act as RADIUS/TACACS clients to communicate with RADIUS/TACACS servers. Configuring the connection to AAA servers and security controls should be implemented. o RADIUS configuration security: The subtree marked with [RFC7317] uses the RADIUS server configuration subtree of RADIUS client model defined in [RFC7317]. For security hardening, enabling message authenticator and checking RADIUS attributes are illustrated. Besides, the actions that may be taken when authentication fail event or authorization check fail event happens are modelled. o TACACS configuration security: The following subtree models the configuration of the connection to TACACS servers as well as security controls to authentication or authorization check failure. Lin & Xia Expires September 2, 2018 [Page 9] Internet-Draft Network Device Management Plane Security March 2018 +--rw aaa-config-security +--rw (aaa-mode) +--:(radius) | +--rw radius-server* [name] [RFC7317] | | +--rw name string | | +--rw (transport) | | | +--:(udp) | | | +--rw address inet:host | | | +--rw authentication-port? inet:port-number | | | +--rw shared-secret string | | +--rw authentication-type? identityref | +--rw message-authenticator-enable? boolean | +--rw check-radius-attribute*? identityref | +--rw authorization-check-fail-policy? boolean | +--rw authen-fail-policy!? | +--rw retry-interval uint8 | +--rw retry-time uint8 | +--rw block-time uint16 +--:(tacacs) +--rw tacacs-server* [name] | +--rw name string | +--rw (transport) | | +--:(tcp) | | +--rw address inet:host | | +--rw authentication-port? inet:port-number | | +--rw shared-secret string | +--rw authentication-type? identityref +--rw authorization-check-fail-policy? boolean +--rw authen-fail-policy!? +--rw retry-interval uint8 +--rw retry-time uint8 +--rw block-time uint16 5.1.4. Administrator Access Statistics The statistics of the current online administrators and the failed login attempts are useful for the monitoring of network infrastructure devices. The structure is as follows: Lin & Xia Expires September 2, 2018 [Page 10] Internet-Draft Network Device Management Plane Security March 2018 +--ro admin-access-statistics +--ro online-admin-list | +--ro total-online-users uint8 | +--ro online-users* [account-name] | +--ro account-name string | +--ro ip-address inet:host | +--ro mac-address yang:mac-address +--ro online-fail-admin-list +--ro fail-users* [account-name] +--ro account-name string +--ro ip-address inet:host +--ro mac-address yang:mac-address 5.2. System Management Security The "system-management-security" submodule is divided into three parts: submodule: system-management-security +--rw system-management-security +--rw snmp-security +--rw netconf-security +--rw port-management-security 5.2.1. SNMP Management Security Simple Network Management Protocol (SNMP) is a network management standard to monitor network devices. Three SNMP versions are available: SNMPv1, SNMPv2c, and SNMPv3. [RFC7407] defines community- based security model for SNMPv1 and SNMPv2c, view-based access control model and user-based security model for SNMPv3. The following module reuses the subtrees defined in RFC7407 for SNMP security configuration, and only supplements ACL configuration for VACM group. Lin & Xia Expires September 2, 2018 [Page 11] Internet-Draft Network Device Management Plane Security March 2018 +--rw snmp-security [RFC7407] +--rw target* [name] | ... +--rw target-params* [name] | ... +--rw community* [index] | ... +--rw vacm | +--rw group* [name] | +--rw name snmp:group-name | +--rw access* [context security-model security-level] | ... | +--rw acl-name-list* string +--rw usm ... 5.2.2. NETCONF Management Security The NETCONF server model defined in [I-D.ietf-netconf-netconf-client-server] supports both the SSH and TLS transport protocols. To conduct more security controls on NETCONF based operations, authorization rules can be used to control which operations can be done and which resources can be accessed. +--rw netconf-security +--rw listen {listen}? [I-D.ietf-netconf-netconf-client-server] | ... +--rw call-home {call-home}? [I-D.ietf-netconf-netconf-client-server] | ... +--rw netconf-authorization? +--rw task-group-rules* [task-group-name] | +--rw task-group-name string | +--rw task-group-rule* [rule-name] | +--rw rule-name string | +--rw rule-type identityref +--rw user-group-rules* [user-group-name] +--rw user-group-name string +--rw user-group-rule* [rule-name] +--rw rule-name string +--rw rule-type identityref 5.2.3. Port Management Security The current status of the ports that are available on the network infrastructure devices can be retrieved and compared to the communication matrix. Lin & Xia Expires September 2, 2018 [Page 12] Internet-Draft Network Device Management Plane Security March 2018 +--rw port-management-security +--rw port-list* [port-number] +--rw port-number inet:port-number +--rw port-status boolean 5.3. Log Security To monitor the running status and diagnose faults or attacks on network infrastructure devices, the activities of network administrators, the operations conducted on devices, and the security notification of abnormal events are needed to be recorded in logs. Besides, policy should be defined to deal with log overflow. Log records can be outputted to console, or stored locally, or outputted to remote Syslog server. The following defined "log-mode" subtree reuses the security configuration of log remote transfer in [I-D.ietf-netmod-syslog-model], and adds access control for locally stored log files. Lin & Xia Expires September 2, 2018 [Page 13] Internet-Draft Network Device Management Plane Security March 2018 submodule: log-security +--rw log-security +--rw log-record | +--rw admin-activity | | +--rw admin-online-offline boolean | | +--rw admin-create-delete boolean | | +--rw admin-lock-unlock boolean | | +--rw admin-level-change boolean | | +--rw admin-attribute-change boolean | | +--rw resource-activity | | | +--rw file-delete-modify boolean | | +--rw security-config-activity | | | +--rw log-policy-change boolean | | | +--rw log-operation-event boolean | | | +--rw log-storage-event boolean | | | +--rw security-policy-change boolean | | +--rw broke-security-policy boolean | | +--rw session-event boolean | +--rw operation-activity | | +--rw system-config-change boolean | | +--rw system-status-change boolean | | +--rw service-status-change boolean | | +--rw software-update boolean | | +--rw cmd-operation-event boolean | +--rw key-cert-status-operation boolean | +--rw security-alg-operation boolean +--rw alert-notification | +--rw login-fail-threshold uint8 | +--rw system-abnormal boolean | +--rw attack boolean | +--rw log-overflow-lost boolean +--rw (log-overflow-action) | +--:(rewrite-when-overflow) boolean | | +--ro rewrite-numbers uint16 | +--:(discard-new-logs) boolean | +--ro discard-numbers uint16 +--rw (log-mode) +--:(file) {file-action}? | +--rw user-level-for-read uint8 | +--rw user-level-for-delete uint8 +--:(remote) {remote-action}? [I-D.ietf-netmod-syslog-model] +--rw destination* [name] +--rw name string +--rw (transport) | ... +--rw signing! {signed-messages}? ... Lin & Xia Expires September 2, 2018 [Page 14] Internet-Draft Network Device Management Plane Security March 2018 5.4. File Security Patches, packages, configuration files, password files are critical system files for network infrastructure devices. To provide security, only administrators with certain security privilege levels are allowed to access or operate on these files. For file transfer security, secure protocol should be used. If insecure protocol has to be used, security hardening needs to be implemented. Lin & Xia Expires September 2, 2018 [Page 15] Internet-Draft Network Device Management Plane Security March 2018 +--rw file-security +--rw (file-operation) +--:(local) | +--rw (file-type) | +--:(patch) | | +--rw user-level-for-execute uint8 | | +--rw patch-integrity-check boolean | | +--rw integrity-alg* identityref | +--:(package) | | +--rw user-level-for-execute uint8 | | +--rw package-integrity-check boolean | | +--rw integrity-alg* identityref | +--:(configuration-file) | | +--rw user-level-for-modify uint8 | | +--rw user-level-for-delete uint8 | | +--rw user-level-for-read uint8 | +--:(password-file) | +--rw user-level-for-read uint8 +--:(remote-transfer) +--rw (transfer-channel) +--:(ftp) | +--rw ftp-enable boolean | +--rw ftp-server-port inet:port-number | +--rw ftp-source-ip inet:host | +--u common-security-policy +--:(sftp) | +--rw sftp-enable boolean | +--rw sftp-server-port inet:port-number | +--u ssh-server-grouping | [I-D.ietf-netconf-ssh-client-server] | +--u ssh-server-security-hardening | +--u common-security-policy +--:(scp) | +--rw scp-enable boolean | +--rw scp-server-port inet:port-number | +--rw ssh-server-grouping | [I-D.ietf-netconf-ssh-client-server] | +--u ssh-server-security-hardening | +--u common-security-policy +--:(ftps) +--rw ftps-enable boolean +--rw ftps-server-port inet:port-number +--u tls-server-grouping [I-D.ietf-netconf-tls-client-server] +--u common-security-policy Lin & Xia Expires September 2, 2018 [Page 16] Internet-Draft Network Device Management Plane Security March 2018 6. Network Infrastructure Device Security Baseline Yang Module TBD 7. Acknowledgements 8. IANA Considerations This document requires no IANA actions. 9. Security Considerations Secure transport should be used to retrieve the current status of management plane security baseline. 10. References 10.1. Normative References [I-D.birkholz-sacm-yang-content] Birkholz, H. and N. Cam-Winget, "YANG subscribed notifications via SACM Statements", draft-birkholz-sacm- yang-content-01 (work in progress), January 2018. [I-D.dong-sacm-nid-cp-security-baseline] Dong, Y. and L. Xia, "The Data Model of Network Infrastructure Device Control Plane Security Baseline", draft-dong-sacm-nid-cp-security-baseline-00 (work in progress), September 2017. [I-D.dong-sacm-nid-infra-security-baseline] Dong, Y. and L. Xia, "The Data Model of Network Infrastructure Device Infrastructure Layer Security Baseline", draft-dong-sacm-nid-infra-security-baseline-00 (work in progress), January 2018. [I-D.ietf-netconf-netconf-client-server] Watsen, K. and G. Wu, "NETCONF Client and Server Models", draft-ietf-netconf-netconf-client-server-05 (work in progress), October 2017. [I-D.ietf-netconf-ssh-client-server] Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and SSH Servers", draft-ietf-netconf-ssh-client-server-05 (work in progress), October 2017. Lin & Xia Expires September 2, 2018 [Page 17] Internet-Draft Network Device Management Plane Security March 2018 [I-D.ietf-netconf-tls-client-server] Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and TLS Servers", draft-ietf-netconf-tls-client-server-05 (work in progress), October 2017. [I-D.ietf-netmod-acl-model] Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, "Network Access Control List (ACL) YANG Data Model", draft-ietf-netmod-acl-model-16 (work in progress), February 2018. [I-D.ietf-netmod-syslog-model] Wildes, C. and K. Koushik, "A YANG Data Model for Syslog Configuration", draft-ietf-netmod-syslog-model-23 (work in progress), March 2018. [I-D.ietf-sacm-information-model] Waltermire, D., Watson, K., Kahn, C., Lorenzin, L., Cokus, M., Haynes, D., and H. Birkholz, "SACM Information Model", draft-ietf-sacm-information-model-10 (work in progress), April 2017. [I-D.xia-sacm-nid-dp-security-baseline] Xia, L. and G. Zheng, "The Data Model of Network Infrastructure Device Data Plane Security Baseline", draft-xia-sacm-nid-dp-security-baseline-01 (work in progress), January 2018. [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, . 10.2. Informative References [I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- ietf-netmod-yang-tree-diagrams-06 (work in progress), February 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Lin & Xia Expires September 2, 2018 [Page 18] Internet-Draft Network Device Management Plane Security March 2018 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Appendix A. The following is the whole structure of the YANG tree diagram for network infrastructure device management plane. The existed RFCs and drafts that related this document are listed at the right side. module: nid-management-plane-security +--rw admin-account-management-security | +--rw admin-account-config-security | +--rw admin-login-security [I-D.ietf-netconf-ssh-client-server] | [I-D.ietf-netconf-tls-client-server] | +--rw aaa-config-security [RFC7317] | +--rw admin-access-statistics +--rw system-management-security | +--rw snmp-security [RFC7407] | +--rw netconf-security [I-D.ietf-netconf-netconf-client-server] | +--rw port-management-security +--rw log-security | +--rw log-record | +--rw alert-notification | +--rw log-overflow-action | +--rw log-mode [I-D.ietf-netmod-syslog-model] +--rw file-security [I-D.ietf-netconf-ssh-client-server] [I-D.ietf-netconf-tls-client-server] Draft [I-D.ietf-netconf-tls-client-server] and draft [I-D.ietf-netconf-ssh-client-server] focus on YANG models for TLS- specific configuration and SSH-specific configuration respectively. The transport-level configuration, such as what ports to listen-on or connect-to, is not included. Draft [I-D.ietf-netconf-netconf-client-server] defines NETCONF YANG model based on the data models defined in the above two documents. [RFC7317] defines a YANG data model for system management of device containing a NETCONF sever. It summarizes data modules for NETCONF user authentication, and RADIUS server configuration. Three methods are defined for user authentication: public key for local users over SSH, password for local users over any secure transport, password for RADIUS users over any secure transport. [RFC7407] defines a YANG model for SNMP configuration, including community-based security module for SNMPv1 and SNMPv2c, as well as Lin & Xia Expires September 2, 2018 [Page 19] Internet-Draft Network Device Management Plane Security March 2018 view-based access control module and user-based security module for SNMPv3. Draft [I-D.ietf-netmod-syslog-model] defines a YANG model for Syslog configuration, including TLS based transport security and syslog messages signing. Authors' Addresses Qiushi Lin Huawei Huawei Industrial Base Shenzhen, Guangdong 518129 China Email: linqiushi@huawei.com Liang Xia Huawei 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: Frank.xialiang@huawei.com Lin & Xia Expires September 2, 2018 [Page 20]