draft-ietf-i2rs-protocol-security-requirements-15.txt   draft-ietf-i2rs-protocol-security-requirements-16.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: April 2, 2017 J. Halpern Expires: April 2, 2017 J. Halpern
Ericsson Ericsson
September 29, 2016 September 29, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-15 draft-ietf-i2rs-protocol-security-requirements-16
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 12, line 38 skipping to change at page 12, line 38
architecture multi-headed control ([RFC7921], section 7.8) allow the architecture multi-headed control ([RFC7921], section 7.8) allow the
I2RS agent to deterministically choose one I2RS client. The I2RS I2RS agent to deterministically choose one I2RS client. The I2RS
client with highest priority is given permission to write the client with highest priority is given permission to write the
variable, and the second client receives an error message. variable, and the second client receives an error message.
A single I2RS client may be associated with multiple applications A single I2RS client may be associated with multiple applications
with different tasks (e.g. weekly configurations or emergency with different tasks (e.g. weekly configurations or emergency
configurations). The secondary identity is an opaque value that the configurations). The secondary identity is an opaque value that the
I2RS client passes to the I2RS agent so that this opaque value can be I2RS client passes to the I2RS agent so that this opaque value can be
placed in the tracing file or event stream to identify the placed in the tracing file or event stream to identify the
application using the I2RS client to I2RS agent communication. application using the I2RS client to I2RS agent communication. The
I2RS client is trusted to simply assert the secondary identifier.
One example of the use of the secondary identity is the situation One example of the use of the secondary identity is the situation
where an operator of a network has two applications that use an I2RS where an operator of a network has two applications that use an I2RS
client. The first application is a weekly configuration application client. The first application is a weekly configuration application
that uses the I2RS protocol to change configurations. The second that uses the I2RS protocol to change configurations. The second
application is an application that allows operators to makes application is an application that allows operators to makes
emergency changes to routers in the network. Both of these emergency changes to routers in the network. Both of these
applications use the same I2RS client to write to an I2RS agent. In applications use the same I2RS client to write to an I2RS agent. In
order for traceability to determine which application (weekly order for traceability to determine which application (weekly
configuration or emergency) wrote some configuration changes to a configuration or emergency) wrote some configuration changes to a
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Figure 1 Figure 1
4.4. Multi-Channel Transport: Secure Transport and Insecure Transport 4.4. Multi-Channel Transport: Secure Transport and Insecure Transport
Requirements: Requirements:
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over secure transport and optionally MAY be able to transfer data over
a non-secure transport. The default transport is a secure a non-secure transport. The default transport is a secure
transport, and this means it is mandatory to implement (MTI) in transport, and this secure transport is mandatory to implement
all I2RS agents, and in any I2RS client which: a) performs a Write (MTI) in all I2RS agents, and in any I2RS client which: a)
scope transaction which is sent to the I2RS agent or b): performs a Write scope transaction which is sent to the I2RS agent
configures an Event Scope transaction. It is mandatory to use or b): configures an Event Scope transaction. This secure
(MTU) on any I2RS client's Write transaction or the configuration transport is mandatory to use (MTU) on any I2RS client's Write
of an Event Scope transaction. transaction or the configuration of an Event Scope transaction.
SEC-REQ-10: The secure transport MUST provide data SEC-REQ-10: The secure transport MUST provide data
confidentiality, data integrity, and practical replay prevention. confidentiality, data integrity, and practical replay prevention.
SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD
implement mechanisms that mitigate DoS attacks. For the secure implement mechanisms that mitigate DoS attacks. For the secure
transport, this means the secure transport must support DoS transport, this means the secure transport must support DoS
prevention. For the insecure transport protocol, the I2RS higher- prevention. For the insecure transport protocol, the I2RS higher-
layer protocol MUST contain a transport management layer that layer protocol MUST contain a transport management layer that
considers the detection of DoS attacks and provides a warning over considers the detection of DoS attacks and provides a warning over
skipping to change at page 16, line 33 skipping to change at page 16, line 33
share peering information, most carriers do not share configuration share peering information, most carriers do not share configuration
and traffic statistics. To achieve this, the I2RS higher-layer and traffic statistics. To achieve this, the I2RS higher-layer
protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for
sensitive data needs to be provided; and the confidentiality sensitive data needs to be provided; and the confidentiality
protection on such data during transportation needs to be enforced. protection on such data during transportation needs to be enforced.
Integrity of data is important even if the I2RS protocol is sending Integrity of data is important even if the I2RS protocol is sending
non-confidential data over an insecure connection. The ability to non-confidential data over an insecure connection. The ability to
trace I2RS protocol messages that enact I2RS transactions provides a trace I2RS protocol messages that enact I2RS transactions provides a
minimal aid to helping operators check how messages enact minimal aid to helping operators check how messages enact
transactions on a secure or insecure transport. transactions on a secure or insecure transport. Contextual checks on
specific non-confidential data sent over a insecure connection may
indicate the data integrity is questionable.
4.6. Role-Based Data Model Security 4.6. Role-Based Data Model Security
The I2RS Architecture [RFC7921] specifies access control by "role" The I2RS Architecture [RFC7921] specifies access control by "role"
where role is a method of making access control more manageable by where role is a method of making access control more manageable by
creating a grouping of users so that access control can be specified creating a grouping of users so that access control can be specified
for a role rather than for each of the individuals. Therefore, I2RS for a role rather than for each of the individuals. Therefore, I2RS
role specifies the access control for a group as being read, write, role specifies the access control for a group as being read, write,
or notification. or notification.
 End of changes. 4 change blocks. 
9 lines changed or deleted 12 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/