draft-ietf-i2rs-security-environment-reqs-01.txt   draft-ietf-i2rs-security-environment-reqs-02.txt 
I2RS WG D. Migault, Ed. I2RS WG D. Migault
Internet-Draft J. Halpern Internet-Draft J. Halpern
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: October 6, 2016 S. Hares Expires: May 19, 2017 S. Hares
Huawei Huawei
April 4, 2016 November 15, 2016
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-01 draft-ietf-i2rs-security-environment-reqs-02
Abstract Abstract
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. Environment security requirements are independent of
the protocol used for I2RS. As a result, the requirements provided the protocol used for I2RS. The I2RS protocol security requirements
in this document are intended to provide good security practise so set the security for the communication between I2RS client and agent
I2RS can be securely deployed and operated. while the security environment requirements are rather intended for
deployment or implementations features independent of the I2RS
These security requirements are designated as environment security protocol. The environmental security requirements described in this
requirements as opposed to the protocol security requirements. The document provide the good security practices to be used with the I2RS
reason to have separate document is that protocol security protocol so that I2RS protocol implementations can be securely
requirements are intended to help the design of the I2RS protocol deployed and operated.
whether the environment requirements are rather intended for
deployment or implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2016. This Internet-Draft will expire on May 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4
4.1. I2RS plane and management plane . . . . . . . . . . . . . 4 3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5
4.2. I2RS plane and forwarding plane . . . . . . . . . . . . . 5 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7
4.3. I2RS plane and Control plane . . . . . . . . . . . . . . 6 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8
4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 8
5. I2RS Access Control for routing system resources . . . . . . 8 4. I2RS Access Control for Routing System Resources . . . . . . 10
5.1. I2RS Access Control architecture . . . . . . . . . . . . 8 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11
5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13 4.1.1. access control Enforcement Scope . . . . . . . . . . 12
5.3. I2RS Client Access Control policies . . . . . . . . . . . 14 4.1.2. Notification Requirements . . . . . . . . . . . . . . 13
5.4. Application and Access Control policies . . . . . . . . . 15 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 14
6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 16 4.1.4. Sharing access control Information . . . . . . . . . 14
6.1. Robustness toward programmability . . . . . . . . . . . . 16 4.1.5. Sharing Access Control in Groups of I2RS Clients and
6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17 Agents . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.6. Managing Access Control Policy . . . . . . . . . . . 17
6.2.2. Application Control . . . . . . . . . . . . . . . . . 17 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 19
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. Application and Access Control Policies . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Robustness Toward Programmability . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 18 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Application Logic Control . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
1. Requirements notation 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
document are to be interpreted as described in [RFC2119]. 9.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
2. Introduction 1. Introduction
This document provides environment security requirements for the I2RS This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of architecture. Environment security requirements are independent of
the protocol used for I2RS. As a result, the requirements provided the protocol used for I2RS. The I2RS protocol security requirements
in this document are intended to provide good security practise so [I-D.ietf-i2rs-protocol-security-requirements] set the security for
I2RS can be securely deployed and operated. the communication between I2RS client and agent while the security
environment requirements are rather intended for deployment or
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
operate. These environment security address the security
considerations for I2RS protocol environment considered in the I2RS
Architecture [RFC7921] in order to provide a stable and secure
environment in which the dynamic programmatic interface to the
routing system (I2RS) should operates.
These security requirements are designated as environment security Even though the I2RS protocol is mostly concerned with the interface
requirements as opposed to the protocol security requirements between the I2RS client and the I2RS agent, the environmental
described in [I-D.ietf-i2rs-protocol-security-requirements]. The security requirements must consider the entire I2RS architecture and
reason to have separate document is that protocol security specify where security functions may be hosted and what criteria
requirements are intended to help the design of the I2RS protocol should be met in order to address any new attack vectors exposed by
whether the environment requirements are rather intended for deploying this architecture. Environment security for I2RS has to be
deployment or implementations. considered the complete I2RS architecture and not only on the
protocol interface.
Even though I2RS is mostly concerned by the interface between the This document is structured as follows:
I2RS Client and the I2RS Agent, the security recommendations must
consider the entire I2RS architecture, specifying where security
functions may be hosted, and what should be met so to address any new
attack vectors exposed by deploying this architecture. In other
words, security 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 o Section 2 describes the terminology used in this document,
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.
This document is built as follows. Section 4 describes how the I2RS o Section 3 describes how the I2RS plane can be contained or
plane can be contained or isolated from existing management plane, isolated from existing management plane, control plane and
control plane and forwarding plane. The remaining sections of the forwarding plane.
document focuses on the security within the I2RS plane. Section 5
analyzes how the I2RS 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 details how I2RS
keeps applications isolated one from another and do not affect the
I2RS components. Applications may be independent, with different
scopes, owned by different tenants. In addition, they modify the
routing system that may be in an automatic way.
The reader is expected to be familiar with the o the subsequent sections of the document focuses on the security
[I-D.ietf-i2rs-architecture]. The document provides a list of within the I2RS plane including:
environment security requirements. Motivations are placed before the
requirements are announced.
3. Terminology and Acronyms * Section 4 analyzes how the I2RS 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 includes providing a
robust communication system between the components.
- Environment Security Requirements : * Section 5 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.
- I2RS plane : The environment the I2RS process is running on. It Motivations are placed before the requirements are given.
includes the Applications, the I2RS Client and the I2RS Agent.
- I2RS user : The user of the I2RS client software or system. The reader is expected to be familiar with the 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 [I-D.ietf-i2rs-protocol-security-requirements].
- I2RS Access Control policies: policies controlling access of the 2. Terminology and Acronyms
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.
- I2RS Client Access Control policies : The Access Control policies - Environment Security Requirements : Security requirements
processed by the I2RS Client. specifying how the environment a protocol operates in needs to
be secure. These requirements do not specify the protocol
security requirements.
- I2RS Agent Access Control policies : The Access Control policies - I2RS plane: The environment the I2RS process is running on. It
processed by the I2RS Agent. includes the applications, the I2RS client and the I2RS agent.
4. I2RS Plane Isolation - I2RS user: The user of the I2RS client software or system.
- I2RS access control policies: 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.
- I2RS client access control policies: The access control policies
processed by the I2RS client.
- I2RS agent access control policies: The access control policies
processed by the I2RS 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, and control planes ) is 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
2. protects other systems vital to the health of the network from
vulnerabilities in the I2RS plane.
Isolating the I2RS plane from other network plane, such as the
control plane, is foundational to the security of the I2RS
environment. Clearly differentiating I2RS components from the rest
of the network protects the I2RS components from vulnerabilities in
other parts of the network, and protect 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 Separating the I2RS plane from other network control and forwarding
planes is similar to the best common practice of containerizing planes is similar to the best common practice of containerizing
software into modules, and defense in depth in the larger world of software into modules. However, the I2RS plane cannot be considered
network security. as completely isolated from other planes so the interactions between
the I2RS plane and other planes should be identified and controlled.
That said the I2RS plane cannot be considered as completely isolated The following is a brief description of how the I2RS plane positions
from other planes, and interactions should be identified and itself in regard to the other planes.
controlled. Follows a brief description on how the I2RS plane
positions itself in regard to the other planes. The description is
indicative, and may not be exhaustive.
4.1. I2RS plane and management plane 3.1. I2RS Plane and Management plane
The I2RS plane purpose is to provide a standard programmatic The purpose of the I2RS plane is to provide a standard programmatic
interface of the routing system resources to network oriented interface of the routing system resources to network oriented
applications. Control plane and forwarding planes are related to applications. The control plane and forwarding planes are related to
routing protocols, and I2RS is based on top of those. The management routing protocols, and I2RS is positioned on top of the control plane
plane is usually vendor specific, provides a broader control over the and forwarding plane. The management plane is usually vendor
networking equipment such as system service. Given its associated specific and provides a broader control over the networking equipment
such as system service. Given the management plane's associated
privileges it is expected to be reserved to highly trusted users like privileges it is expected to be reserved to highly trusted users like
network administrators. network administrators.
The I2RS plane and the management plane both interact with several The I2RS plane and the management plane both interact with several
common elements on forwarding and packet processing devices. common elements on forwarding and packet processing devices.
[I-D.ietf-i2rs-architecture] describes several of these interaction [RFC7921] describes several of these interaction points such as the
points such as the local configuration, the static system state, local configuration, the static system state, routing, and signaling.
routing, and signalling. Because of this potential overlaps, a A routing resource may be accessed by different means (APIs,
routing resource may be accessed by different means (APIs, applications) and different planes which creates potential overlaps.
applications) and different planes. To keep these overlaps under Southbound APIs are often provided to limit the scope of the
control, one could either control the access to these resources with management plane's and the I2RS plane's interaction with the routing
northbound APIs for example. Northbound APIs are provided to limit resources (as figure 1 shows). If there are conflicts in these
the scope of the applications toward the routing resources. In our overlapping southbound APIs, the conflicts should be resolved in a
case, the northbound API may be provided for the I2RS applications by deterministic way.
the I2RS Client as well as to the management plane. In case
conflicting overlaps cannot be avoided, and routing resource can be APIs that interact with the
accessed by both the management plane and the I2RS plane, then, they I2RS Plane and Management PLane
I2RS applications Mangement applications
|| NB API NB API ||
|| ||
I2RS plane management plane
|| ||
||SB API SB API ||
-------------------------------------------
| Routing Resources |
|(forwarding plane, control plane, system) |
+------------------------------------------+
Figure 1 - North Bound (NB) APIs and
South Bound (SB) APIs
The I2RS applications may be provided with a northbound API by the
I2RS client (as figure 1 shows). Similarly, the management plane may
provide a northbound API to management application. The northbound
API from the management plane to the client application and the
northbound API from the I2RS plane to I2RS applications may overlap.
In case that these overlapping APIs between the have conflicts (e.g.
both want to access the same routing resource), the the conflicts
should be resolved in a deterministic way. should be resolved in a deterministic way.
On the northbound side, there must be clear protections against the To resolve conflicts in a northbound APIs, the deterministic
I2RS system "infecting" the management system with bad information, resolution should have clear rules about which data plane with a
or the management system "infecting" the I2RS system with bad system takes precedence (wins during a conflict for resources). This
information. The primary protection in this space is going to need is important to prevent attacks that attempt to drive the two systems
to be validation rules on the speed of information flow, value limits into deadlock situation over which system has precedence (wins)
on the data presented, and other protections of this type.
On the conflicting side/issues, there should be clear rules about In the interactions between the I2RS plane and the applications, and
which plan's commands win in the case of conflict in order to prevent the management plane and the application is it important to prevent
attacks where the two systems can be forced to deadlock. the following things:
4.2. I2RS plane and forwarding plane o the I2RS system "infecting" the management system with bad
information,
Applications hosted on I2RS Client belongs to the I2RS plane. These o the management system "infecting" the I2RS system with bad
Applications are hard to remain constrained into the I2RS plane, or information directly,
even to limit their scope within the I2RS plane.
Applications using I2RS are part of the I2RS plane but may also o the management system indirectly "infecting" the I2RS system by
interact with other components outside the I2RS plane. A common propagating improproper information from one system to another via
example may be an application uses I2RS to configure the network I2RS.
according to security or monitored events. As these events are
monitored on the forwarding plane and not the I2RS plane, the
application breaks plane isolation.
In addition, applications may communicate with multiple I2RS Clients; Prevention:
as such, any given application may have a broader view of the current
and potential states of the network and the I2RS plane itself.
Because of this, any individual application could be an effective The primary protection in this space is going to need to be
attack vector against the operation of the network, the I2RS plane, validation rules on the data being sent/receive, notification of
or any plane with which the I2RS plane interacts. There is little changes that the I2RS agent sends the client, and other access
the I2RS plane can do to validate applications with which it protections.
interacts, other than to provide some broad general validations
against common misconfigurations or errors. As with the separation
between the management plane and the I2RS plane, this should
minimally take the form of limits on information accepted, limits on
the rate at which information is accepted, and rudimentary checks
against intentionally formed routing loops or injecting information
that would cause the control plane to fail to converge. Other forms
of protection may be necessary.
4.3. I2RS plane and Control plane 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 by the I2RS client belong to the I2RS plane. It
is difficult to constrained 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 an I2RS client to configure the
network or monitored events via an I2RS agent on a single machine, or
multiple I2RS agents each on a single machine.
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).
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. The I2RS client
passes the I2RS agent an opaque identifier for the application so
that an application's actions can be traced back to the
application.
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 performing rudimentary
checks on the results of any updates to the forwarding plane.
3.3. I2RS Plane and Control Plane
The network control plane consists of the processes and protocols The network control plane consists of the processes and protocols
that discover topology, advertise reachability, and determine the that discover topology, advertise reachability, and determine the
shortest path between any location on the network and any shortest path between any location on the network and any
destination. It is not anticipated there will be any interactions destination. I2RS client configures, monitors or receives events via
between the on-the-wire signalling used by the control plane. the I2RS agent's interaction with the routing system including the
However, in some situations the I2RS system could modify information process that handling the control plane signaling protocols (BGP,
in the local databases of the control plane. This is not normally ISIS, OSPF, etc.), route information databases (RIBs), and interface
recommended, as it can bypass the normal loop free, loop free databases. In some situation to manage an network outage or to
alternate, and convergence properties of the control plane. However, control traffic, the I2RS protocol may modify information in the
if the I2RS system does directly inject information into these route database or the configuration of routing process. While this
tables, the I2RS system should ensure that loop free routing is is not a part of normal processing, such action that allows the
preserved, including loop free alternates, tunnelled interfaces, network operator to bypass temporary outages or DoS attacks.
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 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. The information configured by the I2RS agent into
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).
To isolate I2RS transactions from other planes, it is recommended Prevention measures:
that:
REQ 1: Application-to-routing system resources communications should The I2RS system can provide checks that during and after the problem
use an isolated communication channel. Various level of has been resolved that loop free routing is preserved. These checks
isolation can be considered. The highest level of isolation should check the preservation of all facets of routing including the
may be provided by using a physically isolated network. following: routing with loop free alternates, tunnelled interfaces,
Alternatives may also consider logical isolation; for example virtual overlays, and other such constructions.
by using vLAN. Eventually, in virtual environment that
shares a common infrastructure, encryption, for example by
using TLS or IPsec, may also be used as a way to enforce
isolation.
REQ 2: The interface (like the IP address) used by the routing 3.4. Requirements
element to receive I2RS transactions 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 also be considered
for example by using a dedicated IP address or a dedicated
port.
When the I2RS Agent performs an action on a routing element, the To isolate I2RS transactions from other planes, it is required that:
action is performed via process(es) associated to a system user . In
a typical UNIX system, the user is designated with a user id (uid)
and belong to groups designated by group ids (gid). These users are
dependent of the routing element's operation system and are
designated I2RS System Users. Some implementation may use a I2RS
System User for the I2RS Agent that proxies the different I2RS
Client, other implementations may use I2RS System User for each
different I2RS Clients.
REQ 3: I2RS Agent should have permissions separate from any other SEC-ENV-REQ 1: application-to-routing system resources
entity (for example any internal system management processes communications should use an isolated communication
or CLI processes). 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
(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
[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 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.
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 performs an action on a routing element, the
action is performed via process(es) associated to 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 unique filter data between the processes.
SEC-ENV-REQ 4: 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 to flood the I2RS plane, and rate limiting (or
summarization) is expected to be applied. These
routing system notification MAY translated to the
appropriate I2RS agent notifications, and passed to
various I2RS clients via notification relays. (This
requirements is also described in section 7.6 of
[RFC7921] for the I2RS client, and this section
extends it to the entire I2RS plane (I2RS agent,
client, and application).
Explanation:
I2RS resource may be shared with the management plane and the control I2RS resource may be shared with the management plane and the control
plane. It is hardly possible to prevent interactions between the plane. The I2RS routing system resource management is limited to the
planes. I2RS routing system resource management is limited to the
I2RS plane. As such, update of I2RS routing system outside of the I2RS plane. As such, update of I2RS routing system outside of the
I2RS plane may be remain unnoticed unless explicitly notified to the I2RS plane may remain unnoticed unless and until explicitly notified
I2RS plane. Such notification is expected to trigger synchronization to the I2RS plane. Such notification is expected to trigger
of the I2RS resource state within each I2RS component. This synchronization of the I2RS resource state within each I2RS
guarantees that I2RS resource are maintained in a coherent state component. This guarantees that I2RS resource are maintained in a
among the I2RS plane. In addition, depending on the I2RS resource coherent state among the I2RS plane. In addition, depending on the
that is updated as well as the origin of the modification performed, I2RS resource that is updated as well as the origin of the
the I2RS Access Control policies may be impacted. More especially, a modification performed, the I2RS access control policies may be
I2RS Client is more likely to update an I2RS resources that has been impacted. Further an I2RS client is more likely to update an I2RS
updated by itself, then by the management plane for example. resources that has been updated by itself, then by the management
plane.
REQ 4: I2RS plane should be informed when a routing system resource SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite
is modified by a user outside the I2RS plane access. The policy". Such policy defines how an I2RS is able to
notification is not expected to flood the I2RS plane. update and overwrite a resource set by a user outside
Instead, notification is expected to be provided to the I2RS the I2RS plane. Such hierarchy has been described in
components interacting, configuring or monitoring the routing section 6.3 and 7.8 of [RFC7921]
system resource. The notification is at least provided by
the I2RS Agent to the various I2RS Client, but additional
mechanisms might eventually be required so I2RS Client can
relay the notification to the I2RS applications. This is
designated as "I2RS resource modified out of I2RS plane".
This requirements is also described in section 7.6 of
[I-D.ietf-i2rs-architecture] for the I2RS Client. This
document extends the requirement to the I2RS plane, in case
future evolution of the I2RS plane.
REQ 5: I2RS plane should define an "I2RS plane overwrite policy". Explanation:
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
[I-D.ietf-i2rs-architecture]
5. I2RS Access Control for routing system resources 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 [RFC7921] 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.
This section provides recommendations on how I2RS Access Control 4. I2RS Access Control for Routing System Resources
This section provides recommendations on how I2RS access control
policies associated to the routing system resources. These policies policies associated to the routing system resources. These policies
only apply within the I2RS plane. More especially, the policies are only apply within the I2RS plane. More especially, the policies are
associated to the Applications, the I2RS Clients and the I2RS Agents, associated to the applications, I2RS clients and I2RS agents, with
with their associated identity and roles. their associated identity and roles.
Note that the deployment of Applications, I2RS Client and I2RS Agent The I2RS deployment of I2RS applications, I2RS clients, and I2RS
in a closed environment, should not be considered by default as a agents can be located locally in a closed environment or distributed
secure environment. Even for closed environment access control over open networks. The normal case for routing system management is
policies should be carefully defined to be able to, in the future to over an open environment. Even in a closed environment access
carefully extend the I2RS plane to remote Applications or remote I2RS control policies should be carefully defined to be able to, in the
Clients. As a result, this section always consider the case future to carefully extend the I2RS plane to remote applications or
Applications and I2RS Client can be located locally, in a closed remote I2RS clients.
environment or distributed over open networks.
Although [I-D.ietf-i2rs-protocol-security-requirements] provides [I-D.ietf-i2rs-protocol-security-requirements] defines the security
security requirements of the transport and protocol between the I2RS requirements of the I2RS protocol between the I2RS client and the
Client and the I2RS Agent, this section is mostly focused on access I2RS agent over a secure transport. This section focuses on I2RS
control. access 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).
5.1. I2RS Access Control architecture 4.1. I2RS Access Control Architecture
Overview:
Applications access to routing system resource via numerous Applications access to routing system resource via numerous
intermediaries nodes. The application communicates with an I2RS intermediaries nodes. The application communicates with an I2RS
Client. In some cases, the I2RS Client is only associated to a client. In some cases, the I2RS client is only associated to a
single application, but the I2RS Client may also act as a broker. single application attached to one or more agents (case a and case b
The I2RS Client, then, communicates with the I2RS Agent that may in figure 2 below). In other cases, the I2RS client may be connected
eventually access the resource. to two applications (case c in figure 2 below), or the I2RS may act
as a broker (agent/client device shown in case d in the figure 2
The I2RS Client broker approach provides scalability to the I2RS below). The I2RS client broker approach provides scalability to the
architecture as it avoids that each Application be registered to the I2RS architecture as it avoids that each application be registered to
I2RS Agent. Similarly, the I2RS Access Control should be able to the I2RS agent. Similarly, the I2RS access control should be able to
scale numerous applications. scale numerous applications.
REQ 6: I2RS Access Control should be performed through the whole The goal of the security environment requirements in this section are
I2RS plane. It should not be enforced by the I2RS Agent only to control the interactions between the applications and the I2RS
within the routing element. Instead, the I2RS Client should client, and the interactions between the I2RS client and the I2RS
enforce the I2RS Client Access Control against Applications agent. The key challenge is that the I2RS architecture puts the I2RS
and the I2RS Agent should enforce the I2RS Agent Access Client in control of the stream of communication (application to I2RS
Control against the I2RS Clients. Note that I2RS Client client and I2RS client to the I2RS agent). The I2RS agent must trust
Access Control is not in the scope of the I2RS architecture the I2RS client's actions without having an ability to verify the
[I-D.ietf-i2rs-architecture], which exclusively focuses on I2RS client's actions.
the I2RS Agent Access Control.
This results in a layered and hierarchical or multi-party I2RS Access a) I2RS application-client pair talking
Control. An application will be able to access a routing system to one I2RS agent
resource only if both the I2RS Client is granted access by the I2RS
Agent and the application is granted access by the I2RS Client.
REQ 7: When an access request to a routing resource is refused by +-----------+ +---------+ +-------+
one party (the I2RS Client or the I2RS Agent), the initiator | I2RS |=====| I2RS |======| I2RS |
of the request (e.g the Application) as well as all |application| | client 1| | agent |
intermediaries should indicate the reason the access has not +-----------+ +---------+ +-------+
been granted as well as the entity that has rejected the
request.
REQ 8: In order to provide coherent Access Control policies enforced b) I2RS application client pair talking to
by multiple parties (e.g. the I2RS Client or the I2RS Agent), two i2RS agents
theses parties should trust each others, and communication +--------+
between them should also be trusted, - that is should not +-------------+ +---------+ | I2RS |
introduce additional vector of attacks. | I2RS |===| I2RS |=====| agent 1|
|application 1| | client 1| +--------+
| | | | +--------+
| | | |=====| I2RS |
+-------------+ +---------+ | agent 2|
+--------+
In case the I2RS Client Access Control or the I2RS Agent Access c) two applications talk to 1 client
Control does not grant access to a routing system resource, the +--------+
Application should be able to determine whether its request has been +-------------+ +--------+ | I2RS |
rejected by the I2RS Client or the I2RS Agent as well as the reason | I2RS |===|I2RS |=====| agent 1|
that caused the reject. More specifically, the I2RS Agent may reject |application 1| |client 1| +--------+
the request because, for example, the I2RS Client is not an +-------------+ | | +--------+
authorized I2RS Client, or because the I2RS Client does not not have +-------------+ | |=====| I2RS |
enough privileges. The I2RS Client should be notified of the reason | I2RS | | | | agent 2|
that caused the reject by the I2RS Agent, and The I2RS Client should |application 2|===| | +--------+
return a message to the Application, indicating the I2RS Client is +-------------+ +--------+
not authorized or does not have enough privileges. Similarly, if the
I2RS Client does not grant the access to the Application, the I2RS
Client should also inform the Application. The error message
returned should be for example: "Read failure: you do not have the
read permission", "Write failure: you do not have write permission"
or "Write failure: resource accessed by someone else". This
requirement has been written in a generic manner as it concerns
various interactions: interactions between the application and the
I2RS Client, interactions between the I2RS Client and the I2RS Agent.
In the latest case, the requirement is part of the protocol security
requirements addressed by
[I-D.ietf-i2rs-protocol-security-requirements].
Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on d) I2RS Broker (agent/client
transport security requirements between the I2RS Client and the I2RS +--------+
Agent, the similar requirements may apply between the Application and +-------------+ +--------+ | I2RS |
the I2RS Client for a remote Application. | I2RS |==|I2RS |=====|agent 3/|
|application 1| |client 1| ==|client 3+----+
+-------------+ +--------+ | +--+-----+ |
| | |
+-------------+ +--------+ | +-------+ +--|----+
| I2RS | |I2RS |===| |I2RS | |I2RS |
|application 2|==|client 2| |agent 1| |agent 2|
+-------------+ +--------+ +-------+ +-------+
REQ 9: I2RS Client or I2RS Agent SHOULD also be able to refuse a 4.1.1. access control Enforcement Scope
communication with an Application or an I2RS Client when the
communication channel does not fulfill enough security
requirements. For example, the it should be able to reject
messages over a communication channel that can be easily
hijacked, like a clear text UDP channel.
In order to limit the number of access request that result in an SEC-ENV-REQ 6: I2RS access control should be performed through the
error, each Application or I2RS Client may be able to retrieve the whole I2RS plane. It should not be enforced by the
I2RS Access Control policies that applies to it. This subset of I2RS agent only within the routing element. Instead,
rules is designated as the "Individual I2RS Access Control policies". the I2RS client should enforce the I2RS client access
As these policies are subject to changes, a dynamic synchronization 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 [RFC7921], which exclusively focuses on
the I2RS agent access control provided by the I2RS
protocol.
Explanation:
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.
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 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.
Explanation:
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.
SEC-REQ-07 indicates the I2RS agent may reject the request because
the I2RS client is not an authorized I2RS client or have enough
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 priviledges, and the I2RS client should return a
message to the application indicating the I2RS agent reject the
transacation 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 the read
permission", "Write failure: you do not have write permission", or
"Write failure: resource accessed by someone else".
This requirement has been written in a generic manner as it concerns
the following interactions:
o interactions between the application and the I2RS client,
o interactions between the I2RS client and the I2RS agent (security
requirements are described by
[I-D.ietf-i2rs-protocol-security-requirements]),
o and interactions between the I2RS agent and the I2RS 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 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 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.
Explanation:
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.
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 requests that result in an
error, each application or I2RS client can retrieve the I2RS access
control policies that applies 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 mechanism may be mechanism should be provided. However, such mechanism may be
implemented with different level of completeness and dynamicity of implemented with different level of completeness and dynamicity of
the Individual I2RS Access Control policies. Caching requests that the individual I2RS access control policies. One example, may be
have been rejected may be one such variant. It remains relatively caching transaction requests that have been rejected.
easy to implement and may avoid the complete disclosure of the Access
Control policies of the I2RS Agent. In fact the relative disclosure
of Access Control policies may leak confidential information in case
of misconfiguration and should be balanced with the level of trust of
the I2RS Client and the necessity of distributing the enforcement of
the Access Control policies.
REQ 10: The I2RS Client may be able to request for its I2RS Access I2RS access control should be appropriately be balanced between the
Control subset policies to the I2RS Agent or cache requests I2RS client and the I2RS agent. It remains relatively easy to avoid
that have been rejected by the I2RS Agent to limit forwarding the complete disclosure of the access control policies of the I2RS
unnecessary queries to the I2RS Agent. agent. Relative disclosure of access control policies may allow the
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.
REQ 11: The I2RS Client may be able to be notified when its I2RS I2RS access control should not solely rely only on the I2RS client or
Access Control subset policies have been updated by the I2RS the I2RS agent as illustrated below:
Agent.
Similarly, for the Applications - 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 request 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.
REQ 12: The Applications may be able to request for its I2RS Access - 2) A single I2RS client connects to multiple applications or
Control subset policies, so to limit forwarding unnecessary acts as a broker for many applications:
queries to the I2RS Client. In the case the I2RS agent has a single I2RS client
attached. This may end up in a situation where the I2RS
client is being delegated by the I2RS agent to enforce
access control policies. In such as case, the I2RS agent
may grant the I2RS client with high priviledges and blidngly
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 priviledge escalation by compromising the
I2RS client. In this situation, the application uses the
I2RS client to perform some action on behalf of the
application that it normally does not have the priviledges
to perform. In order to mitigate such attack, the I2RS
client that connects to multiple applications or operates as
a broker is expected to host application with an equivalent
level of privileges.
REQ 13: The Applications may be able to subscribe a service that 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents
provides notification when its I2RS Access Control subset
policies have been updated.
I2RS Access Control should be appropriately be balanced between the Overview:
I2RS Client and the I2RS Agent. I2RS Access Control should not
solely rely only on the I2RS Client or the I2RS Agent as illustrated
below:
- 1) I2RS Clients are dedicated to a single Application: In this To distribute the I2RS access control policies between I2RS clients
case, it is likely that I2RS Access Control is enforced only by and I2RS agents, I2RS access control policies can also be distributed
the I2RS Agent, as the I2RS Client is likely to accept all within a set of I2RS clients or a set of I2RS agents.
access request of the application. However, 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 pro and cons between sync its access
control policies with the I2RS Agent and simply guessing the
access request to the I2RS Agent.
- 2) A single I2RS Client acts as a broker for all Applications: In Requirements:
the case the I2RS Agent has a single I2RS Client. Such
architecture results in I2RS Client with high privileges, as it
sums the privileges of all applications. As end-to-end
authentication is not provided between the Application and the
I2RS Agent, if the I2RS Client becomes corrupted, it is
possible for the malicious application escalates its privileges
and make the I2RS Client perform some action on behalf of the
application with more privileges. This would not have been
possible with end-to-end authentication. In order to mitigate
such attack, the I2RS Client that acts as a broker is expected
to host application with an equivalent level of privileges.
REQ 14: The I2RS Access Control should explicitly specify accesses SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers
that are granted. More specifically, anything not explicitly for applications that share roughly similar
granted -- the default rule-- should be denied. permissions.
In addition to distribute the I2RS Access Control policies between SEC-ENV-REQ 16: I2RS agents should be avoided granting extra
I2RS Clients and I2RS Agents, I2RS Access Control policies can also privileges to their authorized I2RS client. I2RS
be distributed within a set of I2RS Clients or a set of I2RS Agents. agent should be shared by I2RS client with roughly
similar permissions. More explicitly, an I2RS agent
shared between I2RS 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.
REQ 15: I2RS Clients should be distributed and act as brokers for SEC-ENV-REQ 17: I2RS client and I2RS agent should be able to trace
Applications that share roughly similar permissions. This [RFC7922] the various transaction they perform as
avoids ending with over privileges I2RS Client compared to well as suspicious activities. These logs should be
hosted applications and thus discourages applications to collected regularly and analyzed by functions that
perform privilege escalation within an I2RS Client. may be out of the I2RS plane.
REQ 16: I2RS Agents should be avoided being granted over privileges Explanation:
regarding to their authorized I2RS Client. I2RS Agent should
be shared by I2RS Client with roughly similar permissions.
More explicitly, an I2RS Agent shared between I2RS Clients
that are only provided read access to the routing system
resources does not need to perform any write access, and so
should not be provided these accesses. 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 a I2RS
Agent that is already shared by I2RS Client that requires a
write access.
Access Control policies enforcement should be monitored in order to This restriction for distributed I2RS clients to act as brokers only
detect violation of the policies or detect an attack. Access Control for applications with roughly the same priviledges avoids the I2RS
policies enforcement may not be performed by the I2RS Client or the client extra priviledges compared to hosted applications, and
I2RS Agent as violation may require a more global view of the I2RS discourages applications from perform privilege escalation within an
Access Control policies. As a result, consistency check and 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 a I2RS agent that is already shared by I2RS client that
requires a write access.
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. mitigation may instead be performed by the management plane.
However, I2RS Clients and I2RS Agents play a central role. However, I2RS clients and I2RS agents play a central role.
REQ 17: I2RS Client and I2RS Agent should be able to log the various The I2RS agent can trace transactions that an I2RS client requests it
transaction they perform, as well as suspicious activities. to perform, and to link this to the application via the secondary
These logs should be collected regularly and analyzed by opaque identifier to the application. This information is placed in
functions that may be out of the I2RS plane. a tracing log which is retrieved by 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 instrusion has occurred.
Access Control policies should be implemented so that they remain 4.1.6. Managing Access Control Policy
manageable in short and longer term. This means the way they are
managed today should be address future deployment and use of I2RS.
REQ 18: Access Control should be managed in an automated way, that is Access control policies should be implemented so that the policies
granting or revoking an Application should not involve manual remain manageable in short and longer term deployments of the I2RS
configuration over the I2RS plane - like all the I2RS protocol and the I2RS plane.
Clients.
REQ 19: Access Control should be scalable when the number of Requirements:
Application grows as well as when the number of I2RS Client
increases. A typical implementation of a local I2RS Client
Access Control policies may result in creating manually a
system user associated to each Application. Such an approach
is likely not to scale when the number of Applications
increases or the number of I2RS Client increases.
REQ 20: Access Control should be dynamically managed and easy to be SEC-ENV-REQ 18: access control should be managed in an automated way,
updated. Although the number of I2RS Clients is expected to that is granting or revoking an application should
be lower than the number of Application, as I2RS Agent not involve manual configuration over the I2RS plane
provide access to the routing resource, it is of primary (I2RS client, I2RS agent, and application).
importance that an access can be granted or revoke in an
efficient way.
REQ 21: I2RS Clients and I2RS Agents should be uniquely identified in Explanation:
the network to enable centralized management of the I2RS
Access Control policies.
5.2. I2RS Agent Access Control policies Granting or configuring an application with new policy should not
require manual configuration of I2RS clients, I2RS agents, or other
applications.
The I2RS Agent Access Control restricts the routing system resource SEC-ENV-REQ 19: Access control should be scalable when the number of
application grows as well as when the number of I2RS
client increases.
Explanation:
A typical implementation of a local I2RS client access control
policies may result in creating manually a system user associated to
each application. Such an approach is likely not to scale when the
number of applications increases or the number of
SEC-ENV-REQ 20: Access control should be dynamically managed and
easily updated.
Explanation:
Although the numberof I2RS clients is expected to be lower than the
number of application, as I2RS agent provide access to the routing
resource, it is of primary importance that an access can be granted
or revoke in an efficient way.
SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely
identified in the network to enable centralized
management of the I2RS access control policies.
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
Overview:
The I2RS agent access control restricts the routing system resource
access to authorized identities - possible access policies may be access to authorized identities - possible access policies may be
none, read or write. The initiator of an access request to a routing none, read or write. The initiator of an access request to a routing
resource is always an Application. However, it remains challenging resource is always an application. However, it remains challenging
for the I2RS Agent to establish its access control policies based on for the I2RS agent to establish its access control policies based on
the application that initiates the request. First, when an I2RS the application that initiates the request.
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. Then, 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. Finally, each I2RS Client may contact
various I2RS Agent with different privileges and Access Control
policies.
This section provides recommendations on the I2RS Agent Access First, when an I2RS client acts as a broker, the I2RS agent may not
Control policies to keep I2RS Access Control coherent within the I2RS 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.
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.
Third, each I2RS client may contact various I2RS agent with different
privileges and access control policies.
4.2.1. I2RS Agent Access Control
This section provides recommendations on the I2RS agent access
control policies to keep I2RS access control coherent within the I2RS
plane. plane.
REQ 22: I2RS Agent Access Control policies should be primarily based Requirements:
on the I2RS Clients as described in
[I-D.ietf-i2rs-architecture].
REQ 23: I2RS Agent Access Control policies may be based on the SEC-ENV-REQ 22: I2RS agent access control policies should be
Application. In this case the identity of the Application primarily based on the I2RS clients as described in
MUST be authenticated by the I2RS Agent, and the secondary [RFC7921].
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 SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on
resource may also be updated outside the I2RS plane. Similarly, a the application if the application identity has been
given resource may be accessed by multiple I2RS users within the I2RS authenticated by the I2RS client and passed via the
plane. Although this is considered as an error, depending on the secondary identity to the I2RS agent.
I2RS Client that performed the update, the I2RS may accept or refuse
to overwrite the routing system resource.
REQ 24: The I2RS Agent should know which identity (most likely system SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g.
user) performed the latest update of the routing resource. system user) performed the latest update of the
This is true for an identity inside and outside the I2RS routing resource. This is true for an identity
plane, so the I2RS Agent can appropriately perform an update inside and outside the I2RS plane so the I2RS agent
according to the priorities associated to the requesting can appropriately perform an update according to the
identity and the identity that last updated the resource. On priorities associated to the requesting identity and
an environment perspective, the I2RS Agent MUST be aware when the identity that last updated the resource.
the resource has been modified outside the I2RS plane, as
well as its priority associated towards the I2RS plane.
Similar requirements exist for identities within the I2RS
plane, but belongs to the protocol security requirements.
REQ 25: the I2RS Agent should have a "I2RS Agent overwrite Policy" SEC-ENV-REQ 25: the I2RS agent should have a "I2RS agent overwrite
that indicates how identities can be prioritized. This Policy" that indicates how identities can be
requirements is also described in section 7.6 of prioritized. This requirements is also described in
[I-D.ietf-i2rs-architecture]. Similar requirements exist for section 7.6 of [RFC7921]. Similar requirements exist
components within the I2RS plane, but belongs to the protocol for components within the I2RS plane, but this is
security requirements. within the scope of the I2RS protocol security
requirements
[I-D.ietf-i2rs-protocol-security-requirements].
5.3. I2RS Client Access Control policies Explanation:
The I2RS Client Access Control policies are responsible for 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 I2RS
protocol for tracing.
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.
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 [I-D.ietf-i2rs-ephemeral-state] and security requirements
[I-D.ietf-i2rs-protocol-security-requirements].
4.2.2. I2RS Client Access Control Policies
Overview:
The I2RS client access control policies are responsible for
authenticating the application managing the privileges for the authenticating the application managing the privileges for the
applications, and enforcing access control to resources by the applications, and enforcing access control to resources by the
applications. As a result, applications.
REQ 26: I2RS Client should authenticate its applications. If the Requirements:
I2RS Client acts as a broker and supports multiple
Applications, it should authenticate each of them.
Authentication of the application may used GSSAPI, Secure RPC
mechanisms.
REQ 27: I2RS Client should define Access Control policies associated REQ 26: I2RS client should authenticate its applications. If the
I2RS client acts as a broker and supports multiple
applications, it should authenticate each application.
REQ 27: I2RS client should define access control policies associated
to each applications. An access to a routing resource by an to each applications. An access to a routing resource by an
Application should not be forwarded by the I2RS Client based application should not be forwarded immediately and
on the I2RS Agent Access Control policies. The I2RS Client transparently by the I2RS client based on the I2RS agent
should first check whether the Application has sufficient access control policies. The I2RS client should first check
privileges, and if so send an access request to the I2RS whether the application has sufficient privileges, and if so
Agent. When an I2RS Client has multiple identities that are send an access request to the I2RS agent.
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, no authentication mechanisms have being provided between the Explanation:
I2RS Client and the application, then I2RS Client may not act as
broker, and be instead dedicated to a single application. By doing
so, application authentication may rely on the I2RS authentication
mechanisms between the I2RS Client and the I2RS Agent. On the other
hand, although this is not recommended, the I2RS Access Control
policies is only enforced by the I2RS Agent.
5.4. Application and Access Control policies If no authentication mechanisms have being provided between the I2RS
client and the application, then 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.
Application does not enforce access control policies. Instead these If an I2RS client has multiple identities that are associated with
are enforced by the I2RS Clients and the I2RS Agents. This section different privileges for accessing an I2RS agent(s), the I2RS client
provides recommendations for Applications in order to ease I2RS access control policies should specify the I2RS client identity with
Access Control by the I2RS Client and the I2RS Agent. the access control policy.
As multiple ways may be used for an Application to communicate with 4.2.3. Application and Access Control Policies
its associated I2RS Client, it is not expected that all Applications
use the same conventional identifier format across the I2RS plane.
However, if all Applications are running on a dedicated system
sharing an I2RS Client, it is expected each Application may uniquely
identified, for example using different system users.
REQ 28: Applications SHOULD be uniquely identified by their Overview
associated I2RS Clients
The I2RS Client provides access to resource on its behalf and this 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.
Requirements:
SEC-ENV-REQ 28: applications SHOULD be uniquely identified by their
associated I2RS clients
Explanation:
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.
SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted
number of I2RS client
Explanation:
The I2RS client provides access to resource on its behalf and this
access should only be granted for trusted applications, or access should only be granted for trusted applications, or
Applications with an similar level of trust. On the other hand, this applications with an similar level of trust. This does not prevent
does not prevent an I2RS Client to host a large number of an I2RS client to host a large number of applications with the same
Applications. Similarly, an Application may also require to access levels of trust.
multiple I2RS Clients depending on 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 SEC-ENV-REQ 30: An application SHOULD be provided means and methods
of I2RS Client to contact their associated I2RS client.
REQ 30: Application SHOULD be provided means and methods to contact Explanation:
their associated I2RS Client. If the I2RS Client belongs to
the Application (as a module or a library for example), or
when the Application runs into a dedicated system (like a
container) with a I2RS Client, it is obvious which I2RS
Client the Application is associated to. On the other hand,
Applications may also remotely access the I2RS Client. In
this case, the Application is expected to be provided 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 I2RS Client. In this
case a FQDN may be preferred.
6. I2RS Application Isolation 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 to be able to retrieve
the necessary information to contact its associated I2RS client (e.g.
an IP address or a FQDN).
5. I2RS Application Isolation
A key aspect of the I2RS architecture is the network oriented A key aspect of the I2RS architecture is the network oriented
application. As these application are supposed to be independent, application. As these application are supposed to be independent,
controlled by independent and various tenants. In addition to controlled by independent and various tenants. In addition to
independent logic, these applications may be malicious. Then, these independent logic, these applications may be malicious. Then, these
applications introduce also programmability which results in fast applications introduce also programmability which results in fast
network settings. network settings.
The I2RS architecture should remain robust to these applications and The I2RS architecture should remain robust to these applications and
make sure an application does not impact the other applications. make sure an application does not impact the other applications.
This section discusses both security aspects related to This section discusses both security aspects related to
programmability as well as application isolation in the I2RS programmability as well as application isolation in the I2RS
architecture. architecture.
6.1. Robustness toward programmability 5.1. Robustness Toward Programmability
Overview
I2RS provides a programmatic interface in and out of the Internet I2RS provides a programmatic interface in and out of the Internet
routing system. This feature, in addition to the global network view routing system which provides the following advantages for security
provided by the centralized architecture comes with a few advantages
in term of security.
The use of automation reduces configuration errors. In addition, o the use of automation reduces configuration errors
this interface enables fast network reconfiguration. Agility
provides a key advantage in term of deployment as side effect
configuration may be easily addressed. Finally, it also provides
facilities to monitor and mitigate an attack when the network is
under attack.
On the other hand programmability also comes with a few drawbacks. o the programmatic interface enables fast network reconfiguration
First, applications can belong to multiple tenants with different and agility in adapting to network attacks,
objectives. This absence of coordination may result in unstable
routing configurations such as oscillations between network
configurations, and creation of loops for example. A typical example
would be an application monitoring a state and changing its state.
If another application performs the reverse operation, the routing
system may become unstable. Data and application isolation is
expected to prevent such situations to happen, however, to guarantee
the network stability, constant monitoring and error detection are
recommended to be activated.
REQ 31: The I2RS Agents should monitor constantly parts of the system o monitoring facilities to detect and configuration to mitigate a
for which I2RS Clients or Applications have provided network attack.
requests. It should also be able to detect I2RS Clients or
Applications that lead the routing system in an unstable
state. 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 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.
6.2. Application Isolation Programmability allows applications to flexible control which may
cause problems due to:
6.2.1. DoS o applications which belong to different tenants with different
objectives,
Requirements for robustness to Dos Attacks have been addressed in the o applications which lack coordination resulting in unstable routing
Communication channel section [I-D.ietf-i2rs-architecture]. configurations such as oscillations between network
configurations, and creation of loops for example. 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.
The I2RS plane requires data and application isolation to prevent
such situations to happen. However, to guarantee the network
stability constant monitoring and error detection are recommended to
be activated.
Requirement:
SEC-ENV-REQ 31: 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 I2RS clients or 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
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 hosted
applications.
SEC-ENV-REQ 33: I2RS agent does not make response redirection
possible unless the redirection is previously
validated and agreed by the destination.
SEC-ENV-REQ 34: avoid the use of underlying protocols that are not
robust to reflection attacks.
Explanation:
The I2RS interface is used by application to interact with the The I2RS interface is used by application to interact with the
routing states. As the I2RS Agent is shared between multiple routing states. As the I2RS agent is shared between multiple
applications, one application can prevent an application by applications, one application can prevent an application by
performing DoS or DDoS attacks on the I2RS Agent or on the network. performing DoS or DDoS attacks on the I2RS agent or on the network.
DoS attack targeting the I2RS Agent would consist in providing DoS attack targeting the I2RS agent would consist in providing
requests that keep the I2RS Agent busy for a long time. This may requests that keep the I2RS agent busy for a long time. These
involve heavy computation by the I2RS Agent for example to blocking attacks on the I2RS agent may involve an application (requesting
operations like disk access. In addition, DoS attacks targeting the through an I2RS Client) heavy computation by the I2RS agent in order
network may use specific commands like monitoring stream over the to block operations like disk access.
network. Then, DoS attack may be also targeting the application
directly by performing reflection attacks. Such an attack could be
performed by indicating the target 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 the I2RS Agent Some DoS attacks may attack the I2RS Client's reception of
controls the resources allocated to each I2RS Clients. I2RS notification and monitoring data stream over the network. Other DoS
Client that acts as broker may not be protected as attacks may focus on the application directly by performing
efficiently against these attacks unless they perform reflection attacks. Such an attack could be performed by first
resource controls themselves of their hosted applications. detecting an application is related to monitoring the RIB or changing
the RIB.
REQ 33: I2RS Agent does not make response redirection possible unless Reflection-based DoS may be performed at various levels utilizing UDP
the redirection is previously validated and agreed by the at the service to redirect data to a specific repository.
destination.
REQ 34: avoid the use of underlying protocols that are not robust to 5.2.2. Application Logic Control
reflection attacks.
6.2.2. Application Control Overview
Requirements for Application Control have been addressed in the I2RS Requirements for application control have been addressed in the I2RS
plane isolation as well as in the trusted Communication Channel plane isolation as well as in the trusted Communication Channel
sections. sections. This section examines how application logic must be design
to ensure application isolation.
Requirements:
SEC-ENV-REQ 35: 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.
Explanation:
Applications use the I2RS interface in order to update the routing Applications use the I2RS interface in order to update the routing
system. These updates may be driven by behavior on the forwarding system. These updates may be driven by behavior on the forwarding
plane or any external behaviors. In this case, correlating plane or any external behaviors. In this case, correlating
observation to the I2RS traffic may enable to derive the application observation to the I2RS traffic may enable to derive the application
logic. Once the application logic has been derived, a malicious logic. Once the application logic has been derived, a malicious
application may generate traffic or any event in the network in order application may generate traffic or any event in the network in order
to activate the alternate application. to activate the alternate application.
REQ 35: Application logic should remain opaque to external listeners. 6. Security Considerations
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.
7. Security Considerations
The whole document is about security. The 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.
8. Privacy Considerations 7. IANA Considerations
9. IANA Considerations No IANA considerations for this requirements.
10. Acknowledgments 8. Acknowledgments
A number of people provided a significant amount of helping comments A number of people provided a significant amount of helping comments
and reviews. Among them the authors would like to thank Russ White, and reviews. Among them the authors would like to thank Russ White,
Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas,
Alia Atlas, Linda Dunbar Alia Atlas, and Linda Dunbar.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References [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>.
[I-D.ietf-i2rs-architecture] [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-09 (work in System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
progress), March 2015. <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] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-01 (work in progress), September 2015. requirements-17 (work in progress), September 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 Authors' Addresses
Daniel Migault (editor) Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
Joel Halpern Joel Halpern
Ericsson Ericsson
 End of changes. 137 change blocks. 
635 lines changed or deleted 968 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/