Internet Draft AAA Framework for Multicasting November 2007 Hiroaki Satou, NTT Internet Draft Hiroshi Ohta, NTT Expires:
Jan 10, 2008May 17, Christian Jacquenet, France Telecom Intended status: Informational2008 Tsunemasa Hayashi, NTT Haixiang He, Nortel Networks July 9,November 19, 2007 AAA Framework for Multicasting <draft-ietf-mboned-multiaaa-framework-04.txt><draft-ietf-mboned-multiaaa-framework-05.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. Internet Draft AAA Framework for Multicasting November 2007 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10,May 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Abstract IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify (if not authenticate, especially within the context of enforcing electronic payment schemes) and to invoice such customers in a reliable and efficient manner. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in draft-ietf-mboned- maccnt-req-04.txt,draft-ietf-mboned-maccnt-req-04.txt, "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services". The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. STATUS OF THIS MEMO 1 COPYRIGHT NOTICE 2 ABSTRACT 2 1. INTRODUCTION 5 1.1 PURPOSE AND BACKGROUND 5 2. DEFINITIONS AND ABBREVIATIONS 6 2.1 DEFINITIONS 6 2.2 ABBREVIATIONS 7 3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7 4. FRAMEWORK AND ROLES OF ENTITIES 8 4.1 FRAMEWORK FOR MULTICAST AAA 8 4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9 4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 10 4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11 4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11 4.2 USER ID 11 4.2.1 CP-ASSIGNED USER ID 12 4.2.2 NSP-ASSIGNED USER ID 12 4.3 ACCOUNTING 12 4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13 4.5 ADMISSION CONTROL INFORMATION BY NSP 13 4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14 4.7 AAA PROXY IN NSP 14 5.1 BASIC CONNECTION MODEL 14 5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY ENABLED AAA FRAMEWORK 15 5.3 MODULARITY OF THE FRAMEWORK 19 6. IANA CONSIDERATIONS 19 7. SECURITY CONSIDERATIONS 19 8. CONCLUSION 19 NORMATIVE REFERENCES 19 AUTHORS' ADDRESSES 20 COMMENTS 20 FULL COPYRIGHT STATEMENT 21 COPYRIGHT (C) THE IETF TRUST (2007). 21 INTELLECTUAL PROPERTY 21 EXPIRATION 21 ACKNOWLEDGEMENT 22 1. Introduction 1.1 Purpose and Background IP multicasting is designed to serve cases of group communication schemes of any kind, such as 1-to-n (case of TV broadcasting services for example) or n-to-p (case of videoconferencing services, for example). In these environments, IP multicast provides a better resource optimization than using a unicast transmission scheme, where data need to be replicated as many times as there are receivers. Activation of IP multicast capabilities in networks yields the establishment and the maintenance of multicast distribution trees that are receiver-initiated by nature: multicast-formatted data are forwarded to receivers who explicitly request them. IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify (if not authenticate, especially within the context of enforcing electronic payment schemes) and to invoice such customers in a reliable and efficient manner. Solutions should consider a wide range of possible content delivery applications: content delivered over the multicast network may include video, audio, images, games, software and information such as financial data, etc. This memo describes a framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This memo also describes a framework to realize high-quality multicast transport using a Resource and Admission Control System (RACS) with multicast Authorization. Specifically, this framework addresses the requirements presented in draft-ietf-mboned-maccnt-req-04.txt,draft-ietf-mboned-maccnt-req-05.txt, "Requirements for Accounting, AuthenticationMulticast AAA coordinated between Content Provider(s) and Authorization in Well Managed IP Multicasting Services" MACCNT-REQ-draftNetwork Service Provider(s)" MACCNT-REQ- draft describes the requirements in CDN services using IP multicast. The requirements are derived from: - need for user tracking and billing capabilities - need for network access control to satisfy the requirements of the Network Service Provider (NSP) and/or content access control to satisfy the requirements of the Content Provider (CP) - methods for sharing information between the network service provider and content provider to make it possible to fulfill the above two requirements. Detailed requirements are presented in MACCNT-REQ-draft. These requirements include mechanisms for recording end- user requests and provider responses for content-delivery, sharing user information (possibly anonymously depending on the trust model) between content provider and network service provider, and protecting resources through the prevention of network and content access by unauthorized users, as well as other AAA related requirements. The purpose of this memo is to provide a generalized framework for specifying multicast-inferred AAA capabilities that can meet these requirements. This framework is to provide a basis for future work of investigating the applicability of existing AAA protocols to provide these AAA capabilities in IP multicast specific context and/or if deemed necessary, the refining or defining of protocols to provide these capabilities. 2. Definitions and Abbreviations 2.1 Definitions For the purpose of this memo the following definitions apply: Accounting: The set of capabilities that allow the retrieval of a set of statistical data that can be defined on a per customer and/or a per service basis, within the context of the deployment of multicast-based services. Such data are retrieved for billing purposes, and can be retrieved on a regular basis or upon unsolicited requests. Such data include (but are not necessarily limited to) the volume of multicast-formatted data that have been forwarded to the receiver over a given period of time, the volume of multicast-formatted data that have been exchanged between a receiver (or set of) and a given source over a given period of time (e.g. the duration of a multicast session), etc. Authentication: action for identifying a user as a genuine one. Authorization: The set of capabilities that need to be activated to make sure a given requesting customer is (1) what he claims to be (identification purposes), and (2) is fully entitled to access a set of services (authentication purposes). Receiver: an end-host or end-client which receives content. A receiver may be identified by a network ID such as MAC address or IP address. User: a human with a user account. A user may possibly use multiple reception devices. Multiple users may use the same reception device. Note: The definition of a receiver (device) and a user (human) should not be confused. 2.2 Abbreviations For the purpose of this draft the following abbreviations apply: ACL: Access Control List AN: Access Node CAPCF: Conditional Access Policy Control Function CDN: Content Delivery Network CDS: Content Delivery Services CP: Content Provider CPE: Customer Premise Equipment mRACF:MACF: Multicast Resource andAdmission Control Function NSP: Network Service Provider TS: Transport System 3. Common use models and network architecture implications In some cases a single entity may design and be responsible for a system that covers the various common high-level requirements of a multicasting system such as 1) content serving, 2) the infrastructure to multicast it, 3) network and content access control mechanisms. In many cases however the content provision and network provision roles are divided between separate entities. The MACCNT-REQ- draft provides more detail of the multiple versus single entity CDS network models. As such it should not be assumed that the entity responsible for the multicasting structure and the entity responsible for content serving are the same. Indeed because the infrastructure for multicasting is expensive and many content holders are not likely to be competent at building and maintaining complicated infrastructures necessary for multicasting, many content holders would prefer to purchase transport and management services from a network service provider and thus share the infrastructure costs with other content holders. Similarly network service providers in many cases do not specialize in providing content and are unlikely to build and maintain such a resource-intensive system without a certain level of demand from content holders. The use model of a single NSP providing multicasting services to multiple CPs the following general requirements from MACCNT-REQ-draft apply: -Need for user tracking and billing capabilities -Need for QoS control such as resource management and admission control -Need for conditional content access control satisfactory to the requirements of the CP -Methods for sharing information between the NSP and CP to make the above two possible When the NSP and CP are the same single entity the general requirements are as follows. -Need for user tracking and user-billing capabilities -Need for access control and/or content protection at level the entity deems appropriate 4. Framework and Roles of Entities 4.1Entities4.1 Framework for multicast AAA A general high-level framework can be represented as follows. +------------------------------+ | user | | | +------------------------------+ | Access ^ Response | Request | & Multicast DataV | +------------------------------+ | NSP | | | +------------------------------+ | Access ^ Response | Request | (Success) v | +------------------------------+ | CP | | | +------------------------------+ Figure 1 For the sake of simplicity, the above diagram portrays a case where there is a single NSP entity and a single CP entity, but multiple CPs can be connected to the same NSP.a single NSP (e.g. NSP may provide connections to multiple CPs to provide a wide selection of content categories.) It is also possible for the samea single CP to be connected to multiple NSP networks (e.g. network selection). In other words the relationship of NSP:CP can be described as 1:1, 1:N or M:N.Furthermore it is possible that the NSP and CP could be the same entity. DescriptionA NSP and CP authenticate and authorize each other when they establish connectivity. Below the general case of multiple NSPs with multiple CPs is explained. Then, the various combinations of Roles:single and multiple CPs and NSPs are described in relation to the general case. 4.1.1 Multiple CPs are connected to multiple NSPs The user subscribes to multiple NSPs and multiple CPs in this usage case. The user (or the user's device)selects a CP and a NSP when the user requests content. The NSP may be automatically selected by a user terminal: e.g. a fixed line NSP for STBby a set top box or a mobile NSP forby a mobile phone. In some usage cases it is possible that the NSP used by thea certain user terminalwill not always be the same. For example a user may have contracted with different NSPsmore than one NSP: one for fixed line oraccess and another for mobile roaming access. The CP is responsible for Authentication and Authorization of users' access tocontent thatmay be associated with (or managed by) a specific CP. In this case, when the user selects content, the CP manages.is automatically selected. The CP hopesuser should send an Access-Request to collect accounting information related to the access of their content. The CP may choose to authenticate and authorize NSPs which are eligible to provide users access to its contents. Whenthe CP cannot (e.g. error or resource issues) or decidesselected NSP with enough information not (e.g. policy issues) to deliver content,only for authentication by the CP is responsiblebut also for notifyingCP selection and admission control by the NSP. When an NSP receives an Access-Request from a user, the NSP ofselects the reason. It is up toappropriate CP for the NSP how to relay or translatereceived Access-Request and relays the messages tocontent request. As the user. TheNSP is responsible for managing its network resources. Theresources, the NSP may perform admission control. It is also responsible for relaying the AAA messages from the CP whether the user is eligible to receive content (authentication by proxy), and the NSP's relevant AAA servercontrol.The NSP will allow access to the network and contents conditional to both the CP AAA server'sCP's content authorization result and the NSPs network utilization authorization result. In certain casesavailability. That is, the NSP starts multicast flow only when it has both 1) received an ĎĎacceptíí response from the CP and NSP may have a contractual relationship in which2) determined that the NSP is authorizednetwork resources (e.g. bandwidth) are sufficient to make the content authorization decision based on mutually predetermined criteria: in such cases the NSP- AAA may also make the content authorization decision without queryingserve the CP-AAA.multicast channel. When neither of these conditions are met, the NSP cannot or decidesdoes not tostart the requested multicast to users,channel. When the NSP may notify the users of the reason. It is recommendedalready knows that the NSP notify eligible users of the reason for not multicasting content when it is duenetwork resources are insufficient or content unavailability, for example. Thethere is a network failure, the NSP may choose to not relay the Access-Request to notify ineligible users ofthe reasonCP. The NSP is also responsible for any case. 4.2 Multiple User IDs Users may hold multiple user IDs: IDs which have been separately assigned for each subscription they may have for various NSPs and CPs. The NSPs and CPs controlrelaying the user IDs for their respective domains. The user IDs are only meaningful inResponse message from the context of each domain. WhenCP to the user wants to access content,whether the user registersis eligible to receive content (in response to the corresponding Access-Request from the user ID (includingto the CP.) In cases that the NSP does not start multicast because of its CP domain information)own network issues (e.g. lack of network resources or network failure), the NSP notifies the user with a requestreason for content, etc: web authentication is one possible method. Eachrejecting the request. A CP may identify usersreceives an Access-Request relayed by the user IDs that it has issued to them. Terminal portability can be realized if the NSPNSP. The CP authenticates a user using a NSP-assigned user ID. A NSP- assigned user ID isthe NSPís identity and makes an access-line independent unique ID assignedauthorization decision regarding the NSPís eligibility to provide users which allows user identification from anyaccess point within the networkto its contents. The CP is responsible for Authentication and possibly roamingAuthorization of users' access to other networks. This allowscontent that the userCP manages. The CP hopes to collect accounting information related to accessthe content from various networkaccess points.of their content. The CP responds to the NSP andregarding the relayed Access-Request. When the CP docannot (e.g. error or resource issues) or decides not need(e.g. policy issues) to knowdeliver content, the corresponding user idCP is responsible for notifying the same user inNSP of the other provider's domain, and it is not necessary that there is a one to one relationship.reason. It is quite possible for one personup to hold multiple user idsthe NSP how to relay or translate the reasons for rejection to the same provider. The actual mapping rules for NSPs anduser. 4.1.2 Multiple CPs are connected to mapa single NSP The user IDs with the IDs in other provider domains issubscribes to a matter forsingle NSP which provides multicasting of channels from multiple CPs in this usage case. In this case the providers. A solution should provideuser does not select an API between the providers to flexibly support various mapping methods. 4.3 Accounting MACCNT-REQ-draft defines requirements for Accounting and Billing. These include the requirement for the NSP to logNSP. The user behavior such asselects a CP when the join action anduser requests content. The content may be associated with (or managed by) the leave action, as well asspecific CP, when the result ofuser selects content, the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies that thereCP is automatically selected. The user should be a standardized waysend an Access-Request to sharingthe specific NSP with enough information not only for authentication by the CP the user behaviorbut also for CP selection and content reception information whichadmission control by the NSP. The role of the NSP is logging.(MACCNT-REQ-draft, 4.5.1) Standardizationthe same as that described in 4.1.1. The role of a CP is the logs or messages to share content usage informationsame as that described in 4.1.1. 4.1.3 A single CP is importantconnected to support a single NSP sharing accounting information withmultiple CPs orNSPs A user subscribes to multiple NSPs but a single CP receiving from multiple NSPs. In order to provide the granularity of user-behavior and actual content reception information as specifiedin MACCNT-REQ-draft,this usage case. A user selects the NSP should not manage multicast states on a subnet basis,when the user requests content but on athe CP is fixed. The user basis (see in MACCNT-REQ-draft, 4.1 "User identification") becauseshould send an Access-Request to the selected NSP needs to be able to notifywith enough information not only for authentication by the CP of a user's start and stop timesbut also for accounting purposes. This means thatadmission control by the NSP. The role of the NSP sendsis similar to the CP AAAdescription in 4.1.1, with the exception that when a NSP receives an indication for Join and Leave onAccess- Request from a user basis. User-based multicast state management is equivalentuser, NSP relays it to explicit membership trackingthe CP without CP selection. The role of the CP is the same as that described in RFC33764.1.1. 4.1.4 A single CP is connected to single NSP In this case, a user subscribes to only one NSP and per-host trackingone CP. The user does not select NSP and CP in RFC3810. This framework specifiesthis scenario. The user should send an accounting API provided byAccess-Request to the NSP and accessedwith enough information not only for authentication by the CP to allowbut also for sharing user- behavioradmission control by the NSP. The role for the NSP is the same as 4.1.3 The role of the CP is the same as the description in 4.1.1. The NSP and content-reception information betweenCP could be the same entity. In this case, the roles of the NSP AAAand CP AAA. This accounting API shouldmay be configurable to allowcombined. 4.2 User ID Users may hold multiple user IDs: IDs which have been separately assigned for each subscription they may have for various NSPs and CPs. The NSPs and CPs manage the user IDs for their respective domains. A CP to requestidentifies a user by a user ID assigned by CP itself. A NSP identifies a user by a user ID assigned by NSP itself. The user IDs are only meaningful in the logging information it actually requires. Such an API would allowcontext of each domain. Users may hold multiple user IDs which have been separately assigned for realtime accounting information sharing byeach subscription they may have for various NSPs and CPs. 4.2.1 CP-assigned user ID CPs assign user IDs to their users. The user may have more than one CP-assigned user ID per a specific CP. A user sends an Access-Request to a NSP, the CP-assigned user ID should be indicated so that the CP can identify the user requesting content access. A NSP should relay the CP- assigned user ID from the user to the CP. When logging information is shared throughA NSP should not send a CP-assigned user ID to any CP except the accounting API,one which assigned it and should not relay it all if there is importantno appropriate CP that assigned the CPuser ID. 4.2.2 NSP-assigned user ID NSPs assign user IDs to their users. A user may have more than one NSP-assigned user ID per a specific NSP. A user sends an Access-Request to a NSP, the NSP-assigned user ID may be ableindicated in it so that the NSP can identify the user. The NSP should not relay the NSP-assigned user ID to matchthe CP for security reasons. The NSP may identify the multicast-access user by other methods than the NSP- assigned userID, e.g. by the access port. The actual mapping rules for NSP-assigned user IDs with CP- user assigned IDs in account logs is a matter for the providers and out of the scope of this framework. 4.3 Accounting There are some specific accounting issues for multicasting. A (S,G) should be recorded as describeda channel identifier. The last hop devices, such as a IGMP or MLD router and a IGMP or MLD proxy, notify a (S,G) to AAA function in the database operated byNSP. The (S,G) information should be notified to the CP as part of the accounting log. A NSP records accounting start corresponding to only the first Join for a specific user access session. A NSP should not treat a Query-responded Join as described in the database operated bythe CP. Theaccounting start. A NSP requires the capability to log bothrecords accounting stop triggered by not only user and host information for each join and leave, indicating the corresponding multicast source for each action. When eitherrequested Leave but also timeout of a CP source stops sending,multicast state or there-authentication failure. A NSP stops multicasting, in an unsolicited manner, there ismay also a needrecord an accounting stop due to notify the AAA servers accordingly aboutnetwork availability reasons such as failure. The NSP logs the users who are impacted by this event.reason for each accounting stop. Also, intermittent logs between the join and leave would allow for finer diagnostics and therefore could serve useful in billing discrepancies, and provide for a betterfiner estimation of the time span thatspent for delivering the content was multicastedin the evenevent that users disconnect without sending leave messages. 4.4 Access Control and CP selection by NSP When a NSP receives an access request from a user, it is necessary forthe NSP to determinedetermines to which CP the request is to be directed. It is necessary for theThe NSP to ensure that it is not spoofed by an inappropriatemay select a CP based on CP-assigned userID with CP domain name or user. 4.5 APIchannel identifier (S,G). The user should include in the request sufficient information for CP selection. 4.5 Admission Control Information by NSP After authorizing a user request, the NSP may have further conditions for determining its admission control decision. MACCNT-REQ-draft defines requirementsdecision. The NSP needs to know traffic parameters of a multicast channel for admission control. The traffic parameter information may be either indicated by the user or CP within the access request and responses, or otherwise shared between the NSP and CP outside the access-request message mechanism: - A user may declare traffic parameters for each Access-Request. - A CP may notify a mapping between the channel identifier (S,G) and traffic parameters in the Response message when the CP authorizes an access request. - The NSP may maintain a mapping between channel identifier (S,G) and traffic parameters in advance, for example pre-configured by agreement between the CP and NSP on a per channel basis. A NSPs admission control may manage integrated network resources for unicast usage, such as VoIP or unicast streaming, and multicast usage. Alternatively, it may manage network resources separately for unicast and multicast usage. In either case, AAA and admission control framework for providing the network capability to conduct admission control based on the network bandwidthmulticast usage status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9)is independent of unicast admission control. Such QoS measurement and policy mechanisms themselves depend on NSP policies and are out of the scope of this memo. However the NSP's AAA Server should be provided with an Admission control API that allows for interfacing so that additional conditions can be added to the admission control decision.4.6 Access Control and Distinguishing of Users by CP The user ID and authentication information are forwarded transparently by the NSP so that the CP can distinguish the user, as well as authenticate and authorize the request. 4.7 Caching ofAAA results Anproxy in NSP should be able to cacheA NSP may act as AAA resultsproxy of a CP based upon an agreement between the NSP and athe CP. The AAA cacheproxy would store information about permissions of a specific user to receive multicast data from specified channel(s) up to specified expiration date(s) and time(s). If such cachingproxying is implemented, a method must exist forthe CP to communicate this permission information to the NSP. TheNSP refers to the AAA cachemay receive authorization conditions from a CP in advance and if the cache indicates thatstatically hold them, or a CP may send them dynamically in the Response message. The user has permission to receive multicast data from a specificchannel at that time, thetime. The NSP may forwardstarts the datamulticasting without querying the CP. It should be possible for aThe CP tomay send unsolicited requests to the NSP to refresh or change the permissions for a user for specific channel(s). When a user is receiving multicast content and the permission is about to expire, the NSP may send a notification to the user client that his session is about to expire, and that he will need to re-connect. Thereauthenticate. In such a case, the user will have to reestablish a connection.send the Access-Request. In the case that the user still has permission to the content, they should be able to continue to receive the content without interruption. When re-authentication fails, the NSP should stop the multicast channel and record accounting stop. 5. Network Connection Model and Functional Components Section 3.1 introduces the high-level AAA framework for multicasting. This section provides more detaildetails on the network connection model and constituent functional components. 5.1 Basic Connection Model In the simple case represented in Figure 1 the NSP is the sole entity providing network resources including network access to the User. First a user that requests content sends an Access request to an NSP which then forwards it on to the appropriate CP for Authentication and Authorization purposes. The CP responds with either "success" or "failure". If "success", the NSP may forward a success response and stream multicast data to the user. In this model the user selects the NSP to which to send its content request. Based on this request the NSP selects an appropriate CP to which it forwards the request. The CP responds to the NSP's request: it may not respond to another NSP in regards to the request. In this model, as described in section 3.1, the relationship between NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple networks, and networks have multiple users. 5.2 Constituent Logical Functional Components of the fully enabled AAA Framework MACCNT-REQ-draft defined requirementsRequirements for "well managed""fully AAA and QoS enabled" IP multicasting whichnetworks were defined in MACCNT-REQ-draft. To allow for levels of enablement, this memo callsdefines two models within the framework: "AAA enabled" multicasting.multicasting and "Fully enabled AAA" multicasting in this memowhich means "AAA enabled" with added QoSadmission control functions. Section 3.1 introduces the high-level AAA framework for multicasting. Below is a diagram of a AAA enabled multicasting network with AAA, including the logical components within the various entities. AAA enabled framework (basic model) +-------------------------------+ | user | |+- - - - - - - - - - - - - - -+| || CPE || || || |+- - - - - | - - - - - - - - -+| +-----------|-------------------+ | -------|------ IFa | +-----------|-------------------+ | NSP | | |+- - - - - |- -_+ | ||TS | | | | +------|-+ | || | AN | | | | | | | || +------|-+ | | | | IFb | || +------|-+ | | +---------+| | | |----|-|mAAA || || | NAS | | | | (CAPCF*)|||(MACF *) || * optional | +--------+ +---------+| ||+- - - - - - - + | | +-----------------------|--------+ | -------|------ IFc | +-----------------------|-------+ | CP +---------+ | | | CP-AAA | | | +---------+ | +-------------------------------+ Figure 2 The user entity includes the CPE (Customer Premise Equipment) which includes the user host(s) and optionally a multicast proxy (not shown in the Figure 2.) The NSP (Network Service Provider) in the basic model includes the transport system and a logical element for multicast AAA functionality. The transport system is comprised of the access node and NAS (network access server.)server) An AN may be connected directly to mAAA or a NAS relays AAA information between an AN and a mAAA Descriptions of AN and its interfaces are out of scope for this memo. The multicast AAA function may be provided by a multicast AAA server (mAAA) which may include athe function by which the access policy is downloaded to the NAS (conditional(Multicast access policycontrol function.) The interface between mAAA and the NAS is labeled IFb in Figure 2. Over IFb the NAS makes an access request to the NSP-mAAA and the mAAA replies. The mAAA may push conditional access policy to the NAS. The content provider may have its own AAA server which has the authority over access policy for its contents. The interface between the user and the NSP is labeled IFa in Figure 2. Over IFa the user makes a multicasting request to the NSP. The NSP may in reply send multicast traffic depending on the NSP and CP'sCPís policy decisions. The interface between the NSP and CP is labeled IFc. Over IFc the NSP requests to the CP-AAA for access to contents and the CP replies. CP may also send conditional access policy over this interface for AAA-caching.within the context of proxying multicast AAA messagescaching. Fully enabled framework (c)+-------------------------------+ | user | |+- - - - - - - - - - - - - - -+| || CPE || || || |+- - - - - | - - - - - - - - -+| +-----------|-------------------+ | -------|------ IFa | +-----------|-----------------------+ |+- - - - - |- - _+ + - - - - - + | ||TS | | | | | | | +------|-+ | +--------+ | || | AN | | | | | mRACFMACF || | | | | | | | | || +------|-+ | | | +---|----+| | | | | | | | | | | | IFd----- | | | | | IFb | | | || +------|---+ | | | +---|----+| | | | |---|---| mAAA | | || | NAS | | | | |(CAPCF*)|||(MACF *)|| | * optional | +----------+ | +--------+ | ||+- - - - - - - -+ - - |- - - - -+ | +-----------------------|-----------+ | -------|------ IFc | +-----------------------|-------+ | CP +---------+ | | | CP-AAA | | | +---------+ | +-------------------------------+ Figure 3 In the fully enabled model the NSP also includes a component that provides network resource management (e.g. QoS management), as described in section 3.4, "Network Resource Management by NSP". In the fully enabled model (Figure 3) resource management and admission control is provided by mRACFMACF (multicast resource andadmission control function.) This means that mRACF and Authorization portion of mAAA comprise RACS.function). Before replying to the user's multicast request the mAAA queries the mRACFMACF for a network resource access decision over the interface IFd. The mRACFMACF is responsible for allocating network resources for multicast traffic. So that mRACF hasTo provide MACF with the necessaryrelevant network resource availability information, NAS notifies mRACFMACF via mAAA of the stopping ofthat sending multicast traffic.traffic has ceased. 5.3 Modularity of the framework In the interest of flexibility, this framework is modular so that it is possible that partially enabled versions of the models are supported. AAn AAA-enabled version provides AAA functionality without Network Resource management. A Network-Resource-Management-enabled (QoS-enabled) version provides Network Resource management without AAA functionality. Similarly, the possibility of one or more layers of transit provision between an NSP and CP is in the interest of modularity and extendibility. 6. IANA considerations This memo does not raise any IANA consideration issues. 7. Security considerations Refer to section 3.3. Also the user information related to authentication with the CP must be protected in some way. Otherwise, this memo does not raise any new security issues which are not already addressed by the original protocols. Enhancement of multicast access control capabilities should enhance security performance. 8. Conclusion This memo provides a generalized framework for solution standards to meet the requirements presented in MACCNT-REQ- draft.requirements. Further work should be done to specify the interfaces between the user and NSP, NAS and mAAA, mAAA and mRACFMACF and NSP-mAAA and CP-AAA (presented in 5.2.) Normative References  Hayashi, et. al., "Accounting, AuthenticationRequirements for Multicast AAA coordinated between Content Provider(s) and Authorization Issues in Well Managed IP Multicasting Services", draft-ietf-mboned-maccnt-req-04.txt, February 2006,Network Service Provider(s)", draft-ietf-mboned-maccnt-req- 05.txt, September 2007, Work in Progress.  RFC-3810, Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", June 2004.  RFC-3376, Cain B., et.al., "Internet Group Management Protocol, Version 3", October 2002. Authors' Addresses Hiroaki Satou NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 4683 Email : email@example.com Hiroshi Ohta NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 3617 Email: firstname.lastname@example.org Christian Jacquenet France Telecom 3, avenue Francois Chateau CS 36901, 35069 Rennes Cedex,R&D 4, rue du Clos Courtel - - BP 91226 35512 Cesson-SťvignĀECedex, France Phone: +33 2 99 87 63 3112 49 40 Email: email@example.com@orange-ftgroup.com Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone: +81 46 859 8790 Email: firstname.lastname@example.org Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01801, USA Phone: +1 978 288 7482 Email: email@example.com Comments Comments are solicited and should be addressed to the mboned working group's mailing list at firstname.lastname@example.org_and/or the authors. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.". Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Expiration This Internet-Draft will expire on January 10,May 17, 2008. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.