--- 1/draft-ietf-mboned-maccnt-req-02.txt 2007-11-06 23:47:42.000000000 +0100 +++ 2/draft-ietf-mboned-maccnt-req-03.txt 2007-11-06 23:47:42.000000000 +0100 @@ -1,22 +1,22 @@ Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel - Document:draft-ietf-mboned-maccnt-req-02.txt Hiroaki Satou, NTT - Expires: June 18, 2006 Hiroshi Ohta, NTT + Document:draft-ietf-mboned-maccnt-req-03.txt Hiroaki Satou, NTT + Expires: July 14, 2006 Hiroshi Ohta, NTT Susheela Vaidya, Cisco Systems - December 15, 2005 + January 10, 2006 Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services - + 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- @@ -27,76 +27,78 @@ 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 June 18, 2006. + This Internet-Draft will expire on July 14, 2006. Copyright Notice - Copyright (C) The Internet Society (2005) + Copyright (C) The Internet Society (2006) Abstract This memo presents requirements in the area of accounting and access control for multicasting. General requirements for accounting capabilities including quality-of-service (QoS) related - issues are listed. This I-D assumes that these capabilities can be - realized by functions implemented at edges of a network based on - IGMP or MLD. Finally, cases for Content Delivery Services (CDS) - are described as application examples which could benefit from - multicasting accounting and access control capabilities as + issues are listed. Finally, cases for Content Delivery Services + (CDS) are described as application examples which could benefit + from multicasting accounting and access control capabilities as described in the I-D. It is proposed that this I-D be used as a starting point for further discussion on these issues. Table of contents Copyright Notice.................................................1 1. Introduction..................................................2 2. Definitions and Abbreviations.................................4 2.1 Definitions..................................................4 2.2 Abbreviations................................................4 - 3. Problem statement.............................................5 + 3. Problem statement.............................................4 3.1 Accounting issues...........................................5 3.2 Relationship with secure multicasting (MSEC)................6 - 4. General functional requirements for well managed IP + 4. General AAA-related functional requirements for IP multicasting..................................................6 5. Application example and its specific requirements............10 5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are different entities (companies)......................10 5.1.1 Network model for Multicast Content Delivery Service......10 5.1.2 Content Delivery Service Requirements.....................12 5.1.2.1 Accounting Requirements.................................12 5.1.2.2 Authorization Requirements..............................13 5.1.2.3 Authentication Requirements.............................13 5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are the same entities (companies).......................14 6. Acknowledgements.............................................15 7. IANA considerations..........................................15 8. Security considerations......................................15 9. Conclusion...................................................15 Normative References............................................15 + Authors' Addresses..............................................15 Full Copyright Statement........................................17 Intellectual Property...........................................17 - Acknowledgement.................................................17 1. Introduction - The intention of this memo is to define requirements related to - accounting, authentication and authorization issues for "well- - managed IP multicasting" services ("well-managed" defined at the - end of this introduction). + This I-D will present general functional requirements related to + accounting, authentication and authorization issues in IP + multicasting networks. A multicast network which fulfills all of + these requirements will be called a "fully AAA enabled" IP + multicasting network. Fulfillment of all or some of the + requirements will make possible more robust management of IP + multicasting networks, and as such these capabilities contribute to + the provision of well-managed IP multicasting services. IP multicasting is becoming widely used as a method to save network resources such as bandwidth or CPU processing power of the sender's server for cases where a large volume of information needs to be distributed to a large number of receivers. This trend can be observed both in enterprise use and in broadband services provided by network operator/service providers. Distance learning within a university and in-house (in-company) sharing of multimedia information are examples of enterprise use. @@ -140,26 +142,20 @@ used with user-based accounting capabilities, its applicability would be greatly widened. This I-D first describes problems on accounting issues in multicasting. Then the general requirements for this capability including QoS related issues are listed. Finally, application examples which could benefit from multicasting with accounting capabilities are shown. It is proposed that this I-D be used as a starting point for a discussion on these issues. - This I-D will present general functional requirements related to - accounting, authentication and authorization issues in IP - multicasting networks, and a multicast network which fulfills these - requirements will be called a "well managed" IP multicasting - network. - 2. Definitions and Abbreviations 2.1 Definitions Authentication: action for identifying a user as a genuine one. Authorization: action for giving permission for a user to access content or the network. User-based accounting: actions for grasping each user's behavior, @@ -176,23 +172,24 @@ IGMP: Internet Group Management Protocol MLD: Multicast Listener Discovery NSP: Network Service Provider SSM: Single-Source Multicast QoS: Quality of Service - 3. Problem statement + 3. Problem statement 3.1 Accounting issues + In unicast communications, the server (information source) can identify the client (information receiver) and only permits connection by an eligible client when this type of access control is necessary. In addition, when necessary, the server can grasp what the client is doing (e.g., connecting to the server, starting reception, what information the client is receiving, terminating reception, disconnecting from the server). On the other hand, in multicast communication with current standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its @@ -240,21 +237,21 @@ other words, the ability to decode data to return it to its generally useable form.) This I-D presents requirements for multicasting networks in the areas of 1) access control to prevent unauthorized access to the network, and 2) accounting to grasp user activity. The functional requirements do not require content encryption although it might solve some of the related problems. At this point, it is not yet clear whether encryption would be part of a solution and if so, what other components (if any) would also be required. - 4. General functional requirements for well managed IP multicasting + 4. General AAA-related functional requirements for IP multicasting In consideration of the issues presented in section 3, the following requirements have been derived: (1) User identification The network should be able to identify each user when they attempt to access the service so that necessary access controlling actions can be applied. Also, it is necessary to identify the source (user) of each request (e.g., join/leave) for user accounting @@ -277,22 +274,22 @@ (2.1) Access control The network should be able to apply necessary access controlling actions when an eligible user requests. The network should be able to reject any action requested from an ineligible user. (2.2) Control mechanism to support bandwidth of multicast stream from a physical port of edge router or switch The network may need to control the combined bandwidth for all - groups both at the physical port of the edge router or switch so - that these given physical entities are not overflowed with traffic. + groups at the physical port of the edge router or switch so that + these given physical entities are not overflowed with traffic. (2.3) Control mechanism of number of groups delivered from a physical port of edge router and switch If an NSP desires to guarantee a certain level of QoS to CP and the receivers, it is necessary that the NSP be able to control the number of groups delivered from a physical port of an edge router and a switch so that the combined bandwidth between content servers and multicast routers can be within the limit. @@ -497,30 +494,30 @@ Fig.2 Example of CDS network configuration The NSP provides the information server for all multicast channels, and a CP gives detailed channel information (e.g., Time table of each channel) to the information server. An end-user client gets the information from the information server. In this model, multicast is used in the NSP's CDS network, and there are two different contracts. One is the contract between the NSP and the end user which permits the user to access the basic network resources of the NSP. Another contract is between the CP and end - user to permit the user to subscribe multicast content. Because the - CP and NSP are different entities, and the NSP generally does not - allow a CP to control (operate) the network resources of the NSP, - user authorization needs to be done by the CP and NSP independently. - Since there is no direct connection to the user/network interface, - the CP cannot control the user/network interface. An end user may - want to move to another place, or may want to change her/his device - (client) anytime without interrupting her/his reception of services. - As such, IP Multicast network should support portability - capabilities. + user to permit the user to subscribe to multicast content. Because + the CP and NSP are different entities, and the NSP generally does + not allow a CP to control (operate) the network resources of the + NSP, user authorization needs to be done by the CP and NSP + independently. Since there is no direct connection to the + user/network interface, the CP cannot control the user/network + interface. An end user may want to move to another place, or may + want to change her/his device (client) anytime without interrupting + her/his reception of services. As such, IP Multicast network + should support portability capabilities. 5.1.2 Content Delivery Service Requirements To have a successful business providing multicast, there are some specific requirements for the IP Multicast-based Content Delivery Service. 5.1.2.1 Accounting Requirements Since the CP and NSP are different business entities, they need to @@ -648,40 +645,42 @@ Fig.3 Example of CDS network configuration 6. Acknowledgements The authors of this draft would like to express their appreciation to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T- Systems, as well as the participants of the MBONED WG in general. + Funding for the RFC Editor function is currently provided by the + Internet Society. + 7. IANA considerations This I-D does not raise any IANA consideration issues. 8. Security considerations Accounting capabilities can be used to enhance the security of multicast networks by excluding ineligible clients from the networks. 9. Conclusion This I-D describes general requirements for providing "well managed" IP multicasting services. It lists issues related to accounting, authentication, authorization and admission control for - multicast content delivery, with the goal of finding a solution - implemented at edges of the network based on IGMP or MLD. Content - Delivery Services with different business models is cited as an - application which could benefit from the capabilities of "well - managed" IP multicasting described in this document. + multicast content delivery. Content Delivery Services with + different business models is cited as an application which could + benefit from the capabilities of "well managed" IP multicasting + described in this document. It is proposed that this document be used as a starting point for discussing requirements for "well managed" IP multicasting services. Normative References [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", RFC3376, October 2002. [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC3810, June 2004. @@ -711,21 +711,21 @@ Phone: +81 422 59 3617 Email: ohta.hiroshi@lab.ntt.co.jp Susheela Vaidya Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 Phone: +1 408 525 1952 Email: svaidya@cisco.com Full Copyright Statement - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). 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 @@ -749,15 +749,10 @@ 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. - - Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society.