draft-ietf-i2rs-security-environment-reqs-03.txt   draft-ietf-i2rs-security-environment-reqs-04.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: September 8, 2017 S. Hares Expires: September 13, 2017 S. Hares
Huawei Huawei
March 7, 2017 March 12, 2017
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-03 draft-ietf-i2rs-security-environment-reqs-04
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 security environment requirements the protocol used for I2RS. The security environment requirements
are the good security practices to be used during implementation and are the good security practices to be used during implementation and
deployment of the code related to the new interface to routing system deployment of the code related to the new interface to routing system
(I2RS) so that I2RS implementations can be securely deployed and (I2RS) so that I2RS implementations can be securely deployed and
operated. operated.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 8, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7 3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7
3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10
3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11
4. I2RS Access Control for Routing System Resources . . . . . . 14 4. I2RS Access Control for Routing System Resources . . . . . . 14
4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14
4.1.1. access control Enforcement Scope . . . . . . . . . . 17 4.1.1. Access control Enforcement Scope . . . . . . . . . . 17
4.1.2. Notification Requirements . . . . . . . . . . . . . . 17 4.1.2. Notification Requirements . . . . . . . . . . . . . . 17
4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Sharing access control Information . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 20 Agents . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.6. Managing Access Control Policy . . . . . . . . . . . 22 4.1.6. Managing Access Control Policy . . . . . . . . . . . 22
4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23
4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23
4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24
4.2.3. Application and Access Control Policies . . . . . . . 25 4.2.3. Application and Access Control Policies . . . . . . . 25
5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26
5.1. Robustness Toward Programmability . . . . . . . . . . . . 26 5.1. Robustness Toward Programmability . . . . . . . . . . . . 26
5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27
5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. Application Logic Control . . . . . . . . . . . . . . 29 5.2.2. Application Logic Control . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
skipping to change at page 3, line 26 skipping to change at page 3, line 26
considerations described in the I2RS Architecture [RFC7921] required considerations described in the I2RS Architecture [RFC7921] required
to provide a stable and secure environment in which the dynamic to provide a stable and secure environment in which the dynamic
programmatic interface to the routing system (I2RS) should operates. 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 for 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 securely isolated o Section 3 describes how the I2RS plane can be securely isolated
from the management plane, control plane and forwarding plane. from the management plane, control plane, and forwarding plane.
The subsequent sections of the document focuses on the security The subsequent sections of the document focus on the security within
within the I2RS plane. the I2RS plane.
o Section 4 analyzes how the I2RS access control policies can be o Section 4 analyses how the I2RS access control policies can be
deployed throughout the I2RS plane in order to limit access to the deployed throughout the I2RS plane in order to limit access to the
routing system resources to authorized components with the routing system resources to authorized components with the
authorized privileges. This analysis examines how providing a authorized privileges. This analysis examines how providing a
robust communication system between the components aids the access robust communication system between the components aids the access
control. control.
o 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. Applications another and without affecting the I2RS components. Applications
may be independent, with different scopes, owned by different may be independent, with different scopes, owned by different
tenants. In addition, the applications may modify the routing tenants. In addition, the applications may modify the routing
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 secured. 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: The policies controlling access of - I2RS access control policies: The policies controlling access of
the routing resources by applications. These policies are the routing resources by applications. These policies are
divided into policies applied by the I2RS client regarding divided into policies applied by the I2RS client regarding
applications and policies applied by the I2RS agent regarding applications and policies applied by the I2RS agent regarding
I2RS clients. I2RS clients.
- I2RS client access control policies: The access control policies - I2RS client access control policies: The access control policies
skipping to change at page 4, line 44 skipping to change at page 4, line 44
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, and control planes) is fundamental to the security of the
of the I2RS environment. Clearly differentiating the I2RS components I2RS environment. Clearly differentiating the I2RS components from
from the rest of the network device does the following: 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, 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 placing software planes is similar to the best common practice of placing software
into software containers within modules with clear interfaces to into software containers within modules with clear interfaces to
exterior modules. In a similar way, although the I2RS plane cannot exterior modules. In a similar way, although the I2RS plane cannot
be completely isolated from other planes, it can be carefully be completely isolated from other planes, it can be carefully
designed so the interactions between the I2RS plane and other planes designed so the interactions between the I2RS plane and other planes
can be identified and controlled. The following is a brief can be identified and controlled. The following is a brief
description of how the I2RS plane positions itself in regard to the description of how the I2RS plane positions itself in regard to the
other planes. 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 to the routing system resources to network oriented
applications. Routing protocols often run in a control plane and applications. Routing protocols often run in a control plane and
provide entries for the forwarding plane as shown in figure 1. The provide entries for the forwarding plane as shown in figure 1. The
I2RS plane which contains the I2RS applications, the I2RS client, the I2RS plane contains the I2RS applications, the I2RS client, the north
north bound interface between the I2RS client and I2RS applications, bound interface between the I2RS client and I2RS applications, the
the I2RS protocol, the I2RS agent, and south bound API (SB API) to I2RS protocol, the I2RS agent, and the south bound API (SB API) to
the routing system. The communication interfaces in the I2RS plane the routing system. The communication interfaces in the I2RS plane
are shown on the the left hand side of the figure 1. are shown on the the left hand side of figure 1.
The management plane contains the mangement application the The management plane contains the mangement application, the
management client, the north bound API between the management client management client, the north bound API between the management client
and management application, the mangement server, the management and management application, the mangement server, the management
protocol (E.g. RESTCONF) between mangement client and management protocol (E.g. RESTCONF) between mangement client and management
server, and the south bound API between the management server and the server, and the south bound API between the management server and the
control plane. The communication interfaces associated with the control plane. The communication interfaces associated with the
management plane are shown on the right hand side of figure 2. management plane are shown on the right hand side of figure 2.
The I2RS plane and the management plane both interact with control The I2RS plane and the management plane both interact with the
plane on which the routing systems operate. [RFC7921] describes control plane on which the routing systems operate. [RFC7921]
several of these interaction points such as the local configuration, describes several of these interaction points such as the local
the static system state, routing, and signaling. A routing resource configuration, the static system state, routing, and signaling. A
may be accessed by I2RS plane, the mangement plane, or routing routing resource may be accessed by I2RS plane, the mangement plane,
protocol(s) which creates the potential for overlapping access. The or routing protocol(s) which creates the potential for overlapping
southbound APIs can limit the scope of the management plane's and the access. The southbound APIs can limit the scope of the management
I2RS plane's interaction with the routing resources. plane's and the I2RS plane's interaction with the routing resources.
Security focus: Security focus:
Implementers need to carefully examine the southbound APIs from the Implementers need to carefully examine the southbound APIs from the
I2RS Plane and the management plane to determine if these APIs I2RS Plane and the management plane to determine if these APIs
overlap or conflict during use. If these APIs overlap or conflict, overlap or conflict during use. If these APIs overlap or conflict,
these interactions can provide errors which are not traceable or these interactions can provide errors which are not traceable or
provide a risk for security intrusions between the two planes. provide a risk for security intrusions between the two planes.
APIs that interact with the APIs that interact with the
skipping to change at page 6, line 40 skipping to change at page 6, line 40
interactions between the I2RS plane and the management plane. It is interactions between the I2RS plane and the management plane. It is
important that conflicting interactions do not provide a deadlock important that conflicting interactions do not provide a deadlock
situation or allow a vulnerability due to data store leaking. situation or allow a vulnerability due to data store leaking.
3.1.1. Deadlocks 3.1.1. Deadlocks
How can a deadlock occur? How can a deadlock occur?
The I2RS applications and the management applications may both The I2RS applications and the management applications may both
interact with the Routing System. For example, I2RS applications may interact with the Routing System. For example, I2RS applications may
set ephemeral state for an BGP routing process allowing a peer to set ephemeral state for a BGP routing process allowing a peer to
temporarily increase the maximum number of prefix it will accept. At temporarily increase the maximum number of prefixes it will accept.
the same time, a management plane process may change a BGP Peer's At the same time, a management plane process may change a BGP Peer's
configuration for the maximum number of prefixes to decrease the configuration for the maximum number of prefixes to decrease the
maximum number of prefixes. [RFC7921] suggests that implementations maximum number of prefixes. [RFC7921] suggests that implementations
SHOULD provide operator configurable knobs that will determine which SHOULD provide operator configurable knobs that will determine which
functions (I2RS or configuration management) has precedence in the functions (I2RS or configuration management) has precedence in the
routing system, and that events should signal an I2RS agent if the routing system, and that events should signal an I2RS agent if the
I2RS ephemeral state is overwritten. This is an example of policy I2RS ephemeral state is overwritten. This is an example of policy
that prevents a deadlock situation for both the I2RS application and that prevents a deadlock situation for both the I2RS application and
the mangement application. the management application.
It is important that implementations include both policy knobs for It is important that implementations include both policy knobs for
resolving the deadlocks between the the I2RS plane and the management resolving the deadlocks between the the I2RS plane and the management
plane, and event signaling which reports deadlocks occuring within a plane, and event signaling which reports deadlocks occurring within a
system supporting I2RS. system supporting I2RS.
3.1.2. Data Store leaking 3.1.2. Data Store leaking
A vulnerability can occur if there is leakage between the I2RS A vulnerability can occur if there is leakage between the I2RS
ephemeral control plane data store and the management plane's ephemeral control plane data store and the management plane's
configuration datastore. [I-D.ietf-netmod-revised-datastores] configuration datastore. [I-D.ietf-netmod-revised-datastores]
describes a datastore architecture with control plane datastores describes a datastore architecture with control plane datastores
(such as the I2RS protocol's ephemeral datastore) being logically (such as the I2RS protocol's ephemeral datastore) being logically
different than the the configuration data store. The mixture of the different than the the configuration data store. The mixture of the
skipping to change at page 7, line 31 skipping to change at page 7, line 31
configuration and the management plane configuration, and then configuration and the management plane configuration, and then
installs the state in the routing system. Implementation policy installs the state in the routing system. Implementation policy
determines which configuration state should be installed. determines which configuration state should be installed.
The applied datastore provides information on what is installed in The applied datastore provides information on what is installed in
each part of a system - including the routing system. The each part of a system - including the routing system. The
operational state data store provides both the applied data store operational state data store provides both the applied data store
information and additional operational state from the control plane information and additional operational state from the control plane
protocols and control plane datastore. protocols and control plane datastore.
Since it is the routing system code which mixing the configuration Since it is the routing system code which is combining the
from the I2RS control plane datastore and the management datastore to configuration from the I2RS control plane datastore and the
create applied datastore for the routing system, this code must take management datastore to create applied datastore for the routing
care to prevent: system, this code must take care to prevent:
o the I2RS system "infecting" the management system configuration o the I2RS system "infecting" the management system configuration
datastore with information from the I2RS control plane data store, datastore with information from the I2RS control plane data store,
o the management system "infecting" the I2RS system data with data o the management system "infecting" the I2RS system data with data
not specifically imported by I2RS data models, 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 improper information from one system to another via propagating improper information from one system to another via
I2RS. I2RS.
In this circumstance, we define "infecting" as inteferring with and In this circumstance, we define "infecting" as interfering with and
leading into a incoherent state. Planned interactions such as leading into a incoherent state. Planned interactions such as
interactions denoted in in two cooperating Yang data modules is not interactions denoted in in two cooperating Yang data modules is not
incoherent state. an incoherent state.
For example, BGP configuration and BGP I2RS ephemeral state For example, BGP configuration and BGP I2RS ephemeral state
configuration could have a defined interaction. The I2RS plane may configuration could have a defined interaction. The I2RS plane may
legitimately update a routing resource configured by the management legitimately update a routing resource configured by the management
plane, or the reverse (the management plane updates a resource the plane, or the reverse (the management plane updates a resource the
I2RS plane has configured) if the interactions are defined by Yang I2RS plane has configured) if the interactions are defined by Yang
modules or local policy. Infecting, is when the implementation is modules or local policy. Infecting is when the implementation is
updated by two processes resulting in an incoherent state. Indirect updated by two processes resulting in an incoherent state. Indirect
"infecting", we define as as changes made by the I2RS plane that "infecting" we define as as changes made by the I2RS plane that cause
cause changes in routing protocols which add state unexpected by the changes in routing protocols which add state unexpected by the
management plane or the reverse (the mangement plane adding changes management plane or the reverse (the mangement plane adding changes
in routing protocols the I2RS plane does not expect). in routing protocols the I2RS plane does not expect).
Prevention for Data Store Leakage 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: validation rules on:
o the data being sent/received by the I2RS agent (including o the data being sent/received by the I2RS agent (including
notification of changes that the I2RS agent sends the I2RS notification of changes that the I2RS agent sends the I2RS
skipping to change at page 8, line 32 skipping to change at page 8, line 32
o any data transferred between management datastores (configuration o any data transferred between management datastores (configuration
or operational state) and I2RS ephemeral control plane data or operational state) and I2RS ephemeral control plane data
stores; stores;
o data transferred between I2RS Agent and Routing system, o data transferred between I2RS Agent and Routing system,
o data transferred between a management server and the I2RS routing o data transferred between a management server and the I2RS routing
system, system,
o data transfered between I2RS agent and system (e.g. interfaces o data transferred between I2RS agent and system (e.g. interfaces
ephemeral configuration), ephemeral configuration),
o data transferred between management server and the system (e.g. o data transferred between management server and the system (e.g.
interface configuration). interface configuration).
The next few paragraphs will provide some ideas on how this might be The next few paragraphs will provide some ideas on how this might be
implemented. These suggest implementation policy should resolve what implemented. These suggest implementation policy should resolve what
is not resolved in the YANG Data module definitions. is not resolved in the YANG Data module definitions.
The Network Access Control Module (NACM) has been define to control The Network Access Control Module (NACM) has been define to control
access to the configuration datastore via the management protocol access to the configuration datastore via the management protocol
across a network. A similar network access control module could be across a network. A similar network access control module could be
defined for the I2RS-NACM (per [I-D.ietf-netconf-rfc6536bis]. defined for the I2RS-NACM (per [I-D.ietf-netconf-rfc6536bis].
Figure 2 shows how the I2RS-NACM could be created to support parallel Figure 2 shows how the I2RS-NACM could be created to support parallel
features with the management protocol (E.g. NETCONF) NACM. features with the management protocol (E.g. NETCONF) NACM.
I2RS implementations may also need to define an access modules which I2RS implementations may also need to define access modules which
control access to the routing system (Routing Access Control Module control access to the routing system (Routing Access Control Module
(RACM)) by policy. The I2RS-RACM would control how the I2RS agent (RACM)) by policy. The I2RS-RACM would control how the I2RS agent
access the routing system through the SB API interface. In parallel, accesses the routing system through the SB API interface. In
the management system would have a RACM to control the SB API parallel, the management system would have a RACM to control the SB
interface (see figure 2). I2RS agent and the management server may API interface (see figure 2). I2RS agent and the management server
want to read/write system information interfaces or other system may want to read/write system information interfaces or other system
functions. In order to prevent leakage between the I2RS system and functions. In order to prevent leakage between the I2RS system and
the management system, there needs to be system access control module the management system, there needs to be a system access control
(SACM) that protects the jointly held data. module (SACM) that protects the jointly held data.
I2RS- || (I2RS Mgt protocol || I2RS- || (I2RS Mgt protocol ||
NACM || Protocol) (E.g. NETCONF)|| NACM NACM || Protocol) (E.g. NETCONF)|| NACM
------- ---------- ------- ----------
I2RS ||I2RS Agent Mgt server|| I2RS ||I2RS Agent Mgt server||
SACM || I2RS Control-DS config DS || SACM SACM || I2RS Control-DS config DS || SACM
-----|| (RACM) (RACM) ||=======|| -----|| (RACM) (RACM) ||=======||
| ||SB API SB API || || | ||SB API SB API || ||
| +-----------------------------------+ || | +-----------------------------------+ ||
| | Routing System with protocols | || | | Routing System with protocols | ||
skipping to change at page 10, line 19 skipping to change at page 10, line 19
|| (NAC policy) (NAC policy)|| || (NAC policy) (NAC policy)||
|| || || ||
I2RS protocol mgt protocol I2RS protocol mgt protocol
(NETCONF/RESTCONF) (NETCONF/RESTCONF)
figure 3 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 constrain 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 management client to configure the example an application may use a management client to configure the
network and monitored events via an I2RS agent as figure 4 shows. network and monitored events via an I2RS agent as figure 4 shows.
+--------------------------------------+ +--------------------------------------+
| Application | | Application |
+--------------------------------------+ +--------------------------------------+
|| NB API NB API || || NB API NB API ||
|| I2RS client mgt client || || I2RS client mgt client ||
|| || || ||
I2RS protocol mgt protocol I2RS protocol mgt protocol
(NETCONF/RESTCONF) (NETCONF/RESTCONF)
skipping to change at page 10, line 51 skipping to change at page 10, line 51
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).
Prevention measures: Prevention measures:
Systems should consider the following prevention errors: Systems should consider the following prevention errors:
application validation - There is little the I2RS plane can do to application validation - There is little the I2RS plane can do to
validate applications with which it interacts. The I2RS client validate applications with which it interacts. The I2RS client
passes the I2RS agent an opaque identifier for the application so passes the I2RS agent an unique identifier for the application so
that an application's actions can be traced back to the that an application's actions can be traced back to the
application. application.
Validation against common misconfigurations or errors - One way of Validation against common misconfigurations or errors - One way of
securing the interfaces between application, the I2RS plane, and securing the interfaces between application, the I2RS plane, and
the forwarding plane is to limit the information accepted and to the forwarding plane is to limit the information accepted and to
limit the rate information is accepted between these three limit the rate information is accepted between these three
software planes. Another method is to performing rudimentary software planes. Another method is to perform rudimentary checks
checks on the results of any updates to the forwarding plane. on the results of any updates to the forwarding plane.
3.3. I2RS Plane and Control 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. 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 handles the control plane signalling 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 situations, 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 allows the network is not a part of normal processing, such action allows the 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. For example, information configured by the I2RS the control plane. For example, information configured by the I2RS
agent into routing process or RIBs could cause forwarding problems or agent into routing process or RIBs could cause forwarding problems or
routing loops. As a second example, state which is inserted or routing loops. As a second example, state which is inserted or
deleted from routing processes (control traffic, counters, etc.) deleted from routing processes (control traffic, counters, etc.)
could cause the routing protocols to fail to converge or loop). could cause the routing protocols to fail to converge or loop).
Prevention measures: Prevention measures:
The I2RS implementation can provide internal checks that after a The I2RS implementation can provide internal checks after a routing
routing system protocol changes that it is still operating correctly. system protocol change that it is still operating correctly. These
These checks would be specific to the routing protocol the I2RS Agent checks would be specific to the routing protocol the I2RS Agent would
would change. For example, if a BGP maximum prefix limit for a BGP change. For example, if a BGP maximum prefix limit for a BGP peer is
peer is lowered then the BGP peer should not allow the number lowered then the BGP peer should not allow the number prefixes
prefixes received from that peer to exceed this number. 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 levels 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 specific permissions for SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for
interaction with each routing element and access to interaction with each routing element and access to
the routing element should governed by policy the routing element should governed by policy
specific to the I2RS agent's interfaces (network, specific to the I2RS agent's interfaces (network,
routing system, system, or cross-datastore). routing system, system, or cross-datastore).
skipping to change at page 12, line 48 skipping to change at page 12, line 48
routing process. For example, in a typical UNIX system, the user is routing process. For example, in a typical UNIX system, the user is
designated with a user id (uid) and belongs to groups designated by 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 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 identifier for the routing processes peforming routing tasks in the
control plane, then the I2RS Agent process would communicate with control plane, then the I2RS Agent process would communicate with
these routing processes. It is important that the I2RS agent has its these routing processes. It is important that the I2RS agent has its
own unique identifier and the routing processes have their own own unique identifier and the routing processes have their own
identifier so that access control can uniquely filter data between identifier so that access control can uniquely filter data between
I2RS Agent and routing processes. I2RS Agent and routing processes.
The specific policy the the I2RS agent uses to filter data from the The specific policy that the I2RS agent uses to filter data from the
network or from different processes on a system (routing, system or network or from different processes on a system (routing, system or
cross-datastore) should be specific to the I2RS agent. For example, cross-datastore) should be specific to the I2RS agent. For example,
the network access filter policy that the I2RS agent uses should be the network access filter policy that the I2RS agent uses should be
uniquely identifiable from the configuration datastore updated by a uniquely identifiable from the configuration datastore updated by a
management protocol. management protocol.
SEC-ENV-REQ 4: I2RS plane should be informed when a routing system SEC-ENV-REQ 4: The I2RS plane should be informed when a routing
resource is modified by a user outside the I2RS plane system resource is modified by a user outside the
access. Notifications from the control plane SHOULD I2RS plane access. Notifications from the control
not to flood the I2RS plane, and rate limiting (or plane SHOULD not be allowed to flood the I2RS plane,
summarization) is expected to be applied. These and rate limiting (or summarization) is expected to
routing system notification MAY translated to the be applied. These routing system notifications MAY
appropriate I2RS agent notifications, and passed to translated to the appropriate I2RS agent
various I2RS clients via notification relays. notifications, and passed to various I2RS clients via
notification relays.
Explanation: Explanation:
This requirements is also described in section 7.6 of [RFC7921] for 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 the I2RS client, and this section extends it to the entire I2RS plane
(I2RS agent, client, and application). (I2RS agent, client, and application).
A routing system resource may be accessed by the management plane or A routing system resource may be accessed by management plane or
control plane protocols so a change to a routing system resource may control plane protocols so a change to a routing system resource may
remain unnoticed unless and until the routing system resource remain unnoticed unless and until the routing system resource
notifies the I2RS plane by notifying the I2RS agent. Such notifies the I2RS plane by notifying the I2RS agent. Such
notification is expected to trigger synchronization of the I2RS notification is expected to trigger synchronization of the I2RS
resource state between the I2RS agent and I2RS client - signalled by resource state between the I2RS agent and I2RS client - signalled by
the I2RS agent sending a notification to an I2RS client. the I2RS agent sending a notification to an I2RS client.
The updated resource should be available in the operational state if The updated resource should be available in the operational state if
there is a yang module referencing that operational state, but this there is a yang module referencing that operational state, but this
is not always the case. In the cases, where operational state is not is not always the case. In the cases where operational state is not
updated, the I2RS SB (southbound) API should include the ability to updated, the I2RS SB (southbound) API should include the ability to
send a notification. 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:
skipping to change at page 14, line 12 skipping to change at page 14, line 13
Section 6.3 of [RFC7921] describes how the I2RS agent within the I2RS Section 6.3 of [RFC7921] describes how the I2RS agent within the I2RS
plane interacts with forwarding plane's local configuration, and plane interacts with forwarding plane's local configuration, and
provides the example of an overwrite policy between the I2RS plane provides the example of an overwrite policy between the I2RS plane
and local configuration (instantiated in 2 Policy Knobs) that and local configuration (instantiated in 2 Policy Knobs) that
operators may wish to set. The prompt notification of any outside operators may wish to set. The prompt notification of any outside
overwrite is key to the architecture and proper interworking of the overwrite is key to the architecture and proper interworking of the
I2RS Plane. I2RS Plane.
4. I2RS Access Control for Routing System Resources 4. I2RS Access Control for Routing System Resources
This section provides recommendations on how I2RS access control This section provides recommendations on how the I2RS plane's access
policies associated to the routing system resources. These policies control should be designed to protect the routing system resources.
only apply within the I2RS plane. More especially, the policies are These security policies for access control only apply within the I2RS
associated to the applications, I2RS clients and I2RS agents, with plane. More especially, the policies are associated to the
their associated identity and roles. applications, I2RS clients and I2RS agents, with their associated
identity and roles.
The I2RS deployment of I2RS applications, I2RS clients, and I2RS The I2RS deployment of I2RS applications, I2RS clients, and I2RS
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, 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 4.1), access control policies of access control architecture (section 4.1), access control policies of
the I2RS agent (section 4.2), the I2RS client (section 4.3), and the the I2RS agent (section 4.2), the I2RS client (section 4.3), and the
application (section 4.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 the routing system resource via numerous
intermediaries nodes. The application communicates with an I2RS intermediate 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 with 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 4 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 4 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 4 as a broker (agent/client device shown in case d in figure 4 below).
below). The I2RS client broker approach provides scalability to the The I2RS client broker approach provides scalability to the I2RS
I2RS architecture as it avoids that each application be registered to architecture as it avoids each application being registered to the
the I2RS agent. Similarly, the I2RS access control should be able to I2RS agent. Similarly, the I2RS access control should be able to
scale numerous applications. scale to 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
client and I2RS client to the I2RS agent). The I2RS agent must trust client and I2RS client to the I2RS agent). The I2RS agent must trust
the I2RS client's actions without having an ability to verify the the I2RS client's actions without having an ability to verify the
I2RS client's actions. I2RS client's actions.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
|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 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
architecture [RFC7921], which exclusively focuses on architecture [RFC7921], which exclusively focuses on
skipping to change at page 17, line 49 skipping to change at page 17, line 49
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 lacks the 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 privileges, 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 transaction 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 read permission",
permission", "Write failure: you do not have write permission", or "Write failure: you do not have write permission", or "Write failure:
"Write failure: resource accessed by someone else". 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 relates
the following interactions: to 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 at a o interactions between the I2RS client and the I2RS agent at a
content level (Protocol security requirements are described by content level (Protocol security requirements are described by
[I-D.ietf-i2rs-protocol-security-requirements]), and [I-D.ietf-i2rs-protocol-security-requirements]), and
o interactions between the I2RS agent and the I2RS routing system o interactions between the I2RS agent and the I2RS routing 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 other, 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. vectors of attacks.
SEC-ENV-REQ 9: I2RS client or I2RS agent SHOULD also be able to SEC-ENV-REQ 9: I2RS client or I2RS agent SHOULD also be able to
refuse a communication with an application or an I2RS refuse a communication with an application or an I2RS
client when the communication channel does not client when the communication channel does not
fulfill enough security requirements. fulfill enough security requirements.
Explanation: Explanation:
The participants in the I2RS Plane (I2RS client, I2RS agent, and I2RS The participants in the I2RS Plane (I2RS client, I2RS agent, and I2RS
application) exchange critical information, and to be effective the application) exchange critical information, and to be effective the
skipping to change at page 19, line 32 skipping to change at page 19, line 32
SEC-ENV-REQ 14: The I2RS access control should explicitly specify SEC-ENV-REQ 14: The I2RS access control should explicitly specify
accesses that are granted. More specifically, accesses that are granted. More specifically,
anything not explicitly granted should be denied anything not explicitly granted should be denied
(default rule). (default rule).
Explanation: Explanation:
In order to limit the number of access requests that result in an In order to limit the number of access requests that result in an
error, each application or I2RS client can retrieve the I2RS access error, each application or I2RS client can retrieve the I2RS access
control policies that applies to it. This subset of rules is control policies that apply to it. This subset of rules is
designated as the "Individual I2RS access control policies". As designated as the "Individual I2RS access control policies". As
these policies are subject to changes, a dynamic synchronization these policies are subject to changes, a dynamic synchronization
mechanism should be provided. However, such mechanism may be mechanism should be provided. However, such mechanisms may be
implemented with different level of completeness and dynamicity of implemented with different levels of completeness and dynamicity of
the individual I2RS access control policies. One example, may be the individual I2RS access control policies. One example may be
caching transaction requests that have been rejected. caching transaction requests that have been rejected.
I2RS access control should be appropriately be balanced between the I2RS access control should be appropriately balanced between the I2RS
I2RS client and the I2RS agent. It remains relatively easy to avoid client and the I2RS agent. It remains relatively easy to avoid the
the complete disclosure of the access control policies of the I2RS complete disclosure of the access control policies of the I2RS agent.
agent. Relative disclosure of access control policies may allow the Relative disclosure of access control policies may allow leaking
leaking confidential information in case of misconfiguration. It is confidential information in case of misconfiguration. It is
important to balance the level of trust of the I2RS client and the important to balance the level of trust of the I2RS client and the
necessity of distributing the enforcement of the access control necessity of distributing the enforcement of the access control
policies. policies.
I2RS access control should not solely rely only on the I2RS client or I2RS access control should not solely rely only on the I2RS client or
the I2RS agent as illustrated below: the I2RS agent as illustrated below:
- 1) I2RS clients are dedicated to a single application: In this - 1) I2RS clients are dedicated to a single application: In this
case, it is likely that I2RS access control is enforced only by case, it is likely that I2RS access control is enforced only by
the I2RS agent, as the I2RS client is likely to accept all the I2RS agent, as the I2RS client is likely to accept all
access request of the application. It is recommended that even access requests of the application. It is recommended that
in this case, I2RS client access control is not based on an even in this case, I2RS client access control is not based on
"Allow anything from application" policy, but instead the I2RS an "Allow anything from application" policy, but instead the
client specifies accesses that are enabled. In addition, the I2RS client specifies accesses that are enabled. In addition,
I2RS client may sync its associated I2RS access control the 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 this case the I2RS agent has a single I2RS client In this case the I2RS agent has a single I2RS client
attached, so the I2RS client could end being configured to attached, so the I2RS client could be configured to enforce
enforce access control policies instead of the I2RS Agent. access control policies instead of the I2RS Agent. In this
In this circumstance, it is possible that the I2RS agent may circumstance, it is possible that the I2RS agent may grant
grant an I2RS client with high priviledges and blindly trust an I2RS client high priviledges and blindly trust the I2RS
the I2RS client without enforcing access control policies on client without enforcing access control policies on what the
what the I2RS client can do. Such a situation must be I2RS client can do. Such a situation must be avoided as it
avoided as it could be used by malicious applications for a could be used by malicious applications for a privilege
priviledge escalation by compromising the I2RS client escalation by compromising the I2RS client, causing the I2RS
causing the I2RS client to perform some action on behalf of client to perform some action on behalf of the application
the application that it normally does not have the that it normally does not have the privileges to perform.
priviledges to perform. In order to mitigate such attack, In order to mitigate such attacks, the I2RS client that
the I2RS client that connects to multiple applications or connects to multiple applications or operates as a broker is
operates as a broker is expected to host application with an expected to host application with an equivalent level of
equivalent level of privileges. 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:
SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers
for applications that share roughly similar for applications that share roughly similar
permissions. permissions.
SEC-ENV-REQ 16: I2RS agents should be avoided granting extra SEC-ENV-REQ 16: I2RS agents should avoid granting extra privileges to
privileges to their authorized I2RS client. I2RS their authorized I2RS client. I2RS agents should be
agent should be shared by I2RS client with roughly shared by I2RS clients with roughly similar
similar permissions. More explicitly, an I2RS agent permissions. More explicitly, an I2RS agent shared
shared between I2RS clients that are only provided between I2RS clients that are only provided read
read access to the routing system resources does not access to the routing system resources do not need to
need to perform any write access, so the I2RS client perform any write access, so the I2RS client should
should not be provided these accesses. not be provided these accesses.
SEC-ENV-REQ 17: I2RS client and I2RS agent should be able to trace SEC-ENV-REQ 17: I2RS clients and I2RS agents should be able to trace
[RFC7922] the various transaction they perform as [RFC7922] the various transactions they perform as
well as suspicious activities. These logs should be well as suspicious activities. These logs should be
collected regularly and analyzed by functions that collected regularly and analysed by functions that
may be out of the I2RS plane. may be out of the I2RS plane.
Explanation: Explanation:
This restriction for distributed I2RS clients to act as brokers only This restriction for distributed I2RS clients to act as brokers only
for applications with roughly the same priviledges avoids the I2RS for applications with roughly the same privileges avoids the I2RS
client extra priviledges compared to hosted applications, and client having extra privileges compared to hosted applications, and
discourages applications from perform privilege escalation within an discourages applications from performing privilege escalation within
I2RS client. For example, suppose an I2RS client requires write an I2RS client. For example, suppose an I2RS client requires write
access to the resources. It is not recommended to grant the I2RS access to the resources. It is not recommended to grant the I2RS
agent the write access in order to satisfy a unique I2RS client. agent the write access in order to satisfy a unique I2RS client.
Instead, the I2RS client that requires write access should be Instead, the I2RS client that requires write access should be
connected to a I2RS agent that is already shared by I2RS client that connected to an I2RS agent that is already shared by an I2RS client
requires a write access. that requires write access.
Access control policies enforcement should be monitored in order to Access control policies enforcement should be monitored in order to
detect violation of the policies or detect an attack. Access control detect violation of the policies or detect an attack. Access control
policies enforcement may not be performed by the I2RS client or the 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 I2RS agent as violation may require a more global view of the I2RS
access control policies. As a result, consistency check and 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.
The I2RS agent can trace transactions that an I2RS client requests it The I2RS agent can trace transactions that an I2RS client requests it
to perform, and to link this to the application via the secondary to perform, and to link this to the application via the secondary
opaque identifier to the application. This information is placed in opaque identifier to the application. This information is placed in
a tracing log which is retrieved by management processes. If a a tracing log which is retrieved by management processes. If a
particular application is granted a level of priviledges it should particular application is granted a level of privileges it should not
not have, then this tracing mechanism may detect this security have, then this tracing mechanism may detect this security intrusion
intrusion after the instrusion has occurred. after the intrusion has occurred.
4.1.6. Managing Access Control Policy 4.1.6. Managing Access Control Policy
Access control policies should be implemented so that the policies Access control policies should be implemented so that the policies
remain manageable in short and longer term deployments of the I2RS remain manageable in short and longer term deployments of the I2RS
protocol and the I2RS plane. protocol and the I2RS plane.
Requirements: Requirements:
SEC-ENV-REQ 18: access control should be managed in an automated way, SEC-ENV-REQ 18: access control should be managed in an automated way,
skipping to change at page 22, line 26 skipping to change at page 22, line 26
(I2RS client, I2RS agent, and application). (I2RS client, I2RS agent, and application).
Explanation: Explanation:
Granting or configuring an application with new policy should not Granting or configuring an application with new policy should not
require manual configuration of I2RS clients, I2RS agents, or other require manual configuration of I2RS clients, I2RS agents, or other
applications. applications.
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. clients 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
each application. Such an approach is likely not to scale when the with each application. Such an approach is not likely to scale when
number of applications increases into the hundreds. the 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 number of I2RS clients is expected to be lower than the
number of application, as I2RS agent provide access to the routing number of applications, as I2RS agents 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.
SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely
identified in the network to enable centralized identified in the network to enable centralized
management of the I2RS access control policies. management of the I2RS access control policies.
Explanation: Explanation:
Centralized management of the access control policies of an I2RS Centralized management of the access control policies of an I2RS
plane with network that hosts several I2RS applications, clients and plane with network that hosts several I2RS applications, clients and
agents requires that each devices can be identified. agents requires that each devices can be identified.
4.2. I2RS Agent Access Control Policies 4.2. I2RS Agent Access Control Policies
Overview: Overview:
The I2RS agent access control restricts the routing system resource The I2RS agent access control restricts 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. the application that initiates the request.
First, when an I2RS client acts as a broker, the I2RS agent may not First, when an I2RS client acts as a broker, the I2RS agent may not
be able to authenticate the application. In that sense, the I2RS be able to authenticate the application. In that sense, the I2RS
agent relies on the capability of the I2RS client to authenticate the agent relies on the capability of the I2RS client to authenticate the
applications and apply the appropriated I2RS client access control. applications and apply the appropriated I2RS client access control.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[RFC7921]. [RFC7921].
SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on
the application if the application identity has been the application if the application identity has been
authenticated by the I2RS client and passed via the authenticated by the I2RS client and passed via the
secondary identity to the I2RS agent. secondary identity to the I2RS agent.
SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g. SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g.
system user) performed the latest update of the system user) performed the latest update of the
routing resource. This is true for an identity routing resource. This is true for an identity
inside and outside the I2RS plane so the I2RS agent inside and outside the I2RS plane, so the I2RS agent
can appropriately perform an update according to the can appropriately perform an update according to the
priorities associated to the requesting identity and priorities associated to the requesting identity and
the identity that last updated the resource. the identity that last updated the resource.
SEC-ENV-REQ 25: the I2RS agent should have a "I2RS agent overwrite SEC-ENV-REQ 25: the I2RS agent should have an "I2RS agent overwrite
Policy" that indicates how identities can be Policy" that indicates how identities can be
prioritized. This requirements is also described in prioritized. This requirement is also described in
section 7.6 of [RFC7921]. Similar requirements exist section 7.6 of [RFC7921]. Similar requirements exist
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
skipping to change at page 25, line 20 skipping to change at page 25, line 20
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 immediately and application should not be forwarded immediately and
transparently by the I2RS client based on the I2RS agent transparently by the I2RS client based on the I2RS agent
access control policies. The I2RS client should first check access control policies. The I2RS client should first check
whether the application has sufficient privileges, and if so whether the application has sufficient privileges, and if so
send an access request to the I2RS agent. send an access request to the I2RS agent.
Explanation: Explanation:
If no authentication mechanisms have being provided between the I2RS If no authentication mechanisms have being provided between the I2RS
client and the application, then I2RS client must be dedicated to a client and the application, then the I2RS client must be dedicated to
single application. By doing so, application authentication relies a single application. By doing so, application authentication relies
on the I2RS authentication mechanisms between the I2RS client and the on the I2RS authentication mechanisms between the I2RS client and the
I2RS agent. I2RS agent.
If an I2RS client has multiple identities that are associated with If an I2RS client has multiple identities that are associated with
different privileges for accessing an I2RS agent(s), the I2RS client different privileges for accessing an I2RS agent(s), the I2RS client
access control policies should specify the I2RS client identity with access control policies should specify the I2RS client identity with
the access control policy. the access control policy.
4.2.3. Application and Access Control Policies 4.2.3. Application and Access Control Policies
skipping to change at page 26, line 6 skipping to change at page 26, line 6
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.
SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted
number of I2RS client number of I2RS clients.
Explanation: Explanation:
The I2RS client provides access to resource on its behalf and this 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. This does not prevent applications with an similar level of trust. This does not prevent
an I2RS client to host a large number of applications with the same an I2RS client to host a large number of applications with the same
levels of trust. levels of trust.
SEC-ENV-REQ 30: An application SHOULD be provided means and methods SEC-ENV-REQ 30: An application SHOULD be provided means and methods
skipping to change at page 27, line 18 skipping to change at page 27, line 18
configuration changes which can help mitigate the 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, one
one application may monitor a state and change to positive, and a application may monitor a state and change to positive, and a
second application performs the reverse operation (turns it second application performs the reverse operation (turns it
negative). This fluctuation can cause a routing system to become negative). This fluctuation can cause a routing system to become
unstable. unstable.
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 from happening. However, to guarantee the network
stability constant monitoring and error detection are recommended to stability constant monitoring and error detection are recommended.
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 any I2RS clients or applications causing detect any I2RS clients or applications causing
problems that may lead the routing system in an problems that may leave the routing system in an
unstable state. unstable state.
Explanation: Explanation:
Monitoring consists at least in logging events and receiving streams In the least, monitoring consists of logging events and receiving
of data. I2RS Plane implementations should monitor the I2RS streams of data. I2RS Plane implementations should monitor the I2RS
applications and I2RS clients for potential problems. The cause for applications and I2RS clients for potential problems. The cause for
the I2RS clients or applications providing problematic requests can the I2RS clients or applications providing problematic requests can
be failures in the implementation code or malicious intent. ] be failures in the implementation code or malicious intent. ]
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 28, line 15 skipping to change at page 28, line 12
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:
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 control the resources allocated to each I2RS
clients. I2RS client that acts as broker may not be client. I2RS clients that act as broker may not be
protected as efficiently against these attacks unless protected 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 SHOULD make a response redirection unless SEC-ENV-REQ 33: I2RS agent SHOULD not make a response redirection
the redirection is previously validated and agreed by unless the redirection is previously validated and
the destination. agreed by the destination.
SEC-ENV-REQ 34: I2RS Appications should avoid the use of underlying SEC-ENV-REQ 34: I2RS Applications should avoid the use of underlying
protocols that are not robust to reflection attacks. protocols that are not robust enough to protect
against reflection attacks.
Explanation: Explanation:
The I2RS interface is used by application to interact with the The I2RS interface is used by applications to interact with the
routing states. If the I2RS client is shared between multiple routing states. If the I2RS client is shared between multiple
applications, one application can use the I2RS client to perform DoS applications, one application can use the I2RS client to perform DoS
or DDoS attacks on the I2RS agent(s) and through the I2RS agents or DDoS attacks on the I2RS agent(s) and through the I2RS agents
attacks on the network. DoS attack targeting the I2RS agent would attack the network. DoS attack targeting the I2RS agent would
consist in providing requests that keep the I2RS agent busy for a consist in providing requests that keep the I2RS agent busy for a
long time. These attacks on the I2RS agent may involve an long time. These attacks on the I2RS agent may involve an
application (requesting through an I2RS Client) heavy computation by application (requesting through an I2RS Client) heavy computation by
the I2RS agent in order 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 streams 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 to reflect traffic. In such an attack could be reflection attacks to reflect traffic. Such an attack could be
performed by first detecting an application is related to monitoring performed by first detecting an application is related to monitoring
the RIB or changing the RIB. Reflection-based DoS may be also attack the RIB or changing the RIB. Reflection-based DoS may also attack at
at various levels in the stack utilizing UDP at the service to various levels in the stack utilizing UDP at the service to redirect
redirect data to a specific repository data to a specific repository
I2RS implementation should consider how to protect I2RS against such I2RS implementation should consider how to protect I2RS against such
attacks. attacks.
5.2.2. Application Logic Control 5.2.2. Application Logic Control
Overview Overview
This section examines how application logic must be design to ensure This section examines how application logic must be designed to
application isolation. 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:
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 behaviour on the forwarding
plane or any external behaviors. In this case, correlating plane or any external behaviours. In this case, correlating
observation to the I2RS traffic may enable to derive the application observation with the I2RS traffic may enable the derivation the
logic. Once the application logic has been derived, a malicious application logic. Once the application logic has been derived, a
application may generate traffic or any event in the network in order malicious application may generate traffic or any event in the
to activate the alternate application. network in order to activate the alternate application.
6. Security Considerations 6. Security Considerations
The whole document is about security requirements for the I2RS This whole document is about security requirements for the I2RS
environment. To protect personal privacy, any identifier (I2RS environment. To protect personal privacy, any identifier (I2RS
application identifier, I2RS client identifier, or I2RS agent application identifier, I2RS client identifier, or I2RS agent
identifier) should not contain personal identifiable information. identifier) should not contain personal identifiable information.
7. IANA Considerations 7. IANA Considerations
No IANA considerations for this requirements. No IANA considerations for this requirements.
8. Acknowledgments 8. Acknowledgments
A number of people provided a significant amount of helping comments A number of people provided a significant amount of helpful 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, and Linda Dunbar. Alia Atlas, and Linda Dunbar.
9. References 9. References
9.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,
 End of changes. 92 change blocks. 
197 lines changed or deleted 200 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/