draft-ietf-i2rs-security-environment-reqs-02.txt   draft-ietf-i2rs-security-environment-reqs-03.txt 
I2RS WG D. Migault I2RS WG D. Migault
Internet-Draft J. Halpern Internet-Draft J. Halpern
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: May 19, 2017 S. Hares Expires: September 8, 2017 S. Hares
Huawei Huawei
November 15, 2016 March 7, 2017
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-02 draft-ietf-i2rs-security-environment-reqs-03
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. The I2RS protocol security requirements the protocol used for I2RS. The security environment requirements
set the security for the communication between I2RS client and agent are the good security practices to be used during implementation and
while the security environment requirements are rather intended for deployment of the code related to the new interface to routing system
deployment or implementations features independent of the I2RS (I2RS) so that I2RS implementations can be securely deployed and
protocol. The environmental security requirements described in this operated.
document provide the good security practices to be used with the I2RS
protocol so that I2RS protocol implementations can be securely Environmental security requirements do not specify the I2RS protocol
deployed and operated. seecurity requirements. This is done in another document (draft-
ietf-i2rs-protocol-security-requirements).
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 May 19, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4
2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4
3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5 3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5
3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7 3.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6
3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8 3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10
4. I2RS Access Control for Routing System Resources . . . . . . 10 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11
4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. access control Enforcement Scope . . . . . . . . . . 12 4. I2RS Access Control for Routing System Resources . . . . . . 14
4.1.2. Notification Requirements . . . . . . . . . . . . . . 13 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14
4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. access control Enforcement Scope . . . . . . . . . . 17
4.1.4. Sharing access control Information . . . . . . . . . 14 4.1.2. Notification Requirements . . . . . . . . . . . . . . 17
4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Sharing access control Information . . . . . . . . . 18
4.1.5. Sharing Access Control in Groups of I2RS Clients and 4.1.5. Sharing Access Control in Groups of I2RS Clients and
Agents . . . . . . . . . . . . . . . . . . . . . . . 16 Agents . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.6. Managing Access Control Policy . . . . . . . . . . . 17 4.1.6. Managing Access Control Policy . . . . . . . . . . . 22
4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 18 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23
4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 19 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23
4.2.2. I2RS Client Access Control Policies . . . . . . . . . 20 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24
4.2.3. Application and Access Control Policies . . . . . . . 21 4.2.3. Application and Access Control Policies . . . . . . . 25
5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 22 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26
5.1. Robustness Toward Programmability . . . . . . . . . . . . 22 5.1. Robustness Toward Programmability . . . . . . . . . . . . 26
5.2. Application Isolation . . . . . . . . . . . . . . . . . . 23 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27
5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2. Application Logic Control . . . . . . . . . . . . . . 24 5.2.2. Application Logic Control . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. 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. The I2RS protocol security requirements the protocol used for I2RS. The I2RS protocol security requirements
[I-D.ietf-i2rs-protocol-security-requirements] set the security for [I-D.ietf-i2rs-protocol-security-requirements] define the security
the communication between I2RS client and agent while the security for the communication between I2RS client and agent. The security
environment requirements are rather intended for deployment or environment requirements are good security practices to be used
implementations features independent of the I2RS protocol. The during implementation and deployment of the I2RS protocol so that
environmental security requirements described in this document I2RS protocol implementations can be securely deployed and operated.
provide the good security practices to be used with the I2RS protocol These environment security requirements address the security
so that I2RS protocol implementations can be securely deployed and considerations described in the I2RS Architecture [RFC7921] required
operate. These environment security address the security to provide a stable and secure environment in which the dynamic
considerations for I2RS protocol environment considered in the I2RS programmatic interface to the routing system (I2RS) should operates.
Architecture [RFC7921] in order to provide a stable and secure
environment in which the dynamic programmatic interface to the
routing system (I2RS) should operates.
Even though the I2RS protocol is mostly concerned with the interface Even though the I2RS protocol is mostly concerned with the interface
between the I2RS client and the I2RS agent, the environmental between the I2RS client and the I2RS agent, the environmental
security requirements must consider the entire I2RS architecture and security requirements must consider the entire I2RS architecture and
specify where security functions may be hosted and what criteria specify where security functions may be hosted and what criteria
should be met in order to address any new attack vectors exposed by should be met in order to address any new attack vectors exposed by
deploying this architecture. Environment security for I2RS has to be deploying this architecture. Environment security for I2RS has to be
considered the complete I2RS architecture and not only on the considered the complete I2RS architecture and not only on the
protocol interface. protocol interface.
This document is structured as follows: This document is structured as follows:
o Section 2 describes the terminology used in this document, o Section 2 describes the terminology used in this document,
o Section 3 describes how the I2RS plane can be contained or o Section 3 describes how the I2RS plane can be securely isolated
isolated from existing management plane, control plane and from the management plane, control plane and forwarding plane.
forwarding plane.
o the subsequent sections of the document focuses on the security The subsequent sections of the document focuses on the security
within the I2RS plane including: within the I2RS plane.
* Section 4 analyzes how the I2RS access control policies can be o Section 4 analyzes how the I2RS access control policies can be
deployed throughout the I2RS plane in order to only grant deployed throughout the I2RS plane in order to limit access to the
access to the routing system resources to authorized components routing system resources to authorized components with the
with the authorized privileges. This includes providing a authorized privileges. This analysis examines how providing a
robust communication system between the components. robust communication system between the components aids the access
control.
* Section 5 details how I2RS keeps applications isolated from o Section 5 details how I2RS keeps applications isolated from
another and without affecting the I2RS components. another and without affecting the I2RS components. Applications
applications may be independent, with different scopes, owned may be independent, with different scopes, owned by different
by different tenants. In addition, the applications may modify tenants. In addition, the applications may modify the routing
the routing system in an automatic way. system in an automatic way.
Motivations are placed before the requirements are given. Motivations are described before the requirements are given.
The reader is expected to be familiar with the I2RS problem statement The reader is expected to be familiar with the I2RS problem statement
[RFC7920], I2RS architecture, [RFC7921], traceability requirements [RFC7920], I2RS architecture, [RFC7921], traceability requirements
[RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state
requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security
requirements [I-D.ietf-i2rs-protocol-security-requirements]. requirements [I-D.ietf-i2rs-protocol-security-requirements].
2. Terminology and Acronyms 2. Terminology and Acronyms
- Environment Security Requirements : Security requirements - Environment Security Requirements : Security requirements
specifying how the environment a protocol operates in needs to specifying how the environment a protocol operates in needs to
be secure. These requirements do not specify the protocol be secure. These requirements do not specify the protocol
security requirements. security requirements.
- I2RS plane: The environment the I2RS process is running on. It - I2RS plane: The environment the I2RS process is running on. It
includes the applications, the I2RS client and the I2RS agent. includes the applications, the I2RS client and the I2RS agent.
- I2RS user: The user of the I2RS client software or system. - I2RS user: The user of the I2RS client software or system.
- I2RS access control policies: policies controlling access of the - I2RS access control policies: The policies controlling access of
routing resources by applications. These policies are divided the routing resources by applications. These policies are
into policies applied by the I2RS client regarding applications divided into policies applied by the I2RS client regarding
and policies applied by the I2RS agent regarding I2RS clients. applications and policies applied by the I2RS agent regarding
I2RS clients.
- I2RS client access control policies: The access control policies - I2RS client access control policies: The access control policies
processed by the I2RS client. processed by the I2RS client.
- I2RS agent access control policies: The access control policies - I2RS agent access control policies: The access control policies
processed by the I2RS agent. processed by the I2RS agent.
2.1. Requirements notation 2.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. I2RS Plane Isolation 3. I2RS Plane Isolation
Isolating the I2RS plane from other network planes (the management, Isolating the I2RS plane from other network planes (the management,
forwarding plane, and control planes ) is fundamental to the security forwarding plane, and control planes) is fundamental to the security
of the I2RS environment. Clearly differentiating I2RS components of the I2RS environment. Clearly differentiating the I2RS components
from the rest of the network device does the following: from the rest of the network device does the following:
1. protects the I2RS components from vulnerabilities in other parts 1. protects the I2RS components from vulnerabilities in other parts
of the network, and of the network,
2. protects other systems vital to the health of the network from 2. protects other systems vital to the health of the network from
vulnerabilities in the I2RS plane. 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 placing software
software into modules. However, the I2RS plane cannot be considered into software containers within modules with clear interfaces to
as completely isolated from other planes so the interactions between exterior modules. In a similar way, although the I2RS plane cannot
the I2RS plane and other planes should be identified and controlled. be completely isolated from other planes, it can be carefully
The following is a brief description of how the I2RS plane positions designed so the interactions between the I2RS plane and other planes
itself in regard to the other planes. can be identified and controlled. The following is a brief
description of how the I2RS plane positions itself in regard to the
other planes.
3.1. I2RS Plane and Management plane 3.1. I2RS Plane and Management plane
The purpose of the I2RS plane 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. The control plane and forwarding planes are related to applications. Routing protocols often run in a control plane and
routing protocols, and I2RS is positioned on top of the control plane provide entries for the forwarding plane as shown in figure 1. The
and forwarding plane. The management plane is usually vendor I2RS plane which contains the I2RS applications, the I2RS client, the
specific and provides a broader control over the networking equipment north bound interface between the I2RS client and I2RS applications,
such as system service. Given the management plane's associated the I2RS protocol, the I2RS agent, and south bound API (SB API) to
privileges it is expected to be reserved to highly trusted users like the routing system. The communication interfaces in the I2RS plane
network administrators. are shown on the the left hand side of the figure 1.
The I2RS plane and the management plane both interact with several The management plane contains the mangement application the
common elements on forwarding and packet processing devices. management client, the north bound API between the management client
[RFC7921] describes several of these interaction points such as the and management application, the mangement server, the management
local configuration, the static system state, routing, and signaling. protocol (E.g. RESTCONF) between mangement client and management
A routing resource may be accessed by different means (APIs, server, and the south bound API between the management server and the
applications) and different planes which creates potential overlaps. control plane. The communication interfaces associated with the
Southbound APIs are often provided to limit the scope of the management plane are shown on the right hand side of figure 2.
management plane's and the I2RS plane's interaction with the routing
resources (as figure 1 shows). If there are conflicts in these The I2RS plane and the management plane both interact with control
overlapping southbound APIs, the conflicts should be resolved in a plane on which the routing systems operate. [RFC7921] describes
deterministic way. several of these interaction points such as the local configuration,
the static system state, routing, and signaling. A routing resource
may be accessed by I2RS plane, the mangement plane, or routing
protocol(s) which creates the potential for overlapping access. The
southbound APIs can limit the scope of the management plane's and the
I2RS plane's interaction with the routing resources.
Security focus:
Implementers need to carefully examine the southbound APIs from the
I2RS Plane and the management plane to determine if these APIs
overlap or conflict during use. If these APIs overlap or conflict,
these interactions can provide errors which are not traceable or
provide a risk for security intrusions between the two planes.
APIs that interact with the APIs that interact with the
I2RS Plane and Management PLane I2RS Plane and Management Plane
I2RS applications Mangement applications I2RS applications Mangement applications
|| NB API NB API || || NB API NB API ||
|| || || ||
I2RS plane management plane I2RS plane management plane
|| || || control plane configuration||
||SB API SB API || || datastore datastore ||
------------------------------------------- || ||
| Routing Resources | ||SB API SB API ||
|(forwarding plane, control plane, system) | ---------------------------------------
+------------------------------------------+ | Routing System with protocols |<protocols>
| control plane |
| (applied datastore) |
+-------------------------------------+
| forwarding plane |
+-------------------------------------+
| system |
+-------------------------------------+
Figure 1 - North Bound (NB) APIs and Figure 1 - North Bound (NB) APIs and
South Bound (SB) APIs South Bound (SB) APIs
The I2RS applications may be provided with a northbound API by the The north bound interface may also be a source of conflicting
I2RS client (as figure 1 shows). Similarly, the management plane may interactions between the I2RS plane and the management plane. It is
provide a northbound API to management application. The northbound important that conflicting interactions do not provide a deadlock
API from the management plane to the client application and the situation or allow a vulnerability due to data store leaking.
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.
To resolve conflicts in a northbound APIs, the deterministic 3.1.1. Deadlocks
resolution should have clear rules about which data plane with a
system takes precedence (wins during a conflict for resources). This
is important to prevent attacks that attempt to drive the two systems
into deadlock situation over which system has precedence (wins)
In the interactions between the I2RS plane and the applications, and How can a deadlock occur?
the management plane and the application is it important to prevent
the following things:
o the I2RS system "infecting" the management system with bad The I2RS applications and the management applications may both
information, interact with the Routing System. For example, I2RS applications may
set ephemeral state for an BGP routing process allowing a peer to
temporarily increase the maximum number of prefix it will accept. At
the same time, a management plane process may change a BGP Peer's
configuration for the maximum number of prefixes to decrease the
maximum number of prefixes. [RFC7921] suggests that implementations
SHOULD provide operator configurable knobs that will determine which
functions (I2RS or configuration management) has precedence in the
routing system, and that events should signal an I2RS agent if the
I2RS ephemeral state is overwritten. This is an example of policy
that prevents a deadlock situation for both the I2RS application and
the mangement application.
o the management system "infecting" the I2RS system with bad It is important that implementations include both policy knobs for
information directly, resolving the deadlocks between the the I2RS plane and the management
plane, and event signaling which reports deadlocks occuring within a
system supporting I2RS.
3.1.2. Data Store leaking
A vulnerability can occur if there is leakage between the I2RS
ephemeral control plane data store and the management plane's
configuration datastore. [I-D.ietf-netmod-revised-datastores]
describes a datastore architecture with control plane datastores
(such as the I2RS protocol's ephemeral datastore) being logically
different than the the configuration data store. The mixture of the
I2RS ephemeral configuration and management configuration is done by
the routing system code (specific to an implementation). The routing
system code resolves any conflict between I2RS control plane
configuration and the management plane configuration, and then
installs the state in the routing system. Implementation policy
determines which configuration state should be installed.
The applied datastore provides information on what is installed in
each part of a system - including the routing system. The
operational state data store provides both the applied data store
information and additional operational state from the control plane
protocols and control plane datastore.
Since it is the routing system code which mixing the configuration
from the I2RS control plane datastore and the management datastore to
create applied datastore for the routing system, this code must take
care to prevent:
o the I2RS system "infecting" the management system configuration
datastore with information from the I2RS control plane data store,
o the management system "infecting" the I2RS system data with data
not specifically imported by I2RS data models,
o the management system indirectly "infecting" the I2RS system by o the management system indirectly "infecting" the I2RS system by
propagating improproper information from one system to another via propagating improper information from one system to another via
I2RS. I2RS.
Prevention: In this circumstance, we define "infecting" as inteferring with and
leading into a incoherent state. Planned interactions such as
interactions denoted in in two cooperating Yang data modules is not
incoherent state.
For example, BGP configuration and BGP I2RS ephemeral state
configuration could have a defined interaction. The I2RS plane may
legitimately update a routing resource configured by the management
plane, or the reverse (the management plane updates a resource the
I2RS plane has configured) if the interactions are defined by Yang
modules or local policy. Infecting, is when the implementation is
updated by two processes resulting in an incoherent state. 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).
Prevention for Data Store Leakage
The primary protection in this space is going to need to be The primary protection in this space is going to need to be
validation rules on the data being sent/receive, notification of validation rules on:
changes that the I2RS agent sends the client, and other access
protections.
In this circumstance, we define "infecting" as inteferring with and o the data being sent/received by the I2RS agent (including
leading into a incoherent state. The I2RS plane may update a routing notification of changes that the I2RS agent sends the I2RS
resource configured by the management plane, or the reverse (the client),
management plane updates a resource the I2RS plane has configured).
Indirect "infecting", we define as as changes made by the I2RS plane o any data transferred between management datastores (configuration
that cause changes in routing protocols which add state unexpected by or operational state) and I2RS ephemeral control plane data
the management plane or the reverse (the mangement plane adding stores;
changes in routing protocols the I2RS plane does not expect).
o data transferred between I2RS Agent and Routing system,
o data transferred between a management server and the I2RS routing
system,
o data transfered between I2RS agent and system (e.g. interfaces
ephemeral configuration),
o data transferred between management server and the system (e.g.
interface configuration).
The next few paragraphs will provide some ideas on how this might be
implemented. These suggest implementation policy should resolve what
is not resolved in the YANG Data module definitions.
The Network Access Control Module (NACM) has been define to control
access to the configuration datastore via the management protocol
across a network. A similar network access control module could be
defined for the I2RS-NACM (per [I-D.ietf-netconf-rfc6536bis].
Figure 2 shows how the I2RS-NACM could be created to support parallel
features with the management protocol (E.g. NETCONF) NACM.
I2RS implementations may also need to define an access modules which
control access to the routing system (Routing Access Control Module
(RACM)) by policy. The I2RS-RACM would control how the I2RS agent
access the routing system through the SB API interface. In parallel,
the management system would have a RACM to control the SB API
interface (see figure 2). I2RS agent and the management server may
want to read/write system information interfaces or other system
functions. In order to prevent leakage between the I2RS system and
the management system, there needs to be system access control module
(SACM) that protects the jointly held data.
I2RS- || (I2RS Mgt protocol ||
NACM || Protocol) (E.g. NETCONF)|| NACM
------- ----------
I2RS ||I2RS Agent Mgt server||
SACM || I2RS Control-DS config DS || SACM
-----|| (RACM) (RACM) ||=======||
| ||SB API SB API || ||
| +-----------------------------------+ ||
| | Routing System with protocols | ||
| | control plane | ||
| | (applied datastore) | ||
| | (operational state) | ||
| +--------------||-------------------+ ||
| | forwarding plane | ||
| +--------------||-------------------+ ||
---| system |======||
+-----------------------------------+
*Mgt = management
DS = Datastore
Control-DS = Control plane protocol data store
NACM = Network Access Control Module
RACM = Routing System Access Control Module
figure 2
The I2RS clients and the I2RS agents also need a set of policy which
defines what can be received from the network or sent to the network.
I2RS applications Mangement applications
|| NB API MB API ||
|| (APP NAC policy) (APP NAC policy)||
|| I2RS client mgt client ||
|| (NAC policy) (NAC policy)||
|| ||
I2RS protocol mgt protocol
(NETCONF/RESTCONF)
figure 3
3.2. I2RS Plane and Forwarding Plane 3.2. I2RS Plane and Forwarding Plane
Applications hosted by the I2RS client belong to the I2RS plane. It Applications hosted by the I2RS client belong to the I2RS plane. It
is difficult to constrained these applications to the I2RS plane, or is difficult to constrained these applications to the I2RS plane, or
even to limit their scope within the I2RS plane. Applications using even to limit their scope within the I2RS plane. Applications using
I2RS may also interact with components outside the I2RS plane. For I2RS may also interact with components outside the I2RS plane. For
example an application may use an I2RS client to configure the example an application may use an management client to configure the
network or monitored events via an I2RS agent on a single machine, or network and monitored events via an I2RS agent as figure 4 shows.
multiple I2RS agents each on a single machine.
+--------------------------------------+
| Application |
+--------------------------------------+
|| NB API NB API ||
|| I2RS client mgt client ||
|| ||
I2RS protocol mgt protocol
(NETCONF/RESTCONF)
figure 4
Applications may also communicate with multiple I2RS clients in order Applications may also communicate with multiple I2RS clients in order
to have a broader view of the current and potential states of the to have a broader view of the current and potential states of the
network and the I2RS plane itself. These varied remote communication network and the I2RS plane itself. These varied remote communication
relationships between applications using the I2RS protocol to change relationships between applications using the I2RS protocol to change
the forwarding plane make it possible for an individual application the forwarding plane make it possible for an individual application
to be an effective attack vector against the operation of the to be an effective attack vector against the operation of the
network, a router's I2RS plane, the forwarding plane of the routing network, a router's I2RS plane, the forwarding plane of the routing
system, and other planes (management and control planes). system, and other planes (management and control planes).
skipping to change at page 8, line 19 skipping to change at page 11, line 26
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. I2RS client configures, monitors or receives events via destination. I2RS client configures, monitors or receives events via
the I2RS agent's interaction with the routing system including the the I2RS agent's interaction with the routing system including the
process that handling the control plane signaling protocols (BGP, process that handling the control plane signaling protocols (BGP,
ISIS, OSPF, etc.), route information databases (RIBs), and interface ISIS, OSPF, etc.), route information databases (RIBs), and interface
databases. In some situation to manage an network outage or to databases. In some situation to manage an network outage or to
control traffic, the I2RS protocol may modify information in the control traffic, the I2RS protocol may modify information in the
route database or the configuration of routing process. While this route database or the configuration of routing process. While this
is not a part of normal processing, such action that allows the is not a part of normal processing, such action allows the network
network operator to bypass temporary outages or DoS attacks. operator to bypass temporary outages or DoS attacks.
This capability to modify the routing process information carries This capability to modify the routing process information carries
with it the risk that the I2RS agent may alter the normal properties with it the risk that the I2RS agent may alter the normal properties
of the routing protocols which provide normal loop free routing in of the routing protocols which provide normal loop free routing in
the control plane. The information configured by the I2RS agent into the control plane. For example, information configured by the I2RS
routing process or RIBs could cause problems, or state which is agent into routing process or RIBs could cause forwarding problems or
inserted or deleted from routing processes (control traffic, routing loops. As a second example, state which is inserted or
counters, etc.) could cause the control plan to fail to converge or deleted from routing processes (control traffic, counters, etc.)
fail). could cause the routing protocols to fail to converge or loop).
Prevention measures: Prevention measures:
The I2RS system can provide checks that during and after the problem The I2RS implementation can provide internal checks that after a
has been resolved that loop free routing is preserved. These checks routing system protocol changes that it is still operating correctly.
should check the preservation of all facets of routing including the These checks would be specific to the routing protocol the I2RS Agent
following: routing with loop free alternates, tunnelled interfaces, would change. For example, if a BGP maximum prefix limit for a BGP
virtual overlays, and other such constructions. peer is lowered then the BGP peer should not allow the number
prefixes received from that peer to exceed this number.
3.4. Requirements 3.4. Requirements
To isolate I2RS transactions from other planes, it is required that: To isolate I2RS transactions from other planes, it is required that:
SEC-ENV-REQ 1: application-to-routing system resources SEC-ENV-REQ 1: Application-to-routing system resources
communications should use an isolated communication communications should use an isolated communication
channel. Various level of isolation can be channel. Various level of isolation can be
considered. The highest level of isolation may be considered. The highest level of isolation may be
provided by using a physically isolated network. provided by using a physically isolated network.
Alternatives may also consider logical isolation Alternatives may also consider logical isolation
(e.g. using vLAN). In a virtual environment that (e.g. using vLAN). In a virtual environment that
shares a common infrastructure, encryption may also shares a common infrastructure, encryption may also
be used as a way to enforce isolation. Encryption be used as a way to enforce isolation. Encryption
can be added by using a secure transport required by can be added by using a secure transport required by
the I2RS protocol security the I2RS protocol security
[I-D.ietf-i2rs-protocol-security-requirements], and [I-D.ietf-i2rs-protocol-security-requirements], and
sending the non-confidential I2RS data (designed for sending the non-confidential I2RS data (designed for
a non-secure transport) over a secure transport. a non-secure transport) over a secure transport.
SEC-ENV-REQ 2: The interface used by the routing element to receive SEC-ENV-REQ 2: The interface used by the routing element to receive
I2RS transactions via the I2RS protocol (e.g. the IP I2RS transactions via the I2RS protocol (e.g. the IP
address) should be a dedicated physical or logical address) SHOULD be a dedicated physical or logical
interface. As previously, mentioned a dedicated interface. As previously, mentioned a dedicated
physical interface may contribute to a higher physical interface may contribute to a higher
isolation. Isolation may also be achieved by using a isolation. Isolation may also be achieved by using a
dedicated IP address or a dedicated port. dedicated IP address or a dedicated port.
SEC-ENV-REQ 3: An I2RS agent should have permissions separate from SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for
any other entity (for example any internal system interaction with each routing element and access to
management processes or CLI processes). the routing element should governed by policy
specific to the I2RS agent's interfaces (network,
routing system, system, or cross-datastore).
Explanation: Explanation:
When the I2RS agent performs an action on a routing element, the When the I2RS agent performs an action on a routing element, the
action is performed via process(es) associated to a routing process. action is performed in a process (or processes) associated with a
routing process. For example, in a typical UNIX system, the user is
designated with a user id (uid) and belongs to groups designated by
group ids (gid). If such a user id (uid) and group id (gid) is the
identifier for the routing processes peforming routing tasks in the
control plane, then the I2RS Agent process would communicate with
these routing processes. It is important that the I2RS agent has its
own unique identifier and the routing processes have their own
identifier so that access control can uniquely filter data between
I2RS Agent and routing processes.
For example, in a typical UNIX system, the user is designated with a The specific policy the the I2RS agent uses to filter data from the
user id (uid) and belongs to groups designated by group ids (gid). network or from different processes on a system (routing, system or
If such a user id (uid) and group id (gid) is the identifier for the cross-datastore) should be specific to the I2RS agent. For example,
routing processes peforming routing tasks in the control plane, then the network access filter policy that the I2RS agent uses should be
the I2RS Agent process would communicate with these routing uniquely identifiable from the configuration datastore updated by a
processes. It is important that the I2RS agent has its own unique management protocol.
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 SEC-ENV-REQ 4: I2RS plane should be informed when a routing system
resource is modified by a user outside the I2RS plane resource is modified by a user outside the I2RS plane
access. Notifications from the control plane SHOULD access. Notifications from the control plane SHOULD
not to flood the I2RS plane, and rate limiting (or not to flood the I2RS plane, and rate limiting (or
summarization) is expected to be applied. These summarization) is expected to be applied. These
routing system notification MAY translated to the routing system notification MAY translated to the
appropriate I2RS agent notifications, and passed to appropriate I2RS agent notifications, and passed to
various I2RS clients via notification relays. (This various I2RS clients via notification relays.
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: Explanation:
I2RS resource may be shared with the management plane and the control This requirements is also described in section 7.6 of [RFC7921] for
plane. The I2RS routing system resource management is limited to the the I2RS client, and this section extends it to the entire I2RS plane
I2RS plane. As such, update of I2RS routing system outside of the (I2RS agent, client, and application).
I2RS plane may remain unnoticed unless and until explicitly notified
to the I2RS plane. Such notification is expected to trigger A routing system resource may be accessed by the management plane or
synchronization of the I2RS resource state within each I2RS control plane protocols so a change to a routing system resource may
component. This guarantees that I2RS resource are maintained in a remain unnoticed unless and until the routing system resource
coherent state among the I2RS plane. In addition, depending on the notifies the I2RS plane by notifying the I2RS agent. Such
I2RS resource that is updated as well as the origin of the notification is expected to trigger synchronization of the I2RS
modification performed, the I2RS access control policies may be resource state between the I2RS agent and I2RS client - signalled by
impacted. Further an I2RS client is more likely to update an I2RS the I2RS agent sending a notification to an I2RS client.
resources that has been updated by itself, then by the management
plane. The updated resource should be available in the operational state if
there is a yang module referencing that operational state, but this
is not always the case. In the cases, where operational state is not
updated, the I2RS SB (southbound) API should include the ability to
send a notification.
SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite
policy". Such policy defines how an I2RS is able to policy". Such policy defines how an I2RS is able to
update and overwrite a resource set by a user outside update and overwrite a resource set by a user outside
the I2RS plane. Such hierarchy has been described in the I2RS plane. Such hierarchy has been described in
section 6.3 and 7.8 of [RFC7921] section 6.3 and 7.8 of [RFC7921]
Explanation: Explanation:
A key part of the I2RS architecture is notification regarding routing A key part of the I2RS architecture is notification regarding routing
skipping to change at page 11, line 11 skipping to change at page 14, line 29
agents can be located locally in a closed environment or distributed agents can be located locally in a closed environment or distributed
over open networks. The normal case for routing system management is over open networks. The normal case for routing system management is
over an open environment. Even in a closed environment access over an open environment. Even in a closed environment access
control policies should be carefully defined to be able to, in the control policies should be carefully defined to be able to, in the
future to carefully extend the I2RS plane to remote applications or future to carefully extend the I2RS plane to remote applications or
remote I2RS clients. remote I2RS clients.
[I-D.ietf-i2rs-protocol-security-requirements] defines the security [I-D.ietf-i2rs-protocol-security-requirements] defines the security
requirements of the I2RS protocol between the I2RS client and the requirements of the I2RS protocol between the I2RS client and the
I2RS agent over a secure transport. This section focuses on I2RS I2RS agent over a secure transport. This section focuses on I2RS
access control architecture (section 5.1), access control policies of access control architecture (section 4.1), access control policies of
the I2RS agent (section 5.2), the I2RS client (section 5.3), and the the I2RS agent (section 4.2), the I2RS client (section 4.3), and the
application (section 5.4). application (section 4.4).
4.1. I2RS Access Control Architecture 4.1. I2RS Access Control Architecture
Overview: 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 attached to one or more agents (case a and case b single application attached to one or more agents (case a and case b
in figure 2 below). In other cases, the I2RS client may be connected in figure 4 below). In other cases, the I2RS client may be connected
to two applications (case c in figure 2 below), or the I2RS may act to two applications (case c in figure 4 below), or the I2RS may act
as a broker (agent/client device shown in case d in the figure 2 as a broker (agent/client device shown in case d in the figure 4
below). The I2RS client broker approach provides scalability to the below). The I2RS client broker approach provides scalability to the
I2RS architecture as it avoids that each application be registered to I2RS architecture as it avoids that each application be registered to
the 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.
The goal of the security environment requirements in this section are The goal of the security environment requirements in this section are
to control the interactions between the applications and the I2RS to control the interactions between the applications and the I2RS
client, and the interactions between the I2RS client and the I2RS client, and the interactions between the I2RS client and the I2RS
agent. The key challenge is that the I2RS architecture puts the I2RS agent. The key challenge is that the I2RS architecture puts the I2RS
Client in control of the stream of communication (application to I2RS Client in control of the stream of communication (application to I2RS
skipping to change at page 12, line 47 skipping to change at page 16, line 47
+-------------+ +--------+ | I2RS | +-------------+ +--------+ | I2RS |
| I2RS |==|I2RS |=====|agent 3/| | I2RS |==|I2RS |=====|agent 3/|
|application 1| |client 1| ==|client 3+----+ |application 1| |client 1| ==|client 3+----+
+-------------+ +--------+ | +--+-----+ | +-------------+ +--------+ | +--+-----+ |
| | | | | |
+-------------+ +--------+ | +-------+ +--|----+ +-------------+ +--------+ | +-------+ +--|----+
| I2RS | |I2RS |===| |I2RS | |I2RS | | I2RS | |I2RS |===| |I2RS | |I2RS |
|application 2|==|client 2| |agent 1| |agent 2| |application 2|==|client 2| |agent 1| |agent 2|
+-------------+ +--------+ +-------+ +-------+ +-------------+ +--------+ +-------+ +-------+
figure 4
4.1.1. access control Enforcement Scope 4.1.1. access control Enforcement Scope
SEC-ENV-REQ 6: I2RS access control should be performed through the SEC-ENV-REQ 6: I2RS access control should be performed through the
whole I2RS plane. It should not be enforced by the whole I2RS plane. It should not be enforced by the
I2RS agent only within the routing element. Instead, I2RS agent only within the routing element. Instead,
the I2RS client should enforce the I2RS client access the I2RS client should enforce the I2RS client access
control against applications and the I2RS agent control against applications and the I2RS agent
should enforce the I2RS agent access control against should enforce the I2RS agent access control against
the I2RS clients. The mechanisms for the I2RS client the I2RS clients. The mechanisms for the I2RS client
access control are not in scope of the I2RS access control are not in scope of the I2RS
skipping to change at page 13, line 39 skipping to change at page 17, line 45
Explanation: Explanation:
In case the I2RS client access control or the I2RS agent access In case the I2RS client access control or the I2RS agent access
control does not grant access to a routing system resource, the control does not grant access to a routing system resource, the
application should be able to determine whether its request has been 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 rejected by the I2RS client or the I2RS agent as well as the reason
that caused the reject. that caused the reject.
SEC-REQ-07 indicates the I2RS agent may reject the request because SEC-REQ-07 indicates the I2RS agent may reject the request because
the I2RS client is not an authorized I2RS client or have enough the I2RS client is not an authorized I2RS client or lacks the
privileges to perform the requested transaction (read, write, start privileges to perform the requested transaction (read, write, start
notifications or logging). The I2RS client should be notified of the notifications or logging). The I2RS client should be notified of the
reason the I2RS agent rejected the transaction due to a lack of reason the I2RS agent rejected the transaction due to a lack of
authorization or priviledges, and the I2RS client should return a authorization or priviledges, and the I2RS client should return a
message to the application indicating the I2RS agent reject the message to the application indicating the I2RS agent reject the
transacation with an indication of this reason. Similarly, if the transacation with an indication of this reason. Similarly, if the
I2RS client does not grant the access to the application, the I2RS I2RS client does not grant the access to the application, the I2RS
client should also inform the application. An example of an error client should also inform the application. An example of an error
message could be, "Read failure: you do not have the read message could be, "Read failure: you do not have the read
permission", "Write failure: you do not have write permission", or permission", "Write failure: you do not have write permission", or
"Write failure: resource accessed by someone else". "Write failure: resource accessed by someone else".
This requirement has been written in a generic manner as it concerns This requirement has been written in a generic manner as it concerns
the following interactions: the following interactions:
o interactions between the application and the I2RS client, o interactions between the application and the I2RS client,
o interactions between the I2RS client and the I2RS agent (security o interactions between the I2RS client and the I2RS agent at a
requirements are described by content level (Protocol security requirements are described by
[I-D.ietf-i2rs-protocol-security-requirements]), [I-D.ietf-i2rs-protocol-security-requirements]), and
o and interactions between the I2RS agent and the I2RS routing o interactions between the I2RS agent and the I2RS routing system
system (forwarding plane, control plane, and routing plane). (forwarding plane, control plane, and routing plane).
4.1.3. Trust 4.1.3. Trust
SEC-ENV-REQ 8: In order to provide coherent access control policies SEC-ENV-REQ 8: In order to provide coherent access control policies
enforced by multiple parties (e.g. the I2RS client or enforced by multiple parties (e.g. the I2RS client or
the I2RS agent), theses parties should trust each the I2RS agent), theses parties should trust each
others, and communication between them should also be others, and communication between them should also be
trusted (e.g. TLS) in order to reduce additional trusted (e.g. TLS) in order to reduce additional
vector of attacks. vector of attacks.
skipping to change at page 16, line 18 skipping to change at page 20, line 22
I2RS client may sync its associated I2RS access control I2RS client may sync its associated I2RS access control
policies with the I2RS agent to limit the number of refused policies with the I2RS agent to limit the number of refused
access requests being sent to the I2RS agent. The I2RS client access requests being sent to the I2RS agent. The I2RS client
is expected to balance benefits and problems with synchronizing is expected to balance benefits and problems with synchronizing
its access control policies with the I2RS agent to proxy its access control policies with the I2RS agent to proxy
request validation versus simply passing the access request to request validation versus simply passing the access request to
the I2RS agent. the I2RS agent.
- 2) A single I2RS client connects to multiple applications or - 2) A single I2RS client connects to multiple applications or
acts as a broker for many applications: acts as a broker for many applications:
In the case the I2RS agent has a single I2RS client In this case the I2RS agent has a single I2RS client
attached. This may end up in a situation where the I2RS attached, so the I2RS client could end being configured to
client is being delegated by the I2RS agent to enforce enforce access control policies instead of the I2RS Agent.
access control policies. In such as case, the I2RS agent In this circumstance, it is possible that the I2RS agent may
may grant the I2RS client with high priviledges and blidngly grant an I2RS client with high priviledges and blindly trust
trust the I2RS client without enforcing access control the I2RS client without enforcing access control policies on
policies on what the I2RS client can do. Such a situation what the I2RS client can do. Such a situation must be
must be avoided as it could be used by malicious avoided as it could be used by malicious applications for a
applications for a priviledge escalation by compromising the priviledge escalation by compromising the I2RS client
I2RS client. In this situation, the application uses the causing the I2RS client to perform some action on behalf of
I2RS client to perform some action on behalf of the the application that it normally does not have the
application that it normally does not have the priviledges priviledges to perform. In order to mitigate such attack,
to perform. In order to mitigate such attack, the I2RS the I2RS client that connects to multiple applications or
client that connects to multiple applications or operates as operates as a broker is expected to host application with an
a broker is expected to host application with an equivalent equivalent level of privileges.
level of privileges.
4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents
Overview: Overview:
To distribute the I2RS access control policies between I2RS clients To distribute the I2RS access control policies between I2RS clients
and I2RS agents, I2RS access control policies can also be distributed and I2RS agents, I2RS access control policies can also be distributed
within a set of I2RS clients or a set of I2RS agents. within a set of I2RS clients or a set of I2RS agents.
Requirements: Requirements:
skipping to change at page 18, line 25 skipping to change at page 22, line 33
SEC-ENV-REQ 19: Access control should be scalable when the number of SEC-ENV-REQ 19: Access control should be scalable when the number of
application grows as well as when the number of I2RS application grows as well as when the number of I2RS
client increases. client increases.
Explanation: Explanation:
A typical implementation of a local I2RS client access control A typical implementation of a local I2RS client access control
policies may result in creating manually a system user associated to policies may result in creating manually a system user associated to
each application. Such an approach is likely not to scale when the each application. Such an approach is likely not to scale when the
number of applications increases or the number of number of applications increases into the hundreds.
SEC-ENV-REQ 20: Access control should be dynamically managed and SEC-ENV-REQ 20: Access control should be dynamically managed and
easily updated. easily updated.
Explanation: Explanation:
Although the numberof I2RS clients is expected to be lower than the Although the numberof I2RS clients is expected to be lower than the
number of application, as I2RS agent provide access to the routing number of application, as I2RS agent provide access to the routing
resource, it is of primary importance that an access can be granted resource, it is of primary importance that an access can be granted
or revoke in an efficient way. or revoke in an efficient way.
skipping to change at page 20, line 14 skipping to change at page 24, line 24
for components within the I2RS plane, but this is for components within the I2RS plane, but this is
within the scope of the I2RS protocol security within the scope of the I2RS protocol security
requirements requirements
[I-D.ietf-i2rs-protocol-security-requirements]. [I-D.ietf-i2rs-protocol-security-requirements].
Explanation: Explanation:
If the I2RS application is authenticated to the I2RS client, and the If the I2RS application is authenticated to the I2RS client, and the
I2RS client is authenticated to the I2RS agent, and the I2RS client I2RS client is authenticated to the I2RS agent, and the I2RS client
uses the opaque secondary identifier to pass an authenticated uses the opaque secondary identifier to pass an authenticated
identifier to the I2RS agent, this may be used for access control. identifier to the I2RS agent, then this identifier may be used for
However, caution should be taken when using this chain of access control. However, caution should be taken when using this
authentication since the secondary identifier is intended in the I2RS chain of authentication since the secondary identifier is intended in
protocol for tracing. the I2RS protocol only to aid traceability.
From the environment perspective the I2RS agent MUST be aware when From the environment perspective the I2RS agent MUST be aware when
the resource has been modified outside the I2RS plane by another the resource has been modified outside the I2RS plane by another
plane (management, control, or forwarding). The prioritization plane (management, control, or forwarding). The prioritization
between the different planes should set a deterministic policy that between the different planes should set a deterministic policy that
allows the collision of two planes (I2RS plane and another plane) to allows the collision of two planes (I2RS plane and another plane) to
be resolved via an overwrite policy in the I2RS agent. be resolved via an overwrite policy in the I2RS agent.
Similar requirements exist for knowledge about identities within the Similar requirements exist for knowledge about identities within the
I2RS plane which modify things in the routing system, but this is I2RS plane which modify things in the routing system, but this is
skipping to change at page 21, line 31 skipping to change at page 25, line 41
Overview Overview
Applications do not enforce access control policies. Instead these Applications do not enforce access control policies. Instead these
are enforced by the I2RS clients and the I2RS agents. This section are enforced by the I2RS clients and the I2RS agents. This section
provides recommendations for applications in order to ease I2RS provides recommendations for applications in order to ease I2RS
access control by the I2RS client and the I2RS agent. access control by the I2RS client and the I2RS agent.
Requirements: Requirements:
SEC-ENV-REQ 28: applications SHOULD be uniquely identified by their SEC-ENV-REQ 28: Applications SHOULD be uniquely identified by their
associated I2RS clients associated I2RS clients
Explanation: Explanation:
Different application may use different methods (or multiple methods) Different application may use different methods (or multiple methods)
to communicate with its associated I2RS client, and each application to communicate with its associated I2RS client, and each application
may not use the same form of an application identifier. However, the may not use the same form of an application identifier. However, the
I2RS client must obtain an identifier for each application. One I2RS client must obtain an identifier for each application. One
method for this identification can be a system user id. method for this identification can be a system user id.
skipping to change at page 22, line 15 skipping to change at page 26, line 26
SEC-ENV-REQ 30: An application SHOULD be provided means and methods SEC-ENV-REQ 30: An application SHOULD be provided means and methods
to contact their associated I2RS client. to contact their associated I2RS client.
Explanation: Explanation:
It is obvious when an I2RS client belongs to the application as part 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 of a module or a library that the application can communicate with a
I2RS client. Similarly, if the application runs into a dedicated I2RS client. Similarly, if the application runs into a dedicated
system with a I2RS client, it is obvious which I2RS client the system with a I2RS client, it is obvious which I2RS client the
application should contact. If the application connects to the I2RS application should contact. If the application connects to the I2RS
client remotely, the application needs some to be able to retrieve client remotely, the application needs some means to retrieve the
the necessary information to contact its associated I2RS client (e.g. necessary information to contact its associated I2RS client (e.g. an
an IP address or a FQDN). IP address or a FQDN).
5. I2RS Application Isolation 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 that uses the I2RS high bandwidth programmatic interface
controlled by independent and various tenants. In addition to to monitor or change one or more routing systems. I2RS applications
independent logic, these applications may be malicious. Then, these could be control by a single entity or serve various tenants of the
applications introduce also programmability which results in fast network. If multiple entities use an I2RS application to monitor or
network settings. change the network, security policies must preserve the isolation of
each entity's control and not let malicious entities controlling one
I2RS application interfere with other I2RS applications.
The I2RS architecture should remain robust to these applications and
make sure an application does not impact the other applications.
This section discusses both security aspects related to 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.
5.1. Robustness Toward Programmability 5.1. Robustness Toward Programmability
Overview 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 which provides the following advantages for security routing system which provides the following advantages for security:
o the use of automation reduces configuration errors
o the use of automation reduces configuration errors;
o the programmatic interface enables fast network reconfiguration o the programmatic interface enables fast network reconfiguration
and agility in adapting to network attacks, and agility in adapting to network attacks; and
o monitoring facilities to detect and configuration to mitigate a o monitoring facilities to detect a network attack, and
network attack. configuration changes which can help mitigate the network attack.
Programmability allows applications to flexible control which may Programmability allows applications to flexible control which may
cause problems due to: cause problems due to:
o applications which belong to different tenants with different o applications which belong to different tenants with different
objectives, objectives,
o applications which lack coordination resulting in unstable routing o applications which lack coordination resulting in unstable routing
configurations such as oscillations between network configurations such as oscillations between network
configurations, and creation of loops for example. For example, configurations, and creation of loops for example. For example,
skipping to change at page 23, line 26 skipping to change at page 27, line 34
The I2RS plane requires data and application isolation to prevent The I2RS plane requires data and application isolation to prevent
such situations to happen. However, to guarantee the network such situations to happen. However, to guarantee the network
stability constant monitoring and error detection are recommended to stability constant monitoring and error detection are recommended to
be activated. be activated.
Requirement: Requirement:
SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of
the system for which I2RS clients or applications the system for which I2RS clients or applications
have provided requests. It should also be able to have provided requests. It should also be able to
detect I2RS clients or applications that lead the detect any I2RS clients or applications causing
routing system in an unstable state. problems that may lead the routing system in an
unstable state.
Explanation: Explanation:
Monitoring consists at least in logging events and eventually provide Monitoring consists at least in logging events and receiving streams
notifications or alerts to the management plane in case, something of data. I2RS Plane implementations should monitor the I2RS
has been detected. The management plane is in charge of collecting applications and I2RS clients for potential problems. The cause for
the logs, the notifications and eventually to consider the the I2RS clients or applications providing problematic requests can
appropriated actions. A typical action may be the update of I2RS be failures in the implementation code or malicious intent. ]
access control policies for example or re-configuring routing
elements.
5.2. Application Isolation 5.2. Application Isolation
5.2.1. DoS 5.2.1. DoS
Overview: Overview:
Requirements for robustness to DoS attacks have been addressed in the Requirements for robustness to DoS attacks have been addressed in the
communication channel section [RFC7921]. This section focuses on communication channel section [RFC7921]. This section focuses on
requirements for application isolation that help prevent DoS. requirements for application isolation that help prevent DoS.
Requirements: Requirements:
skipping to change at page 24, line 9 skipping to change at page 28, line 21
Requirements: Requirements:
SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS
agent controls the resources allocated to each I2RS agent controls the resources allocated to each I2RS
clients. I2RS client that acts as broker may not be clients. I2RS client that acts as broker may not be
protected as efficiently against these attacks unless protected as efficiently against these attacks unless
the broker performs resource controls for the hosted the broker performs resource controls for the hosted
applications. applications.
SEC-ENV-REQ 33: I2RS agent does not make response redirection SEC-ENV-REQ 33: I2RS agent SHOULD make a response redirection unless
possible unless the redirection is previously the redirection is previously validated and agreed by
validated and agreed by the destination. the destination.
SEC-ENV-REQ 34: avoid the use of underlying protocols that are not SEC-ENV-REQ 34: I2RS Appications should avoid the use of underlying
robust to reflection attacks. protocols that are not robust to reflection attacks.
Explanation: 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. If the I2RS client is shared between multiple
applications, one application can prevent an application by applications, one application can use the I2RS client to perform DoS
performing DoS or DDoS attacks on the I2RS agent or on the network. or DDoS attacks on the I2RS agent(s) and through the I2RS agents
DoS attack targeting the I2RS agent would consist in providing attacks on the network. DoS attack targeting the I2RS agent would
requests that keep the I2RS agent busy for a long time. These consist in providing requests that keep the I2RS agent busy for a
attacks on the I2RS agent may involve an application (requesting long time. These attacks on the I2RS agent may involve an
through an I2RS Client) heavy computation by the I2RS agent in order application (requesting through an I2RS Client) heavy computation by
to block operations like disk access. the I2RS agent in order to block operations like disk access.
Some DoS attacks may attack the I2RS Client's reception of Some DoS attacks may attack the I2RS Client's reception of
notification and monitoring data stream over the network. Other DoS notification and monitoring data stream over the network. Other DoS
attacks may focus on the application directly by performing attacks may focus on the application directly by performing
reflection attacks. Such an attack could be performed by first reflection attacks to reflect traffic. In such an attack could be
detecting an application is related to monitoring the RIB or changing performed by first detecting an application is related to monitoring
the RIB. the RIB or changing the RIB. Reflection-based DoS may be also attack
at various levels in the stack utilizing UDP at the service to
redirect data to a specific repository
Reflection-based DoS may be performed at various levels utilizing UDP I2RS implementation should consider how to protect I2RS against such
at the service to redirect data to a specific repository. attacks.
5.2.2. Application Logic Control 5.2.2. Application Logic Control
Overview Overview
Requirements for application control have been addressed in the I2RS This section examines how application logic must be design to ensure
plane isolation as well as in the trusted Communication Channel application isolation.
sections. This section examines how application logic must be design
to ensure application isolation.
Requirements: Requirements:
SEC-ENV-REQ 35: application logic should remain opaque to external SEC-ENV-REQ 35: Application logic should remain opaque to external
listeners. application logic may be partly hidden by listeners. Application logic may be partly hidden by
encrypting the communication between the I2RS client encrypting the communication between the I2RS client
and the I2RS agent. Additional ways to obfuscate the and the I2RS agent. Additional ways to obfuscate the
communications may involve sending random messages of communications may involve sending random messages of
various sizes. Such strategies have to be balanced various sizes. Such strategies have to be balanced
with network load. Note that I2RS client broker are with network load. Note that I2RS client broker are
more likely to hide the application logic compared to more likely to hide the application logic compared to
I2RS client associated to a single application. I2RS client associated to a single application.
Explanation: Explanation:
skipping to change at page 26, line 29 skipping to change at page 30, line 43
[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-17 (work in progress), September 2016. requirements-17 (work in progress), September 2016.
9.2. Informative References 9.2. Informative References
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-22 (work in Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in
progress), November 2016. progress), November 2016.
[I-D.ietf-netconf-rfc6536bis]
Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", draft-ietf-
netconf-rfc6536bis-00 (work in progress), January 2017.
[I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", draft-ietf-netmod-revised-datastores-00 (work
in progress), December 2016.
Authors' Addresses Authors' Addresses
Daniel Migault 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
 End of changes. 71 change blocks. 
275 lines changed or deleted 449 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/