draft-ietf-i2rs-protocol-security-requirements-08.txt   draft-ietf-i2rs-protocol-security-requirements-09.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: February 18, 2017 J. Halpern Expires: February 20, 2017 J. Halpern
Ericsson Ericsson
August 17, 2016 August 19, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-08 draft-ietf-i2rs-protocol-security-requirements-09
Abstract Abstract
This presents security-related requirements for the I2RS protocol for This presents security-related requirements for the I2RS protocol for
mutual authentication, transport protocols, data transfer and mutual authentication, transport protocols, data transfer and
transactions. transactions.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 February 18, 2017. This Internet-Draft will expire on February 20, 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 13 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3
2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 3 2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 3
3. Security-Related Requirements . . . . . . . . . . . . . . . . 5 3. Security-Related Requirements . . . . . . . . . . . . . . . . 5
3.1. Mutual authentication of an I2RS client and an I2RS Agent 6 3.1. Mutual authentication of an I2RS client and an I2RS Agent 5
3.2. Transport Requirements Based on Mutual Authentication . . 6 3.2. Transport Requirements Based on Mutual Authentication . . 6
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 8 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 7
3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 8 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 8
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 9 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 8
3.6. Security of the environment . . . . . . . . . . . . . . . 9 3.6. Security of the environment . . . . . . . . . . . . . . . 9
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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. from network routing systems.
This document describes the requirements for the I2RS protocol in the This document describes the requirements for the I2RS protocol in the
skipping to change at page 5, line 29 skipping to change at page 5, line 29
I2RS routing system I2RS routing system
Layer three (L3) routing systems which include physical routers, Layer three (L3) routing systems which include physical routers,
virtual routers (in hypervisors or load splitters), and other virtual routers (in hypervisors or load splitters), and other
devices supporting L3 routing in order to forward packets based on devices supporting L3 routing in order to forward packets based on
L3 headers. L3 headers.
3. Security-Related Requirements 3. Security-Related Requirements
The security for the I2RS protocol requires mutually authenticated The security for the I2RS protocol requires mutually authenticated
I2RS clients and I2RS agents. The I2RS client and I2RS agent using I2RS clients and I2RS agents communicating over a secure transport.
the I2RS protocol MUST be able to exchange data over a secure
transport, but some functions may operate on a non-secure transport.
The I2RS protocol MUST be able to provide atomicity of an I2RS The I2RS protocol MUST be able to provide atomicity of an I2RS
transaction, but it is not required to have multi-message atomicity transaction, but it is not required to have multi-message atomicity
and roll-back mechanism transactions. Multiple messages transactions and roll-back mechanism transactions. Multiple messages transactions
may be impacted by the interdependency of data. This section may be impacted by the interdependency of data. This section
discusses the details of these security requirements. discusses the details of these security requirements.
There are dependencies in some of the requirements below. For There are dependencies in some of the requirements below. For
confidentiality (section 3.3) and integrity (section 3.4) to be confidentiality (section 3.3) and integrity (section 3.4) to be
achieved, the client-agent must have mutual authentication (section achieved, the client-agent must have mutual authentication (section
3.1) and secure transport (section 3.2). Since I2RS does not itself 3.1) and secure transport (section 3.2). Since I2RS does not itself
provide confidentiality and integrity, it depends on running over a provide confidentiality and integrity, it depends on running over a
secure Transport that provides these features. secure Transport that provides these features.
I2RS allows the use of an insecure transport for portions of data
models that clearly indicate the use of an insecure transport.
Operators deploying I2RS must determine if they want to populate and
deploy the portions of the data model which use insecure transports.
3.1. Mutual authentication of an I2RS client and an I2RS Agent 3.1. Mutual authentication of an I2RS client and an I2RS Agent
The I2RS architecture [RFC7921] sets the following requirements: The I2RS architecture [RFC7921] sets the following requirements:
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.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
mutual identification of the I2RS client and I2RS agent. mutual identification of the I2RS client and I2RS agent.
o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a
I2RS client, MUST confirm that the I2RS client has a valid I2RS client, MUST confirm that the I2RS client has a valid
identifier. identifier.
o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from
an I2RS agent, MUST confirm the I2RS agent has a valid identifier. an I2RS agent, MUST confirm the I2RS agent has a valid identifier.
o SEC-REQ-05: Identifier distribution and the loading of these o SEC-REQ-05: Identifier distribution and the loading of these
identifiers into I2RS agent and I2RS Client SHOULD occur outside identifiers into I2RS agent and I2RS Client SHOULD occur outside
the I2RS protocol. The I2RS protocol SHOULD assume some the I2RS protocol prior to the I2RS protocol establishing a
mechanism(s) (IETF or private) will distribute the identifiers and connection between I2RS client and I2RS agent. (One mechanism
load these into the I2RS client and agent so that the I2RS client/ such mechanism is AAA protocols.)
agent has these identifiers prior to the I2RS protocol
establishing a connection between I2RS client and I2RS agent.
(One mechanism such mechanism is AAA protocols.)
o SEC-REQ-06: Each Identifier MUST have just one priority. o SEC-REQ-06: Each Identifier MUST have just one priority.
o SEC-REQ-07: Each Identifier is associated with one secondary o SEC-REQ-07: Each Identifier is associated with one secondary
identifier during a particular I2RS transaction (e.g. read/write identifier during a particular I2RS transaction (e.g. read/write
sequence), but the secondary identifier may vary during the time a sequence), but the secondary identifier may vary during the time a
connection between the I2RS client and I2RS agent is active. connection between the I2RS client and I2RS agent is active.
Since a single I2RS client may be use by multiple applications, Since a single I2RS client may be use by multiple applications,
the secondary identifier may vary as the I2RS client is utilize by the secondary identifier may vary as the I2RS client is utilize by
different application each of whom have a unique secondary different application each of whom have a unique secondary
skipping to change at page 7, line 7 skipping to change at page 6, line 40
SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over a secure transport and optionally MAY be able to transfer data over a
non-secure transport. A secure transport MUST provide data non-secure transport. A secure transport MUST provide data
confidentiality, data integrity, and replay prevention. confidentiality, data integrity, and replay prevention.
The default I2RS transport is a secure transport. The default I2RS transport is a secure transport.
A non-secure transport can be used for publishing telemetry data or A non-secure transport can be used for publishing telemetry data or
other operational state that was specifically indicated to non- other operational state that was specifically indicated to non-
confidential in the data model in the Yang syntax. confidential in the data model in the Yang syntax. Since the non-
secure transport is optional, the operator may transmit this data
over a secure transport. The following are further restrictions on
the non-secure transport:
The configuration of ephemeral data in the I2RS Agent by the I2RS o The configuration of ephemeral data in the I2RS Agent by the I2RS
client SHOULD be done over a secure transport. It is anticipated client SHOULD be done over a secure transport.
that the passing of most I2RS ephemeral state operational status
SHOULD be done over a secure transport. As o It is anticipated that the passing of most I2RS ephemeral state
[I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate operational status SHOULD be done over a secure transport.
whether the transport exchanging the data between I2RS client and
I2RS agent is secure or insecure. The default mode of transport is o As [I-D.ietf-i2rs-ephemeral-state] notes, each data model SHOULD
secure so data models SHOULD clearly annotate what data nodes can be indicate whether the transport exchanging the data between I2RS
passed over an insecure connection. client and I2RS agent is secure or insecure.
SEC-REQ-09: A secure transport MUST be associated with a key SEC-REQ-09: A secure transport MUST be associated with a key
management solution that can guarantee that only the entities having management solution that can guarantee that only the entities having
sufficient privileges can get the keys to encrypt/decrypt the sufficient privileges can get the keys to encrypt/decrypt the
sensitive data. Per BCP107 [RFC4107] this key management system sensitive data. Per BCP107 [RFC4107] this key management system
SHOULD be automatic, but MAY be manual in the following scenarios: SHOULD be automatic, but MAY be manual in the following scenarios:
a) The environment has limited bandwidth or high round-trip times. a) The environment has limited bandwidth or high round-trip times.
b) The information being protected has low value. b) The information being protected has low value.
 End of changes. 14 change blocks. 
35 lines changed or deleted 28 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/