[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]



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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/