idnits 2.17.1 draft-ietf-i2rs-security-environment-reqs-03.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: I2RS plane should be informed when a routing system resource is modified by a user outside the I2RS plane access. Notifications from the control plane SHOULD not to flood the I2RS plane, and rate limiting (or summarization) is expected to be applied. These routing system notification MAY translated to the appropriate I2RS agent notifications, and passed to various I2RS clients via notification relays. -- The document date (March 7, 2017) is 2608 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 (~~), 4 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 8, 2017 S. Hares 6 Huawei 7 March 7, 2017 9 I2RS Environment Security Requirements 10 draft-ietf-i2rs-security-environment-reqs-03 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 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 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 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 focuses on the security 128 within the I2RS plane. 130 o Section 4 analyzes 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 secure. 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 plane, and control planes) is fundamental to the security 185 of the I2RS environment. Clearly differentiating the I2RS components 186 from 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 of 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 which contains the I2RS applications, the I2RS client, the 211 north bound interface between the I2RS client and I2RS applications, 212 the I2RS protocol, the I2RS agent, and 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 the 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 control 225 plane on which the routing systems operate. [RFC7921] describes 226 several of these interaction points such as the local configuration, 227 the static system state, routing, and signaling. A routing resource 228 may be accessed by I2RS plane, the mangement plane, or routing 229 protocol(s) which creates the potential for overlapping access. The 230 southbound APIs can limit the scope of the management plane's and the 231 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 an BGP routing process allowing a peer to 277 temporarily increase the maximum number of prefix it will accept. At 278 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 mangement 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 occuring 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 mixing the configuration 315 from the I2RS control plane datastore and the management datastore to 316 create applied datastore for the routing system, this code must take 317 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 inteferring 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 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 342 cause 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 transfered 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 an 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 access the routing system through the SB API interface. In parallel, 385 the management system would have a RACM to control the SB API 386 interface (see figure 2). I2RS agent and the management server may 387 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 system access control module 390 (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 constrained 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 an 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 opaque 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 performing rudimentary 476 checks 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 handling the control plane signaling protocols (BGP, 486 ISIS, OSPF, etc.), route information databases (RIBs), and interface 487 databases. In some situation 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 that after a 505 routing system protocol changes that it is still operating correctly. 506 These checks would be specific to the routing protocol the I2RS Agent 507 would change. For example, if a BGP maximum prefix limit for a BGP 508 peer is lowered then the BGP peer should not allow the number 509 prefixes 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 level 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 the 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: I2RS plane should be informed when a routing system 566 resource is modified by a user outside the I2RS plane 567 access. Notifications from the control plane SHOULD 568 not to flood the I2RS plane, and rate limiting (or 569 summarization) is expected to be applied. These 570 routing system notification MAY translated to the 571 appropriate I2RS agent notifications, and passed to 572 various I2RS clients via notification relays. 574 Explanation: 576 This requirements is also described in section 7.6 of [RFC7921] for 577 the I2RS client, and this section extends it to the entire I2RS plane 578 (I2RS agent, client, and application). 580 A routing system resource may be accessed by the management plane or 581 control plane protocols so a change to a routing system resource may 582 remain unnoticed unless and until the routing system resource 583 notifies the I2RS plane by notifying the I2RS agent. Such 584 notification is expected to trigger synchronization of the I2RS 585 resource state between the I2RS agent and I2RS client - signalled by 586 the I2RS agent sending a notification to an I2RS client. 588 The updated resource should be available in the operational state if 589 there is a yang module referencing that operational state, but this 590 is not always the case. In the cases, where operational state is not 591 updated, the I2RS SB (southbound) API should include the ability to 592 send a notification. 594 SEC-ENV-REQ 5: I2RS plane should define an "I2RS plane overwrite 595 policy". Such policy defines how an I2RS is able to 596 update and overwrite a resource set by a user outside 597 the I2RS plane. Such hierarchy has been described in 598 section 6.3 and 7.8 of [RFC7921] 600 Explanation: 602 A key part of the I2RS architecture is notification regarding routing 603 system changes across the I2RS plane (I2RS client to/from I2RS 604 agent). The security environment requirements above (SEC-ENV-REQ-03 605 to SEC-ENV-REQ-05) provide the assurance that the I2RS plane and the 606 routing systems the I2RS plane attaches to remains untouched by the 607 other planes or the I2RS plane is notificed of such changes. 608 Section 6.3 of [RFC7921] describes how the I2RS agent within the I2RS 609 plane interacts with forwarding plane's local configuration, and 610 provides the example of an overwrite policy between the I2RS plane 611 and local configuration (instantiated in 2 Policy Knobs) that 612 operators may wish to set. The prompt notification of any outside 613 overwrite is key to the architecture and proper interworking of the 614 I2RS Plane. 616 4. I2RS Access Control for Routing System Resources 618 This section provides recommendations on how I2RS access control 619 policies associated to the routing system resources. These policies 620 only apply within the I2RS plane. More especially, the policies are 621 associated to the applications, I2RS clients and I2RS agents, with 622 their associated identity and roles. 624 The I2RS deployment of I2RS applications, I2RS clients, and I2RS 625 agents can be located locally in a closed environment or distributed 626 over open networks. The normal case for routing system management is 627 over an open environment. Even in a closed environment access 628 control policies should be carefully defined to be able to, in the 629 future to carefully extend the I2RS plane to remote applications or 630 remote I2RS clients. 632 [I-D.ietf-i2rs-protocol-security-requirements] defines the security 633 requirements of the I2RS protocol between the I2RS client and the 634 I2RS agent over a secure transport. This section focuses on I2RS 635 access control architecture (section 4.1), access control policies of 636 the I2RS agent (section 4.2), the I2RS client (section 4.3), and the 637 application (section 4.4). 639 4.1. I2RS Access Control Architecture 641 Overview: 643 Applications access to routing system resource via numerous 644 intermediaries nodes. The application communicates with an I2RS 645 client. In some cases, the I2RS client is only associated to a 646 single application attached to one or more agents (case a and case b 647 in figure 4 below). In other cases, the I2RS client may be connected 648 to two applications (case c in figure 4 below), or the I2RS may act 649 as a broker (agent/client device shown in case d in the figure 4 650 below). The I2RS client broker approach provides scalability to the 651 I2RS architecture as it avoids that each application be registered to 652 the I2RS agent. Similarly, the I2RS access control should be able to 653 scale numerous applications. 655 The goal of the security environment requirements in this section are 656 to control the interactions between the applications and the I2RS 657 client, and the interactions between the I2RS client and the I2RS 658 agent. The key challenge is that the I2RS architecture puts the I2RS 659 Client in control of the stream of communication (application to I2RS 660 client and I2RS client to the I2RS agent). The I2RS agent must trust 661 the I2RS client's actions without having an ability to verify the 662 I2RS client's actions. 664 a) I2RS application-client pair talking 665 to one I2RS agent 667 +-----------+ +---------+ +-------+ 668 | I2RS |=====| I2RS |======| I2RS | 669 |application| | client 1| | agent | 670 +-----------+ +---------+ +-------+ 672 b) I2RS application client pair talking to 673 two i2RS agents 674 +--------+ 675 +-------------+ +---------+ | I2RS | 676 | I2RS |===| I2RS |=====| agent 1| 677 |application 1| | client 1| +--------+ 678 | | | | +--------+ 679 | | | |=====| I2RS | 680 +-------------+ +---------+ | agent 2| 681 +--------+ 683 c) two applications talk to 1 client 684 +--------+ 685 +-------------+ +--------+ | I2RS | 686 | I2RS |===|I2RS |=====| agent 1| 687 |application 1| |client 1| +--------+ 688 +-------------+ | | +--------+ 689 +-------------+ | |=====| I2RS | 690 | I2RS | | | | agent 2| 691 |application 2|===| | +--------+ 692 +-------------+ +--------+ 694 d) I2RS Broker (agent/client 695 +--------+ 696 +-------------+ +--------+ | I2RS | 697 | I2RS |==|I2RS |=====|agent 3/| 698 |application 1| |client 1| ==|client 3+----+ 699 +-------------+ +--------+ | +--+-----+ | 700 | | | 701 +-------------+ +--------+ | +-------+ +--|----+ 702 | I2RS | |I2RS |===| |I2RS | |I2RS | 703 |application 2|==|client 2| |agent 1| |agent 2| 704 +-------------+ +--------+ +-------+ +-------+ 706 figure 4 708 4.1.1. access control Enforcement Scope 710 SEC-ENV-REQ 6: I2RS access control should be performed through the 711 whole I2RS plane. It should not be enforced by the 712 I2RS agent only within the routing element. Instead, 713 the I2RS client should enforce the I2RS client access 714 control against applications and the I2RS agent 715 should enforce the I2RS agent access control against 716 the I2RS clients. The mechanisms for the I2RS client 717 access control are not in scope of the I2RS 718 architecture [RFC7921], which exclusively focuses on 719 the I2RS agent access control provided by the I2RS 720 protocol. 722 Explanation: 724 This architecture results in a layered and hierarchical or multi- 725 party I2RS access control. An application will be able to access a 726 routing system resource only if both the I2RS client is granted 727 access by the I2RS agent and the application is granted access by the 728 I2RS client. 730 4.1.2. Notification Requirements 732 SEC-ENV-REQ 7: When an access request to a routing resource is 733 refused by one party (the I2RS client or the I2RS 734 agent), the requester (e.g the application) as well 735 as all intermediaries should indicate the reason the 736 access has not been granted, and which entity 737 rejected the request. 739 Explanation: 741 In case the I2RS client access control or the I2RS agent access 742 control does not grant access to a routing system resource, the 743 application should be able to determine whether its request has been 744 rejected by the I2RS client or the I2RS agent as well as the reason 745 that caused the reject. 747 SEC-REQ-07 indicates the I2RS agent may reject the request because 748 the I2RS client is not an authorized I2RS client or lacks the 749 privileges to perform the requested transaction (read, write, start 750 notifications or logging). The I2RS client should be notified of the 751 reason the I2RS agent rejected the transaction due to a lack of 752 authorization or priviledges, and the I2RS client should return a 753 message to the application indicating the I2RS agent reject the 754 transacation with an indication of this reason. Similarly, if the 755 I2RS client does not grant the access to the application, the I2RS 756 client should also inform the application. An example of an error 757 message could be, "Read failure: you do not have the read 758 permission", "Write failure: you do not have write permission", or 759 "Write failure: resource accessed by someone else". 761 This requirement has been written in a generic manner as it concerns 762 the following interactions: 764 o interactions between the application and the I2RS client, 766 o interactions between the I2RS client and the I2RS agent at a 767 content level (Protocol security requirements are described by 768 [I-D.ietf-i2rs-protocol-security-requirements]), and 770 o interactions between the I2RS agent and the I2RS routing system 771 (forwarding plane, control plane, and routing plane). 773 4.1.3. Trust 775 SEC-ENV-REQ 8: In order to provide coherent access control policies 776 enforced by multiple parties (e.g. the I2RS client or 777 the I2RS agent), theses parties should trust each 778 others, and communication between them should also be 779 trusted (e.g. TLS) in order to reduce additional 780 vector of attacks. 782 SEC-ENV-REQ 9: I2RS client or I2RS agent SHOULD also be able to 783 refuse a communication with an application or an I2RS 784 client when the communication channel does not 785 fulfill enough security requirements. 787 Explanation: 789 The participants in the I2RS Plane (I2RS client, I2RS agent, and I2RS 790 application) exchange critical information, and to be effective the 791 communication should be trusted and free from security attacks. 793 The I2RS client or the I2RS agent should be able to reject messages 794 over a communication channel that can be easily hijacked, like a 795 clear text UDP channel. 797 4.1.4. Sharing access control Information 799 For the I2RS client: 801 SEC-ENV-REQ 10: The I2RS client MAY request information on its I2RS 802 access control subset policies from the I2RS agent or 803 cache requests that have been rejected by the I2RS 804 agent to limit forwarding unnecessary queries to the 805 I2RS agent. 807 SEC-ENV-REQ 11: The I2RS client MAY support receiving notifications 808 when its I2RS access control subset policies have 809 been updated by the I2RS agent. 811 Similarly, for the applications: 813 SEC-ENV-REQ 12: The applications MAY request information on its I2RS 814 access control subset policies in order to limit 815 forwarding unnecessary queries to the I2RS client. 817 SEC-ENV-REQ 13: The applications MAY subscribe to a service that 818 provides notification when its I2RS access control 819 subset policies have been updated. 821 For both the application and the client: 823 SEC-ENV-REQ 14: The I2RS access control should explicitly specify 824 accesses that are granted. More specifically, 825 anything not explicitly granted should be denied 826 (default rule). 828 Explanation: 830 In order to limit the number of access requests that result in an 831 error, each application or I2RS client can retrieve the I2RS access 832 control policies that applies to it. This subset of rules is 833 designated as the "Individual I2RS access control policies". As 834 these policies are subject to changes, a dynamic synchronization 835 mechanism should be provided. However, such mechanism may be 836 implemented with different level of completeness and dynamicity of 837 the individual I2RS access control policies. One example, may be 838 caching transaction requests that have been rejected. 840 I2RS access control should be appropriately be balanced between the 841 I2RS client and the I2RS agent. It remains relatively easy to avoid 842 the complete disclosure of the access control policies of the I2RS 843 agent. Relative disclosure of access control policies may allow the 844 leaking confidential information in case of misconfiguration. It is 845 important to balance the level of trust of the I2RS client and the 846 necessity of distributing the enforcement of the access control 847 policies. 849 I2RS access control should not solely rely only on the I2RS client or 850 the I2RS agent as illustrated below: 852 - 1) I2RS clients are dedicated to a single application: In this 853 case, it is likely that I2RS access control is enforced only by 854 the I2RS agent, as the I2RS client is likely to accept all 855 access request of the application. It is recommended that even 856 in this case, I2RS client access control is not based on an 857 "Allow anything from application" policy, but instead the I2RS 858 client specifies accesses that are enabled. In addition, the 859 I2RS client may sync its associated I2RS access control 860 policies with the I2RS agent to limit the number of refused 861 access requests being sent to the I2RS agent. The I2RS client 862 is expected to balance benefits and problems with synchronizing 863 its access control policies with the I2RS agent to proxy 864 request validation versus simply passing the access request to 865 the I2RS agent. 867 - 2) A single I2RS client connects to multiple applications or 868 acts as a broker for many applications: 869 In this case the I2RS agent has a single I2RS client 870 attached, so the I2RS client could end being configured to 871 enforce access control policies instead of the I2RS Agent. 872 In this circumstance, it is possible that the I2RS agent may 873 grant an I2RS client with high priviledges and blindly trust 874 the I2RS client without enforcing access control policies on 875 what the I2RS client can do. Such a situation must be 876 avoided as it could be used by malicious applications for a 877 priviledge escalation by compromising the I2RS client 878 causing the I2RS client to perform some action on behalf of 879 the application that it normally does not have the 880 priviledges to perform. In order to mitigate such attack, 881 the I2RS client that connects to multiple applications or 882 operates as a broker is expected to host application with an 883 equivalent level of privileges. 885 4.1.5. Sharing Access Control in Groups of I2RS Clients and Agents 887 Overview: 889 To distribute the I2RS access control policies between I2RS clients 890 and I2RS agents, I2RS access control policies can also be distributed 891 within a set of I2RS clients or a set of I2RS agents. 893 Requirements: 895 SEC-ENV-REQ 15: I2RS clients should be distributed and act as brokers 896 for applications that share roughly similar 897 permissions. 899 SEC-ENV-REQ 16: I2RS agents should be avoided granting extra 900 privileges to their authorized I2RS client. I2RS 901 agent should be shared by I2RS client with roughly 902 similar permissions. More explicitly, an I2RS agent 903 shared between I2RS clients that are only provided 904 read access to the routing system resources does not 905 need to perform any write access, so the I2RS client 906 should not be provided these accesses. 908 SEC-ENV-REQ 17: I2RS client and I2RS agent should be able to trace 909 [RFC7922] the various transaction they perform as 910 well as suspicious activities. These logs should be 911 collected regularly and analyzed by functions that 912 may be out of the I2RS plane. 914 Explanation: 916 This restriction for distributed I2RS clients to act as brokers only 917 for applications with roughly the same priviledges avoids the I2RS 918 client extra priviledges compared to hosted applications, and 919 discourages applications from perform privilege escalation within an 920 I2RS client. For example, suppose an I2RS client requires write 921 access to the resources. It is not recommended to grant the I2RS 922 agent the write access in order to satisfy a unique I2RS client. 923 Instead, the I2RS client that requires write access should be 924 connected to a I2RS agent that is already shared by I2RS client that 925 requires a write access. 927 Access control policies enforcement should be monitored in order to 928 detect violation of the policies or detect an attack. Access control 929 policies enforcement may not be performed by the I2RS client or the 930 I2RS agent as violation may require a more global view of the I2RS 931 access control policies. As a result, consistency check and 932 mitigation may instead be performed by the management plane. 933 However, I2RS clients and I2RS agents play a central role. 935 The I2RS agent can trace transactions that an I2RS client requests it 936 to perform, and to link this to the application via the secondary 937 opaque identifier to the application. This information is placed in 938 a tracing log which is retrieved by management processes. If a 939 particular application is granted a level of priviledges it should 940 not have, then this tracing mechanism may detect this security 941 intrusion after the instrusion has occurred. 943 4.1.6. Managing Access Control Policy 945 Access control policies should be implemented so that the policies 946 remain manageable in short and longer term deployments of the I2RS 947 protocol and the I2RS plane. 949 Requirements: 951 SEC-ENV-REQ 18: access control should be managed in an automated way, 952 that is granting or revoking an application should 953 not involve manual configuration over the I2RS plane 954 (I2RS client, I2RS agent, and application). 956 Explanation: 958 Granting or configuring an application with new policy should not 959 require manual configuration of I2RS clients, I2RS agents, or other 960 applications. 962 SEC-ENV-REQ 19: Access control should be scalable when the number of 963 application grows as well as when the number of I2RS 964 client increases. 966 Explanation: 968 A typical implementation of a local I2RS client access control 969 policies may result in creating manually a system user associated to 970 each application. Such an approach is likely not to scale when the 971 number of applications increases into the hundreds. 973 SEC-ENV-REQ 20: Access control should be dynamically managed and 974 easily updated. 976 Explanation: 978 Although the numberof I2RS clients is expected to be lower than the 979 number of application, as I2RS agent provide access to the routing 980 resource, it is of primary importance that an access can be granted 981 or revoke in an efficient way. 983 SEC-ENV-REQ 21: I2RS clients and I2RS agents should be uniquely 984 identified in the network to enable centralized 985 management of the I2RS access control policies. 987 Explanation: 989 Centralized management of the access control policies of an I2RS 990 plane with network that hosts several I2RS applications, clients and 991 agents requires that each devices can be identified. 993 4.2. I2RS Agent Access Control Policies 995 Overview: 997 The I2RS agent access control restricts the routing system resource 998 access to authorized identities - possible access policies may be 999 none, read or write. The initiator of an access request to a routing 1000 resource is always an application. However, it remains challenging 1001 for the I2RS agent to establish its access control policies based on 1002 the application that initiates the request. 1004 First, when an I2RS client acts as a broker, the I2RS agent may not 1005 be able to authenticate the application. In that sense, the I2RS 1006 agent relies on the capability of the I2RS client to authenticate the 1007 applications and apply the appropriated I2RS client access control. 1009 Second, an I2RS agent may not uniquely identify a piece of software 1010 implementing an I2RS client. In fact, an I2RS client may be provided 1011 multiple identities which can be associated to different roles or 1012 privileges. The I2RS client is left responsible for using them 1013 appropriately according to the application. 1015 Third, each I2RS client may contact various I2RS agent with different 1016 privileges and access control policies. 1018 4.2.1. I2RS Agent Access Control 1020 This section provides recommendations on the I2RS agent access 1021 control policies to keep I2RS access control coherent within the I2RS 1022 plane. 1024 Requirements: 1026 SEC-ENV-REQ 22: I2RS agent access control policies should be 1027 primarily based on the I2RS clients as described in 1028 [RFC7921]. 1030 SEC-ENV-REQ 23: I2RS agent access control policies MAY be based on 1031 the application if the application identity has been 1032 authenticated by the I2RS client and passed via the 1033 secondary identity to the I2RS agent. 1035 SEC-ENV-REQ 24: The I2RS agent should know which identity (E.g. 1036 system user) performed the latest update of the 1037 routing resource. This is true for an identity 1038 inside and outside the I2RS plane so the I2RS agent 1039 can appropriately perform an update according to the 1040 priorities associated to the requesting identity and 1041 the identity that last updated the resource. 1043 SEC-ENV-REQ 25: the I2RS agent should have a "I2RS agent overwrite 1044 Policy" that indicates how identities can be 1045 prioritized. This requirements is also described in 1046 section 7.6 of [RFC7921]. Similar requirements exist 1047 for components within the I2RS plane, but this is 1048 within the scope of the I2RS protocol security 1049 requirements 1050 [I-D.ietf-i2rs-protocol-security-requirements]. 1052 Explanation: 1054 If the I2RS application is authenticated to the I2RS client, and the 1055 I2RS client is authenticated to the I2RS agent, and the I2RS client 1056 uses the opaque secondary identifier to pass an authenticated 1057 identifier to the I2RS agent, then this identifier may be used for 1058 access control. However, caution should be taken when using this 1059 chain of authentication since the secondary identifier is intended in 1060 the I2RS protocol only to aid traceability. 1062 From the environment perspective the I2RS agent MUST be aware when 1063 the resource has been modified outside the I2RS plane by another 1064 plane (management, control, or forwarding). The prioritization 1065 between the different planes should set a deterministic policy that 1066 allows the collision of two planes (I2RS plane and another plane) to 1067 be resolved via an overwrite policy in the I2RS agent. 1069 Similar requirements exist for knowledge about identities within the 1070 I2RS plane which modify things in the routing system, but this is 1071 within the scope of the I2RS protocol's requirements for ephemeral 1072 state [I-D.ietf-i2rs-ephemeral-state] and security requirements 1073 [I-D.ietf-i2rs-protocol-security-requirements]. 1075 4.2.2. I2RS Client Access Control Policies 1077 Overview: 1079 The I2RS client access control policies are responsible for 1080 authenticating the application managing the privileges for the 1081 applications, and enforcing access control to resources by the 1082 applications. 1084 Requirements: 1086 REQ 26: I2RS client should authenticate its applications. If the 1087 I2RS client acts as a broker and supports multiple 1088 applications, it should authenticate each application. 1090 REQ 27: I2RS client should define access control policies associated 1091 to each applications. An access to a routing resource by an 1092 application should not be forwarded immediately and 1093 transparently by the I2RS client based on the I2RS agent 1094 access control policies. The I2RS client should first check 1095 whether the application has sufficient privileges, and if so 1096 send an access request to the I2RS agent. 1098 Explanation: 1100 If no authentication mechanisms have being provided between the I2RS 1101 client and the application, then I2RS client must be dedicated to a 1102 single application. By doing so, application authentication relies 1103 on the I2RS authentication mechanisms between the I2RS client and the 1104 I2RS agent. 1106 If an I2RS client has multiple identities that are associated with 1107 different privileges for accessing an I2RS agent(s), the I2RS client 1108 access control policies should specify the I2RS client identity with 1109 the access control policy. 1111 4.2.3. Application and Access Control Policies 1113 Overview 1115 Applications do not enforce access control policies. Instead these 1116 are enforced by the I2RS clients and the I2RS agents. This section 1117 provides recommendations for applications in order to ease I2RS 1118 access control by the I2RS client and the I2RS agent. 1120 Requirements: 1122 SEC-ENV-REQ 28: Applications SHOULD be uniquely identified by their 1123 associated I2RS clients 1125 Explanation: 1127 Different application may use different methods (or multiple methods) 1128 to communicate with its associated I2RS client, and each application 1129 may not use the same form of an application identifier. However, the 1130 I2RS client must obtain an identifier for each application. One 1131 method for this identification can be a system user id. 1133 SEC-ENV-REQ 29: Each application SHOULD be associated to a restricted 1134 number of I2RS client 1136 Explanation: 1138 The I2RS client provides access to resource on its behalf and this 1139 access should only be granted for trusted applications, or 1140 applications with an similar level of trust. This does not prevent 1141 an I2RS client to host a large number of applications with the same 1142 levels of trust. 1144 SEC-ENV-REQ 30: An application SHOULD be provided means and methods 1145 to contact their associated I2RS client. 1147 Explanation: 1149 It is obvious when an I2RS client belongs to the application as part 1150 of a module or a library that the application can communicate with a 1151 I2RS client. Similarly, if the application runs into a dedicated 1152 system with a I2RS client, it is obvious which I2RS client the 1153 application should contact. If the application connects to the I2RS 1154 client remotely, the application needs some means to retrieve the 1155 necessary information to contact its associated I2RS client (e.g. an 1156 IP address or a FQDN). 1158 5. I2RS Application Isolation 1160 A key aspect of the I2RS architecture is the network oriented 1161 application that uses the I2RS high bandwidth programmatic interface 1162 to monitor or change one or more routing systems. I2RS applications 1163 could be control by a single entity or serve various tenants of the 1164 network. If multiple entities use an I2RS application to monitor or 1165 change the network, security policies must preserve the isolation of 1166 each entity's control and not let malicious entities controlling one 1167 I2RS application interfere with other I2RS applications. 1169 This section discusses both security aspects related to 1170 programmability as well as application isolation in the I2RS 1171 architecture. 1173 5.1. Robustness Toward Programmability 1175 Overview 1177 I2RS provides a programmatic interface in and out of the Internet 1178 routing system which provides the following advantages for security: 1180 o the use of automation reduces configuration errors; 1181 o the programmatic interface enables fast network reconfiguration 1182 and agility in adapting to network attacks; and 1184 o monitoring facilities to detect a network attack, and 1185 configuration changes which can help mitigate the network attack. 1187 Programmability allows applications to flexible control which may 1188 cause problems due to: 1190 o applications which belong to different tenants with different 1191 objectives, 1193 o applications which lack coordination resulting in unstable routing 1194 configurations such as oscillations between network 1195 configurations, and creation of loops for example. For example, 1196 one application may monitor a state and change to positive, and a 1197 second application performs the reverse operation (turns it 1198 negative). This fluctuation can cause a routing system to become 1199 unstable. 1201 The I2RS plane requires data and application isolation to prevent 1202 such situations to happen. However, to guarantee the network 1203 stability constant monitoring and error detection are recommended to 1204 be activated. 1206 Requirement: 1208 SEC-ENV-REQ 31: The I2RS agents should monitor constantly parts of 1209 the system for which I2RS clients or applications 1210 have provided requests. It should also be able to 1211 detect any I2RS clients or applications causing 1212 problems that may lead the routing system in an 1213 unstable state. 1215 Explanation: 1217 Monitoring consists at least in logging events and receiving streams 1218 of data. I2RS Plane implementations should monitor the I2RS 1219 applications and I2RS clients for potential problems. The cause for 1220 the I2RS clients or applications providing problematic requests can 1221 be failures in the implementation code or malicious intent. ] 1223 5.2. Application Isolation 1224 5.2.1. DoS 1226 Overview: 1228 Requirements for robustness to DoS attacks have been addressed in the 1229 communication channel section [RFC7921]. This section focuses on 1230 requirements for application isolation that help prevent DoS. 1232 Requirements: 1234 SEC-ENV-REQ 32: In order to prevent DoS, it is recommended the I2RS 1235 agent controls the resources allocated to each I2RS 1236 clients. I2RS client that acts as broker may not be 1237 protected as efficiently against these attacks unless 1238 the broker performs resource controls for the hosted 1239 applications. 1241 SEC-ENV-REQ 33: I2RS agent SHOULD make a response redirection unless 1242 the redirection is previously validated and agreed by 1243 the destination. 1245 SEC-ENV-REQ 34: I2RS Appications should avoid the use of underlying 1246 protocols that are not robust to reflection attacks. 1248 Explanation: 1250 The I2RS interface is used by application to interact with the 1251 routing states. If the I2RS client is shared between multiple 1252 applications, one application can use the I2RS client to perform DoS 1253 or DDoS attacks on the I2RS agent(s) and through the I2RS agents 1254 attacks on the network. DoS attack targeting the I2RS agent would 1255 consist in providing requests that keep the I2RS agent busy for a 1256 long time. These attacks on the I2RS agent may involve an 1257 application (requesting through an I2RS Client) heavy computation by 1258 the I2RS agent in order to block operations like disk access. 1260 Some DoS attacks may attack the I2RS Client's reception of 1261 notification and monitoring data stream over the network. Other DoS 1262 attacks may focus on the application directly by performing 1263 reflection attacks to reflect traffic. In such an attack could be 1264 performed by first detecting an application is related to monitoring 1265 the RIB or changing the RIB. Reflection-based DoS may be also attack 1266 at various levels in the stack utilizing UDP at the service to 1267 redirect data to a specific repository 1269 I2RS implementation should consider how to protect I2RS against such 1270 attacks. 1272 5.2.2. Application Logic Control 1274 Overview 1276 This section examines how application logic must be design to ensure 1277 application isolation. 1279 Requirements: 1281 SEC-ENV-REQ 35: Application logic should remain opaque to external 1282 listeners. Application logic may be partly hidden by 1283 encrypting the communication between the I2RS client 1284 and the I2RS agent. Additional ways to obfuscate the 1285 communications may involve sending random messages of 1286 various sizes. Such strategies have to be balanced 1287 with network load. Note that I2RS client broker are 1288 more likely to hide the application logic compared to 1289 I2RS client associated to a single application. 1291 Explanation: 1293 Applications use the I2RS interface in order to update the routing 1294 system. These updates may be driven by behavior on the forwarding 1295 plane or any external behaviors. In this case, correlating 1296 observation to the I2RS traffic may enable to derive the application 1297 logic. Once the application logic has been derived, a malicious 1298 application may generate traffic or any event in the network in order 1299 to activate the alternate application. 1301 6. Security Considerations 1303 The whole document is about security requirements for the I2RS 1304 environment. To protect personal privacy, any identifier (I2RS 1305 application identifier, I2RS client identifier, or I2RS agent 1306 identifier) should not contain personal identifiable information. 1308 7. IANA Considerations 1310 No IANA considerations for this requirements. 1312 8. Acknowledgments 1314 A number of people provided a significant amount of helping comments 1315 and reviews. Among them the authors would like to thank Russ White, 1316 Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, 1317 Alia Atlas, and Linda Dunbar. 1319 9. References 1321 9.1. Normative References 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, 1325 DOI 10.17487/RFC2119, March 1997, 1326 . 1328 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 1329 Statement for the Interface to the Routing System", 1330 RFC 7920, DOI 10.17487/RFC7920, June 2016, 1331 . 1333 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1334 Nadeau, "An Architecture for the Interface to the Routing 1335 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1336 . 1338 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1339 the Routing System (I2RS) Traceability: Framework and 1340 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1341 2016, . 1343 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1344 for Subscription to YANG Datastores", RFC 7923, 1345 DOI 10.17487/RFC7923, June 2016, 1346 . 1348 [I-D.ietf-i2rs-protocol-security-requirements] 1349 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1350 Related Requirements", draft-ietf-i2rs-protocol-security- 1351 requirements-17 (work in progress), September 2016. 1353 9.2. Informative References 1355 [I-D.ietf-i2rs-ephemeral-state] 1356 Haas, J. and S. Hares, "I2RS Ephemeral State 1357 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 1358 progress), November 2016. 1360 [I-D.ietf-netconf-rfc6536bis] 1361 Bierman, A. and M. Bjorklund, "Network Configuration 1362 Protocol (NETCONF) Access Control Model", draft-ietf- 1363 netconf-rfc6536bis-00 (work in progress), January 2017. 1365 [I-D.ietf-netmod-revised-datastores] 1366 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1367 and R. Wilton, "A Revised Conceptual Model for YANG 1368 Datastores", draft-ietf-netmod-revised-datastores-00 (work 1369 in progress), December 2016. 1371 Authors' Addresses 1373 Daniel Migault 1374 Ericsson 1375 8400 boulevard Decarie 1376 Montreal, QC H4P 2N2 1377 Canada 1379 Phone: +1 514-452-2160 1380 Email: daniel.migault@ericsson.com 1382 Joel Halpern 1383 Ericsson 1385 Email: Joel.Halpern@ericsson.com 1387 Susan Hares 1388 Huawei 1389 7453 Hickory Hill 1390 Saline, MI 48176 1391 USA 1393 Email: shares@ndzh.com