Internet DRAFT - draft-ietf-mboned-rac-issues

draft-ietf-mboned-rac-issues




 
                                                 Tsunemasa Hayashi, NTT 
   Internet Draft                          Haixiang He, Nortel Networks 
   Expires: October 21, 2006                         Hiroaki Satou, NTT 
                                                      Hiroshi Ohta, NTT 
                                         Susheela Vaidya, Cisco Systems 
                                                                        
                                                         April 19, 2006 
 
    Issues Related to Receiver Access Control in the Current Multicast 
                                 Protocols 
                   <draft-ietf-mboned-rac-issues-03.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. 
    
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
   This Internet-Draft will expire on October 21, 2006. 
    
    
Copyright Notice 
    
    
   Copyright (C) The Internet Society (2006) 
    
    
    
    
   Hayashi, He, Satou, Ohta and Vaidya                        [Page 1] 
 
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
    
Abstract 
    
   This memo evaluates the extent to which current multicasting 
   protocols can be used to address common requirements for commercial, 
   large-scale IP multicasting, but may be applicable to non-commercial 
   deployments as well.  Four existing possible multicasting 
   architectures (with or without some form of access or content 
   control) are presented. Then each architecture is analyzed with 
   respect to how it can or cannot satisfactorily address each issue.  
   This memo concludes that for many of these issues the possible 
   architectures based on present standards as they now exist require 
   non-standardized solutions to meet common use requirements. This 
   memo recommends for requirements to be defined that would set the 
   groundwork for framework(s) and solutions that sufficiently address 
   these limitations.   
 
 
   Copyright Notice...................................................1 
   1. Introduction....................................................3 
   2. Definitions and Abbreviations...................................4 
   2.1 Definitions....................................................4 
   2.2 Abbreviations..................................................5 
   3. Common use models and network architecture implications.........5 
   4. Issues in multicasting related to commercial and large-scale 
   implementations....................................................7 
   4.1 Access limits and resource issues..............................7 
   4.2 Capability to distinguish between receivers (end hosts)........7 
   4.3 Capability to distinguish between users (as opposed to merely 
   hosts).............................................................8 
   4.4 Minimizing Channel Join Latency and Leave Latency..............8 
   4.5 Surveillance of receiver by sender.............................8 
   4.5.1 Precise access logging.......................................8 
   4.5.2 How to share user information................................8 
   4.5.3 Trustworthy logs to monitor user activity....................9 
   4.6 Notification to users of the result of the join request........9 
   4.7 Sharing of Infrastructure for Support of Triple Play Services..9 
   4.8 DRM Protection.................................................9 
   5. Description of existing architectures...........................9 
   5.1 IGMP/MLD......................................................10 
   5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.11 
   5.3 Unicast Control with IGMP/MLD.................................13 
   5.4 IGMP/MLD with Multicast Encryption............................13 
   6. Evaluation of architectures by issue...........................14 
   6.1 Access limit capabilities, compared by architecture...........14 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 2] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   6.2 Capability to distinguish between receivers, compared by 
   architecture......................................................15 
   6.3 Capability to distinguish between users, compared by 
   architecture......................................................16 
   6.4 Maintain guaranteed quality-level of data delivery (Voice, 
   Video), compared by architecture..................................17 
   6.5 Fast leave for fast surfing capability, compared by architecture
   ..................................................................17 
   6.6 Surveillance of receiver by sender, compared by architecture..18 
   6.7 Notification to users of the result of the join request compared 
   by architecture...................................................19 
   6.8 Comparison summary............................................19 
   7. Relevance to non-commercial deployments........................20 
   8. IANA considerations............................................20 
   9. Security considerations........................................20 
   10. Conclusion....................................................20 
   Normative References..............................................21 
   Comments..........................................................22 
   Full Copyright Statement..........................................23 
   Intellectual Property.............................................23 
   Expiration........................................................24 
   Acknowledgement...................................................24 
 
1. Introduction 
    
   The intention of this memo is to initiate a discussion on the state 
   of current multicasting protocols deployed for commercial, large-
   scale multicasting and their capabilities to provide receiver access 
   control. Many of the issues discussed in this memo may be relevant 
   to non-commercial situations, as well.   
    
   Existing IP multicasting protocols (as presented in Section 5) were 
   designed to meet certain sets of requirements that do not 
   necessarily include architectural considerations intended to support 
   commercial services. This memo presents a number of issues network 
   providers may face when they attempt to apply current multicasting 
   standards to commercial services.   The extent to which existing 
   multicast protocols can or cannot satisfactorily deal with these 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 3] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   issues is explored.  A few network models based on a range of 
   different business models are presented as a basis for defining 
   requirements. 
    
   Multicasting can be useful to make the network more scalable when a 
   large volume of information needs to be distributed to a large 
   number of receivers.  However, multicasting according to current 
   standards (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to 
   unicasting in terms of its commercial applicability because of the 
   insufficiency of access control and protection of network resources 
   against malicious use or accidents.  In order to be applicable to 
   large-scale commercial networks, multicast networks need to have the 
   same capabilities which are currently supported by unicast networks.  
   Such issues which are important to commercial, large-scale 
   implementations of multicasting are listed.  Next, a few possible 
   existing architectures used for multicasting with access control 
   based on current standards are presented. Specifically 1) IGMP/ MLD, 
   2) IGMP/MLD with L2/L3 Authentication with ACL 3) Unicast Control 
   with IGMP/MLD and 4) IGMP/MLD with Multicast Encryption will each be 
   presented and described.  Each architecture is discussed with 
   respect to the presented list of issues.  
    
    
2. Definitions and Abbreviations 
    
2.1 Definitions 
    
   For the purposes of this memo 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.   
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 4] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
    
   Triple Play: voice (VoIP), video, and broadband Internet access 
   services.  
    
   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 
    
   CDS: Content Delivery Services 
    
   CP: Content Provider 
    
   DRM: Data Rights Management 
    
   KEI: Key Exchange Identifier 
    
   NSP: Network Service Provider 
    
   QoS: Quality of Service 
    
    
3. Common use models and network architecture implications 
    
   Issues such as user identification, access-control, tracking and 
   billing are common requirements for commercial content delivery 
   services (CDS) systems (and are important in many non-commercial CDS 
   systems as well.)  These same requirements should be met for CDS 
   systems that employ multicasting.   
    
   In some cases a single entity may design and be responsible for a 
   system that covers the various common high-level requirements of a 
   commercial multicasting system such as 1) content serving, 2) the 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 5] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   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 
   memo draft-ietf-mboned-maccnt-04.txt [3, referred to hereafter in 
   this memo as MACCNT-draft] provides more detail of the multiple 
   versus single entity CDS network model. 
 
   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 commercial network service providers do not generally 
   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 business model of a single network service provider (NSP) 
   providing multicasting services to multiple content providers CP has 
   certain implications: 
    
        -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 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 
         
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 6] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   In the next section issues in multicasting related to commercial and 
   large-scale implementations are presented.  Some presented issues 
   are not pertinent to cases where the NSP and CP are the same entity.  
    
    
4. 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.  To avoid unnecessary 
   duplication with MACCNT-draft, detail for some of these issues is 
   provided through references in the Normative Reference section.  
    
    
4.1 Access limits and resource issues 
    
 
   For commercial applications of multicasting, network and content 
   providers generally wish to be able to control the number of groups 
   a host can access at the same time. Also the network provider may 
   wish to limit the number of users accessing a multicast stream 
   because of bandwidth and processing issues between the receiver and 
   the multicast server.  This section corresponds to MACCNT-draft[3], 
   section 4.5.14.2 "Issue of network resource protection", and 4.2.1 
   "Access control", but provides more detail. 
 
   With best-effort services (e.g. mail transfer, web surfing) strict 
   network resource allocation is not necessary, but for services with 
   a guaranteed QoS level (e.g. IP television, teleconferencing, VoIP) 
   it is necessary to allocate sufficient bandwidth and server 
   resources to each service.  More detail on the topic of network 
   resource protection is provided in section "Issue of network 
   resource protection" of the MACCNT-draft[3]. 
 
 
4.2 Capability to distinguish between receivers (end hosts) 
 
For detail on the topic on the capability to distinguish between 
receivers, refer to MACCNT-draft[3], 4.1 the second paragraph which 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 7] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
begins with "With current protocols (IGMP/MLD), the sender cannot 
distinguish 
    
    
4.3 Capability to distinguish between users (as opposed to merely 
   hosts) 
    
   Detail related to the topic of user identification can be found in 
   section "User identification" of the MACCNT-draft[3], the first 
   paragraph. 
 
 
4.4 Minimizing Channel Join Latency and Leave Latency  
 
   More detail on the topic of channel leave latency is provided in 
   section "Channel Join Latency and Leave Latency" of the MACCNT-
   draft[3]. 
 
4.5 Surveillance of receiver by sender 
 
4.5.1 Precise access logging 
    
   For detail on the topic please refer to MACCNT-draft[3], 4.6 
   "Accounting and billing", especially the second paragraph which 
   begins with " To assemble such..." 
 
4.5.2 How to share user information  
     
   For commercial multicast applications where NSP and CP are different 
   entities, there are a number of issues regarding how to share user 
   information between the NSP and CP.  For example, which entities 
   should be able to access which information relating to user-based 
   tracking? What is the user identifier that can be used between the 
   entities to distinguish among users, and which entities should be 
   able to recognize this identifier?  Another important issue is how 
   the edge router should be able to access and then maintain user 
   information. The current situation of present architectures is that 
   only the NSP can get information about user activity, because user 
   activities are only observable from join/leave information logged on 
   edge devices which are under control of the NSP. This section 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 8] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   corresponds to MACCNT-draft[3], section 4.5.1 "How to share user 
   information", but provides more detail than in the MACCNT-draft. 
    
 
4.5.3 Trustworthy logs to monitor user activity 
    
   An important issue for commercial multicasting applications is how 
   the NSP can get trustworthy data on user activity which may be 
   needed for billing and statistics purposes.  A standard way of 
   logging user activity and protecting the integrity of the logs does 
   not exist. Often network providers do not want to keep logs on 
   untrusted user terminals that can be tampered with.  
    
    
4.6 Notification to users of the result of the join request  
 
   Details for this issue are presented in MACCNT-draft[3], section 4.6 
   "Notification to users of the result of the join request." 
    
    
4.7 Sharing of Infrastructure for Support of Triple Play Services  
 
   As stated in MACCNT-draft[3], section "Small impact on the existing 
   products": "Ideally the NSP should be able to use the same 
   infrastructure (such as access control) to support commercial 
   multicast services for the so-called 'triple play' services". 
 
 
4.8 DRM Protection 
    
   Digital Rights Management (DRM) is important but out of scope of 
   this memo. 
 
 
5. Description of existing architectures 
    
   In this section, existing architectures used for multicasting based 
   on current standards are defined.  In section 6 these architectures 
   will be compared by the issues presented in section 4. 
 
 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                           [Page 9] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
5.1 IGMP/MLD 
 
   Internet Group Management Protocol(IGMP) or Multicast Listener 
   Discovery (MLD) are protocols for layer 3 management of multicasting. 
   In IP multicast a receiver sends a request to a first-hop multicast 
   router to join a particular multicast group. The router is then 
   responsible for forwarding the appropriate data from the sender to 
   the receiver.  
    
     +----------+    +----------+   +----------+         +----------+ 
     | Sender   |    | Router   |   | L2SW     |         | Receiver | 
     |          |    |          |<---------------1,JOIN--|          | 
     |          |    |          |   |          |         |          | 
     |          |--------------------------------2,Data->|          | 
     |          |    |          |   |          |         |          | 
     |          |    |          |   |          |         |          | 
     +----------+    +----------+   +----------+         +----------+ 
                                           
   For the sake of simplicity, the above diagram only shows the 
   sequence of requests for a single receiver.  When multiple receivers 
   are requesting the same channel stream the data would be copied at 
   the multicasting router to serve the multiple streams.  
 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 10] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy 
 
   With a basic implementation of IGMP/MLD, no authorization is 
   performed on the receiver.  It is possible to combine an IGMP/MLD 
   implementation with Layer 2 or Layer 3 Authentication to provide an 
   access-control mechanism at the first point of attachment to the 
   network, for example, using 802.1X.  
    
   For example, a receiver may request to an L2 authentication server 
   for access to the network. The authentication controller then 
   queries the policy server with the receiver's credentials (such as 
   IP or MAC address), and if the receiver is determined to be an 
   authorized user of the network ("success"), the router downloads the 
   ACL from the policy server.  For example, users which are not on the 
   ACL are rejected.  Then the Layer 2 Switch is directed to open a 
   port for the receiver to send a join request to the multicast router. 
   The router is then responsible for forwarding the appropriate data 
   from the sender to the receiver.  
    
   Note: ACL is one existing method to realize an access control policy.  
   Other methods exist. 
     
     +----------+ 
     | Policy   | 
     | Server   |\ 
     |          | \ 
     +----------+  \ 4,ACL Download 
        |    ^      \ 
        |    |       \ 
        V    |        V 
     +----------+    +----------+   +----------+          +----------+ 
     | L2       |    | Router   |   | L2SW     |          | Receiver | 
     |          |    |          |   |          |          |          | 
     | Auth.    |<----------------------------  1,Request-|          | 
     |          |    |          |   |          |          |          | 
     |          |--------2,Success------------>X(3,Auth)  |          | 
     +----------+    |          |   |          |          |          | 
                     |          |   |          |          |          | 
     +----------+    |          |   |          |          |          | 
     |          |    |          |<---------------5,Join---|          | 
     | Sender   |    |          |   |          |          |          | 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 11] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
     |          |------------>x------------------6,Data-->|          | 
     |          |    |        | |   |          |          |          | 
     +----------+    +--------|-+   +----------+          +----------+ 
                              |            
                              V 
Key: 
 Auth: Authentication
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 12] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-01.txt   March, 2006 
    
    
 
 
5.3 Unicast Control with IGMP/MLD  
    
   The receiver first sends a unicast request to the sender which 
   resides in the CP's domain.  This method is the same as that used in 
   unicast video-on-demand (VoD) systems.  If authorization is 
   successful the sender sends the multicast address information via 
   unicast.  With this multicast address the receiver does a IGMP\MLD 
   join as in described in 5.1. Generally this approach is relying on 
   either some sort of content encryption or "security through 
   obscurity" for content security. Also accounting becomes problematic 
   because user credentials may not be identified. 
    
     +----------+    +----------+   +----------+          +----------+ 
     | Sender   |    | Router   |   | L2SW     |          | Receiver | 
     |          |    |          |   |          |          |          | 
     |          |<------------------------------1,Request-|          | 
     |          |    |          |   |          |          |          | 
     |          |-------------------------------2,Success>|          | 
     |          |    |          |   |          |          |          | 
     |          |    |          |<--------------3,Join----|          | 
     |          |    |          |   |          |          |          | 
     |          |------------>x-----------------4,Data--->|          | 
     |          |    |        | |   |          |          |          | 
     |          |    |        | |   |          |          |          | 
     +----------+    +--------|-+   +----------+          +----------+ 
                              |             
                              V 
 
5.4 IGMP/MLD with Multicast Encryption  
    
   With a basic implementation of IGMP/MLD, no data protection is 
   performed on data sent to the receiver.  No credential check is 
   performed on the receiver and any receiver can receive and use the 
   data.  The IGMP/MLD with Multicast Encryption model assumes that the 
   sender is sending encrypted data and that for this data to be useful 
   to the receiver it must first request and receive a key from a group 
   controller and key server that is synchronized with the content 
   encryption occurring on the sender's data.  
    
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 13] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
     +----------+    +----------+   +----------+          +----------+ 
     | G.C. &   |    | Router   |   | L2SW     |          | Receiver | 
     |          |    |          |   |          |          |          | 
     | Key S.   |<------------------------------1,Request-|          | 
     |          |    |          |   |          |          |          | 
     |          |-------------------------------2,Key---->|          | 
     +----------+    |          |   |          |          |          | 
                     |          |   |          |          |          | 
     +----------+    |          |   |          |          |          | 
     |          |    |          |<---------------3,Join---|          | 
     | Sender   |    |          |   |          |          |          | 
     |          |------------>x------------------4,Data-->|          | 
     |          |    |        | |   |          |          |          | 
     +----------+    +--------|-+   +----------+          +----------+ 
                              |             
                              V 
   Key: 
   G.C. & Key S.= Group Controller and Key Server 
    
     
6. Evaluation of architectures by issue  
    
   In this section the various issues raised in section four are 
   analyzed by each of the architectures introduced in section five. 
 
    
6.1 Access limit capabilities, compared by architecture 
    
   Comparison of currently available architectures with respect to 
   limiting the access of multicast groups 
    
   - IGMP/MLD:  It is not possible to limit data reception. 
    
   - L2/L3 authentication with access control policy: 
   With an ACL it is possible to limit access of multicast groups. 
   However it should be discussed as to how scalable this approach is 
   because configuring an ACL could be a labor-intensive task. 
    
   - IGMP/MLD with Unicast control  
   It is possible for malicious users to reconfigure the receiver's 
   terminal to ignore the Unicast control.  In this case, this 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 14] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   maliciously reconfigured terminal could send a join message even if 
   it is rejected by the network.  In such a case, the ineligible 
   receiver would be able to receive the multicast.  As such, this 
   method may not be strong enough to exclude ineligible access. 
    
    
   -Multicast Encryption: 
   It is possible for receivers to receive IP packets, even if they do 
   not possess the keys to decrypt them. A receiver may also be able to 
   store such received data until they discover a way to decrypt it.  
   Another disadvantage of this method is that network resources are 
   wasted if an ineligible receiver receives an encrypted content even 
   if they do not have a valid key. 
    
    
6.2 Capability to distinguish between receivers, compared by 
   architecture 
 
   Comparison of currently possible protocol-based solutions. 
    
   -IGMP/MLD: 
   The sender has no direct line of contact with the receiver and 
   therefore cannot distinguish on a receiver-basis.    (If the edge-
   router's user interface is statically assigned then the interface's 
   log can be used to track joins, but this would mean portability is 
   sacrificed.  Moreover, this method is not applicable to a case where 
   the CP and NSP are different companies because the CP cannot access 
   this join-log. Sharing of the join-log could be done with a yet-to-
   be defined standard mechanism/format. ) 
    
   -L2/L3 authentication with access control policy: 
   At the moment of L2/L3 authentication it is possible to recognize 
   receivers, but if there are multiple content providers (CP) a single 
   L2 Authorization Server cannot distinguish among the CPs.  Therefore 
   it would be necessary to gather the join logs.  (If the interface is 
   fixed then the join-log can be used, but this would mean portability 
   is sacrificed.  Moreover, this method is not applicable to a case 
   where the CP and NSP are different companies because the CP cannot 
   access this join-log.) 
    
   -IGMP/MLD with Unicast control : 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 15] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   It is possible to distinguish among receivers using Unicast control.  
   This latency may not be a problem when users are switching between 
   channels of the same CP in cases where the CP grants viewing 
   privileges uniformly across all of its channels. However, other 
   policies are possible that may be on a channel-basis, time-basis, 
   etc. and in such cases channel changing has latency issues.  
    
   -Multicast Encryption: 
   If the CP maintains the Key Server it is possible to distinguish on 
   the receiver-level.  If the Network Service Provider maintains the 
   key server it is necessary to devise a method for the NSP to notify 
   the CP. 
    
    
6.3 Capability to distinguish between users, compared by architecture 
    
   Comparison of currently possible protocol-based solutions: 
    
   -IGMP/MLD: 
   Since there is no user-based information, it is not possible to 
   distinguish on the user-level. 
    
   -L2/L3 authentication with access control policy: 
   At the moment of L2/L3 Authentication it is possible to distinguish 
   on the user-level. 
     
   However it is difficult to combine user and group logs: it would be 
   necessary to match user IDs from L2-Auth logs and group IDs from the 
   Join logs to match users and groups.  
    
   -IGMP/MLD with unicast control : 
   Distinguishing by user is possible using unicast control. 
    
   -Multicast Encryption: 
   If the Content Provider manages the Key Server it is possible to 
   distinguish the user.   
   If the Network Service Provider manages the Key Server it is 
   necessary to notify the Content Provider. 
    
    
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 16] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 
   compared by architecture 
    
   Comparison of currently possible protocol-based solutions: 
 
   -IGMP/MLD: 
    It is not possible to reject a user attempting to access even if 
   there are not sufficient resources.  
    
   -L2/L3 authentication with access control policy: 
   The AAA server does not know whether there are sufficient resources 
   or not.  This method still can provide a guaranteed QoS if every 
   channel has the same bandwidth and sufficient bandwidth are 
   allocated to each user beforehand.  However, it is not possible to 
   provide a guaranteed QoS by comparing the available bandwidth and 
   the necessary bandwidth upon each user's request. 
    
   -IGMP/MLD with Unicast control: 
   When the CP and NSP are separate entities it is not possible for the 
   CP to make a proper authorization decision because only the NSP 
   grasps the network resource availability.  
    
   -Multicast Encryption: 
   Having only encryption provides no access control and therefore  
   provides no mechanism to reject a user attempt to access when 
   sufficient resources are not available (i.e. the user can receive 
   data even without holding a valid key.)  
    
    
6.5 Fast leave for fast surfing capability, compared by architecture 
    
   Comparison of currently possible protocol-based solutions: 
    
   -IGMP/MLD: 
   It is possible to track on a per host level (based on host address) 
   therefore fast leave for fast surfing capability can be achieved.  
    
    
   -L2/L3 authentication with access control policy: 
   It is possible to track on a per host level (based on host address) 
   therefore fast leave for fast surfing capability can be achieved. 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 17] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
    
   -IGMP/MLD with Unicast control : 
   Even if a quick leave is possible, changing to a new channel using 
   Unicast Control is slow (latency problem).  This latency may not be 
   a problem when users are switching between channels of the same CP 
   in cases where the CP grants viewing privileges uniformly across all 
   of its channels.  However, other policies are possible that may be 
   on a channel-basis, time-basis, etc. and in such cases channel 
   changing has latency issues.    
    
   -Multicast Encryption: 
   Even if a quick leave is possible, delivery of the Key Exchange 
   Identifier(KEI) is slow. 
    
    
6.6 Surveillance of receiver by sender, compared by architecture 
    
   Comparison of currently possible protocol-based solutions:  
    
   -IGMP/MLD: 
   With this protocol it is possible to separately log join and leave 
   actions, but it is difficult to match these join and leave actions 
   because analyzing the logs requires heavy computation (related to 
   the scalability with millions of users). 
 
   -L2/L3 authentication with access control policy: 
   In this solution, the leave action is not recorded unless some 
   additional mechanism such as IGMP/MLD snooping is used.  In some 
   cases, users disconnect their terminals without sending logout 
   messages.  Also it is possible that the user is running multiple 
   services and thus they will not log out even if they are finished 
   watching video or other multicast content.  In this case, it is not 
   possible to precisely determine for accounting purposes when each 
   user disconnected.  Also, it may be a problem that unused bandwidth 
   is being needlessly reserved.  
    
   However MLD/IGMP reports/joins need to be refreshed periodically.     
   The ACL entry can be deactivated if the user no longer refreshes the 
   report/join, but this means that user can be charged with unwatched 
   programs (125 seconds default.) This lack of precise timing may be a 
   problem in certain cases such as for paid services.  
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 18] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
    
   -IGMP/MLD with Unicast control : 
   In this solution the leave action is not recorded. 
 
   -Multicast Encryption: 
   If logs are recorded for each renewal of keys, then it is possible 
   to track activity on a per-user basis. However if logs are only 
   recorded per content data download then such tracking is not 
   possible.     
    
    
   It should be noted that authentication of the source of each 
   join/leave message is important. 
 
 
6.7 Notification to users of the result of the join request compared by 
   architecture 
 
   Comparison of currently possible protocol-based solutions: 
    
   -IGMP/MLD: 
   After the join it is not possible to notify the user of the result 
   of the join request. 
    
   -L2/L3 authentication with access control policy: 
   After the join it is not possible to notify the user of the result 
   of the join request. 
    
   -IGMP/MLD with Unicast control : 
   After the join it is not possible to notify the user of the result 
   of the join request. 
    
   -Multicast Encryption: 
   After the join it is not possible to notify the user of the result 
   of the join request. 
    
    
6.8 Comparison summary 
    
   In this section a variety of existing architectures used for 
   multicasting based on current standards were compared and evaluated.   
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 19] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
   None of these architectures can sufficiently meet all of the common 
   requirements for accounting, authentication and authorization in 
   commercial, large-scale IP multicasting.  Therefore it is 
   recommended that framework(s) for sufficiently addressing such 
   requirements be explored.    
    
7. Relevance to non-commercial deployments 
    
   While the impetus for this memo was to discuss issues related to the 
   state of current multicasting protocols deployed for commercial, 
   large-scale multicasting and their capabilities to provide receiver 
   access control. Many of the issues discussed in this memo may be 
   relevant to non-commercial situations, as well. 
 
8. IANA considerations 
    
   This memo does not raise any IANA consideration issues. 
    
    
9. Security considerations 
    
   This memo 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. 
    
10. Conclusion 
 
   Issues such as user identification, access-control, tracking and 
   billing are common requirements for many content delivery services 
   (CDS) systems.  When CDS systems employ multicasting with 
   architectures based on currently existing multicasting standards, it 
   is often necessary to deploy non-standardized solutions to meet 
   these common requirements. It is recommended that requirements be 
   defined to set the groundwork for creating framework(s) and 
   solutions that address the various issues discussed in this memo 
   which are limiting the application of multicasting especially to 
   commercial, large-scale CDS services. Such requirements should take 
   into consideration a range of possible architectures based on 
   multiple business or usage models.    
    
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 20] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
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. 
    
   [3] Hayashi, et. al., "Accounting, Authentication and Authorization 
       Issues in Well Managed IP Multicasting Services", draft-ietf-
       mboned-maccnt-req-04.txt, February 2006 [Work in Progress]. 
 
    
   Authors' Addresses 
    
           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 Networks 
           600 Technology Park Drive 
           Billerica, MA 01801, USA 
           Phone: +1 978 288 7482 
           Email: haixiang@nortelnetworks.com 
    
           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 
    
           Susheela Vaidya 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 21] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
           Cisco Systems, Inc. 
           170 W. Tasman Drive 
           San Jose, CA  95134 
           Phone: +1-408-525-1952 
           Email: svaidya@cisco.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.
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 22] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   April, 2006 
    
    
    
Full Copyright Statement 
    
   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 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 ietf-
   ipr@ietf.org. 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 23] 
    
   Internet Draft   draft-ietf-mboned-rac-issues-03.txt   Aprilh, 2006 
    
    
    
Expiration 
    
   This Internet-Draft will expire on October 21, 2006. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
    
    
   Hayashi, He, Satou, Ohta, Vaidya                          [Page 24]