The Data Model of Network Infrastructure Device Management Plane Security Baseline
draft-lin-sacm-nid-mp-security-baseline-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qiushi Lin , Liang Xia | ||
| Last updated | 2018-03-01 (Latest revision 2017-10-30) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lin-sacm-nid-mp-security-baseline-02
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, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/info/rfc7407>.
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,
<https://www.rfc-editor.org/info/rfc2119>.
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,
<https://www.rfc-editor.org/info/rfc6020>.
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]