[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

I2RS working group                                              S. Hares
Internet-Draft                                                    Huawei
Intended status: Informational                          January 19, 2017
Expires: July 23, 2017


      I2RS Revision to Yang Module Security Considerations Section
                 draft-hares-i2rs-yang-sec-consider-00

Abstract

   This document suggests changes to the yang security considerations
   section for yang module draft supporting the I2RS protocol security
   requirements.

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 http://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 July 23, 2017.

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
   (http://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Hares                     Expires July 23, 2017                 [Page 1]


Internet-Draft      I2RS Yang Security Consideration        January 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Basic Yang Security Considerations versus I2RS Yang Security
       Considerations  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Mandatory to implement transport layer  . . . . . . . . .   4
       2.1.1.  Mandatory to implement NETCONF Transport Layer  . . .   6
       2.1.2.  Mandatory to implement RESTCONF Transport Layer . . .   6
       2.1.3.  Mandatory to implement I2RS Transport Layer . . . . .   6
       2.1.4.  Change to Security Considerations for Mandatory
               Transport Layer . . . . . . . . . . . . . . . . . . .   7
     2.2.  Priority and Opaque Secondary Identity  . . . . . . . . .   7
       2.2.1.  TLS User-Id Formats . . . . . . . . . . . . . . . . .   8
       2.2.2.  I2RS use of priority  . . . . . . . . . . . . . . . .   8
     2.3.  I2RS Yang Models Exist in I2RS Ephemeral DataStores . . .   9
       2.3.1.  Security Considerations for Datastore Interactions  .  11
     2.4.  Different Validations . . . . . . . . . . . . . . . . . .  13
     2.5.  Different NACM Policy . . . . . . . . . . . . . . . . . .  13
     2.6.  Optional Insecure Protocol  . . . . . . . . . . . . . . .  14
   3.  I2RS YANG Model Security Explanation  . . . . . . . . . . . .  15
     3.1.  Basic YANG Model Security Considerations  . . . . . . . .  15
     3.2.  I2RS YANG Model Security Considerations . . . . . . . . .  15
   4.  Revised Security Considerations Template for I2RS Yang
       Modules . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     4.1.  Basic YANG Model Security Considerations  . . . . . . . .  17
     4.2.  I2RS Yang Models for Secure-Only transports . . . . . . .  17
     4.3.  I2RS Data Sent Across Insecure Transport  . . . . . . . .  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   This document proposes language for the the security consideration
   section for Yang modules from the I2RS Working group which utilize
   the I2RS protocol enhancements to the NETCONF/RESTCONF.  The I2RS
   protocol enhancement to the NETCONF/RESTCONF protocol must meet the
   protocol security requirements established in
   [I-D.ietf-i2rs-protocol-security-requirements], and the environment
   requirements set in [I-D.ietf-i2rs-security-environment-reqs].

   [I-D.ietf-netmod-revised-datastores] desribes a revised network
   management datastore structure for management configuration data
   stores used for configuration and operational state.  Within this



Hares                     Expires July 23, 2017                 [Page 2]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   context, the I2RS protocol is a control plane protocol which creates
   a control-plane datastore separate from the NETCONF/RESTCONF
   configuration datastores which are write-able (candidate, running,
   and startup datstores) or expanded uninstalled configuration
   (intended datastores).  The I2RS protocol creates the I2RS ephemeral
   datastore which is one of the control plane datastores.  Any I2RS
   protocol implementation merges the control plane datastore with the
   processed intended datastore (removing missing resources or delays)
   to create the applied datastore.  The I2RS ephemeral datastore is
   defined by the YANG data modeling language augmenting to support the
   I2RS protocol's control plane ephemeral datastore.

   The I2RS YANG data models exist in the I2RS ephemeral control plane
   datastore.  Some I2RS Yang Models exist only within the I2RS
   protocol's ephemeral control plane datastore.  Some YANG models which
   augment configuration datastore and operational state modules.  These
   I2RS YANG data models may augment YANG models for system functions
   (e.g. interface Yang model), routing information models (RIBS),
   routing protocol models, or network management protocol.  I2RS YANG
   models MAY import data from the routing system (e.g.  OSPF state
   topology models for L3).

   The format of this document is:

   o  section 2 - compares I2RS protocol security requirements with
      requirements describe in yang module security considerations found
      at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.

   o  section 3 - suggests new Explanatory text for Yang module security
      considerations for I2RS yang modules, and

   o  section 4 - suggests a new template for Security Considerations
      section for any I2RS yang module or any module based on an I2RS
      yang module.

2.  Basic Yang Security Considerations versus I2RS Yang Security
    Considerations

   The I2RS mandatory-to-implement protocol security features are
   different than the basic NETCONF [RFC6241] mandatory-to-implement
   features or RESTCONF mandatory-to-implement features
   [I-D.ietf-netconf-restconf] in the following way:

   o  different mandatory transport features,

   o  I2RS Protocol supports a priority and secondary opaque associated
      with each Peer Identity,




Hares                     Expires July 23, 2017                 [Page 3]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   o  I2RS Yang Models exist in control plane data stores rather than in
      the configuration data stores,

   o  Different validation processes,

   o  different NACM policies,

   o  optional non-secure transport can be used for a restricted set of
      non-confidential data that does not have privacy issues.

2.1.  Mandatory to implement transport layer

   NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf] utilize
   secure transports to establish a session between a server on a
   network node and a client (often on a end-system).  The secure
   transport layer in these two protocol is a lower layer than the
   application layer exchange between the server and client.  Figure 1
   provides shows how NETCONF, RESTCONF, and I2RS start their transport
   connections (1a or 1b), establish secure connections (2a or 2b), and
   send messges between a client and an NETCONF/RESCONF or I2RS agent.































Hares                     Expires July 23, 2017                 [Page 4]


Internet-Draft      I2RS Yang Security Consideration        January 2017


    NETCONF server           NETCONF client
    RESTCONF Servers         RESTCONF client
    I2RS Agent               I2RS Client

     <--(1a)--TCP--------   client starts
     ---(1b)---TCP--->      call-home service

     <--(2a)--TLS X.509v3 --- NETCONF, RESTCONF,
                                 I2RS protocol

     <  (2b)--SSH ------   (NETCONF only )

     <--(3a)--rpc/rpc-reply--: NETCONF messagese
                 rpc-error    (get-config, edit-config,
                               lock, unlock, close-session,
                               kill-session)

     <--(3b)---http----  RESTCONF (messages)
                            (OPTIONS, HEAD, POST
                             PUT,PATCH, DELETE,
                             Event-streams]

     <--(3c)--rpc/rpc-reply --I2RS Protocol
                          (NETCONF-like messages)
                          [open-session priority]
                          [open transport transport-id]
                          [get-data I2RS-datastore]
                          [get-state I2RS-datastore]
                          [write-data I2RS-datastore]
                          [notify I2RS-datastore]
                          [action I2RS-datastore]
                          [close-transport transport-id]
                          [close-session]


   <--(3d)--http -----I2RS Protocol
                        [RESTCONF-like messages]
                        [OPTIONS, HEAD, GET
                        POST [datastore | Data | Operation]
                        PUT [datastore | Data ]



   Note, in the drawing above, the I2RS agent features MAY utilize the
   NETCONF server methodology with different protocol commands (get-
   data, get-state, write-data, notify, action) which can be directed at
   a particular datastore.




Hares                     Expires July 23, 2017                 [Page 5]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   Similarily, the RESTCONF methodology can be augmented with different
   commands to reference the I2RS datastore.

   This section reviews the manadatory to implement secure transport
   layer for NETCONF, RESTCONF, and I2RS protocol.  For NETCONF, the
   I2RS agent features utilizes the NETCONF server functions, but allows
   multiple trasnports between the I2RS Client and I2RS Agent.  For
   RESTCONF, the I2RS agent features utilize the RESTCONF server
   functions.  Based on this review, it suggest I2RS Yang modules must
   utilize a TLS connection with X.509v3.

2.1.1.  Mandatory to implement NETCONF Transport Layer

   NETCONF's [RFC6241] mandatory-to-implement transport (SSH) [RFC6242]
   augmented by NETCONF's access control module [RFC6536] provides
   security for Data passed via NETCONF.  NETCONF allows user to run
   NETCONF over TLS using X.509 authentication [RFC7589] which mandates
   support for of TLS 1.2 [RFC5246] with its mandatory-to-implement
   Cipher suite ("TLS_RSA_WITH_AES_CBC_SHA"), and suggests implementers
   abide by recommendations in [RFC7525].

2.1.2.  Mandatory to implement RESTCONF Transport Layer

   RESTCONF [I-D.ietf-netconf-restconf] MUST operate over HTTP over the
   TLS using TLS [RFC7230] [RFC5246] with the https URI scheme with port
   443.  RESTCONF server MUST present an X.509v3 based certificate when
   establishing a connection with an RESTCONF Client.  The RESTCONF use
   of X.509v3 certifications is consistent with NTECONF use of X.509
   ceritifications.

2.1.3.  Mandatory to implement I2RS Transport Layer

   The I2RS protocol security requirements
   [I-D.ietf-i2rs-protocol-security-requirements] require I2RS Yang
   modules to be accessed peer [identity] authentication,
   confidentiality, data integrity, and [practical] replay protection
   for I2RS messages" and support "mechanism that mitigate DoS attacks"
   and "DDos prevention" SEC-REQ-01 to SEC-REQ-05, SEC-REQ-09 to SEQ-
   REQ-11).  The I2RS client and I2RS Agent MUST use mutual peer
   authentication based on unique identifier (see SEC-REQ-01, SEC-REQ-
   02, SEC-REQ-03).

   The I2RS transport layer transport protocol "MUST be associated with
   a key management system that guarantees that only the entities having
   sufficient privileges can get the keys to encrypt/decrypt the
   sensitive data" (see SEC-REQ-12).  The transport protocol the I2RS
   messages are passed over MUST be able to support multiple transport
   between the I2RS client and I2RS Agent, but a single connection



Hares                     Expires July 23, 2017                 [Page 6]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   between I2RS client and I2RS Agent MAY elect to use one transport
   (SEC-REQ-14).

   The security association between an I2RS Agent and I2RS client
   continues even when a secure transport connections (TLS over TCP)
   exists.  Therefore, all I2RS clients receiving a message over a
   secure connection to an I2RS agent MUST confirm that the I2RS agent
   has a valid identifier (SEC-REQ-05) and all I2RS agents recieving a
   messages over a secure connection from an I2RS client MUST confirm
   that the I2RS client has a valid identity (SEC-REQ-04).

   According to [I-D.ietf-taps-transports], the secure transport
   protocols which support peer authentication, confidentiality, data
   integrity, and replay protection are the following:

   1.  TLS [RFC5246] over TCP or SCTP,

   2.  DTLS over UDP with replay detection and anti-DoS stateless cookie
       mechanism required for the I2RS protocol, and the I2RS protocol
       allow DTLS options of record size negotiation and and conveyance
       of "don't" fragment bits to be optional in deployments.

   3.  HTTP over TLS (over TCP or SCTP), and

   4.  HTTP over DTLS (with the requirements and optional features
       specified above in item 2).

2.1.4.  Change to Security Considerations for Mandatory Transport Layer

   Based on these additional requirements, the mandatory-to-implement
   NETCONF transport for I2RS Yang modules is NETCONF over TLS with
   Mutual X.509 authentication [RFC7589] augmented by NETCONF's access
   control module.  The mandatory-to-implement RESTCONF transport for
   I2RS YANG Modules is HTTP over TLS with mutual X.509 authentication.

   This requirement should replace the existing requirement for the
   NETCONF transport of SSH [RFC6242] in the Yang modules.

2.2.  Priority and Opaque Secondary Identity

   The I2RS protocol security requirements require that a priority and a
   secondary opaque identifier be associated with the primary I2RS
   identifier (client or agent) (see SEC-REQ-07 and SEC-REQ-08).  In
   NETCONF the X.509v3 identity which is used for mutual authentication,
   becomes a NETCONF user name.  NETCONF links a NTECONF user name to a
   NETCONF group.  Network access control policy
   [I-D.ietf-netconf-rfc6536bis] is associated with this user name for
   the configuration datastore.  In RESTCONF, the X.509v3 identity used



Hares                     Expires July 23, 2017                 [Page 7]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   for mutual authentication, becomes a RESTCONF user name.  Similar to
   NETCONF the RESTCONF user name links to a RESTCONF user name.
   RESTCONF network access policy MAY link the RESTCONF user name to
   group identifier to apply NACM policy.

   I2RS protocol links the X.509v3 identity which is used for X.509v3
   mutual identification to a I2RS user identity (user-id) on the I2RS
   agent.  Associated with the I2RS user-id is one priority per security
   session, one secondary identifier per protocol transaction (NETCONF
   or RESTCONF), and multiple transport sessions.  The I2RS user-id
   links to a policy-id that can be utilized to set NAMCs on transports
   sessions or secondary identifiers, or other constraints.

   This section describes the format of these user identifiers in
   X.509v3 use, and how I2RS uses the priority associated with the I2RS
   user-id.

2.2.1.  TLS User-Id Formats

   NETCONF over TLS with Mutual X.509 authentication [RFC7589] requires
   that the NETCONF server keep a order list of mapping of certificates
   to that the X.509v3 certification is mapped to a NETCONF user name.
   The mapping requires keeping ordered list of these mappings with each
   list entry containing the following:

   o  certificate fingerprint,

   o  map type (specified, san-rfc822-name, san-dns-name, san-ip-
      adderss, san-any, common-nam), and

   o  optional auxillary data.

   The map type "specified" indicates the NETCONF username is specified
   in the auxilary data.  The map types begining with "san-..." indicate
   the user name is found in the subjectAltName and take a particular
   form (rfc822-name, dns-name, ip-address) or anyone of these forms
   (san-any).  The common-nam map type indicates CommonName is mapped to
   the user name after being converted to UTF-8.

   In a similar fashion, the I2RS will utilize user name found in the
   formats as an I2RS identity.

2.2.2.  I2RS use of priority

   The I2RS data models define some data models which MUST exist within
   the I2RS protocol's ephemeral datastore (e.g.  I2RS Ephemeral Data
   Store, I2RS Protocol), and some which MAY exist (e.g. protocol
   independents models or modules which augment routing protocol



Hares                     Expires July 23, 2017                 [Page 8]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   modules).  The YANG Modules which define state in the I2RS Control
   plane data store may have both configuration state and operational
   state.  The I2RS Data Models installed in an I2RS ephemeral state
   data MUST be able to be read by multiple I2RS Clients (if security
   network access policies allow it) and written by one I2RS Client at a
   time.  If multiple I2RS client attempt to write the same I2RS data,
   it is considered an operational error situation (which causes I2RS
   agent to notify both client's about if security policies allow).  To
   resolve these contentions, a priority scheme is used.  The link
   between the I2RS client identity and the priority must be established
   before the I2RS Client makes write changes to the I2RS Agent.  The
   client identity's link to a priority controls multiple write access
   rather than mutual identification.

   How does the I2RS security requirement for a single to user to have
   only one priority (SEC-REQ-07) and one secondary opaque identifier
   (SEC-REQ-08) impact the security of I2RS Yang Data Models?

   The client priority allows the I2RS agent to select which I2RS client
   has priority when multiple I2RS clients try to write the same data
   node in an I2RS ephemeral control plane datastore.  This priority
   resolution of multiple writes occurs after both I2RS clients are
   allowed to have network access (policy set by NACM
   [I-D.ietf-netconf-rfc6536bis]) to a data model.  Therefore, the
   security considerations of the I2RS YANG Data models do not have to
   consider priority contention.  The secondary opaque associated for
   the period of a I2RS protocol operation only provides tracing
   capability to determine what happened.

2.3.  I2RS Yang Models Exist in I2RS Ephemeral DataStores

   The I2RS protocol is a higher layer protocol encourages which reuses
   other IETF protocols (NETCONF/RESTCONF) and modeling language (YANG),
   but modifies these protocols (NETCONF/RESTCONF) and the modeling
   language to support the required features.  Figure 2 provides a
   diagram of how I2RS ephemeral configuration state ("config=true"
   nodes), and I2RS operational state nodes ("config=false" nodes) which
   are part of the I2RS Control Plane Ephemeral datastore interact with
   datastores in the updated IETF management datastore model
   [I-D.ietf-netmod-revised-datastores], and not a part of the
   configuration datastore.  The I2RS protocol implementation merges the
   I2RS ephemeral datastore with currently appplied datastore.









Hares                     Expires July 23, 2017                 [Page 9]


Internet-Draft      I2RS Yang Security Consideration        January 2017


     +-------------+                 +-----------+
     | [candidate] |                 | [startup] |
     |  (ct, rw)   |%lt;---+       +---%gt;| (ct, rw)  |
     +-------------+    |       |    +-----------+
            |           |       |           |
            |         +-----------+         |
            +--------%gt;| [runnin] |<--------+
                      | (ct, rw)  |
                      +-----------+
                            |
                            |        // e.g., removal of 'inactive'
                            |        // nodes, expansion of templates
                            v
                      +------------+
                      | [intended] | // subject to validation
                      | (ct, ro)   |
                      +------------+
                            |
                            |        // e.g., missing resources or
                            |        // delays
                            v
                      +-----------+
                      | [applied] |<---+--- dynamic configuration
                      | (ct, ro)  |    |      protocols
                      +-----------+    +--- control-plane datastores
                            |               +---I2RS ephemeral datastore
                            |               +---BGP ephemeral configuration
                            |                   (Flow Specification filters)
                            |
                            |          +--- auto-discovery
                            |    +-----+--- control-plane protocols
                            |    |     +--- control-plane datastores
                            |    |          +---I2RS operational state
                            |    |          +---BGP operational state
                            |    |            (Flowspec filters)
                            |    |
                            v    v
                  +---------------------+
                  | [operational-state] |
                  | (ct + cf, ro)       |
                  +---------------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     boxes denote datastores

         Figure 2 - modified from NETMOD Revised datastores
                    (draft-ietf-netmod-revised-datastores-00.txt)



Hares                     Expires July 23, 2017                [Page 10]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   The I2RS ephemeral datastore is a control plane datastore which
   contains configuration data ("config=true") which does not persist
   over a reboot.  The I2RS datastore may only be one of the ephemeral
   configuration datastores.  The I2RS protocol creates, reads, writes,
   updates, deletes, notifies, signals events, performs actions,and
   traces (CRUD-NEAT) the data in the I2RS ephemeral datastore.  The
   I2RS protocol mechanisms validate the I2RS ephemeral datastore
   values.  If a routing system reboots, the information in an I2RS
   ephemeral datastore does not persist across the reboot.

2.3.1.  Security Considerations for Datastore Interactions

   An I2RS protocol implementation applies this configuration to a
   routing system which will also have basic IP routing functions (e.g.
   interfaces, IP address, routing), system management functions (e.g.
   syslog), and security functions (e.g. keystore, keychain, Network
   Access Control Management (NACM)).  The I2RS implementation is
   required to have configuration knobs that will specify how the
   intended configuration is validated, checked, and merged with the
   I2RS ephemeral configuration state.  If a system with I2RS protocol
   implementation also has dynamic configuration protocols (e.g. dhcp)
   or other control plane configuraton protocols (e.g.  BGP Flow
   Specification filters passed in the BGP protocol, but defined to be
   installed as ephemeral state in the routing system), then the
   implementation must have configuration knobs and policy to merge the
   configuration (that is "config=true") data modules in a known manner.
   The applied configuration state stored by system must be able to
   identify which datastore (intended, dynamic configuration protocol
   datastore, I2RS ephemeral control-plane datastore) installed each
   piece of configuration in the running system.

   Similar to NETCONF or RESTCONF configuration data stores (candidate,
   running, start-up, intended, and applied), some writable data nodes
   in a Yang Data Model that could be especially disruptive if abused.
   These data nodes MUST Be explicitly listed by name and the associated
   security risks MUST be spelled out.  In addition, some writable data
   nodes in an I2RS ephemeral configuration could cause problems with
   nodes if: data models have write or read/write scoped data which can
   cause security threats by:

   o  I2RS ephemeral data read by the user could cause a security
      threats

   o  overwriting NETCONF/RESTCONF configuration with I2RS ephemeral
      control plane configurations could cause network security risks or
      Denial of Service (DoS),





Hares                     Expires July 23, 2017                [Page 11]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   o  fluctuating between I2RS ephemeral configuration datastore data
      and other control plane datastores could cause security risks or
      denial of service (DoS),

   o  I2RS ephemeral configuration overwriting dynamic configuration
      protocol configuration (e.g. dhcp leases) could cause security
      risks or denial of service attacks (DoS), or fluctuation between
      I2RS ephemeral control plane confguration and dynamic
      configuration control plane could cause problems.

   I2RS data models containing I2RS ephemeral configuration which might
   cause these problems should provide this information in the security
   considerations section.

   Operational state contains all configured data used by the system
   ("config=true" nodes) and applied configuration and operational state
   as read-only data.  Operational state data does not persist across a
   reboot of the routing system, but is regenerated.  This requirement
   to regenerate data requires the I2RS protocol to reload any
   operational state it regenerates.

   The I2RS protocol implementations MUST support I2RS Yang models which
   define operational state.  System-wide operational state may come
   from auto-discovery, control plane protocols (e.g.  BFD, BGP), or
   control plane datastores such as the I2RS Ephemeral Control Plane
   Datastore.  The I2RS protocol implementation must extend the read of
   operational state so that the operational data may get all
   operational data, or data specific to the I2RS operational data.

   I2RS ephemeral data store, similar to NETCONF/RESTCONF operational
   state, may have read-only data in the each ephemeral configuration
   datastore or the ephemeral operational datastores that contains
   especially sensitive information or that raise significant privacy
   concerns.  It is important that the security section MUST be
   explicitly listed this data by name and the reasons for the
   sensitivity/privacy concerns MUST be explained.

   I2RS ephemeral datastores may overwrite with ephemeral data sensitive
   information stored in NETCONF/RESTCONF configuration datastores or
   operational datastores.  This overwriting may decrease the concerns
   for sensitivity/privacy of the information or increase it.  The
   ovewriting and the policy that controls it must be explained in the
   I2RS Yang Data Model.








Hares                     Expires July 23, 2017                [Page 12]


Internet-Draft      I2RS Yang Security Consideration        January 2017


2.4.  Different Validations

   The I2RS protocol is to designed to operate on top of the operates on
   top of the TLS connection using modified network management protocols
   (NETCONF, RESTCONF, and others ) to:

   o  create, read, update, delete ephemeral configuration data within
      the I2RS ephemeral data store (CRUD)

   o  to notify the I2RS client when an event occurs in the I2RS Agent,
      or the I2RS agent when an event occurs as part of a subscription
      servic,

   o  signal the occurrence of individual events (I2RS agent to I2RS
      client or I2RS client to I2RS agent),

   o  act if a action is request (e.g. rpc),

   o  trace information

   (These can be summarizes as CRUD-NEAT operations).

   The validation for these processes is specific to the I2RS protocol
   so the validations will be different, but defined in the I2RS
   protocol.  Therefore, the security considerations will need to
   consider any differences in I2RS protocol features.

2.5.  Different NACM Policy

   The expanded NETCONF NACM [I-D.ietf-netconf-rfc6536bis] proposes
   changes to the NACM procedure so that it focuses on:

   o  Permission to invoke specific protocol operations,

   o  Permission to read and/or alter specific data nodes within any
      datastore,

   o  Permission to receive specific notification event types.

   The NETCONF NACM is based on a netconf group's permissions where each
   netconf user identifier is linked to 1 or more group permissions.
   NETCONF which runs over TLS with X.509v3 services [RFC7589] passes a
   name which becomes the netconf user name.  As described above the
   I2RS protocol also a user name which becomes the I2RS usser
   identifier (user-id) The I2RS user-id may be mapped to different NACM
   policy based on a I@RS protocol implementation and the I2RS protocol
   features.




Hares                     Expires July 23, 2017                [Page 13]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   An I2RS protocol implementation also interacts with the following
   systems to import/export data: to the following:

      routing system (defined as Routing Access Control Management
      (RACM)),

      host system functions (defined as System Access control Management
      (SACM),

   NACM policy for I2RS protocol will need to be augment by this RACM
   and SACM policy.  A security consideration section should discuss
   these issues.

2.6.  Optional Insecure Protocol

   The I2RS protocol allow an implementation of I2RS protocol (NETCONF
   or RESTCONF) to optionally support of an insecure transport as well
   as a secure transport if a set of mandatory constraints are met.  of
   the following constraints are met:

   o  the content that is suitable for insecure transport (see SEC-REQ-
      06),

   o  Yang models with non-confidential data must provide an indication
      that non-confidential data exists within the model in a machine
      readable form.  A non-secure transport may be used to publish only
      read scope data or notification scope data if the associated data
      model indicates the data is non-confidential (see SEC-REQ-13),

   o  The I2RS protocol makes use of both secure and insecure
      transports, but this use MUST NOT be done in any way that weakens
      the secure transport protocol used in the I2RS protocol or other
      contexts that do not have this requirement for mixing secure and
      insecure modes of operation (SEC-REQ-16)

   o  The I2RS higher-layer protocol MUST provide a mechanism for
      message traceability (requirements in [RFC7922]) that supports the
      tracking higher-layer functions run across secure connection or a
      non-secure transport (SEC-REQ-19).

   Any I2RS Data model proposing to transmit a portion of the data over
   an insecure transport MUST provide a section of security
   considerations that explains how these constraints are net.








Hares                     Expires July 23, 2017                [Page 14]


Internet-Draft      I2RS Yang Security Consideration        January 2017


3.  I2RS YANG Model Security Explanation

   Any security consideration section for an I2RS YANG data model must
   contain the following sections:

   o  Basic Yang Module Data considerations - relating to sensitive
      writeable nodes, sensitive read-able nodes, sensitive rpc
      operations),

   o  I2RS related Yang Model considerations - relating to mandatory
      transport, I2RS use of priority and opaque secondary identity,
      validation of I2RS protocol operations, NACM interactions in a
      multiple datastore (config + I2RS control plane datastore), and
      use of optional insecure data.

   This section provide an overview of what goes in each of these two
   sections.  Section 4 provides abbrev template for this information.

3.1.  Basic YANG Model Security Considerations

   Each specification that defines one or more YANG modules MUST contain
   a section that discusses security considerations relevant to those
   modules.  The following data usage must be explained in the security
   consideratinon section:

   1.  If any writable data nodes that could be especially disruptive if
       abused, then these nodes MUST be explicitly listed by name and
       the associated security risks MUST be spelled out.

   2.  If any readable data nodes that contain especially sensitive
       information or that raise significant privacy concerns, then
       these data nodes MUST be explicitly listed by name and the
       reasons for the sensitivity/privacy concerns MUST be explained.

   3.  If any new RPC operations have been defined, then the security
       considerations of each new RPC operation MUST be explained.

3.2.  I2RS YANG Model Security Considerations

   The I2RS YANG Models is design to exists in the I2RS control plane
   ephemeral state.  Therefore, a security consideration section for an
   I2RS YANG Data Model must contain the following information:

      Mandatory requirement to run I2RS protocol over a TLS sesssion
      with X.509 mutual authentication whether I2RS protocol uses
      NETCONF-style messages or RESTCONF-style messages (I2RS protocol
      MUST not use NETCONF over SSH).




Hares                     Expires July 23, 2017                [Page 15]


Internet-Draft      I2RS Yang Security Consideration        January 2017


      Description of how multiple client write-contentions are resolved
      via I2RS priority linked to the I2RS user-id and how I2RS
      secondary identity may trace this.  It is important to provide
      operational insight how how I2RS secondary identity may change and
      how this will impact tracing.

      Validation of I2RS protocol operations may be new.  Any concerns
      with time delays or depth of validation, should be indicated.

      NACM policy for network access to an I2RS Ephemeral control plane
      datastore may be augmented by an access control method for routing
      protocols (RACM), system information (SACM), and an inter-
      datastore access (DACM).  A discussion how sensitive read
      information, write information, or I2RS actions are protected in
      the system.

      If a portion of the data model is available via a non-secure
      transport session, describe how the following restrictions are met

      *  content of data is suitable for insecure transport,

      *  YANG modules provide indication of non-confidential data in
         machine readable form,

      *  the YANG module's use of secure and insecure transport does not
         weaken the secure transport,

      *  the higher layer protocol MUST provide a mechnisms for message
         traceability.

4.  Revised Security Considerations Template for I2RS Yang Modules

   The YANG module defined in this draft is designed to be accessed via
   the I2RS control plane protocol and reside in the I2RS ephemeral
   control plane datastore that contains both configuration data and
   operational state.  I2RS ephemeral control plane datastore does not
   persist (that is does not keep data) across a system reboot.

   This consideration section for I2RS Yang Data Models contains three
   parts: basic YANG model considerations, I2RS ephemeral datstore
   considerations, and considerations for I2RS Yang Models with non-
   confidential data sent over an insecure session.  The basic model
   security considerations are common to all YANG modules whether the
   YANG modules belong to the configuration datastore, or control-plane
   datastores.

   Any I2RS Yang module is required to run the I2RS protocol over a TLS
   session with X.509v3 mutual authentication whether the I2RS protocol



Hares                     Expires July 23, 2017                [Page 16]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   uses NETCONF-style messages or RESTCONF-style messages.  The I2RS
   protocol implementation uses the name passed as the I2RS user
   identifier (user-id).  Write contention between two clients (with
   valid write permissions) attempting to write the same data node in a
   I2RS Yang data model is an operational error, but implementations
   should use the priority associated with each I2RS user-id to resolve
   it.  Tracing of such content resolution will be done by the system,
   and will include the opaque secondary identifier which indicates
   which applications are operationally contending.  Only one opaque
   secondary identifier is linked to a I2RS userid at a time, but the
   opaque secondary identifier may change multiple times during a
   security association.  The opaque secondary identifier may be passed
   during transport connection establishment as part of a write-action
   (write datastore where the datastore is I2RS).  All of these features
   are basic I2RS functionality, and not specific to any I2RS data
   model.

4.1.  Basic YANG Model Security Considerations

   What to put in this section: (Instructions to authors)

   Each specification that defines one or more YANG modules MUST contain
   a section that discusses security considerations relevant to those
   modules.  The following data usage must be explained in the security
   consideration.

   1.  If there is readable data nodes contain especially sensitive
       information or that raise significant privacy concerns, these
       nodes MUST be explicitly listed by name and the reasons for the
       sensitivity/privacy concerns MUST be explained.  One is example
       is if the data might reveal customer information or violate
       personal privacy laws (such as those of the European Union) if
       the data was sent via an unauthorized port.

   2.  If any writable data nodes that could be especially disruptive if
       abused, these writeable data nodes MUST be explicitly listed by
       name and the associated security risks MUST be spelled out.

   3.  If thre are any new RPC operations have been defined, then the
       security considerations of each new RPC operation MUST be
       explained.

4.2.  I2RS Yang Models for Secure-Only transports

   The I2RS YANG models may utilize new rpc commands for to access the
   I2RS ephemeral datastore which create, read, update, and delete data
   nodes; or notify a client of informatio, signal events, perform
   actions, and perform tracing (CRUD-NEAT) notifies, signals events.



Hares                     Expires July 23, 2017                [Page 17]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   Authors should provide a list of any new rpc commands and any
   security considerations regarding their use.

   NACM policy for network access to an I2RS Ephemeral control plane
   datastore may be augmented by an access control method for routing
   protocols (RACM), system information (SACM), and an inter-datastore
   access (DACM).

   Authors should provide a discussion of any data which is retrieved
   from the routing protocols in the control plane system, system
   information, or from anyother datastore (configuration, operational
   state, dynamic configuration protocols, auto-discovery, control-plane
   protocols).  Authors should discuss how fluctuation of the data
   retrieved from the routing protocols in control plane system, host
   system, or other datastores could impact data reliability or
   sensitive data nodes listed in the Basic Yang Module Security
   considerations.  This discussion SHOULD include suggested operational
   knobs that control the overlay of I2RS configuration data over
   configuration data or I2RS operation state over other types of
   operational state.

4.3.  I2RS Data Sent Across Insecure Transport

   I2RS YANG Modules may contain data which MAY be passed across a non-
   secure transport session as well as a secure transport.  Any I2RS
   YANG model sending allowing some data to be sent cross an non-secure
   transport MUST provide adhere to the following requirements:

   o  content of data model (e.g. nodes or subtrees) which is suitable
      for insecure transport,

   o  YANG modules provide indication of non-confidential data in
      machine readable form,

   o  how the YANG module's use of secure and insecure transport does
      not weaken the secure transport,

   o  How I2RS protocol provide a mechnisms for message traceability.

   Authors provide the following:

   o  a list of nodes in this YANG data model which MAY be passed across
      an insecure transport,

   o  How the YANG Module provides the indication of non-condidential
      data existing in the data model,





Hares                     Expires July 23, 2017                [Page 18]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   o  How access to the data is limited to reads of data nodes, or
      notifications sent.

   o  How the use of secure and insecure transport does not weaken the
      secure transport operationally in a deployment, and

   o  How traceability supports detecting any security intrusions for
      this data model.

5.  Security Considerations

   The document provides an updated YANG security considerations for
   I2RS data models.

6.  IANA Considerations

   No IANA considerations for this requirements.

7.  Acknowledgments

   Authors of the protocol security document, protocol security
   environment document, ADs (routing, security, OPS)

8.  References

8.1.  Normative References

   [I-D.ietf-i2rs-protocol-security-requirements]
              Hares, S., Migault, D., and J. Halpern, "I2RS Security
              Related Requirements", draft-ietf-i2rs-protocol-security-
              requirements-17 (work in progress), September 2016.

   [I-D.ietf-i2rs-security-environment-reqs]
              Migault, D., Halpern, J., and S. Hares, "I2RS Environment
              Security Requirements", draft-ietf-i2rs-security-
              environment-reqs-02 (work in progress), November 2016.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-18 (work in
              progress), October 2016.

   [I-D.ietf-netmod-revised-datastores]
              Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "A Revised Conceptual Model for YANG
              Datastores", draft-ietf-netmod-revised-datastores-00 (work
              in progress), December 2016.




Hares                     Expires July 23, 2017                [Page 19]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5264]  Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
              Partial Presence Information", RFC 5264,
              DOI 10.17487/RFC5264, September 2008,
              <http://www.rfc-editor.org/info/rfc5264>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <http://www.rfc-editor.org/info/rfc6242>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <http://www.rfc-editor.org/info/rfc6536>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7589]  Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
              NETCONF Protocol over Transport Layer Security (TLS) with
              Mutual X.509 Authentication", RFC 7589,
              DOI 10.17487/RFC7589, June 2015,
              <http://www.rfc-editor.org/info/rfc7589>.






Hares                     Expires July 23, 2017                [Page 20]


Internet-Draft      I2RS Yang Security Consideration        January 2017


   [RFC7920]  Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
              Statement for the Interface to the Routing System",
              RFC 7920, DOI 10.17487/RFC7920, June 2016,
              <http://www.rfc-editor.org/info/rfc7920>.

   [RFC7921]  Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
              <http://www.rfc-editor.org/info/rfc7921>.

   [RFC7922]  Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
              the Routing System (I2RS) Traceability: Framework and
              Information Model", RFC 7922, DOI 10.17487/RFC7922, June
              2016, <http://www.rfc-editor.org/info/rfc7922>.

   [RFC7923]  Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
              for Subscription to YANG Datastores", RFC 7923,
              DOI 10.17487/RFC7923, June 2016,
              <http://www.rfc-editor.org/info/rfc7923>.

8.2.  Informative References

   [I-D.ietf-i2rs-ephemeral-state]
              Haas, J. and S. Hares, "I2RS Ephemeral State
              Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in
              progress), November 2016.

   [I-D.ietf-netconf-rfc6536bis]
              Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", draft-ietf-
              netconf-rfc6536bis-00 (work in progress), January 2017.

   [I-D.ietf-taps-transports]
              Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
              provided by IETF transport protocols and congestion
              control mechanisms", draft-ietf-taps-transports-14 (work
              in progress), December 2016.

Author's Address

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com




Hares                     Expires July 23, 2017                [Page 21]


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