I2RS WG D.
Migault, Ed.Migault Internet-Draft J. Halpern Intended status: Informational Ericsson Expires: October 6, 2016May 19, 2017 S. Hares Huawei April 4,November 15, 2016 I2RS Environment Security Requirements draft-ietf-i2rs-security-environment-reqs-01draft-ietf-i2rs-security-environment-reqs-02 Abstract This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result, the requirements provided in this document are intended to provide good security practise so I2RS can be securely deployed and operated. These security requirements are designated as environment security requirements as opposed to the protocol security requirements.The reason to have separate document is thatI2RS protocol security requirements are intended to helpset the design ofsecurity for the communication between I2RS protocol whetherclient and agent while the security environment requirements are rather intended for deployment or implementations.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. 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 October 6, 2016.May 19, 2017. Copyright Notice Copyright (c) 2016 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. Requirements notation . .Introduction . . . . . . . . . . . . . . . . . . 2 2. Introduction. . . . . . 3 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Terminology and Acronyms4 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 4.3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 188.8.131.52. I2RS planePlane and managementManagement plane . . . . . . . . . . . . . 4 4.2.5 3.2. I2RS planePlane and forwarding planeForwarding Plane . . . . . . . . . . . . . 5 4.3.7 3.3. I2RS planePlane and Control planePlane . . . . . . . . . . . . . . 6 4.4. Recommendations8 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . 6 5.. 8 4. I2RS Access Control for routing system resourcesRouting System Resources . . . . . . 8 5.1.10 4.1. I2RS Access Control architecture .Architecture . . . . . . . . . . . 8 5.2. I2RS Agent Access Control policies. 11 4.1.1. access control Enforcement Scope . . . . . . . . . . 13 5.3. I2RS Client Access Control policies12 4.1.2. Notification Requirements . . . . . . . . . . . 14 5.4. Application and Access Control policies. . . 13 4.1.3. Trust . . . . . . 15 6. I2RS Application Isolation. . . . . . . . . . . . . . . . . 16 6.1. Robustness toward programmability. 14 4.1.4. Sharing access control Information . . . . . . . . . 14 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents . . 16 6.2. Application Isolation. . . . . . . . . . . . . . . . . . 17 6.2.1. DoS. . . 16 4.1.6. Managing Access Control Policy . . . . . . . . . . . 17 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 17 6.2.2. Application18 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 19 4.2.2. I2RS Client Access Control Policies . . . 17 7. Security Considerations. . . . . . 20 4.2.3. Application and Access Control Policies . . . . . . . 21 5. I2RS Application Isolation . . . . . . 18 8. Privacy Considerations. . . . . . . . . . . 22 5.1. Robustness Toward Programmability . . . . . . . . 18 9. IANA Considerations. . . . 22 5.2. Application Isolation . . . . . . . . . . . . . . . . . 18 10. Acknowledgments. 23 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . 18 11. References. . . 23 5.2.2. Application Logic Control . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . 18 11.1.. . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.2.25 9.2. Informative References . . . . . . . . . . . . . . . . . 1826 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 1926 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]. 2.Introduction This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. As a result,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 providedare rather intended for deployment or implementations features independent of the I2RS protocol. The environmental security requirements described in this document are intended toprovide the good security practisepractices to be used with the I2RS protocol so that I2RS protocol implementations can be securely deployed and operated.operate. These security requirements are designated asenvironment security requirements as opposed toaddress the protocol security requirements described in [I-D.ietf-i2rs-protocol-security-requirements]. The reason to have separate document is that protocolsecurity requirements are intended to help the design of theconsiderations for I2RS protocol whetherenvironment considered in the I2RS Architecture [RFC7921] in order to provide a stable and secure environment requirements are rather intended for deployment or implementations.in which the dynamic programmatic interface to the routing system (I2RS) should operates. Even though the I2RS protocol is mostly concerned bywith the interface between the I2RS Clientclient and the I2RS Agent,agent, the environmental security recommendationsrequirements must consider the entire I2RS architecture, specifyingarchitecture and specify where security functions may be hosted,hosted and what criteria should be met soin order to address any new attack vectors exposed by deploying this architecture. In other words,Environment security for I2RS has to be considered globally overthe complete I2RS architecture and not only on the interfaces. I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes the I2RS components and their interactions to provide a programmatic interface for the routing system. I2RS components as well as their interactions have not yet been considered in conventional routing systems. As such it introduces a need to interface with the routing system designated as I2RS plane in this document.protocol interface. This document is builtstructured as follows.follows: o Section 42 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. The remainingo the subsequent sections of the document focuses on the security within the I2RS plane.plane including: * Section 54 analyzes how the I2RS Access Controlaccess 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 alsoincludes providing a robust communication system between the components. Then,* Section 65 details how I2RS keeps applications isolated onefrom another and do not affectwithout affecting the I2RS components. Applicationsapplications may be independent, with different scopes, owned by different tenants. In addition, theythe applications may modify the routing system that may bein an automatic way. Motivations are placed before the requirements are given. The reader is expected to be familiar with the [I-D.ietf-i2rs-architecture]. The document provides a list of environmentI2RS 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. Motivations are placed before therequirements are announced. 3.[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 :plane: The environment the I2RS process is running on. It includes the Applications,applications, the I2RS Clientclient and the I2RS Agent.agent. - I2RS user :user: The user of the I2RS client software or system. - I2RS Access Controlaccess control policies: policies controlling access of the routing resources by Applications.applications. These policies are divided into policies applied by the I2RS Clientclient regarding Applicationsapplications and policies applied by the I2RS Agentagent regarding I2RS Clients.clients. - I2RS Client Access Control policies :client access control policies: The Access Controlaccess control policies processed by the I2RS Client.client. - I2RS Agent Access Control policies :agent access control policies: The Access Controlaccess control policies processed by the I2RS Agent. 4.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, such as theand control plane,planes ) is foundationalfundamental to the security of the I2RS environment. Clearly differentiating 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 protect2. 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, and defense in depth in the larger world of network security. That saidmodules. However, the I2RS plane cannot be considered as completely isolated from other planes, andplanes so the interactions should be identified andbetween the I2RS plane and other planes should be identified and controlled. FollowsThe following is a brief description onof how the I2RS plane positions itself in regard to the other planes. The description is indicative, and may not be exhaustive. 184.108.40.206. I2RS planePlane and managementManagement plane The purpose of the I2RS plane purposeis to provide a standard programmatic interface of the routing system resources to network oriented applications. ControlThe control plane and forwarding planes are related to routing protocols, and I2RS is basedpositioned on top of those.the control plane and forwarding plane. The management plane is usually vendor specific,specific and provides a broader control over the networking equipment such as system service. Given itsthe management plane's associated privileges it is expected to be reserved to highly trusted users like network administrators. The I2RS plane and the management plane both interact with several common elements on forwarding and packet processing devices. [I-D.ietf-i2rs-architecture][RFC7921] describes several of these interaction points such as the local configuration, the static system state, routing, and signalling. Because of this potential overlaps, asignaling. A routing resource may be accessed by different means (APIs, applications) and different planes. To keep these overlaps under control, one could either control the access to these resources with northbound APIs for example. Northboundplanes which creates potential overlaps. Southbound APIs are often provided to limit the scope of the applications towardmanagement plane's and the I2RS plane's interaction with the routing resources. In our case,resources (as figure 1 shows). If there are conflicts in these overlapping southbound APIs, the northbound API mayconflicts should be provided forresolved in a deterministic way. APIs that interact with the I2RS Plane and Management PLane I2RS applications by theMangement applications || NB API NB API || || || I2RS Client as well as to the management plane. In case conflicting overlaps cannot be avoided, and routing resource can be accessed by both theplane management plane || || ||SB API SB API || ------------------------------------------- | Routing Resources | |(forwarding plane, control plane, system) | +------------------------------------------+ Figure 1 - North Bound (NB) APIs and theSouth Bound (SB) APIs The I2RS plane, then, they shouldapplications may be resolved inprovided with a deterministic way. On thenorthbound side, there must be clear protections againstAPI by the I2RS system "infecting"client (as figure 1 shows). Similarly, the management system with bad information, orplane may provide a northbound API to management application. The northbound API from the management system "infecting"plane to the client application and the northbound API from the I2RS system with bad information. The primary protection in this space is goingplane to needI2RS applications may overlap. In case that these overlapping APIs between the have conflicts (e.g. both want to be validation rules onaccess the speed of information flow, value limits onsame routing resource), the data presented, and other protections of this type. Onthe conflicting side/issues, thereconflicts should be resolved in a deterministic way. To resolve conflicts in a northbound APIs, the deterministic resolution should have clear rules about which plan's commands win in the case ofdata plane with a system takes precedence (wins during a conflict in orderfor resources). This is important to prevent attacks wherethat attempt to drive the two systems can be forced to deadlock. 4.2.into deadlock situation over which system has precedence (wins) In the interactions between the I2RS plane and forwardingthe applications, and the management plane and the application is it important to prevent the following things: o the I2RS system "infecting" the management system with bad information, o the management system "infecting" the I2RS system with bad information directly, o the management system indirectly "infecting" the I2RS system by propagating improproper information from one system to another via I2RS. Prevention: 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. 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). 3.2. I2RS Plane and Forwarding Plane Applications hosted onby the I2RS Client belongsclient belong to the I2RS plane. These Applications are hardIt is difficult to remainconstrained intothese applications to the I2RS plane, or even to limit their scope within the I2RS plane. Applications using I2RS are part of the I2RS plane butmay also interact with othercomponents outside the I2RS plane. A commonFor example may bean application usesmay use an I2RS client to configure the network according to securityor monitored events. As theseevents are monitoredvia an I2RS agent on the forwarding plane and not thea single machine, or multiple I2RS plane, the application breaks plane isolation. In addition, applicationsagents each on a single machine. Applications may also communicate with multiple I2RS Clients; as such, any given application mayclients in order to have a broader view of the current and potential states of the network and the I2RS plane itself. Because of this, anyThese varied remote communication relationships between applications using the I2RS protocol to change the forwarding plane make it possible for an individual application couldto be an effective attack vector against the operation of the network, thea router's I2RS plane, or any plane with whichthe I2RSforwarding plane interacts.of the routing system, and other planes (management and control planes). Prevention measures: Systems should consider the following prevention errors: application validation - There is little the I2RS plane can do to validate applications with which it interacts, other thaninteracts. The I2RS client passes the I2RS agent an opaque identifier for the application so that an application's actions can be traced back to provide some broad general validationsthe application. Validation against common misconfigurations or errors. As witherrors - One way of securing the separationinterfaces between the management plane andapplication, the I2RS plane, this should minimally takeand the forwarding plane is to limit the form of limits oninformation accepted, limits onaccepted and to limit the rate at whichinformation is accepted, andaccepted between these three software planes. Another method is to performing rudimentary checks against intentionally formed routing loops or injecting information that would causeon the control plane to fail to converge. Other formsresults of protection may be necessary. 4.3.any updates to the forwarding plane. 3.3. I2RS planePlane and Control planePlane 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. It is not anticipated there will be any interactions betweenI2RS client configures, monitors or receives events via the on-the-wire signalling used byI2RS agent's interaction with the routing system including the process that handling the control plane. However, inplane signaling protocols (BGP, ISIS, OSPF, etc.), route information databases (RIBs), and interface databases. In some situationssituation to manage an network outage or to control traffic, the I2RS system couldprotocol may modify information in the local databases ofroute database or the control plane. Thisconfiguration of routing process. While this is not normally recommended, as it cana part of normal processing, such action that 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 loop free, loop free alternate, and convergenceproperties of the routing protocols which provide normal loop free routing in the control plane. However, ifThe information configured by the I2RS system does directly inject informationagent into these tables,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). Prevention measures: The I2RS system should ensurecan provide checks that during and after the problem has been resolved that loop free routing is preserved,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. Any information injected into the control plane directly could cause the control plane to fail to converge, resulting in a complete network outage. 4.4. Recommendations3.4. Requirements To isolate I2RS transactions from other planes, it is recommendedrequired that: REQSEC-ENV-REQ 1: Application-to-routingapplication-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; for example byisolation (e.g. using vLAN. Eventually, invLAN). In a virtual environment that shares a common infrastructure, encryption, for example by using TLS or IPsec,encryption may also be used as a way to enforce isolation. REQEncryption 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 (like the IP address)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 interface. As previously, mentioned a dedicated physical interface may contribute to a higher isolation, however logical isolation beisolation. Isolation may also be considered for exampleachieved 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). Explanation: When the I2RS Agentagent performs an action on a routing element, the action is performed via process(es) associated to a system user . Inrouting process. For example, in a typical UNIX system, the user is designated with a user id (uid) and belongbelongs to groups designated by group ids (gid). These users are dependent ofIf such a user id (uid) and group id (gid) is the identifier for the routing element's operation systemprocesses 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 are designatedthe routing processes have their own identifier so that access control can unique filter data between the processes. SEC-ENV-REQ 4: I2RS System Users. Some implementation may useplane should be informed when a routing system resource is modified by a user outside the I2RS System User forplane access. Notifications from the control plane SHOULD not to flood the I2RS Agent that proxiesplane, and rate limiting (or summarization) is expected to be applied. These routing system notification MAY translated to the differentappropriate I2RS Client, other implementations may useagent notifications, and passed to various I2RS System Userclients via notification relays. (This requirements is also described in section 7.6 of [RFC7921] for each differentthe I2RS Clients. REQ 3:client, and this section extends it to the entire I2RS Agent should have permissions separate from any other entity (for example any internal system management processes or CLI processes).plane (I2RS agent, client, and application). Explanation: I2RS resource may be shared with the management plane and the control plane. It is hardly possible to prevent interactions between the planes.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 beremain 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 Controlaccess control policies may be impacted. More especially, aFurther an I2RS Clientclient is more likely to update an I2RS resources that has been updated by itself, then by the management plane for example. REQ 4:plane. SEC-ENV-REQ 5: I2RS plane should be informed whendefine an "I2RS plane overwrite policy". Such policy defines how an I2RS is able to update and overwrite a routing systemresource is modifiedset by a user outside the I2RS plane access. The notification is not expected to flood the I2RSplane. Instead, notification is expected to be provided toSuch hierarchy has been described in section 6.3 and 7.8 of [RFC7921] Explanation: A key part of the I2RS components interacting, configuring or monitoring thearchitecture is notification regarding routing system resource. The notification is at least provided bychanges across the I2RS Agentplane (I2RS client to/from I2RS agent). The security environment requirements above (SEC-ENV-REQ-03 to SEC-ENV-REQ-05) provide the assurance that the various I2RS Client, but additional mechanisms might eventually be required soI2RS Client can relayplane and the notificationrouting systems the I2RS plane attaches to remains untouched by the other planes or the I2RS applications. Thisplane is designated as "I2RS resource modified outnotificed of I2RS plane". This requirements is also described in section 7.6such changes. Section 6.3 of [I-D.ietf-i2rs-architecture] for the I2RS Client. This document extends the requirement to[RFC7921] describes how the I2RS plane, in case future evolution ofagent within the I2RS plane. REQ 5: I2RSplane should defineinteracts with forwarding plane's local configuration, and provides the example of an "I2RS planeoverwrite policy". Suchpolicy defines how anbetween the I2RS is able to updateplane and overwrite a resource set by a userlocal configuration (instantiated in 2 Policy Knobs) that operators may wish to set. The prompt notification of any outside overwrite is key to the I2RS plane. Such hierarchy has been described in section 6.3architecture and 7.8proper interworking of [I-D.ietf-i2rs-architecture] 5.the I2RS Plane. 4. I2RS Access Control for routing system resourcesRouting System Resources This section provides recommendations on how I2RS Access Controlaccess control policies associated to the routing system resources. These policies only apply within the I2RS plane. More especially, the policies are associated to the Applications, theapplications, I2RS Clientsclients and theI2RS Agents,agents, with their associated identity and roles. Note that theThe I2RS deployment of Applications,I2RS Clientapplications, I2RS clients, and I2RS Agentagents can be located locally in a closed environment, should not be considered by default as a secureenvironment or distributed over open networks. The normal case for routing system management is over an open environment. Even forin 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 Applicationsapplications or remote I2RS Clients. As a result, this section always consider the case Applications and I2RS Client can be located locally, in a closed environment or distributed over open networks. Althoughclients. [I-D.ietf-i2rs-protocol-security-requirements] providesdefines the security requirements of the transport andI2RS protocol between the I2RS Clientclient and the I2RS Agent, thisagent over a secure transport. This section is mostly focusedfocuses on I2RS access control. 5.1.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). 4.1. I2RS Access Control architectureArchitecture Overview: Applications access to routing system resource via numerous intermediaries nodes. The application communicates with an I2RS Client.client. In some cases, the I2RS Clientclient is only associated to a single application, butapplication 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 Clientmay alsoact as a broker.broker (agent/client device shown in case d in the figure 2 below). The I2RS Client, then, communicates withclient 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 client and I2RS Agent that may eventually accessclient to the resource.I2RS agent). The I2RS Client broker approach provides scalability toagent must trust the I2RS architecture as it avoids that each Application be registeredclient's actions without having an ability to verify the I2RS Agent. Similarly, theclient's actions. a) I2RS Access Control should be ableapplication-client pair talking to scale numerous applications. REQone I2RS agent +-----------+ +---------+ +-------+ | I2RS |=====| I2RS |======| I2RS | |application| | client 1| | agent | +-----------+ +---------+ +-------+ b) I2RS application client pair talking to two i2RS agents +--------+ +-------------+ +---------+ | I2RS | | I2RS |===| I2RS |=====| agent 1| |application 1| | client 1| +--------+ | | | | +--------+ | | | |=====| I2RS | +-------------+ +---------+ | agent 2| +--------+ c) two applications talk to 1 client +--------+ +-------------+ +--------+ | I2RS | | I2RS |===|I2RS |=====| agent 1| |application 1| |client 1| +--------+ +-------------+ | | +--------+ +-------------+ | |=====| I2RS | | I2RS | | | | agent 2| |application 2|===| | +--------+ +-------------+ +--------+ d) I2RS Broker (agent/client +--------+ +-------------+ +--------+ | I2RS | | I2RS |==|I2RS |=====|agent 3/| |application 1| |client 1| ==|client 3+----+ +-------------+ +--------+ | +--+-----+ | | | | +-------------+ +--------+ | +-------+ +--|----+ | I2RS | |I2RS |===| |I2RS | |I2RS | |application 2|==|client 2| |agent 1| |agent 2| +-------------+ +--------+ +-------+ +-------+ 4.1.1. access control Enforcement Scope SEC-ENV-REQ 6: I2RS Access Controlaccess control should be performed through the whole I2RS plane. It should not be enforced by the I2RS Agentagent only within the routing element. Instead, the I2RS Clientclient should enforce the I2RS Client Access Controlclient access control against Applicationsapplications and the I2RS Agentagent should enforce the I2RS Agent Access Controlagent access control against the I2RS Clients. Note thatclients. The mechanisms for the I2RS Client Access Control isclient access control are not in thescope of the I2RS architecture [I-D.ietf-i2rs-architecture],[RFC7921], which exclusively focuses on the I2RS Agent Access Control.agent access control provided by the I2RS protocol. Explanation: This architecture results in a layered and hierarchical or multi-partymulti- party I2RS Access Control.access control. An application will be able to access a routing system resource only if both the I2RS Clientclient is granted access by the I2RS Agentagent and the application is granted access by the I2RS Client. REQclient. 4.1.2. Notification Requirements SEC-ENV-REQ 7: When an access request to a routing resource is refused by one party (the I2RS Clientclient or the I2RS Agent),agent), the initiator of the requestrequester (e.g the Application)application) as well as all intermediaries should indicate the reason the access has not been granted as well as thegranted, and which entity that hasrejected the request. 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, - that is should not introduce additional vector of attacks.Explanation: In case the I2RS Client Access Controlclient access control or the I2RS Agent Access Controlagent access control does not grant access to a routing system resource, the Applicationapplication should be able to determine whether its request has been rejected by the I2RS Clientclient or the I2RS Agentagent as well as the reason that caused the reject. More specifically,SEC-REQ-07 indicates the I2RS Agentagent may reject the request because, for example,because the I2RS Clientclient is not an authorized I2RS Client,client or because the I2RS Client does not nothave enough privileges.privileges to perform the requested transaction (read, write, start notifications or logging). The I2RS Clientclient should be notified of the reason that caused the reject bythe I2RS Agent,agent rejected the transaction due to a lack of authorization or priviledges, and Thethe I2RS Clientclient should return a message to the Application,application indicating the I2RS Client is not authorized or does not have enough privileges.agent reject the transacation with an indication of this reason. Similarly, if the I2RS Clientclient does not grant the access to the Application,application, the I2RS Clientclient should also inform the Application. Theapplication. An example of an error message returned should be for example:could be, "Read failure: you do not have the read permission", "Write failure: you do not have write permission"permission", or "Write failure: resource accessed by someone else". This requirement has been written in a generic manner as it concerns variousthe following interactions: o interactions between the application and the I2RS Client,client, o interactions between the I2RS Clientclient and the I2RS Agent. In the latest case, the requirement is part of the protocol securityagent (security requirements addressedare described by [I-D.ietf-i2rs-protocol-security-requirements]. Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on transport security requirements[I-D.ietf-i2rs-protocol-security-requirements]), o and interactions between the I2RS Clientagent and the I2RS Agent, the similar requirements may apply between the Applicationrouting 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 for a remote Application. REQclient 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. SEC-ENV-REQ 9: I2RS Clientclient or I2RS Agentagent SHOULD also be able to refuse a communication with an Applicationapplication or an I2RS Clientclient when the communication channel does not fulfill enough security requirements. For example,Explanation: The participants in the itI2RS Plane (I2RS client, I2RS agent, and I2RS application) exchange critical information, and to be effective the communication should be trusted and free from security attacks. The I2RS client or the I2RS agent should be able to reject messages over a communication channel that can be easily hijacked, like a clear text UDP channel. 4.1.4. Sharing access control Information For the I2RS client: SEC-ENV-REQ 10: The I2RS client MAY request information on its I2RS access control subset policies from the I2RS agent or cache requests that have been rejected by the I2RS agent to limit forwarding unnecessary queries to the I2RS agent. SEC-ENV-REQ 11: The I2RS client MAY support receiving notifications when its I2RS access control subset policies have been updated by the I2RS agent. Similarly, for the applications: SEC-ENV-REQ 12: The applications MAY request information on its I2RS access control subset policies in order to limit forwarding unnecessary queries to the I2RS client. SEC-ENV-REQ 13: The applications MAY subscribe to a service that provides notification when its I2RS access control subset policies have been updated. For both the application and the client: SEC-ENV-REQ 14: The I2RS access control should explicitly specify accesses that are granted. More specifically, anything not explicitly granted should be denied (default rule). Explanation: In order to limit the number of access requestrequests that result in an error, each Applicationapplication or I2RS Client may be able toclient can retrieve the I2RS Access Controlaccess control policies that applies to it. This subset of rules is designated as the "Individual I2RS Access Controlaccess control policies". As these policies are subject to changes, a dynamic synchronization mechanism should be provided. However, such mechanism may be implemented with different level of completeness and dynamicity of the Individualindividual I2RS Access Controlaccess control policies. CachingOne example, may be caching transaction requests that have been rejected mayrejected. I2RS access control should be one such variant.appropriately be balanced between the I2RS client and the I2RS agent. It remains relatively easy to implement and mayavoid the complete disclosure of the Access Controlaccess control policies of the I2RS Agent. In fact the relativeagent. Relative disclosure of Access Controlaccess control policies may leakallow the leaking confidential information in case of misconfiguration and should be balanced withmisconfiguration. It is important to balance the level of trust of the I2RS Clientclient and the necessity of distributing the enforcement of the Access Controlaccess control policies. REQ 10: The I2RS Client may be able to request for its I2RS Access Control subset policies to the I2RS Agent or cache requests that have been rejected by the I2RS Agent to limit forwarding unnecessary queries to the I2RS Agent. REQ 11: The I2RS Client may be able to be notified when its I2RS Access Control subset policies have been updated by the I2RS Agent. Similarly, for the Applications REQ 12: The Applications may be able to request for its I2RS Access Control subset policies, so to limit forwarding unnecessary queries to the I2RS Client. REQ 13: The Applications may be able to subscribe a service that provides notification when its I2RS Access Control subset policies have been updated. I2RS Access Control should be appropriately be balanced between the I2RS Client and the I2RS Agent.I2RS Access Controlaccess control should not solely rely only on the I2RS Clientclient or the I2RS Agentagent as illustrated below: - 1) I2RS Clientsclients are dedicated to a single Application:application: In this case, it is likely that I2RS Access Controlaccess control is enforced only by the I2RS Agent,agent, as the I2RS Clientclient is likely to accept all access request of the application. However, itIt is recommended that even in this case, I2RS Client Access Controlclient access control is not based on an "Allow anything from application" policy, but instead the I2RS Clientclient specifies accesses that are enabled. In addition, the I2RS Clientclient may sync its associated I2RS Access Controlaccess control policies with the I2RS Agentagent to limit the number of refused access requests being sent to the I2RS Agent.agent. The I2RS Clientclient is expected to balance probenefits and cons between syncproblems with synchronizing its access control policies with the I2RS Agent andagent to proxy request validation versus simply guessingpassing the access request to the I2RS Agent.agent. - 2) A single I2RS Clientclient connects to multiple applications or acts as a broker for all Applications:many applications: In the case the I2RS Agentagent has a single I2RS Client. Such architecture resultsclient attached. This may end up in a situation where the I2RS Client with high privileges,client is being delegated by the I2RS agent to enforce access control policies. In such as it sumscase, the privileges of all applications. As end-to-end authentication is not provided betweenI2RS agent may grant the ApplicationI2RS client with high priviledges and blidngly trust the I2RS Agent, ifclient without enforcing access control policies on what the I2RS Client becomes corrupted,client can do. Such a situation must be avoided as it is possiblecould be used by malicious applications for a priviledge escalation by compromising the I2RS client. In this situation, the maliciousapplication escalates its privileges and makeuses the I2RS Clientclient to perform some action on behalf of the application with more privileges. This wouldthat it normally does not have been possible with end-to-end authentication.the priviledges to perform. In order to mitigate such attack, the I2RS Clientclient that actsconnects to multiple applications or operates as a broker is expected to host application with an equivalent level of privileges. REQ 14: The I2RS4.1.5. Sharing Access Control should explicitly specify accesses that are granted. More specifically, anything not explicitly granted -- the default rule-- should be denied. In addition toin Groups of I2RS Clients and Agents Overview: To distribute the I2RS Access Controlaccess control policies between I2RS Clientsclients and I2RS Agents,agents, I2RS Access Controlaccess control policies can also be distributed within a set of I2RS Clientsclients or a set of I2RS Agents. REQagents. Requirements: SEC-ENV-REQ 15: I2RS Clientsclients should be distributed and act as brokers for Applicationsapplications that share roughly similar permissions. This avoids ending with over privileges I2RS Client compared to hosted applications and thus discourages applications to perform privilege escalation within an I2RS Client. REQSEC-ENV-REQ 16: I2RS Agentsagents should be avoided being granted overgranting extra privileges regardingto their authorized I2RS Client.client. I2RS Agentagent should be shared by I2RS Clientclient with roughly similar permissions. More explicitly, an I2RS Agentagent shared between I2RS Clientsclients that are only provided read access to the routing system resources does not need to perform any write access, so the I2RS client should not be provided these accesses. SEC-ENV-REQ 17: I2RS client and I2RS agent should be able to trace [RFC7922] the various transaction they perform as well as suspicious activities. These logs should be collected regularly and analyzed by functions that may be out of the I2RS plane. Explanation: This restriction for distributed I2RS clients to act as brokers only for applications with roughly the same priviledges avoids the I2RS client extra priviledges compared to hosted applications, and so should not be provided these accesses. Supposediscourages applications from perform privilege escalation within an I2RS Clientclient. For example, suppose an I2RS client requires write access to the resources. It is not recommended to grant the I2RS Agentagent the write access in order to satisfy a unique I2RS Client.client. Instead, the I2RS Clientclient that requires write access should be connected to a I2RS Agentagent that is already shared by I2RS Clientclient that requires a write access. Access Controlcontrol policies enforcement should be monitored in order to detect violation of the policies or detect an attack. Access Controlcontrol policies enforcement may not be performed by the I2RS Clientclient or the I2RS Agentagent as violation may require a more global view of the I2RS Access Controlaccess control policies. As a result, consistency check and mitigation may instead be performed by the management plane. However, I2RS Clientsclients and I2RS Agentsagents play a central role. REQ 17:The I2RS Client andagent can trace transactions that an I2RS Agent should be ableclient requests it to log the various transaction theyperform, as well as suspicious activities. These logs should be collected regularlyand analyzedto link this to the application via the secondary opaque identifier to the application. This information is placed in a tracing log which is retrieved by functions that may be outmanagement processes. If a particular application is granted a level of priviledges it should not have, then this tracing mechanism may detect this security intrusion after the I2RS plane.instrusion has occurred. 4.1.6. Managing Access Control Policy Access control policies should be implemented so that theythe policies remain manageable in short and longer term. This meansterm deployments of the way they are managed today should be address future deploymentI2RS protocol and use of I2RS. REQthe I2RS plane. Requirements: SEC-ENV-REQ 18: Access Controlaccess control should be managed in an automated way, that is granting or revoking an Applicationapplication should not involve manual configuration over the I2RS plane - like all the(I2RS client, I2RS Clients. REQagent, and application). Explanation: Granting or configuring an application with new policy should not require manual configuration of I2RS clients, I2RS agents, or other applications. SEC-ENV-REQ 19: Access Controlcontrol should be scalable when the number of Applicationapplication grows as well as when the number of I2RS Clientclient increases. Explanation: A typical implementation of a local I2RS Client Access Controlclient access control policies may result in creating manually a system user associated to each Application.application. Such an approach is likely not to scale when the number of Applicationsapplications increases or the number of I2RS Client increases. REQSEC-ENV-REQ 20: Access Controlcontrol should be dynamically managed and easy to beeasily updated. Explanation: Although the number ofnumberof I2RS Clientsclients is expected to be lower than the number of Application,application, as I2RS Agentagent provide access to the routing resource, it is of primary importance that an access can be granted or revoke in an efficient way. REQSEC-ENV-REQ 21: I2RS Clientsclients and I2RS Agentsagents should be uniquely identified in the network to enable centralized management of the I2RS Access Controlaccess control policies. 5.2.Explanation: Centralized management of the access control policies of an I2RS plane with network that hosts several I2RS applications, clients and agents requires that each devices can be identified. 4.2. I2RS Agent Access Control policiesPolicies Overview: The I2RS Agent Access Controlagent access control restricts the routing system resource access to authorized identities - possible access policies may be none, read or write. The initiator of an access request to a routing resource is always an Application.application. However, it remains challenging for the I2RS Agentagent to establish its access control policies based on the application that initiates the request. First, when an I2RS Clientclient acts as a broker, the I2RS Agentagent may not be able to authenticate the Application.application. In that sense, the I2RS Agentagent relies on the capability of the I2RS Clientclient to authenticate the Applicationsapplications and apply the appropriated I2RS Client Access Control. Then,client access control. Second, an I2RS Agentagent may not uniquely identify a piece of software implementing an I2RS Client.client. In fact, an I2RS Clientclient may be provided multiple identities which can be associated to different roles or privileges. The I2RS Clientclient is left responsible for using them appropriately according to the Application. Finally,application. Third, each I2RS Clientclient may contact various I2RS Agentagent with different privileges and access control policies. 4.2.1. I2RS Agent Access Control policies.This section provides recommendations on the I2RS Agent Access Controlagent access control policies to keep I2RS Access Controlaccess control coherent within the I2RS plane. REQRequirements: SEC-ENV-REQ 22: I2RS Agent Access Controlagent access control policies should be primarily based on the I2RS Clientsclients as described in [I-D.ietf-i2rs-architecture]. REQ[RFC7921]. SEC-ENV-REQ 23: I2RS Agent Access Controlagent access control policies mayMAY be based on the Application. In this caseapplication if the application identity of the Application MUST behas been authenticated by the I2RS Agent,client and passed via the secondary identity usedto tag the application as defined in [I-D.ietf-i2rs-architecture] should be considered cautiously. The tag may be used associated only to an authenticated I2RS Client that is known to authenticate its Application. The I2RS Agent Access Control policies may evolve over time as resource may also be updated outside the I2RS plane. Similarly, a given resource may be accessed by multiple I2RS users within the I2RS plane. Although this is considered as an error, depending on the I2RS Client that performed the update,the I2RS may accept or refuse to overwrite the routing system resource. REQagent. SEC-ENV-REQ 24: The I2RS Agentagent should know which identity (most likely(E.g. system user) performed the latest update of the routing resource. This is true for an identity inside and outside the I2RS plane,plane so the I2RS Agentagent can appropriately perform an update according to the priorities associated to the requesting identity andrequesting identity and the identity that last updated the resource. SEC-ENV-REQ 25: the I2RS agent should have a "I2RS agent overwrite Policy" that indicates how identities can be prioritized. This requirements is also described in section 7.6 of [RFC7921]. Similar requirements exist 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 identity that last updatedI2RS protocol for tracing. From the resource. On anenvironment perspective,perspective the I2RS Agentagent MUST be aware when the resource has been modified outside the I2RS plane, as well as its priority associated towardsplane 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 plane.agent. Similar requirements exist for knowledge about identities within the I2RS plane,plane which modify things in the routing system, but belongs tothis is within the protocol security requirements. REQ 25:scope of the I2RS Agent should have a "I2RS Agent overwrite Policy" that indicates how identities can be prioritized. Thisprotocol's requirements is also described in section 7.6 of [I-D.ietf-i2rs-architecture]. Similar requirements existfor components within the I2RS plane, but belongs to the protocolephemeral state [I-D.ietf-i2rs-ephemeral-state] and security requirements. 5.3.requirements [I-D.ietf-i2rs-protocol-security-requirements]. 4.2.2. I2RS Client Access Control policiesPolicies Overview: The I2RS Client Access Controlclient access control policies are responsible for authenticating the application managing the privileges for the applications, and enforcing access control to resources by the applications. As a result,Requirements: REQ 26: I2RS Clientclient should authenticate its applications. If the I2RS Clientclient acts as a broker and supports multiple Applications,applications, it should authenticate each of them. Authentication of the application may used GSSAPI, Secure RPC mechanisms.application. REQ 27: I2RS Clientclient should define Access Controlaccess control policies associated to each applications. An access to a routing resource by an Applicationapplication should not be forwarded immediately and transparently by the I2RS Clientclient based on the I2RS Agent Access Controlagent access control policies. The I2RS Clientclient should first check whether the Applicationapplication has sufficient privileges, and if so send an access request to the I2RS Agent. When an I2RS Client has multiple identities that are associated with different privileges. The I2RS Client Access Control policies should specify the associated I2RS Client's identities, especially, when the I2RS Agent Access Control policies are changed for a given I2RS Client's identity. In case,agent. Explanation: If no authentication mechanisms have being provided between the I2RS Clientclient and the application, then I2RS Client may not act as broker, andclient must be insteaddedicated to a single application. By doing so, application authentication may relyrelies on the I2RS authentication mechanisms between the I2RS Clientclient and the I2RS Agent. On the other hand, although this is not recommended,agent. If an I2RS client has multiple identities that are associated with different privileges for accessing an I2RS agent(s), the I2RS Access Controlclient access control policies is only enforced byshould specify the I2RS client identity with the I2RS Agent. 5.4.access control policy. 4.2.3. Application and Access Control policies Application doesPolicies Overview Applications do not enforce access control policies. Instead these are enforced by the I2RS Clientsclients and the I2RS Agents.agents. This section provides recommendations for Applicationsapplications in order to ease I2RS Access Controlaccess control by the I2RS Clientclient and the I2RS Agent. As multiple ways mayagent. Requirements: SEC-ENV-REQ 28: applications SHOULD be used for an Applicationuniquely identified by their associated I2RS clients Explanation: Different application may use different methods (or multiple methods) to communicate with its associated I2RS Client, it isclient, and each application may not expected that all Applicationsuse the same conventional identifier format acrossform of an application identifier. However, the I2RS plane. However, if all Applications are running on a dedicated system sharingclient must obtain an I2RS Client, it is expectedidentifier for each Application may uniquely identified,application. One method for example using differentthis identification can be a system users. REQ 28: Applicationsuser id. SEC-ENV-REQ 29: Each application SHOULD be uniquely identified by theirassociated to a restricted number of I2RS Clientsclient Explanation: The I2RS Clientclient provides access to resource on its behalf and this access should only be granted for trusted applications, or Applicationsapplications with an similar level of trust. On the other hand, thisThis does not prevent an I2RS Clientclient to host a large number of Applications. Similarly, an Application may also require to access multiple I2RS Clients depending onapplications with the resource to be accessed. As I2RS Client are restricted for a subset of Applications, REQ 29: Each Application SHOULD be associated to a restricted numbersame levels of I2RS Client REQtrust. SEC-ENV-REQ 30: ApplicationAn application SHOULD be provided means and methods to contact their associated I2RS Client. If theclient. Explanation: It is obvious when an I2RS Clientclient belongs to the Application (asapplication as part of a module or a library for example), or whenthat the Applicationapplication can communicate with a I2RS client. Similarly, if the application runs into a dedicated system (like a container)with a I2RS Client,client, it is obvious which I2RS Clientclient the Application is associated to. Onapplication should contact. If the other hand, Applications may also remotely accessapplication connects to the I2RS Client. In this case,client remotely, the Application is expected to be providedapplication needs some meansto be able to retrieve the necessary information to contact its associated I2RS Client. The IP address may not be appropriated in case renumbering occurs within the network or in case the traffic from Applications should be shared between multiple instances of a giventhe necessary information to contact its associated I2RS Client. In this caseclient (e.g. an IP address or a FQDN may be preferred. 6.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. 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. 220.127.116.11. Robustness toward programmabilityToward Programmability Overview I2RS provides a programmatic interface in and out of the Internet routing system. This feature, in addition to the global network view provided bysystem which provides the centralized architecture comes with a fewfollowing advantages in term of security. Thefor security o the use of automation reduces configuration errors. In addition, thiserrors o the programmatic interface enables fast network reconfiguration. Agility provides a key advantagereconfiguration and agility in term of deployment as side effect configuration may be easily addressed. Finally, it also providesadapting to network attacks, o monitoring facilities to monitordetect and configuration to mitigate an attack when thea network is underattack. On the other hand programmability also comes with a few drawbacks. First,Programmability allows applications canto flexible control which may cause problems due to: o applications which belong to multipledifferent tenants with different objectives. This absence ofobjectives, o applications which lack coordination may resultresulting in unstable routing configurations such as oscillations between network configurations, and creation of loops for example. A typical example would be anFor example, one application monitoringmay monitor a state and changing its state. If anotherchange to positive, and a second application performs the reverse operation, theoperation (turns it negative). This fluctuation can cause a routing system mayto become unstable. DataThe I2RS plane requires data and application isolation is expectedto prevent such situations to happen, however,happen. However, to guarantee the network stability,stability constant monitoring and error detection are recommended to be activated. REQRequirement: SEC-ENV-REQ 31: The I2RS Agentsagents should monitor constantly parts of the system for which I2RS Clientsclients or Applicationsapplications have provided requests. It should also be able to detect I2RS Clientsclients or Applicationsapplications that 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 collectingmanagement 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. 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: 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 logs,hosted applications. SEC-ENV-REQ 33: I2RS agent does not make response redirection possible unless the notificationsredirection is previously validated and eventually to consideragreed by the appropriated actions. A typical action may bedestination. SEC-ENV-REQ 34: avoid the updateuse of I2RS Access Control policies for example or re-configuring routing elements. 6.2. Application Isolation 6.2.1. DoS Requirements for robustnessunderlying protocols that are not robust to Dos Attacks have been addressed in the Communication channel section [I-D.ietf-i2rs-architecture].reflection attacks. Explanation: The I2RS interface is used by application to interact with the routing states. As the I2RS Agentagent is shared between multiple applications, one application can prevent an application by performing DoS or DDoS attacks on the I2RS Agentagent or on the network. DoS attack targeting the I2RS Agentagent would consist in providing requests that keep the I2RS Agentagent busy for a long time. ThisThese attacks on the I2RS agent may involve an application (requesting through an I2RS Client) heavy computation by the I2RS Agent for exampleagent in order to blockingblock operations like disk access. In addition,Some DoS attacks targeting the networkmay use specific commands likeattack the I2RS Client's reception of notification and monitoring data stream over the network. Then,Other DoS attackattacks may be also targetingfocus on the application directly by performing reflection attacks. Such an attack could be performed by indicating the targetfirst detecting an application as the target for some information like the listing of the RIB. Reflection may be performed at various levels and can be based on the use of UDP or at the service level like redirection of information to a specific repository. REQ 32: In order to prevent DoS, itis recommendedrelated to monitoring the I2RS Agent controlsRIB or changing the resources allocated to each I2RS Clients. I2RS Client that acts as brokerRIB. Reflection-based DoS may notbe protected as efficiently against these attacks unless they perform resource controls themselves of their hosted applications. REQ 33: I2RS Agent does not make response redirection possible unless the redirection is previously validated and agreed by the destination. REQ 34: avoid the use of underlying protocols that are not robustperformed at various levels utilizing UDP at the service to reflection attacks. 6.2.2.redirect data to a specific repository. 5.2.2. Application Logic Control Overview Requirements for Application Controlapplication control have been addressed in the I2RS plane isolation as well as in the trusted Communication Channel sections. Applications use the I2RS interface in order to update the routing system. These updates may be driven by behavior on the forwarding plane or any external behaviors. In this case, correlating observation to the I2RS traffic may enable to derive the application logic. Once theThis section examines how application logic has been derived, a malicious application may generate traffic or any event in the network in ordermust be design to activate the alternate application. REQensure application isolation. Requirements: SEC-ENV-REQ 35: Applicationapplication logic should remain opaque to external listeners. Applicationapplication logic may be partly hidden by encrypting the communication between the I2RS Clientclient and the I2RS Agent.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 Clientclient broker are more likely to hide the application logic compared to I2RS Clientclient associated to a single application. 7.Explanation: Applications use the I2RS interface in order to update the routing system. These updates may be driven by behavior on the forwarding plane or any external behaviors. In this case, correlating observation to the I2RS traffic may enable to derive the application logic. Once the application logic has been derived, a malicious application may generate traffic or any event in the network in order to activate the alternate application. 6. Security Considerations The whole document is about security. 8. Privacy Considerations 9.security requirements for the I2RS environment. To protect personal privacy, any identifier (I2RS application identifier, I2RS client identifier, or I2RS agent identifier) should not contain personal identifiable information. 7. IANA Considerations 10.No IANA considerations for this requirements. 8. Acknowledgments A number of people provided a significant amount of helping comments and reviews. Among them the authors would like to thank Russ White, Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, Alia Atlas, and Linda Dunbar 11.Dunbar. 9. References 18.104.22.168. 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, <http://www.rfc-editor.org/info/rfc2119>. 11.2. Informative References [I-D.ietf-i2rs-architecture][RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem Statement for the Interface to the Routing System", RFC 7920, DOI 10.17487/RFC7920, June 2016, <http://www.rfc-editor.org/info/rfc7920>. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-09 (work in progress), March 2015.RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc7923>. [I-D.ietf-i2rs-protocol-security-requirements] Hares, S., Migault, D., and J. Halpern, "I2RS Security Related Requirements", draft-ietf-i2rs-protocol-security- requirements-01requirements-17 (work in progress), September 2015.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 progress), November 2016. Authors' Addresses Daniel Migault (editor)Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160 Email: email@example.com Joel Halpern Ericsson Email: Joel.Halpern@ericsson.com Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: firstname.lastname@example.org