draft-ietf-i2rs-protocol-security-requirements-12.txt   draft-ietf-i2rs-protocol-security-requirements-13.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: March 30, 2017 J. Halpern Expires: March 30, 2017 J. Halpern
Ericsson Ericsson
September 26, 2016 September 26, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-12 draft-ietf-i2rs-protocol-security-requirements-13
Abstract Abstract
This presents security-related requirements for the I2RS protocol This presents security-related requirements for the I2RS protocol
which provides a new interface to the routing system described in the which provides a new interface to the routing system described in the
I2RS architecture document (RFC7921). The I2RS protocol is a re-use I2RS architecture document (RFC7921). The I2RS protocol is a re-use
protocol implemented by re-using portions of existing IETF protocols protocol implemented by re-using portions of existing IETF protocols
and adding new features to these protocols. The I2RS protocol re- and adding new features to these protocols. The I2RS protocol re-
uses security features of a secure transport (E.g. TLS, SSH, DTLS) uses security features of a secure transport (E.g. TLS, SSH, DTLS)
such as encryption, message integrity, mutual peer authentication, such as encryption, message integrity, mutual peer authentication,
and replay protection. The new security features I2RS adds are: a and replay protection. The new I2RS features to consider from a
priority mechanism to handle multi-headed write transactions, an security perspective are: a priority mechanism to handle multi-headed
opaque secondary identifier which identifies an application using the write transactions, an opaque secondary identifier which identifies
I2RS client, and an extremely constrained read-only non-secure an application using the I2RS client, and an extremely constrained
transport. This document provides the detailed requirements for read-only non-secure transport. This document provides the detailed
these security features. requirements for these security features.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5 2.2. Security Definitions . . . . . . . . . . . . . . . . . . 4
2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5
3. Security Features and Protocols: Re-used and New . . . . . . 7 3. Security Features and Protocols: Re-used and New . . . . . . 7
3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7 3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7
3.2. New Features Related to Security . . . . . . . . . . . . 8 3.2. New Features Related to Security . . . . . . . . . . . . 8
3.3. I2RS Protocol Security Requirements vs. IETF Management 3.3. I2RS Protocol Security Requirements vs. IETF Management
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10
4.1. I2RS Peers(agent and client) Identity Authentication . . 11 4.1. I2RS Peers(agent and client) Identity Authentication . . 10
4.2. Identity Validation Before Role-Based Message Actions . . 11 4.2. Identity Validation Before Role-Based Message Actions . . 11
4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12
4.4. Multi-Channel Transport: Secure Transport and Insecure 4.4. Multi-Channel Transport: Secure Transport and Insecure
Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Management Protocol Security . . . . . . . . . . . . . . 15 4.5. Management Protocol Security . . . . . . . . . . . . . . 15
4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 16
4.7. Security of the environment . . . . . . . . . . . . . . . 17 4.7. Security of the environment . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 system. 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. [RFC7921] describes the architecture from network routing systems. [RFC7921] describes the architecture
of this interface, and this documents assumes the reader is familiar of this interface, and this documents assumes the reader is familiar
with this architecture and its definitions. Section 2 highlights with this architecture and its definitions. Section 2 highlights
some of the references the reader is required to be familiar with. some of the references the reader is required to be familiar with.
The I2RS interface is instantiated by the I2RS protocol connecting an The I2RS interface is instantiated by the I2RS protocol connecting an
I2RS client and an I2RS agent associated with a routing system. The I2RS client and an I2RS agent associated with a routing system. The
I2RS protocol is a re-use protocol implemented by re-using portions I2RS protocol is a re-use protocol implemented by re-using portions
of existing IETF protocols, and adding new features to these of existing IETF protocols, and adding new features to these
protocols. As a re-use protocol, it can be considered a higher-level protocols. As a re-use protocol, it can be considered a higher-level
protocol since it can be instantiated in multiple management protocol since it can be instantiated in multiple management
protocols (e.g. NETCONF [RFC6241] or RESTCONF protocols (e.g. NETCONF [RFC6241] or RESTCONF
[I-D.ietf-netconf-restconf]) operating over a secure transport. The [I-D.ietf-netconf-restconf]) operating over a secure transport. The
security for the I2RS protocol comes from the managmenet protocols security for the I2RS protocol comes from the management protocols
operating over a a secure transport which carries traffic over operating over a a secure transport.
multiple links.
This document is part of the requirements for I2RS protocol which This document is part of the requirements for I2RS protocol which
also include: also include:
o I2RS architecture [RFC7921], o I2RS architecture [RFC7921],
o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state],
o publication/subscription requirements [RFC7922], and o publication/subscription requirements [RFC7922], and
o traceability [RFC7923]. o traceability [RFC7923].
Since the I2RS "higher-level" protocol changes the interface to the Since the I2RS "higher-level" protocol changes the interface to the
routing systems, it is important that implementers understand the new routing systems, it is important that implementers understand the new
security requirements for the environment the I2RS protocol operates security requirements for the environment the I2RS protocol operates
in. These secuirty requirements for the I2RS environment are in. These security requirements for the I2RS environment are
specified in [I-D.ietf-i2rs-security-environment-reqs], and the specified in [I-D.ietf-i2rs-security-environment-reqs]; and the
summary of the I2RS protocol security environment found in the I2RS summary of the I2RS protocol security environment is found in the
Architecture [RFC7920]. I2RS Architecture [RFC7920].
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which
support encryption, message integrity, peer authentication, and key support encryption, message integrity, peer authentication, and key
distribution protocols. Optionally, implementers may utilize AAA distribution protocols. Optionally, implementers may utilize AAA
protocols (Radius over TLS or Diameter over TLS) to securely protocols (Radius over TLS or Diameter over TLS) to securely
distribute identity information. distribute identity information.
Section 3 provides an overview of security features and protocols Section 3 provides an overview of security features and protocols
being re-used (section 3.1) and the new security features being being re-used (section 3.1) and the new security features being
required (section 3.2). Section 3 also explores how existing and new required (section 3.2). Section 3 also explores how existing and new
security features and protocols would be paired with existing IETF security features and protocols would be paired with existing IETF
management protocols (section 3.3). management protocols (section 3.3).
The new features I2RS extends to these protocols are a priority The new features I2RS extends to these protocols are a priority
mechanism to handle multi-headed writes, an opaque secondary mechanism to handle multi-headed writes, an opaque secondary
identifier to allow traceability of an application utilizing a identifier to allow traceability of an application utilizing a
specific I2RS client to communicate with an I2RS agent, and insecure specific I2RS client to communicate with an I2RS agent, and insecure
transport constrained to be utilized only for read-only data which transport constrained to be utilized only for read-only data, which
publically available data (e.g. public BGP Events, public telemetry may include publically available data (e.g. public BGP Events, public
information, web service available) and some legacy data. telemetry information, web service availability) and some legacy
data.
Section 4 provides the I2RS protocol security requirements by the Section 4 provides the I2RS protocol security requirements by the
following security features: following security features:
o peer identity authentication (section 4.1), o peer identity authentication (section 4.1),
o peer identity validation before role-based message actions o peer identity validation before role-based message actions
(section 4.2) (section 4.2)
o peer identity and client redundancy (section 4.3), o peer identity and client redundancy (section 4.3),
skipping to change at page 7, line 44 skipping to change at page 7, line 39
2. DTLS over UDP with replay detection and anti-DoS stateless cookie 2. DTLS over UDP with replay detection and anti-DoS stateless cookie
mechanism required for the I2RS protocol, and the I2RS protocol mechanism required for the I2RS protocol, and the I2RS protocol
allow DTLS options of record size negotiation and and conveyance allow DTLS options of record size negotiation and and conveyance
of "don't" fragment bits to be optional in deployments. of "don't" fragment bits to be optional in deployments.
3. HTTP over TLS (over TCP or SCTP), and 3. HTTP over TLS (over TCP or SCTP), and
4. HTTP over DTLS (with the requirements and optional features 4. HTTP over DTLS (with the requirements and optional features
specified above in item 2). specified above in item 2).
The following protocols will need to be extended to provide The following protocols would need to be extended to provide
confidentiality, data integrity, peer authentication, and key confidentiality, data integrity, peer authentication, and key
distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML
layer (over SCTP). These protocols will need extensions to run over layer (over SCTP). These protocols will need extensions to run over
a secure transport (TLS or DTLS) (see section 3.3 for details). a secure transport (TLS or DTLS) (see section 3.3 for details).
The specific type of key management protocols an I2RS secure The specific type of key management protocols an I2RS secure
transport uses depends on the transport. Key management protocols transport uses depends on the transport. Key management protocols
utilized for the I2RS protocols SHOULD support automatic rotation. utilized for the I2RS protocols SHOULD support automatic rotation.
An I2RS implementer may use AAA protocols over secure transport to An I2RS implementer may use AAA protocols over secure transport to
skipping to change at page 16, line 18 skipping to change at page 16, line 13
mechanism for message traceability (requirements in [RFC7922]) mechanism for message traceability (requirements in [RFC7922])
that supports the tracking higher-layer functions run across that supports the tracking higher-layer functions run across
secure connection or a non-secure transport. secure connection or a non-secure transport.
Explanation: Explanation:
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, the I2RS higher-layer and traffic statistics. To achieve this, the I2RS higher-layer
protocol (e.g NETCONF) needs to have access control (NACM [RFC6536]) protocol (e.g NETCONF) requires access control (NACM [RFC6536]) for
to sensitive data needs to be provided, and the confidentiality sensitive data needs to be provided; and the confidentiality
protection on such data during transportation needs to be enforced. protection on such data during transportation needs to be enforced.
Integrity of data is important even if the I2RS protocol is sending Integrity of data is important even if the I2RS protocol is sending
non-confidential data over an insecure connection. The ability to non-confidential data over an insecure connection. The ability to
trace I2RS protocol messages that enact I2RS transactions provides a trace I2RS protocol messages that enact I2RS transactions provides a
minimal aid to helping operators check how messages enact minimal aid to helping operators check how messages enact
transactions on a secure or insecure transport. transactions on a secure or insecure transport.
4.6. Role-Based Data Model Security 4.6. Role-Based Data Model Security
skipping to change at page 17, line 20 skipping to change at page 17, line 15
it is operating over multiple connections at the same time. NETCONF it is operating over multiple connections at the same time. NETCONF
can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP
over a secure transport (TLS). SCTP [RFC4960] provides security for over a secure transport (TLS). SCTP [RFC4960] provides security for
multiple streams plus end-to-end transport of data. Some I2RS multiple streams plus end-to-end transport of data. Some I2RS
functions may wish to operate over DTLS which runs over UDP functions may wish to operate over DTLS which runs over UDP
([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]). ([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]).
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.
One example of I2RS privacy concerns related to a person is if I2RS While I2RS clients are expected to be related to network devices and
agent is running on someone's phone to control tethering, and the not individual people, if an I2RS client ran on a person's phone,
I2RS client might be the client tracking such tethering. This then privacy protection to anonymize any data relating to a person's
protection of the privacy of the person involves the I2RS client and identity or location would be needed.
the I2RS agent communication anonymizing the any data related to the
person's identity or locatino.
A variety of forms of managemen may set policy on roles: "operator- A variety of forms of managemen may set policy on roles: "operator-
applied knobs", roles that restrict personal access, data-models with applied knobs", roles that restrict personal access, data-models with
specific "privacy roles", and access filters. specific "privacy roles", and access filters.
4.7. Security of the environment 4.7. Security of the environment
The security for the implementation of a protocol also considers the The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are protocol environment. The environmental security requirements are
found in: [I-D.ietf-i2rs-security-environment-reqs]. found in: [I-D.ietf-i2rs-security-environment-reqs].
 End of changes. 12 change blocks. 
30 lines changed or deleted 28 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/