I2RS working group                                              S. Hares
Internet-Draft                                                    Huawei
Intended status: Informational                                D. Migault
Expires: February 20, March 12, 2017                                       J. Halpern
                                                                Ericsson
                                                         August 19,
                                                       September 8, 2016

                   I2RS Security Related Requirements
           draft-ietf-i2rs-protocol-security-requirements-09
           draft-ietf-i2rs-protocol-security-requirements-10

Abstract

   This presents security-related requirements for the I2RS protocol for
   which provides a new interface to the routing system described in the
   I2RS architecture document (RFC7921).  The I2RS protocol is a re-use
   protocol implemented by re-using portions of existing IETF protocols
   and adding new features to these protocols.  The I2RS protocol re-
   uses security features of a secure transport (E.g.  TLS, SSH, DTLS)
   such as encryption, message integrity, mutual peer authentication, transport protocols, data transfer
   and
   transactions. replay protection.  The new security features I2RS adds are: a
   priority mechanism to handle multi-headed write transactions, an
   opaque secondary identifier which identifies an application using the
   I2RS client, and an extremely constrained read-only non-secure
   transport.  This document provides the detailed requirements for
   these security features.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at 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 February 20, March 12, 2017.

Copyright Notice

   Copyright (c) 2016 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language   3
   2.  Definitions . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.1.   4
     2.2.  Security Definitions  . . . . . . . . . . . . . . . . . .   3
     2.2.   5
     2.3.  I2RS Specific Definitions . . . . . . . . . . . . . . . .   3   5
   3.  Security-Related Requirements  Security Features and Protocols: Re-used and New  . . . . . .   7
     3.1.  Security Protocols Re-Used by the I2RS Protocol . . . . .   7
     3.2.  New Security Features . . . . . . . . . . . .   5
     3.1.  Mutual authentication of an I2RS client and an I2RS Agent   5
     3.2.  Transport Requirements Based on Mutual Authentication . .   6 . . . .   8
     3.3.  Data Confidentiality  I2RS Protocol Security Requirements vs. IETF Management
           Protocols . . . . . . . . . . . .   7
     3.4.  Data Integrity . . . . . . . . . . . .   9
   4.  Security-Related Requirements . . . . . . . . . . . . . . .   8
     3.5. .  10
     4.1.  I2RS Peers(agent and client) Identity Authentication  . .  11
     4.2.  Identity Validation Before Role-Based Data Model Security Message Actions . .  12
     4.3.  Peer Identity, Priority, and Client Redundancy  . . . . .  12
     4.4.  Multi-Channel Transport: Secure Transport and Insecure
           Transport . . . . . . . .   8
     3.6. . . . . . . . . . . . . . . . .  14
     4.5.  Management Protocol Security of the environment  . . . . . . . . . . . . . .  16
     4.6.  Role-Based Data Model Security  . . .   9
   4.  Acknowledgement . . . . . . . . . .  17
     4.7.  Security of the environment . . . . . . . . . . . . .   9
   5.  IANA Considerations . .  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9  18
   6.  Security  IANA Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References . .  18
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative  18
   8.  References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References . . . . . . .  18
     8.1.  Normative References  . . . . . . . . . .  10
   Authors' Addresses . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . .  11 . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The Interface to the Routing System (I2RS) provides read and write
   access to information and state within the routing process.  An I2RS
   client interacts with one or more I2RS agents to collect information
   from network routing systems.

   This document  [RFC7921] describes the requirements for the I2RS protocol in the
   security-related areas architecture
   of mutual authentication this interface, and this documents assumes the reader is familiar
   with this architecture and its definitions.  Section 2 highlights
   some of the references the reader is required to be familiar with.

   The I2RS interface is instantiated by the I2RS protocol connecting an
   I2RS client and agent, the transport an I2RS agent associated with a routing system.  The
   I2RS protocol is a re-use protocol implemented by re-using portions
   of existing IETF protocols, and adding new features to these
   protocols.  As a re-use protocol, it can be considered a higher-level
   protocol carrying since it can be instantiated in multiple management
   protocols (e.g.  NETCONF [RFC6241] or RESTCONF
   [I-D.ietf-netconf-restconf]) operating over a secure transport.  The
   security for the I2RS protocol
   messages, and comes from the atomicity managmenet protocols
   operating over a a secure transport which carries traffic over
   multiple links.

   This document is part of the transactions.  These requirements
   align with the description of the for I2RS architecture found in
   [RFC7921] document protocol which solves the problem described in [RFC7920].

   [I-D.ietf-i2rs-ephemeral-state] discusses
   also include:

   o  I2RS architecture [RFC7921],

   o  I2RS role-based access
   control that provides write conflict resolution in the ephemeral data
   store using state requirements [I-D.ietf-i2rs-ephemeral-state],

   o  publication/subscription requirements [RFC7922], and

   o  traceability [RFC7923].

   Since the I2RS Client Identity, I2RS Secondary Identity and
   priority.  The draft [RFC7922] describes "higher-level" protocol changes the traceability framework
   and its interface to the
   routing systems, it is important that implementers understand the new
   security requirements for I2RS.  The draft [RFC7923] describes the environment the I2RS protocol operates
   in.  These secuirty requirements for the I2RS to be able to publish information or have a
   remote client subscribe to an information data stream.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document environment are to be interpreted as
   specified in [I-D.ietf-i2rs-security-environment-reqs], and the
   summary of the I2RS protocol security environment found in the I2RS
   Architecture [RFC7920].

   I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which
   support encryption, message integrity, peer authentication, and key
   distribution protocols.  Optionally, implementers may utilize AAA
   protocols (Radius over TLS or Diameter over TLS) to securely
   distribute identity information.

   Section 3 provides an overview of security features and protocols
   being re-used (section 3.1) and the new security features being
   required (section 3.2).  Section 3 also explores how existing and new
   security features and protocols would be paired with existing IETF
   management protocols (section 3.3).

   The new features I2RS extends to these protocols are a priority
   mechanism to handle multi-headed reads, an opaque secondary
   identifier to allow traceability of an application utilizing a
   specific I2RS client to communicate with an I2RS agent, and insecure
   transport constrained to be utilized only for read-only data which
   publically available data (e.g. public BGP Events, public telemetry
   information, web service available) and some legacy data.

   Section 4 provides the I2RS protocol security requirements by the
   following security features:

   o  peer identity authentication (section 4.1),

   o  peer identity validation before role-based message actions
      (section 4.2)

   o  peer identity and client redundancy (section 4.3),

   o  multi-channel transport requirements: Secure transport and
      insecure Transport (section 4.4),

   o  management protocol security requirements (section 4.5),

   o  role-based security (section 4.6),

   o  security environment (section 4.7)

   Protocols designed to be I2RS higher-layer protocols need to fulfill
   these security requirements.

2.  Definitions

2.1.  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 RFC 2119 [RFC2119].

2.  Definitions

2.1.

2.2.  Security Definitions

   This document utilizes the definitions found in the following
   documents: [RFC4949] and [RFC7921]

   Specifically, this document utilizes the following definitions from
   [RFC4949]:

   o  access control,

   o  Authentication,  authentication,

   o  Data Confidentiality,  data confidentiality,

   o  Data Integrity,  data integrity,

   o  Data Privacy,  data privacy,

   o  Identity,  identity,

   o  Identifier,  identifier,

   o  Mutual Authentication,  mutual authentication,

   o  role,

   o  role-based access control,

   o  security audit trail, and

   o  trust.

   [RFC7922] describes traceability for I2RS interface and the I2RS
   protocol.  Traceability is not equivalent to a security audit trail.

2.2. trail
   or simple logging of information.  A security audit trail may utilize
   traceability information.

   This document also requires that the user is familiar with the
   pervasive security requirements in [RFC7258].

2.3.  I2RS Specific Definitions

   I2RS component protocols

      Protocols which are combined to create

   The document utilizes the following concepts from the I2RS protocol.
   architecture: [RFC7921]:

   o  I2RS Higher-level protocol

      The client, I2RS agent, and I2RS protocol exists as a higher-level (section 2),

   o  I2RS higher-layer protocol which may
      combine other protocols (NETCONF, RESTCONF, IPFIX (section 7.2)
   o  scope: read scope, notification scope, and others)
      within a specific I2RS client-agent relationship with a specific
      trust for ephemeral configurations, event, tracing, actions, write scope (section
      2),

   o  identity and
      data flow interactions.  The protocols included in scope of the identity (section 2),

   o  roles or security rules (section 2),

   o  identity and scope, and secondary identity (section 2),

   o  routing system/subsytem (section 2),

   o  I2RS
      protocol protocol are defined as assumed security environment (section 4),

   o  I2RS component protocols.  (Note:
      Version 1 identity and authorization (section 4.1),

   o  I2RS authorization, scope of the Authorization in I2RS protocol will combine only NETCONF client and
      RESTCONF.  Experiments with other protocols such as IPFIX have
      shown these are useful to combine
      agent (section 4.2),

   o  client redundancy with NETCONF and RESTCONF
      features.)

   I2RS message

      is a complete data message of one of the single client identity (section 4.3),

   o  restrictions on I2RS component protocols.
      The in personal devices (section 4.4),

   o  communication channels and I2RS component protocols may require multiple IP-packets to
      send one high-layer protocol message.

   I2RS (section 7.2),

   o  active communication versus connectivity (section 7.5),

   o  multi-headed control (section 7.8), and

   o  transaction, message, multi-message atomicity

      An I2RS operation (read, write, event, action) must be contained
      within one I2RS message.  Each I2RS operation must be atomic.
      While it is possible to have an I2RS operation which is contained
      in multiple I2RS (E.g. write in multiple messages), this (section 7.9).

   This document assumes the reader is not
      supported in order to simplify familar with these terms.

   This document discusses the first version of I2RS.
      Multiple-message atomicity of I2RS operations would be used in a
      roll-back of a grouping security of commands (e.g. the multiple writes).

   I2RS transaction

      is a unit of I2RS functionality.  Some examples of
   communication channels which operate over the higher-layer I2RS
      transactions are:

      *
   protocol.  The higher-layer I2RS client issues a read request to protocol combines a secure transport
   and I2RS agent, contextual information, and re-uses IETF protocols and data
   models to create the secure transport and the I2RS Agent responding to data-model driven
   contextual information.  To describe how the read request

      *  The I2RS client issues a write of ephemeral configuration
         values high-layer protocol
   combines other protocols into an I2RS agent's data model, followed by the I2RS
         agent response to the write.

      *  An I2RS client may issue an action request, the I2RS agent
         responds to higher-layer protocol, the action-request, and then responds when action
         is complete.  Actions can be single step processes or multiple
         step process.

      *  An
   following terms are used:

   I2RS client requests to receive an event notification, component protocols

      Protocols which are re-used and
         the I2RS Agent sets up combined to send create the events.

      *  An I2RS agent sends events to an
      protocol.

   I2RS Client on an existing
         connection.

      An secure-transport component protocols
      The I2RS action may require multiple secure transport protocols that support the I2RS messages in order to
      complete a transation. higher-
      layer protocol.

   I2RS secondary identifier management component protocols

      The I2RS architecture document [RFC7921] defines a secondary
      identity as the entity of some non-I2RS entity (e.g. application) management protocol which has requested a particular provide the management
      information context.

   I2RS client perform an operation. AAA component protocols

      The I2RS secondary identifier represents this identity so it may
      be distinguished from all others.

   I2RS routing system

      Layer three (L3) routing systems which include physical routers,
      virtual routers (in hypervisors or load splitters), and other
      devices AAA protocols supporting L3 routing in order to forward packets based on
      L3 headers.

3.  Security-Related Requirements

   The security for the I2RS higher-layer protocol.

   The I2RS higher-layer protocol requires mutually authenticated implementation of a I2RS clients
   secure-transport component protocol and the I2RS agents communicating over a secure transport. management component
   protocol.  The I2RS AAA component protocol MUST be able to provide atomicity of an I2RS
   transaction, but it is not required to have multi-message atomicity optional.

3.  Security Features and roll-back mechanism transactions.  Multiple messages transactions
   may be impacted Protocols: Re-used and New

3.1.  Security Protocols Re-Used by the interdependency of data.  This section
   discusses the details of these security requirements.

   There I2RS Protocol

   I2RS also requires a secure transport protocol and key distribution
   protocols.  The secure transport features required by I2RS are dependencies in some of the requirements below.  For
   confidentiality (section 3.3) peer
   authentication, confidentiality, data integrity, and integrity (section 3.4) replay
   protection for I2RS messages.  According to be
   achieved,
   [I-D.ietf-taps-transports], the client-agent must have mutual authentication (section
   3.1) and secure transport (section 3.2).  Since I2RS does not itself
   provide confidentiality 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).

   The following protocols will need to be extended to provide
   confidentiality, data integrity, it peer authentication, and key
   distribution protocols: SSH, SCTP, or the ForCES TML layer over SCTP.

   The specific type of key management protocols an I2RS secure
   transport uses depends on running the transport.  Key management protocols
   utilized for the I2RS protocols SHOULD support automatic rotation.

   An I2RS implementer may use AAA protocols over secure transport to
   distribute the identities for I2RS client and I2RS agent and role
   authorization information.  Two AAA protocols are: Diameter [RFC6733]
   and Radius [RFC2865].  To provide the best security I2RS peer
   identities, the AAA protocols MUST be run over a secure Transport that provides these features.

3.1.  Mutual authentication of transport
   (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius
   over a secure transport (TLS) [RFC6614]).

3.2.  New Security Features

   The new features are priority, an opaque secondary identifier, and an
   insecure protocol for read-only data constrained to specific standard
   usages.  The I2RS client protocol allows multi-headed control by several
   I2RS clients.  This multi-headed control is based on the assumption
   that the operator deploying the I2RS clients, I2RS agents, and the
   I2rs protocol will coordinate the read, write, and notification scope
   so the I2RS clients will not contend for the same write scope.
   However, just in case there is an unforseen overlap of I2RS Agent

   The clients
   attempting to write a particular piece of data, the I2RS architecture
   [RFC7921] sets provides the following requirements:

   o  SEC-REQ-01: All concept of each I2RS clients and client having a priority.
   The I2RS agents MUST client with the highest priority will have an
      identity, and at least one unique its write
   succeed.  This document specifies requirements for this new concept
   of priority.

   The opaque secondary identifier identifies an application which is
   using the I2RS client to I2RS agent communication to manage the
   routing system.  The secondary identifier is opaque to the I2RS
   protocol.  In order to protect personal privacy, the secondary
   identifier should not contain personal identifiable information.

   The last new security feature is the ability to allow non-
   confidential data to be transfered over a non-secure transport.  It
   is expected that most I2RS data models will describe information that
   will be transferred with confidentiality.  Therefore, any model which
   transfers data over a non-secure transport is marked.  The use of a
   non-secure transport is optional, and an implementer SHOULD create
   knobs that allow data marked as non-confidential to be sent over a
   secure transport.

   Non-confidential data can only be read or notification scope
   transmission of events.  Non-confidential data cannot be write scope
   or notification scope configuration.  An example of non-confidential
   data is the telemetry information that is publically known (e.g.  BGP
   route-views data or web site status data) or some legacy data (e.g.
   interface) which cannot be transported in secure transport.  The IETF
   I2RS Data models MUST indicate in the data model the specific data
   which is non-confidential.

   Most I2RS data models will expect that the information described in
   the model will be transferred with confidentiality.  Therefore, it is

3.3.  I2RS Protocol Security Requirements vs. IETF Management Protocols

   Table 1 below provides a partial list of the candidate management
   protocols and the secure transports each one of the support.  One
   column in the table indicates the transport protocol will need I2RS
   security extensions.

      Mangement
      Protocol   Transport Protocol      I2RS Extensions
      =========  =====================   =================
      NETCONF     TLS over TCP (*1)      None required (*2)

      RESTCONF   HTTP over TLS with      None required (*2)
                 X.509v3 certificates,
                 certificate validation,
                 mutual authentication:
                 1) authenticated
                    server identity,
                 2) authenticated
                   client identity
                (*1)

      FORCES    TML overs SCTP           Needs extension to
                (*1)                     TML to run TML
                                         over TLS over SCTP,
                                         or DTLS described
                                         above.  The
                                         IPSEC mechanism is
                                         not sufficient for
                                         I2RS traveling over
                                         multiple hops
                                         (router + link)
                                         (*2)

      IPFIX     SCTP, TCP, UDP           Needs to extension
                TLS or DTLS for          to support TLS or
                secure client (*1)       DTLS with options
                                         described above. (*2)

       *1 - Key management protocols
        MUST support appropriate key rotation.

       *2 - Identity and Role authorization distributed
       by Diameter or Radius MUST use Diameter over TLS
       or Radius over TLS.

4.  Security-Related Requirements

   This section discusses security requirements based on the following
   security functions:

   o  peer identity authentication (section 4.1),
   o  Peer Identity validation before Role-based Message Actions
      (section 4.2)

   o  peer identity and client redundancy (section 4.3),

   o  multi-channel transport requirements: Secure transport and
      insecure Transport (section 4.4),

   o  management protocol security requirements (section 4.5),

   o  role-based security (section 4.6),

   o  security environment (section 4.7)

   The I2RS Protocol depends upon a secure transport layer for peer
   authentication, data integrity, confidentiality, and replay
   protection.  The optional insecure transport can only be used
   restricted set of publically data available (events or information)
   or a select set of legacy data.  Data passed over the insecure
   transport channel MUST not contain any data which identifies a person
   or any "write" transactions.

4.1.  I2RS Peers(agent and client) Identity Authentication

   The following requirements specify the security requirements for Peer
   Identity Authentication for the I2RS protocol:

   o  SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
      identity, and at least one unique identifier that uniquely
      identifies each party in the I2RS protocol context.

   o  SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
      mutual identification of the I2RS client and I2RS agent.

   o  SEC-REQ-03: Identifier distribution and the loading of these
      identifiers into I2RS agent and I2RS client SHOULD occur outside
      the I2RS protocol prior to the I2RS protocol establishing a
      connection between I2RS client and I2RS agent.  AAA protocols MAY
      be used to distribute these identifiers, but other mechanism can
      be used.

   Explanation:

   These requirements specify the requirements for I2RS peer (I2RS agent
   and I2RS client) authentication.  A secure transport (E.g.  TLS) will
   authenticate based on these identities.  The AAA protocol
   distributing I2RS identity information SHOULD transport its
   information over a secure transport.

4.2.  Identity Validation Before Role-Based Message Actions

   The requirements for I2RS clients with Secure Connections are the
   following:

      SEC-REQ-04: An I2RS agent receiving a request from an I2RS client
      MUST confirm that the I2RS client has a valid identity.

      SEC-REQ-05: An I2RS client receiving an I2RS message over a secure
      transport MUST confirm that the I2RS agent has a valid identifier.

      SEC-REQ-06: An I2RS agent receiving an I2RS message over an
      insecure transport MUST confirm that the content is suitable for
      transfer over such a transport.

   Explanation:

   Each I2RS client has a scope based on its identity and the security
   roles (read, write, or events) associated with that identity, and
   that scope must be considered in processing an I2RS messages sent on
   a communication channel.  An I2RS communication channel may utilize
   multiple transport sessions, or establish a transport session and
   then close the transport session.  Therefore, it is important that
   the I2RS peers are operating utilizing valid peer identities when a
   message is processed rather than checking if a transport session
   exists.

4.3.  Peer Identity, Priority, and Client Redundancy

   Requirements:

      SEC-REQ-07: Each I2RS Identifier MUST be associated with just one
      priority.

      SEC-REQ-08: Each Identifier is associated with one secondary
      identifier during a particular I2RS transaction (e.g. read/write
      sequence), but the secondary identifier may vary during the time a
      connection between the I2RS client and I2RS agent is active.

   Explanation:

   The I2RS architecture also allows multiple I2RS clients with unique
   identities to connect to an I2RS agent (section 7.8).  The I2RS
   deployment using multiple clients SHOULD coordinate this multi-headed
   control of I2RS agents by I2RS clients so no conflict occurs in the
   write scope.  However, in the case of conflict on a write scope
   variable, the error resolution mechanisms defined by the I2RS
   architecture multi-headed control ([RFC7921], section 7.8) allow the
   I2RS agent to deterministically choose one I2RS client.  The I2RS
   client with highest priority is given permission to write the
   variable, and the second client receives an error message.

   A single I2RS client may be associated with multiple applications
   with different tasks (e.g. weekly configurations or emergency
   configurations).  The secondary identity is an opaque value that the
   I2RS client passes to the I2RS agent so that this opaque value can be
   placed in the tracing file or event stream to identify the
   application using the I2RS client to I2RS agent communication.

   One example of the use of the secondary identity is the situation
   where an operator of a network has two applications that use an I2RS
   client.  The first application is a weekly configuration application
   that uniquely
      identifies each party in uses the I2RS protocol context.

   o  SEC-REQ-02: to change configurations.  The I2RS protocol MUST utilize these identifiers for
      mutual identification second
   application is an application that allows operators to makes
   emergency changes to routers in the network.  Both of these
   applications use the same I2RS client and I2RS agent.

   o  SEC-REQ-03: An I2RS agent, upon receiving to write to an I2RS message from agent.  In
   order for traceability to determine which application (weekly
   configuration or emergency) wrote some configuration changes to a
      I2RS client, MUST confirm that
   router, the I2RS client has sends a valid
      identifier.

   o  SEC-REQ-04: different opaque value for each of
   the applications.  The I2RS client, upon receiving an I2RS message from
      an I2RS agent, MUST confirm weekly configuration secondary opaque value
   could be "xzzy-splot" and the emergency secondary opaque value could
   be "splish-splash".

   A second example is if the I2RS agent has client is used for monitoring of
   critical infrastructure.  The operator of a valid identifier.

   o  SEC-REQ-05: Identifier distribution and network using the loading of these
      identifiers into I2RS agent and
   client may desire I2RS Client SHOULD occur outside client redundancy where the I2RS protocol prior to monitoring
   application wth the I2RS protocol establishing a
      connection between I2RS client and I2RS agent.  (One mechanism
      such mechanism is AAA protocols.)

   o  SEC-REQ-06: Each Identifier MUST have just one priority.

   o  SEC-REQ-07: Each Identifier is associated deployed on two different boxes
   with one secondary
      identifier during a particular the same I2RS transaction (e.g. read/write
      sequence), but client identity (see [RFC7921] section 4.3) These
   two monitoring applications pass to the secondary identifier may vary during I2RS client whether the time a
      connection between
   application is the primary or back up application, and the I2RS
   client and passes this information in the I2RS agent secondary identitifier as
   the figure below shows.  The primary applications secondary
   identifier is active.
      Since a single "primary-monitoring", and the backup application
   secondary identifier is "backup-monitoring".  The I2RS client may be use by multiple applications, tracing
   information will include the secondary identifier may vary as information along
   with the transport information in the tracing file in the I2RS client is utilize by
      different application each of whom have a unique agent.

   Example 2: Primary and Backup Application for Monitoring
              Identification sent to agent

   Application A--I2RS client--Secure transport(#1)
    [I2RS identity 1, secondary identifier: "primary-monitoring"]-->

   Application B--I2RS client--Secure transport(#2)
    [I2RS identity 1, secondary identifier: "backup-monitoring"]-->

    Figure 1

4.4.  Multi-Channel Transport: Secure Transport and identifier.

3.2. Insecure Transport Requirements Based on Mutual Authentication

   SEC-REQ-08:

   Requirements:

      SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
      secure transport and optionally MAY be able to transfer data over
      a non-secure transport.  A  The default transport is a secure
      transport, and this means it is mandatory to implement (MTI) in
      all I2RS agents, and in any I2RS client which: a) performs a Write
      scope transaction which is sent to the I2RS agent or b):
      configures an Event Scope transaction.  It is mandatory to use
      (MTU) on any I2RS client's Write transaction or the configuration
      of an Event Scope transaction.

      SEC-REQ-10: The secure transport MUST provide data
      confidentiality, data integrity, and practical replay prevention.

      SEC-REQ-11: The default I2RS client and I2RS agent protocol SHOULD
      implement mechanisms that mitigate DoS attacks.  For the secure
      transport, this means the secure transport must support DoS
      prevention.  For the insecure transport protocol, the I2RS higher-
      layer protocol MUST contain a transport is management layer that
      considers the detection of DoS attacks and provides a secure transport. warning over
      a secure-transport channel.

      SEC-REQ-12: A non-secure secure transport can MUST be used for publishing telemetry data or
   other operational state associated with a key
      management solution that was specifically indicated to non-
   confidential in can guarantee that only the data model in entities
      having sufficient privileges can get the Yang syntax.  Since keys to encrypt/decrypt
      the sensitive data.

      SEC-REQ-13: A machine-readable mechanism to indicate that a data-
      model contains non-confidential data MUST be provided.  A non-
      secure transport is optional, MAY be used to publish only read scope or
      notification scope data if the operator may transmit this associated data model indicates
      that that data is non-confidential.

      SEC-REQ-14: The I2RS protocol MUST be able to support multiple
      secure transport sessions providing protocol and data
      communication between an I2RS agent and an I2RS client.  However,
      a single I2RS agent to I2RS client connection MAY elect to use a
      single secure transport session or a single non-secure transport
      session conforming the requirements above.

      SEC-REQ-15: Deployment configuration knobs SHOULD be created to
      allow operators to send "non-confidential" Read scope (data or
      Event streams) over a secure transport.

   Explanation:

   The following are further restrictions on
   the non-secure transport:

   o I2RS architecture defines three scopes: read, write, and
   notification scope.  Insecure data can only be used for read scope
   and notification scope of "non-confidential data".  The configuration
   of ephemeral data in the I2RS Agent by agent uses either write scope for data
   or write scope for configuration of event notification streams.  The
   requirement to use secure transport for configuration prevents
   accidental or malevolent entities from altering the I2RS
      client SHOULD be done over a secure transport.

   o routing
   system through the I2RS agent.

   It is anticipated that the passing of most I2RS ephemeral state
   operational status SHOULD be done over a secure transport.

   o  As [I-D.ietf-i2rs-ephemeral-state] notes, each data model SHOULD
      indicate whether the transport exchanging

   In most circumstances the data between I2RS
      client and I2RS agent is secure or insecure.

   SEC-REQ-09: A secure transport MUST protocol will be
   associated with a key management solution that can guarantee that only the entities having
   sufficient privileges can get the keys to encrypt/decrypt the
   sensitive data.  Per BCP107 [RFC4107] this key management system
   SHOULD be automatic, but MAY be manual in the following scenarios:

      a) The environment has limited bandwidth or high round-trip times.

      b) The information being protected has low value.

      c) The total volume of traffic over the entire lifetime of the
      long-term session key will be very low.

      d) The scale system.  Most deployments of the deployment is limited.

   Most
   I2RS environments (Clients and Agents) protocol will not have allow for automatic key management systems.  Since
   the
   environment described by BCP107 [RFC4107] but a few I2RS use cases
   required limited non-secure light-weight telemetry messages that have
   these requirements.  An I2RS data model must indicate which portions
   can be served by manual key management.

   SEC-REQ-10: The models for the I2RS protocol MUST be able to support multiple secure
   transport sessions providing protocol and data communication between
   an I2RS Agent and an I2RS client.  However, a single I2RS Agent to will control key routing
   functions, it is important that deployments of I2RS client connection MAY elect to use a single secure transport
   session automatic key
   management systems.

   Per BCP107 [RFC4107] while key management system SHOULD be automatic,
   the systems MAY be manual in the following scenarios:

      a) The environment has limited bandwidth or a single non-secure transport session.

   SEC-REQ-11: high round-trip times.

      b) The information being protected has low value.

      c) The total volume of traffic over the entire lifetime of the
      long-term session key will be very low.

      d) The scale of the deployment is limited.

   Operators deploying the I2RS Client and I2RS Agent protocol selecting manual key management
   SHOULD implement
   mechanisms that mitigate DoS attacks.

3.3.  Data Confidentiality Requirements

   SEC-REQ-12: consider both short and medium term plans.  Deploying
   automatic systems initially may save effort over the long-term.

4.5.  Management Protocol Security

   Requirements:

      SEC-REQ-16: In a critical infrastructure, certain data within
      routing elements is sensitive and read/write operations on such
      data SHOULD be controlled in order to protect its confidentiality.  For example,
   most
      To achieve this, higher-layer protocols MUST utilize a secure
      transport, and SHOULD provide access control functions to protect
      confidentiality of the data.

      SEC-REQ-17: An integrity protection mechanism for I2RS MUST be
      provided that will be able to ensure the following:

         1) the data being protected is not modified without detection
         during its transportation,

         2) the data is actually from where it is expected to come from,
         and

         3) the data is not repeated from some earlier interaction the
         higher layer protocol (best effort).

      The I2RS higher-layer protocol operating over a secure transport
      provides this integrity.  The I2RS higher-layer protocol operating
      over an insecure transport SHOULD provide some way for the client
      receiving non-confidential read-scoped or event-scoped data over
      the insecure connection to detect when the data integrity is
      questionable; and in the event of a questionable data integrity
      the I2RS client should disconnect the insecure transport
      connection.

      SEC-REQ-18: 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.

   Explanation:

   Most carriers do not want a router's configuration and data flow
   statistics known by hackers or their competitors.  While carriers may
   share peering information, most carriers do not share configuration
   and traffic statistics.  To achieve this, the I2RS higher-layer
   protocol (e.g NETCONF) needs to have access control (NACM [RFC6536])
   to sensitive data needs to be provided, and the confidentiality
   protection on such data during transportation needs to be enforced.

3.4.  Data

   Integrity Requirements

   SEC-REQ-13: An integrity protection mechanism for I2RS MUST be
   provided that will be able to ensure the following:

      1) the data being protected is not modified without detection
      during its transportation,

      2) the data is actually from where it is expected to come from,
      and

      3) the data is not repeated from some earlier interaction of the
      protocol.  (That is, when both confidentiality and integrity of data is properly protected, it important even if the I2RS protocol is possible to ensure that
      encrypted sending
   non-confidential data is not modified or replayed without detection.)

   SEC-REQ-14: over an insecure connection.  The I2RS client ability to
   trace I2RS agent transport protocol MUST
   protect against replay attack.

   Requirements SEC-REQ-13 and SEC-REQ-14 are requirements for the
   secure channel which must be supported as the default by every I2RS
   Agent, and by every messages that enact I2RS client communicating over transactions provides a secure
   transport.  In order to provide some traceability or notification for
   the non-secure protocol, SEC-REQ-15 suggests traceability and
   notification are important
   minimal aid to include for any non-secure protocol.

   SEC-REQ-15: The I2RS protocol MUST provide helping operators check how messages enact
   transactions on a mechanism for message
   traceability and notification requirements requirements found in
   [RFC7922] and [RFC7923] that can be supported in communication
   channel that is non-secure to trace secure or notify about potential
   security issues.

3.5. insecure transport.

4.6.  Role-Based Data Model Security

   The I2RS Architecture [RFC7921] defines a role or security role as
   specifying read, write, or notification access by a I2RS client to
   data within an agent's data model.

   SEC-REQ-16:

      SEC-REQ-19: The rules around what I2RS security role is permitted
      to access and manipulate what information plus over a secure transport
      (which protects the data in transit) SHOULD ensure that data of
      any level of sensitivity is reasonably protected from being
      observed by those without permission to view it, so that privacy
      requirements are met.

   SEC-REQ-17:

      SEC-REQ-20: Role security MUST work when multiple transport transport
      connections are being used between the I2RS client and I2RS agent
      as the I2RS architecture [RFC7921] describes.

      Sec-REQ-21: If an I2RS agents or an I2RS client is tightly
      correlated with a person, then the I2RS protocol and data models
      SHOULD provide additional security that protects the person's
      privacy.

   Explanation:

   I2RS higher-layer uses management protocol E.g.  NETCONF, RESTCONF)
   to pass messages in order to enact I2RS transactions.  Role Security
   must secure data (sensitivity and normal data) in a router even when
   it is operating over multiple connections are being used between the I2RS client and I2RS agent as
   the I2RS architecture [RFC7921] states.  These transport message
   streams may start/stop without affecting the existence of at the client/
   agent data exchange. same time.  NETCONF
   can run over TLS (over TCP supports or SCTP) or SSH.  RESTCONF runs over HTTP
   over a single stream of data. secure transport (TLS).  SCTP [RFC4960] provides security for
   multiple streams plus end-to-end transport of data.

   SEC-REQ-18: I2RS clients MAY be used by multiple applications to
   configure routing via I2RS agents, receive status reports, turn on
   the I2RS audit stream, or turn on I2RS traceability.  Application
   software using  Some I2RS client
   functions may host multiple secure
   identities, but each connection will use only one identifier with one
   priority.  Therefore, the security of each I2RS Client wish to I2RS Agent
   connection is unique. operate over DTLS which runs over UDP
   ([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]).

   Please note the security of the application to I2RS client connection
   is outside of the I2RS protocol or I2RS interface.

   Sec-REQ-19: If an I2RS agents or an I2RS client is tightly correlated
   with a person, then the I2RS protocol and data models SHOULD provide
   additional security that protects the person's privacy.  An

   One example of an I2RS agent correlated with privacy concerns related to a person is a if I2RS
   agent is running on someone's phone to control tethering, and an example of a the
   I2RS client might be the client tracking such tethering.  This
   protection MAY
   require a of the privacy of the person involves the I2RS client and
   the I2RS agent communication anonymizing the any data related to the
   person's identity or locatino.

   A variety of forms including: "operator-applied of managemen may set policy on roles: "operator-
   applied knobs", roles that restrict personal access, data-models with
   specific "privacy roles", and access filters.

3.6.

4.7.  Security of the environment

   The security for the implementation of a protocol also considers the
   protocol environment.  The environmental security requirements are
   found in: [I-D.ietf-i2rs-security-environment-reqs].

4.

5.  Security Considerations

   This is a document about security requirements for the I2RS protocol
   and data modules.  Security considerations for the I2RS protocol
   include both the protocol and the security environment.

6.  IANA Considerations

   This draft is requirements, and does not request anything of IANA.

7.  Acknowledgement

   The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
   Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia
   Atlas, and Jeff Haas for their contributions to the I2RS security
   requirements discussion and this document.  The authors would like to
   thank Bob Moskowitz for his review of the requirements.

5.  IANA Considerations

   This draft includes no request to IANA.

6.  Security Considerations

   This is a document about security requirements for the I2RS protocol
   and data modules.  The whole document is security considerations.

7. would like to
   thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Alvaro
   Retana, Ben Campbell, and Alissa Cooper for their review of these
   requirements.

8.  References

7.1.

8.1.  Normative References

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

   [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>.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
              June 2005, <http://www.rfc-editor.org/info/rfc4107>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <http://www.rfc-editor.org/info/rfc4949>.

   [RFC7920]  Atlas, A., Ed., Nadeau, T., Ed.,

   [RFC7258]  Farrell, S. and D. Ward, "Problem
              Statement for the Interface to the Routing System", H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7920, 7258, DOI 10.17487/RFC7920, June 2016,
              <http://www.rfc-editor.org/info/rfc7920>. 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

   [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>.

7.2.

   [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-15 draft-ietf-i2rs-ephemeral-state-16 (work in
              progress), July August 2016.

   [I-D.ietf-i2rs-security-environment-reqs]
              Migault, D., Halpern, J.,

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and S. Hares, "I2RS Environment
              Security Requirements", draft-ietf-i2rs-security-
              environment-reqs-01 K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-16 (work in
              progress), April August 2016.

   [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-11 (work
              in progress), July 2016.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <http://www.rfc-editor.org/info/rfc4960>.

   [RFC7922]  Clarke, J., Salgueiro, G.,

   [RFC5246]  Dierks, T. and C. Pignataro, "Interface 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>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Routing System (I2RS) Traceability: Framework Secure
              Real-time Transport Protocol (SRTP)", RFC 5764,
              DOI 10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

   [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and
              Information Model", J. Rydell, "TOTP:
              Time-Based One-Time Password Algorithm", RFC 7922, 6238,
              DOI 10.17487/RFC7922, 10.17487/RFC6238, May 2011,
              <http://www.rfc-editor.org/info/rfc6238>.

   [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
              2016, <http://www.rfc-editor.org/info/rfc7922>.

   [RFC7923]  Voit, E., Clemm, 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [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>.

   [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
              "Transport Layer Security (TLS) Encryption for RADIUS",
              RFC 6614, DOI 10.17487/RFC6614, May 2012,
              <http://www.rfc-editor.org/info/rfc6614>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

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

Authors' Addresses

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC  HAP 2N2
   Canada

   Email: daniel.migault@ericsson.com

   Joel Halpern
   Ericsson
   US

   Email: joel.halpern@ericsson.com