draft-ietf-i2rs-security-environment-reqs-05.txt		draft-ietf-i2rs-security-environment-reqs-06.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 29, 2017 S. Hares		Expires: March 31, 2018 S. Hares
	Huawei		Huawei
	March 28, 2017		September 27, 2017
	I2RS Environment Security Requirements		I2RS Environment Security Requirements
	draft-ietf-i2rs-security-environment-reqs-05		draft-ietf-i2rs-security-environment-reqs-06
	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 35 ¶		skipping to change at page 1, line 35 ¶
	ietf-i2rs-protocol-security-requirements).		ietf-i2rs-protocol-security-requirements).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 29, 2017.		This Internet-Draft will expire on March 31, 2018.
	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		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.1. Normative References . . . . . . . . . . . . . . . . . . 27		9.1. Normative References . . . . . . . . . . . . . . . . . . 27
	9.2. Informative References . . . . . . . . . . . . . . . . . 27		9.2. Informative References . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		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		[RFC8241] define the security for the communication between I2RS
	for the communication between I2RS client and agent. The security		client and agent. The security environment requirements are good
	environment requirements are good security practices to be used		security practices to be used during implementation and deployment of
	during implementation and deployment of the I2RS protocol so that		the I2RS protocol so that I2RS protocol implementations can be
	I2RS protocol implementations can be securely deployed and operated.		securely deployed and operated. These environment security
	These environment security requirements address the security		requirements address the security considerations described in the
	considerations described in the I2RS Architecture [RFC7921] required		I2RS Architecture [RFC7921] required to provide a stable and secure
	to provide a stable and secure environment in which the dynamic		environment in which the dynamic programmatic interface to the
	programmatic interface to the routing system (I2RS) should operates.		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 for the complete I2RS architecture and not only on the		considered for the complete I2RS architecture and not only on the
	protocol interface.		protocol interface.
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	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
	system in an automatic way.		system in an automatic way.
	Motivations are described before the requirements are given.		Motivations are described before the requirements are given.
	The reader is expected to be familiar with the I2RS problem statement		The reader is expected to be familiar with the I2RS problem statement
	[RFC7920], I2RS architecture, [RFC7921], traceability requirements		[RFC7920], I2RS architecture, [RFC7921], traceability requirements
	[RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state		[RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state
	requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security		requirements [RFC8242], I2RS protocol security requirements
	requirements [I-D.ietf-i2rs-protocol-security-requirements].		[RFC8241].
	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 secured. 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.
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 26 ¶
	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 levels 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 [RFC8241], and sending the
	[I-D.ietf-i2rs-protocol-security-requirements], and		non-confidential I2RS data (designed for a non-secure
	sending the non-confidential I2RS data (designed for		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
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	identity and roles.		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, 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		[RFC8241] defines the security requirements of the I2RS protocol
	requirements of the I2RS protocol between the I2RS client and the		between the I2RS client and the I2RS agent over a secure transport.
	I2RS agent over a secure transport. This section focuses on I2RS		This section focuses on I2RS access control architecture (section
	access control architecture (section 4.1), access control policies of		4.1), access control policies of the I2RS agent (section 4.2), the
	the I2RS agent (section 4.2), the I2RS client (section 4.3), and 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 the routing system resource via numerous		Applications access the routing system resource via numerous
	intermediate 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 with 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
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 16 ¶
	"Write failure: you do not have write permission", or "Write failure:		"Write failure: you do not have write permission", or "Write failure:
	resource accessed by someone else".		resource accessed by someone else".
	This requirement has been written in a generic manner as it relates		This requirement has been written in a generic manner as it relates
	to 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		[RFC8241]), 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
	other, and communication between them should also be		other, and communication between them should also be
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 16 ¶
	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 an "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 requirement 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 [RFC8241].
	[I-D.ietf-i2rs-protocol-security-requirements].
	Explanation:		Explanation:
	If the I2RS application is authenticated to the I2RS client, and the		If the I2RS application is authenticated to the I2RS client, and the
	I2RS client is authenticated to the I2RS agent, and the I2RS client		I2RS client is authenticated to the I2RS agent, and the I2RS client
	uses the opaque secondary identifier to pass an authenticated		uses the opaque secondary identifier to pass an authenticated
	identifier to the I2RS agent, then this identifier may be used for		identifier to the I2RS agent, then this identifier may be used for
	access control. However, caution should be taken when using this		access control. However, caution should be taken when using this
	chain of authentication since the secondary identifier is intended in		chain of authentication since the secondary identifier is intended in
	the I2RS protocol only to aid traceability.		the I2RS protocol only to aid traceability.
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 38 ¶
	From the environment perspective the I2RS agent MUST be aware when		From the environment perspective the I2RS agent MUST be aware when
	the resource has been modified outside the I2RS plane by another		the resource has been modified outside the I2RS plane by another
	plane (management, control, or forwarding). The prioritization		plane (management, control, or forwarding). The prioritization
	between the different planes should set a deterministic policy that		between the different planes should set a deterministic policy that
	allows the collision of two planes (I2RS plane and another plane) to		allows the collision of two planes (I2RS plane and another plane) to
	be resolved via an overwrite policy in the I2RS agent.		be resolved via an overwrite policy in the I2RS agent.
	Similar requirements exist for knowledge about identities within the		Similar requirements exist for knowledge about identities within the
	I2RS plane which modify things in the routing system, but this is		I2RS plane which modify things in the routing system, but this is
	within the scope of the I2RS protocol's requirements for ephemeral		within the scope of the I2RS protocol's requirements for ephemeral
	state [I-D.ietf-i2rs-ephemeral-state] and security requirements		state [RFC8242] and security requirements [RFC8241].
	[I-D.ietf-i2rs-protocol-security-requirements].
	4.2.2. I2RS Client Access Control Policies		4.2.2. I2RS Client Access Control Policies
	Overview:		Overview:
	The I2RS client access control policies are responsible for		The I2RS client access control policies are responsible for
	authenticating the application managing the privileges for the		authenticating the application managing the privileges for the
	applications, and enforcing access control to resources by the		applications, and enforcing access control to resources by the
	applications.		applications.
	skipping to change at page 27, line 12 ¶		skipping to change at page 27, line 12 ¶
	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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem		[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
	Statement for the Interface to the Routing System",		Statement for the Interface to the Routing System",
	RFC 7920, DOI 10.17487/RFC7920, June 2016,		RFC 7920, DOI 10.17487/RFC7920, June 2016,
	<http://www.rfc-editor.org/info/rfc7920>.		<https://www.rfc-editor.org/info/rfc7920>.
	[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.		[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
	Nadeau, "An Architecture for the Interface to the Routing		Nadeau, "An Architecture for the Interface to the Routing
	System", RFC 7921, DOI 10.17487/RFC7921, June 2016,		System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
	<http://www.rfc-editor.org/info/rfc7921>.		<https://www.rfc-editor.org/info/rfc7921>.
	[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to		[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
	the Routing System (I2RS) Traceability: Framework and		the Routing System (I2RS) Traceability: Framework and
	Information Model", RFC 7922, DOI 10.17487/RFC7922, June		Information Model", RFC 7922, DOI 10.17487/RFC7922, June
	2016, <http://www.rfc-editor.org/info/rfc7922>.		2016, <https://www.rfc-editor.org/info/rfc7922>.
	[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements		[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
	for Subscription to YANG Datastores", RFC 7923,		for Subscription to YANG Datastores", RFC 7923,
	DOI 10.17487/RFC7923, June 2016,		DOI 10.17487/RFC7923, June 2016,
	<http://www.rfc-editor.org/info/rfc7923>.		<https://www.rfc-editor.org/info/rfc7923>.
	[I-D.ietf-i2rs-protocol-security-requirements]		[RFC8241] Hares, S., Migault, D., and J. Halpern, "Interface to the
	Hares, S., Migault, D., and J. Halpern, "I2RS Security		Routing System (I2RS) Security-Related Requirements",
	Related Requirements", draft-ietf-i2rs-protocol-security-		RFC 8241, DOI 10.17487/RFC8241, September 2017,
	requirements-17 (work in progress), September 2016.		<https://www.rfc-editor.org/info/rfc8241>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-i2rs-ephemeral-state]		[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System
	Haas, J. and S. Hares, "I2RS Ephemeral State		(I2RS) Ephemeral State Requirements", RFC 8242,
	Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in		DOI 10.17487/RFC8242, September 2017,
	progress), November 2016.		<https://www.rfc-editor.org/info/rfc8242>.
	[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-01 (work in progress), March 2017.		netconf-rfc6536bis-05 (work in progress), September 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, "Network Management Datastore		and R. Wilton, "Network Management Datastore
	Architecture", draft-ietf-netmod-revised-datastores-01		Architecture", draft-ietf-netmod-revised-datastores-04
	(work in progress), March 2017.		(work in progress), August 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. 22 change blocks.
	48 lines changed or deleted		44 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/