idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-12.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-mboned-maccnt-req]), 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2010) is 4956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ancp-framework' is defined on line 856, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ancp-framework-12 == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned H. Satou, 3 Internet-Draft H. Ohta, 4 Intended status: Informational T. Hayashi, 5 Expires: February 25, 2011 NTT 6 C. Jacquenet 7 France Telecom 8 H. He 9 Nortel 11 August 24, 2010 13 AAA and Admission Control Framework for Multicasting 14 draft-ietf-mboned-multiaaa-framework-12 16 Abstract 18 IP multicast-based services, such as TV broadcasting or 19 videoconferencing raise the issue of making sure that potential 20 customers are fully entitled to access the corresponding contents. 21 There is indeed a need for service and content providers to identify 22 users (if not authenticate, especially within the context of 23 enforcing electronic payment schemes) and to retrieve statistical 24 information for accounting purposes, as far as content and network 25 usage are concerned. This memo describes the framework for 26 specifying the Authorization, Authentication and Accounting (AAA) 27 capabilities that could be activated within the context of the 28 deployment and the operation of IP multicast-based services. This 29 framework addresses the requirements presented in "Requirements for 30 Accounting, Authentication and Authorization in Well Managed IP 31 Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo 32 provides a basic AAA enabled model as well as an extended fully 33 enabled model with resource and admission control coordination. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 This Internet-Draft will expire on February 25, 2011. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Purpose and Background . . . . . . . . . . . . . . . . . . 3 62 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 63 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Common use models and network architecture implications . . . 6 66 4. Framework and Roles of Entities . . . . . . . . . . . . . . . 7 67 4.1. AAA Framework in Multicast-Enabled Environments . . . . . 7 68 4.2. User ID . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4. Access Control and CP selection by NSP . . . . . . . . . . 12 71 4.5. Admission Control Information by NSP . . . . . . . . . . . 12 72 4.6. Access Control and Distinguishing of Users by CP . . . . . 13 73 4.7. AAA proxy in NSP . . . . . . . . . . . . . . . . . . . . . 13 74 5. Network Connection Model and Functional Components . . . . . . 14 75 5.1. Basic Connection Model . . . . . . . . . . . . . . . . . . 14 76 5.2. Constituent Logical Functional Components of the fully 77 enabled AAA Framework . . . . . . . . . . . . . . . . . . 15 78 5.3. Modularity of the framework . . . . . . . . . . . . . . . 19 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . . . . 22 87 1. Introduction 89 1.1. Purpose and Background 91 IP multicasting is designed to serve cases of group communication 92 schemes of any kind, such as one-to-many (case of TV broadcasting 93 services for example) or many-to- many (case of videoconferencing 94 services, for example). 96 In these environments, IP multicast provides a better resource 97 optimization than using a unicast transmission scheme, where data 98 need to be replicated as many times as there are receivers. 99 Activation of IP multicast capabilities in networks yields the 100 establishment and the maintenance of multicast distribution trees 101 that are receiver-initiated by nature: multicast-formatted data are 102 forwarded to receivers who explicitly request them. IP multicast- 103 based services, such as TV broadcasting or videoconferencing raise 104 the issue of making sure that potential customers are fully entitled 105 to access the corresponding contents. There is indeed a need for 106 service and content providers to identify (if not authenticate, 107 especially within the context of enforcing electronic payment 108 schemes) and to invoice such customers in a reliable and efficient 109 manner. Solutions should consider a wide range of possible content 110 delivery applications: content delivered over the multicast network 111 may include video, audio, images, games, software and information 112 such as financial data, etc. 114 This memo describes a framework for specifying the Authorization, 115 Authentication and Accounting (AAA) capabilities that could be 116 activated within the context of the deployment and the operation of 117 IP multicast-based services. This memo also describes a framework to 118 realize high-quality multicast transport using a Multicast Admission 119 Control Function (MACF) with multicast Authorization. 121 Specifically, this framework addresses the requirements presented in 122 "Requirements for Multicast AAA coordinated between Content 123 Provider(s) and Network Service Provider(s)" which describes the 124 requirements in CDN services using IP multicast. The requirements 125 are derived from: 127 need for user tracking and billing capabilities 129 need for network access control to satisfy the requirements of the 130 Network Service Provider (NSP) and/or content access control to 131 satisfy the requirements of the Content Provider (CP) 133 methods for sharing information between the network service 134 provider and content provider to make it possible to fulfill the 135 above two requirements. [I-D.mboned-maccnt- req] 137 Detailed requirements are presented in "Requirements for Accounting, 138 Authentication and Authorization in Well Managed IP Multicasting 139 Services" [I-D.ietf-mboned-maccnt-req]. These requirements include 140 mechanisms for recording end- user requests and provider responses 141 for content-delivery, sharing user information (possibly anonymously 142 depending on the trust model) between content provider and network 143 service provider, and protecting resources through the prevention of 144 network and content access by unauthorized users, as well as other 145 AAA related requirements. 147 The purpose of this memo is to provide a generalized framework for 148 specifying multicast-inferred AAA capabilities that can meet these 149 requirements. This framework is to provide a basis for future work 150 of investigating the applicability of existing AAA protocols to 151 provide these AAA capabilities in IP multicast specific context 152 and/or if deemed necessary, the refining or defining of protocols to 153 provide these capabilities. 155 2. Definitions and Abbreviations 157 2.1. Definitions 159 For the purpose of this memo the following definitions apply: 161 Accounting: The set of capabilities that allow the retrieval of a 162 set of statistical data that can be defined on a per customer 163 and/or a per service basis, within the context of the deployment 164 of multicast-based services. Such data are retrieved for billing 165 purposes, and can be retrieved on a regular basis or upon 166 unsolicited requests. Such data include (but are not necessarily 167 limited to) the volume of multicast-formatted data that have been 168 forwarded to the receiver over a given period of time, the volume 169 of multicast-formatted data that have been exchanged between a 170 receiver (or set of) and a given source over a given period of 171 time (e.g. the duration of a multicast session), etc. 173 Authentication: action for identifying a user as a genuine one. 175 Authorization: The set of capabilities that need to be activated 176 to make sure an authenticated user is fully entitled to access a 177 set of services. 179 Join: Signaling mechanism used by receivers to indicate they want 180 to access a multicast group and receive the corresponding traffic. 182 Leave: Signaling mechanism used by receivers to indicate they want 183 to leave a multicast group and not receive the corresponding 184 traffic anymore. 186 Receiver: an end-host or end-client which receives content. A 187 receiver may be identified by a network ID such as MAC address or 188 IP address. 190 User: a human with a user account. A user may possibly use 191 multiple reception devices. Multiple users may use the same 192 reception device. (Note: The definition of a receiver (device) 193 and a user (human) should not be confused.) 195 2.2. Abbreviations 197 For the purpose of this draft the following abbreviations apply: 199 AAA: Authentication.Authorization.and Accounting 201 ACL: Access Control List 203 AN: Access Node 205 CDN: Content Delivery Network 207 CDS: Content Delivery Services 209 CP: Content Provider 211 CP-AAA: Authentication, Authorization, and Accounting functions 212 used by a Content Provider 214 CPE: Customer Premise Equipment 216 ID: Identifier 218 IF: network interface 220 mAAA: Authentication, Authorization, and Accounting functions 221 activated in multicast-enabled environments 223 MACF: Multicast Admission Control Function 225 NAS: Network Access Server (RFC2881) 227 NSP: Network Service Provider 228 NSP-mAAA: Authentication, Authorization, and Accounting functions 229 used by a Network Service provider 231 QoS: Quality of Service 233 3. Common use models and network architecture implications 235 In some cases a single entity may design and be responsible for a 236 system that covers the various common high-level requirements of a 237 multicasting system such as 1) content serving, 2) the infrastructure 238 to multicast it, 3) network and content access control mechanisms. 240 In many cases however the content provision and network provision 241 roles are divided between separate entities. Commonly, Content 242 Providers (CP) do not build and maintain their own multicast network 243 infrastructure as this is not their primary business area. CP often 244 purchase transport and management services from network service 245 providers instead. Similarly Network Service Providers (NSP) may not 246 make their business in providing content. [I-D.mboned- maccnt-req] 247 provides more detail of the multiple versus single-entity Content 248 Delivery Service (CDS) network models. 250 In the usage model where a single NSP provides multicast services to 251 multiple CPs, the following general requirements from [I-D.ietf- 252 mboned-maccnt-req] apply: 254 Need for user tracking and billing capabilities 256 Need for QoS control such as resource management and admission 257 control 259 Need for conditional multicast access control satisfactory to the 260 requirements of the CP 262 Methods for sharing information between the NSP and CP to make the 263 above two possible 265 When the NSP and CP are the same single entity then the general 266 requirements are as follows. 268 Need for user tracking and user-billing capabilities 270 Need for access control and/or content protection at level the 271 entity deems appropriate 273 4. Framework and Roles of Entities 275 4.1. AAA Framework in Multicast-Enabled Environments 277 A general high-level framework is depicted in Figure 1. 279 +------------------------------+ 280 | user | 281 | | 282 +------------------------------+ 283 | 284 | 285 | 286 +------------------------------+ 287 | NSP | 288 | | 289 +------------------------------+ 290 | 291 | 292 | 293 +------------------------------+ 294 | CP | 295 | | 296 +------------------------------+ 298 Figure 1: High-level AAA framework in Multicast-Enabled Environments 300 Figure 1 302 For the sake of simplicity, the above diagram portrays a case where 303 there is a single NSP entity and a single CP entity (one-to-one 304 model), but multiple CPs can be connected to a single NSP (e.g. NSP 305 may provide connections to multiple CPs to provide a wide selection 306 of content categories: one-to-many model) It is also possible for a 307 single CP to be connected to multiple NSP networks (e.g. network 308 selection). Furthermore it is possible that the NSP and CP could be 309 the same entity. A NSP and CP authenticate and authorize each other 310 when they establish connectivity. Below the general case of multiple 311 NSPs with multiple CPs is explained. Then, the various combinations 312 of single and multiple CPs and NSPs are described in relation to the 313 general case. 315 4.1.1. Multiple CPs are connected to multiple NSPs 317 The user subscribes to multiple NSPs and multiple CPs in this usage 318 case. The user selects a CP and a NSP when the user requests 319 content. The NSP may be automatically selected by a user terminal: 321 e.g. a fixed line NSP by a set top box or a mobile NSP by a mobile 322 phone. In some usage cases it is possible that the NSP used by a 323 certain user will not always be the same. For example a user may 324 have contracted with more than one NSP: one for fixed line access and 325 another for mobile roaming access. 327 The content may be associated with (or managed by) a specific CP. In 328 this case, when the user selects content, the CP is automatically 329 selected. 331 Requests for multicast sent by the user to a selected NSP should 332 include enough information not only for authentication by the CP but 333 also for CP selection and admission control by the NSP. 335 When an NSP receives a request for multicast from a user, the NSP 336 requests the appropriate CP to make sure that the user is entitled to 337 access the corresponding content As the NSP is responsible for 338 managing its network resources, the NSP may perform admission 339 control.The NSP will allow access to the multicast service, depending 340 on both the response sent by the CP and the availability of resources 341 operated by the NSP. That is, the NSP will forward multicast traffic 342 towards the user only when the NSP has 1) made sure the user is 343 entitled to access the network resources operated by the NSP, 2) 344 received a confirmation from the CP that the user is entitled to 345 access the content and (possibly) 3) determined that the network 346 resources (e.g. bandwidth) are sufficient to deliver the multicast 347 traffic to the user with the relevant level of quality. When neither 348 of the first two conditions are met, the NSP will not forward 349 multicast traffic to the user. Condition #3 may also be a 350 showstopper. When the NSP already knows that network resources are 351 insufficient or there is a network failure, the NSP may choose to not 352 request the CP about the user's ability to retrieve content. The NSP 353 is also responsible for notifiying the user whether he/she is 354 eligible to receive content depending on the response sent by the CP. 355 In cases where the NSP does not start multicasting because of its own 356 network issues (e.g. lack of network resources or network failure), 357 the NSP notifies the user with a reason for rejecting the request. 359 A CP receives an inquiry from the NSP. The CP authenticates the 360 NSP's identity and makes an authorization decision regarding the 361 user's eligibility to access the requested contents. The CP is 362 responsible for the authentication and authorization of users so that 363 they can access the content managed by the CP. The CP notifies the 364 NSP accordingly. When the CP cannot (e.g. error or resource issues) 365 or decides not (e.g. policy issues) to deliver content, the CP is 366 responsible for notifying the NSP about the reason. It is up to the 367 NSP to relay or translate the reasons for rejection to the user. 369 A CP may delegate AAA responsibility to a NSP. 'AAA proxy in NSP' is 370 described in 4.7 for this case. 372 As defined in [I-D.ietf-mboned-maccnt-req], the CP may require the 373 retrieval of accounting information related to the access of its 374 content. 376 4.1.2. Multiple CPs are connected to a single NSP 378 The user subscribes to a single NSP which provides multicasting from 379 multiple CPs in this usage case. In this case the user does not 380 select an NSP. The user selects a CP when the user requests content. 381 The content may be associated with (or managed by) the specific CP, 382 so that when the user selects content, the CP is automatically 383 selected. 385 The user should send a request for multicast to the specific NSP with 386 enough information not only for authentication by the CP but also for 387 CP selection and admission control by the NSP. 389 The role of the NSP is the same as that described in 4.1.1. 391 The role of a CP is the same as that described in 4.1.1. 393 4.1.3. A single CP is connected to multiple NSPs 395 In this usage case, a user subscribes to multiple NSPs but only a 396 single CP. A user selects the NSP when the user requests multicast 397 but the CP is fixed. The user should send a request for multicast to 398 the selected NSP with enough information not only for authentication 399 by the CP but also for admission control by the NSP. 401 The role of the NSP is similar to the description in 4.1.1, with the 402 exception that when a NSP receives a request from a user, NSP makes 403 an inquiry to the CP without CP selection. 405 The role of the CP is the same as that described in 4.1.1. 407 4.1.4. A single CP is connected to single NSP 409 In this case, a user subscribes to only one NSP and one CP. The user 410 does not select a NSP and CP in this scenario. Requests for 411 multicast sent by the user to a selected NSP should include enough 412 information not only for authentication by the CP but also for 413 admission control by the NSP. 415 The role for the NSP is the same as 4.1.3 The role of the CP is the 416 same as the description in 4.1.1. 418 The NSP and CP could be the same entity. In this case, the roles of 419 the NSP and CP may be combined. 421 4.2. User ID 423 Users may hold multiple user IDs: IDs which have been separately 424 assigned for each subscription to various NSPs and CPs. The NSPs and 425 CPs manage the user IDs for their respective domains. A CP 426 identifies a user by a user ID assigned by the CP itself. A NSP 427 identifies a user by a user ID assigned by the NSP itself. The user 428 IDs are only meaningful within the context of each domain. Users may 429 hold multiple user IDs which have been separately assigned for each 430 subscription they may have for various NSPs and CPs. 432 4.2.1. CP-assigned user ID 434 CPs assign user IDs to their users. The user may have more than one 435 CP-assigned user ID per specific CP. A user requests multicast to a 436 NSP, the CP-assigned user ID should be indicated so that the CP can 437 identify the user requesting content access. A NSP should notify the 438 CP- assigned user ID to the CP. A NSP should not share a CP- 439 assigned user ID with any CP except the one which assigned it and 440 should not relay it at all if there is no appropriate CP that 441 assigned the user ID. 443 4.2.2. NSP-assigned user ID 445 NSPs assign user IDs to their users. A user may have more than one 446 NSP-assigned user ID per a specific NSP. A user requests for 447 multicast to a NSP, the NSP-assigned user ID may be indicated in the 448 request so that the NSP can identify the user. The NSP should not 449 inform the NSP- assigned user ID to the CP for security reasons. The 450 NSP may identify the multicast-access user by other methods than the 451 NSP-assigned userID, e.g. by the access port. 453 The actual mapping rules for NSP-assigned user IDs with CP- user 454 assigned IDs in account logs is a matter for the providers and out of 455 the scope of this framework. 457 This memo assumes that the NSP identifies the user on L2 (such as 458 VLAN or PPP) and that it would be problematic for the NSP if more 459 than two receivers for the same user accessed the same channel and 460 one is accepted but the other is rejected on L2 or L3. Prevention of 461 unauthorized content sharing could be handled on the application 462 layer by the CP: e.g. could distinguish among receivers and 463 distribute encryption keys so that non-authorized receivers can not 464 make use of the content. 466 4.3. Accounting 468 There are some accounting issues specific to multicasting. An (S,G) 469 should be recorded as a channel identifier. The last hop device, 470 such as an IGMP or MLD router or an IGMP or MLD proxy, notifies the 471 NSP's mAAA function of the (S,G) channel identifier. The NSP should 472 notify the CP of the (S,G) information in the accounting report 473 messages. 475 A NSP records an accounting start corresponding to only the first 476 Join for a specific user-access session. A NSP should not treat a 477 "Join" response to a Query as the accounting start. The accounting 478 start assumes that the conditions for forwarding multicast traffic as 479 defined in section 4.1.1 have been met: (1) user is entitled to 480 access network, 2) user is entitled to access content, optionally 3) 481 network resources are determined to be sufficient, and that the 482 forwarding has actually begun. Optionally a NSP may record when a 483 Join could not be granted because of insufficient network resources. 485 A NSP records an accounting stop triggered by any of the following: 486 1) a user requested Leave, 2) a timeout of a multicast state or 3) a 487 re-authentication failure. A NSP may also record an accounting stop 488 due to network availability reasons such as failure. The NSP logs 489 the reason for each accounting stop. 491 Intermittent logs between the join and leave would allow for finer 492 diagnostics and therefore could serve useful in billing 493 discrepancies, and provide for a better estimation of the time-span 494 that content was multicast, in the event that users disconnect 495 without sending leave messages. 497 There are two levels of accounting report messaging. Messages in 498 Accounting level 1 include a channel identifier, a user identifier, 499 and the accounting start and stop time information. Accounting level 500 2 includes all information of Level 1, plus traffic volume 501 information. 503 QoS class is an optional item for each accounting level. Whether to 504 send, and at what interval to send intermittent log information is 505 optional for both levels. CP and NSPs may also agree to include 506 additional option information in accounting messages of either level. 508 The level of account report messaging between the NSP and CP may be 509 either configured statically or can be dynamically requested by the 510 CP in its response to the Access-Request relayed by the NSP to the 511 CP. The determination of the actual level of report messaging is 512 configured by the NSP at the NAS. 514 In case of very fast channel changes, the amount of items logged by 515 the NSP could become high. In order to reduce the number of report 516 messages sent to the CP, the NSP can consolidate multiple sets of 517 accounting information inside a single accounting report message. 519 4.4. Access Control and CP selection by NSP 521 When a NSP receives an access request from a user, the NSP determines 522 to which CP the request is to be directed. The NSP may select a CP 523 based on CP-assigned userID with CP domain name or channel identifier 524 (S,G). The user should include in the request sufficient information 525 for CP selection. 527 4.5. Admission Control Information by NSP 529 After authorizing a user request, the NSP may have further conditions 530 for determining its admission control decision. 532 The NSP receives parameters (such as QoS class, required bandwidth, 533 burst-size, etc.) of multicast traffic. Such parameters serve as 534 information to be considered in the admission control decision. The 535 traffic parameters can be communicated as follows: 537 A CP may notify a mapping between the channel identifier (S,G) and 538 traffic parameters in the Response message when the CP authorizes 539 an access request. Such parameters may include required 540 bandwidth, burst-size, QoS class downgrade policy, etc. 542 A user may indicate in the Request willingness to accept QoS class 543 downgrade to best-effort streaming. 545 The NSP may maintain a mapping between channel identifier (S,G) 546 and traffic parameters in advance, for example pre-configured by 547 agreement between the CP and NSP on a per channel (S,G) basis. 549 The ultimate admission decision is made by the NSP based on required 550 traffic parameters of the requested, and available resources. In a 551 case that it cannot guarantee the required network resources for the 552 requested multicast traffic, streaming the requested multicast 553 traffic as best-effort is optional. The user may indicate in his/her 554 Access Request whether he/she will accept best-effort grade streaming 555 if guaranteed class is not available. The CP's preference for 556 accepting downgrading to best-effort streaming may be either 557 configured statically or can be dynamically requested by the CP in 558 its response to the Access-Request relayed by the NSP to the CP. In 559 the case that it cannot be offered a guaranteed QoS stream, the NSP 560 may decide either to decline admission or to stream the requested 561 multicast traffic as best-effort. The NSP should not stream best- 562 effort traffic if either the user or CP has indicated against best- 563 effort provision. 565 A NSP's admission control may manage integrated network resources for 566 unicast usage, such as VoIP or unicast streaming, and multicast 567 usage. Alternatively, it may manage network resources separately for 568 unicast and multicast usage. In either ease, AAA and admission 569 control framework for multicast usage is independent of unicast 570 admission control. 572 Such QoS measurement and policy mechanisms themselves depend on NSP 573 policies and are out of the scope of this memo. 575 4.6. Access Control and Distinguishing of Users by CP 577 The user ID and authentication information are forwarded 578 transparently by the NSP so that the CP can distinguish the user, as 579 well as authenticate and authorize the request. 581 4.7. AAA proxy in NSP 583 A NSP may act as AAA proxy of a CP based upon an agreement between 584 the NSP and the CP. The AAA proxy would store information about 585 permissions of a specific user to receive multicast data from 586 specified channel(s) up to specified expiration date(s) and time(s). 588 If such proxying is implemented, the NSP may receive authorization 589 conditions from a CP in advance and statically hold them, or a CP may 590 send them dynamically in the Response message. In either case, the 591 user has permission to receive multicast traffic and therefore the 592 NSP starts the multicasting without querying the CP. 594 The CP may send unsolicited requests to the NSP to refresh or change 595 the permissions for a user for specific group(s) or channel(s). 597 When a user is receiving multicast traffic while the permission is 598 about to expire, the NSP may send a notification to the user client 599 that his session is about to expire, and that he will need to re- 600 authenticate. In such a case, the user will have to send the Access- 601 Request. In the case that the user still has permission to the 602 content, they should be able to continue to receive the multicast 603 traffic without interruption. 605 When re-authentication fails, the NSP should stop the multicast 606 traffic and record accounting stop. 608 5. Network Connection Model and Functional Components 610 Section 3.1 introduced the high-level AAA framework for multicasting. 611 This section provides more detail on the network connection model and 612 constituent functional components. 614 5.1. Basic Connection Model 616 +------------------------------+ 617 | receiver | 618 | | 619 +------------------------------+ 620 | ^ Response 621 | Request | 622 V | 623 +------------------------------+ 624 | NSP's network | 625 | | 626 +------------------------------+ 627 | ^ Response 628 | Request | (Success) 629 v | 630 +------------------------------+ 631 | CP's network | 632 | | 633 +------------------------------+ 635 Figure 2: Basic Connection Model 637 Figure 2 639 In the simple case represented in Figure 1 the NSP is the sole entity 640 providing network resources including network access to the multicast 641 receiver. First a receiver sends a request for multicast (e.g. an 642 IGMP Report message) to an NSP which may then forward a mAAA request 643 towards the appropriate CP for authentication and authorization 644 purposes. The receiver gets information about a given multicast 645 group (*,G) or channel (S,G) corresponding to the content beforehand 646 for generating the request. The CP responds with either "success" or 647 "failure". If "success", the NSP grants access to the receiver and 648 forwards multicast traffic accordingly. 650 In this model the receiver selects the NSP to which the Join request 651 will be sent. Based on this request the NSP selects an appropriate 652 CP to which it forwards the corresponding mAAA request. The CP 653 responds to the NSP's m AAA request: it may not respond to another 654 NSP in regards to the request. 656 In this model, as described in section 4.1, the relationship between 657 NSP and CP can be one-to-one, one-to- many or many-to-many. 658 Receivers may connect to multiple networks. 660 5.2. Constituent Logical Functional Components of the fully enabled AAA 661 Framework 663 Requirements for "fully AAA and QoS enabled" IP multicasting networks 664 were defined in MACCNT-REQ-draft. To allow for levels of enablement, 665 this memo defines two models within the framework: "AAA enabled" 666 multicasting and "Fully enabled AAA" multicasting which means "AAA 667 enabled" with added admission control functions. 669 Section 3.1 introduces the high-level AAA framework for multicasting. 670 Below is a diagram of a AAA enabled multicasting network with AAA, 671 including the logical components within the various entities. 673 +-------------------------------+ 674 | user | 675 |+- - - - - - - - - - - - - - -+| 676 || CPE || 677 || || 678 |+- - - - - | - - - - - - - - -+| 679 +-----------|-------------------+ 680 | 681 -------|------ IFa 682 | 683 +-----------|-------------------+ 684 | NSP | | 685 |+- - - - - |- -_+ | 686 ||TS | | | 687 | +------|-+ | 688 || | AN | | | 689 | | |---------+ | 690 || +------|-+ | | | 691 | | IFb | | 692 || +------|-+ | | +---------+| 693 | | |----|-|mAAA || 694 || | NAS | | | |(MACF *) || * optional 695 | +--------+ +---------+| 696 ||+- - - - - - - + | | 697 +-----------------------|--------+ 698 | 699 -------|------ IFc 700 | 701 +-----------------------|-------+ 702 | CP +---------+ | 703 | | CP-AAA | | 704 | +---------+ | 705 +-------------------------------+ 707 Figure 3: AAA enabled framework (basic model) 709 Figure 3 711 The user entity includes the CPE (Customer Premise Equipment) which 712 connects the receiver (s). 714 The NSP (Network Service Provider) in the basic model includes the 715 transport system and a logical element for multicast AAA 716 functionality. The TS (transport system) is comprised of the access 717 node and NAS (Network Access Server) An AN (Access Node) may be 718 connected directly to mAAA or a NAS relays AAA information between an 719 AN and a mAAA. Descriptions of AN and its interfaces are out of the 720 scope for this memo. The multicast AAA function may be provided by a 721 mAAA which may include the function that downloads Join access 722 control lists to the NAS (this function is referred to conditional 723 access policy control function.) 725 Interface between mAAA and NAS 727 The interface between mAAA and the NAS is labeled IFb in Figure 2. 728 Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA 729 replies. The mAAA may push conditional access policy to the NAS. 731 CP-AAA 733 The content provider may have its own AAA server which has the 734 authority over access policy for its contents. 736 Interface between user and NSP 738 The interface between the user and the NSP is labeled IFa in Figure 739 3. Over IFa the user makes a multicasting request to the NSP. The 740 NSP may in return forward multicast traffic depending on the NSP and 741 CP's policy decisions. 743 Interface between NSP and CP 745 The interface between the NSP and CP is labeled IFc. Over IFc the 746 NSP requests to the CP-AAA for access to contents and the CP replies. 747 CP may also send conditional access policy over this interface for 748 AAA-proxying. 750 +-------------------------------+ 751 | user | 752 |+- - - - - - - - - - - - - - -+| 753 || CPE || 754 || || 755 |+- - - - - | - - - - - - - - -+| 756 +-----------|-------------------+ 757 | 758 -------|------ IFa 759 | 760 +-----------|-----------------------+ 761 |+- - - - - |- - _+ + - - - - - + | 762 || | | | | | | 763 | +------|-+ | +--------+ | 764 || | AN | | | | | MACF || | 765 | | | | | | | 766 || +------|-+ | | | +---|----+| | 767 | | | | | | 768 | | | | IFd----- | | 769 | | | IFb | | | 770 || +------|---+ | | | +---|----+| | 771 | | |---|---| mAAA | | 772 || | NAS | | | | |(MACF *)|| | * optional 773 | +----------+ | +--------+ | 774 ||+- - - - - - - -+ - - |- - - - -+ | 775 +-----------------------|-----------+ 776 | 777 -------|------ IFc 778 | 779 +-----------------------|-------+ 780 | CP +---------+ | 781 | | CP-AAA | | 782 | +---------+ | 783 +-------------------------------+ 785 Figure 4: Fully enabled framework 787 Figure 4 789 In the fully enabled model the NSP also includes a component that 790 provides network resource management (e.g. QoS management), as 791 described in section 3.4, "Network Resource Management by NSP". In 792 the fully enabled model (Figure 4) resource management and admission 793 control is provided by MACF (Multicast Admission Control Function). 794 This means that, before replying to the user's multicast request, the 795 mAAA queries the MACF for a network resource access decision over the 796 interface IFd. The MACF is responsible for allocating network 797 resources for forwarding multicast traffic. MACF also receives Leave 798 information from NAS so that MACF releases corresponding reserved 799 resources. 801 5.3. Modularity of the framework 803 In the interest of flexibility, this framework is modular so that it 804 is possible that partially enabled versions of the models are 805 supported. A AAA-enabled version provides AAA functionality without 806 Network Resource management. A Network-Resource-Management-enabled 807 (QoS-enabled) version provides Network Resource management without 808 AAA functionality. Similarly, the possibility of one or more layers 809 of transit provision between an NSP and CP is in the interest of 810 modularity and extendibility. 812 6. Acknowledgments 814 The authors of this draft would like to express their appreciation to 815 Susheela Vaidya of Cisco Systms whose contributions to the 816 "Requirements for Multicast AAA coordinated between Content 817 Provider(s) and Network Service Provider(s)" 818 [I-D.ietf-mboned-maccnt-req] largely influenced this draft; Pekka 819 Savola of Netcore Ltd.; Daniel Alvarez, and Toerless Eckert of Cisco 820 Systems; Sam Sambasivan of AT&T; Sanjay Wadhwa, Greg Shepherd, and 821 Leonard Giuliano of Juniper; Tom Anschutz and Steven Wright of 822 BellSouth; Nicolai Leymann of T-Systems; Bill Atwood of Concordia 823 University; Carlos Garcia Braschi of Telefonica Empresas; Mark Altom, 824 Andy Huang, Tom Imburgia, Han Nguyen, Doug Nortz of ATT Labs; 825 Marshall Eubanks in his role as mboned WG chair; Ron Bonica in his 826 role as Director as the Operations and Management Area; Stephen Rife 827 of Digital Garage and David Meyer in his former role as mboned WG 828 chair as well as their thanks to the participants of the MBONED WG in 829 general. 831 Funding for the RFC Editor function is currently provided by the 832 Internet Society. 834 7. IANA Considerations 836 This memo does not raise any IANA consideration issues. 838 8. Security Considerations 840 The user information related to authentication with the CP and the 841 information related to user accounting shared between the NSP and the 842 CP must be protected in some way. Otherwise, this memo does not 843 raise any new security issues which are not already addressed by the 844 original protocols. Enhancement of multicast access control 845 capabilities should enhance security performance. 847 9. Conclusion 849 This memo provides a generalized framework for solution standards to 850 meet the requirements. Further work should be done to specify the 851 interfaces between the user and NSP, NAS and mAAA, mAAA and MACF and 852 NSP-mAAA and CP-AAA (presented in 5.2.) 854 10. Normative References 856 [I-D.ietf-ancp-framework] 857 Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 858 Wadhwa, "Framework and Requirements for an Access Node 859 Control Mechanism in Broadband Multi-Service Networks", 860 draft-ietf-ancp-framework-12 (work in progress), 861 July 2009. 863 [I-D.ietf-mboned-maccnt-req] 864 Hayashi, T., He, H., Satou, H., Ohta, H., and S. Vaidya, 865 "Requirements for Multicast AAA coordinated between 866 Content Provider(s) and Network Service Provider(s)", 867 draft-ietf-mboned-maccnt-req-08 (work in progress), 868 July 2009. 870 Authors' Addresses 872 Hiroaki Satou 873 Nippon Telegraph and Telephone Corporation 874 3-9-11 Midoricho 875 Musashino-shi, Tokyo 180-8585 876 Japan 878 Phone: +81 422 59 4683 879 Email: satou.hiroaki@lab.ntt.co.jp 880 Hiroshi Ohta 881 Nippon Telegraph and Telephone Corporation 882 3-9-11 Midoricho 883 Musashino-shi, Tokyo 180-8585 884 Japan 886 Phone: +81 422 59 3617 887 Email: ohta.hiroshi@lab.ntt.co.jp 889 Tsunemasa Hayashi 890 Nippon Telegraph and Telephone Corporation 891 1-1 Hikarino'oka 892 Yokosuka-shi, Kanagawa 239-0847 893 Japan 895 Phone: +81 46 859 8790 896 Email: hayashi.tsunemasa@lab.ntt.co.jp 898 Christian Jacquenet 899 France Telecom 900 3, avenue Francois Chateau 901 CS 36901, Rennes Cedex 95134 902 France 904 Phone: +33 2 99 87 61 92 905 Email: christian.jacquenet@orange-ftgroup.com 907 Haixiang He 908 Nortel 909 600 Technology Park Drive 910 Billerica, MA 01801 911 USA 913 Phone: +1 978 288 7482 914 Email: haixiang@nortel.com 916 Copyright and License Notice 918 Copyright (c) 2010 IETF Trust and the persons identified as the 919 document authors. All rights reserved. 921 This document is subject to BCP 78 and the IETF Trust's Legal 922 Provisions Relating to IETF Documents 923 (http://trustee.ietf.org/license-info) in effect on the date of 924 publication of this document. Please review these documents 925 carefully, as they describe your rights and restrictions with respect 926 to this document. Code Components extracted from this document must 927 include Simplified BSD License text as described in Section 4.e of 928 the Trust Legal Provisions and are provided without warranty as 929 described in the Simplified BSD License. 931 This document may contain material from IETF Documents or IETF 932 Contributions published or made publicly available before November 933 10, 2008. The person(s) controlling the copyright in some of this 934 material may not have granted the IETF Trust the right to allow 935 modifications of such material outside the IETF Standards Process. 936 Without obtaining an adequate license from the person(s) controlling 937 the copyright in such materials, this document may not be modified 938 outside the IETF Standards Process, and derivative works of it may 939 not be created outside the IETF Standards Process, except to format 940 it for publication as an RFC or to translate it into languages other 941 than English.