Security Automation and Continuous Monitoring (SACM) Q. Lin Internet-Draft L. Xia Intended status: Standards Track Huawei Expires: May 3, 2018 October 30, 2017 The Data Model of Network Infrastructure Device Management Plane Security Baseline draft-lin-sacm-nid-mp-security-baseline-01 Abstract Network infrastructure devices such as routers and switches are important parts for network security. This document describes security baseline for network infrastructure device management plane, with YANG output, to provide a minimum set of important security management features. 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 May 3, 2018. Copyright Notice Copyright (c) 2017 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 May 3, 2018 [Page 1] Internet-Draft Network Device Management Plane Security October 2017 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 . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Data Model Structure . . . . . . . . . . . . . . . . . . . . 4 5.1. User Authentication . . . . . . . . . . . . . . . . . . . 5 5.1.1. User Login Security . . . . . . . . . . . . . . . . . 5 5.1.2. AAA User Authentication . . . . . . . . . . . . . . . 8 5.1.3. User Profile . . . . . . . . . . . . . . . . . . . . 9 5.2. System Management Security . . . . . . . . . . . . . . . 10 5.2.1. SNMP Management Security . . . . . . . . . . . . . . 10 5.2.2. NETCONF Management Security . . . . . . . . . . . . . 13 5.3. Log Security . . . . . . . . . . . . . . . . . . . . . . 14 5.4. File Security . . . . . . . . . . . . . . . . . . . . . . 15 6. Network Infrastructure Device Security Baseline Yang Module . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Securing network infrastructure devices is a challenging and critical task for organizations and operators to preserve confidentiality, integrity and availability for network and network traffic information. Thus, development and deployment of security baseline for network infrastructure is needed to provide a solid foundation for the overall network security. To address threats and attacks to network infrastructure devices, different security functions are implemented in application layer, network layer and infrastructure layer. Network layer of network infrastructure device is typically categorized into three planes of operation: management plane, control plane and data plane. All the planes should be protected and monitored to secure network. This document focuses on security baseline for network infrastructure device management plane. Management plane provides configuration and monitoring services to network infrastructure devices. It provides a platform for all the system management traffic. Unauthorized access, Lin & Xia Expires May 3, 2018 [Page 2] Internet-Draft Network Device Management Plane Security October 2017 insecure access channels, insecure cryptographic algorithms are common security issues that break management plane security. To enhance security, secure configuration should be implemented to ensure proper configuration and 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, enforcing strong user authentication and authorization, etc. In this document, we propose the most important and universal points of management plane security baseline to provide a minimum set. Thus, future extensibility can be achieved. [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, application layer and infrastructure layer of network infrastructure devices are described in [I-D.dong-sacm-nid-cp-security-baseline], [I-D.xia-sacm-nid-dp-security-baseline] and [I-D.xia-sacm-nid-app- infr-layers-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 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) [RFC6020]. 4. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). Lin & Xia Expires May 3, 2018 [Page 3] Internet-Draft Network Device Management Plane Security October 2017 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 (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 5. Data Model Structure The following parts describe several key points of management plane security baseline, including user authentication, system management security, log security and file security. Both security configuration and runtime state of security controls are taken into consideration. The overall structure is: module:network-device-security +--rw user-authentication | +--rw user-login-security [I-D.ietf-netconf-tls-client-server] | [I-D.ietf-netconf-ssh-client-server] | +--rw aaa-user-authentication [RFC7317] | +--rw user-profile [RFC7317] +--rw system-management-security | +--rw snmp-security [RFC7407] | +--rw netconf-security [RFC7317] | [I-D.ietf-netconf-netconf-client-server] +--log-security [I-D.ietf-netmod-syslog-model] +--rw file-security There exists a multitude of YANG models for network devices and network protocols. For management plane security, several RFCs and drafts has defined related parts. These RFCs and drafts are listed in the above structure. 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. The following sections will reuse the existing YANG models and provide additional modules or groupings for the missing parts. 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 Lin & Xia Expires May 3, 2018 [Page 4] Internet-Draft Network Device Management Plane Security October 2017 [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 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. 5.1. User Authentication The "user-authentication" module is divided into three parts: module:user-authentication +--rw user-authentication +--rw user-login-security [I-D.ietf-netconf-tls-client-server] | [I-D.ietf-netconf-ssh-client-server] +--rw aaa-user-authentication [RFC7317] +--rw user-profile [RFC7317] 5.1.1. User Login Security Network infrastructure devices typically can be managed through command line or web user interface. To configure a device through command line, a user can log in to a device through the console port or using remote access channel. Generally, there are two types of user interfaces for CLI configuration: console user interface and virtual type terminal (VTY) user interface. When a device functions as a server, a user can use the web user interface for login and configuration. The web user interface provides basic maintenance and management functions. Sometimes a user 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. Access Control List (ACL) can be used to enforce security policies on vty login and web login. In this document, "ietf-access- control-list" module defined in [I-D.ietf-netmod-acl-model] is reused for access control of remote login. Lin & Xia Expires May 3, 2018 [Page 5] Internet-Draft Network Device Management Plane Security October 2017 submodule:user-login-security +--rw user-login-security +--rw (user-interface-type) +--:(console) | +--rw console-user-authen-mode identityref | +--rw console-user-level uint8 +--:(vty) | +--rw absolute-number uint8 | +--rw relative-number uint8 | +--rw vty-user-authen-mode identityref | +--rw vty-user-level uint8 | +--rw ip-block-params {ip-block-enable}? | +--rw acl*? [acl-name acl-type] | | +--rw acl-name string | | +--rw acl-type acl:acl-type | +--:(remote-channel) | +--:(telnet) | | +--rw telnet-enable boolean | | +--rw telent-authen-mode identityref | | +--rw telnet-server-source unint16 | | +--rw telent-server-port inet:port-number | | +--rw telent-timeout uint16 | +--:(ssh) | +--rw ssh-enable boolean | +--rw ssh-security-params +--:(web) +--rw web-authen-mode identityref +--rw web-user-level uint8 +--rw telnet-server-source unint16 +--rw https-ipv4-enable boolean +--rw https-ipv6-enable boolean +--rw https-source-port inet:port-number +--rw https-timeout uint16 +--rw acl*? [acl-name acl-type] | +--rw acl-name string | +--rw acl-type acl:acl-type +--rw tls-security-params The structure of "ip-block-params" is: Lin & Xia Expires May 3, 2018 [Page 6] Internet-Draft Network Device Management Plane Security October 2017 grouping: ip-block-params +--rw ip-block-params | +--rw (ip-block-type) | +--:(ip-block-at-first-fail) | | +--rw ip-block-initial-time uint8 | | +--rw ip-max-fail-times? uint8 | | +--rw ip-block-time-increment uint8 | | +--rw ip-block-increment-ratio? boolean | +--:(ip-block-at-several-fails) | +--rw ip-fail-times uint8 | +--rw ip-fail-period uint8 | +--rw ip-block-time uint16 +--ro blocked-list* [blocked-ip] +--ro blocked-ip inet:host +--ro unblocked-interval uint16 The structure of "ssh-security-params" is: grouping: ssh-security-params +--rw ssh-security-params +--rw ssh-service-type identityref +--rw ssh-authen-mode identityref +--rw ssh-server-port? inet:port-number +--rw ssh-timeout? uint8 +--rw ssh-retry-times uint8 +--rw ssh-server-source uint16 +--rw host-keys | +--rw host-key* [name] | +--rw name string | +--rw (host-key-type) | +--:(public-key) -> /ks:keystore/keys/key/name | +--:(certificate) | +--rw certificate? leafref {sshcom:ssh-x509-certs}? +--rw client-cert-auth {sshcom:ssh-x509-certs}? | +--rw trusted-ca-certs? leafref | +--rw trusted-client-certs? leafref +--rw transport-params {ssh-server-transport-params-config}? +--rw host-key | +--rw host-key-alg* identityref +--rw key-exchange | +--rw key-exchange-alg* identityref | +--rw dh-exchange-min-len uint8 +--rw encryption | +--rw encryption-alg* identityref +--rw mac | +--rw mac-alg* identityref +--rw compression +--rw compression-alg* identityref Lin & Xia Expires May 3, 2018 [Page 7] Internet-Draft Network Device Management Plane Security October 2017 The above structure reuses "ssh-server-grouping" defined in [I-D.ietf-netconf-ssh-client-server]. And it also adds other security configurations, such as authentication mode and SSH server port number. The structure of "tls-security-params" is: grouping: tls-security-params +--rw tls-security-params +--rw certificates | +--rw certificate* [name] | +--rw name? leafref +--rw client-auth | +--rw pinned-ca-certs? -> /ks:keystore/pinned-certificates/name | +--rw pinned-client-certs? -> /ks:keystore/pinned-certificates/nam +--rw hello-params {tls-server-hello-params-config}? +--rw tls-versions | +--rw tls-version* identityref +--rw cipher-suites +--rw cipher-suite* identityref The above structure import the grouping defined in [I-D.ietf-netconf-tls-client-server]. 5.1.2. AAA User Authentication 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. [RFC7317] defines RADIUS client model for NETCONF. This section reuses the definition and add "radius-server-type" to distinguish the two different server types: authentication and authorization server, accounting server. Besides, TACACS data model is also provided. Lin & Xia Expires May 3, 2018 [Page 8] Internet-Draft Network Device Management Plane Security October 2017 submodule: aaa-user-authentication +--rw aaa-user-authentication +--rw (aaa-mode) +--:(radius) | +--rw radius-server* [name] | +--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 radius-server-type identityref +--:(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 tacacs-server-type identityref 5.1.3. User Profile User profiles are defined for user access control. For password based authentication, the complexity of user password should be confirmed. submodule: user-profile +--rw user-profile +--rw user* [user-name] +--rw user-name string +--rw password ianach:crypt-hash +--rw password-policy-params? +--rw user-privilege-level uint8 +--rw user-service-type identityref +--rw authorized-key* [name] +--rw name string +--rw algorithm identityref +--rw pulic-key binary The above structure reuses user authentication model defined in [RFC7317] for NETCONF users. To support user authentication in different user interfaces, additional parameters are added. The structure of "password-policy-params" is: Lin & Xia Expires May 3, 2018 [Page 9] Internet-Draft Network Device Management Plane Security October 2017 grouping: password-policy-params +--rw password-policy? +--rw min-username-length uint8 +--rw min-password-length uint8 +--rw password-character? | +--rw password-character-type enumeration | +--rw password-character-min-type uint8 +--rw compare-past-password? | +--rw past-times uint8 +--rw compare-username? boolean 5.2. System Management Security The "system-management-security" module is divided into two parts: module: system-management-security +--rw system-management-security +--rw snmp-security [RFC7407] +--rw netconf-security [RFC7317] [I-D.ietf-netconf-netconf-client-server] 5.2.1. SNMP Management Security Simple Network Management Protocol (SNMP) is a network management standard for monitoring managed 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 security control related submodules defined in RFC7407 for SNMP security configuration, substitutes SSH and TLS common parameters grouping with the groupings defined in section Section 5.1.1. submodule:snmp-management-security +--rw snmp-management-security +--rw target* [name] | +--rw name snmp:identifier | +--rw (transport) | | +--:(udp) | | | +--rw udp | | | +--rw ip inet:ip-address | | | +--rw port? inet:port-number | | | +--rw prefix-length? uint8 | | +--:(tls) | | | +--rw tls | | | +--rw tls-security-params | | +--:(dtls) | | | +--rw dtls Lin & Xia Expires May 3, 2018 [Page 10] Internet-Draft Network Device Management Plane Security October 2017 | | | +--rw tls-security-params | | +--:(ssh) | | +--rw ssh | | +--rw ssh-security-params | +--rw tlstm | | +--rw cert-to-name* [id] | | +--rw id uint32 | | +--rw fingerprint x509c2n:tls-fingerprint | | +--rw map-type identityref | | +--rw name string | +--rw tag* snmp:identifier | +--rw timeout? uint32 | +--rw retries? uint8 | +--rw target-params snmp:identifier +--rw target-params* [name] | +--rw name snmp:identifier | +--rw (params)? | +--:(v1) | | +--rw v1 | | +--rw security-name snmp:security-name | +--:(v2c) | | +--rw v2c | | +--rw security-name snmp:security-name | +--:(usm) | | +--rw usm | | +--rw user-name snmp:security-name | | +--rw security-level security-level | +--:(tsm) | +--rw tsm | +--rw security-name snmp:security-name | +--rw security-level security-level +--rw community* [index] | +--rw index snmp:identifier | +--rw (name)? | | +--:(text-name) | | | +--rw text-name? string | | +--:(binary-name) | | +--rw binary-name? binary | +--rw security-name snmp:security-name | +--rw engine-id? snmp:engine-id | +--rw context? snmp:context-name | +--rw target-tag? snmp:identifier +--rw vacm | +--rw group* [name] | | +--rw name group-name | | +--rw member* [security-name] | | | +--rw security-name snmp:security-name | | | +--rw security-model* snmp:security-model Lin & Xia Expires May 3, 2018 [Page 11] Internet-Draft Network Device Management Plane Security October 2017 | | +--rw access* [context security-model security-level] | | +--rw context snmp:context-name | | +--rw context-match? enumeration | | +--rw security-model snmp:security-model-or-any | | +--rw security-level snmp:security-level | | +--rw read-view? view-name | | +--rw write-view? view-name | | +--rw notify-view? view-name | +--rw view* [name] | +--rw name view-name | +--rw include* snmp:wildcard-object-identifier | +--rw exclude* snmp:wildcard-object-identifier +--rw usm | +--rw local | | +--rw user* [name] | | +--rw user-params | +--rw remote* [engine-id] | +--rw engine-id snmp:engine-id | +--rw user* [name] | +--rw user-params +--rw tsm +--rw use-prefix? boolean The structure of "user-params" is: grouping: user-params +--rw user-params +--rw name snmp:identifier +--rw auth! | +--rw (protocol) | +--:(md5) | | +--rw md5 | | +-- rw key yang:hex-string | +--:(sha) | +--rw sha | +-- rw key yang:hex-string +--rw priv! +--rw (protocol) +--:(des) | +--rw des | +-- rw key yang:hex-string +--:(aes) +--rw aes +-- rw key yang:hex-string Lin & Xia Expires May 3, 2018 [Page 12] Internet-Draft Network Device Management Plane Security October 2017 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. The SSH security grouping and TLS security grouping defined in section Section 5.1.1 are reused. submodule: netconf-management-security +--rw netconf-management-security +--rw listen {listen}? | +--rw endpoint* [name] | +--rw name string | +--rw (transport) | +--:(ssh) {ssh-listen?} | | +--rw ssh-security-params | +--:(tls) {tls-listen?} | +--rw netconf-tls-security-params +--rw call-home {call-home}? +--rw netconf-client* [name] +--rw (transport) +--:(ssh) {ssh-call-home}? | +--rw ssh-security-params +--:(tls) {tls-call-home}? +--rw tls-security-params The structure of "netconf tls-security-params" is: grouping: tls-security-params +--rw tls-security-params +--rw certificates | +--rw certificate* [name] | +--rw name? leafref +--rw client-auth | +--rw pinned-ca-certs? -> /ks:keystore/pinned-certificates/name | +--rw pinned-client-certs? -> /ks:keystore/pinned-certificates/name | +--rw cert-maps {cert-maps-function}? | +--rw cert-to-name* [id] | +--rw id uint32 | +--rw fingerprint x509c2n:tls-fingerprint | +--rw map-type identityref | +--rw name string +--rw hello-params {tls-server-hello-params-config}? +--rw tls-versions | +--rw tls-version* identityref +--rw cipher-suites +--rw cipher-suite* identityref Lin & Xia Expires May 3, 2018 [Page 13] Internet-Draft Network Device Management Plane Security October 2017 The above structure combines the "tls-server-grouping" defined in [I-D.ietf-netconf-tls-client-server] with "cert-maps" defined in [RFC7407]. 5.3. Log Security Logs record information such as user operations on devices and device running status. Stored as log files on devices, logs help network administrators monitor the running status of routers and diagnose network faults. The log records can be outputted to console, or stored locally, or outputted to remote Syslog server. The following defined "log-security" module reuses the security related submodules of [I-D.ietf-netmod-syslog-model], and adds access control for locally stored log files. Lin & Xia Expires May 3, 2018 [Page 14] Internet-Draft Network Device Management Plane Security October 2017 module:log-security +--rw log-security +--rw (log-mode) +--:(file)? | +--rw user-level-for-read uint8 +--:(remote)? ... +--rw (transport) | ... | +--:(tls) | +--rw tls | +--rw server-auth | | +--rw trusted-ca-certs? -> /ks:keystore/trusted-certificates/name | | +--rw trusted-server-certs? -> /ks:keystore/trusted-certificates/name | +--rw client-auth | | +--rw (auth-type)? | | +--:(certificate) | | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name | +--rw hello-params {tls-client-hello-params-config}? | | +--rw tls-versions | | | +--rw tls-version* identityref | | +--rw cipher-suites | | +--rw cipher-suite* identityref | +--rw address? inet:host | +--rw port? inet:port-number +--rw signing-options! {signed-messages}? +--rw cert-signers +--rw cert-signer* [name] | +--rw name string | +--rw certificate? -> /ks:keystore/keys/key/certificates/certificate/name | +--rw hash-algorithm? enumeration +--rw cert-initial-repeat? uint32 +--rw cert-resend-delay? uint32 +--rw cert-resend-count? uint32 +--rw sig-max-delay? uint32 +--rw sig-number-resends? uint32 +--rw sig-resend-delay? uint32 +--rw sig-resend-count? uint32 5.4. File Security Patches, packages, configuration files are critical system files for network infrastructure devices. To provide security, only users under certain security levels are allowed to access these files, but cannot delete or modify them. For configuration files, only users with certain configuration rights can modify them. Lin & Xia Expires May 3, 2018 [Page 15] Internet-Draft Network Device Management Plane Security October 2017 module:file-security +--rw file-security +--rw (file-operation) +--:(local) | +--rw user-level-for-execute uint8 | +--rw (file-type) | +--:(patch) | | +--rw patch-integrity-check boolean | | +--rw integrity-alg identityref | +--:(package) | | +--rw package-integrity-check boolean | | +--rw integrity-alg identityref | +--:(configuration-file) | +--rw user-level-for-modify uint8 +--:(remote-transfer) +--rw (transfer-channel) +--:(ftp) | +--rw ftp-enable boolean | +--rw ftp-server-port inet:port-number | +--rw ftp-source-ip inet:host | +--rw ftp-source-port inet:port-number | +--rw acl*? [acl-name acl-type] | +--rw acl-name string | +--rw acl-type acl:acl-type +--:(sftp) | +--rw sftp-enable boolean | +--rw sftp-server-port inet:port-number | +--rw ssh-security-params +--:(scp) | +--rw scp-enable boolean | +--rw scp-server-port inet:port-number | +--rw ssh-security-params +--:(ftps) +--rw ftps-enable boolean +--rw ftps-server-port inet:port-number +--rw tls-security-params 6. Network Infrastructure Device Security Baseline Yang Module TBD 7. Acknowledgements 8. IANA Considerations This document requires no IANA actions. Lin & Xia Expires May 3, 2018 [Page 16] Internet-Draft Network Device Management Plane Security October 2017 9. Security Considerations TBD 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-00 (work in progress), July 2017. [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.ietf-netconf-netconf-client-server] Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client and Server Models", draft-ietf-netconf-netconf-client- server-04 (work in progress), July 2017. [I-D.ietf-netconf-ssh-client-server] Watsen, K. and G. Wu, "SSH Client and Server Models", draft-ietf-netconf-ssh-client-server-03 (work in progress), June 2017. [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-04 (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-14 (work in progress), October 2017. [I-D.ietf-netmod-syslog-model] Wildes, C. and K. Koushik, "A YANG Data Model for Syslog Configuration", draft-ietf-netmod-syslog-model-17 (work in progress), September 2017. Lin & Xia Expires May 3, 2018 [Page 17] Internet-Draft Network Device Management Plane Security October 2017 [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-00 (work in progress), September 2017. [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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Authors' Addresses Qiushi Lin Huawei Huawei Industrial Base Shenzhen, Guangdong 518129 China Email: linqiushi@huawei.com Lin & Xia Expires May 3, 2018 [Page 18] Internet-Draft Network Device Management Plane Security October 2017 Liang Xia Huawei 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: Frank.xialiang@huawei.com Lin & Xia Expires May 3, 2018 [Page 19]