idnits 2.17.1 draft-ietf-i2rs-security-environment-reqs-00.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 -- The document date (October 7, 2015) is 3125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-protocol-security-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS WG D. Migault, Ed. 3 Internet-Draft J. Halpern 4 Intended status: Informational Ericsson 5 Expires: April 9, 2016 S. Hares 6 Huawei 7 October 7, 2015 9 I2RS Environment Security Requirements 10 draft-ietf-i2rs-security-environment-reqs-00 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. As a result, the requirements provided 17 in this document are intended to provide good security practise so 18 I2RS can be securely deployed and operated. 20 These security requirements are designated as environment security 21 requirements as opposed to the protocol security requirements. The 22 reason to have separate document is that protocol security 23 requirements are intended to help the design of the I2RS protocol 24 whether the environment requirements are rather intended for 25 deployment or implementations. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 9, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 64 4. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 4 65 4.1. I2RS plane and management plane . . . . . . . . . . . . . 4 66 4.2. I2RS plane and forwarding plane . . . . . . . . . . . . . 5 67 4.3. I2RS plane and Control plane . . . . . . . . . . . . . . 6 68 4.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 69 5. I2RS Access Control for routing system resources . . . . . . 8 70 5.1. I2RS Access Control architecture . . . . . . . . . . . . 8 71 5.2. I2RS Agent Access Control policies . . . . . . . . . . . 13 72 5.3. I2RS Client Access Control policies . . . . . . . . . . . 14 73 5.4. Application and Access Control policies . . . . . . . . . 15 74 6. I2RS Application Isolation . . . . . . . . . . . . . . . . . 16 75 6.1. Robustness toward programmability . . . . . . . . . . . . 16 76 6.2. Application Isolation . . . . . . . . . . . . . . . . . . 17 77 6.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 6.2.2. Application Control . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 11.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 This document provides environment security requirements for the I2RS 97 architecture. Environment security requirements are independent of 98 the protocol used for I2RS. As a result, the requirements provided 99 in this document are intended to provide good security practise so 100 I2RS can be securely deployed and operated. 102 These security requirements are designated as environment security 103 requirements as opposed to the protocol security requirements 104 described in [I-D.ietf-i2rs-protocol-security-requirements]. The 105 reason to have separate document is that protocol security 106 requirements are intended to help the design of the I2RS protocol 107 whether the environment requirements are rather intended for 108 deployment or implementations. 110 Even though I2RS is mostly concerned by the interface between the 111 I2RS Client and the I2RS Agent, the security recommendations must 112 consider the entire I2RS architecture, specifying where security 113 functions may be hosted, and what should be met so to address any new 114 attack vectors exposed by deploying this architecture. In other 115 words, security has to be considered globally over the complete I2RS 116 architecture and not only on the interfaces. 118 I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes 119 the I2RS components and their interactions to provide a programmatic 120 interface for the routing system. I2RS components as well as their 121 interactions have not yet been considered in conventional routing 122 systems. As such it introduces a need to interface with the routing 123 system designated as I2RS plane in this document. 125 This document is built as follows. Section 4 describes how the I2RS 126 plane can be contained or isolated from existing management plane, 127 control plane and forwarding plane. The remaining sections of the 128 document focuses on the security within the I2RS plane. Section 5 129 analyzes how the I2RS Access Control policies can be deployed 130 throughout the I2RS plane in order to only grant access to the 131 routing system resources to authorized components with the authorized 132 privileges. This also includes providing a robust communication 133 system between the components. Then, Section 6 details how I2RS 134 keeps applications isolated one from another and do not affect the 135 I2RS components. Applications may be independent, with different 136 scopes, owned by different tenants. In addition, they modify the 137 routing system that may be in an automatic way. 139 The reader is expected to be familiar with the 140 [I-D.ietf-i2rs-architecture]. The document provides a list of 141 environment security requirements. Motivations are placed before the 142 requirements are announced. 144 3. Terminology and Acronyms 146 - Environment Security Requirements : 148 - I2RS plane : The environment the I2RS process is running on. It 149 includes the Applications, the I2RS Client and the I2RS Agent. 151 - I2RS user : The user of the I2RS client software or system. 153 - I2RS Access Control policies: policies controlling access of the 154 routing resources by Applications. These policies are divided 155 into policies applied by the I2RS Client regarding Applications 156 and policies applied by the I2RS Agent regarding I2RS Clients. 158 - I2RS Client Access Control policies : The Access Control policies 159 processed by the I2RS Client. 161 - I2RS Agent Access Control policies : The Access Control policies 162 processed by the I2RS Agent. 164 4. I2RS Plane Isolation 166 Isolating the I2RS plane from other network plane, such as the 167 control plane, is foundational to the security of the I2RS 168 environment. Clearly differentiating I2RS components from the rest 169 of the network protects the I2RS components from vulnerabilities in 170 other parts of the network, and protect other systems vital to the 171 health of the network from vulnerabilities in the I2RS plane. 172 Separating the I2RS plane from other network control and forwarding 173 planes is similar to the best common practice of containerizing 174 software into modules, and defense in depth in the larger world of 175 network security. 177 That said the I2RS plane cannot be considered as completely isolated 178 from other planes, and interactions should be identified and 179 controlled. Follows a brief description on how the I2RS plane 180 positions itself in regard to the other planes. The description is 181 indicative, and may not be exhaustive. 183 4.1. I2RS plane and management plane 185 The I2RS plane purpose is to provide a standard programmatic 186 interface of the routing system resources to network oriented 187 applications. Control plane and forwarding planes are related to 188 routing protocols, and I2RS is based on top of those. The management 189 plane is usually vendor specific, provides a broader control over the 190 networking equipment such as system service. Given its associated 191 privileges it is expected to be reserved to highly trusted users like 192 network administrators. 194 The I2RS plane and the management plane both interact with several 195 common elements on forwarding and packet processing devices. 196 [I-D.ietf-i2rs-architecture] describes several of these interaction 197 points such as the local configuration, the static system state, 198 routing, and signalling. Because of this potential overlaps, a 199 routing resource may be accessed by different means (APIs, 200 applications) and different planes. To keep these overlaps under 201 control, one could either control the access to these resources with 202 northbound APIs for example. Northbound APIs are provided to limit 203 the scope of the applications toward the routing resources. In our 204 case, the northbound API may be provided for the I2RS applications by 205 the I2RS Client as well as to the management plane. In case 206 conflicting overlaps cannot be avoided, and routing resource can be 207 accessed by both the management plane and the I2RS plane, then, they 208 should be resolved in a deterministic way. 210 On the northbound side, there must be clear protections against the 211 I2RS system "infecting" the management system with bad information, 212 or the management system "infecting" the I2RS system with bad 213 information. The primary protection in this space is going to need 214 to be validation rules on the speed of information flow, value limits 215 on the data presented, and other protections of this type. 217 On the conflicting side/issues, there should be clear rules about 218 which plan's commands win in the case of conflict in order to prevent 219 attacks where the two systems can be forced to deadlock. 221 4.2. I2RS plane and forwarding plane 223 Applications hosted on I2RS Client belongs to the I2RS plane. These 224 Applications are hard to remain constrained into the I2RS plane, or 225 even to limit their scope within the I2RS plane. 227 Applications using I2RS are part of the I2RS plane but may also 228 interact with other components outside the I2RS plane. A common 229 example may be an application uses I2RS to configure the network 230 according to security or monitored events. As these events are 231 monitored on the forwarding plane and not the I2RS plane, the 232 application breaks plane isolation. 234 In addition, applications may communicate with multiple I2RS Clients; 235 as such, any given application may have a broader view of the current 236 and potential states of the network and the I2RS plane itself. 238 Because of this, any individual application could be an effective 239 attack vector against the operation of the network, the I2RS plane, 240 or any plane with which the I2RS plane interacts. There is little 241 the I2RS plane can do to validate applications with which it 242 interacts, other than to provide some broad general validations 243 against common misconfigurations or errors. As with the separation 244 between the management plane and the I2RS plane, this should 245 minimally take the form of limits on information accepted, limits on 246 the rate at which information is accepted, and rudimentary checks 247 against intentionally formed routing loops or injecting information 248 that would cause the control plane to fail to converge. Other forms 249 of protection may be necessary. 251 4.3. I2RS plane and Control plane 253 The network control plane consists of the processes and protocols 254 that discover topology, advertise reachability, and determine the 255 shortest path between any location on the network and any 256 destination. It is not anticipated there will be any interactions 257 between the on-the-wire signalling used by the control plane. 258 However, in some situations the I2RS system could modify information 259 in the local databases of the control plane. This is not normally 260 recommended, as it can bypass the normal loop free, loop free 261 alternate, and convergence properties of the control plane. However, 262 if the I2RS system does directly inject information into these 263 tables, the I2RS system should ensure that loop free routing is 264 preserved, including loop free alternates, tunnelled interfaces, 265 virtual overlays, and other such constructions. Any information 266 injected into the control plane directly could cause the control 267 plane to fail to converge, resulting in a complete network outage. 269 4.4. Recommendations 271 To isolate I2RS transactions from other planes, it is recommended 272 that: 274 REQ 1: Application-to-routing system resources communications should 275 use an isolated communication channel. Various level of 276 isolation can be considered. The highest level of isolation 277 may be provided by using a physically isolated network. 278 Alternatives may also consider logical isolation; for example 279 by using vLAN. Eventually, in virtual environment that 280 shares a common infrastructure, encryption, for example by 281 using TLS or IPsec, may also be used as a way to enforce 282 isolation. 284 REQ 2: The interface (like the IP address) used by the routing 285 element to receive I2RS transactions should be a dedicated 286 physical or logical interface. As previously, mentioned a 287 dedicated physical interface may contribute to a higher 288 isolation, however logical isolation be also be considered 289 for example by using a dedicated IP address or a dedicated 290 port. 292 When the I2RS Agent performs an action on a routing element, the 293 action is performed via process(es) associated to a system user . In 294 a typical UNIX system, the user is designated with a user id (uid) 295 and belong to groups designated by group ids (gid). These users are 296 dependent of the routing element's operation system and are 297 designated I2RS System Users. Some implementation may use a I2RS 298 System User for the I2RS Agent that proxies the different I2RS 299 Client, other implementations may use I2RS System User for each 300 different I2RS Clients. 302 REQ 3: I2RS Agent should have permissions separate from any other 303 entity (for example any internal system management processes 304 or CLI processes). 306 I2RS resource may be shared with the management plane and the control 307 plane. It is hardly possible to prevent interactions between the 308 planes. I2RS routing system resource management is limited to the 309 I2RS plane. As such, update of I2RS routing system outside of the 310 I2RS plane may be remain unnoticed unless explicitly notified to the 311 I2RS plane. Such notification is expected to trigger synchronization 312 of the I2RS resource state within each I2RS component. This 313 guarantees that I2RS resource are maintained in a coherent state 314 among the I2RS plane. In addition, depending on the I2RS resource 315 that is updated as well as the origin of the modification performed, 316 the I2RS Access Control policies may be impacted. More especially, a 317 I2RS Client is more likely to update an I2RS resources that has been 318 updated by itself, then by the management plane for example. 320 REQ 4: I2RS plane should be informed when a routing system resource 321 is modified by a user outside the I2RS plane access. The 322 notification is not expected to flood the I2RS plane. 323 Instead, notification is expected to be provided to the I2RS 324 components interacting, configuring or monitoring the routing 325 system resource. The notification is at least provided by 326 the I2RS Agent to the various I2RS Client, but additional 327 mechanisms might eventually be required so I2RS Client can 328 relay the notification to the I2RS applications. This is 329 designated as "I2RS resource modified out of I2RS plane". 330 This requirements is also described in section 7.6 of 331 [I-D.ietf-i2rs-architecture] for the I2RS Client. This 332 document extends the requirement to the I2RS plane, in case 333 future evolution of the I2RS plane. 335 REQ 5: I2RS plane should define an "I2RS plane overwrite policy". 336 Such policy defines how an I2RS is able to update and 337 overwrite a resource set by a user outside the I2RS plane. 338 Such hierarchy has been described in section 6.3 and 7.8 of 339 [I-D.ietf-i2rs-architecture] 341 5. I2RS Access Control for routing system resources 343 This section provides recommendations on how I2RS Access Control 344 policies associated to the routing system resources. These policies 345 only apply within the I2RS plane. More especially, the policies are 346 associated to the Applications, the I2RS Clients and the I2RS Agents, 347 with their associated identity and roles. 349 Note that the deployment of Applications, I2RS Client and I2RS Agent 350 in a closed environment, should not be considered by default as a 351 secure environment. Even for closed environment access control 352 policies should be carefully defined to be able to, in the future to 353 carefully extend the I2RS plane to remote Applications or remote I2RS 354 Clients. As a result, this section always consider the case 355 Applications and I2RS Client can be located locally, in a closed 356 environment or distributed over open networks. 358 Although [I-D.ietf-i2rs-protocol-security-requirements] provides 359 security requirements of the transport and protocol between the I2RS 360 Client and the I2RS Agent, this section is mostly focused on access 361 control. 363 5.1. I2RS Access Control architecture 365 Applications access to routing system resource via numerous 366 intermediaries nodes. The application communicates with an I2RS 367 Client. In some cases, the I2RS Client is only associated to a 368 single application, but the I2RS Client may also act as a broker. 369 The I2RS Client, then, communicates with the I2RS Agent that may 370 eventually access the resource. 372 The I2RS Client broker approach provides scalability to the I2RS 373 architecture as it avoids that each Application be registered to the 374 I2RS Agent. Similarly, the I2RS Access Control should be able to 375 scale numerous applications. 377 REQ 6: I2RS Access Control should be performed through the whole 378 I2RS plane. It should not be enforced by the I2RS Agent only 379 within the routing element. Instead, the I2RS Client should 380 enforce the I2RS Client Access Control against Applications 381 and the I2RS Agent should enforce the I2RS Agent Access 382 Control against the I2RS Clients. Note that I2RS Client 383 Access Control is not in the scope of the I2RS architecture 384 [I-D.ietf-i2rs-architecture], which exclusively focuses on 385 the I2RS Agent Access Control. 387 This results in a layered and hierarchical or multi-party I2RS Access 388 Control. An application will be able to access a routing system 389 resource only if both the I2RS Client is granted access by the I2RS 390 Agent and the application is granted access by the I2RS Client. 392 REQ 7: When an access request to a routing resource is refused by 393 one party (the I2RS Client or the I2RS Agent), the initiator 394 of the request (e.g the Application) as well as all 395 intermediaries should indicate the reason the access has not 396 been granted as well as the entity that has rejected the 397 request. 399 REQ 8: In order to provide coherent Access Control policies enforced 400 by multiple parties (e.g. the I2RS Client or the I2RS Agent), 401 theses parties should trust each others, and communication 402 between them should also be trusted, - that is should not 403 introduce additional vector of attacks. 405 In case the I2RS Client Access Control or the I2RS Agent Access 406 Control does not grant access to a routing system resource, the 407 Application should be able to determine whether its request has been 408 rejected by the I2RS Client or the I2RS Agent as well as the reason 409 that caused the reject. More specifically, the I2RS Agent may reject 410 the request because, for example, the I2RS Client is not an 411 authorized I2RS Client, or because the I2RS Client does not not have 412 enough privileges. The I2RS Client should be notified of the reason 413 that caused the reject by the I2RS Agent, and The I2RS Client should 414 return a message to the Application, indicating the I2RS Client is 415 not authorized or does not have enough privileges. Similarly, if the 416 I2RS Client does not grant the access to the Application, the I2RS 417 Client should also inform the Application. The error message 418 returned should be for example: "Read failure: you do not have the 419 read permission", "Write failure: you do not have write permission" 420 or "Write failure: resource accessed by someone else". This 421 requirement has been written in a generic manner as it concerns 422 various interactions: interactions between the application and the 423 I2RS Client, interactions between the I2RS Client and the I2RS Agent. 424 In the latest case, the requirement is part of the protocol security 425 requirements addressed by 426 [I-D.ietf-i2rs-protocol-security-requirements]. 428 Although [I-D.ietf-i2rs-protocol-security-requirements] is focused on 429 transport security requirements between the I2RS Client and the I2RS 430 Agent, the similar requirements may apply between the Application and 431 the I2RS Client for a remote Application. 433 REQ 9: I2RS Client or I2RS Agent SHOULD also be able to refuse a 434 communication with an Application or an I2RS Client when the 435 communication channel does not fulfill enough security 436 requirements. For example, the it should be able to reject 437 messages over a communication channel that can be easily 438 hijacked, like a clear text UDP channel. 440 In order to limit the number of access request that result in an 441 error, each Application or I2RS Client may be able to retrieve the 442 I2RS Access Control policies that applies to it. This subset of 443 rules is designated as the "Individual I2RS Access Control policies". 444 As these policies are subject to changes, a dynamic synchronization 445 mechanism should be provided. However, such mechanism may be 446 implemented with different level of completeness and dynamicity of 447 the Individual I2RS Access Control policies. Caching requests that 448 have been rejected may be one such variant. It remains relatively 449 easy to implement and may avoid the complete disclosure of the Access 450 Control policies of the I2RS Agent. In fact the relative disclosure 451 of Access Control policies may leak confidential information in case 452 of misconfiguration and should be balanced with the level of trust of 453 the I2RS Client and the necessity of distributing the enforcement of 454 the Access Control policies. 456 REQ 10: The I2RS Client may be able to request for its I2RS Access 457 Control subset policies to the I2RS Agent or cache requests 458 that have been rejected by the I2RS Agent to limit forwarding 459 unnecessary queries to the I2RS Agent. 461 REQ 11: The I2RS Client may be able to be notified when its I2RS 462 Access Control subset policies have been updated by the I2RS 463 Agent. 465 Similarly, for the Applications 467 REQ 12: The Applications may be able to request for its I2RS Access 468 Control subset policies, so to limit forwarding unnecessary 469 queries to the I2RS Client. 471 REQ 13: The Applications may be able to subscribe a service that 472 provides notification when its I2RS Access Control subset 473 policies have been updated. 475 I2RS Access Control should be appropriately be balanced between the 476 I2RS Client and the I2RS Agent. I2RS Access Control should not 477 solely rely only on the I2RS Client or the I2RS Agent as illustrated 478 below: 480 - 1) I2RS Clients are dedicated to a single Application: In this 481 case, it is likely that I2RS Access Control is enforced only by 482 the I2RS Agent, as the I2RS Client is likely to accept all 483 access request of the application. However, it is recommended 484 that even in this case, I2RS Client Access Control is not based 485 on an "Allow anything from application" policy, but instead the 486 I2RS Client specifies accesses that are enabled. In addition, 487 the I2RS Client may sync its associated I2RS Access Control 488 policies with the I2RS Agent to limit the number of refused 489 access requests being sent to the I2RS Agent. The I2RS Client 490 is expected to balance pro and cons between sync its access 491 control policies with the I2RS Agent and simply guessing the 492 access request to the I2RS Agent. 494 - 2) A single I2RS Client acts as a broker for all Applications: In 495 the case the I2RS Agent has a single I2RS Client. Such 496 architecture results in I2RS Client with high privileges, as it 497 sums the privileges of all applications. As end-to-end 498 authentication is not provided between the Application and the 499 I2RS Agent, if the I2RS Client becomes corrupted, it is 500 possible for the malicious application escalates its privileges 501 and make the I2RS Client perform some action on behalf of the 502 application with more privileges. This would not have been 503 possible with end-to-end authentication. In order to mitigate 504 such attack, the I2RS Client that acts as a broker is expected 505 to host application with an equivalent level of privileges. 507 REQ 14: The I2RS Access Control should explicitly specify accesses 508 that are granted. More specifically, anything not explicitly 509 granted -- the default rule-- should be denied. 511 In addition to distribute the I2RS Access Control policies between 512 I2RS Clients and I2RS Agents, I2RS Access Control policies can also 513 be distributed within a set of I2RS Clients or a set of I2RS Agents. 515 REQ 15: I2RS Clients should be distributed and act as brokers for 516 Applications that share roughly similar permissions. This 517 avoids ending with over privileges I2RS Client compared to 518 hosted applications and thus discourages applications to 519 perform privilege escalation within an I2RS Client. 521 REQ 16: I2RS Agents should be avoided being granted over privileges 522 regarding to their authorized I2RS Client. I2RS Agent should 523 be shared by I2RS Client with roughly similar permissions. 524 More explicitly, an I2RS Agent shared between I2RS Clients 525 that are only provided read access to the routing system 526 resources does not need to perform any write access, and so 527 should not be provided these accesses. Suppose an I2RS 528 Client requires write access to the resources. It is not 529 recommended to grant the I2RS Agent the write access in order 530 to satisfy a unique I2RS Client. Instead, the I2RS Client 531 that requires write access should be connected to a I2RS 532 Agent that is already shared by I2RS Client that requires a 533 write access. 535 Access Control policies enforcement should be monitored in order to 536 detect violation of the policies or detect an attack. Access Control 537 policies enforcement may not be performed by the I2RS Client or the 538 I2RS Agent as violation may require a more global view of the I2RS 539 Access Control policies. As a result, consistency check and 540 mitigation may instead be performed by the management plane. 541 However, I2RS Clients and I2RS Agents play a central role. 543 REQ 17: I2RS Client and I2RS Agent should be able to log the various 544 transaction they perform, as well as suspicious activities. 545 These logs should be collected regularly and analyzed by 546 functions that may be out of the I2RS plane. 548 Access Control policies should be implemented so that they remain 549 manageable in short and longer term. This means the way they are 550 managed today should be address future deployment and use of I2RS. 552 REQ 18: Access Control should be managed in an automated way, that is 553 granting or revoking an Application should not involve manual 554 configuration over the I2RS plane - like all the I2RS 555 Clients. 557 REQ 19: Access Control should be scalable when the number of 558 Application grows as well as when the number of I2RS Client 559 increases. A typical implementation of a local I2RS Client 560 Access Control policies may result in creating manually a 561 system user associated to each Application. Such an approach 562 is likely not to scale when the number of Applications 563 increases or the number of I2RS Client increases. 565 REQ 20: Access Control should be dynamically managed and easy to be 566 updated. Although the number of I2RS Clients is expected to 567 be lower than the number of Application, as I2RS Agent 568 provide access to the routing resource, it is of primary 569 importance that an access can be granted or revoke in an 570 efficient way. 572 REQ 21: I2RS Clients and I2RS Agents should be uniquely identified in 573 the network to enable centralized management of the I2RS 574 Access Control policies. 576 5.2. I2RS Agent Access Control policies 578 The I2RS Agent Access Control restricts the routing system resource 579 access to authorized identities - possible access policies may be 580 none, read or write. The initiator of an access request to a routing 581 resource is always an Application. However, it remains challenging 582 for the I2RS Agent to establish its access control policies based on 583 the application that initiates the request. First, when an I2RS 584 Client acts as a broker, the I2RS Agent may not be able to 585 authenticate the Application. In that sense, the I2RS Agent relies 586 on the capability of the I2RS Client to authenticate the Applications 587 and apply the appropriated I2RS Client Access Control. Then, an I2RS 588 Agent may not uniquely identify a piece of software implementing an 589 I2RS Client. In fact, an I2RS Client may be provided multiple 590 identities which can be associated to different roles or privileges. 591 The I2RS Client is left responsible for using them appropriately 592 according to the Application. Finally, each I2RS Client may contact 593 various I2RS Agent with different privileges and Access Control 594 policies. 596 This section provides recommendations on the I2RS Agent Access 597 Control policies to keep I2RS Access Control coherent within the I2RS 598 plane. 600 REQ 22: I2RS Agent Access Control policies should be primarily based 601 on the I2RS Clients as described in 602 [I-D.ietf-i2rs-architecture]. 604 REQ 23: I2RS Agent Access Control policies may be based on the 605 Application. In this case the identity of the Application 606 MUST be authenticated by the I2RS Agent, and the secondary 607 identity used to tag the application as defined in 608 [I-D.ietf-i2rs-architecture] should be considered cautiously. 609 The tag may be used associated only to an authenticated I2RS 610 Client that is known to authenticate its Application. 612 The I2RS Agent Access Control policies may evolve over time as 613 resource may also be updated outside the I2RS plane. Similarly, a 614 given resource may be accessed by multiple I2RS users within the I2RS 615 plane. Although this is considered as an error, depending on the 616 I2RS Client that performed the update, the I2RS may accept or refuse 617 to overwrite the routing system resource. 619 REQ 24: The I2RS Agent should know which identity (most likely system 620 user) performed the latest update of the routing resource. 621 This is true for an identity inside and outside the I2RS 622 plane, so the I2RS Agent can appropriately perform an update 623 according to the priorities associated to the requesting 624 identity and the identity that last updated the resource. On 625 an environment perspective, the I2RS Agent MUST be aware when 626 the resource has been modified outside the I2RS plane, as 627 well as its priority associated towards the I2RS plane. 628 Similar requirements exist for identities within the I2RS 629 plane, but belongs to the protocol security requirements. 631 REQ 25: the I2RS Agent should have a "I2RS Agent overwrite Policy" 632 that indicates how identities can be prioritized. This 633 requirements is also described in section 7.6 of 634 [I-D.ietf-i2rs-architecture]. Similar requirements exist for 635 components within the I2RS plane, but belongs to the protocol 636 security requirements. 638 5.3. I2RS Client Access Control policies 640 The I2RS Client Access Control policies are responsible for 641 authenticating the application managing the privileges for the 642 applications, and enforcing access control to resources by the 643 applications. As a result, 645 REQ 26: I2RS Client should authenticate its applications. If the 646 I2RS Client acts as a broker and supports multiple 647 Applications, it should authenticate each of them. 648 Authentication of the application may used GSSAPI, Secure RPC 649 mechanisms. 651 REQ 27: I2RS Client should define Access Control policies associated 652 to each applications. An access to a routing resource by an 653 Application should not be forwarded by the I2RS Client based 654 on the I2RS Agent Access Control policies. The I2RS Client 655 should first check whether the Application has sufficient 656 privileges, and if so send an access request to the I2RS 657 Agent. When an I2RS Client has multiple identities that are 658 associated with different privileges. The I2RS Client Access 659 Control policies should specify the associated I2RS Client's 660 identities, especially, when the I2RS Agent Access Control 661 policies are changed for a given I2RS Client's identity. 663 In case, no authentication mechanisms have being provided between the 664 I2RS Client and the application, then I2RS Client may not act as 665 broker, and be instead dedicated to a single application. By doing 666 so, application authentication may rely on the I2RS authentication 667 mechanisms between the I2RS Client and the I2RS Agent. On the other 668 hand, although this is not recommended, the I2RS Access Control 669 policies is only enforced by the I2RS Agent. 671 5.4. Application and Access Control policies 673 Application does not enforce access control policies. Instead these 674 are enforced by the I2RS Clients and the I2RS Agents. This section 675 provides recommendations for Applications in order to ease I2RS 676 Access Control by the I2RS Client and the I2RS Agent. 678 As multiple ways may be used for an Application to communicate with 679 its associated I2RS Client, it is not expected that all Applications 680 use the same conventional identifier format across the I2RS plane. 681 However, if all Applications are running on a dedicated system 682 sharing an I2RS Client, it is expected each Application may uniquely 683 identified, for example using different system users. 685 REQ 28: Applications SHOULD be uniquely identified by their 686 associated I2RS Clients 688 The I2RS Client provides access to resource on its behalf and this 689 access should only be granted for trusted applications, or 690 Applications with an similar level of trust. On the other hand, this 691 does not prevent an I2RS Client to host a large number of 692 Applications. Similarly, an Application may also require to access 693 multiple I2RS Clients depending on the resource to be accessed. As 694 I2RS Client are restricted for a subset of Applications, 696 REQ 29: Each Application SHOULD be associated to a restricted number 697 of I2RS Client 699 REQ 30: Application SHOULD be provided means and methods to contact 700 their associated I2RS Client. If the I2RS Client belongs to 701 the Application (as a module or a library for example), or 702 when the Application runs into a dedicated system (like a 703 container) with a I2RS Client, it is obvious which I2RS 704 Client the Application is associated to. On the other hand, 705 Applications may also remotely access the I2RS Client. In 706 this case, the Application is expected to be provided some 707 means to be able to retrieve the necessary information to 708 contact its associated I2RS Client. The IP address may not 709 be appropriated in case renumbering occurs within the network 710 or in case the traffic from Applications should be shared 711 between multiple instances of a given I2RS Client. In this 712 case a FQDN may be preferred. 714 6. I2RS Application Isolation 716 A key aspect of the I2RS architecture is the network oriented 717 application. As these application are supposed to be independent, 718 controlled by independent and various tenants. In addition to 719 independent logic, these applications may be malicious. Then, these 720 applications introduce also programmability which results in fast 721 network settings. 723 The I2RS architecture should remain robust to these applications and 724 make sure an application does not impact the other applications. 725 This section discusses both security aspects related to 726 programmability as well as application isolation in the I2RS 727 architecture. 729 6.1. Robustness toward programmability 731 I2RS provides a programmatic interface in and out of the Internet 732 routing system. This feature, in addition to the global network view 733 provided by the centralized architecture comes with a few advantages 734 in term of security. 736 The use of automation reduces configuration errors. In addition, 737 this interface enables fast network reconfiguration. Agility 738 provides a key advantage in term of deployment as side effect 739 configuration may be easily addressed. Finally, it also provides 740 facilities to monitor and mitigate an attack when the network is 741 under attack. 743 On the other hand programmability also comes with a few drawbacks. 744 First, applications can belong to multiple tenants with different 745 objectives. This absence of coordination may result in unstable 746 routing configurations such as oscillations between network 747 configurations, and creation of loops for example. A typical example 748 would be an application monitoring a state and changing its state. 749 If another application performs the reverse operation, the routing 750 system may become unstable. Data and application isolation is 751 expected to prevent such situations to happen, however, to guarantee 752 the network stability, constant monitoring and error detection are 753 recommended to be activated. 755 REQ 31: The I2RS Agents should monitor constantly parts of the system 756 for which I2RS Clients or Applications have provided 757 requests. It should also be able to detect I2RS Clients or 758 Applications that lead the routing system in an unstable 759 state. Monitoring consists at least in logging events and 760 eventually provide notifications or alerts to the management 761 plane in case, something has been detected. The management 762 plane is in charge of collecting the logs, the notifications 763 and eventually to consider the appropriated actions. A 764 typical action may be the update of I2RS Access Control 765 policies for example or re-configuring routing elements. 767 6.2. Application Isolation 769 6.2.1. DoS 771 Requirements for robustness to Dos Attacks have been addressed in the 772 Communication channel section [I-D.ietf-i2rs-architecture]. 774 The I2RS interface is used by application to interact with the 775 routing states. As the I2RS Agent is shared between multiple 776 applications, one application can prevent an application by 777 performing DoS or DDoS attacks on the I2RS Agent or on the network. 778 DoS attack targeting the I2RS Agent would consist in providing 779 requests that keep the I2RS Agent busy for a long time. This may 780 involve heavy computation by the I2RS Agent for example to blocking 781 operations like disk access. In addition, DoS attacks targeting the 782 network may use specific commands like monitoring stream over the 783 network. Then, DoS attack may be also targeting the application 784 directly by performing reflection attacks. Such an attack could be 785 performed by indicating the target application as the target for some 786 information like the listing of the RIB. Reflection may be performed 787 at various levels and can be based on the use of UDP or at the 788 service level like redirection of information to a specific 789 repository. 791 REQ 32: In order to prevent DoS, it is recommended the I2RS Agent 792 controls the resources allocated to each I2RS Clients. I2RS 793 Client that acts as broker may not be protected as 794 efficiently against these attacks unless they perform 795 resource controls themselves of their hosted applications. 797 REQ 33: I2RS Agent does not make response redirection possible unless 798 the redirection is previously validated and agreed by the 799 destination. 801 REQ 34: avoid the use of underlying protocols that are not robust to 802 reflection attacks. 804 6.2.2. Application Control 806 Requirements for Application Control have been addressed in the I2RS 807 plane isolation as well as in the trusted Communication Channel 808 sections. 810 Applications use the I2RS interface in order to update the routing 811 system. These updates may be driven by behavior on the forwarding 812 plane or any external behaviors. In this case, correlating 813 observation to the I2RS traffic may enable to derive the application 814 logic. Once the application logic has been derived, a malicious 815 application may generate traffic or any event in the network in order 816 to activate the alternate application. 818 REQ 35: Application logic should remain opaque to external listeners. 819 Application logic may be partly hidden by encrypting the 820 communication between the I2RS Client and the I2RS Agent. 821 Additional ways to obfuscate the communications may involve 822 sending random messages of various sizes. Such strategies 823 have to be balanced with network load. Note that I2RS Client 824 broker are more likely to hide the application logic compared 825 to I2RS Client associated to a single application. 827 7. Security Considerations 829 The whole document is about security. 831 8. Privacy Considerations 833 9. IANA Considerations 835 10. Acknowledgments 837 A number of people provided a significant amount of helping comments 838 and reviews. Among them the authors would like to thank Russ White, 839 Russ Housley, Thomas Nadeau, Juergen Schoenwaelder, Jeffrey Haas, 840 Alia Atlas, Linda Dunbar 842 11. References 844 11.1. Normative References 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 848 RFC2119, March 1997, 849 . 851 11.2. Informative References 853 [I-D.ietf-i2rs-architecture] 854 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 855 Nadeau, "An Architecture for the Interface to the Routing 856 System", draft-ietf-i2rs-architecture-09 (work in 857 progress), March 2015. 859 [I-D.ietf-i2rs-protocol-security-requirements] 860 Hares, S., Migault, D., and J. Halpern, "I2RS Security 861 Related Requirements", draft-ietf-i2rs-protocol-security- 862 requirements-01 (work in progress), September 2015. 864 Authors' Addresses 866 Daniel Migault (editor) 867 Ericsson 868 8400 boulevard Decarie 869 Montreal, QC H4P 2N2 870 Canada 872 Phone: +1 514-452-2160 873 Email: daniel.migault@ericsson.com 875 Joel Halpern 876 Ericsson 878 Email: Joel.Halpern@ericsson.com 880 Susan Hares 881 Huawei 882 7453 Hickory Hill 883 Saline, MI 48176 884 USA 886 Email: shares@ndzh.com