draft-ietf-i2rs-security-environment-reqs-04.txt   draft-ietf-i2rs-security-environment-reqs-05.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 13, 2017 S. Hares Expires: September 29, 2017 S. Hares
Huawei Huawei
March 12, 2017 March 28, 2017
I2RS Environment Security Requirements I2RS Environment Security Requirements
draft-ietf-i2rs-security-environment-reqs-04 draft-ietf-i2rs-security-environment-reqs-05
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 13, 2017. This Internet-Draft will expire on September 29, 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 22 skipping to change at page 2, line 22
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.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7
3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8
3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 9
3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11 4. I2RS Access Control for Routing System Resources . . . . . . 11
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11
4. I2RS Access Control for Routing System Resources . . . . . . 14 4.1.1. Access control Enforcement Scope . . . . . . . . . . 14
4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14 4.1.2. Notification Requirements . . . . . . . . . . . . . . 14
4.1.1. Access control Enforcement Scope . . . . . . . . . . 17 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Notification Requirements . . . . . . . . . . . . . . 17 4.1.4. Sharing access control Information . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . 20 Agents . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.6. Managing Access Control Policy . . . . . . . . . . . 22 4.1.6. Managing Access Control Policy . . . . . . . . . . . 19
4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 20
4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 20
4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 21
4.2.3. Application and Access Control Policies . . . . . . . 25 4.2.3. Application and Access Control Policies . . . . . . . 22
5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 23
5.1. Robustness Toward Programmability . . . . . . . . . . . . 26 5.1. Robustness Toward Programmability . . . . . . . . . . . . 23
5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 24
5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2. Application Logic Control . . . . . . . . . . . . . . 29 5.2.2. Application Logic Control . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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] define the security [I-D.ietf-i2rs-protocol-security-requirements] define the security
for the communication between I2RS client and agent. The security for the communication between I2RS client and agent. The security
environment requirements are good security practices to be used environment requirements are good security practices to be used
during implementation and deployment of the I2RS protocol so that during implementation and deployment of the I2RS protocol so that
skipping to change at page 5, line 46 skipping to change at page 5, line 46
control plane on which the routing systems operate. [RFC7921] control plane on which the routing systems operate. [RFC7921]
describes several of these interaction points such as the local describes several of these interaction points such as the local
configuration, the static system state, routing, and signaling. A configuration, the static system state, routing, and signaling. A
routing resource may be accessed by I2RS plane, the mangement plane, routing resource may be accessed by I2RS plane, the mangement plane,
or routing protocol(s) which creates the potential for overlapping or routing protocol(s) which creates the potential for overlapping
access. The southbound APIs can limit the scope of the management access. The southbound APIs can limit the scope of the management
plane's and the 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 Data can be read by I2RS plane from configuration as copy of
I2RS Plane and the management plane to determine if these APIs configuration data, or by management plane as copies of the I2RS
overlap or conflict during use. If these APIs overlap or conflict, plane. The problem is when the I2RS plane installs the routing plane
these interactions can provide errors which are not traceable or as its new configuration or the management plane installs the I2RS
provide a risk for security intrusions between the two planes. plane information as management plane configuration. In this
circumstance, we define "infecting" as interfering with and leading
APIs that interact with the into a incoherent state. Planned interactions such as interactions
I2RS Plane and Management Plane denoted in in two cooperating Yang data modules is not an incoherent
state.
I2RS applications Mangement applications
|| NB API NB API ||
|| ||
I2RS plane management plane
|| control plane configuration||
|| datastore datastore ||
|| ||
||SB API SB API ||
---------------------------------------
| Routing System with protocols |<protocols>
| control plane |
| (applied datastore) |
+-------------------------------------+
| forwarding plane |
+-------------------------------------+
| system |
+-------------------------------------+
Figure 1 - North Bound (NB) APIs and
South Bound (SB) APIs
The north bound interface may also be a source of conflicting
interactions between the I2RS plane and the management plane. It is
important that conflicting interactions do not provide a deadlock
situation or allow a vulnerability due to data store leaking.
3.1.1. Deadlocks
How can a deadlock occur?
The I2RS applications and the management applications may both
interact with the Routing System. For example, I2RS applications may
set ephemeral state for a BGP routing process allowing a peer to
temporarily increase the maximum number of prefixes 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 management application.
It is important that implementations include both policy knobs for
resolving the deadlocks between the the I2RS plane and the management
plane, and event signaling which reports deadlocks occurring 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 is combining 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
propagating improper information from one system to another via
I2RS.
In this circumstance, we define "infecting" as interfering with and
leading into a incoherent state. Planned interactions such as
interactions denoted in in two cooperating Yang data modules is not
an incoherent state.
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: 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
client), client),
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
skipping to change at page 8, line 38 skipping to change at page 7, line 5
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 transferred 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 APIs that interact with the
implemented. These suggest implementation policy should resolve what I2RS Plane and Management Plane
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 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
accesses 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 a 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 I2RS applications Mangement applications
|| NB API MB API || || NB API NB API ||
|| (APP NAC policy) (APP NAC policy)|| || ||
|| I2RS client mgt client || I2RS plane management plane
|| (NAC policy) (NAC policy)|| || control plane configuration||
|| || || datastore datastore ||
I2RS protocol mgt protocol || ||
(NETCONF/RESTCONF) ||SB API SB API ||
---------------------------------------
| Routing System with protocols |<protocols>
| control plane |
| (applied datastore) |
+-------------------------------------+
| forwarding plane |
+-------------------------------------+
| system |
+-------------------------------------+
figure 3 Figure 1 - North Bound (NB) APIs and
South Bound (SB) APIs
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 constrain 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 a 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)
figure 4 figure 2
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 16, line 47 skipping to change at page 13, 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 figure 3
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
skipping to change at page 30, line 49 skipping to change at page 27, line 49
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-23 (work in Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in
progress), November 2016. progress), November 2016.
[I-D.ietf-netconf-rfc6536bis] [I-D.ietf-netconf-rfc6536bis]
Bierman, A. and M. Bjorklund, "Network Configuration Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", draft-ietf- Protocol (NETCONF) Access Control Model", draft-ietf-
netconf-rfc6536bis-00 (work in progress), January 2017. netconf-rfc6536bis-01 (work in progress), March 2017.
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG and R. Wilton, "Network Management Datastore
Datastores", draft-ietf-netmod-revised-datastores-00 (work Architecture", draft-ietf-netmod-revised-datastores-01
in progress), December 2016. (work in progress), March 2017.
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
 End of changes. 14 change blocks. 
210 lines changed or deleted 67 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/