diff options
Diffstat (limited to 'doc/rfc/rfc8241.txt')
| -rw-r--r-- | doc/rfc/rfc8241.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8241.txt b/doc/rfc/rfc8241.txt new file mode 100644 index 0000000..a2e16af --- /dev/null +++ b/doc/rfc/rfc8241.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Hares +Request for Comments: 8241 Huawei +Category: Informational D. Migault +ISSN: 2070-1721 J. Halpern + Ericsson + September 2017 + + + Interface to the Routing System (I2RS) Security-Related Requirements + +Abstract + + This document presents security-related requirements for the + Interface to the Routing System (I2RS) protocol, which provides a new + interface to the routing system described in the I2RS architecture + document (RFC 7921). The I2RS protocol is implemented by reusing + portions of existing IETF protocols and adding new features to them. + One such reuse is of the security features of a secure transport + (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, + Datagram TLS (DTLS)) such as encryption, message integrity, mutual + peer authentication, and anti-replay protection. The new I2RS + features to consider from a security perspective are as follows: a + priority mechanism to handle multi-headed write transactions, an + opaque secondary identifier that identifies an application using the + I2RS client, and an extremely constrained read-only non-secure + transport. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8241. + + + + + + + + + +Hares, et al. Informational [Page 1] + +RFC 8241 I2RS Security Requirements September 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + 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. Terminology and Concepts ........................................4 + 2.1. Requirements Language ......................................4 + 2.2. Security Terminology .......................................4 + 2.3. I2RS-Specific Terminology ..................................5 + 2.4. Concepts ...................................................5 + 3. Security Features and Protocols: Reused and New .................6 + 3.1. Security Protocols Reused by the I2RS Protocol .............6 + 3.2. New Features Related to Security ...........................7 + 3.3. I2RS Protocol Security Requirements vs. IETF + Management Protocols .......................................8 + 4. Security-Related Requirements ..................................10 + 4.1. I2RS Peer (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 and Non-Secure ............13 + 4.5. Management Protocol Security ..............................15 + 4.6. Role-Based Data Model Security ............................16 + 4.7. Security of the Environment ...............................17 + 5. IANA Considerations ............................................17 + 6. Security Considerations ........................................17 + 7. References .....................................................18 + 7.1. Normative References ......................................18 + 7.2. Informative References ....................................18 + Acknowledgements ..................................................20 + Authors' Addresses ................................................20 + + + + + + + + +Hares, et al. Informational [Page 2] + +RFC 8241 I2RS Security Requirements September 2017 + + +1. Introduction + + The Interface to the Routing System (I2RS) protocol provides read and + write 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 document assumes the reader + is familiar with this architecture and its definitions. + + 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 implemented by reusing portions of existing IETF + protocols and adding new features to them. As a reuse protocol, it + can be considered a higher-layer protocol because it can be + instantiated in multiple management protocols (e.g., NETCONF + [RFC6241] or RESTCONF [RFC8040]) operating over a secure transport. + These protocols are what provide its security. + + This document is part of a suite of documents outlining requirements + for the I2RS protocol, which also includes the following: + + o "An Architecture for the Interface to the Routing System" + [RFC7921] + + o "I2RS Ephemeral State Requirements" [RFC8242] + + o "Interface to the Routing System (I2RS) Traceability: Framework + and Information Model" (which discusses traceability) [RFC7923] + + o "Requirements for Subscription to YANG Datastores" (which + highlights the publication/subscription requirements) [RFC7922] + + Since the I2RS "higher-layer" 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. A summary of the I2RS protocol security environment is found in + the I2RS architecture [RFC7921]. + + I2RS reuses the secure transport protocols (TLS, SSH, DTLS) that + support encryption, message integrity, peer authentication, and key + distribution protocols. Optionally, implementers may utilize + Authentication, Authorization, and Accounting (AAA) protocols (Radius + over TLS or Diameter over TLS) to securely distribute identity + information. + + Section 2 highlights some of the terminology and concepts that the + reader is required to be familiar with. + + + + +Hares, et al. Informational [Page 3] + +RFC 8241 I2RS Security Requirements September 2017 + + + Section 3 provides an overview of security features and protocols + being reused (Section 3.1), lists the new security features being + required (Section 3.2), and 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 non- + secure transport constrained to be used only for read-only data, + which may include publicly 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 of several + security features. Protocols designed to be I2RS higher-layer + protocols need to fulfill these security requirements. + +2. Terminology and Concepts + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Security Terminology + + This document uses the terminology found in [RFC4949] and [RFC7921]. + Specifically, this document reuses the following terms from + [RFC4949]: + + o access control + o authentication + o data confidentiality + o data integrity + o data privacy + o identity + o identifier + o mutual authentication + o role + o role-based access control + o security audit trail + o trust + + + + +Hares, et al. Informational [Page 4] + +RFC 8241 I2RS Security Requirements September 2017 + + + [RFC7922] describes traceability for the I2RS interface and the I2RS + protocol. Traceability is not equivalent to a security audit trail + or simple logging of information. A security audit trail may utilize + traceability information. + +2.3. I2RS-Specific Terminology + + This document discusses the security of the multiple I2RS + communication channels that operate over the higher-layer I2RS + protocol. The higher-layer I2RS protocol combines a secure transport + and I2RS contextual information, and it reuses IETF protocols and + data models to create the secure transport and the contextual + information driven by the I2RS data model. To describe how the I2RS + higher-layer protocol combines other protocols, the following terms + are used: + + I2RS component protocols + + Protocols that are reused and combined to create the I2RS higher- + layer protocol. + + I2RS secure transport component protocols (required) + + Secure transport protocols that combine to support the I2RS + higher-layer protocol. + + I2RS management component protocols (required) + + Management protocols that combine to provide the management- + information context for the I@RS higher-layer protocol. + + I2RS AAA component protocols (optional) + + AAA protocols supporting the I2RS higher-layer protocol. + +2.4. Concepts + + The reader should be familiar with the pervasive security + requirements in [RFC7258]. + + This document uses the following concepts from the I2RS architecture + [RFC7921] listed below with their respective section numbers from + said RFC: + + o I2RS client, agent, and protocol (Section 2) + + o I2RS higher-layer protocol (Section 7.2) + + + + +Hares, et al. Informational [Page 5] + +RFC 8241 I2RS Security Requirements September 2017 + + + o scope: read, notification, identity, and write (Section 2) + + o identity and secondary identity (Section 2) + + o roles or security rules (Section 2) + + o routing system/subsystem (Section 2) + + o I2RS assumed security environment (Section 4) + + o I2RS identity and authentication (Section 4.1) + + o scope of Authorization in I2RS client and agent (Section 4.2) + + o client redundancy with a single client identity (Section 4.3), + + o restrictions on I2RS in personal devices (Section 4.4) + + o communication channels and I2RS higher-layer protocol + (Section 7.2) + + o active communication versus connectivity (Section 7.5) + + o multi-headed control (Section 7.8) + + o transaction, message, multi-message atomicity (Section 7.9) + +3. Security Features and Protocols: Reused and New + +3.1. Security Protocols Reused by the I2RS Protocol + + I2RS requires a secure transport protocol and key distribution + protocols. The secure transport for I2RS requires one to provide + peer authentication. In addition, the features required for I2RS + messages are confidentiality, authentication, and replay protection. + According to [RFC8095], the secure transport protocols that support + peer authentication, confidentiality, data integrity, and replay + protection are the following: + + 1. TLS [RFC5246] over TCP or Stream Control Transmission Protocol + (SCTP) + + 2. DTLS over UDP with replay detection and an anti-DoS stateless + cookie mechanism required for the I2RS protocol and the DTLS + options of record-size negotiation and conveyance of the Don't + Fragment (DF) bit are set for IPv4, or no fragmentation extension + headers for IPv6 to be optional in deployments are allowed by the + I2RS protocol + + + +Hares, et al. Informational [Page 6] + +RFC 8241 I2RS Security Requirements September 2017 + + + 3. HTTP over TLS (over TCP or SCTP) + + 4. HTTP over DTLS (with the requirements and optional features + specified above in item 2) + + As detailed in Section 3.3, the following protocols would need to be + extended to provide confidentiality, data integrity, peer + authentication, and key distribution and to run over a secure + transport (TLS or DTLS): + + o IP Flow Information Export (IPFIX) over SCTP, TCP, or UDP + + o Forwarding and Control Element Separation (ForCES) Transport + Mapping Layer (TML) over SCTP + + 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 + distribute the identities for the I2RS client, I2RS agent, and role- + authorization information. Two AAA protocols are as follows: + Diameter [RFC6733] and Radius [RFC2865]. To provide I2RS peer + identities with the best security, the AAA protocols MUST be run over + a secure transport (Diameter over secure transport (TLS over TCP) + [RFC6733]), Radius over a secure transport (TLS) [RFC6614]). + +3.2. New Features Related to Security + + The new features are priority, an opaque secondary identifier, and a + non-secure protocol for read-only data constrained to specific + standard usages. The I2RS protocol allows multi-headed control by + several I2RS clients. This multi-headed control is based on the + assumption that the operator deploying the I2RS clients, I2RS agents, + and the I2RS protocol will coordinate the read, write, and + notification scope so the I2RS clients will not contend for the same + write scope. However, just in case there is an unforeseen overlap of + I2RS clients attempting to write a particular piece of data, the I2RS + architecture [RFC7921] provides the concept of each I2RS client + having a priority. The I2RS client with the highest priority will + have its write succeed. This document specifies requirements for + this new concept of priority (see Section 4.3). + + The opaque secondary identifier identifies an application that uses + communication from the I2RS client to I2RS agent to manage the + routing system. The secondary identifier is opaque to the I2RS + protocol. In order to protect personal privacy, the secondary + identifier should not contain identifiable personal information. + + + +Hares, et al. Informational [Page 7] + +RFC 8241 I2RS Security Requirements September 2017 + + + The last new feature related to I2RS security is the ability to allow + nonconfidential data to be transferred over a non-secure transport. + It is expected that most I2RS data models will describe information + that will be transferred with confidentiality. Therefore, any model + that transfers data over a non-secure transport is marked. The use + of a non-secure transport is optional, and an implementer SHOULD + create knobs that allow data marked as nonconfidential to be sent + over a secure transport. + + Nonconfidential data can only be data with read-scope or + notification-scope transmission of events. Nonconfidential data + cannot have write-scope or notification-scope configuration. + Examples of nonconfidential data would be the telemetry information + that is publicly known (e.g., BGP route-views data or website status + data) or some legacy data (e.g., interface) that cannot be + transported using secure transport. The IETF I2RS data models MUST + indicate (in the model) the specific data that is nonconfidential. + + Most I2RS data models will expect that the information described in + the model will be transferred with confidentiality. + +3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols + + Figure 1 provides a partial list of the candidate management + protocols. It also lists the secure transports each protocol + supports. The column on the right of the table indicates whether or + not the transport protocol will need I2RS security extensions. + + + + + + + + + + + + + + + + + + + + + + + + +Hares, et al. Informational [Page 8] + +RFC 8241 I2RS Security Requirements September 2017 + + + Management I2RS Security + Protocol Transport Protocol Extensions + ========= ===================== ================= + NETCONF TLS over TCP (*1) None required (*2) + + RESTCONF HTTP over TLS with None required (*2) + X.509v3 certificates, + certificate validation, + mutual authentication: + 1) authenticated + server identity, + 2) authenticated + client identity + (*1) + + ForCES TML over SCTP Needs an extension to + (*1) TML to run TML over + TLS over SCTP, or + DTLS with options for + replay protection + and anti-DoS stateless + cookie mechanism. + (DTLS record size + negotiation and conveyance + of DF bits are optional). + The IPsec mechanism is + not sufficient for + I2RS traveling over + multiple hops + (router + link) (*2) + + IPFIX SCTP, TCP, UDP Needs an extension + TLS or DTLS for to support TLS or DTLS with + secure client (*1) options for replay protection + and anti-DoS stateless + cookie mechanism. + (DTLS record size + negotiation and conveyance + of DF bits are optional) + + + *1 - Key management protocols MUST support appropriate key + rotation. + + *2 - Identity and role authorization distributed by Diameter or + Radius MUST use Diameter over TLS or Radius over TLS. + + Figure 1: Candidate Management Protocols and Their Secure Transports + + + +Hares, et al. Informational [Page 9] + +RFC 8241 I2RS Security Requirements September 2017 + + +4. Security-Related Requirements + + This section discusses security requirements based on the following + security functions: + + 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) + + o multi-channel transport requirements: Secure transport and non- + secure Transport (Section 4.4) + + o management protocol security requirements (Section 4.5) + + o role-based security (Section 4.6) + + o security environment (Section 4.7) + + The I2RS protocol depends upon a secure transport layer for peer + authentication, data integrity, confidentiality, and replay + protection. The optional non-secure transport can only be used for a + restricted set of data available publicly (events or information) or + a select set of legacy data. Data passed over the non-secure + transport channel MUST NOT contain any data that identifies a person. + +4.1. I2RS Peer (Agent and Client) Identity Authentication + + Requirements: + + SEC-REQ-01: All I2RS clients and agents MUST have an identity and + at least one unique identifier for each party in the I2RS protocol + context. + + SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for + mutual identification of the I2RS client and agent. + + SEC-REQ-03: Identifier distribution and the loading of these + identifiers into the I2RS agent and client SHOULD occur outside + the I2RS protocol prior to the I2RS protocol establishing a + connection between I2RS client and agent. AAA protocols MAY be + used to distribute these identifiers, but other mechanism can be + used. + + + + + + +Hares, et al. Informational [Page 10] + +RFC 8241 I2RS Security Requirements September 2017 + + + Explanation: + + These requirements are for I2RS peer (I2RS agent and client) + authentication. A secure transport (e.g., TLS) will authenticate + based on these identities, but these identities are for the I2RS + management layer. A AAA protocol distributing I2RS identity + information SHOULD transport its information over a secure transport. + +4.2. Identity Validation before Role-Based Message Actions + + Requirements: + + SEC-REQ-04: An I2RS agent receiving a request from an I2RS client + MUST confirm that the I2RS client has a valid identity. + + SEC-REQ-05: An I2RS client receiving an I2RS message over a secure + transport MUST confirm that the I2RS agent has a valid identifier. + + SEC-REQ-06: An I2RS agent receiving an I2RS message over a non- + secure transport MUST confirm that the content is suitable for + transfer over such a transport. + + Explanation: + + Each I2RS client has a scope based on its identity and the security + roles (read, write, or events) associated with that identity, and + that scope must be considered in processing an I2RS message sent on a + communication channel. An I2RS communication channel may utilize + multiple transport sessions or establish a transport session and then + close the transport session. Therefore, it is important that the + I2RS peers operate utilizing valid peer identities when a message is + processed rather than checking if a transport session exists. + + During the time period when a secure transport session is active, the + I2RS agent SHOULD assume that the I2RS client's identity remains + valid. Similarly, while a secure connection exists that included + validating the I2RS agent's identity and a message is received via + that connection, the I2RS client SHOULD assume that the I2RS agent's + identity remains valid. + + The definition of what constitutes a valid identity or a valid + identifier MUST be defined by the I2RS protocol. + + + + + + + + + +Hares, et al. Informational [Page 11] + +RFC 8241 I2RS Security Requirements September 2017 + + +4.3. Peer Identity, Priority, and Client Redundancy + + Requirements: + + SEC-REQ-07: Each I2RS identifier MUST be associated with just one + priority. + + SEC-REQ-08: Each identifier is associated with one secondary + identifier during a particular I2RS transaction (e.g., read/write + sequence), but the secondary identifier may vary during the time a + connection between the I2RS client and I2RS agent is active. + + Explanation: + + The I2RS architecture also allows multiple I2RS clients with unique + identities to connect to an I2RS agent (see Section 7.8 of + [RFC7921]). The I2RS deployment using multiple clients SHOULD + coordinate this multi-headed control of I2RS agents by I2RS clients + so no conflict occurs in the write scope. However, in the case of + conflict on a write-scope variable, the error resolution mechanisms + defined by the I2RS architecture multi-headed control (Section 7.8 of + [RFC7921]) allow the I2RS agent to deterministically choose one I2RS + client. The I2RS client with highest priority is given permission to + write the variable, and the second client receives an error message. + + A single I2RS client may be associated with multiple applications + with different tasks (e.g., weekly configurations or emergency + configurations). The secondary identity is an opaque value that the + I2RS client passes to the I2RS agent so that this opaque value can be + placed in the tracing file or event stream to identify the + application using the communication from I2RS client to agent. The + I2RS client is trusted to simply assert the secondary identifier. + + One example of the use of the secondary identity is the situation + where an operator of a network has two applications that use an I2RS + client. The first application is a weekly configuration application + that uses the I2RS protocol to change configurations. The second + application allows operators to makes emergency changes to routers in + the network. Both of these applications use the same I2RS client to + write to an I2RS agent. In order for traceability to determine which + application (weekly configuration or emergency) wrote some + configuration changes to a router, the I2RS client sends a different + opaque value for each of the applications. The weekly configuration + secondary opaque value could be "xzzy-splot" and the emergency + secondary opaque value could be "splish-splash". + + + + + + +Hares, et al. Informational [Page 12] + +RFC 8241 I2RS Security Requirements September 2017 + + + A second example is if the I2RS client is used for the monitoring of + critical infrastructure. The operator of a network using the I2RS + client may desire I2RS client redundancy where the monitoring + application with the I2RS client is deployed on two different boxes + with the same I2RS client identity (see Section 4.3 of [RFC7921]). + These two monitoring applications pass to the I2RS client whether the + application is the primary or back-up application, and the I2RS + client passes this information in the I2RS secondary identifier, as + the figure below shows. The primary application's secondary + identifier is "primary-monitoring", and the back-up application + secondary identifier is "backup-monitoring". The I2RS tracing + information will include the secondary identifier information along + with the transport information in the tracing file in the agent. + + Application A--I2RS client--Secure transport(#1) + [I2RS identity 1, secondary identifier: "primary-monitoring"]--> + + Application B--I2RS client--Secure transport(#2) + [I2RS identity 1, secondary identifier: "backup-monitoring"]--> + + Figure 2: Primary and Back-Up Application for Monitoring + Identification Sent to Agent + +4.4. Multi-Channel Transport: Secure and Non-Secure + + Requirements: + + 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 non-secure transport. The default transport is a secure + transport, and this secure transport is mandatory to implement in + all I2RS agents and in any I2RS client that a) performs a write + scope transaction that is sent to the I2RS agent or b) configures + an Event Scope transaction. This secure transport is mandatory to + use on any I2RS client's Write transaction or the configuration of + an Event Scope transaction. + + SEC-REQ-10: The secure transport MUST provide data + confidentiality, data integrity, and practical replay prevention. + + SEC-REQ-11: The I2RS client and I2RS agent SHOULD implement + mechanisms that mitigate DoS attacks. This means the secure + transport must support DoS prevention. For the non-secure + transport, the I2RS higher-layer protocol MUST contain a transport + management layer that considers the detection of DoS attacks and + provides a warning over a secure transport channel. + + + + + +Hares, et al. Informational [Page 13] + +RFC 8241 I2RS Security Requirements September 2017 + + + SEC-REQ-12: A secure transport MUST be associated with a key + management solution that can guarantee that only the entities + having sufficient privileges can get the keys to encrypt/decrypt + the sensitive data. + + SEC-REQ-13: A machine-readable mechanism to indicate that a data + model contains nonconfidential data MUST be provided. A non- + secure transport MAY be used to publish only read-scope or + notification-scope data if the associated data model indicates + that the data in question is nonconfidential. + + SEC-REQ-14: The I2RS protocol MUST be able to support multiple + secure transport sessions providing protocol and data + communication between an I2RS agent and client. However, a single + connection between I2RS agent and client MAY elect to use a single + secure transport session or a single non-secure transport session + conforming to the requirements above. + + SEC-REQ-15: Deployment configuration knobs SHOULD be created to + allow operators to send "nonconfidential" read scope (data or + event streams) over a secure transport. + + SEC-REQ-16: The I2RS protocol makes use of both secure and non- + secure transports, but this use MUST NOT be done in any way that + weakens the secure transport protocol used in the I2RS protocol or + other contexts that do not have this requirement for mixing secure + and non-secure modes of operation. + + Explanation: + + The I2RS architecture defines three scopes: read, write, and + notification. Non-secure data can only be used for read and + notification scopes of "nonconfidential data". The configuration of + ephemeral data in the I2RS agent uses write scope either for data or + for configuration of event notification streams. The requirement to + use secure transport for configuration prevents accidental or + malevolent entities from altering the I2RS routing system through the + I2RS agent. + + It is anticipated that the passing of most I2RS ephemeral state + operational statuses SHOULD be done over a secure transport. + + In most circumstances, the secure transport protocol will be + associated with a key management system. Most deployments of the + I2RS protocol will allow for automatic key management systems. Since + the data models for the I2RS protocol will control key routing + functions, it is important that deployments of I2RS use automatic key + management systems. + + + +Hares, et al. Informational [Page 14] + +RFC 8241 I2RS Security Requirements September 2017 + + + Per BCP 107 [RFC4107], while key management systems SHOULD be + automatic, the systems MAY be manual in the following scenarios: + + a) The environment has limited bandwidth or high round-trip times. + + b) The information being protected has low value. + + c) The total volume of traffic over the entire lifetime of the long- + term session key will be very low. + + d) The scale of the deployment is limited. + + Operators deploying the I2RS protocol selecting manual key management + SHOULD consider both short- and medium-term plans. Deploying + automatic systems initially may save effort in the long term. + +4.5. Management Protocol Security + + Requirements: + + SEC-REQ-17: In a critical infrastructure, certain data within + routing elements is sensitive and read/write operations on such + data SHOULD be controlled in order to protect its confidentiality. + To achieve this, higher-layer protocols MUST utilize a secure + transport, and they SHOULD provide access-control functions to + protect confidentiality of the data. + + SEC-REQ-18: An integrity protection mechanism for I2RS MUST be + provided that will be able to ensure the following: + + 1) the data being protected is not modified without detection + during its transportation, + + 2) the data is actually from where it is expected to come from, + and + + 3) the data is not repeated from some earlier interaction the + higher-layer protocol (best effort). + + The I2RS higher-layer protocol operating over a secure transport + provides this integrity. The I2RS higher-layer protocol operating + over a non-secure transport SHOULD provide some way for the client + receiving nonconfidential read-scoped or event-scoped data over + the non-secure connection to detect when the data integrity is + questionable; and in the event of a questionable data integrity, + the I2RS client should disconnect the non-secure transport + connection. + + + + +Hares, et al. Informational [Page 15] + +RFC 8241 I2RS Security Requirements September 2017 + + + SEC-REQ-19: The I2RS higher-layer protocol MUST provide a + 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 to be 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) requires access control + (NETCONF Access Control Model [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 + nonconfidential data over a non-secure 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 non-secure transport. Contextual checks + on specific nonconfidential data sent over a non-secure connection + may indicate the data has been modified. + +4.6. Role-Based Data Model Security + + In order to make access control more manageable, the I2RS + architecture [RFC7921] specifies a "role" to categorize users into a + group (rather than handling them individually) for access-control + purposes (role-based access control). Therefore, an I2RS role + specifies the access control for a group as being read, write, or + notification. + + SEC-REQ-20: The rules around what I2RS security role is permitted + to access and manipulate what information over a secure transport + (which protects the data in transit) SHOULD ensure that data of + any level of sensitivity is reasonably protected from being + observed by those without permission to view it, so that privacy + requirements are met. + + SEC-REQ-21: Role security MUST work when multiple transport + connections are being used between the I2RS client and agent as + the I2RS architecture [RFC7921] describes. + + Sec-REQ-22: If an I2RS agent or client is tightly correlated with + a person, then the I2RS protocol and data models SHOULD provide + additional security that protects the person's privacy. + + + + +Hares, et al. Informational [Page 16] + +RFC 8241 I2RS Security Requirements September 2017 + + + Explanation: + + An I2RS higher-layer protocol uses a management protocol (e.g., + NETCONF, RESTCONF) to pass messages in order to enact I2RS + transactions. Role security must secure data (sensitive and normal + data) in a router even when 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 + [RFC6347], which runs over UDP ([RFC768]) and SCTP ([RFC5764]). + + Please note the security of the connection between application and + I2RS client is outside of the I2RS protocol or I2RS interface. + + 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 management 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. Implementers should review the summary of the + I2RS security environment in [RFC7921]. + +5. IANA Considerations + + This document does not require any IANA actions. + +6. Security Considerations + + This is a document about security requirements for the I2RS protocol + and data models. Security considerations for the I2RS protocol + include both the protocol and the security environment. + + + + + + + + + + + + +Hares, et al. Informational [Page 17] + +RFC 8241 I2RS Security Requirements September 2017 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic + Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, + June 2005, <https://www.rfc-editor.org/info/rfc4107>. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + <https://www.rfc-editor.org/info/rfc4949>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. + Nadeau, "An Architecture for the Interface to the Routing + System", RFC 7921, DOI 10.17487/RFC7921, June 2016, + <https://www.rfc-editor.org/info/rfc7921>. + + [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to + the Routing System (I2RS) Traceability: Framework and + Information Model", RFC 7922, DOI 10.17487/RFC7922, June + 2016, <https://www.rfc-editor.org/info/rfc7922>. + + [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements + for Subscription to YANG Datastores", RFC 7923, + DOI 10.17487/RFC7923, June 2016, + <https://www.rfc-editor.org/info/rfc7923>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +7.2. Informative References + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + <https://www.rfc-editor.org/info/rfc768>. + + + + + + +Hares, et al. Informational [Page 18] + +RFC 8241 I2RS Security Requirements September 2017 + + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, DOI 10.17487/RFC2865, June 2000, + <https://www.rfc-editor.org/info/rfc2865>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + <https://www.rfc-editor.org/info/rfc5764>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <https://www.rfc-editor.org/info/rfc6347>. + + [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration + Protocol (NETCONF) Access Control Model", RFC 6536, + DOI 10.17487/RFC6536, March 2012, + <https://www.rfc-editor.org/info/rfc6536>. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, + "Transport Layer Security (TLS) Encryption for RADIUS", + RFC 6614, DOI 10.17487/RFC6614, May 2012, + <https://www.rfc-editor.org/info/rfc6614>. + + [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + <https://www.rfc-editor.org/info/rfc6733>. + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + <https://www.rfc-editor.org/info/rfc8040>. + + + + +Hares, et al. Informational [Page 19] + +RFC 8241 I2RS Security Requirements September 2017 + + + [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, + Ed., "Services Provided by IETF Transport Protocols and + Congestion Control Mechanisms", RFC 8095, + DOI 10.17487/RFC8095, March 2017, + <https://www.rfc-editor.org/info/rfc8095>. + + [RFC8242] Haas, J. and S. Hares, "Interface to the Routing System + (I2RS) Ephemeral State Requirements", RFC 8242, + DOI 10.17487/RFC8242, September 2017, + <http://www.rfc-editor.org/info/rfc8242>. + +Acknowledgements + + The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric + Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, Dacheng Zhang, Alia + Atlas, and Jeff Haas for their contributions to the I2RS security + requirements discussion and this document. The authors would like to + thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia + Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their + review of these requirements. + +Authors' Addresses + + Susan Hares + Huawei + 7453 Hickory Hill + Saline, MI 48176 + United States of America + + Email: shares@ndzh.com + + + Daniel Migault + Ericsson + 8275 Trans Canada Route + Saint Laurent, QC H4S + Canada + + Email: daniel.migault@ericsson.com + + + Joel Halpern + Ericsson + United States of America + + Email: joel.halpern@ericsson.com + + + + + +Hares, et al. Informational [Page 20] + |