draft-ietf-i2rs-protocol-security-requirements-11.txt		draft-ietf-i2rs-protocol-security-requirements-12.txt
	I2RS working group S. Hares		I2RS working group S. Hares
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Informational D. Migault		Intended status: Informational D. Migault
	Expires: March 19, 2017 J. Halpern		Expires: March 30, 2017 J. Halpern
	Ericsson		Ericsson
	September 15, 2016		September 26, 2016
	I2RS Security Related Requirements		I2RS Security Related Requirements
	draft-ietf-i2rs-protocol-security-requirements-11		draft-ietf-i2rs-protocol-security-requirements-12
	Abstract		Abstract
	This presents security-related requirements for the I2RS protocol		This presents security-related requirements for the I2RS protocol
	which provides a new interface to the routing system described in the		which provides a new interface to the routing system described in the
	I2RS architecture document (RFC7921). The I2RS protocol is a re-use		I2RS architecture document (RFC7921). The I2RS protocol is a re-use
	protocol implemented by re-using portions of existing IETF protocols		protocol implemented by re-using portions of existing IETF protocols
	and adding new features to these protocols. The I2RS protocol re-		and adding new features to these protocols. The I2RS protocol re-
	uses security features of a secure transport (E.g. TLS, SSH, DTLS)		uses security features of a secure transport (E.g. TLS, SSH, DTLS)
	such as encryption, message integrity, mutual peer authentication,		such as encryption, message integrity, mutual peer authentication,
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 March 19, 2017.		This Internet-Draft will expire on March 30, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 34 ¶		skipping to change at page 2, line 34 ¶
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5		2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5
	2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5		2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5
	3. Security Features and Protocols: Re-used and New . . . . . . 7		3. Security Features and Protocols: Re-used and New . . . . . . 7
	3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7		3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7
	3.2. New Features Related to Security . . . . . . . . . . . . 8		3.2. New Features Related to Security . . . . . . . . . . . . 8
	3.3. I2RS Protocol Security Requirements vs. IETF Management		3.3. I2RS Protocol Security Requirements vs. IETF Management
	Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9		Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Security-Related Requirements . . . . . . . . . . . . . . . . 10		4. Security-Related Requirements . . . . . . . . . . . . . . . . 10
	4.1. I2RS Peers(agent and client) Identity Authentication . . 11		4.1. I2RS Peers(agent and client) Identity Authentication . . 11
	4.2. Identity Validation Before Role-Based Message Actions . . 12		4.2. Identity Validation Before Role-Based Message Actions . . 11
	4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12		4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12
	4.4. Multi-Channel Transport: Secure Transport and Insecure		4.4. Multi-Channel Transport: Secure Transport and Insecure
	Transport . . . . . . . . . . . . . . . . . . . . . . . . 14		Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.5. Management Protocol Security . . . . . . . . . . . . . . 16		4.5. Management Protocol Security . . . . . . . . . . . . . . 15
	4.6. Role-Based Data Model Security . . . . . . . . . . . . . 17		4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16
	4.7. Security of the environment . . . . . . . . . . . . . . . 18		4.7. Security of the environment . . . . . . . . . . . . . . . 17
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Interface to the Routing System (I2RS) provides read and write		The Interface to the Routing System (I2RS) provides read and write
	access to information and state within the routing process. An I2RS		access to information and state within the routing process. An I2RS
	client interacts with one or more I2RS agents to collect information		client interacts with one or more I2RS agents to collect information
	from network routing systems. [RFC7921] describes the architecture		from network routing systems. [RFC7921] describes the architecture
	of this interface, and this documents assumes the reader is familiar		of this interface, and this documents assumes the reader is familiar
	with this architecture and its definitions. Section 2 highlights		with this architecture and its definitions. Section 2 highlights
	some of the references the reader is required to be familiar with.		some of the references the reader is required to be familiar with.
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	protocols (Radius over TLS or Diameter over TLS) to securely		protocols (Radius over TLS or Diameter over TLS) to securely
	distribute identity information.		distribute identity information.
	Section 3 provides an overview of security features and protocols		Section 3 provides an overview of security features and protocols
	being re-used (section 3.1) and the new security features being		being re-used (section 3.1) and the new security features being
	required (section 3.2). Section 3 also explores how existing and new		required (section 3.2). Section 3 also explores how existing and new
	security features and protocols would be paired with existing IETF		security features and protocols would be paired with existing IETF
	management protocols (section 3.3).		management protocols (section 3.3).
	The new features I2RS extends to these protocols are a priority		The new features I2RS extends to these protocols are a priority
	mechanism to handle multi-headed reads, an opaque secondary		mechanism to handle multi-headed writes, an opaque secondary
	identifier to allow traceability of an application utilizing a		identifier to allow traceability of an application utilizing a
	specific I2RS client to communicate with an I2RS agent, and insecure		specific I2RS client to communicate with an I2RS agent, and insecure
	transport constrained to be utilized only for read-only data which		transport constrained to be utilized only for read-only data which
	publically available data (e.g. public BGP Events, public telemetry		publically available data (e.g. public BGP Events, public telemetry
	information, web service available) and some legacy data.		information, web service available) and some legacy data.
	Section 4 provides the I2RS protocol security requirements by the		Section 4 provides the I2RS protocol security requirements by the
	following security features:		following security features:
	o peer identity authentication (section 4.1),		o peer identity authentication (section 4.1),
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	The I2RS AAA protocols supporting the I2RS higher-layer protocol.		The I2RS AAA protocols supporting the I2RS higher-layer protocol.
	The I2RS higher-layer protocol requires implementation of a I2RS		The I2RS higher-layer protocol requires implementation of a I2RS
	secure-transport component protocol and the I2RS management component		secure-transport component protocol and the I2RS management component
	protocol. The I2RS AAA component protocol is optional.		protocol. The I2RS AAA component protocol is optional.
	3. Security Features and Protocols: Re-used and New		3. Security Features and Protocols: Re-used and New
	3.1. Security Protocols Re-Used by the I2RS Protocol		3.1. Security Protocols Re-Used by the I2RS Protocol
	I2RS also requires a secure transport protocol and key distribution		I2RS requires a secure transport protocol and key distribution
	protocols. The secure transport features required by I2RS are peer		protocols. The secure transport features required by I2RS are peer
	authentication, confidentiality, data integrity, and replay		authentication, confidentiality, data integrity, and replay
	protection for I2RS messages. According to		protection for I2RS messages. According to
	[I-D.ietf-taps-transports], the secure transport protocols which		[I-D.ietf-taps-transports], the secure transport protocols which
	support peer authentication, confidentiality, data integrity, and		support peer authentication, confidentiality, data integrity, and
	replay protection are the following:		replay protection are the following:
	1. TLS [RFC5246] over TCP or SCTP,		1. TLS [RFC5246] over TCP or SCTP,
	2. DTLS over UDP with replay detection and anti-DoS stateless cookie		2. DTLS over UDP with replay detection and anti-DoS stateless cookie
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	allow DTLS options of record size negotiation and and conveyance		allow DTLS options of record size negotiation and and conveyance
	of "don't" fragment bits to be optional in deployments.		of "don't" fragment bits to be optional in deployments.
	3. HTTP over TLS (over TCP or SCTP), and		3. HTTP over TLS (over TCP or SCTP), and
	4. HTTP over DTLS (with the requirements and optional features		4. HTTP over DTLS (with the requirements and optional features
	specified above in item 2).		specified above in item 2).
	The following protocols will need to be extended to provide		The following protocols will need to be extended to provide
	confidentiality, data integrity, peer authentication, and key		confidentiality, data integrity, peer authentication, and key
	distribution protocols: SSH, SCTP, or the ForCES TML layer over SCTP.		distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML
			layer (over SCTP). These protocols will need extensions to run over
			a secure transport (TLS or DTLS) (see section 3.3 for details).
	The specific type of key management protocols an I2RS secure		The specific type of key management protocols an I2RS secure
	transport uses depends on the transport. Key management protocols		transport uses depends on the transport. Key management protocols
	utilized for the I2RS protocols SHOULD support automatic rotation.		utilized for the I2RS protocols SHOULD support automatic rotation.
	An I2RS implementer may use AAA protocols over secure transport to		An I2RS implementer may use AAA protocols over secure transport to
	distribute the identities for I2RS client and I2RS agent and role		distribute the identities for I2RS client and I2RS agent and role
	authorization information. Two AAA protocols are: Diameter [RFC6733]		authorization information. Two AAA protocols are: Diameter [RFC6733]
	and Radius [RFC2865]. To provide the best security I2RS peer		and Radius [RFC2865]. To provide the best security I2RS peer
	identities, the AAA protocols MUST be run over a secure transport		identities, the AAA protocols MUST be run over a secure transport
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 39 ¶
	The I2RS client with the highest priority will have its write		The I2RS client with the highest priority will have its write
	succeed. This document specifies requirements for this new concept		succeed. This document specifies requirements for this new concept
	of priority.		of priority.
	The opaque secondary identifier identifies an application which is		The opaque secondary identifier identifies an application which is
	using the I2RS client to I2RS agent communication to manage the		using the I2RS client to I2RS agent communication to manage the
	routing system. The secondary identifier is opaque to the I2RS		routing system. The secondary identifier is opaque to the I2RS
	protocol. In order to protect personal privacy, the secondary		protocol. In order to protect personal privacy, the secondary
	identifier should not contain personal identifiable information.		identifier should not contain personal identifiable information.
	The last new security feature is the ability to allow non-		The last new feature related to I2RS security is the ability to allow
	confidential data to be transfered over a non-secure transport. It		non-confidential data to be transferred over a non-secure transport.
	is expected that most I2RS data models will describe information that		It is expected that most I2RS data models will describe information
	will be transferred with confidentiality. Therefore, any model which		that will be transferred with confidentiality. Therefore, any model
	transfers data over a non-secure transport is marked. The use of a		which transfers data over a non-secure transport is marked. The use
	non-secure transport is optional, and an implementer SHOULD create		of a non-secure transport is optional, and an implementer SHOULD
	knobs that allow data marked as non-confidential to be sent over a		create knobs that allow data marked as non-confidential to be sent
	secure transport.		over a secure transport.
	Non-confidential data can only be read or notification scope		Non-confidential data can only be read or notification scope
	transmission of events. Non-confidential data cannot be write scope		transmission of events. Non-confidential data cannot be write scope
	or notification scope configuration. An example of non-confidential		or notification scope configuration. An example of non-confidential
	data is the telemetry information that is publically known (e.g. BGP		data is the telemetry information that is publically known (e.g. BGP
	route-views data or web site status data) or some legacy data (e.g.		route-views data or web site status data) or some legacy data (e.g.
	interface) which cannot be transported in secure transport. The IETF		interface) which cannot be transported in secure transport. The IETF
	I2RS Data models MUST indicate in the data model the specific data		I2RS Data models MUST indicate in the data model the specific data
	which is non-confidential.		which is non-confidential.
	Most I2RS data models will expect that the information described in		Most I2RS data models will expect that the information described in
	the model will be transferred with confidentiality. Therefore, it is		the model will be transferred with confidentiality.
	3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols		3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols
	Table 1 below provides a partial list of the candidate management		Table 1 below provides a partial list of the candidate management
	protocols and the secure transports each one of the support. One		protocols and the secure transports each one of the support. One
	column in the table indicates the transport protocol will need I2RS		column in the table indicates the transport protocol will need I2RS
	security extensions.		security extensions.
	Mangement		Mangement
	Protocol Transport Protocol I2RS Extensions		Protocol Transport Protocol I2RS Extensions
	skipping to change at page 10, line 20 ¶		skipping to change at page 9, line 34 ¶
	RESTCONF HTTP over TLS with None required (*2)		RESTCONF HTTP over TLS with None required (*2)
	X.509v3 certificates,		X.509v3 certificates,
	certificate validation,		certificate validation,
	mutual authentication:		mutual authentication:
	1) authenticated		1) authenticated
	server identity,		server identity,
	2) authenticated		2) authenticated
	client identity		client identity
	(*1)		(*1)
	FORCES TML overs SCTP Needs extension to		FORCES TML over SCTP Needs extension to
	(*1) TML to run TML		(*1) TML to run TML over
	over TLS over SCTP,		TLS over SCTP, or
	or DTLS described		DTLS with options for
	above. The		replay protection
	IPSEC mechanism is		and anti-DoS stateless
	not sufficient for		cookie mechanism.
	I2RS traveling over		(DTLS record size
	multiple hops		negotiation and conveyance
	(router + link)		of "don't" fragment
	(*2)		bits are optional).
			The IPSEC mechanism is
			not sufficient for
			I2RS traveling over
			multiple hops
			(router + link) (*2)
	IPFIX SCTP, TCP, UDP Needs to extension		IPFIX SCTP, TCP, UDP Needs to extension
	TLS or DTLS for to support TLS or		TLS or DTLS for to support TLS or
	secure client (*1) DTLS with options		secure client (*1) DTLS with options for
	described above. (*2)		replay protection
			and anti-DoS stateless
			cookie mechanism.
			(DTLS record size
			negotiation and conveyance
			of "don't" fragment
			bits are optional).
	*1 - Key management protocols		*1 - Key management protocols
	MUST support appropriate key rotation.		MUST support appropriate key rotation.
	*2 - Identity and Role authorization distributed		*2 - Identity and Role authorization distributed
	by Diameter or Radius MUST use Diameter over TLS		by Diameter or Radius MUST use Diameter over TLS
	or Radius over TLS.		or Radius over TLS.
	4. Security-Related Requirements		4. Security-Related Requirements
	skipping to change at page 11, line 23 ¶		skipping to change at page 10, line 46 ¶
	o role-based security (section 4.6),		o role-based security (section 4.6),
	o security environment (section 4.7)		o security environment (section 4.7)
	The I2RS Protocol depends upon a secure transport layer for peer		The I2RS Protocol depends upon a secure transport layer for peer
	authentication, data integrity, confidentiality, and replay		authentication, data integrity, confidentiality, and replay
	protection. The optional insecure transport can only be used		protection. The optional insecure transport can only be used
	restricted set of publically data available (events or information)		restricted set of publically data available (events or information)
	or a select set of legacy data. Data passed over the insecure		or a select set of legacy data. Data passed over the insecure
	transport channel MUST not contain any data which identifies a person		transport channel MUST NOT contain any data which identifies a person
	or any "write" transactions.		or any "write" transactions.
	4.1. I2RS Peers(agent and client) Identity Authentication		4.1. I2RS Peers(agent and client) Identity Authentication
	The following requirements specify the security requirements for Peer		The following requirements specify the security requirements for Peer
	Identity Authentication for the I2RS protocol:		Identity Authentication for the I2RS protocol:
	o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an		o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
	identity, and at least one unique identifier that uniquely		identity, and at least one unique identifier that uniquely
	identifies each party in the I2RS protocol context.		identifies each party in the I2RS protocol context.
	skipping to change at page 19, line 36 ¶		skipping to change at page 19, line 9 ¶
	[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>.		<http://www.rfc-editor.org/info/rfc7923>.
	8.2. Informative References		8.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-16 (work in		Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in
	progress), August 2016.		progress), September 2016.
	[I-D.ietf-netconf-restconf]		[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", draft-ietf-netconf-restconf-16 (work in		Protocol", draft-ietf-netconf-restconf-16 (work in
	progress), August 2016.		progress), August 2016.
	[I-D.ietf-taps-transports]		[I-D.ietf-taps-transports]
	Fairhurst, G., Trammell, B., and M. K&#258;&#378;hlewind,		Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
	"Services provided by IETF transport protocols and		provided by IETF transport protocols and congestion
	congestion control mechanisms", draft-ietf-taps-		control mechanisms", draft-ietf-taps-transports-11 (work
	transports-11 (work in progress), July 2016.		in progress), July 2016.
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
	RFC 2865, DOI 10.17487/RFC2865, June 2000,		RFC 2865, DOI 10.17487/RFC2865, June 2000,
	<http://www.rfc-editor.org/info/rfc2865>.		<http://www.rfc-editor.org/info/rfc2865>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<http://www.rfc-editor.org/info/rfc4960>.		<http://www.rfc-editor.org/info/rfc4960>.
End of changes. 18 change blocks.
	47 lines changed or deleted		61 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/