draft-ietf-i2rs-protocol-security-requirements-07.txt   draft-ietf-i2rs-protocol-security-requirements-08.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: February 17, 2017 J. Halpern Expires: February 18, 2017 J. Halpern
Ericsson Ericsson
August 16, 2016 August 17, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-07 draft-ietf-i2rs-protocol-security-requirements-08
Abstract Abstract
This presents security-related requirements for the I2RS protocol for This presents security-related requirements for the I2RS protocol for
mutual authentication, transport protocols, data transfer and mutual authentication, transport protocols, data transfer and
transactions. transactions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2017. This Internet-Draft will expire on February 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3
2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 6 2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 3
3. Security-Related Requirements . . . . . . . . . . . . . . . . 7 3. Security-Related Requirements . . . . . . . . . . . . . . . . 5
3.1. Mutual authentication of an I2RS client and an I2RS Agent 8 3.1. Mutual authentication of an I2RS client and an I2RS Agent 6
3.2. Transport Requirements Based on Mutual Authentication . . 9 3.2. Transport Requirements Based on Mutual Authentication . . 6
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 8
3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 8
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 9
3.6. Security of the environment . . . . . . . . . . . . . . . 12 3.6. Security of the environment . . . . . . . . . . . . . . . 9
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) provides read and write The Interface to the Routing System (I2RS) provides read and write
access to information and state within the routing process. An I2RS access to information and state within the routing process. An I2RS
client interacts with one or more I2RS agents to collect information client interacts with one or more I2RS agents to collect information
from network routing systems. from network routing systems.
This document describes the requirements for the I2RS protocol in the This document describes the requirements for the I2RS protocol in the
security-related areas of mutual authentication of the I2RS client security-related areas of mutual authentication of the I2RS client
skipping to change at page 3, line 18 skipping to change at page 3, line 18
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Definitions 2. Definitions
2.1. Security Definitions 2.1. Security Definitions
This document utilizes the definitions found in the following This document utilizes the definitions found in the following
documents: [RFC4949] and [RFC7921] documents: [RFC4949] and [RFC7921]
Specifically, this document utilizes the following definitions: Specifically, this document utilizes the following definitions from
[RFC4949]:
access control
[RFC4949] defines access control as the following:
1. (I) Protection of system resources against unauthorized
access.
2. (I) A process by which use of system resources is regulated
according to a security policy and is permitted only by
authorized entities (users, programs, processes, or other
systems) according to that policy. (See: access, access
control service, computer security, discretionary access
control, mandatory access control, role-based access control.)
3. (I) /formal model/ Limitations on interactions between
subjects and objects in an information system.
4. (O) "The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an
unauthorized manner."
5. (O) /U.S. Government/ A system using physical, electronic,
or human controls to identify or admit personnel with properly
authorized access to a SCIF.
Authentication
[RFC4949] describes authentication as the process of verifying
(i.e., establishing the truth of) an attribute value claimed by or
for a system entity or system resource. Authentication has two
steps: identify and verify.
Data Confidentiality
[RFC4949] describes data confidentiality as having two properties:
a) Data is not disclosed to system entities unless they have
been authorized to know the data, and
b) Data is not disclosed to unauthorized individuals, entities
or processes.
The key point is that confidentiality implies that the originator
has the ability to authorize where the information goes.
Confidentiality is important for both read and write scope of the
data.
Data Integrity
[RFC4949] states data integrity includes:
1. (I) The property that data has not been changed, destroyed,
or lost in an unauthorized or accidental manner. [...]
2. (O) "The property that information has not been modified or
destroyed in an unauthorized manner."
Data Privacy
[RFC4949] describes data privacy as a synonym for data
confidentiality. This I2RS document will utilize data privacy as
a synonym for data confidentiality.
Identity
[RFC4949] (I) The collective aspect of a set of attribute values
(i.e., a set of characteristics) by which a system user or other
system entity is recognizable or known. (See: authenticate,
registration. Compare: identifier.)
Identifier
[RFC4949] (I) A data object -- often, a printable, non-blank
character string -- that definitively represents a specific
identity of a system entity, distinguishing that identity from all
others. (Compare: identity.)
Mutual Authentication
[RFC4949] implies that mutual authentication exists between two
interacting system entities.
Mutual authentication in I2RS implies that both sides move from a
state of mutual suspicion to to mutual authentication to trusted
mutual communication after each system has been identified and
validated by its peer system.
role
[RFC4949] describes role as:
1. (I) A job function or employment position to which people o access control,
or other system entities may be assigned in a system. [...]
2. (O) /Common Criteria/ A pre-defined set of rules o Authentication,
establishing the allowed interactions between a user and the
TOE.
The I2RS uses the common criteria definition. o Data Confidentiality,
role-based access control o Data Integrity,
[RFC4949] describes role-based access control as: "A form of o Data Privacy,
identity-based access control wherein the system entities that are
identified and controlled are functional positions in an
organization or process."
security audit trail o Identity,
[RFC4949] describes a security audit trail as "A chronological o Identifier,
record of system activities that is sufficient to enable the
reconstruction and examination of the sequence environments and
activities surrounding or leading to an operation, procedure, or
event in a security-relevant transaction from inception to final
results."
Requirements to support a security audit is not covered in this o Mutual Authentication,
document.
[RFC7922] describes traceability for I2RS interface and the I2RS o role,
protocol. Traceability is not equivalent to a security audit
trail.
Trust o role-based access control,
[RFC4949] o security audit trail, and
1. (I) /information system/ A feeling of certainty (sometimes o trust.
based on inconclusive evidence) either (a) that the system
will not fail or (b) that the system meets its specifications
(i.e., the system does what it claims to do and does not
perform unwanted functions). (See: trust level, trusted
system, trustworthy system. Compare: assurance.)
2. . (I) /PKI/ A relationship between a certificate user and a CA [RFC7922] describes traceability for I2RS interface and the I2RS
in which the user acts according to the assumption that the CA protocol. Traceability is not equivalent to a security audit trail.
creates only valid digital certificates. (Also referred as
"trusted" in [RFC4949].)
2.2. I2RS Specific Definitions 2.2. I2RS Specific Definitions
I2RS protocol data integrity
The transfer of data via the I2RS protocol has the property of
data integrity described in [RFC4949].
I2RS component protocols I2RS component protocols
Protocols which are combined to create the I2RS protocol. Protocols which are combined to create the I2RS protocol.
I2RS Higher-level protocol I2RS Higher-level protocol
The I2RS protocol exists as a higher-level protocol which may The I2RS protocol exists as a higher-level protocol which may
combine other protocols (NETCONF, RESTCONF, IPFIX and others) combine other protocols (NETCONF, RESTCONF, IPFIX and others)
within a specific I2RS client-agent relationship with a specific within a specific I2RS client-agent relationship with a specific
trust for ephemeral configurations, event, tracing, actions, and trust for ephemeral configurations, event, tracing, actions, and
skipping to change at page 7, line 39 skipping to change at page 5, line 19
complete a transation. complete a transation.
I2RS secondary identifier I2RS secondary identifier
The I2RS architecture document [RFC7921] defines a secondary The I2RS architecture document [RFC7921] defines a secondary
identity as the entity of some non-I2RS entity (e.g. application) identity as the entity of some non-I2RS entity (e.g. application)
which has requested a particular I2RS client perform an operation. which has requested a particular I2RS client perform an operation.
The I2RS secondary identifier represents this identity so it may The I2RS secondary identifier represents this identity so it may
be distinguished from all others. be distinguished from all others.
I2RS routing system
Layer three (L3) routing systems which include physical routers,
virtual routers (in hypervisors or load splitters), and other
devices supporting L3 routing in order to forward packets based on
L3 headers.
3. Security-Related Requirements 3. Security-Related Requirements
The security for the I2RS protocol requires mutually authenticated The security for the I2RS protocol requires mutually authenticated
I2RS clients and I2RS agents. The I2RS client and I2RS agent using I2RS clients and I2RS agents. The I2RS client and I2RS agent using
the I2RS protocol MUST be able to exchange data over a secure the I2RS protocol MUST be able to exchange data over a secure
transport, but some functions may operate on a non-secure transport. transport, but some functions may operate on a non-secure transport.
The I2RS protocol MUST be able to provide atomicity of an I2RS The I2RS protocol MUST be able to provide atomicity of an I2RS
transaction, but it is not required to have multi-message atomicity transaction, but it is not required to have multi-message atomicity
and roll-back mechanism transactions. Multiple messages transactions and roll-back mechanism transactions. Multiple messages transactions
may be impacted by the interdependency of data. This section may be impacted by the interdependency of data. This section
discusses the details of these security requirements. discusses the details of these security requirements.
There are dependencies in some of the requirements below. For There are dependencies in some of the requirements below. For
confidentiality (section 3.3) and integrity (section 3.4) to be confidentiality (section 3.3) and integrity (section 3.4) to be
achieved, the client-agent must have mutual authentication (section achieved, the client-agent must have mutual authentication (section
3.1) and secure transport (section 3.2). I2RS allows the use of an 3.1) and secure transport (section 3.2). Since I2RS does not itself
insecure transport for portions of data models that clearly indicate provide confidentiality and integrity, it depends on running over a
insecure transport. If insecure transport is used, then secure Transport that provides these features.
confidentiality and integrity cannot be achieved.
I2RS allows the use of an insecure transport for portions of data
models that clearly indicate the use of an insecure transport.
Operators deploying I2RS must determine if they want to populate and
deploy the portions of the data model which use insecure transports.
3.1. Mutual authentication of an I2RS client and an I2RS Agent 3.1. Mutual authentication of an I2RS client and an I2RS Agent
The I2RS architecture [RFC7921] sets the following requirements: The I2RS architecture [RFC7921] sets the following requirements:
o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
identity, and at least one unique identifier that uniquely identity, and at least one unique identifier that uniquely
identifies each party in the I2RS protocol context. identifies each party in the I2RS protocol context.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
skipping to change at page 8, line 30 skipping to change at page 6, line 25
o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a
I2RS client, MUST confirm that the I2RS client has a valid I2RS client, MUST confirm that the I2RS client has a valid
identifier. identifier.
o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from
an I2RS agent, MUST confirm the I2RS agent has a valid identifier. an I2RS agent, MUST confirm the I2RS agent has a valid identifier.
o SEC-REQ-05: Identifier distribution and the loading of these o SEC-REQ-05: Identifier distribution and the loading of these
identifiers into I2RS agent and I2RS Client SHOULD occur outside identifiers into I2RS agent and I2RS Client SHOULD occur outside
the I2RS protocol. the I2RS protocol. The I2RS protocol SHOULD assume some
mechanism(s) (IETF or private) will distribute the identifiers and
o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF load these into the I2RS client and agent so that the I2RS client/
or private) will distribute or load identifiers so that the I2RS agent has these identifiers prior to the I2RS protocol
client/agent has these identifiers prior to the I2RS protocol
establishing a connection between I2RS client and I2RS agent. establishing a connection between I2RS client and I2RS agent.
(One mechanism such mechanism is AAA protocols.)
o SEC-REQ-07: Each Identifier MUST have just one priority. o SEC-REQ-06: Each Identifier MUST have just one priority.
o SEC-REQ-08: Each Identifier is associated with one secondary o SEC-REQ-07: 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.
Since a single I2RS client may be use by multiple applications, Since a single I2RS client may be use by multiple applications,
the secondary identifier may vary as the I2RS client is utilize by the secondary identifier may vary as the I2RS client is utilize by
different application each of whom have a unique secondary different application each of whom have a unique secondary
identity and identifier. identity and identifier.
3.2. Transport Requirements Based on Mutual Authentication 3.2. Transport Requirements Based on Mutual Authentication
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over a secure transport and optionally MAY be able to transfer data over a
non-secure transport. A secure transport MUST provide data non-secure transport. A secure transport MUST provide data
confidentiality, data integrity, and replay prevention. confidentiality, data integrity, and replay prevention.
The default I2RS transport is a secure transport. The default I2RS transport is a secure transport.
A non-secure transport can be can be used for publishing telemetry A non-secure transport can be used for publishing telemetry data or
data or other operational state that was specifically indicated to other operational state that was specifically indicated to non-
non-confidential in the data model in the Yang syntax. confidential in the data model in the Yang syntax.
The configuration of ephemeral data in the I2RS Agent by the I2RS The configuration of ephemeral data in the I2RS Agent by the I2RS
client SHOULD be done over a secure transport. It is anticipated client SHOULD be done over a secure transport. It is anticipated
that the passing of most I2RS ephemeral state operational status that the passing of most I2RS ephemeral state operational status
SHOULD be done over a secure transport. As SHOULD be done over a secure transport. As
[I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate
whether the transport exchanging the data between I2RS client and whether the transport exchanging the data between I2RS client and
I2RS agent is secure or insecure. The default mode of transport is I2RS agent is secure or insecure. The default mode of transport is
secure so data models SHOULD clearly annotate what data nodes can be secure so data models SHOULD clearly annotate what data nodes can be
passed over an insecure connection. passed over an insecure connection.
SEC-REQ-10: A secure transport MUST be associated with a key SEC-REQ-09: A secure transport MUST be associated with a key
management solution that can guarantee that only the entities having management solution that can guarantee that only the entities having
sufficient privileges can get the keys to encrypt/decrypt the sufficient privileges can get the keys to encrypt/decrypt the
sensitive data. Per BCP107 [RFC4107] this key management system sensitive data. Per BCP107 [RFC4107] this key management system
SHOULD be automatic, but MAY be manual in the following scenarios: SHOULD be automatic, but 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-term session key will be very low. long-term session key will be very low.
d) The scale of the deployment is limited. d) The scale of the deployment is limited.
Most I2RS environments (Clients and Agents) will not have the Most I2RS environments (Clients and Agents) will not have the
environment described by BCP107 [RFC4107] but a few I2RS use cases environment described by BCP107 [RFC4107] but a few I2RS use cases
required limited non-secure light-weight telemetry messages that have required limited non-secure light-weight telemetry messages that have
these requirements. An I2RS data model must indicate which portions these requirements. An I2RS data model must indicate which portions
can be served by manual key management. can be served by manual key management.
SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure SEC-REQ-10: The I2RS protocol MUST be able to support multiple secure
transport sessions providing protocol and data communication between transport sessions providing protocol and data communication between
an I2RS Agent and an I2RS client. However, a single I2RS Agent to an I2RS Agent and an I2RS client. However, a single I2RS Agent to
I2RS client connection MAY elect to use a single secure transport I2RS client connection MAY elect to use a single secure transport
session or a single non-secure transport session. session or a single non-secure transport session.
SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement SEC-REQ-11: The I2RS Client and I2RS Agent protocol SHOULD implement
mechanisms that mitigate DoS attacks. mechanisms that mitigate DoS attacks.
3.3. Data Confidentiality Requirements 3.3. Data Confidentiality Requirements
SEC-REQ-13: In a critical infrastructure, certain data within routing SEC-REQ-12: In a critical infrastructure, certain data within routing
elements is sensitive and read/write operations on such data SHOULD elements is sensitive and read/write operations on such data SHOULD
be controlled in order to protect its confidentiality. For example, be controlled in order to protect its confidentiality. For example,
most carriers do not want a router's configuration and data flow most carriers do not want a router's configuration and data flow
statistics known by hackers or their competitors. While carriers may statistics known by hackers or their competitors. While carriers may
share peering information, most carriers do not share configuration share peering information, most carriers do not share configuration
and traffic statistics. To achieve this, access control to sensitive and traffic statistics. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on such data needs to be provided, and the confidentiality protection on such
data during transportation needs to be enforced. data during transportation needs to be enforced.
3.4. Data Integrity Requirements 3.4. Data Integrity Requirements
SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able SEC-REQ-13: An integrity protection mechanism for I2RS MUST be
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 of the 3) the data is not repeated from some earlier interaction of the
protocol. (That is, when both confidentiality and integrity of protocol. (That is, when both confidentiality and integrity of
data is properly protected, it is possible to ensure that data is properly protected, it is possible to ensure that
encrypted data is not modified or replayed without detection.) encrypted data is not modified or replayed without detection.)
SEC-REQ-15: The integrity that the message data is not repeated means SEC-REQ-14: The I2RS client to I2RS agent transport protocol MUST
that I2RS client to I2RS agent transport SHOULD protect against protect against replay attack.
replay attack
Requirements SEC-REQ-14 and SEC-REQ-15 are SHOULD requirements only Requirements SEC-REQ-13 and SEC-REQ-14 are requirements for the
because it is recognized that some I2RS Client to I2RS agent secure channel which must be supported as the default by every I2RS
communication occurs over a non-secure channel. The I2RS client to Agent, and by every I2RS client communicating over a secure
I2RS agent over a secure channel would implement these features. In transport. In order to provide some traceability or notification for
order to provide some traceability or notification for the non-secure the non-secure protocol, SEC-REQ-15 suggests traceability and
protocol, SEC-REQ-16 suggests traceability and notification are notification are important to include for any non-secure protocol.
important to include for any non-secure protocol.
SEC-REQ-16: The I2RS message traceability and notification SEC-REQ-15: The I2RS protocol MUST provide a mechanism for message
requirements requirements found in [RFC7922] and [RFC7923] SHOULD be traceability and notification requirements requirements found in
supported in communication channel that is non-secure to trace or [RFC7922] and [RFC7923] that can be supported in communication
notify about potential security issues. channel that is non-secure to trace or notify about potential
security issues.
3.5. Role-Based Data Model Security 3.5. Role-Based Data Model Security
The I2RS Architecture [RFC7921] defines a role or security role as The I2RS Architecture [RFC7921] defines a role or security role as
specifying read, write, or notification access by a I2RS client to specifying read, write, or notification access by a I2RS client to
data within an agent's data model. data within an agent's data model.
SEC-REQ-17: The rules around what role is permitted to access and SEC-REQ-16: The rules around what role is permitted to access and
manipulate what information plus a secure transport (which protects manipulate what information plus a secure transport (which protects
the data in transit) SHOULD ensure that data of any level of the data in transit) SHOULD ensure that data of any level of
sensitivity is reasonably protected from being observed by those sensitivity is reasonably protected from being observed by those
without permission to view it, so that privacy requirements are met. without permission to view it, so that privacy requirements are met.
SEC-REQ-18: Role security MUST work when multiple transport SEC-REQ-17: Role security MUST work when multiple transport
connections are being used between the I2RS client and I2RS agent as connections are being used between the I2RS client and I2RS agent as
the I2RS architecture [RFC7921] states. These transport message the I2RS architecture [RFC7921] states. These transport message
streams may start/stop without affecting the existence of the client/ streams may start/stop without affecting the existence of the client/
agent data exchange. TCP supports a single stream of data. SCTP agent data exchange. TCP supports a single stream of data. SCTP
[RFC4960] provides security for multiple streams plus end-to-end [RFC4960] provides security for multiple streams plus end-to-end
transport of data. transport of data.
SEC-REQ-19: I2RS clients MAY be used by multiple applications to SEC-REQ-18: I2RS clients MAY be used by multiple applications to
configure routing via I2RS agents, receive status reports, turn on configure routing via I2RS agents, receive status reports, turn on
the I2RS audit stream, or turn on I2RS traceability. Application the I2RS audit stream, or turn on I2RS traceability. Application
software using I2RS client functions may host multiple secure software using I2RS client functions may host multiple secure
identities, but each connection will use only one identifier with one identities, but each connection will use only one identifier with one
priority. Therefore, the security of each I2RS Client to I2RS Agent priority. Therefore, the security of each I2RS Client to I2RS Agent
connection is unique. connection is unique.
Please note the security of the application to I2RS client connection Please note the security of the application to I2RS client connection
is outside of the I2RS protocol or I2RS interface. is outside of the I2RS protocol or I2RS interface.
Sec-REQ-20: If an I2RS agents or an I2RS client is tightly correlated Sec-REQ-19: If an I2RS agents or an I2RS client is tightly correlated
with a person, then the I2RS protocol and data models should provide with a person, then the I2RS protocol and data models SHOULD provide
additional security that protects the person's privacy. An example additional security that protects the person's privacy. An example
of an I2RS agent correlated with a person is a I2RS agent running on of an I2RS agent correlated with a person is a I2RS agent running on
someone's phone to control tethering, and an example of a I2RS client someone's phone to control tethering, and an example of a I2RS client
might be the client tracking such tethering. This protection MAY might be the client tracking such tethering. This protection MAY
require a variety of forms including: "operator-applied knobs", roles require a variety of forms including: "operator-applied knobs", roles
that restrict personal access, data-models with specific "privacy that restrict personal access, data-models with specific "privacy
roles", and access filters. roles", and access filters.
3.6. Security of the environment 3.6. Security of the environment
skipping to change at page 12, line 41 skipping to change at page 10, line 35
[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>. <http://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, <http://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>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
Statement for the Interface to the Routing System", Statement for the Interface to the Routing System",
RFC 7920, DOI 10.17487/RFC7920, June 2016, RFC 7920, DOI 10.17487/RFC7920, June 2016,
<http://www.rfc-editor.org/info/rfc7920>. <http://www.rfc-editor.org/info/rfc7920>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<http://www.rfc-editor.org/info/rfc7921>. <http://www.rfc-editor.org/info/rfc7921>.
skipping to change at page 13, line 17 skipping to change at page 11, line 17
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-15 (work in Requirements", draft-ietf-i2rs-ephemeral-state-15 (work in
progress), July 2016. progress), July 2016.
[I-D.ietf-i2rs-security-environment-reqs] [I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security- Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016. environment-reqs-01 (work in progress), April 2016.
[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>.
[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>. <http://www.rfc-editor.org/info/rfc4960>.
[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, <http://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
 End of changes. 42 change blocks. 
195 lines changed or deleted 89 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/