idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 923. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2007) is 6264 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 828, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 831, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-05 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '1') == Outdated reference: A later version (-13) exists of draft-ietf-ancp-framework-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ancp-framework (ref. '4') Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA Framework for Multicasting Feb. 2008 4 Internet Draft Hiroaki Satou, NTT 5 Intended Status: Hiroshi Ohta, NTT 6 Informational 7 Expires: August Christian Jacquenet, France Telecom 8 22, 2008 9 Tsunemasa Hayashi, NTT 10 Haixiang He, Nortel Networks 12 February 25, 2007 14 AAA Framework for Multicasting 15 17 Status of this Memo 19 By submitting this Internet-Draft, each author 20 represents that any applicable patent or other IPR 21 claims of which he or she is aware have been or will 22 be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 24 6 of BCP 79. 26 Internet-Drafts are working documents of the 27 Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may 29 also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a 33 maximum of six months and may be updated, replaced, 34 or obsoleted by other documents at any time. It is 35 inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed 40 at http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be 43 accessed at http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 22, 2008. 47 Copyright Notice 49 Copyright (C) The IETF Trust (2008). This document 50 is subject to the rights, licenses and restrictions 51 contained in BCP 78, and except as set forth 52 therein, the authors retain all their rights. 54 Abstract 56 IP multicast-based services, such as TV broadcasting 57 or videoconferencing raise the issue of making sure 58 that potential customers are fully entitled to 59 access the corresponding contents. There is indeed a 60 need for service and content providers to identify 61 (if not authenticate, especially within the context 62 of enforcing electronic payment schemes) and to 63 invoice such customers in a reliable and efficient 64 manner. This memo describes the framework for 65 specifying the Authorization, Authentication and 66 Accounting (AAA) capabilities that could be 67 activated within the context of the deployment and 68 the operation of IP multicast-based services. This 69 framework addresses the requirements presented in 70 draft-ietf-mboned-maccnt-req-04.txt, "Requirements 71 for Accounting, Authentication and Authorization in 72 Well Managed IP Multicasting Services". The memo 73 provides a basic AAA enabled model as well as an 74 extended fully enabled model with resource and 75 admission control coordination. 77 Table of Contents 78 1. INTRODUCTION 4 79 1.1 PURPOSE AND BACKGROUND 4 80 2. DEFINITIONS AND ABBREVIATIONS 5 81 2.1 DEFINITIONS 5 82 2.2 ABBREVIATIONS 6 83 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 84 4. FRAMEWORK AND ROLES OF ENTITIES 8 85 4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 8 86 4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 87 4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 10 88 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 10 89 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 10 90 4.2 USER ID 11 91 4.2.1 CP-ASSIGNED USER ID 11 92 4.2.2 NSP-ASSIGNED USER ID 11 93 4.3 ACCOUNTING 12 94 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 95 4.5 ADMISSION CONTROL INFORMATION BY NSP 13 96 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 97 4.7 AAA PROXY IN NSP 14 98 5.1 BASIC CONNECTION MODEL 15 99 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY 100 ENABLED AAA FRAMEWORK 15 101 5.3 MODULARITY OF THE FRAMEWORK 19 102 6. IANA CONSIDERATIONS 19 103 7. SECURITY CONSIDERATIONS 19 104 8. CONCLUSION 19 106 1. Introduction 108 1.1 Purpose and Background 110 IP multicasting is designed to serve cases of group 111 communication schemes of any kind, such as 1-to-n (case of 112 TV broadcasting services for example) or n-to-p (case of 113 videoconferencing services, for example). 115 In these environments, IP multicast provides a better 116 resource optimization than using a unicast transmission 117 scheme, where data need to be replicated as many times as 118 there are receivers. Activation of IP multicast 119 capabilities in networks yields the establishment and the 120 maintenance of multicast distribution trees that are 121 receiver-initiated by nature: multicast-formatted data are 122 forwarded to receivers who explicitly request them. 123 IP multicast-based services, such as TV broadcasting or 124 videoconferencing raise the issue of making sure that 125 potential customers are fully entitled to access the 126 corresponding contents. There is indeed a need for service 127 and content providers to identify (if not authenticate, 128 especially within the context of enforcing electronic 129 payment schemes) and to invoice such customers in a 130 reliable and efficient manner. Solutions should consider a 131 wide range of possible content delivery applications: 132 content delivered over the multicast network may include 133 video, audio, images, games, software and information such 134 as financial data, etc. 136 This memo describes a framework for specifying the 137 Authorization, Authentication and Accounting (AAA) 138 capabilities that could be activated within the context of 139 the deployment and the operation of IP multicast-based 140 services. This memo also describes a framework to realize 141 high-quality multicast transport using a Multicast 142 Admission Control Function (MACF) with multicast 143 Authorization. 144 Specifically, this framework addresses the requirements 145 presented in draft-ietf-mboned-maccnt-req-05.txt, 146 "Requirements for Multicast AAA coordinated between Content 147 Provider(s) and Network Service Provider(s)" MACCNT-REQ- 148 draft describes the requirements in CDN services using IP 149 multicast[1]. The requirements are derived from: 150 - need for user tracking and billing capabilities 151 - need for network access control to satisfy the 152 requirements of the Network Service Provider (NSP) and/or 153 content access control to satisfy the requirements of the 154 Content Provider (CP) 155 - methods for sharing information between the network 156 service provider and content provider to make it possible 157 to fulfill the above two requirements. 159 Detailed requirements are presented in MACCNT-REQ-draft. 160 These requirements include mechanisms for recording end- 161 user requests and provider responses for content-delivery, 162 sharing user information (possibly anonymously depending on 163 the trust model) between content provider and network 164 service provider, and protecting resources through the 165 prevention of network and content access by unauthorized 166 users, as well as other AAA related requirements. 168 The purpose of this memo is to provide a generalized 169 framework for specifying multicast-inferred AAA 170 capabilities that can meet these requirements. This 171 framework is to provide a basis for future work of 172 investigating the applicability of existing AAA protocols 173 to provide these AAA capabilities in IP multicast specific 174 context and/or if deemed necessary, the refining or 175 defining of protocols to provide these capabilities. 177 2. Definitions and Abbreviations 179 2.1 Definitions 181 For the purpose of this memo the following definitions 182 apply: 184 Accounting: The set of capabilities that allow the 185 retrieval of a set of statistical data that can be defined 186 on a per customer and/or a per service basis, within the 187 context of the deployment of multicast-based services. Such 188 data are retrieved for billing purposes, and can be 189 retrieved on a regular basis or upon unsolicited requests. 190 Such data include (but are not necessarily limited to) the 191 volume of multicast-formatted data that have been forwarded 192 to the receiver over a given period of time, the volume of 193 multicast-formatted data that have been exchanged between a 194 receiver (or set of) and a given source over a given period 195 of time (e.g. the duration of a multicast session), etc. 197 Authentication: action for identifying a user as a genuine 198 one. 200 Authorization: The set of capabilities that need to be 201 activated to make sure a given requesting customer is (1) 202 what he claims to be (identification purposes), and (2) is 203 fully entitled to access a set of services (authentication 204 purposes). 206 Receiver: an end-host or end-client which receives content. 207 A receiver may be identified by a network ID such as MAC 208 address or IP address. 210 User: a human with a user account. A user may possibly use 211 multiple reception devices. Multiple users may use the 212 same reception device. 214 Note: The definition of a receiver (device) and a user 215 (human) should not be confused. 217 2.2 Abbreviations 219 For the purpose of this draft the following abbreviations 220 apply: 222 ACL: Access Control List 224 AN: Access Node 226 CDN: Content Delivery Network 228 CDS: Content Delivery Services 230 CP: Content Provider 232 CPE: Customer Premise Equipment 233 MACF: Multicast Admission Control Function 235 NSP: Network Service Provider 237 TS: Transport System 239 3. Common use models and network architecture implications 241 In some cases a single entity may design and be responsible 242 for a system that covers the various common high-level 243 requirements of a multicasting system such as 1) content 244 serving, 2) the infrastructure to multicast it, 3) network 245 and content access control mechanisms. In many cases 246 however the content provision and network provision roles 247 are divided between separate entities. The MACCNT-REQ- 248 draft provides more detail of the multiple versus single 249 entity CDS network models. 251 As such it should not be assumed that the entity 252 responsible for the multicasting structure and the entity 253 responsible for content serving are the same. Indeed 254 because the infrastructure for multicasting is expensive 255 and many content holders are not likely to be competent at 256 building and maintaining complicated infrastructures 257 necessary for multicasting, many content holders would 258 prefer to purchase transport and management services from a 259 network service provider and thus share the infrastructure 260 costs with other content holders. 262 Similarly network service providers in many cases do not 263 specialize in providing content and are unlikely to build 264 and maintain such a resource-intensive system without a 265 certain level of demand from content holders. 267 The use model of a single NSP providing multicasting 268 services to multiple CPs the following general requirements 269 from MACCNT-REQ-draft apply: 271 -Need for user tracking and billing capabilities 272 -Need for QoS control such as resource management and 273 admission control 274 -Need for conditional content access control 275 satisfactory to the requirements of the CP 276 -Methods for sharing information between the NSP and 277 CP to make the above two possible 279 When the NSP and CP are the same single entity the general 280 requirements are as follows. 282 -Need for user tracking and user-billing capabilities 283 -Need for access control and/or content protection at 284 level the entity deems appropriate 286 4. Framework and Roles of Entities 288 4.1 "AAA Framework in Multicast-Enabled Environments 290 A general high-level framework can be represented as 291 follows. 293 +------------------------------+ 294 | user | 295 | | 296 +------------------------------+ 297 | Access ^ Response 298 | Request | 299 V | 300 +------------------------------+ 301 | NSP | 302 | | 303 +------------------------------+ 304 | Access ^ Response 305 | Request | (Success) 306 v | 307 +------------------------------+ 308 | CP | 309 | | 310 +------------------------------+ 311 Figure 1 313 For the sake of simplicity, the above diagram portrays a 314 case where there is a single NSP entity and a single CP 315 entity, but multiple CPs can be connected to a single NSP 316 (e.g. NSP may provide connections to multiple CPs to 317 provide a wide selection of content categories.) It is also 318 possible for a single CP to be connected to multiple NSP 319 networks (e.g. network selection). Furthermore it is 320 possible that the NSP and CP could be the same entity. A 321 NSP and CP authenticate and authorize each other when they 322 establish connectivity. Below the general case of multiple 323 NSPs with multiple CPs is explained. Then, the various 324 combinations of single and multiple CPs and NSPs are 325 described in relation to the general case. 327 4.1.1 Multiple CPs are connected to multiple NSPs 329 The user subscribes to multiple NSPs and multiple CPs in 330 this usage case. The user selects a CP and a NSP when the 331 user requests content. The NSP may be automatically 332 selected by a user terminal: e.g. a fixed line NSP by a set 333 top box or a mobile NSP by a mobile phone. In some usage 334 cases it is possible that the NSP used by a certain user 335 will not always be the same. For example a user may have 336 contracted with more than one NSP: one for fixed line 337 access and another for mobile roaming access. 339 The content may be associated with (or managed by) a 340 specific CP. In this case, when the user selects content, 341 the CP is automatically selected. 343 The user should send an Access-Request to the selected NSP 344 with enough information not only for authentication by the 345 CP but also for CP selection and admission control by the 346 NSP. 348 When an NSP receives an Access-Request from a user, the NSP 349 selects the appropriate CP for the received Access-Request 350 and relays the content request. As the NSP is responsible 351 for managing its network resources, the NSP may perform 352 admission control.The NSP will allow access to the network 353 and contents conditional to both the CP's content 354 authorization result and the NSPs network availability. 355 That is, the NSP starts multicast flow only when it has 356 both 1) received an "accept" response from the CP and 2) 357 determined that the network resources (e.g. bandwidth) are 358 sufficient to serve the multicast channel. When neither of 359 these conditions are met, the NSP does not start the 360 requested multicast channel. When the NSP already knows 361 that network resources are insufficient or there is a 362 network failure, the NSP may choose to not relay the 363 Access-Request to the CP. The NSP is also responsible for 364 relaying the Response message from the CP to the user 365 whether the user is eligible to receive content (in 366 response to the corresponding Access-Request from the user 367 to the CP.) In cases that the NSP does not start 368 multicasting because of its own network issues (e.g. lack 369 of network resources or network failure), the NSP notifies 370 the user with a reason for rejecting the request. 372 A CP receives an Access-Request relayed by the NSP. The CP 373 authenticates the NSP's identity and makes an authorization 374 decision regarding the NSP's eligibility to provide users 375 access to its contents. The CP is responsible for 376 Authentication and Authorization of users' access to 377 content that the CP manages. The CP hopes to collect 378 accounting information related to the access of their 379 content. The CP responds to the NSP regarding the relayed 380 Access-Request. When the CP cannot (e.g. error or 381 resource issues) or decides not (e.g. policy issues) to 382 deliver content, the CP is responsible for notifying the 383 NSP of the reason. It is up to the NSP how to relay or 384 translate the reasons for rejection to the user. 386 4.1.2 Multiple CPs are connected to a single NSP 388 The user subscribes to a single NSP which provides 389 multicasting of channels from multiple CPs in this usage 390 case. In this case the user does not select an NSP. The 391 user selects a CP when the user requests content. The 392 content may be associated with (or managed by) the specific 393 CP, so that when the user selects content, the CP is 394 automatically selected. 395 The user should send an Access-Request to the specific NSP 396 with enough information not only for authentication by the 397 CP but also for CP selection and admission control by the 398 NSP. 400 The role of the NSP is the same as that described in 4.1.1. 402 The role of a CP is the same as that described in 4.1.1. 404 4.1.3 A single CP is connected to multiple NSPs 406 A user subscribes to multiple NSPs but a single CP in this 407 usage case. A user selects the NSP when the user requests 408 content but the CP is fixed. The user should send an 409 Access-Request to the selected NSP with enough information 410 not only for authentication by the CP but also for 411 admission control by the NSP. 413 The role of the NSP is similar to the description in 4.1.1, 414 with the exception that when a NSP receives an Access- 415 Request from a user, NSP relays it to the CP without CP 416 selection. 418 The role of the CP is the same as that described in 4.1.1. 420 4.1.4 A single CP is connected to single NSP 422 In this case, a user subscribes to only one NSP and one CP. 423 The user does not select NSP and CP in this scenario. The 424 user should send an Access-Request to the NSP with enough 425 information not only for authentication by the CP but also 426 for admission control by the NSP. 428 The role for the NSP is the same as 4.1.3 429 The role of the CP is the same as the description in 4.1.1. 431 The NSP and CP could be the same entity. In this case, the 432 roles of the NSP and CP may be combined. 434 4.2 User ID 436 Users may hold multiple user IDs: IDs which have been 437 separately assigned for each subscription they may have for 438 various NSPs and CPs. The NSPs and CPs manage the user IDs 439 for their respective domains. A CP identifies a user by a 440 user ID assigned by the CP itself. A NSP identifies a user 441 by a user ID assigned by the NSP itself. The user IDs are 442 only meaningful within the context of each domain. Users 443 may hold multiple user IDs which have been separately 444 assigned for each subscription they may have for various 445 NSPs and CPs. 447 4.2.1 CP-assigned user ID 449 CPs assign user IDs to their users. The user may have more 450 than one CP-assigned user ID per specific CP. A user sends 451 an Access-Request to a NSP, the CP-assigned user ID should 452 be indicated so that the CP can identify the user 453 requesting content access. A NSP should relay the CP- 454 assigned user ID from the user to the CP. A NSP should not 455 send a CP-assigned user ID to any CP except the one which 456 assigned it and should not relay it at all if there is no 457 appropriate CP that assigned the user ID. 459 4.2.2 NSP-assigned user ID 461 NSPs assign user IDs to their users. A user may have more 462 than one NSP-assigned user ID per a specific NSP. A user 463 sends an Access-Request to a NSP, the NSP-assigned user ID 464 may be indicated in the request so that the NSP can 465 identify the user. The NSP should not relay the NSP- 466 assigned user ID to the CP for security reasons. The NSP 467 may identify the multicast-access user by other methods 468 than the NSP-assigned userID, e.g. by the access port. 470 The actual mapping rules for NSP-assigned user IDs with CP- 471 user assigned IDs in account logs is a matter for the 472 providers and out of the scope of this framework. 474 4.3 Accounting 476 There are some accounting issues specific to multicasting. 477 An (S,G) should be recorded as a channel identifier. The 478 last hop device, such as an IGMP or MLD router or an IGMP 479 or MLD proxy, notifies the NSP's AAA function of the (S,G) 480 channel identifier. The NSP should notify the CP of the 481 (S,G) information in the accounting report messages. 483 A NSP records an accounting start corresponding to only the 484 first Join for a specific user-access session. A NSP should 485 not treat a "Join" response to a Query as the accounting 486 start. 488 A NSP records an accounting stop triggered by any of the 489 following: 1) a user requested Leave, 2) a timeout of a 490 multicast state or 3) a re-authentication failure. A NSP 491 may also record an accounting stop due to network 492 availability reasons such as failure. The NSP logs the 493 reason for each accounting stop. 495 Intermittent logs between the join and leave would allow 496 for finer diagnostics and therefore could serve useful in 497 billing discrepancies, and provide for a better estimation 498 of the time-span that content was multicasted, in the event 499 that users disconnect without sending leave messages. 501 There are two levels of accounting report messaging. 502 Messages in Accounting level 1 include a channel identifier, 503 a user identifier, and the accounting start and stop time 504 information. Accounting level 2 includes all information of 505 Level 1, plus traffic volume information. 507 QoS class is an optional item for each accounting level. 508 Whether to send, and at what interval to send intermittent 509 log information is optional for both levels. CP and NSPs 510 may also agree to include additional option information in 511 accounting messages of either level. 513 The level of account report messaging between the NSP and 514 CP may be either configured statically or can be 515 dynamically requested by the CP in its response to the 516 Access-Request relayed by the NSP to the CP. The 517 determination of the actual level of report messaging is 518 configured by the NSP at the NAS. 520 In case of very fast channel changes, the amount of items 521 logged by the NSP could become high. In order to reduce 522 the number of report messages sent to the CP, the NSP can 523 consolidate multiple sets of accounting information inside 524 a single accounting report message. [4] 526 4.4 Access Control and CP selection by NSP 528 When a NSP receives an access request from a user, the NSP 529 determines to which CP the request is to be directed. The 530 NSP may select a CP based on CP-assigned userID with CP 531 domain name or channel identifier (S,G). The user should 532 include in the request sufficient information for CP 533 selection. 535 4.5 Admission Control Information by NSP 537 After authorizing a user request, the NSP may have further 538 conditions for determining its admission control decision. 540 The NSP receives traffic parameters (such as QoS class, 541 required bandwidth, burst-size, etc.) of a multicast 542 channel. Such parameters serve as information to be 543 considered in the admission control decision. The traffic 544 parameters can be communicated as follows: 545 - A CP may notify a mapping between the channel 546 identifier (S,G) and traffic parameters in the Response 547 message when the CP authorizes an access request. Such 548 parameters may include required bandwidth, burst-size, QoS 549 class downgrade policy, etc. 550 - A user may indicate in the Request willingness to 551 accept QoS class downgrade to best-effort streaming. 552 - The NSP may maintain a mapping between channel 553 identifier (S,G) and traffic parameters in advance, for 554 example pre-configured by agreement between the CP and NSP 555 on a per channel basis. 557 The ultimate admission decision is made by the NSP based on 558 required traffic parameters of the requested, and available 559 resources. In a case that it cannot guarantee the required 560 network resources for the requested channel, streaming the 561 requested channel as best-effort traffic is optional. 562 The user may indicate in his/her Access Request whether 563 he/she will accept best-effort grade streaming if 564 guaranteed class is not available. The CP's preference for 565 accepting downgrading to best-effort streaming may be 566 either configured statically or can be dynamically 567 requested by the CP in its response to the Access-Request 568 relayed by the NSP to the CP. In the case that it cannot 569 offered a guaranteed QoS stream, the NSP may decide to 570 either to decline admission or to stream the requested 571 channel as best-effort traffic. The NSP should not stream 572 best-effort traffic if either the user or CP has indicated 573 against best-effort provision. 575 A NSP's admission control may manage integrated network 576 resources for unicast usage, such as VoIP or unicast 577 streaming, and multicast usage. Alternatively, it may 578 manage network resources separately for unicast and 579 multicast usage. In either ease, AAA and admission control 580 framework for multicast usage is independent of unicast 581 admission control. 583 Such QoS measurement and policy mechanisms themselves 584 depend on NSP policies and are out of the scope of this 585 memo. 587 4.6 Access Control and Distinguishing of Users by CP 589 The user ID and authentication information are forwarded 590 transparently by the NSP so that the CP can distinguish the 591 user, as well as authenticate and authorize the request. 593 4.7 AAA proxy in NSP 595 A NSP may act as AAA proxy of a CP based upon an agreement 596 between the NSP and the CP. The AAA proxy would store 597 information about permissions of a specific user to receive 598 multicast data from specified channel(s) up to specified 599 expiration date(s) and time(s). 601 If such proxying is implemented, the NSP may receive 602 authorization conditions from a CP in advance and 603 statically hold them, or a CP may send them dynamically in 604 the Response message. In either case, the user has 605 permission to receive multicast channel and therefore the 606 NSP starts the multicasting without querying the CP. 608 The CP may send unsolicited requests to the NSP to refresh 609 or change the permissions for a user for specific 610 channel(s). 612 When a user is receiving multicast content and the 613 permission is about to expire, the NSP may send a 614 notification to the user client that his session is about 615 to expire, and that he will need to reauthenticate. In such 616 a case, the user will have to send the Access-Request. In 617 the case that the user still has permission to the content, 618 they should be able to continue to receive the content 619 without interruption. 621 When re-authentication fails, the NSP should stop the 622 multicast channel and record accounting stop. 624 5. Network Connection Model and Functional Components 626 Section 3.1 introduces the high-level AAA framework for 627 multicasting. This section provides more detail on the 628 network connection model and constituent functional 629 components. 631 5.1 Basic Connection Model 633 In the simple case represented in Figure 1 the NSP is the 634 sole entity providing network resources including network 635 access to the User. First a user that requests content 636 sends an Access request to an NSP which then forwards it on 637 to the appropriate CP for Authentication and Authorization 638 purposes. The CP responds with either "success" or 639 "failure". If "success", the NSP may forward a success 640 response and stream multicast data to the user. 642 In this model the user selects the NSP to which to send its 643 content request. Based on this request the NSP selects an 644 appropriate CP to which it forwards the request. The CP 645 responds to the NSP's request: it may not respond to 646 another NSP in regards to the request. 648 In this model, as described in section 3.1, the 649 relationship between NSP and CP can be 1:1, 1:N or M:N. 650 Users may connect to multiple networks, and networks have 651 multiple users. 653 5.2 Constituent Logical Functional Components of the fully 654 enabled AAA Framework 656 Requirements for "fully AAA and QoS enabled" IP 657 multicasting networks were defined in MACCNT-REQ-draft. To 658 allow for levels of enablement, this memo defines two 659 models within the framework: "AAA enabled" multicasting and 660 "Fully enabled AAA" multicasting which means "AAA enabled" 661 with added admission control functions. 663 Section 3.1 introduces the high-level AAA framework for 664 multicasting. Below is a diagram of a AAA enabled 665 multicasting network with AAA, including the logical 666 components within the various entities. 668 AAA enabled framework (basic model) 669 +-------------------------------+ 670 | user | 671 |+- - - - - - - - - - - - - - -+| 672 || CPE || 673 || || 674 |+- - - - - | - - - - - - - - -+| 675 +-----------|-------------------+ 676 | 677 -------|------ IFa 678 | 679 +-----------|-------------------+ 680 | NSP | | 681 |+- - - - - |- -_+ | 682 ||TS | | | 683 | +------|-+ | 684 || | AN | | | 685 | | |---------+ | 686 || +------|-+ | | | 687 | | IFb | | 688 || +------|-+ | | +---------+| 689 | | |----|-|mAAA || 690 || | NAS | | | |(MACF *) || * optional 691 | +--------+ +---------+| 692 ||+- - - - - - - + | | 693 +-----------------------|--------+ 694 | 695 -------|------ IFc 696 | 697 +-----------------------|-------+ 698 | CP +---------+ | 699 | | CP-AAA | | 700 | +---------+ | 701 +-------------------------------+ 702 Figure 2 704 The user entity includes the CPE (Customer Premise 705 Equipment) which includes the user host(s) and optionally a 706 multicast proxy (not shown in the Figure 2.) 708 The NSP (Network Service Provider) in the basic model 709 includes the transport system and a logical element for 710 multicast AAA functionality. The transport system is 711 comprised of the access node and NAS (network access 712 server.) An AN may be connected directory to mAAA or a NAS 713 relays AAA information between an AN and a mAAA 714 Descriptions of AN and its interfaces are out of scope for 715 this memo. The multicast AAA function may be provided by a 716 multicast AAA server (mAAA) which may include the function 717 by which the access policy is downloaded to the NAS 718 (conditional access policy control function.) The interface 719 between mAAA and the NAS is labeled IFb in Figure 2. Over 720 IFb the NAS makes an access request to the NSP-mAAA and the 721 mAAA replies. The mAAA may push conditional access policy 722 to the NAS. 724 The content provider may have its own AAA server which has 725 the authority over access policy for its contents. 727 The interface between the user and the NSP is labeled IFa 728 in Figure 2. Over IFa the user makes a multicasting 729 request to the NSP. The NSP may in reply send multicast 730 traffic depending on the NSP and CP's policy decisions. 732 The interface between the NSP and CP is labeled IFc. Over 733 IFc the NSP requests to the CP-AAA for access to contents 734 and the CP replies. CP may also send conditional access 735 policy over this interface for AAA-proxying. 737 Fully enabled framework 738 +-------------------------------+ 739 | user | 740 |+- - - - - - - - - - - - - - -+| 741 || CPE || 742 || || 743 |+- - - - - | - - - - - - - - -+| 744 +-----------|-------------------+ 745 | 746 -------|------ IFa 747 | 748 +-----------|-----------------------+ 749 |+- - - - - |- - _+ + - - - - - + | 750 ||TS | | | | | | 751 | +------|-+ | +--------+ | 752 || | AN | | | | | MACF || | 753 | | | | | | | 754 || +------|-+ | | | +---|----+| | 755 | | | | | | 756 | | | | IFd----- | | 757 | | | IFb | | | 758 || +------|---+ | | | +---|----+| | 759 | | |---|---| mAAA | | 760 || | NAS | | | | |(MACF *)|| | * optional 761 | +----------+ | +--------+ | 762 ||+- - - - - - - -+ - - |- - - - -+ | 763 +-----------------------|-----------+ 764 | 765 -------|------ IFc 766 | 767 +-----------------------|-------+ 768 | CP +---------+ | 769 | | CP-AAA | | 770 | +---------+ | 771 +-------------------------------+ 772 Figure 3 774 In the fully enabled model the NSP also includes a 775 component that provides network resource management (e.g. 776 QoS management), as described in section 3.4, "Network 777 Resource Management by NSP". In the fully enabled model 778 (Figure 3) resource management and admission control is 779 provided by MACF (multicast admission control function.) 780 This means that Before replying to the user's multicast 781 request the mAAA queries the MACF for a network resource 782 access decision over the interface IFd. The MACF is 783 responsible for allocating network resources for multicast 784 traffic. So that MACF has the necessary network resource 785 availability information, NAS notifies MACF via mAAA of the 786 stopping of multicast traffic. 788 5.3 Modularity of the framework 790 In the interest of flexibility, this framework is modular 791 so that it is possible that partially enabled versions of 792 the models are supported. A AAA-enabled version provides 793 AAA functionality without Network Resource management. A 794 Network-Resource-Management-enabled (QoS-enabled) version 795 provides Network Resource management without AAA 796 functionality. Similarly, the possibility of one or more 797 layers of transit provision between an NSP and CP is in the 798 interest of modularity and extendibility. 800 6. IANA considerations 802 This memo does not raise any IANA consideration issues. 804 7. Security considerations 806 Refer to section 3.3. Also the user information related to 807 authentication with the CP must be protected in some way. 808 Otherwise, this memo does not raise any new security issues 809 which are not already addressed by the original protocols. 810 Enhancement of multicast access control capabilities should 811 enhance security performance. 813 8. Conclusion 815 This memo provides a generalized framework for solution 816 standards to meet the requirements. Further work should be 817 done to specify the interfaces between the user and NSP, 818 NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA 819 (presented in 5.2.) 821 Normative References 823 [1] Hayashi, et. al., "Requirements for Multicast AAA 824 coordinated between Content Provider(s) and Network 825 Service Provider(s)", draft-ietf-mboned-maccnt-req- 826 05.txt, September 2007, Work in Progress. 828 [2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener 829 Discovery Version 2 (MLDv2) for IPv6", June 2004. 831 [3] RFC-3376, Cain B., et.al., "Internet Group Management 832 Protocol, Version 3", October 2002. 834 [4] Ooghe, et. al, "Framework and Requirements for an 835 Access Node Control Mechanism in Broadband Multi- 836 Service Networks", draft-ietf-ancp-framework-05.txt, 837 February 2008, Work in Progress. 839 Authors' Addresses 841 Hiroaki Satou 842 NTT Network Service Systems Laboratories 843 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 844 Japan 845 Phone : +81 422 59 4683 846 Email : satou.hiroaki@lab.ntt.co.jp 848 Hiroshi Ohta 849 NTT Network Service Systems Laboratories 850 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 851 Japan 852 Phone : +81 422 59 3617 853 Email: ohta.hiroshi@lab.ntt.co.jp 855 Christian Jacquenet 856 France Telecom 857 3, avenue Francois Chateau 858 CS 36901, 35069 Rennes Cedex, France 859 Phone: +33 2 99 87 63 31 860 Email: christian.jacquenet@francetelecom.com 862 Tsunemasa Hayashi 863 NTT Network Innovation Laboratories 864 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 865 Japan 866 Phone: +81 46 859 8790 867 Email: tsunemasa@gmail.com 869 Haixiang He 870 Nortel 871 600 Technology Park Drive 872 Billerica, MA 01801, USA 873 Phone: +1 978 288 7482 874 Email: haixiang@nortel.com 876 Comments 877 Comments are solicited and should be addressed to the 878 mboned working group's mailing list at 879 mboned@lists.uoregon.edu_and/or the authors. 881 Full Copyright Statement 883 Copyright (C) The IETF Trust (2008). 885 This document is subject to the rights, licenses and 886 restrictions contained in BCP 78, and except as set forth 887 therein, the authors retain all their rights. 889 This document and the information contained herein are 890 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 891 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 892 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 893 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 894 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 895 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 896 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 897 A PARTICULAR PURPOSE. 899 Intellectual Property 901 The IETF takes no position regarding the validity or scope 902 of any Intellectual Property Rights or other rights that 903 might be claimed to pertain to the implementation or use 904 of the technology described in this document or the extent 905 to which any license under such rights might or might not 906 be available; nor does it represent that it has made any 907 independent effort to identify any such rights. 908 Information on the procedures with respect to rights in RFC 909 documents can be found in BCP 78 and BCP 79. 911 Copies of IPR disclosures made to the IETF Secretariat and 912 any assurances of licenses to be made available, or the 913 result of an attempt made to obtain a general license or 914 permission for the use of such proprietary rights by 915 implementers or users of this specification can be 916 obtained from the IETF on-line IPR repository at 917 http://www.ietf.org/ipr. 919 The IETF invites any interested party to bring to its 920 attention any copyrights, patents or patent applications, 921 or other proprietary rights that may cover technology that 922 may be required to implement this standard. Please 923 address the information to the IETF at ietf-ipr@ietf.org. 925 Expiration 927 This Internet-Draft will expire on August 22, 2008. 929 Acknowledgement 931 Funding for the RFC Editor function is currently provided 932 by the Internet Society.