One document matched: draft-ietf-i2rs-protocol-security-requirements-11.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5764 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY RFC6238 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6238.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC6614 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6614.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY RFC7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY RFC7920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7920.xml">
<!ENTITY RFC7921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7921.xml">
<!ENTITY RFC7922 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7922.xml">
<!ENTITY RFC7923 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7923.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-security-environment-reqs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-security-environment-reqs.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-taps-transports SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-taps-transports.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-ietf-i2rs-protocol-security-requirements-11" ipr="trust200902">
<front>
<title abbrev="I2RS Security Requirements">I2RS Security Related Requirements</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Migault" initials="D" surname="Migault">
<organization>Ericsson</organization>
<address>
<postal>
<street>8400 boulevard Decarie</street>
<city>Montreal</city>
<region>QC</region>
<code>HAP 2N2</code>
<country>Canada</country>
</postal>
<email>daniel.migault@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Joel Halpern" initials="J" surname="Halpern">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>US</country>
</postal>
<email>joel.halpern@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t> This presents security-related requirements for the I2RS
protocol which provides a new interface to the routing system
described in the I2RS architecture document (RFC7921). The I2RS protocol
is a re-use protocol implemented by re-using portions of existing
IETF protocols and adding new features to these protocols.
The I2RS protocol re-uses security features of a secure transport
(E.g. TLS, SSH, DTLS) such as encryption, message integrity, mutual peer
authentication, and replay protection. The new security features
I2RS adds are: a priority mechanism to handle multi-headed write transactions,
an opaque secondary identifier which 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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS)
provides read and write access to information and state within the
routing process. An I2RS client interacts with one or more I2RS agents to collect information
from network routing systems. <xref target="RFC7921"></xref> describes the
architecture of this interface, and this documents 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.
</t>
<t>
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 portions of existing
IETF protocols, and adding new features to these protocols.
As a re-use protocol, it can be considered a higher-level protocol
since it can be instantiated in multiple management protocols (e.g. NETCONF
<xref target="RFC6241"></xref> or RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>)
operating over a secure transport. The security for
the I2RS protocol comes from the managmenet protocols operating over a
a secure transport which carries traffic over multiple links.
</t>
<t>This document is part of the requirements for I2RS protocol which
also include:
<list style="symbols">
<t>I2RS architecture <xref target="RFC7921"></xref>,
</t>
<t>I2RS ephemeral state requirements <xref target="I-D.ietf-i2rs-ephemeral-state"></xref>,
</t>
<t> publication/subscription requirements <xref target="RFC7922"></xref>, and
</t>
<t> traceability <xref target="RFC7923"></xref>.
</t>
</list>
</t>
<t>
Since the I2RS "higher-level" 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 secuirty requirements for the I2RS environment are specified in
<xref target="I-D.ietf-i2rs-security-environment-reqs"></xref>,
and the summary of the I2RS protocol security environment found in the
I2RS Architecture <xref target="RFC7920"></xref>.
</t>
<t>
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which support encryption,
message integrity, peer authentication, and key distribution protocols.
Optionally, implementers may utilize AAA protocols (Radius over TLS or
Diameter over TLS) to securely distribute identity information.
</t>
<t>
Section 3 provides an overview of security features and
protocols being re-used (section 3.1) and the new security features
being required (section 3.2). Section 3 also explores how existing and new
security features and protocols would be paired with
existing IETF management protocols (section 3.3).
</t>
<t>
The new features I2RS extends to these protocols are a priority
mechanism to handle multi-headed reads, an opaque secondary
identifier to allow traceability of an application utilizing a specific I2RS client to
communicate with an I2RS agent, and insecure transport constrained
to be utilized only for read-only data which publically available
data (e.g. public BGP Events, public telemetry information,
web service available) and some legacy data.
</t>
<t>
Section 4 provides the
I2RS protocol security requirements by the following security
features:
<list style="symbols">
<t>peer identity authentication (section 4.1), </t>
<t>peer identity validation before role-based message actions (section 4.2) </t>
<t>peer identity and client redundancy (section 4.3), </t>
<t>multi-channel transport requirements: Secure transport and insecure Transport
(section 4.4), </t>
<t>management protocol security requirements (section 4.5),
</t>
<t>role-based security (section 4.6), </t>
<t>security environment (section 4.7) </t>
</list>
Protocols designed to be I2RS higher-layer protocols
need to fulfill these security requirements.
</t>
</section>
<section title="Definitions" >
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Security Definitions">
<t>This document utilizes the definitions found in the
following documents: <xref target="RFC4949"></xref> and <xref target="RFC7921"></xref>
</t>
<t> Specifically, this document utilizes the following definitions from
<xref target="RFC4949" />:
<list style="symbols">
<t>access control,</t>
<t>authentication,</t>
<t>data confidentiality, </t>
<t>data integrity, </t>
<t>data privacy, </t>
<t>identity,</t>
<t>identifier,</t>
<t>mutual authentication,</t>
<t>role,</t>
<t>role-based access control,</t>
<t>security audit trail, and </t>
<t>trust.</t>
</list>
</t>
<t><xref target="RFC7922"></xref> describes traceability for 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.
</t>
<t>This document also requires that the user is familiar with the
pervasive security requirements in <xref target="RFC7258"></xref>.
</t>
</section>
<section title="I2RS Specific Definitions">
<t>
The document utilizes the following concepts from the I2RS architecture:
<xref target="RFC7921"></xref>:
<list style="symbols">
<t>I2RS client, I2RS agent, and I2RS protocol (section 2), </t>
<t> I2RS higher-layer protocol (section 7.2) </t>
<t>scope: read scope, notification scope, and write scope (section 2), </t>
<t>identity and scope of the identity (section 2), </t>
<t>roles or security rules (section 2), </t>
<t>identity and scope, and secondary identity (section 2), </t>
<t>routing system/subsytem (section 2), </t>
<t>I2RS assumed security environment (section 4), </t>
<t>I2RS identity and authorization (section 4.1), </t>
<t>I2RS authorization, scope of Authorization in I2RS client and agent (section 4.2), </t>
<t>client redundancy with a single client identity (section 4.3),</t>
<t>restrictions on I2RS in personal devices (section 4.4), </t>
<t>communication channels and I2RS high-layer protocol (section 7.2),</t>
<t>active communication versus connectivity (section 7.5), </t>
<t>multi-headed control (section 7.8), and </t>
<t>transaction, message, multi-message atomicity (section 7.9). </t>
</list>
This document assumes the reader is familar with these terms.
</t>
<t>This document discusses the security of the multiple I2RS 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:
<list style="hanging">
<t hangText="I2RS component protocols"><vspace blankLines="1" /> Protocols
which are re-used and combined to create the I2RS protocol.
</t>
<t hangText="I2RS secure-transport component protocols"><vspace blankLines="1" />
The I2RS secure transport protocols that support the I2RS higher-layer protocol.
</t>
<t hangText="I2RS management component protocols"><vspace blankLines="1" />
The I2RS management protocol which provide the management information context.
</t>
<t hangText="I2RS AAA component protocols"><vspace blankLines="1" />
The I2RS AAA protocols supporting the I2RS higher-layer protocol.
</t>
</list>
The I2RS higher-layer protocol requires implementation of a
I2RS secure-transport component protocol and the I2RS management component protocol.
The I2RS AAA component protocol is optional.
</t>
</section>
</section>
<section title="Security Features and Protocols: Re-used and New">
<section title="Security Protocols Re-Used by the I2RS Protocol">
<t>
I2RS also requires a secure transport protocol and key
distribution protocols. The secure transport features required by I2RS
are peer authentication, confidentiality, data integrity, and replay protection
for I2RS messages. According to <xref target="I-D.ietf-taps-transports"></xref>, the
secure transport protocols which support peer authentication,
confidentiality, data integrity, and replay protection
are the following:
<list style="numbers">
<t>TLS <xref target = "RFC5246"></xref> over TCP or SCTP,
</t>
<t>DTLS over UDP with replay detection and anti-DoS
stateless cookie mechanism required for the I2RS protocol, and the
I2RS protocol allow DTLS options of record size negotiation and
and conveyance of "don't" fragment bits to be optional in deployments.
</t>
<t>HTTP over TLS (over TCP or SCTP), and
</t>
<t>HTTP over DTLS (with the requirements and optional features specified above
in item 2).
</t>
</list>
</t>
<t>The following protocols will need to be extended to provide
confidentiality, data integrity, peer authentication, and key distribution
protocols: SSH, SCTP, or the ForCES TML layer over SCTP.
</t>
<t>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.</t>
<t> An I2RS implementer may use AAA protocols over secure transport
to distribute the identities for I2RS client and I2RS agent and role authorization
information. Two AAA protocols are: Diameter <xref target="RFC6733"></xref> and
Radius <xref target="RFC2865"></xref>. To provide the best security
I2RS peer identities, the AAA protocols MUST be run over a
secure transport (Diameter over secure transport (TLS over TCP) <xref target="RFC6733"></xref>),
Radius over a secure transport (TLS) <xref target="RFC6614"></xref>).
</t>
</section>
<section title="New Features Related to Security">
<t>
The new features are priority, an opaque secondary identifier,
and an insecure 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 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 overlap of I2RS
clients attempting to write a particular piece of data, the
I2RS architecture <xref target="RFC7921"></xref> 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.
</t>
<t>The opaque secondary identifier identifies an application which
is using 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 information.
</t>
<t>
The last new security feature is the ability to allow non-confidential
data to be transfered 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
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 to be sent over a secure transport.
</t>
<t> Non-confidential data can only be read or notification scope transmission of events.
Non-confidential data cannot be write scope or notification scope configuration.
An example of non-confidential data is the telemetry information
that is publically known (e.g. BGP route-views
data or web site status data) or some legacy data (e.g. interface) which
cannot be transported in secure transport. The IETF I2RS Data models
MUST indicate in the data model the specific data which is non-confidential.
</t>
<t>
Most I2RS data models will expect that the information described in the model
will be transferred with confidentiality. Therefore, it is
</t>
</section>
<section title="I2RS Protocol Security Requirements vs. IETF Management Protocols">
<t>Table 1 below provides a partial list of the candidate management protocols
and the secure transports each one of the support.
One column in the table indicates the transport protocol will need
I2RS security extensions.
<figure>
<artwork>
Mangement
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 TML overs SCTP Needs extension to
(*1) TML to run TML
over TLS over SCTP,
or DTLS described
above. The
IPSEC mechanism is
not sufficient for
I2RS traveling over
multiple hops
(router + link)
(*2)
IPFIX SCTP, TCP, UDP Needs to extension
TLS or DTLS for to support TLS or
secure client (*1) DTLS with options
described above. (*2)
*1 - Key management protocols
MUST support appropriate key rotation.
*2 - Identity and Role authorization distributed
by Diameter or Radius MUST use Diameter over TLS
or Radius over TLS.
</artwork>
</figure>
</t>
</section>
</section>
<section title="Security-Related Requirements" >
<t>This section discusses security requirements based on the following
security functions:
<list style="symbols">
<t>peer identity authentication (section 4.1), </t>
<t>Peer Identity validation before Role-based Message Actions (section 4.2)</t>
<t>peer identity and client redundancy (section 4.3), </t>
<t>multi-channel transport requirements: Secure transport and insecure Transport (section 4.4), </t>
<t>management protocol security requirements (section 4.5),</t>
<t>role-based security (section 4.6), </t>
<t>security environment (section 4.7) </t>
</list>
</t>
<t>The I2RS Protocol depends upon a secure transport layer for
peer authentication, data integrity, confidentiality, and replay protection.
The optional insecure transport can only be used restricted set of publically data
available (events or information) or a select set of legacy data.
Data passed over the insecure transport channel MUST not contain any data
which identifies a person or any "write" transactions.
</t>
<section title="I2RS Peers(agent and client) Identity Authentication ">
<t>The following requirements specify the security requirements for Peer Identity
Authentication for the I2RS protocol:
<list style="symbols">
<t>SEC-REQ-01: All I2RS clients and I2RS agents MUST have an identity, and at least one unique
identifier that uniquely identifies each party in the I2RS protocol context. </t>
<t>SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of
the I2RS client and I2RS agent. </t>
<t>SEC-REQ-03: Identifier distribution and the loading of these identifiers into 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.
</t>
</list>
</t>
<t>Explanation:
</t>
<t>These requirements specify the requirements for I2RS peer (I2RS agent and I2RS client)
authentication. A secure transport (E.g. TLS) will authenticate based on these identities.
The AAA protocol distributing I2RS identity information SHOULD transport its information
over a secure transport.
</t>
</section>
<section title="Identity Validation Before Role-Based Message Actions">
<t>
The requirements for I2RS clients with Secure Connections are the following:
<list>
<t>SEC-REQ-04: An I2RS agent receiving a request from an I2RS client MUST confirm that the I2RS client has a valid identity.
</t>
<t>
SEC-REQ-05: An I2RS client receiving an I2RS message over a secure transport MUST confirm that the I2RS agent has a valid identifier.
</t>
<t>
SEC-REQ-06: An I2RS agent receiving an I2RS message over an insecure transport MUST confirm that the content is suitable for transfer over such a transport.
</t>
</list>
</t>
<t>
Explanation:
</t>
<t>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 sent on a communication channel. An I2RS communication
channel may utilize multiple transport sessions, or establish
a transport session and then close the transport session.
Therefore, it is important that the I2RS peers
are operating utilizing valid peer identities when a message is processed
rather than checking if a transport session exists.
</t>
</section>
<section title="Peer Identity, Priority, and Client Redundancy">
<t>
Requirements:
<list>
<t> SEC-REQ-07: Each I2RS Identifier MUST be associated with just one priority.</t>
<t> SEC-REQ-08: Each Identifier is associated with one secondary identifier during a
particular I2RS transaction (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.</t>
</list>
</t>
<t>
Explanation:
</t>
<t>
The I2RS architecture also allows multiple I2RS clients with unique identities
to connect to an I2RS agent (section 7.8). 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
variable, the error resolution mechanisms defined by the I2RS architecture
multi-headed control (<xref target="RFC7921"></xref>, section 7.8) 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.
</t>
<t>A single I2RS client may be associated with multiple applications
with different tasks (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 I2RS client to I2RS agent communication.
</t>
<t>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".
</t>
<t>A second example is if the I2RS client is used for monitoring of
critical infrastructure. The operator of a network using the I2RS client
may desire I2RS client redundancy where the monitoring application
wth the I2RS client is deployed on two different boxes with the
same I2RS client identity (see <xref target="RFC7921"></xref> section 4.3)
These two monitoring applications pass to the I2RS client
whether the application is the primary or
back up application, and the I2RS client passes this information
in the I2RS secondary identitifier as the figure below shows.
The primary applications secondary identifier is "primary-monitoring",
and the backup 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.
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
<section title="Multi-Channel Transport: Secure Transport and Insecure Transport" >
<t>
Requirements:
<list>
<t>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 means it is mandatory to implement (MTI) in all I2RS agents,
and in any I2RS client which: a) performs a Write scope transaction which
is sent to the I2RS agent or b): configures an Event Scope transaction.
It is mandatory to use (MTU) on any I2RS client's Write transaction or
the configuration of an Event Scope transaction.
</t>
<t>SEC-REQ-10: The secure transport MUST provide data
confidentiality, data integrity, and practical replay prevention.
</t>
<t>SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD implement
mechanisms that mitigate DoS attacks. For the secure transport,
this means the secure transport must support DoS prevention.
For the insecure transport protocol, the I2RS higher-layer protocol
MUST contain a transport management layer that considers the
detection of DoS attacks and provides a warning over
a secure-transport channel.
</t>
<t>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.
</t>
<t>SEC-REQ-13: A machine-readable mechanism to indicate that a data-model
contains non-confidential data MUST be provided. A non-secure transport
MAY be used to publish only read scope or notification scope data if the
associated data model indicates that that data is non-confidential.
</t>
<t> 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 I2RS agent to I2RS client connection MAY
elect to use a single secure transport session or a single
non-secure transport session conforming the requirements above.
</t>
<t>SEC-REQ-15: Deployment configuration knobs SHOULD be
created to allow operators to send "non-confidential" Read
scope (data or Event streams) over a secure transport.
</t>
</list>
</t>
<t>
Explanation:
</t>
<t>The I2RS architecture defines three scopes: read, write,
and notification scope. Insecure data can only be used
for read scope and notification scope of "non-confidential data".
The configuration of ephemeral data in the I2RS agent uses
either write scope 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.
</t>
<t>It is anticipated that the passing of most I2RS
ephemeral state operational
status SHOULD be done over a secure transport.
</t>
<t> In most 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.
</t>
<t>
Per <xref target="RFC4107">BCP107</xref> while
key management system SHOULD be automatic, the systems
MAY be manual in the following scenarios:
<list>
<t>a) The environment has limited bandwidth or high round-trip times.</t>
<t>b) The information being protected has low value.</t>
<t>c) The total volume of traffic over the entire lifetime of the long-term session key will be very low.</t>
<t>d) The scale of the deployment is limited.</t>
</list>
Operators deploying the I2RS protocol selecting manual key management SHOULD
consider both short and medium term plans. Deploying automatic
systems initially may save effort over the long-term.
</t>
</section>
<section title="Management Protocol Security">
<t>
Requirements:
<list>
<t>SEC-REQ-16: 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 SHOULD provide access control functions to protect confidentiality of the data.
</t>
<t> SEC-REQ-17: An integrity protection mechanism for I2RS MUST be provided
that will be able to ensure the following:
<list>
<t>1) the data being protected is not modified without detection during
its transportation,
</t>
<t>2) the data is actually from where it is expected to come from, and
</t>
<t>3) the data is not repeated from some earlier interaction the higher layer
protocol (best effort).
</t>
</list>
The I2RS higher-layer protocol operating over a secure transport provides this integrity.
The I2RS higher-layer protocol operating over an insecure transport SHOULD provide
some way for the client receiving non-confidential read-scoped or event-scoped data
over the insecure connection to detect when the data integrity is questionable; and
in the event of a questionable data integrity the I2RS client should disconnect the
insecure transport connection.
</t>
<t>SEC-REQ-18: The I2RS higher-layer protocol MUST provide a mechanism for
message traceability (requirements in <xref target="RFC7922"></xref>) that
supports the tracking higher-layer functions run across secure connection or
a non-secure transport. </t>
</list>
</t>
<t>
Explanation:
</t>
<t>
Most carriers do not want a router's configuration and
data flow statistics 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 NETCONF) needs to have access control
(NACM <xref target="RFC6536"></xref>) to sensitive
data needs to be provided, and the confidentiality protection on
such data during transportation needs to be enforced.
</t>
<t>
Integrity of data is important even if the I2RS protocol is sending
non-confidential data over an insecure 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 transport.
</t>
</section>
<section title="Role-Based Data Model Security">
<t>The <xref target="RFC7921">I2RS Architecture</xref> specifies access control
by "role" where role is a method of making access
control more manageable by creating a grouping of users so that
access control can be specified for a role rather than for each of
the individuals. Therefore, I2RS role specifies the
access control for a group as being read, write, or notification.
</t>
<t>
<list>
<t> SEC-REQ-19: 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.
</t>
<t> SEC-REQ-20: Role security MUST work when multiple transport connections are being used
between the I2RS client and I2RS agent as the <xref target="RFC7921">I2RS architecture</xref> describes.
</t>
<t>Sec-REQ-21: If an I2RS agents 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.
</t>
</list>
</t>
<t>Explanation:</t>
<t> I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF) to pass messages in order
to enact I2RS transactions. Role Security must secure data (sensitivity 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 <xref target="RFC4960" /> provides security for multiple streams plus end-to-end transport of data.
Some I2RS functions may wish to operate over DTLS which runs over UDP (<xref target="RFC6347"></xref>),
DDCP (<xref target="RFC6238"></xref>), and SCTP (<xref target="RFC5764"></xref>).
</t>
<t> Please note the security of the application to
I2RS client connection is outside of the I2RS protocol or I2RS interface.
</t>
<t>
One example of I2RS privacy concerns related to a person
is if I2RS agent is running on someone's phone to control tethering, and
the I2RS client might be the client tracking such tethering.
This protection of the privacy of the person involves the
I2RS client and the I2RS agent communication anonymizing the
any data related to the person's identity or locatino.
</t>
<t>A variety of forms of managemen may set policy on roles:
"operator-applied knobs", roles that restrict personal access,
data-models with specific "privacy roles", and access filters.
</t>
</section>
<section title="Security of the environment">
<t>The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are found in:
<xref target="I-D.ietf-i2rs-security-environment-reqs"></xref>.
</t>
</section>
</section>
<section title="Security Considerations">
<t>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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft is requirements, and does not request
anything of IANA.
</t>
</section>
<section anchor="Acks" title="Acknowledgement">
<t>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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4107;
&RFC4949;
&RFC7258;
&RFC7921;
&RFC7922;
&RFC7923;
&I-D.ietf-i2rs-security-environment-reqs;
</references>
<references title="Informative References">
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-taps-transports;
&I-D.ietf-netconf-restconf;
&RFC2865;
&RFC4960;
&RFC5264;
&RFC5764;
&RFC6238;
&RFC6241;
&RFC6347;
&RFC6536;
&RFC6614;
&RFC6733;
&RFC7920;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:21:28 |