Hiroaki Satou, NTT Internet Draft Hiroshi Ohta, NTT Expires: April 20, 2006 Tsunemasa Hayashi, NTT Haixiang He, Nortel Networks October 17, 2005 AAA Framework for Multicasting 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005) Abstract Satou, Ohta, Hayashi and He [Page 1] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 This memo provides a generalized framework for solution standards to meet the requirements presented in draft-mboned-maccnt-req-01.txt. In this framework a user sends a request for multicast data to a network service provider which then selects the appropriate content provider to which it then sends on the request transparently in a way so that the network service provider and content provider do not need to know the corresponding user id for the same user in the other provider's domain. The content provider then responds with success of failure to the network provider and if success, the network provider may delivery the requested data to the user. The network service may base its decision to deliver such data to the user based on its bandwidth management policy. Table of contents Copyright Notice...................................................1 1. Introduction....................................................2 1.1 Purpose and Background.........................................2 2. Definitions and Abbreviations...................................3 2.1 Definitions....................................................3 2.2 Abbreviations..................................................4 3. Issues in multicasting related to commercial and large-scale implementations....................................................4 3.1 Framework for multicast AAA allowing bandwidth Management......5 3.3 Access Control and CSP selection by NP.........................6 3.4 Bandwidth Management by NP.....................................6 3.5 Access Control and Distinguishing of Users by CSP..............6 3.6 Multicast Session Management for Accounting....................6 4. IANA considerations.............................................6 5. Security considerations.........................................6 6. Conclusion......................................................7 Normative References...............................................7 Comments...........................................................7 Full Copyright Statement...........................................8 Intellectual Property..............................................8 Expiration.........................................................8 Acknowledgement....................................................8 1. Introduction 1.1 Purpose and Background IP multicasting is designed to serve cases where a single source of data content is to be concurrently streamed to multiple recipients. In these types of cases, multicasting provides resource efficiencies (both for the overall network and the content server)relative to Satou, Ohta, Hayashi and He [Page 2] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 unicasting. These efficiencies are possible because of the avoidance of unneccesary duplication of streams, video/audio processing, etc. Multicasting also provides resource advantages relative to IP broadcasting in that content data is only delivered to end hosts which request it. There are many real-life situations where IP multicasting is selected as the technology used for concurrent content delivery of identical content data to multiple end-hosts. draft-ietf-mboned-maccnt-req- 01.txt (a work in progress, hereafter MACCNT-REQ-draft) describes the requirements in CDN services using IP multicast. draft-ietf-mboned- rac-issues-01.txt (a work in progress, hereafter RAC-ISSUES-draft) discusses the requirements and existing support for commercial, large-scale content delivery. The requirements are derived from: - need for user tracking and billing capabilities - need for network access control and/or content access control satisfactory to the requirements of the CP - methods for sharing information between the network service provider and content provider to make the above two possible. 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 anonymous depending on the trust model) between content provider and network service provider, and protecting resources through preventing 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 solution standards to meet these requirements. 2. Definitions and Abbreviations 2.1 Definitions For the purposes of this I-D the following definitions apply: Accounting: actions for grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. Authentication: action for identifying a user as a genuine one. Authorization: action for giving permission to access the content or network to a user. Receiver: an end-host or end-client which receives content. A receiver may be distinguishable by a network ID such as MAC address or IP address. Satou, Ohta, Hayashi and He [Page 3] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 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 purposes of this draft the following abbreviations apply: ACL: Access Control List CDN: Content Delivery Network CDS: Content Delivery Services CP: Content Provider NSP: Network Service Provider 3. Issues in multicasting related to commercial and large-scale implementations This section lists issues related to receiver access control in current multicasting protocols which are especially important to commercial, large-scale multicasting. More details concerning the requirements related to these issues are provided in a separate I-D draft-ietf-mboned-maccnt-01.txt[1]. References to that document are provided as applicable below. Satou, Ohta, Hayashi and He [Page 4] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 3.1 Framework for multicast AAA allowing bandwidth Management A general high-level framework can be represented as follows. +------------------------------+ | user | | | +------------------------------+ | Access ^ Response | Request | & Multicast Data V | +------------------------------+ | NSP | | | +------------------------------+ | Authentication ^ Response | Request | (Success) v | +------------------------------+ | CP | | | +------------------------------+ Description: First a user desiring authorization sends an Access request to NSP which then forwards it on to the appropriate CP for Authentication and Authorization. The CP responds with either success of failure. If success the NP forwards a success response and stream multicast data to the user. For the sake of simplicity, the above diagram portrays a case where there is a singe NSP entity and a single CP entity. Under the framework it is possible for there to be multiple CPs connected to the same network, at the same time it is possible for the same 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. 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 to forward such request. The CP responds to the NSP's request: it should not respond to another NSP in regards to the request. 3.2 Multiple User IDs Users may be assigned separate user IDs for each subscription for various CPs. When the user wants to access content, the user registers the corresponding user ID with a request for content. Satou, Ohta, Hayashi and He [Page 5] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 Each CP may identify users by the user IDs which it has issued to them. The NSP and CP do not need to know the corresponding user id for the same user in the other provider's domain, and it is not necessary that there is a one to one relationship. It is quite possible for one person to hold multiple user ids for the same provider. 3.3 Access Control and CP selection by NSP When a NSP receives an access request from a user, it is necessary for the NSP to determine to which CP the request is directed. It is necessary for the NSP to ensure that it is not spoofed by an inappropriate CP. 3.4 Bandwidth Management by NSP After the NSP authorizes a user request, NSP may conduct admission control based on NSP's bandwidth management policy. For example, if the NSP manages the shared bandwidth of access lines, the NSP might calculate available bandwidth and necessary bandwidth, and based on these calculations determine to accept or reject the user request. 3.5 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 the NSP forwards user's requests to the target CP, the CP can authenticate and authorize the user's request. 3.6 Multicast Session Management for Accounting The NSP should not manage multicast states on a subnet basis, but on a user basis because the NSP needs to notify start and stop times for accounting purposes. This means that the NSP sends an indication for Join and Leave on a user basis. 4. IANA considerations This I-D does not raise any IANA consideration issues. 5. Security considerations Refer to section 3.3. Also the user information related to authentication with the CP should be protected in some way. Otherwise, this I-D does not raise any new security issues which are not already existing in original protocols. Enhancement of multicast access control capabilities may enhance security performance. Satou, Ohta, Hayashi and He [Page 6] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 6. Conclusion This memo provides a generalized framework for solution standards to meet the requirements presented in draft-mboned-maccnt-req-01.txt. Further work should be done to break down the content provider and network service provider entities into their functional objects such as edge devices, AAA servers, etc. Normative References [1] Hayashi, et. al., "Accounting, Authentication and Authorization Issues in Well Managed IP Multicasting Services", draft-ietf- mboned-maccnt-req-01.txt, October 2005 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 : satou.hiroaki@lab.ntt.co.jp Hiroshi Ohta NTT Network Service Systems Laboratories 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan Phone : +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone: +81 46 859 8790 Email: hayashi.tsunemasa@lab.ntt.co.jp Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01801, USA Phone: +1 978 288 7482 Email: haixiang@nortel.com Comments Comments are solicited and should be addressed to the mboned working group's mailing list at mboned@lists.uoregon.edu_and/or the authors. Satou, Ohta, Hayashi and He [Page 7] Internet Draft draft-satou-multiaaa-framework-00.txt October, 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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 IETF's procedures with respect to rights in IETF 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 ietf ipr@ietf.org. Expiration This Internet-Draft will expire on April 20, 2006. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Satou, Ohta, Hayashi and He [Page 8]