idnits 2.17.1 draft-mglt-i2rs-security-requirements-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2015) is 3228 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 Summary: 1 error (**), 0 flaws (~~), 2 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: December 27, 2015 June 25, 2015 7 I2RS Security Requirements 8 draft-mglt-i2rs-security-requirements-00 10 Abstract 12 This document provides security requirements for the I2RS 13 architecture. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 27, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 51 3. I2RS Plane Isolation . . . . . . . . . . . . . . . . . . . . 3 52 3.1. I2RS plane and management plane . . . . . . . . . . . . . 5 53 3.2. I2RS plane and forwarding plane . . . . . . . . . . . . . 6 54 3.3. I2RS plane and Control plane . . . . . . . . . . . . . . 6 55 3.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 56 4. I2RS Authentication and Authorization Access Policy for 57 routing system resources . . . . . . . . . . . . . . . . . . 8 58 4.1. I2RS AAA architecture . . . . . . . . . . . . . . . . . . 8 59 4.2. I2RS Agent AAA . . . . . . . . . . . . . . . . . . . . . 10 60 4.3. I2RS Client AAA . . . . . . . . . . . . . . . . . . . . . 11 61 4.4. I2RS AAA Security Domain . . . . . . . . . . . . . . . . 12 62 4.4.1. Available I2RS Communication Channel . . . . . . . . 12 63 4.4.2. Trusted I2RS Communications Channel . . . . . . . . . 13 64 5. I2RS Application Isolation . . . . . . . . . . . . . . . . . 14 65 5.1. Robustness toward programmability . . . . . . . . . . . . 14 66 5.2. Application Isolation . . . . . . . . . . . . . . . . . . 15 67 5.2.1. DoS . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 5.2.2. Application Control . . . . . . . . . . . . . . . . . 16 69 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. Informative References . . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 This document addresses security considerations for the I2RS 78 architecture. It provides guidance and security principles to 79 guarantee the stability of the I2RS architecture. This documents 80 provides an analysis of the security issues of the I2RS architecture 81 beyond those already listed in [I-D.ietf-i2rs-architecture]. 83 Even though I2RS is mostly concerned by the interface between the 84 I2RS Client and the I2RS Agent, the security recommendations must 85 consider the entire I2RS architecture, specifying where security 86 functions may be hosted, and what should be met so to address any new 87 attack vectors exposed by deploying this architecture. In other 88 words, security has to be considered globally over the complete I2RS 89 architecture and not only on the interfaces. 91 I2RS architecture depicted in [I-D.ietf-i2rs-architecture] describes 92 the I2RS components and their interactions to provide a programmatic 93 interface for the routing system. I2RS components as well as their 94 interactions have not yet been considered in conventional routing 95 systems. As such it introduces a need to interface with the routing 96 system designated as I2RS plane in this document. 98 This document is built as follows. Section 3 describes how the I2RS 99 plane can be contained or isolated from existing management plane, 100 control plane and forwarding plane. The remaining sections of the 101 document focuses on the security within the I2RS plane. Section 4 102 analyzes how the I2RS Authentication Authorization and Access Control 103 (I2RS AAA) can be deployed throughout the I2RS plane in order to only 104 grant access to the routing system resources to authorized components 105 with the authorized privileges. This also includes providing a 106 robust communication system between the components. Then, Section 5 107 details how I2RS keeps applications isolated one from another and do 108 not affect the I2RS components. Applications may be independent, 109 with different scopes, owned by different tenants. In addition, they 110 modify the routing system that may be in an automatic way. 112 The reader is expected to be familiar with the 113 [I-D.ietf-i2rs-architecture]. 115 [QUESTION: Some suggested to use system instead of plane. Which is 116 the more appropriate terminology?] 118 2. Terminology and Acronyms 120 - I2RS plane : 122 - I2RS user : 124 - I2RS AAA : 126 - I2RS Client AAA : 128 - I2RS Agent AAA : 130 3. I2RS Plane Isolation 132 Isolating the I2RS plane from other network plane, such as the 133 control plane, is foundational to I2RS security. Clearly 134 differentiating I2RS components from the rest of the network protects 135 the I2RS components from vulnerabilities in other parts of the 136 network, and protect other systems vital to the health of the network 137 from vulnerabilities in the I2RS plane. Separating the I2RS plane 138 from other network control and forwarding planes is similar to the 139 best common practice of containerizing software into modules, and 140 defense in depth in the larger world of network security. 142 ****************** ***************** ***************** 143 * Application C * * Application D * * Application E * 144 ****************** ***************** ***************** 145 ^ ^ ^ 146 | | | 147 |--------------| | |--------------| 148 | | | 149 v v v 150 *************** 151 * Client P * 152 *************** 153 ^ ^ 154 | |-------------------------| 155 *********************** | *********************** | 156 * Application A * | * Application B * | 157 * * | * * | 158 * +----------------+ * | * +----------------+ * | 159 * | Client A | * | * | Client B | * | 160 * +----------------+ * | * +----------------+ * | 161 ******* ^ ************* | ***** ^ ****** ^ ****** | 162 | | | | | 163 | |-------------| | | |-----| 164 | | -----------------------| | | 165 | | | | | 166 ************ v * v * v ********* ***************** v * v ******** 167 * +---------------------+ * * +---------------------+ * 168 * | Agent 1 | * * | Agent 2 | * 169 * +---------------------+ * * +---------------------+ * 170 * ^ ^ ^ ^ * * ^ ^ ^ ^ * 171 * | | | | * * | | | | * 172 * v | | v * * v | | v * 173 * +---------+ | | +--------+ * * +---------+ | | +--------+ * 174 * | Routing | | | | Local | * * | Routing | | | | Local | * 175 * | and | | | | Config | * * | and | | | | Config | * 176 * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * 177 * +---------+ | | ^ * * +---------+ | | ^ * 178 * ^ | | | * * ^ | | | * 179 * | |----| | | * * | |----| | | * 180 * v | v v * * v | v v * 181 * +----------+ +------------+ * * +----------+ +------------+ * 182 * | Dynamic | | Static | * * | Dynamic | | Static | * 183 * | System | | System | * * | System | | System | * 184 * | State | | State | * * | State | | State | * 185 * +----------+ +------------+ * * +----------+ +------------+ * 186 * * * * 187 * Routing Element 1 * * Routing Element 2 * 188 ******************************** ******************************** 190 Figure 1: Architecture of I2RS clients and agents 192 Figure 1 (copied from [I-D.ietf-i2rs-architecture]) depicts the I2RS 193 components that constitute the I2RS plane. More specifically, the 194 network oriented applications, the I2RS Client, the I2RS Agent, and 195 to some extent the routing system resources accessed by the I2RS 196 Agent. The I2RS plane has its own goals and specificities that make 197 it a separate plane from the others. The I2RS plane purpose is to 198 provide a standard programmatic interface of the routing system 199 resources to network oriented applications. Control plane and 200 forwarding planes are related to routing protocols, and I2RS is based 201 on top of those. The management plane is usually vendor specific, 202 provides a broader control over the networking equipment such as 203 system service. Given its associated privileges it is expected to be 204 reserved to highly trusted users like network administrators. 206 [QUESTION: Should we remove the text above and the figure? ] 208 That said the I2RS plane cannot be considered as completely isolated 209 from other planes, and interactions should be identified and 210 controlled. Follows a brief description on how the I2RS plane 211 positions itself in regard to the other planes. The description is 212 indicative, and may not be exhaustive. 214 3.1. I2RS plane and management plane 216 The I2RS plane and the management plane both interact with several 217 common elements on forwarding and packet processing devices. 218 Figure 1 shows several of these interaction points, including the 219 local configuration, the static system state, routing, and 220 signalling. Because of this potential overlaps, a routing resource 221 may be accessed by different means (APIs, applications) and different 222 planes. To keep these overlaps under control. On the other hand, 223 one could either control the access to these resources with 224 northbound APIs for example, and if conflicting overlaps cannot be 225 avoided, then conflicts should be resolved in a deterministic way. 226 On the norhtbound side, there must be clear protections against the 227 I2RS system "infecting" the management system with bad information, 228 or the management system "infecting" the I2RS system with bad 229 information. The primary protection in this space is going to need 230 to be validation rules on the speed of information flow, value limits 231 on the data presented, and other protections of this type. On the 232 conflicting side, there should be clear rules about which plan's 233 commands win in the case of conflict in order to prevent attacks 234 where the two systems can be forced to deadlock. 236 3.2. I2RS plane and forwarding plane 238 Applications using I2RS are part of the I2RS plane but may also 239 interact with other components outside the I2RS plane. A common 240 example may be an application uses I2RS to configure the network 241 according to security or monitored events. As these events are 242 monitored on the forwarding plane and not the I2RS plane, the 243 application breaks plane isolation. 245 In addition, applications may communicate with multiple I2RS clients; 246 as such, any given application may have a broader view of the current 247 and potential states of the network and the I2RS plane itself. 248 Because of this, any individual application could be an effective 249 attack vector against the operation of the network, the I2RS plane, 250 or any plane with which the I2RS plane interacts. There is little 251 the I2RS plane can do to validate applications with which it 252 interacts, other than to provide some broad general validations 253 against common misconfigurations or errors. As with the separation 254 between the management plane and the I2RS plane, this should 255 minimally take the form of limits on information accepted, limits on 256 the rate at which information is accepted, and rudimentary checks 257 against intentionally formed routing loops or injecting information 258 that would cause the control plane to fail to converge. Other forms 259 of protection may be necessary. 261 3.3. I2RS plane and Control plane 263 The network control plane consists of the processes and protocols 264 that discover topology, advertise reachability, and determine the 265 shortest path between any location on the network and any 266 destination. It is not anticipated there will be any interaction 267 between the on-the-wire signalling used by the control plane. 268 However, in some situations the I2RS system could modify information 269 in the local databases of the control plane. This is not normally 270 recommended, as it can bypass the normal loop free, loop free 271 alternate, and convergence properties of the control plane. However, 272 if the I2RS system does directly inject information into these 273 tables, the I2RS system should ensure that loop free routing is 274 preserved, including loop free alternates, tunnelled interfaces, 275 virtual overlays, and other such constructions. Any information 276 injected into the control plane directly could cause the control 277 plane to fail to converge, resulting in a complete network outage. 279 3.4. Recommendations 281 To isolate I2RS transactions from other planes, it is recommended 282 that: 284 REQ 1: Application-to-routing system resources communications should 285 use an isolated network. An isolated network may be provided 286 with various level of isolation. The highest level of 287 isolation may be provided by using a physically isolated 288 network. Alternatives may also consider logical isolation; 289 for example by using vLAN. Eventually, in virtual 290 environment that shares a common infrastructure, encryption 291 may also be used as a way to enforce isolation. 293 REQ 2: The interface (like the IP address) used by the routing 294 element to receive I2RS transactions should be a dedicated 295 interface. 297 REQ 3: The I2RS Agent validates data to ensure injecting the 298 information will not create a deadlock with any other system, 299 nor will it create a routing loop, nor will it cause the 300 control plane to fail to converge. 302 When the I2RS Agent performs an action on a routing element, the 303 action is performed via process(es) associated to a system user . In 304 a typical UNIX system, the user is designated with a user id (uid) 305 and belong to groups designated by group ids (gid). These users are 306 dependent of the routing element's operation system and are 307 designated I2RS System Users. Some implementation may use a I2RS 308 System User for the I2RS Agent that proxies the different I2RS 309 Client, other implementations may use I2RS System User for each 310 different I2RS Clients. 312 REQ 4: I2RS Agent should have permissions separate from any other 313 entity (for example any internal system management processes 314 or CLI processes). 316 I2RS resource may be shared with the management plane and the control 317 plane. It is hardly possible to prevent interactions between the 318 planes. I2RS routing system resource management is limited to the 319 I2RS plane. As such, update of I2RS routing system outside of the 320 I2RS plane may be remain unnoticed unless explicitly notified to the 321 I2RS plane. Such notification is expected to trigger synchronization 322 of the I2RS resource state within each I2RS component. This 323 guarantees that I2RS resource are maintained in a coherent state 324 among the I2RS plane. In addition, depending on the I2RS resource 325 that is updated as well as the origin of the modification performed, 326 the I2RS Authentication Authorization and Access Control policies 327 (I2RS AAA) may be impacted. More especially, a I2RS Client is more 328 likely to update an I2RS resources that has been updated by itself, 329 then by the management plane for example. 331 REQ 5: I2RS plane should be informed when a routing system resource 332 is modified by a user outside the I2RS plane access. This is 333 designated as "I2RS resource modified out of I2RS plane". 334 This requirements is also described in section 7.6 of 335 [I-D.ietf-i2rs-architecture] for the I2RS Client. This 336 document extends the requirement to the I2RS plane, in case 337 future evolution of the I2RS plane. 339 REQ 6: I2RS plane should define an "I2RS plane overwrite policy". 340 Such policy defines how an I2RS is able to update and 341 overwrite a resource set by a user outside the I2RS plane. 342 Such hierarchy has been described in section 6.3 and 7.8 of 343 [I-D.ietf-i2rs-architecture] 345 REQ 7: I2RS AAA policies should be updated upon receipt of a "I2RS 346 resource modified out of I2RS plane". 348 4. I2RS Authentication and Authorization Access Policy for routing 349 system resources 351 This section details the I2RS Authentication and Authorization Access 352 Policy (I2RS AAA) associated to the routing system resources. These 353 policies only apply within the I2RS plane for I2RS users. 355 4.1. I2RS AAA architecture 357 Applications access to routing system resource via numerous 358 intermediaries nodes. The application communicates with an I2RS 359 Client. In some cases, the I2RS Client is only associated to a 360 single application, but the I2RS Client may also act as a broker. 361 The I2RS Client, then, communicates with the I2RS Agent that may 362 eventually access the resource. 364 The I2RS Client broker approach provides scalability to the I2RS 365 architecture as it avoids that each Application be registered to the 366 I2RS Agent. Similarly, the I2RS AAA should be able to scale numerous 367 applications. 369 REQ 8: I2RS AAA should be performed through the whole I2RS plane. 370 I2RS AAA should not be enforced by the I2RS Agent only within 371 the routing element. Instead, the I2RS Client should enforce 372 the I2RS Client AAA against applications and the I2RS Agent 373 should enforce the I2RS Agent AAA against the I2RS Client. 374 Note that I2RS Client AAA is not in the scope of the I2RS 375 architecture [I-D.ietf-i2rs-architecture], which exclusively 376 focuses on the I2RS Agent AAA. 378 This results in a layered and hierarchical I2RS AAA. An application 379 will be able to access a routing system resource only if both the 380 I2RS Client is granted access by the I2RS Agent AAA and the 381 application is granted access by the I2RS Client AAA. 383 REQ 9: In case I2RS Client AAA or I2RS Agent AAA does not grant the 384 access to a routing system resource, the Application should 385 be able to define the I2RS AAA that generated this reject, as 386 well as the reason. More specifically, the I2RS Agent may 387 reject the request based on the I2RS Client privileges, and 388 the I2RS Client should return a message to the application, 389 indicating the I2RS Client does not have enough privileges. 390 Similarly, if the I2RS Client does not grant the access to 391 the application, the I2RS Client should also inform the 392 application. Note that although multiple reject may occur, 393 only the first reject should be mandatory. 395 In order to limit the number of access request that result in an 396 error, each component should be able to retrieve the global I2RS AAA 397 policies that applies to it. This subset of rules is designated as 398 the "I2RS AAA component's subset policies". As they are subject to 399 changes, a dynamic synchronization mechanism should be provided. 401 REQ 10: The I2RS Client should be able to request for its I2RS AAA 402 Agent subset policies to the I2RS Agent AAA, so to limit 403 forwarding unnecessary queries to the I2RS Agent. 405 REQ 11: The I2RS Client should be able to be notified when its I2RS 406 AAA Agent subset policies have been updated. 408 Similarly, for the application 410 REQ 12: The Application may be able to request for its I2RS AAA 411 Client subset policies, so to limit forwarding unnecessary 412 queries to the I2RS Client. 414 REQ 13: The Application may be able to subscribe a service that 415 provides notification when its I2RS AAA Client subset 416 policies have been updated. 418 I2RS AAA should be appropriately be balanced between the I2RS Client 419 and the I2RS Agent which can be illustrated by two extreme cases: 421 - 1) I2RS Clients are dedicated to a single Application: In this 422 case, it is likely that I2RS AAA is enforced only by the I2RS 423 Agent AAA, as the I2RS Client is likely to accept all access 424 request of the application. However, it is recommended that 425 even in this case, I2RS Client AAA is not based on an "Allow 426 anything from application" policy, but instead the I2RS Client 427 specifies accesses that are enabled. In addition, the I2RS 428 Client may sync its associated I2RS Agent AAA with the I2RS 429 Agent to limit the number of refused access requests being sent 430 to the I2RS Agent. The I2RS Client is expected to balance pro 431 and cons between sync the I2RS Agent AAA and simply guessing 432 the access request to the I2RS Agent. 434 - 2) A single I2RS Client acts as a broker for all Applications: In 435 the case the I2RS Agent has a single I2RS Client. Such 436 architecture results in I2RS Client with high privileges, as it 437 sums the privileges of all applications. As end-to-end 438 authentication is not provided between the Application and the 439 I2RS Agent, if the I2RS Client becomes corrupted, it is 440 possible for the malicious application escalates its privileges 441 and make the I2RS Client perform some action on behalf of the 442 application with more privileges. This would not have been 443 possible with end-to-end authentication. In order to mitigate 444 such attack, the I2RS Client that acts as a broker is expected 445 to host application with an equivalent level of privileges. 447 REQ 14: The I2RS AAA should explicitly specify accesses that are 448 granted. More specifically, anything not explicitly granted 449 -- the default rule-- should be denied. 451 In order to keep the I2RS AAA architecture as distributed as 452 possible, 454 REQ 15: I2RS Client should be distributed and act as brokers for 455 applications that share roughly similar permissions. This 456 avoids ending with over privileges I2RS Client compared to 457 hosted applications and thus discourages applications to 458 perform privilege escalation within an I2RS Client. 460 REQ 16: I2RS Agent should be avoided being granted over privileged 461 regarding to their authorized I2RS Client. I2RS Agent should 462 be shared by I2RS Client with roughly similar permissions. 464 4.2. I2RS Agent AAA 466 The I2RS Agent AAA restricts the routing system resource access to 467 authorized components. Possible access policies may be none, read or 468 write. The component represents the one originating the access 469 request. The origin of the query is always an application. However, 470 the I2RS Agent may not be able to authenticate the application. 471 Instead, the I2RS Client may act as a broker. Similarly, multiple 472 I2RS Agents may be used, and different access privilege may be 473 provided depending on the I2RS Agent used. As a result, the origin 474 of the query may be represented in multiple ways, and each way be may 475 associated to a specific AAA. 477 REQ 17: I2RS Agent AAA may use various ways to represent the origin 478 of the access request of a routing system resource. However, 479 representation of the origin should be based on information 480 that can be authenticated. The I2RS Client, optionally the 481 I2RS Agent in case of multiple I2RS Agents go into this 482 category. On the hand, unless some additional means for 483 authentication have been provided, the secondary identity 484 used to tag the application as defined in 485 [I-D.ietf-i2rs-architecture] should not be considered. 487 The I2RS Agent AAA may evolve over time as resource may also be 488 updated outside the I2RS plane. Similarly, a given resource may be 489 accessed by multiple I2RS users within the I2RS plane. Although this 490 is considered as an error, depending on the I2RS Client that 491 performed the update, the I2RS may accept or refuse to overwrite the 492 routing system resource. 494 REQ 18: Each routing system resource updated by a I2RS Agent should 495 keep track of the component that performed the last update. 497 REQ 19: the I2RS Agent should have a "I2RS Agent overwrite Policy" 498 that indicates how the originating components can be 499 prioritized. This requirements is also described in section 500 7.6 of [I-D.ietf-i2rs-architecture] 502 4.3. I2RS Client AAA 504 The I2RS Client AAA works similarly to the I2RS Agent AAA. The main 505 difference is that components are applications. As a result, 507 REQ 20: The I2RS Client should be able to authenticate its 508 application. 510 In case, no authentication mechanisms have being provided between the 511 I2RS Client and the application, then I2RS Client may not act as 512 broker, and be instead dedicated to a single application. In this 513 case, although this is not recommended, the I2RS AAA is only enforced 514 by the I2RS Agent AAA. The I2RS Client may only sync and cache the 515 I2RS Agent AAA associated to its application, in order to limit the 516 access requests to the I2RS Agent. The I2RS Client is expected to 517 balance pro and cons between synchronization of the I2RS Agent AAA, 518 or simply sending the request to the I2RS Agent. 520 4.4. I2RS AAA Security Domain 522 I2RS Client AAA and I2RS Agent AAA are respectively enforced within 523 the I2RS Client and the I2RS Agent. I2RS AAA enforcement should not 524 remain local, and should be also enforced through the network 525 communications. More specifically: 527 - 1) Communication should remain available at any time, and it 528 should be robust to potential attacks, or misbehaviors. 530 - 2) Components' operation requests should be guaranteed to have 531 have been properly authorized by the I2RS AAA policies. 533 4.4.1. Available I2RS Communication Channel 535 Communication is considered available if and only if all components 536 are available as well as the communication channel itself. In order 537 to maintain it available here are the considered aspects: 539 - 1) Make communication robust to DoS by design 541 - 2) Provide active ways to mitigate an DoS attack 543 - 3) Limit damages when a DoS event occurs 545 Protocols used to communicate between components should not provide 546 means that would result in a component's resource exhaustion. 548 At the transport layer, when possible, protocols that do not 549 implement any mechanisms to check the origin reachability should be 550 avoided (like UDP). Instead, if possible, protocols like TCP or SCTP 551 with origin reachability verification should be preferred. Anti DoS 552 mechanisms should also be considered at other layers including the 553 application layer. More specifically, it should be avoided to 554 perform actions that generate heavy computation on a component. At 555 least the component should be able to post-pone and re-schedule the 556 action. Similarly, DoS by amplification should be avoided, and 557 special attention should be given to small access request that 558 generate massive network traffic without any control. An example of 559 asymmetric dialogue could be the subscription of information streams 560 like prefix announcement from OSPF. In addition, some service may 561 also provide the ability to redirect these streams to a third party. 562 In the case of information stream, registration by an I2RS Client may 563 provide the possibility to redirect the stream on a shared directory, 564 so it can be accessed by multiple I2RS Clients, while not flooding 565 the network. In this case, special attention should be provided so 566 the shared directory can agree based on its available resources the 567 service subscription by the I2RS Client. Otherwise, the shared 568 directory may become overloaded. 570 REQ 21: Communication protocols should be robust against DoS attacks. 571 DoS should be considered at multiple layers, in the design of 572 the communication protocol. Engaged resources should be 573 agreed by the component using these resources. 575 Components should be able to control the computing resource they 576 allocate to each other components, or each actions. Based on 577 available resource, requests should be differed, or returned an 578 error. 580 REQ 22: I2RS Client and I2RS Agent should implement mechanisms to 581 mitigate DoS attacks. 583 One alternative way to mitigate a DoS attack or event is to limit the 584 damages when resource exhaustion happens. This can be done by 585 appropriately group or ungroup applications. For example, critical 586 applications may not share their I2RS Client with multiple other 587 Applications. This limits the probability of I2RS Client failure for 588 the critical application. Similarly, I2RS Agent may also be 589 selective regarding their I2RS Client as well as to the scope of 590 their routing system resources. In fact some, some I2RS Client may 591 be less trusted than others and some routing system resource access 592 may be more sensitive than the others. Note that trust of an I2RS 593 Client is orthogonal to authentication and rather involves, for 594 example, the quality of the hosted Applications. 596 REQ 23: Application, I2RS Client and I2RS Agent should be distributed 597 among the I2RS Plane to minimize the impact of a failure. 599 Even though this should be considered, it does not address the high 600 availability issue. In order to reduce the impact of a single I2RS 601 Client failure, remote applications may load balance their access 602 request against multiple I2RS Clients. Non remote I2RS Client or 603 I2RS Agent are bound the system hosting the application or to the 604 routing element. This makes high availability be provided by the 605 system, and thus implementation dependent. 607 REQ 24: I2RS Client should provide resilient and high availability 608 for the hosted applications. 610 4.4.2. Trusted I2RS Communications Channel 612 This section addresses the authorization and trust of the 613 Communication Channel. The main purpose of this section is to 614 provide guidance to avoid identity usurpation. More specifically, 615 resource access request should only be issued and responded by the 616 expected components and concern the expected resource only. 618 REQ 25: Communications between the different components should be 619 mutually authenticated. 621 REQ 26: Communications between components should be protected against 622 replay attacks. 624 Within the I2RS AAA Security Domain, information exchanged between 625 the I2RS Client and the I2RS Agent or the application and the I2RS 626 Client may leak information about the application goal, as well as 627 its internal logic. As a result, it is recommended to isolate 628 components communications. 630 REQ 27: Communications between components should avoid leaking 631 information about internal logic, and thus, it is recommended 632 to encrypt them. 634 When an incident occurs, one should be able to understand the reasons 635 in order to prevent it to happen again. 637 REQ 28: Log and monitoring facilities should be provided and made 638 available for forensic investigation. 640 5. I2RS Application Isolation 642 A key aspect of the I2RS architecture is the network oriented 643 application. As these application are supposed to be independent, 644 controlled by independent and various tenants. In addition to 645 independent logic, these applications may be malicious. Then, these 646 applications introduce also programmability which results in fast 647 network settings. 649 The I2RS architecture should remain robust to these applications and 650 make sure an application does not impact the other applications. 651 This section discusses both security aspects related to 652 programmability as well as application isolation in the I2RS 653 architecture. 655 5.1. Robustness toward programmability 657 I2RS provides a programmatic interface in and out of the Internet 658 routing system. This feature, in addition to the global network view 659 provided by the centralized architecture comes with a few advantages 660 in term of security. 662 The use of automation reduces configuration errors. In addition, 663 this interface enables fast network reconfiguration. Agility 664 provides a key advantage in term of deployment as side effect 665 configuration may be easily addressed. Finally, it also provides 666 facilities to monitor and mitigate an attack when the network is 667 under attack. 669 On the other hand programmability also comes with a few drawbacks. 670 First, applications can belong to multiple tenants with different 671 objectives. This absence of coordination may result in unstable 672 routing configurations such as oscillations between network 673 configurations, and creation of loops for example. A typical example 674 would be an application monitoring a state and changing its state. 675 If another application performs the reverse operation, the routing 676 system may become unstable. Data and application isolation is 677 expected to prevent such situations to happen, however, to guarantee 678 the network stability, constant monitoring and error detection are 679 recommended to be activated. 681 REQ 29: I2RS should monitor constantly parts of the system for which 682 clients have requested notification. It should also be able 683 to detect components that lead the routing system in an 684 unstable state. 686 5.2. Application Isolation 688 5.2.1. DoS 690 Requirements for robustness to Dos Attacks have been addressed in the 691 Communication channel section [I-D.ietf-i2rs-architecture]. 693 The I2RS interface is used by application to interact with the 694 routing states. As the I2RS Agent is shared between multiple 695 applications, one application can prevent an application by 696 performing DoS or DDoS attacks on the I2RS Agent or on the network. 697 DoS attack targeting the I2RS Agent would consist in providing 698 requests that keep the I2RS Agent busy for a long time. This may 699 involve heavy computation by the I2RS Agent for example to blocking 700 operations like disk access. In addition, DoS attacks targeting the 701 network may use specific commands like monitoring stream over the 702 network. Then, DoS attack may be also targeting the application 703 directly by performing reflection attacks. Such an attack could be 704 performed by indicating the target application as the target for some 705 information like the listing of the RIB. Reflection may be performed 706 at various levels and can be based on the use of UDP or at the 707 service level like redirection of information to a specific 708 repository. 710 REQ 30: In order to prevent DoS, it is recommended the I2RS Agent 711 controls the resources allocated to each I2RS Clients. I2RS 712 Client that acts as broker may not be protected as 713 efficiently against these attacks unless they perform 714 resource controls themselves of their hosted applications. 716 REQ 31: I2RS Agent does not make response redirection possible unless 717 the redirection is previously validated and agreed by the 718 destination. 720 REQ 32: avoid the use of underlying protocols that are not robust to 721 reflection attacks. 723 5.2.2. Application Control 725 Requirements for Application Control have been addressed in the I2RS 726 plane isolation as well as in the trusted Communication Channel 727 sections. 729 Applications use the I2RS interface in order to update the routing 730 system. These updates may be driven by behavior on the forwarding 731 plane or any external behaviors. In this case, correlating 732 observation to the I2RS traffic may enable to derive the application 733 logic. Once the application logic has been derived, a malicious 734 application may generate traffic or any event in the network in order 735 to activate the alternate application. 737 REQ 33: Application logic should remain opaque to external listeners. 738 Application logic may be partly hidden by encrypting the 739 communication between the I2RS Client and the I2RS Agent. 740 Additional ways to obfuscate the communications may involve 741 sending random messages of various sizes. Such strategies 742 have to be balanced with network load. Note that I2RS Client 743 broker are more likely to hide the application logic compared 744 to I2RS Client associated to a single application. 746 6. Privacy Considerations 748 7. IANA Considerations 750 8. Acknowledgments 752 We would like to thanks Russ White for its review and editorial 753 contributions. 755 9. Informative References 757 [I-D.ietf-i2rs-architecture] 758 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 759 Nadeau, "An Architecture for the Interface to the Routing 760 System", draft-ietf-i2rs-architecture-09 (work in 761 progress), March 2015. 763 Authors' Addresses 765 Daniel Migault (editor) 766 Ericsson 767 8400 boulevard Decarie 768 Montreal, QC H4P 2N2 769 Canada 771 Phone: +1 514-452-2160 772 Email: daniel.migault@ericsson.com 774 Joel Halpern 775 Ericsson 777 Email: Joel.Halpern@ericsson.com