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/