draft-ietf-mboned-rac-issues-00.txt   draft-ietf-mboned-rac-issues-01.txt 
Tsunemasa Hayashi, NTT Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Networks Internet Draft Haixiang He, Nortel Networks
Expires: January 4, 2006 Hiroaki Satou, NTT Expires: April 15, 2006 Hiroaki Satou, NTT
Hiroshi Ohta, NTT Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems Susheela Vaidya, Cisco Systems
July 4, 2005 October 12, 2005
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-00.txt> <draft-ietf-mboned-rac-issues-01.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
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsolet ed by other documents at
time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 January 4, 2006. This Internet-Draft will expire on April 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005) Copyright (C) The Internet Society (2005)
Abstract Abstract
This I-D evaluates the extent to which current multicasting protocols This I-D evaluates the extent to which current multicasting protocols
can be used to address common requirements for commercial, large- can be used to address common requirements for commercial, large-
scale IP multicasting. Four existing possible multicasting scale IP multicasting. Four existing possible multicasting
skipping to change at page 2, line 27 skipping to change at page 2, line 27
groundwork for creating standardized ways to overcome these groundwork for creating standardized ways to overcome these
limitations. limitations.
Copyright Notice...................................................1 Copyright Notice...................................................1
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..................................................4 2.2 Abbreviations..................................................4
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.................................................6 implementations....................................................6
4.1 Access limits and resource issues..............................6 4.1 Access limits and resource issues..............................6
4.2 Capability to distinguish between receivers (end hosts)........6 4.2 Capability to distinguish between receivers (end hosts)........6
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).............................................................7
4.4 Channel "leave latency"........................................7 4.4 Channel "leave latency"........................................7
4.5 Surveillance of receiver by sender.............................7 4.5 Surveillance of receiver by sender.............................7
4.5.1 Precise access log...........................................7 4.5.1 Precise access log...........................................7
4.5.2 How to share user information................................7 4.5.2 How to share user information................................7
4.5.3 Trustworthy logs to monitor user activity....................8 4.5.3 Trustworthy logs to monitor user activity....................8
4.6 Notification to users of the result of the join request........8 4.6 Notification to users of the result of the join request........8
4.7 Triple Play....................................................8 4.7 Triple Play....................................................8
4.8 DRM Protection.................................................8 4.8 DRM Protection.................................................8
5. Description of existing architectures...........................8 5. Description of existing architectures...........................8
5.1 IGMP/MLD.......................................................8 5.1 IGMP/MLD.......................................................8
5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy..9 5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy.10
5.3 Unicast Control with IGMP/MLD.................................10 5.3 Unicast Control with IGMP/MLD.................................11
5.4 IGMP/MLD with Multicast Encryption............................11 5.4 IGMP/MLD with Multicast Encryption............................11
6. Evaluation of architectures by issue...........................11 6. Evaluation of architectures by issue...........................12
6.1 Access limit capabilities, compared by architecture...........11 6.1 Access limit capabilities, compared by architecture...........12
6.2 Capability to distinguish between receivers, compared by 6.2 Capability to distinguish between receivers, compared by
architecture..................................................12 architecture......................................................13
6.3 Capability to distinguish between users, compared by architecture 6.3 Capability to distinguish between users, compared by architecture
..................................................................13 ..................................................................13
6.4 Maintain guaranteed quality-level of data delivery (Voice, Video), 6.4 Maintain guaranteed quality-level of data delivery (Voice, Video),
compared by architecture......................................13 compared by architecture..........................................14
6.5 Fast leave for fast surfing capability, compared by architecture 6.5 Fast leave for fast surfing capability, compared by architecture
..................................................................14 ..................................................................14
6.6 Surveillance of receiver by sender, compared by architecture..14 6.6 Surveillance of receiver by sender, compared by architecture..15
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...............................................15 by architecture...................................................15
6.8 Comparison summary............................................15 6.8 Comparison summary............................................16
7. IANA considerations............................................15 7. IANA considerations............................................16
8. Security considerations........................................16 8. Security considerations........................................16
9. Conclusion.....................................................16 9. Conclusion.....................................................16
Normative References..............................................16 Normative References..............................................17
Comments..........................................................17 Full Copyright Statement..........................................19
Full Copyright Statement..........................................18 Intellectual Property.............................................19
Intellectual Property.............................................18 Acknowledgement...................................................19
Expiration........................................................18
Acknowledgement...................................................18
1. Introduction 1. Introduction
The intention of this I-D is to initiate a discussion on the state of The intention of this I-D is to initiate a discussion on the state of
current multicasting protocols deployed for commercial, large-scale current multicasting protocols deployed for commercial, large-scale
multicasting and their capabilities to provide receiver access multicasting and their capabilities to provide receiver access
control. control.
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 necessarily designed to meet certain sets of requirements that do not necessarily
include architectural considerations intended to support commercial include architectural considerations intended to support commercial
services. This I-D presents a number of issues network providers may services. This I-D presents a number of issues network providers may
face when they attempt to apply current multicasting standards to face when they attempt to apply current multicasting standards to
commercial services. The extent to which existing multicast commercial services. The extent to which existing multicast
protocols can or cannot satisfactorily deal with issue is explored. protocols can or cannot satisfactorily deal with these issues is
A few network models based on a range of different business models explored. A few network models based on a range of different
are presented as a basis for defining requirements. business models are presented as a basis for defining requirements.
Multicasting can be useful to make the network more scalable when a Multicasting can be useful to make the network more scalable when a
large volume of information needs to be distributed to a large number large volume of information needs to be distributed to a large number
of receivers. However, multicasting according to current standards of receivers. However, multicasting according to current standards
(e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting (e.g., IGMPv3[1] and MLDv2[2]) has drawbacks compared to unicasting
in terms of its commercial applicability because of the insufficiency in terms of its commercial applicability because of the insufficiency
of access control and protect network resources against malicious use of access control and protect network resources against malicious use
or accidents. In order to be applicable to large-scale commercial or accidents. In order to be applicable to large-scale commercial
networks, multicast networks need to have the same capabilities which networks, multicast networks need to have the same capabilities which
are currently supported by unicast networks. Such issues important are currently supported by unicast networks. Such issues which are
to commercial, large-scale implementations of multicasting are listed. important to commercial, large-scale implementations of multicasting
Next, a few possible existing architectures used for multicasting are listed. Next, a few possible existing architectures used for
with access control based on current standards are presented. multicasting with access control based on current standards are
Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2 Authentication with presented. Specifically 1) IGMP/ MLD, 2) IGMP/MLD with L2
ACL 3) Unicast Control with IGMP/MLD and 4) IGMP/MLD with Multicast Authentication with ACL 3) Unicast Control with IGMP/MLD and 4)
Encryption will each be presented and described. Each architecture IGMP/MLD with Multicast Encryption will each be presented and
is discussed with respect to the presented list of issues. described. Each architecture is discussed with respect to the
presented list of issues.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1 Definitions 2.1 Definitions
For the purposes of this I-D the following definitions apply: For the purposes of this I-D the following definitions apply:
Accounting: actions for grasping each user's behavior, when she/he Accounting: actions for grasping each user's behavior, when she/he
starts/stops to receive a channel, which channel she/he receives, etc. starts/stops to receive a channel, which channel she/he receives, etc.
skipping to change at page 5, line 4 skipping to change at page 4, line 50
ACL: Access Control List ACL: Access Control List
CDS: Content Delivery Services CDS: Content Delivery Services
CSP: Content Service Provider CSP: Content Service Provider
DRM: Data Rights Management DRM: Data Rights Management
KEI: Key Exchange Identifier KEI: Key Exchange Identifier
NSP: Network Service Provider
NSP: Network Service Provider
QoS: Quality of Service QoS: Quality of Service
3. Common use models and network architecture implications 3. Common use models and network architecture implications
Issues such as user identification, access-control, tracking and Issues such as user identification, access-control, tracking and
billing are common requirements for commercial content delivery billing are common requirements for commercial content delivery
services (CDS) systems (and are important in many non-commercial CDS services (CDS) systems (and are important in many non-commercial CDS
systems as well.) These same requirements should be met for CDS systems as well.) These same requirements should be met for CDS
systems that employ multicasting. systems that employ multicasting.
In some cases a single entity may design and be responsible for a In some cases a single entity may design and be responsible for a
system that covers the various common high-level requirements of a system that covers the various common high-level requirements of a
commercial multicasting system such as 1) content serving, 2) the commercial multicasting system such as 1) content serving, 2) the
infrastructure to multicast it, 3) network and content access control infrastructure to multicast it, 3) network and content access control
mechanisms. In many cases however the content provision and network mechanisms. In many cases however the content provision and network
provision roles are divided between separate entities. The I-D provision roles are divided between separate entities. The I-D
draft-ietf-mboned-maccnt-req-00.txt[3] provides more detail of the draft-ietf-mboned-maccnt-00.txt provides more detail of the multiple
multiple versus single entity CDS network model. versus single entity CDS network model.
As such it should not be assumed that the entity responsible for the As such it should not be assumed that the entity responsible for the
multicasting structure and the entity responsible for content serving multicasting structure and the entity responsible for content serving
are the same. Indeed because the infrastructure for multicasting is are the same. Indeed because the infrastructure for multicasting is
expensive and many content holders are not likely to be competent at expensive and many content holders are not likely to be competent at
building and maintaining complicated infrastructures necessary for building and maintaining complicated infrastructures necessary for
multicasting, many content holders would prefer to purchase transport multicasting, many content holders would prefer to purchase transport
and management services from a network service provider and thus and management services from a network service provider and thus
share the infrastructure costs with other content holders. share the infrastructure costs with other content holders.
skipping to change at page 5, line 43 skipping to change at page 5, line 41
Similarly commercial network service providers do not generally Similarly commercial network service providers do not generally
specialize in providing content and are unlikely to build and specialize in providing content and are unlikely to build and
maintain such a resource-intensive system without a certain level of maintain such a resource-intensive system without a certain level of
demand from content holders. demand from content holders.
The business model of a single NSP providing multicasting services to The business model of a single NSP providing multicasting services to
multiple CSP has certain implications: multiple CSP has certain implications:
- Need for user tracking and billing capabilities - Need for user tracking and billing capabilities
- Need for network access control and/or content access control - Need for network access control and/or content access control
satisfactory to the requirements of the CSP satisfactory to the requirements of the CSP
-Methods for sharing information between the NSP and CSP to make
- Methods for sharing information between the NSP and CSP to the above two possible
make the above two possible
When the NSP and CSP are the same single entity the general When the NSP and CSP are the same single entity the general
requirements are as follows. requirements are as follows.
- Need for user tracking and user-billing capabilities - Need for user tracking and user-billing capabilities
-Need for access control and/or content protection at level the
- Need for access control and/or content protection at level entity deems appropriate
the entity deems appropriate
In the next section issues in multicasting related to commercial and In the next section issues in multicasting related to commercial and
large-scale implementations are presented. Some presented issues are large-scale implementations are presented. Some presented issues are
not pertinent to cases where the NSP and CSP are the same entity. not pertinent to cases where the NSP and CSP are the same entity.
4. Issues in multicasting related to commercial and large-scale 4. Issues in multicasting related to commercial and large-scale
implementations implementations
This section lists issues related to receiver access control in This section lists issues related to receiver access control in
current multicasting protocols which are especially important to current multicasting protocols which are especially important to
commercial, large-scale multicasting. More details concerning the commercial, large-scale multicasting. More details concerning the
requirements related to these issues are provided in a separate I-D requirements related to these issues are provided in a separate I-D
draft-ietf-mboned-maccnt-req-00.txt[3]. References to that document draft-ietf-mboned-maccnt-00.txt[3]. References to that document are
are provided as applicable below. provided as applicable below.
4.1 Access limits and resource issues 4.1 Access limits and resource issues
For commercial applications of multicasting, network and content For commercial applications of multicasting, network and content
providers generally wish to be able to control the number of groups a 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 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 to limit the number of users accessing a multicast stream because of
bandwidth and processing issues between the receiver and the bandwidth and processing issues between the receiver and the
multicast server. multicast server.
skipping to change at page 6, line 47 skipping to change at page 6, line 44
each service. In order to guarantee certain QoS levels, it is each service. In order to guarantee certain QoS levels, it is
important for network providers to be able to protect their network important for network providers to be able to protect their network
resources from being wasted (either maliciously or accidentally). resources from being wasted (either maliciously or accidentally).
More detail on this topic is provided in I-D draft-ietf-mboned- More detail on this topic is provided in I-D draft-ietf-mboned-
maccnt-00.txt, section "Issue of network resource protection." maccnt-00.txt, section "Issue of network resource protection."
4.2 Capability to distinguish between receivers (end hosts) 4.2 Capability to distinguish between receivers (end hosts)
Currently the sender cannot distinguish which receivers (end hosts) Currently the sender cannot distinguish which receivers (end hosts)
are actually receiving its information with current protocols are actually receiving its information with existing protocols
(IGMP/MLD.) The sender must rely on the information from the (IGMP/MLD.) The sender must rely on the information from the
multicasting routers. This can be complicated if the sender and multicasting routers. This can be complicated if the sender and
routers are maintained by different entities. There is currently no routers are maintained by different entities. There is currently no
standard way to share such information. standard way to share such information.
4.3 Capability to distinguish between users (as opposed to merely 4.3 Capability to distinguish between users (as opposed to merely
hosts) hosts)
Many content providers would like to have detailed information on Many content providers would like to have detailed information on
which users (as opposed to merely hosts identified by physical which users (as opposed to merely hosts identified by physical
addresses, etc.) are consuming their content and information on addresses, etc.) are consuming their content and information on
their usage behavior. More detail on this topic can be found in I-D their usage behavior. More detail on this topic can be found in I-D
draft-ietf-mboned-maccnt-00.txt, section "User identification" draft-ietf-mboned-maccnt-00.txt, section "User identification."
4.4 Channel "leave latency" 4.4 Channel "leave latency"
Commercial implementations of IP multicasting are likely to have Commercial implementations of IP multicasting are likely to have
strict requirements in terms of user experience. Leave latency is strict requirements in terms of user experience. Leave latency is
the time between when a user sends a signal that he/she wishes to 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" a group and when the network recognizes the "leave."
A separate I-D draft-ietf-mboned-maccnt-00.txt provides more detail A separate I-D draft-ietf-mboned-maccnt-00.txt provides more detail
on this topic in the section "Channel 'leave latency'" on this topic in the section "Channel 'leave latency'"
skipping to change at page 10, line 36 skipping to change at page 11, line 9
+----------+ +--------|-+ +----------+ +----------+ +----------+ +--------|-+ +----------+ +----------+
| |
V V
Key: Key:
Auth: Authentication Auth: Authentication
5.3 Unicast Control with IGMP/MLD 5.3 Unicast Control with IGMP/MLD
The receiver first sends a unicast request to the sender which 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 resides in the CP's domain. This method is the same as that used in
unicast video-on demand (VoD) systems. If authorization is unicast video-on demand (VoD) systems. If authorization is
successful the sender sends the multicast address information via successful the sender sends the multicast address information via
unicast. With this multicast address the receiver does a IGMP\MLD unicast. With this multicast address the receiver does a IGMP\MLD
join as in described in 5.1. join as in described in 5.1.
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Sender | | Router | | L2SW | | Receiver | | Sender | | Router | | L2SW | | Receiver |
| | | | | | | | | | | | | | | |
| |<------------------------------1,Request-| | | |<------------------------------1,Request-| |
| | | | | | | | | | | | | | | |
| |-------------------------------2,Success>| | | |-------------------------------2,Success>| |
| | | | | | | | | | | | | | | |
skipping to change at page 12, line 5 skipping to change at page 12, line 41
Comparison of currently available architectures with respect to Comparison of currently available architectures with respect to
limiting the access of multicast groups limiting the access of multicast groups
- IGMP/MLD: It is not possible to limit data reception. - IGMP/MLD: It is not possible to limit data reception.
- L2/L3 authentication with access control policy: - L2/L3 authentication with access control policy:
With an ACL it is possible to limit access of multicast groups. With an ACL it is possible to limit access of multicast groups.
However it should be discussed as to how scalable this approach is However it should be discussed as to how scalable this approach is
because configuring an ACL could be a labor-intensive task. because configuring an ACL could be a labor-intensive task.
- IGMP/MLD with Unicast control: - IGMP/MLD with Unicast control
It is possible for malicious users to reconfigure the receiver's It is possible for malicious users to reconfigure the receiver's
terminal to ignore the Unicast control. In this case, this terminal to ignore the Unicast control. In this case, this
maliciously reconfigured terminal could send a join message even if maliciously reconfigured terminal could send a join message even if
it is rejected by the network. In such a case, the ineligible it is rejected by the network. In such a case, the ineligible
receiver would be able to receive the multicast. As such, this receiver would be able to receive the multicast. As such, this
method may not be strong enough to exclude ineligible access. method may not be strong enough to exclude ineligible access.
-Multicast Encryption: -Multicast Encryption:
It is possible for receivers to receive IP packets, even if they do 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 not possess the keys to decrypt them. A receiver may also be able to
skipping to change at page 14, line 34 skipping to change at page 15, line 22
-Multicast Encryption: -Multicast Encryption:
Even if a quick leave is possible, delivery of the Key Exchange Even if a quick leave is possible, delivery of the Key Exchange
Identifier(KEI) is slow. Identifier(KEI) is slow.
6.6 Surveillance of receiver by sender, compared by architecture 6.6 Surveillance of receiver by sender, compared by architecture
Comparison of currently possible protocol-based solutions: Comparison of currently possible protocol-based solutions:
-IGMP/MLD: -IGMP/MLD:
With this protocol it is possible to log separately join and leave With this protocol it is possible to separately log join and leave
actions, but it is difficult to match these join and leave actions actions, but it is difficult to match these join and leave actions
when analyzing the logs is heavy computation (scalability with because analyzing the logs requires heavy computation (related to the
millions of users). scalability with millions of users).
-L2/L3 authentication with access control policy: -L2/L3 authentication with access control policy:
In this solution, the leave action is not recorded unless some In this solution, the leave action is not recorded unless some
additional mechanism such as IGMP/MLD snooping is used. In some additional mechanism such as IGMP/MLD snooping is used. In some
cases, users disconnect their terminals without sending leave cases, users disconnect their terminals without sending leave
messages. In this case, it is not possible to determine when each messages. In this case, it is not possible to determine when each
user's entry in the ACL should be deactivated. user's entry in the ACL should be deactivated.
-IGMP/MLD with Unicast control : -IGMP/MLD with Unicast control :
In this solution the leave action is not recorded. In this solution the leave action is not recorded.
skipping to change at page 16, line 35 skipping to change at page 17, line 16
Normative References Normative References
[1] B. Cain, et. al., "Internet Group Management Protocol, Version 3", [1] B. Cain, et. al., "Internet Group Management Protocol, Version 3",
RFC3376, October 2002. RFC3376, October 2002.
[2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2) [2] R. Vida, et. al., "Multicast Listener Discovery Version 2 (MLDv2)
for IPv6", RFC3810, June 2004. for IPv6", RFC3810, June 2004.
[3] Hayashi, et. al., "Accounting, Authentication and Authorization [3] Hayashi, et. al., "Accounting, Authentication and Authorization
Issues in Well Managed IP Multicasting Services", draft-ietf- Issues in Well Managed IP Multicasting Services", draft-ietf-
mboned-maccnt-req-00.txt, April 2005 mboned-maccnt-req-01.txt, October 2005 [Work in Progress].
Authors' Addresses Authors' Addresses
Tsunemasa Hayashi Tsunemasa Hayashi
NTT Network Innovation Laboratories NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
Phone: +81 46 859 8790 Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp Email: hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He Haixiang He
skipping to change at page 18, line 47 skipping to change at page 19, line 47
http://www.ietf.org/ipr. 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 January 4, 2006. This Internet-Draft will expire on April 15, 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. 31 change blocks. 
56 lines changed or deleted 52 lines changed or added

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