draft-ietf-i2rs-protocol-security-requirements-03.txt   draft-ietf-i2rs-protocol-security-requirements-04.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track D. Migault Intended status: Standards Track D. Migault
Expires: September 10, 2016 J. Halpern Expires: November 6, 2016 J. Halpern
Ericsson Ericsson
March 9, 2016 May 5, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-03 draft-ietf-i2rs-protocol-security-requirements-04
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 September 10, 2016. This Internet-Draft will expire on November 6, 2016.
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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . 6
3. Security-Related Requirements . . . . . . . . . . . . . . . . 7 3. Security-Related Requirements . . . . . . . . . . . . . . . . 7
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 8
3.2. Transport Requirements Based on Mutual Authentication . . 8 3.2. Transport Requirements Based on Mutual Authentication . . 8
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10
3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Security of the environment . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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. The 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
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.ietf-i2rs-ephemeral-state] discusses I2RS roles-based write [I-D.ietf-i2rs-ephemeral-state] discusses I2RS role-based access
conflict resolution in the ephemeral data store using the I2RS Client control that provides write conflict resolution in the ephemeral data
Identity, I2RS Secondary Identity and priority. The draft store using the I2RS Client Identity, I2RS Secondary Identity and
[I-D.ietf-i2rs-traceability] describes the traceability framework and priority. The draft [I-D.ietf-i2rs-traceability] describes the
its requirements for I2RS. The draft traceability framework and 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].
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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].
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 combines The I2RS protocol exists as a higher-level protocol which may
combination of other protocols (NETCONF, RESTCONF, IPFIX, and combine other protocols (NETCONF, RESTCONF, IPFIX and others)
others) within a specific I2RS client-agent relationship with a within a specific I2RS client-agent relationship with a specific
specific trust for ephemeral configurations, event, tracing, trust for ephemeral configurations, event, tracing, actions, and
actions, and data flow interactions. The protocols included in data flow interactions. The protocols included in the I2RS
the I2RS protocol protocol are defined as I2RS component protocol protocol are defined as I2RS component protocols. (Note:
protocols. Version 1 of the I2RS protocol will combine only NETCONF and
RESTCONF. Experiments with other protocols such as IPFIX have
shown these are useful to combine with NETCONF and RESTCONF
features.)
I2RS message I2RS message
is a complete data message of one of the I2RS component protocols. is a complete data message of one of the I2RS component protocols.
The I2RS component protocols may require multiple IP-packets to The I2RS component protocols may require multiple IP-packets to
send one protocol message. send one protocol message.
I2RS multi-message atomicity I2RS multi-message atomicity
An I2RS operation (read, write, event, action) must be contained An I2RS operation (read, write, event, action) must be contained
skipping to change at page 7, line 4 skipping to change at page 7, line 6
An I2RS operation (read, write, event, action) must be contained An I2RS operation (read, write, event, action) must be contained
within one I2RS message. Each I2RS operation must be atomic. within one I2RS message. Each I2RS operation must be atomic.
While it is possible to have an I2RS operation which is contained While it is possible to have an I2RS operation which is contained
in multiple I2RS (E.g. write in multiple messages), this is not in multiple I2RS (E.g. write in multiple messages), this is not
supported in order to simply the first version of I2RS. Multiple- supported in order to simply the first version of I2RS. Multiple-
message atomicity of I2RS operations would be used in a roll-back message atomicity of I2RS operations would be used in a roll-back
of a grouping of commands (e.g. multiple writes). of a grouping of commands (e.g. multiple writes).
I2RS transaction I2RS transaction
is a unit of I2RS functionality. Some examples of I2RS is a unit of I2RS functionality. Some examples of I2RS
transactions are: transactions are:
* The I2RS client issuing a read request to a I2RS agent, and the * The I2RS client issues a read request to a I2RS agent, and the
I2RS Agent responding to the read request I2RS Agent responding to the read request
* The I2RS client issue a write of ephemeral configuration values * The I2RS client issues a write of ephemeral configuration
into a data model, followed by the I2RS agent response to the values into an I2RS agent'sbr data model, followed by the I2RS
write. agent response to the write.
* An I2RS client may issue an action request, the I2RS agent * An I2RS client may issue an action request, the I2RS agent
responds to the action-request, and then responds when action responds to the action-request, and then responds when action
is complete. Actions can be single step processes or multiple is complete. Actions can be single step processes or multiple
step process. step process.
* An I2RS client requests to receive an event notification, and * An I2RS client requests to receive an event notification, and
the I2RS Agent sets up to send the events. the I2RS Agent sets up to send the events.
* An I2RS agent sends events to an I2RS Client on an existing * An I2RS agent sends events to an I2RS Client on an existing
connection. connection.
An I2RS action may require multiple I2RS messages in order to An I2RS action may require multiple I2RS messages in order to
complete a transation. complete a transation.
I2RS secondary identifier I2RS secondary identifier
the I2RS architecture document [I-D.ietf-i2rs-architecture] The I2RS architecture document [I-D.ietf-i2rs-architecture]
defines a secondary identity as the entity of some non-I2RS entity defines a secondary identity as the entity of some non-I2RS entity
(e.g. application) which has requested a particular I2RS client (e.g. application) which has requested a particular I2RS client
perform an operation. The I2RS secondary identifier represents perform an operation. The I2RS secondary identifier represents
this identity so it may be distinguished from all others. this identity so it may be distinguished from all others.
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
skipping to change at page 9, line 47 skipping to change at page 9, line 47
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.
SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement SEC-REQ-12: 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-13: In a critical infrastructure, certain data within routing
elements is sensitive and read/write operations on such data MUST be elements is sensitive and read/write operations on such data SHOULD
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-14: An integrity protection mechanism for I2RS SHOULD be able
to ensure the following: 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 and 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
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-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
skipping to change at page 11, line 36 skipping to change at page 11, line 36
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
with a person, then the I2RS protocol and data models should provide
additional security that protects the person's privacy. An example
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
might be the client tracking such tethering. This protection MAY
require a variety of forms including: "operator-applied knobs", roles
that restrict personal access, data-models with specific "privacy
roles", and access filters.
3.6. Security of the environment
The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are
found in: [I-D.ietf-i2rs-security-environment-reqs].
4. Acknowledgement 4. Acknowledgement
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia
Atlas, and Jeff Haas for their contributions to the I2RS security Atlas, and Jeff Haas for their contributions to the I2RS security
requirements discussion and this document. The authors would like to requirements discussion and this document. The authors would like to
thank Bob Moskowitz for his review of the requirements. thank Bob Moskowitz for his review of the requirements.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 12, line 12 skipping to change at page 12, line 29
This is a document about security requirements for the I2RS protocol This is a document about security requirements for the I2RS protocol
and data modules. The whole document is security considerations. and data modules. The whole document is security considerations.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 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", draft-ietf-i2rs-architecture-13 (work in System", draft-ietf-i2rs-architecture-15 (work in
progress), February 2016. progress), April 2016.
[I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-10 (work in progress), February 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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>.
7.2. Informative References 7.2. Informative References
[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-03 (work in Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in
progress), March 2016. progress), March 2016.
[I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-10 (work in progress), February 2016.
[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-05 (work in progress), February 2016. requirements-07 (work in progress), May 2016.
[I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016.
[I-D.ietf-i2rs-traceability] [I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 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", draft-ietf-i2rs-traceability-07 (work Information Model", draft-ietf-i2rs-traceability-09 (work
in progress), February 2016. in progress), May 2016.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <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>.
Authors' Addresses Authors' Addresses
 End of changes. 24 change blocks. 
45 lines changed or deleted 72 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/