draft-ietf-i2rs-protocol-security-requirements-14.txt   draft-ietf-i2rs-protocol-security-requirements-15.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 31, 2017 J. Halpern Expires: April 2, 2017 J. Halpern
Ericsson Ericsson
September 27, 2016 September 29, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-14 draft-ietf-i2rs-protocol-security-requirements-15
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 31, 2017. This Internet-Draft will expire on April 2, 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 42 skipping to change at page 2, line 42
4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10
4.1. I2RS Peers(agent and client) Identity Authentication . . 10 4.1. I2RS Peers(agent and client) Identity Authentication . . 10
4.2. Identity Validation Before Role-Based Message Actions . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Management Protocol Security . . . . . . . . . . . . . . 15 4.5. Management Protocol Security . . . . . . . . . . . . . . 15
4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16
4.7. Security of the environment . . . . . . . . . . . . . . . 17 4.7. Security of the environment . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . . 20 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 system. An I2RS access to information and state within the routing system. An I2RS
client interacts with one or more I2RS agents to collect information client interacts with one or more I2RS agents to collect information
skipping to change at page 14, line 35 skipping to change at page 14, line 35
secure transport sessions providing protocol and data secure transport sessions providing protocol and data
communication between an I2RS agent and an I2RS client. However, communication between an I2RS agent and an I2RS client. However,
a single I2RS agent to I2RS client connection MAY elect to use a a single I2RS agent to I2RS client connection MAY elect to use a
single secure transport session or a single non-secure transport single secure transport session or a single non-secure transport
session conforming the requirements above. session conforming the requirements above.
SEC-REQ-15: Deployment configuration knobs SHOULD be created to SEC-REQ-15: Deployment configuration knobs SHOULD be created to
allow operators to send "non-confidential" Read scope (data or allow operators to send "non-confidential" Read scope (data or
Event streams) over a secure transport. Event streams) over a secure transport.
SEC-REQ-16: The I2RS protocol makes use of both secure and
insecure transports, but this use MUST NOT be done in any way that
weakens the secure transport protocol used in the I2RS protocol or
other contexts that do not have this requirement for mixing secure
and insecure modes of operation.
Explanation: Explanation:
The I2RS architecture defines three scopes: read, write, and The I2RS architecture defines three scopes: read, write, and
notification scope. Insecure data can only be used for read scope notification scope. Insecure data can only be used for read scope
and notification scope of "non-confidential data". The configuration and notification scope of "non-confidential data". The configuration
of ephemeral data in the I2RS agent uses either write scope for data of ephemeral data in the I2RS agent uses either write scope for data
or write scope for configuration of event notification streams. The or write scope for configuration of event notification streams. The
requirement to use secure transport for configuration prevents requirement to use secure transport for configuration prevents
accidental or malevolent entities from altering the I2RS routing accidental or malevolent entities from altering the I2RS routing
system through the I2RS agent. system through the I2RS agent.
skipping to change at page 15, line 27 skipping to change at page 15, line 35
d) The scale of the deployment is limited. d) The scale of the deployment is limited.
Operators deploying the I2RS protocol selecting manual key management Operators deploying the I2RS protocol selecting manual key management
SHOULD consider both short and medium term plans. Deploying SHOULD consider both short and medium term plans. Deploying
automatic systems initially may save effort over the long-term. automatic systems initially may save effort over the long-term.
4.5. Management Protocol Security 4.5. Management Protocol Security
Requirements: Requirements:
SEC-REQ-16: In a critical infrastructure, certain data within SEC-REQ-17: In a critical infrastructure, certain data within
routing elements is sensitive and read/write operations on such routing elements is sensitive and read/write operations on such
data SHOULD be controlled in order to protect its confidentiality. data SHOULD be controlled in order to protect its confidentiality.
To achieve this, higher-layer protocols MUST utilize a secure To achieve this, higher-layer protocols MUST utilize a secure
transport, and SHOULD provide access control functions to protect transport, and SHOULD provide access control functions to protect
confidentiality of the data. confidentiality of the data.
SEC-REQ-17: An integrity protection mechanism for I2RS MUST be SEC-REQ-18: An integrity protection mechanism for I2RS MUST be
provided that will be able to ensure the following: provided that will be able to ensure the following:
1) the data being protected is not modified without detection 1) the data being protected is not modified without detection
during its transportation, during its transportation,
2) the data is actually from where it is expected to come from, 2) the data is actually from where it is expected to come from,
and and
3) the data is not repeated from some earlier interaction the 3) the data is not repeated from some earlier interaction the
higher layer protocol (best effort). higher layer protocol (best effort).
The I2RS higher-layer protocol operating over a secure transport The I2RS higher-layer protocol operating over a secure transport
provides this integrity. The I2RS higher-layer protocol operating provides this integrity. The I2RS higher-layer protocol operating
over an insecure transport SHOULD provide some way for the client over an insecure transport SHOULD provide some way for the client
receiving non-confidential read-scoped or event-scoped data over receiving non-confidential read-scoped or event-scoped data over
the insecure connection to detect when the data integrity is the insecure connection to detect when the data integrity is
questionable; and in the event of a questionable data integrity questionable; and in the event of a questionable data integrity
the I2RS client should disconnect the insecure transport the I2RS client should disconnect the insecure transport
connection. connection.
SEC-REQ-18: The I2RS higher-layer protocol MUST provide a SEC-REQ-19: The I2RS higher-layer protocol MUST provide a
mechanism for message traceability (requirements in [RFC7922]) mechanism for message traceability (requirements in [RFC7922])
that supports the tracking higher-layer functions run across that supports the tracking higher-layer functions run across
secure connection or a non-secure transport. secure connection or a non-secure transport.
Explanation: Explanation:
Most carriers do not want a router's configuration and data flow Most carriers do not want a router's configuration and data flow
statistics known by hackers or their competitors. While carriers may statistics known by hackers or their competitors. While carriers may
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
skipping to change at page 16, line 37 skipping to change at page 16, line 44
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.
SEC-REQ-19: The rules around what I2RS security role is permitted SEC-REQ-20: The rules around what I2RS security role is permitted
to access and manipulate what information over a secure transport to access and manipulate what information over a secure transport
(which protects the data in transit) SHOULD ensure that data of (which protects the data in transit) SHOULD ensure that data of
any level of sensitivity is reasonably protected from being any level of sensitivity is reasonably protected from being
observed by those without permission to view it, so that privacy observed by those without permission to view it, so that privacy
requirements are met. requirements are met.
SEC-REQ-20: Role security MUST work when multiple transport SEC-REQ-21: Role security MUST work when multiple transport
connections are being used between the I2RS client and I2RS agent connections are being used between the I2RS client and I2RS agent
as the I2RS architecture [RFC7921] describes. as the I2RS architecture [RFC7921] describes.
Sec-REQ-21: If an I2RS agents or an I2RS client is tightly Sec-REQ-22: If an I2RS agents or an I2RS client is tightly
correlated with a person, then the I2RS protocol and data models correlated with a person, then the I2RS protocol and data models
SHOULD provide additional security that protects the person's SHOULD provide additional security that protects the person's
privacy. privacy.
Explanation: Explanation:
I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF) I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF)
to pass messages in order to enact I2RS transactions. Role Security to pass messages in order to enact I2RS transactions. Role Security
must secure data (sensitivity and normal data) in a router even when must secure data (sensitivity and normal data) in a router even when
it is operating over multiple connections at the same time. NETCONF it is operating over multiple connections at the same time. NETCONF
skipping to change at page 19, line 14 skipping to change at page 19, line 24
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-18 (work in Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in
progress), September 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-17 (work in
progress), August 2016. progress), September 2016.
[I-D.ietf-taps-transports] [I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion provided by IETF transport protocols and congestion
control mechanisms", draft-ietf-taps-transports-11 (work control mechanisms", draft-ietf-taps-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,
 End of changes. 13 change blocks. 
14 lines changed or deleted 20 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/