Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Networks
Expires: August 13, 2005 Hiroaki Satou, NTT
Hiroshi Ohta, NTT
Susheela Vaidya, Cisco Systems
February 13 2005
Issues Related to Receiver Access Control in the Current Multicast
Protocols
<draft-hayashi-rac-issues-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 13, 2005
Copyright Notice
Copyright (C) The Internet Society (2005)
Hayashi, He, Satou, Ohta, Vaidya [Page 1]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
Abstract
This I-D lists and describes issues related to receiver access
control in current multicasting protocols which are especially
important to commercial, large-scale multicasting. A few common
business models for content and network provision are presented to
provide background and explain the motivation of this work. 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 I-D 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 I-D recommends for requirements to be defined
that would set the groundwork for creating standardized ways to
overcome 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....................................................6
4.1 Access limits and resource issues..............................6
4.1.1 Access limit for multicast groups............................6
4.1.2 Maintain guaranteed quality-level of data delivery (Voice,
Video).............................................................7
4.1.3 Issue of network resource protection.........................7
4.1.3.1 Control mechanism to support bandwidth of multicast stream
from a physical port of edge router or switch......................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 Channel "leave latency"........................................8
4.5 Surveillance of receiver by sender.............................9
4.5.1 Precise access log...........................................9
4.5.2 How to share user information................................9
4.5.3 Trustworthy logs to monitor user activity....................9
Hayashi, He, Satou, Ohta, Vaidya [Page 2]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
4.6 Notification to users of the result of the join request.......10
4.7 Triple Play...................................................10
4.8 DRM Protection................................................10
5. Description of existing architectures..........................10
5.1 IGMP/MLD......................................................10
5.2 IGMP/MLD with L2 Authentication with ACL......................11
5.3 Unicast Control with IGMP/MLD.................................12
5.4 IGMP/MLD with Multicast Encryption............................12
6. Evaluation of architectures by issue...........................13
6.1 Access limit capabilities, compared by architecture...........13
6.2 Capability to distinguish between receivers, compared by
architecture......................................................14
6.3 Capability to distinguish between users, compared by architecture
..................................................................14
6.4 Maintain guaranteed quality-level of data delivery (Voice, Video),
compared by architecture..........................................15
6.5 Fast leave for fast surfing capability, compared by architecture
..................................................................15
6.6 Surveillance of receiver by sender, compared by architecture..16
6.7.Notification to users of the result of the join request compared
by architecture...................................................16
6.8 Triple Play capability, compared by architecture..............17
7. IANA considerations............................................17
8. Security considerations........................................17
9. Conclusion.....................................................17
Normative References..............................................18
Full Copyright Statement..........................................19
Intellectual Property.............................................19
Acknowledgement...................................................19
1. Introduction
The intention of this I-D is to initiate a discussion on issues
related to receiver access control in the current multicast protocols
especially when deployed for commercial, large-scale multicasting.
It is hoped that further drafts will define requirements to address
the issues raised in this draft.
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 I-D 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
Hayashi, He, Satou, Ohta, Vaidya [Page 3]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
protocols can or cannot satisfactorily deal with issue is explored.
A few network models based on a range of different business models
are presented as a basis for defining requirements in a future
document.
IP multicasting is becoming widely used as a method to save network
resources such as bandwidth or CPU processing power of the sender's
server for cases where a large volume of information needs to be
distributed to a large number of receivers. This trend can be
observed both in enterprise use and in broadband services provided by
network operator/service providers.
Distance learning within a university and in-house (in-company)
sharing of multimedia information are examples of enterprise use. In
these examples, sources generate high-bit rate (e.g., 6Mbit/s)
streaming information. When the number of receivers becomes large,
such systems do not scale well without multicasting.
On the other hand, content delivery service (CDS) is an example of a
broadband service provided by network operators/service providers.
Distribution of movies and other video programs to each user are
typical services. Each channel requires large bandwidth (e.g.,
6Mbit/s) and operator/service providers need to provide many channels
to make their service attractive. In addition, the number of
receivers is large (e.g., more than a few thousands). The system to
provide this service does not scale well without multicasting.
As such, 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. This I-D first presents a few common business models for
content and network provision in order to provide background and
explain the motivation of this work. Then, issues which are important
for 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
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 I-D the following definitions apply:
Hayashi, He, Satou, Ohta, Vaidya [Page 4]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
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. The receiver should be distinguished from the user
(see below.)
User: a human with a user account. A user may possibly use multiple
reception devices. Multiple users may use the same reception device.
2.2 Abbreviations
For the purposes of this draft the following abbreviations apply:
ACL: Access Control List
CDS: Content Delivery Services
CSP: Content Service 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
infrastructure to multicast it, 3) network and content access control
mechanisms.
Hayashi, He, Satou, Ohta, Vaidya [Page 5]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
However 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 the
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 NSP providing multicasting services to
multiple CSP 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 CSP
-Methods for sharing information between the NSP and CSP to make
the above two possible
When the NSP and CSP 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
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 CSP 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.
4.1 Access limits and resource issues
4.1.1 Access limit for multicast groups
For commercial applications of multicasting network and content
providers generally wish to be able to control the number of groups a
Hayashi, He, Satou, Ohta, Vaidya [Page 6]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
host can access at the same time. If any user can access any group
without limitation network providers may waste network resources, and
this may have implications on the Quality of Service (QoS) they can
provide to other users. Access control is also important to prevent
against unauthorized access of data as it is a priority of many
content providers to control access to their content from reasons
ranging to IPR issues to privacy issues.
4.1.2 Maintain guaranteed quality-level of data delivery (Voice, Video)
For NSP to guarantee and charge for a certain quality of data
delivery it is important that they can limit the number of receivers
to a level that their bandwidth and servers can handle.
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.
4.1.3 Issue of network resource protection
In order to guarantee certain QoS levels as described in the above
section (4.1.2), it is important for network providers to be able to
protect their network resources from being wasted, (either
maliciously or accidentally).
4.1.3.1 Control mechanism to support bandwidth of multicast stream from
a physical port of edge router or switch
The network should be able to control the combined bandwidth for all
groups both at the physical port of the edge router or switch and on
each link between routers and/or NW switches so that these given
physical entities are not overflown by the traffic.
4.1.3.2. Number of groups delivered from a physical port of edge router
and switch
So that the NSP can guarantee a certain level of QoS to the CSP and
the receivers it is important that it be able to control the number
of groups that are served from any certain edge router or switch at
any certain time.
When the NSP and the CSP are the same entity the QoS obligations are
simplified since guarantees would be made only to the users.
4.2 Capability to distinguish between receivers (end hosts)
Currently the sender cannot distinguish which receivers (end hosts)
are actually receiving its information with current protocols
Hayashi, He, Satou, Ohta, Vaidya [Page 7]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
(IGMP/MLD.) The sender must rely on the information from the
multicasting routers. This can be complicated if the sender and
routers are maintained by different entities. There is currently no
standard way to share such information.
4.3 Capability to distinguish between users (as opposed to merely
hosts)
Many content providers would like to have detailed information on
what users are consuming their content and information on their usage
behavior. This information might be used for ratings information,
billing, auditing, and programming decisions. Also content and
network providers may wish to provide users with access to their
usage history. If a network provider and content provider are
separate entities there are no protocols for sharing such information
on a user basis.
For example, if NSPs are going to provide access control and/or usage
information to a CSP on a user level it is important that the two
entities be able to distinguish users and communicate appropriate
information. For example, it is quite conceivable that a CSP might
want to bill or track separate users who may use the same device
(such as at Internet cafes, at hotels, with families, etc.) In such a
case it is important that the NSP record information on who is
actually downloading data on the user-level since the CSP would
otherwise not be able to receive this information. Also for example,
in many usage models it is important to provide portability, in other
words to allow users to access the network from different devices
and/or different access points. If NSPs are going to provide access
control and/or billing capability to a separate-entity CSP, this
capability of distinguishing users is important.
If the same entity is providing both content and network services,
the entity has access to sufficient data to distinguish users.
Nevertheless a standard way of relaying this information between
servers on the network would be attractive from the standpoint of
potential decreased development and operational costs.
4.4 Channel "leave latency"
Commercial implementations of IP multicasting are likely to have
strict requirements in terms of user experience. Leave latency is
the time between when a user sends a signal that he/she wishes to
"leave" a group and when the network recognizes the "leave."
Leave latency impacts :
i. Acceptable end-user experience for fast channel surfing.
Hayashi, He, Satou, Ohta, Vaidya [Page 8]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
In an IP-TV application, users are not going to be
receptive to slow response time when changing channels.
ii. Resource consumption
With a low "leave latency" network providers could
minimize streaming content when there are no audiences.
4.5 Surveillance of receiver by sender
4.5.1 Precise access log
In many commercial multicast situations, NSP and CSP would like to be
able to precisely grasp the content consumption of end-users. Such
information might be used for "identifying highly viewed content" for
advertising revenue, ratings calculations, programming decisions, etc.
To assemble such an understanding of end-user behavior, it is
necessary to precisely log information such as who (host/user) is
accessing what content at what time (join action) until what time
(leave action). The result of the access-control decision (e.g.
results of authorization) would also be valuable information.
4.5.2 How to share user information
For commercial multicast applications where NSP and CSP are different
entities, there are a number of issues regarding how to share user
information between the NSP and CSP. 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.
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
terminal which can be tampered with.
Hayashi, He, Satou, Ohta, Vaidya [Page 9]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
4.6 Notification to users of the result of the join request
It is necessary to provide information to the user about the status
of his/her join request(granted/denied/other).
4.7 Triple Play
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: voice (VoIP), video, and broadband
Internet access services.
4.8 DRM Protection
Digital Rights Management (DRM) is important but out of scope of this
I-D.
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.
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--| |
| | | | | | | |
| |------------>x------------------2,Data->| |
| | | | | | | | |
| | | | | | | | |
+----------+ +--------|-+ +----------+ +----------+
|
V
Hayashi, He, Satou, Ohta, Vaidya [Page 10]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
5.2 IGMP/MLD with L2 Authentication with ACL
With a basic implementation of IGMP/MLD implementation, no
authorization is performed on the receiver. It is possible to
combine an IGMP/MLD implementation with Layer 2 Authentication to
provide a control mechanism for accessing the network using 802.X. In
this scenario a receiver first requests to the L2 authentication
server for access to 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 sever. 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 of the methods 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 | | | | | | |
| |------------>x------------------6,Data-->| |
| | | | | | | | |
+----------+ +--------|-+ +----------+ +----------+
|
V
Key:
Auth: Authentication
Hayashi, He, Satou, Ohta, Vaidya [Page 11]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
5.3 Unicast Control with IGMP/MLD
The receiver first sends a unicast request to the sender, 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.
+----------+ +----------+ +----------+ +----------+
| 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 implementation, 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 12]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
+----------+ +----------+ +----------+ +----------+
| 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 authentication with ACL:
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. As such, this method may not
be strong enough to exclude ineligible accesses.
-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
Hayashi, He, Satou, Ohta, Vaidya [Page 13]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
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 available protocols.
-IGMP/MLD:
The sender has no direct line of contact with the receiver and
therefore cannot distinguish on a receiver-basis. (If the
interface is fixed to the receiver 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 CSP and NSP are different
companies because CSP cannot access this join-log.)
-L2 authentication with ACL:
At the moment of L2 authentication it is possible to recognize
receivers, but if there are multiple content service providers (CSP)
a single L2 Authorization Server cannot distinguish among the CSPs.
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 CSP and NSP are different companies because the
CSP cannot access this join-log.)
-IGMP/MLD with Unicast control :
It is possible to distinguish among receivers using Unicast control.
-Multicast Encryption:
If the Content Service Provider 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 CSP.
6.3 Capability to distinguish between users, compared by architecture
Comparison of currently available protocols:
-IGMP/MLD:
Since there is no user-based information, it is not possible to
distinguish on the user-level.
-L2 authentication with ACL:
At the moment of L2 Authentication it is possible to distinguish on
the user-level.
Hayashi, He, Satou, Ohta, Vaidya [Page 14]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
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.
6.4 Maintain guaranteed quality-level of data delivery (Voice, Video),
compared by architecture
Comparison of currently available protocols:
-IGMP/MLD:
It is not possible to reject a user attempting to access even if
there are not sufficient resources.
-L2 authentication with ACL:
The AAA server does not know whether there are sufficient resources
or not. While it is possible to control QoS levels on a link-by-link
basis, it is not possible on a service-by-service basis.
-IGMP/MLD with Unicast control :
When the CSP and NSP are separate entities it is not possible for the
CSP to make a proper authorization decision because only the NSP
grasps the network resource availability.
-Multicast Encryption:
It is not possible to reject a user attempting to access even if
there are not sufficient resources because the user can receive data
even without a valid key.
6.5 Fast leave for fast surfing capability, compared by architecture
Comparison of currently available protocols:
-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 authentication with ACL:
Hayashi, He, Satou, Ohta, Vaidya [Page 15]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
It is possible to track on a per host level (based on host address)
therefore fast leave for fast surfing capability can be achieved.
-IGMP/MLD with Unicast control :
Even if a quick leave is possible, changing to a new channel using
Unicast Control is slow (latency problem).
-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 available protocols:
-IGMP/MLD:
With this protocol it is possible to log separately join and leave
actions, but it is difficult to match these join and leave actions
when analyzing the logs is heavy computation (scalability with
millions of users).
-L2 authentication with ACL:
In this protocol the leave action is not recorded.
-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.
6.7.Notification to users of the result of the join request compared by
architecture
Comparison of currently available protocols:
-IGMP/MLD:
After the join it is not possible to notify the user of the result of
the join request.
-L2 authentication with ACL:
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.
Hayashi, He, Satou, Ohta, Vaidya [Page 16]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
-Multicast Encryption:
After the join it is not possible to notify the user of the result of
the join request.
6.8 Triple Play capability, compared by architecture
Comparison of currently available protocols:
-IGMP/MLD:
It is necessary for NSP to integrate all "triple play services" into
a single access control system. No standards currently exist.
-L2 authentication with ACL:
When services have a per-channel fee structure that require real-time
changes to the access control list (such as prepayment for specific
shows), it is not possible to integrate these services with other
services. On the other hand for a fixed subscription based service
where the access control list is not changed, it is possible to
integrate the triple-play services on one infrastructure.
-IGMP/MLD with Unicast control :
It is necessary for NSP to integrate all "triple play services" into
a single access control system. No standards currently exist.
-Multicast Encryption:
It is necessary for NSP to integrate all "triple play services" into
a single access control system. No standards currently exist.
7. IANA considerations
This I-D does not raise any IANA consideration issues.
8. Security considerations
This I-D 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.
9. 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
Hayashi, He, Satou, Ohta, Vaidya [Page 17]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
common requirements. It is recommended that requirements be defined
to serve as a basis for creating standardized ways to address the
various issues discussed in this I-D 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.
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.
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
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
Phone: +1-408-525-1952
Email: svaidya@cisco.com
Hayashi, He, Satou, Ohta, Vaidya [Page 18]
Internet Draft draft-hayashi-rac-issues-00.txt February, 2005
Full Copyright Statement
Copyright (C) The Internet Society (2004).
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 IETF's procedures with respect to rights in IETF 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hayashi, He, Satou, Ohta, Vaidya [Page 19]