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/