idnits 2.17.1 draft-ietf-i2rs-security-environment-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SEC-ENV-REQ 4: The 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 be allowed to flood the I2RS plane, and rate limiting (or summarization) is expected to be applied. These routing system notifications MAY translated to the appropriate I2RS agent notifications, and passed to various I2RS clients via notification relays. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SEC-ENV-REQ 33: I2RS agent SHOULD not make a response redirection unless the redirection is previously validated and agreed by the destination. -- The document date (March 12, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-netconf-rfc6536bis-00 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS WG D. Migault 3 Internet-Draft J. Halpern 4 Intended status: Informational Ericsson 5 Expires: September 13, 2017 S. Hares 6 Huawei 7 March 12, 2017 9 I2RS Environment Security Requirements 10 draft-ietf-i2rs-security-environment-reqs-04 12 Abstract 14 This document provides environment security requirements for the I2RS 15 architecture. Environment security requirements are independent of 16 the protocol used for I2RS. The security environment requirements 17 are the good security practices to be used during implementation and 18 deployment of the code related to the new interface to routing system 19 (I2RS) so that I2RS implementations can be securely deployed and 20 operated. 22 Environmental security requirements do not specify the I2RS protocol 23 seecurity requirements. This is done in another document (draft- 24 ietf-i2rs-protocol-security-requirements). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 63 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 64 3.1. I2RS Plane and Management plane . . . . . . . . . . . . . 5 65 3.1.1. Deadlocks . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.2. Data Store leaking . . . . . . . . . . . . . . . . . 7 67 3.2. I2RS Plane and Forwarding Plane . . . . . . . . . . . . . 10 68 3.3. I2RS Plane and Control Plane . . . . . . . . . . . . . . 11 69 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 70 4. I2RS Access Control for Routing System Resources . . . . . . 14 71 4.1. I2RS Access Control Architecture . . . . . . . . . . . . 14 72 4.1.1. Access control Enforcement Scope . . . . . . . . . . 17 73 4.1.2. Notification Requirements . . . . . . . . . . . . . . 17 74 4.1.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . 18 75 4.1.4. Sharing access control Information . . . . . . . . . 18 76 4.1.5. Sharing Access Control in Groups of I2RS Clients and 77 Agents . . . . . . . . . . . . . . . . . . . . . . . 20 78 4.1.6. Managing Access Control Policy . . . . . . . . . . . 22 79 4.2. I2RS Agent Access Control Policies . . . . . . . . . . . 23 80 4.2.1. I2RS Agent Access Control . . . . . . . . . . . . . . 23 81 4.2.2. I2RS Client Access Control Policies . . . . . . . . . 24 82 4.2.3. Application and Access Control Policies . . . . . . . 25 83 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 26 84 5.1. Robustness Toward Programmability . . . . . . . . . . . . 26 85 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 27 86 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 5.2.2. Application Logic Control . . . . . . . . . . . . . . 29 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 93 9.2. Informative References . . . . . . . . . . . . . . . . . 30 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 96 1. Introduction 98 This document provides environment security requirements for the I2RS 99 architecture. Environment security requirements are independent of 100 the protocol used for I2RS. The I2RS protocol security requirements 101 [I-D.ietf-i2rs-protocol-security-requirements] define the security 102 for the communication between I2RS client and agent. The security 103 environment requirements are good security practices to be used 104 during implementation and deployment of the I2RS protocol so that 105 I2RS protocol implementations can be securely deployed and operated. 106 These environment security requirements address the security 107 considerations described in the I2RS Architecture [RFC7921] required 108 to provide a stable and secure environment in which the dynamic 109 programmatic interface to the routing system (I2RS) should operates. 111 Even though the I2RS protocol is mostly concerned with the interface 112 between the I2RS client and the I2RS agent, the environmental 113 security requirements must consider the entire I2RS architecture and 114 specify where security functions may be hosted and what criteria 115 should be met in order to address any new attack vectors exposed by 116 deploying this architecture. Environment security for I2RS has to be 117 considered for the complete I2RS architecture and not only on the 118 protocol interface. 120 This document is structured as follows: 122 o Section 2 describes the terminology used in this document, 124 o Section 3 describes how the I2RS plane can be securely isolated 125 from the management plane, control plane, and forwarding plane. 127 The subsequent sections of the document focus on the security within 128 the I2RS plane. 130 o Section 4 analyses how the I2RS access control policies can be 131 deployed throughout the I2RS plane in order to limit access to the 132 routing system resources to authorized components with the 133 authorized privileges. This analysis examines how providing a 134 robust communication system between the components aids the access 135 control. 137 o Section 5 details how I2RS keeps applications isolated from 138 another and without affecting the I2RS components. Applications 139 may be independent, with different scopes, owned by different 140 tenants. In addition, the applications may modify the routing 141 system in an automatic way. 143 Motivations are described before the requirements are given. 145 The reader is expected to be familiar with the I2RS problem statement 146 [RFC7920], I2RS architecture, [RFC7921], traceability requirements 147 [RFC7922], I2RS Pub/Sub requirements [RFC7923], I2RS ephemeral state 148 requirements [I-D.ietf-i2rs-ephemeral-state], I2RS protocol security 149 requirements [I-D.ietf-i2rs-protocol-security-requirements]. 151 2. Terminology and Acronyms 153 - Environment Security Requirements : Security requirements 154 specifying how the environment a protocol operates in needs to 155 be secured. These requirements do not specify the protocol 156 security requirements. 158 - I2RS plane: The environment the I2RS process is running on. It 159 includes the applications, the I2RS client, and the I2RS agent. 161 - I2RS user: The user of the I2RS client software or system. 163 - I2RS access control policies: The policies controlling access of 164 the routing resources by applications. These policies are 165 divided into policies applied by the I2RS client regarding 166 applications and policies applied by the I2RS agent regarding 167 I2RS clients. 169 - I2RS client access control policies: The access control policies 170 processed by the I2RS client. 172 - I2RS agent access control policies: The access control policies 173 processed by the I2RS agent. 175 2.1. Requirements notation 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. I2RS Plane Isolation 183 Isolating the I2RS plane from other network planes (the management, 184 forwarding, and control planes) is fundamental to the security of the 185 I2RS environment. Clearly differentiating the I2RS components from 186 the rest of the network device does the following: 188 1. protects the I2RS components from vulnerabilities in other parts 189 of the network, 191 2. protects other systems vital to the health of the network from 192 vulnerabilities in the I2RS plane. 194 Separating the I2RS plane from other network control and forwarding 195 planes is similar to the best common practice of placing software 196 into software containers within modules with clear interfaces to 197 exterior modules. In a similar way, although the I2RS plane cannot 198 be completely isolated from other planes, it can be carefully 199 designed so the interactions between the I2RS plane and other planes 200 can be identified and controlled. The following is a brief 201 description of how the I2RS plane positions itself in regard to the 202 other planes. 204 3.1. I2RS Plane and Management plane 206 The purpose of the I2RS plane is to provide a standard programmatic 207 interface to the routing system resources to network oriented 208 applications. Routing protocols often run in a control plane and 209 provide entries for the forwarding plane as shown in figure 1. The 210 I2RS plane contains the I2RS applications, the I2RS client, the north 211 bound interface between the I2RS client and I2RS applications, the 212 I2RS protocol, the I2RS agent, and the south bound API (SB API) to 213 the routing system. The communication interfaces in the I2RS plane 214 are shown on the the left hand side of figure 1. 216 The management plane contains the mangement application, the 217 management client, the north bound API between the management client 218 and management application, the mangement server, the management 219 protocol (E.g. RESTCONF) between mangement client and management 220 server, and the south bound API between the management server and the 221 control plane. The communication interfaces associated with the 222 management plane are shown on the right hand side of figure 2. 224 The I2RS plane and the management plane both interact with the 225 control plane on which the routing systems operate. [RFC7921] 226 describes several of these interaction points such as the local 227 configuration, the static system state, routing, and signaling. A 228 routing resource may be accessed by I2RS plane, the mangement plane, 229 or routing protocol(s) which creates the potential for overlapping 230 access. The southbound APIs can limit the scope of the management 231 plane's and the I2RS plane's interaction with the routing resources. 233 Security focus: 235 Implementers need to carefully examine the southbound APIs from the 236 I2RS Plane and the management plane to determine if these APIs 237 overlap or conflict during use. If these APIs overlap or conflict, 238 these interactions can provide errors which are not traceable or 239 provide a risk for security intrusions between the two planes. 241 APIs that interact with the 242 I2RS Plane and Management Plane 244 I2RS applications Mangement applications 245 || NB API NB API || 246 || || 247 I2RS plane management plane 248 || control plane configuration|| 249 || datastore datastore || 250 || || 251 ||SB API SB API || 252 --------------------------------------- 253 | Routing System with protocols | 254 | control plane | 255 | (applied datastore) | 256 +-------------------------------------+ 257 | forwarding plane | 258 +-------------------------------------+ 259 | system | 260 +-------------------------------------+ 262 Figure 1 - North Bound (NB) APIs and 263 South Bound (SB) APIs 265 The north bound interface may also be a source of conflicting 266 interactions between the I2RS plane and the management plane. It is 267 important that conflicting interactions do not provide a deadlock 268 situation or allow a vulnerability due to data store leaking. 270 3.1.1. Deadlocks 272 How can a deadlock occur? 274 The I2RS applications and the management applications may both 275 interact with the Routing System. For example, I2RS applications may 276 set ephemeral state for a BGP routing process allowing a peer to 277 temporarily increase the maximum number of prefixes it will accept. 278 At the same time, a management plane process may change a BGP Peer's 279 configuration for the maximum number of prefixes to decrease the 280 maximum number of prefixes. [RFC7921] suggests that implementations 281 SHOULD provide operator configurable knobs that will determine which 282 functions (I2RS or configuration management) has precedence in the 283 routing system, and that events should signal an I2RS agent if the 284 I2RS ephemeral state is overwritten. This is an example of policy 285 that prevents a deadlock situation for both the I2RS application and 286 the management application. 288 It is important that implementations include both policy knobs for 289 resolving the deadlocks between the the I2RS plane and the management 290 plane, and event signaling which reports deadlocks occurring within a 291 system supporting I2RS. 293 3.1.2. Data Store leaking 295 A vulnerability can occur if there is leakage between the I2RS 296 ephemeral control plane data store and the management plane's 297 configuration datastore. [I-D.ietf-netmod-revised-datastores] 298 describes a datastore architecture with control plane datastores 299 (such as the I2RS protocol's ephemeral datastore) being logically 300 different than the the configuration data store. The mixture of the 301 I2RS ephemeral configuration and management configuration is done by 302 the routing system code (specific to an implementation). The routing 303 system code resolves any conflict between I2RS control plane 304 configuration and the management plane configuration, and then 305 installs the state in the routing system. Implementation policy 306 determines which configuration state should be installed. 308 The applied datastore provides information on what is installed in 309 each part of a system - including the routing system. The 310 operational state data store provides both the applied data store 311 information and additional operational state from the control plane 312 protocols and control plane datastore. 314 Since it is the routing system code which is combining the 315 configuration from the I2RS control plane datastore and the 316 management datastore to create applied datastore for the routing 317 system, this code must take care to prevent: 319 o the I2RS system "infecting" the management system configuration 320 datastore with information from the I2RS control plane data store, 322 o the management system "infecting" the I2RS system data with data 323 not specifically imported by I2RS data models, 325 o the management system indirectly "infecting" the I2RS system by 326 propagating improper information from one system to another via 327 I2RS. 329 In this circumstance, we define "infecting" as interfering with and 330 leading into a incoherent state. Planned interactions such as 331 interactions denoted in in two cooperating Yang data modules is not 332 an incoherent state. 334 For example, BGP configuration and BGP I2RS ephemeral state 335 configuration could have a defined interaction. The I2RS plane may 336 legitimately update a routing resource configured by the management 337 plane, or the reverse (the management plane updates a resource the 338 I2RS plane has configured) if the interactions are defined by Yang 339 modules or local policy. Infecting is when the implementation is 340 updated by two processes resulting in an incoherent state. Indirect 341 "infecting" we define as as changes made by the I2RS plane that cause 342 changes in routing protocols which add state unexpected by the 343 management plane or the reverse (the mangement plane adding changes 344 in routing protocols the I2RS plane does not expect). 346 Prevention for Data Store Leakage 348 The primary protection in this space is going to need to be 349 validation rules on: 351 o the data being sent/received by the I2RS agent (including 352 notification of changes that the I2RS agent sends the I2RS 353 client), 355 o any data transferred between management datastores (configuration 356 or operational state) and I2RS ephemeral control plane data 357 stores; 359 o data transferred between I2RS Agent and Routing system, 361 o data transferred between a management server and the I2RS routing 362 system, 364 o data transferred between I2RS agent and system (e.g. interfaces 365 ephemeral configuration), 367 o data transferred between management server and the system (e.g. 368 interface configuration). 370 The next few paragraphs will provide some ideas on how this might be 371 implemented. These suggest implementation policy should resolve what 372 is not resolved in the YANG Data module definitions. 374 The Network Access Control Module (NACM) has been define to control 375 access to the configuration datastore via the management protocol 376 across a network. A similar network access control module could be 377 defined for the I2RS-NACM (per [I-D.ietf-netconf-rfc6536bis]. 378 Figure 2 shows how the I2RS-NACM could be created to support parallel 379 features with the management protocol (E.g. NETCONF) NACM. 381 I2RS implementations may also need to define access modules which 382 control access to the routing system (Routing Access Control Module 383 (RACM)) by policy. The I2RS-RACM would control how the I2RS agent 384 accesses the routing system through the SB API interface. In 385 parallel, the management system would have a RACM to control the SB 386 API interface (see figure 2). I2RS agent and the management server 387 may want to read/write system information interfaces or other system 388 functions. In order to prevent leakage between the I2RS system and 389 the management system, there needs to be a system access control 390 module (SACM) that protects the jointly held data. 392 I2RS- || (I2RS Mgt protocol || 393 NACM || Protocol) (E.g. NETCONF)|| NACM 394 ------- ---------- 395 I2RS ||I2RS Agent Mgt server|| 396 SACM || I2RS Control-DS config DS || SACM 397 -----|| (RACM) (RACM) ||=======|| 398 | ||SB API SB API || || 399 | +-----------------------------------+ || 400 | | Routing System with protocols | || 401 | | control plane | || 402 | | (applied datastore) | || 403 | | (operational state) | || 404 | +--------------||-------------------+ || 405 | | forwarding plane | || 406 | +--------------||-------------------+ || 407 ---| system |======|| 408 +-----------------------------------+ 410 *Mgt = management 411 DS = Datastore 412 Control-DS = Control plane protocol data store 413 NACM = Network Access Control Module 414 RACM = Routing System Access Control Module 416 figure 2 418 The I2RS clients and the I2RS agents also need a set of policy which 419 defines what can be received from the network or sent to the network. 421 I2RS applications Mangement applications 422 || NB API MB API || 423 || (APP NAC policy) (APP NAC policy)|| 424 || I2RS client mgt client || 425 || (NAC policy) (NAC policy)|| 426 || || 427 I2RS protocol mgt protocol 428 (NETCONF/RESTCONF) 430 figure 3 432 3.2. I2RS Plane and Forwarding Plane 434 Applications hosted by the I2RS client belong to the I2RS plane. It 435 is difficult to constrain these applications to the I2RS plane, or 436 even to limit their scope within the I2RS plane. Applications using 437 I2RS may also interact with components outside the I2RS plane. For 438 example an application may use a management client to configure the 439 network and monitored events via an I2RS agent as figure 4 shows. 441 +--------------------------------------+ 442 | Application | 443 +--------------------------------------+ 444 || NB API NB API || 445 || I2RS client mgt client || 446 || || 447 I2RS protocol mgt protocol 448 (NETCONF/RESTCONF) 450 figure 4 452 Applications may also communicate with multiple I2RS clients in order 453 to have a broader view of the current and potential states of the 454 network and the I2RS plane itself. These varied remote communication 455 relationships between applications using the I2RS protocol to change 456 the forwarding plane make it possible for an individual application 457 to be an effective attack vector against the operation of the 458 network, a router's I2RS plane, the forwarding plane of the routing 459 system, and other planes (management and control planes). 461 Prevention measures: 463 Systems should consider the following prevention errors: 465 application validation - There is little the I2RS plane can do to 466 validate applications with which it interacts. The I2RS client 467 passes the I2RS agent an unique identifier for the application so 468 that an application's actions can be traced back to the 469 application. 471 Validation against common misconfigurations or errors - One way of 472 securing the interfaces between application, the I2RS plane, and 473 the forwarding plane is to limit the information accepted and to 474 limit the rate information is accepted between these three 475 software planes. Another method is to perform rudimentary checks 476 on the results of any updates to the forwarding plane. 478 3.3. I2RS Plane and Control Plane 480 The network control plane consists of the processes and protocols 481 that discover topology, advertise reachability, and determine the 482 shortest path between any location on the network and any 483 destination. I2RS client configures, monitors or receives events via 484 the I2RS agent's interaction with the routing system including the 485 process that handles the control plane signalling protocols (BGP, 486 ISIS, OSPF, etc.), route information databases (RIBs), and interface 487 databases. In some situations, to manage an network outage or to 488 control traffic, the I2RS protocol may modify information in the 489 route database or the configuration of routing process. While this 490 is not a part of normal processing, such action allows the network 491 operator to bypass temporary outages or DoS attacks. 493 This capability to modify the routing process information carries 494 with it the risk that the I2RS agent may alter the normal properties 495 of the routing protocols which provide normal loop free routing in 496 the control plane. For example, information configured by the I2RS 497 agent into routing process or RIBs could cause forwarding problems or 498 routing loops. As a second example, state which is inserted or 499 deleted from routing processes (control traffic, counters, etc.) 500 could cause the routing protocols to fail to converge or loop). 502 Prevention measures: 504 The I2RS implementation can provide internal checks after a routing 505 system protocol change that it is still operating correctly. These 506 checks would be specific to the routing protocol the I2RS Agent would 507 change. For example, if a BGP maximum prefix limit for a BGP peer is 508 lowered then the BGP peer should not allow the number prefixes 509 received from that peer to exceed this number. 511 3.4. Requirements 513 To isolate I2RS transactions from other planes, it is required that: 515 SEC-ENV-REQ 1: Application-to-routing system resources 516 communications should use an isolated communication 517 channel. Various levels of isolation can be 518 considered. The highest level of isolation may be 519 provided by using a physically isolated network. 520 Alternatives may also consider logical isolation 521 (e.g. using vLAN). In a virtual environment that 522 shares a common infrastructure, encryption may also 523 be used as a way to enforce isolation. Encryption 524 can be added by using a secure transport required by 525 the I2RS protocol security 526 [I-D.ietf-i2rs-protocol-security-requirements], and 527 sending the non-confidential I2RS data (designed for 528 a non-secure transport) over a secure transport. 530 SEC-ENV-REQ 2: The interface used by the routing element to receive 531 I2RS transactions via the I2RS protocol (e.g. the IP 532 address) SHOULD be a dedicated physical or logical 533 interface. As previously mentioned, a dedicated 534 physical interface may contribute to a higher 535 isolation. Isolation may also be achieved by using a 536 dedicated IP address or a dedicated port. 538 SEC-ENV-REQ 3: An I2RS agent SHOULD have specific permissions for 539 interaction with each routing element and access to 540 the routing element should governed by policy 541 specific to the I2RS agent's interfaces (network, 542 routing system, system, or cross-datastore). 544 Explanation: 546 When the I2RS agent performs an action on a routing element, the 547 action is performed in a process (or processes) associated with a 548 routing process. For example, in a typical UNIX system, the user is 549 designated with a user id (uid) and belongs to groups designated by 550 group ids (gid). If such a user id (uid) and group id (gid) is the 551 identifier for the routing processes peforming routing tasks in the 552 control plane, then the I2RS Agent process would communicate with 553 these routing processes. It is important that the I2RS agent has its 554 own unique identifier and the routing processes have their own 555 identifier so that access control can uniquely filter data between 556 I2RS Agent and routing processes. 558 The specific policy that the I2RS agent uses to filter data from the 559 network or from different processes on a system (routing, system or 560 cross-datastore) should be specific to the I2RS agent. For example, 561 the network access filter policy that the I2RS agent uses should be 562 uniquely identifiable from the configuration datastore updated by a 563 management protocol. 565 SEC-ENV-REQ 4: The I2RS plane should be informed when a routing 566 system resource is modified by a user outside the 567 I2RS plane access. Notifications from the control 568 plane SHOULD not be allowed to flood the I2RS plane, 569 and rate limiting (or summarization) is expected to 570 be applied. These routing system notifications MAY 571 translated to the appropriate I2RS agent 572 notifications, and passed to various I2RS clients via 573 notification relays. 575 Explanation: 577 This requirements is also described in section 7.6 of [RFC7921] for 578 the I2RS client, and this section extends it to the entire I2RS plane 579 (I2RS agent, client, and application). 581 A routing system resource may be accessed by management plane or 582 control plane protocols so a change to a routing system resource may 583 remain unnoticed unless and until the routing system resource 584 notifies the I2RS plane by notifying the I2RS agent. Such 585 notification is expected to trigger synchronization of the I2RS 586 resource state between the I2RS agent and I2RS client - signalled by 587 the I2RS agent sending a notification to an I2RS client. 589 The updated resource should be available in the operational state if 590 there is a yang module referencing that operational state, but this 591 is not always the case. In the cases where operational state is not 592 updated, the I2RS SB (southbound) API should include the ability to 593 send a notification. 595 SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite 596 policy". Such policy defines how an I2RS is able to 597 update and overwrite a resource set by a user outside 598 the I2RS plane. Such hierarchy has been described in 599 section 6.3 and 7.8 of [RFC7921] 601 Explanation: 603 A key part of the I2RS architecture is notification regarding routing 604 system changes across the I2RS plane (I2RS client to/from I2RS 605 agent). The security environment requirements above (SEC-ENV-REQ-03 606 to SEC-ENV-REQ-05) provide the assurance that the I2RS plane and the 607 routing systems the I2RS plane attaches to remains untouched by the 608 other planes or the I2RS plane is notificed of such changes. 609 Section 6.3 of [RFC7921] describes how the I2RS agent within the I2RS 610 plane interacts with forwarding plane's local configuration, and 611 provides the example of an overwrite policy between the I2RS plane 612 and local configuration (instantiated in 2 Policy Knobs) that 613 operators may wish to set. The prompt notification of any outside 614 overwrite is key to the architecture and proper interworking of the 615 I2RS Plane. 617 4. I2RS Access Control for Routing System Resources 619 This section provides recommendations on how the I2RS plane's access 620 control should be designed to protect the routing system resources. 621 These security policies for access control only apply within the I2RS 622 plane. More especially, the policies are associated to the 623 applications, I2RS clients and I2RS agents, with their associated 624 identity and roles. 626 The I2RS deployment of I2RS applications, I2RS clients, and I2RS 627 agents can be located locally in a closed environment or distributed 628 over open networks. The normal case for routing system management is 629 over an open environment. Even in a closed environment, access 630 control policies should be carefully defined to be able to, in the 631 future, carefully extend the I2RS plane to remote applications or 632 remote I2RS clients. 634 [I-D.ietf-i2rs-protocol-security-requirements] defines the security 635 requirements of the I2RS protocol between the I2RS client and the 636 I2RS agent over a secure transport. This section focuses on I2RS 637 access control architecture (section 4.1), access control policies of 638 the I2RS agent (section 4.2), the I2RS client (section 4.3), and the 639 application (section 4.4). 641 4.1. I2RS Access Control Architecture 643 Overview: 645 Applications access the routing system resource via numerous 646 intermediate nodes. The application communicates with an I2RS 647 client. In some cases, the I2RS client is only associated with a 648 single application attached to one or more agents (case a and case b 649 in figure 4 below). In other cases, the I2RS client may be connected 650 to two applications (case c in figure 4 below), or the I2RS may act 651 as a broker (agent/client device shown in case d in figure 4 below). 652 The I2RS client broker approach provides scalability to the I2RS 653 architecture as it avoids each application being registered to the 654 I2RS agent. Similarly, the I2RS access control should be able to 655 scale to numerous applications. 657 The goal of the security environment requirements in this section are 658 to control the interactions between the applications and the I2RS 659 client, and the interactions between the I2RS client and the I2RS 660 agent. The key challenge is that the I2RS architecture puts the I2RS 661 Client in control of the stream of communication (application to I2RS 662 client and I2RS client to the I2RS agent). The I2RS agent must trust 663 the I2RS client's actions without having an ability to verify the 664 I2RS client's actions. 666 a) I2RS application-client pair talking 667 to one I2RS agent 669 +-----------+ +---------+ +-------+ 670 | I2RS |=====| I2RS |======| I2RS | 671 |application| | client 1| | agent | 672 +-----------+ +---------+ +-------+ 674 b) I2RS application client pair talking to 675 two i2RS agents 676 +--------+ 677 +-------------+ +---------+ | I2RS | 678 | I2RS |===| I2RS |=====| agent 1| 679 |application 1| | client 1| +--------+ 680 | | | | +--------+ 681 | | | |=====| I2RS | 682 +-------------+ +---------+ | agent 2| 683 +--------+ 685 c) two applications talk to 1 client 686 +--------+ 687 +-------------+ +--------+ | I2RS | 688 | I2RS |===|I2RS |=====| agent 1| 689 |application 1| |client 1| +--------+ 690 +-------------+ | | +--------+ 691 +-------------+ | |=====| I2RS | 692 | I2RS | | | | agent 2| 693 |application 2|===| | +--------+ 694 +-------------+ +--------+ 696 d) I2RS Broker (agent/client 697 +--------+ 698 +-------------+ +--------+ | I2RS | 699 | I2RS |==|I2RS |=====|agent 3/| 700 |application 1| |client 1| ==|client 3+----+ 701 +-------------+ +--------+ | +--+-----+ | 702 | | | 703 +-------------+ +--------+ | +-------+ +--|----+ 704 | I2RS | |I2RS |===| |I2RS | |I2RS | 705 |application 2|==|client 2| |agent 1| |agent 2| 706 +-------------+ +--------+ +-------+ +-------+ 708 figure 4 710 4.1.1. Access control Enforcement Scope 712 SEC-ENV-REQ 6: I2RS access control should be performed through the 713 whole I2RS plane. It should not be enforced by the 714 I2RS agent only within the routing element. Instead, 715 the I2RS client should enforce the I2RS client access 716 control against applications and the I2RS agent 717 should enforce the I2RS agent access control against 718 the I2RS clients. The mechanisms for the I2RS client 719 access control are not in scope of the I2RS 720 architecture [RFC7921], which exclusively focuses on 721 the I2RS agent access control provided by the I2RS 722 protocol. 724 Explanation: 726 This architecture results in a layered and hierarchical or multi- 727 party I2RS access control. An application will be able to access a 728 routing system resource only if both the I2RS client is granted 729 access by the I2RS agent and the application is granted access by the 730 I2RS client. 732 4.1.2. Notification Requirements 734 SEC-ENV-REQ 7: When an access request to a routing resource is 735 refused by one party (the I2RS client or the I2RS 736 agent), the requester (e.g the application) as well 737 as all intermediaries should indicate the reason the 738 access has not been granted, and which entity 739 rejected the request. 741 Explanation: 743 In case the I2RS client access control or the I2RS agent access 744 control does not grant access to a routing system resource, the 745 application should be able to determine whether its request has been 746 rejected by the I2RS client or the I2RS agent as well as the reason 747 that caused the reject. 749 SEC-REQ-07 indicates the I2RS agent may reject the request because 750 the I2RS client is not an authorized I2RS client or lacks the 751 privileges to perform the requested transaction (read, write, start 752 notifications or logging). The I2RS client should be notified of the 753 reason the I2RS agent rejected the transaction due to a lack of 754 authorization or privileges, and the I2RS client should return a 755 message to the application indicating the I2RS agent reject the 756 transaction with an indication of this reason. Similarly, if the 757 I2RS client does not grant the access to the application, the I2RS 758 client should also inform the application. An example of an error 759 message could be, "Read failure: you do not have read permission", 760 "Write failure: you do not have write permission", or "Write failure: 761 resource accessed by someone else". 763 This requirement has been written in a generic manner as it relates 764 to the following interactions: 766 o interactions between the application and the I2RS client, 768 o interactions between the I2RS client and the I2RS agent at a 769 content level (Protocol security requirements are described by 770 [I-D.ietf-i2rs-protocol-security-requirements]), and 772 o interactions between the I2RS agent and the I2RS routing system 773 (forwarding plane, control plane, and routing plane). 775 4.1.3. Trust 777 SEC-ENV-REQ 8: In order to provide coherent access control policies 778 enforced by multiple parties (e.g. the I2RS client or 779 the I2RS agent), theses parties should trust each 780 other, and communication between them should also be 781 trusted (e.g. TLS) in order to reduce additional 782 vectors of attacks. 784 SEC-ENV-REQ 9: I2RS client or I2RS agent SHOULD also be able to 785 refuse a communication with an application or an I2RS 786 client when the communication channel does not 787 fulfill enough security requirements. 789 Explanation: 791 The participants in the I2RS Plane (I2RS client, I2RS agent, and I2RS 792 application) exchange critical information, and to be effective the 793 communication should be trusted and free from security attacks. 795 The I2RS client or the I2RS agent should be able to reject messages 796 over a communication channel that can be easily hijacked, like a 797 clear text UDP channel. 799 4.1.4. Sharing access control Information 801 For the I2RS client: 803 SEC-ENV-REQ 10: The I2RS client MAY request information on its I2RS 804 access control subset policies from the I2RS agent or 805 cache requests that have been rejected by the I2RS 806 agent to limit forwarding unnecessary queries to the 807 I2RS agent. 809 SEC-ENV-REQ 11: The I2RS client MAY support receiving notifications 810 when its I2RS access control subset policies have 811 been updated by the I2RS agent. 813 Similarly, for the applications: 815 SEC-ENV-REQ 12: The applications MAY request information on its I2RS 816 access control subset policies in order to limit 817 forwarding unnecessary queries to the I2RS client. 819 SEC-ENV-REQ 13: The applications MAY subscribe to a service that 820 provides notification when its I2RS access control 821 subset policies have been updated. 823 For both the application and the client: 825 SEC-ENV-REQ 14: The I2RS access control should explicitly specify 826 accesses that are granted. More specifically, 827 anything not explicitly granted should be denied 828 (default rule). 830 Explanation: 832 In order to limit the number of access requests that result in an 833 error, each application or I2RS client can retrieve the I2RS access 834 control policies that apply to it. This subset of rules is 835 designated as the "Individual I2RS access control policies". As 836 these policies are subject to changes, a dynamic synchronization 837 mechanism should be provided. However, such mechanisms may be 838 implemented with different levels of completeness and dynamicity of 839 the individual I2RS access control policies. One example may be 840 caching transaction requests that have been rejected. 842 I2RS access control should be appropriately balanced between the I2RS 843 client and the I2RS agent. It remains relatively easy to avoid the 844 complete disclosure of the access control policies of the I2RS agent. 845 Relative disclosure of access control policies may allow leaking 846 confidential information in case of misconfiguration. It is 847 important to balance the level of trust of the I2RS client and the 848 necessity of distributing the enforcement of the access control 849 policies. 851 I2RS access control should not solely rely only on the I2RS client or 852 the I2RS agent as illustrated below: 854 - 1) I2RS clients are dedicated to a single application: In this 855 case, it is likely that I2RS access control is enforced only by 856 the I2RS agent, as the I2RS client is likely to accept all 857 access requests of the application. It is recommended that 858 even in this case, I2RS client access control is not based on 859 an "Allow anything from application" policy, but instead the 860 I2RS client specifies accesses that are enabled. In addition, 861 the I2RS client may sync its associated I2RS access control 862 policies with the I2RS agent to limit the number of refused 863 access requests being sent to the I2RS agent. The I2RS client 864 is expected to balance benefits and problems with synchronizing 865 its access control policies with the I2RS agent to proxy 866 request validation versus simply passing the access request to 867 the I2RS agent. 869 - 2) A single I2RS client connects to multiple applications or 870 acts as a broker for many applications: 871 In this case the I2RS agent has a single I2RS client 872 attached, so the I2RS client could be configured to enforce 873 access control policies instead of the I2RS Agent. In this 874 circumstance, it is possible that the I2RS agent may grant 875 an I2RS client high priviledges and blindly trust the I2RS 876 client without enforcing access control policies on what the 877 I2RS client can do. Such a situation must be avoided as it 878 could be used by malicious applications for a privilege 879 escalation by compromising the I2RS client, causing the I2RS 880 client to perform some action on behalf of the application 881 that it normally does not have the privileges to perform. 882 In order to mitigate such attacks, the I2RS client that 883 connects to multiple applications or operates as a broker is 884 expected to host application with an equivalent level of 885 privileges. 887 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents 889 Overview: 891 To distribute the I2RS access control policies between I2RS clients 892 and I2RS agents, I2RS access control policies can also be distributed 893 within a set of I2RS clients or a set of I2RS agents. 895 Requirements: 897 SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers 898 for applications that share roughly similar 899 permissions. 901 SEC-ENV-REQ 16: I2RS agents should avoid granting extra privileges to 902 their authorized I2RS client. I2RS agents should be 903 shared by I2RS clients with roughly similar 904 permissions. More explicitly, an I2RS agent shared 905 between I2RS clients that are only provided read 906 access to the routing system resources do not need to 907 perform any write access, so the I2RS client should 908 not be provided these accesses. 910 SEC-ENV-REQ 17: I2RS clients and I2RS agents should be able to trace 911 [RFC7922] the various transactions they perform as 912 well as suspicious activities. These logs should be 913 collected regularly and analysed by functions that 914 may be out of the I2RS plane. 916 Explanation: 918 This restriction for distributed I2RS clients to act as brokers only 919 for applications with roughly the same privileges avoids the I2RS 920 client having extra privileges compared to hosted applications, and 921 discourages applications from performing privilege escalation within 922 an I2RS client. For example, suppose an I2RS client requires write 923 access to the resources. It is not recommended to grant the I2RS 924 agent the write access in order to satisfy a unique I2RS client. 925 Instead, the I2RS client that requires write access should be 926 connected to an I2RS agent that is already shared by an I2RS client 927 that requires write access. 929 Access control policies enforcement should be monitored in order to 930 detect violation of the policies or detect an attack. Access control 931 policies enforcement may not be performed by the I2RS client or the 932 I2RS agent as violation may require a more global view of the I2RS 933 access control policies. As a result, consistency check and 934 mitigation may instead be performed by the management plane. 935 However, I2RS clients and I2RS agents play a central role. 937 The I2RS agent can trace transactions that an I2RS client requests it 938 to perform, and to link this to the application via the secondary 939 opaque identifier to the application. This information is placed in 940 a tracing log which is retrieved by management processes. If a 941 particular application is granted a level of privileges it should not 942 have, then this tracing mechanism may detect this security intrusion 943 after the intrusion has occurred. 945 4.1.6. Managing Access Control Policy 947 Access control policies should be implemented so that the policies 948 remain manageable in short and longer term deployments of the I2RS 949 protocol and the I2RS plane. 951 Requirements: 953 SEC-ENV-REQ 18: access control should be managed in an automated way, 954 that is granting or revoking an application should 955 not involve manual configuration over the I2RS plane 956 (I2RS client, I2RS agent, and application). 958 Explanation: 960 Granting or configuring an application with new policy should not 961 require manual configuration of I2RS clients, I2RS agents, or other 962 applications. 964 SEC-ENV-REQ 19: Access control should be scalable when the number of 965 application grows as well as when the number of I2RS 966 clients increases. 968 Explanation: 970 A typical implementation of a local I2RS client access control 971 policies may result in creating manually a system user associated 972 with each application. Such an approach is not likely to scale when 973 the number of applications increases into the hundreds. 975 SEC-ENV-REQ 20: Access control should be dynamically managed and 976 easily updated. 978 Explanation: 980 Although the number of I2RS clients is expected to be lower than the 981 number of applications, as I2RS agents provide access to the routing 982 resource, it is of primary importance that an access can be granted 983 or revoke in an efficient way. 985 SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely 986 identified in the network to enable centralized 987 management of the I2RS access control policies. 989 Explanation: 991 Centralized management of the access control policies of an I2RS 992 plane with network that hosts several I2RS applications, clients and 993 agents requires that each devices can be identified. 995 4.2. I2RS Agent Access Control Policies 997 Overview: 999 The I2RS agent access control restricts routing system resource 1000 access to authorized identities - possible access policies may be 1001 none, read or write. The initiator of an access request to a routing 1002 resource is always an application. However, it remains challenging 1003 for the I2RS agent to establish its access control policies based on 1004 the application that initiates the request. 1006 First, when an I2RS client acts as a broker, the I2RS agent may not 1007 be able to authenticate the application. In that sense, the I2RS 1008 agent relies on the capability of the I2RS client to authenticate the 1009 applications and apply the appropriated I2RS client access control. 1011 Second, an I2RS agent may not uniquely identify a piece of software 1012 implementing an I2RS client. In fact, an I2RS client may be provided 1013 multiple identities which can be associated to different roles or 1014 privileges. The I2RS client is left responsible for using them 1015 appropriately according to the application. 1017 Third, each I2RS client may contact various I2RS agent with different 1018 privileges and access control policies. 1020 4.2.1. I2RS Agent Access Control 1022 This section provides recommendations on the I2RS agent access 1023 control policies to keep I2RS access control coherent within the I2RS 1024 plane. 1026 Requirements: 1028 SEC-ENV-REQ 22: I2RS agent access control policies should be 1029 primarily based on the I2RS clients as described in 1030 [RFC7921]. 1032 SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on 1033 the application if the application identity has been 1034 authenticated by the I2RS client and passed via the 1035 secondary identity to the I2RS agent. 1037 SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g. 1038 system user) performed the latest update of the 1039 routing resource. This is true for an identity 1040 inside and outside the I2RS plane, so the I2RS agent 1041 can appropriately perform an update according to the 1042 priorities associated to the requesting identity and 1043 the identity that last updated the resource. 1045 SEC-ENV-REQ 25: the I2RS agent should have an "I2RS agent overwrite 1046 Policy" that indicates how identities can be 1047 prioritized. This requirement is also described in 1048 section 7.6 of [RFC7921]. Similar requirements exist 1049 for components within the I2RS plane, but this is 1050 within the scope of the I2RS protocol security 1051 requirements 1052 [I-D.ietf-i2rs-protocol-security-requirements]. 1054 Explanation: 1056 If the I2RS application is authenticated to the I2RS client, and the 1057 I2RS client is authenticated to the I2RS agent, and the I2RS client 1058 uses the opaque secondary identifier to pass an authenticated 1059 identifier to the I2RS agent, then this identifier may be used for 1060 access control. However, caution should be taken when using this 1061 chain of authentication since the secondary identifier is intended in 1062 the I2RS protocol only to aid traceability. 1064 From the environment perspective the I2RS agent MUST be aware when 1065 the resource has been modified outside the I2RS plane by another 1066 plane (management, control, or forwarding). The prioritization 1067 between the different planes should set a deterministic policy that 1068 allows the collision of two planes (I2RS plane and another plane) to 1069 be resolved via an overwrite policy in the I2RS agent. 1071 Similar requirements exist for knowledge about identities within the 1072 I2RS plane which modify things in the routing system, but this is 1073 within the scope of the I2RS protocol's requirements for ephemeral 1074 state [I-D.ietf-i2rs-ephemeral-state] and security requirements 1075 [I-D.ietf-i2rs-protocol-security-requirements]. 1077 4.2.2. I2RS Client Access Control Policies 1079 Overview: 1081 The I2RS client access control policies are responsible for 1082 authenticating the application managing the privileges for the 1083 applications, and enforcing access control to resources by the 1084 applications. 1086 Requirements: 1088 REQ 26: I2RS client should authenticate its applications. If the 1089 I2RS client acts as a broker and supports multiple 1090 applications, it should authenticate each application. 1092 REQ 27: I2RS client should define access control policies associated 1093 to each applications. An access to a routing resource by an 1094 application should not be forwarded immediately and 1095 transparently by the I2RS client based on the I2RS agent 1096 access control policies. The I2RS client should first check 1097 whether the application has sufficient privileges, and if so 1098 send an access request to the I2RS agent. 1100 Explanation: 1102 If no authentication mechanisms have being provided between the I2RS 1103 client and the application, then the I2RS client must be dedicated to 1104 a single application. By doing so, application authentication relies 1105 on the I2RS authentication mechanisms between the I2RS client and the 1106 I2RS agent. 1108 If an I2RS client has multiple identities that are associated with 1109 different privileges for accessing an I2RS agent(s), the I2RS client 1110 access control policies should specify the I2RS client identity with 1111 the access control policy. 1113 4.2.3. Application and Access Control Policies 1115 Overview 1117 Applications do not enforce access control policies. Instead these 1118 are enforced by the I2RS clients and the I2RS agents. This section 1119 provides recommendations for applications in order to ease I2RS 1120 access control by the I2RS client and the I2RS agent. 1122 Requirements: 1124 SEC-ENV-REQ 28: Applications SHOULD be uniquely identified by their 1125 associated I2RS clients 1127 Explanation: 1129 Different application may use different methods (or multiple methods) 1130 to communicate with its associated I2RS client, and each application 1131 may not use the same form of an application identifier. However, the 1132 I2RS client must obtain an identifier for each application. One 1133 method for this identification can be a system user id. 1135 SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted 1136 number of I2RS clients. 1138 Explanation: 1140 The I2RS client provides access to resource on its behalf and this 1141 access should only be granted for trusted applications, or 1142 applications with an similar level of trust. This does not prevent 1143 an I2RS client to host a large number of applications with the same 1144 levels of trust. 1146 SEC-ENV-REQ 30: An application SHOULD be provided means and methods 1147 to contact their associated I2RS client. 1149 Explanation: 1151 It is obvious when an I2RS client belongs to the application as part 1152 of a module or a library that the application can communicate with a 1153 I2RS client. Similarly, if the application runs into a dedicated 1154 system with a I2RS client, it is obvious which I2RS client the 1155 application should contact. If the application connects to the I2RS 1156 client remotely, the application needs some means to retrieve the 1157 necessary information to contact its associated I2RS client (e.g. an 1158 IP address or a FQDN). 1160 5. I2RS Application Isolation 1162 A key aspect of the I2RS architecture is the network oriented 1163 application that uses the I2RS high bandwidth programmatic interface 1164 to monitor or change one or more routing systems. I2RS applications 1165 could be control by a single entity or serve various tenants of the 1166 network. If multiple entities use an I2RS application to monitor or 1167 change the network, security policies must preserve the isolation of 1168 each entity's control and not let malicious entities controlling one 1169 I2RS application interfere with other I2RS applications. 1171 This section discusses both security aspects related to 1172 programmability as well as application isolation in the I2RS 1173 architecture. 1175 5.1. Robustness Toward Programmability 1177 Overview 1179 I2RS provides a programmatic interface in and out of the Internet 1180 routing system which provides the following advantages for security: 1182 o the use of automation reduces configuration errors; 1183 o the programmatic interface enables fast network reconfiguration 1184 and agility in adapting to network attacks; and 1186 o monitoring facilities to detect a network attack, and 1187 configuration changes which can help mitigate the network attack. 1189 Programmability allows applications to flexible control which may 1190 cause problems due to: 1192 o applications which belong to different tenants with different 1193 objectives, 1195 o applications which lack coordination resulting in unstable routing 1196 configurations such as oscillations between network 1197 configurations, and creation of loops. For example, one 1198 application may monitor a state and change to positive, and a 1199 second application performs the reverse operation (turns it 1200 negative). This fluctuation can cause a routing system to become 1201 unstable. 1203 The I2RS plane requires data and application isolation to prevent 1204 such situations from happening. However, to guarantee the network 1205 stability constant monitoring and error detection are recommended. 1207 Requirement: 1209 SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of 1210 the system for which I2RS clients or applications 1211 have provided requests. It should also be able to 1212 detect any I2RS clients or applications causing 1213 problems that may leave the routing system in an 1214 unstable state. 1216 Explanation: 1218 In the least, monitoring consists of logging events and receiving 1219 streams of data. I2RS Plane implementations should monitor the I2RS 1220 applications and I2RS clients for potential problems. The cause for 1221 the I2RS clients or applications providing problematic requests can 1222 be failures in the implementation code or malicious intent. ] 1224 5.2. Application Isolation 1226 5.2.1. DoS 1228 Overview: 1230 Requirements for robustness to DoS attacks have been addressed in the 1231 communication channel section [RFC7921]. This section focuses on 1232 requirements for application isolation that help prevent DoS. 1234 Requirements: 1236 SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS 1237 agent control the resources allocated to each I2RS 1238 client. I2RS clients that act as broker may not be 1239 protected efficiently against these attacks unless 1240 the broker performs resource controls for the hosted 1241 applications. 1243 SEC-ENV-REQ 33: I2RS agent SHOULD not make a response redirection 1244 unless the redirection is previously validated and 1245 agreed by the destination. 1247 SEC-ENV-REQ 34: I2RS Applications should avoid the use of underlying 1248 protocols that are not robust enough to protect 1249 against reflection attacks. 1251 Explanation: 1253 The I2RS interface is used by applications to interact with the 1254 routing states. If the I2RS client is shared between multiple 1255 applications, one application can use the I2RS client to perform DoS 1256 or DDoS attacks on the I2RS agent(s) and through the I2RS agents 1257 attack the network. DoS attack targeting the I2RS agent would 1258 consist in providing requests that keep the I2RS agent busy for a 1259 long time. These attacks on the I2RS agent may involve an 1260 application (requesting through an I2RS Client) heavy computation by 1261 the I2RS agent in order to block operations like disk access. 1263 Some DoS attacks may attack the I2RS Client's reception of 1264 notification and monitoring data streams over the network. Other DoS 1265 attacks may focus on the application directly by performing 1266 reflection attacks to reflect traffic. Such an attack could be 1267 performed by first detecting an application is related to monitoring 1268 the RIB or changing the RIB. Reflection-based DoS may also attack at 1269 various levels in the stack utilizing UDP at the service to redirect 1270 data to a specific repository 1272 I2RS implementation should consider how to protect I2RS against such 1273 attacks. 1275 5.2.2. Application Logic Control 1277 Overview 1279 This section examines how application logic must be designed to 1280 ensure application isolation. 1282 Requirements: 1284 SEC-ENV-REQ 35: Application logic should remain opaque to external 1285 listeners. Application logic may be partly hidden by 1286 encrypting the communication between the I2RS client 1287 and the I2RS agent. Additional ways to obfuscate the 1288 communications may involve sending random messages of 1289 various sizes. Such strategies have to be balanced 1290 with network load. Note that I2RS client broker are 1291 more likely to hide the application logic compared to 1292 I2RS client associated to a single application. 1294 Explanation: 1296 Applications use the I2RS interface in order to update the routing 1297 system. These updates may be driven by behaviour on the forwarding 1298 plane or any external behaviours. In this case, correlating 1299 observation with the I2RS traffic may enable the derivation the 1300 application logic. Once the application logic has been derived, a 1301 malicious application may generate traffic or any event in the 1302 network in order to activate the alternate application. 1304 6. Security Considerations 1306 This whole document is about security requirements for the I2RS 1307 environment. To protect personal privacy, any identifier (I2RS 1308 application identifier, I2RS client identifier, or I2RS agent 1309 identifier) should not contain personal identifiable information. 1311 7. IANA Considerations 1313 No IANA considerations for this requirements. 1315 8. Acknowledgments 1317 A number of people provided a significant amount of helpful comments 1318 and reviews. Among them the authors would like to thank Russ White, 1319 Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, 1320 Alia Atlas, and Linda Dunbar. 1322 9. References 1324 9.1. Normative References 1326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1327 Requirement Levels", BCP 14, RFC 2119, 1328 DOI 10.17487/RFC2119, March 1997, 1329 . 1331 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 1332 Statement for the Interface to the Routing System", 1333 RFC 7920, DOI 10.17487/RFC7920, June 2016, 1334 . 1336 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1337 Nadeau, "An Architecture for the Interface to the Routing 1338 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1339 . 1341 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1342 the Routing System (I2RS) Traceability: Framework and 1343 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1344 2016, . 1346 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1347 for Subscription to YANG Datastores", RFC 7923, 1348 DOI 10.17487/RFC7923, June 2016, 1349 . 1351 [I-D.ietf-i2rs-protocol-security-requirements] 1352 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1353 Related Requirements", draft-ietf-i2rs-protocol-security- 1354 requirements-17 (work in progress), September 2016. 1356 9.2. Informative References 1358 [I-D.ietf-i2rs-ephemeral-state] 1359 Haas, J. and S. Hares, "I2RS Ephemeral State 1360 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 1361 progress), November 2016. 1363 [I-D.ietf-netconf-rfc6536bis] 1364 Bierman, A. and M. Bjorklund, "Network Configuration 1365 Protocol (NETCONF) Access Control Model", draft-ietf- 1366 netconf-rfc6536bis-00 (work in progress), January 2017. 1368 [I-D.ietf-netmod-revised-datastores] 1369 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1370 and R. Wilton, "A Revised Conceptual Model for YANG 1371 Datastores", draft-ietf-netmod-revised-datastores-00 (work 1372 in progress), December 2016. 1374 Authors' Addresses 1376 Daniel Migault 1377 Ericsson 1378 8400 boulevard Decarie 1379 Montreal, QC H4P 2N2 1380 Canada 1382 Phone: +1 514-452-2160 1383 Email: daniel.migault@ericsson.com 1385 Joel Halpern 1386 Ericsson 1388 Email: Joel.Halpern@ericsson.com 1390 Susan Hares 1391 Huawei 1392 7453 Hickory Hill 1393 Saline, MI 48176 1394 USA 1396 Email: shares@ndzh.com