draft-ietf-i2rs-protocol-security-requirements-17.txt   rfc8241.txt 
I2RS working group S. Hares Internet Engineering Task Force (IETF) S. Hares
Internet-Draft Huawei Request for Comments: 8241 Huawei
Intended status: Informational D. Migault Category: Informational D. Migault
Expires: April 2, 2017 J. Halpern ISSN: 2070-1721 J. Halpern
Ericsson Ericsson
September 29, 2016 September 2017
I2RS Security Related Requirements Interface to the Routing System (I2RS) Security-Related Requirements
draft-ietf-i2rs-protocol-security-requirements-17
Abstract Abstract
This presents security-related requirements for the I2RS protocol This document presents security-related requirements for the
which provides a new interface to the routing system described in the Interface to the Routing System (I2RS) protocol, which provides a new
I2RS architecture document (RFC7921). The I2RS protocol is a re-use interface to the routing system described in the I2RS architecture
protocol implemented by re-using portions of existing IETF protocols document (RFC 7921). The I2RS protocol is implemented by reusing
and adding new features to these protocols. The I2RS protocol re- portions of existing IETF protocols and adding new features to them.
uses security features of a secure transport (E.g. TLS, SSH, DTLS) One such reuse is of the security features of a secure transport
such as encryption, message integrity, mutual peer authentication, (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol,
and replay protection. The new I2RS features to consider from a Datagram TLS (DTLS)) such as encryption, message integrity, mutual
security perspective are: a priority mechanism to handle multi-headed peer authentication, and anti-replay protection. The new I2RS
write transactions, an opaque secondary identifier which identifies features to consider from a security perspective are as follows: a
an application using the I2RS client, and an extremely constrained priority mechanism to handle multi-headed write transactions, an
read-only non-secure transport. This document provides the detailed opaque secondary identifier that identifies an application using the
requirements for these security features. I2RS client, and an extremely constrained read-only non-secure
transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on April 2, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8241.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Concepts ........................................4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language ......................................4
2.2. Security Definitions . . . . . . . . . . . . . . . . . . 4 2.2. Security Terminology .......................................4
2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 2.3. I2RS-Specific Terminology ..................................5
3. Security Features and Protocols: Re-used and New . . . . . . 7 2.4. Concepts ...................................................5
3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7 3. Security Features and Protocols: Reused and New .................6
3.2. New Features Related to Security . . . . . . . . . . . . 8 3.1. Security Protocols Reused by the I2RS Protocol .............6
3.3. I2RS Protocol Security Requirements vs. IETF Management 3.2. New Features Related to Security ...........................7
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. I2RS Protocol Security Requirements vs. IETF
4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 Management Protocols .......................................8
4.1. I2RS Peers(agent and client) Identity Authentication . . 10 4. Security-Related Requirements ..................................10
4.2. Identity Validation Before Role-Based Message Actions . . 11 4.1. I2RS Peer (Agent and Client) Identity Authentication ......10
4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 4.2. Identity Validation before Role-Based Message Actions .....11
4.4. Multi-Channel Transport: Secure Transport and Insecure 4.3. Peer Identity, Priority, and Client Redundancy ............12
Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Multi-Channel Transport: Secure and Non-Secure ............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. IANA Considerations ............................................17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations ........................................17
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 7. References .....................................................18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References ......................................18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References ....................................18
8.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgements ..................................................20
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) protocol provides read and
access to information and state within the routing system. An I2RS write access to information and state within the routing system. An
client interacts with one or more I2RS agents to collect information I2RS client interacts with one or more I2RS agents to collect
from network routing systems. [RFC7921] describes the architecture information from network routing systems. [RFC7921] describes the
of this interface, and this documents assumes the reader is familiar architecture of this interface, and this document assumes the reader
with this architecture and its definitions. Section 2 highlights is familiar with this architecture and its definitions.
some of the references the reader is required to be familiar with.
The I2RS interface is instantiated by the I2RS protocol connecting an The I2RS interface is instantiated by the I2RS protocol connecting an
I2RS client and an I2RS agent associated with a routing system. The I2RS client and an I2RS agent associated with a routing system. The
I2RS protocol is a re-use protocol implemented by re-using portions I2RS protocol is implemented by reusing portions of existing IETF
of existing IETF protocols, and adding new features to these protocols and adding new features to them. As a reuse protocol, it
protocols. As a re-use protocol, it can be considered a higher-level can be considered a higher-layer protocol because it can be
protocol since it can be instantiated in multiple management instantiated in multiple management protocols (e.g., NETCONF
protocols (e.g. NETCONF [RFC6241] or RESTCONF [RFC6241] or RESTCONF [RFC8040]) operating over a secure transport.
[I-D.ietf-netconf-restconf]) operating over a secure transport. The These protocols are what provide its security.
security for the I2RS protocol comes from the management protocols
operating over a a secure transport.
This document is part of the requirements for I2RS protocol which This document is part of a suite of documents outlining requirements
also include: for the I2RS protocol, which also includes the following:
o I2RS architecture [RFC7921], o "An Architecture for the Interface to the Routing System"
[RFC7921]
o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], o "I2RS Ephemeral State Requirements" [RFC8242]
o publication/subscription requirements [RFC7922], and o "Interface to the Routing System (I2RS) Traceability: Framework
and Information Model" (which discusses traceability) [RFC7923]
o traceability [RFC7923]. o "Requirements for Subscription to YANG Datastores" (which
highlights the publication/subscription requirements) [RFC7922]
Since the I2RS "higher-level" protocol changes the interface to the Since the I2RS "higher-layer" protocol changes the interface to the
routing systems, it is important that implementers understand the new routing systems, it is important that implementers understand the new
security requirements for the environment the I2RS protocol operates security requirements for the environment the I2RS protocol operates
in. These security requirements for the I2RS environment are in. A summary of the I2RS protocol security environment is found in
specified in [I-D.ietf-i2rs-security-environment-reqs]; and the the I2RS architecture [RFC7921].
summary of the I2RS protocol security environment is found in the
I2RS Architecture [RFC7920].
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which I2RS reuses the secure transport protocols (TLS, SSH, DTLS) that
support encryption, message integrity, peer authentication, and key support encryption, message integrity, peer authentication, and key
distribution protocols. Optionally, implementers may utilize AAA distribution protocols. Optionally, implementers may utilize
protocols (Radius over TLS or Diameter over TLS) to securely Authentication, Authorization, and Accounting (AAA) protocols (Radius
distribute identity information. over TLS or Diameter over TLS) to securely distribute identity
information.
Section 2 highlights some of the terminology and concepts that the
reader is required to be familiar with.
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 reused (Section 3.1), lists the new security features being
required (section 3.2). Section 3 also explores how existing and new required (Section 3.2), and explores how existing and new security
security features and protocols would be paired with existing IETF features and protocols would be paired with existing IETF management
management protocols (section 3.3). 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 writes, 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 non-
transport constrained to be utilized only for read-only data, which secure transport constrained to be used only for read-only data,
may include publically available data (e.g. public BGP Events, public which may include publicly available data (e.g., public BGP events,
telemetry information, web service availability) and some legacy public telemetry information, web service availability) and some
data. legacy data.
Section 4 provides the I2RS protocol security requirements by the
following security features:
o peer identity authentication (section 4.1),
o peer identity validation before role-based message actions
(section 4.2)
o peer identity and client redundancy (section 4.3),
o multi-channel transport requirements: Secure transport and
insecure Transport (section 4.4),
o management protocol security requirements (section 4.5),
o role-based security (section 4.6),
o security environment (section 4.7)
Protocols designed to be I2RS higher-layer protocols need to fulfill Section 4 provides the I2RS protocol security requirements of several
these security requirements. security features. Protocols designed to be I2RS higher-layer
protocols need to fulfill these security requirements.
2. Definitions 2. Terminology and Concepts
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Security Definitions 2.2. Security Terminology
This document utilizes the definitions found in the following This document uses the terminology found in [RFC4949] and [RFC7921].
documents: [RFC4949] and [RFC7921] Specifically, this document reuses the following terms from
Specifically, this document utilizes the following definitions from
[RFC4949]: [RFC4949]:
o access control, o access control
o authentication
o authentication, o data confidentiality
o data integrity
o data confidentiality, o data privacy
o identity
o data integrity, o identifier
o mutual authentication
o data privacy, o role
o role-based access control
o identity, o security audit trail
o trust
o identifier,
o mutual authentication,
o role,
o role-based access control,
o security audit trail, and
o trust.
[RFC7922] describes traceability for I2RS interface and the I2RS [RFC7922] describes traceability for the I2RS interface and the I2RS
protocol. Traceability is not equivalent to a security audit trail protocol. Traceability is not equivalent to a security audit trail
or simple logging of information. A security audit trail may utilize or simple logging of information. A security audit trail may utilize
traceability information. traceability information.
This document also requires that the user is familiar with the 2.3. I2RS-Specific Terminology
pervasive security requirements in [RFC7258].
2.3. I2RS Specific Definitions
The document utilizes the following concepts from the I2RS This document discusses the security of the multiple I2RS
architecture: [RFC7921]: communication channels that operate over the higher-layer I2RS
protocol. The higher-layer I2RS protocol combines a secure transport
and I2RS contextual information, and it reuses IETF protocols and
data models to create the secure transport and the contextual
information driven by the I2RS data model. To describe how the I2RS
higher-layer protocol combines other protocols, the following terms
are used:
o I2RS client, I2RS agent, and I2RS protocol (section 2), I2RS component protocols
o I2RS higher-layer protocol (section 7.2) Protocols that are reused and combined to create the I2RS higher-
layer protocol.
o scope: read scope, notification scope, and write scope (section I2RS secure transport component protocols (required)
2),
o identity and scope of the identity (section 2), Secure transport protocols that combine to support the I2RS
o roles or security rules (section 2), higher-layer protocol.
o identity and scope, and secondary identity (section 2), I2RS management component protocols (required)
o routing system/subsytem (section 2), Management protocols that combine to provide the management-
information context for the I@RS higher-layer protocol.
o I2RS assumed security environment (section 4), I2RS AAA component protocols (optional)
o I2RS identity and authorization (section 4.1), AAA protocols supporting the I2RS higher-layer protocol.
o I2RS authorization, scope of Authorization in I2RS client and 2.4. Concepts
agent (section 4.2),
o client redundancy with a single client identity (section 4.3), The reader should be familiar with the pervasive security
requirements in [RFC7258].
o restrictions on I2RS in personal devices (section 4.4), This document uses the following concepts from the I2RS architecture
[RFC7921] listed below with their respective section numbers from
said RFC:
o communication channels and I2RS high-layer protocol (section 7.2), o I2RS client, agent, and protocol (Section 2)
o active communication versus connectivity (section 7.5), o I2RS higher-layer protocol (Section 7.2)
o scope: read, notification, identity, and write (Section 2)
o multi-headed control (section 7.8), and o identity and secondary identity (Section 2)
o transaction, message, multi-message atomicity (section 7.9). o roles or security rules (Section 2)
This document assumes the reader is familar with these terms. o routing system/subsystem (Section 2)
This document discusses the security of the multiple I2RS o I2RS assumed security environment (Section 4)
communication channels which operate over the higher-layer I2RS
protocol. The higher-layer I2RS protocol combines a secure transport
and I2RS contextual information, and re-uses IETF protocols and data
models to create the secure transport and the I2RS data-model driven
contextual information. To describe how the I2RS high-layer protocol
combines other protocols into the I2RS higher-layer protocol, the
following terms are used:
I2RS component protocols o I2RS identity and authentication (Section 4.1)
Protocols which are re-used and combined to create the I2RS o scope of Authorization in I2RS client and agent (Section 4.2)
protocol.
I2RS secure-transport component protocols o client redundancy with a single client identity (Section 4.3),
The I2RS secure transport protocols that support the I2RS higher- o restrictions on I2RS in personal devices (Section 4.4)
layer protocol.
I2RS management component protocols o communication channels and I2RS higher-layer protocol
The I2RS management protocol which provide the management (Section 7.2)
information context.
I2RS AAA component protocols o active communication versus connectivity (Section 7.5)
The I2RS AAA protocols supporting the I2RS higher-layer protocol. o multi-headed control (Section 7.8)
The I2RS higher-layer protocol requires implementation of a I2RS o transaction, message, multi-message atomicity (Section 7.9)
secure-transport component protocol and the I2RS management component
protocol. The I2RS AAA component protocol is optional.
3. Security Features and Protocols: Re-used and New 3. Security Features and Protocols: Reused and New
3.1. Security Protocols Re-Used by the I2RS Protocol 3.1. Security Protocols Reused by the I2RS Protocol
I2RS 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 for I2RS requires one to provide
authentication, confidentiality, data integrity, and replay peer authentication. In addition, the features required for I2RS
protection for I2RS messages. According to messages are confidentiality, authentication, and replay protection.
[I-D.ietf-taps-transports], the secure transport protocols which According to [RFC8095], the secure transport protocols that support
support peer authentication, confidentiality, data integrity, and peer authentication, confidentiality, data integrity, and replay
replay protection are the following: protection are the following:
1. TLS [RFC5246] over TCP or SCTP, 1. TLS [RFC5246] over TCP or Stream Control Transmission Protocol
(SCTP)
2. DTLS over UDP with replay detection and anti-DoS stateless cookie 2. DTLS over UDP with replay detection and an anti-DoS stateless
mechanism required for the I2RS protocol, and the I2RS protocol cookie mechanism required for the I2RS protocol and the DTLS
allow DTLS options of record size negotiation and and conveyance options of record-size negotiation and conveyance of the Don't
of "don't" fragment bits to be optional in deployments. Fragment (DF) bit are set for IPv4, or no fragmentation extension
headers for IPv6 to be optional in deployments are allowed by the
I2RS protocol
3. HTTP over TLS (over TCP or SCTP), and 3. HTTP over TLS (over TCP or SCTP)
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 would need to be extended to provide As detailed in Section 3.3, the following protocols would need to be
confidentiality, data integrity, peer authentication, and key extended to provide confidentiality, data integrity, peer
distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML authentication, and key distribution and to run over a secure
layer (over SCTP). These protocols will need extensions to run over transport (TLS or DTLS):
a secure transport (TLS or DTLS) (see section 3.3 for details).
o IP Flow Information Export (IPFIX) over SCTP, TCP, or UDP
o Forwarding and Control Element Separation (ForCES) Transport
Mapping Layer (TML) over SCTP
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 the I2RS client, I2RS agent, and role-
authorization information. Two AAA protocols are: Diameter [RFC6733] authorization information. Two AAA protocols are as follows:
and Radius [RFC2865]. To provide the best security I2RS peer Diameter [RFC6733] and Radius [RFC2865]. To provide I2RS peer
identities, the AAA protocols MUST be run over a secure transport identities with the best security, the AAA protocols MUST be run over
(Diameter over secure transport (TLS over TCP) [RFC6733]), Radius a secure transport (Diameter over secure transport (TLS over TCP)
over a secure transport (TLS) [RFC6614]). [RFC6733]), Radius over a secure transport (TLS) [RFC6614]).
3.2. New Features Related to Security 3.2. New Features Related to Security
The new features are priority, an opaque secondary identifier, and an The new features are priority, an opaque secondary identifier, and a
insecure protocol for read-only data constrained to specific standard non-secure protocol for read-only data constrained to specific
usages. The I2RS protocol allows multi-headed control by several standard usages. The I2RS protocol allows multi-headed control by
I2RS clients. This multi-headed control is based on the assumption several I2RS clients. This multi-headed control is based on the
that the operator deploying the I2RS clients, I2RS agents, and the assumption that the operator deploying the I2RS clients, I2RS agents,
I2rs protocol will coordinate the read, write, and notification scope and the I2RS protocol will coordinate the read, write, and
so the I2RS clients will not contend for the same write scope. notification scope so the I2RS clients will not contend for the same
However, just in case there is an unforseen overlap of I2RS clients write scope. However, just in case there is an unforeseen overlap of
attempting to write a particular piece of data, the I2RS architecture I2RS clients attempting to write a particular piece of data, the I2RS
[RFC7921] provides the concept of each I2RS client having a priority. architecture [RFC7921] provides the concept of each I2RS client
The I2RS client with the highest priority will have its write having a priority. The I2RS client with the highest priority will
succeed. This document specifies requirements for this new concept have its write succeed. This document specifies requirements for
of priority. this new concept of priority (see Section 4.3).
The opaque secondary identifier identifies an application which is The opaque secondary identifier identifies an application that uses
using the I2RS client to I2RS agent communication to manage the communication from the I2RS client to I2RS agent 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 identifiable personal information.
The last new feature related to I2RS security is the ability to allow The last new feature related to I2RS security is the ability to allow
non-confidential data to be transferred over a non-secure transport. nonconfidential data to be transferred over a non-secure transport.
It is expected that most I2RS data models will describe information It is expected that most I2RS data models will describe information
that will be transferred with confidentiality. Therefore, any model that will be transferred with confidentiality. Therefore, any model
which transfers data over a non-secure transport is marked. The use that transfers data over a non-secure transport is marked. The use
of a non-secure transport is optional, and an implementer SHOULD of a non-secure transport is optional, and an implementer SHOULD
create knobs that allow data marked as non-confidential to be sent create knobs that allow data marked as nonconfidential to be sent
over a secure transport. over a secure transport.
Non-confidential data can only be read or notification scope Nonconfidential data can only be data with read-scope or
transmission of events. Non-confidential data cannot be write scope notification-scope transmission of events. Nonconfidential data
or notification scope configuration. An example of non-confidential cannot have write-scope or notification-scope configuration.
data is the telemetry information that is publically known (e.g. BGP Examples of nonconfidential data would be the telemetry information
route-views data or web site status data) or some legacy data (e.g. that is publicly known (e.g., BGP route-views data or website status
interface) which cannot be transported in secure transport. The IETF data) or some legacy data (e.g., interface) that cannot be
I2RS Data models MUST indicate in the data model the specific data transported using secure transport. The IETF I2RS data models MUST
which is non-confidential. indicate (in the model) the specific data that is nonconfidential.
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. 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 Figure 1 provides a partial list of the candidate management
protocols and the secure transports each one of the support. One protocols. It also lists the secure transports each protocol
column in the table indicates the transport protocol will need I2RS supports. The column on the right of the table indicates whether or
security extensions. not the transport protocol will need I2RS security extensions.
Mangement Management I2RS Security
Protocol Transport Protocol I2RS Extensions Protocol Transport Protocol Extensions
========= ===================== ================= ========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2) NETCONF TLS over TCP (*1) None required (*2)
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 over SCTP Needs extension to ForCES TML over SCTP Needs an extension to
(*1) TML to run TML over (*1) TML to run TML over
TLS over SCTP, or TLS over SCTP, or
DTLS with options for DTLS with options for
replay protection replay protection
and anti-DoS stateless and anti-DoS stateless
cookie mechanism. cookie mechanism.
(DTLS record size (DTLS record size
negotiation and conveyance negotiation and conveyance
of "don't" fragment of DF bits are optional).
bits are optional). The IPsec mechanism is
The IPSEC mechanism is not sufficient for
not sufficient for I2RS traveling over
I2RS traveling over multiple hops
multiple hops (router + link) (*2)
(router + link) (*2)
IPFIX SCTP, TCP, UDP Needs to extension IPFIX SCTP, TCP, UDP Needs an extension
TLS or DTLS for to support TLS or TLS or DTLS for to support TLS or DTLS with
secure client (*1) DTLS with options for secure client (*1) options for replay protection
replay protection and anti-DoS stateless
and anti-DoS stateless cookie mechanism.
cookie mechanism. (DTLS record size
(DTLS record size negotiation and conveyance
negotiation and conveyance of DF bits are optional)
of "don't" fragment
bits are optional).
*1 - Key management protocols *1 - Key management protocols MUST support appropriate key
MUST support appropriate key rotation. rotation.
*2 - Identity and Role authorization distributed *2 - Identity and role authorization distributed by Diameter or
by Diameter or Radius MUST use Diameter over TLS Radius MUST use Diameter over TLS or Radius over TLS.
or Radius over TLS.
Figure 1: Candidate Management Protocols and Their Secure Transports
4. Security-Related Requirements 4. Security-Related Requirements
This section discusses security requirements based on the following This section discusses security requirements based on the following
security functions: security functions:
o peer identity authentication (section 4.1), o peer identity authentication (Section 4.1)
o Peer Identity validation before Role-based Message Actions o Peer Identity validation before role-based message actions
(section 4.2) (Section 4.2)
o peer identity and client redundancy (section 4.3), o peer identity and client redundancy (Section 4.3)
o multi-channel transport requirements: Secure transport and o multi-channel transport requirements: Secure transport and non-
insecure Transport (section 4.4), secure Transport (Section 4.4)
o management protocol security requirements (section 4.5), o management protocol security requirements (Section 4.5)
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 non-secure transport can only be used for a
restricted set of publically data available (events or information) restricted set of data available publicly (events or information) or
or a select set of legacy data. Data passed over the insecure a select set of legacy data. Data passed over the non-secure
transport channel MUST NOT contain any data which identifies a transport channel MUST NOT contain any data that identifies a person.
person.
4.1. I2RS Peers(agent and client) Identity Authentication 4.1. I2RS Peer (Agent and Client) Identity Authentication
The following requirements specify the security requirements for Peer Requirements:
Identity Authentication for the I2RS protocol:
o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an SEC-REQ-01: All I2RS clients and agents MUST have an identity and
identity, and at least one unique identifier that uniquely at least one unique identifier for each party in the I2RS protocol
identifies each party in the I2RS protocol context. context.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 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 agent.
o SEC-REQ-03: Identifier distribution and the loading of these SEC-REQ-03: Identifier distribution and the loading of these
identifiers into I2RS agent and I2RS client SHOULD occur outside identifiers into the I2RS agent and client SHOULD occur outside
the I2RS protocol prior to the I2RS protocol establishing a the I2RS protocol prior to the I2RS protocol establishing a
connection between I2RS client and I2RS agent. AAA protocols MAY connection between I2RS client and agent. AAA protocols MAY be
be used to distribute these identifiers, but other mechanism can used to distribute these identifiers, but other mechanism can be
be used. used.
Explanation: Explanation:
These requirements specify the requirements for I2RS peer (I2RS agent These requirements are for I2RS peer (I2RS agent and client)
and I2RS client) authentication. A secure transport (E.g. TLS) will authentication. A secure transport (e.g., TLS) will authenticate
authenticate based on these identities, but these identities are based on these identities, but these identities are for the I2RS
identities for the I2RS management layer. An AAA protocol management layer. A AAA protocol distributing I2RS identity
distributing I2RS identity information SHOULD transport its information SHOULD transport its information over a secure transport.
information over a secure transport.
4.2. Identity Validation Before Role-Based Message Actions 4.2. Identity Validation before Role-Based Message Actions
The requirements for I2RS clients with Secure Connections are the Requirements:
following:
SEC-REQ-04: An I2RS agent receiving a request from an I2RS client SEC-REQ-04: An I2RS agent receiving a request from an I2RS client
MUST confirm that the I2RS client has a valid identity. MUST confirm that the I2RS client has a valid identity.
SEC-REQ-05: An I2RS client receiving an I2RS message over a secure SEC-REQ-05: An I2RS client receiving an I2RS message over a secure
transport MUST confirm that the I2RS agent has a valid identifier. transport MUST confirm that the I2RS agent has a valid identifier.
SEC-REQ-06: An I2RS agent receiving an I2RS message over an SEC-REQ-06: An I2RS agent receiving an I2RS message over a non-
insecure transport MUST confirm that the content is suitable for secure transport MUST confirm that the content is suitable for
transfer over such a transport. transfer over such a transport.
Explanation: Explanation:
Each I2RS client has a scope based on its identity and the security Each I2RS client has a scope based on its identity and the security
roles (read, write, or events) associated with that identity, and roles (read, write, or events) associated with that identity, and
that scope must be considered in processing an I2RS messages sent on that scope must be considered in processing an I2RS message sent on a
a communication channel. An I2RS communication channel may utilize communication channel. An I2RS communication channel may utilize
multiple transport sessions, or establish a transport session and multiple transport sessions or establish a transport session and then
then close the transport session. Therefore, it is important that close the transport session. Therefore, it is important that the
the I2RS peers are operating utilizing valid peer identities when a I2RS peers operate utilizing valid peer identities when a message is
message is processed rather than checking if a transport session processed rather than checking if a transport session exists.
exists.
During the time period when a secure transport session is active, the During the time period when a secure transport session is active, the
I2RS agent SHOULD assume that the I2RS client's identity remains I2RS agent SHOULD assume that the I2RS client's identity remains
valid. Similarly, while a secure connection exists that included valid. Similarly, while a secure connection exists that included
validating the I2RS agent's identity and a message is received via validating the I2RS agent's identity and a message is received via
that connection, the I2RS client SHOULD assume that the I2RS agent's that connection, the I2RS client SHOULD assume that the I2RS agent's
identity remains valid. identity remains valid.
The definition of what constitutes a valid identity or a valid The definition of what constitutes a valid identity or a valid
identifier MUST be defined by the I2RS protocol. identifier MUST be defined by the I2RS protocol.
4.3. Peer Identity, Priority, and Client Redundancy 4.3. Peer Identity, Priority, and Client Redundancy
Requirements: Requirements:
SEC-REQ-07: Each I2RS Identifier MUST be associated with just one SEC-REQ-07: Each I2RS identifier MUST be associated with just one
priority. priority.
SEC-REQ-08: Each Identifier is associated with one secondary SEC-REQ-08: 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.
Explanation: Explanation:
The I2RS architecture also allows multiple I2RS clients with unique The I2RS architecture also allows multiple I2RS clients with unique
identities to connect to an I2RS agent (section 7.8). The I2RS identities to connect to an I2RS agent (see Section 7.8 of
deployment using multiple clients SHOULD coordinate this multi-headed [RFC7921]). The I2RS deployment using multiple clients SHOULD
control of I2RS agents by I2RS clients so no conflict occurs in the coordinate this multi-headed control of I2RS agents by I2RS clients
write scope. However, in the case of conflict on a write scope so no conflict occurs in the write scope. However, in the case of
variable, the error resolution mechanisms defined by the I2RS conflict on a write-scope variable, the error resolution mechanisms
architecture multi-headed control ([RFC7921], section 7.8) allow the defined by the I2RS architecture multi-headed control (Section 7.8 of
I2RS agent to deterministically choose one I2RS client. The I2RS [RFC7921]) allow the I2RS agent to deterministically choose one I2RS
client with highest priority is given permission to write the client. The I2RS client with highest priority is given permission to
variable, and the second client receives an error message. write the 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. The application using the communication from I2RS client to agent. The
I2RS client is trusted to simply assert the secondary identifier. 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 allows operators to makes emergency changes to routers in
emergency changes to routers in the network. Both of these the network. Both of these applications use the same I2RS client to
applications use the same I2RS client to write to an I2RS agent. In write to an I2RS agent. In order for traceability to determine which
order for traceability to determine which application (weekly application (weekly configuration or emergency) wrote some
configuration or emergency) wrote some configuration changes to a configuration changes to a router, the I2RS client sends a different
router, the I2RS client sends a different opaque value for each of opaque value for each of the applications. The weekly configuration
the applications. The weekly configuration secondary opaque value secondary opaque value could be "xzzy-splot" and the emergency
could be "xzzy-splot" and the emergency secondary opaque value could secondary opaque value could be "splish-splash".
be "splish-splash".
A second example is if the I2RS client is used for monitoring of A second example is if the I2RS client is used for the monitoring of
critical infrastructure. The operator of a network using the I2RS critical infrastructure. The operator of a network using the I2RS
client may desire I2RS client redundancy where the monitoring client may desire I2RS client redundancy where the monitoring
application wth the I2RS client is deployed on two different boxes application with the I2RS client is deployed on two different boxes
with the same I2RS client identity (see [RFC7921] section 4.3) These with the same I2RS client identity (see Section 4.3 of [RFC7921]).
two monitoring applications pass to the I2RS client whether the These two monitoring applications pass to the I2RS client whether the
application is the primary or back up application, and the I2RS application is the primary or back-up application, and the I2RS
client passes this information in the I2RS secondary identitifier as client passes this information in the I2RS secondary identifier, as
the figure below shows. The primary applications secondary the figure below shows. The primary application's secondary
identifier is "primary-monitoring", and the backup application identifier is "primary-monitoring", and the back-up application
secondary identifier is "backup-monitoring". The I2RS tracing secondary identifier is "backup-monitoring". The I2RS tracing
information will include the secondary identifier information along information will include the secondary identifier information along
with the transport information in the tracing file in the agent. with the transport information in the tracing file in the agent.
Example 2: Primary and Backup Application for Monitoring
Identification sent to agent
Application A--I2RS client--Secure transport(#1) Application A--I2RS client--Secure transport(#1)
[I2RS identity 1, secondary identifier: "primary-monitoring"]--> [I2RS identity 1, secondary identifier: "primary-monitoring"]-->
Application B--I2RS client--Secure transport(#2) Application B--I2RS client--Secure transport(#2)
[I2RS identity 1, secondary identifier: "backup-monitoring"]--> [I2RS identity 1, secondary identifier: "backup-monitoring"]-->
Figure 1 Figure 2: Primary and Back-Up Application for Monitoring
Identification Sent to Agent
4.4. Multi-Channel Transport: Secure Transport and Insecure Transport 4.4. Multi-Channel Transport: Secure and Non-Secure
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 secure transport is mandatory to implement transport, and this secure transport is mandatory to implement in
(MTI) in all I2RS agents, and in any I2RS client which: a) all I2RS agents and in any I2RS client that a) performs a write
performs a Write scope transaction which is sent to the I2RS agent scope transaction that is sent to the I2RS agent or b) configures
or b): configures an Event Scope transaction. This secure an Event Scope transaction. This secure transport is mandatory to
transport is mandatory to use (MTU) on any I2RS client's Write use on any I2RS client's Write transaction or the configuration of
transaction or the configuration of an Event Scope transaction. 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 SHOULD implement
implement mechanisms that mitigate DoS attacks. For the secure mechanisms that mitigate DoS attacks. This means the secure
transport, this means the secure transport must support DoS transport must support DoS prevention. For the non-secure
prevention. For the insecure transport protocol, the I2RS higher- transport, the I2RS higher-layer protocol MUST contain a transport
layer protocol MUST contain a transport management layer that management layer that considers the detection of DoS attacks and
considers the detection of DoS attacks and provides a warning over provides a warning over a secure transport channel.
a secure-transport channel.
SEC-REQ-12: A secure transport MUST be associated with a key SEC-REQ-12: A secure transport MUST be associated with a key
management solution that can guarantee that only the entities management solution that can guarantee that only the entities
having sufficient privileges can get the keys to encrypt/decrypt having sufficient privileges can get the keys to encrypt/decrypt
the sensitive data. the sensitive data.
SEC-REQ-13: A machine-readable mechanism to indicate that a data- SEC-REQ-13: A machine-readable mechanism to indicate that a data
model contains non-confidential data MUST be provided. A non- model contains nonconfidential data MUST be provided. A non-
secure transport MAY be used to publish only read scope or secure transport MAY be used to publish only read-scope or
notification scope data if the associated data model indicates notification-scope data if the associated data model indicates
that that data is non-confidential. that the data in question is nonconfidential.
SEC-REQ-14: The I2RS protocol MUST be able to support multiple SEC-REQ-14: The I2RS protocol MUST be able to support multiple
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 client. However, a single
a single I2RS agent to I2RS client connection MAY elect to use a connection between I2RS agent and client MAY elect to use a single
single secure transport session or a single non-secure transport secure transport session or a single non-secure transport session
session conforming the requirements above. conforming to 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 "nonconfidential" 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 SEC-REQ-16: The I2RS protocol makes use of both secure and non-
insecure transports, but this use MUST NOT be done in any way that secure transports, but this use MUST NOT be done in any way that
weakens the secure transport protocol used in the I2RS protocol or weakens the secure transport protocol used in the I2RS protocol or
other contexts that do not have this requirement for mixing secure other contexts that do not have this requirement for mixing secure
and insecure modes of operation. and non-secure 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. Non-secure data can only be used for read and
and notification scope of "non-confidential data". The configuration notification scopes of "nonconfidential data". The configuration of
of ephemeral data in the I2RS agent uses either write scope for data ephemeral data in the I2RS agent uses write scope either for data or
or write scope for configuration of event notification streams. The for configuration of event notification streams. The requirement to
requirement to use secure transport for configuration prevents use secure transport for configuration prevents accidental or
accidental or malevolent entities from altering the I2RS routing malevolent entities from altering the I2RS routing system through the
system through the I2RS agent. I2RS agent.
It is anticipated that the passing of most I2RS ephemeral state It is anticipated that the passing of most I2RS ephemeral state
operational status SHOULD be done over a secure transport. operational statuses SHOULD be done over a secure transport.
In most circumstances the secure transport protocol will be In most circumstances, the secure transport protocol will be
associated with a key management system. Most deployments of the associated with a key management system. Most deployments of the
I2RS protocol will allow for automatic key management systems. Since I2RS protocol will allow for automatic key management systems. Since
the data models for the I2RS protocol will control key routing the data models for the I2RS protocol will control key routing
functions, it is important that deployments of I2RS use automatic key functions, it is important that deployments of I2RS use automatic key
management systems. management systems.
Per BCP107 [RFC4107] while key management system SHOULD be automatic, Per BCP 107 [RFC4107], while key management systems SHOULD be
the systems MAY be manual in the following scenarios: automatic, the systems 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.
c) The total volume of traffic over the entire lifetime of the c) The total volume of traffic over the entire lifetime of the long-
long-term session key will be very low. term session key will be very low.
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 in the long term.
4.5. Management Protocol Security 4.5. Management Protocol Security
Requirements: Requirements:
SEC-REQ-17: 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 they SHOULD provide access-control functions to
confidentiality of the data. protect confidentiality of the data.
SEC-REQ-18: 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
higher layer protocol (best effort). 3) the data is not repeated from some earlier interaction the
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 a non-secure transport SHOULD provide some way for the client
receiving non-confidential read-scoped or event-scoped data over receiving nonconfidential read-scoped or event-scoped data over
the insecure connection to detect when the data integrity is the non-secure 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 non-secure transport
connection. connection.
SEC-REQ-19: 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 to be known by hackers or their competitors. While
share peering information, most carriers do not share configuration carriers may share peering information, most carriers do not share
and traffic statistics. To achieve this, the I2RS higher-layer configuration and traffic statistics. To achieve this, the I2RS
protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for higher-layer protocol (e.g., NETCONF) requires access control
sensitive data needs to be provided; and the confidentiality (NETCONF Access Control Model [RFC6536]) for sensitive data needs to
protection on such data during transportation needs to be enforced. be provided; and the confidentiality 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 nonconfidential data over a non-secure 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. Contextual checks on transactions on a secure or non-secure transport. Contextual checks
specific non-confidential data sent over a insecure connection may on specific nonconfidential data sent over a non-secure connection
indicate the data has been modified. may indicate the data has been modified.
4.6. Role-Based Data Model Security 4.6. Role-Based Data Model Security
The I2RS Architecture [RFC7921] specifies access control by "role" In order to make access control more manageable, the I2RS
where role is a method of making access control more manageable by architecture [RFC7921] specifies a "role" to categorize users into a
creating a grouping of users so that access control can be specified group (rather than handling them individually) for access-control
for a role rather than for each of the individuals. Therefore, I2RS purposes (role-based access control). Therefore, an I2RS role
role specifies the access control for a group as being read, write, specifies the access control for a group as being read, write, or
or notification. notification.
SEC-REQ-20: 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-21: 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 agent as
as the I2RS architecture [RFC7921] describes. the I2RS architecture [RFC7921] describes.
Sec-REQ-22: If an I2RS agents or an I2RS client is tightly Sec-REQ-22: If an I2RS agent or client is tightly correlated with
correlated with a person, then the I2RS protocol and data models a person, then the I2RS protocol and data models SHOULD provide
SHOULD provide additional security that protects the person's additional security that protects the person's privacy.
privacy.
Explanation: Explanation:
I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF) An I2RS higher-layer protocol uses a management protocol (e.g.,
to pass messages in order to enact I2RS transactions. Role Security NETCONF, RESTCONF) to pass messages in order to enact I2RS
must secure data (sensitivity and normal data) in a router even when transactions. Role security must secure data (sensitive and normal
it is operating over multiple connections at the same time. NETCONF data) in a router even when it is operating over multiple connections
can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP at the same time. NETCONF can run over TLS (over TCP or SCTP) or
over a secure transport (TLS). SCTP [RFC4960] provides security for SSH. RESTCONF runs over HTTP over a secure transport (TLS). SCTP
multiple streams plus end-to-end transport of data. Some I2RS [RFC4960] provides security for multiple streams plus end-to-end
functions may wish to operate over DTLS which runs over UDP transport of data. Some I2RS functions may wish to operate over DTLS
([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]). [RFC6347], which runs over UDP ([RFC768]) and SCTP ([RFC5764]).
Please note the security of the application to I2RS client connection Please note the security of the connection between application and
is outside of the I2RS protocol or I2RS interface. I2RS client is outside of the I2RS protocol or I2RS interface.
While I2RS clients are expected to be related to network devices and While I2RS clients are expected to be related to network devices and
not individual people, if an I2RS client ran on a person's phone, not individual people, if an I2RS client ran on a person's phone,
then privacy protection to anonymize any data relating to a person's then privacy protection to anonymize any data relating to a person's
identity or location would be needed. identity or location would be needed.
A variety of forms of managemen may set policy on roles: "operator- A variety of forms of management may set policy on roles: "operator-
applied knobs", roles that restrict personal access, data-models with applied knobs", roles that restrict personal access, data models with
specific "privacy roles", and access filters. specific "privacy roles", and access filters.
4.7. Security of the environment 4.7. Security of the Environment
The security for the implementation of a protocol also considers the The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are protocol environment. Implementers should review the summary of the
found in: [I-D.ietf-i2rs-security-environment-reqs]. I2RS security environment in [RFC7921].
5. Security Considerations
This is a document about security requirements for the I2RS protocol
and data modules. Security considerations for the I2RS protocol
include both the protocol and the security environment.
6. IANA Considerations
This draft is requirements, and does not request anything of IANA. 5. IANA Considerations
7. Acknowledgement This document does not require any IANA actions.
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 6. Security Considerations
Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia
Atlas, and Jeff Haas for their contributions to the I2RS security
requirements discussion and this document. The authors would like to
thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia
Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their
review of these requirements.
8. References This is a document about security requirements for the I2RS protocol
and data models. Security considerations for the I2RS protocol
include both the protocol and the security environment.
8.1. Normative References 7. References
[I-D.ietf-i2rs-security-environment-reqs] 7.1. Normative References
Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016.
[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>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[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>.
8.2. Informative References
[I-D.ietf-i2rs-ephemeral-state] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Haas, J. and S. Hares, "I2RS Ephemeral State 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in May 2017, <https://www.rfc-editor.org/info/rfc8174>.
progress), September 2016.
[I-D.ietf-netconf-restconf] 7.2. Informative References
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-17 (work in
progress), September 2016.
[I-D.ietf-taps-transports] [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services DOI 10.17487/RFC0768, August 1980,
provided by IETF transport protocols and congestion <https://www.rfc-editor.org/info/rfc768>.
control mechanisms", draft-ietf-taps-transports-11 (work
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>. <https://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>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
Time-Based One-Time Password Algorithm", RFC 6238,
DOI 10.17487/RFC6238, May 2011,
<http://www.rfc-editor.org/info/rfc6238>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012, RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>. <https://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Statement for the Interface to the Routing System", Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
RFC 7920, DOI 10.17487/RFC7920, June 2016, <https://www.rfc-editor.org/info/rfc8040>.
<http://www.rfc-editor.org/info/rfc7920>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>.
[RFC8242] Haas, J. and S. Hares, "Interface to the Routing System
(I2RS) Ephemeral State Requirements", RFC 8242,
DOI 10.17487/RFC8242, September 2017,
<http://www.rfc-editor.org/info/rfc8242>.
Acknowledgements
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Alia
Atlas, and Jeff Haas for their contributions to the I2RS security
requirements discussion and this document. The authors would like to
thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia
Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their
review of these requirements.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA United States of America
Email: shares@ndzh.com Email: shares@ndzh.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8275 Trans Canada Route
Montreal, QC HAP 2N2 Saint Laurent, QC H4S
Canada Canada
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
Joel Halpern Joel Halpern
Ericsson Ericsson
US United States of America
Email: joel.halpern@ericsson.com Email: joel.halpern@ericsson.com
 End of changes. 174 change blocks. 
530 lines changed or deleted 488 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/