wdiff rfc8241.original rfc8241.txt

I2RS working group
Internet Engineering Task Force (IETF) S. Hares
Internet-Draft
Request for Comments: 8241 Huawei
Intended status:
Category: Informational D. Migault
Expires: April 2, 2017
ISSN: 2070-1721 J. Halpern
Ericsson
September 29, 2016

I2RS Security Related 2017

Interface to the Routing System (I2RS) Security-Related Requirements
draft-ietf-i2rs-protocol-security-requirements-17

Abstract

This document presents security-related requirements for the I2RS protocol
Interface to the Routing System (I2RS) protocol, which provides a new
interface to the routing system described in the I2RS architecture
document (RFC7921). (RFC 7921). The I2RS protocol is a re-use
protocol implemented by re-using reusing
portions of existing IETF protocols and adding new features to these protocols. The I2RS protocol re-
uses them.
One such reuse is of the security features of a secure transport (E.g. TLS, SSH, DTLS)
(e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol,
Datagram TLS (DTLS)) such as encryption, message integrity, mutual
peer authentication, and replay anti-replay protection. The new I2RS
features to consider from a security perspective are: are as follows: a
priority mechanism to handle multi-headed write transactions, an
opaque secondary identifier which that identifies an application using the
I2RS client, and an extremely constrained read-only non-secure
transport. This document provides the detailed
requirements for these security features.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 2, 2017.
https://www.rfc-editor.org/info/rfc8241.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 ....................................................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 Terminology and Concepts ........................................4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 ......................................4
2.2. Security Definitions . . . . . . . . . . . . . . . . . . 4 Terminology .......................................4
2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 I2RS-Specific Terminology ..................................5
2.4. Concepts ...................................................5
3. Security Features and Protocols: Re-used Reused and New . . . . . . 7 .................6
3.1. Security Protocols Re-Used Reused by the I2RS Protocol . . . . . 7 .............6
3.2. New Features Related to Security . . . . . . . . . . . . 8 ...........................7
3.3. I2RS Protocol Security Requirements vs. IETF
Management Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 .......................................8
4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 ..................................10
4.1. I2RS Peers(agent Peer (Agent and client) Client) Identity Authentication . . 10 ......10
4.2. Identity Validation Before before Role-Based Message Actions . . 11 .....11
4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 ............12
4.4. Multi-Channel Transport: Secure Transport and Insecure
Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 Non-Secure ............13
4.5. Management Protocol Security . . . . . . . . . . . . . . 15 ..............................15
4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16 ............................16
4.7. Security of the environment . . . . . . . . . . . . . . . 17 Environment ...............................17
5. Security IANA Considerations . . . . . . . . . . . . . . . . . . . 17 ............................................17
6. IANA Security Considerations . . . . . . . . . . . . . . . . . . . . . 18 ........................................17
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. .....................................................17
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. ......................................17
7.2. Informative References . . . . . . . . . . . . . . . . . 19 ....................................18
Acknowledgements ..................................................20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 ................................................20

1. Introduction

The Interface to the Routing System (I2RS) protocol provides read and
write access to information and state within the routing system. An
I2RS client interacts with one or more I2RS agents to collect
information from network routing systems. [RFC7921] describes the
architecture of this interface, and this documents document assumes the reader
is familiar with this architecture and its definitions. Section 2 highlights
some of the references the reader is required to be familiar with.

The I2RS interface is instantiated by the I2RS protocol connecting an
I2RS client and an I2RS agent associated with a routing system. The
I2RS protocol is a re-use protocol implemented by re-using reusing portions of existing IETF protocols,
protocols and adding new features to these
protocols. them. As a re-use reuse protocol, it
can be considered a higher-level higher-layer protocol since because it can be
instantiated in multiple management protocols (e.g. (e.g., NETCONF
[RFC6241] or RESTCONF
[I-D.ietf-netconf-restconf]) [RFC8040]) operating over a secure transport. The
security for the I2RS protocol comes from the management
These protocols
operating over a a secure transport. are what provide its security.

This document is part of the a suite of documents outlining requirements
for the I2RS protocol protocol, which also include: includes the following:

o I2RS architecture [RFC7921], "An Architecture for the Interface to the Routing System"
[RFC7921]

o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], "I2RS Ephemeral State Requirements" [RFC8242]

o publication/subscription requirements [RFC7922], "Interface to the Routing System (I2RS) Traceability: Framework
and Information Model" (which discusses traceability) [RFC7923]

o traceability [RFC7923]. "Requirements for Subscription to YANG Datastores" (which
highlights the publication/subscription requirements) [RFC7922]

Since the I2RS "higher-level" "higher-layer" protocol changes the interface to the
routing systems, it is important that implementers understand the new
security requirements for the environment the I2RS protocol operates
in. These security requirements for the I2RS environment are
specified in [I-D.ietf-i2rs-security-environment-reqs]; and the A summary of the I2RS protocol security environment is found in
the I2RS Architecture [RFC7920]. architecture [RFC7921].

I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which that
support encryption, message integrity, peer authentication, and key
distribution protocols. Optionally, implementers may utilize AAA
Authentication, Authorization, and Accounting (AAA) protocols (Radius
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
being re-used (section 3.1) and reused (Section 3.1), lists the new security features being
required (section 3.2). Section 3 also (Section 3.2), and explores how existing and new security
features and protocols would be paired with existing IETF management
protocols (section (Section 3.3).

The new features I2RS extends to these protocols are a priority
mechanism to handle multi-headed writes, an opaque secondary
identifier to allow traceability of an application utilizing a
specific I2RS client to communicate with an I2RS agent, and insecure non-
secure transport constrained to be utilized used only for read-only data,
which may include publically publicly available data (e.g. (e.g., public BGP Events, events,
public telemetry information, web service availability) and some
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 of several
security environment (section 4.7) features. Protocols designed to be I2RS higher-layer
protocols need to fulfill these security requirements.

2. Definitions Terminology and Concepts

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2.2. Security Definitions Terminology

This document utilizes uses the definitions terminology found in the following
documents: [RFC4949] and [RFC7921] [RFC7921].
Specifically, this document utilizes reuses the following definitions terms from
[RFC4949]:

o access control, control
o authentication, authentication
o data confidentiality, confidentiality
o data integrity, integrity
o data privacy, privacy
o identity, identity
o identifier, identifier
o mutual authentication, authentication
o role, role
o role-based access control, control
o security audit trail, and trail
o trust. trust
[RFC7922] describes traceability for the I2RS interface and the I2RS
protocol. Traceability is not equivalent to a security audit trail
or simple logging of information. A security audit trail may utilize
traceability information.

This document also requires that the user is familiar with the
pervasive security requirements in [RFC7258].

2.3. I2RS Specific Definitions

The document utilizes the following concepts from the I2RS
architecture: [RFC7921]:

o I2RS client, I2RS agent, and I2RS protocol (section 2),

o I2RS higher-layer protocol (section 7.2)

o scope: read scope, notification scope, and write scope (section
2),

o identity and scope of the identity (section 2),
o roles or security rules (section 2),

o identity and scope, and secondary identity (section 2),

o routing system/subsytem (section 2),

o I2RS assumed security environment (section 4),

o I2RS identity and authorization (section 4.1),

o I2RS authorization, scope of Authorization in I2RS client and
agent (section 4.2),

o client redundancy with a single client identity (section 4.3),

o restrictions on I2RS in personal devices (section 4.4),

o communication channels and I2RS high-layer protocol (section 7.2),

o active communication versus connectivity (section 7.5),

o multi-headed control (section 7.8), and

o transaction, message, multi-message atomicity (section 7.9).

This document assumes the reader is familar with these terms. I2RS-Specific Terminology

This document discusses the security of the multiple I2RS
communication channels which that operate over the higher-layer I2RS
protocol. The higher-layer I2RS protocol combines a secure transport
and I2RS contextual information, and re-uses it reuses IETF protocols and
data models to create the secure transport and the I2RS data-model driven contextual information.
information driven by the I2RS data model. To describe how the I2RS high-layer
higher-layer protocol combines other protocols into the I2RS higher-layer protocol, protocols, the following terms
are used:

I2RS component protocols

Protocols which that are re-used reused and combined to create the I2RS higher-
layer protocol.

I2RS secure-transport secure transport component protocols

The I2RS secure (required)

Secure transport protocols that combine to support the I2RS higher-
layer
higher-layer protocol.

I2RS management component protocols
The I2RS management protocol which (required)

Management protocols that combine to provide the management management-
information context. context for the I@RS higher-layer protocol.

I2RS AAA component protocols

The I2RS (optional)

AAA protocols supporting the I2RS higher-layer protocol.

2.4. Concepts

The reader should be familiar with the pervasive security
requirements in [RFC7258].

This document uses the following concepts from the I2RS architecture
[RFC7921] listed below with their respective section numbers from
said RFC:

o I2RS client, agent, and protocol (Section 2)

o I2RS higher-layer protocol requires implementation (Section 7.2)
o scope: read, notification, identity, and write (Section 2)

o identity and secondary identity (Section 2)

o roles or security rules (Section 2)

o routing system/subsystem (Section 2)

o I2RS assumed security environment (Section 4)

o I2RS identity and authentication (Section 4.1)

o scope of a Authorization in I2RS
secure-transport component protocol client and the agent (Section 4.2)

o client redundancy with a single client identity (Section 4.3),

o restrictions on I2RS management component
protocol. The in personal devices (Section 4.4)

o communication channels and I2RS AAA component higher-layer protocol is optional.
(Section 7.2)

o active communication versus connectivity (Section 7.5)

o multi-headed control (Section 7.8)

o transaction, message, multi-message atomicity (Section 7.9)

3. Security Features and Protocols: Re-used Reused and New

3.1. Security Protocols Re-Used Reused by the I2RS Protocol

I2RS requires a secure transport protocol and key distribution
protocols. The secure transport for I2RS requires one to provide
peer authentication. In addition, the features required by for I2RS
messages are peer
authentication, confidentiality, data integrity, authentication, and replay
protection for I2RS messages. protection.
According to
[I-D.ietf-taps-transports], [RFC8095], the secure transport protocols which that support
peer authentication, confidentiality, data integrity, and replay
protection are the following:

1. TLS [RFC5246] over TCP or SCTP, Stream Control Transmission Protocol
(SCTP)

2. DTLS over UDP with replay detection and an anti-DoS stateless
cookie mechanism required for the I2RS protocol, protocol and the I2RS protocol
allow DTLS
options of record size record-size negotiation and and conveyance of "don't" fragment bits the Don't
Fragment (DF) bit are set for IPv4, or no fragmentation extension
headers for IPv6 to be optional in deployments. deployments are allowed by the
I2RS protocol
3. HTTP over TLS (over TCP or SCTP), and SCTP)

4. HTTP over DTLS (with the requirements and optional features
specified above in item 2).

The 2)

As detailed in Section 3.3, the following protocols would need to be
extended to provide confidentiality, data integrity, peer
authentication, and key distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML
layer (over SCTP). These protocols will need extensions to run over a secure
transport (TLS or DTLS) (see section 3.3 for details). DTLS):

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
transport uses depends on the transport. Key management protocols
utilized for the I2RS protocols SHOULD support automatic rotation.

An I2RS implementer may use AAA protocols over secure transport to
distribute the identities for the I2RS client and client, I2RS agent agent, and role role-
authorization information. Two AAA protocols are: are as follows:
Diameter [RFC6733] and Radius [RFC2865]. To provide the best security I2RS peer
identities,
identities with the best security, the AAA protocols MUST be run over
a secure transport (Diameter over secure transport (TLS over TCP)
[RFC6733]), Radius over a secure transport (TLS) [RFC6614]).

3.2. New Features Related to Security

The new features are priority, an opaque secondary identifier, and an
insecure a
non-secure protocol for read-only data constrained to specific
standard usages. The I2RS protocol allows multi-headed control by
several I2RS clients. This multi-headed control is based on the
assumption that the operator deploying the I2RS clients, I2RS agents,
and the
I2rs I2RS protocol will coordinate the read, write, and
notification scope so the I2RS clients will not contend for the same
write scope. However, just in case there is an unforseen unforeseen overlap of
I2RS clients attempting to write a particular piece of data, the I2RS
architecture [RFC7921] provides the concept of each I2RS client
having a priority. The I2RS client with the highest priority will
have its write succeed. This document specifies requirements for
this new concept of priority. priority (see Section 4.3).

The opaque secondary identifier identifies an application which is
using that uses
communication from the I2RS client to I2RS agent communication to manage the
routing system. The secondary identifier is opaque to the I2RS
protocol. In order to protect personal privacy, the secondary
identifier should not contain personal identifiable personal information.

The last new feature related to I2RS security is the ability to allow
non-confidential
nonconfidential data to be transferred over a non-secure transport.
It is expected that most I2RS data models will describe information
that will be transferred with confidentiality. Therefore, any model
which
that transfers data over a non-secure transport is marked. The use
of a non-secure transport is optional, and an implementer SHOULD
create knobs that allow data marked as non-confidential nonconfidential to be sent
over a secure transport.

Non-confidential

Nonconfidential data can only be read data with read-scope or notification scope
notification-scope transmission of events. Non-confidential Nonconfidential data
cannot be write scope have write-scope or notification scope notification-scope configuration. An example
Examples of non-confidential nonconfidential data is would be the telemetry information
that is publically publicly known (e.g. (e.g., BGP route-views data or web site website status
data) or some legacy data (e.g. (e.g., interface) which that cannot be
transported in using secure transport. The IETF I2RS Data data models MUST
indicate in (in the data model model) the specific data
which that is non-confidential. nonconfidential.

Most I2RS data models will expect that the information described in
the model will be transferred with confidentiality.

3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols

Table

Figure 1 below provides a partial list of the candidate management
protocols and
protocols. It also lists the secure transports each one of the support. One protocol
supports. The column in on the right of the table indicates whether or
not the transport protocol will need I2RS security extensions.

Mangement

Management I2RS Security
Protocol Transport Protocol I2RS Extensions
========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2)

RESTCONF HTTP over TLS with None required (*2)
X.509v3 certificates,
certificate validation,
mutual authentication:
1) authenticated
server identity,
2) authenticated
client identity
(*1)

FORCES

ForCES TML over SCTP Needs an extension to
(*1) TML to run TML over
TLS over SCTP, or
DTLS with options for
replay protection
and anti-DoS stateless
cookie mechanism.
(DTLS record size
negotiation and conveyance
of "don't" fragment DF bits are optional).
The IPSEC IPsec mechanism is
not sufficient for
I2RS traveling over
multiple hops
(router + link) (*2)

IPFIX SCTP, TCP, UDP Needs to an extension
TLS or DTLS for to support TLS or DTLS with
secure client (*1) DTLS with options for replay protection
and anti-DoS stateless
cookie mechanism.
(DTLS record size
negotiation and conveyance
of "don't" fragment DF bits are optional). optional)

*1 - Key management protocols MUST support appropriate key
rotation.

*2 - Identity and Role role authorization distributed by Diameter or
Radius MUST use Diameter over TLS or Radius over TLS.

Figure 1: Candidate Management Protocols and Their Secure Transports

4. Security-Related Requirements

This section discusses security requirements based on the following
security functions:

o peer identity authentication (section 4.1), (Section 4.1)

o Peer Identity validation before Role-based Message Actions
(section role-based message actions
(Section 4.2)

o peer identity and client redundancy (section 4.3), (Section 4.3)

o multi-channel transport requirements: Secure transport and
insecure non-
secure Transport (section 4.4), (Section 4.4)

o management protocol security requirements (section 4.5), (Section 4.5)

o role-based security (section 4.6), (Section 4.6)

o security environment (section (Section 4.7)

The I2RS Protocol protocol depends upon a secure transport layer for peer
authentication, data integrity, confidentiality, and replay
protection. The optional insecure non-secure transport can only be used for a
restricted set of publically data available publicly (events or information) or
a select set of legacy data. Data passed over the insecure non-secure
transport channel MUST NOT contain any data which that identifies a person.

4.1. I2RS Peers(agent and client) Identity Authentication

The following requirements specify the security requirements for Peer (Agent and Client) Identity Authentication for the I2RS protocol:

Requirements:

SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
identity, identity and
at least one unique identifier that uniquely
identifies for each party in the I2RS protocol
context.

SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
mutual identification of the I2RS client and I2RS agent.

SEC-REQ-03: Identifier distribution and the loading of these
identifiers into the I2RS agent and I2RS client SHOULD occur outside
the I2RS protocol prior to the I2RS protocol establishing a
connection between I2RS client and I2RS agent. AAA protocols MAY be
used to distribute these identifiers, but other mechanism can be
used.

Explanation:

These requirements specify the requirements are for I2RS peer (I2RS agent and I2RS client)
authentication. A secure transport (E.g. (e.g., TLS) will authenticate
based on these identities, but these identities are
identities for the I2RS
management layer. An A AAA protocol distributing I2RS identity
information SHOULD transport its information over a secure transport.

4.2. Identity Validation Before before Role-Based Message Actions

The requirements for I2RS clients with Secure Connections are the
following:

Requirements:

SEC-REQ-04: An I2RS agent receiving a request from an I2RS client
MUST confirm that the I2RS client has a valid identity.

SEC-REQ-05: An I2RS client receiving an I2RS message over a secure
transport MUST confirm that the I2RS agent has a valid identifier.

SEC-REQ-06: An I2RS agent receiving an I2RS message over an
insecure a non-
secure transport MUST confirm that the content is suitable for
transfer over such a transport.

Explanation:

Each I2RS client has a scope based on its identity and the security
roles (read, write, or events) associated with that identity, and
that scope must be considered in processing an I2RS messages message sent on a
communication channel. An I2RS communication channel may utilize
multiple transport sessions, sessions or establish a transport session and then
close the transport session. Therefore, it is important that the
I2RS peers are operating operate utilizing valid peer identities when a message is
processed rather than checking if a transport session exists.

During the time period when a secure transport session is active, the
I2RS agent SHOULD assume that the I2RS client's identity remains
valid. Similarly, while a secure connection exists that included
validating the I2RS agent's identity and a message is received via
that connection, the I2RS client SHOULD assume that the I2RS agent's
identity remains valid.

The definition of what constitutes a valid identity or a valid
identifier MUST be defined by the I2RS protocol.

4.3. Peer Identity, Priority, and Client Redundancy

Requirements:

SEC-REQ-07: Each I2RS Identifier identifier MUST be associated with just one
priority.

SEC-REQ-08: Each Identifier identifier is associated with one secondary
identifier during a particular I2RS transaction (e.g. (e.g., read/write
sequence), but the secondary identifier may vary during the time a
connection between the I2RS client and I2RS agent is active.

Explanation:

The I2RS architecture also allows multiple I2RS clients with unique
identities to connect to an I2RS agent (section 7.8). (see Section 7.8 of
[RFC7921]). The I2RS deployment using multiple clients SHOULD
coordinate this multi-headed control of I2RS agents by I2RS clients
so no conflict occurs in the write scope. However, in the case of
conflict on a write scope write-scope variable, the error resolution mechanisms
defined by the I2RS architecture multi-headed control ([RFC7921], section 7.8) (Section 7.8 of
[RFC7921]) allow the I2RS agent to deterministically choose one I2RS
client. The I2RS client with highest priority is given permission to
write the variable, and the second client receives an error message.

A single I2RS client may be associated with multiple applications
with different tasks (e.g. (e.g., weekly configurations or emergency
configurations). The secondary identity is an opaque value that the
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
application using the communication from I2RS client to I2RS agent communication. agent. The
I2RS client is trusted to simply assert the secondary identifier.

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
client. The first application is a weekly configuration application
that uses the I2RS protocol to change configurations. The second
application is an application that allows operators to makes emergency changes to routers in
the network. Both of these applications use the same I2RS client to
write to an I2RS agent. In order for traceability to determine which
application (weekly configuration or emergency) wrote some
configuration changes to a router, the I2RS client sends a different
opaque value for each of the applications. The weekly configuration
secondary opaque value could be "xzzy-splot" and the emergency
secondary opaque value could be "splish-splash".

A second example is if the I2RS client is used for the monitoring of
critical infrastructure. The operator of a network using the I2RS
client may desire I2RS client redundancy where the monitoring
application wth with the I2RS client is deployed on two different boxes
with the same I2RS client identity (see [RFC7921] section 4.3) identity (see Section 4.3 of [RFC7921]).
These two monitoring applications pass to the I2RS client whether the
application is the primary or back up back-up application, and the I2RS
client passes this information in the I2RS secondary identitifier identifier, as
the figure below shows. The primary applications application's secondary
identifier is "primary-monitoring", and the backup back-up application
secondary identifier is "backup-monitoring". The I2RS tracing
information will include the secondary identifier information along
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)
[I2RS identity 1, secondary identifier: "primary-monitoring"]-->

Application B--I2RS client--Secure transport(#2)
[I2RS identity 1, secondary identifier: "backup-monitoring"]-->

Figure 1 2: Primary and Back-Up Application for Monitoring
Identification Sent to Agent

4.4. Multi-Channel Transport: Secure Transport and Insecure Transport Non-Secure

Requirements:

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
a non-secure transport. The default transport is a secure
transport, and this secure transport is mandatory to implement
(MTI) in
all I2RS agents, agents and in any I2RS client which: that a) performs a Write write
scope transaction which that is sent to the I2RS agent or b): b) configures
an Event Scope transaction. This secure transport is mandatory to
use (MTU) on any I2RS client's Write transaction or the configuration of
an Event Scope transaction.

SEC-REQ-10: The secure transport MUST provide data
confidentiality, data integrity, and practical replay prevention.

SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD implement
mechanisms that mitigate DoS attacks. For the secure
transport, this This means the secure
transport must support DoS prevention. For the insecure transport protocol, non-secure
transport, the I2RS higher-
layer higher-layer protocol MUST contain a transport
management layer that considers the detection of DoS attacks and
provides a warning over a secure-transport secure transport channel.

SEC-REQ-12: A secure transport MUST be associated with a key
management solution that can guarantee that only the entities
having sufficient privileges can get the keys to encrypt/decrypt
the sensitive data.

SEC-REQ-13: A machine-readable mechanism to indicate that a data- data
model contains non-confidential nonconfidential data MUST be provided. A non-
secure transport MAY be used to publish only read scope read-scope or
notification scope
notification-scope data if the associated data model indicates
that that the data in question is non-confidential. nonconfidential.

SEC-REQ-14: The I2RS protocol MUST be able to support multiple
secure transport sessions providing protocol and data
communication between an I2RS agent and an I2RS client. However, a single
connection between I2RS agent to I2RS and client connection MAY elect to use a single
secure transport session or a single non-secure transport session
conforming to the requirements above.

SEC-REQ-15: Deployment configuration knobs SHOULD be created to
allow operators to send "non-confidential" Read "nonconfidential" read scope (data or
Event
event streams) over a secure transport.

SEC-REQ-16: The I2RS protocol makes use of both secure and
insecure non-
secure 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 non-secure modes of operation.

Explanation:

The I2RS architecture defines three scopes: read, write, and
notification scope. Insecure
notification. Non-secure data can only be used for read scope and
notification scope scopes of "non-confidential "nonconfidential data". The configuration of
ephemeral data in the I2RS agent uses either write scope either for data or write scope
for configuration of event notification streams. The requirement to
use secure transport for configuration prevents accidental or
malevolent entities from altering the I2RS routing system through the
I2RS agent.

It is anticipated that the passing of most I2RS ephemeral state
operational status statuses SHOULD be done over a secure transport.

In most circumstances circumstances, the secure transport protocol will be
associated with a key management system. Most deployments of the
I2RS protocol will allow for automatic key management systems. Since
the data models for the I2RS protocol will control key routing
functions, it is important that deployments of I2RS use automatic key
management systems.

Per BCP107 [RFC4107] BCP 107 [RFC4107], while key management system systems SHOULD be
automatic, the systems MAY be manual in the following scenarios:

a) The environment has limited bandwidth or high round-trip times.

b) The information being protected has low value.

c) The total volume of traffic over the entire lifetime of the
long-term long-
term session key will be very low.

d) The scale of the deployment is limited.

Operators deploying the I2RS protocol selecting manual key management
SHOULD consider both short short- and medium term medium-term plans. Deploying
automatic systems initially may save effort over in the long-term. long term.

4.5. Management Protocol Security

Requirements:

SEC-REQ-17: In a critical infrastructure, certain data within
routing elements is sensitive and read/write operations on such
data SHOULD be controlled in order to protect its confidentiality.
To achieve this, higher-layer protocols MUST utilize a secure
transport, and they SHOULD provide access control access-control functions to
protect confidentiality of the data.

SEC-REQ-18: An integrity protection mechanism for I2RS MUST be
provided that will be able to ensure the following:

1) the data being protected is not modified without detection
during its transportation,

2) the data is actually from where it is expected to come from,
and

3) the data is not repeated from some earlier interaction the
higher layer
higher-layer protocol (best effort).

The I2RS higher-layer protocol operating over a secure transport
provides this integrity. The I2RS higher-layer protocol operating
over an insecure a non-secure transport SHOULD provide some way for the client
receiving non-confidential nonconfidential read-scoped or event-scoped data over
the insecure non-secure connection to detect when the data integrity is
questionable; and in the event of a questionable data integrity integrity,
the I2RS client should disconnect the insecure non-secure transport
connection.

SEC-REQ-19: The I2RS higher-layer protocol MUST provide a
mechanism for message traceability (requirements in [RFC7922])
that supports the tracking higher-layer functions run across
secure connection or a non-secure transport.

Explanation:

Most carriers do not want a router's configuration and data flow data-flow
statistics to be known by hackers or their competitors. While
carriers may share peering information, most carriers do not share
configuration and traffic statistics. To achieve this, the I2RS
higher-layer protocol (e.g (e.g., NETCONF) requires access control (NACM
(NETCONF Access Control Model [RFC6536]) for sensitive data needs to
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
non-confidential
nonconfidential data over an insecure a non-secure connection. The ability to
trace I2RS protocol messages that enact I2RS transactions provides a
minimal aid to helping operators check how messages enact
transactions on a secure or insecure non-secure transport. Contextual checks
on specific non-confidential nonconfidential data sent over a insecure non-secure connection
may indicate the data has been modified.

4.6. Role-Based Data Model Security

The I2RS Architecture [RFC7921] specifies access control by "role"
where role is a method of making

In order to make access control more manageable by
creating manageable, the I2RS
architecture [RFC7921] specifies a grouping of "role" to categorize users so that access control can be specified
for into a role rather
group (rather than handling them individually) for each of the individuals. access-control
purposes (role-based access control). Therefore, an I2RS role
specifies the access control for a group as being read, write, or
notification.

SEC-REQ-20: The rules around what I2RS security role is permitted
to access and manipulate what information over a secure transport
(which protects the data in transit) SHOULD ensure that data of
any level of sensitivity is reasonably protected from being
observed by those without permission to view it, so that privacy
requirements are met.

SEC-REQ-21: Role security MUST work when multiple transport
connections are being used between the I2RS client and I2RS agent as
the I2RS architecture [RFC7921] describes.

Sec-REQ-22: If an I2RS agents agent or an I2RS client is tightly correlated with
a person, then the I2RS protocol and data models SHOULD provide
additional security that protects the person's privacy.

Explanation:

An I2RS higher-layer protocol uses a management protocol E.g. (e.g.,
NETCONF, RESTCONF) to pass messages in order to enact I2RS
transactions. Role Security security must secure data (sensitivity (sensitive and normal
data) in a router even when it is operating over multiple connections
at the same time. NETCONF can run over TLS (over TCP or SCTP) or
SSH. RESTCONF runs over HTTP over a secure transport (TLS). SCTP
[RFC4960] provides security for multiple streams plus end-to-end
transport of data. Some I2RS functions may wish to operate over DTLS
[RFC6347], which runs over UDP
([RFC6347]), DDCP ([RFC6238]), ([RFC768]) and SCTP ([RFC5764]).

Please note the security of the connection between application to and
I2RS client connection is outside of the I2RS protocol or I2RS interface.

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,
then privacy protection to anonymize any data relating to a person's
identity or location would be needed.

A variety of forms of managemen management may set policy on roles: "operator-
applied knobs", roles that restrict personal access, data-models data models with
specific "privacy roles", and access filters.

4.7. Security of the environment Environment

The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are
found in: [I-D.ietf-i2rs-security-environment-reqs].

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 Implementers should review the security environment.

6. IANA Considerations

This draft is requirements, and does not request anything summary of IANA.

7. Acknowledgement

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 environment in [RFC7921].

5. IANA Considerations

This document does not require any IANA actions.

6. Security Considerations

This is a document about security requirements discussion and this document. The authors would like to
thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia
Perlman, Alvaro Retana, Ben Campbell, for the I2RS protocol
and Alissa Cooper data models. Security considerations for their
review of these requirements.

8. the I2RS protocol
include both the protocol and the security environment.

7. References

8.1.

7.1. Normative References

[I-D.ietf-i2rs-security-environment-reqs]
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
Requirement Levels", BCP 14, RFC 2119,
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
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. <https://www.rfc-editor.org/info/rfc4107>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
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
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. <https://www.rfc-editor.org/info/rfc7258>.

[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
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
the Routing System (I2RS) Traceability: Framework and
Information Model", RFC 7922, DOI 10.17487/RFC7922, June
2016, <http://www.rfc-editor.org/info/rfc7922>. <https://www.rfc-editor.org/info/rfc7922>.

[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
for Subscription to YANG Datastores", RFC 7923,
DOI 10.17487/RFC7923, June 2016,
<http://www.rfc-editor.org/info/rfc7923>.

8.2.
<https://www.rfc-editor.org/info/rfc7923>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-18 (work in
progress), September 2016.

[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF

[RFC768] Postel, J., "User Datagram Protocol", draft-ietf-netconf-restconf-17 (work in
progress), September 2016.

[I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion
control mechanisms", draft-ietf-taps-transports-11 (work
in progress), July 2016. STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
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",
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
(TLS) Protocol Version 1.2", RFC 5246,
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
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://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>.
<https://www.rfc-editor.org/info/rfc5764>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(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
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. <https://www.rfc-editor.org/info/rfc6347>.

[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
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,
"Transport Layer Security (TLS) Encryption for RADIUS",
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,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.

[RFC7920] Atlas,
<https://www.rfc-editor.org/info/rfc6733>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.

[RFC8095] Fairhurst, G., Ed., Nadeau, T., Trammell, B., Ed., and D. Ward, "Problem
Statement for the Interface 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", System
(I2RS) Ephemeral State Requirements", RFC 7920, 8242,
DOI 10.17487/RFC7920, June 2016,
<http://www.rfc-editor.org/info/rfc7920>. 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

Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
United States of America

Email: shares@ndzh.com

Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal,
8275 Trans Canada Route
Saint Laurent, QC HAP 2N2 H4S
Canada

Email: daniel.migault@ericsson.com
Joel Halpern
Ericsson
US
United States of America

Email: joel.halpern@ericsson.com