--- 1/draft-ietf-mboned-maccnt-req-01.txt 2007-11-06 23:47:41.000000000 +0100 +++ 2/draft-ietf-mboned-maccnt-req-02.txt 2007-11-06 23:47:41.000000000 +0100 @@ -1,25 +1,24 @@ Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel - Document:draft-ietf-mboned-maccnt-req-01.txt Hiroaki Satou, NTT - Expires: April 15, 2006 Hiroshi Ohta, NTT + Document:draft-ietf-mboned-maccnt-req-02.txt Hiroaki Satou, NTT + Expires: June 18, 2006 Hiroshi Ohta, NTT Susheela Vaidya, Cisco Systems - October 12, 2005 + December 15, 2005 - Accounting, Authentication and Authorization Issues in Well Managed - IP Multicasting Services - + 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- Drafts. @@ -28,77 +27,76 @@ 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 15, 2006. + This Internet-Draft will expire on June 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005) Abstract - This Internet Draft (I-D) describes problems 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. By such functions, - information obtained from edge routers would be logged in a - dedicated database. Finally, cases for Content Delivery Services - (CDS) are described as application examples which could benefit - from multicasting accounting and access control capabilities as + + 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 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..................................................3 + 1. Introduction..................................................2 2. Definitions and Abbreviations.................................4 2.1 Definitions..................................................4 2.2 Abbreviations................................................4 3. Problem statement.............................................5 3.1 Accounting issues...........................................5 3.2 Relationship with secure multicasting (MSEC)................6 - 4. Functional general requirements for well managed IP multicasting - .................................................................6 + 4. General functional requirements for well managed 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 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. IANA considerations..........................................15 - 7. Security considerations......................................15 - 8. Conclusion...................................................15 - Normative References............................................16 + 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 Full Copyright Statement........................................17 Intellectual Property...........................................17 Acknowledgement.................................................17 + 1. Introduction - The intention of this Internet Draft (I-D) is to initiate a - discussion focused on accounting, authentication and authorization - issues for "well-managed IP multicasting" services ("well-managed" - defined at the end of this introduction). This I-D intends to - develop an informational RFC on requirements for "well-managed IP - multicasting". + 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). 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. @@ -122,44 +120,39 @@ current standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting when one applies it to commercial services. Accounting of each user's actions is not possible with multicasting as it is with unicasting. Accounting consists of grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. IP multicasting can be used to distribute free material efficiently, but there are limitations to multicasting in usage models where usage accounting is necessary, such as many commercial applications. - Although multicasting has already been used in several applications, - in many cases it is used in such a way that accounting is not - necessary. Alternatively, one could develop and use a proprietary - solution to address this issue. However, non-standard solutions - have drawbacks in terms of interoperability or cost of development - and maintenance. + These limitations have prevented the widespread deployment of + multicasting. Alternatively, one could develop and use a + proprietary solution to address this issue. However, non-standard + solutions have drawbacks in terms of interoperability or cost of + development and maintenance. Without accounting capability in multicasting, information providers desiring accounting capability are forced to use unicasting even when multicasting would otherwise be desirable from a bandwidth/server resource perspective. If multicasting could be 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. This I-D assumes that - these capabilities can be realized by functions implemented at - edges of a network based on IGMP or MLD. Such functions would - record into dedicated database information obtained from edge - routers. 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. + 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 @@ -194,31 +187,29 @@ 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 as in Fig.1, the - server just feeds its information to the multicast router. Then, - the multicast router replicates the information to distribute to - the clients. According to current standards (e.g., IGMPv3[1] or - MLDv2[2]), the multicast router feeds the replicated information to - any link which has at least one client requesting the information. - In this process, no eligibility check is conducted. Any client can - receive information just by requesting it. In other words, the - current standards do not provide multicasting with authorization or - access control capabilities sufficient to meet the requirements of - accounting. + On the other hand, in multicast communication with current + standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its + information to the multicast router [as in Fig.1]. Then, the + multicast router replicates the data to any link which has at least + one client requesting the information. In this process, no + eligibility check is conducted. Any client can receive information + just by requesting it. In other words, the current standards do + not provide multicasting with authorization or access control + capabilities sufficient to meet the requirements of accounting. +--------+ | user |\ +--------+ \ \+------+ +------+ +------+ +------+ +--------+ |Multi-| |Multi-| |Multi-| | | | user |---|cast |----|cast |----|cast |----|Server| +--------+ |router| |router| |router| | | /+------+ +------+ +------+ +------+ +--------+ / @@ -242,155 +234,164 @@ networks. 3.2 Relationship with secure multicasting (MSEC) In many cases, content encryption (e.g. MSEC) is an effective method for preventing unauthorized access to original content (in 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. It is not the intention of this I-D to propose - alternatives to encryption. Access control, accounting and - encryption are separate technologies. The implementation of any of - these technologies does not preclude the use of the others. + 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. Functional general requirements for well managed IP multicasting + 4. General functional requirements for well managed IP multicasting - It seems beneficial to use IGMP or MLD for access controlling in - multicast networks. However, from the considerations presented in - section 3, there are issues in the following areas: + 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 purposes. - With current protocols, the sender cannot distinguish which - receivers (end hosts) are actually receiving its information with - current protocols (IGMP/MLD.) The sender must rely on the - information from the multicasting routers. This can be complicated - if the sender and routers are maintained by different entities. + With current protocols (IGMP/MLD), the sender cannot distinguish + which receivers (end hosts) are actually receiving the information. + The sender must rely on the information from the multicasting + routers. This can be complicated if the sender and routers are + maintained by different entities. (2) Issue of network resource protection In order to guarantee certain QoS it is important for network providers to be able to protect their network resources from being wasted, (either maliciously or accidentally). - (2.1) Access control + For comparisons sake, in the case of unicast this issue can be + resolved e.g. by using RSVP. + (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 should be able 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. + 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. (2.3) Control mechanism of number of groups delivered from a physical port of edge router and switch - In order to enable an NSP to guarantee a certain level of QoS to - the CP and the receivers, it is important that the NSP can 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. + 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. + + For comparisons sake, in the case of unicast this issue can be + resolved e.g. by using RSVP. (3) User authentication The network should be able to authenticate a user. (4) User authorization - The network should be able to authorize a user's access to content - or a multicast group, so as to meet any demands by a CP to prevent - content access by ineligible users. Also, the NSP does not want to - waste their network resources on ineligible users. Eligibility can - be defined in several ways. The definition of an "eligible user" - should be discussed further. + The network, at its option, should be able to authorize a user's + access to content or a multicast group, so as to meet any demands + by a CP to prevent content access by ineligible users. In the case + that the NSP may wish to provide a service based on guaranteed + delivery, the NSP would not want to waste its network resources on + ineligible users. Eligibility can be defined in several ways. The + definition of an "eligible user" should be discussed further. (5) Accounting and billing - In many commercial multicast situations, NSP would like to be able - to precisely grasp network resource consumption and CP would like + In many commercial multicast situations, NSPs would like to be able + to precisely grasp network resource consumption and CPs would like to be able to precisely grasp the content consumption by end-users. - Such information might be used for "identifying highly viewed - content" for advertising revenue, ratings calculations, programming + Such information might be used for identifying highly viewed + content for advertising revenue, ratings calculations, programming decisions, etc., as well as billing and auditing purposes. Also content and network providers may wish to provide users with access to their usage history. To assemble such an understanding of end-user behavior, it is necessary to precisely log information such as who (host/user) is accessing what content at what time (join action) until what time (leave action). The result of the access-control decision (e.g. results of authorization) would also be valuable information. The desired degree of logging precisions would depend on the application used. - Networks need database functions to realize user-based accounting - through the accumulation of logs from edge routers. - (5.1) How to share user information For commercial multicast applications it is important for NSP and CP to be able to share information regarding user's behaviour (as described in (5) in standardized ways. (6) Notification to users of the result of the join request It should be possible to provide information to the user about the status of his/her join request(granted/denied/other). (7) Service and terminal portability - Networks should allow for a user to receive a service from - different places and/or with a different terminal device. + Depending on the service, networks should allow for a user to + receive a service from different places and/or with a different + terminal device. (8) Support of ASM and SSM Both ASM (G), and SSM (S,G) should be supported as multicast models. (9) Admission control for join action - In order to maintain a predefined QoS level, an edge router should - not accept a consequent "join" after a "leave" until the - termination of the stream of the multicast group which was "left". - This is essential to protect against e.g., multicast denial of - service (DoS) attacks. + In order to maintain a predefined QoS level, depending on the NSP's + policy, an edge router should be able to control the number of + streams it serves to a user, and total bandwidth consumed to that + user. For example if the number of streams being served to a + certain user has reached the limit defined by the NSP's policy, + then the edge router should not accept a subsequent "join" until + one of the existing streams is terminated. Similarly, if the NSP + is controlling by per-user bandwidth consumption, then a subsequent + "join" should not be accepted if delivery of the requested stream + would push the consumed bandwidth over the NSP policy-defined limit. - (10) Channel Leave Latency + (10) Channel Join Latency and Leave Latency Commercial implementations of IP multicasting are likely to have - strict requirements in terms of user experience. Leave latency is - the time between when a user sends a signal that he/she wishes to - "leave" a group and when the network recognizes the "leave." - - Leave latency impacts : - - i. Acceptable end-user experience for fast channel surfing. - - In an IP-TV application, users are not going to be receptive to - slow response time when changing channels. + strict requirements in terms of user experience. Join latency is + the time between when a user sends a "join" request and when the + requested data streaming first reaches the user. Leave latency is + the time between when a user sends a "leave" signal and when the + network stops streaming to the user. - ii. Resource consumption + Leave and Join latencies impact the acceptable end-user experience + for fast channel surfing. In an IP-TV application, users are not + going to be receptive to a slow response time when changing + channels. If there are policies for controlling the number of + simultaneous streams a user may access then channel surfing will be + determined by the join and leave latencies. - With a low "leave latency" network providers could minimize - streaming content when there are no audiences. + Furthermore, leave affects resource consumption: with a low "leave + latency" network providers could minimize streaming content when + there are no audiences. It is important that any overhead for authentication, authorization, and access-control be minimized at the times of joining and leaving multicast groups so as to achieve join and leave latencies acceptable in terms of user experience. For example this is important in an IP-TV application, because users are not going to be receptive to a slow response time when changing channels. (11) Scalability @@ -411,23 +412,23 @@ (13) Deployable as alternative to Unicast IP Multicasting would ideally be available as an alternative to IP unicasting when the "on-demand" nature of unicasting is not required. Therefore interfaces to multicasting should allow for easy integration into CDS systems that support unicasting. Especially equivalent interfaces for authorization, access control and accounting capabilities should be provided. (14) Multicast replication + The above requirements should also apply if multicast replication - is - being done on an access-node (e.g. DSLAMs or OLTs). + is being done on an access-node (e.g. DSLAMs or OLTs). Specific functional requirements for each application can be derived from the above general requirements. An example is shown in the section 5. 5. Application example and its specific requirements This section shows an application example which could benefit from multicasting. Then, specific functional requirements related to user-based accounting capabilities are derived. @@ -637,44 +640,48 @@ +----------- / --- | --- \ ---------------------------+ / | \ / | \ <- user/network interface / | \ +---------++ +-----+----+ ++---------+ |user #a | |user #b | |user #c | +----------+ +----------+ +----------+ End user A End user B End user C Fig.3 Example of CDS network configuration + 6. Acknowledgements - 6. IANA considerations + 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. + + 7. IANA considerations This I-D does not raise any IANA consideration issues. - 7. Security considerations + 8. Security considerations Accounting capabilities can be used to enhance the security of multicast networks by excluding ineligible clients from the networks. - 8. Conclusion + 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. This solution likely - would assume the existence of a database in the network dedicated - to accumulating logs obtained from edge routers. 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. + 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. 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.