[i2rs] Review comments for draft-i2rs-protocol-security-02

Thu, 14 Jan 2016 14:14:00 -0800 

Authors,

As part of document shepherd work for draft-ietf-i2rs-protocol-security, I've 
done the following review and edits on the draft.  Rather than give the typical 
tedious line-by-line list review, I am attaching the following files:

A modified .xml, based on the published -02.xml file.  It includes:
- Minor textual, grammatical and structural edits.
- XML comments flagged "XXX JMH" of items that require response.  These 
non-editorial items are noted below.
- rfcdiff output showing the changes covered in the .xml I am attaching.

I'm happy to make the git repository this review was created in available to 
anyone interested.  (Note that Sue and I are in the process of getting a formal 
I2RS github repository in order to aid in this type of work.)

Hopefully the .xml changes aid your integration of the comments. 

Commentary:
- Several pieces of quoted text varied from the source.  In many of those cases 
I've simply copied the appropriate text directly from that source.
- The direct correlation between applications and clients doesn't seem to be 
firmly stated in the architecture.  I think this document may be stretching a 
bit by doing so.  I suggest tightening up that wording.
- Messages are referred to as protocol items with regard to identifier 
requirements.  I think this may be incorrect, as the protocol mechanisms we've 
discussed thus far are likely bound to sessions.  Discussion may be required 
here.
- This document notes that the data model may be tagged with the 
confidentiality requirements of a given set of nodes.  I don't believe this has 
been part of our prior data model discussions and thus may represent a new 
requirement to convey to the netmod group.  (Note that description annotation 
may be used, but given that the desire seems to be to impose security 
restrictions based upon this, that may be too weak of a mechanism.)
- In the presence of such data model security requirement markup, what should 
the behavior be if there's an attempt to violate confidentiality requirements; 
e.g. using a non-confidential transport to carry confidential information?

Once we've reached some conclusion on the discussion above and have produced an 
updated version, we should be able to proceed through the next portion of the 
document shepherding process.

-- Jeff (acting as an individual contributor)

Attachment: draft-ietf-i2rs-protocol-security-requirements-02.xml
Description: XML document

Title: Diff: draft-ietf-i2rs-protocol-security-requirements-02-orig.txt - draft-ietf-i2rs-protocol-security-requirements-02-jhaas-review.txt
 draft-ietf-i2rs-protocol-security-requirements-02-orig.txt   draft-ietf-i2rs-protocol-security-requirements-02-jhaas-review.txt 
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 . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security-Related Requirements . . . . . . . . . . . . . . . . 5 2. Security-Related Requirements . . . . . . . . . . . . . . . . 5
2.1. Mutual authentication of I2RS client and I2RS Agent . . . 5 2.1. Mutual authentication of an I2RS client and an I2RS Agent 5
2.2. Transport Requirements Based on Mutual Authentication . . 6 2.2. Transport Requirements Based on Mutual Authentication . . 6
2.3. Data Confidentiality Requirements . . . . . . . . . . . . 7 2.3. Data Confidentiality Requirements . . . . . . . . . . . . 7
2.4. Data Integrity Requirements . . . . . . . . . . . . . . . 7 2.4. Data Integrity Requirements . . . . . . . . . . . . . . . 7
2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8 2.5. Role-Based Data Model Security . . . . . . . . . . . . . 8
3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 3. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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
and agent, the transport protocol carrying the I2RS protocol and agent, the transport protocol carrying the I2RS protocol
messages, and the atomicity of the transactions. These requirements messages, and the atomicity of the transactions. These requirements
align with the description of the I2RS architecture found in align with the description of the I2RS architecture found in
[I-D.ietf-i2rs-architecture] document which solves the problem [I-D.ietf-i2rs-architecture] document which solves the problem
described in [I-D.ietf-i2rs-problem-statement]. described in [I-D.ietf-i2rs-problem-statement].
[I-D.haas-i2rs-ephemeral-state-reqs] discusses I2RS roles-based write [I-D.ietf-i2rs-ephemeral-state] discusses I2RS roles-based write
conflict resolution in the ephemeral data store using the I2RS Client conflict resolution in the ephemeral data store using the I2RS Client
Identity, I2RS Secondary Identity and priority. The draft Identity, I2RS Secondary Identity and priority. The draft
[I-D.ietf-i2rs-traceability] describes the traceability framework and [I-D.ietf-i2rs-traceability] describes the traceability framework and
its requirements for I2RS. The draft its requirements for I2RS. The draft
[I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for
I2RS to be able to publish information or have a remote client I2RS to be able to publish information or have a remote client
subscribe to an information data stream. subscribe to an information data stream.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "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].
1.2. Definitions 1.2. Definitions
This document utilizes the definitions found in the following drafts: This document utilizes the definitions found in the following
[RFC4949], and [I-D.ietf-i2rs-architecture] documents: [RFC4949] and [I-D.ietf-i2rs-architecture]
Specifically, this document utilizes the following definitions: Specifically, this document utilizes the following definitions:
access control access control
[RFC4949] defines access control as the following: [RFC4949] defines access control as the following:
1)(I))protection of system resources against unauthorized use; 1. (I) Protection of system resources against unauthorized
access.
2)(I)process by which use of system resources is regulated 2. (I) A process by which use of system resources is regulated
according to a security policy and is permitted only by according to a security policy and is permitted only by
authorized entities (users, programs, processes, or other authorized entities (users, programs, processes, or other
systems) according to that policy; 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 3. (I) /formal model/ Limitations on interactions between
subjects and objects in an information system; subjects and objects in an information system.
4)(O) "The prevention of unauthorized use of a resource, 4. (O) "The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an including the prevention of use of a resource in an
unauthorized manner."; unauthorized manner." [I7498-2]
5.(O) /U.S. Government/ A system using physical, electronic, 5.(O) /U.S. Government/ A system using physical, electronic,
or human controls to identify or admit personnel with properly or human controls to identify or admit personnel with properly
authorized access to a SCIF. authorized access to a SCIF.
Authentication Authentication
[RFC4949] describes authentication as the process of verifying [RFC4949] describes authentication as the process of verifying
(i.e., establishing the truth of) an attribute value claimed by or (i.e., establishing the truth of) an attribute value claimed by or
for a system entity or system resource. Authentication has two for a system entity or system resource. Authentication has two
steps: identify and verify. steps: identify and verify.
Data Confidentiality Data Confidentiality
[RFC4949] describes data confidentiality as having two properties: [RFC4949] describes data confidentiality as having two properties:
a) data is not disclosed to system entities unless they have been
authorized to know, and b) data is not disclosed to unauthorized a) Data is not disclosed to system entities unless they have
individuals, entities or processes. The key point is that been authorized to know the data, and
confidentiality implies that the originator has the ability to
authorize where the information goes. Confidentiality is b) Data is not disclosed to unauthorized individuals, entities
important for both read and write scope of the data. 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 Data Integrity
[RFC4949] states data integrity includes
[RFC4949] states data integrity includes:
1. (I)The property that data has not been changed, destroyed, 1. (I)The property that data has not been changed, destroyed,
or or lost in an unauthorized or accidental manner. [...]
2. (O) "The property that information has not been modified or 2. (O) "The property that information has not been modified or
destroyed in an unauthorized manner." destroyed in an unauthorized manner." [I7498-2]
Data Privacy Data Privacy
[RFC4949] describes data privacy as a synonym for data [RFC4949] describes data privacy as a synonym for data
confidentiality. This I2RS document will utilize data privacy as confidentiality. This I2RS document will utilize data privacy as
a synonym for data confidentiality. a synonym for data confidentiality.
Mutual Authentication Mutual Authentication
[RFC4949] implies that mutual authentication exists between two [RFC4949] implies that mutual authentication exists between two
interacting system entities. Mutual authentication in I2RS interacting system entities. Mutual authentication in I2RS
implies that both sides move from a state of mutual suspicion to implies that both sides move from a state of mutual suspicion to
mutually authenticated communication after each system has been mutually authenticated communication after each system has been
identified and validated by its peer system. identified and validated by its peer system.
role role
[RFC4949] describes role as: [RFC4949] describes role as:
1) (I) A job function or employment position to which people or 1. (I) A job function or employment position to which people
other system entities may be assigned in a system. (See: role- or other system entities may be assigned in a system. [...]
based access control. Compare: duty, billet, principal, user.)
2) (O) /Common Criteria/ A pre-defined set of rules 2. (O) /Common Criteria/ A pre-defined set of rules
establishing the allowed interactions between a user and the establishing the allowed interactions between a user and the
TOE. TOE.
The I2RS uses the common criteria definition. The I2RS uses the common criteria definition.
role role-based access control
[RFC4949] describes role-based access control as: (I) A form of [RFC4949] describes role-based access control as: "A form of
identity-based access control wherein the system entities that are identity-based access control wherein the system entities that are
identified and controlled are functional positions in an identified and controlled are functional positions in an
organization or process. organization or process."
security audit trail
Security audit trail [RFC4949] describes a security audit trail as "A chronological
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."
[RFC4949] (page 254) describes a security audit trail as a Requirements to support a security audit is not covered in this
chronological record of system activities that is sufficient to document.
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 document. The draft
[I-D.ietf-i2rs-traceability] describes traceability for I2RS
interface and protocol. Traceability is not equivalent to a
security audit trail.
I2RS the following phrase that incorporates an [RFC4949] definition: [I-D.ietf-i2rs-traceability] describes traceability for I2RS
interface and the I2RS protocol. Traceability is not equivalent
to a security audit trail.
I2RS protocol data integrity I2RS protocol data integrity
The transfer of data via the I2RS protocol has the property of The transfer of data via the I2RS protocol has the property of
data integrity described in [RFC4949]. data integrity described in [RFC4949].
2. Security-Related Requirements 2. 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 non-secure transport. transport, but some functions may operate on a non-secure transport.
The I2RS protocol MUST BE able to provide atomicity of a transaction, The I2RS protocol MUST be able to provide atomicity of a transaction,
but it is not required to have multi-message atomicity and roll-back but it is not required to have multi-message atomicity and roll-back
mechanism transactions. Multiple messages transactions may be mechanism transactions. Multiple messages transactions may be
impacted by the interdependency of data. This section discusses impacted by the interdependency of data. This section discusses the
these details of these security requirements. details of these security requirements.
2.1. Mutual authentication of I2RS client and I2RS Agent 2.1. Mutual authentication of an I2RS client and an I2RS Agent
The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following
requirements: requirements:
o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least o SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least
one unique identifier that uniquely identifies each party. one unique identifier that uniquely identifies each party.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
mutual identification of the I2RS client and I2RS agent. mutual identification of the I2RS client and I2RS agent.
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.
o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
or private) will distribute or load identifiers so that the I2RS or private) will distribute or load identifiers so that the I2RS
client/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.
o SEC-REQ-07: Each Identifier MUST be linked to one priority o SEC-REQ-07: Each Identifier MUST be linked to exactly one
priority.
o SEC-REQ-08: Each Identifier is associated with one secondary o SEC-REQ-08: Each Identifier is associated with one secondary
identifier during a particular read/write sequence, but the identifier during a particular read/write sequence, but the
secondary identifier may vary during the time a connection between secondary identifier may vary during the time a connection between
the I2RS client and I2RS agent is active. The variance of the the I2RS client and I2RS agent is active. The variance of the
secondary identifier allows the I2RS client to be associated with secondary identifier allows the I2RS client to be associated with
multiple applications and pass along an identifier for these multiple applications and pass along an identifier for these
applications in the secondary identifier. applications in the secondary identifier.
2.2. Transport Requirements Based on Mutual Authentication 2.2. Transport Requirements Based on Mutual Authentication
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over 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 transport is a secure transport.
Note:The non-secure transport can be used for publishing telemetry Note:The non-secure transport can be used for publishing telemetry
data that was specifically indicated to non-confidential in the data data or other operational state that was specifically indicated to
model. The configuration of ephemeral data in the I2RS Agent by the non-confidential in the data model.
I2RS client SHOULD be done over a secure transport. It is
anticipated that the passing of most I2RS ephemeral state operational The configuration of ephemeral data in the I2RS Agent by the I2RS
status SHOULD be done over a secure transport. Data models SHOULD client SHOULD be done over a secure transport. It is anticipated
clearly annotate what data nodes can be passed over an insecure that the passing of most I2RS ephemeral state operational status
connection. The default transport is a secure transport. SHOULD be done over a secure transport. Data models SHOULD clearly
annotate what data nodes can be passed over an insecure connection.
SEC-REQ-10: A secure transport MUST be associated with a key SEC-REQ-10: 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 if the following constraints SHOULD be automatic, but MAY be manual in the following scenarios:
from BCP107:
a)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 a low value and b) The information being protected has low value.
c)the total volume over the entire lifetime of the long-term c) The total volume of traffic over the entire lifetime of the
session key will be very low, long-term session key will be very low.
d)the scale of the deployment is limited.
Most I2RS environments (I2RS Client - I2S Agents) will not have the d) The scale of the deployment is limited.
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-11: 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.
skipping to change at page 7, line 36 skipping to change at page 7, line 44
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.
2.4. Data Integrity Requirements 2.4. Data Integrity Requirements
SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able
to ensure the following: 1) the data being protected is not modified to ensure the following:
without detection during its transportation and 2) the data is
actually from where it is expected to come from 3) the data is not 1) The data being protected is not modified without detection
repeated from some earlier interaction of the protocol. That is, during its transportation and
when both confidentiality and integrity of data is properly
protected, it is possible to ensure that encrypted data is not 2) The data is actually from where it is expected to come from
modified or replayed without detection.
3) The data is not repeated from some earlier interaction of the
protocol. That is, when both confidentiality and integrity of
data is properly protected, it is possible to ensure that
encrypted data is not modified or replayed without detection.
SEC-REQ-15: The integrity that the message data is not repeated means SEC-REQ-15: The integrity that the message data is not repeated means
that I2RS client to I2RS agent transport SHOULD protect against that I2RS client to I2RS agent transport SHOULD protect against
replay attack replay attack
Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only
because it is recognized that some I2RS Client to I2RS agent because it is recognized that some I2RS Client to I2RS agent
communication occurs over a non-secure channel. The I2RS client to communication occurs over a non-secure channel. The I2RS client to
I2RS agent over a secure channel would implement these features. In I2RS agent over a secure channel would implement these features. In
order to provide some traceability or notification for the non-secure order to provide some traceability or notification for the non-secure
protocol, SEC-REQ-16 suggests traceability and notification are protocol, SEC-REQ-16 suggests traceability and 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-16: The I2RS message traceability and notification
requirements requirements found in [I-D.ietf-i2rs-traceability] and requirements requirements found in [I-D.ietf-i2rs-traceability] and
[I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in
communication channel that is non-secure to trace or notify about communication channel that is non-secure to trace or notify about
potential security issues potential security issues.
2.5. Role-Based Data Model Security 2.5. Role-Based Data Model Security
The [I-D.ietf-i2rs-architecture] defines a role or security role as The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or
specifying read, write, or notification access by a I2RS client to security role as specifying read, write, or notification access by a
data within an agent's data model. I2RS client to data within an agent's data model.
SEC-REQ-17: The rules around what role is permitted to access and SEC-REQ-17: 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-18: 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 [I-D.ietf-i2rs-architecture] states. These the I2RS architecture [I-D.ietf-i2rs-architecture] states. These
transport message streams may start/stop without affecting the transport message streams may start/stop without affecting the
existence of the client/agent data exchange. TCP supports a single existence of the client/agent data exchange. TCP supports a single
stream of data. SCTP [RFC4960] provides security for multiple stream of data. SCTP [RFC4960] provides security for multiple
streams plus end-to-end transport of data. streams plus end-to-end transport of data.
SEC-REQ-19: I2RS clients MAY be used by multiple applications to SEC-REQ-19: 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 several 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.
3. Acknowledgement 3. Acknowledgement
The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
skipping to change at page 9, line 33 skipping to change at page 9, line 43
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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>.
6.2. Informative References 6.2. Informative References
[I-D.haas-i2rs-ephemeral-state-reqs] [I-D.ietf-i2rs-ephemeral-state]
Haas, J., "I2RS Ephemeral State Requirements", draft-haas- Haas, J. and S. Hares, "I2RS Ephemeral State
i2rs-ephemeral-state-reqs-00 (work in progress), May 2015. Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in
progress), September 2015.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-08 (work in progress), December 2015. problem-statement-08 (work in progress), December 2015.
[I-D.ietf-i2rs-pub-sub-requirements] [I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-04 (work in progress), January 2016. requirements-04 (work in progress), January 2016.
 End of changes. 39 change blocks. 
78 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to