<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC7920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7920.xml">
<!ENTITY RFC7921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7921.xml">
<!ENTITY RFC7922 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7922.xml">
<!ENTITY RFC7923 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7923.xml">
<!ENTITY RFC8241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8241.xml">
<!ENTITY RFC8242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8242.xml">
<!ENTITY I-D.ietf-netmod-revised-datastores
  SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-revised-datastores.xml">
<!ENTITY I-D.ietf-netconf-rfc6536bis
  SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-rfc6536bis.xml">

]>


<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes"?>

<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="4"?>

<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>

<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" ipr="trust200902" docName="draft-ietf-i2rs-security-environment-reqs-06">
  <front>
    <title abbrev="I2RS Environment Security Requirements">I2RS Environment Security Requirements</title>

    <author fullname="Daniel Migault" initials="D." surname="Migault">
      <organization> Ericsson </organization>
      <address>
        <postal>
          <street> 8400 boulevard Decarie </street>
          <city> Montreal, QC </city>
          <code> H4P 2N2 </code>
          <country> Canada </country>
        </postal>
        <phone> +1 514-452-2160 </phone>
        <email> daniel.migault@ericsson.com </email>
      </address>
    </author>

    <author fullname="Joel Halpern" initials="J.H." surname="Halpern">
      <organization>Ericsson</organization>
      <address>
        <email>Joel.Halpern@ericsson.com</email>
      </address>
    </author>
    <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
      </address>
    </author>

    <date/> <!-- <date day="4" month="March" year="2015"/> -->
    <area> Routing Area </area>
    <workgroup> I2RS WG </workgroup>

    <abstract>
    <t>This document provides environment security requirements for the I2RS architecture. 
	Environment security requirements are independent of the protocol used for I2RS. 
    The security environment requirements are the good security practices to be used 
    during implementation and deployment of the code related to the new interface 
    to routing system (I2RS) so that I2RS implementations can be securely deployed and operated. </t>
    <t>Environmental security requirements do not specify the I2RS protocol seecurity requirements. 
    This is done in another document (draft-ietf-i2rs-protocol-security-requirements). 
	</t> 
    </abstract>

  </front>
  <middle>

    <section title="Introduction" anchor="sec-intro">	
    <t>
	This document provides environment security requirements for the I2RS architecture. 
	Environment security requirements are independent of the protocol used for I2RS. 
	The I2RS protocol security requirements <xref target="RFC8241"></xref>
	define the security for the communication between 
	I2RS client and agent.   The security environment requirements are good security practices
    to be used during implementation and deployment of the I2RS protocol 
    so that I2RS protocol implementations can be securely deployed and operated.  These environment security 
    requirements address the security considerations described in the I2RS Architecture <xref target="RFC7921"></xref> 
    required to provide a stable and secure environment in which the dynamic programmatic interface to the 
    routing system (I2RS) should operates.  
	 </t> 
     <t>Even though the I2RS protocol is mostly concerned with the interface between the I2RS client and the I2RS agent, 
	 the environmental security requirements must consider the entire I2RS architecture and 
	 specify where security functions may be hosted and what criteria should be met in order to 
	 address any new attack vectors exposed by deploying this architecture. 
	 Environment security for I2RS has to be considered for the complete I2RS architecture 
	 and not only on the protocol interface.</t>
      <t>This document is structured as follows: 
	  <list style="symbols">
	  <t>Section 2 describes the terminology used in this document,</t>
	  <t><xref target="sec-i2rs-plane-isolation"/> describes how the I2RS plane can be securely
	  isolated from the management plane, control plane, and forwarding plane.
	  </t>
      </list>
	  </t>
	  <t>The subsequent sections of the document focus on the security within the I2RS plane.
      </t>
       <t>
      <list style="symbols">
	  <t> <xref target="sec-i2rs-aaa"/> analyses how the I2RS access control policies can be 
	deployed throughout the I2RS plane in order to limit access to the routing system resources 
	to authorized components with the authorized privileges. This analysis examines how 
	providing a robust communication system between the components aids the access control. 
     </t>
	 <t> <xref target="sec-i2rs-application-isolation"/> details how I2RS keeps applications 
	 isolated from another and without affecting the I2RS components. 
	 Applications may be independent, with different scopes, owned by different tenants. 
	 In addition, the applications may modify the routing system in an automatic way.
	 </t>
	  </list>
      </t>
	  <t>
	  Motivations are described before the requirements are given.
	  </t>
      <t>The reader is expected to be familiar with the I2RS problem statement <xref target="RFC7920"></xref>,
      I2RS architecture, <xref target="RFC7921"/>, traceability requirements <xref target="RFC7922"></xref>,
	  I2RS Pub/Sub requirements <xref target="RFC7923"></xref>, I2RS ephemeral state requirements 
	  <xref target="RFC8242"></xref>, I2RS protocol security requirements
	  <xref target="RFC8241"></xref>.
    </t>
    </section>
    <section title="Terminology and Acronyms">
    <t>
        <list hangIndent="6" style="hanging">
            <t hangText="- Environment Security Requirements : "> Security requirements specifying how the environment 
            a protocol operates in needs to be secured.  These requirements do not specify 
			the protocol security requirements.
			</t> 
            <t hangText="- I2RS plane: "> The environment the I2RS  process is running on. It includes the applications, 
			the I2RS client, and the I2RS agent.</t> 
            <t hangText="- I2RS user: "> The user of the I2RS client software or system.</t> 
	    <t hangText="- I2RS access control policies: "> The policies controlling access of the routing resources by applications. 
		These policies are divided into policies applied by the I2RS client regarding applications and 
		policies applied by the I2RS agent regarding I2RS clients.</t>
	    <t hangText="- I2RS client access control policies: "> The access control policies processed by the I2RS client. </t>
	    <t hangText="- I2RS agent access control policies: "> The access control policies processed by the I2RS agent. </t>
       </list> 
     </t>
	 
  <section title="Requirements notation">
   <t>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 <xref target="RFC2119"/>.</t>
    </section>
    </section>

<section title="I2RS Plane Isolation" anchor="sec-i2rs-plane-isolation">

<t>Isolating the I2RS plane from other network planes (the management, forwarding, and control planes) is fundamental to the security of the I2RS environment. 
Clearly differentiating the I2RS components from the rest of the network device does the following: 
<list style="numbers"> 
<t>protects the I2RS components from 
vulnerabilities in other parts of the network, 
</t>
<t>protects other systems vital to the health of the network 
from vulnerabilities in the I2RS plane. 
</t>
</list>
</t>
<t>
Separating the I2RS plane from other network control and forwarding planes is 
similar to the best common practice of placing software into software containers within 
modules with clear interfaces to exterior modules. In a similar way, although the I2RS plane  
cannot be completely isolated from other planes, it can be carefully designed 
so the interactions between the I2RS plane and other planes can be identified and controlled. 
The following is a brief description of how the I2RS plane positions 
itself in regard to the other planes. 
</t> 
<section title="I2RS Plane and Management plane">
<t>The purpose of the I2RS plane is to provide a standard programmatic 
interface to the routing system resources to network oriented applications. 
Routing protocols often run in a control plane and provide entries
for the forwarding plane as shown in figure 1.  The I2RS plane contains 
the I2RS applications, the I2RS client, the north bound interface between the
I2RS client and I2RS applications, the I2RS protocol, the I2RS agent, and the
south bound API (SB API) to the routing system. The communication 
interfaces in the I2RS plane are shown on the the left hand side of figure 1.  
</t>
<t>The management plane contains the mangement application, the 
management client, the north bound API between the management client
and management application, the mangement server, the 
management protocol (E.g. RESTCONF) between mangement client and 
management server, and the south bound API between the management 
server and the control plane. The communication interfaces associated
with the management plane are shown on the right hand side of figure 2. 
</t>
 <t>
 The I2RS plane and the management plane both interact with the
 control plane on which the routing systems operate. 
 <xref target="RFC7921"/> describes several of these interaction points 
 such as the local configuration, the static system state, routing, and signaling.
 A routing resource may be accessed by I2RS plane, the mangement plane,
 or routing protocol(s) which creates the potential for overlapping access. 
 The southbound APIs can limit the scope of the management plane's 
 and the I2RS plane's interaction with the routing resources.
</t>
<t>
Security focus:
</t>
<t>
Data can be read by I2RS plane from configuration 
as copy of configuration data, or by management plane as 
copies of the I2RS plane.  The problem is when the I2RS plane 
installs the routing plane as its new configuration or the 
management plane installs the I2RS plane information as 
management plane configuration.  In this circumstance, we define "infecting" as 
interfering with and leading into a incoherent state.  Planned interactions 
such as interactions denoted in in two cooperating Yang data modules is not an incoherent state.
</t> 
<t>
The primary protection in this space is going to need to be validation rules on: 
<list style="symbols">
<t>the data being sent/received by the I2RS agent (including notification of changes that 
the I2RS agent sends the I2RS client),  </t>
<t> any data transferred between management datastores 
  (configuration or operational state) and 
I2RS ephemeral control plane data stores; 
</t>
<t>data transferred between I2RS Agent and Routing system, 
</t>
<t>data transferred between a management server and the I2RS routing system, 
</t>
<t>data transferred between I2RS agent and system (e.g. interfaces ephemeral configuration), 
</t>
<t>data transferred between management server and the system (e.g. interface configuration).  
</t>
</list> 
</t>
<t>
<figure>
<artwork> 

   APIs that interact with the 
   I2RS Plane and Management Plane 

  I2RS applications     Mangement applications 
   || NB API                  NB API ||
   ||                                ||
   I2RS plane           management plane 
   || control plane     configuration||
   || datastore            datastore ||
   ||                                ||
   ||SB API                   SB API ||
   ---------------------------------------
   | Routing System with protocols       |&lt;protocols&gt; 
   | control plane                       | 
   | (applied datastore)                 | 
   +-------------------------------------+
   |  forwarding plane                   |
   +-------------------------------------+
   |   system                            |
   +-------------------------------------+
   
   Figure 1 - North Bound (NB) APIs and 
              South Bound (SB) APIs

</artwork>
</figure>
</t>
</section>     
<section title="I2RS Plane and Forwarding Plane">
 <t>Applications hosted by the I2RS client belong to the I2RS plane. 
It is difficult to constrain these applications to the I2RS plane, or even to 
limit their scope within the I2RS plane. Applications using I2RS 
may also interact with components outside the I2RS plane. 
For example an application may use a management client to
 configure the network and monitored events via an I2RS agent
 as figure 4 shows. 
</t>
<t>
<figure>
<artwork>
 +--------------------------------------+
 |       Application                    | 
 +--------------------------------------+  
   || NB API                 NB API ||
   || I2RS client        mgt client ||
   ||                               || 
    I2RS protocol        mgt protocol
                         (NETCONF/RESTCONF) 

   figure 2 
</artwork>
</figure>
</t>
<t> 
 Applications may also communicate with 
 multiple I2RS clients in order to have a broader view of the 
 current and potential states of the network and the I2RS plane itself.  
 These varied remote communication relationships between applications using 
 the I2RS protocol to change the forwarding plane make it possible for 
 an individual application to be an effective attack vector against 
 the operation of the network, a router's I2RS plane, 
 the forwarding plane of the routing system, and other planes (management and control planes).
 </t>
 <t>Prevention measures: 
 </t>
 <t> 
Systems should consider the following prevention errors: 
 <list style="hanging">
 <t hangText="application validation -"> There is little the I2RS plane can do 
 to validate applications with which it interacts. 
 The I2RS client passes the I2RS agent an unique identifier for the application so that an 
 application's actions can be traced back to the application. 
 </t>
 <t hangText ="Validation against common misconfigurations or errors -">
 One way of securing the interfaces between application, the I2RS plane, and the forwarding plane 
 is to limit the information accepted and to limit the rate information is accepted between 
 these three software planes.  Another method is to perform rudimentary checks on the 
 results of any updates to the forwarding plane. 
</t>
</list>
</t>
</section>
<section title="I2RS Plane and Control Plane">
<t>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. 
I2RS client configures, monitors or receives events via the I2RS agent's 
interaction with the routing system including the process that 
handles the control plane signalling protocols (BGP, ISIS, OSPF, etc.), 
route information databases (RIBs), and interface databases. 
In some situations, to manage an network outage or to control traffic, 
the I2RS protocol may modify information in the route database or 
the configuration of routing process.  While this is not a part of 
normal processing, such action allows the network operator 
to bypass temporary outages or DoS attacks. 
</t>
<t>This capability to modify the routing process information
carries with it the risk that the I2RS agent may 
alter the normal properties of the routing protocols 
which provide normal loop free routing in the control plane.
For example, information configured by the 
I2RS agent into routing process or RIBs could cause 
forwarding problems or routing loops.  As a second example, 
state which is inserted or deleted from routing
processes (control traffic, counters, etc.) could cause the routing 
protocols to fail to converge or loop). 
</t>
<t>Prevention measures:</t>
<t>The I2RS implementation can provide internal checks after a
routing system protocol change that it is still operating correctly. 
These checks would be specific to the routing protocol the I2RS Agent 
would change. For example, if a BGP maximum prefix limit for a 
BGP peer is lowered then the BGP peer should not allow 
the number prefixes received from that peer to exceed this number.  
</t>
</section>
<section title="Requirements">
<t>To isolate I2RS transactions from other planes, it is required that: 
<list style="format SEC-ENV-REQ %d:" counter="my_count">
<t>Application-to-routing system resources communications should use an isolated 
communication channel. Various levels 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 (e.g. using vLAN). 
In a virtual environment that shares a common infrastructure, encryption may also be 
used as a way to enforce isolation. Encryption can be added by 
using a secure transport required by the I2RS protocol security 
<xref target="RFC8241"></xref>, and 
sending the non-confidential I2RS data (designed for a non-secure transport)
 over a secure transport. 
</t>
<t>The interface 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.  Isolation may also
 be achieved by using a dedicated IP address or a dedicated port.
 </t>    
 <t>An I2RS agent SHOULD have specific permissions
 for interaction with each routing element and access to the routing element 
should governed by policy specific to the I2RS agent's interfaces (network, 
routing system, system, or cross-datastore).  
 </t>
</list>
 </t>
 <t>Explanation:</t>
 <t>When the I2RS agent performs an action on a routing element, 
 the action is performed in a process (or processes) associated with a
 routing process. For example, in a typical UNIX system, the user is 
 designated with a user id (uid) and belongs to groups designated by group ids (gid). 
If such a user id (uid) and group id (gid) is the identifier for the routing 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 the routing processes have their own identifier so that access control 
can uniquely filter data between I2RS Agent and routing processes. 
 </t>
<t>The specific policy that the I2RS agent uses to filter data from the network 
or from different processes on a system (routing, system or cross-datastore) 
should be specific to the I2RS agent.  For example, the network access filter 
policy that the I2RS agent uses should be uniquely identifiable from the 
configuration datastore updated by a management protocol. 
</t>
  <t>
  <list style="format SEC-ENV-REQ %d:" counter="my_count">
   <t>The I2RS plane should be informed when a routing
   system resource is modified by a user outside the I2RS plane access. 
   Notifications from the control plane SHOULD not be allowed
   to flood the I2RS plane, and rate limiting (or summarization)
   is expected to be applied.  These routing system notifications 
   MAY translated to the appropriate I2RS agent notifications, and 
   passed to various I2RS clients via notification relays. 
   </t>
   </list>
   </t>
   <t>
   	Explanation:
	</t>
   <t> This requirements is also described in section 
   7.6 of <xref target="RFC7921"></xref> for the I2RS client, 
   and this section extends it to the entire I2RS plane 
   (I2RS agent, client, and application).
    </t> 
	<t>A routing system resource may be accessed by management 
    plane or control plane protocols so a change to a routing 
    system resource may remain unnoticed unless and until 
    the routing system resource notifies the I2RS plane
    by notifying the I2RS agent. 
    Such notification is expected to trigger
    synchronization of the I2RS resource state between 
    the I2RS agent and I2RS client - signalled by the 
    I2RS agent sending a notification to an I2RS client. 
    </t>
    <t> 
    The updated resource should be available in the 
    operational state if there is a yang module referencing 
    that operational state, but this is not always the case. 
    In the cases where operational state is not updated, 
    the I2RS SB (southbound) API should include the ability to 
    send a notification.  
    </t> 
    <t>
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
	<t>I2RS plane should define an "I2RS plane overwrite policy". 
	Such policy defines how an I2RS is able to update and overwrite a 
	resource set by a user outside the I2RS plane. Such hierarchy 
	has been described in section 6.3 and 7.8 of <xref target="RFC7921"/>
	</t>
	</list> 
	</t>	
	<t>Explanation:
	</t>
	<t>A key part of the I2RS architecture is notification regarding 
	routing system changes across the I2RS 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 I2RS plane and the routing 
	systems the I2RS plane attaches to remains untouched by the other planes 
	or the I2RS plane is notificed of such changes. Section 6.3 of
	<xref target="RFC7921"></xref> describes how the I2RS agent within 
	the I2RS plane interacts with forwarding plane's local configuration, 
	and provides the example of an overwrite policy between the I2RS plane and 
	local configuration (instantiated in 2 Policy Knobs) that operators 
    may wish to set. The prompt notification of any outside overwrite 
	is key to the architecture and proper interworking of the I2RS Plane. 
	</t>
	</section>
</section>
 <section title="I2RS Access Control for Routing System Resources" anchor="sec-i2rs-aaa">
	<t>This section provides recommendations on how the I2RS plane's access control 
    should be designed to protect the routing system resources.  These 
	security policies for access control only apply within the I2RS plane.  
	More especially, the policies are associated to the applications, I2RS clients and 
	I2RS agents, with their associated identity and roles.</t>
    <t>The I2RS deployment of I2RS applications, I2RS clients, and I2RS agents can be located locally 
    in a closed environment or distributed over open networks.  The normal 
    case for routing system management is over an open environment.  Even in a closed 
	environment, access control policies should be carefully defined to 
	be able to, in the future, carefully extend the I2RS plane to remote applications 
	or remote I2RS clients. 
	</t>
	<t><xref target="RFC8241"/> 
	defines the security requirements of the I2RS protocol between the
	I2RS client and the I2RS agent over a secure transport. 
	This section focuses on I2RS access control architecture (section 4.1), 
	access control policies of the I2RS agent (section 4.2), 
	the I2RS client (section 4.3), and the application (section 4.4). 
	</t>
 <section title="I2RS Access Control Architecture">
<t>Overview:</t>
<t>Applications access the routing system resource via numerous 
	intermediate nodes. The application communicates with an I2RS client. 
	In some cases, the I2RS client is only associated with a single application attached
	to one or more agents (case a and case b in figure 4 below).  In other cases, the 
	I2RS client may be connected to two applications (case c in figure 4 below),
	or the I2RS may act as a broker (agent/client device shown in case d in 
	figure 4 below). The I2RS client broker approach provides scalability to the I2RS architecture
	as it avoids each application being registered to the I2RS agent. Similarly, 
	the I2RS access control should be able to scale to numerous applications.
	</t>
<t>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 client to the I2RS agent).  The I2RS agent must trust the 
I2RS client's actions without having an ability to verify the 
I2RS client's actions. 
</t>
<t>
	<figure>
    <artwork>
	
  a) I2RS application-client pair talking 
     to 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|
  +-------------+  +--------+      +-------+ +-------+

  figure 3 
	</artwork>	
	</figure>
	</t>
 <section title="Access control Enforcement Scope">
 <t>
 <list style="format SEC-ENV-REQ %d:" counter="my_count">
	 <t>I2RS access control should be performed through the whole I2RS plane. 
	 It should not be enforced by the I2RS agent only within the 
	 routing element. Instead, the I2RS client should enforce the 
	 I2RS client access control against applications and the 
	 I2RS agent should enforce the I2RS agent access control 
	 against the I2RS clients. The mechanisms for the 
	 I2RS client access control are not in scope of the 
	 I2RS architecture <xref target="RFC7921"/>, 
	 which exclusively focuses on the I2RS agent access control
	 provided by the I2RS protocol.</t> 
 </list>
 </t>
 <t>Explanation: 
 </t>
 <t>This architecture results in a layered and hierarchical or multi-party I2RS access control.
 An application will be able to access a routing system resource only 
 if both the I2RS client is granted access by the I2RS agent and 
 the application is granted access by the I2RS client. 
 </t>
</section> 
<section title="Notification Requirements">
 <t>
 <list style="format SEC-ENV-REQ %d:" counter="my_count">
     <t>When an access request to a routing resource is refused by one party 
	 (the I2RS client or the I2RS agent), the requester
	 (e.g the application) as well as all intermediaries should indicate 
	 the reason the access has not been granted, and which entity rejected
	 the request.</t>
 </list>
 </t>
 <t>Explanation:
 </t>
	 <t>In case the I2RS client access control or the I2RS agent access 
	 control does not grant access to a routing system resource, the 
	 application should be able to determine whether its request has 
	 been rejected by the I2RS client or the I2RS agent as well as the 
	 reason that caused the reject. 
	 </t>
	 <t>
	 SEC-REQ-07 indicates the I2RS agent may reject the request because
     the I2RS client is not an authorized I2RS client or lacks the privileges to 
     perform the requested transaction (read, write, start notifications or logging).	 
	 The I2RS client should be notified of the reason the I2RS agent rejected 
	 the transaction due to a lack of authorization or privileges, and the I2RS client should return a 
	 message to the application indicating the I2RS agent reject the transaction with 
	 an indication of this reason.  Similarly, if the I2RS client does not grant the access to the application, 
	 the I2RS client should also inform the application. An example of an error message could be, 
	 "Read failure: you do not have read permission",  "Write failure: you do not have write permission",
	 or "Write failure: resource accessed by someone else". 
	 </t>
	 <t> This requirement has been written in a generic manner as it relates to the following interactions:
	 <list style="symbols">
	 <t>interactions between the application and the I2RS client,
	 </t>
	 <t>interactions between the I2RS client and the I2RS agent at a content level
      (Protocol security requirements are described by 	 
	 <xref target="RFC8241"></xref>), and 
	 </t> 
	 <t>interactions between the I2RS agent and the I2RS routing system (forwarding plane, 
	  control plane, and routing plane). 
	 </t>
	</list> 
	</t>
</section> 
<section title="Trust">
<t>
 <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>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 other, and communication between 
	them should also be trusted (e.g. TLS) in order to reduce 
	additional vectors of attacks.
	</t>
    <t>I2RS client or I2RS agent SHOULD also be able to refuse a communication with an 
	 application or an I2RS client when the communication channel does not fulfill enough 
	 security requirements. 
	 </t>
    </list> 
	</t>
	<t>Explanation:</t>	
	<t>The participants in the 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. 
	</t>
    <t>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. 
	</t>
</section> 
<section title="Sharing access control Information">
  <t> For the I2RS client: 
  <list style="format SEC-ENV-REQ %d:" counter="my_count">
	  <t>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.</t>
	  <t>The I2RS client MAY support receiving notifications when its
	  I2RS access control subset policies have been updated by the I2RS agent.</t>  
  </list>
  </t>
  <t>Similarly, for the applications: 
  <list style="format SEC-ENV-REQ %d:" counter="my_count">
	  <t>The applications MAY request information on its I2RS access control subset policies
	  in order to limit forwarding unnecessary queries to the I2RS client.</t>
	  <t>The applications MAY subscribe to a service that provides notification
	  when its I2RS access control subset policies have been updated.</t>  
 </list> 
 </t> 
    <t>  For both the application and the client: 
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>The I2RS access control should explicitly specify accesses that are granted. 
	 More specifically, anything not explicitly granted should be denied (default rule). </t>
  </list>
  </t>
    <t>Explanation: 
	</t>
	<t>In order to limit the number of access 
	requests that result in an error, each application or I2RS client can retrieve the 
	I2RS access control policies that apply to it. This subset of rules is designated as the
	"Individual I2RS access control policies".  As these policies are subject to changes, a 
	dynamic synchronization mechanism should be provided. However, such mechanisms may be 
	implemented with different levels of completeness and dynamicity of the individual I2RS access control policies. 
	One example may be caching transaction requests that have been rejected.  
	</t>
	<t>I2RS access control should be appropriately balanced between the 
	I2RS client and the I2RS agent. It remains relatively easy to avoid the
	complete disclosure of the access control policies of the I2RS agent. 
	Relative disclosure of access control policies may allow leaking confidential information 
	in case of misconfiguration. It is important to balance the level of trust of the I2RS client
	and the necessity of distributing the enforcement of the access control policies.
	</t>
	<t>
	I2RS access control should not solely rely 
	only on the I2RS client or the I2RS agent as illustrated below:
    <list hangIndent="6" style="hanging">
    <t hangText="- 1) I2RS clients are dedicated to a single application: "> In this case, 
	it is likely that I2RS access control is enforced only by the I2RS agent, 
	as the I2RS client is likely to accept all access requests of the application. 
	It is recommended that even in this case, I2RS client access control 
	is not based on an "Allow anything from application" policy, but instead  
	the I2RS client specifies accesses that are enabled. In addition, 
	the I2RS client may sync its associated I2RS access control policies with the 
	I2RS agent to limit the number of refused access requests being sent to the I2RS agent. 
	The I2RS client is expected to balance benefits and problems with synchronizing
	its access control policies with the I2RS agent to proxy request validation versus simply passing  
	the access request to the I2RS agent.</t>
	 <t hangText="- 2) A single I2RS client connects to multiple applications or 
	 acts as a broker for many applications: ">In this case the I2RS agent has a 
	 single I2RS client attached, so the I2RS client could be configured to 
     enforce access control policies instead of the I2RS Agent.  In this circumstance, 
     it is possible that the I2RS agent may grant an I2RS client high priviledges 
     and blindly trust the I2RS client without enforcing access control policies
     on what the I2RS client can do.  Such a situation must be avoided as it could 
     be used by malicious applications for a privilege escalation by compromising 
     the I2RS client, causing the I2RS client to perform some action on behalf of the application 
	 that it normally does not have the privileges to perform.   In order to 
	 mitigate such attacks, the I2RS client that connects to multiple applications or 
	 operates as a broker is expected to host application with an equivalent level of privileges.
	 </t>
    </list>
    </t>
</section>
<section title="Sharing Access Control in Groups of I2RS Clients and Agents">
    <t>Overview: </t>
     <t>To distribute the I2RS access control policies between I2RS clients and I2RS agents, 
	  I2RS access control policies can also be distributed within a set of I2RS clients or a set of I2RS agents. 
	  </t>
	  <t>Requirements: 
	
     <list style="format SEC-ENV-REQ %d:" counter="my_count">
	<t>I2RS clients should be distributed and act as brokers for applications that share roughly similar permissions. 
	</t>
	<t>I2RS agents should avoid granting extra privileges to their authorized I2RS client. 
	I2RS agents should be shared by I2RS clients with roughly similar permissions. 
	More explicitly, an I2RS agent shared between I2RS clients that are only provided read
	access to the routing system resources do not need to perform any write access, 
	so the I2RS client should not be provided these accesses. 
	</t>
	<t>I2RS clients and I2RS agents should be able to trace <xref target="RFC7922"></xref> the various transactions they perform
	as well as suspicious activities. These logs should be collected regularly and analysed by functions 
	that may be out of the I2RS plane.</t>
	</list>
	</t>
	<t>Explanation: 
	</t>
	<t>This restriction for distributed I2RS clients to act as brokers only for applications 
	with roughly the same privileges avoids the I2RS client having extra privileges compared to hosted applications, 
	and discourages applications from performing privilege escalation within an I2RS client.
    For example, suppose an I2RS client requires write access to the resources. 
	It is not recommended to grant the I2RS agent the write access in order to satisfy a unique I2RS client. 
	Instead, the I2RS client that requires write access should be connected to an I2RS agent that is already 
	shared by an I2RS client that requires write access.</t>      
     <t>Access control policies enforcement should be monitored in 
	 order to detect violation of the policies or detect an attack. 
	 Access control policies enforcement may not be performed by the I2RS client
	 or the I2RS agent as violation may require a more global view of the I2RS access control policies. 
	 As a result, consistency check and mitigation may instead be performed by the management plane. 
	 However, I2RS clients and I2RS agents play a central role.
	 </t>
	<t>The I2RS agent can trace transactions that an I2RS client requests it to perform, and 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 management processes. If a particular application is granted
    a level of privileges it should not have, then this tracing mechanism may detect this security intrusion 
    after the intrusion has occurred. 
	</t>
</section> 
  <section title="Managing Access Control Policy">
    <t>Access control policies should be implemented so that the policies 
	remain manageable in short and longer term deployments of the I2RS protocol 
	and the I2RS plane. 
	</t>
	<t>Requirements:
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>access control should be managed in an automated way, that
    is granting or revoking an application should not involve
    manual configuration over the I2RS plane (I2RS client, I2RS agent, 
	and application).</t>
	</list> 
	</t>
	<t>Explanation: 
	</t>
	<t>Granting or configuring an application with 
	new policy should not require manual configuration of I2RS clients, 
	I2RS agents, or other applications.
	</t>
    <t>
	<list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>Access control should be scalable when the number of
    application grows as well as when the number of I2RS clients
    increases. 
	</t>
	</list>
	</t>
    <t>Explanation: 
	</t>
	<t>A typical implementation of a local I2RS client
           access control policies may result in creating manually a system user associated
           with each application.  Such an approach is not likely to scale
           when the number of applications increases into the hundreds. 
    </t>
	<t>
	<list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>Access control should be dynamically managed and easily updated. 
	</t>
	</list>
	</t>
	<t>Explanation:</t>
	<t>Although the number of I2RS clients is expected to be lower than the number of
           applications, as I2RS agents provide access to the routing
           resource, it is of primary importance that an access can be
           granted or revoke in an efficient way.   
    </t>
    <t>
	<list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>I2RS clients and I2RS agents should be uniquely identified in the 
	network to enable centralized management of the I2RS access control policies.
	</t>
	</list>
	</t>
	<t>Explanation: 
	</t>
	<t>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.  
	</t>
  </section>
 </section> 
 <section title="I2RS Agent Access Control Policies">
<t>Overview:</t>
 <t>The I2RS agent access control restricts 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. 
However, it remains challenging for the I2RS agent to establish its access control 
policies based on the application that initiates the request. 
</t>
<t>
First, when an I2RS client acts as a broker, the I2RS agent 
may not be able to authenticate the application. 
In that sense, the I2RS agent relies on the capability of the 
I2RS client to authenticate the applications and apply the appropriated I2RS client access control. 
</t>
<t>Second, an I2RS agent may not uniquely identify a piece of software 
implementing an I2RS client. In fact, an I2RS client may be provided 
multiple identities which can be associated to different roles or privileges. 
The I2RS client is left responsible for using them appropriately according to the application. 
</t>
<t>
Third, each I2RS client may contact various I2RS agent with different privileges and access control policies.
</t>
<section title="I2RS Agent Access Control">
<t>This section provides recommendations on the I2RS agent 
access control policies to keep I2RS access control coherent within the I2RS plane.
</t>
<t>Requirements:
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
     <t>I2RS agent access control policies should be primarily 
	 based on the I2RS clients as described in 
	 <xref target="RFC7921"></xref>.
	 </t>
    <t> I2RS agent access control policies MAY be based on the application
	if the application identity has been authenticated by the I2RS client 
	and passed via the secondary identity to the I2RS agent.
	</t>
	<t>The I2RS agent should know which identity (E.g. system user) 
	performed the latest update of the routing resource. 
	This is true for an identity inside and outside the I2RS plane,
	so the I2RS agent can appropriately perform an update according 
	to the priorities associated to the requesting identity and the identity that last updated the resource. 
	</t>
	<t>the I2RS agent should have an "I2RS agent overwrite Policy" 
	that indicates how identities can be prioritized. This requirement is also described in section
	7.6 of <xref target="RFC7921"/>. Similar requirements exist for components within 
	the I2RS plane, but this is within the scope of the I2RS protocol security requirements
	<xref target="RFC8241"></xref>.</t>
</list>
</t>
<t>Explanation:</t>
<t>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,  then this identifier 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 I2RS protocol only to aid traceability.
</t> 
<t>From the environment perspective the I2RS agent MUST be aware when the resource 
has been modified outside the I2RS 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 agent.  
</t>
<t>Similar requirements exist for knowledge about identities within the I2RS plane
which modify things in the routing system, but this is within the scope of the 
I2RS protocol's requirements for ephemeral state <xref target="RFC8242"></xref>
and security requirements <xref target="RFC8241"></xref>.
</t>  
</section>
<section title="I2RS Client Access Control Policies">

	    <t>Overview: 
		</t>
		<t>
		The I2RS 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.
		</t>
		<t>Requirements:
         <list style="format REQ %d:" counter="my_count">
		 <t>I2RS client should authenticate its applications. 
		If the I2RS client acts as a broker and supports multiple applications, 
		it should authenticate each application. 
		</t>
        <t>I2RS client should define access control policies associated to each 
		applications. An access to a routing resource by an application should 
		not be forwarded immediately and transparently by the 
		I2RS client based on the I2RS agent access control policies. 
		The I2RS client should first check whether the application has sufficient privileges, 
		and if so send an access request to the I2RS agent. 
         </t>
        </list>
	    </t>
    <t>
	Explanation:
	</t>
	<t>
	If no authentication mechanisms have being provided 
	between the I2RS client and the application, then the I2RS client must be 
	dedicated to a single application. By doing so, application authentication 
	relies on the I2RS authentication mechanisms between the I2RS client and the I2RS agent. 
	</t>
	<t>If an I2RS client has multiple identities that are associated with different privileges
	for accessing an I2RS agent(s), the I2RS client access control policies 
	should specify the I2RS client identity with the access control policy.  
	</t>
	    </section>
    <section title="Application and Access Control Policies">
    <t>Overview</t>
    <t>Applications do not enforce access control policies. 
	Instead these are enforced by the I2RS clients and the I2RS agents. 
	This section provides recommendations for applications 
	in order to ease I2RS access control by the I2RS client and the I2RS agent.
	</t>
	<t>Requirements:
	</t>
	<t>
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>Applications SHOULD be uniquely identified by their associated I2RS clients</t>
    </list>
	</t>
	<t>Explanation: </t>
	<t>Different application may use different methods (or multiple methods)
	to communicate with its associated I2RS client, and each  
    application may not use the same form of an application identifier. 
    However, the I2RS client must obtain an identifier for each application. 
    One method for this identification can be a system user id. 	
    </t>
	<t>
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>Each application SHOULD be associated to a restricted number
       of I2RS clients.</t>
	 </list>
	 </t>
    <t>	Explanation: 
	</t>
	<t>
	The I2RS client provides access to resource on its behalf and this
    access should only be granted for trusted applications, 
    or applications with an similar level of trust. 
    This does not prevent an I2RS client to host a
    large number of applications with the same levels of trust.  
    </t>
    <t>
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
    <t>An application SHOULD be provided means and methods to contact
           their associated I2RS client.  
	</t>
	</list>
	</t>
	<t>Explanation:</t>
	<t>
	It is obvious when an I2RS client belongs to
    the application as part of a module or a library 
	that the application can communicate with a I2RS client. 
    Similarly, if the application runs into a dedicated system 
	with a I2RS client, it is obvious which I2RS client the 
    application should contact.  If the application connects to 
    the I2RS client remotely, the application needs some means 
    to retrieve the necessary information to
    contact its associated I2RS client (e.g. an IP address or a 
	FQDN).
	</t>
	    </section>
    </section>
</section>  

 <section title="I2RS Application Isolation" anchor="sec-i2rs-application-isolation">
	<t>A key aspect of the I2RS architecture is the network oriented application 
    that uses the I2RS high bandwidth programmatic interface to monitor or 
    change one or more routing systems. I2RS applications could be control 
    by a single entity or serve various tenants of the network.  If multiple 
    entities use an I2RS application to monitor or change the network, security policies  
    must preserve the isolation of each entity's control and not 
    let malicious entities controlling one I2RS application interfere
    with other I2RS applications.  
    </t>
    <t>
	This section discusses both security aspects related to programmability as well as 
	application isolation in the I2RS architecture.
    </t>
<section title="Robustness Toward Programmability">
    <t>Overview</t>
	<t>I2RS provides a programmatic interface in and out of
	the Internet routing system which provides the following 
	advantages for security:
	<list style="symbols">
	<t>the use of automation reduces configuration errors;
	</t>
	<t> the programmatic interface 
	enables fast network reconfiguration and agility in adapting to network attacks; and  
    </t>
    <t>monitoring facilities to detect a network attack, and configuration 
      changes which can help mitigate the network attack. 
	  </t>
	</list>
	Programmability allows applications to flexible control 
    which may cause problems due to: 
	<list style="symbols">
	<t>applications which belong to different tenants with different objectives, 
	</t>
    <t>applications which lack coordination resulting in unstable routing configurations 
	such as oscillations between network configurations, and creation of loops. 
	For example, one application may monitor a state and change to positive, and 
	a second application performs the reverse operation (turns it negative).
	This fluctuation can cause a routing system to become unstable. 
	</t>
	</list> 
	</t>
	<t>The I2RS plane requires data and application isolation to 
	prevent such situations from happening.  However, to guarantee the network stability
	constant monitoring and error detection are recommended.  
	</t>
	<t>Requirement: 
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
		<t>The I2RS agents should monitor constantly parts of 
		the system for which I2RS clients or applications have provided requests. 
		It should also be able to detect any I2RS clients or applications 
		causing problems that may leave the routing system in an unstable state. 
		</t>
	</list>
	</t>
	<t>Explanation: </t>
	<t>In the least, monitoring consists of logging events and 
	   receiving streams of data. I2RS Plane implementations should monitor 
       the I2RS applications and I2RS clients for potential problems.  
        The cause for the I2RS clients or applications providing problematic 
        requests can be failures in the implementation code or malicious intent. ]
     </t> 
</section>

<section title="Application Isolation">
	<section title="DoS">
	<t>Overview:</t>
		<t>Requirements for robustness to DoS
		attacks have been addressed in the communication 
		channel section <xref target="RFC7921"></xref>. 
		This section focuses on requirements for application isolation 
		that help prevent DoS. 
	</t>
	<t>Requirements: 
    <list style="format SEC-ENV-REQ %d:" counter="my_count">
	<t>In order to prevent DoS, it is recommended the I2RS 
		agent control the resources allocated to each I2RS client. 
		I2RS clients that act as broker may not be protected  
		efficiently against these attacks unless the broker performs 
		resource controls for the hosted applications.</t> 
	<t>I2RS agent SHOULD not make a response redirection 
	unless the redirection is previously validated and agreed by the destination.</t> 
    <t>I2RS Applications should avoid the use of underlying protocols 
       that are not robust enough to protect against reflection attacks.</t> 
   </list>
	    </t>
	<t>Explanation: </t>
	<t>The I2RS interface is used by applications to interact with the routing states. 
		If the I2RS client is shared between multiple applications, one application can 
		use the I2RS client to perform DoS or DDoS attacks on the I2RS agent(s) and through the 
        I2RS agents attack the network.  DoS attack targeting the I2RS agent would 
        consist in providing requests that keep the I2RS 
		agent busy for a long time. These attacks on the I2RS agent 
		may involve an application (requesting through an I2RS Client) 
		heavy computation by the I2RS agent in order to block operations like disk access. 
		</t>
		<t>Some DoS attacks may attack the I2RS Client's reception of 
		notification and monitoring data streams over the network.  
		Other DoS attacks may focus on the application directly by 
		performing reflection attacks to reflect traffic. Such an attack 
		could be performed by first detecting an application is 
        related to monitoring the RIB or changing the RIB.
	    Reflection-based DoS may also attack at various levels in the stack
		utilizing UDP at the service to redirect data to 
		a specific repository 
       </t>		
	   <t>
       I2RS implementation should consider how to protect I2RS against such attacks. 
		</t>
	</section>
	<section title="Application Logic Control">

	  <t>Overview</t>
		<t>	This section examines how application logic must be designed to 
        ensure application isolation.
		</t>
		<t>Requirements: 
		<list style="format SEC-ENV-REQ %d:" counter="my_count">
			    <t>Application logic should remain opaque to external listeners. Application logic may be partly hidden by encrypting the communication between the I2RS client and the I2RS 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 broker are more likely to hide the application logic compared to I2RS client associated to a single application.</t>
		    </list>
	    </t>	
        <t>Explanation: </t>
		<t>Applications use the I2RS 
		interface in order to update the routing system. These updates 
		may be driven by behaviour on the forwarding plane or any external behaviours. 
		In this case, correlating observation with the I2RS traffic may enable the 
		derivation 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.
		</t>
	</section>
</section>

    </section>

      <section title="Security Considerations">
        <t>This whole document is about 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. 
        </t>
      </section>
    <section title="IANA Considerations">
      <t>No IANA considerations for this requirements. </t>
    </section>
    <section title="Acknowledgments">
      <t>A number of people provided a significant amount 
	  of helpful 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. 
      </t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
        &RFC2119; 
		&RFC7920;
        &RFC7921;
        &RFC7922;
        &RFC7923;	
		&RFC8241;  		
    </references>
    <references title="Informative References">
	 &RFC8242;  
     &I-D.ietf-netconf-rfc6536bis;
     &I-D.ietf-netmod-revised-datastores;
	 
    </references>
  </back>
</rfc>
