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