--- 1/draft-ietf-i2rs-security-environment-reqs-02.txt 2017-03-07 14:13:10.309825656 -0800 +++ 2/draft-ietf-i2rs-security-environment-reqs-03.txt 2017-03-07 14:13:10.369827044 -0800 @@ -1,305 +1,460 @@ I2RS WG D. Migault Internet-Draft J. Halpern Intended status: Informational Ericsson -Expires: May 19, 2017 S. Hares +Expires: September 8, 2017 S. Hares Huawei - November 15, 2016 + March 7, 2017 I2RS Environment Security Requirements - draft-ietf-i2rs-security-environment-reqs-02 + draft-ietf-i2rs-security-environment-reqs-03 Abstract This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of - the protocol used for I2RS. The I2RS protocol security requirements - set the security for the communication between I2RS client and agent - while the security environment requirements are rather intended for - deployment or implementations features independent of the I2RS - protocol. The environmental security requirements described in this - document provide the good security practices to be used with the I2RS - protocol so that I2RS protocol implementations can be securely - deployed and operated. + the protocol used for I2RS. The security environment requirements + are the good security practices to be used during implementation and + deployment of the code related to the new interface to routing system + (I2RS) so that I2RS implementations can be securely deployed and + operated. + + Environmental security requirements do not specify the I2RS protocol + seecurity requirements. This is done in another document (draft- + ietf-i2rs-protocol-security-requirements). 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/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 19, 2017. + This Internet-Draft will expire on September 8, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + 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 (http://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 Acronyms . . . . . . . . . . . . . . . . . . 4 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5 - 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7 - 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8 - 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 - 4. I2RS Access Control for Routing System Resources . . . . . . 10 - 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11 - 4.1.1. access control Enforcement Scope . . . . . . . . . . 12 - 4.1.2. Notification Requirements . . . . . . . . . . . . . . 13 - 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1.4. Sharing access control Information . . . . . . . . . 14 + 3.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7 + 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10 + 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11 + 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 + 4. I2RS Access Control for Routing System Resources . . . . . . 14 + 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14 + 4.1.1. access control Enforcement Scope . . . . . . . . . . 17 + 4.1.2. Notification Requirements . . . . . . . . . . . . . . 17 + 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1.4. Sharing access control Information . . . . . . . . . 18 4.1.5. Sharing Access Control in Groups of I2RS Clients and - Agents . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.1.6. Managing Access Control Policy . . . . . . . . . . . 17 - 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 18 - 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 19 - 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 20 - 4.2.3. Application and Access Control Policies . . . . . . . 21 - 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 22 - 5.1. Robustness Toward Programmability . . . . . . . . . . . . 22 - 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 23 - 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 5.2.2. Application Logic Control . . . . . . . . . . . . . . 24 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 9.2. Informative References . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + Agents . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1.6. Managing Access Control Policy . . . . . . . . . . . 22 + 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23 + 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23 + 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24 + 4.2.3. Application and Access Control Policies . . . . . . . 25 + 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26 + 5.1. Robustness Toward Programmability . . . . . . . . . . . . 26 + 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27 + 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 5.2.2. Application Logic Control . . . . . . . . . . . . . . 29 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 9.2. Informative References . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. The I2RS protocol security requirements - [I-D.ietf-i2rs-protocol-security-requirements] set the security for - the communication between I2RS client and agent while the security - environment requirements are rather intended for deployment or - implementations features independent of the I2RS protocol. The - environmental security requirements described in this document - provide the good security practices to be used with the I2RS protocol - so that I2RS protocol implementations can be securely deployed and - operate. These environment security address the security - considerations for I2RS protocol environment considered in the I2RS - Architecture [RFC7921] in order to provide a stable and secure - environment in which the dynamic programmatic interface to the - routing system (I2RS) should operates. + [I-D.ietf-i2rs-protocol-security-requirements] define the security + for the communication between I2RS client and agent. The security + environment requirements are good security practices to be used + during implementation and deployment of the I2RS protocol so that + I2RS protocol implementations can be securely deployed and operated. + These environment security requirements address the security + considerations described in the I2RS Architecture [RFC7921] required + to provide a stable and secure environment in which the dynamic + programmatic interface to the routing system (I2RS) should operates. Even though the I2RS protocol is mostly concerned with the interface between the I2RS client and the I2RS agent, the environmental security requirements must consider the entire I2RS architecture and specify where security functions may be hosted and what criteria should be met in order to address any new attack vectors exposed by deploying this architecture. Environment security for I2RS has to be considered the complete I2RS architecture and not only on the protocol interface. This document is structured as follows: o Section 2 describes the terminology used in this document, - o Section 3 describes how the I2RS plane can be contained or - isolated from existing management plane, control plane and - forwarding plane. + o Section 3 describes how the I2RS plane can be securely isolated + from the management plane, control plane and forwarding plane. - o the subsequent sections of the document focuses on the security - within the I2RS plane including: + The subsequent sections of the document focuses on the security + within the I2RS plane. - * Section 4 analyzes how the I2RS access control policies can be - deployed throughout the I2RS plane in order to only grant - access to the routing system resources to authorized components - with the authorized privileges. This includes providing a - robust communication system between the components. + o Section 4 analyzes how the I2RS access control policies can be + deployed throughout the I2RS plane in order to limit access to the + routing system resources to authorized components with the + authorized privileges. This analysis examines how providing a + robust communication system between the components aids the access + control. - * Section 5 details how I2RS keeps applications isolated from - another and without affecting the I2RS components. - applications may be independent, with different scopes, owned - by different tenants. In addition, the applications may modify - the routing system in an automatic way. + o Section 5 details how I2RS keeps applications isolated from + another and without affecting the I2RS components. Applications + may be independent, with different scopes, owned by different + tenants. In addition, the applications may modify the routing + system in an automatic way. - Motivations are placed before the requirements are given. + Motivations are described before the requirements are given. The reader is expected to be familiar with the I2RS problem statement [RFC7920], I2RS architecture, [RFC7921], traceability requirements [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security requirements [I-D.ietf-i2rs-protocol-security-requirements]. 2. Terminology and Acronyms - Environment Security Requirements : Security requirements specifying how the environment a protocol operates in needs to be secure. These requirements do not specify the protocol security requirements. - I2RS plane: The environment the I2RS process is running on. It includes the applications, the I2RS client and the I2RS agent. - I2RS user: The user of the I2RS client software or system. - - I2RS access control policies: policies controlling access of the - routing resources by applications. These policies are divided - into policies applied by the I2RS client regarding applications - and policies applied by the I2RS agent regarding I2RS clients. + - I2RS access control policies: The policies controlling access of + the routing resources by applications. These policies are + divided into policies applied by the I2RS client regarding + applications and policies applied by the I2RS agent regarding + I2RS clients. - I2RS client access control policies: The access control policies processed by the I2RS client. - I2RS agent access control policies: The access control policies processed by the I2RS agent. 2.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. I2RS Plane Isolation Isolating the I2RS plane from other network planes (the management, forwarding plane, and control planes ) is fundamental to the security - of the I2RS environment. Clearly differentiating I2RS components + of the I2RS environment. Clearly differentiating the I2RS components from the rest of the network device does the following: 1. protects the I2RS components from vulnerabilities in other parts - of the network, and + of the network, 2. protects other systems vital to the health of the network from vulnerabilities in the I2RS plane. Separating the I2RS plane from other network control and forwarding - planes is similar to the best common practice of containerizing - software into modules. However, the I2RS plane cannot be considered - as completely isolated from other planes so the interactions between - the I2RS plane and other planes should be identified and controlled. - The following is a brief description of how the I2RS plane positions - itself in regard to the other planes. + planes is similar to the best common practice of placing software + into software containers within modules with clear interfaces to + exterior modules. In a similar way, although the I2RS plane cannot + be completely isolated from other planes, it can be carefully + designed so the interactions between the I2RS plane and other planes + can be identified and controlled. The following is a brief + description of how the I2RS plane positions itself in regard to the + other planes. 3.1. I2RS Plane and Management plane The purpose of the I2RS plane is to provide a standard programmatic interface of the routing system resources to network oriented - applications. The control plane and forwarding planes are related to - routing protocols, and I2RS is positioned on top of the control plane - and forwarding plane. The management plane is usually vendor - specific and provides a broader control over the networking equipment - such as system service. Given the management plane's associated - privileges it is expected to be reserved to highly trusted users like - network administrators. + applications. Routing protocols often run in a control plane and + provide entries for the forwarding plane as shown in figure 1. The + I2RS plane which contains the I2RS applications, the I2RS client, the + north bound interface between the I2RS client and I2RS applications, + the I2RS protocol, the I2RS agent, and south bound API (SB API) to + the routing system. The communication interfaces in the I2RS plane + are shown on the the left hand side of the figure 1. - The I2RS plane and the management plane both interact with several - common elements on forwarding and packet processing devices. - [RFC7921] describes several of these interaction points such as the - local configuration, the static system state, routing, and signaling. - A routing resource may be accessed by different means (APIs, - applications) and different planes which creates potential overlaps. - Southbound APIs are often provided to limit the scope of the - management plane's and the I2RS plane's interaction with the routing - resources (as figure 1 shows). If there are conflicts in these - overlapping southbound APIs, the conflicts should be resolved in a - deterministic way. + The management plane contains the mangement application the + management client, the north bound API between the management client + and management application, the mangement server, the management + protocol (E.g. RESTCONF) between mangement client and management + server, and the south bound API between the management server and the + control plane. The communication interfaces associated with the + management plane are shown on the right hand side of figure 2. + + The I2RS plane and the management plane both interact with control + plane on which the routing systems operate. [RFC7921] describes + several of these interaction points such as the local configuration, + the static system state, routing, and signaling. A routing resource + may be accessed by I2RS plane, the mangement plane, or routing + protocol(s) which creates the potential for overlapping access. The + southbound APIs can limit the scope of the management plane's and the + I2RS plane's interaction with the routing resources. + + Security focus: + + Implementers need to carefully examine the southbound APIs from the + I2RS Plane and the management plane to determine if these APIs + overlap or conflict during use. If these APIs overlap or conflict, + these interactions can provide errors which are not traceable or + provide a risk for security intrusions between the two planes. APIs that interact with the - I2RS Plane and Management PLane + I2RS Plane and Management Plane I2RS applications Mangement applications || NB API NB API || || || I2RS plane management plane + || control plane configuration|| + || datastore datastore || || || ||SB API SB API || - ------------------------------------------- - | Routing Resources | - |(forwarding plane, control plane, system) | - +------------------------------------------+ + --------------------------------------- + | Routing System with protocols | + | control plane | + | (applied datastore) | + +-------------------------------------+ + | forwarding plane | + +-------------------------------------+ + | system | + +-------------------------------------+ Figure 1 - North Bound (NB) APIs and South Bound (SB) APIs - The I2RS applications may be provided with a northbound API by the - I2RS client (as figure 1 shows). Similarly, the management plane may - provide a northbound API to management application. The northbound - API from the management plane to the client application and the - northbound API from the I2RS plane to I2RS applications may overlap. - In case that these overlapping APIs between the have conflicts (e.g. - both want to access the same routing resource), the the conflicts - should be resolved in a deterministic way. + The north bound interface may also be a source of conflicting + interactions between the I2RS plane and the management plane. It is + important that conflicting interactions do not provide a deadlock + situation or allow a vulnerability due to data store leaking. - To resolve conflicts in a northbound APIs, the deterministic - resolution should have clear rules about which data plane with a - system takes precedence (wins during a conflict for resources). This - is important to prevent attacks that attempt to drive the two systems - into deadlock situation over which system has precedence (wins) +3.1.1. Deadlocks - In the interactions between the I2RS plane and the applications, and - the management plane and the application is it important to prevent - the following things: + How can a deadlock occur? - o the I2RS system "infecting" the management system with bad - information, + The I2RS applications and the management applications may both + interact with the Routing System. For example, I2RS applications may + set ephemeral state for an BGP routing process allowing a peer to + temporarily increase the maximum number of prefix it will accept. At + the same time, a management plane process may change a BGP Peer's + configuration for the maximum number of prefixes to decrease the + maximum number of prefixes. [RFC7921] suggests that implementations + SHOULD provide operator configurable knobs that will determine which + functions (I2RS or configuration management) has precedence in the + routing system, and that events should signal an I2RS agent if the + I2RS ephemeral state is overwritten. This is an example of policy + that prevents a deadlock situation for both the I2RS application and + the mangement application. - o the management system "infecting" the I2RS system with bad - information directly, + It is important that implementations include both policy knobs for + resolving the deadlocks between the the I2RS plane and the management + plane, and event signaling which reports deadlocks occuring within a + system supporting I2RS. + +3.1.2. Data Store leaking + + A vulnerability can occur if there is leakage between the I2RS + ephemeral control plane data store and the management plane's + configuration datastore. [I-D.ietf-netmod-revised-datastores] + describes a datastore architecture with control plane datastores + (such as the I2RS protocol's ephemeral datastore) being logically + different than the the configuration data store. The mixture of the + I2RS ephemeral configuration and management configuration is done by + the routing system code (specific to an implementation). The routing + system code resolves any conflict between I2RS control plane + configuration and the management plane configuration, and then + installs the state in the routing system. Implementation policy + determines which configuration state should be installed. + + The applied datastore provides information on what is installed in + each part of a system - including the routing system. The + operational state data store provides both the applied data store + information and additional operational state from the control plane + protocols and control plane datastore. + + Since it is the routing system code which mixing the configuration + from the I2RS control plane datastore and the management datastore to + create applied datastore for the routing system, this code must take + care to prevent: + + o the I2RS system "infecting" the management system configuration + datastore with information from the I2RS control plane data store, + + o the management system "infecting" the I2RS system data with data + not specifically imported by I2RS data models, o the management system indirectly "infecting" the I2RS system by - propagating improproper information from one system to another via + propagating improper information from one system to another via I2RS. - Prevention: + In this circumstance, we define "infecting" as inteferring with and + leading into a incoherent state. Planned interactions such as + interactions denoted in in two cooperating Yang data modules is not + incoherent state. + + For example, BGP configuration and BGP I2RS ephemeral state + configuration could have a defined interaction. The I2RS plane may + legitimately update a routing resource configured by the management + plane, or the reverse (the management plane updates a resource the + I2RS plane has configured) if the interactions are defined by Yang + modules or local policy. Infecting, is when the implementation is + updated by two processes resulting in an incoherent state. Indirect + "infecting", we define as as changes made by the I2RS plane that + cause changes in routing protocols which add state unexpected by the + management plane or the reverse (the mangement plane adding changes + in routing protocols the I2RS plane does not expect). + + Prevention for Data Store Leakage The primary protection in this space is going to need to be - validation rules on the data being sent/receive, notification of - changes that the I2RS agent sends the client, and other access - protections. + validation rules on: - In this circumstance, we define "infecting" as inteferring with and - leading into a incoherent state. The I2RS plane may update a routing - resource configured by the management plane, or the reverse (the - management plane updates a resource the I2RS plane has configured). - Indirect "infecting", we define as as changes made by the I2RS plane - that cause changes in routing protocols which add state unexpected by - the management plane or the reverse (the mangement plane adding - changes in routing protocols the I2RS plane does not expect). + o the data being sent/received by the I2RS agent (including + notification of changes that the I2RS agent sends the I2RS + client), + + o any data transferred between management datastores (configuration + or operational state) and I2RS ephemeral control plane data + stores; + + o data transferred between I2RS Agent and Routing system, + + o data transferred between a management server and the I2RS routing + system, + + o data transfered between I2RS agent and system (e.g. interfaces + ephemeral configuration), + + o data transferred between management server and the system (e.g. + interface configuration). + + The next few paragraphs will provide some ideas on how this might be + implemented. These suggest implementation policy should resolve what + is not resolved in the YANG Data module definitions. + + The Network Access Control Module (NACM) has been define to control + access to the configuration datastore via the management protocol + across a network. A similar network access control module could be + defined for the I2RS-NACM (per [I-D.ietf-netconf-rfc6536bis]. + Figure 2 shows how the I2RS-NACM could be created to support parallel + features with the management protocol (E.g. NETCONF) NACM. + + I2RS implementations may also need to define an access modules which + control access to the routing system (Routing Access Control Module + (RACM)) by policy. The I2RS-RACM would control how the I2RS agent + access the routing system through the SB API interface. In parallel, + the management system would have a RACM to control the SB API + interface (see figure 2). I2RS agent and the management server may + want to read/write system information interfaces or other system + functions. In order to prevent leakage between the I2RS system and + the management system, there needs to be system access control module + (SACM) that protects the jointly held data. + + I2RS- || (I2RS Mgt protocol || + NACM || Protocol) (E.g. NETCONF)|| NACM + ------- ---------- + I2RS ||I2RS Agent Mgt server|| + SACM || I2RS Control-DS config DS || SACM + -----|| (RACM) (RACM) ||=======|| + | ||SB API SB API || || + | +-----------------------------------+ || + | | Routing System with protocols | || + | | control plane | || + | | (applied datastore) | || + | | (operational state) | || + | +--------------||-------------------+ || + | | forwarding plane | || + | +--------------||-------------------+ || + ---| system |======|| + +-----------------------------------+ + + *Mgt = management + DS = Datastore + Control-DS = Control plane protocol data store + NACM = Network Access Control Module + RACM = Routing System Access Control Module + + figure 2 + + The I2RS clients and the I2RS agents also need a set of policy which + defines what can be received from the network or sent to the network. + + I2RS applications Mangement applications + || NB API MB API || + || (APP NAC policy) (APP NAC policy)|| + || I2RS client mgt client || + || (NAC policy) (NAC policy)|| + || || + I2RS protocol mgt protocol + (NETCONF/RESTCONF) + + figure 3 3.2. I2RS Plane and Forwarding Plane Applications hosted by the I2RS client belong to the I2RS plane. It is difficult to constrained these applications to the I2RS plane, or even to limit their scope within the I2RS plane. Applications using I2RS may also interact with components outside the I2RS plane. For - example an application may use an I2RS client to configure the - network or monitored events via an I2RS agent on a single machine, or - multiple I2RS agents each on a single machine. + example an application may use an management client to configure the + network and monitored events via an I2RS agent as figure 4 shows. + + +--------------------------------------+ + | Application | + +--------------------------------------+ + || NB API NB API || + || I2RS client mgt client || + || || + I2RS protocol mgt protocol + (NETCONF/RESTCONF) + + figure 4 Applications may also communicate with multiple I2RS clients in order to have a broader view of the current and potential states of the network and the I2RS plane itself. These varied remote communication relationships between applications using the I2RS protocol to change the forwarding plane make it possible for an individual application to be an effective attack vector against the operation of the network, a router's I2RS plane, the forwarding plane of the routing system, and other planes (management and control planes). @@ -325,113 +480,123 @@ The network control plane consists of the processes and protocols that discover topology, advertise reachability, and determine the shortest path between any location on the network and any destination. I2RS client configures, monitors or receives events via the I2RS agent's interaction with the routing system including the process that handling the control plane signaling protocols (BGP, ISIS, OSPF, etc.), route information databases (RIBs), and interface databases. In some situation to manage an network outage or to control traffic, the I2RS protocol may modify information in the route database or the configuration of routing process. While this - is not a part of normal processing, such action that allows the - network operator to bypass temporary outages or DoS attacks. + is not a part of normal processing, such action allows the network + operator to bypass temporary outages or DoS attacks. This capability to modify the routing process information carries with it the risk that the I2RS agent may alter the normal properties of the routing protocols which provide normal loop free routing in - the control plane. The information configured by the I2RS agent into - routing process or RIBs could cause problems, or state which is - inserted or deleted from routing processes (control traffic, - counters, etc.) could cause the control plan to fail to converge or - fail). + the control plane. For example, information configured by the I2RS + agent into routing process or RIBs could cause forwarding problems or + routing loops. As a second example, state which is inserted or + deleted from routing processes (control traffic, counters, etc.) + could cause the routing protocols to fail to converge or loop). Prevention measures: - The I2RS system can provide checks that during and after the problem - has been resolved that loop free routing is preserved. These checks - should check the preservation of all facets of routing including the - following: routing with loop free alternates, tunnelled interfaces, - virtual overlays, and other such constructions. + The I2RS implementation can provide internal checks that after a + routing system protocol changes that it is still operating correctly. + These checks would be specific to the routing protocol the I2RS Agent + would change. For example, if a BGP maximum prefix limit for a BGP + peer is lowered then the BGP peer should not allow the number + prefixes received from that peer to exceed this number. 3.4. Requirements To isolate I2RS transactions from other planes, it is required that: - SEC-ENV-REQ 1: application-to-routing system resources + SEC-ENV-REQ 1: Application-to-routing system resources communications should use an isolated communication channel. Various level of isolation can be considered. The highest level of isolation may be provided by using a physically isolated network. Alternatives may also consider logical isolation (e.g. using vLAN). In a virtual environment that shares a common infrastructure, encryption may also be used as a way to enforce isolation. Encryption can be added by using a secure transport required by the I2RS protocol security [I-D.ietf-i2rs-protocol-security-requirements], and sending the non-confidential I2RS data (designed for a non-secure transport) over a secure transport. SEC-ENV-REQ 2: The interface used by the routing element to receive I2RS transactions via the I2RS protocol (e.g. the IP - address) should be a dedicated physical or logical + address) SHOULD be a dedicated physical or logical interface. As previously, mentioned a dedicated physical interface may contribute to a higher isolation. Isolation may also be achieved by using a dedicated IP address or a dedicated port. - SEC-ENV-REQ 3: An I2RS agent should have permissions separate from - any other entity (for example any internal system - management processes or CLI processes). + SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for + interaction with each routing element and access to + the routing element should governed by policy + specific to the I2RS agent's interfaces (network, + routing system, system, or cross-datastore). Explanation: When the I2RS agent performs an action on a routing element, the - action is performed via process(es) associated to a routing process. + action is performed in a process (or processes) associated with a + routing process. For example, in a typical UNIX system, the user is + designated with a user id (uid) and belongs to groups designated by + group ids (gid). If such a user id (uid) and group id (gid) is the + identifier for the routing processes peforming routing tasks in the + control plane, then the I2RS Agent process would communicate with + these routing processes. It is important that the I2RS agent has its + own unique identifier and the routing processes have their own + identifier so that access control can uniquely filter data between + I2RS Agent and routing processes. - For example, in a typical UNIX system, the user is designated with a - user id (uid) and belongs to groups designated by group ids (gid). - If such a user id (uid) and group id (gid) is the identifier for the - routing processes peforming routing tasks in the control plane, then - the I2RS Agent process would communicate with these routing - processes. It is important that the I2RS agent has its own unique - identifier and the routing processes have their own identifier so - that access control can unique filter data between the processes. + The specific policy the the I2RS agent uses to filter data from the + network or from different processes on a system (routing, system or + cross-datastore) should be specific to the I2RS agent. For example, + the network access filter policy that the I2RS agent uses should be + uniquely identifiable from the configuration datastore updated by a + management protocol. SEC-ENV-REQ 4: I2RS plane should be informed when a routing system resource is modified by a user outside the I2RS plane access. Notifications from the control plane SHOULD not to flood the I2RS plane, and rate limiting (or summarization) is expected to be applied. These routing system notification MAY translated to the appropriate I2RS agent notifications, and passed to - various I2RS clients via notification relays. (This - requirements is also described in section 7.6 of - [RFC7921] for the I2RS client, and this section - extends it to the entire I2RS plane (I2RS agent, - client, and application). + various I2RS clients via notification relays. Explanation: - I2RS resource may be shared with the management plane and the control - plane. The I2RS routing system resource management is limited to the - I2RS plane. As such, update of I2RS routing system outside of the - I2RS plane may remain unnoticed unless and until explicitly notified - to the I2RS plane. Such notification is expected to trigger - synchronization of the I2RS resource state within each I2RS - component. This guarantees that I2RS resource are maintained in a - coherent state among the I2RS plane. In addition, depending on the - I2RS resource that is updated as well as the origin of the - modification performed, the I2RS access control policies may be - impacted. Further an I2RS client is more likely to update an I2RS - resources that has been updated by itself, then by the management - plane. + This requirements is also described in section 7.6 of [RFC7921] for + the I2RS client, and this section extends it to the entire I2RS plane + (I2RS agent, client, and application). + + A routing system resource may be accessed by the management plane or + control plane protocols so a change to a routing system resource may + remain unnoticed unless and until the routing system resource + notifies the I2RS plane by notifying the I2RS agent. Such + notification is expected to trigger synchronization of the I2RS + resource state between the I2RS agent and I2RS client - signalled by + the I2RS agent sending a notification to an I2RS client. + + The updated resource should be available in the operational state if + there is a yang module referencing that operational state, but this + is not always the case. In the cases, where operational state is not + updated, the I2RS SB (southbound) API should include the ability to + send a notification. SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite policy". Such policy defines how an I2RS is able to update and overwrite a resource set by a user outside the I2RS plane. Such hierarchy has been described in section 6.3 and 7.8 of [RFC7921] Explanation: A key part of the I2RS architecture is notification regarding routing @@ -460,35 +625,35 @@ agents can be located locally in a closed environment or distributed over open networks. The normal case for routing system management is over an open environment. Even in a closed environment access control policies should be carefully defined to be able to, in the future to carefully extend the I2RS plane to remote applications or remote I2RS clients. [I-D.ietf-i2rs-protocol-security-requirements] defines the security requirements of the I2RS protocol between the I2RS client and the I2RS agent over a secure transport. This section focuses on I2RS - access control architecture (section 5.1), access control policies of - the I2RS agent (section 5.2), the I2RS client (section 5.3), and the - application (section 5.4). + access control architecture (section 4.1), access control policies of + the I2RS agent (section 4.2), the I2RS client (section 4.3), and the + application (section 4.4). 4.1. I2RS Access Control Architecture Overview: Applications access to routing system resource via numerous intermediaries nodes. The application communicates with an I2RS client. In some cases, the I2RS client is only associated to a single application attached to one or more agents (case a and case b - in figure 2 below). In other cases, the I2RS client may be connected - to two applications (case c in figure 2 below), or the I2RS may act - as a broker (agent/client device shown in case d in the figure 2 + in figure 4 below). In other cases, the I2RS client may be connected + to two applications (case c in figure 4 below), or the I2RS may act + as a broker (agent/client device shown in case d in the figure 4 below). The I2RS client broker approach provides scalability to the I2RS architecture as it avoids that each application be registered to the I2RS agent. Similarly, the I2RS access control should be able to scale numerous applications. The goal of the security environment requirements in this section are to control the interactions between the applications and the I2RS client, and the interactions between the I2RS client and the I2RS agent. The key challenge is that the I2RS architecture puts the I2RS Client in control of the stream of communication (application to I2RS @@ -531,20 +696,22 @@ +-------------+ +--------+ | I2RS | | I2RS |==|I2RS |=====|agent 3/| |application 1| |client 1| ==|client 3+----+ +-------------+ +--------+ | +--+-----+ | | | | +-------------+ +--------+ | +-------+ +--|----+ | I2RS | |I2RS |===| |I2RS | |I2RS | |application 2|==|client 2| |agent 1| |agent 2| +-------------+ +--------+ +-------+ +-------+ + figure 4 + 4.1.1. access control Enforcement Scope SEC-ENV-REQ 6: I2RS access control should be performed through the whole I2RS plane. It should not be enforced by the I2RS agent only within the routing element. Instead, the I2RS client should enforce the I2RS client access control against applications and the I2RS agent should enforce the I2RS agent access control against the I2RS clients. The mechanisms for the I2RS client access control are not in scope of the I2RS @@ -571,44 +738,44 @@ Explanation: In case the I2RS client access control or the I2RS agent access control does not grant access to a routing system resource, the application should be able to determine whether its request has been rejected by the I2RS client or the I2RS agent as well as the reason that caused the reject. SEC-REQ-07 indicates the I2RS agent may reject the request because - the I2RS client is not an authorized I2RS client or have enough + the I2RS client is not an authorized I2RS client or lacks the privileges to perform the requested transaction (read, write, start notifications or logging). The I2RS client should be notified of the reason the I2RS agent rejected the transaction due to a lack of authorization or priviledges, and the I2RS client should return a message to the application indicating the I2RS agent reject the transacation with an indication of this reason. Similarly, if the I2RS client does not grant the access to the application, the I2RS client should also inform the application. An example of an error message could be, "Read failure: you do not have the read permission", "Write failure: you do not have write permission", or "Write failure: resource accessed by someone else". This requirement has been written in a generic manner as it concerns the following interactions: o interactions between the application and the I2RS client, - o interactions between the I2RS client and the I2RS agent (security - requirements are described by - [I-D.ietf-i2rs-protocol-security-requirements]), + o interactions between the I2RS client and the I2RS agent at a + content level (Protocol security requirements are described by + [I-D.ietf-i2rs-protocol-security-requirements]), and - o and interactions between the I2RS agent and the I2RS routing - system (forwarding plane, control plane, and routing plane). + o interactions between the I2RS agent and the I2RS routing system + (forwarding plane, control plane, and routing plane). 4.1.3. Trust SEC-ENV-REQ 8: In order to provide coherent access control policies enforced by multiple parties (e.g. the I2RS client or the I2RS agent), theses parties should trust each others, and communication between them should also be trusted (e.g. TLS) in order to reduce additional vector of attacks. @@ -692,36 +859,35 @@ I2RS client may sync its associated I2RS access control policies with the I2RS agent to limit the number of refused access requests being sent to the I2RS agent. The I2RS client is expected to balance benefits and problems with synchronizing its access control policies with the I2RS agent to proxy request validation versus simply passing the access request to the I2RS agent. - 2) A single I2RS client connects to multiple applications or acts as a broker for many applications: - In the case the I2RS agent has a single I2RS client - attached. This may end up in a situation where the I2RS - client is being delegated by the I2RS agent to enforce - access control policies. In such as case, the I2RS agent - may grant the I2RS client with high priviledges and blidngly - trust the I2RS client without enforcing access control - policies on what the I2RS client can do. Such a situation - must be avoided as it could be used by malicious - applications for a priviledge escalation by compromising the - I2RS client. In this situation, the application uses the - I2RS client to perform some action on behalf of the - application that it normally does not have the priviledges - to perform. In order to mitigate such attack, the I2RS - client that connects to multiple applications or operates as - a broker is expected to host application with an equivalent - level of privileges. + In this case the I2RS agent has a single I2RS client + attached, so the I2RS client could end being configured to + enforce access control policies instead of the I2RS Agent. + In this circumstance, it is possible that the I2RS agent may + grant an I2RS client with high priviledges and blindly trust + the I2RS client without enforcing access control policies on + what the I2RS client can do. Such a situation must be + avoided as it could be used by malicious applications for a + priviledge escalation by compromising the I2RS client + causing the I2RS client to perform some action on behalf of + the application that it normally does not have the + priviledges to perform. In order to mitigate such attack, + the I2RS client that connects to multiple applications or + operates as a broker is expected to host application with an + equivalent level of privileges. 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents Overview: To distribute the I2RS access control policies between I2RS clients and I2RS agents, I2RS access control policies can also be distributed within a set of I2RS clients or a set of I2RS agents. Requirements: @@ -795,21 +961,21 @@ SEC-ENV-REQ 19: Access control should be scalable when the number of application grows as well as when the number of I2RS client increases. Explanation: A typical implementation of a local I2RS client access control policies may result in creating manually a system user associated to each application. Such an approach is likely not to scale when the - number of applications increases or the number of + number of applications increases into the hundreds. SEC-ENV-REQ 20: Access control should be dynamically managed and easily updated. Explanation: Although the numberof I2RS clients is expected to be lower than the number of application, as I2RS agent provide access to the routing resource, it is of primary importance that an access can be granted or revoke in an efficient way. @@ -881,24 +1047,24 @@ for components within the I2RS plane, but this is within the scope of the I2RS protocol security requirements [I-D.ietf-i2rs-protocol-security-requirements]. Explanation: If the I2RS application is authenticated to the I2RS client, and the I2RS client is authenticated to the I2RS agent, and the I2RS client uses the opaque secondary identifier to pass an authenticated - identifier to the I2RS agent, this may be used for access control. - However, caution should be taken when using this chain of - authentication since the secondary identifier is intended in the I2RS - protocol for tracing. + identifier to the I2RS agent, then this identifier may be used for + access control. However, caution should be taken when using this + chain of authentication since the secondary identifier is intended in + the I2RS protocol only to aid traceability. From the environment perspective the I2RS agent MUST be aware when the resource has been modified outside the I2RS plane by another plane (management, control, or forwarding). The prioritization between the different planes should set a deterministic policy that allows the collision of two planes (I2RS plane and another plane) to be resolved via an overwrite policy in the I2RS agent. Similar requirements exist for knowledge about identities within the I2RS plane which modify things in the routing system, but this is @@ -946,21 +1112,21 @@ Overview Applications do not enforce access control policies. Instead these are enforced by the I2RS clients and the I2RS agents. This section provides recommendations for applications in order to ease I2RS access control by the I2RS client and the I2RS agent. Requirements: - SEC-ENV-REQ 28: applications SHOULD be uniquely identified by their + SEC-ENV-REQ 28: Applications SHOULD be uniquely identified by their associated I2RS clients Explanation: Different application may use different methods (or multiple methods) to communicate with its associated I2RS client, and each application may not use the same form of an application identifier. However, the I2RS client must obtain an identifier for each application. One method for this identification can be a system user id. @@ -978,53 +1144,52 @@ SEC-ENV-REQ 30: An application SHOULD be provided means and methods to contact their associated I2RS client. Explanation: It is obvious when an I2RS client belongs to the application as part of a module or a library that the application can communicate with a I2RS client. Similarly, if the application runs into a dedicated system with a I2RS client, it is obvious which I2RS client the application should contact. If the application connects to the I2RS - client remotely, the application needs some to be able to retrieve - the necessary information to contact its associated I2RS client (e.g. - an IP address or a FQDN). + client remotely, the application needs some means to retrieve the + necessary information to contact its associated I2RS client (e.g. an + IP address or a FQDN). 5. I2RS Application Isolation A key aspect of the I2RS architecture is the network oriented - application. As these application are supposed to be independent, - controlled by independent and various tenants. In addition to - independent logic, these applications may be malicious. Then, these - applications introduce also programmability which results in fast - network settings. + application that uses the I2RS high bandwidth programmatic interface + to monitor or change one or more routing systems. I2RS applications + could be control by a single entity or serve various tenants of the + network. If multiple entities use an I2RS application to monitor or + change the network, security policies must preserve the isolation of + each entity's control and not let malicious entities controlling one + I2RS application interfere with other I2RS applications. - The I2RS architecture should remain robust to these applications and - make sure an application does not impact the other applications. This section discusses both security aspects related to programmability as well as application isolation in the I2RS architecture. 5.1. Robustness Toward Programmability Overview I2RS provides a programmatic interface in and out of the Internet - routing system which provides the following advantages for security - - o the use of automation reduces configuration errors + routing system which provides the following advantages for security: + o the use of automation reduces configuration errors; o the programmatic interface enables fast network reconfiguration - and agility in adapting to network attacks, + and agility in adapting to network attacks; and - o monitoring facilities to detect and configuration to mitigate a - network attack. + o monitoring facilities to detect a network attack, and + configuration changes which can help mitigate the network attack. Programmability allows applications to flexible control which may cause problems due to: o applications which belong to different tenants with different objectives, o applications which lack coordination resulting in unstable routing configurations such as oscillations between network configurations, and creation of loops for example. For example, @@ -1036,35 +1201,33 @@ The I2RS plane requires data and application isolation to prevent such situations to happen. However, to guarantee the network stability constant monitoring and error detection are recommended to be activated. Requirement: SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of the system for which I2RS clients or applications have provided requests. It should also be able to - detect I2RS clients or applications that lead the - routing system in an unstable state. + detect any I2RS clients or applications causing + problems that may lead the routing system in an + unstable state. Explanation: - Monitoring consists at least in logging events and eventually provide - notifications or alerts to the management plane in case, something - has been detected. The management plane is in charge of collecting - the logs, the notifications and eventually to consider the - appropriated actions. A typical action may be the update of I2RS - access control policies for example or re-configuring routing - elements. + Monitoring consists at least in logging events and receiving streams + of data. I2RS Plane implementations should monitor the I2RS + applications and I2RS clients for potential problems. The cause for + the I2RS clients or applications providing problematic requests can + be failures in the implementation code or malicious intent. ] 5.2. Application Isolation - 5.2.1. DoS Overview: Requirements for robustness to DoS attacks have been addressed in the communication channel section [RFC7921]. This section focuses on requirements for application isolation that help prevent DoS. Requirements: @@ -1068,62 +1231,62 @@ Requirements: SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS agent controls the resources allocated to each I2RS clients. I2RS client that acts as broker may not be protected as efficiently against these attacks unless the broker performs resource controls for the hosted applications. - SEC-ENV-REQ 33: I2RS agent does not make response redirection - possible unless the redirection is previously - validated and agreed by the destination. + SEC-ENV-REQ 33: I2RS agent SHOULD make a response redirection unless + the redirection is previously validated and agreed by + the destination. - SEC-ENV-REQ 34: avoid the use of underlying protocols that are not - robust to reflection attacks. + SEC-ENV-REQ 34: I2RS Appications should avoid the use of underlying + protocols that are not robust to reflection attacks. Explanation: The I2RS interface is used by application to interact with the - routing states. As the I2RS agent is shared between multiple - applications, one application can prevent an application by - performing DoS or DDoS attacks on the I2RS agent or on the network. - DoS attack targeting the I2RS agent would consist in providing - requests that keep the I2RS agent busy for a long time. These - attacks on the I2RS agent may involve an application (requesting - through an I2RS Client) heavy computation by the I2RS agent in order - to block operations like disk access. + routing states. If the I2RS client is shared between multiple + applications, one application can use the I2RS client to perform DoS + or DDoS attacks on the I2RS agent(s) and through the I2RS agents + attacks on the network. DoS attack targeting the I2RS agent would + consist in providing requests that keep the I2RS agent busy for a + long time. These attacks on the I2RS agent may involve an + application (requesting through an I2RS Client) heavy computation by + the I2RS agent in order to block operations like disk access. Some DoS attacks may attack the I2RS Client's reception of notification and monitoring data stream over the network. Other DoS attacks may focus on the application directly by performing - reflection attacks. Such an attack could be performed by first - detecting an application is related to monitoring the RIB or changing - the RIB. + reflection attacks to reflect traffic. In such an attack could be + performed by first detecting an application is related to monitoring + the RIB or changing the RIB. Reflection-based DoS may be also attack + at various levels in the stack utilizing UDP at the service to + redirect data to a specific repository - Reflection-based DoS may be performed at various levels utilizing UDP - at the service to redirect data to a specific repository. + I2RS implementation should consider how to protect I2RS against such + attacks. 5.2.2. Application Logic Control Overview - Requirements for application control have been addressed in the I2RS - plane isolation as well as in the trusted Communication Channel - sections. This section examines how application logic must be design - to ensure application isolation. + This section examines how application logic must be design to ensure + application isolation. Requirements: - SEC-ENV-REQ 35: application logic should remain opaque to external - listeners. application logic may be partly hidden by + SEC-ENV-REQ 35: Application logic should remain opaque to external + listeners. Application logic may be partly hidden by encrypting the communication between the I2RS client and the I2RS agent. Additional ways to obfuscate the communications may involve sending random messages of various sizes. Such strategies have to be balanced with network load. Note that I2RS client broker are more likely to hide the application logic compared to I2RS client associated to a single application. Explanation: @@ -1184,23 +1347,34 @@ [I-D.ietf-i2rs-protocol-security-requirements] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", draft-ietf-i2rs-protocol-security- requirements-17 (work in progress), September 2016. 9.2. Informative References [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State - Requirements", draft-ietf-i2rs-ephemeral-state-22 (work in + Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in progress), November 2016. + [I-D.ietf-netconf-rfc6536bis] + Bierman, A. and M. Bjorklund, "Network Configuration + Protocol (NETCONF) Access Control Model", draft-ietf- + netconf-rfc6536bis-00 (work in progress), January 2017. + + [I-D.ietf-netmod-revised-datastores] + Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., + and R. Wilton, "A Revised Conceptual Model for YANG + Datastores", draft-ietf-netmod-revised-datastores-00 (work + in progress), December 2016. + Authors' Addresses Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160 Email: daniel.migault@ericsson.com