I2RS WG                                                       D. Migault, Ed. Migault
Internet-Draft                                                J. Halpern
Intended status: Informational                                  Ericsson
Expires: October 6, 2016 May 19, 2017                                           S. Hares
                                                                  Huawei
                                                           April 4,
                                                       November 15, 2016

                 I2RS Environment Security Requirements
              draft-ietf-i2rs-security-environment-reqs-01
              draft-ietf-i2rs-security-environment-reqs-02

Abstract

   This document provides environment security requirements for the I2RS
   architecture.  Environment security requirements are independent of
   the protocol used for I2RS.  As a result, the requirements provided
   in this document are intended to provide good security practise so
   I2RS can be securely deployed and operated.

   These security requirements are designated as environment security
   requirements as opposed to the protocol security requirements.  The
   reason to have separate document is that I2RS protocol security requirements are intended to help
   set the design of security for the communication between I2RS protocol
   whether client and agent
   while the security environment requirements are rather intended for
   deployment or implementations. implementations features independent of the I2RS
   protocol.  The environmental security requirements described in this
   document provide the good security practices to be used with the I2RS
   protocol so that I2RS protocol implementations can be securely
   deployed and operated.

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 October 6, 2016. May 19, 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.  Requirements notation . .  Introduction  . . . . . . . . . . . . . . . . . .   2
   2.  Introduction . . . . . .   3
   2.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  Terminology and Acronyms   4
     2.1.  Requirements notation . . . . . . . . . . . . . . . . . .   4
   4.
   3.  I2RS Plane Isolation  . . . . . . . . . . . . . . . . . . . .   4
     4.1.
     3.1.  I2RS plane Plane and management Management plane . . . . . . . . . . . . .   4
     4.2.   5
     3.2.  I2RS plane Plane and forwarding plane Forwarding Plane . . . . . . . . . . . . .   5
     4.3.   7
     3.3.  I2RS plane Plane and Control plane Plane  . . . . . . . . . . . . . .   6
     4.4.  Recommendations   8
     3.4.  Requirements  . . . . . . . . . . . . . . . . . . . . .   6
   5. .   8
   4.  I2RS Access Control for routing system resources Routing System Resources  . . . . . .   8
     5.1.  10
     4.1.  I2RS Access Control architecture  . Architecture  . . . . . . . . . . .   8
     5.2.  I2RS Agent Access Control policies .  11
       4.1.1.  access control Enforcement Scope  . . . . . . . . . .  13
     5.3.  I2RS Client Access Control policies  12
       4.1.2.  Notification Requirements . . . . . . . . . . .  14
     5.4.  Application and Access Control policies . . .  13
       4.1.3.  Trust . . . . . .  15
   6.  I2RS Application Isolation . . . . . . . . . . . . . . . . .  16
     6.1.  Robustness toward programmability .  14
       4.1.4.  Sharing access control Information  . . . . . . . . .  14
       4.1.5.  Sharing Access Control in Groups of I2RS Clients and
               Agents  . .  16
     6.2.  Application Isolation . . . . . . . . . . . . . . . . . .  17
       6.2.1.  DoS . . .  16
       4.1.6.  Managing Access Control Policy  . . . . . . . . . . .  17
     4.2.  I2RS Agent Access Control Policies  . . . . . . . . . . .  17
       6.2.2.  Application  18
       4.2.1.  I2RS Agent Access Control . . . . . . . . . . . . . .  19
       4.2.2.  I2RS Client Access Control Policies . . .  17
   7.  Security Considerations . . . . . .  20
       4.2.3.  Application and Access Control Policies . . . . . . .  21
   5.  I2RS Application Isolation  . . . . . .  18
   8.  Privacy Considerations . . . . . . . . . . .  22
     5.1.  Robustness Toward Programmability . . . . . . . .  18
   9.  IANA Considerations . . . .  22
     5.2.  Application Isolation . . . . . . . . . . . . . . . . .  18
   10. Acknowledgments .  23
       5.2.1.  DoS . . . . . . . . . . . . . . . . . . . . . .  18
   11. References . . .  23
       5.2.2.  Application Logic Control . . . . . . . . . . . . . .  24
   6.  Security Considerations . . . . . . . .  18
     11.1. . . . . . . . . . . .  25
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     11.2.  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  26

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   This document provides environment security requirements for the I2RS
   architecture.  Environment security requirements are independent of
   the protocol used for I2RS.  As a result,  The I2RS protocol security requirements
   [I-D.ietf-i2rs-protocol-security-requirements] set the security for
   the communication between I2RS client and agent while the security
   environment requirements provided are rather intended for deployment or
   implementations features independent of the I2RS protocol.  The
   environmental security requirements described in this document are intended to
   provide the good security practise practices to be used with the I2RS protocol
   so that I2RS protocol implementations can be securely deployed and operated.
   operate.  These security requirements are designated as environment security
   requirements as opposed to address the protocol security requirements
   described in [I-D.ietf-i2rs-protocol-security-requirements].  The
   reason to have separate document is that protocol security
   requirements are intended to help the design of the
   considerations for I2RS protocol
   whether environment considered in the I2RS
   Architecture [RFC7921] in order to provide a stable and secure
   environment requirements are rather intended for
   deployment or implementations. in which the dynamic programmatic interface to the
   routing system (I2RS) should operates.

   Even though the I2RS protocol is mostly concerned by with the interface
   between the I2RS Client client and the I2RS Agent, agent, the environmental
   security recommendations requirements must consider the entire I2RS architecture, specifying architecture and
   specify where security functions may be hosted, hosted and what criteria
   should be met so in order to address any new attack vectors exposed by
   deploying this architecture.  In other
   words,  Environment security for I2RS has to be
   considered globally over the complete I2RS architecture and not only on the interfaces.

   I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes
   the I2RS components and their interactions to provide a programmatic
   interface for the routing system.  I2RS components as well as their
   interactions have not yet been considered in conventional routing
   systems.  As such it introduces a need to interface with the routing
   system designated as I2RS plane in this document.
   protocol interface.

   This document is built structured as follows. follows:

   o  Section 4 2 describes the terminology used in this document,

   o  Section 3 describes how the I2RS plane can be contained or
      isolated from existing management plane, control plane and
      forwarding plane.  The remaining

   o  the subsequent sections of the document focuses on the security
      within the I2RS plane. plane including:

      *  Section 5 4 analyzes how the I2RS Access Control access control policies can be
         deployed throughout the I2RS plane in order to only grant
         access to the routing system resources to authorized components
         with the authorized privileges.  This also includes providing a
         robust communication system between the components.  Then,

      *  Section 6 5 details how I2RS keeps applications isolated one from
         another and do not affect without affecting the I2RS components.  Applications
         applications may be independent, with different scopes, owned
         by different tenants.  In addition, they the applications may modify
         the routing system that may be in an automatic way.

   Motivations are placed before the requirements are given.

   The reader is expected to be familiar with the
   [I-D.ietf-i2rs-architecture].  The document provides a list of
   environment I2RS problem statement
   [RFC7920], I2RS architecture, [RFC7921], traceability requirements
   [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state
   requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security requirements.  Motivations are placed before the
   requirements are announced.

3. [I-D.ietf-i2rs-protocol-security-requirements].

2.  Terminology and Acronyms

   - Environment Security Requirements :   Security requirements
         specifying how the environment a protocol operates in needs to
         be secure.  These requirements do not specify the protocol
         security requirements.

   - I2RS plane : plane:   The environment the I2RS process is running on.  It
         includes the Applications, applications, the I2RS Client client and the I2RS Agent. agent.

   - I2RS user : user:   The user of the I2RS client software or system.

   - I2RS Access Control access control policies:   policies controlling access of the
         routing resources by Applications. applications.  These policies are divided
         into policies applied by the I2RS Client client regarding Applications applications
         and policies applied by the I2RS Agent agent regarding I2RS Clients. clients.

   - I2RS Client Access Control policies : client access control policies:   The Access Control access control policies
         processed by the I2RS Client. client.

   - I2RS Agent Access Control policies : agent access control policies:   The Access Control access control policies
         processed by the I2RS Agent.

4. agent.

2.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  I2RS Plane Isolation

   Isolating the I2RS plane from other network planes (the management,
   forwarding plane, such as the and control plane, planes ) is foundational fundamental to the security
   of the I2RS environment.  Clearly differentiating I2RS components
   from the rest of the network device does the following:

   1.  protects the I2RS components from vulnerabilities in other parts
       of the network, and protect

   2.  protects other systems vital to the health of the network from
       vulnerabilities in the I2RS plane.

   Separating the I2RS plane from other network control and forwarding
   planes is similar to the best common practice of containerizing
   software into modules, and defense in depth in the larger world of
   network security.

   That said modules.  However, the I2RS plane cannot be considered
   as completely isolated from other planes, and planes so the interactions should be identified and between
   the I2RS plane and other planes should be identified and controlled.  Follows
   The following is a brief description on of how the I2RS plane positions
   itself in regard to the other planes.  The description is
   indicative, and may not be exhaustive.

4.1.

3.1.  I2RS plane Plane and management Management plane

   The purpose of the I2RS plane purpose is to provide a standard programmatic
   interface of the routing system resources to network oriented
   applications.  Control  The control plane and forwarding planes are related to
   routing protocols, and I2RS is based positioned on top of those. the control plane
   and forwarding plane.  The management plane is usually vendor specific,
   specific and provides a broader control over the networking equipment
   such as system service.  Given its the management plane's associated
   privileges it is expected to be reserved to highly trusted users like
   network administrators.

   The I2RS plane and the management plane both interact with several
   common elements on forwarding and packet processing devices.
   [I-D.ietf-i2rs-architecture]
   [RFC7921] describes several of these interaction points such as the
   local configuration, the static system state, routing, and signalling.  Because of this potential overlaps, a signaling.
   A routing resource may be accessed by different means (APIs,
   applications) and different planes.  To keep these overlaps under
   control, one could either control the access to these resources with
   northbound APIs for example.  Northbound planes which creates potential overlaps.
   Southbound APIs are often provided to limit the scope of the applications toward
   management plane's and the I2RS plane's interaction with the routing resources.  In our
   case,
   resources (as figure 1 shows).  If there are conflicts in these
   overlapping southbound APIs, the northbound API may conflicts should be provided for resolved in a
   deterministic way.

      APIs that interact with the
      I2RS Plane and Management PLane

     I2RS applications by
   the       Mangement applications
      || NB API                     NB API ||
      ||                                   ||
      I2RS Client as well as to the management plane.  In case
   conflicting overlaps cannot be avoided, and routing resource can be
   accessed by both the plane               management plane
      ||                                   ||
      ||SB API                      SB API ||
      -------------------------------------------
      |     Routing Resources                    |
      |(forwarding plane, control plane, system) |
      +------------------------------------------+

      Figure 1 - North Bound (NB) APIs and the
                 South Bound (SB) APIs

   The I2RS plane, then, they
   should applications may be resolved in provided with a deterministic way.

   On the northbound side, there must be clear protections against API by the
   I2RS system "infecting" client (as figure 1 shows).  Similarly, the management system with bad information,
   or plane may
   provide a northbound API to management application.  The northbound
   API from the management system "infecting" plane to the client application and the
   northbound API from the I2RS system with bad
   information.  The primary protection in this space is going plane to need I2RS applications may overlap.
   In case that these overlapping APIs between the have conflicts (e.g.
   both want to be validation rules on access the speed of information flow, value limits
   on same routing resource), the data presented, and other protections of this type.

   On the conflicting side/issues, there conflicts
   should be resolved in a deterministic way.

   To resolve conflicts in a northbound APIs, the deterministic
   resolution should have clear rules about which plan's commands win in the case of data plane with a
   system takes precedence (wins during a conflict in order for resources).  This
   is important to prevent attacks where that attempt to drive the two systems can be forced to deadlock.

4.2.
   into deadlock situation over which system has precedence (wins)

   In the interactions between the I2RS plane and forwarding the applications, and
   the management plane and the application is it important to prevent
   the following things:

   o  the I2RS system "infecting" the management system with bad
      information,

   o  the management system "infecting" the I2RS system with bad
      information directly,

   o  the management system indirectly "infecting" the I2RS system by
      propagating improproper information from one system to another via
      I2RS.

   Prevention:

   The primary protection in this space is going to need to be
   validation rules on the data being sent/receive, notification of
   changes that the I2RS agent sends the client, and other access
   protections.

   In this circumstance, we define "infecting" as inteferring with and
   leading into a incoherent state.  The I2RS plane may update a routing
   resource configured by the management plane, or the reverse (the
   management plane updates a resource the I2RS plane has configured).
   Indirect "infecting", we define as as changes made by the I2RS plane
   that cause changes in routing protocols which add state unexpected by
   the management plane or the reverse (the mangement plane adding
   changes in routing protocols the I2RS plane does not expect).

3.2.  I2RS Plane and Forwarding Plane

   Applications hosted on by the I2RS Client belongs client belong to the I2RS plane.  These
   Applications are hard  It
   is difficult to remain constrained into these applications to the I2RS plane, or
   even to limit their scope within the I2RS plane.  Applications using
   I2RS are part of the I2RS plane but may also interact with other components outside the I2RS plane.  A common  For
   example may be an application uses may use an I2RS client to configure the
   network
   according to security or monitored events.  As these events are
   monitored via an I2RS agent on the forwarding plane and not the a single machine, or
   multiple I2RS plane, the
   application breaks plane isolation.

   In addition, applications agents each on a single machine.

   Applications may also communicate with multiple I2RS Clients;
   as such, any given application may clients in order
   to have a broader view of the current and potential states of the
   network and the I2RS plane itself.

   Because of this, any  These varied remote communication
   relationships between applications using the I2RS protocol to change
   the forwarding plane make it possible for an individual application could
   to be an effective attack vector against the operation of the
   network, the a router's I2RS plane,
   or any plane with which the I2RS forwarding plane interacts. of the routing
   system, and other planes (management and control planes).

   Prevention measures:

   Systems should consider the following prevention errors:

   application validation -  There is little the I2RS plane can do to
      validate applications with which it
   interacts, other than interacts.  The I2RS client
      passes the I2RS agent an opaque identifier for the application so
      that an application's actions can be traced back to provide some broad general validations the
      application.

   Validation against common misconfigurations or errors.  As with errors -  One way of
      securing the separation interfaces between the management plane and application, the I2RS plane, this should
   minimally take and
      the forwarding plane is to limit the form of limits on information accepted, limits on accepted and to
      limit the rate at which information is accepted, and accepted between these three
      software planes.  Another method is to performing rudimentary
      checks
   against intentionally formed routing loops or injecting information
   that would cause on the control plane to fail to converge.  Other forms results of protection may be necessary.

4.3. any updates to the forwarding plane.

3.3.  I2RS plane Plane and Control plane Plane

   The network control plane consists of the processes and protocols
   that discover topology, advertise reachability, and determine the
   shortest path between any location on the network and any
   destination.  It is not anticipated there will be any interactions
   between  I2RS client configures, monitors or receives events via
   the on-the-wire signalling used by I2RS agent's interaction with the routing system including the
   process that handling the control plane.
   However, in plane signaling protocols (BGP,
   ISIS, OSPF, etc.), route information databases (RIBs), and interface
   databases.  In some situations situation to manage an network outage or to
   control traffic, the I2RS system could protocol may modify information in the local databases of
   route database or the control plane.  This configuration of routing process.  While this
   is not normally
   recommended, as it can a part of normal processing, such action that allows the
   network operator to bypass temporary outages or DoS attacks.

   This capability to modify the routing process information carries
   with it the risk that the I2RS agent may alter the normal loop free, loop free
   alternate, and convergence properties
   of the routing protocols which provide normal loop free routing in
   the control plane.  However,
   if  The information configured by the I2RS system does directly inject information agent into these
   tables,
   routing process or RIBs could cause problems, or state which is
   inserted or deleted from routing processes (control traffic,
   counters, etc.) could cause the control plan to fail to converge or
   fail).

   Prevention measures:

   The I2RS system should ensure can provide checks that during and after the problem
   has been resolved that loop free routing is
   preserved, is preserved.  These checks
   should check the preservation of all facets of routing including the
   following: routing with loop free alternates, tunnelled interfaces,
   virtual overlays, and other such constructions.  Any information
   injected into the control plane directly could cause the control
   plane to fail to converge, resulting in a complete network outage.

4.4.  Recommendations

3.4.  Requirements

   To isolate I2RS transactions from other planes, it is recommended required that:

   REQ

   SEC-ENV-REQ 1:  Application-to-routing  application-to-routing system resources
                   communications should use an isolated communication
                   channel.  Various level of isolation can be
                   considered.  The highest level of isolation may be
                   provided by using a physically isolated network.
                   Alternatives may also consider logical isolation; for example
           by isolation
                   (e.g. using vLAN.  Eventually, in vLAN).  In a virtual environment that
                   shares a common infrastructure, encryption, for example by
           using TLS or IPsec, encryption may also
                   be used as a way to enforce isolation.

   REQ  Encryption
                   can be added by using a secure transport required by
                   the I2RS protocol security
                   [I-D.ietf-i2rs-protocol-security-requirements], and
                   sending the non-confidential I2RS data (designed for
                   a non-secure transport) over a secure transport.

   SEC-ENV-REQ 2:  The interface (like the IP address) used by the routing element to receive
                   I2RS transactions via the I2RS protocol (e.g. the IP
                   address) should be a dedicated physical or logical
                   interface.  As previously, mentioned a dedicated
                   physical interface may contribute to a higher
           isolation, however logical isolation be
                   isolation.  Isolation may also be considered
           for example achieved by using a
                   dedicated IP address or a dedicated port.

   SEC-ENV-REQ 3:  An I2RS agent should have permissions separate from
                   any other entity (for example any internal system
                   management processes or CLI processes).

   Explanation:

   When the I2RS Agent agent performs an action on a routing element, the
   action is performed via process(es) associated to a system user . In routing process.

   For example, in a typical UNIX system, the user is designated with a
   user id (uid) and belong belongs to groups designated by group ids (gid).  These users are
   dependent of
   If such a user id (uid) and group id (gid) is the identifier for the
   routing element's operation system processes peforming routing tasks in the control plane, then
   the I2RS Agent process would communicate with these routing
   processes.  It is important that the I2RS agent has its own unique
   identifier and are
   designated the routing processes have their own identifier so
   that access control can unique filter data between the processes.

   SEC-ENV-REQ 4:  I2RS System Users.  Some implementation may use plane should be informed when a routing system
                   resource is modified by a user outside the I2RS
   System User for plane
                   access.  Notifications from the control plane SHOULD
                   not to flood the I2RS Agent that proxies plane, and rate limiting (or
                   summarization) is expected to be applied.  These
                   routing system notification MAY translated to the different
                   appropriate I2RS
   Client, other implementations may use agent notifications, and passed to
                   various I2RS System User clients via notification relays.  (This
                   requirements is also described in section 7.6 of
                   [RFC7921] for each
   different the I2RS Clients.

   REQ 3: client, and this section
                   extends it to the entire I2RS Agent should have permissions separate from any other
           entity (for example any internal system management processes
           or CLI processes). plane (I2RS agent,
                   client, and application).

   Explanation:

   I2RS resource may be shared with the management plane and the control
   plane.  It is hardly possible to prevent interactions between the
   planes.  The I2RS routing system resource management is limited to the
   I2RS plane.  As such, update of I2RS routing system outside of the
   I2RS plane may be remain unnoticed unless and until explicitly notified
   to the I2RS plane.  Such notification is expected to trigger
   synchronization of the I2RS resource state within each I2RS
   component.  This guarantees that I2RS resource are maintained in a
   coherent state among the I2RS plane.  In addition, depending on the
   I2RS resource that is updated as well as the origin of the
   modification performed, the I2RS Access Control access control policies may be
   impacted.  More especially, a  Further an I2RS Client client is more likely to update an I2RS
   resources that has been updated by itself, then by the management plane for example.

   REQ 4:
   plane.

   SEC-ENV-REQ 5:  I2RS plane should be informed when define an "I2RS plane overwrite
                   policy".  Such policy defines how an I2RS is able to
                   update and overwrite a routing system resource
           is modified set by a user outside
                   the I2RS plane access.  The
           notification is not expected to flood the I2RS plane.
           Instead, notification is expected to be provided to  Such hierarchy has been described in
                   section 6.3 and 7.8 of [RFC7921]

   Explanation:

   A key part of the I2RS
           components interacting, configuring or monitoring the architecture is notification regarding routing
   system resource.  The notification is at least provided by changes across the I2RS Agent plane (I2RS client to/from I2RS
   agent).  The security environment requirements above (SEC-ENV-REQ-03
   to SEC-ENV-REQ-05) provide the assurance that the various I2RS Client, but additional
           mechanisms might eventually be required so I2RS Client can
           relay plane and the notification
   routing systems the I2RS plane attaches to remains untouched by the
   other planes or the I2RS applications.  This plane is
           designated as "I2RS resource modified out notificed of I2RS plane".
           This requirements is also described in section 7.6 such changes.
   Section 6.3 of
           [I-D.ietf-i2rs-architecture] for the I2RS Client.  This
           document extends the requirement to [RFC7921] describes how the I2RS plane, in case
           future evolution of agent within the I2RS plane.

   REQ 5:  I2RS
   plane should define interacts with forwarding plane's local configuration, and
   provides the example of an "I2RS plane overwrite policy".
           Such policy defines how an between the I2RS is able to update plane
   and
           overwrite a resource set by a user local configuration (instantiated in 2 Policy Knobs) that
   operators may wish to set.  The prompt notification of any outside
   overwrite is key to the I2RS plane.
           Such hierarchy has been described in section 6.3 architecture and 7.8 proper interworking of
           [I-D.ietf-i2rs-architecture]

5. the
   I2RS Plane.

4.  I2RS Access Control for routing system resources Routing System Resources

   This section provides recommendations on how I2RS Access Control access control
   policies associated to the routing system resources.  These policies
   only apply within the I2RS plane.  More especially, the policies are
   associated to the Applications, the applications, I2RS Clients clients and the I2RS Agents, agents, with
   their associated identity and roles.

   Note that the

   The I2RS deployment of Applications, I2RS Client applications, I2RS clients, and I2RS Agent
   agents can be located locally in a closed environment, should not be considered by default as a
   secure environment or distributed
   over open networks.  The normal case for routing system management is
   over an open environment.  Even for in a closed environment access
   control policies should be carefully defined to be able to, in the
   future to carefully extend the I2RS plane to remote Applications applications or
   remote I2RS
   Clients.  As a result, this section always consider the case
   Applications and I2RS Client can be located locally, in a closed
   environment or distributed over open networks.

   Although clients.

   [I-D.ietf-i2rs-protocol-security-requirements] provides defines the security
   requirements of the transport and I2RS protocol between the I2RS
   Client client and the
   I2RS Agent, this agent over a secure transport.  This section is mostly focused focuses on I2RS
   access
   control.

5.1. control architecture (section 5.1), access control policies of
   the I2RS agent (section 5.2), the I2RS client (section 5.3), and the
   application (section 5.4).

4.1.  I2RS Access Control architecture Architecture

   Overview:

   Applications access to routing system resource via numerous
   intermediaries nodes.  The application communicates with an I2RS
   Client.
   client.  In some cases, the I2RS Client client is only associated to a
   single application, but application attached to one or more agents (case a and case b
   in figure 2 below).  In other cases, the I2RS client may be connected
   to two applications (case c in figure 2 below), or the I2RS Client may also act
   as a broker. broker (agent/client device shown in case d in the figure 2
   below).  The I2RS Client, then, communicates with client broker approach provides scalability to the
   I2RS architecture as it avoids that each application be registered to
   the I2RS agent.  Similarly, the I2RS access control should be able to
   scale numerous applications.

   The goal of the security environment requirements in this section are
   to control the interactions between the applications and the I2RS
   client, and the interactions between the I2RS client and the I2RS
   agent.  The key challenge is that the I2RS architecture puts the I2RS
   Client in control of the stream of communication (application to I2RS
   client and I2RS Agent that may
   eventually access client to the resource. I2RS agent).  The I2RS Client broker approach provides scalability to agent must trust
   the I2RS
   architecture as it avoids that each Application be registered client's actions without having an ability to verify the
   I2RS Agent.  Similarly, the client's actions.

     a) I2RS Access Control should be able application-client pair talking
        to
   scale numerous applications.

   REQ one I2RS agent

     +-----------+     +---------+      +-------+
     |   I2RS    |=====| I2RS    |======| I2RS  |
     |application|     | client 1|      | agent |
     +-----------+     +---------+      +-------+

     b) I2RS application client pair talking to
        two i2RS agents
                                       +--------+
     +-------------+   +---------+     | I2RS   |
     |   I2RS      |===| I2RS    |=====| agent 1|
     |application 1|   | client 1|     +--------+
     |             |   |         |     +--------+
     |             |   |         |=====| I2RS   |
     +-------------+   +---------+     | agent 2|
                                       +--------+

     c) two applications talk to 1 client
                                      +--------+
     +-------------+   +--------+     | I2RS   |
     |   I2RS      |===|I2RS    |=====| agent 1|
     |application 1|   |client 1|     +--------+
     +-------------+   |        |     +--------+
     +-------------+   |        |=====| I2RS   |
     |  I2RS       |   |        |     | agent 2|
     |application 2|===|        |     +--------+
     +-------------+   +--------+

     d) I2RS Broker (agent/client
                                     +--------+
     +-------------+  +--------+     | I2RS   |
     |   I2RS      |==|I2RS    |=====|agent 3/|
     |application 1|  |client 1|   ==|client 3+----+
     +-------------+  +--------+   | +--+-----+    |
                                   |    |          |
     +-------------+  +--------+   |  +-------+ +--|----+
     |  I2RS       |  |I2RS    |===|  |I2RS   | |I2RS   |
     |application 2|==|client 2|      |agent 1| |agent 2|
     +-------------+  +--------+      +-------+ +-------+

4.1.1.  access control Enforcement Scope

   SEC-ENV-REQ 6:  I2RS Access Control access control should be performed through the
                   whole I2RS plane.  It should not be enforced by the
                   I2RS Agent agent only within the routing element.  Instead,
                   the I2RS Client client should enforce the I2RS Client Access Control client access
                   control against Applications applications and the I2RS Agent agent
                   should enforce the I2RS Agent Access
           Control agent access control against
                   the I2RS Clients.  Note that clients.  The mechanisms for the I2RS Client
           Access Control is client
                   access control are not in the scope of the I2RS
                   architecture
           [I-D.ietf-i2rs-architecture], [RFC7921], which exclusively focuses on
                   the I2RS Agent Access Control. agent access control provided by the I2RS
                   protocol.

   Explanation:

   This architecture results in a layered and hierarchical or multi-party multi-
   party I2RS Access
   Control. access control.  An application will be able to access a
   routing system resource only if both the I2RS Client client is granted
   access by the I2RS
   Agent agent and the application is granted access by the
   I2RS Client.

   REQ client.

4.1.2.  Notification Requirements

   SEC-ENV-REQ 7:  When an access request to a routing resource is
                   refused by one party (the I2RS Client client or the I2RS Agent),
                   agent), the initiator
           of the request requester (e.g the Application) application) as well
                   as all intermediaries should indicate the reason the
                   access has not been granted as well as the granted, and which entity that has
                   rejected the request.

   REQ 8:  In order to provide coherent Access Control policies enforced
           by multiple parties (e.g. the I2RS Client or the I2RS Agent),
           theses parties should trust each others, and communication
           between them should also be trusted, - that is should not
           introduce additional vector of attacks.

   Explanation:

   In case the I2RS Client Access Control client access control or the I2RS Agent Access
   Control agent access
   control does not grant access to a routing system resource, the
   Application
   application should be able to determine whether its request has been
   rejected by the I2RS Client client or the I2RS Agent agent as well as the reason
   that caused the reject.  More specifically,

   SEC-REQ-07 indicates the I2RS Agent agent may reject the request because, for example, because
   the I2RS Client client is not an authorized I2RS Client, client or because the I2RS Client does not not have enough privileges.
   privileges to perform the requested transaction (read, write, start
   notifications or logging).  The I2RS Client client should be notified of the
   reason
   that caused the reject by the I2RS Agent, agent rejected the transaction due to a lack of
   authorization or priviledges, and The the I2RS Client client should return a
   message to the Application, application indicating the I2RS Client is
   not authorized or does not have enough privileges. agent reject the
   transacation with an indication of this reason.  Similarly, if the
   I2RS Client client does not grant the access to the Application, application, the I2RS
   Client
   client should also inform the Application.  The application.  An example of an error
   message
   returned should be for example: could be, "Read failure: you do not have the read
   permission", "Write failure: you do not have write permission" permission", or
   "Write failure: resource accessed by someone else".

   This requirement has been written in a generic manner as it concerns
   various
   the following interactions:

   o  interactions between the application and the I2RS Client, client,

   o  interactions between the I2RS Client client and the I2RS Agent.
   In the latest case, the requirement is part of the protocol security agent (security
      requirements addressed are described by
   [I-D.ietf-i2rs-protocol-security-requirements].

   Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on
   transport security requirements
      [I-D.ietf-i2rs-protocol-security-requirements]),

   o  and interactions between the I2RS Client agent and the I2RS
   Agent, the similar requirements may apply between the Application routing
      system (forwarding plane, control plane, and routing plane).

4.1.3.  Trust

   SEC-ENV-REQ 8:  In order to provide coherent access control policies
                   enforced by multiple parties (e.g. the I2RS Client for a remote Application.

   REQ client or
                   the I2RS agent), theses parties should trust each
                   others, and communication between them should also be
                   trusted (e.g.  TLS) in order to reduce additional
                   vector of attacks.

   SEC-ENV-REQ 9:  I2RS Client client or I2RS Agent agent SHOULD also be able to
                   refuse a communication with an Application application or an I2RS Client
                   client when the communication channel does not
                   fulfill enough security requirements.  For example,

   Explanation:

   The participants in the it I2RS Plane (I2RS client, I2RS agent, and I2RS
   application) exchange critical information, and to be effective the
   communication should be trusted and free from security attacks.

   The I2RS client or the I2RS agent should be able to reject messages
   over a communication channel that can be easily hijacked, like a
   clear text UDP channel.

4.1.4.  Sharing access control Information

   For the I2RS client:

   SEC-ENV-REQ 10: The I2RS client MAY request information on its I2RS
                   access control subset policies from the I2RS agent or
                   cache requests that have been rejected by the I2RS
                   agent to limit forwarding unnecessary queries to the
                   I2RS agent.

   SEC-ENV-REQ 11: The I2RS client MAY support receiving notifications
                   when its I2RS access control subset policies have
                   been updated by the I2RS agent.

   Similarly, for the applications:

   SEC-ENV-REQ 12: The applications MAY request information on its I2RS
                   access control subset policies in order to limit
                   forwarding unnecessary queries to the I2RS client.

   SEC-ENV-REQ 13: The applications MAY subscribe to a service that
                   provides notification when its I2RS access control
                   subset policies have been updated.

   For both the application and the client:

   SEC-ENV-REQ 14: The I2RS access control should explicitly specify
                   accesses that are granted.  More specifically,
                   anything not explicitly granted should be denied
                   (default rule).

   Explanation:

   In order to limit the number of access request requests that result in an
   error, each Application application or I2RS Client may be able to client can retrieve the I2RS Access Control access
   control policies that applies to it.  This subset of rules is
   designated as the "Individual I2RS Access Control access control policies".  As
   these policies are subject to changes, a dynamic synchronization
   mechanism should be provided.  However, such mechanism may be
   implemented with different level of completeness and dynamicity of
   the Individual individual I2RS Access Control access control policies.  Caching  One example, may be
   caching transaction requests that have been rejected may rejected.

   I2RS access control should be one such variant. appropriately be balanced between the
   I2RS client and the I2RS agent.  It remains relatively easy to implement and may avoid
   the complete disclosure of the Access
   Control access control policies of the I2RS Agent.  In fact the relative
   agent.  Relative disclosure of Access Control access control policies may leak allow the
   leaking confidential information in case of misconfiguration and should be balanced with misconfiguration.  It is
   important to balance the level of trust of the I2RS Client client and the
   necessity of distributing the enforcement of the Access Control access control
   policies.

   REQ 10: The I2RS Client may be able to request for its I2RS Access
           Control subset policies to the I2RS Agent or cache requests
           that have been rejected by the I2RS Agent to limit forwarding
           unnecessary queries to the I2RS Agent.

   REQ 11: The I2RS Client may be able to be notified when its I2RS
           Access Control subset policies have been updated by the I2RS
           Agent.

   Similarly, for the Applications

   REQ 12: The Applications may be able to request for its I2RS Access
           Control subset policies, so to limit forwarding unnecessary
           queries to the I2RS Client.

   REQ 13: The Applications may be able to subscribe a service that
           provides notification when its I2RS Access Control subset
           policies have been updated.

   I2RS Access Control should be appropriately be balanced between the
   I2RS Client and the I2RS Agent.

   I2RS Access Control access control should not solely rely only on the I2RS Client client or
   the I2RS Agent agent as illustrated below:

   - 1) I2RS Clients clients are dedicated to a single Application: application:   In this
         case, it is likely that I2RS Access Control access control is enforced only by
         the I2RS Agent, agent, as the I2RS Client client is likely to accept all
         access request of the application.  However, it  It is recommended that even
         in this case, I2RS Client Access Control client access control is not based on an
         "Allow anything from application" policy, but instead the I2RS Client
         client specifies accesses that are enabled.  In addition, the
         I2RS Client client may sync its associated I2RS Access Control access control
         policies with the I2RS Agent agent to limit the number of refused
         access requests being sent to the I2RS Agent. agent.  The I2RS Client client
         is expected to balance pro benefits and cons between sync problems with synchronizing
         its access control policies with the I2RS Agent and agent to proxy
         request validation versus simply guessing passing the access request to
         the I2RS Agent. agent.

   - 2) A single I2RS Client client connects to multiple applications or
   acts as a broker for all Applications: many applications:
            In the case the I2RS Agent agent has a single I2RS Client.  Such
         architecture results client
            attached.  This may end up in a situation where the I2RS Client with high privileges,
            client is being delegated by the I2RS agent to enforce
            access control policies.  In such as it
         sums case, the privileges of all applications.  As end-to-end
         authentication is not provided between I2RS agent
            may grant the Application I2RS client with high priviledges and blidngly
            trust the I2RS Agent, if client without enforcing access control
            policies on what the I2RS Client becomes corrupted, client can do.  Such a situation
            must be avoided as it is
         possible could be used by malicious
            applications for a priviledge escalation by compromising the
            I2RS client.  In this situation, the malicious application escalates its privileges
         and make uses the
            I2RS Client client to perform some action on behalf of the
            application with more privileges.  This would that it normally does not have been
         possible with end-to-end authentication. the priviledges
            to perform.  In order to mitigate such attack, the I2RS Client
            client that acts connects to multiple applications or operates as
            a broker is expected to host application with an equivalent
            level of privileges.

   REQ 14: The I2RS

4.1.5.  Sharing Access Control should explicitly specify accesses
           that are granted.  More specifically, anything not explicitly
           granted -- the default rule-- should be denied.

   In addition to in Groups of I2RS Clients and Agents

   Overview:

   To distribute the I2RS Access Control access control policies between I2RS Clients clients
   and I2RS Agents, agents, I2RS Access Control access control policies can also be distributed
   within a set of I2RS Clients clients or a set of I2RS Agents.

   REQ agents.

   Requirements:

   SEC-ENV-REQ 15: I2RS Clients clients should be distributed and act as brokers
                   for
           Applications applications that share roughly similar
                   permissions.  This
           avoids ending with over privileges I2RS Client compared to
           hosted applications and thus discourages applications to
           perform privilege escalation within an I2RS Client.

   REQ

   SEC-ENV-REQ 16: I2RS Agents agents should be avoided being granted over granting extra
                   privileges
           regarding to their authorized I2RS Client. client.  I2RS Agent
                   agent should be shared by I2RS Client client with roughly
                   similar permissions.  More explicitly, an I2RS Agent agent
                   shared between I2RS Clients clients that are only provided
                   read access to the routing system resources does not
                   need to perform any write access, so the I2RS client
                   should not be provided these accesses.

   SEC-ENV-REQ 17: I2RS client and I2RS agent should be able to trace
                   [RFC7922] the various transaction they perform as
                   well as suspicious activities.  These logs should be
                   collected regularly and analyzed by functions that
                   may be out of the I2RS plane.

   Explanation:

   This restriction for distributed I2RS clients to act as brokers only
   for applications with roughly the same priviledges avoids the I2RS
   client extra priviledges compared to hosted applications, and so
           should not be provided these accesses.  Suppose
   discourages applications from perform privilege escalation within an
   I2RS
           Client client.  For example, suppose an I2RS client requires write
   access to the resources.  It is not recommended to grant the I2RS Agent
   agent the write access in order to satisfy a unique I2RS Client. client.
   Instead, the I2RS Client client that requires write access should be
   connected to a I2RS
           Agent agent that is already shared by I2RS Client client that
   requires a write access.

   Access Control control policies enforcement should be monitored in order to
   detect violation of the policies or detect an attack.  Access Control control
   policies enforcement may not be performed by the I2RS Client client or the
   I2RS Agent agent as violation may require a more global view of the I2RS
   Access Control
   access control policies.  As a result, consistency check and
   mitigation may instead be performed by the management plane.
   However, I2RS Clients clients and I2RS Agents agents play a central role.

   REQ 17:

   The I2RS Client and agent can trace transactions that an I2RS Agent should be able client requests it
   to log the various
           transaction they perform, as well as suspicious activities.
           These logs should be collected regularly and analyzed to link this to the application via the secondary
   opaque identifier to the application.  This information is placed in
   a tracing log which is retrieved by
           functions that may be out management processes.  If a
   particular application is granted a level of priviledges it should
   not have, then this tracing mechanism may detect this security
   intrusion after the I2RS plane. instrusion has occurred.

4.1.6.  Managing Access Control Policy

   Access control policies should be implemented so that they the policies
   remain manageable in short and longer term.  This means term deployments of the way they are
   managed today should be address future deployment I2RS
   protocol and use of I2RS.

   REQ the I2RS plane.

   Requirements:

   SEC-ENV-REQ 18: Access Control access control should be managed in an automated way,
                   that is granting or revoking an Application application should
                   not involve manual configuration over the I2RS plane - like all the
                   (I2RS client, I2RS
           Clients.

   REQ agent, and application).

   Explanation:

   Granting or configuring an application with new policy should not
   require manual configuration of I2RS clients, I2RS agents, or other
   applications.

   SEC-ENV-REQ 19: Access Control control should be scalable when the number of
           Application
                   application grows as well as when the number of I2RS Client
                   client increases.

   Explanation:

   A typical implementation of a local I2RS Client
           Access Control client access control
   policies may result in creating manually a system user associated to
   each Application. application.  Such an approach is likely not to scale when the
   number of Applications applications increases or the number of I2RS Client increases.

   REQ

   SEC-ENV-REQ 20: Access Control control should be dynamically managed and easy to be
                   easily updated.

   Explanation:

   Although the number of numberof I2RS Clients clients is expected to be lower than the
   number of Application, application, as I2RS Agent agent provide access to the routing
   resource, it is of primary importance that an access can be granted
   or revoke in an efficient way.

   REQ

   SEC-ENV-REQ 21: I2RS Clients clients and I2RS Agents agents should be uniquely
                   identified in the network to enable centralized
                   management of the I2RS
           Access Control access control policies.

5.2.

   Explanation:

   Centralized management of the access control policies of an I2RS
   plane with network that hosts several I2RS applications, clients and
   agents requires that each devices can be identified.

4.2.  I2RS Agent Access Control policies Policies

   Overview:

   The I2RS Agent Access Control agent access control restricts the routing system resource
   access to authorized identities - possible access policies may be
   none, read or write.  The initiator of an access request to a routing
   resource is always an Application. application.  However, it remains challenging
   for the I2RS Agent agent to establish its access control policies based on
   the application that initiates the request.

   First, when an I2RS
   Client client acts as a broker, the I2RS Agent agent may not
   be able to authenticate the Application. application.  In that sense, the I2RS Agent
   agent relies on the capability of the I2RS Client client to authenticate the Applications
   applications and apply the appropriated I2RS Client Access Control.  Then, client access control.

   Second, an I2RS
   Agent agent may not uniquely identify a piece of software
   implementing an I2RS Client. client.  In fact, an I2RS Client client may be provided
   multiple identities which can be associated to different roles or
   privileges.  The I2RS Client client is left responsible for using them
   appropriately according to the Application.  Finally, application.

   Third, each I2RS Client client may contact various I2RS Agent agent with different
   privileges and access control policies.

4.2.1.  I2RS Agent Access Control
   policies.

   This section provides recommendations on the I2RS Agent Access
   Control agent access
   control policies to keep I2RS Access Control access control coherent within the I2RS
   plane.

   REQ

   Requirements:

   SEC-ENV-REQ 22: I2RS Agent Access Control agent access control policies should be
                   primarily based on the I2RS Clients clients as described in
           [I-D.ietf-i2rs-architecture].

   REQ
                   [RFC7921].

   SEC-ENV-REQ 23: I2RS Agent Access Control agent access control policies may MAY be based on
                   the
           Application.  In this case application if the application identity of the Application
           MUST be has been
                   authenticated by the I2RS Agent, client and passed via the
                   secondary identity used to tag the application as defined in
           [I-D.ietf-i2rs-architecture] should be considered cautiously.
           The tag may be used associated only to an authenticated I2RS
           Client that is known to authenticate its Application.

   The I2RS Agent Access Control policies may evolve over time as
   resource may also be updated outside the I2RS plane.  Similarly, a
   given resource may be accessed by multiple I2RS users within the I2RS
   plane.  Although this is considered as an error, depending on the
   I2RS Client that performed the update, the I2RS may accept or refuse
   to overwrite the routing system resource.

   REQ agent.

   SEC-ENV-REQ 24: The I2RS Agent agent should know which identity (most likely (E.g.
                   system user) performed the latest update of the
                   routing resource.  This is true for an identity
                   inside and outside the I2RS
           plane, plane so the I2RS Agent agent
                   can appropriately perform an update according to the
                   priorities associated to the requesting
           identity and requesting identity and
                   the identity that last updated the resource.

   SEC-ENV-REQ 25: the I2RS agent should have a "I2RS agent overwrite
                   Policy" that indicates how identities can be
                   prioritized.  This requirements is also described in
                   section 7.6 of [RFC7921].  Similar requirements exist
                   for components within the I2RS plane, but this is
                   within the scope of the I2RS protocol security
                   requirements
                   [I-D.ietf-i2rs-protocol-security-requirements].

   Explanation:

   If the I2RS application is authenticated to the I2RS client, and the
   I2RS client is authenticated to the I2RS agent, and the I2RS client
   uses the opaque secondary identifier to pass an authenticated
   identifier to the I2RS agent, this may be used for access control.
   However, caution should be taken when using this chain of
   authentication since the secondary identifier is intended in the identity that last updated I2RS
   protocol for tracing.

   From the resource.  On
           an environment perspective, perspective the I2RS Agent agent MUST be aware when
   the resource has been modified outside the I2RS plane, as
           well as its priority associated towards plane by another
   plane (management, control, or forwarding).  The prioritization
   between the different planes should set a deterministic policy that
   allows the collision of two planes (I2RS plane and another plane) to
   be resolved via an overwrite policy in the I2RS plane. agent.

   Similar requirements exist for knowledge about identities within the
   I2RS
           plane, plane which modify things in the routing system, but belongs to this is
   within the protocol security requirements.

   REQ 25: scope of the I2RS Agent should have a "I2RS Agent overwrite Policy"
           that indicates how identities can be prioritized.  This protocol's requirements is also described in section 7.6 of
           [I-D.ietf-i2rs-architecture].  Similar requirements exist for
           components within the I2RS plane, but belongs to the protocol ephemeral
   state [I-D.ietf-i2rs-ephemeral-state] and security requirements.

5.3. requirements
   [I-D.ietf-i2rs-protocol-security-requirements].

4.2.2.  I2RS Client Access Control policies Policies

   Overview:

   The I2RS Client Access Control client access control policies are responsible for
   authenticating the application managing the privileges for the
   applications, and enforcing access control to resources by the
   applications.  As a result,

   Requirements:

   REQ 26: I2RS Client client should authenticate its applications.  If the
           I2RS Client client acts as a broker and supports multiple
           Applications,
           applications, it should authenticate each of them.
           Authentication of the application may used GSSAPI, Secure RPC
           mechanisms. application.

   REQ 27: I2RS Client client should define Access Control access control policies associated
           to each applications.  An access to a routing resource by an
           Application
           application should not be forwarded immediately and
           transparently by the I2RS Client client based on the I2RS Agent Access Control agent
           access control policies.  The I2RS Client client should first check
           whether the Application application has sufficient privileges, and if so
           send an access request to the I2RS
           Agent.  When an I2RS Client has multiple identities that are
           associated with different privileges.  The I2RS Client Access
           Control policies should specify the associated I2RS Client's
           identities, especially, when the I2RS Agent Access Control
           policies are changed for a given I2RS Client's identity.

   In case, agent.

   Explanation:

   If no authentication mechanisms have being provided between the I2RS Client
   client and the application, then I2RS Client may not act as
   broker, and client must be instead dedicated to a
   single application.  By doing so, application authentication may rely relies
   on the I2RS authentication mechanisms between the I2RS Client client and the
   I2RS Agent.  On the other
   hand, although this is not recommended, agent.

   If an I2RS client has multiple identities that are associated with
   different privileges for accessing an I2RS agent(s), the I2RS Access Control client
   access control policies is only enforced by should specify the I2RS client identity with
   the I2RS Agent.

5.4. access control policy.

4.2.3.  Application and Access Control policies

   Application does Policies

   Overview

   Applications do not enforce access control policies.  Instead these
   are enforced by the I2RS Clients clients and the I2RS Agents. agents.  This section
   provides recommendations for Applications applications in order to ease I2RS
   Access Control
   access control by the I2RS Client client and the I2RS Agent.

   As multiple ways may agent.

   Requirements:

   SEC-ENV-REQ 28: applications SHOULD be used for an Application uniquely identified by their
                   associated I2RS clients

   Explanation:

   Different application may use different methods (or multiple methods)
   to communicate with its associated I2RS Client, it is client, and each application
   may not expected that all Applications use the same conventional identifier format across form of an application identifier.  However, the
   I2RS plane.
   However, if all Applications are running on a dedicated system
   sharing client must obtain an I2RS Client, it is expected identifier for each Application may uniquely
   identified, application.  One
   method for example using different this identification can be a system users.

   REQ 28: Applications user id.

   SEC-ENV-REQ 29: Each application SHOULD be uniquely identified by their associated to a restricted
                   number of I2RS Clients client

   Explanation:

   The I2RS Client client provides access to resource on its behalf and this
   access should only be granted for trusted applications, or
   Applications
   applications with an similar level of trust.  On the other hand, this  This does not prevent
   an I2RS Client client to host a large number of
   Applications.  Similarly, an Application may also require to access
   multiple I2RS Clients depending on applications with the resource to be accessed.  As
   I2RS Client are restricted for a subset of Applications,

   REQ 29: Each Application SHOULD be associated to a restricted number same
   levels of I2RS Client

   REQ trust.

   SEC-ENV-REQ 30: Application An application SHOULD be provided means and methods
                   to contact their associated I2RS Client.  If the client.

   Explanation:

   It is obvious when an I2RS Client client belongs to the Application (as application as part
   of a module or a library for example), or
           when that the Application application can communicate with a
   I2RS client.  Similarly, if the application runs into a dedicated
   system (like a
           container) with a I2RS Client, client, it is obvious which I2RS
           Client client the Application is associated to.  On
   application should contact.  If the other hand,
           Applications may also remotely access application connects to the I2RS Client.  In
           this case,
   client remotely, the Application is expected to be provided application needs some
           means to be able to retrieve the necessary information to
           contact its associated I2RS Client.  The IP address may not
           be appropriated in case renumbering occurs within the network
           or in case the traffic from Applications should be shared
           between multiple instances of a given
   the necessary information to contact its associated I2RS Client.  In this
           case client (e.g.
   an IP address or a FQDN may be preferred.

6. FQDN).

5.  I2RS Application Isolation

   A key aspect of the I2RS architecture is the network oriented
   application.  As these application are supposed to be independent,
   controlled by independent and various tenants.  In addition to
   independent logic, these applications may be malicious.  Then, these
   applications introduce also programmability which results in fast
   network settings.

   The I2RS architecture should remain robust to these applications and
   make sure an application does not impact the other applications.
   This section discusses both security aspects related to
   programmability as well as application isolation in the I2RS
   architecture.

6.1.

5.1.  Robustness toward programmability Toward Programmability

   Overview

   I2RS provides a programmatic interface in and out of the Internet
   routing system.  This feature, in addition to the global network view
   provided by system which provides the centralized architecture comes with a few following advantages
   in term of security.

   The for security

   o  the use of automation reduces configuration errors.  In addition,
   this errors

   o  the programmatic interface enables fast network reconfiguration.  Agility
   provides a key advantage reconfiguration
      and agility in term of deployment as side effect
   configuration may be easily addressed.  Finally, it also provides adapting to network attacks,

   o  monitoring facilities to monitor detect and configuration to mitigate an attack when the a
      network is
   under attack.

   On the other hand programmability also comes with a few drawbacks.
   First,

   Programmability allows applications can to flexible control which may
   cause problems due to:

   o  applications which belong to multiple different tenants with different
   objectives.  This absence of
      objectives,

   o  applications which lack coordination may result resulting in unstable routing
      configurations such as oscillations between network
      configurations, and creation of loops for example.  A typical example
   would be an  For example,
      one application monitoring may monitor a state and changing its state.
   If another change to positive, and a
      second application performs the reverse operation, the operation (turns it
      negative).  This fluctuation can cause a routing system may to become
      unstable.  Data

   The I2RS plane requires data and application isolation is
   expected to prevent
   such situations to happen, however, happen.  However, to guarantee the network stability,
   stability constant monitoring and error detection are recommended to
   be activated.

   REQ

   Requirement:

   SEC-ENV-REQ 31: The I2RS Agents agents should monitor constantly parts of
                   the system for which I2RS Clients clients or Applications applications
                   have provided requests.  It should also be able to
                   detect I2RS Clients clients or
           Applications applications that lead the
                   routing system in an unstable state.

   Explanation:

   Monitoring consists at least in logging events and eventually provide
   notifications or alerts to the management
           plane in case, something has been detected.  The management
           plane is in charge of collecting management plane in case, something
   has been detected.  The management plane is in charge of collecting
   the logs, the notifications and eventually to consider the
   appropriated actions.  A typical action may be the update of I2RS
   access control policies for example or re-configuring routing
   elements.

5.2.  Application Isolation

5.2.1.  DoS

   Overview:

   Requirements for robustness to DoS attacks have been addressed in the
   communication channel section [RFC7921].  This section focuses on
   requirements for application isolation that help prevent DoS.

   Requirements:

   SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS
                   agent controls the resources allocated to each I2RS
                   clients.  I2RS client that acts as broker may not be
                   protected as efficiently against these attacks unless
                   the broker performs resource controls for the logs, hosted
                   applications.

   SEC-ENV-REQ 33: I2RS agent does not make response redirection
                   possible unless the notifications redirection is previously
                   validated and eventually to consider agreed by the appropriated actions.  A
           typical action may be destination.

   SEC-ENV-REQ 34: avoid the update use of I2RS Access Control
           policies for example or re-configuring routing elements.

6.2.  Application Isolation

6.2.1.  DoS

   Requirements for robustness underlying protocols that are not
                   robust to Dos Attacks have been addressed in the
   Communication channel section [I-D.ietf-i2rs-architecture]. reflection attacks.

   Explanation:

   The I2RS interface is used by application to interact with the
   routing states.  As the I2RS Agent agent is shared between multiple
   applications, one application can prevent an application by
   performing DoS or DDoS attacks on the I2RS Agent agent or on the network.
   DoS attack targeting the I2RS Agent agent would consist in providing
   requests that keep the I2RS Agent agent busy for a long time.  This  These
   attacks on the I2RS agent may involve an application (requesting
   through an I2RS Client) heavy computation by the I2RS Agent for example agent in order
   to blocking block operations like disk access.  In addition,

   Some DoS attacks targeting the
   network may use specific commands like attack the I2RS Client's reception of
   notification and monitoring data stream over the network.  Then,  Other DoS attack
   attacks may be also targeting focus on the application directly by performing
   reflection attacks.  Such an attack could be performed by indicating the target first
   detecting an application as the target for some
   information like the listing of the RIB.  Reflection may be performed
   at various levels and can be based on the use of UDP or at the
   service level like redirection of information to a specific
   repository.

   REQ 32: In order to prevent DoS, it is recommended related to monitoring the I2RS Agent
           controls RIB or changing
   the resources allocated to each I2RS Clients.  I2RS
           Client that acts as broker RIB.

   Reflection-based DoS may not be protected as
           efficiently against these attacks unless they perform
           resource controls themselves of their hosted applications.

   REQ 33: I2RS Agent does not make response redirection possible unless
           the redirection is previously validated and agreed by the
           destination.

   REQ 34: avoid the use of underlying protocols that are not robust performed at various levels utilizing UDP
   at the service to
           reflection attacks.

6.2.2. redirect data to a specific repository.

5.2.2.  Application Logic Control

   Overview

   Requirements for Application Control application control have been addressed in the I2RS
   plane isolation as well as in the trusted Communication Channel
   sections.

   Applications use the I2RS interface in order to update the routing
   system.  These updates may be driven by behavior on the forwarding
   plane or any external behaviors.  In this case, correlating
   observation to the I2RS traffic may enable to derive the application
   logic.  Once the  This section examines how application logic has been derived, a malicious
   application may generate traffic or any event in the network in order must be design
   to activate the alternate application.

   REQ ensure application isolation.

   Requirements:

   SEC-ENV-REQ 35: Application application logic should remain opaque to external
                   listeners.
           Application application logic may be partly hidden by
                   encrypting the communication between the I2RS Client client
                   and the I2RS Agent. agent.  Additional ways to obfuscate the
                   communications may involve sending random messages of
                   various sizes.  Such strategies have to be balanced
                   with network load.  Note that I2RS Client client broker are
                   more likely to hide the application logic compared to
                   I2RS Client client associated to a single application.

7.

   Explanation:

   Applications use the I2RS interface in order to update the routing
   system.  These updates may be driven by behavior on the forwarding
   plane or any external behaviors.  In this case, correlating
   observation to the I2RS traffic may enable to derive the application
   logic.  Once the application logic has been derived, a malicious
   application may generate traffic or any event in the network in order
   to activate the alternate application.

6.  Security Considerations

   The whole document is about security.

8.  Privacy Considerations

9. security requirements for the I2RS
   environment.  To protect personal privacy, any identifier (I2RS
   application identifier, I2RS client identifier, or I2RS agent
   identifier) should not contain personal identifiable information.

7.  IANA Considerations

10.

   No IANA considerations for this requirements.

8.  Acknowledgments

   A number of people provided a significant amount of helping comments
   and reviews.  Among them the authors would like to thank Russ White,
   Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas,
   Alia Atlas, and Linda Dunbar

11. Dunbar.

9.  References

11.1.

9.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-i2rs-architecture]

   [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", draft-ietf-i2rs-architecture-09 (work in
              progress), March 2015. 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>.

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

9.2.  Informative References

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

Authors' Addresses

   Daniel Migault (editor)
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com

   Joel Halpern
   Ericsson

   Email: Joel.Halpern@ericsson.com
   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com