--- 1/draft-ietf-i2rs-security-environment-reqs-04.txt 2017-03-28 04:13:24.660025332 -0700 +++ 2/draft-ietf-i2rs-security-environment-reqs-05.txt 2017-03-28 04:13:24.740027218 -0700 @@ -1,20 +1,20 @@ I2RS WG D. Migault Internet-Draft J. Halpern Intended status: Informational Ericsson -Expires: September 13, 2017 S. Hares +Expires: September 29, 2017 S. Hares Huawei - March 12, 2017 + March 28, 2017 I2RS Environment Security Requirements - draft-ietf-i2rs-security-environment-reqs-04 + draft-ietf-i2rs-security-environment-reqs-05 Abstract This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of 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. @@ -31,21 +31,21 @@ 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 September 13, 2017. + This Internet-Draft will expire on September 29, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,50 +55,48 @@ 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.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 + 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 7 + 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 8 + 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 + 4. I2RS Access Control for Routing System Resources . . . . . . 11 + 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 11 + 4.1.1. Access control Enforcement Scope . . . . . . . . . . 14 + 4.1.2. Notification Requirements . . . . . . . . . . . . . . 14 + 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1.4. Sharing access control Information . . . . . . . . . 15 4.1.5. Sharing Access Control in Groups of I2RS Clients and - 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 . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 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 + Agents . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.1.6. Managing Access Control Policy . . . . . . . . . . . 19 + 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 20 + 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 20 + 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 21 + 4.2.3. Application and Access Control Policies . . . . . . . 22 + 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 23 + 5.1. Robustness Toward Programmability . . . . . . . . . . . . 23 + 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 24 + 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 5.2.2. Application Logic Control . . . . . . . . . . . . . . 26 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 9.2. Informative References . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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] 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 @@ -225,132 +223,29 @@ 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 applications Mangement applications - || NB API NB API || - || || - I2RS plane management plane - || control plane configuration|| - || datastore datastore || - || || - ||SB API SB API || - --------------------------------------- - | Routing System with protocols | - | control plane | - | (applied datastore) | - +-------------------------------------+ - | forwarding plane | - +-------------------------------------+ - | system | - +-------------------------------------+ - - Figure 1 - North Bound (NB) APIs and - South Bound (SB) APIs - - 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. - -3.1.1. Deadlocks - - How can a deadlock occur? - - The I2RS applications and the management applications may both - interact with the Routing System. For example, I2RS applications may - set ephemeral state for a BGP routing process allowing a peer to - temporarily increase the maximum number of prefixes 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 management application. - - 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 occurring 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 is combining 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 improper information from one system to another via - I2RS. - - In this circumstance, we define "infecting" as interfering with and - leading into a incoherent state. Planned interactions such as - interactions denoted in in two cooperating Yang data modules is not - an 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 + Data can be read by I2RS plane from configuration as copy of + configuration data, or by management plane as copies of the I2RS + plane. The problem is when the I2RS plane installs the routing plane + as its new configuration or the management plane installs the I2RS + plane information as management plane configuration. In this + circumstance, we define "infecting" as interfering with and leading + into a incoherent state. Planned interactions such as interactions + denoted in in two cooperating Yang data modules is not an incoherent + state. The primary protection in this space is going to need to be validation rules on: 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 @@ -360,101 +255,63 @@ o data transferred between a management server and the I2RS routing system, o data transferred 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 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 - accesses 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 a 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. + APIs that interact with the + I2RS Plane and Management Plane I2RS applications Mangement applications - || NB API MB API || - || (APP NAC policy) (APP NAC policy)|| - || I2RS client mgt client || - || (NAC policy) (NAC policy)|| + || NB API NB API || || || - I2RS protocol mgt protocol - (NETCONF/RESTCONF) + I2RS plane management plane + || control plane configuration|| + || datastore datastore || + || || + ||SB API SB API || + --------------------------------------- + | Routing System with protocols | + | control plane | + | (applied datastore) | + +-------------------------------------+ + | forwarding plane | + +-------------------------------------+ + | system | + +-------------------------------------+ - figure 3 + Figure 1 - North Bound (NB) APIs and + South Bound (SB) APIs 3.2. I2RS Plane and Forwarding Plane Applications hosted by the I2RS client belong to the I2RS plane. It is difficult to constrain 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 a 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 + figure 2 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). @@ -698,21 +555,21 @@ +-------------+ +--------+ | 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 + figure 3 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 @@ -1356,27 +1213,27 @@ 9.2. Informative References [I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State 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. + netconf-rfc6536bis-01 (work in progress), March 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. + and R. Wilton, "Network Management Datastore + Architecture", draft-ietf-netmod-revised-datastores-01 + (work in progress), March 2017. Authors' Addresses Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160