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