idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-05.txt: -(368): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(695): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3979, Section 5, paragraph 1 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 886. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. INTRODUCTION 5' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA considerations' ) ** There are 362 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), 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 Copyright Line does not match the current year -- 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 (November 19, 2007) is 6001 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) -- Missing reference section? '1' on line 789 looks like a reference -- Missing reference section? '2' on line 794 looks like a reference -- Missing reference section? '3' on line 797 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA Framework for Multicasting November 3 2007 5 Hiroaki Satou, NTT 6 Internet Draft Hiroshi Ohta, NTT 7 Expires: May 17, Christian Jacquenet, France Telecom 8 2008 9 Tsunemasa Hayashi, NTT 10 Haixiang He, Nortel Networks 12 November 19, 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-Drafts. 31 Internet-Drafts are draft documents valid for a 32 maximum of six months and may be updated, replaced, 33 or obsoleted by other documents at any time. It is 34 inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed 39 at http://www.ietf.org/ietf/1id-abstracts.txt. 41 Internet Draft AAA Framework for Multicasting November 42 2007 44 The list of Internet-Draft Shadow Directories can be 45 accessed at http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on May 17, 2008. 49 Copyright Notice 51 Copyright (C) The IETF Trust (2007). This document 52 is subject to the rights, licenses and restrictions 53 contained in BCP 78, and except as set forth therein, 54 the authors retain all their rights. 56 Abstract 57 IP multicast-based services, such as TV broadcasting 58 or videoconferencing raise the issue of making sure 59 that potential customers are fully entitled to 60 access the corresponding contents. There is indeed a 61 need for service and content providers to identify 62 (if not authenticate, especially within the context 63 of enforcing electronic payment schemes) and to 64 invoice such customers in a reliable and efficient 65 manner. This memo describes the framework for 66 specifying the Authorization, Authentication and 67 Accounting (AAA) capabilities that could be 68 activated within the context of the deployment and 69 the operation of IP multicast-based services. This 70 framework addresses the requirements presented in 71 draft-ietf-mboned-maccnt-req-04.txt, "Requirements 72 for Accounting, Authentication and Authorization in 73 Well Managed IP Multicasting Services". The memo 74 provides a basic AAA enabled model as well as an 75 extended fully enabled model with resource and 76 admission control coordination. 78 STATUS OF THIS MEMO 1 79 COPYRIGHT NOTICE 2 80 ABSTRACT 2 81 1. INTRODUCTION 5 82 1.1 PURPOSE AND BACKGROUND 5 83 2. DEFINITIONS AND ABBREVIATIONS 6 84 2.1 DEFINITIONS 6 85 2.2 ABBREVIATIONS 7 86 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 87 4. FRAMEWORK AND ROLES OF ENTITIES 8 88 4.1 FRAMEWORK FOR MULTICAST AAA 8 89 4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 90 4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 10 91 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11 92 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 93 4.2 USER ID 11 94 4.2.1 CP-ASSIGNED USER ID 12 95 4.2.2 NSP-ASSIGNED USER ID 12 96 4.3 ACCOUNTING 12 97 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 98 4.5 ADMISSION CONTROL INFORMATION BY NSP 13 99 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 100 4.7 AAA PROXY IN NSP 14 101 5.1 BASIC CONNECTION MODEL 14 102 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY 103 ENABLED AAA FRAMEWORK 15 104 5.3 MODULARITY OF THE FRAMEWORK 19 105 6. IANA CONSIDERATIONS 19 106 7. SECURITY CONSIDERATIONS 19 107 8. CONCLUSION 19 108 NORMATIVE REFERENCES 19 109 AUTHORS' ADDRESSES 20 110 COMMENTS 20 111 FULL COPYRIGHT STATEMENT 21 112 COPYRIGHT (C) THE IETF TRUST (2007). 21 113 INTELLECTUAL PROPERTY 21 114 EXPIRATION 21 115 ACKNOWLEDGEMENT 22 116 1. Introduction 118 1.1 Purpose and Background 119 IP multicasting is designed to serve cases of group 120 communication schemes of any kind, such as 1-to-n (case of 121 TV broadcasting services for example) or n-to-p (case of 122 videoconferencing services, for example). 123 In these environments, IP multicast provides a better 124 resource optimization than using a unicast transmission 125 scheme, where data need to be replicated as many times as 126 there are receivers. Activation of IP multicast 127 capabilities in networks yields the establishment and the 128 maintenance of multicast distribution trees that are 129 receiver-initiated by nature: multicast-formatted data are 130 forwarded to receivers who explicitly request them. 132 IP multicast-based services, such as TV broadcasting 133 or videoconferencing raise the issue of making sure that 134 potential customers are fully entitled to access the 135 corresponding contents. 136 There is indeed a need for service and content providers to 137 identify (if not authenticate, especially within the 138 context of enforcing electronic payment schemes) and to 139 invoice such customers in a reliable and efficient manner. 140 Solutions should consider a wide range of possible content 141 delivery applications: content delivered over the multicast 142 network may include video, audio, images, games, software 143 and information such as financial data, etc. 145 This memo describes a framework for specifying the 146 Authorization, Authentication and Accounting (AAA) 147 capabilities that could be activated within the context of 148 the deployment and the operation of IP multicast-based 149 services. This memo also describes a framework to realize 150 high-quality multicast transport using a Resource and 151 Admission Control System (RACS) with multicast 152 Authorization. 153 Specifically, this framework addresses the requirements 154 presented in draft-ietf-mboned-maccnt-req-05.txt, 155 "Requirements for Multicast AAA coordinated between Content 156 Provider(s) and Network Service Provider(s)" MACCNT-REQ- 157 draft describes the requirements in CDN services using IP 158 multicast[1]. The requirements are derived from: 159 - need for user tracking and billing capabilities 160 - need for network access control to satisfy the 161 requirements of the Network Service Provider (NSP) and/or 162 content access control to satisfy the requirements of the 163 Content Provider (CP) 164 - methods for sharing information between the network 165 service provider and content provider to make it possible 166 to fulfill the above two requirements. 168 Detailed requirements are presented in MACCNT-REQ-draft. 169 These requirements include mechanisms for recording end- 170 user requests and provider responses for content-delivery, 171 sharing user information (possibly anonymously depending on 172 the trust model) between content provider and network 173 service provider, and protecting resources through the 174 prevention of network and content access by unauthorized 175 users, as well as other AAA related requirements. 177 The purpose of this memo is to provide a generalized 178 framework for 179 specifying multicast-inferred AAA capabilities that can 180 meet these requirements. This framework is to provide a 181 basis for future work of investigating the applicability of 182 existing AAA protocols to provide these AAA capabilities in 183 IP multicast specific context and/or if deemed necessary, 184 the refining or defining of protocols to provide these 185 capabilities. 187 2. Definitions and Abbreviations 189 2.1 Definitions 191 For the purpose of this memo the following definitions 192 apply: 194 Accounting: The set of capabilities that allow the 195 retrieval of a set of statistical data that can be defined 196 on a per customer and/or a per service basis, within the 197 context of the deployment of multicast-based services. Such 198 data are retrieved for billing purposes, and can be 199 retrieved on a regular basis or upon unsolicited requests. 200 Such data include (but are not necessarily limited to) the 201 volume of multicast-formatted data that have been forwarded 202 to the receiver over a given period of time, the volume of 203 multicast-formatted data that have been exchanged between a 204 receiver (or set of) and a given source over a given period 205 of time (e.g. the duration of a multicast session), etc. 207 Authentication: action for identifying a user as a genuine 208 one. 210 Authorization: The set of capabilities that need to be 211 activated to make sure a given requesting customer is (1) 212 what he claims to be (identification purposes), and (2) is 213 fully entitled to access a set of services (authentication 214 purposes). 216 Receiver: an end-host or end-client which receives content. 217 A receiver may be identified by a network ID such as MAC 218 address or IP address. 220 User: a human with a user account. A user may possibly use 221 multiple reception devices. Multiple users may use the 222 same reception device. 224 Note: The definition of a receiver (device) and a user 225 (human) should not be confused. 227 2.2 Abbreviations 229 For the purpose of this draft the following abbreviations 230 apply: 232 ACL: Access Control List 234 AN: Access Node 236 CAPCF: Conditional Access Policy Control Function 238 CDN: Content Delivery Network 240 CDS: Content Delivery Services 242 CP: Content Provider 244 CPE: Customer Premise Equipment 246 MACF: Multicast Admission Control Function 248 NSP: Network Service Provider 250 TS: Transport System 252 3. Common use models and network architecture implications 254 In some cases a single entity may design and be responsible 255 for a system that covers the various common high-level 256 requirements of a multicasting system such as 1) content 257 serving, 2) the infrastructure to multicast it, 3) network 258 and content access control mechanisms. In many cases 259 however the content provision and network provision roles 260 are divided between separate entities. The MACCNT-REQ- 261 draft provides more detail of the multiple versus single 262 entity CDS network models. 264 As such it should not be assumed that the entity 265 responsible for the multicasting structure and the entity 266 responsible for content serving are the same. Indeed 267 because the infrastructure for multicasting is expensive 268 and many content holders are not likely to be competent at 269 building and maintaining complicated infrastructures 270 necessary for multicasting, many content holders would 271 prefer to purchase transport and management services from a 272 network service provider and thus share the infrastructure 273 costs with other content holders. 275 Similarly network service providers in many cases do not 276 specialize in providing content and are unlikely to build 277 and maintain such a resource-intensive system without a 278 certain level of demand from content holders. 280 The use model of a single NSP providing multicasting 281 services to multiple CPs the following general requirements 282 from MACCNT-REQ-draft apply: 284 -Need for user tracking and billing capabilities 285 -Need for QoS control such as resource management and 286 admission control 287 -Need for conditional content access control 288 satisfactory to the requirements of the CP 289 -Methods for sharing information between the NSP and 290 CP to make the above two possible 292 When the NSP and CP are the same single entity the general 293 requirements are as follows. 295 -Need for user tracking and user-billing capabilities 296 -Need for access control and/or content protection at 297 level the entity deems appropriate 299 4. Framework and Roles of Entities4.1 Framework for multicast 300 AAA 302 A general high-level framework can be represented as 303 follows. 305 +------------------------------+ 306 | user | 307 | | 308 +------------------------------+ 309 | Access ^ Response 310 | Request | 311 V | 312 +------------------------------+ 313 | NSP | 314 | | 315 +------------------------------+ 316 | Access ^ Response 317 | Request | (Success) 318 v | 319 +------------------------------+ 320 | CP | 321 | | 322 +------------------------------+ 323 Figure 1 325 For the sake of simplicity, the above diagram portrays a 326 case where there is a single NSP entity and a single CP 327 entity, but multiple CPs can be connected to a single NSP 328 (e.g. NSP may provide connections to multiple CPs to 329 provide a wide selection of content categories.) It is also 330 possible for a single CP to be connected to multiple NSP 331 networks (e.g. network selection). Furthermore it is 332 possible that the NSP and CP could be the same entity. A 333 NSP and CP authenticate and authorize each other when they 334 establish connectivity. Below the general case of multiple 335 NSPs with multiple CPs is explained. Then, the various 336 combinations of single and multiple CPs and NSPs are 337 described in relation to the general case. 339 4.1.1 Multiple CPs are connected to multiple NSPs 341 The user subscribes to multiple NSPs and multiple CPs in 342 this usage case. The user selects a CP and a NSP when the 343 user requests content. The NSP may be automatically 344 selected by a user terminal: e.g. a fixed line NSP by a set 345 top box or a mobile NSP by a mobile phone. In some usage 346 cases it is possible that the NSP used by a certain user 347 will not always be the same. For example a user may have 348 contracted with more than one NSP: one for fixed line 349 access and another for mobile roaming access. 351 The content may be associated with (or managed by) a 352 specific CP. In this case, when the user selects content, 353 the CP is automatically selected. 355 The user should send an Access-Request to the selected NSP 356 with enough information not only for authentication by the 357 CP but also for CP selection and admission control by the 358 NSP. 360 When an NSP receives an Access-Request from a user, the NSP 361 selects the appropriate CP for the received Access-Request 362 and relays the content request. As the NSP is responsible 363 for managing its network resources, the NSP may perform 364 admission control.The NSP will allow access to the network 365 and contents conditional to both the CP's content 366 authorization result and the NSPs network availability. 367 That is, the NSP starts multicast flow only when it has 368 both 1) received an ��accept�� response from the CP and 2) 369 determined that the network resources (e.g. bandwidth) are 370 sufficient to serve the multicast channel. When neither of 371 these conditions are met, the NSP does not start the 372 requested multicast channel. When the NSP already knows 373 that network resources are insufficient or there is a 374 network failure, the NSP may choose to not relay the 375 Access-Request to the CP. The NSP is also responsible for 376 relaying the Response message from the CP to the user 377 whether the user is eligible to receive content (in 378 response to the corresponding Access-Request from the user 379 to the CP.) In cases that the NSP does not start multicast 380 because of its own network issues (e.g. lack of network 381 resources or network failure), the NSP notifies the user 382 with a reason for rejecting the request. 384 A CP receives an Access-Request relayed by the NSP. The CP 385 authenticates the NSP�s identity and makes an authorization 386 decision regarding the NSP�s eligibility to provide users 387 access to its contents. The CP is responsible for 388 Authentication and Authorization of users' access to 389 content that the CP manages. The CP hopes to collect 390 accounting information related to the access of their 391 content. The CP responds to the NSP regarding the relayed 392 Access-Request. When the CP cannot (e.g. error or 393 resource issues) or decides not (e.g. policy issues) to 394 deliver content, the CP is responsible for notifying the 395 NSP of the reason. It is up to the NSP how to relay or 396 translate the reasons for rejection to the user. 398 4.1.2 Multiple CPs are connected to a single NSP 400 The user subscribes to a single NSP which provides 401 multicasting of channels from multiple CPs in this usage 402 case. In this case the user does not select an NSP. The 403 user selects a CP when the user requests content. The 404 content may be associated with (or managed by) the specific 405 CP, when the user selects content, the CP is automatically 406 selected. 408 The user should send an Access-Request to the specific NSP 409 with enough information not only for authentication by the 410 CP but also for CP selection and admission control by the 411 NSP. 413 The role of the NSP is the same as that described in 4.1.1. 415 The role of a CP is the same as that described in 4.1.1. 417 4.1.3 A single CP is connected to multiple NSPs 419 A user subscribes to multiple NSPs but a single CP in this 420 usage case. A user selects the NSP when the user requests 421 content but the CP is fixed. The user should send an 422 Access-Request to the selected NSP with enough information 423 not only for authentication by the CP but also for 424 admission control by the NSP. 426 The role of the NSP is similar to the description in 4.1.1, 427 with the exception that when a NSP receives an Access- 428 Request from a user, NSP relays it to the CP without CP 429 selection. 431 The role of the CP is the same as that described in 4.1.1. 433 4.1.4 A single CP is connected to single NSP 435 In this case, a user subscribes to only one NSP and one 436 CP. The user does not select NSP and CP in this scenario. 437 The user should send an Access-Request to the NSP with 438 enough information not only for authentication by the CP 439 but also for admission control by the NSP. 441 The role for the NSP is the same as 4.1.3 442 The role of the CP is the same as the description in 4.1.1. 444 The NSP and CP could be the same entity. In this case, the 445 roles of the NSP and CP may be combined. 447 4.2 User ID 449 Users may hold multiple user IDs: IDs which have been 450 separately assigned for each subscription they may have for 451 various NSPs and CPs. The NSPs and CPs manage the user IDs 452 for their respective domains. A CP identifies a user by a 453 user ID assigned by CP itself. A NSP identifies a user by a 454 user ID assigned by NSP itself. The user IDs are only 455 meaningful in the context of each domain. Users may hold 456 multiple user IDs which have been separately assigned for 457 each subscription they may have for various NSPs and CPs. 459 4.2.1 CP-assigned user ID 461 CPs assign user IDs to their users. The user may have more 462 than one CP-assigned user ID per a specific CP. A user 463 sends an Access-Request to a NSP, the CP-assigned user ID 464 should be indicated so that the CP can identify the user 465 requesting content access. A NSP should relay the CP- 466 assigned user ID from the user to the CP. A NSP should not 467 send a CP-assigned user ID to any CP except the one which 468 assigned it and should not relay it all if there is no 469 appropriate CP that assigned the user ID. 471 4.2.2 NSP-assigned user ID 473 NSPs assign user IDs to their users. A user may have more 474 than one NSP-assigned user ID per a specific NSP. A user 475 sends an Access-Request to a NSP, the NSP-assigned user ID 476 may be indicated in it so that the NSP can identify the 477 user. The NSP should not relay the NSP-assigned user ID to 478 the CP for security reasons. The NSP may identify the 479 multicast-access user by other methods than the NSP- 480 assigned userID, e.g. by the access port. 482 The actual mapping rules for NSP-assigned user IDs with CP- 483 user assigned IDs in account logs is a matter for the 484 providers and out of the scope of this framework. 486 4.3 Accounting 488 There are some specific accounting issues for multicasting. 489 A (S,G) should be recorded as a channel identifier. The 490 last hop devices, such as a IGMP or MLD router and a IGMP 491 or MLD proxy, notify a (S,G) to AAA function in the NSP. 492 The (S,G) information should be notified to the CP as part 493 of the accounting log. 495 A NSP records accounting start corresponding to only the 496 first Join for a specific user access session. A NSP should 497 not treat a Query-responded Join as the accounting start. 499 A NSP records accounting stop triggered by not only user 500 requested Leave but also timeout of a multicast state or 501 re-authentication failure. A NSP may also record an 502 accounting stop due to network availability reasons such as 503 failure. The NSP logs the reason for each accounting stop. 505 Also, intermittent logs between the join and leave would 506 allow for finer diagnostics and therefore could serve 507 useful in billing discrepancies, and provide for a finer 508 estimation of the time spent for delivering the content in 509 the event that users disconnect without sending leave 510 messages. 512 4.4 Access Control and CP selection by NSP 514 When a NSP receives an access request from a user, the NSP 515 determines to which CP the request is to be directed. The 516 NSP may select a CP based on CP-assigned userID with CP 517 domain name or channel identifier (S,G). The user should 518 include in the request sufficient information for CP 519 selection. 521 4.5 Admission Control Information by NSP 523 After authorizing a user request, the NSP may have further 524 conditions for determining its admission control decision. 526 The NSP needs to know traffic parameters of a multicast 527 channel for admission control. The traffic parameter 528 information may be either indicated by the user or CP 529 within the access request and responses, or otherwise 530 shared between the NSP and CP outside the access-request 531 message mechanism: 532 - A user may declare traffic parameters for each 533 Access-Request. 534 - A CP may notify a mapping between the channel 535 identifier (S,G) and traffic parameters in the Response 536 message when the CP authorizes an access request. 537 - The NSP may maintain a mapping between channel 538 identifier (S,G) and traffic parameters in advance, for 539 example pre-configured by agreement between the CP and NSP 540 on a per channel basis. 542 A NSPs admission control may manage integrated network 543 resources for unicast usage, such as VoIP or unicast 544 streaming, and multicast usage. Alternatively, it may 545 manage network resources separately for unicast and 546 multicast usage. In either case, AAA and admission control 547 framework for multicast usage is independent of unicast 548 admission control. 550 Such QoS measurement and policy mechanisms themselves 551 depend on NSP policies and are out of the scope of this 552 memo. 554 4.6 Access Control and Distinguishing of Users by CP 556 The user ID and authentication information are forwarded 557 transparently by the NSP so that the CP can distinguish the 558 user, as well as authenticate and authorize the request. 560 4.7 AAA proxy in NSP 562 A NSP may act as AAA proxy of a CP based upon an agreement 563 between the NSP and the CP. The AAA proxy would store 564 information about permissions of a specific user to receive 565 multicast data from specified channel(s) up to specified 566 expiration date(s) and time(s). 567 If such proxying is implemented, the NSP may receive 568 authorization conditions from a CP in advance and 569 statically hold them, or a CP may send them dynamically in 570 the Response message. The user has permission to receive 571 multicast channel at that time. The NSP starts the 572 multicasting without querying the CP. 574 The CP may send unsolicited requests to the NSP to refresh 575 or change the permissions for a user for specific 576 channel(s). 578 When a user is receiving multicast content and the 579 permission is about to expire, the NSP may send a 580 notification to the user client that his session is about 581 to expire, and that he will need to reauthenticate. In such 582 a case, the user will have to send the Access-Request. In 583 the case that the user still has permission to the content, 584 they should be able to continue to receive the content 585 without interruption. 586 When re-authentication fails, the NSP should stop the 587 multicast channel and record accounting stop. 589 5. Network Connection Model and Functional Components 591 Section 3.1 introduces the high-level AAA framework for 592 multicasting. This section provides more details on the 593 network connection model and constituent functional 594 components. 596 5.1 Basic Connection Model 598 In the simple case represented in Figure 1 the NSP is the 599 sole entity providing network resources including network 600 access to the User. First a user that requests content 601 sends an Access request to an NSP which then forwards it on 602 to the appropriate CP for Authentication and Authorization 603 purposes. The CP responds with either "success" or 604 "failure". If "success", the NSP may forward a success 605 response and stream multicast data to the user. 607 In this model the user selects the NSP to which to send its 608 content request. Based on this request the NSP selects an 609 appropriate CP to which it forwards the request. The CP 610 responds to the NSP's request: it may not respond to 611 another NSP in regards to the request. 613 In this model, as described in section 3.1, the 614 relationship between NSP and CP can be 1:1, 1:N or M:N. 615 Users may connect to multiple networks, and networks have 616 multiple users. 618 5.2 Constituent Logical Functional Components of the fully 619 enabled AAA Framework 621 Requirements for "fully AAA and QoS enabled" IP 622 multicasting networks were defined in MACCNT-REQ-draft. To 623 allow for levels of enablement, this memo defines two 624 models within the framework: "AAA enabled" multicasting and 625 "Fully enabled AAA" multicasting which means "AAA enabled" 626 with added admission control functions. 628 Section 3.1 introduces the high-level AAA framework for 629 multicasting. Below is a diagram of a AAA enabled 630 multicasting network with AAA, including the logical 631 components within the various entities. 633 AAA enabled framework (basic model) 634 +-------------------------------+ 635 | user | 636 |+- - - - - - - - - - - - - - -+| 637 || CPE || 638 || || 639 |+- - - - - | - - - - - - - - -+| 640 +-----------|-------------------+ 641 | 642 -------|------ IFa 643 | 644 +-----------|-------------------+ 645 | NSP | | 646 |+- - - - - |- -_+ | 647 ||TS | | | 648 | +------|-+ | 649 || | AN | | | 650 | | | | 651 || +------|-+ | | 652 | | IFb | 653 || +------|-+ | | +---------+| 654 | | |----|-|mAAA || 655 || | NAS | | | |(MACF *) || * optional 656 | +--------+ +---------+| 657 ||+- - - - - - - + | | 658 +-----------------------|--------+ 659 | 660 -------|------ IFc 661 | 662 +-----------------------|-------+ 663 | CP +---------+ | 664 | | CP-AAA | | 665 | +---------+ | 666 +-------------------------------+ 667 Figure 2 669 The user entity includes the CPE (Customer Premise 670 Equipment) which includes the user host(s) and optionally a 671 multicast proxy (not shown in the Figure 2.) 673 The NSP (Network Service Provider) in the basic model 674 includes the transport system and a logical element for 675 multicast AAA functionality. The transport system is 676 comprised of the access node and NAS (network access 677 server) An AN may be connected directly to mAAA or a NAS 678 relays AAA information between an AN and a mAAA 679 Descriptions of AN and its interfaces are out of scope for 680 this memo. The multicast AAA function may be provided by a 681 multicast AAA server (mAAA) which may include the function 682 by which the access policy is downloaded to the NAS 683 (Multicast access control function.) The interface between 684 mAAA and the NAS is labeled IFb in Figure 2. Over IFb the 685 NAS makes an access request to the NSP-mAAA and the mAAA 686 replies. The mAAA may push conditional access policy to the 687 NAS. 689 The content provider may have its own AAA server which has 690 the authority over access policy for its contents. 692 The interface between the user and the NSP is labeled IFa 693 in Figure 2. Over IFa the user makes a multicasting 694 request to the NSP. The NSP may in reply send multicast 695 traffic depending on the NSP and CP�s policy decisions. 697 The interface between the NSP and CP is labeled IFc. Over 698 IFc the NSP requests to the CP-AAA for access to contents 699 and the CP replies. CP may also send conditional access 700 policy over this interface within the context of proxying 701 multicast AAA messagescaching. 703 Fully enabled framework 704 +-------------------------------+ 705 | user | 706 |+- - - - - - - - - - - - - - -+| 707 || CPE || 708 || || 709 |+- - - - - | - - - - - - - - -+| 710 +-----------|-------------------+ 711 | 712 -------|------ IFa 713 | 714 +-----------|-----------------------+ 715 |+- - - - - |- - _+ + - - - - - + | 716 ||TS | | | | | | 717 | +------|-+ | +--------+ | 718 || | AN | | | | | MACF || | 719 | | | | | | | 720 || +------|-+ | | | +---|----+| | 721 | | | | | | 722 | | | | IFd----- | | 723 | | | IFb | | | 724 || +------|---+ | | | +---|----+| | 725 | | |---|---| mAAA | | 726 || | NAS | | | | |(MACF *)|| | * optional 727 | +----------+ | +--------+ | 728 ||+- - - - - - - -+ - - |- - - - -+ | 729 +-----------------------|-----------+ 730 | 731 -------|------ IFc 732 | 733 +-----------------------|-------+ 734 | CP +---------+ | 735 | | CP-AAA | | 736 | +---------+ | 737 +-------------------------------+ 738 Figure 3 740 In the fully enabled model the NSP also includes a 741 component that provides network resource management (e.g. 742 QoS management), as described in section 3.4, "Network 743 Resource Management by NSP". In the fully enabled model 744 (Figure 3) resource management and admission control is 745 provided by MACF (multicast admission control function). 746 Before replying to the user's multicast request the mAAA 747 queries the MACF for a network resource access decision 748 over the interface IFd. The MACF is responsible for 749 allocating network resources for multicast traffic. To 750 provide MACF with the relevant network resource 751 availability information, NAS notifies MACF via mAAA that 752 sending multicast traffic has ceased. 754 5.3 Modularity of the framework 756 In the interest of flexibility, this framework is modular 757 so that it is possible that partially enabled versions of 758 the models are supported. An AAA-enabled version provides 759 AAA functionality without Network Resource management. A 760 Network-Resource-Management-enabled (QoS-enabled) version 761 provides Network Resource management without AAA 762 functionality. Similarly, the possibility of one or more 763 layers of transit provision between an NSP and CP is in the 764 interest of modularity and extendibility. 766 6. IANA considerations 768 This memo does not raise any IANA consideration issues. 770 7. Security considerations 772 Refer to section 3.3. Also the user information related to 773 authentication with the CP must be protected in some way. 774 Otherwise, this memo does not raise any new security issues 775 which are not already addressed by the original protocols. 776 Enhancement of multicast access control capabilities should 777 enhance security performance. 779 8. Conclusion 781 This memo provides a generalized framework for solution 782 standards to meet the requirements. Further work should be 783 done to specify the interfaces between the user and NSP, 784 NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA 785 (presented in 5.2.) 787 Normative References 789 [1] Hayashi, et. al., Requirements for Multicast AAA 790 coordinated between Content Provider(s) and Network 791 Service Provider(s)", draft-ietf-mboned-maccnt-req- 792 05.txt, September 2007, Work in Progress. 794 [2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener 795 Discovery Version 2 (MLDv2) for IPv6", June 2004. 797 [3] RFC-3376, Cain B., et.al., "Internet Group Management 798 Protocol, Version 3", October 2002. 800 Authors' Addresses 802 Hiroaki Satou 803 NTT Network Service Systems Laboratories 804 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 805 Japan 806 Phone : +81 422 59 4683 807 Email : satou.hiroaki@lab.ntt.co.jp 809 Hiroshi Ohta 810 NTT Network Service Systems Laboratories 811 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 812 Japan 813 Phone : +81 422 59 3617 814 Email: ohta.hiroshi@lab.ntt.co.jp 816 Christian Jacquenet 817 France Telecom R&D 818 4, rue du Clos Courtel - 819 - BP 91226 820 35512 Cesson-S�vign�ECedex, France 821 Phone: +33 2 99 12 49 40 822 Email: christian.jacquenet@orange-ftgroup.com 824 Tsunemasa Hayashi 825 NTT Network Innovation Laboratories 826 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 827 Japan 828 Phone: +81 46 859 8790 829 Email: tsunemasa@gmail.com 831 Haixiang He 832 Nortel 833 600 Technology Park Drive 834 Billerica, MA 01801, USA 835 Phone: +1 978 288 7482 836 Email: haixiang@nortel.com 838 Comments 840 Comments are solicited and should be addressed to the 841 mboned working group's mailing list at 842 mboned@lists.uoregon.edu_and/or the authors. 844 Full Copyright Statement 846 Copyright (C) The IETF Trust (2007). 848 This document is subject to the rights, licenses and 849 restrictions contained in BCP 78, and except as set forth 850 therein, the authors retain all their rights. 852 "This document and the information contained herein are 853 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 854 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 855 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 856 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 857 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 858 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 859 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 860 A PARTICULAR PURPOSE.". 862 Intellectual Property 864 The IETF takes no position regarding the validity or scope 865 of any Intellectual Property Rights or other rights that 866 might be claimed to pertain to the implementation or use 867 of the technology described in this document or the extent 868 to which any license under such rights might or might not 869 be available; nor does it represent that it has made any 870 independent effort to identify any such rights. 871 Information on the procedures with respect to rights in RFC 872 documents can be found in BCP 78 and BCP 79. 874 Copies of IPR disclosures made to the IETF Secretariat and 875 any assurances of licenses to be made available, or the 876 result of an attempt made to obtain a general license or 877 permission for the use of such proprietary rights by 878 implementers or users of this specification can be 879 obtained from the IETF on-line IPR repository at 880 http://www.ietf.org/ipr. 882 The IETF invites any interested party to bring to its 883 attention any copyrights, patents or patent applications, 884 or other proprietary rights that may cover technology that 885 may be required to implement this standard. Please 886 address the information to the IETF at ietf-ipr@ietf.org. 888 Expiration 890 This Internet-Draft will expire on May 17, 2008. 892 Acknowledgement 894 Funding for the RFC Editor function is currently provided 895 by the Internet Society.