idnits 2.17.1 draft-marin-sdnrg-sdn-aaa-mng-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 11, 2015) is 3089 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-merged-i2nsf-framework-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SDNRG R. Marin-Lopez 3 Internet-Draft G. Lopez-Millan 4 Intended status: Experimental University of Murcia 5 Expires: May 14, 2016 November 11, 2015 7 Software-Defined Networking (SDN)-based AAA Infrastructures Management 8 draft-marin-sdnrg-sdn-aaa-mng-00 10 Abstract 12 This document describes the management of Authentication, 13 Authorization and Accounting (AAA) infraesctrutures by means of a 14 Software-Defined Network (SDN) controller and raises the requirements 15 to support this service. It considers the management of AAA routing 16 and the establishment of security associations between AAA entities. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 14, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. AAA flow based routing . . . . . . . . . . . . . . . . . . . 6 57 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 6.1. AAA routing and security association establishment . . . 10 59 6.2. AAA agents under different SDN controllers . . . . . . . 12 60 7. Relationship with I2NSF . . . . . . . . . . . . . . . . . . . 13 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 65 10.2. Informative References . . . . . . . . . . . . . . . . . 15 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 68 1. Introduction 70 Software-Defined Networking (SDN) is an architecture that enables 71 users to directly program, orchestrate, control and manage network 72 resources through software. SDN paradigm relocates the control of 73 network resources to a dedicated network element, namely SDN 74 controller. The SDN controller manages and configures the 75 distributed network resources and provides an abstracted view of the 76 network resources to the SDN applications. The SDN application can 77 customize and automate the operations (including management) of the 78 abstracted network resources in a programmable manner via this 79 interface [RFC7149][ITU-T.Y.3300] 80 [ONF-SDN-Architecture][ONF-OpenFlow]. 82 Authentication, Authorization and Accounting (AAA) [RFC2903][RFC2904] 83 infrastructures manage three basic security services to control the 84 access to network resources: Authentication, in order to determine 85 who the end user is; Authorization, in order to determine under what 86 conditions an end user is granted access to the network resource; and 87 Accounting, in order to account the resource usage of the end user. 89 Following the terminology in [RFC6733], an AAA infrastructure is 90 formed by AAA nodes. An AAA protocol is used to exchange AAA 91 information between them. RADIUS [RFC2865], [RFC2866] and Diameter 92 [RFC6733]. These AAA nodes can be classified as follows: 94 o AAA client. It is a AAA node that implement the client part of a 95 AAA protocol. 97 o AAA server. AAA node that handles authentication, authorization, 98 and accounting requests for a particular realm. 100 o AAA agent. AAA node that implements one of the following 101 functionalities: 103 o 105 * Relay Agents. They are agents that accept requests and route 106 messages (making use of a routing table) to other nodes based 107 on information found in the DIAMETER messages. 109 * Proxy Agents. Similarly to relays, proxy agents also route 110 messages using a routing table. However, they differ since 111 they modify messages to implement policy enforcement. 113 * Redirect Agents. Redirect agents do not relay Diameter 114 messages, they return an answer with the information required 115 by the agents to communicate directly, so they do not modify 116 messages. They are useful in scenarios where routing 117 configuration needs to be centralized. 119 * Translation Agents. A translation agent is a device that 120 provides translation between two protocols (e.g., 121 RADIUS<->Diameter, TACACS+<->Diameter). 123 As depicted in Figure 1, the AAA framework [RFC2903] defines a model 124 consisting of the User desiring gain access to a specific network 125 service; the AAA server in the User Home Organization (UHO) which has 126 registered the User's identity and credentials; and the AAA server 127 located in the Service Provider (SP) operating and controlling the 128 access to the network service through a Service Equipment. In non- 129 federated environments, User Home Organization and Service Provider 130 are the same organization. In federated environments, they are two 131 separate organizations. 133 Between the AAA client and the AAA server in the UHO, the AAA 134 infrastructure can deploy other intermediate AAA agents to forward 135 the information between both entities. RADIUS defines, apart from 136 the RADIUS client and RADIUS server, the role of proxy RADIUS or 137 forwarding RADIUS. Proxy RADIUS receives authentication requests 138 from a RADIUS client, forwards the request to a remote RADIUS server, 139 receives authentication responses from the remote server and forwards 140 the response to the client. In Diameter, apart from the AAA client 141 and the AAA server, it defines a set of these Diameter agents that 142 corresponds with the agents described above. 144 It is important to note that the AAA node can act as AAA server in a 145 realm but also can act as, for example, Relay/Proxy agent for those 146 types of AAA requests that cannot be processed and need to be 147 forwarded to the next AAA node. It is also important to note that 148 some kind of trust relationship is required to be established between 149 these AAA nodes, in order to protect the AAA traffic 151 Typically, Proxy RADIUS and Diameter agents (from now on AAA agents) 152 hold and manage AAA routing information. Moreover AAA 153 infrastructures are manually configured, specially the AAA routing 154 information. For example, RADIUS implementations typically require 155 the name or address of servers or clients be manually configured, 156 besides passwords or cryptographic material to establish a security 157 associations between AAA entities. It makes difficult their 158 management and generates a lack of flexibility, specially if the 159 number of entities is high and the AAA infrastructure is complex. 160 With the grow of SDN-based scenarios where network resources are 161 deployed in an autonomous manner, a mechanism to manage AAA 162 infrastructures according to the SDN paradigm becomes more relevant. 163 Thus, the SDN-based service described in this document deals with AAA 164 infrastructures in such as an autonomous manner. 166 +------+ +-------------------------+ 167 | | | User Home Organization | 168 | | | +-------------------+ | 169 | | | | AAA Server | | 170 | | | | | | 171 | | | +-------------------+ | 172 | | | | 173 | | +-------------------------+ 174 | | 175 | | 176 | | 177 | User | +-------------------------+ 178 | | | Service Provider | 179 | | | +-------------------+ | 180 | | | | AAA Server | | 181 | | | | | | 182 | | | +-------------------+ | 183 | | | | 184 | | | +-------------------+ | 185 | | | | AAA Client | | 186 | | | |-------------------| | 187 | | | | Service | | 188 | | | | Equipment | | 189 | | | +-------------------+ | 190 | | | | 191 +------+ +-------------------------+ 193 Figure 1: AAA framework 195 2. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC 2119 [RFC2119]. 200 When these words appear in lower case, they have their natural 201 language meaning. 203 3. Terminology 205 This document uses the terminology described in [RFC7149], [RFC6733], 206 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 207 [ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms 208 are defined below: 210 o Software-Defined Networking: A set of techniques enabling to 211 directly program, orchestrate, control, and manage network 212 resources, which facilitates the design, delivery and operation of 213 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 215 4. Objectives 217 o Flow-based AAA traffic routing: SDN-based management allows to 218 route AAA traffic (flow) between different AAA agents so that the 219 authentication, authorization and accounting tasks can be 220 preformed. Thus, it can adapt quickly the routing information 221 when a AAA route is not available to redirect the AAA traffic to 222 other nodes. 224 o Bootstrapping security associations: SDN-based flow protection 225 allows the centralized bootstrapping of credentials to protect the 226 AAA traffic between two adjacent AAA nodes (hop-by-hop) or between 227 two separate AAA nodes without intermediate AAA nodes in between 228 (end-to-end). 230 5. AAA flow based routing 232 As mentioned, the AAA infrastructure is formed by a set of AAA nodes. 233 These nodes interconnect each other using the AAA protocol, such as 234 RADIUS or Diameter. When the User desires to access a service which 235 requires authentication and authorization, she typically sends her 236 identity to the Service Equipment. The Service Equipment (e.g. an 237 WiFi access point) deploys the AAA client to interact with the AAA 238 infrastructure. The User's identity contains the realm where she 239 belongs to. For example, an identity can be "alice@um.es". The 240 identifier is "alice" and the realm is "um.es". Based on this realm 241 (realm-based routing), the AAA agents, for example, AAA relay or 242 proxy, route the AAA information to the specific AAA server in the 243 User Home Organization that has a register of "alice@um.es". This 244 AAA server will be in charge of authenticate and authorize the Users 245 in the realm. In order to achieve a correct routing of AAA 246 information each AAA agent maintains a AAA routing table and another 247 table with the adjacent AAA servers, which are considered as next 248 "AAA hop". 250 As an example of AAA routing table, Diameter defines a format where 251 each table entry contains the following fields: 253 Realm Name 255 This is the field that MUST be used as a primary key in the 256 routing table lookups. Note that some implementations perform 257 their lookups based on longest-match-from-the-right on the realm 258 rather than requiring an exact match. 260 Application Identifier 261 A Diameter Application (i.e. NAS-REQ, EAP, etc.) is identified by 262 an Application Id. The Diameter message can have a different 263 destination (route entry) based on the Application Id in the 264 message header. This field MUST be used as a secondary key field 265 in routing table lookups. 267 Local Action 269 The Local Action field is used to identify how a message should be 270 treated. The following actions are supported: 272 1. LOCAL - Diameter messages that can be satisfied locally, and 273 do not need to be routed to another Diameter entity. 275 2. RELAY - All Diameter messages that fall within this category 276 MUST be routed to a next hop Diameter entity that is indicated 277 by the identifier described below. Routing is done without 278 modifying any non-routing AVPs. 280 3. PROXY - All Diameter messages that fall within this category 281 MUST be routed to a next Diameter entity that is indicated by 282 the identifier described below. The local server MAY apply 283 its local policies to the message by including new AVPs to the 284 message prior to routing. 286 4. REDIRECT - Diameter messages that fall within this category 287 MUST have the identity of the home Diameter server(s) 288 appended, and returned to the sender of the message. 290 Additionally, Diameter specification defines the Peer Table, which is 291 used for message forwarding, and referenced by the Routing Table. A 292 Peer Table entry contains the following fields: 294 Host identity 296 The name of the peer (i.e. Diameter URI of the peer). 298 StatusT 300 This is the state of the peer entry. 302 Static or Dynamic 303 Specifies whether a peer entry was statically configured or 304 dynamically discovered. 306 Expiration time 308 Specifies the time at which dynamically discovered peer table 309 entries are to be either refreshed, or expired. 311 TLS/TCP and DTLS/SCTP Enabled 313 Specifies whether TLS/TCP or DTLS/SCTP is to be used when 314 communicating with the peer. 316 Thus, the general idea presented in the document assumes that a SDN 317 controller can manage and fill this routing information in the 318 different AAA entities under its control. In particular, a set of 319 tasks (not exhaustive) that the SDN controller can perform over the 320 AAA infrastructure is the following: 322 o The SDN controller can provide this AAA routing information to the 323 AAA agents so having a dynamic AAA routing. In general, the SDN 324 controller can fill the AAA routing and peer table of any AAA 325 agents and servers, but also the AAA client to indicate the next 326 AAA hop. This brings all the existing advantages right now for 327 general IP routing with SDN paradigm to AAA routing. That is, it 328 provides flexibility, scalability, availability, and security. 330 o AAA entity and its adjacent ones typically keep a security 331 association (hop-by-hop security). For example, RADIUS has a 332 simple and weak model based on shared secrets. Extensions such as 333 RADSec [RFC6614] has been proposed for running TLS between two 334 RADIUS servers. Diameter mandates the usage of TLS and optionally 335 IPsec. To avoid manual configuration of these security 336 associations, the SDN controller can dynamically provide this 337 cryptographic information to both interacting AAA servers. 339 o When forming AAA federations, security is usually provided hop-by- 340 hop, which means that, between each pair of neighboring AAA 341 entities, the AAA protocol provides message protection. 342 Sometimes, for example in RADIUS, this protection is based on 343 message authentication, but not message encryption. So these 344 intermediate AAA entities can see all the information in clear. 345 To avoid this, end-to-end security MAY be required. With a SDN- 346 approach we foresee achieving the following. When the SP's AAA 347 server observes that the User belongs to a different realm that it 348 does not know (managed by the UHO's AAA server), it can inform the 349 SDN controller. The SDN controller can then enforce cryptographic 350 material to both the UHO's AAA and SP's AAA server to establish a 351 direct security association between them. Thus, in a simple 352 architecture, the SDN controller would act as the manager of the 353 federation. Nevertheless, more complex cases can be envisages 354 such as each AAA server is managed by a different SDN-controller. 356 o The SDN controller can modulate the behaviour between a relay, 357 proxy and translation agent. For example, the SDN controller can 358 enforce routing tables but not sending any particular policy to 359 the agent, so that it behaves as a relay agent. However, if a 360 proxy is required the particular behaviour is enforced by the 361 controller based on internal policies. For certain routes the AAA 362 agent can act as a Redirect Agent. In fact, in relationship with 363 Network Function Virtualization (NVF) and Network Security 364 Function (NSF), we envisage that the SDN controller can order the 365 instantiation of a particular AAA agent (VNF) when it is required 366 and "places it" in the path of the chain of AAA agents where the 367 AAA requests and responses have to travel. For example, if the 368 SDN controller realizes the request is a RADIUS message and it has 369 to traverse a Diameter-based AAA infrastructure, it can 370 instantiate a Translation Agent, so that the requests and 371 responses are automatically translated from and to the different 372 AAA protocols. Once it is instantiated, the SDN controller can 373 install a routing entry in the RADIUS proxy so that the AAA 374 request goes through the Translation Agent. 376 o The SDN controller MAY also manage the User's credentials. In 377 other words, the SDN controller can store all the User information 378 provided by the administrator. When the AAA server is going to 379 act as UHO's AAA server for a set of services and users, it will 380 require this information to complete the authentication and 381 authorization steps. The SDN can proactively push this 382 information to the AAA server. Or, reactively, when the AAA 383 server does not know how to authenticate and authorize a request 384 it can ask for the advice of the SDN controller and the controller 385 can enforce the behaviour and the user's 'information. 387 o The SDN controller can also select the AAA server in charge of 388 (exclusively) Accounting. This accounting information can be also 389 route to the specific AAA server. 391 NOTE: In general, the SDN controller MAY make use of NETCONF and YANG 392 model for AAA entities to configure them. 394 6. Scenarios 396 This section explains two main use cases as examples for the SDN- 397 based AAA management: first, when a single SDN controller is used; 398 second, when multiple SDN controllers take place in the 399 infrastructure. 401 6.1. AAA routing and security association establishment 403 As depicted in Figure 2, the SDN controller represents the "AAA 404 control plane" where the decisions of AAA routing are taken based on 405 AAA policies provided by the administrator (1). Once, the SDN 406 controller interprets these policies (2), it sends the AAA routing 407 information ("AAA data plane") to the AAA entities (e.g. Relay, 408 Proxies or Redirect) to carry out the forwarding of the AAA request. 409 This information is used to fill the AAA routing table and peer table 410 of AAA agent 1 and AAA agent 2 (3). Associated to this routing 411 information any security credential is also provided (4) by the SDN 412 controller to establish hop-by-hop security (5). In general, the SDN 413 controller can fill all the required information to the different AAA 414 agents that form the AAA routing path to the destination. 416 +----------------------------------------+ 417 | SDN Controller | 418 | | 419 (1)| +--------------+ (2)+--------------+ | 420 AAA ------>| AAA Routing/ |--->| South. Prot. | | 421 Policies | | Key Distr. | | | | 422 | +--------------+ +--------------+ | 423 | AAA Control Plane | | | 424 | | | | 425 +--------------------------|-----|-------+ 426 | | 427 | (3) | 428 |--------------------------+ (4) +---| 429 AAA V AAA Data Plane V AAA 430 request +-------------+ +-----------+request 431 ------->| AAA |===============>| AAA |------> 432 | agent 1 | hop-by-hop | agent 2 | 433 | | security | | 434 +-------------+ (5) +-----------+ 436 Figure 2: Example of AAA agent-to-agent routing. 438 Figure 3 represents the case where end-to-end security (5) is 439 established. In this case, the SDN controller enables credential and 440 AAA routing information so that the AAA request goes directly between 441 the SP's AAA server and the UHO's AAA server without passing through 442 any intermediate AAA entity. 444 +----------------------------------------+ 445 | SDN Controller | 446 | | 447 (1)| +--------------+ (2)+--------------+ | 448 AAA --------| AAA Routing/ |--->| South. Prot. | | 449 Policies. | Key Distr. | | | | 450 | +--------------+ +--------------+ | 451 | AAA Control Plane | | | 452 | | | | 453 +--------------------------|----------|--+ 454 | | 455 (3) (4) | | (3)(4) 456 |--------------------+ + -----| 457 V AAA Data Plane V 458 AAA request +----------------+ +-----------+ 459 ------>| SP's AAA | | UHO's AAA | 460 | server |=================>| Server | 461 +----------------+ (5) +-----------+ 462 end-to-end 463 security 465 Figure 3: Example of AAA server-to-server routing (end-to-end 466 security). 468 Finally, Figure 4 describes the case of pushing AAA routing 469 information only when really required (reactive). Let us assume that 470 the administrator has provided general AAA policies (1). When a 471 initial AAA request arrives the first time to the AAA agent 1, it 472 notifies about the request to the SDN Controller (2). The SDN 473 Controller looks for AAA routing information associated with the AAA 474 policies and the information in the AAA request. It decides that the 475 AAA request has to be forwarded to AAA agent 2 (3). The SDN 476 controller installs then AAA routing information in the routing table 477 and peer table in AAA agent 1 (4). Moreover, it fills the routing 478 and peer tables within AAA agent 2 (5). It also sends credentials to 479 both agents to establish a security association (6) in order to 480 provide hop-by-hop or end-to-end security (7). 482 +----------------------------------------+ 483 | (1) SDN Controller | 484 AAA ----------------+ | 485 Policies | V | 486 | +----------+ (3) +-------------+ | 487 ---------->| AAA |<--->|South. Prot. | | 488 | | | Policies | | | | 489 | | +----------+ +-------------+ | 490 | | | | | 491 | | | | | 492 (2) | +------------------------| --- | --------+ 493 | | | 494 | (4)(6)| |(5)(6) 495 | |------------------------+ +--| 496 AAA | V V AAA 497 request +-------------+ +-----------+request 498 ------->| AAA |================= >| AAA |------> 499 | agent 1 | hop-to-hop/ | agent 2 | 500 | | security | | 501 +-------------+ (7) +-----------+ 503 Figure 4: Example of SDN controller pushing AAA routing information 504 (reactive) 506 NOTE: It is worth noting that for the same AAA request some 507 information can be enforced proactively and other can be retrieved 508 reactively during the travel of the AAA request. 510 6.2. AAA agents under different SDN controllers 512 Another case (Figure 5) is when, for example, two organizations, ISP 513 A and ISP B have their own SDN controller (A and B respectively), 514 each one controlling a different set of AAA agents. During the 515 travel of a AAA request, it may need to pass from the AAA agent 1 516 controlled by SDN Controller A to another AAA agent 2 which is under 517 the control of a different SDN controller B. 519 In this case, both SDN controllers may coordinate each other and 520 determine whether the AAA request is allowed to traverse through both 521 realms or not (1). If they agree the conditions (2), the AAA 522 policies that represents this agreement are enforced by the SDN 523 controllers as AAA routing information and credentials into the AAA 524 agents (3). Then the AAA request can move forward (4). 526 +-------------+ +-------------+ 527 AAA | SDN |<=================>| SDN | 528 Policy. -->| Controller A| (2) |Controller B | 529 (1) | | | | 530 +-------------+ +-------------+ 531 | | 532 | (3) (3) | 533 AAA V V AAA 534 request +-------------+ +-------------+ request 535 ------>| AAA agent 1 |<=============>| AAA agent 2 |------> 536 +-------------+ (4) +-------------+ 538 Figure 5: Gateway-to-gateway multi controller flow in case 1 540 7. Relationship with I2NSF 542 According to [I-D.merged-i2nsf-framework-04] I2NSF needs to provide 543 identity information, along with additional data that Authentication, 544 Authorization, and Accounting (AAA) frameworks can use. This enables 545 those frameworks to perform AAA functions on the I2NSF traffic. In 546 this sense, we assume that each AAA entity is, in the end, a NSF that 547 may need to be configured with AAA-related information and where the 548 administrator can obtain some valuable information such as, number 549 authentications executed, number of active users accessing the 550 service, accounting records, etc. 552 We envisage that SDN controller MAY also instantiate a vNSF acting as 553 one of the AAA agents (relay, proxy, redirect, translation, server, 554 etc...) when necessary. Even more, an administrator MAY instantiate 555 a AAA server that works as UHO's AAA server. For that, apart from 556 create the vNSF, it needs to register the users that the AAA server 557 needs. 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Security Application | App. 561 | (e.g.Identity and AAA Management) | Layer 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Application Support | SDN/ 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security 567 |AAA Control Plane(routing,key distribution.| Controller 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AAA server 571 | AAA Data Plane |(NSF) 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 ----> | Policy and Event Repository (PER) | ---> 574 +-------------------------------------------+ 575 | AAA routing table (AAA-RT) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 6: High-level Architecture for SDN-based AAA management 580 Figure 6 describes the mapping with our use cases. In the right side 581 of the figure each entity follows the same terminology than 582 [I-D.merged-i2nsf-framework-04] 584 8. Security Considerations 586 TBD. 588 9. Acknowledgements 590 TBD. 592 10. References 594 10.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 602 "Remote Authentication Dial In User Service (RADIUS)", 603 RFC 2865, DOI 10.17487/RFC2865, June 2000, 604 . 606 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 607 DOI 10.17487/RFC2866, June 2000, 608 . 610 [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and 611 D. Spence, "Generic AAA Architecture", RFC 2903, 612 DOI 10.17487/RFC2903, August 2000, 613 . 615 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 616 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 617 D. Spence, "AAA Authorization Framework", RFC 2904, 618 DOI 10.17487/RFC2904, August 2000, 619 . 621 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 622 "Transport Layer Security (TLS) Encryption for RADIUS", 623 RFC 6614, DOI 10.17487/RFC6614, May 2012, 624 . 626 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 627 Ed., "Diameter Base Protocol", RFC 6733, 628 DOI 10.17487/RFC6733, October 2012, 629 . 631 10.2. Informative References 633 [I-D.merged-i2nsf-framework-04] 634 Lopez, E., Lopez, D., Zhuang, X., Dunbar, L., Parrott, J., 635 Krishnan, R., and SR. Durbha, "Framework for Interface to 636 Network Security Functions", draft-merged-i2nsf-framework- 637 04.txt (work in progress), October 2015. 639 [ITU-T.X.1252] 640 "Baseline Identity Management Terms and Definitions", 641 April 2010. 643 [ITU-T.X.800] 644 "Security Architecture for Open Systems Interconnection 645 for CCITT Applications", March 1991. 647 [ITU-T.Y.3300] 648 "Recommendation ITU-T Y.3300", June 2014. 650 [ONF-OpenFlow] 651 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 652 October 2013. 654 [ONF-SDN-Architecture] 655 "SDN Architecture", June 2014. 657 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 658 Networking: A Perspective from within a Service Provider 659 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 660 . 662 Authors' Addresses 664 Rafa Marin-Lopez 665 University of Murcia 666 Campus de Espinardo S/N, Faculty of Computer Science 667 Murcia 30100 668 Spain 670 Phone: +34 868 88 85 01 671 Email: rafa@um.es 673 Gabriel Lopez-Millan 674 University of Murcia 675 Campus de Espinardo S/N, Faculty of Computer Science 676 Murcia 30100 677 Spain 679 Phone: +34 868 88 85 04 680 Email: gabilm@um.es