draft-ietf-mboned-rac-issues-02.txt   draft-ietf-mboned-rac-issues-03.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Networks Internet Draft Haixiang He, Nortel Networks
Expires: September 6, 2006 Hiroaki Satou, NTT Expires: October 21, 2006 Hiroaki Satou, NTT
Hiroshi Ohta, NTT Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
March 5, 2006 April 19, 2006
Issues Related to Receiver Access Control in the Current Multicast Issues Related to Receiver Access Control in the Current Multicast
Protocols Protocols
<draft-ietf-mboned-rac-issues-02.txt> <draft-ietf-mboned-rac-issues-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006. This Internet-Draft will expire on October 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006) Copyright (C) The Internet Society (2006)
Abstract Abstract
This memo evaluates the extent to which current multicasting This memo evaluates the extent to which current multicasting
protocols can be used to address common requirements for commercial, protocols can be used to address common requirements for commercial,
large-scale IP multicasting. Four existing possible multicasting 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 architectures (with or without some form of access or content
control) are presented. Then each architecture is analyzed with control) are presented. Then each architecture is analyzed with
respect to how it can or cannot satisfactorily address each issue. respect to how it can or cannot satisfactorily address each issue.
This memo concludes that for many of these issues the possible This memo concludes that for many of these issues the possible
architectures based on present standards as they now exist require architectures based on present standards as they now exist require
non-standardized solutions to meet common use requirements. This non-standardized solutions to meet common use requirements. This
memo recommends for requirements to be defined that would set the memo recommends for requirements to be defined that would set the
groundwork for framework(s) and solutions that sufficiently address groundwork for framework(s) and solutions that sufficiently address
these limitations. these limitations.
skipping to change at page 2, line 31 skipping to change at page 2, line 32
1. Introduction....................................................3 1. Introduction....................................................3
2. Definitions and Abbreviations...................................4 2. Definitions and Abbreviations...................................4
2.1 Definitions....................................................4 2.1 Definitions....................................................4
2.2 Abbreviations..................................................5 2.2 Abbreviations..................................................5
3. Common use models and network architecture implications.........5 3. Common use models and network architecture implications.........5
4. Issues in multicasting related to commercial and large-scale 4. Issues in multicasting related to commercial and large-scale
implementations....................................................7 implementations....................................................7
4.1 Access limits and resource issues..............................7 4.1 Access limits and resource issues..............................7
4.2 Capability to distinguish between receivers (end hosts)........7 4.2 Capability to distinguish between receivers (end hosts)........7
4.3 Capability to distinguish between users (as opposed to merely 4.3 Capability to distinguish between users (as opposed to merely
hosts).............................................................7 hosts).............................................................8
4.4 Minimizing Channel Join Latency and Leave Latency..............8 4.4 Minimizing Channel Join Latency and Leave Latency..............8
4.5 Surveillance of receiver by sender.............................8 4.5 Surveillance of receiver by sender.............................8
4.5.1 Precise access logging.......................................8 4.5.1 Precise access logging.......................................8
4.5.2 How to share user information................................8 4.5.2 How to share user information................................8
4.5.3 Trustworthy logs to monitor user activity....................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.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.7 Sharing of Infrastructure for Support of Triple Play Services..9
4.8 DRM Protection.................................................9 4.8 DRM Protection.................................................9
5. Description of existing architectures...........................9 5. Description of existing architectures...........................9
5.1 IGMP/MLD.......................................................9 5.1 IGMP/MLD......................................................10
5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.11 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.11
5.3 Unicast Control with IGMP/MLD.................................12 5.3 Unicast Control with IGMP/MLD.................................13
5.4 IGMP/MLD with Multicast Encryption............................13 5.4 IGMP/MLD with Multicast Encryption............................13
6. Evaluation of architectures by issue...........................14 6. Evaluation of architectures by issue...........................14
6.1 Access limit capabilities, compared by architecture...........14 6.1 Access limit capabilities, compared by architecture...........14
6.2 Capability to distinguish between receivers, compared by 6.2 Capability to distinguish between receivers, compared by
architecture......................................................15 architecture......................................................15
6.3 Capability to distinguish between users, compared by 6.3 Capability to distinguish between users, compared by
architecture......................................................16 architecture......................................................16
6.4 Maintain guaranteed quality-level of data delivery (Voice, 6.4 Maintain guaranteed quality-level of data delivery (Voice,
Video), compared by architecture..................................17 Video), compared by architecture..................................17
6.5 Fast leave for fast surfing capability, compared by architecture 6.5 Fast leave for fast surfing capability, compared by architecture
..................................................................17 ..................................................................17
6.6 Surveillance of receiver by sender, compared by architecture..18 6.6 Surveillance of receiver by sender, compared by architecture..18
6.7.Notification to users of the result of the join request compared 6.7 Notification to users of the result of the join request compared
by architecture...................................................19 by architecture...................................................19
6.8 Comparison summary............................................19 6.8 Comparison summary............................................19
7. IANA considerations............................................20 7. Relevance to non-commercial deployments........................20
8. Security considerations........................................20 8. IANA considerations............................................20
9. Conclusion.....................................................20 9. Security considerations........................................20
Normative References..............................................20 10. Conclusion....................................................20
Normative References..............................................21
Comments..........................................................22 Comments..........................................................22
Full Copyright Statement..........................................23 Full Copyright Statement..........................................23
Intellectual Property.............................................23 Intellectual Property.............................................23
Expiration........................................................24 Expiration........................................................24
Acknowledgement...................................................24 Acknowledgement...................................................24
1. Introduction 1. Introduction
The intention of this memo is to initiate a discussion on the state The intention of this memo is to initiate a discussion on the state
of current multicasting protocols deployed for commercial, large- of current multicasting protocols deployed for commercial, large-
scale multicasting and their capabilities to provide receiver access scale multicasting and their capabilities to provide receiver access
control. 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 Existing IP multicasting protocols (as presented in Section 5) were
designed to meet certain sets of requirements that do not designed to meet certain sets of requirements that do not
necessarily include architectural considerations intended to support necessarily include architectural considerations intended to support
commercial services. This memo presents a number of issues network commercial services. This memo presents a number of issues network
providers may face when they attempt to apply current multicasting providers may face when they attempt to apply current multicasting
standards to commercial services. The extent to which existing standards to commercial services. The extent to which existing
multicast protocols can or cannot satisfactorily deal with these multicast protocols can or cannot satisfactorily deal with these
issues is explored. A few network models based on a range of issues is explored. A few network models based on a range of
different business models are presented as a basis for defining different business models are presented as a basis for defining
skipping to change at page 19, line 17 skipping to change at page 19, line 17
-Multicast Encryption: -Multicast Encryption:
If logs are recorded for each renewal of keys, then it is possible 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 to track activity on a per-user basis. However if logs are only
recorded per content data download then such tracking is not recorded per content data download then such tracking is not
possible. possible.
It should be noted that authentication of the source of each It should be noted that authentication of the source of each
join/leave message is important. join/leave message is important.
6.7.Notification to users of the result of the join request compared by 6.7 Notification to users of the result of the join request compared by
architecture architecture
Comparison of currently possible protocol-based solutions: Comparison of currently possible protocol-based solutions:
-IGMP/MLD: -IGMP/MLD:
After the join it is not possible to notify the user of the result After the join it is not possible to notify the user of the result
of the join request. of the join request.
-L2/L3 authentication with access control policy: -L2/L3 authentication with access control policy:
After the join it is not possible to notify the user of the result After the join it is not possible to notify the user of the result
skipping to change at page 20, line 11 skipping to change at page 20, line 11
In this section a variety of existing architectures used for In this section a variety of existing architectures used for
multicasting based on current standards were compared and evaluated. multicasting based on current standards were compared and evaluated.
None of these architectures can sufficiently meet all of the common None of these architectures can sufficiently meet all of the common
requirements for accounting, authentication and authorization in requirements for accounting, authentication and authorization in
commercial, large-scale IP multicasting. Therefore it is commercial, large-scale IP multicasting. Therefore it is
recommended that framework(s) for sufficiently addressing such recommended that framework(s) for sufficiently addressing such
requirements be explored. requirements be explored.
7. IANA considerations 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. This memo does not raise any IANA consideration issues.
8. Security considerations 9. Security considerations
This memo does not raise any new security issues which are not This memo does not raise any new security issues which are not
already existing in original protocols. Enhancement of multicast already existing in original protocols. Enhancement of multicast
access control capabilities may enhance security performance. access control capabilities may enhance security performance.
9. Conclusion 10. Conclusion
Issues such as user identification, access-control, tracking and Issues such as user identification, access-control, tracking and
billing are common requirements for many content delivery services billing are common requirements for many content delivery services
(CDS) systems. When CDS systems employ multicasting with (CDS) systems. When CDS systems employ multicasting with
architectures based on currently existing multicasting standards, it architectures based on currently existing multicasting standards, it
is often necessary to deploy non-standardized solutions to meet is often necessary to deploy non-standardized solutions to meet
these common requirements. It is recommended that requirements be these common requirements. It is recommended that requirements be
defined to set the groundwork for creating framework(s) and defined to set the groundwork for creating framework(s) and
solutions that address the various issues discussed in this memo solutions that address the various issues discussed in this memo
which are limiting the application of multicasting especially to which are limiting the application of multicasting especially to
skipping to change at page 24, line 7 skipping to change at page 24, line 7
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Expiration Expiration
This Internet-Draft will expire on September 6, 2006. This Internet-Draft will expire on October 21, 2006.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 17 change blocks. 
20 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/